|
|
Tag Switching combines the performance and capabilities of Layer 2 (data link layer) switching with the proven scalability of Layer 3 (network layer) routing. It enables service providers to meet challenges brought about by explosive growth and provides the opportunity for differentiated services without necessitating the sacrifice of existing infrastructure. The Tag Switching architecture is remarkable for its flexibility. Data can be transferred over any combination of Layer 2 technologies, support is offered for all Layer 3 protocols, and scaling is possible well beyond anything offered in today's networks.
Specifically Tag Switching can efficiently enable the delivery of IP services over an ATM switched network. It supports the creation of different routes between a source and a destination on a purely router-based Internet backbone. Service providers who use Tag Switching can save money and increase revenue and productivity.
Tag Switching offers the following benefits:
ATM-TSR---A Tag Switching router with a number of TC-ATM interfaces. The router forwards the cells among these interfaces using tags carried in the VPI/VCI field.
ATM edge TSR---A router that is connected to the ATM-TSR cloud through TC-ATM interfaces. The ATM edge TSR adds tags to untagged packets and strips tags from tagged packets.
forwarding equivalence class---A set of packets, which, however different they may be, are indistinguishable to the forwarding function.
headend---The upstream, transmit end of a tunnel.
tag---A short fixed-length label that tells switching nodes how the data (packets or cells) should be forwarded.
tag imposition---The act of putting the first tag on a packet.
tag edge router---The router that performs tag imposition.
Tag Switch---A node that forwards units of data (packets or cells) on the basis of tags.
tag-switched path (TSP)---A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn through Tag Switching mechanisms. A tag-switched path can be chosen dynamically, based on normal routing mechanisms, or through configuration.
Tag Switching Router (TSR)---A Layer 3 router that forwards packets based on the value of a tag encapsulated in the packets.
tailend---The downstream, receive end of a tunnel.
TDP---Tag Distribution Protocol. The protocol used to distribute tag bindings on TSRs.
TFIB---Tag Forwarding Information Base. The data structure used by the switching function to switch tagged packets.
TIB---Tag Information Base. A database used to store tags learned from other TSRs as well as tags assigned by the local TSR.
traffic engineering---The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
traffic engineering tunnel--- A tag-switched path tunnel that is used for engineering traffic. It is set up through means other than normal Layer 3 routing and is used to direct traffic over a path different from the one that Layer 3 routing would cause it to take.
tag-switched path (TSP) tunnel---A configured connection between two routers, using Tag Switching to carry the packets.
Tag VC (TVC)---An ATM virtual circuit that is set up through ATM TSR tag distribution procedures.
tag-controlled ATM interface (TC-ATM interface)---An interface on a router or switch that uses tag distribution procedures to negotiate tag VCs.
Tag Switching on the router requires that Cisco Express Forwarding (CEF) be enabled. Refer to the Cisco Express Forwarding (CEF) feature documentation for configuration information.
The recommended minimum memory requirement in platforms carrying full Internet routing information is the same as for Cisco Express Forwarding. For more details, see the Release Notes for Cisco IOS 11.1 CC and Feature Modules.
Tag switching is supported on the following platforms:
The interfaces supported are
This feature supports RFC 2105, Cisco Systems' Tag Switching Architectural Overview.
Tag switching is a high-performance packet forwarding technology. It integrates the performance and traffic management capabilities of data link layer (Layer 2) switching with the scalability and flexibility of network layer (Layer 3) routing.
In conventional Layer 3 forwarding, as a packet traverses the network, each router extracts all the information relevant to forwarding the packet from the Layer 3 header. This information is then used as an index for a routing table lookup to determine the packet's next hop.
In the most common case, the only relevant field in the header is the destination address field, but in some cases other header fields may also be relevant. As a result, the header analysis must be done independently at each router through which the packet passes, and a complicated lookup must also be done at each router.
In Tag Switching, the analysis of the Layer 3 header is done just once. The Layer 3 header is then mapped into a fixed length, unstructured value called a tag.
Many different headers can map to the same tag, as long as those headers always result in the same choice of next hop. In effect, a tag represents a forwarding equivalence class---that is, a set of packets, which, however different they may be, are indistinguishable to the forwarding function.
The initial choice of tag need not be based exclusively on the contents of the Layer 3 header; it can also be based on policy. This allows forwarding decisions at subsequent hops to be based on policy as well.
Once a tag is chosen, a short tag header is put at the front of the Layer 3 packet, so that the tag value can be carried across the network with the packet. At each subsequent hop, the forwarding decision can be made simply by looking up the tag. There is no need to re-analyze the header. Since the tag is a fixed length and unstructured value, looking it up is fast and simple.
Each tag switching router (TSR) makes an independent, local decision as to which tag value is used to represent which forwarding equivalence class. This association is known as a tag binding. Each TSR informs its neighbors of the tag bindings it has made. This is done by means of the Tag Distribution Protocol (TDP).
When a tagged packet is being sent from TSR A to a neighboring TSR B, the tag value carried by the packet is the tag value that B assigned to represent the packet's forwarding equivalence class. Thus the tag value changes as the packet travels through the network.
A tag represents a forwarding equivalence class, but it does not represent a particular path through the network. In general, the path through the network continues to be chosen by the existing
Layer 3 routing algorithms such as OSPF, EIGRP, and BGP. That is, at each hop when a tag is looked up, the next hop chosen is determined by the dynamic routing algorithm.
In conventional Layer 3 routing, network topologies frequently include multiple paths between two points, but the normal routing procedure is to select a single path as the Layer 3 route between two points regardless of the load on the links that implement the path. As a consequence, some links are congested and some are underused.
Traffic engineering provides a way to override routing protocols across multiple routers. It gives you the ability to direct selected traffic over specific paths in the network in order to efficiently use network resources and provide different levels of service.
To engineer your network traffic, you follow a two-step process. First, you define a sequence of links between two routers. Tag switching is used to tunnel packets between the two routers over these links. The links collectively form a tag switched path (TSP) tunnel, which defines a traffic engineering path. Second, you select the traffic which you want forwarded on to the tunnel.
Configuration and the initiation of the tunnel are controlled by the headend (transmit end) router. Per-tunnel configuration of other routers is unnecessary.
Routers create and maintain the traffic engineering tunnels based on information you enter through the command line interface (CLI). See the section called "Command Reference."
This section describes three sample cases where Tag Switching is configured on Cisco 7500/7200 series routers. These cases show the levels of control possible in selecting how Tag Switching is deployed in a network.
Table 1 lists the cases, including the steps to perform Tag Switching and their corresponding Cisco IOS CLI commands.
| This case | Describes |
Case 1---Enable Tag Switching Incrementally in a Network | The steps necessary for incrementally deploying Tag Switching through a network, assuming that packets to all destination prefixes should be tag switched. |
Case 2---Route Tagged Packets to Network A Only | The mechanism by which Tag Switching can be restricted, such that packets are tag switched to only a subset of destinations. |
Case 3---Limit Tag Distribution on a Tag Switching Network | The mechanisms for further controlling the distribution of tag within a network. |
For more information about the IOS CLI commands, see the section called "Command Reference."
Figure 1 shows a router-only Tag Switching network with Ethernet interfaces. The following sections outline the procedures for configuring Tag Switching and displaying Tag Switching information in a network based on the topology shown in Figure 1.
In the first case, the assumption is that you want to deploy Tag Switching incrementally throughout a network of routers, but that you do not want to restrict which destination prefixes are tag switched. For a description of the commands listed in these cases, see the section on "Command Reference."
To enable Tag Switching incrementally in a network, perform these steps and enter the commands in router configuration mode (see Figure 1).
| Task | Command |
|---|---|
Step 1 Enable Tag Switching between R1 and R3. | |
Step 2 Enable Tag Switching between R3 and R4. | |
After you perform these steps, R1 applies tags to packets that are forwarded through interface e0/1, with a next hop to R3.
Tag switching can be enabled throughout the rest of the network by the repetition of steps 1 and 2 as appropriate on other routers until all routers and interfaces are enabled for Tag Switching.
In the second case to be considered here, the assumption is that you want to enable Tag Switching for a subset of destination prefixes. This option might be used to test Tag Switching across a large network. In this case, you would configure the system so that only a small number of destinations is tag switched (for example, internal test networks) without the majority of traffic being affected.
Perform the steps in the following table at each router in the network in router configuration mode (see Figure 1),
.
| Task | Command |
|---|---|
Step 1 Limit tag distribution by using access lists. | Router(config)# access-list-1 permit A |
Step 2 Instruct the router to advertise for network A only to all adjacent tag switch routers. Any tags for other destination networks that the router may have distributed before this step are withdrawn. | Router(config)# tag-switching advertise-tags for 1 |
The third case demonstrates the full control which is available to you in determining the destination prefixes and paths for which Tag Switching is enabled.
Configure the routers so that packets addressed to network A are tagged, all other packets are untagged, and only links R1-R3, R3-R4, R4-R6, and R6-R7 carry tagged packets addressed to A. For example, suppose the normally routed path for packets arriving at R1 addressed to network A or network B is R1, R3, R5, R6, R7. A packet addressed to A would flow tagged on links R1-R3 and R6-R7, and untagged on links R3-R5 and R5-R6. A packet addressed to B would follow the same path, but would be untagged on all links.
Assume that at the outset the routers are configured so that packets addressed to network A are tagged and all other packets are untagged (as at the completion of Case 2).
Use the tag-switching advertise-tags command and access lists to limit tag distribution. Specifically, you need to configure routers R2, R5, and R8 to distribute no tags to other routers. This ensures that no other routers send tagged packets to any of those three. You also need to configure routers R1, R3, R4, R6, and R7 to distribute tags only for network A and to distribute them only to the appropriate adjacent router; that is, R3 distributes its tag for network A only to R1, R4 only to R3, and so on.
To limit tag distribution on a Tag Switching network, perform these steps in router configuration mode.
| Task | Command |
|---|---|
Step 1 Configure R2 to distribute no tags. | Router(config)# no tag-switching advertise-tags |
Step 2 Configure R5 to distribute no tags. | Router(config)# no tag-switching advertise-tags |
Step 3 Configure R8 to distribute no tags | Router(config)# no tag-switching advertise-tags |
Step 4 Configure R3 by defining an access list and by instructing the router to distribute tags for the networks permitted by access list 1 (created as part of Case 2) to the routers permitted by access list 2. | Router(config)# access-list 2 permit R1 |
Step 5 Configure R3. | Router(config)# access-list 1 permit A |
Step 6 Configure R4. | Router(config)# access-list 1 permit A (Enter the actual network address and netmask in place of permit A and permit R3. For example, access-list 1 permit 192.5.34. 0 0.0.0.255.) |
Step 7 Configure R6. | Router(config)# access-list 1 permit A (Enter the actual network address and netmask in place of permit A and permit R4. For example, access-list 1 permit 192.5.34. 0 0.0.0.255.) |
Step 8 Configure R7. | Router(config)# access-list 1 permit A (Enter the actual network address and netmask in place of permit A and permit R6. For example, access-list 1 permit 192.5.34. 0 0.0.0.255.) |
This section describes a sample traffic engineering case. This case describes the steps necessary to engineer traffic across the "middle" path R3-R5-R8 (see Figure 2).
The assumption is made that traffic from R1 and R2 (in Figure 2), which is intended for R11, would be directed by Layer 3 routing along the "upper" path R3-R4-R7-R10-R11.
Figure 2 shows a router-only Tag Switching network with traffic-engineered paths.
The following table lists the configuration commands you need to engineer traffic across the "middle" path R3-R5-R8 by building a tunnel R1-R3-R5-R8-R10, without affecting the path taken by traffic from R2 (see Figure 2).
To engineer traffic across a path, perform the following steps in router configuration mode:
| Task | Command |
Step 1 Configure support for TSP tunnel signalling along the path. Note: To configure a Cisco 7200 series router, enter ip cef. To configure a Cisco 7500 series router, enter ip cef distributed. | |
Step 2 Configure a TSP tunnel at the headend. | |
Step 3 Need static route steps???? |
|
This section provides sample configurations for the Cisco 7500/7200 series routers. It contains the following sections:
The following example shows you how to configure Tag Switching incrementally throughout a network of routers. You enable Tag Switching first between one pair of routers (in this case, R1 and R3 shown in Figure 1) and add routers step by step until every router in the network is tag switch enabled.
router-1# configuration terminalrouter-1(config)# ip cef distributedrouter-1(config)# tag-switching iprouter-1(config)# interface e0/1router-1(config-if)# tag-switching iprouter-1(config-if)# exitrouter-1(config)#
router-3# configuration terminalrouter-3(config)# ip cef distributedrouter-3(config)# tag-switching iprouter-3(config)# interface e0/1router-3(config-if)# tag-switching iprouter-3(config-if)# exitrouter-3(config)#
The following example shows the commands you enter at each of the routers to enable Tag Switching for only a subset of destination prefixes (see Figure 1).
Router(config)# access-list-1 permit ARouter(config)# tag-switching advertise-tags for 1
The following example shows the commands you enter to configure the routers to select the destination prefixes and paths for which Tag Switching is enabled. When you configure R2, R5, and R8 to distribute no tags to other routers, you ensure that no routers send them tagged packets. You also need to configure routers R1, R3, R4, R6, and R7 to distribute tags only for network A and only to the applicable adjacent router. This configuration ensures that R3 distributes its tag for
network A only to R1, R4 only to R3, R6 only to R4, and R7 only to R6 (see Figure 1).
router-2(config)# no tag-switching advertise-tagsrouter-5(config)# no tag-switching advertise-tagsrouter-8(config)# no tag-switching advertise-tagsrouter-1(config)# access-list permit R1router-1(config)# no tag-switching advertise-tags for 1router-1(config)# tag-switching advertise-tags for 1 to 2router-1(config)# exit
router-3# router-3# access-list 2 permit R1router-3# tag-switching advertise-tags for 1 to 2router-3# exit
router-4# router-4# access-list 2 permit R3router-4# tag-switching advertise-tags for 1 to 2router-4# exit
router-6# access-list 1 permit Arouter-6# access-list 2 permit R4router-6# tag-switching advertise-tags for 1 to 2router-6# exit
router-7# access-list 1 permit Arouter-7# access-list 2 permit R6router-7# tag-switching advertise-tags for 1 to 2router-7# exit
Use the show tag-switching tdp bindings command to display the contents of the Tag Information Base (TIB). The display can show the entire database or can be limited to a subset of entries, based on prefix, input or output tag values or ranges, and/or the neighbor advertising the tag.
Router# show tag-switching tdp bindings
Matching entries:
tib entry: 10.92.0.0/16, rev 28
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.102.0.0/16, rev 29
local binding: tag: 26
remote binding: tsr: 172.27.32.29:0, tag: 26
tib entry: 10.105.0.0/16, rev 30
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.205.0.0/16, rev 31
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.211.0.7/32, rev 32
local binding: tag: 27
remote binding: tsr: 172.27.32.29:0, tag: 28
tib entry: 10.220.0.7/32, rev 33
local binding: tag: 28
remote binding: tsr: 172.27.32.29:0, tag: 29
tib entry: 99.101.0.0/16, rev 35
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 100.101.0.0/16, rev 36
local binding: tag: 29
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 171.69.204.0/24, rev 37
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 172.27.32.0/22, rev 38
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 210.10.0.0/16, rev 39
local binding: tag: imp-null(1)
tib entry: 210.10.0.8/32, rev 40
remote binding: tsr: 172.27.32.29:0, tag: 27
Use the show tag-switching forwarding-table command to display the contents of the Tag Forwarding Information Base (TFIB). The TFIB lists the tags, output interface information, prefix or tunnel associated with the entry, and number of bytes received with each incoming tag. A request can show the entire TFIB or can be limited to a subset of entries. A request can also be restricted to selected entries in any of the following ways:
Router# show tag-switching forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
26 Untagged 10.253.0.0/16 0 Et4/0/0 172.27.32.4
28 1/33 10.15.0.0/16 0 AT0/0.1 point2point
29 Pop tag 10.91.0.0/16 0 Hs5/0 point2point
1/36 10.91.0.0/16 0 AT0/0.1 point2point
30 32 10.250.0.97/32 0 Et4/0/2 10.92.0.7
32 10.250.0.97/32 0 Hs5/0 point2point
34 26 10.77.0.0/24 0 Et4/0/2 10.92.0.7
26 10.77.0.0/24 0 Hs5/0 point2point
35 Untagged [T] 10.100.100.101/32 0 Tu301 point2point
36 Pop tag 168.1.0.0/16 0 Hs5/0 point2point
1/37 168.1.0.0/16 0 AT0/0.1 point2point
[T] Forwarding through a TSP tunnel.
View additional tagging info with the 'detail' option
Use the show tag-switching interfaces command to show information about the requested interface or about all interfaces on which Tag Switching is enabled. The per-interface information includes the interface name and indications as to whether IP Tag Switching is enabled and operational.
Router# show tag-switching interfaces Interface IP Tunnel Operational Hssi3/0 Yes Yes No ATM4/0.1 Yes Yes Yes (ATM tagging) Ethernet5/0/0 No Yes Yes Ethernet5/0/1 Yes No Yes Ethernet5/0/2 Yes No No Ethernet5/0/3 Yes No Yes Ethernet5/1/1 Yes No No
The following shows sample output from the show tag-switching interfaces command when you specify detail:
Router# show tag interface detail
Interface Hssi3/0:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging not operational
MTU = 4470
Interface ATM4/0.1:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI = 1, Control VC = 0/32
Interface Ethernet5/0/0:
IP tagging not enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/2:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging not operational
MTU = 1500
Interface Ethernet5/0/3:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Use the show tag-switching tdp neighbors command to display the status of Tag Distribution Protocol (TDP) sessions. The neighbor information branch can have information about all TDP neighbors or can be limited to the neighbor with a specific IP address or, TDP identifier, or to TDP neighbors known to be accessible over a specific interface.
Router# show tag-switching tdp neighbors
Peer TDP Ident: 10.220.0.7:1; Local TDP Ident 172.27.32.29:1
TCP connection: 10.220.0.7.711 - 172.27.32.29.11029
State: Oper; PIEs sent/rcvd: 17477/17487; Downstream on demand
Up time: 01:03:00
TDP discovery sources:
ATM0/0.1
Peer TDP Ident: 210.10.0.8:0; Local TDP Ident 172.27.32.29:0
TCP connection: 210.10.0.8.11004 - 172.27.32.29.711
State: Oper; PIEs sent/rcvd: 14656/14675; Downstream;
Up time: 2d5h
TDP discovery sources:
Ethernet4/0/1
Ethernet4/0/2
POS6/0/0
Addresses bound to peer TDP Ident:
99.101.0.8 172.27.32.28 10.105.0.8 10.92.0.8
10.205.0.8 210.10.0.8
The following example shows you how to configure support for tag-switched path (TSP) tunnel signalling along a path and on each interface crossed by one or more tunnels:
Router(config)# ip cef distributed Router(config)# tag-switching tsp-tunnels Router(config)# interface e0/1 Router(config-if)# tag-switching tsp-tunnels Router(config-if)# interface e0/2 Router(config-if)# tag-switching tsp-tunnels Router(config-if)# exit
The following example shows you how to set the encapsulation of the tunnel to Tag Switching and how to define hops in the path for the TSP.
Follow these steps to configure a two-hop tunnel, hop 0 being the headend router. For hops 1 and 2, you specify the IP addresses of the incoming interfaces for the tunnel. The tunnel interface number is arbitrary, but must be less than 65,535.
Router(config)# interface tunnel 2003 Router(config-if)# tunnel mode tag-switching Router(config-if)# tunnel tsp-hop 1 10.10.0.12 Router(config-if)# tunnel tsp-hop 2 10.50.0.24 lasthop Router(config-if)# exit
To shorten the previous path, you delete a hop by entering the following commands:
Router(config)# interface tunnel 2003 Router(config-if)# no tunnel tsp-hop 2 Router(config-if)# tunnel tsp-hop 1 10.10.0.12 lasthop Router(config-if)# exit
Use the show tag-switching tsp tunnels command to display information about the configuration and status of selected tunnels.
Router# show tag-switching tsp-tunnels
Signalling Summary:
TSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL ID DESTINATION STATUS CONNECTION
10.106.0.6.2003 10.2.0.12 up up
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 11.1 command references.
This section includes commands supported for Tag Switching. There are no examples of command output for the configuration commands, since they typically do not generate output.
All other commands used with this feature are documented in the Cisco IOS Release 11.1 command references.
To display the requested entries from the ATM TDP tag binding database, use the show tag-switching atm-tdp bindings command. The ATM TDP database contains TIB entries for tag VCs on TC-ATM interfaces.
show tag-switching atm-tdp bindings [network {mask | length}]network | (Optional.) Destination network number. |
mask | Network mask in the form A.B.C.D (destination prefix). |
length | Mask length (1 to 32). |
local-tag vpi vci | (Optional.) Select tag VC value assigned by this router. |
remote-tag vpi vci | (Optional.) Select tag values assigned by the other router. |
neighbor interface | (Optional.) Select tag values assigned by neighbor on a specified interface. |
Privileged EXEC
The display output can show entries from the entire database, or it can be limited to a subset of entries based on prefix, VC tag value, and/or an assigning interface.
The following is router sample output from the show tag-switching atm-tdp bindings command:
Router# show tag-switching atm-tdp bindings
Destination: 10.16.0.16/32
Tailend Router ATM1/0.1 1/35 1/34 Active, VCD=2
Destination: 10.24.0.0/24
Tailend Router ATM1/0.1 1/39 Active, VCD=3
Destination: 10.15.0.15/32
Tailend Router ATM1/01 1/33 Active, VCD=4
Destination: 10.23.0 0/24
Tailend Router ATM1/01 1/37 Active, VCD=5
Table 2 lists the significant fields in this display.
| Field | Description |
Destination: | Destination (network/mask) |
Tailend Router | Types of VC. Options are Tailend---VC that terminates at this router Headend---VC that originates at this router Transit---VC that passes through a switch
|
ATM1/0.1 | Interface. |
1/35 | VPI/VCI. |
Active | TVC state: Active---Set up and working. Bindwait---Waiting for response. Remote Resource Wait---Waiting for resources (VPI/VCI space) to be available on the downstream device. Parent Wait---Transit VC input side waiting for output side to become active. |
VCD=2 | Virtual circuit descriptor number. |
The following is ATM switch sample output from the show tag-switching atm-tdp bindings command:
Switch# show tag-switching atm-tdp bindings
Destination: 6.6.6.6/32
Tailend Switch ATM0/0/3 1/34 Active -> Terminating Active
Destination: 150.0.0.0/16
Tailend Switch ATM0/0/3 1/35 Active -> Terminating Active
Destination: 4.4.4.4/32
Transit ATM0/0/3 1/33 Active -> ATM0/1/1 1/33 Active
show tag-switching atm-tdp summary
To display the ATM TDP tag capabilities, use the show tag-switching atm-tdp capability command.
show tag-switching atm-tdp capabilityThis command has no keywords or arguments.
Privileged EXEC
The following example shows the display from the show tag-switching atm-tdp capability command.
Router# show tag-switching atm-tdp capability
VPI VCI Alloc Odd/Even VC Merge
ATM0/1/0 Range Range Scheme Scheme IN OUT
Negotiated [100 - 101] [33 - 1023] UNIDIR - -
Local [100 - 101] [33 - 16383] UNIDIR EN EN
Peer [100 - 101] [33 - 1023] UNIDIR - -
VPI VCI Alloc Odd/Even VC Merge
ATM0/1/1 Range Range Scheme Scheme IN OUT
Negotiated [201 - 202] [33 - 1023] BIDIR - -
Local [201 - 202] [33 - 16383] UNIDIR ODD NO NO
Peer [201 - 202] [33 - 1023] BIDIR EVEN - -
Table 3 lists the significant fields in this display.
| Field | Description |
|---|---|
VPI Range | Minimum and maximum number of VPIs supported on this interface. |
VCI Range | Minimum and maximum number of VCIs supported on this interface. |
Alloc Scheme | UNIDIR---Unidirectional capability indicates that the peer device can, within a single VPI, support binding of the same VCI to different prefixes on different directions of the link. BIDIR---Bidirectional capability indicates that within a single VPI, a single VCI can appear in one binding only. In this case, one peer device allocates bindings in the even VCI space, and the other in the odd VCI space. The system with the lower TDP identifier will assign even-numbered VCIs. The negotiated allocation scheme is UNIDIR, if and only if, both peer devices have UNIDIR capability. Otherwise it is BIDIR. |
Odd/Even Scheme | Indicates whether the local device or the peer device is assigning an odd- or even-numbered VCI when the negotiated scheme is BIDIR. It does not display any information when the negotiated scheme is UNIDIR. |
VC Merge | Indicates the type of VC merge support on this interface. IN---Indicates input interface merge capability. IN accepts the following values: · EN---The hardware interface supports VC merge and VC merge is enabled on the device. · DIS---The hardware interface supports VC merge and VC merge is disabled on the device. · NO---The hardware interface does not support VC merge. OUT---Indicates output interface merge capability. OUT accepts the same values as the input merge side. The VC merge capability is meaningful only on ATM switches. It is not negotiated. |
Negotiated | Set of options that both TDP peer devices have agreed to share on this interface. For example, the VPI or VCI allocation on either peer device remains within the negotiated ranges. |
Local | Options supported locally on this interface. |
Peer | Options supported by the remote TDP peer device on this interface. |
tag-switching atm control-vc
tag-switching atm vc-merge
tag-switching atm vpi
To display summary information on ATM tag bindings, use the show tag-switching atm-tdp summary command.
show tag-switching atm-tdp summaryThis command has no arguments or keywords.
Privileged EXEC
The following is sample output from the show tag-switching atm-tdp summary command:
Router# show tag-switching atm-tdp summary Total number of destinations: 788
TC-ATM bindings summary
interface total active bindwait local remote other
ATM0/0/0 594 592 1 296 298 1
ATM0/0/1 590 589 0 294 296 1
ATM0/0/2 1179 1178 0 591 588 1
ATM0/0/3 1177 1176 0 592 585 1
ATM0/1/0 1182 1178 4 590 588 0
Waiting for bind on ATM0/0/0 10.21.0.0/24
Table 4 lists the significant fields in this display.
| Field | Description |
|---|---|
Total number of destinations | The number of known destination address prefixes. |
interface | The name of an interface with associated ATM tag bindings. |
total | The total number of ATM tags on this interface. |
active | The number of ATM tags in an "active" state that are ready to use for data transfer. |
bindwait | The number of bindings that are waiting for a tag assignment from the neighbor TSR. |
local | The number of ATM tags assigned by this TSR on this interface. |
remote | The number of ATM tags assigned by the neighbor TSR on this interface. |
other | The number of ATM tags in a state other than "active" or "bindwait." |
Waiting for bind on ATM0/0/0 | A list of the destination address prefixes (on a particular interface) that are waiting for ATM tag assignment from the neighbor TSR. |
show tag-switching atm-tdp bindings
To display the contents of the Tag Forwarding Information Base (TFIB), use the show tag-switching forwarding-table command.
show tag-switching forwarding-table [{network {mask | length} | tags tag [- tag] |network | (Optional.) Show entry for specified destination only. |
mask | IP address of destination mask whose entry is to be shown. |
length | Number of bits in mask of destination. |
tags tag - tag | (Optional.) Show entries with specified local tags only. |
interface interface | (Optional.) Show entries with specified outgoing interface only. |
next-hop address | (Optional.) Show entries with specified neighbor as next hop only. |
tsp-tunnel [tunnel-id] | (Optional.) Show entries with specified TSP tunnel only, or all TSP tunnel entries. |
detail | (Optional.) Display information in long form (includes length of encapsulation, length of MAC string, maximum transmission unit (MTU), and all tags). |
Privileged EXEC
The optional parameters allow specification of a subset of the entire TFIB.
The following is sample output from the show tag-switching forwarding-table command:
Router# show tag-switching forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
26 Untagged 10.253.0.0/16 0 Et4/0/0 172.27.32.4
28 1/33 10.15.0.0/16 0 AT0/0.1 point2point
29 Pop tag 10.91.0.0/16 0 Hs5/0 point2point
1/36 10.91.0.0/16 0 AT0/0.1 point2point
30 32 10.250.0.97/32 0 Et4/0/2 10.92.0.7
32 10.250.0.97/32 0 Hs5/0 point2point
34 26 10.77.0.0/24 0 Et4/0/2 10.92.0.7
26 10.77.0.0/24 0 Hs5/0 point2point
35 Untagged [T] 10.100.100.101/32 0 Tu301 point2point
36 Pop tag 168.1.0.0/16 0 Hs5/0 point2point
1/37 168.1.0.0/16 0 AT0/0.1 point2point
[T] Forwarding through a TSP tunnel.
View additional tagging info with the 'detail' option
The following is sample output from the show tag-switching forwarding-table command when you specify detail:
Router# show tag-switching forwarding-table detail
Local Outgoing Prefix Bytes tag Outgoing NextHop
tag tag or VC or Tunnel Id switched interface
26 Untagged 10.253.0.0/16 0 Et4/0/0 172.27.32.4
MAC/Encaps=0/0, MTU=1504, Tag Stack{}
28 1/33 10.15.0.0/16 0 AT0/0.1 point2point
MAC/Encaps=4/8, MTU=4470, Tag Stack{1/33(vcd=2)}
00020900 00002000
29 Pop tag 10.91.0.0/16 0 Hs5/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
FF030081
1/36 10.91.0.0/16 0 AT0/0.1 point2point
MAC/Encaps=4/8, MTU=4470, Tag Stack{1/36(vcd=3)}
00030900 00003000
30 32 10.250.0.97/32 0 Et4/0/2 10.92.0.7
MAC/Encaps=14/18, MTU=1500, Tag Stack{32}
006009859F2A00E0F7E984828847 00020000
32 10.250.0.97/32 0 Hs5/0 point2point
MAC/Encaps=4/8, MTU=4470, Tag Stack{32}
FF030081 00020000
34 26 10.77.0.0/24 0 Et4/0/2 10.92.0.7
MAC/Encaps=14/18, MTU=1500, Tag Stack{26}
006009859F2A00E0F7E984828847 0001A000
26 10.77.0.0/24 0 Hs5/0 point2point
MAC/Encaps=4/8, MTU=4470, Tag Stack{26}
FF030081 0001A000
35 Untagged 10.100.100.101/32 0 Tu301 point2point
MAC/Encaps=0/0, MTU=1504, Tag Stack{}, via Et4/0/2
36 Pop tag 168.1.0.0/16 0 Hs5/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
FF030081
1/37 168.1.0.0/16 0 AT0/0.1 point2point
MAC/Encaps=4/8, MTU=4470, Tag Stack{1/37(vcd=4)}
00040900 00004000
Table 5 lists the significant fields in this display.
| Field | Description |
|---|---|
Local tag | Tag assigned by this router. |
Outgoing tag or VC | Tag assigned by next hop, or VPI/VCI used to get to next hop. Some of the entries you can have in this column are · [T] means forwarding through a TSP tunnel. · "Untagged" means there is no tag for the destination from the next hop, or Tag Switching is not enabled on the outgoing interface. · "Pop tag" means the next hop advertised an implicit NULL tag for the destination, and this router popped the top tag. |
Prefix or Tunnel Id | Address or tunnel to which packets with this tag are going. |
Bytes tag switched | Number of bytes switched with this incoming tag. |
Outgoing interface | Interface through which packets with this tag are sent. |
NextHop | IP address of neighbor that assigned the outgoing tag. |
Mac/Encaps | Length in bytes of Layer 2 header, and length in bytes of packet encapsulation, including Layer 2 header and tag header. |
MTU | Maximum transmission unit (MTU) of tagged packet. |
Tag Stack | All the outgoing tags. If the outgoing interface is TC-ATM, the VCD is also shown. |
00020900 00002000 | The actual encapsulation in hexadecimal form. There is a space shown between Layer 2 and tag header. |
To display information about one or more interfaces that have Tag Switching enabled, use the show tag-switching interfaces command.
show tag-switching interfaces [interface][detail]interface | (Optional.) The interface about which to display Tag Switching information. |
detail | (Optional.) Display information in long form. |
EXEC
You can show information about the requested interface or about all interfaces on which Tag Switching is enabled.
The following is sample output from the show tag-switching interfaces command:
Router# show tag-switching interfaces Interface IP Tunnel Operational Hssi3/0 Yes Yes No ATM4/0.1 Yes Yes Yes (ATM tagging) Ethernet5/0/0 No Yes Yes Ethernet5/0/1 Yes No Yes Ethernet5/0/2 Yes No No Ethernet5/0/3 Yes No Yes Ethernet5/1/1 Yes No No
ATM tagging).
Table 6 lists the significant fields in this display.
| Field | Description |
|---|---|
Interface | Interface name. |
IP | "Yes" if IP tagging has been enabled on this interface. |
Tunnel | "Yes" if TSP tunnel tagging has been enabled on this interface. |
Operational | Operational state. "Yes" if packets are being tagged. |
MTU | Maximum number of data bytes per tagged packet that will be transmitted. |
The following is sample output from the show tag-switching interfaces command when you specify detail:
Router# show tag-switching interface Ethernet2/0/1 detail
Interface Hssi3/0:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging not operational
MTU = 4470
Interface ATM4/0.1:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI = 1, Control VC = 0/32
Interface Ethernet5/0/0:
IP tagging not enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/2:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging not operational
MTU = 1500
Interface Ethernet5/0/3:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
tag-switching tsp-tunnels
tag-switching ip
To display the contents of the tag information base (TIB), use the show tag-switching tdp bindings command:
show tag-switching tdp bindings [network {mask | length} [longer-prefixes]] tag [- tag] [neighbor address] [local]network | (Optional.) Destination network number. |
mask | Network mask written as A.B.C.D. |
length | Mask length (1 to 32 characters). |
longer-prefixes | (Optional.) Select any prefix that matches mask with length# to 32. |
local-tag tag - tag | (Optional.) Display entries matching local tag values by this router. Use the - tag option to indicate tag range. |
remote-tag tag - tag | (Optional.) Display entries matching tag values assigned by a neighbor router. Use the |
neighbor address | (Optional.) Display tag bindings assigned by selected neighbor. |
local | (Optional.) Display local tag bindings. |
Privileged EXEC
A request can specify that the entire database be shown, or it or can be limited to a subset of entries. A request to show a subset of entries can be based on the prefix, on input or output tag values or on ranges, and/or the neighbor advertising the tag.
The following is sample output from the show tag-switching tdp bindings command. This form of the command causes the contents of the entire TIB to be displayed.
Router# show tag-switching tdp bindings
Matching entries:
tib entry: 10.92.0.0/16, rev 28
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.102.0.0/16, rev 29
local binding: tag: 26
remote binding: tsr: 172.27.32.29:0, tag: 26
tib entry: 10.105.0.0/16, rev 30
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.205.0.0/16, rev 31
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.211.0.7/32, rev 32
local binding: tag: 27
remote binding: tsr: 172.27.32.29:0, tag: 28
tib entry: 10.220.0.7/32, rev 33
local binding: tag: 28
remote binding: tsr: 172.27.32.29:0, tag: 29
tib entry: 99.101.0.0/16, rev 35
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 100.101.0.0/16, rev 36
local binding: tag: 29
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 171.69.204.0/24, rev 37
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 172.27.32.0/22, rev 38
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 210.10.0.0/16, rev 39
local binding: tag: imp-null(1)
tib entry: 210.10.0.8/32, rev 40
remote binding: tsr: 172.27.32.29:0, tag: 27
The following is sample output from the show tag tdp bindings 10.0.0.0 8 longer-prefixes neighbor 172.27.32.29 variant of the command; it displays tags learned from TSR 172.27.32.29 for network 10.0.0.0 and any of its subnets. The use of the neighbor option suppresses the output of local tags and tags learned from other neighbors.
Router# show tag tdp bindings 10.0.0.0 8 longer-prefixes neighbor 172.27.32.29
tib entry: 10.92.0.0/16, rev 28
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.102.0.0/16, rev 29
remote binding: tsr: 172.27.32.29:0, tag: 26
tib entry: 10.105.0.0/16, rev 30
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.205.0.0/16, rev 31
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.211.0.7/32, rev 32
remote binding: tsr: 172.27.32.29:0, tag: 28
tib entry: 10.220.0.7/32, rev 33
remote binding: tsr: 172.27.32.29:0, tag: 29
Table 7 lists the significant fields in this display.
| Field | Description |
|---|---|
tib entry | Indicates that the following lines are the TIB entry for a particular destination (network/mask). The revision number is used internally to manage tag distribution for this destination. |
remote binding | A list of outgoing tags for this destination learned from other Tag Switching Routers (TSRs). Each item on this list identifies the TSR from which the outgoing tag was learned and the tag itself. The TSR is identified by its TDP identifier. |
imp-null | The implicit null tag. This tag value instructs the upstream router to pop the tag entry off the tag stack before forwarding the packet. |
show tag-switching tdp neighbors
show tag-switching forwarding-table
To display the status of the TDP discovery process, use the show tag-switching tdp discovery command. Status means a list of interfaces over which TDP discovery is running.
show tag-switching tdp discoveryThis command has no arguments or keywords.
Privileged EXEC
The following is sample output from the show tag-switching tdp discovery command.
Router# show tag-switching tdp discovery
Local TDP Identifier:
172.27.32.29:0
TDP Discovery Sources:
Interfaces:
ATM0/0.1: xmit/recv
ATM0/0.1: xmit/rec
Ethernet4/0/1: xmit/recv
Ethernet4/0/2: xmit/recv
POS6/0/0: xmit/recv
Table 8 lists the significant fields in this display.
| Field | Description |
|---|---|
Local TDP Identifier | The TDP identifier for the local router. A TDP identifier is a 6-byte quantity displayed as an IP address:number. The Cisco convention is to use a router ID for the first 4 bytes of the TDP identifier, and integers starting with 0 for the final two bytes of the IP address:number. |
Interfaces | Lists the interfaces engaging in TDP discovery activity. xmit |
show tag-switching tdp neighbors
To display the status of Tag Distribution Protocol (TDP) sessions, enter the show tag-switching tdp neighbor command:
show tag-switching tdp neighbors {[address | interface] [detail]}address | (Optional.) The neighbor with this IP address. |
interface | (Optional.) TDP neighbors accessible over this interface. |
detail | (Optional.) Display information in long form. |
Privileged EXEC
The neighbor information branch can give information about all TDP neighbors, or it can be limited to
The following is sample output from the show tag-switching tdp neighbors command:
Router# show tag-switching tdp neighbors
Peer TDP Ident: 10.220.0.7:1; Local TDP Ident 172.27.32.29:1
TCP connection: 10.220.0.7.711 - 172.27.32.29.11029
State: Oper; PIEs sent/rcvd: 17477/17487; Downstream on demand
Up time: 01:03:00
TDP discovery sources:
ATM0/0.1
Peer TDP Ident: 210.10.0.8:0; Local TDP Ident 172.27.32.29:0
TCP connection: 210.10.0.8.11004 - 172.27.32.29.711
State: Oper; PIEs sent/rcvd: 14656/14675; Downstream
Up time: 2d5h
TDP discovery sources:
Ethernet4/0/1
Ethernet4/0/2
POS6/0/0
Addresses bound to peer TDP Ident:
99.101.0.8 172.27.32.28 10.105.0.8 10.92.0.8
10.205.0.8 210.10.0.8
Table 9 lists the significant fields in this display.
| Field | Description |
|---|---|
Peer TDP Ident | The TDP identifier of the neighbor (peer device) for this session. |
Local TDP Ident | The TDP identifier for the local TSR for this session. |
TCP connection | The TCP connection used to support the TDP session. The format for displaying the TCP connection is peer IP address.peer port |
State | The state of the TDP session. Generally this is Oper (operational), but transient is another possible state. |
PIEs sent/rcvd | The number of TDP protocol information elements (PIEs) sent to and received from the session peer device. The count includes the transmission and receipt of periodic keep alive PIEs, which are required for maintenance of the TDP session. |
Downstream | Indicates that the downstream method of tag distribution is being used for this TDP session. When the downstream method is used, a TSR advertises all of its locally assigned (incoming) tags to its TDP peer device (subject to any configured access list restrictions). |
Downstream on demand | Indicates that the downstream on demand method of tag distribution is being used for this TDP session. When the downstream on demand method is used, a TSR advertises its locally assigned (incoming) tags to its TDP peer device only when the peer device asks for them. |
Up time | The length of time the TDP session has existed. |
TDP discovery sources | The source(s) of TDP discovery activity that led to the establishment of this TDP session. |
Addresses bound to peer TDP Ident | The known interface addresses of the TDP session peer device. These are addresses that may appear as "next hop" addresses in the local routing table. They are used to maintain the Tag Forwarding Information Base (TFIB). |
show tag-switching tdp discovery
To display available TDP parameters, use the show tag-switching tdp parameters command:
show tag-switching tdp parametersThis command has no keywords or arguments.
Privileged EXEC
The following example shows the display from the show tag-switching tdp parameters command:
Router# show tag-switching tdp parameters Protocol version: 1 Downstream tag pool: min tag: 10; max_tag: 10000; reserved tags: 16 Session hold time: 15 sec; keep alive interval: 5 sec Discovery hello: holdtime: 15 sec; interval: 5 sec Discovery directed hello: holdtime: 15 sec; interval: 5 sec Accepting directed hellos
Table 10 lists the significant fields in this display.
| Field | Description |
|---|---|
Protocol version | Indicates the version of the Tag Distribution Protocol (TDP) running on the platform. |
Downstream tag pool | Describes the range of tags available for the platform to assign for Tag Switching. The tags available run from the smallest tag value (min tag) to the largest tag value (max tag), with a modest number of tags at the low end of the range (reserved tags) reserved for diagnostic purposes. |
Session hold time | Indicates the time to maintain a TDP session with a TDP peer device without receiving TDP traffic or a TDP keep alive from the peer device. |
keep alive interval | Indicates the interval of time between consecutive transmission TDP keep alive messages to a TDP peer device. |
Discovery hello | Indicates the amount of time to remember that a neighbor platform wants a TDP session without receiving a TDP Hello from the neighbor (holdtime), and the time interval between transmitting TDP Hello messages to neighbors (interval). |
Discovery directed hello | Indicates the amount of time to remember that a neighbor platform wants a TDP session when (1) the neighbor platform is not directly connected to the router and (2) the neighbor platform has not sent a TDP Hello message. The interval is known as holdtime. Also indicates the time interval between the transmission of Hello messages to a neighbor not directly connected to the router. |
Accepting directed hellos | Indicates that the platform will accept and act on Directed TDP Hello messages (may not be present). |
tag-switching tdp holdtime
tag-switching tdp discovery
To display information about the configuration and status of selected tunnels, use the show tag-switching tsp-tunnels command.
show tag-switching tsp-tunnels [{head | middle | tail | all | remote | address} [interface-number]] [brief]head | (Optional.) Displays information for tunnels that originate at the node. |
middle | (Optional.) Displays information for tunnels that pass through the node. |
tail | (Optional.) Displays information for tunnels that terminate at the node. |
all | (Optional.) Displays the combination of head, middle, and tail information for tunnels. |
remote | (Optional.) Displays information for tunnels that originate elsewhere; it is thus is the combination of middle and tail. |
address | (Optional.) Displays information for tunnels that use the specified address in their identifier. |
interface-number | (Optional.) Displays information for tunnels that use the specified number in their identifier. |
brief | Displays a brief summary of tunnel status and configuration. |
Privileged EXEC
The optional arguments restrict the set of tunnels displayed. With no optional arguments, the command displays all tunnels passing through the node.
Each TSP tunnel has a globally unique identifier. When signalling the TSP tunnel is signalled and is available at each hop, this identifier is used. This identifier is a combination of the originating IP address and the number of the IOS tunnel interface used in configuring the TSP tunnel at the headend.
The following is sample output from the show tag-switching tsp-tunnels command:
Signalling Summary:
TSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL ID DESTINATION STATUS CONNECTION
10.106.0.6 0 10.2.0.12 up up
Table 11 lists the significant fields in this display.
| Field | Description |
|---|---|
Signalling Summary | The status of the signalling and forwarding mechanism that is required in order for TSP tunnels to be signalled through the router. |
TSP Tunnels Process | The status of the TSP tunnel signalling process. This process interacts with the signalling protocol to manage signalled tunnels and monitors the state of established tunnels. |
RSVP Process | The status of the RSVP process. You use the RSVP protocol to signal tunnels. |
Forwarding | The status of the forwarding mechanism used to switch data through local TSP tunnel segments. |
TUNNEL ID | The identity of the tunnel being summarized as shown in the previous display output. The tunnel ID includes an IP address part and a number part, and is unique within the entire network. |
DESTINATION | The destination of the TSP tunnel being summarized as shown in the previous display output---the IP address of the tunnel tail. |
STATUS | The configuration status of the tunnel. At the head, this is an indication whether or not the tunnel has been completely configured. It also refers to the status of the associated software and hardware interfaces. |
CONNECTION | The connection status of the tunnel. This is an indication whether or not the local signalling/configuration information shows that the tunnel is up. Typically the tunnel becomes "up" at the tail hop first, and then at the second to the last hop, and so forth until signalling brings it up at the first hop. |
tag-switching tsp-tunnels
tunnel mode tag-switching
To control the distribution of locally assigned (incoming) tags via the Tag Distribution Protocol (TDP), use the tag-switching advertise-tags command. To disable tag advertisement, use the no form of this command.
tag-switching advertise-tags [for access-list-number [to access-list-number]for access-list-number | Specifies which destinations should have their tags advertised. |
to access-list-number | Specifies which TSR neighbors should receive tag advertisements. A TSR is identified by the router ID that is the first 4 bytes of its 6-byte TDP identifier. |
Advertise all to all is the default.
Global configuration
To enable the distribution of all locally assigned tags to all TDP neighbors, use the tag-switching advertise-tags command
You can enter multiple tag-switching advertise-tags commands. Taken together, they determine how local tags are advertised.
In the following example, the router is configured to advertise all locally assigned tags to all TDP neighbors. This is the default.
Router(config)# tag-switching advertise-tags
In the following example, the router is configured to advertise to all TDP neighbors tags for networks 10.101.0.0 and 10.221.0.0 only.
Router(config)# access-list 1 permit 10.101.0.0 0.0.255.255 Router(config)# access-list 4 permit 10.221.0.0 0.0.255.255
Router(config)# tag-switching advertise-tags for 1
Router(config)# tag-switching advertise-tags for 4
In the following example, the router is configured to advertise all tags to all TDP neighbors except neighbor 10.101.0.8.
Router(config)# access-list 1 permit any
Router(config)# access-list 2 deny 10.101.0.8
Router(config)# tag-switching advertise-tags
Router(config)# tag-switching advertise-tags for 1 to 2
To control the mode used for handling tag binding requests on TC-ATM interfaces, use the tag-switching atm allocation-mode global configuration command. Use the no form of this command to disable this feature.
tag-switching atm allocation-mode {optimistic | conservative}optimistic | Tag binding is returned immediately and packets are discarded until the downstream setup is complete. |
conservative | Tag binding is delayed until the tag VC has been set up downstream. |
The default is conservative.
Global configuration
In the following example, the mode for handling binding requests is set to optimistic on a TC-ATM interface:
tag-switching atm allocation-mode optimistic
To configure the VPI and VCI to be used for the initial link to the Tag Switching peer device, use the tag-switching atm control-vc subinterface configuration command. The initial link is used to establish the TDP session and to carry non-IP traffic. To clear the interface configuration, use the no form of this command.
tag-switching atm control-vc vpi vcivpi | Virtual path identifier. |
vci | Virtual channel identifier. |
If the subinterface has not changed to a VP tunnel, the default is 0/32. If the subinterface corresponds to VP tunnel VPI X, the default is X/32.
Interface configuration
For a router interface (for example, an AIP) ATM Tag Switching can be enabled only on a tag-switch subinterface.
On the Cisco LightStream 1010 ATM switch, a subinterface corresponds to a VP tunnel, so the VPI field of the control-vc must match the VPI field of the VP tunnel.
The following example shows you how to create a Tag Switching subinterface on a router and how to select VPI 1 and VCI 34 as the control VC.
interface atm4/0.1 tag-switchingtag-switching iptag-switching atm control-vc 1 34
show tag-switching interfaces
show tag-switching atm-tdp capability
To limit the maximum hop counts to a value you have specified, use the tag-switching atm maxhops command. Use the no form of this command to disable this feature.
tag-switching atm maxhopsThis command has no keywords or arguments.
The default is 254.
Configuration
When an ATM TSR receives a BIND REQUEST, it does not send a BIND back if the value in the request is equal to the maxhops value. Instead, the ATM TSR or TSR returns an error that specifies that the hop count has been reached.
When an ATM-TSR initiates a request for a tag binding, it includes a parameter specifying the maximum number of hops that the request should travel before reaching the edge of the ATM Tag Switching region. This is used to prevent forwarding loops in setting up tag paths across the ATM region.
The following example shows how to set the hop limit to 2.
(config)# tag-switching atm maxhops 2
show tag-switching atm-tdp bindings
To control whether vc-merge (multipoint-to-point) is supported for unicast tag VCs, use the tag-switching atm vc-merge command. Use the no form of this command to disable this feature.
tag-switching atm vc-mergeThis command has no keywords or arguments.
The default is enabled if the hardware supports the ATM-VC merge capability.
Global configuration
Since the default mode is to enable VC merge, you need not issue the tag-switching atm vc-merge command. However to disable VC merge, you must enter the no form of the command:
no tag-switching atm vc-merge
show tag-switching atm-tdp capability
To configure the range of values to use in the VPI field for tag VCs, use the tag-switching atm vpi command. To clear the interface configuration, use the no form of this command.
tag-switching atm vpi vpi [- vpi]vpi | Virtual path identifier (low end of range). |
-vpi | (Optional.) Virtual path identifier (high end of range). |
The default is 1-1.
Interface configuration
To configure ATM Tag Switching on a router interface (for example, an ATM Interface Processor), you must enable a Tag Switching subinterface.
Use this command to select an alternate range of VPI values for ATM tag assignment on this interface. The two ends of the link negotiate a range defined by the intersection of the range configured at each end.
The following example shows you how to create a subinterface and how to select a VPI range from VPI 1 to VPI 3:
interface atm4/0.1 tag-switching tag-switching ip tag-switching atm vpi 1-3
tag-switching atm control-vc
To allow Tag Switching of IPv4 packets, use the tag-switching ip command. To disable IP Tag Switching across all interfaces, use the no form of this command.
tag-switching ipThis command has no arguments or keywords.
Tag Switching of IPv4 packets is allowed.
Global configuration
Dynamic Tag Switching (that is, distribution of tags based on routing protocols) is allowed by this optional command, but it is not actually enabled until the interface-level tag-switching ip command is issued on at least one interface. The no form of this command stops the distribution of dynamic tags, and the sending of outgoing tagged packets on all interfaces. The command does not affect the sending of tagged packets through TSP tunnels.
For a TC-ATM interface, the no form of this command prevents the establishment of tag VCs beginning at, terminating at, or passing through the platform.
Since the default mode is to allow Tag Switching of IPv4 packets if enabled on an interface, this command is only needed to disable the feature globally.
The following example shows how to prevent the distribution of dynamic tags on all interfaces:
configure terminal no tag-switching ip
tag-switching ip (interface)
To enable Tag Switching of IPv4 packets on an interface, use the tag-switching ip interface configuration command. To disable IP Tag Switching on this interface, use the no form of this command.
tag-switching ipThis command has no arguments or keywords.
Tag Switching of IPv4 packets is disabled on this interface.
Interface configuration
The first time this command is issued on any interface, dynamic Tag Switching is enabled on the router as a whole. TDP hello messages are issued on this interface. When an outgoing tag for a destination routed out through this interface is received, packets sent to that destination are assigned with that tag.
The no form of this command causes packets routed out through this interface to be sent untagged, and outgoing TDP hello messages are no longer sent.
When the no form is issued on the only interface of a router for which Tag Switching was enabled, dynamic Tag Switching is disabled on the router as a whole.
For a TC-ATM interface, the no form of this command prevents the establishment of tag VCs beginning at, terminating at, or passing through the platform.
In the following example, Tag Switching is enabled on the specified Ethernet interface.
configure terminal interface e0/2 tag-switching ip
tag-switching advertise-tags
show tag-switching interfaces
To enable the distribution of tags associated with the IP default route, use the tag-switching ip default-route command.
tag-switching ip default-routeThis command has no arguments or keywords.
No distribution of IP default routes.
Global configuration
Dynamic Tag Switching (that is, distribution of tags based on routing protocols) must be enabled before you can use the tag-switching ip default-route command.
The following commands enable the distribution of tags associated with the IP default route:
configure terminal tag-switching ip tag-switching ip default-route
tag-switching ip (configuration)
tag-switching ip (interface)
To override the per-interface maximum transmission unit (MTU), use the tag-switching mtu interface configuration command. To restore the default, use the no form of this command.
tag-switching mtu bytesbytes | MTU in bytes. |
Minimum is 128 bytes; maximum depends on interface medium type.
Interface configuration
If a tagged IP packet exceeds the MTU set for the interface, the Cisco IOS software will fragment it. All devices on a physical medium must have the same protocol MTU in order to operate.
The following example sets the maximum tagged packet size for the first serial interface to 300 bytes:
interface serial 0 tag-switching mtu 300
To configure the size of the tag space for downstream unicast tag allocation, use the tag-switching tag-range downstream command. Use the no form of this command to revert to the platform defaults.
tag-switching tag-range downstream min max reservedmin | The smallest tag allowed in the tag space. The default is 10. |
max | The largest tag allowed in the tag space. The default is 10000. |
reserved | The number of tags reserved for diagnostic purposes. These tags come out of the low end of the tag space. Default is 16. |
The default values for the parameters just listed are as follows:
Global configuration
The following example shows how to configure the size of the tag space for downstream unicast tag allocation. In the example, min is set with the value of 10, max is set with the value of 12000, and reserved is set with the value of 16.
tagsw-r9# configure terminal
Enter configuration commands, one per line. End with Ctrl/Z.
Router(config)# tag-switching tag-range downstream 10 12000 16 Router(config)#
show tag-switching tdp parameters
To configure the interval between transmission of TDP discovery hello messages, or the hold time for a TDP transport connection, use the tag-switching tdp discovery global configuration command.
tag-switching tdp discovery {hello | directed hello} {holdtime | interval} secondshello | Configures the intervals and hold times for directly connected neighbors. |
directed-hello | Configures the intervals and hold times for neighbors that are not directly connected. (for example, TDP sessions that run through a TSP tunnel). |
holdtime | The interval for which a connection stays up if no hello messages are received. The default is 15 seconds. |
interval | The period between the sending of consecutive hello messages. The default is 5 seconds. |
seconds | The hold time or interval. |
The default values for holdtime and interval are
Global configuration
In the following example, the interval for which a connection stays up if no hello messages are received is set to 5 seconds:
tag-switching tdp discovery hello holdtime 5
show tag-switching tdp parameters
tag-switching tdp holdtime
To enable TSP tunnel functionality on a device, use the tag-switching tdp holdtime command.
tag-switching tdp holdtime secondsseconds | The time for which a TDP session is maintained in the absence of TDP messages from the session peer device. |
The default value for the seconds parameter is 15.
Global configuration
When a TDP session is initiated, the hold time is set to the lower of the values configured at the two ends.
In the following example, the hold time of TDP sessions is configured for 30 seconds:
tag-switching tdp holdtime 30
show tag-switching tdp parameters
tag-switching tdp discovery
To allow the operation of Tag-Switched Path (TSP) tunnels, use the tag-switching tsp-tunnels global configuration command. To disable the operation of TSP tunnels, use the no form of this command.
tag-switching tsp-tunnelsThis command has no arguments or keywords.
Off
Global configuration
TSP tunnel operation is allowed on the device by this optional command, but proper operation also requires that the interface-level tag-switching tsp-tunnels command be issued on the interfaces that are used by TSP tunnels. The no form of this command completely disables TSP tunnel operation on the device.
The following example shows how to allow TSP tunnel operation on a device:
configure terminal ip cef distributed
tag-switching tsp-tunnels
ip cef distributed
show tag-switching tsp-tunnels
To allow TSP tunnel operation over an interface, use the tag-switching tsp-tunnels interface configuration command. To disable TSP tunnel operation over an interface, use the no form of this command.
tag-switching tsp-tunnelsThis command has no arguments or keywords.
Off
Interface configuration
TSP tunnel operation over a specific interface is allowed by this optional command. In order for TSP tunnels to operate over an interface, the tag-switching tsp-tunnels global configuration command must also be enabled. The no form of this command disables TSP tunnel operation over the specified interface.
The following example shows how to allow TSP tunnel operation over an interface:
configure terminal
ip cef distributed
tag-switching tsp-tunnels
ip cef distributed
show tag-switching tsp-tunnels
This command has no arguments or keywords.
Interface configuration
A tunnel interface number must be less than or equal to 65535.
The tunnel mode tag-switching command fails if the interface number is invalid for a TSP tunnel identifier.
In the following example, the tunnel mode is set to Tag Switching:
interface tunnel 5
tunnel mode tag-switching
interface tunnel
tunnel tsp-hop
hop-number | The sequence number of the hop being defined in the path. The first number is 1, which identifies the hop just after the head hop. |
A.B.C.D | The IP address of the input interface on that hop. |
lasthop | (Optional.) Indicates that the hop being defined is the final hop in the path (the tunnel destination). |
Off
Interface configuration
The list of tunnel hops must specify a strict source route for the tunnel. In other words, the router at hop <N> must be directly connected to the router at hop <N>+1.
The following example shows the configuration of a two-hop tunnel. The first hop router/switch is 82.0.0.2, and the second and last hop is router/switch 81.0.0.2.
interface tunnel 5
tunnel mode tag-switching
ip unnumbered e0/1
tunnel tsp-hop 1 82.0.0.2
tunnel tsp-hop 2 81.0.0.2 lasthop
interface tunnel
tunnel mode tag-switching
This section contains an alphabetical listing of the Tag Switching debug commands and their descriptions. Documentation for each command includes a brief description of its use, command syntax, usage guidelines, sample output, and a description of that output.
Use the debug tag-switching adjacency EXEC command to display changes to Tag Switching entries in the adjacency database. The no form of this command disables debugging output.
[no] debug tag-switching adjacencyYou can use the debug tag-switching adjacency command to monitor those instances when entries are updated or added to the adjacency.
The following is an example of the display you see when you enter debug tag-switching adjacency:
Router# debug tag-switching adjacency TAG ADJ: add 10.10.0.1, Ethernet0/0/0 TAG ADJ: update 10.10.0.1, Ethernet0/0/0
Table 12 lists the significant fields shown in this display.
| Field | Description |
|---|---|
add | Adding an entry to the database. |
update | Updating the MAC address for an existing entry. |
10.10.0.1 | Address of neighbor TSR. |
Ethernet0/0/0 | Connecting interface. |
show adjacency
You can use the debug tag-switching atm-tdp api command with the debug tag-switching atm-tdp states command to display more complete information about a TVC.
The following is an example of the display you see when you enter debug tag-switching atm-tdp api:
Router# debug tag-switching atm-tdp api
Tailend Router Free tag Req 167.50.0.0 on ATM0/0.2 VPI/VCI 1/674
TAGATM_API: received tag free request
interface: ATM0/0.2 dir: in vpi: 1 vci: 674
TAGATM_API: completed tag free
interface: ATM0/0.2 vpi: 1 vci: 674
result: TAGATM_OK
Table 13 lists the significant fields in this display.
| Field | Description |
|---|---|
TAGATM_API | The subsystem that prints the message. |
interface | The interface used by the driver to allocate or free VPI/VCI resources. |
dir | The direction of the VC: · In---Input or receive VC · Out---Output VC |
vpi | Virtual path identifier. |
vci | Virtual channel identifier. |
result | The return error code from the driver API. |
debug tag-switching atm-tdp states
Use the debug tag-switching atm-tdp routes EXEC command to display information about the state of the routes for which VCI requests are being made. The no form of this command disables debugging output.
[no] debug tag-switching atm-tdp routesWhen there are many routes and system activities (that is, shutting down interfaces, learning of new routes, and so forth), the debug tag-switching atm-tdp routes command displays a lot of information that may interfere with system timing. Most commonly, this affects the normal operation of Tag Distribution Protocol (TDP). You should increase the TDP hold time value by using the tag-switching tdp holdtime command.
Here is an example of the display you see when you enter debug tag-switching atm-tdp routes:
Router# debug tag-switching atm-tdp routes CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0 tcatmFindRouteTags,153.7.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0 AddNewRoute,153.7.0.0/16,idb=ATM0/0.2 CleanupRoutes,153.7.0.0/16 CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0 tcatmFindRouteTags,153.8.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0 AddNewRoute,153.8.0.0/16,idb=ATM0/0.2 CleanupRoutes,153.8.0.0/16 CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0 tcatmFindRouteTags,153.9.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0 AddNewRoute,153.9.0.0/16,idb=ATM0/0.2 CleanupRoutes,153.9.0.0/16 CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0 tcatmFindRouteTags,153.10.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0 AddNewRoute,153.10.0.0/16,idb=ATM0/0.2 CleanupRoutes,153.10.0.0/16 CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0 tcatmFindRouteTags,153.11.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0 AddNewRoute,153.11.0.0/16,idb=ATM0/0.2 CleanupRoutes,153.11.0.0/16
Table 14 lists the significant fields in this display.
| Field | Description |
CleanupRoutes | Cleans up the routing table after a route has been deleted. |
not deleting route of idb ATM0/0.2 | The route cleanup event has not removed the specified route. |
rdbIndex | Index identifying the route. |
tcatmFindRouteTags | Request a VC for the route. |
idb | The internal descriptor for an interface. |
nh | Next hop for the route. |
index | Identifier for the route. |
AddNewRoute | Action of adding routes for a prefix or address. |
debug tag-switching atm-tdp holdtime
Use the debug tag-switching atm-tdp states EXEC command to display information about TVC state transitions as they occur. The no form of this command disables debugging output.
[no] debug tag-switching atm-tdp statesWhen there are many routes and system activities (that is, shutting down interfaces, learning of new routes, and so forth), the debug tag-switching atm-tdp states command outputs a lot of information that may interfere with system timing. Most commonly, this affects the normal operation of Tag Distribution Protocol (TDP). You should increase the TDP hold time value by using the tag-switching tdp holdtime command.
Here is an example of the display you see when you enter debug tag-switching atm-tdp states:
Router# debug tag-switching atm-tdp states Transit Output 166.35.0.0 VPI/VCI 1/67 Active -> XmitRelease NoPath Transit Input 166.35.0.0 VPI/VCI 1/466 Active -> ApiWaitParentLoss ParentLoss Transit Input 166.35.0.0 VPI/VCI 1/466 ApiWaitParentLoss -> ParentWait ApiSuccess Transit Input 166.35.0.0 VPI/VCI 1/466 ParentWait -> XmitWithdraw NoPath Transit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> XmitWithdraw Transmit Transit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> NonExistent Release Transit Input 166.35.0.0 VPI/VCI 1/466 NonExistent -> NonExistent ApiSuccess
Table 15 lists the significant fields in this display.
| Field | Description |
|---|---|
Transit Output | Output side of a TVC. |
VPI/VCI | VC value. |
Transit Input | Input side of a TVC. |
debug tag-switching atm-tdp holdtime
Use the debug tag-switching packets EXEC command to display tagged packets switched by this router. The no form of this command disables debugging output.
[no] debug tag-switching packets [interface]
Syntax
interface | (Optional.) Interface or subinterface name. |
The optional interface parameter restricts the display to only those packets received or transmitted on the indicated interface.
The following is an example of the display you see when you enter debug tag-switching packets:
Router# debug tag-switching packets TAG: Hs3/0: recvd: CoS=0, TTL=254, Tag(s)=27 TAG: Hs0/0: xmit: (no tag) TAG: Hs0/0: recvd: CoS=0, TTL=254, Tag(s)=30 TAG: Hs3/0: xmit: CoS=0, TTL=253, Tag(s)=27
Table 16 lists the significant fields in this display.
| Field | Description |
|---|---|
Hs0/0 | The identifier for the interface on which the packet was received or transmitted. |
recvd | Packet received. |
xmit | Packet transmitted. |
CoS | Class of Service field from the packet tag header. |
TTL | Time To Live field from the packet tag header. |
(no tag) | Last tag popped off the packet and transmitted untagged. |
Tag(s) | A list of tags on the packet, ordered from top of stack to bottom. |
Use the debug tag-switching tdp advertisements EXEC command to print information about the advertisement of tags and interface addresses to TDP peer devices. The no form of this command disables debugging output.
[no] debug tag-switching tdp advertisementsThe following is an example of the display you see when you enter debug tag-switching tdp advertisements:
Router# debug tag-switching tdp advertisements tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 99.101.0.8 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 172.27.32.28 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.105.0.8 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.92.0.8 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.205.0.8 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 210.8.0.8 tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.105.0.0/16, tag 1 (#2) tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.102.0.0/16, tag 26 (#4) tagcon: adj 210.9.0.9:0 (pp 0x60D8E98C): advertise 10.227.0.0/16, tag 27 (#6)
Table 17 lists the significant fields in this display.
| Field | Description |
|---|---|
tagcon: | Identifies the source of the message as the tag control subsystem. |
adj a.b.c.d:e | The TDP identifier of the peer device to which the advertisement has been made. |
(pp 0xnnnnnnnn) | The identifier for the data structure used to represent the peer device at the tag distribution level. Useful for correlating debug output. |
advertise X | What was advertised to the peer device---either an interface address ("a.b.c.d") or tag binding ("a.b.c.d/m, tag t (#n)"). |
(#n) | For a tag binding advertisement, the sequence number of the Tag Information Base (TIB) modification that made it necessary to advertise the tag. |
show tag-switching tdp neighbors
Use the debug tag-switching tdp bindings EXEC command to print information about changes to the tag information base (TIB) used to keep track of tag bindings learned from TDP peer devices through TDP downstream tag distribution. The no form of this command disables debugging output.
[no] debug tag-switching tdp bindingsThe following is an example of the display you see when you enter debug tag-switching tdp bindings:
Router# debug tag-switching tdp bindings tagcon: tibent(10.105.0.0/16): created; find route tags request tagcon: tibent(10.105.0.0/16): lcl tag 1 (#2) assigned tagcon: tibent(10.102.0.0/16): created; find route tags request tagcon: tibent(10.102.0.0/16): lcl tag 26 (#4) assigned tagcon: 210.9.0.9:0: 99.101.0.9 added to addr<->tdp ident map tagcon: 210.9.0.9:0: 172.27.32.29 added to addr<->tdp ident map tagcon: 210.9.0.9:0: 10.105.0.9 added to addr<->tdp ident map tagcon: tibent(172.27.32.0/22): rem tag 1 from 210.9.0.9:0 added tagcon: tibent(200.26.0.0/16): rem tag 30 from 210.9.0.9:0 added tagcon: tibent(210.8.0.8/32): created; remote tag learned tagcon: tibent(210.8.0.8/32): rem tag 31 from 210.9.0.9:0 added
Table 18 lists the significant fields in this display.
| Field | Description |
|---|---|
tagcon: | Identifies the source of the message as the tag control subsystem. |
tibent(network/mask) | The destination that has a tag binding change. |
created; reason | A TIB entry has been created for the specified destination for the indicated reason. |
rem tag ... | Describes a change to the tag bindings for the specified destination. The change is for a tag binding learned from the specified TDP peer device. |
lcl tag ... | Describes a change to a locally assigned (incoming) tag for the specified destination. |
(#n) | The sequence number of the modification to the TIB corresponding to the local tag change. |
a.b.c.d:n: e.f.g.h added to addr<->tdp ident map | The address e.f.g.h has been added to the set of addresses associated with TDP identifier a.b.c.d:n. |
show tag-switching tdp bindings
Use the debug tag-switching tdp directed-neighbors EXEC command to print information about the directed neighbor mechanism. This mechanism establishes TDP adjacencies to peer devices that are not directly adjacent, such as peer devices at either end of a tunnel. The no form of this command disables debugging output.
[no] debug tag-switching tdp directed-neighborsThe directed neighbor mechanism starts TDP discovery between two TSRs that are not necessarily directly adjacent. This mechanism is used, for instance, to support two-level tagging across a TSP tunnel, and to support traffic engineering metric exchange across a TSP tunnel.
The mechanism is based on an IP address, such as the IP address of the last hop of a TSP tunnel. A TSR wanting to establish a TDP adjacency to some other TSR with a given IP address is the active TSR for that directed neighbor discovery. A TSR willing to respond to that discovery is the passive TSR for that discovery.
As with TDP discovery between adjacent TSRs, it is possible to have multiple directed neighbor discovery sessions running between two TSRs, all supporting a single TDP adjacency.
The debug messages track discovery changes, such as discovery or loss of a directed neighbor. As a detail reflected in the debug prints, discovery of a directed neighbor with IP address X is complete when a TDP adjacency comes up and the far end announces that IP address X is one of its IP addresses.
The following is an example of the display you see when you enter debug tag-switching tdp directed-neighbors:
Router# debug tag-switching tdp directed-neighbors tdp_directednbr: TDPDirAdj 10.11.10.11 received address addition notification tdp_directednbr: TDPDirAdj 10.11.10.11 TDP peer set tdp_directednbr: TDPDirAdj 10.11.10.11 received address deletion notification tdp_directednbr: TDPDirAdj 10.11.10.11 peer cleared
Table 19 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp_directednbr: | Identifies this as a TDP directed neighbor debug statement. |
TDPDirAdj addr: | Identifies the IP address to which a TDP adjacency is desired. |
show tag-switching tdp neighbors
Use the debug tag-switching tdp peer state-machine EXEC command to print information about state transitions at the tag distribution level. The no form of this command disables debugging output.
[no] debug tag-switching tdp peer state-machineTDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
The following is an example of the display you see when you enter debug tag-switching tdp peer state-machine:
Router# debug tag tdp peer state-machine
tagcon: start TDP TCP timers for 202.0.0.1:1 (pp 0x60D8ABC8)
tagcon: adj 202.0.0.1:1-1 (pp 0x60D8ABC8): Event unsol open
unsol op pdg -> estab
tagcon: start TDP TCP timers for 210.9.0.9:0 (pp 0x60D93608)
tagcon: adj 210.9.0.9:0 (pp 0x60D93608): Event unsol open
unsol op pdg -> estab
tagcon: adj 210.9.0.9:0 (pp 0x60D93608): Event down
estab -> dstroy
tagcon: adj 202.0.0.1:1 (pp 0x60D8ABC8): Event down
estab -> dstroy
tagcon: start TDP TCP timers for 202.0.0.1:1 (pp 0x60DAC678)
tagcon: adj 202.0.0.1:1-1 (pp 0x60DAC678): Event unsol open
unsol op pdg -> defrd
tagcon: start TDP TCP timers for 210.9.0.9:0 (pp 0x60D895C4)
tagcon: adj 210.9.0.9:0 (pp 0x60D895C4): Event unsol open
unsol op pdg -> defrd
tagcon: adj 210.9.0.9:0 (pp 0x60D93608): Event cleanup done
dstroy -> non-ex
tagcon: adj 210.9.0.9:0 (pp 0x60D895C4): Event undefer
defrd -> estab
tagcon: adj 202.0.0.1:1 (pp 0x60D8ABC8): Event cleanup done
dstroy -> non-ex
tagcon: adj 202.0.0.1:1-1 (pp 0x60DAC678): Event undefer
defrd -> estab
Table 20 lists the significant fields in this display.
| Field | Description |
|---|---|
tagcon: | Identifies the source of the message as the tag control subsystem. |
adj a.b.c.d:e | The TDP identifier of the peer device for the session with the state change. |
(pp 0xnnnnnnnn) | Address of the data structure used to represent the peer device at the tag distribution level. It is useful for correlating debug output. |
Event E | The event causing the state change. |
S1 -> S2 | The state of the TDP session has changed from state S1 to state S2. |
Use the debug tag-switching tdp pies received EXEC command to print information about TDP protocol information elements (PIEs) received from TDP peer devices. The no form of this command disables debugging output.
[no] debug tag-switching tdp pies received [all]
Syntax Description
all | (Optional.) TDP received PIEs, including periodic keep alive PIEs. |
TDP requires periodic transmission of keep alive PIEs. If you do not specify the all option, periodic keep alive PIEs are not displayed.
The following is an example of the display you see when you enter debug tag-switching tdp pies received:
Router# debug tag tdp pies received all tdp: Rcvd open PIE from 202.0.0.1 (pp 0x0) tdp: Rcvd keep_alive PIE from 202.0.0.1:1 (pp 0x0) tdp: Rcvd request_bind PIE from 202.0.0.1:1 (pp 0x60DAC678) tdp: Rcvd request_bind PIE from 202.0.0.1:1 (pp 0x60DAC678) tdp: Rcvd open PIE from 210.9.0.9 (pp 0x0) tdp: Rcvd keep_alive PIE from 210.9.0.9:0 (pp 0x0) tdp: Rcvd bind PIE from 202.0.0.1:1 (pp 0x60DAC678) tdp: Rcvd bind PIE from 202.0.0.1:1 (pp 0x60DAC678)
Table 21 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
Rcvd xxx PIE | The type of PIE received. |
from a.b.c.d | The host that sent the PIE. Used in the early stages of the opening of a TDP session, when the TDP identifier is not yet known. |
from a.b.c.d:e | The TDP identifier of the peer device that sent the PIE. |
(pp 0xnnnnnnnn) | Identifies the data structure used to represent the peer device at the tag distribution level. Useful for correlating debug output. |
debug tag-switching tdp pies sent
Use the debug tag-switching tdp pies sent EXEC command to print information about state transitions at the tag distribution level. The no form of this command disables debugging output.
[no] debug tag-switching tdp pies sent [all]
Syntax
all | TDP sent PIEs, including periodic keep alive PIEs. |
TDP requires periodic transmission of keep alive PIEs. If you do not specify the all option, periodic keep alive PIEs are not displayed.
The following is an example of the display you see when you enter debug tag-switching tdp pies sent all:
Router# debug tag tdp pies sent all tdp: Queued open PIE to 210.222.0.222:1 (pp 0x0) tdp: Sent open PIE to 210.222.0.222:1 (pp 0x0) tdp: Queued keep_alive PIE to 210.222.0.222:1 (pp 0x0) tdp: Sent keep_alive PIE to 210.222.0.222:1 (pp 0x0) tdp: Queued request_bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Sent request_bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Queued request_bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Sent request_bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Queued open PIE to 210.8.0.8 (pp 0x0) tdp: Queued bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Sent bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Queued bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Sent bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Queued bind PIE to 210.222.0.222:1 (pp 0x60F264C8) tdp: Queued open PIE to 210.8.0.8 (pp 0x0) tdp: Sent open PIE to 210.8.0.8 (pp 0x0) tdp: Queued keep_alive PIE to 210.8.0.8:0 (pp 0x0) tdp: Sent keep_alive PIE to 210.8.0.8:0 (pp 0x0) tdp: Queued address PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent address PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Queued bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Queued bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Queued bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Queued bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Queued bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent bind PIE to 210.8.0.8:0 (pp 0x60F161AC) tdp: Sent bind PIE to 210.8.0.8:0 (pp 0x60F161AC)
Table 22 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
Queued xxx PIE | Indicates that a PIE of the specified type has been queued for transmission. |
Sent xxx PIE | Indicates that a PIE of the specified type has been sent on the TDP session TCP connection. |
to a.b.c.d | The host to which the PIE has been sent or for which it has been queued. Used in the early stages of opening a TDP session when the TDP identifier is not yet known. |
to a.b.c.d:e | The TDP identifier of the peer device to which the PIE has been sent or for which it has been queued. |
(pp 0xnnnnnnnn) | Identifies the data structure used to represent the peer device at the tag distribution level. Useful for correlating debug output. |
debug tag-switching tdp pies received
debug tag-switching tdp session i/0
Use the debug tag-switching tdp session io EXEC command to print the contents of TDP PIEs sent to and received from TDP peer devices. The no form of this command disables debugging output.
[no] debug tag-switching tdp session io [all]
Syntax
all | (Optional.) TDP session I/O activity, including I/O for periodic keep alives. |
TDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
TDP requires periodic transmission of keep alive PIEs. If you do not specify the all option, periodic keep alive PIEs are not displayed.
The following is an example of the display you see when you enter debug tag-switching tdp session io:
Router# debug tag-switching tdp session io all tdp: Rcvd open PIE from 210.9.0.9 (pp 0x0) tdp: TDP open PIE: PDU hdr: TDP Id: 210.9.0.9:0; PIE Contents: 0x00 0x01 0x00 0x10 0xD2 0x09 0x00 0x09 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x04 0x01 0x00 0x00 0x1E tdp: Sent open PIE to 210.9.0.9:0 (pp 0x0) tdp: TDP open PIE: PDU hdr: TDP Id: 172.27.32.28:0; PIE Contents: 0x00 0x01 0x00 0x10 0xAC 0x1B 0x20 0x1C 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x04 0x01 0x00 0x00 0x0F tdp: Sent keep_alive PIE to 210.9.0.9:0 (pp 0x0) tdp: TDP keep_alive PIE: PDU hdr: TDP Id: 172.27.32.28:0; PIE Contents: 0x00 0x01 0x00 0x0C 0xAC 0x1B 0x20 0x1C 0x00 0x00 0x00 0x00 0x05 0x00 0x00 0x00 tdp: Rcvd keep_alive PIE from 210.9.0.9:0 (pp 0x0) tdp: TDP keep_alive PIE: PDU hdr: TDP Id: 210.9.0.9:0; PIE Contents: 0x00 0x01 0x00 0x0C 0xD2 0x09 0x00 0x09 0x00 0x00 0x00 0x00 0x05 0x00 0x00 0x00 tdp: Rcvd address PIE from 210.9.0.9:0 (pp 0x60E109F0) tdp: TDP address PIE: PDU hdr: TDP Id: 210.9.0.9:0; PIE Contents: 0x00 0x01 0x00 0x35 0xD2 0x09 0x00 0x09 0x00 0x00 0x00 0x00 0x08 0x00 0x00 0x29 0x00 0x01 0x00 0x03 0x00 0x23 0x20 0x63 0x65 0x00 0x09 0x20 0xAC 0x1B 0x20 0x1D 0x20 0x0A 0x69 0x00 0x09 0x20 0x0A 0x5C 0x00 0x09 0x20 0x0A 0x6F 0x00 0x09 0x20 0x0A 0xCD 0x00 0x09 0x20 0xD2 0x09 0x00 0x09 tdp: Rcvd bind PIE from 210.9.0.9:0 (pp 0x60E109F0) tdp: TDP bind PIE: PDU hdr: TDP Id: 210.9.0.9:0; PIE Contents: 0x00 0x01 0x00 0xFC 0xD2 0x09 0x00 0x09 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0xF0 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x02 0x00 0xE6 0x00 0x00 0x00 0x00 0x01 0x10 0x0A 0x6F 0x00 0x00 0x00 0x00 0x01 0x16 0xAC 0x1B 0x20 0x00 0x00 0x00 0x00 0x01 0x10 0xD2 0x09 0x00 0x00 0x00 0x00 0x1A 0x20 0x0A 0x0B 0x00 0x0B 0x00 0x00 0x00
Table 23 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
Rcvd xxx PIE | Indicates that a PIE of the specified type has been received. |
from a.b.c.d | The host to which the PIE has been sent. Used in the early stages of the opening of a TDP session when the TDP identifier is not yet known. |
Sent xxx PIE | Indicates that a PIE of the specified type has been sent. |
to a.b.c.d | The host to which the PIE has been sent. Used in the early stages of opening a TDP session when the TDP identifier is not yet known. |
to a.b.c.d:e | The TDP identifier of the peer device to which the PIE has been sent. |
(pp 0xnnnnnnnn) | Identifies the data structure used to represent the peer device at the tag distribution level. Useful for correlating debug output. |
--TDP xxx PIE | The type of PIE that has been sent. |
PDU_hdr: TDP Id: a.b.c.d:e | The TDP identifier of the sender included in the TDP PDU header. |
PIE contents: 0xnn ... 0xnn | The contents of the PIE represented as a sequence of bytes. |
debug tag-switching tdp pies received
debug tag-switching tdp pies sent
Use the debug tag-switching tdp session state-machine EXEC command to print information about state transitions at the protocol level. The no form of this command disables debugging output.
[no] debug tag-switching tdp session state-machineTDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
The following is an example of the display you see when you enter debug tag-switching tdp session state-machine:
Router# debug tag-switching tdp session state-machine
tdp: adj:210.9.0.9(0x60DDBB4C): Event: Xport opened;
Non-existent -> Init pasv
tdp: tdp_create_ptcl_adj: tp = 0x60DDBB4C, ipaddr = 210.9.0.9
tdp: adj:210.9.0.9(0x60DDBB4C): Event: Xport opened;
Init pasv -> Init pasv
tdp: adj:10.105.0.9(0x60DDBB4C): Event: Rcv TDP Open;
Init pasv -> Open rcvd pasv
tdp: adj:10.105.0.9(0x60DDBB4C): Event: Rcv TDP KA;
Open rcvd pasv -> Oper
tdp: adj:unknown(0x60DDBB4C): Event: Xport closed;
Oper -> Non-existent
Table 24 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
adj:a.b.c.d | Identifies the network address of the TDP peer device. |
(0xnnnnnnnn) | Identifies the data structure used to represent the peer device at the protocol level. Useful for correlating debug output. |
Event: E | The event that caused the state transition. |
S1 -> S2 | The state of the TDP session has changed from state S1 to state S2. |
Use the debug tag-switching tdp transport connections EXEC command to print information about the TCP connections used to support TDP sessions. The no form of this command disables debugging output.
[no] debug tag-switching tdp transport connectionsTDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
When two devices establish a TCP connection for a TDP session, the device with the larger transport address plays an active role and the other plays a passive role. The active device attempts to establish a TCP connection to the well known TDP port at the passive device. The passive device waits for the connection to the well known port to be established.
The following is an example of the display you see when you enter debug tag-switching transport connections:
Router# debug tag-switching tdp transport connections
Debug output at active peer:
tdp: Opening conn; adj 0x60F7C604, 210.9.0.9 <-> 172.27.32.28
tdp: Conn is up; adj 0x60F7C604, 210.9.0.9:11018 <-> 172.27.32.28:711
tdp: Hold timer expired for adj 0x60F7C604, will close conn
tdp: Closing conn 210.9.0.9:11018 <-> 172.27.32.28:711, adj 0x60F7C604
Debug output at passive peer:
tdp: Incoming conn 172.27.32.28:711 <-> 210.9.0.9:11018
tdp: Conn closed by peer; adj 0x60EB5FD4
172.27.32.28:711 <-> 210.9.0.9:11018, Ethernet1/1/1
tdp: Closing conn 172.27.32.28:711 <-> 210.9.0.9:11018, adj 0x60EB5FD4
Table 25 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
adj 0xnnnnnnnn | Identifies the data structure used to represent the peer device at the transport level. Useful for correlating debug output. |
a.b.c.d -> p.q.r.s | Indicates a TCP connection between a.b.c.d and p.q.r.s. |
a.b.c.d:x -> p.q.r.s:y | Indicates a TCP connection between a.b.c.d, port x and p.q.r.s, port y. |
debug tag-switching tdp transport events
Use the debug tag-switching tdp transport events EXEC command to print information about the events related to the TDP peer discovery mechanism, which is used to determine the devices with which to establish TDP sessions. The no form of this command disables debugging output.
[no] debug tag-switching tdp transport eventsTDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
The following is an example of the display you see when you enter debug tag-switching tdp transport events:
Router# debug tag tdp transport events tdp: Rcvd hello; Ethernet1/1/1, from 10.105.0.9 (210.9.0.9:0), intf_id 0, opt 0x4 tdp: Hello from 10.105.0.9 (210.9.0.9:0) to 255.255.255.255, opt 0x4 tdp: New adj 0x60DF6E50 from 10.105.0.9 (210.9.0.9:0), Ethernet1/1/1 tdp: Rcvd hello; ATM3/0.1, from 200.26.0.4 (202.0.0.1:1), intf_id 1, opt 0x4, tcatm tdp: Rcvd hello; Ethernet1/1/1, from 10.105.0.9 (210.9.0.9:0), intf_id 0, opt 0x4 tdp: Hello from 10.105.0.9 (210.9.0.9:0) to 255.255.255.255, opt 0x4 tdp: Ignore Hello Timer for Ethernet1/1/1; intf not TDP ready tdp: Send hello; Ethernet1/1/1, src/dst 10.105.0.8/255.255.255.255, inst_id 0 tdp: Incoming conn 172.27.32.28:711 <-> 210.9.0.9:11019 tdp: Found adj 0x60DF6E50 for 210.9.0.9 (Hello xport addr opt) tdp: New temporary adj 0x61033D38 from 210.9.0.9 tdp: Real adj 0x60DF6E50 bound to 210.9.0.9:0, replacing temp adj 0x61033D38 tdp: Adj 0x61033D38; state set to closed tdp: Rcvd hello; Ethernet1/1/1, from 10.105.0.9 (210.9.0.9:0), intf_id 0, opt 0x4 tdp: Rcvd hello; ATM3/0.1, from 200.26.0.4 (202.0.0.1:1), intf_id 1, opt 0x4, tcatm tdp: Send hello; ATM3/0.1, src/dst 99.101.0.8/255.255.255.255, inst_id 1, tcatm tdp: Rcvd hello; Ethernet1/1/1, from 10.105.0.9 (210.9.0.9:0), intf_id 0, opt 0x4 tdp: Send hello; Ethernet1/1/1, src/dst 10.105.0.8/255.255.255.255, inst_id 0 tdp: Rcvd hello; ATM3/0.1, from 200.26.0.4 (202.0.0.1:1), intf_id 1, opt 0x4, tcatm
Table 26 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp: | Identifies the source of the message as TDP. |
adj 0xnnnnnnnn | Identifies data structure used to represent the peer device at the transport level. Useful for correlating debug output. |
a.b.c.d (p.q.r.s:n) | Network address and TDP identifier of the peer device. |
intf_id | Interface identifier (non-zero for TC-ATM interfaces, 0 otherwise). |
opt 0xn | Bits that describe options in the TDP discovery hello packet: · 0x1---Directed hello option · 0x2---Send directed hello option · 0x4---Transport address option |
debug tag-switching tdp transport connections
Use the debug tag-switching tdp transport timers EXEC command to print information about events that restart the "hold" timers that are part of the TDP discovery mechanism. The no form of this command disables debugging output.
[no] debug tag-switching tdp transport timersTDP sessions are supported by data structures and state machines at three levels:
The debug tag-switching tdp transport commands provide visibility of activity at the transport level, the debug tag-switching tdp session commands at the protocol level, and the debug tag-switching tdp peer commands at the tag distribution level.
The following is an example of the display you see when you enter debug tag-switching tdp transport timers:
Router# debug tag-switching tdp transport timers tdp: Start holding timer; adj 0x60D5BC10, 200.26.0.4 tdp: Start holding timer; adj 0x60EA9360, 10.105.0.9 tdp: Start holding timer; adj 0x60D5BC10, 200.26.0.4 tdp: Start holding timer; adj 0x60EA9360, 10.105.0.9 tdp: Start holding timer; adj 0x60D5BC10, 200.26.0.4 tdp: Start holding timer; adj 0x60EA9360, 10.105.0.9
Table 27 lists the significant fields in this display.
| Field | Description |
|---|---|
tdp | Identifies the source of the message as TDP. |
adj 0xnnnnnnnn | Identifies the data structure used to represent the peer device at the transport level. |
a.b.c.d | Network address of the peer device. |
debug tag-switching tdp transport events
Use the debug tag-switching tfib cef EXEC command to print detailed information about tag rewrites being created, resolved, and deactivated as CEF routes are added, changed, or removed. The no form of this command disables debugging.
[no] debug tag-switching tfib cefSeveral lines of output are produced for each route placed into the TFIB. If your router has thousands of tagged routes, be careful about issuing this command. When Tag Switching is first enabled, each of these routes is placed into the TFIB. If debug tag-switching tfib cef has been issued, several lines of output are displayed for each route.
The following is an example of the display you see when you enter debug tag-switching tfib cef
Router# debug tag-switching tfib cef
Cisco Express Forwarding related TFIB services debugging is on
tagcon: tc_ip_rtlookup fail on 10.0.0.0/8:subnet_lookup failed
TFIB: route tag chg 10.7.0.7/32,idx=1,inc=Withdrn,outg=Withdrn,enabled=0x2
TFIB: fib complete delete: prefix=10.7.0.7/32,inc tag=26,delete_info=1
TFIB: deactivate tag rew for 10.7.0.7/32,index=0
TFIB: set fib rew: pfx 10.7.0.7/32,index=0,add=0,tag_rew->adj=Ethernet2/3
TFIB: resolve tag rew,prefix=10.7.0.7/32,no tag_info,no parent
TFIB: fib scanner start:needed:1,unres:0,mac:0,loadinfo:0
TFIB: resolve tag rew,prefix=10.7.0.7/32,no tag_info,no parent
TFIB: fib upd loadinf 10.100.100.100/32,tag=Tun_hd,fib no loadin,tfib no loadin
TFIB: fib check cleanup for 10.100.100.100/32,index=0,return_value=0
TFIB: fib_scanner_end
TFIB: create dynamic entry for 10.11.0.11/32
TFIB: call find_route_tags,dist_method=1,next_hop=10.93.0.11,Et2/3
TFIB: route tag chg 10.11.0.11/32,idx=0,inc=26,outg=Unkn,enabled=0x3
TFIB: create tag info 10.11.0.11/32,inc tag=26,has no info
TFIB: resolve tag rew,prefix=10.11.0.11/32,has tag_info,no parent
TFIB: finish fib res 10.11.0.11/32:index 0,parent outg tag no parent
TFIB: fib upd loadinf 10.11.0.11/32,tag=26,fib no loadin,tfib no loadin
TFIB: set fib rew: pfx 10.11.0.11/32,index=0,add=1,tag_rew->adj=Ethernet2/3
tagcon: route_tag_change for: 10.250.0.97/32
intag 33, outtag 28, nexthop tsr 10.11.0.11:0
TFIB: route tag chg 10.250.0.97/32,idx=0,inc=33,outg=28,enabled=0x3
TFIB: deactivate tag rew for 10.250.0.97/32,index=0
TFIB: set fib rew: pfx 10.250.0.97/32,index=0,add=0,tag_rew->adj=Ethernet2/3
TFIB: create tag info 10.250.0.97/32,inc tag=33,has old info
On VIP:
TFIB: route tag chg 10.13.72.13/32,idx=0,inc=34,outg=Withdrn,enabled=0x3
TFIB: deactivate tag rew for 10.13.72.13/32,index=0
TFIB: set fib rew: pfx 10.13.72.13/32,index=0,add=0,tag_rew->adj=
TFIB: create tag info 10.13.72.13/32,inc tag=34,has old info
TFIB: resolve tag rew,prefix=10.13.72.13/32,has tag_info,no parent
TFIB: finish fib res 10.13.72.13/32:index 0,parent outg tag no parent
TFIB: set fib rew: pfx 10.100.100.100/32,index=0,add=0,tag_rew->adj=
TFIB: create tag info 10.100.100.100/32,inc tag=37,has old info
TFIB: resolve tag rew,prefix=10.100.100.100/32,has tag_info,no parent
TFIB: finish fib res 10.100.100.100/32:index 0,parent outg tag no parent
TFIB: fib upd loadinf 10.100.100.100/32,tag=37,fib no loadin,tfib no loadin
Table 28 lists the significant fields in this display. See Table 30 for a description of special tag names seen in the debug output.
| Field | Description |
|---|---|
TFIB | The name of the subsystem issuing the debug output |
tagcon | The name of subsystem issuing the debug output (Tag Control) |
tc_ip_rtlookup fail on x.y.w.z/m: subnet_lookup failed | The destination with IP address and mask shown is not in the Routing Table |
route tag chg x.y.w.z/m | Request to create TFIB entry for specified prefix/mask |
idx=-1 | The index within FIB entry of the path whose TFIB entry is being created. -1 means all paths for this FIB entry. |
inc=s | Incoming tag of entry being processed |
outg=s | Outgoing tag of entry being processed |
enabled=0xn | Bit mask indicating types of Tag Switching currently enabled (0x1 = dynamic, 0x2 = TSP tunnels, 0x3 = both) |
fib complete delete | Indicates FIB entry being deleted |
prefix=x.y.w.z/m | A destination prefix |
delete_info=1 | Indicates that tag_info is also being deleted |
deactivate tag rew for x.y.w.z/m | Indicates tag rewrite for specified prefix is being deleted |
index=n | Index of path in FIB entry being processed |
set fib rew: pfx x.y.w.z/m | Indicates tag rewrite is being installed or deleted from the FIB entry for the specified destination for tag imposition purposes |
add=0 | Indicates tag rewrite is being deleted from the FIB (no longer imposing tag) |
tag_rew->adj=s | Adjacency of tag_rewrite for tag imposition |
resolve tag rew,prefix=x.y.w.z/m | Indicates the FIB route to the specified prefix is being resolved |
no tag_info | Indicates there is no tag_info for the destination (destination not tagged) |
no parent | Indicates route is not recursive |
fib scanner start | Indicates the periodic scan of the FIB has started |
needed:1 | Indicates TFIB needs the FIB to be scanned |
unres:n | The number of unresolved TFIB entries |
mac:n | The number of TFIB entries missing MAC strings |
loadinfo:n | Indicates whether non-recursive accounting state has changed and thus the loadinfo information in the TFIB needs to be adjusted |
fib upd loadinf x.y.w.z/m | Indicates that a check for non-recursive accounting is being made and TFIB loadinfo information for specified prefix is being updated |
tag=s | Incoming tag of entry |
fib no loadin | Indicates corresponding FIB entry has no loadinfo |
tfib no loadin | Indicates TFIB entry has no loadinfo |
fib check cleanup for x.y.w.z/m | Indicates a check is being made on the TFIB entry for specified destination to see if rewrite needs to be removed from TFIB |
return_value=x | If 0, no change in TFIB entry. If 1, there was a change. |
fib_scanner_end | FIB scan has come to an end |
create dynamic entry for x.y.w.z/m | The TFIB has been enabled and a TFIB entry is being created for the specified destination |
call find_route_tags | The tags for that destination are being requested |
dist_method=n | The tag distribution method -- TDP, TC-ATM, and so on. |
next_hop=x.y.z.w | Next hop for the destination |
interface name | Outgoing interface for the destination |
create tag info | A tag_info data structure is being created for the destination |
has no info | The destination does not already have a tag_info |
finish fib res x.y.z.w/m | The TFIB entry for the specified route is being completed |
parent outg tag s | If recursive, specifies the outgoing tag of the route through which it recurses (the parent). If not recursive, s = "no parent" |
tagcon: route_tag_change for: x.y.z.w/m | Tag Control is notifying TFIB that tags are available for specified destination |
intag s | Incoming tag for the destination |
outtag s | Outgoing tag for the destination |
nexthop tsr x.y.z.w.i | TDP ID of next hop which sent the tag |
debug tag-switching tfib enc
Use the debug tag-switching tfib enc EXEC command to print detailed information about tag encapsulations while tag rewrites are created or updated and placed into the Tag Forwarding Information Base (TFIB). This output shows you which adjacency the tag rewrite is being created on and the tags. The no form of this command disables debugging output.
[no] debug tag-switching tfib encSeveral lines of output are produced for each route placed into the TFIB. If your router has thousands of tagged routes, be careful about issuing this command. When Tag Switching is first enabled, each of these routes is placed into the TFIB, and a tag encapsulation is created. When debug tag-switching tfib enc is issued, several lines of output are displayed for each route.
The following is an example of the display you see when you enter debug tag-switching tfib enc. This example shows the encapsulations for three routes that have been created and placed into the TFIB.
Router# debug tag-switching tfib enc TFIB: finish res:inc tag=28,outg=Imp_null,next_hop=10.93.72.13,Ethernet4/0/3 TFIB: update_mac, mac_length = 14,addr=10.93.72.13,idb=Ethernet4/0/3 TFIB: get ip adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=7 TFIB: get tag adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=79 TFIB: encaps:inc=28,outg=Imp_null,idb:Ethernet4/0/3,sizes 14,14,1504,type 0 TFIB: finish res:inc tag=30,outg=27,next_hop=10.93.72.13,Ethernet4/0/3 TFIB: get ip adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=7 TFIB: get tag adj: addr=10.93.72.13,is_p2p=0,fibidb=Ethernet4/0/3,linktype=79 TFIB: encaps:inc=30,outg=27,idb:Ethernet4/0/3,sizes 14,18,1500,type 0 TFIB: finish res:inc tag=30,outg=10,next_hop=0.0.0.0,ATM0/0.1 TFIB: get ip adj: addr=0.0.0.0,is_p2p=1,fibidb=ATM0/0.1,linktype=7 TFIB: get tag adj: addr=0.0.0.0,is_p2p=1,fibidb=ATM0/0.1,linktype=79 TFIB: encaps:inc=30,outg=10,idb:ATM0/0,sizes 4,8,4470,type 1
Table 29 lists the significant fields in this display.
| Field | Description |
|---|---|
TFIB | Identifies the source of the message as the TFIB subsystem. |
finish res | Shows that the TFIB resolution is being finished. |
inctag=x or inc=x | An incoming (local) tag for the TFIB entry is being created. Tags can be numbers or special values. |
outg=y | An outgoing (remote) tag for the TFIB entry is being created. |
next_hop=a.b.c.d | IP address of next hop for the destination. |
interface | The outgoing interface through which a packet will be sent. |
get ip adj | Shows that the IP adjacency to use in the TFIB entry is being determined. |
get tag adj | Shows that the tag-switching adjacency to use for the TFIB entry is being determined. |
addr = a.b.c.d | The IP address of the adjacency. |
is_p2p=x | If 1, this is a point-to-point adjacency. If 0, it is not. |
fibidb = s | The interface of the adjacency. |
linktype = x | The link type of the adjacency (7 = LINK_IP or 79 = LINK_TAG). |
sizes x,y,z | x = length of macstring, y = length of tag encapsulation, z = tag MTU. |
type = x | Tag encapsulation type. 0= normal, |
idb:s | Outgoing interface. |
update_mac | Shows that the macstring of the adjacency is being updated. |
Table 30 lists special tags, which sometimes appear in the debug output, and their meanings.
| Special Tag | Meaning |
|---|---|
Unassn---Inital value | No tag assigned yet. |
Unused | This destination does not have a tag (for example, a BGP route). |
Withdrn | The tag for this destination has been withdrawn. |
Unkn | This destination should have a tag, but it is not known yet. |
Get_res | A recursive route that will get a tag when resolved. |
Exp_null | Explicit null tag---used over TC-ATM. |
Imp_null | Implicit null tag---for directly connected routes. |
Tun_hd | For head of TSP tunnel. |
debug tag-switching tfib state
Use the debug tag-switching tfib state EXEC command to trace what is happening as tag-switching is enabled or disabled. The no form of this command disables debugging output.
[no] debug tag-switching tfib stateUse this command when you wish to trace what happens to the TFIB when you issue tag-switching ip or tag-switching tsp-tunnel commands.
The following is an example of the display you see when you enter debug tag-switching tfib state:
Router# debug tag-switching tfib state TFIB enable/disable state debugging is on TFIB: Upd tag sb 6(status:0xC1,tmtu:1500,VPI:1-1 VC=0/32,et:0/0/0),lc 0x0 TFIB: intf status chg: idb=Et4/0/2,status=0xC1,oldstatus=0xC3 TFIB: interface dyntag change,change in state to Ethernet4/0/2 TFIB: enable entered, table exists,enabler type=0x2 TFIB: enable, TFIB already enabled, types now 0x3,returning TFIB: enable entered, table exists,enabler type=0x1 TFIB: disable entered, table exists,type=0x1 TFIB: cleanup: tfib[32] still non-0 On linecard only: TFIB: disable lc msg recvd, type=0x1 TFIB: Ethernet4/0/1 fibidb subblock message received TFIB: enable lc msg recvd, type=0x1 TFIB: Tunnel301 set encapfix to 0x6016A97C
Table 31 lists the significant fields in this display.
| Field | Description |
|---|---|
TFIB | Identifies the source of the message as the TFIB subsystem. |
Upd tag sb x | Shows that the status of the xth Tag Switching subblock is being updated, where x is the interface number. There is a Tag Switching subblock for each interface on which Tag Switching has ever been enabled. |
(status:0xC1,tmtu:1500,VPI:1-1VC=0/32, | The values of the fields in the Tag Switching subblock: 1) the status byte, the MTU, the range of ATM VPs, control VP and control VC (if this is a TC-ATM interface), the encapsulation type, encapsulation information, and tunnel interface number, and the line card number to which the update message is being sent (0 means all line cards) |
intf status change | Shows that there was an interface status change. |
idb=Et4/0/2 | The interface whose status changed. |
status=0xC1 | The new status bits in the Tag Switching subblock of the idb. |
oldstatus=0xC3 | What the old status bits were before the change. |
Interface dyntag change, change in state to Ethernet4/0/2 | Shows that there was a change in dynamic tag status for the particular interface. |
enable entered | Shows that the code that enables the TFIB was invoked. |
TFIB already enabled | Shows that TFIB was already enabled when this call was made. |
table exists | Shows that a TFIB table had already been allocated in a previous call. |
cleanup: tfib[x] still non-0 | Indicates TFIB is in the process of being deleted, but that slot x is still around. |
disable lc mesg recvd, type=0x1 | Shows that a message to disable Tag Switching type 1 (dynamic) was received by the line card. |
disable entered, table exists,type=0x1 | Shows that a call to disable dynamic Tag Switching was issued. |
Ethernet4/0/1 fibidb subblock message received | Shows that a message giving fibidb status change was received on the lc. |
enable lc msg recvd,type=0x1 | Shows that a message to enable Tag Switching type 1 (dynamic) was received by the line card. |
Tunnel301 set encapfix to 0x6016A97C | Shows that fibidb Tunnel301 on the line card received an encapsulation fixup. |
types now 0x3, returning | Gives the value of the bitmask indicating the type of Tag Switching enabled. 0x1 means dynamic Tag Switching; 0x2 means tsp-tunnels; and 0x3 means both. |
debug tag-switching tfib enc
debug tag-switching tfib state
debug tag-switching tfib struct
Use the debug tag-switching tfib struct EXEC command to trace the allocation and freeing of TFIB-related data structures---the TFIB itself, tag-rewrites, and tag-info data. The no form of this command disables debugging output.
[no] debug tag-switching tfib structThe following is an example of the display you see when you enter debug tag-switching tfib struct.
Router# debug tag-switching tfib struct TFIB data structure changes debugging is on TFIB: delete tag rew, incoming tag 32 TFIB: remove from tfib,inc tag=32 TFIB: set loadinfo,tag=32,no old loadinfo,no new loadinfo TFIB: TFIB not in use. Checking for entries. TFIB: cleanup: tfib[0] still non-0 TFIB: remove from tfib,inc tag=Tun_hd TFIB: set loadinfo,tag=Exp_null,no old loadinfo,no new loadinfo TFIB: TFIB freed. TFIB: enable, TFIB allocated, size 4024 bytes, maxtag = 500 TFIB: create tag rewrite: inc Tun_hd,outg Unkn TFIB: add to tfib at Tun_hd, first in circular list, mac=0,enc=0 TFIB: delete tag rew, incoming tag Tun_hd TFIB: remove from tfib,inc tag=Tun_hd TFIB: set loadinfo,tag=Exp_null,no old loadinfo,no new loadinfo TFIB: create tag rewrite: inc Tun_hd,outg Unkn TFIB: add to tfib at Tun_hd, first in circular list, mac=0,enc=0 TFIB: create tag rewrite: inc 26,outg Unkn TFIB: add to tfib at 26, first in circular list, mac=0,enc=0 TFIB: add to tfib at 27, added to circular list, mac=0,enc=0 TFIB: delete tag rew, incoming tag Tun_hd TFIB: remove from tfib,inc tag=Tun_hd TFIB: set loadinfo,tag=Exp_null,no old loadinfo,no new loadinfo TFIB: add to tfib at 29, added to circular list, mac=4,enc=8 TFIB: delete tag rew, incoming tag 29 TFIB: remove from tfib,inc tag=29
Table 32 lists the significant fields in this display.
| Field | Description |
|---|---|
TFIB | The subsystem issuing the message. |
delete tag rew | A tag_rewrite is being freed. |
remove from tfib | A tag rewrite is being removed from the TFIB. |
inc tag-s | The incoming tag of the entry being processed. |
set loadinfo | The loadinfo field in the TFIB entry is being set (used for nonrecursive accounting). |
tag=s | The incoming tag of the entry being processed. |
no old loadinfo | The TFIB entry did not have a loadinfo before. |
no new loadinfo | The TFIB entry should not have a loadinfo now. |
TFIB not is use. Checking for entries | Tag Switching has been disabled, and the TFIB is being freed up. |
cleanup: tfib[x] still non-0 | The TFIB is being checked for any entries in use, and entry x is the lowest numbered slot still in use. |
TFIB freed | The TFIB table has been freed. |
enable, TFIB allocated, size x bytes, maxtag = y | Tag Switching has been enabled, and a TFIB of x bytes has been allocated. The largest legal tag is y. |
create tag rewrite | A tag_rewrite is being created. |
inc s | The incoming tag. |
outg s | The outgoing tag. |
add to tfib at s | A tag_rewrite has been placed in the TFIB at slot s. |
first in circular list | This TFIB slot had been empty, and this is the first rewrite in the list. |
mac=0,enc=0 | Length of the mac string and total encapsulation length, including tags. |
added to circular list | A tag_rewrite is being added to a TFIB slot which already had an entry. This rewrite is being inserted in the circular list. |
tag-switching tfib cef
tag-switching tfib enc
tag-switching tfib state
Use the debug tag-switching tfib tsp EXEC command to print detailed information about tag rewrites being created and deleted as TSP tunnels are added or removed. The no form of this command disables debugging output.
[no] debug tag-switching tfib tspThe following is an example of the display you see when you enter debug tag-switching tfib tsp:
Router# debug tag-switching tfib tsp TSP-tunnel related TFIB services debugging is on TFIB: tagtun,next hop=10.93.72.13,inc=35,outg=1,idb=Et4/0/3 TFIB: tsptunnel:next hop=10.93.72.13,inc=35,outg=Imp_null,if_number=7 TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun tag chg linec,fiblc=0,in tg=35,o tg=1,if=7,nh=10.93.72.13 TFIB: tagtun,next hop=10.92.0.7,inc=36,outg=1,idb=Et4/0/2 TFIB: tsptunnel:next hop=10.92.0.7,inc=36,outg=Imp_null,if_number=6 TFIB: tsptun update loadinfo:tag=36,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun tag chg linec,fiblc=0,in tg=36,o tg=1,if=6,nh=10.92.0.7 TFIB: tagtun_delete, inc = 36 tagtun tag del linec,itag=12 TFIB: tagtun_delete, inc = 35 tagtun tag del linec,itag=12 TFIB: tagtun,next hop=10.92.0.7,inc=35,outg=1,idb=Et4/0/2 TFIB: tsptunnel:next hop=10.92.0.7,inc=35,outg=Imp_null,if_number=6 TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun tag chg linec,fiblc=0,in tg=35,o tg=1,if=6,nh=10.92.0.7 On VIP: TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.93.72.13,if=7 TFIB: tsptunnel:next hop=10.93.72.13,inc=35,outg=Imp_null,if_number=7 TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun chg msg,in tg=36,o tg=1,nh=10.92.0.7,if=6 TFIB: tsptunnel:next hop=10.92.0.7,inc=36,outg=Imp_null,if_number=6 TFIB: tsptun update loadinfo:tag=36,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.93.72.13,if=7 TFIB: tsptunnel:next hop=10.93.72.13,inc=35,outg=Imp_null,if_number=7 TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun chg msg,in tg=36,o tg=1,nh=10.92.0.7,if=6 TFIB: tsptunnel:next hop=10.92.0.7,inc=36,outg=Imp_null,if_number=6 TFIB: tsptun update loadinfo:tag=36,loadinfo_reqd=0,no new loadinfo,no old loadinfo TFIB: tagtun chg msg,in tg=35,o tg=1,nh=10.92.0.7,if=6 TFIB: tsptunnel:next hop=10.92.0.7,inc=35,outg=Imp_null,if_number=6 TFIB: tsptun update loadinfo:tag=35,loadinfo_reqd=0,no new loadinfo,no old loadinfo
lists the significant fields in this display.
| Field | Description |
|---|---|
tagtun | Name of routine entered |
next hop=x.y.z.w | Next hop for the tunnel being created |
inc=x | Incoming tag for this hop of the tunnel being created |
outg=x | Outgoing tag (1 means Implicit Null tag) |
idb=s | Outgoing interface for the tunnel being created |
if_number=7 | Interface number of outgoing interface |
tsptunnel | Name of routine entered |
tsptun update loadinfo | Procedure being performed |
tag=x | Incoming tag of TFIB slot whose loadinfo is being updated |
loadinfo_reqd=x | Shows whether a loadinfo is expected for this entry (non-recursive accounting is on) |
no new loadinfo | Means no change in loadinfo required |
no old loadinfo | Means there was no loadinfo before |
tagtun tag chg linec | Linecard is being informed of the TSP tunnel |
fiblc=x | Which linecard being informed (0 means all) |
in tg=x | Incoming tag of new TSP tunnel |
o tg=x | Outgoing tag of new TSP tunnel |
if=x | Outgoing interface number |
nh=x.y.w.z | Next hop IP address |
tagtun_delete | Procedure being performed: delete a TSP tunnel |
tagtun tag del linec | Inform linecard of TSP tunnel deletion |
tagtun chg msg | Linecard has received a message to create a TSP tunnel |
debug tag-switching tfib enc
Use the debug tag-switching tsp-tunnels events EXEC command to enable logging of significant events that affect TSP tunnels. The no form of this command disables debugging output.
[no] debug tag-switching tsp-tunnels eventsThe debug tag-switching tsp-tunnels events command displays notifications received by the TSP tunnels module. The notifications displayed are generally associated with timers, interfaces, or interface addresses.
The following is an example of the display you see when you enter debug tag-switching tsp-tunnels events:
Router# debug tag-switching tsp-tunnels events TSP-TUNNEL: received event for Tunnels Checkup Timer: timer fired TSP-TUNNEL: received event for Tunnel1206: Interface administratively down
Table 34 lists the significant fields in this display.
| Field | Description |
|---|---|
TSP-TUNNEL | Identifies the source of the message as TSP tunnels. |
received event for | Identifies the object affected by the event. |
timer fired | Describes the event that has occurred for the named object. This field is object-specific. |
debug tag-switching tsp-tunnels signalling
Use the debug tag-switching tsp-tunnels signalling EXEC command to enable logging of TSP tunnel signalling activity. The no form of this command disables debugging output.
[no] debug tag-switching tsp-tunnels signallingTSP tunnels are signalled using the Resource Reservation Protocol (RSVP). TSP tunnel establishment is initiated at the head-end router by making an active open request to RSVP, which causes a message to be sent towards the tail-end router. At the tail-end router, RSVP notifies the TSP tunnels module of the incoming open request. If the tailend router accepts the request, it makes a corresponding passive open request to RSVP, which causes a message to return to the headend router, establishing the TSP tunnel state at each hop along the way.
The debug tag-switching tsp-tunnels signalling command displays the signalling requests made to RSVP by the TSP tunnels modules at the headend and tail-end routers. It also displays the signalling requests made by RSVP to the TSP tunnels modules at every hop along the path, in order to establish the TSP tunnel state.
The following is an example of the display you see when you enter debug tag-switching tsp-tunnels signalling:
Router# debug tag-switching tsp-tunnels signalling Open at tunnel head: TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: RSVP head-end open Open at tunnel tail: TSP-TUNNEL-SIG: received NEW PATH TAIL ARRIVAL event about tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: RSVP tail-end open TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206 NEW PATH TAIL ARRIVAL event handled successfully State setup at tail hop: TSP-TUNNEL-SIG: received ADD RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path previous hop is 10.2.0.10 (Et4/0/2) TSP-TUNNEL-SIG: sending ADD RESV reply for tunnel 10.106.0.6 1206 State setup at intermediate hop: TSP-TUNNEL-SIG: received ADD RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path previous hop is 10.32.0.6 (AT1/0.1) TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path next hop is 10.2.0.12 (Et4/0/2) TSP-TUNNEL-SIG: sending ADD RESV reply for tunnel 10.106.0.6 1206 State setup at head hop: TSP-TUNNEL-SIG: received ADD RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path next hop is 10.32.0.10 (AT0/0.1) TSP-TUNNEL-SIG: sending ADD RESV reply for tunnel 10.106.0.6 1206
Table 35 lists the significant fields in this display.
| Field | Description |
|---|---|
TSP-TUNNEL-SIG | Identifies the source of the message as TSP tunnels signalling. |
tunnel 10.106.0.6 1206 | Identifies the tunnel being signalled. |
RSVP head-end open | TSP tunnels module has made an active open request to RSVP for a tunnel head. |
received NEW PATH TAIL ARRIVAL | RSVP has notified the TSP tunnels module of an incoming setup request. |
RSVP tail-end open | TSP tunnels module has made a passive open request to RSVP for a tunnel tail. |
received ADD RESV request | TSP tunnels module has received a state setup request from RSVP for a tunnel. |
path previous hop is | Indicates the address of the previous hop in the path of the TSP tunnel being signalled, followed by the interface (in parentheses) being used to reach that hop. |
path next hop is | Indicates the address of the next hop in the path of the TSP tunnel being signalled, followed by the interface (in parentheses) being used to reach that hop. |
sending ADD RESV reply | The TSP tunnels module is sending a response to an earlier state setup request made by RSVP. If an error is not explicitly indicated, then the request was completed without failure. |
The display output for signalling teardown uses the same format:
Output at tunnel head: TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: RSVP head-end close TSP-TUNNEL-SIG: received DELETE RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path next hop is 10.32.0.10 (AT0/0.1) TSP-TUNNEL-SIG: sending DELETE RESV reply for tunnel 10.106.0.6 1206 Output at intermediate hop: TSP-TUNNEL-SIG: received DELETE RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path previous hop is 10.32.0.6 (AT1/0.1) TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path next hop is 10.2.0.12 (Et4/0/2) TSP-TUNNEL-SIG: sending DELETE RESV reply for tunnel 10.106.0.6 1206 Output at tunnel tail: TSP-TUNNEL-SIG: received PATH TAIL DELETION event about tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: RSVP tail-end close TSP-TUNNEL-SIG: received DELETE RESV request for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: tunnel 10.106.0.6 1206: path previous hop is 10.2.0.10 (Et4/0/2) TSP-TUNNEL-SIG: sending DELETE RESV reply for tunnel 10.106.0.6 1206 TSP-TUNNEL-SIG: PATH TAIL DELETION event handled successfully
debug tag-switching tsp-tunnels events
debug tag-switching tsp-tunnels tagging
Use the debug tag-switching tsp-tunnels tagging EXEC command to enable logging of TSP tunnel Tag Switching state programming. The no form of this command disables debugging output.
[no] debug tag-switching tsp-tunnels taggingThe debug tag-switching tsp-tunnels tagging command displays the setup and removal of the tag-switched path state (and any additional forwarding state) at a router hop that is associated with TSP tunnels.
The following is an example of the display you see when you enter debug tag-switching tsp-tunnels tagging:
Router# debug tag-switching tsp-tunnels tagging TSP-TUNNEL-TAGGING: tunnel 10.106.0.6 1206: fabric PROGRAM request TSP-TUNNEL-TAGGING: tunnel 10.106.0.6 1206: programming tag VC 1/43 on output interface ATM0/0.1 TSP-TUNNEL-TAGGING: background thread starting TSP-TUNNEL-TAGGING: background thread started (pid 57) TSP-TUNNEL-TAGGING: descriptor D7AB40: created [1 total] TSP-TUNNEL-TAGGING: descriptor D7AB40: continuing "Program" request TSP-TUNNEL-TAGGING: descriptor D7AB40: allocated outgoing ATM VC 1/43 (vcd 12) TSP-TUNNEL-TAGGING: descriptor D7AB40: set "Interface Point Out State" to, allocated TSP-TUNNEL-TAGGING: # of resource points held for "TC-ATM" interfaces: 1 TSP-TUNNEL-TAGGING: enabling TFIB fabric programming TSP-TUNNEL-TAGGING: TFIB is now enabled TSP-TUNNEL-TAGGING: descriptor D7AB40: set "Fabric State" to, enabled TSP-TUNNEL-TAGGING: descriptor D7AB40: set "Fabric Kind" to, default (TFIB) TSP-TUNNEL-TAGGING: descriptor D7AB40: set "Fabric State" to, set TSP-TUNNEL-TAGGING: tunnel 10.106.0.6 1206: fabric PROGRAM reply TSP-TUNNEL-TAGGING: background thread awaiting events
Table 36 lists the significant fields in this display.
| Field | Description |
|---|---|
TSP-TUNNEL-TAGGING | Identifies the source of the message as TSP tunnel tagging. |
tunnel 10.106.0.6 1206 | Identifies the tunnel being programmed. |
fabric PROGRAM request | Identifies the request that has been entered by the signalling code. The verb "PROGRAM" indicates that that state is being installed. All other verbs indicate that that state is being removed. |
programming tag | Identifies an input or output interface being programmed and the tag being set up or removed. |
descriptor xxxxxx | Identifies the switching fabric resource being used to send, switch, or receive tunnel data. |
allocated outgoing... | Indicates that an outgoing tag (or VPI/VCI) has been allocated on the outgoing interface. |
enabling TFIB fabric programming | The TFIB switching fabric is required to support this tunnel and is enabled for use by this tunnel. |
TFIB is now enabled | The TFIB's state has changed to active---it was not previously in use. |
programming TFIB: | The TFIB is being programmed to forward tunnel packets as follows: packets arriving with tag 26 will be forwarded with tag 1. Tag 1 is the Implicit Null tag. |
set "<resource>" to, <state> | The resource identified by <resource> has been placed in the state described by <state>. |
fabric PROGRAM reply | Indicates that the request has been completed and that a reply is being sent to the signalling code. If an error is not explicitly indicated, the request was completed without a failure. |
debug tag-switching tsp-tunnels signally
This section lists and describes Cisco IOS Tag Switching system error messages. The system software sends these error messages to the console (and, optionally, to a logging server on another system) during operation. Not all system error messages indicate problems with your system. Some are purely informational, while others may help diagnose problems with communications lines, internal hardware, or the system software.
System error messages begin with a percent sign (%) and are structured as follows:
%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: Message-text
FACILITY is a code consisting of two or more uppercase letters that indicate the facility to which the message refers. A facility can be a hardware device, a protocol, or a module of the system software. Table 37 lists the system facilities codes.
SEVERITY is a single-digit code from 0 to 7 that reflects the severity of the condition. The lower the number, the more serious the situation. Table 38 lists the severity levels.
MNEMONIC is a code that uniquely identifies the error message.
Message-text is a text string describing the condition. This portion of the message sometimes contains detailed information about the event, including terminal port numbers, network addresses, or addresses that correspond to locations in the system memory address space. Because the information in these variable fields changes from message to message, it is represented here by short strings enclosed in square brackets ([ ]). A decimal number, for example, is represented as [dec]. Table 39 lists the representations of variable fields and the type of information in them.
The following is a sample system error message:
%LINK-2-BADVCALL: Ints. TDR=[dec]
| Code | Facility |
|---|---|
AAA | TACACS+ Authentication, Authorization, and Accounting security |
AIP | ATM Interface Processor |
ALIGN | Memory optimization in Reduced Instruction-Set Computer (RISC) processor |
AMDP2 | Presidio Ethernet & Laguna Fast Ethernet |
APPN | Advanced Peer-to-Peer Networking |
ARAP | Apple Remote Access Protocol |
ASPP | Asynchronous Security Protocol |
AT | AppleTalk |
ATM | Asynchronous Transfer Mode |
BAP | PPP Bandwidth Allocation Protocol (BAP) |
BGP | Border Gateway Protocol |
BRI | Integrated Services Digital Network (ISDN) Basic Rate Interface |
BRIMUX | AS5200 BRIMUX board |
BSC | Binary Synchronous Communications mode |
BSTUN | Block serial tunneling |
C1600 | Cisco 1600 platform |
C3600 | Cisco 3600 platform |
C5RSP | Cisco Catalyst 5000 platform |
CBUS | ciscoBus controller |
CDM | Cable Data Modem subsystem |
CI | 75xx platform chassis interface |
CIP facility | Channel Interface Processor |
CIRRUS_PM | Slow speed async/sync port module |
CLEAR | Clear facility |
CLNS | OSI Connectionless Network Service |
CLS | Cisco Link Services |
CLSDR | Cisco Link Services Driver |
COMP | Point-to-point compression |
CONTROLLER | Controller |
CPAD | Compression service adapter |
CPM | Combo Port Module device driver |
CSC2 | CSC2/CSC3 CPU cards |
CT3 | Channelized T3 port adapter |
DBUS | Data bus |
DIALER | Dial-on-demand routing |
DLC | Data-link control |
DLSw | Data-link switching |
DMA | Direct memory access |
DNET | DECnet |
DRP | Director Response Protocol |
DSPU | Downstream physical unit |
DSX1 | Channelized E1 (Europe) and T1(US) telephony standard |
DUAL | Enhanced Interior Gateway Routing Protocol |
DVMRP | Distance Vector Multicast Routing Protocol |
EGP | Exterior Gateway Protocol |
ENT_API | Entity MIB API |
ENV | Environmental monitor card |
ETHERNET | Ethernet for the C1000 series |
FDDI | Fiber Distributed Data Interface |
FLASH | Flash nonvolatile memory |
FR | Frame Relay |
FTC_TRUNK | Cisco 3801 platform |
GRIP | Xerox Network Systems (XNS) Routing Protocol |
HD | HD64570 serial controller |
HOOD | LAN controller 100VG-AnyLAN interface |
HP100VG | 100VG-AnyLAN PA driver |
HUB | Cisco Ethernet hub |
IBM2692 | IBM Token Ring chip set |
IFS | IOS File System |
IGRP | Interior Gateway Routing Protocol |
ILACC | ILACC driver |
INTERFACE_API | Binary API for the interface descriptor block |
IP | Internet Protocol |
IPC | Interprocess Communication |
IPFAST | IP fast switching |
IPRT | Internet Protocol routing |
IPX | Internetwork Packet Exchange Protocol |
IP-SNMP | Simple Network Management Protocol specific to IP |
ISDN | Integrated Services Digital Network |
LANCE | Local Area Network Controller Ethernet |
LANE | LAN Emulation |
LANMGR | IBM LAN Network Manager |
LAPB | X.25 Link Access Procedure, Balanced |
LAT | DEC Local Area Transport |
LEX | LAN extension |
LINEPROTO | Line Protocol |
LINK | Data link |
LLC2 | Logical Link Control type 2 |
LLIST | Linked list facility |
LNMC | LAN network manager |
LPD | Line printer daemon |
MAILBOX | ChipCom mailbox support |
MBRI | Multi-BRI port module |
MCI | Multiport Communications Interface |
MK5 | MK5025 serial controller |
MPA68360 | VIP Multi-channel Port Adapter |
MROUTE | Multicast route |
MUESLIX | Mx serial application-specific integrated circuit (ASIC) |
NIC100 | NIC100 driver |
NIM | Network interface module |
OSPF | Open Shortest Path First |
PA | Port adapter |
PAD | X.25 packet assembler/disassembler |
PARSER | Parser |
PIM | Protocol-independent multicast |
PPP | Point-to-Point Protocol |
QA | Queue and accumulator |
QLLC | Qualified Logical Link Control |
QUICC | MC68360 Quad Integrated Communications Controller |
RADIUS | Remote Access Dial-In User Service (RADIUS) facility |
RADIX | Radix facility |
RCMD | Remote commands |
RIP | IP Routing Information Protocol |
RSP | Route Switch Processor |
RSRB | Remote source-route bridging |
S4T68360 | Four port synchronous serial adapter based on the 68360 processor |
SCHED | Scheduler |
SDLC | Synchronous Data Link Control |
SDLLC | SDLC/Logical Link Control type 2 (LLC2) translation |
SEC | IP security |
SERVICE_MODULE | Service Module |
SLIP | Serial Line Internet Protocol |
SMRP | Simple Multicast Routing Protocol |
SNAPSHOT | Snapshot dial-on-demand routing |
SNMP | Simple Network Management Protocol |
SNMP_MGR | SNMP Proxy |
SSE | Silicon switching engine |
STANDBY | Hot Standby Router Protocol (HSRP) |
STUN | Serial tunneling |
SUBSYS | Software subsystems |
SWITCH | Switch interface |
SYS | Operating system |
SYSMGT | System management |
TAC | Terminal Access Controller Protocol Access Control System |
TAGCON | Tag Switching Control |
TCATM | Tag Controlled ATM |
TDP | Tag Distribution Protocol |
TFIB | Tag Forwarding Information Base |
TIB | Tag Information Base |
TSP_TUNNEL | Tag-Switched Path tunnel |
TBRIDGE | Transparent bridging |
TCP | Transmission Control Protocol |
TMQ | Inbound terminal port queuing |
TN | Telnet |
TN3270 | TN3270 protocol |
TR | Token Ring |
TUN | Tunnel |
UCODE | Microcode |
UNIX | UNIX |
UTIL | Utility |
VINES | Banyan VINES |
VIP | Versatile Interface Processor |
VPN | Virtual Private Dialup Network |
X25 | X.25 |
| Level | Description |
|---|---|
0 - emergency | System unusable |
1 - alert | Immediate action needed |
2 - critical | Critical condition |
3 - error | Error condition |
4 - warning | Warning condition |
5 - notification | Normal, but significant, condition |
6 - informational | Informational message only |
7 - debugging | Appears during debugging only |
Error message severity levels correspond to the keywords assigned by the logging global configuration commands that define where and at what level these messages appear. The default is to log messages to the console at the debugging level (7). For more information, see the system configuration chapter and descriptions of the logging command in the appropriate Cisco IOS configuration guide and command reference publications.
| Representation | Type of Information |
|---|---|
[atalk_address] | AppleTalk address |
[atalk_net] | AppleTalk network, either 600 or 600-601 |
[char] | Single character |
[chars] | Character string |
[dec] | Decimal number |
[enet] | Ethernet address (for example, 0000.FEED.00C0) |
[hex] | Hexadecimal number |
[inet] | Internet address (for example, 12.128.2.16) |
[int] | Integer number |
[node] | Address or node name |
[sci_notation] | Scientific notation |
[t-line] | Terminal line number in octal (or decimal if the decimal-TTY service is enabled) |
[v-name] | VINES name; or number (hex or decimal) |
Some messages describe internal errors and contain traceback information. This information is very important and should be included when you report a problem to your technical support representative.
The following sample message includes traceback information:
-Process= "Exec", level= 0, pid= 17This section lists the Tag Switching error messages.
Explanation An internal inconsistency was detected when an attempt was made to remove from a list an item not on the list.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An internal inconsistency was detected when an attempt was made to add to a list an item already on the list.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to allocate a tag-switching data structure failed because of a low memory condition.
Recommended Action Reduce other system activity if possible. If this message persists, call your technical support representative for assistance.
Explanation An unexpected failure occurred during the building of a TDP protocol information element (PIE) for transmission to a TDP peer device. It occurred when an attempt was made to add a tag binding or an address to the PIE.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An action attempted by the tag control process encountered an unexpected condition.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation A problem was encountered in the cleanup following termination of a TDP session.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE that was received from a TDP peer device contained an unexpected binding list type. The PIE will be ignored.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by the disabling of dynamic Tag Switching at the chassis level (enter the no tag ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation on the TDP directed adjacency data structure failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation When a process, such as the TDP process, must request that the tag distribution and control process take some action, it queues a work item for the tag distribution and control process. If the attempt to queue the work item fails, the message shown here is generated. The failure can occur if the system is unable to allocate memory to hold the work request, or if the process has stopped accepting requests on its work queue.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation The tag distribution and control process failed to initialize itself. The probable cause is insufficient memory.
Recommended Action Reduce other system activity if possible. If this message persists, call your technical support representative for assistance.
Explanation The revision number used to manage advertisement of interface addresses to TDP peer devices overflowed. This results in faulty advertisement of interface addresses to TDP peer devices and faulty Tag Switching on those peer devices.
Recommended Action To restore proper interface address advertisement, reboot the platform. Report this condition to your technical support representative.
Explanation A TDP peer device has requested an action that is not currently implemented by the tag distribution and control subsystem.
Recommended Action The request is ignored. If it occurs repeatedly, copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation involving the state machine for a TDP peer device failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to create the tag distribution and control process failed. The probable cause is insufficient memory.
Recommended Action Reduce other system activity, if possible. If this message persists, call your technical support representative for assistance.
Explanation Some Tag Information Base (TIB) maintenance operations involve a complete scan (walk) of the TIB data structure. This message is generated when a TIB walk encounters an unexpected failure.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Recommended Action If the message recurs, copy the error message exactly as it appears on the console or in the system log, call your Cisco technical support representative, and provide the representative with the error message text.
Explanation An operation on the state machine for the tag distribution and control process failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation The tag distribution and control process maintains a data structure used to convert between the TDP identifier for a TDP peer device and the IP addresses of that peer device. This message is generated when an internal inconsistency is discovered in that data structure.
Recommended Action Disable dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), wait 15 to 20 seconds, and then reenable it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation The tag distribution and control process maintains a data structure used to convert between the TDP identifier for a TDP peer device and the IP addresses of that peer device. This message is generated when an internal inconsistency is discovered in that data structure.
Recommended Action Disable dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), wait 15 to 20 seconds, and then reenable it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation When a new IP address for a TDP peer device is learned, it may be necessary to update the Tag Forwarding Information Base (TFIB) for any routes for which the new address is a next hop. Deciding whether it is necessary to update the TFIB is the responsibility of an "address process." This message is generated when an attempt to queue work for the address process fails.
Recommended Action This is an informational message. The system remembers that it needs to do this work and regularly attempts to queue the necessary work item. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation When a new IP address for a TDP peer device is learned, it may be necessary to update the TFIB for any routes for which the new address is a next hop. Deciding whether it is necessary to update the TFIB is the responsibility of an "address process". This message is generated when an attempt to create the address process fails.
Recommended Action This is an informational message. As long as it needs the process, the system regularly attempts to create it. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation The system was unable to initialize the data structure used to support allocation of tags for Tag Switching for the specified tag pool.
Recommended Action The system ignores the event. However, because the system will not be able to allocate tags from the tag pool, it will not advertise them to peer devices. Therefore, it will not be able to forward tagged packets it receives (because it advertises no tags, it should not receive any tagged packets). Copy the message exactly as it appears, and report it along with the startup and running configuration to your technical support representative.
Explanation An attempt to queue a TDP PIE for transmission to a TDP peer device failed.
Recommended Action This is an informational message. Failure to queue a PIE for a peer device should occur only when the TDP session with the peer device no longer exists. The software should recover from this situation by discarding the TDP session and trying to establish a new one. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation An internal inconsistency was detected when an attempt was made to insert an item in a list.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Recommended Action ATM TAG Control uses a table-driven state machine to keep track and transition a TVC through various states. A state transition occurs when a TVC receives one of many possible events. When this error occurs, it means that a TVC receives an event that it did not expect while in this state.
Recommended Action The system can continue, but may lose the TVC that generates this error. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to request or to create a binding failed while the ATM tag-control system was not initialized. Probable cause is misconfiguration or low memory.
Recommended Action Reduce other system activity if possible, and call your technical support representative for assistance.
Explanation An internal inconsistency was detected when an attempt was made to remove from a list an item not on the list.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An internal inconsistency was detected when an attempt was made to add to a list an item already on the list.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to create the ATM tag control process failed. The probable cause is insufficient memory.
Recommended Action Reduce other system activity if possible, and call your technical support representative for assistance.
Explanation An unexpected bind is received for a prefix. This message appears only when a memory resource allocation failure prevents this peer device from asking the neighbor to release the bind. The system will continue, but the downstream neighbor could be holding a binding for which there is no matching VCI at this end.
Recommended Action Reduce other system activity if possible, and call your technical support representative for assistance.
Explanation This message appears when a loop is discovered in the network.
Recommended Action Check the configuration and network path for the relevant prefix.
Explanation ATM TAG Control received a malformed PIE from TDP.
Recommended Action This does not affect system operation, but if the error persists, report it to your technical support representative.
Explanation Tag Switching is not enabled on the specified interface. Tag VCI requests and advertising will be rejected. As a side effect, the VCI requests at the upstream device can remain in BindWait state until Tag Switching is reenabled on this interface.
Explanation This message appears when a loop is discovered in the network.
Recommended Action Check the configuration and network path for the relevant prefix.
Explanation A TDP PIE containing an address with a bad length has been received from a peer device.
Recommended Action This is an informational message. The system ignores the remainder of the PIE beyond the bad item. The partially processed PIE may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing a metric with a bad length has been received from a peer device.
Recommended Action This is an informational message. The system ignores the remainder of the PIE beyond the bad item. The partially processed PIE may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing an unknown metric list type or one that is unexpected for the situation has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unknown TDP PIE type has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the no tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing a destination prefix with a bad length has been received from a peer device.
Recommended Action This is an informational message. The system ignores the remainder of the PIE beyond the bad item. The partially processed PIE may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation An action attempted by the TDP encountered an unexpected condition.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An action attempted by the TDP implementation failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to allocate a buffer for a TDP Keep Alive PIE has failed.
Recommended Action The system omits transmission of the TDP keep alive PIE. This may result in termination of one or more TDP sessions as the peer devices time out the sessions. If this message persists, reduce other system activity if possible, and call your technical support representative for assistance.
Explanation A malformed TDP PIE has been received from a TDP peer device.
Recommended Action This is an informational message. The system recovers from this situation by terminating the TDP session and attempting to establish a new session with the peer device. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation An error occurred while attempting to read a TDP PDU received from a peer device.
Recommended Action This is an informational message. The system recovers from this situation by terminating the TDP session and attempting to establish a new session with the peer device. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation An operation on the state machine for a TDP peer device failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation The VPI range exchanged between the TDP peer devices is nonoverlapping.
Recommended Action The system cannot create a TDP session between the affected TDP peer devices. Reissue the tag-switching vpi command on the appropriate interface with the correct VPI range.
Explanation An attempt to allocate a buffer for TDP TAGATM VPI/VCI ranges has failed.
Recommended Action The system cannot create a TDP session between the affected TDP peer devices. If this message persists, reduce other system activity if possible, and call your technical support representative for assistance.
Explanation A TDP PIE containing an address list type that is unexpected for the situation has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the no tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing a binding list type that is unexpected for the situation has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the no tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE that is unexpected for the situation has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing an unknown address list type has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation A TDP PIE containing an unknown binding list type has been received from a peer device.
Recommended Action This is an informational message. The system ignores the PIE. This may result in impaired or faulty Tag Switching with the peer device. You might be able to correct the situation by disabling dynamic Tag Switching at the chassis level (enter the no tag-switching ip command), waiting 15 to 20 seconds, and then reenabling it (enter the tag-switching ip command). In addition, copy the message exactly as it appears, and report it to your technical support representative.
Explanation The TDP requires that each chassis have a TDP identifier. An attempt to set the TDP identifier for the chassis has failed.
Recommended Action This is an informational message. As long as it needs to set its chassis TDP identifier, the system periodically attempts to do so until it succeeds. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Explanation A violation of the TDP protocol by a TDP peer device has been detected.
Recommended Action This is an informational message. The system recovers from this situation by terminating the TDP session and attempting to establish a new session with the peer device. If this message occurs repeatedly, copy it exactly as it appears, and report it to your technical support representative.
Recommended Action The tag-switching advertise-tags configuration command has no effect for tag-controlled ATM interfaces. The rationale for this behavior is summed up this way:
Recommended Action No action is required.
Recommended Action The tag-switching advertise-tags configuration command has no effect for tag-controlled ATM interfaces. The rationale for this behavior is summed up this way:
Recommended Action No action is required.
Explanation This is an informational message generated by the TDP implementation.
Recommended Action No action is required.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation on the Tag Forwarding Information Base (TFIB) requiring memory failed because of insufficient free memory.
Recommended Action Reduce other system activity if possible. If this message persists, call your technical support representative for assistance.
Explanation A temporary difference occurred between the Cisco Express Forwarding (CEF) data base and the TFIB. This difference will be resolved later.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An invalid tag was seen during an operation on the TFIB.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation A temporary difference occurred between the CEF data base and the TFIB. This difference will be resolved later.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An unexpected operation on the TFIB occurred.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An action attempted by the TIB implementation failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation During initialization for Tag Switching, an attempt to initialize the TIB failed, probably because of insufficient memory.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation on the TIB involving a locally assigned (incoming) tag failed.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An attempt to allocate a local (incoming) tag failed. This should happen only if the system has allocated all available local tags.
Recommended Action You can change the number of tags available for allocation by the tag-switching tag-range configuration command. Consult with your technical support representative to determine whether you should use this command to increase the number of available tags.
Explanation An operation on the TIB data structure failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation on the TIB involving a tag assigned by a TDP peer device failed.
Recommended Action This is an informational message. The system omits the tag operation. This may result in impaired or faulty behavior for tagged packets for this destination. Copy the message exactly as it appears, and report it to your technical support representative.
Explanation An operation on the TIB state machine failed.
Recommended Action Copy the message exactly as it appears, and report it to your technical support representative.
Explanation The TIB revision number used to manage advertisement of tags to TDP peer devices overflowed. This results in faulty tag distribution to TDP peer devices. The system recovers by toggling dynamic Tag Switching off and on, which forces reinitialization of the revision number.
Recommended Action None required.
Explanation A message handler used by the signaller to receive events or requests from RSVP could not be installed or removed.
Recommended Action Copy and save the message. If possible, restart the TSP tunnel signalling process by issuing the no tag-switching tsp-tunnels command, followed by the tag-switching tsp-tunnels command. If the message continues to occur even after you restart the signalling process several times, contact your technical support representative for assistance.
Explanation State associated with a TSP tunnel could not be completely removed because of an internal failure.
Recommended Action Copy and save this message. If possible, remove all local TSP tunnel states by issuing the no tag-switching tsp-tunnels command, followed by the tag-switching tsp-tunnels command. (TSP tunnels removed by the first command should be resignalled shortly after the second command has been issued.) If the message recurs, copy and save the message and call your technical support representative for assistance.
For information about the Cisco 7200 series and Cisco 7500 series routers, refer to the Cisco 7200 Series Installation and Configuration Guide and the Cisco 7500 Series Installation and Configuration Guide.
Posted: Wed Aug 25 08:11:26 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.