Solved: Re: "allowed vlans" on trunk limits transmit, receive, or both?

grnelson · ‎10-15-2010

Does adding an "allowed vlans" statement to a trunk limit the vlans transmitted on the trunk, received from the trunk, or both?

Jon Marshall · ‎10-15-2010

grnelson wrote:

Does adding an "allowed vlans" statement to a trunk limit the vlans transmitted on the trunk, received from the trunk, or both?

Both. It will limit the vlans trasmitted across the trunk but it will also drop traffic for a vlan not included in the allowed list.

Jon

View solution in original post

Jon Marshall · ‎10-15-2010

grnelson wrote:

Thanks, I believe you. My boss may not be satisfied. Can you

cite a cisco document that clarifies what "allowed vlans" does?

If your Boss knows so much about LAN Switching why did he bother asking you to find out

View solution in original post

glen.grant · ‎10-18-2010

I would always use the "add" parameter when adding new vlans to the list . Below is the answer I think you might be looking for.

STP Configuration Guidelines

If more VLANs are defined in the VTP than there are spanning-tree instances, you can enable STP on only 64 VLANs. The remaining VLANs operate with spanning tree disabled. If the number of VLANs exceeds 128, we recommend that you enable the MSTP to map multiple VLANs to a single spanning-tree instance. For more information, see the "Configuring RSTP and MSTP."

If 64 instances of spanning tree are already in use, you can disable STP on one of the VLANs and then enable it on the VLAN where you want it to run. Use the no spanning-tree vlan vlan-id global configuration command to disable STP on a specific VLAN, and use the spanning-tree vlan vlan-id global configuration command to enable STP on the desired VLAN.

Caution

Switches that are not running spanning tree still forward BPDUs that they receive so that the other switches on the VLAN that have a running spanning-tree instance can break loops. Therefore, spanning tree must be running on enough switches to break all the loops in the network; for example, at least one switch on each loop in the VLAN must be running spanning tree. It is not absolutely necessary to run spanning tree on all switches in the VLAN; however, if you are running spanning tree only on a minimal set of switches, an incautious change to the network that introduces another loop into the VLAN can result in a broadcast storm.

Note If you have already used all available spanning-tree instances on your switch, adding another VLAN anywhere in the VTP domain creates a VLAN that is not running spanning tree on that switch. If you have the default allowed list on the trunk ports of that switch, the new VLAN is carried on all trunk ports. Depending on the topology of the network, this could create a loop in the new VLAN that will not be broken, particularly if there are several adjacent switches that have all run out of spanning-tree instances. You can prevent this possibility by setting up allowed lists on the trunk ports of switches that have used up their allocation of spanning-tree instances. Setting up allowed lists is not necessary in many cases and can make it more labor-intensive to add another VLAN to the network.

Spanning-tree commands determine the configuration of VLAN spanning-tree instances. You create a spanning-tree instance when you assign an interface to a VLAN. The spanning-tree instance is removed when the last interface is moved to another VLAN. You can configure switch and port parameters before a spanning-tree instance is created; these parameters are applied when the spanning-tree instance is created.

View solution in original post

glen.grant · ‎10-18-2010

No you are not above 64 . What you are looking at is the just VTP advertisement telling you there are 102 vlans in the domain and as you see with your "manual" pruning" on the links only 9 are allowed across from the vtp server so that switch only has to allocate 9 stp instances in your case . So the switch could allocate 55 more spanning tree instances if it had to . For every new vlan that is allowed across the link your spanning tree instance on the switch decreases by 1 . This is only valid for manual pruning like you have done on the links . No it is not forwarding any other vlans other than what is allowed across the links...

View solution in original post

Jon Marshall · ‎10-18-2010

What causes a switch to create a spanning-tree instance? Receiving a BDPU, a Vlan-tagged packet, or both?

A switch will create an instance of STP for a vlan when -

1) the vlan exists on the switch. As you are running VTP server/client all vlans you create on the 6500 switch will be propogated to the CIGESM switches. As Glen says, VTP transparent can be used to avoid this

AND

2) there is an active port on the switch for that vlan. This can either be an access port that has a device configured which is in the up/up state

or

it can be a trunk link that allows that vlan. This is why using "switchport trunk allowed vlan.." limits the creation of STP instances on the switch assuming you do not have a port that is in the vlan connected to an end device.

