Hi Philip, On 20 Oct 2014, at 14:24, Philip Homburg <philip.homburg@ripe.net> wrote:
I guess not having to do proxy arp is attractive from a network operations point of view, but for a host having to use one specific address is not attractive at all.
This would be a lot of work on the Atlas side. Not only adding the alias would require quite a few changes, but then also making sure that all network code would use the right source address.
I don't think using the right source address should be difficult - http://linux-ip.net/html/routing-saddr-selection.html "the kernel will use the src hint from the chosen route path" http://serverfault.com/questions/248056/set-default-outgoing-ip-on-ubuntu-se... suggests the way to bring up the default route and pin eth0:1 to use for outgoing connections is in the form: up route add -net 0.0.0.0/0 gw 11.22.178.1 dev eth0:1
So for Atlas, it would be best if the probe could be configured as p.q.r.0/24 with p.q.r.1 as the gateway. Leaving the whole 10.a.b out of the story.
That does bring back memories of moving customers off of a shared VLAN and a /23 onto their own VLAN and /28. Those that didn't renumber in a timely fashion had a VLAN with proxy-arp enabled, and a static arp entry for their mac address to their new (yet configured on their host) IP, and a static route for the old IP address to the new IP address. I guess on my side I could assign a subnet of private space, make a static arp entry to your real mac address for a chosen IP from the private range, and then make a static route /32 for your public IP towards the private IP. The sensible netmask to use would be the /19 or /22 or whatever our allocated block is (otherwise the probe wouldn't be able to reach the IPs it thinks are its network and broadcast addresses. I shall give this a try. Can you think of any problems this might make? What's the limit of the arp table size on the probe for instance? Thanks James