while testing vrf route leaking, I've found that the behavior is not as expected.
When using the below config:
set protocols vrf ivrf static route 172.25.200.1/32 next-hop 220.127.116.11 next-hop-vrf default
what I see in the frr config is:
vrf ivrf ip route 0.0.0.0/0 XYZ ip route 172.25.200.1/32 18.104.22.168 exit-vrf
but would expect it to be:
vrf ivrf ip route 0.0.0.0/0 XYZ ip route 172.25.200.1/32 22.214.171.124 nexthop-vrf default exit-vrf
As pointed by cpo on slack, I've done some investigation to try to get it fixed and working as expected (based on the ipv6 code).
This led to some additional findings that may be useful when reworking the code:
- vrf route leaking logic for ipv4 behaves differently than the one for ipv6 at the moment - as for ipv6 there is a requirement to have both next-hop-interface AND next-hop-vrf set (when only next-hop-vrf set, on commit you see: "VRF route-leaking requires a next-hop interface to be set in the destination VRF"). Logic suggests that the requirement of both variables being set is the same for both ipv4 and ipv6 routes ?
- There's inconsistency between the naming of sub-nodes - for ipv4 it's next-hop-interface, while for ipv6 it's just interface - potential area to improve, but I would not know how to handle it, as a change here would break existing configurations if not handled properly. Specifically:
set protocols vrf ivrf static route6 fe:fe::/128 next-hop fe::1 interface eth0 vs
set protocols vrf ivrf static route 126.96.36.199/24 next-hop 188.8.131.52 next-hop-interface eth0