[quagga-dev 11978] Re: [PATCH] bgpd: Deprecate 'neighbour ... interface', replace peer->interface with update_if
paul at jakma.org
Fri Jan 23 18:30:13 GMT 2015
On Fri, 23 Jan 2015, David Lamparter wrote:
> You're removing the possibility to bind to a specific ipv6 address on an
> interface, e.g.:
> neighbor fe80::1234 interface eth0
> neighbor fe80::1234 update-source fe80::2345
> This is relevant since there is often an autogenerated MAC-derived
> linklocal plus an admin-configured easily-remembered one.
Yeah, that'd break.
I looked at this because bgp_nexthop_set seems to be pretty badly broken
on v6, or at least it's very naïve and works only in certain cases and
does daft things in many others. Trying to fix it is complicated by the
interplay of update-source, interface, and the v6 address being either
global or ll. I was hoping to simplify away one of those factors!
To summarise some off-list discussion we've had (from my POV anyway :) ):
I'm not a fan of running BGP between LL addresses myself, but you've
pointed to a few drafts that indicate others seem to find it advantageous.
I think bgpd is somewhat broken for BGP-on-LL at the moment, though I
guess it works for some. You've also pointed at the issue that LL
addresses need not be unique, which make 'neighbour <non unique LL> ...'
problematic. You mentioned <LL>%<iface> syntax. That'd be a bit of a job
to make work for the 'neighbour ..' key. That syntax could be also be used
in the update-source above, of course.
I guess the thing here is to figure out what is the minimum, sane & tidy
UI we need to support v4, v6 and v6-ll, in terms of neighbour keys, source
address & bind interface, and nexthop resolution?
Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
Bernard Shaw is an excellent man; he has not an enemy in the world, and
none of his friends like him either.
-- Oscar Wilde
More information about the Quagga-dev