Bug#963826: cloud.debian.org: Policy based routing needed when using multiple network interfaces, subnets
> Scratchpad/napkin suggestions, needs ipv6 routing:
>
> auto $INTERFACE
> allow-hotplug $INTERFACE
>
> iface $INTERFACE inet dhcp
> post-up ip route add default via $GATEWAY dev $DEVICE table $TABLE
> post-up ip route add $CIDR dev $DEVICE proto kernel scope link src
> $ADDR table $TABLE
> post-up ip rule add iif $DEVICE table $TABLE
> post-up ip route add default via $GATEWAY dev $DEVICE metric $TABLE
>
> pre-down ip route del default via $GATEWAY dev $DEVICE metric $TABLE
> pre-down ip rule del iif $DEVICE table $TABLE
> pre-down ip route del $CIDR dev $DEVICE proto kernel scope link src
> $ADDR table $TABLE
> pre-down ip route del default via $GATEWAY dev $DEVICE table $TABLE
This is effectively what we want to do. However, we don't have access
to the network configuration data (gateway, address, etc) directly in
ifupdown's scripts. We have a few options:
1. We can parse the ip(8) output to identify the address configuration
assigned to an interface. The disadvantage of this is that it involves
parsing output from a tool whose output isn't specifically intended to
be parsed.
2. We can configure routing in a dhclient exit hook. This should have
access to all the details that dhclient has configured on the interface
via the environment. However, it tightens our coupling with dhclient,
which may not be desirable. There's been some talk of moving to
systemd-networkd for interface configuration.
3. We can retrieve interface configuration via the instance metadata
service (IMDS). This is what amazon-ec2-net-utils does. Disadvantages
here involve the need to cope with propagation delays in IMDS. Per
comments in that code, it can take up to 30s for address information to
become available, meaning we need to implement retry logic and error
handling. That adds undesirable complexity to our code.
(https://github.com/aws/amazon-ec2-net-utils/blob/master/ec2net-functions#L68)
We also need to handle IMDSv2, and IMDS can be disabled altogether these
days, which would break our implementation.
> Another solution may be to modify and use AWS' ec2-net-utils directly.
> https://github.com/aws/amazon-ec2-net-utils It's my opinion that debian-cloud-
> images may have enough pieces already to make this more work than modifying the
> existing scripts.
I'm inclined to agree that modifying amazon-ec2-net-utils directly is
not the most efficient approach to this.
My inclination is to implement this functionality using dhclient. Quick
examination suggests that this will be straightforward, and it should be
the most reliable. We'll need to reimplement it if we do move away from
dhclient, but at the moment nobody is actually working on that, so I'm
not too concerned.
noah
Reply to: