Wired Intelligent Edge

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

Will this help you out?

https://techhub.hpe.com/eginfolib/Aruba/OS-CX_10.04/5200-6720/index.html#GUID-AC6C8F68-D366-44EA-9D7E-573CE321516C.html

------------------------------
Gerber van Beek

Original Message:
Sent: Apr 03, 2024 11:23 AM
From: MH33
Subject: DHCP Relay - Source IP in Offer and Ack

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

Did you do the capture on the client side of your DHCP relay? On the client itself or on the Aruba CX device?

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

Client itself

If anyone is able to find a RFC/IETF that ways what the Source IP *should* be using, that would be very helpful.    My googling hasn't found anything yet.

Did you do the capture on the client side of your DHCP relay? On the client itself or on the Aruba CX device?

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

To verify I would do a packet capture on the Aruba CX device and the client. This will verify the DHCP exchange takes the path you expect.

To work the OFFER must come from a device in the same subnet as the client, and also the the ACK. The client can't use the given information from DHCP server until the ACK. So the "partner" must be the DHCP relay agent. But sometimes during migration packets does follow unexpected paths, so verify on the switch itself also.

You have tshark build into the diag tools, or you may do a mirror session to a dedicated device.

Client itself

If anyone is able to find a RFC/IETF that ways what the Source IP *should* be using, that would be very helpful.    My googling hasn't found anything yet.

Did you do the capture on the client side of your DHCP relay? On the client itself or on the Aruba CX device?

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.

I did a capture from the 6300M side as well and it is showing the same as the client side capture.

I can also confirm that the src mac of the DHCP packets is showing the Aruba 6300M, but the src IP is not the vlan SVI.

I am still waiting for feedback from TAC.

To verify I would do a packet capture on the Aruba CX device and the client. This will verify the DHCP exchange takes the path you expect.

To work the OFFER must come from a device in the same subnet as the client, and also the the ACK. The client can't use the given information from DHCP server until the ACK. So the "partner" must be the DHCP relay agent. But sometimes during migration packets does follow unexpected paths, so verify on the switch itself also.

You have tshark build into the diag tools, or you may do a mirror session to a dedicated device.

Client itself

If anyone is able to find a RFC/IETF that ways what the Source IP *should* be using, that would be very helpful.    My googling hasn't found anything yet.

Did you do the capture on the client side of your DHCP relay? On the client itself or on the Aruba CX device?

We recently replaced a Cisco 4500-X layer 3 switch with a 6300M.   The 6300M is running FL.10.10.1030

After the migration, several legacy devices stopped getting DHCP addresses.   The legacy Cisco switch was still connected, so I gave one of the SVIs a new IP and re-enabled it, and the devices immediately started getting DHCP addresses.    

A key note is that the DHCP relay worked for many clients on the 6300M, but not all.   With the relay on the Cisco core, all clients work successfully.

I ran a capture to compare the working and not-working flows, and i found one glaring difference.

Cisco (working) :  During the DORA process, the Offer and Ack packets have a source IP of the SVI IP from the Cisco switch

Aruba (not working):  During the DORA process, the Offer and Ack packets have a source IP of the DHCP server

I tried finding RFC or IETF documentation to show what *should* be used, but this site is the only thing I have found (figure 2):

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

This shows that the Offer and Ack should use the SVI IP address of the relay, which matches the Cisco flow.

Questions:

1. Is there a command on CX to tell the relay agent to use the SVI IP instead of the DHCP server IP
2. Is there a standards document that shows what *should* be used?   Most of these are older IoT devices, but at the end of the day they worked before and now they dont.