Specify VRF for the route manipulation

[serenheit]

We'd like to see routes addition with VRF support. As an example here is the CLI command:

ip route vrf VRFNAME 0.0.0.0/0 192.168.100.2
no ip route vrf VRFNAME 0.0.0.0/0 192.168.100.2

Right now we can listen and react to events in VRF without full support of routes manipulation.

[rmadsen]

Hi @serenheit - This is something we want to support, but I don't think we'll properly be able to add support for this in the short term.

The right way to go about this, I believe, is to the following methods to the API:

1. Add a std::string vrf attribute to eos::ip_route_key_t
2. Update all of the ip_route_mgr methods to be VRF aware
3. Add a method to the ip_route_mgr that lets you "register" that you want to manage a VRF.

Unfortunately EOS's underlying config types for static routes is pretty complex, so part 2 is going to take some time (especially in the context of the resync & iterators).

Part 3 is necessary for backwards compatibility, and because there is some setup the SDK needs to do behind the scenes whenever a user wants a new VRF.

I'll keep you posted as we begin work on this.

[rmadsen]

Just a quick update: we've started work on this. Also, while implementing this feature, I realized we don't have to do step 3 above after all. This means that all you have to do to program a route in a VRF is to fill out the new vrf attribute in eos::ip_route_key_t.