Re: Manipulating allowed VLAN list on trunks

Kevin Dorrell · ‎09-30-2005

I am in the process of restricting some of my VLANs so that they can be accessed only on the switches that actually need them. I have a VTP domain, so I am doing it by manipulating the "allowed" lists on the trunks. I have a mixed environment of IOS 4500, CatOS 4000, CatOS 5500, and IOS 29xx.

So, I have a number of questions and observations:

1. There are some special default VLANs, 1002-1005, which are designated fddi-default, token-ring-default etc. In an Ethernet-only environment, is there any harm if I clear these from all the trunks?

2. I do not use the extended VLAN range 1025-4095. Is there any harm if I clear these from all trunks?

3. Just out of academic interest, what ever happened to VLANs 1006 to 1024? They do not appear in any of the default "allowed" lists. Are they reserved for something?

4. Suppose my native VLAN for my trunks is not 1, let us say 99. And my management is on yet another VLAN, say 98. What happens if I try and clear the native VLAN 99 from the trunks? (Yes, I know I should try this in a lab, but does anyone know the answer to save me the effort of setting it up?)

5. Suppose I have a VLAN, say 50, that is only needed in two switches, so I clear it from all trunks except the one between those two switches. But all the switches know about it cos it is in the VTP list. I notice that in the IOS switches, the PVST+ instance for that VLAN get shut down. In the CatOS switches, the STP seems to continue to run, but the root bridge is designated as 00-00-00-00-00-00. Are these two behaviors consistent, i.e. what is actually going on in the CatOS case? (AAMOF, in the IOS switches, it is enough that none of the ports has an "up" presence in the VLAN, and the PVST+ instance shuts down, even if there are "down" ports configured to use it.

6. Is there any way to set a global default "allowed" list in a switch, so that any new trunks only allow those VLANs, regardless of what is in the VTP list? (That is, apart from setting it to "transparent", which have other unwanted side effects such as not being aware of the creation of new VLANs.)

That's a lot of questions. The new edition of the Clarke/Hamilton book is well overdue!

Kevin Dorrell

Luxembourg

glen.grant · ‎09-30-2005

Hi Kev, try to answer some of these.

1. No harm whatsoever clearing 1002-1005.

2.No harm clearing extended vlans.

3. Have no idea !!!!!

4. Wouldn't think anything would happen if clear 99 as long as your management vlan is active across it .I guess the question would be why was it 99 to begin with ??

5. I think what you are seeing is normal. To get good a good idea you have to look at the Server side to see what is active and what is being allowed down at the access switches , looking at the access switch trunk parameters can be confusing in a client/server setup. If you have a vlan and it is allowed down the trunk but no one is using it then the switch prunes the vlan off .

6. Can't say i know of any way to do that . If you find out differently you should post it here . Can't say I have ever needed that though.

Kevin Dorrell · ‎09-30-2005

Glen,

Thanks for the responses.

1. I shall clear them out immediately.

2. I shall clear them out immediately.

3. It's a mystery. Anyone?

4. It was 99 because that VLAN was created specifically to accommodate the trunks. Unfortunately, in that particular network, VLAN 1 was still in use as an access VLAN. It is recommended not to have any access ports on the VLAN that is used as the native on the trunks, to prevent VLAN-hopping. Most NetAdmins do this by putting all the access ports anywhere but VLAN 1, and keeping VLAN 1 for trunk natives and/or management. This network did it the other way round, by shifting the native of the trunks off onto an unused VLAN. But I don't know what would happen if I cleared the native VLAN off the trunk.

5. I think here we need to distinguish between VTP and STP, and between allowed lists and pruning. I am not pruning here, I am actually clearing the VLANs from the trunks. In the case of pruning, the VTP declines to send the broadcasts down the trunk if they are not useful at the access layer switch, but the Spanning Tree topology is not affected. In the case of clearing, the Spanning Tree topology of the VLAN is actually modified, as if the trunk did not exist for that VLAN. OTOH, the VTP VLAN list is propagated to all switches, regardless of whether they have any presence on each VLAN. So according to the VTP server and all clients, there is a load of VLANs active in the domain. But if you have an allowed list on all the trunks, it could well be that the access switch knows about a VLAN, but does not have any presence on it. That is when the IOS shuts down the PVST+ STP for that VLAN, and a CatOS switch registers the root bridge as 00-00-00-00-00-00. As opposed to the case where the VTP domain does not have a VLAN in its database, so the CatOS has no STP instance for it.

6. Anyone else?

Thanks for the responses.

Kevin Dorrell

Luxembourg

amit-singh · ‎09-30-2005

Kevin,

1. You can clear these vlans but it wont make much difference as these are reserved vlans and unless you configured them for FDDI/TOKENRING there will be no STP instance of them.

2. You can clear extended range vlans if you dont have running on your n/w.

3. I studied a long way back somewhere in a DOC that these are reserved vlans which are reserved by Cisco for future use.

4. No issues with that as far as you native Vlan is not 1.

5. You have already point it out. Prunning will not take the STP instance out of the trunk but allowed/remove list does.

6. No such feature available yet.

regards,

-amit singh

Kevin Dorrell · ‎10-03-2005

Amit,

On issue 4, I tried it today. I configured a trunk with an allowed list that did not include the native VLAN (99). As you said, no problem. As I understand it, when a trunk port receives a frame tagged with a VLAN that is not on its allowed list, then it should discard it. But if you clear the native VLAN from the trunk, what does that mean - I guess it means that the switch will discard all untagged frames. And that is precisely what I was trying to achieve by putting the trunk on native 99 in the first place - to discard dangerous untagged frames.

Kevin Dorrell

Luxembourg

amit-singh · ‎10-03-2005

Kevin,

You are right about clearing the native vlan. Native vlan carries untagged frames over the trunk links. So the moment you take the native vlan out of the trunk you all the frames will be tagged and no untagged frame passes over the trunk link.

Cheers :-)

-amit singh

Kevin Dorrell · ‎10-07-2005

I just found out the hard way that there a danger in clearing the native VLAN off a trunk (where the native VLAN is not 1). That is: if you clear the non-1 native VLAN from a trunk, then the switch is no longer able to receive and process PVST BPDUs for VLAN 1, even if VLAN 1 is allowed on the trunk. I'm sure you can image that this could be disastrous if your switch has two uplinks, and you clear the native VLAN off both trunks.

In fact, I think this principle is important enough to warrant a new thread to see if anyone can explain what exactly is going on.

Kevin Dorrell

Luxembourg

Kevin Dorrell · ‎09-30-2005

Thanks both for the replies.

Regarding VLANs 1002-1005, there is a complication: most of my switches allow me to remove them from a trunk, but some do not. IOS on 4503, CatOS on 4003, and IOS 12.0(5)WC3b on WS-C2912-XL are all OK with removing them. But IOS 12.1(6)EA2b on WS-C2950-12 is not ... it gives "Command rejected: Bad VLAN allowed list." I wonder why?

Also observed that IOS on 4503 treats the VLANs as a continuous block - there is no hole from 1006 to 1024. Again I wonder why?

Kevin Dorrell

Luxembourg

amit-singh · ‎09-30-2005

I think the IOS is too old on your 2950 and it doesnot support taking those vlans out of it. I am pretty sure this is available in new IOS.

Dont sure abotu your second question :(

regards,

-amit singh