I am working in a environment that is classed as collapssed Layer 3 environment. We have a core 6500 with routed links to 3560's which are access switches.
We have layer 3 vlans on the access switches, one for data one for voice.
On the layer 3 vlans we have ip helper addresses that are used for DHCP. The DHCP servers are located on the 6500.
I recently had a incident where someone plugged a netgear router into a desk point because they thought they could use it for a switch. This router then started to dish out IP addresses to people in the morning for those who came in and docked their laptops. 99% of people weren't affected because they have desktop PC's are their leases hadn't expired.
Now we have bpduguard, bpdufilter to prevent people from plugging in switches that send out BPDU's. However this doesn't prevent the above senario where someone plugs a router or a 'dumb' switch that doesn't send BPDU's.
Because of the above senario I started looking at DHCP Snooping, but I am unsure on a couple of things.
With the topology of our network I understand that I don't need to configure IP DHCP Snooping Trust on the L3 uplinks to our core switch. From what I understand I just need to enable IP DHCP Snooping globaly and then on the VLAN's on the access switch (because of the L3 topology VLAN's are local to the access switches). Only if I had L2 uplinks to the core would I need to configure IP DHCP Snooping Trust on the trunk links.
Can anyone confirm if my understanding is correct, or perhaps provide further info for me. Most examples/configurations I have seen are for L2 configurations only.
To my best understanding, your judgement of the situation is correct. As the trusted DHCP state is configured only on switchports and not on routed ports, you should be fine with simply activating the DHCP Snooping globally and on selected VLANs, but you should not be required to configure any port as trusted port.
Testing out this configuration should be largely easy because after activating the DHCP Snooping, the worst thing that can happen is your clients becoming unable to obtain their IP config via DHCP - but as this operation is performed infrequently, your clients should not notice anything during your testing period if performed swiftly.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...