- Bird-users - Mailing Lists

draft-keyur-idr-bgp-prefix-limit-orf
by Marco Marzetti 15 Nov '17

15 Nov '17

Dear Developer of BIRD, We're working on a draft called draft-keyur-idr-bgp-prefix-limit-orf that you can find on IETF's website at this URL: https://tools.ietf.org/html/ draft-keyur-idr-bgp-prefix-limit-orf-02 Its goal is to allow BGP speakers to exchange maxprefix values in-band by making use of the ORF capability. We think the ideas expressed in the draft are very simple, but we would like to hear from you how hard it would be to get them implemented in your software. Let me briefly explain how it is supposed to work. Peer A and B set up a BGP session and set ORF as one of the active capabilities. Every time administrators of A change/set/remove maxprefix router A sends an ORF message indicating to router B the new value along with the behavior that router B must follow. In case that the Match field is set to DENY router B will consider the value as purely informational and will follow the usual behavior. Else, in case Match is set to PERMIT, router B will not advertise any prefix if that would cause the amount of advertised (non withdrawn) prefixes to exceed router's A maxprefix value. Please note that what described above is just a coarse summary of what is stated within the draft. We encourage you to read it to better understand what we're working on. In case that you're wondering why draft-keyur-idr-bgp-prefix-limit-orf could be useful here some real world cases: 1) Life safer for unplanned redistribution or fat fingers. In MPLS L3VPNs service providers often impose strict maxprefix limit as those are commercial values discussed before of signing the contracts. An unplanned increment in the advertisements may break the VPN. In that case spokes may prefer to not to announce some routes and still be able to reach the rest of the network from the larger part of the site than loosing all connectivity. And hubs can advertise both default and more specific routes for traffic engineering without the risk of breaking the network. Almost the same applies to FlowSpec where you could prefer to not to advertise some "rules" than to get all of them withdrawn because of an error. 2) Easier and faster method to share maxprefix betweem peers. Maxprefix is one of the few protection mechanisms used by autonomous systems when peering in the DFZ. When networks merge or transit providers get new large customers their NOCs have to reach all the peering partners in an attempt to get maxprefix updated. This is usually done by broadcasting the request by email to all peers (maybe multiple times) a few weeks before of the increment. Then "cross the fingers" and send the additional advertisements. What often happens is emails got lost or unnoticed by the network engineers of the receiving network and AS to AS connectivity breaks for some hours or even days. With the proposed solution the NOCs would be able to verify if the change has been executed before of touching anything. At this very moment we're in the process of refining the draft before of submitting it to the IETF community, but we do understand that internet standards are useful only if they're supported by vendors. For this reason we would like to hear from you how hard it could be to add the features of draft-keyur-idr-bgp-prefix-limit-orf in BIRD. In case that it would be too complicated please let us know how we could make things easier. Thank you in advance for the comments or the suggestions you would like to make. Regards -- Marco

1 0

Export only "Primary" (best) route
by Jean-Baptiste COUPIAC 15 Nov '17

15 Nov '17

