0

We have a production server where we receive a continuous stream of UDP packets (~ 15 Mbps). We have a small research team which wants to process this same exact stream for some research purposes on another server. The research team's server is also on the same subnet. First we thought of creating a copy of the stream on the switch itself and putting the research team's server on promiscuous mode but the IT team is unwilling to program the switches that way. So we were wondering if we could do the stream recreation for the research server on the production server itself.

The production server is beefy enough to handle any CPU load which may arise from creating duplicate packets. However, the stream recreation does need to be near real-time (a couple of seconds delay is acceptable). The server runs Debian on a x64 processor and has plenty of free RAM.

General Googling tells me about UDP samplicator on github. However, I wanted to know if there is a cleaner approach e.g. OS level primitive/tool to achieve this?

Dave M
  • 4,514
  • 22
  • 31
  • 30
Azeem Khan
  • 11
  • 2
  • 2
    iptables has a TEE target that should do what you want. Since the research server is on the same subnet, this is well suited for your use case. – Brandon Xavier Feb 18 '20 at 08:43
  • Thank you. Works great on our test VMs. Will definitely try it out on the production over the weekend. The actual command came down to `sudo iptables -t mangle -A PREROUTING -i enp10s0 -p udp --dport 35000 -j TEE --gateway 192.168.100.8` where the 100.8 is the destination server address. – Azeem Khan Feb 18 '20 at 10:13
  • 1
    Happy to be of service. You should considering posting your command as an Answer. – Brandon Xavier Feb 18 '20 at 10:35

1 Answers1

1

Thanks to Brandon Xavier for pointing us in the right direction. The command on the production server came to be:

sudo iptables -t mangle -A PREROUTING -i enp10s0 -p udp --dport 35000 -j TEE --gateway 192.168.100.8

where enp10s0 was the receiving NIC device, 35000 was the destination port of the packets and 192.168.100.8 was the IP address of the research team's server. Note that the packet is recreated as-is at the IP level for the other machine. So, on the other machine, your parsing program would have to be in promiscuous mode to read it.

Azeem Khan
  • 11
  • 2
  • If the destination is on ethernet, at the ethernet level, the received IP packet will have the gateway's MAC address (that's the role of this option: to resolve the destination MAC address). So there shouldn't be the need to be in promiscuous mode for the interface to accept the duplicate: the packet is a copy of the original IP packet, but its ethernet frame is different from the original frame: destination MAC address is gateway's MAC address. Without special configuration the IP layer would still ignore it as not intended for itself, so yes a special configuration is still needed. – A.B Feb 23 '20 at 02:03
  • You are absolutely right in those details about the Ethernet frame being okay to accept at the research team's server but the IP packet not being accepted since the destination IP will not match the NIC's IP (perhaps it get logged as martian by the kernel??). I have never ventured into this territory so could you please hint on what special configuration is best suited for accepting the packet? iptables ? or something else? Thanks. – Azeem Khan Feb 24 '20 at 03:31
  • Reuse the same IP on the additional processing system, or use an iptables prerouting rule (if you can afford the IP to change on the application) etc. You must ensure that the result doesn't interfere with the original system, both for this IP and for ARP requests to this IP (iptables + arptables?) . Really depends on the method and there are multiple methods – A.B Feb 24 '20 at 07:21
  • Thank you. Sounds like a fun challenge. – Azeem Khan Feb 25 '20 at 08:18