One of my not so good decission was to "fast add" protocols vrf using the ancient node.def implementation.
THis turns out to have some limitations as discoverd in T2446. It should be migrated to XML and Python as the CLI nodes are rather new and not too complex (at a first glance).
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In progress | FEATURE REQUEST | None | T3355 Remove all remaining legacy Vyatta code | ||
| Resolved | c-po | T2175 Rewriting all FRR processes allow for reloading and to XML/Python style | |||
| Resolved | FEATURE REQUEST | c-po | T2450 Rewrite "protocols vrf" tree in XML and Python | ||
| Wontfix | BUG | c-po | T2446 VRF IPv6 static routes subnet deletion | ||
| Resolved | BUG | c-po | T2338 Can't delete static IPv6 route on vrf | ||
| Resolved | FEATURE REQUEST | Viacheslav | T3278 Add XML for "protocols vrf" [conf-mode] |
So it turn's out, while looking at the current status more closely, there is a lot of redundancy available which should be migrated away.
VyOS 1.3 - which has the basic VRF functionality implements the following subsystems:
So route and interface-route are more or less the same except for the next-hop - the FRR syntax under the hood provides you:
vyos(config-vrf)# ip route 10.0.0.0/8
A.B.C.D IP gateway address
INTERFACE IP gateway interface name
eth0 eth1 eth2 loTODO:
If this works out as expected, the same should happen to the regular protocols static tree
This one looks much more reasonable:
vyos@vyos# set protocols vrf foo static route 10.0.0.0/24 Possible completions: > blackhole Silently discard pkts when matched interface IPv4 gateway interface name +> next-hop Next-hop router vyos@vyos# set protocols vrf foo static route 10.0.0.0/24 next-hop 1.1.1.1 Possible completions: disable Temporary disable distance Distance for this route interface IPv4 gateway interface name vrf VRF to leak route