- Bird-users - Mailing Lists

Re: How to show community value
by Mo Shivji 12 Jul '18

12 Jul '18

> On 12 Jul 2018, at 10:58, Isaac HO <isaacho.jc(a)gmail.com> wrote: > > Thanks all but tried two method no luck. > > echo "show route all x.x.x.0/24" | sudo /usr/bin/birdc -s /var/run/bird.ctl > sudo: /usr/bin/birdc: command not found Perhaps birdc is under a different path on your box. > > birdc 'show route for x.x.x.0/24 all' > BIRD 1.6.4 ready. > 5.195.208.0/24 <http://5.195.208.0/24> via 192.168.199.202 on ens160 [R77654x1 14:32:50] * (100) [AS77654i] > Type: BGP unicast univ > BGP.origin: IGP > BGP.as_path: 77654 > BGP.next_hop: 192.168.199.202 > BGP.med: 0 > BGP.local_pref: 100 > I guess the community attribute is not showing because the prefix is not tagged with any communities. The above works for me also and shows the tagged communities. Mo

1 0

How to show community value
by Isaac HO 12 Jul '18

12 Jul '18

sh ip bgp x.x.x.0/24 <-- Cisco birdc show route where net ~ x.x.x.0/24 all BIRD 1.6.4 ready. root: variable expected. <-- Can't see any information. May I know have any other command? Thanks,

3 2

[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

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