cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
171
Views
3
Helpful
9
Replies

DHCP Snooping

michalkores
Level 1
Level 1

Hi!

I am troubleshooting an issue with DHCP snooping. I have the following network topology (see the diagram in the attachment)

DHCP snooping is enabled on the access switch, which is connected to the core network where DHCP snooping is completely disabled (including option 82 insertion and verification of HWADDR/GIADDR). The VLAN to which the PC is connected is terminated at the L3 interface on the core switch. An IP helper is configured on the VLAN interface, which resides in the global VRF.

The packet reaches the DHCP server successfully, the server processes it, and the client obtains an address. On the access switch, I have enabled option 82 insertion: circuit-ID (suboption 1) is set in the default format VLAN-MOD-PORT, and remote-ID (suboption 2) is configured as the hostname of the access switch.

When I inspect the packet that arrives at the DHCP server, the option 82 information has been modified as follows:

  • Circuit-ID (suboption 1): The VLAN remains unchanged, but the MOD-PORT reflects the physical interface of the core switch.
  • Remote-ID (suboption 2): This field is missing entirely.
  • VRF-Name (suboption 151): Contains the name of VRF A.
  • Link-Selection (suboption 5): Reflects the network address from which the client is communicating.
  • Server-ID-Override (suboption 11): Contains the L3 termination address.

I understand why the core switch expanded the packet with additional suboptions (151, 5, and 11). However, I don't understand why it overwrote the circuit-ID and removed the remote-ID.

My expectation is to identify, on the DHCP server, the specific access switch and port from which the client originated. When I inspect the communication on the uplink from the access switch, the circuit-ID and remote-ID are correctly present. Therefore, it seems certain that the core device is modifying the packet.

Could you please advise?

9 Replies 9

can you more elaborate

in simple words 
if 
Acc SW run dhcp snooping and add op82 
Core run dhcp snooping then Core not trust about what Acc SW add so it override or use different TLV 

you need to use op trust under interface connect Acc SW to Core SW

MHM 

As I mentioned in the original post, DHCP snooping is not enabled on the core box, so (as I assume) it should not interact with those two suboptions (1 and 2) at all. The interface on the core is configured as follows:
vrf forwarding VRF-A
ip dhcp relay information trusted
ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
ip helper-address global xxx.xxx.xxx.xxx
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode

If I didn't include the command ip dhcp relay information trusted, the DHCP request from the client did not reach the server at all (the core box is likely dropping those packets). More details are explained here: https://community.cisco.com/t5/switching/dhcp-snooping/m-p/1622878/highlight/true#M164843

thanks 

now let see what relay do to dhcp 

from cisco doc.

Relay Agent Information Option

Automatic DHCP address allocation is typically based on an IP address, whether it be the gateway IP address (giaddr field of the DHCP packet) or the incoming interface IP address. In some networks, it is necessary to use additional information to further determine which IP addresses to allocate. By using the relay agent information option (option 82), the Cisco IOS XE relay agent can include additional information about itself when forwarding client-originated DHCP packets to a DHCP server.

Cisco IOS XE supports this functionality by using the ip dhcp relay information option command. The relay agent will automatically add the circuit identifier suboption and the remote ID suboption to the relay agent information option and forward them to the DHCP server.

The DHCP server can use this information to assign IP addresses, perform access control, and set quality of service (QoS) and security policies (or other parameter-assignment policies) for each subscriber of a service provider network.

So the relay add auto new Crt-ID and remote-ID 
but we use trust 

here I think below command use 

Relay Agent Information Reforwarding Policy

A DHCP relay agent may receive a message from another DHCP relay agent that already contains relay information. By default, the relay information from the previous relay agent is replaced. If this behavior is not suitable for your network, you can use the ip dhcp relay information policy {drop keep replace } global configuration command to change it.

To ensure the correct operation of the reforwarding policy, make sure to disable the relay agent information check by using the no ip dhcp relay information check global configuration command.

in simple word you need to make relay keep the op and add VPN as additional op82

MHM

Thank you so much for your response. It was very helpful.

I didn’t want to use the global command ip dhcp relay information policy {drop | keep | replace}, so I found a similar one, ip dhcp relay information policy-action {drop | keep | replace | encapsulate}, which, according to the documentation, can be applied per interface. However, this is documented for IOS version 16.12. Interestingly, the command is also available in my IOS version (17.09.05).

If I configure the interface as follows:

  • ip dhcp relay information policy-action drop – the core probably correctly drops DHCP packets (I don't see them on the DHCP server interface).
  • ip dhcp relay information policy-action keep – the core also seems to drop DHCP packets, although according to the documentation, it should forward the packet to the DHCP server with the information it received from the access layer.
  • ip dhcp relay information policy-action replace – as expected, it rewrites option 82 with its own information (this behavior is currently enabled globally by default).
  • ip dhcp relay information policy-action encapsulate – adds its own option 82 information (like "replace") but additionally encapsulates the information received from the access layer into sub-option 9 in some unknown format.

Yes there are two types of command for dhcp snooping and dhcp relay 

A- global mode' effect all SW interface 

B- under interface which effect only that interface.

I prefer B 

Try keep op82 abd check

MHM

I made a mistake in my previous post. The keep option does the same as the replace option, meaning it overwrites option 82 with its own information.

@michalkores 

 Which devices and IOS do you have?  
 this can be a bug but this also can be some characteristic of the IOS or platform considering the way they are in your environment. 
 

I apologize, I forgot to mention this. The access switch is a Catalyst 9200 running IOS version 17.06.05, and the core switch is a Catalyst 9500-48Y4C running IOS version 17.09.05.

@michalkores 

 Take a look on this doc, in case you didn´t

IP Addressing Services Configuration Guide, Cisco IOS XE Cupertino 17.9.x (Catalyst 9500 Switches) - Configuring DHCP [Support] - Cisco

Attention to "DHCP Relay Agent in a Metropolitan Ethernet Network"  there is mentioned a few commands that might be important. 

Review Cisco Networking for a $25 gift card