On 12/04/06, tony sarendal <[EMAIL PROTECTED]> wrote: > > > > On 12/04/06, Sylvain Coutant <[EMAIL PROTECTED]> 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. > > > > > > > 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. > > > > > > > No, the session and the nexthop are two different things. > > > > I agree. My point is : how to prevent routing loops in such cases ? > > 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 ? > > > That sounds like fixing a bug with an option. > In your case the problem is that a connected next-hop is considered > invalid, right ? >
Sorry, cut that a bit short. If you your router receives a prefix with a next-hop it can't resolv then that prefix isn't valid and will not be used and not be advertised to other peers, so the option of dropping the session serves no purpose. If your network receives the same prefix or superblock from another path then that path will be used. /Tony
