
VPLS Unicast Flooding
Unicast flooding problems, usually associated with switched networks, can also impact VPLS.
If traffic is forwarded asymmetrically through a VPLS instance, unicast flooding of unknown frames can occur. I’ll step through a scenario where this could happen.
I set a LAB up with two CSR 1000V routers acting as PE routers, providing a VPLS instance. GNS3 was used to run the IOS routers acting as CE and C routers.
In this scenario we could imagine that CE3 and CE4 are Internet routers, they run HSRP on the VPLS facing interfaces for redundancy. CE3 is the Active HSRP device with a HSRP address of 10.0.0.5. On the Internet side of CE3 and CE4 would typically be a BGP connection, although we use static routes in our scenario to easily cause asymmetric routing. With regular BGP connections to an ISP, it’s easy to imagine how asymmetric forwarding could arise.
CE1 and CE2 have static default routes pointing to the HSRP address to provide connectivity. CE3 points to C1 for the address 4.2.2.2. C1 has a static route for 10.0.0.0/24 pointing to CE4 to cause asymmetric routing.
This configuration forces traffic from / to CE1 (10.0.0.1) to 4.2.2.2 to be forwarded in the following direction.
This initially works fine. Looking at the MAC address table associated with the bridge domain connected to the VPLS instance on PE2, we can see that an entry for CE1 (CA02.02A0.0008) exists. Any traffic PE2 receives from CE4 destined for CE1 is forwarded across the pseudowire towards the neighbouring PE1 router.
PE2#show bridge-domain 200
Bridge-domain 200 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 20
GigabitEthernet3 service instance 20
vfi LAB neighbor 172.16.0.1 300
MAC address Policy Tag Age Pseudoport
0000.0C07.AC01 forward dynamic 297 LAB.1001010
CA02.02A0.0008 forward dynamic 252 LAB.1001010
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe8e8bc00
CA00.016C.0008 forward dynamic 300 GigabitEthernet2.EFP20
CA01.01F9.0008 forward dynamic 253 LAB.1001010
CA02.016C.0008 forward dynamic 253 GigabitEthernet3.EFP20
In order to test for any flooding, we set up an access list egress on the PE2 to CE2 link.
We then send 100 pings from CE1 to 4.2.2.2.
CE1#ping 4.2.2.2 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 16/40/172 ms
The ICMP echo reply packets are routed back asymmetrically via PE2, the icmptest ACL does not increment and the unicast ICMP packets are not flooded out of the PE2 to CE2 link.
PE2#show access-lists
Extended IP access list icmptest
10 permit icmp any any
20 permit ip any any (3881 matches)
By default, the MAC address entries are only in place for 300 seconds. As with a switch, this is updated based on the source address of frames received by the PE router.
As traffic is being forwarded asymmetrically and no communication occurs between CE1 and CE2, PE2 does not receive any frames to update the MAC address entry for CE1 (CA02.02A0.0008).
We see that the timer for the CE1 (CA02.02A0.0008) entry is decremented.
PE2#show bridge-domain 200
Bridge-domain 200 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 20
GigabitEthernet3 service instance 20
vfi LAB neighbor 172.16.0.1 300
MAC address Policy Tag Age Pseudoport
0000.0C07.AC01 forward dynamic 299 LAB.1001010
CA02.02A0.0008 forward dynamic 3 LAB.1001010
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe8e8bc00
CA00.016C.0008 forward dynamic 298 GigabitEthernet2.EFP20
CA01.01F9.0008 forward dynamic 238 LAB.1001010
CA02.016C.0008 forward dynamic 238 GigabitEthernet3.EFP20
It then times out and is removed.
PE2#show bridge-domain 200
Bridge-domain 200 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 20
GigabitEthernet3 service instance 20
vfi LAB neighbor 172.16.0.1 300
MAC address Policy Tag Age Pseudoport
0000.0C07.AC01 forward dynamic 298 LAB.1001010
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe8e8bc00
CA00.016C.0008 forward dynamic 300 GigabitEthernet2.EFP20
CA01.01F9.0008 forward dynamic 229 LAB.1001010
CA02.016C.0008 forward dynamic 229 GigabitEthernet3.EFP20
This results in a problem where traffic being received be PE2, destined for CE1 has no entry in the MAC address table of PE2. The frames are therefore flooded by PE2.
To prove that the frames are being flooded, 100 more echo requests are sent to 4.2.2.2.
CE1#ping 4.2.2.2 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 12/59/288 ms
The asymmetrically forwarded echo reply packets can now be seen on the ACL on the PE2 to CE2 link.
PE2#show access-lists
Extended IP access list icmptest
10 permit icmp any any (100 matches)
20 permit ip any any (4114 matches)
Needless to say, this is at best very inefficient. Bandwidth on all links connected to this VPLS instance on PE2 is wasted.
If we generate any traffic from CE1 that reaches PE2 directly across the VPLS instance, the problem is resolved for a further 300 seconds.
A permanent solution can be put in place by lowering the ARP timeout on the VPLS facing interface on CE4 (although it would be recommended to apply on CE3 VPLS interface too).
Lowering the ARP timeout to 300 seconds on CE4 causes CE4 to send out an ARP request for any IP addresses is it forwarding traffic towards before it’s 300 second timer expires. The ARP reply that comes from CE1 towards CE4 causes the MAC address table on PE2 to be updated, preventing unicast flooding of frames destined for CE1.
Configuration applied as follows.
CE4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CE4(config)#int fa0/0
CE4(config-if)#arp timeout 300
We see the MAC address entry timeout for CE1 decrement down to 89 seconds.
PE2#show bridge-domain 200
Bridge-domain 200 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 20
GigabitEthernet3 service instance 20
vfi LAB neighbor 172.16.0.1 300
MAC address Policy Tag Age Pseudoport
0000.0C07.AC01 forward dynamic 299 LAB.1001010
CA02.02A0.0008 forward dynamic 89 LAB.1001010
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe8e8bc00
CA00.016C.0008 forward dynamic 300 GigabitEthernet2.EFP20
CA01.01F9.0008 forward dynamic 246 LAB.1001010
CA02.016C.0008 forward dynamic 278 GigabitEthernet3.EFP20
An ARP request and reply is then exchanged between CE4 and CE1, and the timer is renewed.
PE2#show bridge-domain 200
Bridge-domain 200 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 20
GigabitEthernet3 service instance 20
vfi LAB neighbor 172.16.0.1 300
MAC address Policy Tag Age Pseudoport
0000.0C07.AC01 forward dynamic 299 LAB.1001010
CA02.02A0.0008 forward dynamic 300 LAB.1001010
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe8e8bc00
CA00.016C.0008 forward dynamic 300 GigabitEthernet2.EFP20
CA01.01F9.0008 forward dynamic 245 LAB.1001010
CA02.016C.0008 forward dynamic 277 GigabitEthernet3.EFP20
When thousands of ICMP messages are sent to 4.2.2.2 from CE1, the icmptest ACL shows no unicast flooding.
PE2#show access-lists
Extended IP access list icmptest
10 permit icmp any any
20 permit ip any any (179 matches)