> 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
Ping the IP address of gif1 here, why can you still ping the if address
of an administratively down interface? That is just fundementally
wrong in so many ways.
> # 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.
I suspect your no longer seeing the bad messages cause your route is now
-pinned and does nolonger alterable by anyone other than someone specifically
using a -pinned arg to the calls.
You have now hardwired a permanent route to the local IP address of any
interface weither that interface is up or not. And done so in a way that
is not easy to work around without altering kernel source code.
Rather than file a PR I well write a differential that simply wraps a knob
around all this *maintain_looopback_route() non-sense so that kernels can
be bulit without it, and inside that knob add a sysctl to turn the behavior
on and off so that those caught, like the reporting person on the mail
list that got hammered by your MFC, can quickly recover with a loader.conf
variable.
Proposed option and sysctl names for bikeshed of colour blue:
options MAINTAIN_LOOPBACK_ROUTE #Maintain a pinned and always present
#(even when interface is down) route
#to the local IP of all interfaces
sysctl net.route.maintain_loopback_route=1
The above well be the defaults, IE, in GENERIC and sysctl set to 1,
that well maintain YOUR bad behavior, but allow me and others to
easily correct for it.
OK?
--
Rod Grimes rgri...@freebsd.org
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
