cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
557
Views
8
Helpful
15
Replies

native vlan

harinirina
Level 1
Level 1

Hi all,

Its seems it is always recommended to not use the native VLAN

to send user traffic

We'd like to know if when using only one switch, all users are on one network, do we need to create other vlan than vlan 1 for users?

and what about vlan for management ?

15 Replies 15

adamclarkuk_2
Level 4
Level 4

Hi

The native VLAN can be changed to whatever VLAN you want and is only a factor on trunks links using 802.1q for encapsulation. As you only have one switch, you will not have any concept of the native VLAN in your network.

You will have all your ports in VLAN 1 which is native by default.

It is still best practice to create another VLAN rather than use VLAN 1 but you don't need to do this.

I would recommend in your case that you do create 2 VLAN's, one for your data and one for you management as this will aid with scalability later on when your network grows.

Here is a VLAN security document which includes the use of VLAN 1 :-

hxxp://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f

Jon Marshall
Hall of Fame
Hall of Fame

Agree with Adam on this. Best practices from Cisco regarding this are

1) Native vlan should be a vlan in which there are no user ports and this vlan should not be used for management. It should not have a L3 vlan interface because there is no need to route the native vlan.

You can go one step further and tag all vlans including the native vlan.

2) Vlan 1 should be used for nothing. You can shut vlan 1 L3 interface down. It should not be used for management or user ports. Note that some Cisco protocols CDP/PaGP etc. will still use vlan 1 - you can't stop this.

3) Select a separate vlan for managing your switches. No user ports should be in this vlan.

Jon

Hi all,

When you say

"Select a separate vlan for managing your switches. No user ports should be in this vlan",

Do you mean only the port of PC from which management is done should be affected to this vlan management?

Exactly

Actually no i didn't mean that. There are 2 ways you could do this

1) As you say have a PC allocated into the management vlan

OR

2) More commonly, the PC from which you manage the switches is in a different vlan but you can use acl's on the either the management vlan L3 interface or on the vty lines to restrict access to certain IP addresses.

You could also use a combination of the 2 ie.

you have one PC for management that is either on the management vlan or is on a different vlan. You then restrict access to the management vlan from this PC only.

Then you can use RDP or some such to allow access to this PC from other PC's. This gives more flexibility as you may need to manage the switches when you don't have physical access to the management PC.

Jon

Hi

Sorry I misread the post.

I thought he was saying the interfaces that the servers/devices are managed from not a management Server.

I still firmly beleive that it is a good idea to have managment traffic seperate from general use.

Adam

To be honest after re-reading the question again i'm not entirely sure what was meant :-).

I agree that the optimal solution is to have management traffic completely separate from general use but how you do this does depend on your budget. So you could have a completely separate physical infrastructure for managing both routers/switches and servers altho obviously this can be expensive !

Or you only access the devices from within the management vlans but this can be a bit restrictive.

Or you allow user vlans access to the management vlans or more specifically certain IP addresses or username/password if you want to use something like 802.1x. This is probably the most flexible but also most prone to security issues.

Think we are both strongly agreeing on this one :-)

Jon

Hi again,

Let's suppose we have one switch which has 24 ports. The switch is configured with 3 vlans.

Vlan 10 : network1 - port 1 to 8

Vlan 20 : network2 - port 9 to 16

Vlan 30 : network3 - port 17 to 24

To assure the seurity of the switch, do you mean we need to create another VLAN? let's say VLAN 40.

1 - So, should be the switch managed from that VLAN 40?

2 - Or should we manage the switch from one of these 3 Vlans and apply ACL?

You create another vlan for managing the switch. If it is a layer 2 switch you

1) shutdown vlan 1 interface

2) create vlan 40 at layer 2 on switch

3) create a L3 vlan interface for vlan 40

4) assign an IP address to L3 vlan 40 interface

5) assign a default-gateway which is where vlan 40 is routed off - usually either a router or more commonly a L3 switch

If it is a L3 switch just create vlan 40 and a L3 SVI.

You never need to allocate any port into vlan 40 altho you may well need to allow vlan 40 across your trunk links.

Jon

Hi,

We do the test on a L3 switch.

vlan 40 has been created and assigned an address, "ip routing" has been activated.

it seems the protocol of vlan40 stays down as long as it is not affected to any switch's port. The status is up but the protocol down.

we tried to assign it to one port connected to a pc and it the protocol becomes up.

what should we do?

For a L3 vlan interface to be up/up you need either

1) an active port in that vlan on the switch

2) a trunk link on that switch that includes vlan 40.

If you don't have a trunk link on this switch then you cannot use vlan 40 without allocating a port into it. A common setup is to have a number of switches connected via trunks - then you can use a vlan for management without actually allocating any ports into that specific vlan. But like i say, if you don't have a trunk link on the switch you will have to allocate a port into vlan 40.

Jon

Thanks both for your reply

Adam,

Could you please send again the URL about VLAN security document which includes the use of VLAN 1 ?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco