04-22-2021 12:14 PM
Hi Cisco folks,
I’m a L3 guy who’s been asked to modify a couple of L2 devices. I need to connect some client hosts to two different switches, and I think I’m misunderstanding how my VLANs traverse the bundle-Ethernet topology.
For the sake of simplicity, let’s say I have the below topology:
(Bundle) +----------+ (Bundle) +----------+ (Bundle) Client A ===========| Switch A |================| Switch B |============= Client B +----------+ +----------+
…where Switches A and B are strictly L2 devices, running IOS XR 6.6.12. There’s already a bundle-Ethernet configured between the two of them. Currently, the switch-to-switch bundle interfaces are configured thusly:
Switch A: Switch B: ---------------------------------------- ---------------------------------------- interface Bundle-Ether3 interface Bundle-Ether3 mtu 9192 mtu 9192 dampening dampening ! ! interface Bundle-Ether3.2300 l2transport interface Bundle-Ether3.2300 l2transport encapsulation dot1q 2300 second-dot1q 23 encapsulation dot1q 2300 second-dot1q 23 ! !
(I’m omitting a few things here like service-policies and load-intervals and logging events and whatnot.) If I’m reading this config correctly only traffic on VLAN 2300 can traverse the bundle, although the switches are using VLAN 23 as an inner VLAN. Perhaps this is Q-in-Q tagging?
All of the above was configured by another engineer (who has since left our company) and it works great. Now for the parts of the switches’ configs that I’ve modified:
I now need Clients A and B to be able to exchange traffic. They connect to their respective switches using Bundle-Ethernet interfaces, too. I cloned the configurations of other interfaces going to other client hosts:
Switch A: Switch B: ---------------------------------------- ---------------------------------------- interface Bundle-Ether500 interface Bundle-Ether10 description to Client A description to Client B mtu 9192 mtu 9192 dampening dampening ! ! interface Bundle-Ether500.2300 l2transport interface Bundle-Ether10.2300 l2transport encapsulation dot1q 201 encapsulation dot1q 201 rewrite ingress tag push dot1q 2300 symmetric rewrite ingress tag push dot1q 2300 symmetric ! !
I don’t fully understand what these configs are doing, but like I said, its how all other client hosts connect to these switches. I think – but am not certain – that the end clients must send traffic on VLAN 201. Once that traffic is received by the switches, the switch rewrites the VLAN from 201 to 2300. This is necessary, I guess, because only VLAN 2300 can go across the bundle.
Finally, I use a l2vpn xconnect to “tie” the bundle subinterfaces together:
Switch A: Switch B: ---------------------------------------- ---------------------------------------- l2vpn l2vpn xconnect group myGroup xconnect group myGroup p2p myGroup1 p2p myGroup1 interface Bundle-Ether3.2300 interface Bundle-Ether3.2300 interface Bundle-Ether500.2300 interface Bundle-Ether10.2300 ! ! ! ! ! !
That’s it. I’ve been pouring over TAC documentation, and my switch’s configurations, and I think this should work. And yet, Clients A and B cannot ping one another.
When I have the clients send bidirectional test traffic on VLAN 201, I see this on the switches:
Switch_A# Switch_A# ! To Client A: Switch_A# show int Bundle-Ether 500 | inc rate 30 second input rate 810503000 bits/sec, 817040 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec Switch_A# ! To Switch_B: Switch_A# show int Bundle-Ether 3 | inc rate 30 second input rate 848325000 bits/sec, 828444 packets/sec 30 second output rate 850379000 bits/sec, 830449 packets/sec Switch_A# Switch_B# ! To Client B: Switch_B# show int Bundle-Ether 10 | inc rate 30 second input rate 837827000 bits/sec, 844584 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec Switch_B# ! To Switch_A: Switch_B# show int Bundle-Ether 3 | inc rate 30 second input rate 864860000 bits/sec, 844591 packets/sec 30 second output rate 864859000 bits/sec, 844590 packets/sec Switch_B#
So I’m doing something right. It looks like the test traffic is accepted by the switches and forwarded across the Switch-to-Switch bundle. That’s great. But then, it looks like the remote switch does not complete the journey and forward the traffic to the destination host.
I realize that this forum isn’t designed to troubleshoot end-to-end problems like mine. But I thought it might be fruitful to pose my problem, if only to see if I’m making some glaring mistake that more experienced eyes might spot. Thank you for reading this post.
Solved! Go to Solution.
04-23-2021 03:30 AM - edited 04-23-2021 03:30 AM
Hello Peter,
I agree you are close to a working solution.
There is nothing on the client facing interfaces to instruct them how to deal with double tagged frames arriving from the inter "switch" link.
rewrite ingress tag push dot1q 2300 symmetric
You may need to add a command to say what to do for frames exiting the interface they must be single tagged with vlan-id 201.
see if there is a rewrite egress command ( I am not sure) or you have to change the previous command adding second-dot1q 23 before final symmetric keyword.
Hope to help
Giuseppe
04-23-2021 03:30 AM - edited 04-23-2021 03:30 AM
Hello Peter,
I agree you are close to a working solution.
There is nothing on the client facing interfaces to instruct them how to deal with double tagged frames arriving from the inter "switch" link.
rewrite ingress tag push dot1q 2300 symmetric
You may need to add a command to say what to do for frames exiting the interface they must be single tagged with vlan-id 201.
see if there is a rewrite egress command ( I am not sure) or you have to change the previous command adding second-dot1q 23 before final symmetric keyword.
Hope to help
Giuseppe
04-26-2021 06:03 AM
Awesome, thanks so much Giuseppe! It hadn't occurred to me that my traffic was being dropped at the remote side switch because I wasn't rewriting the VLAN tags on that end. That's a great lead, thank you!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide