VlanTraffic on blocked Trunk

Unanswered Question
Aug 6th, 2008
User Badges:

Hi all

I have an access switch WS-C4506 (122-25.EWA.bin) which is redundant connected over trunks to two distribution Switches WS-C6509-E (122-33.SXH.bin)and I use rapid spanning tree.

One Vlan (not vlan1) is blocked on access switch and the other is in forwarding state on access switch.

The problem is that I have still traffic on blocked Vlan (interface), although this Vlan is blocked ??

I receive no failure message or errors.

Thank you for your comments and help.

Marco

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Collin Clark Wed, 08/06/2008 - 08:52
User Badges:
  • Purple, 4500 points or more

Are there other VLANs on that trunk interface besides the one being blocked? Sounds like it. Post a show spanning-tree and we might be able to help more.


marcosaner Thu, 08/07/2008 - 05:47
User Badges:

Hi Collin


Enclosed I send you a show spanning-tree from access switch C4506. I have a lot of vlans but currently only two are active. Vlan 250 for management goes over port-channel 50 and backup vlan 1970 goes over port-channel 10.

Backup vlan 1970 is blocked over port-channel 50 , but I have there sometimes huge backup traffic to 1,5Gbps.


Please let me know if you need more information. Thank you marco


VLAN0250

Spanning tree enabled protocol rstp

Root ID Priority 8442

Address 001f.269d.2000

Cost 6660

Port 690 (Port-channel50)

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


Bridge ID Priority 33018 (priority 32768 sys-id-ext 250)

Address 0011.5c2e.e740

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

Aging Time 300


Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Po10 Altn BLK 6660 128.650 P2p

Po50 Root FWD 6660 128.690 P2p



VLAN1970

Spanning tree enabled protocol rstp

Root ID Priority 10162

Address 001f.269f.2000

Cost 6660

Port 650 (Port-channel10)

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


Bridge ID Priority 34738 (priority 32768 sys-id-ext 1970)

Address 0011.5c2e.e740

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

Aging Time 300


Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Gi2/9 Desg FWD 2000000 128.73 Edge Shr

Gi2/10 Desg FWD 2000000 128.74 Edge Shr

Gi2/21 Desg FWD 20000 128.85 Edge P2p

Gi2/42 Desg FWD 20000 128.106 Edge P2p

Po10 Root FWD 6660 128.650 P2p

Po50 Altn BLK 6660 128.690 P2p



HCS26-1#sh interfaces port-channel 50

Port-channel50 is up, line protocol is up (connected)

Hardware is EtherChannel, address is 001e.7ad0.fae3 (bia 001e.7ad0.fae3)

Description: *** HCS51-0 channel ***

MTU 1500 bytes, BW 3000000 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 N/A

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

Members in this channel: Gi1/2 Gi3/4 Gi3/5

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

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

Last clearing of "show interface" counters 03:11:16

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 448000 bits/sec, 44 packets/sec

5 minute output rate 6000 bits/sec, 1 packets/sec

276208 packets input, 362097744 bytes, 0 no buffer

Received 21324 broadcasts (21319 multicast)

0 runts, 0 giants, 0 throttles

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

0 input packets with dribble condition detected

15911 packets output, 3014850 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Giuseppe Larosa Wed, 08/06/2008 - 12:19
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Marco,

an STP blocked port receives STP BPDUs frames from the designated port on the segment.


If the blocked port should stop to receive BPDUs it will start to react to see if it has to change its state.


do a sh spanning-tree vlan X and see the received BPDUs counter on the trunk port where Vlan X is blocked (not in forwarding state)


Hope to help

Giuseppe

marcosaner Thu, 08/07/2008 - 06:08
User Badges:

Ciao Giuseppe

The blocked Vlan on trunk port respectively port-channel does still receive BPDU frames.


Please be aware that I have two vlans in use.

One vlan 250 for network management goes over port-channel 50 and a vlan 1970 for backup traffic goes over port-channel 10. The backup vlan 1970 is blocked over port-channel 50, but I have there a lot of traffic until 1,5 Gbps. So it's really strange..


Please let me know if you have a good idea.

Thank you

Marco


Port 690 (Port-channel50) of VLAN1970 is alternate blocking

Port path cost 6660, Port priority 128, Port Identifier 128.690.

Designated root has priority 10162, address 001f.269f.2000

Designated bridge has priority 18354, address 001f.269d.2000

