DHCP Snooping issue.

[DuJin0509]

Hello folks,

I was wondering why if the DHCP snooping feature is enabled on Sw1, the port 3 on Sw1 must be configured as "trusted port" ?

R1 is DHCP server, R3 is DHCP relay agent (ip helper-address is configured on f0/1), R5 act as client.

Assuming option 82 is nothing to do in this scenario and only considered it from giaddr aspect.

Cited below picture from http://brbccie.blogspot.my/2013/03/dhcp-snooping-and-option-82.html?m=1.

Thank you.

[Georg Pauwen]

Hello

if port 3 on SW1 were to be an untrusted port, DHCPDISCOVER messages sent from clients (coming from the right of port 3 in your drawing) would not even get to the DHCP server. With snooping enabled, DHCP broadcast message are only sent to trusted ports.

Hope that makes sense. You basically need a path of 'trusted' ports from your clients to the DHCP server.

[DuJin0509]

Hello Georg,

Thanks a lot for your prompt reply.

Agree with your point that if port 3 on SW1 were to be an untrusted port, DHCPDISCOVER messages sent from clients (coming from the right of port 3 in your drawing) would not even get to the DHCP server.

but, I got below syslog from Switch1 and my concern is why the switch1 dropped the dhcp discovery packet with non-zero giaddr ? (we can forget option82 in this case as I have disabled the option82 insertion from the Sw2 ), DHCP discovery packet will ingress from Sw1 Port 3, it only a DHCP discovery packet rather than DHCP offer packet from DHCP server, so why Sw1 dorps this kind packet on an untrusted port ? Is it normal behavious of DHCP snooping that untrusted port could accpect the DHCP discovery packet from client and forward it to DHCP server ?

Apr 19 05:06:34 CST: %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: 7c0e.ce06.3b80.

[Rolf Fischer]

Hello,

DHCP snopping drops DHCPOFFER,DHCPACK and DHCPNACK messages on untrusted ports. We should not see such messages on Sw1 port 3, so it doesn't have to be a trusted port.

However, you also have to deal somehow with Option 82 and all-zero/non-zero GIADDR. There are several ways to do that (globally: no ip dhcp snooping information option, ip dhcp relay information trust-all; interface-level: ip dhcp relay information trusted) without trusting the port.

I think in practice trunks are often generally trusted in order to simplify configuration.

HTH
Rolf

[DuJin0509]

Hello Rolf,

Actually Georg spoken truth, in my scenario if I place the port 3 of Sw1 to untrusted, all the dhcp discovery generated from R3 (R3 is DHCP relay agent ) will be discarded by Sw1, they could not reach to DHCP server at all.

I am stumped by in what scenario the DHCP discovery packet will be dropped by "drop message with non-zero giaddr". or if the DHCP relay installed on R3, the port 3 on Sw1 have to be configured as trusted port , why ?

Apr 19 05:06:34 CST: %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: 7c0e.ce06.3b80.

[Rolf Fischer]

Actually Georg spoken truth, in my scenario if I place the port 3 of Sw1 to untrusted, all the dhcp discovery generated from R3 (R3 is DHCP relay agent ) will be discarded by Sw1, they could not reach to DHCP server at all.

Well, I do not fully agree with that. DHCP snooping normally does not drop client-to-server messages  like DHCPDISCOVER on untrusted ports. If this were the case, you would need to trust all the edge-ports. Rather it drops server-to-client Messages when the port is not trusted. So you need to trust the all the server-to-client paths, not [necessarily] the client-to-server paths (that's indeed a difference).

The problem in your scenario is that the DISCOVER has Option 82 set or a nonzero GIADDR (I guess here it's Option 82..[EDITED].). You can solve this by trusting the port (and this is what I see very often) but there are other solutions as well.

[DuJin0509]

Hello Rolf,

On switch 1 we have issued "no ip dhcp snooping information option", so believe option82 insertion won't happen ...to the initial DHCP discovery packeted generated from client.

Sw1#sho ip dhcp snooping 
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
99
DHCP snooping is operational on following VLANs:
99
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is disabled >>>>>>>>>>>>>>>>>>>>>
   circuit-id default format: vlan-mod-port
   remote-id: f025.7298.c400 (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    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------   
GigabitEthernet0/1         yes        yes             unlimited
  Custom circuit-ids:

So suspecting option82 is nothing to do with .

[DuJin0509]

Following is from Sw2.

Sw2>sho ip dhcp snooping 
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs
DHCP snooping is operational on following VLANs:
99
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is disabled
   circuit-id default format: vlan-mod-port:
99
   remote-id: f025.7298.c500 (MAC)
Option 82 on untrusted port is 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    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------   
FastEthernet0/1            yes        yes             unlimited
  Custom circuit-ids:
FastEthernet0/2            yes        yes             unlimited
  Custom circuit-ids:
FastEthernet0/24           yes        yes             unlimited
  Custom circuit-ids:
GigabitEthernet0/1         yes        yes             unlimited
  Custom circuit-ids:
GigabitEthernet0/2         yes        yes             unlimited
  Custom circuit-ids:
Port-channel1              yes        yes             unlimited
  Custom circuit-ids:

[Rolf Fischer · Accepted solution]

So suspecting option82 is nothing to do with .

You're right; sorry, my bad.

I couldn't correct my answer earlier because of the CSC maintenance window.

So the reason is obviously the non-zero GIADDR set by the DHCP relay agent. You can verify this with

show ip dhcp snooping statistics detail

and disable that check with the global configuration command

no ip dhcp snooping verify no-relay-agent-address

[DuJin0509]

Hi Rolf,

Yes, the command provided by you resolved my issue, another option we could utilize is to set the port 3 as trusted.

Not sure why non-zero giaddr could incur such promble...on untrusted port.

Thanks a lot for your kindly advise.

[Rolf Fischer]

You're welcome. Thanks for using the rating system!

Not sure why non-zero giaddr could incur such promble...on untrusted port.

That's something I need to review too. I thought this particular checks were defined in RFC 3046 but after quickly re-reading section 2.1 (Agent Operation) it doesn't seem so.