cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2751
Views
0
Helpful
11
Replies

STP blocking OR not blocking that is the question?

ava79cisco
Level 1
Level 1

Hi all,

I have cisco catalyst 3750 switch that is connected to a HP interconnect switch (provided with Proliant BL20p blade servers).

On the 3750 switch I defined an etherchannel consisting of 4 ports. I allowed all VLANs on this etherchannel thus putting all 4 ports in trunk access mode. I use Dot1Q encapsulation on the trunk because it is the only tagging protocol supported by HP (and I definitely want my cisco switch to be able to talk with his HP neighbor :).

The native VLAN for this trunk is VLAN1.

On the HP interconnect switch I defined a trunk of 4 ports (understand that these are the 4 ports connected to the ones I defined on the 3750). I allowed all VLANs on the trunk and the native VLAN is also VLAN1.

Now here comes the problem:

On my 3750, among the 4 ports belonging to the etherchannel, one status led is Flashing amber.

According to the "Catalyst 3750 Switch Hardware Installation Guide" (page 2-20) it means that the "Port is blocked by STP and is transmitting or receiving packets".

First, it doesn't make any sense to me. I would assume that a blocked port does not receive nor transmit any traffic (it is blocked after all!).

Second, there is no active STP instance ('show spanning-tree active' returns nothing). There is no level 2 loop in my network.

So if there is no active STP instance how is it possible that one port is blocked? I suspect that when you define an etherchannel, a silent STP instance is running. Am I right? After all an etherchannel allow to aggregate some throughput so you definitely create a loop between device when cabling. I suspect that this silent STP instance has some connections with the default native vlan (ie VLAN1 in my case).

Can anyone help? Does this mean that I have STP issues (possible loop?).

Also, I am not sure of the diagnostic.

The status led is flashing amber. I indeed see it flashing amber AT A REGULAR and CONSTANT PACE but the default color is green (understand when not amber) so I could also understand it as alternating green amber (which has another meaning: link fault).

If there are any issues or tricks I should be aware of when connecting my cisco and HP switches I would be happy to learn about it. I already read:

h200006.www2.hp.com/bc/docs/support/SupportManual/ c00111930/c00111930.pdf

and other relevant HP documents but could not find anything from Cisco.

My network is currently working perfectly except this worrying flashing port status led.

Help.

Arnaud Vangelisti

11 Replies 11

Hello,

can you post the output of:

debug spanning-tree events

debug spanning-tree etherchannel

Regards,

GP

Spanning tree event debugging is on.

Spanning tree etherchannel support debugging is on.

Sorry but there is nothing more to post since no output is produced by those commands to the console.

I would have expected some messages to pop up for example when I unplug the cable that is connected to what I call the 'blocked port', I indeed see that something is happening since the other ports of the trunk start flashing amber (I suspect this is the STP algorithm that determine what port to put in the blocked state) and eventually one of the remaining ports member of the trunk turn out to be flashing amber (blocked state).

Still I am really worried because when I issue this command:

'show spanning-tree blockedports'

I get as an answer:

Number of blocked ports (segments) in the system: 0

It clearly indicates that no port is in blocked state.

Also, when I issue:

'show spanning-tree detail'

I get:

No spanning tree instance exists.

Which is exactly what I expect since I turned off STP.

Finally, I checked that STP is turned off on the HP interconnect switch so I really don't get where those STP issues come from?

Any further help appreciated.

Arnaud Vangelisti

forsudhaji
Level 1
Level 1

Yes..Port in Blocking state will not process the real traffic but will listen to BPDU's..(Bridge protocol data Units)..Also when u have redundant links to a specific destination STP will by default make a port blocked..Also by default STP is ON...Pls chk whether STP Is active at HP end..

But in ur case its not redundant..its trunking..logically one..Something to do with HP config I believe..

If you have spanning tree turned off, there should be no reason that the trunk port is blocking. Can you do a show interface on that port and post it here.

I know...

Here is what you asked but to me nothing is wrong. Why the *?/! is this status led flashing ???

No errors, no CRC, nothing special in the logs. I really don't understand.

Arnaud Vangelisti

_______________________________________________________________________

Catalyst_Machine#sh interfaces GigabitEthernet1/0/3

GigabitEthernet1/0/3 is up, line protocol is up (connected)

Hardware is Gigabit Ethernet, address is 000f.3478.eb03 (bia 000f.3478.eb03)

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is RJ45

output flow-control is off, input flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:02, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 1000 bits/sec, 2 packets/sec

5 minute output rate 1000 bits/sec, 2 packets/sec

1128411 packets input, 86463229 bytes, 0 no buffer

Received 14 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 6 multicast, 0 pause input

0 input packets with dribble condition detected

