Comment 11 for bug 1737428
Revision history for this message
| Dmitrii Shcherbakov (dmitriis) wrote | #11 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
Sandor,
Not on the VRF usage side but there is a feature in MAAS 2.6 to have a better way to work in multi-homed environments (for bionic+ machines):
https:/
"Networking - Multiple default gateways"
It relies on "routing policy database" (RPDB) functionality
https:/
At the target machine you will see something like this:
# ip rule
0: from all lookup local
0: from 10.232.24.0/21 to 10.232.24.0/21 lookup main
0: from 10.232.40.0/21 to 10.232.40.0/21 lookup main
100: from 10.232.24.0/21 lookup 2
100: from 10.232.40.0/21 lookup 1
32766: from all lookup main
32767: from all lookup default
# ip route show table 1
default via 10.232.40.1 dev b-enp4s0f0-2730 proto static
# ip route show table 2
default via 10.232.24.1 dev b-enp4s0f0-2731 proto static
This works well for TCP when responding to traffic (even when software listens on 0.0.0.0). For UDP a frequent server use-case is DNS servers and bind9 binds its UDP sockets to interface addresses directly as opposed to using 0.0.0.0 (some other DNS servers do the same, e.g. PowerDNS - they even have a post about it https:/
For sending, the policy rules will also kick in provided that a client socket (TCP or UDP) is bound to a specific address (so that the source IP is not automatically selected). This requires that the target software supports binding client sockets to specific addresses unfortunately.
So far using static routes to summarized prefixes has been a solution for east-west traffic (because we control nodes managed by MAAS) and using the approach above for client responses to arbitrary networks (via https:/
After juju starts supporting this new MAAS feature https:/
I hope that helps while VRF functionality is not implemented.