Hello everybody, I'm trying to configure a Route-Reflector. I have created a filter to import only some AS: ############################ filter bgp_IN prefix set allnet; int set allas; { allas = [10753, 10929, 11478, 12322, 12353, 12392, 12566, 12670, 12684, 12876, 13193, 13238, 13335, 133530, 13414, 14061, 14618, 15133, 15169, 15557, 15895, 16136, 16211, 16276, 16347, 16509, 174, 19506, 197161, 198551, 199064, 201106, 202089, 202727, 203070, 203476, 20473, 20900, 20940, 21502, 21837, 2200, 23033, 23889, 24711, 24940, 24961, 25117, 25186, 25540, 26101, 2635, 2856, 28708, 2914, 29169, 29286, 30999, 31167, 31216, 31976, 32097, 3215, 3269, 32934, 3303, 3320, 3352, 3356, 34010, 34173, 34177, 34274, 34949, 35540, 35625, 35632, 35994, 36351, 36408, 36647, 36903, 36947, 39405, 39473, 39572, 39931, 4134, 43350, 43646, 44050, 44444, 47608, 47833, 47841, 48069, 48072, 4837, 50583, 5089, 51207, 51862, 52075, 5410, 54104, 54113, 5432, 55967, 56844, 5769, 577, 57809, 60068, 60718, 60855, 62044, 62540, 65623, 6661, 6713, 6830, 6848, 702, 714, 786, 7922, 8068, 8075, 8218, 8220, 8228, 8346, 8399, 8560, 8565, 8839, 9003, 9159]; if (bgp_path.last ~ allas) then accept; reject; } ############################ protocol bgp ibgp_AAAAA { table bgp_filtre_IN; import filter bgp_IN; export none; local as XXXXX; neighbor YYYYYYYY as XXXXX; } protocol bgp ibgp_BBBBB { table bgp_filtre_IN; import filter bgp_IN; export none; local as XXXXX; neighbor ZZZZZZZZZ as XXXXX; } ############################ Into to table bgp_filtre_IN, I wan to have only the best route (primary route) instead of all. For example, for 2.22.88.0/22 bird> show route table bgp_filtre_IN for 2.22.88.0/22 2.22.88.0/22 unreachable [ibgp_AAAAA 17:04:11 from YYYYYYYYY] * (100/-) [AS20940i] unreachable [ibgp_BBBBB 17:04:07 from ZZZZZZZ] (100/-) [AS20940i] I just want to import first route, which is the best: 2.22.88.0/22 unreachable [ibgp_AAAAA 17:04:11 from YYYYYYYYY] * (100/-) [AS20940i] Can I do it into table bgp_filtre_IN ? Does I need to create another one with some filtering options ? Regards, __ Jean-Baptiste,

1 0

Re: Decode BGP Shutdown Communication messages (RFC 8203)
by Mikhail Grishin 15 Nov '17

15 Nov '17

Hi, 1) You also implemented enable bgp2 "enable message" This message currently seen only at local side and doesn't seen at remote peer. Scenario: You made maintenance work with the shutdown message "Session will be down from 13:00 till 14:00". Later session was established again. Days after at remote peer side still printed the same message. That's confusing. Suggestion: (May be) To show two different messages? Tx and Rx. To clear Rx message every time when BGP session state changed to established. 2) Is it possible to log such messages and see via syslog? P.S. For russian UTF8 text 128 bytes restriction (RFC) probably not always enough. Ondrej Zajicek пишет 19.09.2017 21:53: > On Thu, Jul 27, 2017 at 05:55:40PM +0200, Job Snijders wrote: >> Hi all, >> >> Here is a patch to decode received BGP shutdown communication messages >> as specified in RFC 8203. In the following example scenario I'm sending >> a shutdown communication with openbgpd: >> >> $ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, back in 30 min" >> request processed > Hi > > Merged with some significant changes, with support for both RX and TX of > shutdown communication: > > https://gitlab.labs.nic.cz/labs/bird/commit/cd1d99611e445c9fe2452d05627ccfc… > > I generalized it a bit, so the message is not specific to BGP, but can be > attached to any protocol, so it makes sense that it can be changed by > general commands like disable, restart. That means it also changed the > output a bit: > > bird> show protocols all bgp2 > name proto table state since info > bgp2 BGP master down 19:39:00 > Description: My BGP session > Message: Planned shutdown, back in 30 min > Preference: 100 > Input filter: ACCEPT > Output filter: (unnamed) > BGP state: Down > Neighbor address: 10.0.1.1 > Neighbor AS: 10 > > Conceptually, it is one-item mailbox, which can be set by either the core > (using enable/disable/restart commands) or the protocol (received BGP > Notification with the RFC 8203 message). I am not sure if it would not be > better to have two separate mailboxes for both directions, but it > probably does not matter. > > The message can be send from BIRD shell: > > birdc> disable bgp1 "hi, we will upgrade to bird 1.6.4" > > Unfortunately, that means that from Unix shell you have to do double qouting: > > birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"' > > Currently no support for message associated with 'disabled' in bird.conf > or for message associated with BIRD global shutdown. > > > Otherwise, there are some minor changes w.r.t. your patch: > > 1) Your patch requires that RFC 8203 message fills the entire space of > BGP notification (i.e. msg_len + 1 == remaining_len). I do not see any > such requirement in RFC 8203, so i accept if (msg_len + 1 <= remaining_len) > > 2) I reset the message not with any RX notification, but only with > administrative shutdown/reset notification. That prevents message reset > with subsequent errors unrelated to administrative notification. > > 3) Proper handling of zero-length messages (should be handled equally > like no message at all according to RFC 8203). > > 4) Some basic sanitization of received strings to avoid escape-attacks > and newlines in logs. > > Any comments, suggestions, opposition? >

