RE: 'prefer older' does not work?

[Arvin Gan]

Hi  Alexander,
   Suggest you confirm with the BGP route selection algorithm bgp_rte_better,  
the option "prefer older"  will  work  only when all pervious selection options 
are the same. 

Best Regards,
Arvin Gan

-Original Message-
From: Bird-users  On Behalf Of Alexander Shikov
Sent: Monday, May 13, 2019 5:49 PM
To: bird-users@network.cz
Subject: 'prefer older' does not work?

Hello!

All of our BGP peers have 'prefer older' option enabled. 
But I noticed that best route is not the oldest one:

bird> show route for 91.226.190.1 all
91.226.190.0/24via 193.25.181.44 on bge0 [ITSTARCOM 2019-05-10 11:05:56] * 
(100) [AS50981i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 48422 50981
BGP.next_hop: 193.25.181.44
BGP.local_pref: 100
BGP.community: (65005,10804) (31210,31210)
BGP.ext_community: (rt, 31210, 31210)
   via 193.25.180.141 on bge0 [SATELLITE 2019-05-09 15:16:08] 
(100) [AS50981i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 44416 50981
BGP.next_hop: 193.25.180.141
BGP.local_pref: 100
BGP.community: (44416,2) (65005,10804) (31210,31210)
BGP.ext_community: (rt, 31210, 31210)

What am I missing?
Thanks!

-- 
Alexander Shikov
Technical Staff, Digital Telecom IX
Tel.: +380 44 201 14 07
Mob.: +380 50 410 30 57
http://dtel-ix.net/

BGP end mark

[Arvin Gan]

Hi Ondrej,
   In bgp_create_end_mark(), suggest to add condition ext_next_hop to select 
ip_end_mark or mp_end_mark that is aligned with bgp_create_update function,  
although this don't affect protocols communication :)


@@ -2225,7 +2297,7 @@ bgp_create_end_mark(struct bgp_channel *
   BGP_TRACE(D_PACKETS, "Sending END-OF-RIB");
-  return (c->afi == BGP_AF_IPV4) ?
+  return (c->afi == BGP_AF_IPV4) && !c->ext_next_hop ?
 bgp_create_ip_end_mark(c, buf):
 bgp_create_mp_end_mark(c, buf);
}

Best Regards,
Arvin Gan

RE: BGP import_table & graceful restart issue

[Arvin Gan]

Hi Ondrej,
Thanks for your answer :).
I checked the RFC 4271 and RFC 4274, maybe what you said it's correct 
behavior based on RFC4271, " The phrase "the BGP connection is closed" means 
the TCP connection has been closed, the associated Adj-RIB-In has been cleared, 
and all resources for that BGP connection have been deallocated. Entries in the 
Loc-RIB associated with the remote peer are marked as invalid.The local system 
recalculates its best routes for the destinations of the routes marked as 
invalid. Before the invalid routes are deleted from the system, it advertises, 
to its peers, either withdraws for the routes marked as invalid, or the new 
best routes before the invalid routes are deleted from the system." 
And RFC4274 said, "when the Receiving Speaker detects termination of the 
TCP session for a BGP session with a peer that has advertised the Graceful 
Restart Capability, it MUST retain the routes received from the peer for all 
the address families that were previously received in the Graceful Restart 
Capability and MUST mark them as stale routing information."
  
RFC4274 said  that retain the routes received from the peer .., my 
understand is peer should retain routes in Adj-RIB-IN table and mark them as 
stale. Normally, the BGP route in local-RIB or adj-RIB-out should come from 
Adj-RIB-IN table.  The behavior of BIRD for GR, BGP route is  NOT  in 
adj-RIB-in, but in local-RIB or adj-RIB-out, I think it's not a complete 
behavior. What's your opinion ?

Best Regards,
Arvin Gan


-Original Message-
From: Ondrej Zajicek  
Sent: Saturday, March 23, 2019 3:55 AM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP import_table & graceful restart issue

On Thu, Mar 21, 2019 at 05:54:00AM +, Arvin Gan wrote:
> Hi All,

>  I am using BIRD 2.0.4, the configuration of bgp.ipv4  for import 
> table and graceful restart are yes . when BGP remote peer is 
> restarting, the graceful restart is detected by the local peer, using 
> "show route protocols bgp1" on local peer, the route related with the 
> restarting peer are exist, I think it's correct. But when I using 
> "show route import table bgp1.ipv4" to show route for local peer Adj-RIB-In , 
> the route is
> empty,  correct ?   After the remote peer is restarted done, the local
> import table can be recovered.
>
> As RFC4274 description:
> "when the Receiving Speaker detects termination of the TCP session for
>a BGP session with a peer that has advertised the Graceful Restart
>Capability, it MUST retain the routes received from the peer for all
>the address families that were previously received in the Graceful
>Restart Capability and MUST mark them as stale routing information."

Hi

After graceful restart, BIRD retains the routes, but only in the master table, 
not in the import table. That is intended and IMHO correct behavior.

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

BGP import_table & graceful restart issue

[Arvin Gan]

Hi All,
 I am using BIRD 2.0.4, the configuration of bgp.ipv4  for import table and 
graceful restart are yes . when BGP remote peer is restarting, the graceful 
restart is detected by the local peer, using "show route protocols bgp1" on 
local peer, the route related with the restarting peer are exist, I think it's 
correct. But when I using "show route import table bgp1.ipv4" to show route for 
local peer Adj-RIB-In , the route is empty,  correct ?   After the remote peer 
is restarted done, the local import table can be recovered.

As RFC4274 description:
"when the Receiving Speaker detects termination of the TCP session for
   a BGP session with a peer that has advertised the Graceful Restart
   Capability, it MUST retain the routes received from the peer for all
   the address families that were previously received in the Graceful
   Restart Capability and MUST mark them as stale routing information."

Best Regards,
Arvin Gan

Help: BGP neighbor

[Arvin Gan]

Hello All,
   I  notice that if BGP is directly connected, when BGP started, the 
bgp_start_locked() is called and using neigh_find2() to lookup the neighbor. In 
neigh_find2(), bird will loop iface_list and comparing the remote IP address 
with the IP prefix of interface, checking whether is the subnet.
Now, I have a question that why not using route table to find the neighbor ?  
Since I have one case that make me have some confusion.

Test Case:
DUT1  DUT2  

 DUT3
   lo interface 
2000::/128 , interface3 3000:1::8/112 <---> interface4 
3000:1::9/112, lo interface: 2000::/128
  interface1 2000::2/112 <-->interface2: 2000::1/112

  suppose that the route table configuration are all reachable.
  1.  Anyone known the topology connection is normal or correct ?
  2.  If yes, when create  BGP peer with loopback interface 2000::, remote 
IP 2000::.
  3.  BGP peer will  use 2000:: to compare with interface prefix list on 
DUT2, find the neighbor interface2 with prefix 2000::1/112 [interface2 on 
DUT2], and consider as directly connected.

BUT, actually, BGP peer TCP connection is not directly connected,  and TCP 
connection don't using interface2 on DUT2,  but using interface3 on DUT2 to 
connect interface4 of DUT3.

Best Regards,
Arvin Gan

BGP neighbor

[Arvin Gan]

Hi All,
   I  notice that if BGP is directly connected, when BGP started, the 
bgp_start_locked() is called and using neigh_find2() to lookup the neighbor. In 
neigh_find2(), bird will loop iface_list and comparing the remote IP address 
with the IP prefix of interface, checking whether is the subnet.
Now, I have a question that why not using route table to find the neighbor ?  
Since I have one case that make me have some confusion.

Test Case:
DUT1  DUT2  

 DUT3
   lo interface 
2000::/128 , interface3 3000:1::8/112 <---> interface4 
3000:1::9/112, lo interface: 2000::/128
  interface1 2000::1/112 <-->interface2: 2000::1/112

   Igor the route table configuration, suppose the route is correct.
   1.  Anyone known the topology connection is normal or correct ?
  2. if yes,  create  BGP peer with loopback interface 2000::, remote IP 
2000::, directly connection.
   3. BGP peer will  use 2000:: to compare with interface prefix on DUT1, 
find the neighbor interface2 with prefix 2000::1/112 [interface2 on DUT2]

BUT, actually, BGP peer TCP connection is not directly connected,  and TCP 
connection don't using interface2 on DUT2,  but using interface3 on DUT2 to 
connect interface4 of DUT3.

Best Regards,
Arvin Gan

RE: vpn6-mpls routes on BIRD 2

[Arvin Gan]

Hi ,
  From your protocols info, “BGP Next hop:   ::”  in channel vpn6-mpls, if next 
hop is empty, the route is withdrawn. Suggest to check it.

Best Regards,
Arvin Gan

From: Bird-users  On Behalf Of Chris Herdt
Sent: Friday, August 24, 2018 5:48 AM
To: bird-users@network.cz
Subject: vpn6-mpls routes on BIRD 2

Thanks to the list for all the help you've given me so far!

Another question: I am running BIRD 2.0.2 and peering with a host that is 
announcing vpn4 mpls and vpn6 mpls routes.

The vpn4 mpls routes are working, but all of the vpn6 mpls routes appear as 
withdrawn routes. I'm not sure why -- I looked at the packet capture in 
Wireshark and the UPDATE messages containing the IPv6 routes all show zero for 
Withdrawn Routes Length. Any ideas?

Here's the result of 'show protocols all peer1' (addresses changed):

bird> show protocols all peer1
Name   Proto  Table  State  Since Info
peer1  BGP---up 14:35:04.353  Established
  BGP state:  Established
Neighbor address: 192.168.42.1
Neighbor AS:  65321
Neighbor ID:  192.168.42.1
Local capabilities
  Multiprotocol
AF announced: vpn4-mpls vpn6-mpls
  Route refresh
  Graceful restart
  4-octet AS numbers
  Enhanced refresh
Neighbor capabilities
  Multiprotocol
AF announced: vpn4-mpls vpn6-mpls
  Route refresh
  Extended next hop
IPv6 nexthop: ipv4 ipv4-mc
  Graceful restart
Restart time: 120
AF supported: vpn4-mpls vpn6-mpls
AF preserved:
  4-octet AS numbers
Session:  internal multihop AS4
Source address:   192.168.100.1
Hold timer:   12.954/15
Keepalive timer:  0.005/5
  Channel vpn4-mpls
State:  UP
Table:  vpntab4
Preference: 100
Input filter:   ACCEPT
Output filter:  REJECT
Routes: 9771 imported, 0 exported
Route change stats: received   rejected   filteredignored   accepted
  Import updates:   9771  0  0  0   9771
  Import withdraws:   20  0--- 20  0
  Export updates:   9771   9771  0---  0
  Export withdraws:0---------  0
BGP Next hop:   192.168.100.1
IGP IPv4 table: master4
  Channel vpn6-mpls
State:  UP
Table:  vpntab6
Preference: 100
Input filter:   ACCEPT
Output filter:  REJECT
Routes: 0 imported, 0 exported
Route change stats: received   rejected   filteredignored   accepted
  Import updates:  0  0  0  0  0
  Import withdraws: 2785  0---   2785  0
  Export updates:  0  0  0---  0
  Export withdraws:0---------  0
BGP Next hop:   ::
IGP IPv6 table: master6


--
Chris Herdt
https://osric.com/chris/

RE: BGP resolvable issue

[Arvin Gan]

Hi Ondrej,
   Thanks for your info :)
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Tuesday, August 21, 2018 9:00 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP resolvable issue

