Hi Aaron, Do you consider what you have done a fix, or a potential work around that may have customer implications? That may mean your customer now has partial connectivity through the SP cloud - It may be that your customer is already performing dot1q tunnelling and performing L2 protocol tunnelling (hence the use of the "special multicast mac") - it may be better to talk to the customer and verify what they are doing is within the service agreement of the product/service you are supporting. Interfaces that enter err-disable state are trying to protect the network which is providing shared infrastructure to multiple customers at the cost of service availability to a single interface. If they are doing qinq internally and using l2protocol tunnelling, it may be simply a matter of them forgetting to put the l2protocol tunnelling config so they decapsulate the STP/VTP/CDP/etc frames before sending them on to you..
MPLS based Carrier Ethernet is what Service Providers these days are tending to head towards in order to deal with large scale ethernet networks, it has more scalability and more resilience than a native STP implementation. Within the data centre though, Data Center Bridging which is somewhat IS-IS based L2 routing/bridging mechanim is another technique that SPs are looking at. On Sun, Aug 15, 2010 at 1:00 AM, Aaron Moreck <[email protected]> wrote: > I was having a bit of an issue with dot1q-in-q and l2 protocol tunneling > where nterfaces were going err-disabled. > > I understand now (and I stresss the word now) that if a packet with the > special multicast mac address used for tunneling is recieved on an > interface configured for l2 protocol tunneling it will go err-disabled. > > The fix for this is to restrict specific VLANS on the trunks. > > However, I found this easier said than done (especially if this was a large > service provider network). I have to admit that this is the very first time > playing with dot1q-in-q tunneling so i am hoping some of you guys have been > there and done that so to speak. > > Is there any debug command or show command that can help me determine what > VLAN is causing the issue to make it easier to track down? > > > Thanks > > Aaron > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
