Cart
In part three of this series we looked into how DHCP Snooping works on multiple switches for the hosts in the same (V)LAN. This time, we’ll take a look into how DHCP Snooping affects the networks that utilize DHCP Relays.
As a quick reminder, the diagram below shows the network we’re working on.
These are the relevant configurations on added switches and routers.
Cat1:
interface range FastEthernet0/1 , FastEthernet0/4 switchport access vlan 14 switchport mode access spanning-tree portfast ! interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate !
Cat2:
interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate !
R1:
interface FastEthernet0/0 ip address dhcp !
R4:
router ospf 1 router-id 4.4.4.4 ! interface FastEthernet0/0 ip address 192.168.14.4 255.255.255.0 ip helper-address 192.168.145.5 ip ospf 1 area 0 !
R5:
router ospf 1 router-id 5.5.5.5 ! interface FastEthernet0/1 ip dhcp relay information trusted ip address 192.168.145.5 255.255.255.0 ip ospf 1 area 0 ! ip dhcp pool 145-Net network 192.168.145.0 255.255.255.0 !
I included only the relevant changes since the previous article in the series. Everything that was configured at the end of Part Three still remains configured. As far as DHCP snooping is concerned, the feature is enabled on Cat2 and Cat3 globally, as well as on VLAN 145. Remember that we also turned off the insertion of the DHCP Option 82 on Cat2.
Cat2:
Cat2#show ip dhcp snooping Switch DHCP snooping is enabled DHCP snooping is configured on following VLANs: 145 DHCP snooping is operational on following VLANs: 145 DHCP snooping is configured on the following L3 Interfaces: Insertion of option 82 is disabled 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) ------------------------ ------- ---------------- FastEthernet0/20 yes unlimited
Cat3:
Cat3#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
145
DHCP snooping is operational on following VLANs:
145
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)
------------------------ ------- ----------------
FastEthernet0/5 yes unlimited
Cat1 is at this moment in the default state as far as the DHCP Snooping is concerned; that is the feature is disabled both globally and on all the VLANs.
Cat1:
Cat1#show ip dhcp snooping
Switch DHCP snooping is disabled
DHCP snooping is configured on following VLANs:
none
DHCP snooping is operational on following VLANs:
none
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)
------------------------ ------- ----------------
I’ll configure SPAN session on Cat3 to capture the DHCP Discover packets as they arrive to Cat3 from R4 and see how they look like. After this, I will bounce the interface Fa0/0 on R1.
Cat3:
monitor session 1 source interface FastEthernet0/4 both monitor session 1 destination interface FastEthernet0/15
This is what our Wireshark captured.
No. Time Source Destination Protocol Info 1 0.000000 192.168.14.4 192.168.145.5 DHCP DHCP Discover - Transaction ID 0x10f1 2 3.669106 192.168.14.4 192.168.145.5 DHCP DHCP Discover - Transaction ID 0x10f1 3 7.668996 192.168.14.4 192.168.145.5 DHCP DHCP Discover - Transaction ID 0x10f1
From our previous experiences, we know this spells trouble. We seem to be getting DHCP Discover packets, but nothing seems to be replying to them. If we take a look at the log output on Cat3, it will become pretty obvious what the problem is.
%DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 000a.b81a.5179
Port facing R4 on Cat3 is an untrusted port. However, this port is now sending the packet that has either GIADDR (Relay Agent) or Option 82 set. In the current configuration, the switch will reject these packets. Here’s the packet with the highlighted problem.
Frame 1: 618 bytes on wire (4944 bits), 618 bytes captured (4944 bits)
Ethernet II, Src: 00:0a:b8:1a:51:79 (00:0a:b8:1a:51:79), Dst: 00:0a:b8:19:c8:f1 (00:0a:b8:19:c8:f1)
Internet Protocol Version 4, Src: 192.168.14.4 (192.168.14.4), Dst: 192.168.145.5 (192.168.145.5)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0x000010f1
Seconds elapsed: 0
Bootp flags: 0x8000 (Broadcast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 192.168.14.4 (192.168.14.4)
Client MAC address: 00:0a:b8:2d:ca:88 (00:0a:b8:2d:ca:88)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (t=57,l=2) Maximum DHCP Message Size = 1152
Option: (t=61,l=27) Client identifier
Option: (t=12,l=2) Host Name = "R1"
Option: (t=55,l=8) Parameter Request List
Option: (t=60,l=12) Vendor class identifier = "dslforum.org"
End Option
Padding
How can we solve this? In theory, all we needed to do is make sure the untrusted port Fa0/4 on Cat3 accepts these packets and forwards them on to the trusted ports. In reality, things are a little bit more difficult.
Simply said, with the DHCP Snooping enabled there is no configuration available that will make this work from a single untrusted port. We can get very close to the solution using global configuration “no ip dhcp snooping verify no-relay-agent-address”, which will disable verification of Option 82 on all untrusted ports. However, when we do that, we’ll be met with another error message:
Cat3:
no ip dhcp snooping verify no-relay-agent-address
%DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPDISCOVER, chaddr: 000a.b82d.ca88, MAC sa: 000a.b81a.5179
This message simply means that the actual source MAC address in the incoming packet doesn’t match the client’s MAC address in the DHCP packet. We can solve this minor issue as well.
Cat3:
no ip dhcp snooping verify mac-address
After configuring this, error messages from Cat3 are going to disappear, but end-to-end DHCP between R1 and R5 is still broken. If we move the Wireshark probe from the port facing R4 to the port facing R5, we’ll see that R5 is receiving DHCP Discover messages sent by R1 and that it’s responding to them. However, these messages are silently being dropped by the switch still. If we enable the debug on Cat3 and observe, we’ll reach the point where Cat3 receives the DHCP Offer packet from R5, but does nothing with it. For brevity, I will omit the information about the packet going towards R5.
Cat3:
Cat3#debug ip dhcp snooping packet DHCP Snooping Packet debugging is on [...] DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/5) DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Fa0/5, MAC da: 000a.b81a.5179, MAC sa: 000a.b819.c8f1, IP da: 192.168.14.4, IP sa: 192.168.145.5, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 192.168.14.2, DHCP siaddr: 0.0.0.0, DHCP giaddr: 192.168.14.4, DHCP chaddr: 000a.b82d.ca88 DHCP_SNOOPING: DHCP packet may be headed in the direction of the relay 192.168.14.4, not extracting option82 information DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.
This is one of those moments when you do one of those “facepalm” moves made by Patrick Stewart in “Star Trek: The Next Generation” series. We’re, essentially stuck and I believe this is something Cisco should actually look to fix. DHCP should now work, yet it doesn’t. Does this mean we cannot use DHCP Relays together with the DHCP Snooping? No, but there are limitations as to what can be done.
To make this configuration work now, we need to trust the port facing R4. Yes, R4 is also the client in this case, but it’s acting as a relay and in the mind of the team designing DHCP Snooping, these two don’t go hand-in-hand. Well, let’s trust the port then.
Cat3:
interface FastEthernet0/4 ip dhcp snooping trust !
When we bounce the Fa0/0 on R1 and capture the traffic on R4′s port on Cat3, this is what we get.
No. Time Source Destination Protocol Info 1 0.000000 192.168.14.4 192.168.145.5 DHCP DHCP Discover - Transaction ID 0xe5c 2 0.006647 192.168.145.5 192.168.14.4 DHCP DHCP Offer - Transaction ID 0xe5c 3 0.877256 192.168.14.4 192.168.145.5 DHCP DHCP Request - Transaction ID 0xe5c 4 0.882244 192.168.145.5 192.168.14.4 DHCP DHCP ACK - Transaction ID 0xe5c
Now we can see that our DHCP operation worked like a charm. What’s the status on R1?
R1:
R1#show ip interface FastEthernet0/0 | include [Aa]ddress
Internet address is 192.168.14.2/24
Broadcast address is 255.255.255.255
Address determined by DHCP
Helper address is not set
Network address translation is disabled
Fine work, but… We’re not quite done yet. DHCP Snooping is still disabled on Cat1. What will happen when we enable it? Let’s give it a try. Remember also to trust at least one of the ports on Cat1, or otherwise “the intelligent broadcast” will not send the DHCP Discover packets anywhere. We’ll configure Cat1 to trust the port facing R4. It’s the only one that makes sense, since this is where the server replies will be coming from on Cat1.
Cat1:
ip dhcp snooping ip dhcp snooping vlan 14 ! interface FastEthernet0/4 ip dhcp snooping trust !
We’ll observe that no packets are going out of R4′s Fa0/1 port and that no devices are showing any error messages in the logs. However, our DHCP doesn’t work. If we remember back to the DHCP Snooping operation on the single switch, we’ll recall that switches insert Option 82, but routers don’t trust this. We need to enable debug on R4 to prove this point.
R4:
R4#debug ip dhcp server packet
DHCP server packet debugging is on.
DHCPD: inconsistent relay information.
DHCPD: relay information option exists, but giaddr is zero.
Sure enough, the problem is visible. Again, there are few ways to fix it. We can either trust this information if we need some subsequent processing on the DHCP Server or we can configure the switch to not insert it. Let’s configure the switch not to insert the option.
Cat1:
no ip dhcp snooping information option
After bouncing the port on R1, everything should work just fine.
R1:
R1#show ip interface FastEthernet0/0 | include [Aa]ddress
Internet address is 192.168.14.2/24
Broadcast address is 255.255.255.255
Address determined by DHCP
Helper address is not set
Network address translation is disabled
As I previously mentioned in the series, DHCP Snooping on switches allows us to use the information in the DHCP Snooping database for security purposes. By default, this is not enabled on the switches, but now we are in position to explore these features. That’s coming soon.
Happy studies!
–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List
Tags: CCIE, dhcp, DHCP Relays, DHCP Snooping
Just great :D
Thank you.
Thanks Marko :)
Elie
Thanks Marko,
it is incredible your knowledge and approach. It would be a dream one day to reach your goal.
Thank you for the kind words. There is a fine way to start your journey there – come to one of my classes! :-)
-Marko.
Thank you for your invitation, I have much respect for your courses, but I can not participate financially. Maximum respect again for your right expertise. I’ll continue to follow you from … this windows.
Thanks very much for this educational material
I’m sorry, I must be stupid, how do I navigate between the different parts of this series?
I would normally expect a link to each from each…?
After studying and labbing this for quite a few hours now,
I think this is more of a design issue than anything else.
There is no reason not to trust Fa0/24 and be done with it.
So, Cat1 Fa0/24 -> Cat2 Fa0/20 -> Cat3 Fa0/5
Don’t trust Cat 1 Fa0/4 at all. It’s fun to play with yes, but nothing Cisco needs to “fix”. Just my 2c.
Brian