Choose interface on multihomed hosts

[rapier1]

Is it possible to extend this to allow the user to specify the non-default interface? This would be helpful on systems that are attached to multiple networks. I've taken a look at the code and if I can figure it out I'll let you know but I'm a C guy; C++ is still a new world for me.

Thanks

[insomniacslk]

Hi @rapier1 , making this OS-independent could be tricky, but it's easily doable on Linux at least. We can use SO_BINDTODEVICE on the outgoing socket for the Go version of the tool, and I'm pretty sure that libtins allows setting the outgoing interface, for the C++ version

[rapier1]

OS independence is always the tricky part.

If you do get the chance to look at this I would appreciate it - even if its just a one off for linux.

As to why I"m interested in this:
I'm using dublin traceroute as part of an automated network testing tool. It's a minimal iso that boots into a live cd of known good configuration and runs a mess of tests against perfSonar nodes (iperfs, udp tests, tcpdump, traceroutes, RTT tests, etc). The results are then packaged and returned to the network engineer. Saves a lot of time when trying to get diagnostic data from remote users of questionable IT skills.

A number of the users we support are using multihomed systems (often a 10Gbps link to a high performance research and education network and a 1Gbps to the regular internet). We want to ensure that the paths we are testing are the correct paths.

[omribahumi]

How about specifying the source IP and using policy routing for choosing the internet? I think it will work properly.
Anyway, I came here because I'm interested in specifying the source IP for our network layout.

I think that all that's needed to change is this code for the sourceip:
https://github.com/insomniacslk/dublin-traceroute/blob/master/include/dublintraceroute/udpv4probe.h#L42

You need to specify the local IP address you want to bind to instead of 0, according to the documentation here: http://libtins.github.io/tutorial/sending/

Note that no source address was specified in the IP constructor. This uses by default the address 0.0.0.0. However, when sending network layer PDUs, if the source address is 0.0.0.0, the PDU will perform a lookup on the routing table to find out which should be the source address and automatically sets it. This is done by the network driver already, but some transport layer protocols such as TCP, require this address when calculating the checksum, so this must be done by the library as well.

Which is exactly like the implementation in UDPv4Probe::forge() :)
https://github.com/insomniacslk/dublin-traceroute/blob/master/src/udpv4probe.cc#L44

So we just need to patch the argument in from the command line, defaulting to 0.0.0.0 (INADDR_ANY) for backwards compatibility

[omribahumi]

Actually, the interface can also be chosen there: https://github.com/insomniacslk/dublin-traceroute/blob/master/src/udpv4probe.cc#L58

[insomniacslk]

Actually, the interface can also be chosen there: https://github.com/insomniacslk/dublin-traceroute/blob/master/src/udpv4probe.cc#L58

Apparently libtins ignores the network interface parameter, https://github.com/mfontanini/libtins/blob/master/src/ip.cpp#L393 . This seems to be confirmed by my experiments

[omribahumi]

For IP packets, it makes sense not to allow you to specify the egress interface.
The OS needs a functioning routing table for reasoning about ARP. If the egress interface you specify conflicts with the current routing table, where would the ARP request go to? It doesn't make sense to send ARP on eth0 and then send the packet out of eth1, and it can't assume anything about the directly connected hosts on the subnet, so how would it route?

I just hope they implemented policy routing table lookup properly :)

https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html

[jbemmel]

For IPv6 libtins now does look at the interface: mfontanini/libtins@a619e4f#diff-b23b9d060c719b60ce59dccae8ef233bf13ae3b2cedfa7610b0f202b5a9e39b5