Designated port id is 128.1668, designated path cost 1000

Timers: message age 15, forward delay 0, hold 0

Number of transitions to forwarding state: 1

Link type is point-to-point by default

Loop guard is enabled on the port

BPDU: sent 935, received 695



Giuseppe Larosa Thu, 08/07/2008 - 08:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Ciao Marco,

of course you cannot have 1,5 Gbps of STP BPDUs !


verify that all switches are in RSTP mode.


Is possible to have all this traffic on vlan250 the one in forwarding state ?

How can you say that traffic is of vlan 1970 ?


>> BPDU: sent 935, received 695

it looks like there is some conflict here because rx should be much more then tx on a blocked port.


Number of transitions to forwarding state: 1


for some time the port was in forwarding




Hope to help

Giuseppe

marcosaner Fri, 08/08/2008 - 01:40
User Badges:

Hi Giuseppe


All switches are in RSTP mode:


spanning-tree mode rapid-pvst

spanning-tree extend system-id

spanning-tree pathcost method long


You're right I assume that the traffic is on

blocked backup vlan 1970, cause the other vlan 250 in forwarding state is only for switch management. On C4506 I have only vlan 250 with IP address for management configured, there is no other access port or trunk with vlan 250, so I would say this huge traffic is not from management.


Best regards

Marco



Giuseppe Larosa Fri, 08/08/2008 - 13:04
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Marco,

good all switches in the same mode.


The traffic is incoming from the upstream switch ?

on the upstream switch the port for vlan1970 is in forwarding state.

So broadcast multicast traffic is allowed to go out of the upstream switch or unknown unicast


To verify this do the following:

on the upstream's stream port-channel configure


storm-control broadcast level 1.00


Switch(config-if)#storm-control ?

broadcast Broadcast address storm control

multicast Multicast address storm control

unicast Unicast address storm control



you can do the same for multicast or unknown unicast


let's see if this traffic is reduced


if it is reduced you have multicast or broadcast traffic that is going everywhere and you may enable igmp snooping on upstream switches.


given the very high volume I don't suggest to try to capture it it would be dangerous !


Hope to help

Giuseppe

marcosaner Mon, 08/11/2008 - 22:57
User Badges:

Hello Giuseppe


I did some tests again and there is no mutch multicast or broadcast traffic.

Multicast (PIM sparese mode)is still configured in conjunction with IGMP. I did a capture with NAM module of one trunk which is blocked and I saw there is backup traffic of Vlan 1970 from uptream switch (C6509) to access switch (C4509) and it's normal unicast traffic. It looks like like a loadsharing of backuptraffic over blocked and forwarding trunk or channel.


Maybe it has something to do with Supervisor Engine 720 10GE (Active) VS-S720-10G ?


Thank you.

Best regards

Marco



Giuseppe Larosa Tue, 08/12/2008 - 22:24
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Marco,


you are playing with the newest toys.


New rules may apply:


http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1054759


Multichassis EtherChannels

Multichassis EtherChannel (MEC) is an EtherChannel with ports that terminate on both chassis of the VSS. These sections describe multichassis EtherChannels:


•Overview


•Failure Scenarios


Overview

Multichassis EtherChannel (MEC) is an EtherChannel with ports that terminate on both chassis of the VSS (see Figure 4-7). A VSS MEC can connect to any network element that supports EtherChannel (such as a host, server, router, or switch).


At the VSS, a MEC is an EtherChannel with additional capability: the VSS balances the load across ports in each chassis independently. For example, if traffic enters the active chassis, the VSS will select a MEC link from the active chassis. This MEC capability ensures that data traffic does not unnecessarily traverse the VSL.


Each MEC can optionally be configured to support either PAgP or LACP. These protocols run only on the active chassis. PAgP or LACP control packets destined for a MEC link on the standby chassis are sent across VSL.



Hope to help

Giuseppe

marcosaner Wed, 08/13/2008 - 00:44
User Badges:

Hello Giuseppe


Our two C6509 switches are still in standalone mode so we have no virtual switching system (VSS) in use and Multichassis EtherChannel (MEC)could only operate with virtual switching system (VSS)



#show switch virtual

Switch Mode : Standalone


Thank you for your help.

Best regards

Marco


Giuseppe Larosa Wed, 08/13/2008 - 09:23
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Marco,

at this point I would open a TAC case that traffic shouldn't be there.



Hope to help

Giuseppe

Actions

This Discussion