11-27-2024 08:25 AM
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:
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?
11-27-2024 08:33 AM - edited 11-27-2024 08:52 AM
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
11-27-2024 09:37 AM
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
11-27-2024 10:00 AM
thanks
now let see what relay do to dhcp
from cisco doc.
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
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
11-28-2024 08:43 AM
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:
11-28-2024 08:47 AM
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
11-28-2024 09:00 AM
11-27-2024 08:46 AM
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.
11-27-2024 09:18 AM
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.
11-27-2024 09:41 AM
Take a look on this doc, in case you didn´t
Attention to "DHCP Relay Agent in a Metropolitan Ethernet Network" there is mentioned a few commands that might be important.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide