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 [email protected] @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_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
