On 2014/10/20 20:55 , James A. T. Rice wrote:
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"
Yes, that might work. I would almost say: just insert a NAT box between the router and the probe. :-)
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?
I don't know if there is a BCP for this, but I would suspect that allocating one VLAN per host would be best. The provides complete isolation. Then, if you tell the host it is on a /24 or bigger, the router would have to proxy-arp for the other hosts on the same subnet. But the probe has no business of talking to those hosts. For the ARP cache, if it works for a normal Linux hosts, then I suspect it will work for a v3 probe as well. Philip