Hello ALL!!!

We have our aggregation layer here composed of two N7K with vPC between them. Every access switch is a N5K. Security policies state that we have to filter unnecessary vlans going through the trunk between N5K and N7K. So we use the 'switchport trunk allowed vlan 10,20,30' command. My question is:

Do I have to include the native vlan id on this command?

_________________
[]s
Rafael Bianco

Keep calm and don't forget to be awesome!!!

Yes.

_________________
som om sinnet hade svartnat för evigt.

srg,

And we have another policy that states that we have to change vlan 1 to vlan 402. Is there a offical paper explaining this (that it's mandatory that we have to include the native vlan id on the 'switchport trunk allowed vlan 10,20,30' command)?

_________________
[]s
Rafael Bianco

Keep calm and don't forget to be awesome!!!

Just to add... I found this 2 articles:

1- https://supportforums.cisco.com/thread/2157701
2- https://learningnetwork.cisco.com/thread/13009

In my understanding, even if you don't permit the native vlan, trunk negotiation (DTP) and CDP will still occur. The problem is if you try to have any client running on the native vlan.

_________________
[]s
Rafael Bianco

Keep calm and don't forget to be awesome!!!

Well, this was the closest I could get: http://www.cisco.com/en/US/docs/switche ... #wp1206651
The native VLAN has to be in the allowed vlan list for transit traffic to work, though other management functions as CDP etc will still work in VLAN 1 even if you dont allow the native VLAN.

edit; fixed error.

_________________
som om sinnet hade svartnat för evigt.

1) Your policy is broken. Leaving the native VLAN as "1" is perfectly fine, so long as nothing uses VLAN 1. The number is meaningless.
2) If you have clients using VLAN 402, then you better allow it on the trunk. If nobody is using it, then there's no reason to allow it.
3) If you change the native VLAN from "1" to something else, then CDP etc will still work, but it will be tagged with 1, whether you allow VLAN 1 on the trunk or not.

I think this clears most of your questions: http://www.cisco.com/en/US/customer/pro ... shtml#pre6

_________________
som om sinnet hade svartnat för evigt.

you can also use vlan pruning and have the vlans add/remove as needed automagically.


also on the vlan trunking thing, best practice is to place an unused vlan at the native
between the two switches, to limit the scope of the traffic,

so i trunk 10,20,30 use 100 as native in the configuration, vlan100 is not defined on either device.

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw

why not leaving native vlan in default setting (1)? There wouldnt be any difference, wouldnt it?


VLAN pruning has a VERY high risk of taking down a big network by a single configuration error. Even with hundreds or thousands of switches it is best practise IMHO to configure allowed vlans manually or by management software with limited reach.

_________________
kindly regards
Poison Nuke

www.poisonnuke.de

This is the second time Ive seen you bring this up in the past few days and its an interesting thought to me as Ive always just been taught to never use vlan 1. So i thought I'd spend a couple cycles thinking through this.

The only risk I see with this is your native (untagged) vlan is the same vlan that control traffic (CDP/DTP/STP etc...) resides on.

So even if VLAN 1 is pruned from the trunk, control traffic still uses vlan 1. Not knowing 100%, thinking through it I would think an untagged frame would still be able to pass to the switch on vlan 1, if generated correctly. So that leads me to wonder how control traffic is differentiated over normal user traffic??? Is it marked (CoS 6 or 7), or sourced from a special control plan interface, or is there some other magic that happens under the hood???

So with that thought in mind i would assume if you can generate a false control packet destined to a switch without a tag and marked as a control packet then wouldn't the switch process the frame as control traffic and then maybe send that frame out all trunk interfaces towards other switches?

I guess I need more information on the logic of how control traffic is handled... or Im just thinking myself off the deep-end and need to move back to reality

Sorry for jacking the thread...

_________________
http://blog.movingonesandzeros.net/

Well, I said it's fine so long as *nothing* (user traffic) uses VLAN 1. There's a legacy VLAN traversal attack where that's not true: allowing trunks to use an access VLAN is dangerous there. The way I usually configure things, the only traffic that goes untagged is control traffic.

I think you'll find that you're unable to put an untagged frame onto such a trunk if VLAN 1 is prohibited from all trunk interfaces, and has no access ports.

It's magic - you can prohibit user traffic, but not CDP, etc...

First the attacker is going to have to get the bogus packet into VLAN 1 - quite a trick from an access port on VLAN not-1. Then the attacker will have to deal with the fact that most of this control plane traffic is addressed to special non-bridgable L2 addresses.

Assuming those hurdles are past, what difference does changing the native VLAN make? If we can VLAN-hop from not-1 to untagged-1, surely we can VLAN hop from not-1 to tagged-1

...and then there's that other category of control traffic that unlike CDP and friends (always VLAN 1), always goes untagged. Changing the native VLAN does nothing to, say, DTP.

It's all just a bunch of extra typing in my opinion.