Re: Am I missing the announcements for New releases or ???

2018-04-11 Thread Stuart Henderson 
On 2018/04/11 14:23, James W. Laferriere wrote:
>   Hello All ,  Am I missing the announcements for New releases or are they
> ONLY on the webpage ?  I really use email except for general reasearch and
> was hoping that the announcements of new releases would be announced here .
>   Hope I am missing something obvious .

They were sent here too,


- Forwarded message from Ondrej Filip  -

From: Ondrej Filip 
Date: Thu, 22 Mar 2018 13:36:55 +0100
To: bird 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
Thunderbird/52.6.0
Subject: BIRD 2.0.2 and 1.6.4

Dear BIRD users,
we just released two new versions - 1.6.4 and 2.0.2. There is an
important security bugfix in both. Upgrade is highly recommended.


Version 2.0.2 (2018-03-22)
  o Source-specific routing support for Linux kernel and Babel
  o BGP: New option 'disable after cease'
  o Filter: Allow silent filter execution
  o Filter: Fixed stack overflow in BGP mask expressions.
  o Several bugfixes

  Notes:

  Syntax prefix:netmask for IPv4 prefixes was dropped. Just use
prefix/pxlen.


Version 1.6.4 (2018-03-22)
  o Basic VRF support
  o Simplified autoconf scripts
  o BGP: Shutdown communication (RFC 8203)
  o BGP: Allow exchanging LOCAL_PREF with eBGP peers
  o BGP: Allow to specify interface for regular sessions
  o BGP: New option 'disable after cease'
  o RAdv: Support for more specific routes (RFC 4191)
  o RAdv: Proper handling of prefix retraction
  o Filter: Allow silent filter execution
  o Filter: Fixed stack overflow in BGP mask expressions.
  o Several bug fixes

Ondrej

- End forwarded message -

Re: Am I missing the announcements for New releases or ???

2018-04-11 Thread Ondrej Filip 
On 12.4.2018 00:23, James W. Laferriere wrote:

Hi!
All releases are announced in this mailing list as well.

Ondrej

> Hello All ,  Am I missing the announcements for New releases or
> are they ONLY on the webpage ?  I really use email except for general
> reasearch and was hoping that the announcements of new releases would
> be announced here .
> Hope I am missing something obvious .
> 
>     Tia ,  JimL

Am I missing the announcements for New releases or ???

2018-04-11 Thread James W. Laferriere 
	Hello All ,  Am I missing the announcements for New releases or are they 
ONLY on the webpage ?  I really use email except for general reasearch and was 
hoping that the announcements of new releases would be announced here .

Hope I am missing something obvious .

Tia ,  JimL
--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+

Re: BGP import route

2018-04-11 Thread RICCARDO RUSSO 
 Ok. I have installed bird via epel on Centos

The router sending BGP announcement is Juniper Open Contrail Virtual Router
(on Openstack). I downloaded and installed the 2.0.2 and used this config:


-
# more /usr/local/etc/bird.conf
log syslog all;
log stderr all;
log "/var/log/bird.logg" all;
debug protocols all;

protocol kernel {
ipv4 {
 import all;
 export all;
};
persist;
scan time 20;
}

protocol device {
scan time 10;   # Scan interfaces every 10 seconds
}

router id 192.168.200.6;

protocol bgp bgp1 {
   local as 64521;
   neighbor 192.168.200.1 as 64520;
   ipv4 {
  import all;
  export all;
   };
}

-

And finally I see all routes:

-
[root@vm-1 bird-2.0.2]# birdc show route
BIRD 2.0.2 ready.
Table master4:
163.162.35.131/32unicast [bgp1 20:48:36.342] * (100) [AS64520?]
via 192.168.200.1 on eth1
163.162.35.80/32 unicast [bgp1 20:48:36.342] * (100) [AS3269i]
via 192.168.200.1 on eth1
100.64.3.28/32   unicast [bgp1 20:48:36.342] * (100) [AS64520?]
via 192.168.200.1 on eth1
...

-

Rr


2018-04-11 19:21 GMT+02:00 Jan Maria Matějka :

