From: Stuart Henderson (stuspacehopper.org)
Date: Fri Jan 26 2007 - 06:36:18 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> well, it turns out that the machine can't see their neighbours too
> well. The iBGP peer isn't listed,

'bgpctl sh nex' lists *nexthops*, not peers. nexthops are not re-
written unless you 'set nexthop self', they stay as learned from the
e-bgp sessions.

> and the upstream is now marked "invalid" although they can both be
> reached via static routes, are up,
...
> What does "invalid" in this case mean?

unless you change 'nexthop qualify', it means not reachable by either:

directly-connected network
static (non-default) route
route learned from a different protocol (ospf/rip)

additional options if you change 'nexthop qualify' are:

default route
bgp route

but there's a reason these are not default.

> and the session (in 'bgpctl show') to the iBGP peer was, and is, up
> at all times. The iBGP peer is even on the same LAN segment, and the
> summary output says that the session to this peer is now up for 2+
> hours (I restarted it this morning, it was well over a week old
> before).

the path to the ibgp peer is irrelevant, it's the path to the
nexthop learned by bgp that's important.

the ibgp announcement with the prefix is _not_ necessarily sent
by the router with the external session, you may be using a route
reflector.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]