Jon

View solution in original post

Jon Marshall · ‎10-15-2010

grnelson wrote:

Does adding an "allowed vlans" statement to a trunk limit the vlans transmitted on the trunk, received from the trunk, or both?

Both. It will limit the vlans trasmitted across the trunk but it will also drop traffic for a vlan not included in the allowed list.

Jon

grnelson · ‎10-15-2010

Thanks, I believe you. My boss may not be satisfied. Can you

cite a cisco document that clarifies what "allowed vlans" does?

Jon Marshall · ‎10-15-2010

grnelson wrote:

Thanks, I believe you. My boss may not be satisfied. Can you

cite a cisco document that clarifies what "allowed vlans" does?

If your Boss knows so much about LAN Switching why did he bother asking you to find out

grnelson · ‎10-15-2010

We had a serious network interruption last Friday. I added a Vlan to a 6509 VTP server. A number of IBM blade centers went down because the CIGESM switches were exceeding their limit of 64 spanning-tree instances. We had previously configured "allowed vlans" on the trunks between the 6509's and the CIGESM switches. That didn't help. CIGESM log messages indicated they were receiving vlan-tagged packets from the blades outside those in the allowed list.

So, we added "allowed vlans" to each blade trunk interface. That fixed it. However we were puzzled since we assumed "allowed vlans" only limited transmitted vlans. Blocking only vlans transmitted to the blades would not have stopped the spurious vlan traffic from the blades.

Thanks for your answer.

Jon Marshall · ‎10-15-2010

We had a serious network interruption last Friday. I added a Vlan to a 6509 VTP server. A number of IBM blade centers went down because the CIGESM switches were exceeding their limit of 64 spanning-tree instances. We had previously configured "allowed vlans" on the trunks between the 6509's and the CIGESM switches. That didn't help. CIGESM log messages indicated they were receiving vlan-tagged packets from the blades outside those in the allowed list.

Haven't worked on those blades so how do the CIGESM switches relate to the blades ?? Not sure what you mean when you say CIGESM log messages indicated they were receiving vlan-tagged packets from the blades outside those in the allowed list.?

Jon

grnelson · ‎10-15-2010

There are a pair of CIGESM running IOS 12.1 in each blade chassis. Each switch connects to each blade over a trunk and has four interfaces to the network. Here are some log messages showing the CIGESM complaining about Vlans received on the blade interfaces numbered G0/1 -G0/14:

y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to up
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to down
1y4w: %SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLAN5 (port Gi0/14).
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to up
1y4w: %SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLAN202 (port Gi0/1).
1y4w: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/17.
1y4w: %PM-4-ERR_DISABLE: loopback error detected on Gi0/17, putting Gi0/17 in err-disable state
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/17, changed state to down
1y4w: %LINK-3-UPDOWN: Interface GigabitEthernet0/17, changed state to down
1y4w: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/18.
1y4w: %PM-4-ERR_DISABLE: loopback error detected on Gi0/18, putting Gi0/18 in err-disable state
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/18, changed state to down
1y4w: %LINK-3-UPDOWN: Interface GigabitEthernet0/18, changed state to down

Jon Marshall · ‎10-15-2010

grnelson wrote:

There are a pair of CIGESM running IOS 12.1 in each blade chassis. Each switch connects to each blade over a trunk and has four interfaces to the network. Here are some log messages showing the CIGESM complaining about Vlans received on the blade interfaces numbered G0/1 -G0/14:

y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to up
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to down
1y4w: %SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLAN5 (port Gi0/14).
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to up
1y4w: %SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLAN202 (port Gi0/1).
1y4w: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/17.
1y4w: %PM-4-ERR_DISABLE: loopback error detected on Gi0/17, putting Gi0/17 in err-disable state
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/17, changed state to down
1y4w: %LINK-3-UPDOWN: Interface GigabitEthernet0/17, changed state to down
1y4w: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/18.
1y4w: %PM-4-ERR_DISABLE: loopback error detected on Gi0/18, putting Gi0/18 in err-disable state
1y4w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/18, changed state to down
1y4w: %LINK-3-UPDOWN: Interface GigabitEthernet0/18, changed state to down

So the CIGESM switches connect back to the 6500 switches ?? And the blade interfaces have to go via the CIGESM to get to the 6500 ?

Is that correct ??

If so on which interfaces did you have allowed vlan configured on ?

