Hi, On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote: > When using a rule forcing the nexthop to a specific address bgpd > currently does not mark that nexthop as no-modify. In other words > the default rules for nexthop propagation applies. This means that > for ebgp it only sends out the set nexthop when this nexthop is connected > and on the same network as the peer. So while the Adj-RIB-Out shows the > right nexthop it is actually not on the wire. > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop > no-modify. This way the set nexthop is always on the wire. > The problem with that is that it will hand you a nice footgun ready to > blow of your big toe (but in the end the current behaviour is doing the > same just with a different angle of attack) . > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a > decision is made on how to handle this.
I think I'm not a big fan of this change. Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on what NEXT_HOPs are valid to send over a non-multihop BGP session. Only addresses that are part of the linknet between the two routers are valid NEXT_HOP addresses on the wire. This changes makes it trivial to send not-valid NEXT_HOPs to a neighbor, this may result in very hard to debug troublecases. Feels like we'll be handing way too much rope to users, especially since it facilitates protocol violations. I am not aware of a real world BGP implementation that would allow you to send completely arbitrary NEXT_HOPs. Kind regards, Job