On Tue, Aug 21, 2018 at 01:43:58AM +, Arvin Gan wrote:
> Ping, anyone known it ?:)
> 
> Thanks
> Arvin
> 
> From: Arvin Gan
> Sent: Monday, August 13, 2018 5:42 PM
> To: bird-users@network.cz
> Subject: BGP resolvable issue
> 
> Hi all,

>In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an 
> address that is not resolvable, or if it would become unresolvable if 
> the route was installed in the routing table, the BGP route MUST be 
> excluded from  the Phase 2 decision function. Actually, BGP protocol 
> is implemented this option. I notice that  resolvable is checked with 
> "rt->attrs->dest == RTD_UNICAST" , that mean the check is depend on 
> the reachability of route for NEXT_HOP.  However, NEXT_HOP is a host 
> address, not  a subnet address, the resolvable checking in VRF is 
> depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be 
> resolved for MAC, it should be  unresolved.

Hi

IMHO resolvability condition is completely unrelated to ARP/NDP. See RFC
4271 9.1.2.2, host route is resolved in the same way as regular route.
NEXT_HOP is one IP address, but resolvability check does longest-matching 
prefix match to find matching prefix.

--
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 resolvable issue

[Arvin Gan]

Ping, anyone known it ?:)

Thanks
Arvin

From: Arvin Gan
Sent: Monday, August 13, 2018 5:42 PM
To: bird-users@network.cz
Subject: BGP resolvable issue

Hi all,
   In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an address that 
is not resolvable, or if it would become unresolvable if the route was 
installed in the routing table, the BGP route MUST be excluded from  the Phase 
2 decision function. Actually, BGP protocol is implemented this option. I 
notice that  resolvable is checked with "rt->attrs->dest == RTD_UNICAST" , that 
mean the check is depend on the reachability of route for NEXT_HOP.  However, 
NEXT_HOP is a host address, not  a subnet address, the resolvable checking in 
VRF is depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be resolved 
for MAC, it should be  unresolved.
   The description of RFC4271 for "resolvable", I am confused whether it 
includes only route reachable, not includes host address reachable, does anyone 
clearly understand it?

My test case:

   BGP4--BGP4 peer
  set next hop:1560::28



BGP4 peer route table :

1560::/64unicast [direct2 09:03:52.007] * (250)
dev A6IF1 the 
address of interface is 1560::15/64 ,generate direct route
 unicast [bgp4 09:24:36.872 from 1560::26] (200) [?]
via 1560::28 on A6IF1  
---the route is resolved in 
BGP4 peer based in brid, but the address the interface of BGP4 peer is 
1560::15, not 1560::28, NDP is not successful.

Thanks
Arvin

BGP resolvable issue

[Arvin Gan]

Hi all,
   In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an address that 
