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

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

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

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.

• Cisco LAN Switching Study Guide