you could probably do something like this R1 ==(trunk)== Q1 -- R2 --(MPLS cloud)-- R3 -- Q2 ==(trunk)== R4
Where Q1 and Q2 would on the trunk side: switchport mode dot1q-tunnel switchport access vlan QinQ l2tunnel-protocol STP and then the "tunneled" STP may get forwarded via xconnect. Specifically Q1-R2 function could be done on R2 with an external loop. But that is just a workaround not a solution. And I wouldn't do it. A solution would be to extended mpls towards R1 and R4 but that probably is not possible. Best Regards, -mat On 11 March 2010 09:09, Gert Doering <[email protected]> wrote: > Hi, > > On Thu, Mar 11, 2010 at 06:36:44PM +1000, David Hughes wrote: >> On 11/03/2010, at 7:33 AM, Gert Doering wrote: >> > Workaround: >> > Not to Send BPDU over EOMPLS. >> >> What a fantastic work around. There's a bug that breaks STP so the >> work around is not to use STP. Pure genius. > > *g* > > Actually, this is along the lines of what I expected as one of the > potential responses from this list - "don't build your redundancy on > top of STP" (which is why I explained my setup in somewhat more detail). > > There are good arguments for avoiding STP - and "less Cisco bugs to hit" > is certainly one of them... - but still, the workaround is definitely > worth quoting every now and then :-) > > 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] > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
