-
Cisco IOS XR Troubleshooting Guide for the Cisco XR 12000 Series Router
-
Preface
-
General Troubleshooting
-
Troubleshooting Booting
-
Troubleshooting Forwarding
-
Troubleshooting Interfaces
-
Collecting System Information
-
Process Monitoring and Troubleshooting
-
Troubleshooting Memory
-
Troubleshooting Upgrading and Downgrading Software
-
Troubleshooting the Statistics Infrastructure
-
Multiprotocol Label Switching Checklist
-
Troubleshooting Load Balancing on the Cisco XR 12000 Series Router
-
Index
-
Feedback
Table Of Contents
Troubleshooting IPv4 CEF Information
Troubleshooting Adjacency Information
Troubleshooting Transient Traffic Drop in Forwarding
Troubleshooting Control Plane Information
Troubleshooting the Interface Manager
Interface Manager Control Process
Troubleshooting the Trace Logs for the Interface Manager
Troubleshooting the Client for the Interface Manager
Troubleshooting the Rules for the Interface Manager
Troubleshooting the Control Chain and Interface Information
Troubleshooting the Registrations for the Interface Manager
Troubleshooting the Interface Manager Distributor
Interface Manager Distributor Overview
Troubleshooting the Trace Logs for the Interface Manager Distributor
Troubleshooting the Clients for the Interface Manager Distributor
Troubleshooting the Interface Information for the Interface Manager Distributor
Troubleshooting the Global Registrations for the Interface Manager Distributor
Troubleshooting the Rules for the Interface Manager Distributor
Troubleshooting Forwarding
Cisco Express Forwarding (CEF) is the mechanism that enables packet forwarding. CEF information is examined when data forwarding is not occurring as expected. Troubleshooting CEF involves comparing the Routing Information Base (RIB) information to the software Forwarding Information Base (FIB), verifying that the hardware is programmed correctly, verifying that the adjacencies are built correctly, verifying the control plane is built correctly, and gathering any necessary trace information.
The only prerequisite for CEF is a valid route in the RIB.
This chapter describes techniques that you can use to troubleshoot router forwarding. It includes the following sections:
•
Troubleshooting IPv4 CEF Information
•
•
•
•
•
Troubleshooting IPv4 CEF Information
CEF is an advanced, Layer 3 IP switching technology that optimizes network performance. It also improves the scalability for networks with large and dynamic traffic patterns, such as the Internet and networks characterized by intensive Web-based applications.
Information conventionally stored in a route cache is stored in several data structures for CEF switching. The data structures provide optimized lookup for efficient packet forwarding. The two main components of CEF operation are forwarding information base (FIB) and adjacency tables:
•
•
Figure 3-1 provides an overview of the components involved in contributing information to the CEF process and displays the interaction between the software and hardware elements of the CEF process.
Figure 3-1 CEF Process
To troubleshoot IPv4 CEF information on Cisco IOS XR software, perform the following procedure.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
Step 1
show route ipv4 prefix mask
Example:RP/0/0/CPU0:router# show route 192.168.2.0 255.255.255.0
Displays the current routes in the Routing Information Base (RIB).
•
•
A lower timer value is present when a route is installed in the RIB for a short period of time. A low timer value may indicate flapping. For example, if a BGP route was being installed and removed from the RIB table every sixty seconds, then the route is flapping.
Look for routes that have not been installed in the routing table for very long. The route will either be stable or flapping. If the route is flapping, contact contact Cisco Technical Support. For Cisco Technical Support contact information, see the "Obtaining Documentation and Submitting a Service Request" section in the Preface.
•
Step 2
show cef ipv4 prefix mask detail
Example:RP/0/0/CPU0:router# show route ipv4 192.168.2.0 255.255.255.0 detail
Displays the IPv4 Cisco Express Forwarding (CEF) table detailed entry information.
•
•
•
Step 3
show cef ipv4 prefix mask detail location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 192.168.2.0 255.255.255.0 detail location 0/14/cpu0
Displays the IPv4 CEF table for the designated ingress node.
•
•
•
Step 4
show cef ipv4 prefix mask detail location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 192.168.2.0 255.255.255.0 detail location 0/13/cpu0
Displays the IPv4 CEF table for the designated egress node.
•
•
•
Step 5
show cef ipv4 prefix mask hardware ingress detail location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 192.168.2.0 255.255.255.0 hardware ingress detail location 0/14/cpu0
Displays the IPv4 CEF table for the designated ingress node.
•
•
•
•
SW: 0x0c000000 00000020 00000000 00000000HW: 0x0c000000 00000020 00000000 00000000Step 6
show cef ipv4 prefix mask hardware egress detail location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 192.168.2.0 255.255.255.0 hardware detail egress location 0/13/cpu0
Displays the IPv4 CEF table for the designated egress node.
•
•
•
•
SW: 0x0c000000 00000020 00000000 00000000HW: 0x0c000000 00000020 00000000 00000000Step 7
show cef ipv4 interface type instance location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 interface tengige 1/3/0/7 location 1/3/cpu0Displays IPv4 CEF-related information for an interface.
Verify the interface handle `interface is marked' is as expected. The command output also shows how many references there are to the interface in CEF table and the IPv4 MTU.
Use this command for the ingress and egress interfaces.
Step 8
show cef ipv4 summary location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 summary location 0/3/cpu0Displays a summary of the IPv4 CEF table. Check the VPN routing and forwarding (VRF) names associated with the node, the route update drops, and that there are the expected number of incomplete adjacencies.
Note the number of routes CEF has entries for, the number of load sharing elements, and the number of references to this node.
Use this command for the ingress and egress line cards and route processor (RP).
Step 9
show cef ipv4 trace location node-id
Example:RP/0/0/CPU0:router# show cef ipv4 trace location 0/3/cpu0Displays IPv4 CEF trace table information.
Check if there is any flap on the prefix.
Use this command for the RP, and ingress and egress interfaces for the local line card.
Step 10
show cef platform trace ipv4 all location node-id
Example:RP/0/0/CPU0:router# show cef platform trace ipv4 all location 0/3/cpu0Displays CEF IPv4 hardware status and configuration trace table information.
Verify that the TLU pointer and RPF pointer are as expected.
Use this command for the ingress and egress interfaces for the local line card.
Step 11
Contact Cisco Technical Support.
If the problem is not resolved, contact Cisco Technical Support. For Cisco Technical Support contact information, see the "Obtaining Documentation and Submitting a Service Request" section in the Preface.
Troubleshooting Adjacency Information
To troubleshoot adjacency information on Cisco IOS XR software, perform the following procedure.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Step 1
show arp location node-id
Example:RP/0/0/CPU0:router# show arp location 0/12/cpu0Displays the Address Resolution Protocol (ARP) for an egress line card with a broadcast interface.
Ensure that you can find the IP address and that correct MAC address of the neighbor is learned.
Step 2
show arp traffic location node-id
Example:RP/0/0/CPU0:router# show arp traffic location 0/12/cpu0Displays ARP traffic statistics for an egress line card with a broadcast interface.
Check for any errors or IP packet drops.
Step 3
show adjacency interface-type interface-instance remote detail location node-id
Example:RP/0/0/CPU0:router# show adjacency pos 0/13/0/2 remote detail location 0/14/cpu0Displays detailed CEF adjacency table information for a remote ingress line card.
Ensure that the output shows IPv4 adjacency information and that an adjacency exists.
Step 4
show adjacency interface-type interface-instance remote detail hardware location node-id
Example:RP/0/0/CPU0:router# show adjacency pos 0/13/0/2 remote detail hardware location 0/14/cpu0Displays adjacency information for a remote ingress line card.
•
•
Step 5
show adjacency ipv4 nexthop ipv4-address detail location node-id
Example:RP/0/0/CPU0:router# show adjacency ipv4 nexthop 192.168.2.0 detail location 0/12/cpu0Displays adjacencies on an egress line card with a broadcast interface that are destined to the specified IPv4 next hop.
When an egress interface is broadcast, use the show adjacency ipv4 nexthop command to display the adjacency information.
Compare the mac layer rewrite information that shows the destination L2 address in the first part followed by the source L2 address, and the Ethernet value with the output from the show arp location node-id command.
Step 6
show adjacency interface-type interface-instance detail location node-id
Example:RP/0/0/CPU0:router# show adjacency pos 0/13/0/2 detail location 0/13/cpu0Displays CEF adjacency table information for an egress line card with a point to point interface.
There should be two IPv4 entries in the command output. Ensure both entries exist.
•
•
On broadcast interfaces you will have a SRC MAC only and one for each nexthop IP address. Please note the MTU is for the IPv4 minus the layer 2 header. Use the show im chains command to display MTU details.
Step 7
show adjacency ipv4 nexthop ipv4-address detail hardware location node-id
Example:RP/0/0/CPU0:router# show adjacency ipv4 nexthop 192.168.2.0 detail hardware location 0/12/cpu0Displays the hardware programming associated with the adjacency. Verify that the packets are being switched in the hardware.
Step 8
show adjacency interface-type interface-instance detail hardware location node-id
Example:RP/0/0/CPU0:router# show adjacency pos 0/13/0/2 detail hardware location 0/13/cpu0Displays the hardware programming information for a point-to-point interface such as the Packet-over-SONET/SDH (POS) interface. The rewrite information is slightly different because there is no MAC rewrite string as there is in Ethernet.
Verify that the rewrite is appropriate for the encapsulation on the interface. Compare the CEF hardware output and verify that the pointer matches the egress adjacency.
Step 9
show adjacency trace location node-id
Example:RP/0/0/CPU0:router# show adjacency trace location 0/13/cpu0Displays CEF adjacency trace table information.
Use this command for the egress interfaces for the local line card.
Step 10
show adjacency trace client aib-client location node-id
Example:RP/0/0/CPU0:router# show adjacency trace client ipv4_fib_mgr location 0/13/cpu0Displays CEF adjacency trace table information for a specified adjacency information base (AIB) client.
Use this command for the egress interfaces for the local line card.
Step 11
show adjacency hardware trace location node-id
Example:RP/0/0/CPU0:router# show adjacency hardware trace location 0/13/cpu0Displays CEF adjacency hardware trace table information.
Use this command for the egress interfaces for the local line card.
Step 12
Contact Cisco Technical Support.
If the problem is not resolved, contact Cisco Technical Support. For Cisco Technical Support contact information, see the "Obtaining Documentation and Submitting a Service Request" section in the Preface.
Examples
The following example shows that the TLU pointers match. The TLU pointers are indicated in bold.
RP/0/0/CPU0:router# show cef 202.112.36.224/30 hardware ingress location 0/0/CPU0202.112.36.224/30, version 1536, internal 0x42040001[1]...TLU2 0x0101041dTLU2 ENTRY 0SW: 0x00000000 00000000 00000000 00a22800HW: 0x00000000 00000000 00000000 00a22800label1: 0 label2: 0num of labels: 0 next ptr: 0x0000a228RP/0/0/CPU0:router# show adjacency pos 0/4/0/15 remote detail hardware location 0/0/CPU0...ingress adjacencyTLU3 : 0x200a228[HW: 0x00400000 0x00000000 0x00000000 0x00082800]num. entries : 1num. labels : 0label 1 : 0label 2 : 0next ptr : 0x828TLU4 : 0x3000828Entry[0][HW: 0x00000000 0x11410000 0x01480600The following example shows that the address information matches. The addresses are indicated in bold.
RP/0/0/CPU0:router# show arp location 0/1/cpu0Address Age Hardware Addr State Type Interface212.27.50.157 02:08:34 0016.c761.f509 Dynamic ARPA TenGigE0/1/0/2RP/0/0/CPU0:router# show adjacency ipv4 nexthop 212.27.50.157 detail loccation 0/1/cpu0Interface Address Version Refcount ProtocolTenGigE0/1/0/2 212.27.50.157 41 2 ipv40016c761f5090015fa9959890800mtu: 1500, flags 0 0 02894 packets, 156876 bytes0xffffffffTroubleshooting Transient Traffic Drop in Forwarding
To troubleshoot a momentary drop in IPV4 packet forwarding on Cisco XR12000 Series router, you must perform the following procedure.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Troubleshooting Control Plane Information
To troubleshoot control plane information on Cisco IOS XR software, perform the following procedure.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
show netio idb interface-type interface-instance location node-id
Example:RP/0/0/CPU0:router# show netio idb tengige0/0/0/0 location 0/0/cpu0Displays control plane information for the software switching path. The output provides useful statistics for determining software forwarding issues.
•
•
Note
•
Use this command for the ingress and egress interfaces for the local line card.
Step 2
show uidb index
Example:RP/0/0/CPU0:router# show uidb index
Displays the micro-interface descriptor block (IDB) index assigned by the software.
Check that the interface and the universal interface descriptor block (UIDB) value are what is expected.
Compare the IDB index to the uidb index value in the show adjacency ipv4 interface-type interface-instance detail hardware location node-id command output.
Step 3
show uidb data interface-type interface-instance location node-id
Example:RP/0/0/CPU0:router# show uidb data tengige 1/3/0/0 location 0/3/cpu0Displays, from a software perspective, features that are enabled on a selected interface.
•
•
•
Compare the output to the configuration of the interface and expected features.
Use this command for the ingress and egress interfaces for the local line card.
Step 4
show im chains interface-type interface-instance location node-id
Example:RP/0/0/CPU0:router# show im chains pos 0/14/0/0 location 0/14/cpu0or
RP/0/0/CPU0:router# show im chains pos 0/13/0/2 location 0/13/cpu0Displays the output of the control plane encapsulations for data plane forwarding.
•
•
Compare the output to the expected encapsulations on the interface, the correct MTU values, and the correct ifhandle value from the show cef ipv4 interface command output.
Use this command for the ingress interface on the ingress line card and the egress interface on egress line card.
Step 5
show imds interface brief
Example:RP/0/0/CPU0:router# show imds interface briefDisplays interface manager distribution server (IMDS) interface information.
Note
Check the state, MTU, encapsulation being used, and the ifhandle for each interface.
Step 6
show tbm hardware {ipv4 | ipv6} unicast dual detail location node-id
Example:RP/0/0/CPU0:router# show tbm hardware ipv4 unicast dual detail location 0/13/cpu0or
RP/0/0/CPU0:router# show tbm hardware ipv4 unicast dual detail location 0/14/cpu0Displays tree bitmap hardware-related ingress and egress information.
Check if there have been any failures in the different stages of the lookup.
Use this command for the ingress and egress interfaces for the local line card.
Step 7
Contact Cisco Technical Support.
If the problem is not resolved, contact Cisco Technical Support. For Cisco Technical Support contact information, see the "Obtaining Documentation and Submitting a Service Request" section in the Preface.
Examples
The following example displays the control plane information for the software switching path. Check for any errors or drops.
RP/0/0/CPU0:router# show netio idb tenGigE 0/1/1/0 location 0/1/cpu0TenGigE0/1/1/0 (handle: 0x01180020, nodeid:0x11) netio idb:---------------------------------name: TenGigE0_1_1_0interface handle: 0x01180020interface global index: 2physical media type: 30dchain ptr: <0x482ae8e0>echain ptr: <0x482d791c>fchain ptr: <0x482d79b8>driver cookie: <0x4824ad58>driver func: <0x4824ad44>number of subinterfaces: 4096subblock array size: 3DSNCNF: 0x00000000interface stats info:IN unknown proto pkts: 0IN unknown proto bytes: 0IN multicast pkts: 0OUT multicast pkts: 0IN broadcast pkts: 0OUT broadcast pkts: 0IN drop pkts: 0OUT drop pkts: 0IN errors pkts: 0OUT errors pkts: 0Chains--------------------Base decap chain:ether <30> <0xfd7aef88, 0x48302824> < 0, 0>Protocol chains:---------------<Protocol number> (name) StatsType Chain_node <caps num> <function, context> <drop pkts, drop bytes><7> (arp) Stats IN: 0 pkts, 0 bytes; OUT: 0 pkts, 0 bytesEncap:l2_adj_rewrite <86> <0xfcec7a88, 0x4834efec> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0>Decap:queue_fifo <56> <0xfcedda4c, 0x482dbee4> < 0, 0>arp <24> <0xfd1082cc, 0x00000000> < 0, 0>Fixup:l2_adj_rewrite <86> <0xfcec745c, 0x00000000> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0><12> (ipv4) Stats IN: 0 pkts, 0 bytes; OUT: 0 pkts, 0 bytesEncap:ipv4 <26> <0xfd10f41c, 0x482d7724> < 0, 0>ether <30> <0xfd7aeb44, 0x48302824> < 0, 0>l2_adj_rewrite <86> <0xfcec7a88, 0x4834f104> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0>Decap:queue_fifo <56> <0xfcedda4c, 0x482dbee4> < 0, 0>ipv4 <26> <0xfd10f474, 0x00000000> < 0, 0>Fixup:l2_adj_rewrite <86> <0xfcec745c, 0x00000000> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0><22> (ether_sock) Stats IN: 0 pkts, 0 bytes; OUT: 0 pkts, 0 bytesEncap:ether_sock <98> <0xfd7b1630, 0x48302824> < 0, 0>l2_adj_rewrite <86> <0xfcec7a88, 0x48304c1c> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0>Decap:queue_fifo <56> <0xfcedda4c, 0x482dbee4> < 0, 0>ether_sock <98> <0xfd7b1874, 0x48302824> < 0, 0>Fixup:l2_adj_rewrite <86> <0xfcec745c, 0x00000000> < 0, 0>queue_fifo <56> <0xfcedda68, 0x482dbee4> < 0, 0>txm_nopull <60> <0xfcea2a5c, 0x482dc11c> < 0, 0>Protocol SAFI counts:--------------------Protocol SAFI Pkts In Bytes In Pkts Out Bytes Out--------------- ---------- ---------- ---------- ---------- ----------ipv4 Unicast 0 0 0 0ipv4 Multicast 0 0 0 0ipv4 Broadcast 0 0 0 0ipv6 Unicast 0 0 0 0ipv6 Multicast 0 0 0 0The following example shows that the micro-idb index value is 12.
RP/0/0/CPU0:router# show uidb index tengige1/3/0/6.30 location 1/3/cpu0------------------------------------------------------------------------------Location Interface-name Interface-Type Ingress-index Egress-index---------------------------------------------------------------------------1/3/CPU0 TenGigE1_3_0_6.30 Sub-interface 20 12Comparing the IDB index value of 12 in the show uidb index command to the uidb index value in the following command output shows that the values are the same.
RP/0/0/CPU0:router# show adjacency ipv4 tengige1/3/0/6.30 detail hardware location 1/3/cpu0Interface Address Version Refcount ProtocolTenGigE1/3/0/6.30 (src mac only) 90 1 ipv4000000000000001243602d8b8100001e0800mtu: 1500, flags 1 0 1453 packets, 42582 bytes453 hw-only-packets, 42582 hw-only-bytesether egress adjacencyTLU1 : 0x4407[HW: 0x00401862 0xc4170800 0x8100001e 0x01060700]num. entries : 1uidb index : 12counter msb : 0x2counter lsb : 0xc417vlan e or len : 0x800ether len : 0x8100 (33024)vlan info : 30next ptr : 0x10607The following example displays, from a software perspective, features that are enabled on a selected interface. Compare the output to the configuration of the interface and expected features. Verify that the configured features are correctly enabled.
RP/0/0/CPU0:router# show uidb data location 0/6/cpu0--------------------------------------------------------------------------Location = 0/6/CPU0Index = 0Pse direction = INGRESSGlobal general 16 bytes:------------------------ROUTER_ID: 45.104.151.108MINIMUM MASK DESTINATION: 0 / 0MINIMUM MASK SOURCE: 0 / 0BYTES OF SNIFF PACKET: 0SUPPRESS PUNT ACL: 0MPLS PROPAGATE TTL FLAG: 1PARITY: 0FABRIC QOS ENABLE FLAG: 0--------------------------------------------------------------------------Location = 0/6/CPU0Index = 0Pse direction = EGRESSGlobal general 16 bytes:------------------------ROUTER_ID: 45.104.151.108MINIMUM MASK DESTINATION: 0 / 0MINIMUM MASK SOURCE: 0 / 0BYTES OF SNIFF PACKET: 0SUPPRESS PUNT ACL: 0MPLS PROPAGATE TTL FLAG: 1PARITY: 0IPV4 PREFIX ACCNTG: 0--------------------------------------------------------------------------Location = 0/6/CPU0Ifname/Ifhandle = GigabitEthernet0_6_5_0Index = 1Pse direction = INGRESSGeneral 16 bytes:-----------------IFHANDLE: 0x168002STATUS: 0IPV4 ENABLE: 0IPV6 ENABLE: 0MPLS ENABLE: 0STATS POINTER: 0x2c400SPRAYER QUEUE: 32IPV4 MULTICAST: 0IPV6 MULTICAST: 0USE TABLE ID IPV4: 0USE TABLE ID IPV6: 0USE TABLE ID MPLS: 0TABLE ID: 0QOS ENABLE: 0QOS ID: 0NETFLOW SAMPLING PERIOD: 0L2 PKT DROP: 0L2 QOS ENABLE: 0SRC FWDING: 0*BUNDLE IFHANDLE: 0*TUNNEL IFHANDLE: 0*L2 ENCAP: 3* Not programmed in hardware...Troubleshooting the Interface Manager
These sections describe how to troubleshoot the interface manager (IM):
•
•
•
•
•
•
Interface Manager Control Process
The interface manager (IM) is the main control process in the Packet Forwarding Infrastructure (PFI) and runs one copy on each line card (LC), route processor (RP), and distributed route processor (DRP). The IM process creates interfaces, adds protocols and capsulations, initiates state and MTU walks, and registers for notification changes.
The following sample output from the show im server activity command with the summary keyword shows an overall summary of information about the instance of IM on a particular node:
RP/0/0/CPU0:router# show im server activity summaryINTERFACE MANAGER ACTIVITY SUMMARY (v1.0)---------------------------------------------Notifications-----------------------------------------------------------------------Owner : 2298Third Party : 2058Total notifications sent : 4356-----------------------------------------------------------------------Control tree nodesintf: caps: [ ctrl:] proto: vc:-------------------------------------------------------------------------Created 506 1037 [ 1543] 511 3Deleted 0 0 [ 0] 6 0Existing 506 1037 [ 1543] 505 3-------------------------------------------------------------------------Memory (bytes): 194304 157624 [ 351928] 67682 49212-------------------------------------------------------------------------Total memory (bytes): 468822Avg. memory per intf (bytes): 926Avg. caps per intf: 2Increases of intf proto map: 1Increases in proto max: 2-------------------------------------------------------------------------Client requestsRequest Type Requests: Operations: Max Ops:-----------------------------------------------------------------------SPECIFY_CONTROL 23 23 1NOTIFY_GET 136 136 1INTERFACE_REPLICATE 0 0 0INTERFACE_CREATE 4 4 1INTF_CREATE_WITH_BCAPS 0 0 0INTERFACE_DELETE 0 0 0DELETE_CONFIRM 0 0 0CAPS_BASE_DEFINE 0 0 0RESOURCE_ALLOC_DONE 0 0 0CAPS_ADD 6 6 1CAPS_REMOVE 0 0 0ADOPT_CONFIRM 0 0 0PROTO_LOOKUP 5 5 1PROTO_REVERSE_LOOKUP 0 0 0CAPS_LOOKUP 10 10 1CAPS_REVERSE_LOOKUP 1 1 1INTF_TYPE_LOOKUP 3 3 1INTF_TYPE_REVERSE_LOOKUP 0 0 0INTERFACE_FIND 29 29 1INTERFACE_NAME 223 223 1INTERFACE_GET_BASE_CAPS 7 7 1INTERFACE_READY 4 4 1INTERFACE_GET_TYPE 3 3 1CONTROL_PARENT_INTF_LOOKUP 0 0 0INTERFACE_DESC_LOOKUP 0 0 0CAPS_DISPLAY_NAME_LOOKUP 0 0 0STATE_QUERY 3263 3263 1STATE_REGISTER 1 1 1STATE_UPDATE 4 4 1CREATE_REGISTER 9 9 1CREATE_REGISTER_NAME 0 0 0CHILDREN_CREATE_REGISTER 0 0 0OWNER_SUPPORT_SET 1 1 1OWNER_SUPPORT_GET 0 0 0OWNER_CHANGE 0 0 0CONFIG_NEW_ENCAP 0 0 0IF_CONFIGURABLE 0 0 0IF_IS_HW 0 0 0MTU_UPDATE 4 4 1MTU_IMPOSE 0 0 0MTU_QUERY 1 1 1MTU_REGISTER 1 1 1DATA_CAPS_LOAD 0 0 0DATA_CAPS_UNLOAD 0 0 0IF_IS_CONTROL_ONLY 0 0 0GET_MAIN_INT_PARSER_DATA 0 0 0GET_SUB_INT_PARSER_DATA 0 0 0REMOVE_CALLBACK 0 0 0REPLACE_BASE_CAPS 0 0 0CAPS_DPC_DISTRIBUTE 5 5 1PROTO_CHAINS_DISABLE 0 0 0PROTO_CHAINS_ENABLE 0 0 0------------ ------------ ------------IF_CREATE 3 502 500IF_READY 0 0 0IF_FIND 578 1578 500IF_DELETE 0 0 0DEL_CONFIRM 0 0 0IF_UPDATE_PRIMARY 1 1 1IF_FLAGS 0 0 0CAPS_ADD 26 526 500CAPS_REMOVE 0 0 0CAPS_BASE_DEFINE 3 3 1ID_LOOKUP 9 9 1STATE_UPDATE 14 14 1MTU_UPDATE 17 202 93REG_WALK 9 11 2REG_CREATE 27 29 3IF_NAME 13 14 2STATE_QUERY 0 0 0MTU_QUERY 0 0 0PIC_UPDATE 0 0 0RSRC_ALLOC 3 3 1REPL_INTF_OPER 0 0 0REPL_INTF_OPER_ACK 0 0 0INTF_CONFIG_PARAM 0 0 0IF_REPLICATE 0 0 0ADOPT_CONFIRM 0 0 0CFG_NEW_BC 0 0 0REPLACE_BC 0 0 0IF_TYPE_GET 3 3 1IF_DESC_LOOKUP 0 0 0IF_DESC_LOOKUP_BYNAME 0 0 0CAPS_DN_LOOKUP 0 0 0CTRLP_IF_LOOKUP 0 0 0ID_REV_LOOKUP 0 0 0REG_CREATE_NAME 0 0 0IF_GET_BC 1 1 1DPC 19 521 500DP_RESTART_REG 2 3 2IF_CREATE_CHILDREN 0 0 0IF_CREATE_IND 0 0 0CAPS_ADD_SP 0 0 0CAPS_ADD_TGT 0 0 0CAPS_GET_NODESET 0 0 0IIR_UL_INFO 0 0 0CFG_RESTORE 0 0 0Total non-bulk requests: 3743 3743 1Total bulk requests: 728 3420 500-----------------------------------------------------------------------Request data received: 230058 bytes-----------------------------------------------------------------------IM to IMProxy download commands#cmds #bytes #mallocs-----------------------------------------------------------------------Total 5891 135328 11782Per cmd - 22 2-----------------------------------------------------------------------Downloads#Super #GS_SHM Total [ Empty Errors Timeouts]-----------------------------------------------------------------------3 55 58 [ 1 0 0]-----------------------------------------------------------------------Total data downloaded: 169652 bytesAvg. size of download: 2925 bytes-----------------------------------------------------------------------Download Memory (in bytes)Type Reserved In Use Max In Use Max Dnld-----------------------------------------------------------------------Super - 0 106032 106032GS_SHM 821688 0 12196 12196Atomic Ring 448016 400000 - ------------------------------------------------------------------------Rules-----------------------------------------------------------------------Max Protocol: : 85Max Protocol Chg: : 2-----------------------------------------------------------------------Interface Handle Allocation Memory: (element is 16 bytes)Allocation Type: Initial Sz: Chunk Sz: #Chunks: Max Chunks:-----------------------------------------------------------------------Physical interface handles 0 32 16 16Virtual interface handles 0 32 0 0Other physical handles 0 512 4 4Other virtual handles 0 512 0 0-----------------------------------------------------------------------Initial Memory: 0 bytesCurrent Memory: 40960 bytesMax Memory: 40960 bytes-----------------------------------------------------------------------Interface Handle Freelist Memory (element is 16 bytes)Freelist Type Size Max Size Memory-----------------------------------------------------------------------Physical interface handles 518 544 8288Virtual interface handles 0 0 0Other physical handles 2551 2560 40816Other virtual handles 0 0 0-----------------------------------------------------------------------Current usage 3069 49104Max usage 3104 49664-----------------------------------------------------------------------PFI-IFH Broadcast Queue Memory (element is 20 bytes)Allocation Type: Initial Sz: Chunk Sz: #Chunks: Max Chunks:-----------------------------------------------------------------------Create Queue 1024 1024 0 0Delete Queue 0 0 0 0-----------------------------------------------------------------------Current Total Memory: 20480 bytesMax Memory: 20480 bytes-----------------------------------------------------------------------1500 items committed in 23 sec (62)items/sec----------------------------------------------------------------------UpdatingTimer Queue (element is 24 bytes)Queue Size Max Size Memory-----------------------------------------------------------------------State 11 11 264MTU 706 706 16944Delete 0 0 0-----------------------------------------------------------------------Current Total 717 717 17208Max Memory 17208Freelist 0 8 0-----------------------------------------------------------------------Bulk storesStore Entries Max Entries Memory-----------------------------------------------------------------------Bulk 0 0 0Bulk Delete 0 0 0Updated Commit database in 1 seculk Delete 0 0 0DP Restart 2 2 56-----------------------------------------------------------------------Total 2 2 56-----------------------------------------------------------------------Client callback information#Active #Dead Total Memory (bytes)-----------------------------------------------------------------------23 0 23 19568-----------------------------------------------------------------------Requested Client Connections : 23Requested Disconnections : 0Unrequested Disconnections : 0IM server (re)start count : 1-----------------------------------------------------------------------Third Party RegistrationsCreate/Delete State MTU Memory (bytes)-----------------------------------------------------------------------36 6 7 1072-----------------------------------------------------------------------IM->IMD communications informationType Chunk Sz #Chunks Used Max Mem Max Mem----------------------------------------------------------------------------Big 1024 30 0 0 0 0Small 512 300 44 1358 880 106800No-chunk 0 0 0 0 0 0Total 330 44 1358 880 106800----------------------------------------------------------------------------Pre-allocated memory for small chunks : 155057 bytesPre-allocated memory for big chunks : 31095 bytes----------------------------------------------------------------------------Transmit queue size: 142 elements[range MIN:100 -> MAX:1000based on nfn size: 108 bytes, optimal msg size: 15376 bytes]----------------------------------------------------------------------------Comms type Count #Elem Average Success #Retry Fail #RetryTx start 1875 945489 504 72 0 0 0Tx done 73 4054 55----------------------------------------------------------------------------Total bytes sent: 186332attempted: 186332----------------------------------------------------------------------------Checkpoint information----------------------------------------------------------------------------Timer Expiries : 234Checkpoints : 19----------------------------------------------------------------------------Node status Chkptd Avg nodes/chkpt Bytes chkptd Avg bytes/chkptClean 300 15 35360 1861Dirty 2616 137 353984 18630Total 2916 153 389344 20491----------------------------------------------------------------------------Memory summary----------------------------------------------------------------------------Total memory reserved : 1251438 bytesTotal memory used : 997670 bytes----------------------------------------------------------------------------Troubleshooting the Trace Logs for the Interface Manager
To debug the problem that occurred on the router and the IM, use the show im trace command with both the location and internal keywords to trace logs that are recovered from the router for the applicable location.
The debug im errors command enables the server for error debugging. When the problem is narrowed down, debugging is enabled to provide more information.
The debug im callbacks command is used to display when notifications are arriving at the clients from IM or Interface Manager Distributor (IMD). In addition, the command checks to see the number and types of messages that are in the set of notifications.
Troubleshooting the Client for the Interface Manager
A client must be connected to use any of the IM services. If the client is an owner of the nodes in the IM or is registered for the notifications with the IM, the client must specify a callback handle. The show im client command is used to find which clients are connected and have registered callback handles.
Note
The following sample output from the show im client command shows which clients are connected:
RP/0/0/CPU0:router# show im client infoINTERFACE MANAGER ACTIVITY CLIENT-INFO--------------------------------------Process PID JID Context Status Handle-------------------- ------- ------- ----------------------- ------- ----------pfi_ifh_server 53321 246 pfi_ifh alive 0x30000001sysldr 53297 287 slr_im_evc alive 0x30000002driver_infra_partner 24603 54 di-node0_0_CPU0-2 alive 0x30000003ether_caps_partner 61515 154 ether alive 0x30000004qos_ma 61517 254 qos_ma alive 0x30000005driver_infra_partner 24603 54 caps_netio_0 alive 0x30000006aib 61520 100 aib alive 0x30000007ipv4_fib_mgr 61525 188 ipv4_fib_cfg_im_connect alive 0x30000008arp 61522 102 arp alive 0x30000009arp 61522 102 arp_ipv4_caps_reg alive 0x3000000aipv4_io 65623 189 ipv4 alive 0x3000000bntpd 65632 192 ntpv4 alive 0x3000000ccdp 65633 125 cdp alive 0x3000000dcdp 65633 125 cdp_caps alive 0x3000000empls_lfd 65631 227 mpls_lfd alive 0x3000000ftcp 65640 294 tcp alive 0x30000010clns 65643 130 clns_transport alive 0x30000011parser_server 65657 244 parser alive 0x30000012bundlemgr_distrib 65653 124 BM-DISTRIB_LOCAL alive 0x30000013nd_partner 65671 235 Null0 alive 0x30000014ipv6_io 65670 202 ipv6-fint alive 0x30000015null_caps_partner 69770 239 null_caps_partner alive 0x30000016ipv6_nd 65672 204 ipv6-nd alive 0x30000017ipv6_grp 69785 201 ipv6-grp alive 0x30000018mpls_lsd 69788 229 mpls_lsd alive 0x30000019fint_partner 53302 157 FINT alive 0x30000000Troubleshooting the Rules for the Interface Manager
A process that calls the IM to create an interface or add a capsulation is defined as an owner. The owners own sets of triplets from an interface, protocol, or capsulation. The triplets are secure domain router (SDR) unique identifiers to control the nodes.
The interface handle is displayed in hexadecimal and contains platform-specific mapping for the node ID, virtual bit, and interface instance number for the node ID.
The protocol and capsulation numbers are small numbers and are displayed in hexadecimal or decimal. They represent a unique identifier for a specific protocol such as IPv4, IPv6, or MPLS.
The show im rules command is used to set interfaces, protocols, and capsulations that are installed on the router.
The following sample output from the show im rules command with the interface-types keyword shows the types of interfaces:
RP/0/0/CPU0:router# show im rules interface-typesIM rules interface-type data============================tag: IFT_LOOPBACKid: 16source: /pkg/rules/loopback.intfdescription: Loopback interface(s)allowed-base-caps: loopbackdefault-base-caps: loopbackdynamic-ifname: Loopbackowner-string: loopbackdefault-mtu: 1514subint-range: 0 - 65535invisibility: 0x2ignore: mtu deleteThe following sample output from the show im rules command with the capsulations keyword shows the rule of each type:
RP/0/0/CPU0:router# show im rules capsulationsIM rules caps data==================tag: ipv6_prerouteid: 128source: /pkg/rules/ipv6.capsdescription: IPv6 preroute capsulation nodesdll: libipv6_netio.dllordering: 0x6fffffffswitching: decaps encapsignore: state mtuThe following sample output from the show im rules command with the protocols keyword shows the rules for the protocols:
RP/0/0/CPU0:router# show im rules protocolsIM rules proto data===================tag: fint_n2nid: 6source: /pkg/rules/fint_n2n.capsdescription: Forwarder netio 2 netio packet forwarding protocoldll: libfint_n2n.dllchain: use-base-capsIf the rules for a specific capsulation, protocol, or interface are missing from the IM on a given node, you cannot create a control node for the type. If the rules are on the router, a process restart of ifmgr can resynchronize the rules.
Troubleshooting the Control Chain and Interface Information
When the control nodes are created, you can use both the show im chains command and the show im children command to see the given location and state for the IM nodes. Both commands display the ASCII names, which map to the interface, protocol, and capsulation triplets.
Tip
•
•
•
The following sample output from the show im chains command shows all the interface PICs and the current interface flags:
RP/0/0/CPU0:router# show im chains location allShowing all interface control chains:--------------------------------------------Interface MgmtEth0/0/CPU0/0, ifh 0x01000100 (up)[pic:0x0, intf_flags:0x5]Protocol Caps (state, mtu)<base> txm_nopull (up, 1514)queue_fifo (up, 1514)ether (up, 1514)arp arp (up, 1500)ipv4 ipv4 (up, 1500)ether_sock ether_sock (up, 1500)Interface Null0, ifh 0x01000080 (up)[pic:0x0, intf_flags:0x1c]Protocol Caps (state, mtu)<base> null (up, 1500)...Interface POS0/2/0/0, ifh 0x03000400 (administratively down)[pic:0x0, intf_flags:0x15]Parent interface: SonetPath0_2_0_0, ifh 0x03000300Protocol Caps (state, mtu)<base> txm_nopull (administratively down, 4474)queue_fifo (administratively down, 4474)hdlc (administratively down, 4474)chdlc chdlc (administratively down, 4470)slarp (administratively down, 4470)...Controller SONET0/3/0/0, ifh 0x04000200 (administratively down)[pic:0x0, intf_flags:0x37]The following sample output from the show im children command with the ifhandle keyword shows when the subinterfaces or other control parent and child summaries are required:
RP/0/0/CPU0:router# show im children ifhandle 0x03000200SONET0/2/0/0, ifh 0x03000200 (administratively down)SonetPath0/2/0/0, ifh 0x03000300 (administratively down)POS0/2/0/0, ifh 0x03000400 (administratively down)When the interfaces are created, use the show interfaces command to examine the state. The following sample output is from the show interfaces command for POS 0/2/0/0:
RP/0/0/CPU0:router# show interfaces POS 0/2/0/0POS0/2/0/0 is up, line protocol is upHardware is Packet over SONETDescription: router4 POS 2\0Internet address is 3.4.5.6/24MTU 4474 bytes, BW 155520 Kbitreliability 25/255, txload Unknown, rxload UnknownEncapsulation HDLC, crc 16, controller loopback not set, keepalive set (10 sec)Last clearing of "show interface" counters never5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec0 packets input, 0 bytes, 0 total input drops0 drops for unrecognized upper-level protocolReceived 0 broadcast packets, 0 multicast packets0 runts, 0 giants, 0 throttles, 0 parity0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort3 packets output, 62 bytes, 0 total output dropsOutput 0 broadcast packets, 0 multicast packets0 output errors, 0 underruns, 0 applique, 0 resets0 output buffer failures, 0 output buffers swapped out0 carrier transitionsThe following sample output from the show interfaces command shows the router summary:
RP/0/0/CPU0:router# show interfaces summaryInterface Type Total UP Down Admin Down-------------- ----- -- ---- ----------ALL TYPES 54 32 1 21--------------IFT_ETHERBUNDLE 1 1 0 0IFT_VLAN_SUBIF 3 3 0 0IFT_POSBUNDLE 1 1 0 0IFT_LOOPBACK 1 1 0 0IFT_NULL 1 1 0 0IFT_SBC 2 2 0 0IFT_POS 20 11 1 8IFT_SERIAL_T3E3 4 0 0 4IFT_GETHERNET 16 8 0 8IFT_ETHERNET 4 4 0 0The following sample output from the show interfaces command shows a per interface summary:
RP/0/0/CPU0:router# show interfaces briefIntf Intf LineP Encap MTU BWName State State Type (byte) (Kbps)--------------------------------------------------------------------------------Nu0 up up Null 1500 UnknownMg0/0/CPU0/0 up up ARPA 1514 100000PO0/2/0/0 up down HDLC 4474 155520PO0/2/0/1 admin-down admin-down HDLC 4474 155520PO0/2/0/2 admin-down admin-down HDLC 4474 155520PO0/2/0/3 admin-down admin-down HDLC 4474 155520PO0/7/0/0 admin-down admin-down HDLC 4474 622080Troubleshooting the Registrations for the Interface Manager
When the interfaces and control nodes are created, various processes want to obtain information that includes the notifications of the state, MTU, and existence.
You can use the show im registrations command to see which clients are registered with the IM. With the exception of the all option, the other options filter the table to show only the rows of a certain type. The location keyword is used to direct the command to a specific IM. The job ID (JID) is used with the show process command to find more information about the client process, or with the show im server activity command with the client-info keyword to find out more about the client connection to the IM.
The following sample output from the show im registrations command shows all the IM registrations:
RP/0/0/CPU0:router# show im registrations allINTERFACE MANAGER REGISTRATIONSReg: C - Create, CH - Child create, D - Delete, M - MTU, O - Owner, S - StateNode JID Context Interface Name or Type Protocol Capsulation RegCH:(parent) type---- ----- --------------- ----------------------- -------- --------------- ---0 189 ipv4_fib_cfg_f IFT_FINT_INTF 0 0 C0 244 pfi_ifh any 0 any C0 102 arp IFT_GETHERNET unknown unknown C0 100 aib any ipv6 ipv6 C0 100 aib any 0 0 C0 102 arp IFT_ETHERNET unknown unknown C0 100 aib FINT0_0_CPU0 ipv6 ipv6 M0 102 arp_ipv4_caps_ MgmtEth0_0_CPU0_0 ipv4 ipv4 S48 148 ipv4_fib_cfg_f IFT_FINT_INTF 0 0 C48 102 arp unknown unknown unknown C48 173 pfi_ifh any 0 any C48 102 arp IFT_GETHERNET unknown unknown C48 101 aib any ipv6 ipv6 C48 101 aib any 0 0 C48 102 arp IFT_ETHERNET unknown unknown C48 50 SONET-0_3_CPU0 (SonetPath0_3_0_3) any any 0 CH48 50 POS- 30 POS0_3_0_3 0 0 S48 50 SONET-0_3_CPU0 POS0_3_0_3 0 0 S48 101 aib FINT0_3_CPU0 ipv6 ipv6 M112 50 di-node0_7_CPU Node0_7_CPU0 0 0 O112 129 ether GigabitEthernet0_7_0_2 ether_s ether_sock O112 129 ether GigabitEthernet0_7_0_2 0 ether O112 129 ether GigabitEthernet0_7_0_1 ether_s ether_sock O112 129 ether GigabitEthernet0_7_0_1 0 ether OThe registered client receives the changes for the IM notifications. If a client appears to be missing notifications, see the possible reasons in Table 3-1.
The following sample output from the show im client command with the notify keyword shows the IM activity notifications:
RP/0/0/CPU0:router# show im client notifyINTERFACE MANAGER ACTIVITY CLIENT-NOTIFY----------------------------------------Context #Notifications Max queued-------------------------------- -------------- ----------pfi_ifh 7 2slr_im_evc 1 1di-node0_0_CPU0-2 4 2Troubleshooting the Interface Manager Distributor
These sections provide information on how to troubleshoot the Interface Manager Distributor (IMD):
•
•
•
•
•
•
Interface Manager Distributor Overview
The IMD is an aggregation service. The following elements are supported:
•
•
•
•
IMD cannot be used to update any information.
Every IMD instance is a copy of other instances, because the same updates are received from every IM. Although the IMD runs on the standby cards, the IMD is not aware of the standby issues; instead, the IMD provides a full copy of all information as if it is on an active card and clients can connect, make registrations, and make queries.
Troubleshooting the Trace Logs for the Interface Manager Distributor
If the problem occurred on the router and affected the IMD, previous information is the most useful. You can use the show imds trace command with the location and file keywords to ensure that the trace logs are recovered from the router for the applicable location.
If there are problems with the connections to the IMD server, use the debug imd client command. For problems with the IMD contents (for example, not synchronized with the IM or with the configuration), use the debug imd imdc command and debug imd collector command. For registrations and notification, use the debug imd filter command and the debug imd notifier command. For show command issues, use the debug imd edm command. For IMD update processing, use the debug imd interface command and the debug imd msg command.
No specific IMD client-side debugging is provided. Because the IMD clients use the IM client library, the same IM client debugging is used.
Troubleshooting the Clients for the Interface Manager Distributor
To use any of the IMD services, a client must be connected. IMD clients who want to register notifications must specify a callback handle. Part of the function of the application programming interface (API) is to pass a unique client context string.
You can use the show imds client command to find out which clients are connected and registered to callback handles, as shown in the following sample output:
Note
RP/0/0/CPU0:router# show imds client location 0/0/CPU0IMD CLIENTSNode: 0x0Internal States---------------State: 0x02 LC_req: 0 LC_res: 12 ID: 0x00Sync: 4 Gather: 0 Resync: 0 Check: 0ClientsName ID Filter Ref Interface Ref----------------------- ---------- ---------- -------------ipv4_arm 0x00000064 1 9ipv6_arm 0x00000065 1 4arp 0x30000009 4 0parser 0x30000012 2 0di-node0_0_CPU0-2 0x30000003 0 0mpls_lsd 0x30000019 0 0ipv6-grp 0x30000018 1 0slr_im_evc 0x30000002 1 0arp_ipv4_caps_reg 0x3000000a 0 1ISIS_207_BaseCaps 0x00000068 2 0ISIS_207_CLNS 0x00000069 2 4ISIS_207_v4/v6 0x0000006a 2 2Troubleshooting the Interface Information for the Interface Manager Distributor
The show imds interface command is used to display the contents of the IMD database. The following sample output from the show imds interface command shows the interface information for the IMD database :
RP/0/0/CPU0:router# show imds interface all location 0/0/CPU0IMDS INTERFACE DATA (Node 0x0)FINT0_0_CPU0 (0x01000000)-----------------------flags: 0x00000007 type: 27 (IFT_FINT_INTF) encap: 91 (fint_base)state: 3 (up) mtu: 8000 protocol count: 9control parent: 0x00000000 data parent: 0x00000000protocol capsulation state mtu--------------- -------------------- --------------- --------0 (Unknown)91 (fint_base) 3 (up) 600018 (lpts)81 (lpts) 3 (up) 60006 (fint_n2n)92 (fint_n2n) 3 (up) 600010 (clns)15 (clns) 3 (up) 600012 (ipv4)26 (ipv4) 2 (down) 030 (ipv4_prero115 (ipv4_preroute) 3 (up) 600013 (mpls)25 (mpls) 3 (up) 600032 (ipv6_prero128 (ipv6_preroute) 3 (up) 600019 (ipv6)90 (ipv6_preswitch) 3 (up) 600082 (ipv6) 3 (up) 6000Null0 (0x01000080)-----------------------flags: 0x000000ab type: 17 (IFT_NULL) encap: 17 (null)state: 3 (up) mtu: 1500 protocol count: 1control parent: 0x00000000 data parent: 0x00000000protocol capsulation state mtu--------------- -------------------- --------------- --------0 (Unknown)17 (null) 3 (up) 1500MgmtEth0_0_CPU0_0 (0x01000100)-----------------------flags: 0x0000002f type: 8 (IFT_ETHERNET) encap: 30 (ether)state: 3 (up) mtu: 1514 protocol count: 4control parent: 0x00000000 data parent: 0x00000000protocol capsulation state mtu--------------- -------------------- --------------- --------0 (Unknown)60 (txm_nopull) 3 (up) 151456 (queue_fifo) 3 (up) 151430 (ether) 3 (up) 151422 (ether_sock98 (ether_sock) 3 (up) 150012 (ipv4)26 (ipv4) 3 (up) 15007 (arp)24 (arp) 3 (up) 1500SONET0_3_0_0 (0x04000200)-----------------------flags: 0x0000006d type: 22 (IFT_SONET) encap: 0 (Unknown)state: 3 (up) mtu: 10000 protocol count: 0control parent: 0x00000000 data parent: 0x00000000SonetPath0_3_0_0 (0x04000300)-----------------------flags: 0x00000005 type: 33 (IFT_SONET_PATH) encap: 0 (Unknown)state: 3 (up) mtu: 10000 protocol count: 0control parent: 0x04000200 data parent: 0x00000000POS0_3_0_0 (0x04000400)-----------------------flags: 0x0000002f type: 19 (IFT_POS) encap: 14 (hdlc)state: 3 (up) mtu: 4474 protocol count: 4control parent: 0x04000300 data parent: 0x00000000protocol capsulation state mtu--------------- -------------------- --------------- --------0 (Unknown)60 (txm_nopull) 3 (up) 447456 (queue_fifo) 3 (up) 447414 (hdlc) 2 (down) 44749 (chdlc)13 (chdlc) 2 (down) 447012 (slarp) 2 (down) 447010 (clns)15 (clns) 2 (down) 447012 (ipv4)26 (ipv4) 2 (down) 4470Troubleshooting the Global Registrations for the Interface Manager Distributor
The show imds registrations command is used to display the information for the IMD client registrations.
IMD supports the concept of an encapsulation change registration so that clients are informed of the changes on an interface.
The following sample output from the show imds registrations command with the all keyword shows all the IMD registrations:
RP/0/0/CPU0:router# show imds registrations all location 0/0/CPU0IMD REGISTRATIONSReg: C - Create, E - Encap, M - MTU, S - StateNode JID Context Interface Name or Type Protocol Capsulation Reg------ ---- --------------- ----------------------- -------- --------------- ---0x0 187 ipv4_arm any ipv4 ipv4 C0x0 198 ipv6_arm any ipv6 ipv6 C0x0 244 parser any 0 0 C0x0 201 ipv6-grp any ipv6 ipv6 C0x0 287 slr_im_evc IFT_OTHER 0 0 C0x0 102 arp IFT_ETHERNET mpls any C0x0 102 arp IFT_GETHERNET mpls any C0x0 102 arp IFT_ETHERBUNDLE mpls any C0x0 102 arp IFT_VLAN_SUBIF mpls any C0x0 207 ISIS_207_BaseC POS0_3_0_0 0 any C0x0 207 ISIS_207_CLNS 0 clns clns C0x0 207 ISIS_207_v4/v6 0 ipv4 ipv4 C0x0 207 ISIS_207_CLNS 0 clns clns C0x0 207 ISIS_207_v4/v6 0 ipv4 ipv4 C0x0 244 parser E0x0 187 ipv4_arm FINT0_0_CPU0 ipv4 ipv4 S0x0 198 ipv6_arm FINT0_0_CPU0 ipv6 ipv6 S0x0 187 ipv4_arm MgmtEth0_0_CPU0_0 ipv4 ipv4 S0x0 102 arp_ipv4_caps_ MgmtEth0_0_CPU0_0 ipv4 ipv4 S0x0 187 ipv4_arm FINT0_3_CPU0 ipv4 ipv4 S0x0 198 ipv6_arm FINT0_3_CPU0 ipv6 ipv6 S0x0 207 ISIS_207_CLNS POS0_3_0_0 clns clns M0x0 207 ISIS_207_CLNS POS0_3_0_0 clns clns S0x0 187 ipv4_arm POS0_3_0_0 ipv4 ipv4 S0x0 207 ISIS_207_v4/v6 POS0_3_0_0 ipv4 ipv4 SThe following sample output from the show imds registrations command shows how the context keyword is useful for a particular client callback:
RP/0/0/CPU0:router# show imds registrations context ipv4_connected allIMD REGISTRATIONSContext: ipv4_connectedNode JID Interface Name or Type Protocol Capsulation Reg------ ----- ----------------------- -------- --------------- -------0x0 0 any ipv4 ipv4 Create0x0 0 any 0 0 Create0x0 0 MgmtEth0/0/CPU0/0 ipv4 ipv4 State0x0 0 GigabitEthernet0/7/0/0 ipv4 ipv4 State0x0 0 GigabitEthernet0/7/0/1 ipv4 ipv4 State0x0 0 GigabitEthernet0/7/0/2 ipv4 ipv4 StateTroubleshooting the Rules for the Interface Manager Distributor
The show imds rules command is used to display information for the IMD rules, which is a summary of basic information cached in the IMD. The show commands for the IM are used to display detailed data information on the rules.
