> 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
