Knowledge Center Search


 

[MX] Troubleshoot MAC Address Learning (Data Plane)

  [KB25027] Show KB Properties

  [KB25027] Hide KB Properties

Categories:
Knowledge Base ID: KB25027
Last Updated: 25 Jun 2012
Version: 1.0

Summary:

This article provides a step-by-step procedure to troubleshoot generic Virtual Private LAN Service (VPLS) MAC address learning issues.

This article is called from the KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data.



Problem or Goal:

Goal:

To troubleshoot VPLS MAC address learning issues.


Symptoms:

  • Cannot see MAC entries for local CE devices on the local PE router

  • Cannot see MAC entries for remote CE devices on the local PE router

  • The output of 'show route forwarding-table family vpls' or 'show vpls mac-table' on the PE do not show the MAC entries for the local or remote CE devices.
         

    Example output (working):

    User@host# run show route forwarding-table family vpls    
    Routing table: VPLS_INSTANCE.vpls             
    VPLS:
    Destination        Type RtRef Next hop          Type Index NhRef Netif
    default            dynm     0                   flood   293     1
    default            perm     0                   dscd   280     1
    


    Example output:

    user@host-re0> show vpls mac-table      
                                 <---it does not return values
    user@host-re0> 
    


If you are having issues with the VPLS connection between PE’s, then go to KB25025 - Resolution Guide - MX - VPLS Troubleshooting (Control Plane) - Connection not listed or down.


Cause:
 

Solution:

Perform the following steps:


Note: While these troubleshooting steps can be applied for all code versions and all platforms, this troubleshooting guide is written primarily keeping MX platform in mind.


Step 1. Confirm you have initiated traffic from CE to remote CE, so that the PEs will learn or attempt to learn the MAC addresses.



Step 2.  Verify if VLAN encapsulations are used on the CE facing interface of the interested PE routers. To do this, enter the ‘show interfaces ge-X/Y/Z unit n’ command.

Example output:

user@host# show interfaces ge-3/0/6
vlan-tagging;
encapsulation vlan-vpls;  <<<<<
unit 0 {
    encapsulation vlan-vpls; <<<<<
    vlan-id 512;
    family vpls;
}

Is VLAN encapsulation configured on the CE facing interface?

  • Yes - Continue to Step 3
  • No - Jump to Step 5


Step 3.  If VLAN stacking or VLAN normalization is done on the interested PE routers, then verify the configuration. 

Example configuration:

VPLS-1 {
 interfaces {
   ge-0/0/0 {
     unit 3 {
       encapsulation vlan-vpls;
       vlan-id 3;  <<<<<<<<<<<<<
     }
   }
}
routing-instances {
  VPLS-1 {
    instance-type vpls;
    vlan-tags outer 2 inner 1; <<<<<<<<<<<<<<<
    route-distinguisher 10.0.0.3:1000;
    vrf-target target:1000:1000;
    protocols {
       vpls {
         no-tunnel-services;
         site 3 {
           site-identifier 3;
         }
       }
    }
}

In the example above, interface ge-0/0/0.3 (link facing CE) has a VLAN-ID (outer tag) of 3. Also in the routing-instance, VLAN Normalization (aka VLAN Translation) is configured where in we are normalizing the VLAN tags on the core by pushing 2 as outer VLAN and swapping VLAN 3 with 1 as the inner VLAN before the frame is sent across the core.

If VLAN manipulation techniques are applied on the PE routers, verify if correct VLAN tags are applied on the frames going to CE for push or pop operations. So when we are configuring VLAN Normalization care should be taken as to the correct VLAN tags are applied. Any mis-configuration may lead to frames getting dropped which may prevent PE routers from learning MAC addresses of the CE devices. For more information on VLAN translation go to http://www.juniper.net/techpubs/software/junos/junos95/mx-solutions-guide/id-10687204.html

If VLAN translation is not done on the PE routers but VLAN encapsulation is still used, then make sure the VLAN ID’s are identical on both the CE facing interfaces of the interested PE router. If they are non-identical and if a frame is sent across from a local CE, it will be dropped on the remote PE device as it doesn't have any sites configured for that VLAN.

Continue to Step 4.



Step 4.  Identify which MAC address is not learned on the interested PE router.  Is it the local CE MAC address or that for the remote CE device?

  •  Remote CE device - Continue to Step 5
  •  Local CE device - Jump to Step 6



Step 5.  If the MAC address for the remote CE device is not learned on the interested PE router, then verify that packets are hitting the local PE router from the remote CE by applying a filter and monitoring the count.  The filter should look something like the following:

user@PE> show configuration firewall family vpls filter vpls     
term 1 {
    from {
        source-mac-address {
            00:00:00:09:00:06/48;
        }
    }
    then {
        count local_CE_count;
        accept;
    }
}
term 2 {
    from {
        source-mac-address {
            00:00:00:10:00:06/48;
        }
    }
    then {
        count REMOTE_CE_count;
        accept;
    }
}

In the above configuration under term2, the MAC address is for the remote CE device and the counter REMOTE_CE_count is incremented whenever frames from the remote CE hit the local PE.

Apply this filter under forwarding options inside the routing-instance on the PE router.

user@PE> show configuration routing-instances VPLS_INSTANCE forwarding-options family vpls {  
    filter {
        input vpls;
    }
}

Now initiate traffic from CE-CE again.
If the count for ‘REMOTE_CE_count’ increases then that verifies that traffic is hitting the local PE, but the router is unable to learn the MAC address.

To correct this issue, during a maintenance window, try to deactivate/activate the routing instance of the affected PE, so as to bounce the VPLS connection with the remote PE route.
Now Initiate traffic between the CE's again, and see if we the PE router learns the MAC address for the remote CE, if not then enable traceoptions for the l2learning on the local PE router and see if MAC learning is happening or not.

Example traceoptions config:
# show protocols
l2-learning {
    traceoptions {
        file l2ald-trace size 100m;
        flag mac-learning;
        flag ipc;
        flag routing-socket;
    }
}

If the issue is still not resolved, jump to Step 7.



Step 6. If the MAC address for the local CE device is not learned on the interested PE router, then verify that packets are hitting the local PE router from the local CE by applying a filter and monitoring the count.  The filter should look something like the following:

user@PE> show configuration firewall family vpls filter vpls
term 1 {
    from {
        source-mac-address {
            00:00:00:09:00:06/48;
        }
    }
    then {
        count LOCAL_CE_count;
        accept;
    }
}
term 2 {
    from {
        source-mac-address {
            00:00:00:10:00:06/48;
        }
    }
    then {
        count REMOTE_CE_count;
        accept;
    }
}

In the above configuration under term 1, the MAC address is for the local CE device and the counter LOCAL_CE_count is incremented whenever frames from the remote CE hit the local PE.

Apply this filter under forwarding options inside the routing-instance on the PE router.

user@PE1> show configuration routing-instances VPLS_INSTANCE forwarding-options family vpls {  
    filter {
        input vpls;
    }
  }   
Initiate traffic from CE to CE again. If the count for ‘LOCAL_CE_count’ increases then that verifies that traffic is hitting the local PE, but the router is enable to learn the MAC address.

To correct the issue try the following during a maintenance window:
  1. Flush the ARP table entries on the PE by doing ‘clear arp host-name| MAC-ADDand
  2. Deactivate/activate the CE facing IFL (logical interface towards CE) on the PE, so as to re-initialize MAC learning.      

Initiate traffic from CE to CE again and verify If MAC addresses are learned on the local PE. If not, then enable traceoptions for the L2 learning on the local PE router and see if MAC learning is happening or not.

Example traceoptions config:
# show protocols
l2-learning {
    traceoptions {
        file l2ald-trace size 100m;
        flag mac-learning;
        flag ipc;
        flag routing-socket;
    }
}

If the issue is still not resolved, continue to Step 7.



Step 7.  As a final step to resolve the issue do the following:
  • Verify if there are any logs in Syslog messages with MAC MOVE NOTIFICATION as key words.  Generally when there is configuration mistake or when there is topology change which results in the local router from learning a MAC address on a different routing-instance or on a different interface, we see this log. To correct this, look into any config changes done recently or any topology change that resulted in the MAC not learned on the correct routing-instance.


If the VPLS issue is still not resolved, collect the logs/information in the KB22637 - [M, MX, T Routers] Data Collection Checklist under the 'VPLS' section, and open a case with your technical support representative.



Purpose:
Troubleshooting

Related Links:

 

 

ASK THE KB

Question or KB ID:


 


 

 
Copyright© 1999-2012 Juniper Networks, Inc. All rights reserved.