> Hello!
>
> First of all, we don't support this old version. Please upgrade, either to
> 1.6.4 or to 2.0.2.
>
> Second, the other side seems to send multiprotocol NLRI to you. BIRD in
> 1.x versions AFAIK does not support this extension and should not announce
> it. What is the remote software?
>
> Writing from my phone with no access to source code, trying to recall it
> from my memory. I might be wrong.
>
> Maria
>
> Quidquid latine dictum sit, altum videtur.
>
> -Original Message-
> From: RICCARDO RUSSO 
> To: bird-users@network.cz
> Sent: Wed, 11 Apr 2018 6:10 PM
> Subject: BGP import route
>
> Hello,
> I'm not able to import route from BGP (CentOS 7). In log file I read "Got
> UPDATE" but  "import updates" is always 0. With TCPDUMP I see that BGP
> receive the routes
>
> Rr
>
> 
> # more bird.conf
> log syslog all;
> log stderr all;
> log "/var/log/bird.logg" all;
> debug protocols all;
>
> protocol kernel {
> persist;# Don't remove routes on bird shutdown
> scan time 20;   # Scan kernel routing table every 20
> seconds
> }
>
> protocol device {
> scan time 10;   # Scan interfaces every 10 seconds
> }
>
> router id 192.168.200.6;
>
> protocol bgp bgp1 {
>local as 64521;
>neighbor 192.168.200.1 as 64520;
>import filter all;
> }
> 
>
>
> 
>
> # tail -f /var/log/bird.logg
> 2018-04-11 17:46:53  kernel1 < interface lo goes up
> 2018-04-11 17:46:53  kernel1 < interface eth0 goes up
> 2018-04-11 17:46:53  kernel1 < interface eth1 goes up
> 2018-04-11 17:46:53  kernel1: State changed to up
> 2018-04-11 17:46:53  bgp1: Started
> 2018-04-11 17:46:53  bgp1: Connect delayed by 5 seconds
> 2018-04-11 17:46:53  kernel1: Scanning routing table
> 2018-04-11 17:46:53  kernel1: 0.0.0.0/0: [alien] ignored
> 2018-04-11 17:46:53  kernel1: 192.168.44.0/24: [alien] ignored
> 2018-04-11 17:46:53  kernel1: Pruning table master
> 2018-04-11 17:46:57  bgp1: Connecting to 192.168.200.1 from local
> address 192.168.200.6
> 2018-04-11 17:46:57  bgp1: Connected
> 2018-04-11 17:46:57  bgp1: Sending
> OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
> 2018-04-11 17:46:57  bgp1: Connection closed
> 2018-04-11 17:46:57  bgp1: Connect delayed by 5 seconds
> 2018-04-11 17:47:03  device1: Scanning interfaces
> 2018-04-11 17:47:03  bgp1: Connecting to 192.168.200.1 from local
> address 192.168.200.6
> 2018-04-11 17:47:03  bgp1: Connected
> 2018-04-11 17:47:03  bgp1: Sending
> OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
> 2018-04-11 17:47:03  bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686)
> 2018-04-11 17:47:03  bgp1: Sending KEEPALIVE
> 2018-04-11 17:47:03  bgp1: Got KEEPALIVE
> 2018-04-11 17:47:03  bgp1: BGP session established
> 2018-04-11 17:47:03  bgp1: Connected to table master
> 2018-04-11 17:47:03  bgp1: State changed to feed
> 2018-04-11 17:47:03  bgp1: State changed to up
> 2018-04-11 17:47:03  bgp1: Sending End-of-RIB
> 2018-04-11 17:47:03  bgp1: Got UPDATE
> 2018-04-11 17:47:03  bgp1: Got UPDATE
> 2018-04-11 17:47:03  bgp1: Got UPDATE
> 2018-04-11 17:47:03  bgp1: Got UPDATE
> 2018-04-11 17:47:03  bgp1: Got UPDATE
> 2018-04-11 17:47:03  ...
> 
>
>
>

Re: RPKI / roa_check() question - BIRD 2.0.2

2018-04-11 Thread Radu Anghel 
Thank you, it works with last_nonaggregated, I don't know how I didn't
notice that in the doc.

Radu