3 4

bird control-socket: connection reset by peer
by Oliver Herms 14 Nov '17

14 Nov '17

Hello bird users, I'm running bird 1.6.3 on ubuntu 16.04 as kind of a route server. I wrote a piece of software that connects to the bird control-socket and runs queries against it like this: "show route all for x.y.z.a protocol xxx". The software keeps the socket open and executes the queries in a loop persisting of a write() call followed by a read() call. Now to the problem: At some point bird resets the connection and the logs are not showing anything related. Did anyone make similar experiences or can help me to find out what's wrong with bird here? Thanks Oliver -- Oliver Herms oliver.peter.herms(a)gmail.com

2 2

Bird6 high CPU usage
by Saksham Manchanda 12 Nov '17

12 Nov '17

Hi All, I have a loopback IPv6 address on a server. IP addr = 2dd:1111:1111:1111:1111::1 I use BGP to announce this to the upstream router. Client traffic comes in through an interface ens3 connected to the router with destination address as the loopback. Bird configuration: protocol direct { description "Local anycast addresses"; export none; interface "lo"; } # The kernel protocol gives us access to the kernel routing table. protocol kernel { #persist; # Don't remove routes on shutdown scan time 20; # Scan kernel routing table every 20 seconds export all; # Default is export none } # The device protocol is needed in order to see what addresses are local # to this server. protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol bgp { description "Arya"; import none; local as 65001; neighbor neighbourIPv6ADDR as 100; direct; # Neighbors are directly connected hold time 240; connect retry time 120; keepalive time 80; # defaults to hold time / 3 #export filter packetdns; export all; } All this works great. Now, when client traffic comes in we get the following entries in the routing table: . . . CLIENTIP::136 via 2dd:1111:1111:1111:1111::1 dev ens3 metric 0 cache CLIENTIP::5 via 2dd:1111:1111:1111:1111::1 dev ens3 metric 0 cache CLIENTIP::13 via 2dd:1111:1111:1111:1111::1 dev ens3 metric 0 cache CLIENTIP::15 via 2dd:1111:1111:1111:1111::1 dev ens3 metric 0 cache . . . This table grows to ip -6 r s |wc -l 8296 And changes constantly. Now, the top output shows bird using a lot of CPU: 2205 root 20 0 6924 780 560 R 26.2 0.0 0:06.14 bird6 Since my configuration will never make use of these entries, is there a way to disable this scanning behaviour in bird? Thanks! -- Saksham Manchanda

1 0

Issues establishing more than 2 BGP sessions
by Chris Stein 12 Nov '17

12 Nov '17

