Hi, On Thu, Mar 11, 2010 at 10:51:15AM +0000, Mateusz Blaszczyk wrote: > you could probably do something like this > > R1 ==(trunk)== Q1 -- R2 --(MPLS cloud)-- R3 -- Q2 ==(trunk)== R4
This might work as a workaround, or might not, depending on whether
R2/R3 would be willing to forward QinQ-encapsulated STP or not...
OTOH, we can life with "no working STP on R2->EoMPLS" for now, and
making the whole topology even more complex is not going to help my
colleagues understand and maintain and troubleshoot the setup (something
to keep in mind).
> A solution would be to extended mpls towards R1 and R4 but that
> probably is not possible.
This is not possible here, because R1 and R4 might have SVIs in the
corresponding VLANs, and 6500 with LAN cards cannot do SVI+EoMPLS bridge
in the same box.
(Well, actually you can, by plugging a loop between two ports, one port
being a switchport/trunk and the other port being the EoMPLS link. But that
won't gain me much compared to what I have now - if the IOS combination
is broken with STP+EoMPLS, it will also be broken if that IOS is running
on R1...)
If I urgently needed the functionality today, I'd downgrade R2 from SXI2
to SXH3a - but I want $them to fix it, makes much more sense for everybody.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpG4NlSU7DGu.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