is not resolvable, or if it would become unresolvable if the route was 
installed in the routing table, the BGP route MUST be excluded from  the Phase 
2 decision function. Actually, BGP protocol is implemented this option. I 
notice that  resolvable is checked with "rt->attrs->dest == RTD_UNICAST" , that 
mean the check is depend on the reachability of route for NEXT_HOP.  However, 
NEXT_HOP is a host address, not  a subnet address, the resolvable checking in 
VRF is depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be resolved 
for MAC, it should be  unresolved.
   The description of RFC4271 for "resolvable", I am confused whether it 
includes only route reachable, not includes host address reachable, does anyone 
clearly understand it?

My test case:

   BGP4--BGP4 peer
  set next hop:1560::28



BGP1 peer route table :

1560::/64unicast [direct2 09:03:52.007] * (250)
dev A6IF1 the 
address of interface is 1560::15/64 generate direct route
 unicast [bgp4 09:24:36.872 from 1560::26] (200) [?]
via 1560::28 on A6IF1  
---the route is resolved in 
BGP4 peer based in brid, but the address the interface of BGP4 peer is 
1560::15, not 1560::28, NDP is not successful.

Thanks
Arvin

RE: bird 2 and vpn4 mpls

[Arvin Gan]

Hi Chris,
   From your config-file,  table option is not assigned for protocol bgp peer1, 
but system will select the first table of given nettype.  ‘---’ in the table 
column, that mean you don’t define table name, used the default one.

table name
Specify a table to which the channel is connected. Default: the first table of 
given nettype.

Thanks
Arvin

From: Bird-users  On Behalf Of Chris Herdt
Sent: Tuesday, August 07, 2018 12:34 AM
To: bird-users@network.cz
Subject: bird 2 and vpn4 mpls

Following the example at 
https://github.com/BIRD/bird/blob/v2.0.2/doc/bird.conf.example2, I set up a 
simple bird config (see below).

It is working, but I am not certain what the '---' in the table column of the 
output of `show protocols` means. I expected the column to display vpntab4.

$ sudo /usr/local/sbin/birdc show protocols
BIRD v2.0.2 ready.
Name   Proto  Table  State  Since Info
peer1  BGP---up 17:14:48.474  Established


The output of `show route count` shows that there are routes in table vpntab4:

$ sudo /usr/local/sbin/birdc show route count
BIRD v2.0.2 ready.
0 of 0 routes for 0 networks in table master4
0 of 0 routes for 0 networks in table master6
9581 of 9581 routes for 9581 networks in table vpntab4
Total: 9581 of 9581 routes for 9581 networks in 3 tables


The contents of my bird.conf:

log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log stderr all;

router id 127.0.0.1;

vpn4 table vpntab4;

protocol bgp peer1 {
local as 65321;
neighbor 192.168.1.1 as 65321;
hold time 180;
vpn4 mpls {
import all;
};
}


Thanks,

--
Chris Herdt
https://osric.com/chris/

lists issue

[Arvin Gan]

Hi all,
   There may be an issue  in blow function when deleted the node is the first 
one, that mean n->prev is NULL., similarly, same issue as the last one node 
is deleted.

LIST_INLINE void
rem_node(node *n)
{
  node *z = n->prev;
  node *x = n->next;

   z->next = x;
   x->prev = z;
   n->next = NULL;
   n->prev = NULL;
}

Thanks
Arvin

RE: BGP hostentry update

[Arvin Gan]

Any method to bypass this limitation ? thanks

-Original Message-
From: Arvin Gan 
Sent: Thursday, June 28, 2018 11:11 AM
To: 'Ondrej Zajicek' 
Cc: bird-users@network.cz
Subject: RE: BGP hostentry update

Hi Ondrej,
  Thanks. It seems the limitation for iBGP is more impact, since more than one 
levels of indirection NEXT_HOP for iBGP is regular application.
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, June 27, 2018 7:22 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP hostentry update

On Wed, Jun 27, 2018 at 11:15:02AM +0000, Arvin Gan wrote:
> Hi Ondrej,
>   Is any consideration/plan  to  optimize this limitation ? 

No hard plan for this.

--
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 hostentry update

[Arvin Gan]

Hi Ondrej,
  Thanks. It seems the limitation for iBGP is more impact, since more than one 
levels of indirection NEXT_HOP for iBGP is regular application.
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, June 27, 2018 7:22 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP hostentry update

On Wed, Jun 27, 2018 at 11:15:02AM +, Arvin Gan wrote:
> Hi Ondrej,
>   Is any consideration/plan  to  optimize this limitation ? 

No hard plan for this.

--
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 hostentry update

[Arvin Gan]

Hi Ondrej,
  Is any consideration/plan  to  optimize this limitation ? 
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, June 27, 2018 7:07 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP hostentry update

On Wed, Jun 27, 2018 at 07:25:49AM +, Arvin Gan wrote:
> Hi All,
>  When I using bird 2.0.2 version ,I have an issue route include 
> "unreachable", but I think this application is reasonable , anyone can help 
> me ?

>  /* Recursive route should not depend on another recursive route */ 
> ---do you know the reason ??

Hi

This is implementation limitation. We support only one level of indirection, as 
it significantly simplify the recursive route handling and covers realistic use 
cases.

--
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 channel add/remove

[Arvin Gan]

Hi Ondrej,
   It's great, thanks. 
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, June 27, 2018 6:53 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP channel add/remove

On Tue, Jun 26, 2018 at 10:43:59AM +0000, Arvin Gan wrote:
> Hi Ondrej,
>Thanks for your response. 
>As my code investigated, the function proto_configure_channel()  always 
> return value "1" , that mean the same is true in function bgp_reconfigure(),  
> line 917 of  proto.c will  ignore  the change(add/delete channel)... But if 
> we modify others bgp configuration, i.e, ext_next_hop, the function  
> bgp_reconfigure will return 0, (),  line 917 of  proto.c will continue to 
> process as PDC_CF_RESTART, is my understand correct ? 

Yes. But the main problem is that generally the infrastructure for 
adding/removing channels during reconfigure is insufficient to handle that 
properly. Protocol-specific code can decide whether to force-restart channel in 
e.g. bgp_channel_reconfigure() for channel reconfiguration, but not for channel 
add/remove.

> As your mentioned, any plan to optimize  add/remove channel process for  
> command "configure" ?

Yes, we should design and implement proper hooks to handle this. Although it 
could be probably hacked in general bgp_reconfigure() hook currently.

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

BGP hostentry update

[Arvin Gan]

Hi All,
 When I using bird 2.0.2 version ,I have an issue route include 
"unreachable", but I think this application is reasonable , anyone can help me ?
Error is reported in codes:
rt_update_hostentry()
{
  
  if (a->hostentry)
{
  /* Recursive route should not depend on another recursive 
route */ ---do you know the reason ??
  log(L_WARN "Next hop address %I resolvable through recursive 
route for %N",
  he->addr, n->n.addr);
  goto done;
}
   ..
}

bird> show route all
Table master4:
192.170.13.0/24  unreachable [bgp1 04:31:13.630 from 192.170.23.15] * 
(55/-) [AS2000i]
Type: IBGP univ
BGP.origin: IGP
BGP.as_path: 2000
BGP.next_hop: 192.170.40.13
BGP.local_pref: 100
192.170.15.0/24  unicast [bgp1 04:31:13.630] * (55/0) [?]
via 192.170.23.15 on A3IF1
Type: IBGP univ
BGP.origin: Incomplete
BGP.as_path:
BGP.next_hop: 192.170.23.15
BGP.local_pref: 100
192.170.23.0/24  unicast [direct1 04:31:07.741] * (255)
dev A3IF1
Type: device univ
 unicast [bgp1 04:31:13.630] (55/0) [?]