Hello there- I’m hoping to get guidance/feedback from you all on whether or not what I’m trying to do it possible, and if it is possible, what am I doing incorrectly. My goal is to make this a transit VPC for handling routes between multiple remote regions (and clouds). I’m testing with 4 VPCs (A, B, C, and D), each with a different ASN. VPC B is acting as my transit VPC, which is where bird and strongswan are running. VPCs A, C, and D are acting as the remote regions, and each has a VPN connection back to B. IPSec is up and working as expected, but routing is giving me some trouble. Each VPN has 2 tunnels, so I’m currently trying to establish 6 BGP sessions, however, only 2 sessions will establish at a time. The other sessions are in a “Start” state. Eventually, one of the established connections will drop and may reestablish, or, one of the other tunnels will establish a BGP connection. I have tried multiple bird configurations, but all roads lead back only 2 established BGP sessions. I thought this example might be what I need, but it also did not work: https://gitlab.labs.nic.cz/labs/bird/wikis/Simple_route_server Individually, bird is able to establish a session on both tunnels at every remote VPC, so I know that works. Occasionally, I have noticed that established connections will disconnect with a “Hold timer expired”. There’s something I’m missing/overlooking in the config to allow all sessions to be active. Below is the most basic config I have used. Thanks in advance for your help. log "/var/log/bird.log" all; debug protocols all; router id 172.41.1.117; protocol kernel { scan time 10; export all; import all; } protocol device { scan time 10; } template bgp aws { local as 65000; hold time 30; export all; import all; direct; } protocol bgp ATUN0 from aws { neighbor 169.254.xxx.xxx as 7224; } protocol bgp ATUN1 from aws { neighbor 169.254.xxx.xxx as 7224; } protocol bgp CTUN0 from aws { neighbor 169.254.xxx.xxx as 65100; } protocol bgp CTUN1 from aws { neighbor 169.254.xxx.xxx as 65100; } protocol bgp DTUN0 from aws { neighbor 169.254.xxx.xxx as 65200; } protocol bgp DTUN1 from aws { neighbor 169.254.xxx.xxx as 65200; }

2 2

BGP with wrong netmask on wan interface
by Magnus Löfqvist 09 Nov '17

09 Nov '17

