[c-nsp] Spanning-Tree vs. EoMPLS links in SXI2?

[Anrey Teslenko]

 Hi,

Cisco declare some restriction for propagation BPDU across EoMPLS  cloud,
may be this  decision for your problem...


The following restrictions apply to using trunks with EoMPLS:
 – To support Ethernet spanning tree bridge protocol data units (BPDUs)
across an EoMPLS cloud,
you must disable the supervisor engine spanning tree for the
Ethernet-over-MPLS VLAN.
This ensures that the EoMPLS VLANs are carried only on the trunk to the
customer router.
Otherwise, the BPDUs are directed to the supervisor engine and not to the
EoMPLS cloud.

– The native VLAN of a trunk must not be configured as an EoMPLS VLAN.

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/pfc3mpls.html#wp1279824


2010/3/9 Gert Doering <gert at greenie.muc.de>

> Hi,
>
> maybe a stupid question: are there any issues known with Rapid-PVSTP,
> EoMPLS links, and IOS SXI2?
>
> We just had a "nice" problem due to a broadcast loop which should have
> been broken by STP in the first place, but wasn't - and investigation
> afterwards showed an EoMPLS link that just refuses to forward STP packets.
>
> Here's the setup (simplified):
>
> R1 ==(trunk)== R2 --(MPLS cloud)-- R3 ==(trunk)== R4
>
> the trunk carries about 100+ VLANs, so R2 and R3 are setup to do
> port-mode EoMPLS:
>
> interface GigabitEthernet2/21
>  mtu 1504
>  no ip address
>  udld port disable
>  xconnect 1.2.3.68 11310002 encapsulation mpls
> end
>
>
> Spanning-Tree is active, because of redundancy requirements - the
> connection
> between R1 and R4 must not fail if R2 or R3 fail.  So there is a second
> trunk, and second EoMPLS link (not shown above).
>
>
> What I can see when I do "show spanning-tree vlan 2800" on R1, it
> claims "this bridge is the root" - and if I ask R4, R4 also claims
> "this bridge is the root".  If I flap the trunk link, I see both sides
> go through the standard STP cycle (blocking/learning/forwarding), but
> no rapid-STP exchange takes place.
>
> We have a number of similar links in our network, and never experienced
> any problem with STP over port-mode EoMPLS (nor with STP over subif
> EoMPLS either).  The only thing that's unique about this particular link
> is that "R3" is running SXI2, and all other (working) EoMPLS things are on
> SXH3a, SXI, or SXI2a.
>
>
> I'll open a TAC case for this, of course, but if one of you has come
> across that and knows which IOS versions are problematic, that would
> be appreciated.
>
> (NB: if one of you has a better suggestion to do "redundant trunks for
> about 100-200 VLANs between R1 and R4" that does not require STP, let
> me know.  "Routed" link redundancy is not possible, as there are devices
> to the left and right of R1 and R4 that need to be in the same L2 domain.
> Depending on link state of R1->R2 is also not good enough, as R2 might
> have some issues leading to end-to-end failure...)
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>                                                           //
> www.muc.de/~gert/ <http://www.muc.de/%7Egert/>
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>