Preventing rogue devices - technical instr. + policies?!?

Hi, everyone,

I am trying to put together a set of [technical] instructions, and associated policies, for how to "plug in" various network devices, by non-network people. The problem I am facing is that we are supporting a Cisco infrastructure, setup by my group, where some of our users have access and are required by the nature of their job, to "play" with various Cisco devices. Problems we have encountered, so far:

- rogue device plugged in, and giving away DHCP addresses;

- rogue switch setup "by mistake" with the same VTP domain as the production network, but with a higher version number (as it's been played with, quite extensively), thus killing the real VTP server;

- rogue access point, giving away addresses all over, or passing through clients, to our production DHCP; ... and on, and on ... you get the picture.

We have looked at the most obvious things: "police-ing" the network for new devices being plugged in , port security in each connection in the labs, engineering areas, etc., all with a lot of admin overhead. As an example - the problem with port security (including possibility of 802.1x usage) is that the development groups (our users) need a lot of "freedom", so I am trying to figure our if there is a good balance between our need to keep networks running, the need to keep our resources within reasonable limits, and their need to "screw around".

Any recommendations, links, etc. will be greatly appreciated. I am pretty sure there is no easy solution for this, but picking other people's brains may help :) I guess one simple question would be: how do Cisco NetAdmins work with their development groups?!?

TIA, Papi

Reply to
Papi
Loading thread data ...

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.