Date: Mon, 22 Jun 2020 22:33:39 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "current@FreeBSD.org" <current@freebsd.org>, net <net@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: routed && route6d removal proposal Message-ID: <202006230533.05N5XdsD013964@gndrsh.dnsmgr.net> In-Reply-To: <33c892bf-5d71-cd65-3041-449cc1bf6e6b@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 23.06.2020 2:26, Rodney W. Grimes wrote: > > >> 22.06.2020 19:49, Rodney W. Grimes wrote: > >>> Whats unmaintained about code that has no need to change cause it just pretty much works? > >> Have you actually tried running routed(8) as base for real network with loops, > >> mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lists and > >> with diameter about 6 hops? > > > > As I said I know of people that are running and it is working, and > > Hiroko's post clearly establishes that as fact in evidence. > > > > I am not even sure that RIP* has loop detection in the protocol, > > It has, of course. Slight miss communications, there really isnt a loop detection in the on wire protocol, or multipath support, it simply excludes certain routes that end up excluded by counting to infinity to stop the loop (inifinity is usually 16 for this solution). Its not like OSPF or BGP where you can calculate loops and mulipath effects. Bottom line, RipV2 is not healthy on a network when loops exist, though it should not lead to failure. > > > as the prefered routing protocol for anything multipath (which > > is what loops are in effect) is OSPF. > > RIPv2 may be used for failover, not for multipath. Any redundant route creates L3 "multipath". Yes. > >> I'm not talking about RIPv2 inherent deficiencies. > >> Our routed just glitches where quagga's ripd just works. > > > > And your PR# for reporting the bug is? > > Was. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=51927 > Never had a chance to verify if it was really fixed in HEAD because it was not for RELENG_4, > so I moved to ripd. As you may remeber, RELENG_5 needed much time to become ready for production. I can not find any commit linked to that bug, but this is probalby before the system to do that existed. Unless we can confirm the bug still exists I think it would be predunt to assume it is fixed based on what I read in the PR, so dismissing the claim that the inbase routed "just glitches." Can you agree with that logic Eugene? Regards, -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202006230533.05N5XdsD013964>