> 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.
