Date: Wed, 22 May 2002 10:48:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Vladimir B. Grebenschikov" <vova@sw.ru> Cc: Oleg Chebotarev <chebotarev@yahoo.com>, freebsd-current@FreeBSD.org Subject: Re: multi default routes in freebsd !? Message-ID: <3CEBD9E5.58E633A@mindspring.com> References: <20020521032746.14287.qmail@web11607.mail.yahoo.com> <3CE9DD37.88DDCABC@mindspring.com> <1021965925.557.9.camel@vbook.express.ru> <3CEA0FC0.E71EC770@mindspring.com> <1021977292.24428.30.camel@vbook.express.ru> <3CEAB378.D4B7F9E@mindspring.com> <1022056574.460.30.camel@vbook.express.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
"Vladimir B. Grebenschikov" wrote: > > Without the cooperation of the tother end, you don't have > > control of the symmetry of the return route. So maybe > > your packets are round-robin'ed out interfaces, but they > > all come back through the same interface, because you have > > no control of the other end. > > On other end I have providers CISCO router _with_ standard BGP multipath > feature, so I have symmetric situation. This is a circular argument. Why can't you use BGP on FreeBSD, then, instead of having to invent this new thing? > > > If interface goes down route will be DOWN by kernel. > > > So it is not problem. > > > > No. > > > > ,---------------. > > | BOX WITH TWO | > > ,-------| DEF. ROUTES |-------. > > route #1 | `---------------' | route #2 > > | | > > ,---------------. ,---------------. > > | ROUTER "A" | | ROUTER "B" | > > `---------------' `---------------' > > | | > > | | > > good link dead link > > > > The link between the box and "router B" remains up. Therefore the > > box fails to note that packets sent via "route #2" never get to > > their destination. > > No, if link BOX<->routerB fails kernel must down one of two routes with > same prefix (you said default). Since this is a cable you own, it's highly unlikely. You are much more likely to lose your T1 on the *other side* of "router B". > If from side of BOX it is noot seen thar carrier (whatever) on link > BOX<->routerB down - BGP session over this link will down so, BGP > software will down route. On the ISP side, which does not affect packets you send, since you are refusing to run BGP, or you won't need the hack. > I am not happy with hack pach when one route have more then one gateway, > may opinion to allow insert more then one full-featured route to one > prefix into kernel FIB, but it is implementation issue. No. The hack for multiple default routes implicitly assumes that it is not a protocol issue that it's trying to solve. The problem you have requires a protocol to solve it. I'm not surprised that it doesn't make you happy: it's not a fix for your problem. [ ... ] > Again multipath IS in BGP concept not it is FreeBSD kernel hack for BGP > because can't do multipath. Are you saying that this is a feature that the FreeBSD BGP lacks? > > So it is not a "routing protocol solution" in any sense of things. > > As I already said I am not fight for these patches - for me it is ugly > hack, I fight for multiple routes for one prefix in kernel. This is the classic seperation of the control plane from the data plane. It is a good thing. The patches only implement, they do not set policy. It is the job of other software to set policy. > > I don't think you can get what you want without the cooperation > > of the other end of the link. If you want FEC, then use Bill Paul's > > FEC code, which does the channel bonding that you seem to want. But > > you will need the other end to cooperate. > > I know, anyway thinks like FEC will only solve problem of connecting > two boxes by some number of links but will not solve problem of > many x many connection. I don't think anything short of source routing can really solve the problem that you are saying you have, because that's the only way you will get to dictate the return path for response packets. > > > My opinion - it is useful feature for FreeBSD kernel, often used now > > > as good routing platform. > > > > I already said that I think the code should be committed to the > > main line kernel, and preserved. > > May be it is better to discuss a bit what we want to have in kernel > exactly ? I think better to have another rt_entry structure for > second/third/etc routes for some prefix. Only modifications it will take > - lookup algorithm > ( I think radix tree code will need some modification ) > - forwarding code ( need to choose one of few routes ) > - code for add/delete/get routes (something like "allow multipath" > option for addition and "remove all" for deletion) You seem to imply that this will fix a bug in the FreeBSD BGP implementation; what bug? If it's not a FreeBSD bug, then what problem are you trying to solve? You can't control the return path for responses to packets you send out. How does doing this "make FreeBSD more like Cisco"? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CEBD9E5.58E633A>