EoMPLS Spanning Tree

EoMPLS ile (P2P) spanning tree paketlerinin taşınmasında dikkat edilmesi gereken bazı noktalar vardır. Aşağıdaki linkde bu konuda açıklayıcı bilgiler yer almaktadır.

Spanning Tree gibi kontrol protokollerinin iletiminde genel olarak izlenebilecek 3 tip method vardır. Peer, transport, discard. Bunların kullanımı özellik ile yedek pseudowire ve full mesh pseudowire gibi uygulamarında, looplara veya kararsız spanning tree oluşumlarına yol açabilir.

https://supportforums.cisco.com/document/92621/asr9000xr-migrating-ios-ios-xr-starting-guide

Spanning Tree

The ASR9000 only supports full MSTP and no other spanning tree protocol.

There is the possibility to use the PVST in PVST-AG mode or Access Gateway.

The “AG” version of the MST or PVST gives you the ability to run these protocols in an P2MP VPLS deployment without the need to run the full protocol set. It basically is designed around the 9K PE’s being the root, advertising pre-canned BPDU’s and receive the TCN’s from the access switches to trigger MAC withdrawl.

More info on VPLS and ASR9000 is here.

Running Spanning Tree (not the AGG) version together with IOS requires you to be aware of the concept of VLAN pruning that IOS does and XR is not aware of.

Migrating spanning tree from 7600 to ASR9000 can be a complex task. IOS switches run STP by default, and you need to disable it explicitly if you don’t want to run it. ASR9000 does not run any spanning tree protocol by default and you need to enable it explicitly.

Also the way that BPDU’s are handled in XR/ASR9000 is dependant on your configuration.

The following scenarios cover a few of these design migrations you need to be aware of.

This section tries to cover both MSTP and PVST. The key difference for these 2 protocols is that MSTP sends BPDU’s untagged and PVST sends tagged BPDU’s on the vlans that are PVST enabled.

One of the first decisions you need to make is whether you want the A9K’s to be part of the Spanning Tree design or be transparent to them.

There are pros and cons to each option.

In this first picture below shows a design whereby the ASR9000’s are NOT part of the spanning tree topology.

If you have defined an untagged EFP like this:

int Gig0/0/0/P.1 l2trans

encap untagged

you will capture the MSTP BPDU’s and put them subject to the service that is attached to this untagged EFP.

This can either be a Cross connect (p2p) or a Bridge domain (p2mp). The difference between XCON and BD is that XCON transparently takes whatever comes in on the Attachment Circuit (AC) and send it to the other side (whether that is a phyiscal interface again or a PseudoWire). An Xcon can only have 2 interfaces.

A bridge domain can have multiple EFP’s and also employs mac-learning. If the Destination MAC is not know or part of a broadcast/multicast mac address it will get “Flooded” over to all EFP’s in the Bridge Domain, except for the originating EFP (split horizon).

Ok so in this design, with that knowledge from above, the BPDU’s from switch X are sent via interfaces X and Y to PE1 and PE2.

PE1 would take the BPDU from the untagged EFPand sends them transparently to PE2 over interface M to Switch B’s interface U.

In other words Switch A and B see each other as directly connected neighbors. The A9k’s are completely transparent and acting as a transparent L2 wire.

This STP design will block one of the 4 (X, Y, U or V) interfaces to break the loop.

Design 1

Slide3.JPG

If you were to have a bridge domain on PE1 and a pseudowire between PE1 and PE4, the BPDU *also* gets sent to PE4 and arriving on interface V.

This model whereby the 9k’s are transparent to STP cannot be used with a full mesh of PseudoWires.

This design that you see above is generally seen by “accident” when it is forgotten that the switches run STP by default and the 9k would transparently pass everything on.

“Solutions” are to break to loop manually and using an L2ACL to block the MSTP BPDU’s from traversing your 9K’s.

In the scenario that you do want the 9k’s to participate in spanning tree you basically create to STP “islands” on the left and right side.