via 192.170.23.15 on A3IF1
Type: IBGP univ
BGP.origin: Incomplete
BGP.as_path:
BGP.next_hop: 192.170.23.15
BGP.local_pref: 100
192.170.27.0/24  unreachable [bgp1 04:31:13.630 from 192.170.23.15] * 
(55/-) [?]
Type: IBGP univ
BGP.origin: Incomplete
BGP.as_path:
BGP.next_hop: 192.170.15.27
BGP.local_pref: 100
 unicast [kernel2 04:31:06.395] (10)
via 192.170.23.15 on A3IF1 onlink
Type: inherit univ
Kernel.source: 4
Kernel.metric: 5
192.169.23.0/24  unicast [direct1 04:31:08.093] * (255)
dev N1IF1
Type: device univ
192.170.40.0/24  unicast [bgp1 04:31:13.630] * (55/0) [?]
via 192.170.23.15 on A3IF1
Type: IBGP univ
BGP.origin: Incomplete
BGP.as_path:
BGP.next_hop: 192.170.23.15
BGP.local_pref: 100
 unicast [kernel2 04:31:06.395] (10)
via 192.170.23.15 on A3IF1 onlink
Type: inherit univ
Kernel.source: 4
Kernel.metric: 5

Thanks
Arvin

RE: BGP channel add/remove

[Arvin Gan]

Hi Ondrej,
   Thanks for your response. 
   As my code investigated, the function proto_configure_channel()  always 
return value "1" , that mean the same is true in function bgp_reconfigure(),  
line 917 of  proto.c will  ignore  the change(add/delete channel)... But if we 
modify others bgp configuration, i.e, ext_next_hop, the function  
bgp_reconfigure will return 0, (),  line 917 of  proto.c will continue to 
process as PDC_CF_RESTART, is my understand correct ? 
As your mentioned, any plan to optimize  add/remove channel process for  
command "configure" ?
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Tuesday, June 26, 2018 6:22 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP channel add/remove

On Fri, Jun 22, 2018 at 09:23:02AM +, Arvin Gan wrote:
> Hi All,
> I am using Bird 2.0.2 version, I create a BGP instance with one channel IPV4, 
> that all work normally.  Then I modified configuration file and add new 
> channel IPV6, and using command "configure" under birdc , found the  new 
> added channel IPV6 is not announced to peer and channel ipv6 is down state.  
> Then I used "restart bgp",  all channels IPV4 and IPV6 are announced, work 
> normally.   I also do another test that delete channel  in configure file and 
> used   "configure", it work normally.
>  Anyone know the difference of actions  between  "configure" and "restart "?  
>  The command "configure" can dynamically modify the BGP protocol 
> configuration, cant the action "configure"  re-announce the added/removed 
> capability  to peer to update ?

Hi

The capabilities (including supported AFIs/SAFIs) can be announced just during 
the session establishment, not later. So it is not possible to really 
add/remove BGP channels without restarting the session.

Currently the 'configure' adds/removes the channels while do not trigger 
restart, so consecutive 'restart' would cause re-establishment.
Obviously, just using 'restart' without 'configure' would not read the config 
file and would keep the old setting.

Perhaps we should trigger restart when BGP channels are added/removed and keep 
current behavior for 'configure soft'.

--
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 channel add/remove

[Arvin Gan]

Hi All,
 After investigate the codes  for  command "configure", found that when 
delete/add channel, the function proto_configure_channel()  always return value 
"1" , that mean the same is true in function bgp_reconfigure(),  line 917 of  
proto.c will  ignore  the change(add/delete channel) Is my understand 
correct ?

Thanks
Arvin

From: Arvin Gan
Sent: Friday, June 22, 2018 5:23 PM
To: bird-users@network.cz
Subject: BGP channel add/remove

Hi All,
I am using Bird 2.0.2 version, I create a BGP instance with one channel IPV4, 
that all work normally.  Then I modified configuration file and add new channel 
IPV6, and using command "configure" under birdc , found the  new added channel 
IPV6 is not announced to peer and channel ipv6 is down state.  Then I used 
"restart bgp",  all channels IPV4 and IPV6 are announced, work normally.   I 
also do another test that delete channel  in configure file and used   
"configure", it work normally.
 Anyone know the difference of actions  between  "configure" and "restart "?   
The command "configure" can dynamically modify the BGP protocol configuration, 
cant the action "configure"  re-announce the added/removed capability  to peer 
to update ?
Appreciated your help in advance..
Thanks
Arvin

BGP channel add/remove

[Arvin Gan]

Hi All,
I am using Bird 2.0.2 version, I create a BGP instance with one channel IPV4, 
that all work normally.  Then I modified configuration file and add new channel 
IPV6, and using command "configure" under birdc , found the  new added channel 
IPV6 is not announced to peer and channel ipv6 is down state.  Then I used 
"restart bgp",  all channels IPV4 and IPV6 are announced, work normally.   I 
also do another test that delete channel  in configure file and used   
"configure", it work normally.
 Anyone know the difference of actions  between  "configure" and "restart "?   
The command "configure" can dynamically modify the BGP protocol configuration, 
cant the action "configure"  re-announce the added/removed capability  to peer 
to update ?
Appreciated your help in advance..
Thanks
Arvin

RE: BGP: AS private number check

[Arvin Gan]

Hi ,
   Suggest to refer to the example of 6.3 BGP  from URL 
http://bird.network.cz/?get_doc&v=20&f=bird-6.html .

Thanks
Arvin

From: zilhazur.rah...@novocom-bd.com 
Sent: Friday, June 15, 2018 4:53 PM
To: Arvin Gan 
Cc: bird-users 
Subject: Re: BGP: AS private number check


Hi Arvin

Its really good to get a prompt response. Thank you for the help. Any example 
you can provide?

Regards
Zilhaz

From: "Arvin Gan" mailto:a...@advaoptical.com>>
To: "zilhazur rahman" 
mailto:zilhazur.rah...@novocom-bd.com>>
Cc: "bird-users" mailto:bird-users@network.cz>>
Sent: Friday, June 15, 2018 12:36:41 PM
Subject: RE: BGP: AS private number check

Hi ,
Bird support  the configuration of  efault bgp_local_pref. In export filter, 
this attribute can also be reconfigure.

default bgp_local_pref number
A default value for the Local Preference attribute. It is used when a new Local 
Preference attribute is attached to a route by the BGP protocol itself (for 
example, if a route is received through eBGP and therefore does not have such 
attribute). Default: 100 (0 in pre-1.2.0 versions of BIRD).
Thanks
Arvin

From: Bird-users 
mailto:bird-users-boun...@network.cz>> On Behalf 
Of zilhazur.rah...@novocom-bd.com<mailto:zilhazur.rah...@novocom-bd.com>
Sent: Friday, June 15, 2018 2:24 PM
To: bird-users@network.cz<mailto:bird-users@network.cz>
Subject: Re: BGP: AS private number check

