Questions VLAN design best practices

[dariopalermo]

As per best practices for VLAN design:

1) Avoid using VLAN 1 as the “blackhole” for all unused ports.
2) In the local VLANs model, avoid VTP (use transparent mode).

Point 1

In a big network, I'm having VLAN 1 as the blackhole VLAN. I'd like to confirm that, even if we're not complying with best practices, we're still doing fine.

a) all trunk ports on all switches have the allowed vlans explicitly assigned.

b) about all ports on all switches are assigned to specific data/voice vlans, even if shutted down

c) the remaining ports (some unused sfp ports for example) are shutted down

d) we always tag the native vlan (vlan dot1q tag native)

So, no data is flowing anywhere on VLAN 1. In our situation, it is safe to use VLAN 1 as blackhole VLAN?

Point 2

Event if we're using local VLANs model, we have VTP in place. What are the reasons of the best practice? As already said, we allow only specific VLANs on trunk ports (it's part of our network policy), so we do not have undesired layer 2 loops to deal with.

Any thoughs?

Bye

Dario

[Bilal Nawaz]

Hello Dario,

I'll probably just express my opinion on your points. Depending on who you talk to there are rights and wrongs.

1) Using vlan 1 as the "blackhole" vlan is frowned upon due to the very fact that it is "default" vlan id that everyone knows about. Putting ourselves in the shoe's of a hacker, the first vlan that we'll try to get on is the default vlan - vlan 1. So in that case having the vlan ID a bit more difficult to guess on first attempt is a start. I mean if we are talking about no tagging on the native vlan, then there is no need for this anyway. The other points a,b,c and d seem fair enough.

2)VTP is on my default to my recollection. To turn it off we require to do switchport nonegotiate. The reasons for the best practice is Joe Bloggs comes in the office with his new shiny cisco switch and plugs it on the network. Now he can plug more of his devices in to. With config or no config on that port, if measures are not taken to protect against this, it could allow some sort of access to the network and the infrastructure, or enable someone to sniff/listen out on the various vlans that so happen to stretch to this new switch.

I guess if you explicitly shut ports down the ones that arent being used you are "kinda" safe from that. Another could be bpduguard.

Hope this helps

Bilal

[dariopalermo]

Hi Bilal, thanks for answering!

1) Ok, if that's all I think I'll keep my current design

2) "switchport nonegotiate" command prevents the interface from generating DTP frames. It's not VTP related afaik. VTP sends frames only on trunk links, but you use "vtp mode transparent" to virtually disable VTP. In a local VLANs design the need to have a full propagated VLAN database is not so strong. Still, we like to have all VLANs in the database of every switch to simplify port-to-vlan assignment. Is there any reason to avoid VTP in our design? Or maybe there are just some precautions to take in case we keep it?

[Bilal Nawaz]

ah! my bad, I completely got mixed up, and didnt think about it and let my hands to the typing. Normally with my security hat on its DTP that is a concern.

VTP, best to have transparent mode, I'd like to think of it as, you are the admin, you configure exactly what you require instead of letting VTP do its thing. I guess if you have a small network, VTP will work OK, in a bigger network, it is not advisable due to unnecessary broadcast traffic etc...

hth

Bilal

[dariopalermo]

No prob! ;)

Just because you put the topic on the table, I've got all ports in trunk or access mode. I'm not disabling DTP in my design because my switches, with the config ahead, will not get fooled by others. They just reply in case of a dynamic desirable port get connected to one of thei port.

For VTP, we have a very large network with A LOT o local VLANs. We either use a big excel or use VTP with meaning names for every VLAN. We went for the latter and it seems to work. I'm trying to understand possible concerns in terms of security and all.

Bye

Dario

[Jon Marshall]

Dario

Just a thought on VTP.

If you are going to the trouble of only allowing certain vlans on each trunk port then what do you when you create a new vlan ?

I ask because if you are not running transparent then it will be created on all your switches but then as you only allow certain vlans on the trunks it seems pointless having vlans that aren't allowed on the trunk to be in the vlan database.

It's not so much a security concern as efficiency ie. a switch runs an instance of STP for each vlan it has in it's database (unless you are running MST).

The one main concern with VTP (versions 1 and 2) as you run it is that a client switch added to the network with a higher revision number than currently in use can overwrite the vlan databases of all your switches.

It doesn't mean you can't use it, just something to be aware of.

Some people have strong opinions on VTP ie. you should always use transparent etc.

I wouldn't go that far and in a large environment with a lot of vlans it can be useful but it really comes down to how much control you want over which vlans are on which switches.

Jon

[dariopalermo]

We are currently using VTP version 3 and migrating from Rapid-PVST to MST.

The main reason for having VTP in place (at least for use) is to have the ability to assign ports to the correct VLAN in each site simply looking at the propagated VLAN database and to manage that database centrally.

We also avoid using the same VLAN ID at two different sites.

However, I did find something to look deeped: with MST and VTP, a remote switch can be root for a VLAN it doesn't even use or as active ports into, and this doesn't feel right.

An example:

1) switch1 and switch528 share a link with allowed vlan 100

2) switch1 is the root for instances 0 and 1

4) VLAN 100 is assigned to instance 1

5) VLAN 528 is not assigned to any particular instance so it goes under instance 0

6) VLAN 528 is the Local Data LAN for switch528 (switch501 has VLAN 501)

swtich528#sh spanning-tree vlan 528

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    24576
             Address     1c6a.7a7c.af80
             Cost        0
             Port        25 (GigabitEthernet1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     1cde.a7f8.4380
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1               Desg FWD 20000     128.1    P2p Bound(PVST)
Gi0/2               Desg FWD 20000     128.2    P2p Edge
Gi0/3               Desg FWD 200000    128.3    P2p Edge
Gi0/4               Desg FWD 200000    128.4    P2p
Gi0/5               Desg FWD 20000     128.5    P2p Edge

switch1#sh spanning-tree vlan 501

MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    24576
             Address     1c6a.7a7c.af80
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24576  (priority 24576 sys-id-ext 0)
             Address     1c6a.7a7c.af80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------

Should I worry about this?