Comment 3 for bug 1656350

Hello again,

I can confirm in my lan setup (see reference diagram), that addition of pre and post up stanza does not work.
[ https://www.lucidchart.com/documents/view/24043097-9fc5-4d88-a598-a825e5bd2217 ]

I have the following working implementation:

root@ops-lab-ter-01:/home/ubuntu# cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
1 LABPUB
root@ops-lab-ter-01:/home/ubuntu#

root@ops-lab-ter-01:/home/ubuntu# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

ip route add 192.168.22.0/24 dev eno2 src 192.168.22.1 table LABPUB
ip route add default via 192.168.22.254 dev eno2 table LABPUB
ip rule add from 192.168.22.1/24 table LABPUB
ip rule add to 192.168.22.1/24 table LABPUB

exit 0
root@ops-lab-ter-01:/home/ubuntu#

root@ops-lab-ter-01:/home/ubuntu# cat /etc/network/interfaces
auto lo
iface lo inet loopback
    dns-nameservers 192.168.1.1 192.168.3.1 8.8.8.8
    dns-search prepaidmeters.local maas prepaidmeters.example prepaidmeters.test

auto eno1
iface eno1 inet static
    dns-nameservers 192.168.1.1 192.168.3.1 8.8.8.8
    gateway 192.168.21.254
    address 192.168.21.1
    netmask 255.255.255.0
    broadcast 192.168.21.254
    mtu 1500

auto eno2
iface eno2 inet static
    dns-nameservers 192.168.1.1 192.168.3.1 8.8.8.8
    address 192.168.22.1
    netmask 255.255.255.0
    broadcast 192.168.22.254
    network 192.168.22.0
    mtu 1500

source /etc/network/interfaces.d/*.cfg
root@ops-lab-ter-01:/home/ubuntu#

Please note that I have manually edited these files to obtain this implementation.
I have also used the more traditional stanza format for iface definitions.

I am not sure how to make curtin or cloud-init produce these results.

I don't know if others would agree, but I find this to be a clearer, more flexible and more persistent method to implement the routing. However, this implementation is a test case to meet the requirements of OpenStack so I would assume that the implementation suggested above is of greater benefit than just MAAS.