The 9k’s now terminate the spanning tree coming from the switches. A full PW mesh is possible and this is also one of the designs where the AG version of the STP protocol becomes very useful.

Switch A sees PE1 and PE2 as neighbor.

Design it such that the PE1 and PE2 are root and back up root.

The configuration for this design is to put the interface P into the STP Configuration so that BPDU’s are sent and received.

Design 2

Slide4.JPG

The effects of the design scenarios and the relation to the spanning-tree protocol in use are pretty much the same for both MSTP and PVST.

What happens when you follow design 1 or 2 in relation to the EFP configuration associated with it, will be discussed below separated out between the two key STP’s.

More detailed configurations and VPLS designs are discussed in this article.

Let us evaluate the various configuration options that you have when defining your EFP’s with and without Spanning tree.

MSTP

Slide1.JPG

Scenario 1 in this picture above is the model that you want to use in the design option “2”. There is no untagged EFP necessary in this case, and BPDU’s received are punted and locally generated BPDU’s are injected directly into the port to the switch.

Scenario 2 describes a situation whereby sometimes people want to peel out their untagged traffic and transport it while still running MSTP on the 9k as in design “2”. This is problematic today for a few reasons:

     1) received BPDU’s are subject to the untagged EFP service defintion and will get forwarded. The local MSTP configuration injects BPDU’s.

     2) this causes the locally connected switch to see BPDU’s from the VPLS remote side (switch B) as well as PE1.

     3) it will cause MSTi mismatches and unexpected blocked ports.

Scenario 3 can be used for “design option 1”. We don’t have any local configuration for STP, so we’re not injecting anything, we are sending the BPDU’s across as per the EFP service definition.

Note:

Scenario 2 is however a design that is recognized as a design we need to support. Starting XR421 scenario 2 will work as follows:

If there is an untagged EFP *and* local STP config on the PE, THEN we will NOT forward the BPDU, but punt them for local STP handling.

We will continue to inject local BPDU’s towards the locally connected switch.

In other words if you have untagged traffic that you want to transport but not the BPDU’s this will work in XR421. Today, you will get the behavior as described above in scenario 2.

If your intend is to use design option 1, and you want to forward untagged traffic (config scenario 3), but you don’t want to forward the BPDU’s then you must apply an L2 ACL onto the untagged EFP to block and deny the DMAC used for (MSTP) BPDU’s.

The ACL definition is discussed in this article in the related information section.

PVST

The story above doesn’t change that much when we are considering PVST.

However there are some minor tweaks caused by the fact that PVST BPDU’s are vlan tagged.

Slide2.JPG

Scenario 1 is used in design option “2” whereby you want your A9K’s to participate in PVST. Note that we don’t do full PVST, but PVST-AG or access gateway, which means that we are sending the bpdu’s on the EFP’s for the respective vlans and take the BPDU’s from these vlans and react on them with mac widthdrawl. The configuration scenario looks like this:

!EFP’s

interface g0/0/0/P.10 l2trans

encap dot1q 10

…etc

!service definitions

l2vpn

bridge group VLANS

bridge-domain vlan-10

interface g0/0/0/P.10

bridge-domain vlan-20

interface g0/0/0/P.20

…etc

!spanning-tree config

spanning-tree pvst-ag

interface g0/0/0/P.10

interface g0/0/0/P.20

interface g0/0/0/P.30

HOT HOT HOT HOT

Scenario 2 is a common issue we see happening causing a lot of trouble. This config scenario does NOT have any local PVST configuration, but if the adjacent switches have PVST enabled (and that can be the default!!) then we’d be transparently passing on the vlans as part of the EFP’s service definition! The PVST BPDU’s are arriving at the remote side and what can be worse is that if we are doing vlan manipulation in terms of tag rewriting with pop or push operations, then the remote side received BPDU’s meant to describe vlan 10, but received as VLAN X after the rewrite!

