On Tue, May 28, 2019 at 05:17:08PM +0200, Claudio Jeker wrote: > On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote: > > 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. > > I came to a similar conclusion and will send out a better diff. The > idea is that for the non-multihop BGP sessions we should require the > nexthop to be in the same network.
With 'same network', you mean the NEXT_HOP IP address must be part of the router-to-router linknet, right? > The ebgp multihop case is currently always sticking to the local > address and should probably respect the nexthop if set explicitly > (that is also what the RFC suggests). Right. > ibgp seems to do the right thing. yup, in IBGP the NEXT_HOP can be anything. > The same rules need to be applied to "set nexthop no-modify" since > that is currently on massive hammer. Right. Thanks! Kind regards, Job
