[c-nsp] Cat 3750E w/ MAC learning disabled shutting port?

[Sascha Pollok]

Hi Adam,

the "why" is simple. Some on the remote end disconnected the wrong cable :-)

But I still dont understand why the edge port saw a link up/down then.

Thanks
Sascha






Am 25. April 2015 16:59:23 schrieb Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>:

> Hi Sascha,
>
> Isn't there anything else in the logs concerning STP changes or why the 
> port went down?
> My wild theory would be that the port flap broke the tunnelling for some 
> reason.
>
> adam
> > -----Original Message-----
> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> > Sascha E. Pollok
> > Sent: 25 April 2015 07:53
> > To: Blake Dunlap; Lukas Tribus
> > Cc: jm at iphh.net; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Cat 3750E w/ MAC learning disabled shutting port?
> >
> > Hi Lukas, hi Blake, et al,
> >
> > me again. I noticed I have not been completely honest with you guys :)
> >
> > >>>> I am looking for an explanation for a strange port flap that I
> > >>>> experienced this afternoon and out of desperation (and because I can
> > not
> > >>>> find an answer on Cisco, Google, you name it and I am not yet
> > desperate
> > >>>> enough to open a TAC case) I am posting here.
> > >>>>
> > >>>> Here is the situation:
> > >>>> Catalyst 3750E has several VLANs. One VLAN has mac-learning disabled.
> > >>>> The VLAN is tagged on one TenG interface and untagged on a GigE.
> > >>>> The TenG interface went down due to a transmission problem. The
> > GigE
> > >>>> interface went Lineproto-down too. Thats weird.
> > >>>
> > >>> I would guess that the box connected to the GigE interface has some
> > >>> kind of heartbeat running towards the other end of the network and
> > >>> resets itself (or the interface) in case the communication breaks. Like a
> > >>> "suicide-is-better-than-a-split-brain" protection?
> > >>>
> > >>> Seems strange for a Catalyst to drop the link in this case. Is the box
> > >>> in a stack?
> > >
> > > The 3750E is a 2x3750E stack. The two interfaces are on the same stack
> > > member (Te1/0/1 is going down, Gig1/0/33 went down too). And yes,
> > > Gig1/0/33 was the only member left in this VLAN but there is no SVI.
> > > Plain layer 2 with MAC-learning disabled.
> > >
> > > To make it a little more strange: the link down of Gig1/0/33 was
> > > actually not logged on the 3750E itself. But the switch connected to
> > > Gig1/0/33 (a 6509 SUP720) saw its link going to up/down when Te1/0/1 of
> > > 3750E went down. Do I have to make a drawing? :)
> > >
> > > I will try to reproduce it but as these are production boxes I can not
> > > just do as I wish.
> >
> > What I forgot to tell you that the interface Gig1/0/33 (that went down on
> > the connected device) has a l2 protocol tunnel configured! :-O
> >
> >  switchport access vlan 82
> >  switchport mode dot1q-tunnel
> >  logging event bundle-status
> >  logging event status
> >  load-interval 30
> >  speed 1000
> >  duplex full
> >  l2protocol-tunnel cdp
> >  l2protocol-tunnel stp
> >  l2protocol-tunnel vtp
> >  l2protocol-tunnel point-to-point pagp
> >  l2protocol-tunnel point-to-point lacp
> >  l2protocol-tunnel point-to-point udld
> >
> > Could the protocol tunneling have an influence on any link state
> > forwarding from the uplink to the access port?
> >
> > Thanks
> > Sascha
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> ---------------------------------------------------------------------------------------
>  This email has been scanned for email related threats and delivered safely 
>  by Mimecast.
>  For more information please visit http://www.mimecast.com
> ---------------------------------------------------------------------------------------