Trunking/VLAN issue with 3rd party switch

jordan.bean · ‎02-26-2009

We have 2 Catalyst 3750's (Core1 and Core2) that are trunked together and running STP/VTP. We recently trunked a 3rd party switch to both Core1 and Core2. That switch supports RSTP and we have it configured. The 3rd party switch shows its port 1 (going to Core1) as forwarding and port 2 (going to Core2) as discarding. It shows the STP root as Core1 (which is correct). However, we are seeing some strange behavior with this switch.

All servers connected to this 3rd party switch use port 1 to Core1 as the active trunk and we can see the traffic per 'show int'. What is strange is the 'show interface trunk' command:

Core1:

Port Vlans in spanning tree forwarding state and not pruned

Gi1/0/3 1

Core2:

Port Vlans in spanning tree forwarding state and not pruned

Gi1/0/3 1,7-8,11-17,500-504,550-563

The problem that we are having is that when other servers on our network do ARP broadcasts to contact servers on this 3rd party switch, the ARP broadcasts are only directed out the trunk on Core2. The 3rd party switch isn't responding to those on that trunk because it's blocking.

It's like traffic originating from the 3rd party switch is being handled properly, but for some reason the Cisco's aren't seeing the STP convergence properly. We have other Cisco devices trunked into our network the exact same way with no issues however.

How does the Cisco determine which VLAN's to prune for the switch port?

Any ideas?

Roberto Salazar · ‎02-26-2009

hmm, something is amiss. If core1 is the root for all the vlan, it should be forwarding on all port downstream, meaning all of it's ports should be DP. show int trunk tells me that gig 1/0/3 is blocking for the rest of the vlan except vlan 1. Can you make sure that core1 sees itself as root for the vlans you say it is root for?

jordan.bean · ‎02-26-2009

Here is a VLAN that we're specifically have problems with (can't ping from a server on our network to a server on the 3rd party switch unless we add a static ARP entry).

Core1 'show spanning vlan 563':

VLAN0563

Spanning tree enabled protocol ieee

Root ID Priority 25139

Address 000d.650d.xxxx

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 25139 (priority 24576 sys-id-ext 563)

Address 000d.650d.xxxx

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

Fa1/0/24 Desg FWD 19 128.26 P2p

Gi1/0/3 Desg FWD 4 128.27 P2p

Fa1/0/24 is the trunk to Core2. Gi1/0/3 is the trunk to the 3rd party switch. Core2 shows both forwarding as well. The only port that shows blocking is port 2 on the 3rd party switch.

Roberto Salazar · ‎02-26-2009

So, core1 is the root and it is forwarding to all downstream switch. The server is in vlan 563? Do both of the 3750 have int vlan 563? What is the IOS the 3750 running?

jordan.bean · ‎02-26-2009

Yes, the 3rd party switch is a blade switch (running multiple VLAN's). We have a blade server sitting on VLAN 563. If we put a server elsewhere on our network on VLAN 563, it can't ping the blade server unless we add a static ARP entry. I put a sniffer on the network and the problem is that the Cisco's are sending the ARP broadcasts out Core2 to the trunk that is blocking, not to the trunk on Core1 like it should. I know it's not a VLAN issue. We are running VTP and have never had any issues. The problem is specific to this 3rd party switch - I have a ticket open with that vendor. We are running C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(25)SED.

Roberto Salazar · ‎02-26-2009

The core1 forwarding traffic to only to blocked port sounds strange core1 is the root all the ports from it going downstream should be forwarding. ARP if sent with broadcast destination would be flooded, maybe you are sniffing the cisco only but in reality the 3rd party is also seeing that arp but you are not sniffing it? I am guessing here but the root should definitely have ports going to all edge/dist switches should be forwarding.

jordan.bean · ‎02-26-2009

Both Core1 and Core2 show everything as forwarding. The only port that shows blocking is port 2 on the blade switch. ARP broadcasts are only being sent our Core2 port 2 to the blade switch port 2, which is blocking.

Roberto Salazar · ‎02-26-2009

Ok, gotcha! the 3rd party is the one sending to core2. I think that answers your question. 3rd party is the one sending to core2 which should be blocking on 3rd party. Why? 3rd party should tell us.

jordan.bean · ‎02-26-2009

The 3rd party switch is sending data out port 1 to Core1 (correct). The 2 Cisco switches are for some reason sending the ARP broadcasts out Core2 to the port that the blade switch is blocking. So, no ARP responses are received (they are dropped). Therefore, machines on our network cannot communicate to the blade servers.

Why is Core2 sending broadcasts out the Core2 port (which is blocked by the blade switch) rather than the Core1 port (which is forwarding on the blade switch)?