70768440 packets output, 521920367 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

Catalyst_Machine#sh interfaces GigabitEthernet 1/0/3 etherchannel

Port state = Up Mstr In-Bndl

Channel group = 2 Mode = On/FEC Gcchange = -

Port-channel = Po2 GC = - Pseudo port-channel = Po2

Port index = 0 Load = 0x00 Protocol = -

Age of the port in the current state: 00d:19h:12m:10s

Catalyst_Machine#sh interfaces GigabitEthernet 1/0/3 trunk

Port Mode Encapsulation Status Native vlan

Gi1/0/3 on 802.1q trunk-inbndl 1

(Po2)

Port Vlans allowed on trunk

Gi1/0/3 1-4094

Port Vlans allowed and active in management domain

Gi1/0/3 1-12

Port Vlans in spanning tree forwarding state and not pruned

Gi1/0/3 1-12

Catalyst_Machine#sh interfaces port-channel 2 etherchannel

Age of the Port-channel = 07d:15h:09m:19s

Logical slot/port = 10/2 Number of ports = 4

GC = 0x00000000 HotStandBy port = null

Port state = Port-channel Ag-Inuse

Protocol = -

Ports in the Port-channel:

Index Load Port EC state No of bits

------+------+------+------------------+-----------

0 00 Gi1/0/1 On/FEC 0

0 00 Gi1/0/2 On/FEC 0

0 00 Gi1/0/3 On/FEC 0

0 00 Gi1/0/4 On/FEC 0

Time since last port bundled: 00d:19h:15m:31s Gi1/0/1

Time since last port Un-bundled: 00d:19h:16m:02s Gi1/0/4

Is the port going amber and then turning green? It might be a duplex or speed issue. Also Are you able to communicate via HP switch on the GIG port?

Another thing you can try is the show log and see if there is anything happening on the port.

mcdonalda
Level 1
Level 1

Hi Arnaud,

We have also seen 3750 interfaces flashing amber, and I too don't understand what is meant by "port is blocked by STP and is transmitting or receiving packets", but here's another clue:

I searched the bug toolkit and discovered that the interface can also flash amber for another reason:

CSCec53648 Bug Details

Headline 61-64 byte dot1q frames trigger LED to blink amber

Product 3750 Model all

Component led Duplicate of

Severity 4 Severity help Status Verified Status help

First Found-in Version 12.1(14)EA1 All affected versions First Fixed-in Version Version help

Release Notes

Symptom:

Interface LED is amber blinking when receiving valid dot1q packets which are less

than 68 bytes (tag included).

Conditions:

This problem affects the Catalyst 2970, 3560, and 3750 family of switches.

As for what causes those under-sized ethernet frames -- fragments? -- someone else said to verify speed/duplex settings and check for interface errors, which is probably good advice. Also check that the same trunking encapsulation method is set at both ends.

Hope this helps

Andrew M

Hi Andrew,

I was not aware of the fact that on Cisco Catayst 3750:

"Interface LED is amber blinking when receiving valid dot1q packets which are less than 68 bytes (tag included)."

I indeed configured my cisco trunk with dot1q encapsulation and selected the same protocol on my HP interconnect switch. Actually I had no choice since HP only supports dot1q encapsulation and NOT ISL which is a Cisco proprietary protocol.

I also heard about the possible speed/duplex issue. I was very surprised to discover that when you force the speed to 1000b/s on the HP interconnect switch you MUST set the auto negocation parameter to auto (that is you cannot force it to full duplex for example). I can provide logs to prove my saying.

The trouble is that it lets you no choice regarding the port configuration on the cisco side. You have to enable auto negociation also.

Anyway, I check my CRC and error counter and they are stil equal to 0 so I assume that everything is working fine.

Thanks for your help.

Regards,

Arnaud Vangelisti

"I assume everything is working fine" is a famous last words isn't it? :)

Did you remember to disable Cisco DTP on the port that connects to the HP switch with:

- "switchport mode trunk"

- "switchport nonegotiate"

- and I'd probably disable CDP and PAgP too.

If the HP end is also transmitting some untagged control traffic -- like stp bpdus?-- could that explain why your Cisco switch thinks it's receiving frames which would otherwise be too small to be vlan-tagged?

And if that fails I'd consider hardware faults by trying different ports, etc.

All the best

Andrew M

teru-lei
Level 1
Level 1

Hi Arnaud,

I think the problem should be located in the etherchannel protocol. Cisco support pagp, lacp and manual config to "on". But normally pagp is not supported by other vendors. Try to config your etherchannel to "on" mode or use "channel-protocol" command in interface to set the protocol to lacp.

Best Regards

Teru Lei

Review Cisco Networking for a $25 gift card