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

[Gert Doering]

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/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100309/6e58c000/attachment.bin>