On Thu, May 14, 2015 at 03:31:09PM -0400, Michel Blais wrote: > Thanks Claudio for answering > > I added the option "nexthop qualify via bgp" and now, route are now valid. > I found this option from a post from you on this old thread: > http://openbsd-archive.7691.n7.nabble.com/what-s-makes-a-route-not-valid-in-o > penbgpd-td51614.html > > # bgpctl show fib YYY.YYY.143.199 > flags: * = valid, B = BGP, C = Connected, S = Static > N = BGP Nexthop reachable via this route > r = reject route, b = blackhole route > > flags prio destination gateway > *BN 48 YYY.YYY.128.0/20 XXX.XXX.111.29 > > > XXX.XXX.111.29 is the gateway of AS5769. > > # bgpctl show rib YYY.YYY.128.0/20 > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > *> YYY.YYY.128.0/20 YYY.YYY.143.199 100 0 22652 i > * YYY.YYY.128.0/20 XXX.XXX.111.29 100 0 5769 6453 22652 i > > No default route on the system. If I understand well, the problem would be > that route to reach AS22652 neighbor pass through AS5769 ? Should I filter > this subnet for AS5769 instead of using option "next hop qualify via BGP" ? > I presume this option is unsecure. >
So YYY.YYY.143.199 is not directly connected to your router and therefor you configured a multihop session to that peer. In this case the best thing is to install a static route to YYY.YYY.143.199 over the link you actually want to talk to this peer. Using "nexthop qualify via bgp" is dangerous since you can quickly produce routing loops and other scary problems. So in short: When doing multihop sessions the network of the remote neighbor is either announced via an IGP (like ospfd) or is added as static route. In both cases bgpd will consider the nexthop as valid. -- :wq Claudio
