Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

L2 issue

Status
Not open for further replies.

paublo

ISP
Sep 14, 2006
127
US
We have an Ethernet ring with 6 cisco 3500 switches. “Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol”
The root switch of this ring is connected to a cisco 6500. The cisco 6500 is not participating in this spanning tree ring. I simply have a routed interface from the 6500 to the 3500 root switch.

6500 interface:

FastEthernet1/5 is up, line protocol is up
Internet address is 10.10.10.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Secondary address 209
Secondary address 209
Secondary address 209

Everything on the ring works as expected, its blocking and forwarding in the right places etc. The issue sometimes is when there is a topology change in the ring the 6500 can’t ping certain ring switches usually the ring switch which had the backup port but sometimes other switches also. On the 6500 I noticed that the the arp entry age for those switch ips is usually set to 0 and it takes a long time for the 6500 to ping those switches. When everything is up and running the 6500 can ping any ring switch ip with zero issues but as soon as there is a change on the ring things to go bad but again again within the ring all is well.

I was thinking that even if I have a routed interface on the 6500 towards the 3500 root switch that it would route the 1st packet leaving the 6500 to the 3500 root and then the 3500 would use the L2 header to switch the packet. This does seem to work but then again when a topo change occurs the 6500 starts to have issues.


I was thinking of involving the 6500 in the spanning tree ring and making it the root, this should probably solve my issues but I was wondering if anyone has any idea what the problem might be what I need to solve it.

On another note, the 6500 is running rst-pvst and the 3500 are running ieee stp, I shouldn’t see any issues between the two flavors correct?
Also the 3500 are using the regular vlan1 interface and I wanted to create vlan interface on the 6500 of 105, will this cause issues.


Thanks very much, paul



 
If the ring is stable you should get very few topology changes. Would start looking at the connecting links to see why you are getting the changes . Seeing the 6500 is a routed link the issue has to be somewhere in the ring itself.
 
the changes are fine and the ring sees and reacts to the changes the problem is while the ring converges fast the 6500 takes a long time to see the changes, in other words it can't ping ip off the ring for sometime while the ring switches are able to reach all ips right away.
 
What kind of topology changes though? Are switches changing that frequently? Cisco recommends that you run the same STP version between switches otherwise there will be timing issues. Switching over all the 3500s to rapid PVST would be ideal.

When the topology change does happen you can run a few commands from the 6500 and the 3500 to debug:

show spann
show spann vlan <ID>

That will show you the port status, i.e. blocking, learning, listening. You could then evaluate how long each interface is staying in a certain state. I would also recommend running 'debug spanning-tree events'.

There is no duplex mismatch between the 6500 and the 3500 right?
 
lets say a main link goes down and the blocked port comes on line the ring switches see this right away as with the 6500 it takes forever.
 
Paub,

As Netrx stated you should be running the same STP version everywhere.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top