ASR9k L2 Bridge Problem

[ez9]

Hello,

I have a case where i want to put clients in a different bridge domain based on their (source) MAC-address. In each bridge domain I have the l2 intefaces of each client and also an l2 subinterface of the router acting as the default gateway. When I have one client in the bridge domain with the subinteface of the default gateway everything working as expected. When I am trying to insert in the bridge domain one more client the communication is stopping working. The bridge domain during this situation have the MAC addresses learned in its MAC table. Any insights on this issue? The configuration is the following:

interface Bundle-Ether50.980 l2transport
description *** Gateway ***
encapsulation dot1q 927 second-dot1q 650
rewrite ingress tag translate 2-to-2 dot1q 1400 second-dot1q 1800 symmetric

interface Bundle-Ether50.981 l2transport
description *** Client 1 ***
encapsulation dot1q 1400 second-dot1q 1800 ingress source-mac xxxx.yyyy.zzzz
rewrite ingress tag translate 2-to-2 dot1q 927 second-dot1q 650 symmetric

interface Bundle-Ether50.982 l2transport
description *** Client 2 ***
encapsulation dot1q 1400 second-dot1q 1800 ingress source-mac yyyy.xxxx.zzzz
rewrite ingress tag translate 2-to-2 dot1q 927 second-dot1q 650 symmetric

l2vpn
bridge group TEST_BG

bridge-domain BD_1400
interface Bundle-Ether50.980
!
interface Bundle-Ether50.981
!
interface Bundle-Ether50.982

show l2vpn forwarding bridge-domain TEST_BG:BD_1400 mac-address location 0/0/CPU0

To Resynchronize MAC table from the Network Processors, use the command...
l2vpn resynchronize forwarding mac-address-table location <r/s/i>

Mac Address Type Learned from/Filtered on LC learned Resync Age/Last Change Mapped to
-------------- ------- --------------------------- ---------- ---------------------- --------------
xxxx.yyyy.zzzz dynamic BE50.981 N/A 02 Sep 21:37:07 N/A (client 1)
yyyy.xxxx.zzzz dynamic BE50.982 N/A 02 Sep 21:36:07 N/A (client 2)

zzzz.xxxx.yyyy dynamic BE50.980 N/A 02 Sep 21:36:07 N/A (gateway)

[MHM Cisco World]

interface Bundle-Ether50.980 l2transport
description *** Gateway ***
encapsulation dot1q 927 second-dot1q 650
rewrite ingress tag translate 2-to-2 dot1q 1400 second-dot1q 1800 symmetric

interface Bundle-Ether50.981 l2transport
description *** Client 1 ***
encapsulation dot1q 1400 second-dot1q 1800 ingress source-mac xxxx.yyyy.zzzz
rewrite ingress tag translate 2-to-2 dot1q 927 second-dot1q 650 symmetric

Why the encapsulate is different? 

Bridge domain must share same vlan tag 

MHM

[ez9]

I am trying to achive the following:

My clients are behind q-in-q (outer vlan 1400, inner vlan 1800). The router (default gateway) is also behind q-in-q (outer vlan 927, inner vlan 650). So, I made these translations to achive the communication between client and router. Adding one client in the bridge domain the communication between client and gateway is OK. So, I suppose the VLANs translations are OK. I have a trunk link on a Nexus switch to Bundle-Ether50 passing VLANS 1400, 927

[MHM Cisco World]

Friend there are encap and rewrite 

So you config two interface differently?

MHM

[ez9]

So, based on your experience is it a wrong configuration? I thought that using this config a frame that coming with the vlan stack of 1400, 1800 is going to translate to 927, 650 so it will be reachable from the gateway. In the other way the mac address of the gateway coming with vlan stack 927, 650 is going to translate to 1400, 1800 so this mac will be reachable from the clients. Is this a wrong thought? Can I implement this with a different way?

[nkarpysh]

Try:

rewrite ingress tag pop 2 symmetric 

 instead on all interfaces. That should strip both tag when packet enters the bridge domain and on egress it should symmetrically push two tags based on interfaces encap.

[MHM Cisco World]

Can ypu draw simple topolgy 

Thanks 

MHM

[ez9]

Hello,

Thank you for your help. In my case the solution was the command "split-horizon group" in the member subinterfaces in the bridge domain configuration (except subinterface with the default gateway). I suppose there was some kind o loop in my topology and the "split-horizon" solved it.

[MHM Cisco World]

Friend 

Thanks so so much for update us

Have a nice day

MHM