"show span vlan <#> detail" will give you all the ports forwarding for the vlan. The key here is in knowing the spanning tree topology well enough to identify a port that should be blocking but is not. There should be one root port and multiple designated ports in a forwarding state.
In a redundant topology there should be one blocking port to prevent a loop. To identify that port you must understand stp path selection. See:
STP: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10556-16.html for
I have seen very RARE cases where a blocked port is actually forwarding traffic. Once you identify which port should be blocking and confirm it is blocking via the "show span vlan <#> detail" command you can check the interface stats with "show interface <#>" and look at input / output rates. Note if it is a trunk and not all vlans are blocked then this command will not be very useful.
... View more
Hi Amit, I have a few questions. - Can you provide me the switch config and show version? - what interfaces are conneting the routers? Unless it is configured to create a tunnel or is a metro switch with service instances the switch will only look at the outer tag.
... View more
not sure if this will work but I found the following thread: https://discussions.apple.com/thread/2033838?start=0&tstart=0 sudo ifconfig en0 media 100baseTX mediaopt hw-loopback unfortunately this is not persistent across reloads
... View more
Not sure why that link did not work. It's a support forum doc I wrote. Here's the body: Catalyst Switch Configuration Options for Microsoft NLB Clustering in Multicast Mode Switch config for Microsoft NLB 2003/2007 for Multicast Mode with IGMP NOTE: If you are running an IOS version that does not contain the fix for CSCsw72680 you cannot use PIM on the NLB VLAN SVI. Only use the IGMP snooping querier. CSCsw72680 Release Notes: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsw72680 NLB in Multicast mode with IGMP: 1) Create an igmp snooping querier (either globally or on the SVI - platform dependent) On the 4500, the snooping querier is first supported on 12.2(50)SG (documented in release note http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/release/note/OL_5184.html#wp1480270) 2) Add static ARP entries to your switches that route into the NLB VLAN (this is still necessary as the clients are going be accessing the NLB cluster at its unicast IP which is tied to the multicast MAC). If you create a querier on the VLAN SVIs that are connected to the NLB clusters and have your NLB cluster running in Multicast Mode w/ IGMP then you do not need static MAC entries, as IGMP joins will be sent by the NLB into the switch which will program the NLB multicast MAC addresses dynamically. All downstream IGMP enabled switches on the NLB subnet will learn this address. Make sure your NLB multicast mac address is RFC complaint - meaning it starts with 0100.5eXX.XXXX. This should be created on the NLB. Sample IGMP Config on Core: IGMP Snooping Querier: (config)#int vlan (config-if)#ip igmp snooping querier (this is done globally on some DSBU switches) Good articles about NLB configuration from MSFT http://support.microsoft.com/kb/193602 http://support.microsoft.com/kb/197862/ http://technet.microsoft.com/en-us/library/cc783135.aspx IGMP Support for NLB http://support.microsoft.com/kb/283028 NLB in Multicast mode without IGMP: 1) Create static ARP entries to your switches that route into the NLB VLAN 2) Create static MAC entries on all layer 2 uplinks and NLB access ports. This is necessary as we will not dynamicall learn the multicast MAC of the NLB because the NLB does not send IGMP joins NOTE: There have been some issues recently (post April 2010) where customers even with the above configs could not get NLB to work. Both problems were Microsoft issues. Problem 1: Clients could not connect to NLB VIP Resolution: Apply NLB hotfix http://support.microsoft.com/kb/960916 Problem 2: NLB server could not ping outside of the subnet. When sourcing a ping from the VIP, customer would get “ping transmit failed. general failure” on the windows CMD screen. Resolution: Run following commands on NLB Server from Windows Command Line “netsh interface ipv4 set interface nlb weakhostreceive=enable” “netsh interface ipv4 set interface nlb weakhostsend=enable” (Customer ran these brom the c:\windows\system32 directory - not sure if that's required or not)
... View more
You will always need the static ARP entries becasue we will never dynamically program a unicast IP to a multicast mac (as this breaks RFC1812). With NLB in multicast mode with IGMP you will not need to program any static MACs on the NLB uplinks and access ports. Here's a link to basic Catalyst Switch configuration for NLB in multicast and multicast with IGMP: https://supportforums.cisco.com/docs/DOC-16620
... View more
Hi Michael - If you haven't already done so you'll probably want to open a TAC case on this. NLB in multicast mode can run in one of two modes: multicast or multicast with igmp. From the switch perspective the difference is that if the NLB is running in multcast mode w/ IGMP we should dynamically learn the NLB multicast MAC address on the uplinks to the switch. This configuration requires an IGMP snooping querier to be defined on the NLB vlan (and can be one of the 4500s if they are running newer code). If the NLB is not running IGMP then the NLB multicast MACs need to be statically defined on the uplinks to the NLB and the link between the HSRP primary and secondary switch. I'm not exactly clear on what you're failing over so I can't tell you where the failure lies and in which direction the failure is occurring. If the NLBs are on vlan 140 and connected to the TMG firewalls then you will want to make sure the NLB multicast MAC is still learned on the port to the NLB/TMG FW after failover.
... View more
"buffers" means that each of the 4 egress queues on the interface get 25% of the buffer
"reserved" means how much of that 25% buffer you are guaranteed.
100% means you are guaranteed your full 25% buffer share.
50% means that you are only guaranteed 1/2 of your 25% buffer share and that the other 3 queues
can borrow the other 1/2 if you are not using it at the time.
"maximum" means how much buffer you can borrow from other queues.
400% means you can use your 100% plus the 100% of the other 3 queues (if not in use and not reserved) for a total of 400%
"threshold" are the drop thresholds for each queue.
Once you hit that % of queue fullness you drop all packets with the QoS value associated with that queue.
So to answer your question "How does this "overflow" 50% of the buffer space for Queue 1 (or 3) fit into 25% of available buffer space?" the answer is it doesn't. Your calculation is correct in that you have allocated up to 50% of total buffer space for queues 1 and 3 to borrow - but with this config the most you'll ever get is ALL of the 25% allocated for the shared pool. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/command/reference/cli1.html#wp2144505 From the above link: While buffer ranges allow individual queues in the queue-set to use more of the common pool when available, the maximum number of packets for each queue is still internally limited to 400 percent, or 4 times the allocated number of buffers. The switch uses a buffer allocation scheme to reserve a minimum amount of buffers for each egress queue, to prevent any queue or port from consuming all the buffers and depriving other queues, and to decide whether to grant buffer space to a requesting queue. The switch decides whether the target queue has not consumed more buffers than its reserved amount (under-limit), whether it has consumed all of its maximum buffers (over-limit), and whether the common pool is empty (no free buffers) or not empty (free buffers). If the queue is not over-limit, the switch can allocate buffer space from the reserved pool or from the common pool (if it is not empty). If there are no free buffers in the common pool or if the queue is over-limit, the switch drops the frame.
... View more
Catalyst 4500: Cat4k IOS SW licenses are as follows: - for 4503/4506, one enhanced L3 license for the supervisor - for 4507R/4510R, one enhanced L3 license for the chassis Issue 1: Failed: Specified UDI not found You get an error message akin to "Failed:Specified UDI not found" Fix: Make sure the license was generated per the above rules for the 4500. The folks in licensing do not always know which serial number and part ID to use and will often generate the license mismatched (ie chassis serial # and Sup Part ID). Here are the contents of a sample license file. You'll see the serial number & PID in bold. Make sure they match. <?xml version="1.0" encoding="UTF-8"?><CISCO_WT_ARTIFACTS version="1.0"><CISCO_WT_LICENSE version="1.0"><FEATURE_NAME>ipbase</FEATURE_NAME><FEATURE_VERSION>1.0</FEATURE_VERSION><UDI><PID>WS-C4510R-E</PID><SN>SPE12345678</SN></UDI><SOURCE>Cisco HQ</SOURCE><CREATE_DATE>2011-02-02T12:27:45</CREATE_DATE><LICENSE_LINE_HASH hashAlgo="SHA1">sdjC+123456789tABqdgxE87Po=</LICENSE_LINE_HASH><TYPE>PERMANENT</TYPE><LICENSE_LINE><![CDATA[11 ipbase 1.0 LONG NORMAL STANDALONE EXCL INFINITE_KEYS INFINITE_KEYS NEVER NEVER NiL SLM_CODE CL_ND_LCK NiL *1UG2ABCKEFGHIJ400 NiL NiL NiL 5_MINS <UDI><PID>WS-C4510R-E</PID><SN>SPE12345678</SN></UDI> DlR7FXJno2,3BDiBkv4GVEtw:ajCQRwsMGzzFG123456789098765,OUnvLAtgtpVFIOA:Jr:N5mbirGpf2AjvLu8RYIT7D6oON4LA8i:BcXL72hVAlAFu7q4arxjylr38LJ$<WLC>AQEBIf8B//+5D2KWQmOVz71RspLUJdvviBnoPaJcxkVMehB7v3404wBd4A7CaTrOXJKQExSNDAhHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE+y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t612345678Vhvoh/FZfy5iRY3oE=</WLC>]]></LICENSE_LINE><USER_MODIFIABLE_COMMENT fieldRestrictions="Max 99 ASCII characters in length."></USER_MODIFIABLE_COMMENT></CISCO_WT_LICENSE></CISCO_WT_ARTIFACTS> Install Command: license install bootflash:SPE12345678_20110113112345678.lic license install t ftp:// <ip address>/SPE12345678_20110113112345678.lic Issue 2: License file parsing failed The license often comes as a Zip file. If they are not unzipped prior to installation the 4500 will generate the following message: License file parsing failed with err type 0, reason 2 Fail tag NULL, Fail attr NULL, Fail errmsg Bad XML form, Last State INIT_BLDG, Last Known tag 'NotARealTag' % Error: License installation failed with error: XML parsing failed % Error: License installation failed with error: XML parsing failed Fix: You guessed it. Unzip the file. Nexus 7000: Issue 1: SERVER line in license should have "this_host ANY" On a N7K you will often see the error: Installing license failed: SERVER line in license should have "this_host ANY" Fix: This is usually caused by a corrupt license file. To resolve it, follow these steps: - Open the .lic file, copy and past its contents into notepad, and save it as type "all files" (encoding ANSI) - Transfer the file on the N7k and run the install command N7K# install license bootflash:MDS20110730051234567.lic Issue 2: I nstalling license failed : license host-id doesn’t match license file The license may sometimes be incorrectly generated for the sup/chassis bundle or supervisor serial number instead of the chassis serial number. Fix: Run the command " show license host-id" Contact licensing and have them issue the correct license for the chassis serial number or generate your own licens via the license generator tool on Cisco.com: https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet Issue 3: Missing License If you end up seeing the following: nexus#sh license usage Feature Ins Lic Status Expiry Date Comments Count -------------------------------------------------------------------------------- LAN_ADVANCED_SERVICES_PKG No - Unused - LAN_ENTERPRISE_SERVICES_PKG Yes - In use Never license missing -------------------------------------------------------------------------------- **** WARNING: License file(s) missing. **** This means that the license file is not in the bootflash. This issue can be seen when a customer with multiple N7Ks receives supervisors with pre-installed licenses and moves the Sup from one chassis to another. Since the license is tied to the chassis, the above message is reported. To get around this you simply need to put the file in the bootflash for that supervisor. You can determine which supervisor belongs to which license by running the following command: show license host-id You can take the output of this command and compare it to the name of the .lic file.
... View more
Q: thanks for reply but i do not see any messages in switch log do you why? A: You will only see it the when the port fist comes up and goes through spanning tree listen/learn states and you're logging is set up to log this level of message. You can look at port spanning tree state while the port is amber and it will show as broken due to port inconsistency: SW3#sh span int f0/24 Vlan Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- VLAN0001 Desg BKN*19 128.26 P2p *TYPE_Inc If you shut/no shut the access port that will also trigger the message. SW3(config)#int f0/24 SW3(config-if)#shut 1d15h: %LINK-5-CHANGED: Interface FastEthernet0/24, changed state to administratively down SW3(config-if)#no shut SW3(config-if)# 1d15h: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up 1d15h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to up 1d15h: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/24 VLAN1. 1d15h: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/24 on VLAN0001. Inconsistent port type. If you're still not seeing the message logged make sure your logging level is set to debug, increase the size of your logging buffer and make sure you're logging to console. SW3(config)#logg buff 7 SW3(config)#logg buff 1000000 SW3(config)#logg console 7 To reiterate my earlier statement, your config is not supported. You can't have mode dynamic on one side and static trunk on the other.
... View more
Hi Anders - In looking at the two captures I see the ARP sender IP is 0.0.0.0. There is a bug where we drop these packets if DAI is enabled. The bug ID is CSCsg18176. You can view the bug details here: http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs While the bug was filed for the 3750 the DAI code was ported across multiple platforms including the 6500 so it is impacted and as far as I can tell a fix was never ported to the Cat6500 code train. If you're hitting this bug and would like to find the status of getting this fixed on the 6500 please open a TAC case and request to have the fix ported over.
... View more
First - the solid amber light on the 2950 indicates the port is not forwarding: http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/hardware/installation/guide/hgovrev.html#wp1089458 The reason it is not forwarding is becasue you have a non-supported config. One side of the link (switch b) is a static trunk and is not running DTP so it is not notifying the far end that it is a trunk. Switch A has not recevied any DTP frames so he falls back to an access port. You probably will see log messages similar to this on switch A: 23:00:10: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/24 VLAN1. 23:00:10: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/24 on VLAN0001. Inconsistent port type. As to why it shows up as static access, it is because we are not receiving DTP frames on that port so we're not negotiating to access. We are falling back to access. Hope this answers your questions.
... View more
If the ISSU failed with the full config then the first thing that you need to look for is whether a any crashinfo files were generated. Run the command "dir all" and look for a crashino file on both bootflash, sup-bootdisk, standby-bootflash and standby-Sup-bootdisk. I would suggest opening a TAC case as I did a little extra research and found another posting where this same behavior was seen when performing an ISSU upgrade from SXI4a to SXI5 on a Sup32, non-VSS and is still under investigation. Also, verify that the SXI4a and SXI5 images are both identical. You post indicates that they are both IPBASE images. Make sure they are both "K9" as your SXI5 image is a K9 image. s72033-ipbase***k9***-mz.122-33.SXI5.bin
... View more
This document provides simplified steps for creating a layer two port channel between two Catalyst switches running IOS. In this example we're creating a portchannel between a Catalyst 4500 and Catalyst 6500 using LACP. When creating a port channel, it is very important that it be done in the proper order. 1) Determine the port channel numbers you want to use on both ends and make sure they are not already in use 2) Configure all interface attributes prior to assigning them to the port channel 3) Assign the interfaces to the port channel 4) Verify the port channel is up and the interfaces are properly bundled 1) Determine the port channel numbers you want to use on both ends and make sure they are not already in use with the "show etherchannel summ" command. 4500#sh etherc summ Flags: D - down P - bundled in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 20 Po20(RD) - !! As port-channel 20 already exists I want to make sure I do NOT use this port-channel number for my new port-channel. 2) Configure all interface attributes PRIOR to assigning them to the port-channel. 4500(config)#int range g1/2-3 4500(config-if-range)#switchport 4500(config-if-range)#switchport trunk enc dot1q 4500(config-if-range)#switchport mode trunk 4500(config-if-range)#switchport trunk allowed vlan 2-3 3) Assign the interfaces to the port-channel. Let the switch dynamically create the port-channel interface. 4500(config-if-range)#channel-group 10 mode active Creating a port-channel interface Port-channel 10 At this point the port-channel will be down and in a "waiting to be aggregated" state as you must now create the port-channel on the other end. Note in the below output the interfaces have (I) after them, indicating they are waiting to receive LACP packets form their peer switch. 4500#sh etherchannel summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 10 Po10(SD) LACP Gi1/2 (I) Gi1/3 (I) Connect to the peer switch and perform the same steps 1-3. 6500(config)#int range g5/1-2 6500(config-if-range)#switchport 6500(config-if-range)#switchport trunk enc dot 6500(config-if-range)#switchport mode trunk 6500(config-if-range)#switchport trunk allowed vlan 2,3 6500(config-if-range)#channel-group 10 mode active On the 6500, after adding the ports to the channel you will see this message: %EC-SP-5-PORTDOWN: Shutting down Gi5/1 as its port-channel is admin-down %EC-SP-5-PORTDOWN: Shutting down Gi5/2 as its port-channel is admin-down To bring the port channel up you must no-shut the port channel interface: 6500(config)#int port-channel 10 6500(config-if)#no shut 4) Verification: Check to see that the etherchannel is now properly bundled on each end. You want to see the P-Flag (P) after the interfaces, indicating they are bundled. 4500#sh etherc summ Flags: D - down P - bundled in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel Protocol Port ------+-------------+-----------+----------------------------------------------- 10 Po10(SU) LACP Gi1/2 (P) Gi1/3 (P) 6500#sh etherc summ Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 10 Po10(SU) LACP Gi5/1 (P) Gi5/2 (P) You will now see the port-channel interface with the same conifg as the physical interfaces: 4500#sh run int po10 Building configuration... Current configuration : 140 bytes ! interface Port-channel10 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,3 switchport mode trunk end 6500#sh run int port-channel 10 Building configuration... Current configuration : 140 bytes ! interface Port-channel10 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,3 switchport mode trunk end All future changes (such as adding or removing vlans) should be done on the port-channel interface: Note, on the Catalyst 4500, Sup6-E you cannot apply auto-qos directly on a port channel. See CSCsq67430 for details and the proper config steps.
... View more
A bridging loop or spanning tree loop caused a network outage. To break the loop you've pulled one of the redundant links or shut down one of the switches that are participating in the loop but now you're unsure of what to do to both find the source of the loop and prevent it from occurring again.
Action Plan: Prior to bringing the redundant link/switch back online, implement Layer 2 safeguards designed to protect against STP loops and mitigate the impact if one does occur.
1) Implement Spanning Tree PortFast and BPDUGuard on all edge ports
2) Verify that currently the proper switch is STP root for all VLANs. Consider enabling root guard on root/core switch uplink ports to the distribution layer switches to ensure your root bridge does not change unexpectedly (such as when new switches are connected to the network). It can also be enabled at the access layer, rather than on the root bridge(s), if you maintain control of the distrubution layer and are not concerned with anyone making changes or adding switches to the distribution layer.
Below is an excellent doc that details root guard. See the section titled "What Is the Difference Between STP BPDU Guard and STP Root Guard?" for clarification on the difference. You do not want root guard on the port-channel between core switches running HSRP. It should be enabled ONLY on the uplinks to other switches (or access ports) that you do NOT want to become spanning tree root.
3) Enable loop guard on all distribution/access layer switches* 4) Enable BPDU guard on all distribution/access layer switches* 5) Enable UDLD on all fiber uplinks* - Unidirectional links can cause spanning tree loops. UDLD will prevent this by shutting down a unidirectional link. Note that in Some NX-OS vPC environments UDLD in Aggressive mode is NOT recommended. See http://tools.ietf.org/html/rfc5171#section-5.4 for the IEEE definintion on the difference between "Normal" and "Aggressive"
6) Prune unnecessary VLANs off your trunks
After implementing root guard, loop guard, UDLD aggressive, and BPDU guard, bring the link/switch back up and see if the loop reforms.
* Prior to implementing any of these features it is recommended that you Familiarize yourself with how each feature works:
IF THE LOOP REFORMS: 1) Have a TAC engineer online to troubleshoot
2) Enable mac-address move notification (if applicable - this is disabled by default on the 6500/7600 platform and enabled by default on most others - including the 3750/3560/2960 platforms)
ITLABSW#(config)#mac-address-table notification mac-move
Check the switch log for mac's flapping between interfaces. These are the ports that are participating in the loop. Trace the MAC back to its source. Look for: - A link flapping on a upstream switch, causing spanning tree TCNs (topology change notifications) and spanning tree reconvergence. This should be used in conjunction with step 3 below. - A unidirectional link on an upstream switch causing the loop. - A hub or switch connected to a portfast enabled access port where this mac is learned. Shut this port down and see if this breaks the loop.
3) Check for TCNs While the loop is occurring, if you see excessive TCNs you need to trace the TCNs to the source . To do this, start from the core and run the following commands.
ITLABSW#show spanning-tree detail | inc ieee|occurr|from|is exec
The output from this command will show you the port the last TCN was received on and the time which it was received.
Look for the port that received a TCN in the last few seconds.
ITLABSW#sh spanning-tree detail | i ieee|occur|from|is exec
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 187927 last change occurred 00:01 ago <-time rec'd
from Port-Channel12 <--interface that received the TCN
You will want to follow this port until the port that receives the TCN is an access port, or until the switch in question is generating TCNs but not receiving them. If you find an access port receiving TCNs, shut it down and see if that stabilizes the network.
If you find a switch generating TCNs, you will want to look for two uplink ports or trunks in a spanning tree forwarding state for the same VLAN. If you find two ports in a forwarding state, shut one port down and see if this breaks the loop. Check for a unidirectional link or excessive link flaps.
4) look for an interface with a very high input rate and low output rate
ITLABSW#sh int | i is up|rate
When a bridging loop occurs you will usually see multiple interfaces with a high output rate and low input rate and a single interface with a high input rate and low output rate. - Trace the port with the high input rate down until you come to an access port and shut it down - If the port with the high input rate leads you into a loop you will want to check spanning tree and Etherchannel states until you either find a switch that has a port in an incorrect forwarding state or incorrectly bundled.
5) Look for packets hitting the CPU. Sniff the CPU and see if the packets share a common source (this is only an option on certain platforms. You'll need to contact TAC to assist with setting it up and analyzing the data). Track down the source. If they are STP or CDP packets (or packets destined to the 0100.0CCC.CCCX reserved multicast address) trace where the source mac is learned. See if the source mac leads you in a loop.
If you see two ports in a forwarding state for the same VLAN on the same switch, we need to look for the following: a) does this switch think he is the root for this VLAN (or vlans)? b) should he be? c) is he receiving BPDUs from his neighbor on the ports in a forwarding state? (sniff both forwarding ports to look for BPDUs) d) look for a unidirectional link on one of the ports in a forwarding state e) shut one of the ports in a forwarding state and see if the loop stops
Good doc for troubleshooting bridging loops.
... View more