Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Quagga>
  3. Users
ospf learned default route not being re-installed after interface reset
brian at interlinx
Mar 27, 2018, 6:09 AM
Post #1 of 6 (1191 views)
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.

Attached Files:

Re: ospf learned default route not being re-installed after interface reset [ In reply to ]
tim at kooky
Mar 27, 2018, 6:26 AM
Post #2 of 6 (1191 views)
Permalink
On 27/03/18 14:09, Brian J. Murrell wrote:
> 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


> 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.

>
> 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.

> 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
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users
Re: ospf learned default route not being re-installed after interface reset [ In reply to ]
brian at interlinx
Mar 27, 2018, 8:47 AM
Post #3 of 6 (1191 views)
Permalink
On Tue, 2018-03-27 at 14:26 +0100, Tim Bray wrote:
>
> 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...

> 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.

> 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.

Attached Files:

Re: ospf learned default route not being re-installed after interface reset [ In reply to ]
tim at kooky
Mar 27, 2018, 9:04 AM
Post #4 of 6 (1191 views)
Permalink
On 27/03/18 16:47, Brian J. Murrell wrote:
> 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
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users
Re: ospf learned default route not being re-installed after interface reset [ In reply to ]
brian at interlinx
Mar 27, 2018, 11:09 AM
Post #5 of 6 (1191 views)
Permalink
On Tue, 2018-03-27 at 17:04 +0100, Tim Bray wrote:
>
> 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.

Attached Files:

Re: ospf learned default route not being re-installed after interface reset [ In reply to ]
brian at interlinx
Mar 28, 2018, 3:22 AM
Post #6 of 6 (1189 views)
Permalink
On Tue, 2018-03-27 at 14:09 -0400, Brian J. Murrell wrote:
> On Tue, 2018-03-27 at 17:04 +0100, Tim Bray wrote:
> >
> > 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.

Attached Files:

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal