I'm trying to resolve a problem with system startup involving zebra,
ospfd and NetworkManager.
First question is, is it necessary to wait for interfaces to be up
before starting zebra/ospfd? What exactly is the minimum required
interface state? Interface(s) just up? Or do they need to be up with
an IPv4 address? Something else?
Or can I avoid gating starting zebra/ospfd on anything to do with
interfaces and zebra/ospfd will just start to use interfaces as they
are brought up?
The problem I am having currently is that what seems to happen is that
after the interface, zebra and ospfd are up, NetworkManager finds a
reason to reset the interface, completely tearing it down and bringing
back up again. Let's ignore why NM is doing this for the moment and
just accept that there are states where NM needs to do this. It
doesn't really have to be NM doing this. Even on an NM-less machine,
one could need to bring and interface down and then back up.
What is happening though, is that after this teardown/bringup,
zebra/ospfd manages to restore all of the OSPF learned routes except
the default route:
10.0.0.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.8.0.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.75.22.0/24 dev enp2s0 proto kernel scope link src 10.75.22.247 metric 100
10.75.22.247 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.75.23.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
67.193.224.0/20 via 10.75.22.252 dev enp2s0 proto zebra metric 20
67.193.224.1 via 10.75.22.252 dev enp2s0 proto zebra metric 20
192.168.101.0/24 proto zebra metric 20
nexthop via 10.75.22.196 dev enp2s0 weight 1
nexthop via 10.75.22.252 dev enp2s0 weight 1
192.168.199.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
206.248.155.132 via 10.75.22.252 dev enp2s0 proto zebra metric 20
But why? Why are all of the routes *except* the default route
restored? That all but the default route are restored seems to
indicate that zebra/ospfd *should* handle interfaces being torn down
and brought back up, but with this one caveat that the default route is
not being restored.
Any ideas?
I'm using quagga-0.99.22.4 here.
Cheers,
b.
ospfd and NetworkManager.
First question is, is it necessary to wait for interfaces to be up
before starting zebra/ospfd? What exactly is the minimum required
interface state? Interface(s) just up? Or do they need to be up with
an IPv4 address? Something else?
Or can I avoid gating starting zebra/ospfd on anything to do with
interfaces and zebra/ospfd will just start to use interfaces as they
are brought up?
The problem I am having currently is that what seems to happen is that
after the interface, zebra and ospfd are up, NetworkManager finds a
reason to reset the interface, completely tearing it down and bringing
back up again. Let's ignore why NM is doing this for the moment and
just accept that there are states where NM needs to do this. It
doesn't really have to be NM doing this. Even on an NM-less machine,
one could need to bring and interface down and then back up.
What is happening though, is that after this teardown/bringup,
zebra/ospfd manages to restore all of the OSPF learned routes except
the default route:
10.0.0.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.8.0.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.75.22.0/24 dev enp2s0 proto kernel scope link src 10.75.22.247 metric 100
10.75.22.247 via 10.75.22.252 dev enp2s0 proto zebra metric 20
10.75.23.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
67.193.224.0/20 via 10.75.22.252 dev enp2s0 proto zebra metric 20
67.193.224.1 via 10.75.22.252 dev enp2s0 proto zebra metric 20
192.168.101.0/24 proto zebra metric 20
nexthop via 10.75.22.196 dev enp2s0 weight 1
nexthop via 10.75.22.252 dev enp2s0 weight 1
192.168.199.0/24 via 10.75.22.252 dev enp2s0 proto zebra metric 20
206.248.155.132 via 10.75.22.252 dev enp2s0 proto zebra metric 20
But why? Why are all of the routes *except* the default route
restored? That all but the default route are restored seems to
indicate that zebra/ospfd *should* handle interfaces being torn down
and brought back up, but with this one caveat that the default route is
not being restored.
Any ideas?
I'm using quagga-0.99.22.4 here.
Cheers,
b.