Jon

grnelson · ‎10-15-2010

Yes, that is correct. We had a similar problem where the blade switches (CIGESM) were exceeding their limit of 64 spanning tree instances about a year ago. At that time we added "allowed vlans" statements to both ends of the trunks between the 6509's and the CIGESM's. That solved the problem until last Friday. Adding another vlan to our vlan list caused havoc and the CIGESM's were once again exceeding their spanning-tree limit.

This time we copied the allowed vlan list to each blade trunk interface which corrected the problem once again.

No one can explain why the blades were emitting vlan packets for vlans not in the "allowed" list.

Jon Marshall · ‎10-15-2010

grnelson wrote:

Yes, that is correct. We had a similar problem where the blade switches (CIGESM) were exceeding their limit of 64 spanning tree instances about a year ago. At that time we added "allowed vlans" statements to both ends of the trunks between the 6509's and the CIGESM's. That solved the problem until last Friday. Adding another vlan to our vlan list caused havoc and the CIGESM's were once again exceeding their spanning-tree limit.

This time we copied the allowed vlan list to each blade trunk interface which corrected the problem once again.

No one can explain why the blades were emitting vlan packets for vlans not in the "allowed" list.

Unfortunately i had a quick look and couldn't find anything to corroborate what i said originally but i have seen the behaviour before so i'm sure that's the way it works.

You say you are using VTP server/client setup. How many vlans are there actually on the CIGESM switch ??

Jon

grnelson · ‎10-15-2010

Here is what is on our 6509 VTP server:

gcw-r65-5dgrn#sho vlan summ
Number of existing VLANs : 102
Number of existing VTP VLANs : 102
Number of existing extended VLANs : 0

This is from a CIGESM:

ibm-blade5-s2#sho vlan summ
Number of existing VLANs : 102
Number of existing VTP VLANs : 102
Number of existing extended VLANs : 0

The CIGESM's are VTP clients.

Jon Marshall · ‎10-15-2010

grnelson wrote:

Here is what is on our 6509 VTP server:

gcw-r65-5dgrn#sho vlan summ
Number of existing VLANs : 102
Number of existing VTP VLANs : 102
Number of existing extended VLANs : 0

This is from a CIGESM:

ibm-blade5-s2#sho vlan summ
Number of existing VLANs : 102
Number of existing VTP VLANs : 102
Number of existing extended VLANs : 0

The CIGESM's are VTP clients.

Okay, so 64 of those 102 vlans on the CIGESM either have a trunk with the vlan allowed on or an active port in that vlan. I say this because for an STP instance to be started on a switch the vlan must either be part of a trunk ot have an active port for that vlan.

The new vlan you added, is there any chance one of the blades was in this vlan or there was any active port in this vlan on the CIGESM ?

Jon

grnelson · ‎10-15-2010

BTW, this is the manual for the CIGESM switches.

http://www.redbooks.ibm.com/redpapers/pdfs/redp3869.pdf

It mentions the 64 spanning tree instances limit on page 133.

Unfortunately it doesn't tell you what the consequences might be of exceeding that limit.

glen.grant · ‎10-15-2010

Is it possible that you didn't use the add parameter which I think will allow everything across ? It should have been "switchport trunk allowed vlan add XX " . If you didn't use the "add" parameter by mistake (switchport trunk allowed vlan XX) I think it will allow everything which would then overrun the STP instances. Myself i would make the blades transparent and just create and allow what you need on the blades directly. This would avoid the issue you ran into . If you are going to manually prune the links with the switchport trunk allowed parameter , use it on both ends of the link, on the 6509 and the bladeserver switches... The switches will allocate a spanning tree instance for everything that is allowed across those links even if those vlans are not used on the blades.. Those blade server switches is basically a 2950 on a card .

grnelson · ‎10-18-2010

We enter the entire vlan list each time we configure the "allowed vlans".

I have another related question.

We had previously limited vlans on both ends of the trunks between the CIGESM switches and the 6509 switches using the "allowed vlans" statement.

The longest list had fewer than 20 vlans yet the CIGESM switch's log files were reporting they had already reached their limit of 64 spanning-tree instances. Log messages indicated blades were issuing packets for Vlans not in the "allowed" list.

What causes a switch to create a spanning-tree instance? Receiving a BDPU, a Vlan-tagged packet, or both?