Description

It was noticed that when unknown unicast frames are received, the Source MAC is learned on the Local PFE.  The local PFE updates all the Remote PFE's of the same. But, the Source MAC learned by the Remote PFE's ages out after 5 minutes of inactivity.

Symptoms

Customer has a simple VPLS Routing-instance with two interfaces on different slots/PFEs:

 

601 {

instance-type vpls;

protocols {

vpls {

encapsulation-type ethernet;

vpls-id 601;

}

}

vlan-id none;

interface xe-0/0/0:2.601;

interface et-1/1/0.601;

}

They have two hosts connected to the VPLS instance 601 (BD index 15) in the following manner:

 

00:00:5E:00:53:aa: xe-0/0/0:2.601 (FPC0/PFE0)

00:00:5E:00:53:bb: et-1/1/0.601 (FPC1/PFE2)

 

In this state,when the MAC address table for the BD index 15 is empty, they constantly send unknown-unicast (UU) traffic from MAC 00:00:5E:00:53:aa to a non-existing MAC 00:00:5E:00:53:fe.   This forces the MAC address 00:00:5E:00:53:aa to be learned and refreshed in its "home", FPC0/PFE0 and be learned at FPC1/PFE2 facing the host with the MAC 00:00:5E:00:53:bb.

 

On the local PFE0, the age for Local MAC 00:00:5E:00:53:aa is always set to 0 as it is receiving continuous stream of traffic with source MAC of 00:00:5E:00:53:aa.  However, on the Remote PFE 1, the MAC entry is not refreshed, slowly ages, and reaches the max age of 300.  At that point, it gets removed from the remote PFE 1.

 

Solution

As per Engineering, this is expected behavior.  MAC addresses installed on other PFEs referred to as "Remote MACs" or DMACs will age out after 5 minutes of inactivity.

However, DMAC aging on a PFE will be prevented if that MAC is actively being referenced or "used" by another traffic stream in that PFE.

Even if the MAC is aged out in the remote PFE, when the remote PFE gets a packet with destination MAC of 00:00:5E:00:53:aa, it will sends MLP  Query to other PFE's to see if the destination MAC is present anywhere. The PFE who owns the MAC will then respond back and the traffic will be unicast after that.

Modification History

2026-03-13 : Article Created