- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Web and Unmanaged
- >
- Re: stp loop-protection
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2016 01:48 AM
08-30-2016 01:48 AM
Re: stp loop-protection
I have been able to identify a bit more information on this problem this morning.
It appears that I do get a loop on the LAN as I have seen the following on the syslog server...
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333397] net_ratelimit: 2883 callbacks suppressed
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333400] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333463] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333475] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333492] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:06:59 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:06:59) kernel [2072766.333553] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332217] net_ratelimit: 1068885 callbacks suppressed
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332220] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332226] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332232] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332237] vlan200: received packet on eth1.200 with own address as source address
Aug 29 18:07:04 10.125.3.1 FIREWALL-00 local0 warning (2016-08-29T17:07:04) kernel [2072771.332243] vlan200: received packet on eth1.200 with own address as source address
Based on the 'callbacks suppressed' figure it looks as though there are literally thousands of dropped syslog messages (I assume thats what it means hence thousands of packets). btw its a Watchguard firewall.
At this stage I am not really sure where to start looking. Lack of receiving a BPDU could be caused by the loop creating a storm, but what is causing STP to transition to a forwarding state and hence cause the loop in the first place, albeit only for a very short period of time before all goes back to normal. It appears as though STP is not woking as it should if it is creating loops for a short period.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2016 05:21 AM
08-30-2016 05:21 AM
Re: stp loop-protection
Hi Ian,
Just downloaded IMC as you suggested and attempted to install, but it appears that SQL is a pre-requisite so its a bit of a non-started I'm afraid.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-06-2016 02:09 AM
09-06-2016 02:09 AM
Re: stp loop-protection
I have removed the "port auto-power-dow"n from the ling aggregation member interfaces and set speed/duplex to auto on all of them.
Will wait and see if this makes any difference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-13-2016 03:20 AM
09-13-2016 03:20 AM
Re: stp loop-protection
Problem has reappeared.
I can see why loops are being introduced - switch-06 is transitioning interfaces to FORWARDING on an uplink before it sets them to DISCARDING on the other uplink !!
%Sep 10 08:57:29:258 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
%Sep 10 08:57:30:905 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
%Sep 10 08:57:31:007 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
%Sep 10 08:57:31:135 2016 SWITCH-06 MSTP/6/MSTP_DISCARDING: Instance 2's port GigabitEthernet1/0/26 has been set to discarding state.
%Sep 10 08:57:31:136 2016 SWITCH-06 MSTP/6/MSTP_FORWARDING: Instance 2's port GigabitEthernet1/0/25 has been set to forwarding state.
%Sep 10 08:57:32:916 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
%Sep 10 08:58:00:255 2016 SWITCH-06 MSTP/6/MSTP_FORWARDING: Instance 0's port GigabitEthernet1/0/26 has been set to forwarding state.
%Sep 10 08:58:00:256 2016 SWITCH-06 MSTP/6/MSTP_DETECTED_TC: Instance 0's port GigabitEthernet1/0/26 detected a topology change.
%Sep 10 08:58:00:257 2016 SWITCH-06 MSTP/6/MSTP_FORWARDING: Instance 1's port GigabitEthernet1/0/26 has been set to forwarding state.
%Sep 10 08:58:00:258 2016 SWITCH-06 MSTP/6/MSTP_FORWARDING: Instance 2's port GigabitEthernet1/0/26 has been set to forwarding state.
%Sep 10 08:58:13:531 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/26 was notified of a topology change.
%Sep 10 08:58:13:532 2016 SWITCH-06 MSTP/6/MSTP_DISCARDING: Instance 0's port GigabitEthernet1/0/26 has been set to discarding state.
%Sep 10 08:58:13:533 2016 SWITCH-06 MSTP/6/MSTP_DISCARDING: Instance 1's port GigabitEthernet1/0/26 has been set to discarding state.
%Sep 10 08:58:13:534 2016 SWITCH-06 MSTP/6/MSTP_DISCARDING: Instance 2's port GigabitEthernet1/0/25 has been set to discarding state.
%Sep 10 08:58:13:720 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
%Sep 10 08:58:14:933 2016 SWITCH-06 MSTP/6/MSTP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/25 was notified of a topology change.
Normal operation is:
1/0/25 Forwarding Instances 0,1 and Discard instance 2
1/0/26 Discard instances 0,1 and Forwarding instance 2
so it can be clearly seen in the log above that I end up with all three instances being forwarded out of both g1/0/25 and g1/0/26.
This is when I start seeing looping packets in the network and may indicate why I get BPDU starvation on switch-02.
Is this a known bug? If so is there a fix?
Not sure what else I can do if STP is not functioning correctly.
- « Previous
-
- 1
- 2
- Next »