Ensuring the ELANs Are Functional between the Source and the Destination

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_machine 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.