Discussion:
[quagga-users 14964] ospf learned default route not being re-installed after interface reset
Brian J. Murrell
2018-03-27 13:09:55 UTC
Permalink
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.
Tim Bray
2018-03-27 13:26:54 UTC
Permalink
Post by Brian J. Murrell
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?
I think if you have your interfaces set as link detect in zebra, then no
need to wait.  When the interface comes up, zebra/quagga will go their
thing.

interface eth0
 link-detect
Post by Brian J. Murrell
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?
I think you are fine if you use link-detect.
Post by Brian J. Murrell
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.
On a debian machine

I put

iface eno1 inet manual

into /etc/network/interfaces and NM leaves alone.  I have nothing else
to bring the interface up, I think Zebra will do it for you.

Sorry, I don't really have a way to test this.
Post by Brian J. Murrell
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.
Are you expecting to receive the default route via OSPF?



Tim
Brian J. Murrell
2018-03-27 15:47:18 UTC
Permalink
Post by Tim Bray
I think if you have your interfaces set as link detect in zebra, then no
need to wait. When the interface comes up, zebra/quagga will go
their
thing.
interface eth0
link-detect
I'll give that a try...
Post by Tim Bray
On a debian machine
I put
iface eno1 inet manual
into /etc/network/interfaces and NM leaves alone. I have nothing
else
to bring the interface up, I think Zebra will do it for you.
How does zebra know what ip address/netmask/etc. to assign? I actually
didn't know Zebra would do full interface management.
Post by Tim Bray
Are you expecting to receive the default route via OSPF?
Yes, as I do when NM doesn't have to reset the interface:

default via 10.75.22.252 dev enp2s0 proto zebra metric 50
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

I can actually reproduce without even rebooting by simply doing "ifdown
enp2s0; ifup enp2s0". After doing that, all of the above routes are
restored except the default route.

Cheers,
b.
Tim Bray
2018-03-27 16:04:25 UTC
Permalink
Post by Brian J. Murrell
How does zebra know what ip address/netmask/etc. to assign? I actually
didn't know Zebra would do full interface management.
Look here http://www.nongnu.org/quagga/docs/quagga.html#Interface-Commands

Commands in zebra like

interface enp2s0
  ip address 10.75.22.252/24
  link-detect


Has the advantage that the routes disappear when the ethernet cable
falls out or the switch powers off.


Can you check the default route exists in ospf (rather than just in zebra)


telnet localhost 2604    / vtsh

and

show ip ospf route



and you are looking for 0.0.0.0/0, probably under OSPF external routing
table

Tim
Brian J. Murrell
2018-03-27 18:09:11 UTC
Permalink
Post by Tim Bray
and you are looking for 0.0.0.0/0, probably under OSPF external routing
table
============ OSPF external routing table ===========
N E2 0.0.0.0/0 [10/50] tag: 0
via 10.75.22.252, enp2s0

Cheers,
b.
Brian J. Murrell
2018-03-28 10:22:18 UTC
Permalink
Post by Brian J. Murrell
Post by Tim Bray
and you are looking for 0.0.0.0/0, probably under OSPF external routing
table
============ OSPF external routing table ===========
N E2 0.0.0.0/0 [10/50] tag: 0
So is this a bug in quagga that a (OSPF) distributed default route does
not get installed after an interface is torn down and brought back up?

b.

Loading...