Glad we got that working dude! On Wed, Sep 9, 2009 at 1:37 PM, Joe Astorino <[email protected]> wrote:
> 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] > -- 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
