On 10/14/11 15:38 , Ondrej Zajicek wrote:
On Thu, Oct 13, 2011 at 01:03:52PM +0200, Mathias Wolkert wrote:
Hi
I need to alter the next_hop for IPv6 prefixes advertised over IPv6 eBGP.
I'm using a filter that says "bgp_next_hop = x:x:0:1c::1 ;". And it is seen in the birdc6 with: show route all <filtername> as
BGP.next_hop: x:x:0:1c::1
but on the line I see:
Next hop: x:x:0:1c::2 (16) #The GUA of the router Next hop: fe80::230:48ff:feba:6b17 (16) #The LL of the router
which also is what I see on the receiving cisco.
Has this behavior changed? i believe I had this working in bird-1.2.5
I don't think so.
See 'missing lladdr' option, it is probably related to your problem. You probably need to set it to 'ignore'.
So you believe it will send only GUA if I set lladdr to ignore?
I'm now running bird-1.3.5 on Debian Lenny.
What I'm really looking for is a way to only send a manually set globally unique address and no link-local.
When I read the bird docs, it seems odd that this is referred to as a "improper bgp update".
My interpretation of rfc2545 section 3 is that link-local is optional.
I don't think so:
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to ...
That does not sound as optional - if the condition (common subnet) is satisfied, link-local address should be used, otherwise it shouldn't.
Well, I think this is confusing... today when I read it, I agree with you.
But in some cases it is inevitable, esp. on route servers.
My general feeling is that what was simple in IPv4, is not thought through in IPv6.
I agree, this issue with link-local address in BGP updates is a bit ugly.
Thanks for the empathy. :) /Tias