On 11.04.2018 20:06, Matthias Waehlisch wrote:
> Hi Radu,
> 
>   the path includes an AS-set ({30884 65004 65005}).
> 
> "Both first and last return zero if there is no appropriate ASN, for 
> example if the path contains an AS set element as the first (or the 
> last) part. If the path ends with an AS set, last_nonaggregated may be 
> used to get last ASN before any AS set. "
> 
>   AS-sets are deprecated: https://tools.ietf.org/html/rfc6472
> 
>   Strictly speaking, you you don't know which AS in AS-set is the actual 
> origin.
> 
> 
> 
> Cheers
>   matthias
> 
> 
> On Wed, 11 Apr 2018, Radu Anghel wrote:
> 
>> Hello,
>>
>> I have found this while doing RPKI validation:
>>
>> net = 94.127.104.0/21
>> bgp_path = 48112 6830 174 13110 {30884 65004 65005}
>> BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var)
>>
>> roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD
>> thinks bgp_path.last = 0
>>
>> There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the
>> validation should be done on the aggregator AS.
>>
>> Could you tell me what is the corect way to handle this?
>>
>> TIA,
>> Radu
>>
> 
>

Re: BGP import route

2018-04-11 Thread Jan Maria Matějka 
Hello! 

First of all, we don't support this old version. Please upgrade, either to 
1.6.4 or to 2.0.2.

Second, the other side seems to send multiprotocol NLRI to you. BIRD in 1.x 
versions AFAIK does not support this extension and should not announce it. What 
is the remote software?

Writing from my phone with no access to source code, trying to recall it from 
my memory. I might be wrong. 

Maria 

Quidquid latine dictum sit, altum videtur. 

-Original Message-
From: RICCARDO RUSSO 
To: bird-users@network.cz
Sent: Wed, 11 Apr 2018 6:10 PM
Subject: BGP import route

Hello,
I'm not able to import route from BGP (CentOS 7). In log file I read "Got
UPDATE" but  "import updates" is always 0. With TCPDUMP I see that BGP
receive the routes

Rr


# more bird.conf
log syslog all;
log stderr all;
log "/var/log/bird.logg" all;
debug protocols all;

protocol kernel {
persist;# Don't remove routes on bird shutdown
scan time 20;   # Scan kernel routing table every 20 seconds
}

protocol device {
scan time 10;   # Scan interfaces every 10 seconds
}

router id 192.168.200.6;

protocol bgp bgp1 {
   local as 64521;
   neighbor 192.168.200.1 as 64520;
   import filter all;
}





# tail -f /var/log/bird.logg
2018-04-11 17:46:53  kernel1 < interface lo goes up
2018-04-11 17:46:53  kernel1 < interface eth0 goes up
2018-04-11 17:46:53  kernel1 < interface eth1 goes up
2018-04-11 17:46:53  kernel1: State changed to up
2018-04-11 17:46:53  bgp1: Started
2018-04-11 17:46:53  bgp1: Connect delayed by 5 seconds
2018-04-11 17:46:53  kernel1: Scanning routing table
2018-04-11 17:46:53  kernel1: 0.0.0.0/0: [alien] ignored
2018-04-11 17:46:53  kernel1: 192.168.44.0/24: [alien] ignored
2018-04-11 17:46:53  kernel1: Pruning table master
2018-04-11 17:46:57  bgp1: Connecting to 192.168.200.1 from local
address 192.168.200.6
2018-04-11 17:46:57  bgp1: Connected
2018-04-11 17:46:57  bgp1: Sending
OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
2018-04-11 17:46:57  bgp1: Connection closed
2018-04-11 17:46:57  bgp1: Connect delayed by 5 seconds
2018-04-11 17:47:03  device1: Scanning interfaces
2018-04-11 17:47:03  bgp1: Connecting to 192.168.200.1 from local
address 192.168.200.6
2018-04-11 17:47:03  bgp1: Connected
2018-04-11 17:47:03  bgp1: Sending
OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
2018-04-11 17:47:03  bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686)
2018-04-11 17:47:03  bgp1: Sending KEEPALIVE
2018-04-11 17:47:03  bgp1: Got KEEPALIVE
2018-04-11 17:47:03  bgp1: BGP session established
2018-04-11 17:47:03  bgp1: Connected to table master
2018-04-11 17:47:03  bgp1: State changed to feed
2018-04-11 17:47:03  bgp1: State changed to up
2018-04-11 17:47:03  bgp1: Sending End-of-RIB
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  ...





