dhcp-relay: Handle client requests

[yoelcaspersen]

Initial checks:

• Destination MAC = FF:FF:FF:FF:FF:FF
• Destination IP = 255.255.255.255
• UDP destination port = 67
• OP == 1
• If hops > 16: Discard packet
• If option 82 is set, discard

Modify packet:

• Increment "hops" field
• If GIADDR == 0, set GIADDR = relay agent IP
• Add option 82 (use VLAN tags and interface name)
• Set source IP = relay agent IP
• Set destination IP = DHCP server IP
• Set destination MAC = relay agent MAC
• Re-calc IP checksum

Final action:

• Return XDP_PASS (pass on to kernel)

[adityasohoni]

Hi @yoelcaspersen
While modifying the packet, should we remove the VLAN tags that were attached from the customer side?

in this testbed that we had created, we were able to get the packets through the client-side interface where the current XDP program is attached. We were able to see the packets with option 82 and destination IP set correctly using Wireshark.
However, the packets were not being forwarded to the destination(server-side) interface. We are not removing the VLAN tags that came with the packet.
Our guess was that the packets were being dropped by the kernel.
We also confirmed that ping or any other packet without the VLAN tags are being correctly forwarded to the DHCP server.

[yoelcaspersen]

Hi @adityasohoni,

The packets are indeed being dropped by the kernel, but not because of the VLAN tags. Removing VLAN tags isn't necessary, as the kernel does that for you.

To make the kernel forward the packets, convert the packets to unicast first:

• Set destination MAC = NIC MAC (the destination MAC of broadcast packets is FF:FF:FF:FF:FF:FF)
• Set source IP (in lack of better alternatives, I set the source IP = NIC IP)
• Enable forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward)
• Enable accept_local feature (echo 1 > /proc/sys/net/ipv4/conf/all/accept_local)

The latter is necessary if you set source IP = NIC IP.

In a few hours, I will commit the code I have produced - it takes care of the issues mentioned above.

Regards,

Yoel Caspersen

[yoelcaspersen]

@adityasohoni, I have pushed my latest work-in-progress to the repo (09bc685).

Please beware that this commit may break your testbed - tail extending packets doesn't seem to work in SKB mode (see issue #10) and requires testing with a physical NIC instead.

However, head extending the packet is not optimal, as we need to inject option 82 as the last option (right before option 255 END). That would leave us with a variable number of bytes that we would need to move - but that doesn't fly with the built-in XDP memcpy function, which takes a const length as argument.

There are a few ugly workarounds that may work, but for now I will use a physical NIC for testing and stick with tail extending the packets. After all, that is also the real world use case for the XDP program.

[bhaskar792]

Hi @yoelcaspersen

Could you please share more information regarding the testbed that you will be using?
We can then try to set up a similar testbed, and if any extra hardware is required we can ask our supervisor about it.

[yoelcaspersen]

Could you please share more information regarding the testbed that you will be using?

Sure, I have just committed an updated README file in 37f30d5.

In my test setup, I use two physical servers connected back-to-back, but perhaps you can loop two NIC ports on the same server to get the same effect (I haven't tested that approach). I use two Mellanox 25 Gbit/s NICs as those are the ones we will be using in production, but I think any XDP compatible NIC will work.

Any feedback is highly appreciated.

[bhaskar792]

Thanks a lot, @yoelcaspersen for the updated README, that clears quite a few doubts we had. We'll now set up our testbed accordingly.

[bhaskar792]

@yoelcaspersen Any suggestion for where should we be keeping the check for Destination IP = 255.255.255.255? As of now we are keeping it right after we parse IP header.