I have an interesting problem with my switch environment. I have (2) 3550s acting as my distribution layer (labeled d1 and d2) and (3) 3548s acting at my access layer (labeled a1, a2 and a3). Each access switch has a single dot1q trunk link to 1 of the distribution switches (a1 and a3 link via gig-E to d1; a2 links via gig-E to d2). d1 and d2 have a single dot1q trunk link and a single routed link between them.
Currently, I am having an issue with VLAN1 on a few different levels.
Interface VLAN 1 is configured for HSRP on d1 and d2, with d2 being primary for HSRP and also it should be the root bridge for VLAN 1 (spanning-tree vlan 1 pri 4096).
First and most obvious to me when I first started looking at this problem (I recently started working at this company) is the the layer3 interface for VLAN 1 on d1 is showing down/down, even though there are trunk ports carrying VLAN 1 ok. I cannot see a reason the VLAN interface should be down/down. I have tried shutting and no shutting the interface with no luck.
The second problem is there are 4 switches (d1, d2, a1 and a3, recall both a1 and a3 have single dot1q trunks to d1) that all think they are the root bridge for VLAN1 even though I have the spanning-tree priority on d1 set lower to be root bridge. According to d1 spanning-tree, all the ports are in "DWN" status:
For your trunk links check to make sure Vlan 1 is allowed across the links on both ends of the link . It sounds like dist switch thinks it has no active links in vlan 1 so the dist. switches will put it in a down/down state. Could also account for spanning tree root problem. The dist switches need to see at least 1 active port in vlan 1 (switchport or a trunk link with vlan 1 allowed.)
I would say possibly you might have a 1 sided link between d1 and a1 . You can still see cdp if you have one side and would account for not getting to to the switch. You could run cdp debug on both sides , you should see cdp packets going out and coming in in the debug , if not then more than likely it is one sided. Have seen this many times.
The reason your Int vlan 1 is down/down is that you are probably not using vlan 1 as your management vlan. If vlan 1 is not being used for the management then it will automatically shut itself down, you cannot bring it back up unless you specify it as the the management vlan again.Also to attempt to help you with your spanning tree issue. Are you actually running spnning tree on all your switches? Possibly the other switches are not negoitiating root bridge because stp is disabled on them or the ports facing the other switches...Some things to think about...
Thanks for the replies all, Turns out the switch needed a reboot. Last night after modifying the VLAN database and VTP domain, the switch decided to reload it self with an "Unassigned Exception" and when it came back up all was fine. VLAN 1 was up/up, the root bridge priority was all sorted out and CDP was fine. Traffic passing normally.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...