Management VRF on FRR containers

[ipspace]

FRR uses its management IP address in routing protocols, which causes some confusion in IPv6-only networks (and some default route issues).

We could implement the management VRF in FRR, but that could disable outbound communication with the outside world (example: installation of additional software). Have to check what could be done.

[jbemmel]

Have something in the works

{% else %}
#
# On Containerlab put eth0 in its own netns, so FRR daemons don't get confused.
# For example, isisd sends the mgmt IP as router ID
#
ip netns add mgmt
ip link set eth0 netns mgmt
{% endif %}

[ipspace]

Have something in the works

This creates a completely new namespace, which means that the existing daemons won't be able to access it. It would be easier to shut down the management interface or remove IP address from it.

[jbemmel]

It is not modeled in the FRR config, so I don't understand why the ISIS daemon takes it into consideration. To me that's a bug

By putting it in a separate namespace, we can still access it from the outside and do things like install software etc. but it's not implicitly taken into consideration

Another option would be to model it in FRR as a separate vrf, that's even cleaner (but not easier than this 2-line patch :)

[ipspace]

It is not modeled in the FRR config, so I don't understand why the ISIS daemon takes it into consideration. To me that's a bug

Because it needs an IPv4 Router ID.

By putting it in a separate namespace, we can still access it from the outside

And what daemons would be listening to incoming requests on that interface?

Another option would be to model it in FRR as a separate vrf, that's even cleaner (but not easier than this 2-line patch :)

That would be the correct way to go.