Where do you actually have "l2protocol-tunnel" on? Where do you have "switchport mode dot1q-tunnel" configured???
You would need l2protocol-tunnel and switchport mode dot1q-tunnel on the ISP1 links facing the client. on the ISP links facing each other all in the middle you need normal trunks. So really, you probably need some sort of common "tunneling" vlan shared between isp1, 2, and 3 On Wed, Sep 9, 2009 at 1:12 PM, Justin Guagliata <[email protected]> wrote: > I had a typo below. i mean When the client plugs in a switch on the > *LEFT*side, the ISP2 switch on the > *LEFT* side facing ISP1 goes into errdisable l2tpguard. > > > On Wed, Sep 9, 2009 at 1:02 PM, Justin Guagliata <[email protected]>wrote: > >> It's actually like this. >> >> CLIENT------ISP1------ISP2------ISP2 >> ------ISP3-------ISP3--------ISP1------CLIENT >> >> We OWN the ISP1 switches. When are doing QnQ for the client switches as >> well (including l2tp (CDP,STP,VTP)). When the client plugs in a switch on >> the right side, the ISP2 switch on the right side facing ISP1 goes into >> errdisable l2tpguard. >> >> I've been sniffing the packets and my conclusion is, you can only do l2tp >> once. In other words you can't nest and get cdp/stp/vtp from ISP1 to ISP1 or >> from cleint to cleint in the above diagram. >> >> What are your thoughts Joe? >> >> Thanks, >> >> Justin >> >> >> >> On Wed, Sep 9, 2009 at 12:51 PM, Joe Astorino <[email protected]>wrote: >> >>> Let me fully understand what you are saying. I am picturing: >>> >>> Client Switch ----- ISP1-----ISP2-----ISP3-----Client Switch >>> >>> Is that right? So you have ISP1,2, and 3 all doing Q-Q ? >>> >>> >>> On Wed, Sep 9, 2009 at 12:40 PM, Justin Guagliata <[email protected]>wrote: >>> >>>> Joe, >>>> >>>> What if you have a link that spans 3 providers, all of which are >>>> performing QnQ. Will it be possible to l2tunnel all the way across the link >>>> span. It seems like the l2tunnel can't survive multiple hops. If one >>>> provider is involved, I can span that fine, as soon as I add a second and >>>> try to use l2tunnel, the provider in the middle goes errdisable. >>>> >>>> >>>> On Wed, Sep 9, 2009 at 12:26 PM, Joe Astorino >>>> <[email protected]>wrote: >>>> >>>>> Also, check out this blog post, it may help you understand that >>>>> particular error: >>>>> http://ipexpert.ccieblog.com/2009/07/29/l2-tunneling/ >>>>> >>>>> >>>>> On Wed, Sep 9, 2009 at 12:24 PM, Joe Astorino >>>>> <[email protected]>wrote: >>>>> >>>>>> Typically you see this when a port configured for "switchport mode >>>>>> dot1q-tunnel" and "l2protocol-tunnel" is receiving an l2protocol-tunnel >>>>>> frame from another switch that it is connected to. Make sure your >>>>>> customer >>>>>> is not configuring l2protocol-tunnel anywhere on their end, and is simply >>>>>> trunking to you. >>>>>> >>>>>> On Wed, Sep 9, 2009 at 10:20 AM, Justin Guagliata >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> I have a link with a provider spanning two locations. The provider is >>>>>>> running QinQ and we have a trunk setup across the link. Recently we had >>>>>>> the >>>>>>> requirement to start doing QnQ for a few "customers" so we attempted to >>>>>>> do >>>>>>> QinQ for our downstream neighbors. The problem is, when our downstream >>>>>>> "customer" plugs in one switch, our port on the provider side goes into >>>>>>> errdisable due to l2ptguard. >>>>>>> >>>>>>> I believe if the customer plugs a switch on the other side, the link >>>>>>> will come up and be fine. The problem is, we can't afford to lose our >>>>>>> link >>>>>>> because the customer had a switch die or is missing a switch on one >>>>>>> side for >>>>>>> some other reason. >>>>>>> >>>>>>> The only solution i can think up is to have the provider disable >>>>>>> errdiable for the l2ptguard cause. >>>>>>> >>>>>>> Does anyone else have any ideas, suggestion? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> For more information regarding industry leading CCIE Lab training, >>>>>>> please visit www.ipexpert.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Joe Astorino - CCIE #24347 R&S >>>>>> Technical Instructor - IPexpert, Inc. >>>>>> Cell: +1.586.212.6107 >>>>>> Fax: +1.810.454.0130 >>>>>> Mailto: [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Joe Astorino - CCIE #24347 R&S >>>>> Technical Instructor - IPexpert, Inc. >>>>> Cell: +1.586.212.6107 >>>>> Fax: +1.810.454.0130 >>>>> Mailto: [email protected] >>>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Joe Astorino - CCIE #24347 R&S >>> Technical Instructor - IPexpert, Inc. >>> Cell: +1.586.212.6107 >>> Fax: +1.810.454.0130 >>> Mailto: [email protected] >>> >> >> > -- Regards, Joe Astorino - CCIE #24347 R&S Technical Instructor - IPexpert, Inc. Cell: +1.586.212.6107 Fax: +1.810.454.0130 Mailto: [email protected]
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