Hi everyone

Could you assist me how can I use local preference in BGP in Bird for traffic 
manipulation ?

Regards
Zilhaz


From: "Arvin Gan" mailto:a...@advaoptical.com>>
To: bird-users@network.cz<mailto:bird-users@network.cz>
Sent: Friday, June 15, 2018 12:13:59 PM
Subject: BGP: AS private number check

Hi  All,
According to RFC1930, the AS number 64512 to 65535  are reserved for 
private,  I cannot find the implementation for  checking  private AS number in 
BIRD, anybody know it or it’s lost in BGP ?

RFC1930
10<https://tools.ietf.org/html/rfc1930.html#section-10>. Reserved AS Numbers





   The Internet Assigned Numbers Authority (IANA) has reserved the

   following block of AS numbers for private use (not to be advertised

   on the global Internet):



   64512 through 65535

Thanks
Arvin

RE: BGP: AS private number check

[Arvin Gan]

Hi ,
Bird support  the configuration of  efault bgp_local_pref. In export filter, 
this attribute can also be reconfigure.

default bgp_local_pref number
A default value for the Local Preference attribute. It is used when a new Local 
Preference attribute is attached to a route by the BGP protocol itself (for 
example, if a route is received through eBGP and therefore does not have such 
attribute). Default: 100 (0 in pre-1.2.0 versions of BIRD).
Thanks
Arvin

From: Bird-users  On Behalf Of 
zilhazur.rah...@novocom-bd.com
Sent: Friday, June 15, 2018 2:24 PM
To: bird-users@network.cz
Subject: Re: BGP: AS private number check

Hi everyone

Could you assist me how can I use local preference in BGP in Bird for traffic 
manipulation ?

Regards
Zilhaz


From: "Arvin Gan" mailto:a...@advaoptical.com>>
To: bird-users@network.cz<mailto:bird-users@network.cz>
Sent: Friday, June 15, 2018 12:13:59 PM
Subject: BGP: AS private number check

Hi  All,
According to RFC1930, the AS number 64512 to 65535  are reserved for 
private,  I cannot find the implementation for  checking  private AS number in 
BIRD, anybody know it or it’s lost in BGP ?

RFC1930
10<https://tools.ietf.org/html/rfc1930.html#section-10>. Reserved AS Numbers





   The Internet Assigned Numbers Authority (IANA) has reserved the

   following block of AS numbers for private use (not to be advertised

   on the global Internet):



   64512 through 65535

Thanks
Arvin

Recall: BGP: AS private number check

[Arvin Gan]

Arvin Gan would like to recall the message, "BGP: AS private number check ".

Recall: BGP: AS private number check

[Arvin Gan]

Arvin Gan would like to recall the message, "BGP: AS private number check ".

RE: BGP: AS private number check

[Arvin Gan]

Hi all,
   Sorry,  my understand is incorrect,   can ignore the mail.
Thanks
Arvin

From: Arvin Gan
Sent: Friday, June 15, 2018 2:14 PM
To: bird-users@network.cz
Subject: BGP: AS private number check

Hi  All,
According to RFC1930, the AS number 64512 to 65535  are reserved for 
private,  I cannot find the implementation for  checking  private AS number in 
BIRD, anybody know it or it's lost in BGP ?

RFC1930
10<https://tools.ietf.org/html/rfc1930.html#section-10>. Reserved AS Numbers





   The Internet Assigned Numbers Authority (IANA) has reserved the

   following block of AS numbers for private use (not to be advertised

   on the global Internet):



   64512 through 65535

Thanks
Arvin

BGP: AS private number check

[Arvin Gan]

Hi  All,
According to RFC1930, the AS number 64512 to 65535  are reserved for 
private,  I cannot find the implementation for  checking  private AS number in 
BIRD, anybody know it or it's lost in BGP ?

RFC1930
10. Reserved AS Numbers





   The Internet Assigned Numbers Authority (IANA) has reserved the

   following block of AS numbers for private use (not to be advertised

   on the global Internet):



   64512 through 65535

Thanks
Arvin

RE: BGP keepalive_time

[Arvin Gan]

Hi Ondrej,
Similarly, if create bgp session with configuration of bgp keepalive_time 
80 and hold_time 240,   configuration  of bgp peer keepalive_time 5 and 
hold_time 20, I think it also cannot negotiate successfully since negotiated 
hold_time is 20, but  keepalive_time of bgp speaker is 80...  Do you think so?
Thanks
Arvin

-Original Message-
From: Arvin Gan 
Sent: Wednesday, June 13, 2018 9:39 AM
To: 'Ondrej Zajicek' 
Cc: bird-users@network.cz
Subject: RE: BGP keepalive_time

Hi Ondrej,
Thanks for your response. My test step as below:
1. create bgp1:   keepalive_time:80, hold_time:240
2. create bgp peer bgp2,  keepalive_time:80, hold_time:240 3. bgp1 connected to 
bgp2, BGP established, all work normally 4. configure bgp2 keepalive_time to 5, 
and hold_time to 20 5. use command : "show protocols all bgp1",  session state 
is not stable, sometime normal, sometime report error hold time expired.
the negotiated  hold time on bgp1 is changed 20, but keepalive_time is 80

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek 
Sent: Tuesday, June 12, 2018 7:43 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP keepalive_time

On Tue, Jun 12, 2018 at 01:54:07AM +, Arvin Gan wrote:
> Hi all,
> 
>  When I used bird, found a question that BGP session received OPEN 
> message, hold_time is updated with min(config_hold_time, 
> peer_hold_time), but keepalive_time is not updated if keepalive_time 
> is not zero,  that maybe cause keepalive_time is more than  the 
> updated hold_time after received OPEN message.
> 
> Line 702 in packets.cc for bgp protocol :
> conn->keepalive_time = p->cf->keepalive_time ? : conn->hold_time / 
> 3;

That is true, but the answer is just to not configure keepalive time to too 
short values (or better not configure it at all).

It is not clear what to do when user configured explicit keepalive time which 
is too short w.r.t. negotiated hold time.

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

[Arvin Gan]

Hi Ondrej,
Thanks for your response. My test step as below:
1. create bgp1:   keepalive_time:80, hold_time:240
2. create bgp peer bgp2,  keepalive_time:80, hold_time:240
3. bgp1 connected to bgp2, BGP established, all work normally
4. configure bgp2 keepalive_time to 5, and hold_time to 20
5. use command : "show protocols all bgp1",  session state is not stable, 
sometime normal, sometime report error hold time expired.
the negotiated  hold time on bgp1 is changed 20, but keepalive_time is 80

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Tuesday, June 12, 2018 7:43 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP keepalive_time

On Tue, Jun 12, 2018 at 01:54:07AM +0000, Arvin Gan wrote:
> Hi all,
> 
>  When I used bird, found a question that BGP session received OPEN 
> message, hold_time is updated with min(config_hold_time, 
> peer_hold_time), but keepalive_time is not updated if keepalive_time 
> is not zero,  that maybe cause keepalive_time is more than  the 
> updated hold_time after received OPEN message.
> 
> Line 702 in packets.cc for bgp protocol :
> conn->keepalive_time = p->cf->keepalive_time ? : conn->hold_time / 
> 3;

That is true, but the answer is just to not configure keepalive time to too 
short values (or better not configure it at all).

It is not clear what to do when user configured explicit keepalive time which 
is too short w.r.t. negotiated hold time.

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

[Arvin Gan]

Hi all,

   Anyone meet the issue as below reason that cause BGP hold timer timeout 
(keepalive_time > hold_time) and switch action between  closing and opening 
session?
Thanks
Arvin

From: Arvin Gan
Sent: Friday, June 08, 2018 3:22 PM
To: 'Ondrej Zajicek' 
Cc: bird-users@network.cz
Subject: BGP keepalive_time

Hi all,
 When I used bird, found a question that BGP session received OPEN message, 
hold_time is updated with min(config_hold_time, peer_hold_time), but 
keepalive_time is not updated if keepalive_time is not zero,  that maybe cause 
keepalive_time is more than  the updated hold_time after received OPEN message.

Line 702 in packets.cc for bgp protocol :
conn->keepalive_time = p->cf->keepalive_time ? : conn->hold_time / 3;

  RFC 4271:
4.4. KEEPALIVE Message Format
BGP does not use any TCP-based, keep-alive mechanism to determine if
peers are reachable. Instead, KEEPALIVE messages are exchanged
between peers often enough not to cause the Hold Timer to expire. A
reasonable maximum time between KEEPALIVE messages would be one third
of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more
frequently than one per second. An implementation MAY adjust the
rate at which it sends KEEPALIVE messages as a function of the Hold
Time interval.

Thanks
Arvin

BGP keepalive_time

[Arvin Gan]

Hi all,
 When I used bird, found a question that BGP session received OPEN message, 
hold_time is updated with min(config_hold_time, peer_hold_time), but 
keepalive_time is not updated if keepalive_time is not zero,  that maybe cause 
keepalive_time is more than  the updated hold_time after received OPEN message.

Line 702 in packets.cc for bgp protocol :
conn->keepalive_time = p->cf->keepalive_time ? : conn->hold_time / 3;

  RFC 4271:
4.4. KEEPALIVE Message Format
BGP does not use any TCP-based, keep-alive mechanism to determine if
peers are reachable. Instead, KEEPALIVE messages are exchanged
between peers often enough not to cause the Hold Timer to expire. A
reasonable maximum time between KEEPALIVE messages would be one third
of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more
frequently than one per second. An implementation MAY adjust the
rate at which it sends KEEPALIVE messages as a function of the Hold
Time interval.
Thanks
Arvin

RE: BGP origin attribute

[Arvin Gan]

Hi Ondrej,
 Thanks for your response.
> If the route is from IGP (OSPF, RIP, Babel ..) -> src is NULL -> use 
> ORIGIN_IGP
   Yes, I agree using IGP  if route  is from OSPF, RIP, but if route is 
static or direct, using ORIGIN_IGP is not applicable. 
I also notice the explanation  from Cisco is all redistributed route are 
INCOMPLETE. What's your opinion ?

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Thursday, May 31, 2018 10:11 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP origin attribute

On Thu, May 31, 2018 at 03:14:40AM +, Arvin Gan wrote:
> Hi All,
>   I notice the origin attribute in function bgp_update_attrs , if route 
> source  is BGP, I think it should set as ORIGIN_IGP, not INCOMPLETE, 
> according to RFC or Cisco device . It seems there is mistake on Line 1443 in 
> attrs.c .

Hi

I think the current behavior is correct.

If the route is from IGP (OSPF, RIP, Babel ..) -> src is NULL -> use ORIGIN_IGP

If the route is from BGP, then it should already have bgp_origin -> do nothing

If the route is from BGP but bgp_origin attribute was removed by filters -> use 
ORIGIN_INCOMPLETE.


> Line 1443:
> bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_INCOMPLETE : 
> ORIGIN_IGP);
> 
> ð  bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_IGP : 
> ORIGIN_INCOMPLETE ); // correct?

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

BGP origin attribute

[Arvin Gan]

Hi All,
  I notice the origin attribute in function bgp_update_attrs , if route source  
is BGP, I think it should set as ORIGIN_IGP, not INCOMPLETE, according to RFC 
or Cisco device . It seems there is mistake on Line 1443 in attrs.c .

Line 1443:
bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_INCOMPLETE : 
ORIGIN_IGP);

ð  bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_IGP : 
ORIGIN_INCOMPLETE ); // correct?

Thanks
Arvin

BGP next hop

[Arvin Gan]

Hi all,
   I notice below description in user guide, my understand is source address 
mainly used for BGP session for TCP connection ,don't understand why this 
source is also used as next_hop_addr calculation. If source address is related 
with next hop calculation, this case is may not support: used MP_REACH_NLRI to 
support IPV4 route with IPV4 next hop ,but TCP connection type is IPV6. Since 
to support MP_REACH_NLRI for ipv4 channel, need to enabled ext_next_hop, if 
enabled ext_next_hop, if  ipv6 source address is selected as next_hop_addr if 
no others configuration for next_hop_addr. Does my understand is correct ?

source address ip

Define local address we should use for next hop calculation and as a source 
address for the BGP session. Default: the address of the local end of the 
interface our neighbor is connected to.

Thanks
Arvin

RE: BGP filter

[Arvin Gan]

Hi all,
Thanks for your fix. I noticed that we fixed several key bugs recently,  do 
you have plan to merge int-new to master branch and release new archive?
My previous reported bug:

https://gitlab.labs.nic.cz/labs/bird/commit/f3a8cf050e6181e158dcde2fe885d7bf220eedc3

Thanks
Arvin

-Original Message-
From: Jan Maria Matejka  
Sent: Friday, April 27, 2018 8:41 PM
To: Arvin Gan ; bird-users@network.cz
Subject: Re: BGP filter

On 04/25/2018 03:26 PM, Jan Maria Matejka wrote:
> [...]
> 
> On 04/25/2018 12:38 PM, Arvin Gan wrote:
>> Thanks, I will try.
> 
> We found out that it may coredump on reconfiguration as instruction 
> comparison happens there and the format() instruction has no 
> comparator. Please look into your log, there should be something like >>Bug: 
> Unknown instruction<<.

Fixed in 823ad12191e66e243dd088a81c66e4a518563e40.
Maria

RE: BGP route selection

[Arvin Gan]

Hi,
   Thanks. I notice this codes in rte_better() in file rt-table.c.  Since iBGP 
and eBGP have same protocol preference, that mean route preference are also 
same. In this case, if we have one iBGP instance and one eBGP instance, since 
instance address are different,  route selection  will entry this branch as 
blow, yes ? but we cannot ensure address of eBGP is prior than  address of 
iBGP... is it based on sequence of BGP instance in bird.conf ? 

 if (new->attrs->src->proto->proto != old->attrs->src->proto->proto) 
{
  /*
   *  If the user has configured protocol preferences, so that two 
different protocols
   *  have the same preference, try to break the tie by comparing 
addresses. Not too
   *  useful, but keeps the ordering of routes unambiguous.
   */
  return new->attrs->src->proto->proto > old->attrs->src->proto->proto;
}

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, April 18, 2018 10:58 PM
To: Arvin Gan 
Cc: bird-users@network.cz; Robert Blayzor 
Subject: Re: BGP route selection

On Wed, Apr 18, 2018 at 03:35:43AM +, Arvin Gan wrote:
> Hi all,
>Sorry, it's my ambiguous description. What I said default value is Cisco's 
> admin distance value, eBGP is 20 and iBGP is 200. We plan to use preference 
> to implement  admin distance. Actually ,in bird,  the preference of channel 
> for BGP is  BGP protocol default preference DEF_PREF_BGP ( = 100). 
>  1)  Since the configuration of preference is in channel ,if the protocol 
> have more than one channel, does mean different channel can configure 
> different preference  in the same protocol ?

Yes

>  2) I also notice that " new->pref = c->preference; " in rte_update2, 
> does mean  the preference of route in route table get from  preference of 
> channel ?

Yes, the channel preference is just a default value for route preference (could 
be changed even per-route by filters).

>  3)  When route selection, does mean algorithm selection compare 
> preference of every route firstly , whether compare  the preference of  
> routes coming from same protocol ?  

Yes

> The global best route selection algorithm is (roughly) as follows:  ---> Does 
> routes selection be processed as below sequence ?
> 
>*   Preferences of the routes are compared.  > what's preference of 
> the route, is preference in channel-config ?
>*   Source protocol instance preferences are compared. --> what's protocol 
> instance preference, is preference in channel-config for BGP protocol 
> instance?

This is a bit confusing in documentation, there is just route preference (which 
is compared as a first step). Protocol/channel preference is just a default 
value for route preference.

>*   If source protocols are the same (e.g. BGP vs. BGP), the protocol's 
> route selection algorithm is invoked. --->source protocols, iBGP and eBGP are 
> treated as same source protocol ?

Yes

>*   If source protocols are different (e.g. BGP vs. OSPF), result of the 
> algorithm is undefined.

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

[Arvin Gan]

Hi ,
   Yes, I used GDB tools to trace,  the coredump  occurred on "0x0006ea88 in 
bug (msg=0x7b7c8 "Unknown instruction %d in same (%c)") at 
sysdep/unix/log.c:213".

Thanks
Arvin

-Original Message-
From: Jan Maria Matejka  
Sent: Wednesday, April 25, 2018 9:26 PM
To: Arvin Gan ; bird-users@network.cz
Subject: Re: BGP filter

[...]

On 04/25/2018 12:38 PM, Arvin Gan wrote:
> Thanks, I will try.

We found out that it may coredump on reconfiguration as instruction comparison 
happens there and the format() instruction has no comparator. Please look into 
your log, there should be something like >>Bug: Unknown instruction<<.

Thanks
Maria

RE: netlink support question for RFC 5549

[Arvin Gan]

Hi ,
   Yes, Linux kernel does not supported on by now, but we found a kernel patch 
to support RFC 5549, we are trying to support this case.

http://lists.openwall.net/netdev/2015/03/26/142

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, April 25, 2018 8:45 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: netlink support question for RFC 5549

On Tue, Apr 24, 2018 at 10:38:03AM +, Arvin Gan wrote:
> Hi All,
>
>  I notice that BGP can support RFC 5549  using configuration 
> "ext_next_hop", bird can sync with kernel table using netlink assuming 
> kernel support route with IPV4 DIP and IPV6 next hop.
> ...
> that mean if bird received IPV4 NLRI  with IPV6 next hop, the gateway 
> is parsed with IPV4 address since address family is IPV4 unicast on 
> this case, does  my understand correct ? If yes, this parse process 
> have a bug ?

Hi

BIRD does not support mixed next hops on netlink. It would be simple to 
implement that, but i think that Linux kernel does not (yet) support such 
routes anyway. At least i failed to setup such routes using 'ip' tool.

Could you (or anybody) get such routes to work in Linux?

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

[Arvin Gan]

Thanks, I will try.

-Original Message-
From: Bird-users  On Behalf Of Jan Maria Matejka
Sent: Wednesday, April 25, 2018 6:31 PM
To: bird-users@network.cz
Subject: Re: BGP filter

>> 2.   config-file:
>>
>>   filter filter_bgp1{
>>
>>   if format(net) = "0.0.0.0/0" then accept;  // "format(net) 
>> = ." , bird coredump ???
>>
>>   /* if net = "0.0.0.0/0" then accept;  // " net= ." 
>> ,  not bird coredump*/
>>
>> }
> 
> Will check this. Thanks for report.

Checked, couldn't reproduce. My test config follows below:

- 8<  BEGIN OF CONFIG - define x = 
(format(0.0.0.0/0) = "0.0.0.0/0"); filter y { if format(net) = "0.0.0.0/0" then 
accept; };

protocol device {}
protocol kernel { learn; ipv4; }
protocol kernel { learn; ipv6; }

ipv4 table ttt;

protocol pipe { table ttt; peer table master4; import filter y; export filter 
y; }
- 8<  END OF CONFIG ---

This does not trigger a coredump when running on v2.0.2.

Please try this config on your machine or send in some minimal config that 
causes a coredump.

Thanks!
Maria

RE: BGP filter

[Arvin Gan]

Hi ,
  Thanks for your response. 
  Do you know the reason " show route filter {if format(net) = "0.0.0.0/0" then 
accept;}" is running correctly in birdc command ,but cause the coredump in 
config-file?  

Thanks
Arvin

-Original Message-
From: Bird-users  On Behalf Of Jan Maria Matejka
Sent: Wednesday, April 25, 2018 6:19 PM
To: bird-users@network.cz
Subject: Re: BGP filter

Hi!

> 1.   bird>show route filter {if format(net) = "0.0.0.0/0" then accept;}  
> //correct result
> 
> /* show route filter {if net = "0.0.0.0/0" then accept;}  // incorrect result 
>  */

compare net = 0.0.0.0/0 - the "0.0.0.0/0" is a string literal, the 0.0.0.0/0 is 
a prefix literal.

> 2.   config-file:
> 
>   filter filter_bgp1{
> 
>   if format(net) = "0.0.0.0/0" then accept;  // "format(net) 
> = ." , bird coredump ???
> 
>   /* if net = "0.0.0.0/0" then accept;  // " net= ." ,  not 
> bird coredump*/
> 
> }

Will check this. Thanks for report.
M.

BGP filter

[Arvin Gan]

Hi All,
  I am implementing a function that send default route to BGP peer, and I am 
facing an issue about BGP filter, when I use "show route filter" in birdc, the 
filter result is correct; when I add this filter to config-file and start bird, 
the bird will occur coredump issue. Does anyone know the reason?  Appreciated 
in advance.


1.   bird>show route filter {if format(net) = "0.0.0.0/0" then accept;}  
//correct result

/* show route filter {if net = "0.0.0.0/0" then accept;}  // incorrect result  
*/

2.   config-file:
  filter filter_bgp1{
  if format(net) = "0.0.0.0/0" then accept;  // "format(net) = 
..." , bird coredump ???
  /* if net = "0.0.0.0/0" then accept;  // " net= ..." ,  not 
bird coredump*/
}

  protocol  bgp bgp1 {
 ..
ipv4 {
  import all;
  export filter filter_bgp1;
  };
  
}
Thanks
Arvin

netlink support question for RFC 5549

[Arvin Gan]