# birdc show protocols all bgp1
BIRD 1.4.5 ready.
name prototablestate  since   info
bgp1 BGP  master   up 17:47:03Established
  Preference: 100
  Input filter:   ACCEPT
  Output filter:  REJECT
  Routes: 0 imported, 0 exported, 0 preferred
  Route change stats: received   rejected   filteredignored
 accepted
Import updates:  0  0  0  0
  0
Import withdraws:0  0---  0
  0
Export updates:  0  0  0---
  0
Export withdraws:0---------
  0
  BGP state:  Established
Neighbor address: 192.168.200.1
Neighbor AS:  64520
Neighbor ID:  163.162.230.134
Neighbor caps:restart-aware
Session:  external
Source address:   192.168.200.6
Hold timer:   62/90
Keepalive timer:  22/30




# tcpdump -i eth1 tcp port 179 -vvv -XX
17:37:51.260061 IP (tos 0x0, ttl 1, id 49246, offset 0, flags [DF], proto
TCP (6), length 1353)
192.168.200.1.bgp > vm-1.59873: Flags [P.], cksum 0xad25 (correct), seq
61:1362, ack 69, win 210, options [nop,nop,TS val 1643220008 ecr 25496328],
length 1301: BGP
Update Message (2), length: 66
  Origin (1), length: 1, Flags [T]: Incomplete
0x:  02
  Next Hop (3), length: 4, Flags [T]: 192.168.200.1
0x:  c0a8 c801
  Multi Exit Discriminator (4), length: 4, Flags [O]: 100
0x:   0064

Re: RPKI / roa_check() question - BIRD 2.0.2

2018-04-11 Thread Jan Maria Matějka 
The bgp_path.last_nonaggregated attribute should help you. Don't have user 
manual right now here, writing from my phone, just trying to recall it from my 
memory. 

Maria 

Quidquid latine dictum sit, altum videtur. 

-Original Message-
From: Radu Anghel 
To: bird-users@network.cz
Sent: Wed, 11 Apr 2018 6:34 PM
Subject: RPKI / roa_check() question - BIRD 2.0.2

Hello,

I have found this while doing RPKI validation:

net = 94.127.104.0/21
bgp_path = 48112 6830 174 13110 {30884 65004 65005}
BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var)

roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD
thinks bgp_path.last = 0

There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the
validation should be done on the aggregator AS.

Could you tell me what is the corect way to handle this?

TIA,
Radu

RPKI / roa_check() question - BIRD 2.0.2

2018-04-11 Thread Radu Anghel 
Hello,

I have found this while doing RPKI validation:

net = 94.127.104.0/21
bgp_path = 48112 6830 174 13110 {30884 65004 65005}
BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var)

roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD
thinks bgp_path.last = 0

There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the
validation should be done on the aggregator AS.

Could you tell me what is the corect way to handle this?

TIA,
Radu

BGP import route

2018-04-11 Thread RICCARDO RUSSO 
Hello,
I'm not able to import route from BGP (CentOS 7). In log file I read "Got
UPDATE" but  "import updates" is always 0. With TCPDUMP I see that BGP
receive the routes

Rr


# more bird.conf
log syslog all;
log stderr all;
log "/var/log/bird.logg" all;
debug protocols all;

protocol kernel {
persist;# Don't remove routes on bird shutdown
scan time 20;   # Scan kernel routing table every 20 seconds
}

protocol device {
scan time 10;   # Scan interfaces every 10 seconds
}

router id 192.168.200.6;

protocol bgp bgp1 {
   local as 64521;
   neighbor 192.168.200.1 as 64520;
   import filter all;
}





