The ASR9000 employs a different concept when it comes to L2 carrier ethernet. Because the ASR9K is not a true L2 switch, it uses the EVC model to provide L2 carrier ethernet functionality. With that for instance we don't have the concept of "trunks" here, or understand what "vlan pruning" does or is.
With that in mind there are a few things you want to know when it comes to IOS and XR integration of carrier ethernet.
VLAN pruning means that a certain trunk in IOS will not forward packets of the vlans that are pruned of that trunk. When running MST (multiple Spanning Tree protocol) this can cause some funky issues with the ASR9000:
Under certain circumstances certain vlans are not to be routed to or through the core.
MSTP requires all instances to be consistent throughout the region
IOS can use vlan pruning to prevent traffic from certain vlans over certain trunks
This can affect root selection in an XR/IOS interop scenario
The following diagrams highlight the issue with Vlan pruning in IOS:
Network diagram and how everything is interconnected.
Showing the XR configuration is used for this topology. Here we have 2 MST instances under the same MST region, one for vlan 100 and one for vlan 200. Each have a different Priority. This is also how we can achieve loadbalancing, by electing one instance as root on device A, and defining another instance to be root on device B. We have loadbalancing and failover in that scenario.
Showing the MST outputs of the "TOP" viking on the left of the network diagram. In the RootID section you can see who is the root for that instance. In this case you can see that the 2 instances 1 and 2 have a different root. In the BridgeID section you can verify what our mac and priorities are that we advetise.
Config and verifiction for the other ASR9000. with the same outputs we collected from the TOP device for comparison.
You can see here that I flipped the priorities for the instances 1 and 2 compared to the TOP viking.
For isntance 1, because the 7600 is the root for that instnace, the inter asr9k link is to be blocked, since there are 2 links between the 9k's
we are blocking the Bundle-Ethernet and Gigabit Ethernet togehter. Even if one of the 9k's was root, either of these paths were to be shut down anyway, which is what you can see in the Instance 2 output of the TOP device (gig is blocked). The gig is blocked because of its cost as opposed to the Bundle-Ether which is higher speed.
Also comparing the 7600 outputs here, the formatting of the output is a little different then what we just saw in XR, but still easy to interpret.
We already knew from the 2 9k's that the 7600 was root for instance 1, and that is confirmed here in RED.
The 7600 is also confirming that BOT is the root for instance 2.
Just a sanity check to make sure we all are on the same page on Spanning-tree and priorities. When the priority is changed in this case much higher on the 9k BOT, which was previously root for instance 2, we see a shift in the root election.
And indeed, the 7600 is now root for both instance 1 and 2.
Another verification step is to check the 2 ASR9k's and their view of the instance 2/vlan 101 definition now that the BOT is no longer root.
Correct, both see the 7600 being root.
Now, this is what I was alluding to earlier! I am only showing here the BOT device, but the TOP will follow the same path here. With the vlan pruning, that is only allowing vlan 1 as per config example on my two uplinks, suddenly the BOT device claims himself to be ROOT!!!
And the 7600 also!!
The reason for that is that when we do vlan pruning the digest in the MST packets remains correct as if we are not pruning, because remember that the mst packets need to be same digest for all switches in the same region.
BUT the 7600 is now omitting a priority and effetively spanning-tree information for these pruned vlans, and in the absence of a superior BPDU, the 9k claims itself to be root then!
So the vlan pruning as what IOS is doing is something sneaky if you will and something to be careful about when integrating with XR.