July 2018 - Bird-users - Mailing Lists

[PATCH] babel: Check TLV framing before dereferencing tlv->type
by Toke Høiland-Jørgensen 11 Jul '18

11 Jul '18

Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4ecf649..991c1520 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -1373,10 +1373,6 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, (byte *)tlv < end; tlv = NEXT_TLV(tlv)) { - /* Ugly special case */ - if (tlv->type == BABEL_TLV_PAD1) - continue; - /* The end of the common TLV header */ pos = (byte *)tlv + sizeof(struct babel_tlv); if ((pos > end) || (pos + tlv->length > end)) @@ -1386,6 +1382,10 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, break; } + /* Ugly special case */ + if (tlv->type == BABEL_TLV_PAD1) + continue; + msg = sl_alloc(p->msg_slab); res = babel_read_tlv(tlv, &msg->msg, &state); if (res == PARSE_SUCCESS) -- 2.18.0

2 2

[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