Hi ,
   Thanks for so quick reply. Do you mean if (s->channel->afi == BGP_AF_IPV4) 
maybe have bug,  need change to if (s->channel->afi == BGP_AF_IPV4 && 
!s->channel-> ext_next_hop) ?

Thanks
Arvin

-----Original Message-----
From: Ondrej Zajicek <santi...@crfreenet.org> 
Sent: Wednesday, April 11, 2018 5:26 PM
To: Arvin Gan <a...@advaoptical.com>
Cc: bird-users@network.cz
Subject: Re: BGP attribute ext-next-hop

On Wed, Apr 11, 2018 at 07:55:28AM +0000, Arvin Gan wrote:
> 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 ?

Hi

In traditional BGP (encoded by bgp_create_ip_reach() function), NEXT_HOP is 
encoded like other attributes by bgp_encode_next_hop() function from attrs.c 
file as part of bgp_encode_attrs().

In MP-BGP (encoded by bgp_create_mp_reach() function), NEXT_HOP attribute 
should not be encoded independently as part of bgp_encode_attrs(), but is 
encoded by bgp_encode_next_hop_ip() function (or its variant based on SAFI), 
called through dispatch function directly from bgp_create_mp_reach()).

But now when i checked it, it seem like the condition in
bgp_encode_next_hop() does not take in to account ext-next-hop option.
So it is possible there is a bug here.


> 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....

The assert in bgp_encode_next_hop_ip() function checks the length of the 
internal representation of the next hop, which is always 16 bytes (type 
ip_addr), even if IPv4 next hop is used (in such case it is encoded as 
IPv4-mapped IPv6 address). Function ipa_to_ip4() gets 4B ip4_addr from 16B 
ip_addr.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@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."

Reply via email to