# tail -f /var/log/bird.logg
2018-04-11 17:46:53  kernel1 < interface lo goes up
2018-04-11 17:46:53  kernel1 < interface eth0 goes up
2018-04-11 17:46:53  kernel1 < interface eth1 goes up
2018-04-11 17:46:53  kernel1: State changed to up
2018-04-11 17:46:53  bgp1: Started
2018-04-11 17:46:53  bgp1: Connect delayed by 5 seconds
2018-04-11 17:46:53  kernel1: Scanning routing table
2018-04-11 17:46:53  kernel1: 0.0.0.0/0: [alien] ignored
2018-04-11 17:46:53  kernel1: 192.168.44.0/24: [alien] ignored
2018-04-11 17:46:53  kernel1: Pruning table master
2018-04-11 17:46:57  bgp1: Connecting to 192.168.200.1 from local
address 192.168.200.6
2018-04-11 17:46:57  bgp1: Connected
2018-04-11 17:46:57  bgp1: Sending
OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
2018-04-11 17:46:57  bgp1: Connection closed
2018-04-11 17:46:57  bgp1: Connect delayed by 5 seconds
2018-04-11 17:47:03  device1: Scanning interfaces
2018-04-11 17:47:03  bgp1: Connecting to 192.168.200.1 from local
address 192.168.200.6
2018-04-11 17:47:03  bgp1: Connected
2018-04-11 17:47:03  bgp1: Sending
OPEN(ver=4,as=64521,hold=240,id=c0a8c806)
2018-04-11 17:47:03  bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686)
2018-04-11 17:47:03  bgp1: Sending KEEPALIVE
2018-04-11 17:47:03  bgp1: Got KEEPALIVE
2018-04-11 17:47:03  bgp1: BGP session established
2018-04-11 17:47:03  bgp1: Connected to table master
2018-04-11 17:47:03  bgp1: State changed to feed
2018-04-11 17:47:03  bgp1: State changed to up
2018-04-11 17:47:03  bgp1: Sending End-of-RIB
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  bgp1: Got UPDATE
2018-04-11 17:47:03  ...





# birdc show protocols all bgp1
BIRD 1.4.5 ready.
name prototablestate  since   info
bgp1 BGP  master   up 17:47:03Established
  Preference: 100
  Input filter:   ACCEPT
  Output filter:  REJECT
  Routes: 0 imported, 0 exported, 0 preferred
  Route change stats: received   rejected   filteredignored
 accepted
Import updates:  0  0  0  0
  0
Import withdraws:0  0---  0
  0
Export updates:  0  0  0---
  0
Export withdraws:0---------
  0
  BGP state:  Established
Neighbor address: 192.168.200.1
Neighbor AS:  64520
Neighbor ID:  163.162.230.134
Neighbor caps:restart-aware
Session:  external
Source address:   192.168.200.6
Hold timer:   62/90
Keepalive timer:  22/30




# tcpdump -i eth1 tcp port 179 -vvv -XX
17:37:51.260061 IP (tos 0x0, ttl 1, id 49246, offset 0, flags [DF], proto
TCP (6), length 1353)
192.168.200.1.bgp > vm-1.59873: Flags [P.], cksum 0xad25 (correct), seq
61:1362, ack 69, win 210, options [nop,nop,TS val 1643220008 ecr 25496328],
length 1301: BGP
Update Message (2), length: 66
  Origin (1), length: 1, Flags [T]: Incomplete
0x:  02
  Next Hop (3), length: 4, Flags [T]: 192.168.200.1
0x:  c0a8 c801
  Multi Exit Discriminator (4), length: 4, Flags [O]: 100
0x:   0064
  AS Path (2), length: 4, Flags [T]: 64520
0x:  0201 fc08
  Multi-Protocol Reach NLRI (14), length: 14, Flags [OE]:
AFI: IPv4 (1), SAFI: Unicast (1)
nexthop: 192.168.200.1, nh-length: 4, no SNPA
  163.162.230.199/32
0x:  0001 0104 c0a8 c801 0020 a3a2 e6c7

Re: BGP attribute ext-next-hop

2018-04-11 Thread Ondrej Zajicek 
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

2018-04-11 Thread Ondrej Zajicek 
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

2018-04-11 Thread Arvin Gan 
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  
Sent: Wednesday, April 11, 2018 5:26 PM 
To: Arvin Gan 
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

2018-04-11 Thread Ondrej Zajicek 
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."