Config Router

  • Google Sheets
  • CCNA Online training
    • CCNA
  • CISCO Lab Guides
    • CCNA Security Lab Manual With Solutions
    • CCNP Route Lab Manual with Solutions
    • CCNP Switch Lab Manual with Solutions
  • Juniper
  • Linux
  • DevOps Tutorials
  • Python Array
You are here: Home / Cisco / Ensuring the ELANs Are Functional between the Source and the Destination

Ensuring the ELANs Are Functional between the Source and the Destination

March 17, 2020 by Scott

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.

  • Cisco LAN Switching Study Guide

Related

Filed Under: Cisco Tagged With: Determining That All MPCs and MPSs Are Functional, Determining That MPCs and MPSs Discovered Each Other, Other Causes of MPOA Failures

Recent Posts

  • How do I give user access to Jenkins?
  • What is docker volume command?
  • What is the date format in Unix?
  • What is the difference between ARG and ENV Docker?
  • What is rsync command Linux?
  • How to Add Music to Snapchat 2021 Android? | How to Search, Add, Share Songs on Snapchat Story?
  • How to Enable Snapchat Notifications for Android & iPhone? | Steps to Turn on Snapchat Bitmoji Notification
  • Easy Methods to Fix Snapchat Camera Not Working Black Screen Issue | Reasons & Troubleshooting Tips to Solve Snapchat Camera Problems
  • Detailed Procedure for How to Update Snapchat on iOS 14 for Free
  • What is Snapchat Spotlight Feature? How to Make a Spotlight on Snapchat?
  • Snapchat Hack Tutorial 2021: Can I hack a Snapchat Account without them knowing?

Copyright © 2025 · News Pro Theme on Genesis Framework · WordPress · Log in