2960x

VLANs were used to segregate users back in the early 90s before WIndows NT enabled admins to properly do authentication and authorisation.

You can use your AD with RADIUS to authenticate switch managers.

Is there a particular reason you want to fiddle with access lists? How does this help people who *do* need access to manage the switch? Are you going to have to fiddle with their IP addresses to make them static? All a bit fiddly, don't you think?

As far as the ports go, do a show interface brief or a show ip int to get a full list, you should be able to tell from the interface name what it is. You can have many many interfaces that aren't related to the interfaces you can see on the outside - port-channels, SVIs, Loopbacks being some of them.

So how would you secure your management VLAN my thought was to put management traffic on VLAN60 this is in readiness for VSphere where hosts would sit in VLAN60

Looks like you do not have a lot of experience in this field and trying to learn.
That is ok. We can't design your network for you, but we can help you to get there.
Cisco makes a set of very good design guides which will give you the general idea's,
and specifics on how to get things done. Take a look at this link

Actually I do have experience in this matter but asked the question how would you secure your Management VLAN i.e access list for the whole vlan or just the vty ports ?

Attached is my config and VLAN database so I have to assign a ACL to the VTY interface to allow only IT Personnel and assign the ports in to the users vlan or factory.

Expect the uplink to the switch which needs to be a trunk to allow all vlans back to the router which is subinterfaced with all vlans ?

or you know like vince said up thread:

setup radius server - and since you mentioned you are running VMs it shouldn't be too hard to spin it up .
create a group in radius server that are allowed access to your switches.

setup authentication, authorization and accounting on your switches so that only the correct people can login to it.


in general, management vlan should not be pushed through the same network/devices as the rest of your networks.
i usually use a 3750x stack for the 'core' of the MGT network, and then plugin to the MGT port of all my switches, routers, etc..
this way there is one way to get into the rest of my MGT network and that is through a routed network where i control via access-lists.

again since you have virtualization you could create a couple of workstations that have static addresses. your IT staff would RDP into those workstations and from there access the MGT network. Radius would be used to log and allow access to each individual device. and a proper syslog service would be up and running to keep track of who did what...

**excuse bad spelling/ grammer i haven't slept for awhile.


We must go always forward, not backward
always up, not down and always twirling twirling towards infinity.

Is it right to use a seperate vlan for management traffic, i.e I dont want to use the management ports as all of these would have to go in to a hub then to a dedicated pc, my thinking was vlan 40 for management traffic acl on there to allow 2 ips of it to access the management v lan

Separation is definitely good, and I always at least suggest a separate management VLAN.

Dumb ACLs are not so good. They are a very blunt weapon that create extra work for you without giving you much control.
Every device on your network should have its access locked down via policies managed by a central directory, ie, AD. That includes workstations, servers and network infrastructure.
Your Windows server has Radius already built into it, you just need to turn it on, create some groups, etc...

Imbadatthis describes a management network that is actually airgapped on dedicated infrastructure - you don't need a separate PC for this, your air-gapped management network is just another "Zone" (like DMZ, LAN, GUEST, etc...) which you connect to your gateway for security (which consists of much more than ACLs).
This option is for the larger environment.