Hi All,
 I notice that BGP can support RFC 5549  using configuration 
"ext_next_hop", bird can sync with kernel table using netlink assuming kernel 
support route with IPV4 DIP and IPV6 next hop. Sending route to kernel 
(nl_add_nexthop()) that don't  check address family type that mean bird can 
send IPV4 NLRI with IPV6 next_hop to kernel if enabled "ext_next_hop". For bird 
receiving kernel route table, bird parse the gateway with nl_parse_attrs from 
rtm_attr_want4/rtm_attr_want6 based on address family , that mean if bird 
received IPV4 NLRI  with IPV6 next hop, the gateway is parsed with IPV4 address 
since address family is IPV4 unicast on this case, does  my understand correct 
? If yes, this parse process have a bug ?

Thanks
Arvin

RE: BGP route selection

[Arvin Gan]

Hi,
   Onderj, thank you!  I notice this codes in rte_better() in file rt-table.c.  
Since iBGP and eBGP have same protocol preference, that mean route preference 
are also same. In this case, if we have one iBGP instance and one eBGP 
instance, since instance address are different,  route selection  will entry 
this branch as blow, yes ? but we cannot ensure address of eBGP is prior than  
address of iBGP... is it based on sequence of BGP instance in bird.conf ? 

 if (new->attrs->src->proto->proto != old->attrs->src->proto->proto) 
{
  /*
   *  If the user has configured protocol preferences, so that two 
different protocols
   *  have the same preference, try to break the tie by comparing 
addresses. Not too
   *  useful, but keeps the ordering of routes unambiguous.
   */
  return new->attrs->src->proto->proto > old->attrs->src->proto->proto;
}

Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Wednesday, April 18, 2018 10:58 PM
To: Arvin Gan 
Cc: bird-users@network.cz; Robert Blayzor 
Subject: Re: BGP route selection

On Wed, Apr 18, 2018 at 03:35:43AM +, Arvin Gan wrote:
> Hi all,
>Sorry, it's my ambiguous description. What I said default value is Cisco's 
> admin distance value, eBGP is 20 and iBGP is 200. We plan to use preference 
> to implement  admin distance. Actually ,in bird,  the preference of channel 
> for BGP is  BGP protocol default preference DEF_PREF_BGP ( = 100). 
>  1)  Since the configuration of preference is in channel ,if the protocol 
> have more than one channel, does mean different channel can configure 
> different preference  in the same protocol ?

Yes

>  2) I also notice that " new->pref = c->preference; " in rte_update2, 
> does mean  the preference of route in route table get from  preference of 
> channel ?

Yes, the channel preference is just a default value for route preference (could 
be changed even per-route by filters).

>  3)  When route selection, does mean algorithm selection compare 
> preference of every route firstly , whether compare  the preference of  
> routes coming from same protocol ?  

Yes

> The global best route selection algorithm is (roughly) as follows:  ---> Does 
> routes selection be processed as below sequence ?
> 
>*   Preferences of the routes are compared.  > what's preference of 
> the route, is preference in channel-config ?
>*   Source protocol instance preferences are compared. --> what's protocol 
> instance preference, is preference in channel-config for BGP protocol 
> instance?

This is a bit confusing in documentation, there is just route preference (which 
is compared as a first step). Protocol/channel preference is just a default 
value for route preference.

>*   If source protocols are the same (e.g. BGP vs. BGP), the protocol's 
> route selection algorithm is invoked. --->source protocols, iBGP and eBGP are 
> treated as same source protocol ?

Yes

>*   If source protocols are different (e.g. BGP vs. OSPF), result of the 
> algorithm is undefined.

--
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 route selection

[Arvin Gan]

Hi all,
   Sorry, it's my ambiguous description. What I said default value is Cisco's 
admin distance value, eBGP is 20 and iBGP is 200. We plan to use preference to 
implement  admin distance. Actually ,in bird,  the preference of channel for 
BGP is  BGP protocol default preference DEF_PREF_BGP ( = 100). 
 1)  Since the configuration of preference is in channel ,if the protocol 
have more than one channel, does mean different channel can configure different 
preference  in the same protocol ?
 2) I also notice that " new->pref = c->preference; " in rte_update2, does 
mean  the preference of route in route table get from  preference of channel ?  
  
 3)  When route selection, does mean algorithm selection compare preference 
of every route firstly , whether compare  the preference of  routes coming from 
same protocol ?  

The global best route selection algorithm is (roughly) as follows:  ---> Does 
routes selection be processed as below sequence ?

   *   Preferences of the routes are compared.  > what's preference of the 
route, is preference in channel-config ?
   *   Source protocol instance preferences are compared. --> what's protocol 
instance preference, is preference in channel-config for BGP protocol instance?
   *   If source protocols are the same (e.g. BGP vs. BGP), the protocol's 
route selection algorithm is invoked. --->source protocols, iBGP and eBGP are 
treated as same source protocol ?
   *   If source protocols are different (e.g. BGP vs. OSPF), result of the 
algorithm is undefined.

The Admin distance of Cisco for eBGP and iBGP:  
https://supportforums.cisco.com/t5/wan-routing-and-switching/administrative-distance-and-bgp-path-selection-process/td-p/2276230

Thanks
Arvin

-Original Message-
From: Bird-users  On Behalf Of Robert Blayzor
Sent: Tuesday, April 17, 2018 10:07 PM
To: bird-users@network.cz
Subject: Re: BGP route selection

On 4/17/18 8:20 AM, Ondrej Zajicek wrote:
> Hi
> 
> No, default value is 200 for both EBGP and IBGP. Where did you noticed 20?


20 is Cisco's default admin distance for EBGP.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

RE: BGP attribute ext-next-hop

[Arvin Gan]

Hi, 
Thanks!
Thanks
Arvin

-Original Message-
From: Ondrej Zajicek  
Sent: Tuesday, April 17, 2018 8:22 PM
To: Arvin Gan 
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 +0000, 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."

BGP route selection

[Arvin Gan]

Hi,
I notice that there is a description of route selection algorithm:

  The global best route selection algorithm is (roughly) as follows:

  *   Preferences of the routes are compared.
  *   Source protocol instance preferences are compared.
  *   If source protocols are the same (e.g. BGP vs. BGP), the protocol's route 
selection algorithm is invoked.
  *   If source protocols are different (e.g. BGP vs. OSPF), result of the 
algorithm is undefined.
  And I also notice that normally the  configuration  "Administrative Distance" 
 that is mapped to preference under channel  in bird  is different between eBGP 
(default  value 20) and iBGP (default value 200).

My question is : If iBgp preference is lower than eBGP preference that mean 
iBGP priority higher than eBGP,   iBGP route is selected or eBGP route is 
selected, do anyone know it? But in BGP instance, eGBP is prior than iBGP   
Appreciated in advance!

Thanks
Arvin

RE: BGP attribute ext-next-hop

[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

[Arvin Gan]

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

[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  
Sent: Tuesday, April 03, 2018 10:14 PM
To: Arvin Gan 
Cc: bird-users@network.cz
Subject: Re: BGP attribute ext-next-hop

On Tue, Apr 03, 2018 at 09:42:18AM +, 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: 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."

BGP attribute ext-next-hop

[Arvin Gan]

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 ?

Thanks
Arvin