RIPE atlas probe network configuration
Hi RIPE, We've just obtained our final /22 of IPv4 PA space, and we're looking at doing things a little differently with regards to trying to maximise the efficiency of usage within that block. While 100% utilisation of IP addresses by customers is not difficult in e.g. broadband networks (with a /32 being routed over a point to point link to each user), it is difficult in ethernet networks (with 2^n size subnets, network and broadcast and router addresses). Essentially we're going to try to have each customer device (for this purpose, the RIPE atlas probe is a customer device) consume exactly the number of globally unique IP addresses that it needs. Because for isolation each customer gets their own VLAN, and because "ethernet" traditionally means subnets with 2^n size and network and broadcast addresses and physical router addresses and VRRP addresses needing to be on that subnet, we end up with a subnet of 8 IP addresses used for a customer device that only will have 1 IP address exposed to the outside world: globally unique range: 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 7 - broadcast What I'd like to do, in order to only consume 1 globally unique IP address for the whole setup is as follows: private range, e.g. 10.a.b.c/24 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 255 - broadcast with a single globally unique IPv4 /32 (let's say) p.q.r.s routed to 10.a.b.4 in the above example. This means that you'd need to configure on your device, something like (assuming linux): network: 10.a.b.0/24 gateway: 10.a.b.1 alias: p.q.r.s/32 with it configured that p.q.r.s is the default source IP address to use for any outbound packets. This is a relatively 'clean' way of doing things, as it doesn't involve proxy-arp or similar trickery. It should be possible to do this for linux based systems. What do you think? Will the atlas probe support it, or would you consider making that a feature? Thanks James Rice Jump Networks Ltd.
Hi James, On 2014/10/16 19:04 , James A. T. Rice wrote:
This means that you'd need to configure on your device, something like (assuming linux): network: 10.a.b.0/24 gateway: 10.a.b.1 alias: p.q.r.s/32
with it configured that p.q.r.s is the default source IP address to use for any outbound packets.
This is a relatively 'clean' way of doing things, as it doesn't involve proxy-arp or similar trickery.
It should be possible to do this for linux based systems. What do you think? Will the atlas probe support it, or would you consider making that a feature?
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. 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. Philip
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
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
participants (2)
-
James A. T. Rice
-
Philip Homburg