Hi, I have some mobile routers (connected over LTE) and with openvpn. Over the openvpn we are running a BGP to allow distribute some routes and export routes. Some of the routers are having wrong netmask (255.0.0.0 instead of 255.255.255.252). This seems to work (ie internet are working, and the openvpn connection is established). But when we are trying to get the BGP connection up, it tries to send the BGP connection over the WAN istead of openvpn connection. I guess that I have made some mistake in the config. It should take smaller path before matching the larger.. WAN (Mobile): 10.6.90.187 / 255.0.0.0 OpenVPN interface (tap0): 10.9.140.33 / 255.255.252.0 Bird config: template bgp RR_LTE { debug all; # debug BGP description "BIRD RR"; local as 1; # the AS used by the local BGP speaker direct; gateway direct; import filter import_ATM; # just accept everything export filter export_ATM; # and advertise it to all the neigbors connect retry time 10; # reconnect try after 10s hold time 240; # hold time send in BGP messages } protocol bgp BGP1 from RR_LTE { neighbor 10.9.140.1 as 1; preference 140;}; root@client1:/etc# tcpdump -ni wwan0 tcp port 179 and host 10.9.140.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wwan0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:29:08.755188 IP 10.6.90.187.34974 > 10.9.140.1.179: Flags [S], seq 1482209106, win 14600, options [mss 1460,sackOK,TS val 88007 ecr 0,nop,wscale 8], length 0 15:29:11.762726 IP 10.6.90.187.45591 > 10.9.140.1.179: Flags [S], seq 1681977930, win 14600, options [mss 1460,sackOK,TS val 88307 ecr 0,nop,wscale 8], length 0 Med vänlig hälsning / Best regards Magnus Löfqvist

2 9

Fwd: about the bgp route reflector problem?
by 曾小小 03 Nov '17

03 Nov '17

---------- Forwarded message ---------- From: 曾小小 <flyinsky2018(a)gmail.com> Date: 2017-11-03 9:36 GMT+08:00 Subject: Re: about the bgp route reflector problem? To: Matthew Walster <matthew(a)walster.org> Sorry for the description of some problems. Thank you for your answer, thank you very much！！😊 I want to know the route (ebgp) of R3, after entering route reflector (R1), the route obtained on R2 (for example, 120.26.0.0/18, 122.72.90.78/32 route entry) did not add BGP.originator_id and BGP. cluster_list routing attributes? Did you mean that route reflectors do not add route attributes (BGP.originator_id and BGP. Cluster_list) to routes originating from ebgp? 2017-11-03 1:47 GMT+08:00 Matthew Walster <matthew(a)walster.org>: > Maybe I'm missing something here, but in the examples you show, > 120.26.0.0/18 and 122.72.90.78/32 have not been reflected? Route > Reflection deals with iBGP only -- eBGP to iBGP does not need a route > reflector. Only the attributes learned on the iBGP session from R4 will be > reflected (and have the originator and cluster attributes set) to R1. > > Does that make sense? > > Matthew Walster > > On 2 November 2017 at 11:30, 曾小小 <flyinsky2018(a)gmail.com> wrote: > >> about the bgp route reflector problem? >> Why does the reflector client receive EBGP routing entries without >> attributes?? >> >> >> my topology is shown below: >> >> R3 (as 100) >> | >> | （ebgp） >> | >> | >> | ( ibgp) >> R1 (RR)--------------------R4 (client) (as 200) >> | >> | >> | >> | ( ibgp ) >> | >> | >> R2 （client）(as 200) >> My configuration is as follows： >> >> ===The R1 (RR) configuration is as follows: >> >> #ebgp parts >> >> protocol bgp bgp_pa_r3 { >> description "ebgp-pa-r3"; >> multihop 10; >> table tab_pa_adsl; >> igp table tab_ospf_10; >> local as 200; >> neighbor 192.168.1.1 as 100; >> source address 192.168.1.2; >> import all; >> export all; >> next hop self; >> default bgp_local_pref 5; >> } >> >> #rr parts >> template bgp rr_client { >> description "ibgp-rr1"; >> local 192.168.2.1 as 200; >> multihop; >> rr client; >> rr cluster id 1.1.1.1; >> } >> >> protocol bgp bgp_pa_r2 from rr_client { >> debug all; >> enable route refresh on; >> table tab_rr_1; >> igp table tab_ospf_10; >> neighbor 192.168.2.2 as 200; >> export all; >> import all; >> } >> >> protocol bgp bgp_pa_r4 from rr_client { >> table tab_rr_1; >> igp table tab_ospf_10; >> neighbor 192.168.2.4 as 200; >> export all; >> import all; >> # next hop self; >> } >> >> ==The R2 client configuration is as follows: >> >> protocol bgp bgp_pa_r2 { >> router id 192.168.2.2; >> debug all; >> # debug { states,interfaces,events }; >> description "ibgp-rr1"; >> import all; >> export all; >> local as 200; >> neighbor 192.168.2.1 as 200; >> source address 192.168.2.2; >> next hop self; >> } >> >> ================== >> >> Check the route of R2 and find that the route entry received R4 has the >> BGP.originator_id and BGP.cluster_list attributes, >> but the entry received from R1 does not have this attribute. why? >> >> Thank you very much for your help!! thanks!! >> >> >> The route entries viewed by R2 are as follows: >> >> bird> show route protocol bgp_pa_r2 all >> 1007-121.52.236.16/32 >> 1008- Type: BGP unicast univ >> 1012- BGP.origin: IGP >> BGP.as_path: >> BGP.next_hop: 192.168.2.4 >> BGP.local_pref: 100 >> * BGP.originator_id: 192.168.2.4* >> * BGP.cluster_list: 1.1.1.1* >> 1007-116.211.98.20/32 >> 1008- Type: BGP unicast univ >> 1012- BGP.origin: IGP >> BGP.as_path: >> BGP.next_hop: 192.168.2.4 >> BGP.local_pref: 100 >> * BGP.originator_id: 192.168.2.4* >> * BGP.cluster_list: 1.1.1.1* >> 1007-120.26.0.0/18 >> 1008- Type: BGP unicast univ >> 1012- BGP.origin: IGP >> BGP.as_path: 100 >> BGP.next_hop: 192.168.1.1 >> BGP.local_pref: 5 >> >> 1007-122.72.90.78/32 >> 1008- Type: BGP unicast univ >> 1012- BGP.origin: IGP >> BGP.as_path: 100 >> BGP.next_hop: 192.168.1.1 >> BGP.local_pref: 5 >> >> >

2 1

about the bgp route reflector problem?
by 曾小小 02 Nov '17

02 Nov '17

about the bgp route reflector problem? Why does the reflector client receive EBGP routing entries without attributes?? my topology is shown below: R3 (as 100) | | （ebgp） | | | ( ibgp) R1 (RR)--------------------R4 (client) (as 200) | | | | ( ibgp ) | | R2 （client）(as 200) My configuration is as follows： ===The R1 (RR) configuration is as follows: #ebgp parts protocol bgp bgp_pa_r3 { description "ebgp-pa-r3"; multihop 10; table tab_pa_adsl; igp table tab_ospf_10; local as 200; neighbor 192.168.1.1 as 100; source address 192.168.1.2; import all; export all; next hop self; default bgp_local_pref 5; } #rr parts template bgp rr_client { description "ibgp-rr1"; local 192.168.2.1 as 200; multihop; rr client; rr cluster id 1.1.1.1; } protocol bgp bgp_pa_r2 from rr_client { debug all; enable route refresh on; table tab_rr_1; igp table tab_ospf_10; neighbor 192.168.2.2 as 200; export all; import all; } protocol bgp bgp_pa_r4 from rr_client { table tab_rr_1; igp table tab_ospf_10; neighbor 192.168.2.4 as 200; export all; import all; # next hop self; } ==The R2 client configuration is as follows: protocol bgp bgp_pa_r2 { router id 192.168.2.2; debug all; # debug { states,interfaces,events }; description "ibgp-rr1"; import all; export all; local as 200; neighbor 192.168.2.1 as 200; source address 192.168.2.2; next hop self; } ================== Check the route of R2 and find that the route entry received R4 has the BGP.originator_id and BGP.cluster_list attributes, but the entry received from R1 does not have this attribute. why? Thank you very much for your help!! thanks!! The route entries viewed by R2 are as follows: bird> show route protocol bgp_pa_r2 all 1007-121.52.236.16/32 1008- Type: BGP unicast univ 1012- BGP.origin: IGP BGP.as_path: BGP.next_hop: 192.168.2.4 BGP.local_pref: 100 * BGP.originator_id: 192.168.2.4* * BGP.cluster_list: 1.1.1.1* 1007-116.211.98.20/32 1008- Type: BGP unicast univ 1012- BGP.origin: IGP BGP.as_path: BGP.next_hop: 192.168.2.4 BGP.local_pref: 100 * BGP.originator_id: 192.168.2.4* * BGP.cluster_list: 1.1.1.1* 1007-120.26.0.0/18 1008- Type: BGP unicast univ 1012- BGP.origin: IGP BGP.as_path: 100 BGP.next_hop: 192.168.1.1 BGP.local_pref: 5 1007-122.72.90.78/32 1008- Type: BGP unicast univ 1012- BGP.origin: IGP BGP.as_path: 100 BGP.next_hop: 192.168.1.1 BGP.local_pref: 5

2 1

[PATCH] babel: Ignore Hello TLVs with unicast flag set
by Toke Høiland-Jørgensen 31 Oct '17

31 Oct '17

RFC6126bis introduces a flags field for the Hello TLV, and adds a unicast flag that is used to signify that a hello was sent as unicast. This adds parsing of the flags field and ignores such unicast hellos, which preserves compatibility until we can add a proper implementation of the unicast hello mechanism. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index efe05678..597ed60d 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -40,7 +40,7 @@ struct babel_tlv_ack { struct babel_tlv_hello { u8 type; u8 length; - u16 reserved; + u16 flags; u16 seqno; u16 interval; } PACKED; @@ -104,8 +104,9 @@ struct babel_tlv_seqno_request { } PACKED; -#define BABEL_FLAG_DEF_PREFIX 0x80 -#define BABEL_FLAG_ROUTER_ID 0x40 +#define BABEL_FLAG_DEF_PREFIX 0x80 +#define BABEL_FLAG_ROUTER_ID 0x40 +#define BABEL_FLAG_UNICAST_HELLO 0x8000 struct babel_parse_state { @@ -340,6 +341,12 @@ babel_read_hello(struct babel_tlv *hdr, union babel_msg *m, { struct babel_tlv_hello *tlv = (void *) hdr; struct babel_msg_hello *msg = &m->hello; + u16 flags; + + /* We currently don't support unicast Hello */ + flags = get_u16(&tlv->flags); + if (flags & BABEL_FLAG_UNICAST_HELLO) + return PARSE_IGNORE; msg->type = BABEL_TLV_HELLO; msg->seqno = get_u16(&tlv->seqno); -- 2.14.2

2 2