search

xdp-project / BNG-router

BNG - Linux router project
GNU General Public License v2.0
21 stars 8 forks source link

dhcp-relay: Handle client requests #8

Open yoelcaspersen opened 3 years ago

yoelcaspersen commented 3 years ago

Initial checks:

Modify packet:

Final action:

adityasohoni commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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

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

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 commented 3 years ago

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 commented 3 years ago

@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.