On 12/04/06, Claudio Jeker <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 12, 2006 at 01:58:24PM +0100, tony sarendal wrote: > > On 12/04/06, Claudio Jeker <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Apr 12, 2006 at 01:36:46PM +0200, Sylvain Coutant wrote: > > > > > What was the state of the parent interface and what kind of > interface > > > is > > > > > it? > > > > > > > > Bge driver. It was up and running : BGP sessions were established > > > > through the vlans reported as invalid by OpenBGP. > > > > > > > > > > I bet Henning's diff will fix this. > > > > > > > > > > > > ifconfig down should not crash the box. Panic message and trace > would > > > be > > > > > interesting. > > > > > > > > It was remote and we did a hard reboot without console access. Log > files > > > > were empty. > > > > > > > > > > Bummer. > > > > > > > > > > > > No, the session and the nexthop are two different things. > > > > > > > > I agree. My point is : how to prevent routing loops in such cases ? > > > > > > How should routing loops happen if you do not announce those invalid > > > routes? Prefixes with an invalid netxhop are not used and are not > > > redistributed. > > > > > > > Whatever triggered the case (a link down for any reason or a bug) is > not > > > > so important. Announcing routes over the Internet and creating a > routing > > > > loop for those routes is important. > > > > > > > > It could be one more setting that, if set to yes, would drop the > session > > > > if it receives an unreachable nexthop ... just an idea. It could > default > > > > to yes for eBGP session and no for iBGP sessions. Would that fit > most of > > > > "usual" cases ? > > > > > > > > > > No way. This is not how BGP works and will break in many cases. > > > > > > -- > > > :wq Claudio > > > > > > > > But speaking of routing loops, I suspect that there is something wrong > with > > the > > route-reflector part. I can introduce routing loops into my test network > by > > flapping > > prefixes. Before I wrote this I flapped 13.0.0.0/8 just once in my test > > network: > > > > View from the route-server which peers with all routers: > > > > quagga-bgpd# sh ip bgp 13.0.0.0 > > BGP routing table entry for 13.0.0.0/8 > > Paths: (7 available, best #7, table Default-IP-Routing-Table) > > Not advertised to any peer > > Local > > 10.1.1.22 from 10.0.0.5 (10.0.0.2) > > Origin IGP, metric 900, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 10.0.0.5 10.0.0.6 10.0.0.8 > > 172.16.0.3 10.0.0.7 10.0.0.4 172.16.0.2 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 10.1.1.26 from 10.0.0.4 (10.0.0.2) > > Origin IGP, metric 700, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 10.0.0.4 10.0.0.7 10.0.0.8 > > 10.0.0.6 10.0.0.5 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 172.16.1.13 from 172.16.0.2 (10.0.0.2) > > Origin IGP, metric 800, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 172.16.0.2 10.0.0.4 10.0.0.7 > > 10.0.0.8 10.0.0.6 10.0.0.5 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 10.1.1.34 from 10.0.0.6 (10.0.0.2) > > Origin IGP, metric 800, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 10.0.0.6 10.0.0.8 172.16.0.3 > > 10.0.0.7 10.0.0.4 172.16.0.2 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 172.16.1.21 from 10.0.0.8 (10.0.0.2) > > Origin IGP, metric 700, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 10.0.0.8 172.16.0.3 10.0.0.7 > > 10.0.0.4 172.16.0.2 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 172.16.1.18 from 172.16.0.3 (10.0.0.2) > > Origin IGP, metric 700, localpref 100, valid, internal > > Originator: 10.0.0.2, Cluster list: 172.16.0.3 10.0.0.7 10.0.0.8 > > 10.0.0.6 10.0.0.5 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > Local > > 10.1.1.30 from 10.0.0.7 (10.0.0.2) > > Origin IGP, metric 600, localpref 100, valid, internal, best > > Originator: 10.0.0.2, Cluster list: 10.0.0.7 10.0.0.8 10.0.0.6 > > 10.0.0.5 10.0.0.3 10.0.0.1 > > Last update: Wed Apr 12 14:11:25 2006 > > > > quagga-bgpd# > > > > The loop does not occur at the same place everytime. > > > > Do you have a setup with route-reflectors ? > > > > No but I can reconfigure my lab network. > > > Claudio, could my problem have to do with the problem in rde_reflector() > > which you mentioned in another thread ? The cluster-list seems a bit > > screwed up when I trace the prefix from the router with the lowest > metric. > > > > Oh yes. The diff that fixes the attr_compare fatals may help here because > it may have influence on loop detection because attributes are modified > which are referenced by multiple prefixes. > > Sorry I did not have time to actually commit it. > --
I'm applied the attr_compare diff you posted earlier a few days ago, it prevents bgpd from crashing but does not prevent the loops. /Tony
