Ensuring the ELANs Are Functional between the Source and the Destination
If you configure the ELANs correctly, you should be able to ping each of the interfaces for each MPS and NHS along the default path between the source and destination client. If not, you either configured the ELAN incorrectly, you have a Layer 3 issue such as a bad IP address, or you have some routing protocol issues.
Examine your intra-ELAN connectivity first. See if you can ping the neighbor device(s) within the ELAN. If you can, ping the next device in the next ELAN, either from your current device or from the next hop component within your ELAN. Do this along each ELAN to ensure that each ELAN is completely functional.
Also ensure that each LEC bound to an MPOA device acquired an elan-id as demonstrated in the Catalyst output of Example 10-3.
Determining That All MPCs and MPSs Are Functional
Check the configuration results of the MPC and MPS with the show mpoa client and show mpoa server commands. Each command should provide you with basic information such as name of the device, the interface where it is enabled, and the current state (up or down).
Determining That MPCs and MPSs Discovered Each Other
Each MPOA device attempts to discover its MPOA neighbors through the ELAN’s LES. MPOA has a neighbor discovery protocol enabling MPCs to discover MPSs, and for MPSs to discover other MPSs. Output from the show mpoa client and show mpoa server commands verify if the device knows any neighbors. The MPS and MPC discover each other by registering their device type values with the LES of their local ELAN. They then send an inquiry to the LES to discover the neighbor devices.
Determining If the Threshold Is Crossed at the MPC to Initiate an MPOA Resolution Request
MPOA defines a default value of 10 frames over 1 second as a threshold for an MPC to trigger a resolution request. If the traffic type never exceeds the configured threshold, the MPC never attempts to establish a shortcut to the egress MPC. You can get an indication if the client even issued a resolution request with the show mpoa client cache command. Example 10-17 shows client statistics for an MPC, and shows that it issued and received an MPOA resolution request and reply.
Example 10-17 An MPOA Client Statistics Screen
Cat-A#sh mp cl statistics MPC Name: mpc2, Interface: ATM1/0, State: Up MPC actual operating address: 47.009181000000009092BF7401.0090AB16A80D.00 Shortcut-Setup Count: 10, Shortcut-Setup Time: 1 Transmitted Received MPOA Resolution Requests 1 0 MPOA Resolution Replies 0 1 MPOA Cache Imposition Requests 0 1 MPOA Cache Imposition Replies 1 0 MPOA Cache Purge Requests 0 0 MPOA Cache Purge Replies 0 0 MPOA Trigger Request 0 0 NHRP Purge Requests 0 0 Invalid MPOA Data Packets Received: 0 Cat-A#
If the resolution request counter does not increment, the MPC does not see interesting traffic to trigger a request to an MPS. If the resolution request counter increments, but the resolution reply counter does not match the request counter, the MPC did not receive a reply to its request. When this happens, ensure that the MPSs are operational. Also check that a default path actually exists to the egress MPC. If the default path does not exist, the MPS cannot resolve a shortcut.
Another method of examining the MPC behavior uses debug. The debug mpoa client command provides an opportunity to track how the MPC monitors a potential flow and to determine if the MPC actually triggers an MPOA resolution request. Example 10-18 shows an abbreviated debug output from an MPC.
Example 10-18 Sample debug mpoa client Command Output
Cat-A#debug mp cl ? all Enable all MPOA Client debugging data Debugs MPOA Client Data Processing egress Debugs MPOA Client Egress Activity general Debugs MPOA Client General/Common Activity ingress Debugs MPOA Client Ingress Activity keep-alives Debugs keep-alives received from MPOA servers platform-specific Hardware platform specific debug Cat-A#debug mp cl all … … MPOA CLIENT: mpc_trigger_from_lane: mac 0090.ab16.5008 on out ATM0.20 MPOA CLIENT: Is MAC 0090.ab16.5008 interesting on i/f: ATM0.20 MPOA CLIENT MPC: MAC 0090.ab16.5008 interesting MPOA CLIENT: lower levels detected 1 packets to 0090.ab16.5008 (3.0.0.1) MPOA CLIENT MPC: mpc_ingress_cache_state_machie called for icache 3.0.0.1: current state: INIT, event MPC_ELIGIBLE_PACKET_RECEIVED MPOA CLIENT: mpc_count_and_trigger: cache state INIT MPOA CLIENT: mpc_trigger_from_lane: mac 0090.ab16.5008 on out ATM0.20 MPOA CLIENT: Is MAC 0090.ab16.5008 interesting on i/f: ATM0.20 MPOA CLIENT MPC: MAC 0090.ab16.5008 interesting MPOA CLIENT: lower levels detected 1 packets to 0090.ab16.5008 (3.0.0.1) MPOA CLIENT MPC: mpc_ingress_cache_state_machine called for icache 3.0.0.1: current state: INIT, event MPC_FLOW_DETECTED MPOA CLIENT MPC: MPOA Resolution process started for 3.0.0.1 MPOA CLIENT MPC: Sending MPOA Resol. req(ReqId=2) for 3.0.0.1 MPOA CLIENT: mpc_count_and_trigger: cache state TRIG
The first two highlighted portions of the output illustrate where the MPC recognized what is called interesting traffic. Interesting traffic targets a host in another ELAN. Therefore, the source and destination Layer 3 addresses differ. But the destination MAC address targets a neighbor ingress MPS. Why does it see a MAC address for the MPS? The MPC sees a MAC address for the MPS because this is the first router in the default path. The MPC puts the first hop router’s MAC address in the data link header. The two highlighted statements are for frames 9 and 10 within the configured one-second period (the first eight frames were removed for simplicity). There is no indication of the frame count, so you might need to sort through the debug output to see if at least ten frames were seen. Because there are ten frames per second, the MPC triggers a resolution request to the ingress MPS. This is shown in the third highlighted area of Example 10-18.
Eventually, the MPC should receive a resolution reply from the MPS as shown in Example 10-19.
Example 10-19 MPOA Resolution Reply from debug
MPOA CLIENT: received a MPOA_RESOLUTION_REPLY packet of size 127 bytes on ATM1/0 vcd 832 dumping nhrp packet: fixed part: op_type 135 (MPOA_RESOLUTION_REPLY), shtl 20, sstl 0 mandatory part: src_proto_len 4, dst_proto_len 4, flags 0, request_id 2 src_nbma_addr: 47.009181000001000200030099.0090AB16540D.00 src_prot_addr: 0.0.0.0 dst_prot_addr: 3.0.0.1 cie 0: code 0, prefix_length 0, mtu 1500, holding_time 1200 cli_addr_tl 20, cli_saddr_tl 0, cli_proto_len 0, preference 0 cli_nbma_addr: 47.009181000001000200030099.0090AB164C0D.00 tlv 0: type 4097, length 4 data: 15 05 00 01 tlv 1: type 4096, length 23 compulsory data: 00 00 00 01 00 00 00 67 0E 00 90 AB 16 4C 08 00 90 AB 16 B0 08 08 00 MPOA CLIENT MPC: Resol Reply- IP addr 3.0.0.1, mpxp addr=47.00918100000100020003 0099.0090AB164C0D.00, TAG=352649217 MPOA CLIENT MPC: mpc_ingress_cache_state_machine called for icache 3.0.0.1: current state: TRIG, event MPC_VALID_RESOL_REPLY_RECVD
The middle portion of the debug output displays various items from the MPOA resolution reply messages. For example, cie refers to a client information element as specified by MPOA. code 0 means that the operation was successful. Reference the MPOA documents for decode specifics. The important parts of the debug for the immediate purposes of troubleshooting are highlighted.
Ensuring That the MPS and NHS Components ARE Functional
Check along the default path and ensure that all MPOA server related devices found each other and can communicate over LANE. Without functional pieces, MPOA cannot resolve a shortcut.
Other Causes of MPOA Failures
One other event can prevent a shortcut from getting established. When the ingress MPC issues the resolution request, the request gets forwarded to the egress MPS. The egress MPS issues a cache imposition request to the egress MPC. If the egress MPC cannot accept a cache imposition, it rejects the imposition request forcing the ingress MPC to continue to use the default paths.
The egress MPC can reject the imposition whenever its local resources prevent it from doing so. For example, the egress MPC might not have enough memory resources to hold another cache entry. It might be that the egress MPC already has too many virtual circuits established and cannot support another circuit. Any of these can cause the egress MPC to reject the imposition preventing a shortcut from getting established.
If you use the MPC debug, you should see a line like that shown at the end of Example 10-19 to confirm that the cache imposition worked successfully.