RE: BGP attribute ext-next-hop
Hi, Thanks! Thanks Arvin -Original Message- From: Ondrej Zajicek <santi...@crfreenet.org> Sent: Tuesday, April 17, 2018 8:22 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 02:52:46PM +0200, Ondrej Zajicek wrote: > On Wed, Apr 11, 2018 at 09:57:44AM +, Arvin Gan wrote: > > 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) ? > > Yes, likely. I will check that. Yes, it was a bug, here is the fix: https://gitlab.labs.nic.cz/labs/bird/commit/f3a8cf050e6181e158dcde2fe885d7bf220eedc3 -- 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."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 02:52:46PM +0200, Ondrej Zajicek wrote: > On Wed, Apr 11, 2018 at 09:57:44AM +, Arvin Gan wrote: > > 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) ? > > Yes, likely. I will check that. Yes, it was a bug, here is the fix: https://gitlab.labs.nic.cz/labs/bird/commit/f3a8cf050e6181e158dcde2fe885d7bf220eedc3 -- 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."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 10:41:25AM +, Arvin Gan wrote: > Hi, > > I found the traditional BGP and MP-BGP are independent in bird, > if use MP_REACH_NLRI, IPV4 NLRI are not used. Has any case that need to > support traditional BGP and MP-BGP at the same time ? That mean have a > configuration option that create UPDATE message with MP-BGP and > traditional BGP, transmit IPV4 route and IPV6 route in one UPDATE > message. Hi Mixing traditional BGP and MP-BGP in one UPDATE is forbidden by RFC 7606, section 5.1. Of course, if you have BGP session with both IPv4 and IPv6, then both traditional BGP and MP-BGP can be used in one session, but not in one UPDATE. -- 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."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 09:57:44AM +, Arvin Gan wrote: > 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) ? Yes, likely. I will check that. -- 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."
RE: BGP attribute ext-next-hop
Hi, I found the traditional BGP and MP-BGP are independent in bird, if use MP_REACH_NLRI, IPV4 NLRI are not used. Has any case that need to support traditional BGP and MP-BGP at the same time ? That mean have a configuration option that create UPDATE message with MP-BGP and traditional BGP, transmit IPV4 route and IPV6 route in one UPDATE message. 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 +, 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."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 07:55:28AM +, 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."
