- Bird-users - Mailing Lists

[PATCH] babel: Don't send routes with empty next hops
by Toke Høiland-Jørgensen 10 Jul '18

10 Jul '18

If an interface has no configured v4 address, no valid next hop will be found for v4 routes. Rather than send them with an invalid next hop (which will just cause parse errors at the receiver), skip such routes entirely when sending updates. Also, amend the warning on configure to make it clear that v4 routes will not work if there is no v4 address on the interface. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 44c6adb8..d3b5b841 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -951,8 +951,13 @@ babel_send_update_(struct babel_iface *ifa, btime changed, struct fib *rtable) msg.update.next_hop = ((e->n.addr->type == NET_IP4) ? ifa->next_hop_ip4 : ifa->next_hop_ip6); - - babel_enqueue(&msg, ifa); + /* + * We may get empty next hop addresses here if no v4 address is configured + * on the interface. These will just cause parsing errors at the receiver, + * so don't send them. + */ + if (!ipa_zero(msg.update.next_hop)) + babel_enqueue(&msg, ifa); /* Update feasibility distance for redistributed routes */ if (e->router_id != p->router_id) @@ -1580,7 +1585,8 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) - log(L_WARN "%s: Cannot find IPv4 next hop addr on %s", p->p.name, new->name); + log(L_WARN "%s: Cannot find IPv4 next hop addr on %s. " + "v4 routes will not work!", p->p.name, new->name); init_list(&ifa->neigh_list); ifa->hello_seqno = 1; @@ -1682,7 +1688,8 @@ babel_reconfigure_iface(struct babel_proto *p, struct babel_iface *ifa, struct b ifa->next_hop_ip6 = ipa_nonzero(new->next_hop_ip6) ? new->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) - log(L_WARN "%s: Cannot find IPv4 next hop addr on %s", p->p.name, ifa->ifname); + log(L_WARN "%s: Cannot find IPv4 next hop addr on %s. " + "v4 routes will not work!", p->p.name, ifa->ifname); if (ifa->next_hello > (current_time() + new->hello_interval)) ifa->next_hello = current_time() + (random() % new->hello_interval); -- 2.17.1

1 2

multiple BIRD instances on the same machine with seperated RIBs
by Kurt Wauters 10 Jul '18

10 Jul '18

Hello, I recently started playing with BIRD and was wondering if i can run multiple BIRD instances on the same machine but the route selection should happen per instance and not accross instances. Basically i want to setup different RS on the same machine. I’ve found out that you can listen on different ip’s/interfaces but they seem to be sharing the same table. Any idea if and how it can be configured? Thanks Kurt

2 1

route server community evaluation examples - bug and fix
by Chris Caputo 08 Jul '18

08 Jul '18

On Mon, 22 Jan 2018, Chris Caputo wrote: > To see the communities supported by the SIX route servers, refer to: > > https://www.seattleix.net/route-servers#communities > > Below is how we do it with bird 1.6.3. Not sure about 2.0+. > > I hope this helps and feedback from the community is welcome. > > Chris > > --- > > define myas = SET TO IXP ASN; > define peerPrepend1 = 65001; > define peerPrepend2 = 65002; > define peerPrepend3 = 65003; > > # BGP output filter (based on communities) > # Returning false means don't propagate route to peeras. > # Returning true means do propagate route to peeras. > function bgp_out_comm(int peeras) > { > if ! (source = RTS_BGP ) then return false; > > if (myas,0,peeras) ~ bgp_large_community then return false; > if (myas,1,peeras) ~ bgp_large_community then return true; > if (myas,0,0) ~ bgp_large_community then return false; > > if peeras > 65535 then > { > if (ro,0,peeras) ~ bgp_ext_community then return false; > if (ro,myas,peeras) ~ bgp_ext_community then return true; > if ((ro,0,myas) ~ bgp_ext_community) then return false; > } else { > if ((0,peeras) ~ bgp_community) || ((ro,0,peeras) ~ bgp_ext_community) then return false; > if ((myas,peeras) ~ bgp_community) || ((ro,myas,peeras) ~ bgp_ext_community) then return true; > if ((0,myas) ~ bgp_community) || ((ro,0,myas) ~ bgp_ext_community) then return false; > } > return true; > } I now believe the above and examples at: https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… https://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.… and likely elsewhere, are buggy in that 32-bit ASN peers of the route server will be exempt from a standard community deny of (0:IXP_ASN). They shouldn't be. I believe the deny check for both standard and extended communities needs to be outside of the check for a 32-bit ASN peer during the export evaluation. Thus the above should be changed as follows: --- define myas = SET TO IXP ASN; # BGP output filter (based on communities) # Returning false means don't propagate route to peeras. # Returning true means do propagate route to peeras. function bgp_out_comm(int peeras) { if ! (source = RTS_BGP ) then return false; if (myas,0,peeras) ~ bgp_large_community then return false; if (myas,1,peeras) ~ bgp_large_community then return true; if (myas,0,0) ~ bgp_large_community then return false; if peeras > 65535 then { if (ro,0,peeras) ~ bgp_ext_community then return false; if (ro,myas,peeras) ~ bgp_ext_community then return true; } else { if ((0,peeras) ~ bgp_community) || ((ro,0,peeras) ~ bgp_ext_community) then return false; if ((myas,peeras) ~ bgp_community) || ((ro,myas,peeras) ~ bgp_ext_community) then return true; } if ((0,myas) ~ bgp_community) || ((ro,0,myas) ~ bgp_ext_community) then return false; return true; } --- Diff as follows: --- { if (ro,0,peeras) ~ bgp_ext_community then return false; if (ro,myas,peeras) ~ bgp_ext_community then return true; - if ((ro,0,myas) ~ bgp_ext_community) then return false; } else { if ((0,peeras) ~ bgp_community) || ((ro,0,peeras) ~ bgp_ext_community) then return false; if ((myas,peeras) ~ bgp_community) || ((ro,myas,peeras) ~ bgp_ext_community) then return true; - if ((0,myas) ~ bgp_community) || ((ro,0,myas) ~ bgp_ext_community) then return false; } + + if ((0,myas) ~ bgp_community) || ((ro,0,myas) ~ bgp_ext_community) then return false; + return true; } --- Feedback welcome and if agreed, I think the wiki should be updated. Thanks, Chris

2 1

route withdrawals are not sent upon protocol removal
by Thomás S. Bregolin 08 Jul '18

08 Jul '18

Hello, bird (all versions) does not send BGP route withdrawals when a protocol is removed, only when the filter changes or the protocol is disabled. Is this intentional? If not, could it be a configurable option to send route withdrawals upon protocols being removed? I am having an issue where the peers keep stale routes that were removed from bird but were not withdrawn via update messages. Regards, Thomás

4 15

BIRD - Config Support for RFC 3107 - Carrying Label Information in BGP
by LAKSHMANAN, THIRUVAZHIYA 30 Jun '18

30 Jun '18

Dear support-team, In the BIRD 2.0 user guide, I see the support for RFC 3107 - Carrying Label information in BGP. We want to configure a VM with BIRD agent working like a PE for adding MPLS labels for IPv4 and IPv6 unicast routes. Do we have this configuration supported now, and can I get any sample working configuration for this please. Regards, Thiruvazhiyan

5 18

Advertise Loopback interface to the 3107 BGP neighbor
by Thiruvazhiyan Lakshmanan 29 Jun '18

29 Jun '18

Dear Support, I have a VM running with Bird 2.0.2 and peering with a 3107 BGP neighbor. I would like to advertise VM's loopback IP address to the 3107 BGP neighbor (Labeled unicast) with label value of 3 and the nexthop as interface address. Is it possible and how can it be achieved. Thanks & Regards, Thiru ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. ============================================================================================================================

1 0

MP_UNREACH_NLRI RFC8277 compatibility
by Vadim Fedorenko 29 Jun '18

29 Jun '18

Hi! According to RFC 8277, NLRI for withdrawal contains 3 fields: Length, Compatibility and Prefix. "Upon transmission, the Compatibility field SHOULD be set to 0x800000.Upon reception, the value of the Compatibility field MUST be ignored." Right now, BIRD 2.0.2 checks Compatibility field for value 0x800000, and this is not compatible with RFC, and at least Juniper MX do not set this field to 0x800000, and BGP session between BIRD and Juniper resets with Malformed Attribute List. Attached patch fixes this behavior. diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c index 190fd6f..5dcb00d 100644 --- a/proto/bgp/packets.c +++ b/proto/bgp/packets.c @@ -1165,8 +1165,11 @@ bgp_decode_mpls_labels(struct bgp_parse_state *s, byte **pos, uint *len, uint *p ADVANCE(*pos, *len, 3); *pxlen -= 24; - /* Withdraw: Magic label stack value 0x800000 according to RFC 3107, section 3, last paragraph */ - if (!a && !s->err_withdraw && (lnum == 1) && (label == BGP_MPLS_MAGIC)) + /* + * Withdraw: According to RFC 3107, section 2.4, second paragraph + * Upon reception, the value of the Compatibility field MUST be ignored. + */ + if (!a && !s->err_withdraw && (lnum == 1) && (s->mp_unreach_len)) break; } while (!(label & BGP_MPLS_BOS));

2 1

How to upgrade from 1.6.4 to 2.0
by Isaac HO 28 Jun '18

28 Jun '18

Thanks.

1 0

BGP hostentry update
by Arvin Gan 28 Jun '18

28 Jun '18

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

2 5

BIRD 2.x and arrays
by Carlo Rengo 27 Jun '18

27 Jun '18

Hi, I'm testing BIRD 2 (version 2.0.2) but I am having issue with the new syntax. More specifically, with arrays. This is a snippet of my configuration: protocol direct direct1 { interface "lo"; debug all; ipv4 { import where net ~ 192.168.60.0/24 ; export none; }; } I start bird and this is the logged output: 2018-06-27T15:26:21.123818+02:00 my.bird.router.com bird: direct1 < address 127.0.0.0/8 on interface lo added 2018-06-27T15:31:19.396405+02:00 my.bird.router.com bird: direct1 < address 192.168.60.10/32 on interface lo added 2018-06-27T15:31:19.396527+02:00 my.bird.router.com bird: direct1 > filtered out 192.168.60.10/32 unicast 2018-06-27T15:31:19.396653+02:00 my.bird.router.com bird: direct1 < address 192.168.60.20/32 on interface lo added 2018-06-27T15:31:19.396778+02:00 my.bird.router.com bird: direct1 > filtered out 192.168.60.20/32 unicast 2018-06-27T15:31:19.397165+02:00 my.bird.router.com bird: direct1 < address 192.168.60.21/32 on interface lo added 2018-06-27T15:31:19.397295+02:00 my.bird.router.com bird: direct1 > filtered out 192.168.60.21/32 unicast 2018-06-27T15:31:19.397419+02:00 my.bird.router.com bird: direct1 < address 192.168.60.12/32 on interface lo added 2018-06-27T15:31:19.397541+02:00 my.bird.router.com bird: direct1 > filtered out 192.168.60.12/32 unicast This works as expected. Now, if I try to use even a 1-member array, like this: protocol direct direct1 { interface "lo"; debug all; ipv4 { import where net ~ [ 192.168.60.0/24 ]; export none; }; } the result is that bird filters out my IPs. These are the relevant log lines: 2018-06-27T15:26:21.123818+02:00 my.bird.router.com bird: direct1 < address 127.0.0.0/8 on interface lo added 2018-06-27T15:26:21.123943+02:00 my.bird.router.com bird: direct1 < address 192.168.60.10/32 on interface lo added 2018-06-27T15:26:21.124277+02:00 my.bird.router.com bird: direct1 > added [best] 192.168.60.10/32 unicast 2018-06-27T15:26:21.124406+02:00 my.bird.router.com bird: direct1 < address 192.168.60.20/32 on interface lo added 2018-06-27T15:26:21.124534+02:00 my.bird.router.com bird: direct1 > added [best] 192.168.60.20/32 unicast 2018-06-27T15:26:21.124913+02:00 my.bird.router.com bird: direct1 < address 192.168.60.21/32 on interface lo added 2018-06-27T15:26:21.125041+02:00 my.bird.router.com bird: direct1 > added [best] 192.168.60.21/32 unicast 2018-06-27T15:26:21.125177+02:00 my.bird.router.com bird: direct1 < address 192.168.60.12/32 on interface lo added 2018-06-27T15:26:21.125304+02:00 my.bird.router.com bird: direct1 > added [best] 192.168.60.12/32 unicast "import where net ~" + "array" has always worked fine with BIRD 1.6. Did the syntax change on v2? Is this a bug? Thanks, Carlo

2 5