BGP attribute ext-next-hop

[Arvin Gan]

Hi ,
    Thanks for your response.  Could you help me for another question. If ext-next-hop is enabled and AFI is BGP_AF_IPV4, next- hop is a IPV4 address, when update message created, the function bgp_create_mp_reach is called, what is the format of UPDATE message ? Firstly, bgp_encode_attrs  function encode all attributes, is the attribute BA_NEXT_HOP encoded in this step ?  If yes, as comment said, IPV4 NLRI is not used; If no, bgp_encode_next_hop assert next-hop is 16 bytes or 32 bytes, but IPV4 next-hop is 4 bytes....
   
Thanks
Arvin

-----Original Message-----
From: Ondrej Zajicek <santiago at crfreenet.org> 
Sent: Tuesday, April 03, 2018 10:14 PM
To: Arvin Gan <AGan at advaoptical.com>
Cc: bird-users at network.cz
Subject: Re: BGP attribute ext-next-hop

On Tue, Apr 03, 2018 at 09:42:18AM +0000, Arvin Gan wrote:
> Hi all,
> 
>     The version of my bird is 2.0.0,  I found the source code of bird can support the attribute ext_next_hop for BGP, and this attribute is also parsed in cf-parse.y, but cannot found in user's guide document.
> Does anyone know  what configuration is coherent with the attribute ext_next_hop?  Is  the attribute ext_next_hop fully supported in version 2.0.0 ?

Hi

'extended next hop' is a BGP channel option, is fully supported in version 2.0.2 (and likely also in 2.0.0 but i think there were some bugfixes in this). Unfortunately we forgot to document it. Will fix that.
See doc/bird.conf.example2, where it is used (but commented out).

The option allows to use IPv4 next hop with IPv6 routes and vice versa.
For IPv4 channels, it requires that the peer announces the support by the capability (RFC 5549). For IPv6 channels there is no relevant capability.
It can be used with all BGP channels with the exception of flowspec ones, which do not have next hops anyways).

It is disabled by default, but perhaps we should change it to be enabled by default for MPLS/VPNv6 channel (not sure what are expectations here).

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."