This scenario can be the intended design as described in design option “1” above.

Scenario 3 is a remedy for scenario 2. Basically we are using an L2ACL blocking any bpdu’s on the EFP’s received so that we are not confusing switches on either end. Alternatively you can also disable STP on the switches connected to the 9k PE’s. We are applying L2 ACL’s that are blocking a particular DMAC that is used for the PVST bpdu’s (see

This issue described here above is something you MUST be aware of.

The ACL definition is discussed in this article in the related information section.

SVI and BVI

The concept between a Switch Virtual Interface and a Bridge Virtual Interface is the same: and L3 endpoint in an L2 environment.

The SVI is a switch concept and the BVI is an L3 concept generally seen on routers.

The BVI interface in IOS-XR/ASR9000 has some restrictions well documented in the CCO documentation for BVI.

Use this reference to setup IRB (Integrated Route Bridging) using the BVI.

EFP

When you set up your Ethernet Flow Point (EFP), especially the untagged one, it can make you run into unexpected scenarios.

For instance, when you have an untagged EFP and you are running full MSTP, the 9K will be able to inject BPDU’s to the peer, but the peer’s BPDU’s are subject to the service of the untagged EFP and may get forwarded. This results in MSTP conflicts on your peer device.

With XR 4.2.1 we’ll have the auto ability to peel out the BPDU’s from the untagged EFP when MSTP configuration is present.

More info here.

Also the forwarding of vlan traffic out of an EFP and vlans has a few things that you need to be aware of documented in this article

Converting IOS trunks into XR

Because the IOS-XR EVC model is not aware of trunks like IOS devices are, the conversion from an IOS trunk to an XR EVC based config can be a bit confusing at first. This configuration example documents how to convert an IOS trunk to an XR EVC model:

IOS:

interface TenGigabitEthernet13/3

description my-trunk

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 4,130,133

switchport mode trunk

no ip address

interface Vlan 4

ip add 10.11.2.1 255.255.255.0

XR:

The translation will be:

interface TenGigabitEthernet 0/0/0/0

description my-trunk-like-xr-interface

Define the EFP’s with their respective vlan tags. Because a BVI is used we need to pop the tag so that “inside” the bridge-domain we see untagged packets. On egress, the vlan tag will be slapped on as per EFP definition. Effectively, we create a bridge-domain per vlan.

interface ten0/0/0/0.4 l2transport

encapsulation dot1q 4

rewrite ingress tag pop 1 symmetric

interface ten0/0/0/0.130 l2transport

encapsulation dot1q 130

rewrite ingress tag pop 1 symmetric

int ten0/0/0/0.133 l2transport

encapsulation dot1q 133

rewrite ingress tag pop 1 symmetric

The L2transport command makes these switchports for L2 services

For the switchport trunk allowed vlans, and the interface vlan X, you need to do the following:

First create the bvi interface:

interface BVI4

  ipv4 address 10.4.1.10 255.255.0.0

interface BVI130

  ipv4 address 10.130.1.1 255.255.0.0

interface BVI133

  ipv4 address 10.130.1.1 255.255.0.0

Note that the BVI interface number doesn’t necessarily need to be the same as the VLAN identifier, same goes for the subinterface number of the l2transport interface. Though for this example, the practice is followed to make the BVI number, the same as the dot1q TAG value and the same as the EFP subinterface number for clarity.

Then you need to create the bridge group to tide all together.

l2vpn

bridge group MyTrunks

  bridge-domain VLAN4

    interface ten0/0/0/0.4

    routed-interface bvi4

bridge-domain VLAN130

  interface ten0/0/0/0.130

  routed-interface bvi130

bridge-domain VLAN133

  interface ten0/0/0/0.133

  interface bvi133

The Bridge group is just a non functional configuration hierarchy to tie several bridge-domains together in part of the same functional group. It functionaly is no different then creating multiple individual groups with their domains, as opposed to one group with multiple domains.