Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: ND2 strange node behaviour (Nikolaos Milas)
2. Re: ND2 strange node behaviour (Nikolaos Milas)
3. Re: ND2 strange node behaviour (Alan Buxey)
4. Re: ND2 strange node behaviour (Mark Cooper)
5. Re: ND2 strange node behaviour (Nikolaos Milas)
6. Re: ND2 strange node behaviour (Mark Cooper)
--- Begin Message ---
On 1/6/2014 2:24 πμ, Eric Miller wrote:
Nick,
In the previous debugging information you provided
csw-astr0#show spanning-tree vlan 1 detail
The line “Number of topology changes 5583310 last change occurred
00:00:01 ago from FastEthernet0/24”
indicates that STP TCN's are a problem. These should occur rarely,
yet this switch has seen 5,583,310 ! When you turned off STP the
switch stopped listening for TCN's.
The last change came in on FastEthernet0/24, so you need to look at
csw-astr2 and csw-dye-pen with the same show spanning-tree vlan 1
detail command to see where the TCN's are originating.
You should make sure that postfast is enabled on all ports which could
be used for an end station. Portfast suppresses the STP TCN's. Don't
enable portfast on connections to other switches. If TCN's are
originating from an end station port without portfast enabled then
most likely you have a link flapping (up/down) somewhere in the
network. Also, note that if you have an unmanaged switch in your
network participating in spanning-tree but not portfast capable it
could be the source of the TCN's.
Each time a TCN's is received it reduces the ageing timer to 15
seconds, TCN's are propagated to every switch in the VLAN
(spanning-tree domain) regardless of where it originated. This
explains why the mac addresses are disappearing so quickly.
Eric
Thanks Eric for your analysis. It makes the situation a lot clearer.
I'll continue investigation per your advice.
All the best,
Nick
--- End Message ---
--- Begin Message ---
On 1/6/2014 12:29 μμ, Nikolaos Milas wrote:
Thanks Eric for your analysis. It makes the situation a lot clearer.
I'll continue investigation per your advice.
I identified a link to another switch (csw-astr2 to csw-dye) which was
configured with "switchport mode access" and "spanning-tree portfast"
and this was obviously the cause of STP malfunction (which resulted in
TCN flooding). When I changed it to trunk, everything started running
smoothly in this network branch (I re-enabled STP on csw-astr0).
I guess I'll have to go through all our other network branches and
correct any and all STP issues.
So, Oliver was right! ND2 works fine, but our switches are sensitive to
various config settings and sometimes we miss things... :-(
ND2 helped in identifying and resolving this undesirable situation. ND1
was "concealing" it.
I even think that ND2 (or a plugin thereof) could leverage this
behaviour to alert administrator of possible STP issues! What would you
think?
By the way, I also found this related thread from Cisco, which details
the same situation as well:
https://supportforums.cisco.com/discussion/11180151/mac-address-disappearing-fast-show-mac-address-table-interface
Thanks again everyone for your patience, help and advice, esp. Oliver
and Eric.
All the best,
Nick
--- End Message ---
--- Begin Message ---
.... I'm not even going to bother mentioning who said that you've got a network
issue and the tool shouldn't be fixed to hide your issue ;)
The side effects of this would have been interesting regarding network
performance and all kinds of quirky things that the clients would have been
seeing
alan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--- End Message ---
--- Begin Message ---
Thanks for the info. Back in the day, about 2000 we had built one of the top 10
data centers in the US. Cisco at the time didn't have this answer, and their
best practice was to leave STP turned on everywhere. I think the idea was to
remain dynamic. ;) Looking back now that sounds like we needed to be talking to
some other folks who knew a little more. I won't get into the dual core issue
that was missed on the outset here, but if you don't know about splitting layer
3 between cores and fail over working properly, give me a shout and I can help
out with that.
Thanks everyone for all the info, always a good mailing list to be on, this.
Coop
On May 31, 2014 7:24 PM, Eric Miller <[email protected]> wrote:
>
> Nick,
>
> In the previous debugging information you provided
>
> csw-astr0#show spanning-tree vlan 1 detail
>
> The line “Number of topology changes 5583310 last change occurred
> 00:00:01 ago from FastEthernet0/24”
>
> indicates that STP TCN's are a problem. These should occur rarely, yet
> this switch has seen 5,583,310 ! When you turned off STP the switch
> stopped listening for TCN's.
>
> The last change came in on FastEthernet0/24, so you need to look at
> csw-astr2 and csw-dye-pen with the same show spanning-tree vlan 1 detail
> command to see where the TCN's are originating.
>
> You should make sure that postfast is enabled on all ports which could
> be used for an end station. Portfast suppresses the STP TCN's. Don't
> enable portfast on connections to other switches. If TCN's are
> originating from an end station port without portfast enabled then most
> likely you have a link flapping (up/down) somewhere in the network.
> Also, note that if you have an unmanaged switch in your network
> participating in spanning-tree but not portfast capable it could be the
> source of the TCN's.
>
> Each time a TCN's is received it reduces the ageing timer to 15 seconds,
> TCN's are propagated to every switch in the VLAN (spanning-tree domain)
> regardless of where it originated. This explains why the mac addresses
> are disappearing so quickly.
>
> Eric
>
> On 2014-05-31 14:18, Nikolaos Milas wrote:
> > On 31/5/2014 7:05 μμ, Nikolaos Milas wrote:
> >
> >> I guess, since we don't use STP at all, I could disable STP altogether
> >> on our two currently used vlans:
> >>
> >> no spanning-tree vlan 1
> >> no spanning-tree vlan 100
> >
> > So, I disabled STP on this switch that and the problem disappeared (on
> > this switch)!
> >
> > Now dynamic addresses in the mac table have doubled:
> >
> > csw-astr0# show mac-address-table count
> >
> > Mac Entries for Vlan 1:
> > ---------------------------
> > Dynamic Address Count : 51
> > Static Address Count : 0
> > Total Mac Addresses : 51
> >
> > Mac Entries for Vlan 100:
> > ---------------------------
> > Dynamic Address Count : 4
> > Static Address Count : 0
> > Total Mac Addresses : 4
> >
> > Total Mac Address Space Available: 7393
> >
> > But, I still don't understand why this happened and how it can be
> > avoided without disabling STP. If someone can explain things, I will
> > appreciate it!
> >
> > Nick
> >
> > ------------------------------------------------------------------------------
> > Time is money. Stop wasting it! Get your web API in 5 minutes.
> > www.restlet.com/download
> > http://p.sf.net/sfu/restlet
> > _______________________________________________
> > Netdisco mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/netdisco-users
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
On 1/6/2014 1:20 μμ, Nikolaos Milas wrote:
When I changed it to trunk, everything started running
smoothly in this network branch (I re-enabled STP on csw-astr0).
Yet, I still wonder why, when the TCN flooding situation was happening,
the "MAC disappearing" issue seemed to occur only with particular
dynamic MAC addresses and not with all (or more) of them...
Could you, Eric (you seem most knowledgeable on the subject), or anyone
else, attempt an explanation, please?
Thanks,
Nick
--- End Message ---
--- Begin Message ---
Hosts can participate in STP. Maybe that's your answer. The ones that do
cause this MAC display issue, those that don't...
Thanks,Mark Cooper
*Cooper's Communications*
[email protected]
On Sunday, June 01, 2014 08:40:51 PM Nikolaos Milas wrote:
> On 1/6/2014 1:20 μμ, Nikolaos Milas wrote:
>
> > When I changed it to trunk, everything started running
> > smoothly in this network branch (I re-enabled STP on csw-astr0).
>
> Yet, I still wonder why, when the TCN flooding situation was happening,
> the "MAC disappearing" issue seemed to occur only with particular
> dynamic MAC addresses and not with all (or more) of them...
>
> Could you, Eric (you seem most knowledgeable on the subject), or anyone
> else, attempt an explanation, please?
>
> Thanks,
> Nick
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/netdisco-users
>
--- End Message ---
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
