Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2017 13:56:13 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
Cc:        sthaug@nethelp.no, freebsd-net@freebsd.org, crest@rlwinm.de
Subject:   Re: Changes to route(8) or routing between r325235 and r326782?
Message-ID:  <5A32208D.3070500@grosbein.net>
In-Reply-To: <201712122021.vBCKL219088220@pdx.rh.CN85.dnsmgr.net>
References:  <201712122021.vBCKL219088220@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 13.12.2017 03:21, Rodney W. Grimes wrote:

> Flap your intgerfaces and see what happens when quagga and the kernel fight
> over who gets to install the local MTU route via lo of the ip address for
> the interface you flapped.

I do not see any problem here. After service quagga restart:

# egrep 'zebra|ospfd' /var/log/messages
Dec 14 13:48:43 ptic zebra[96288]: Zebra 1.2.1 starting: vty@2601
...
Dec 14 13:48:46 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif0:192.168.100.234: Loading -> Full (LoadingDone)
Dec 14 13:48:46 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Loading -> Full (LoadingDone)

# ifconfig gif1 down
# ifconfig gif1 up

This adds to /var/log/messages:

Dec 14 13:49:01 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Full -> Deleted (KillNbr)
Dec 14 13:49:01 ptic zebra[96288]: if_ioctl(SIOCGIFMEDIA) failed: Invalid argument
Dec 14 13:49:01 ptic zebra[96288]: kernel_rtm_ipv4: 192.168.100.132/30: rtm_write() unexpectedly returned -4 for command RTM_DELETE
Dec 14 13:49:04 ptic zebra[96288]: if_ioctl(SIOCGIFMEDIA) failed: Invalid argument
Dec 14 13:49:04 ptic ospfd[96297]: OSPF MPLS-TE: Abort update TE parameters: no Link Parameters for interface
Dec 14 13:49:06 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Exchange -> Full (ExchangeDone)

There is no fight. Why don't you describe *your* setup in a PR so we could handle it right way?
Perhaps, we could add another sysctl to disable route pinning if it really unavoidable for such setups.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A32208D.3070500>