“At work I've got a cisco
3750 switch and few end devices which of course are company proprietary,
connected to this switch in a separate VLAN. Now these end devices generate
dhcp traffic "request" and is being propagated across all the sites
where these devices are connected.
Now I've been reading
stuff about dhcp snooping features which is great but in this instance these
end devices don't have a DHCP server. In this scenario all these end end devices
have got static ip addresses allocated.
Also my senior engineer
being very narrow minded wants me to implement this change only on the
interface level and not on the configuration level.
Can someone please confirm
if I can just only enable "ip dhcp snooping trust" on the interface
level which i believe will stop the dhcp traffic?”
The above question is about DHCP snoopingconfiguration. Here we will list some related tech tips and examples to give a
response.
Every example in the response post has been
tested in a lab environment with a Cisco 3550, Infoblox DHCP servers, a Netgear
router as a "rogue" dhcp server, and a MacBook Pro as a client. The
3550 is configured with ip routing and a layer 3 interface on the subnet where
the DHCP servers are located (10.0.10.0/24). VLAN 20 has been created on the
3550 with an interface ip address of 10.0.20.254/24. All the DHCP server
configuration and helper addresses were tested and working prior to
implementing DHCP snooping to eliminate any doubt as to whether the DHCP
snooping configuration is working or not. So, let's get started.
For DHCP snooping to work, you have to
enable it globally. That is done with the following global configuration
command:
Switch(config)#ip dhcp
snooping
You also have to tell the switch which
VLANs to monitor. In a production environment, this would be the client VLANs,
not a transit VLAN that leads to the rest of the network. This is done with the
following command:
Switch(config)#ip dhcp
snooping vlan 20
At this point DHCP snooping is configured
and enabled. There are several default settings that can be modified later, but
that can be delt with after we verify things are working. Here is the basic
show command to verify DHCP snooping is working (specifically the top few lines):
Switch#show ip dhcp
snooping
Switch DHCP snooping is
enabled
DHCP snooping is
configured on following VLANs:
20
DHCP snooping is
operational on following VLANs:
20
DHCP snooping is
configured on the following L3 Interfaces:
Insertion of option 82 is
enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted
port is not allowed
Verification of hwaddr
field is enabled
Verification of giaddr
field is enabled
DHCP snooping trust/rate
is configured on the following Interfaces:
Interface Trusted Rate limit (pps)
------------------------ -------
----------------
Once you verify DHCP snooping is working,
you can verify DHCP lease information starts to populate the DHCP snooping
binding table on the switch with the following command:
Switch#show ip dhcp
snooping binding
MacAddress IpAddress Lease(sec) Type
VLAN Interface
------------------ --------------- ----------
------------- ---- --------------------
AA:2C:DD:09:D1:CD 10.0.20.28 28781 dhcp-snooping 20
FastEthernet0/13
Total number of bindings:
1
If you have a DHCP server plugged into a
switch with DHCP snooping enabled, or if you have a layer 2 LAN port connected
to an upstream switch where the DHCP server resides, you'll have to trust that
port. To do this, enter the following command in interface configuration mode:
Switch(config-if)#ip dhcp
snooping trust
Any DHCP responses that come from an
untrusted port (all the other ports) will simply be dropped without any
notification. To test this out, after this was all configured and working, I
connected a Netgear router with DHCP enabled into another VLAN 20 access port
on the 3550. I forced a DHCP request to be sent out by the client and nothing
happened. No log messages or warnings, nothing. Just to be sure the rogue DHCP
server was working; I disabled snooping and unplugged the 3550 uplink to the
production network. The client received a 192.168.1.2 ip address immediately. I
released the IP, reconfigured snooping and tested again. The client received an
IP from the authorized DHCP server and nothing happened with the fake DHCP
server port.
I wish the switch was smart enough to put
the switch-port connected to the rogue DHCP server into err-disable mode, but
at least it stops the unauthorized DHCP server from actually handing out IP
leases.
This concludes the basic DHCP snooping
configuration. For additional information regarding DHCP snooping configuration
options, check out these links:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/relea...
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/12ew/conf...
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/na...
Also, for reference, here are the relevant
parts of my 3550 lab configuration:
interface FastEthernet0/1
description Layer 3 uplink to production
network
no switchport
ip address 10.0.10.253 255.255.255.0
speed 100
duplex full
!
interface FastEthernet0/12
description Rogue DHCP server
switchport access
vlan 20
switchport mode access
spanning-tree portfast
!
interface FastEthernet0/13
description Client
switchport access
vlan 20
switchport mode access
spanning-tree portfast
!
interface Vlan20
ip address 10.0.20.254 255.255.255.0
ip helper-address 10.0.10.106
ip helper-address 10.0.10.107
One final thought. If you are rolling this
out into production, be sure to do so during a change window and test a client
DHCP request with ipconfig /release and ipconfig /renew to be sure it can get
an IP address and it shows up in the binding table.
Notes: This configuration was tested in a lab environment. If you use this
configuration to modify a production environment, you do so at your own risk.
The information in this post is provided as an example so you can custom tailor
it to your own network. Don't blame me if this information is misused and
causes an outage to production systems.
More
Related Cisco Tech Tips:
Thanks for sharing poe switches
ReplyDelete