[quagga-dev 11978] Re: [PATCH] bgpd: Deprecate 'neighbour ... interface', replace peer->interface with update_if

Paul Jakma 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?

regards,
-- 
Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
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 mailing list