- dev - lists.frrouting.org

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

22 Nov '17

Dear Developer of FRR, 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/dr aft-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 FRR. 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

BGP RPKI available in FRouting!
by Donald Sharp 17 Nov '17

17 Nov '17

All - I'd like to announce the arrival of BGP RPKI (RFC 6810) to FRRouting. I'd like to thank Marcel for taking the time to submit this code. To use this code, ensure that you have installed a new dependant library rtrlib available here: http://rtrlib.realmv6.org/ And configure FRR with `--enable-rpki` when compiling it. Thanks! donald

2 1

Next weeks Technical meeting
by Donald Sharp 16 Nov '17

16 Nov '17

I'm going to cancel next weeks Technical Meeting due to it being Thanksgiving Week in America. thanks! donald

1 0

Security Issue CVE-2017-15865
by Donald Sharp 16 Nov '17

16 Nov '17

All - Security Issue CVE-2017-15865: `A Vulnerability exists in the BGP daemon of FRR where a malformed BGP Update packet can leak information from the BGP daemon and cause a denial of service by crashing the daemon` Has been fixed in releases 3.0.2 and 2.0.2 and the master branch of FRR. For further information: https://frrouting.org/community/security/cve-2017-15865.html As always the source is available at https://github.com/frrouting/frr Release Information can be found here: https://github.com/FRRouting/frr/releases thanks! donald

1 0

Package for Debina7
by André Carlim 16 Nov '17

16 Nov '17

Hi! Sorry if I am not posting the right list, however, I need to compile the installable package fo Debian 7, I have a legacy Debian 7 farm and I would like to test the Frr and who knows my routing problems stop, thank you for the attention. -- Best Regards, André Carlim StubNetwork

2 1

DEFUN different from Quagga
by Mostafa Salari 14 Nov '17

14 Nov '17

Hi I figured out that the syntax of DEFUN commands in FRR 3 is different from Quagga. I found this problem when i saw my old (Quagga based) code raise errors when copied in FRR! For example, it seems that *() *has no meaning or different interpretation! As another example i think *argv*s are counted for all words in the command not only variables! am i right? So i have 2 questions 1. Where can i find the differences of DEFUN in FRR? 2. A trouble!!! When i input the *argv*s in vtysh in a different order, I will take different argv values!!!!!!! For example: i have in DEFUN: "snmp-server group NAME <v1|v2c> {read WORD|write WORD|notify WORD|context WORD}" Now, in vtysh, if the user enters: Router# snmp-server group g1 v1 write view1 read view2 My DEFUN considers argv[5] as view1 and argv[7] as view2 and if user enters: Router# snmp-server group g1 v1 read view2 write view1 My DEFUN considers argv[7] as view1 and argv[5] as view2 While in my DEFUN, i expect that snmp write view always to be (e.g.) argv[5] Please help. Thanks

2 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 14 Nov '17

14 Nov '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1461579: Resource leaks (RESOURCE_LEAK) /zebra/zebra_ptm.c: 949 in zebra_ptm_bfd_dst_deregister() ________________________________________________________________________________________________________ *** CID 1461579: Resource leaks (RESOURCE_LEAK) /zebra/zebra_ptm.c: 949 in zebra_ptm_bfd_dst_deregister() 943 zlog_debug("%s: Sent message (%d) %s", __func__, data_len, 944 ptm_cb.out_data); 945 946 zebra_ptm_send_message(ptm_cb.out_data, data_len); 947 948 stream_failure: >>> CID 1461579: Resource leaks (RESOURCE_LEAK) >>> Variable "out_ctxt" going out of scope leaks the storage it points to. 949 return 0; 950 } 951 952 /* BFD client register */ 953 int zebra_ptm_bfd_client_register(struct zserv *client, 954 u_short length) ** CID 1461578: Resource leaks (RESOURCE_LEAK) /zebra/zebra_ptm.c: 820 in zebra_ptm_bfd_dst_register() ________________________________________________________________________________________________________ *** CID 1461578: Resource leaks (RESOURCE_LEAK) /zebra/zebra_ptm.c: 820 in zebra_ptm_bfd_dst_register() 814 if (IS_ZEBRA_DEBUG_SEND) 815 zlog_debug("%s: Sent message (%d) %s", __func__, data_len, 816 ptm_cb.out_data); 817 zebra_ptm_send_message(ptm_cb.out_data, data_len); 818 819 stream_failure: >>> CID 1461578: Resource leaks (RESOURCE_LEAK) >>> Variable "out_ctxt" going out of scope leaks the storage it points to. 820 return 0; 821 } 822 823 /* BFD peer/dst deregister */ 824 int zebra_ptm_bfd_dst_deregister(struct zserv *client, u_short length, 825 struct zebra_vrf *zvrf) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Open source routing @ ietf meetup
by Lou Berger 13 Nov '17

13 Nov '17

Hi, Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "Hullet Room" on *Wednesday* during lunch (noon). There is no agenda or slides -- feel free to come with a topic you'd like to discuss or info you want to share... Cheers, Lou

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 12 Nov '17

12 Nov '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1461328: Security best practices violations (TOCTOU) /lib/command.c: 1668 in file_write_config() ________________________________________________________________________________________________________ *** CID 1461328: Security best practices violations (TOCTOU) /lib/command.c: 1668 in file_write_config() 1662 if (errno != ENOENT) { 1663 vty_out(vty, 1664 "Can't unlink backup configuration file %s.\n", 1665 config_file_sav); 1666 goto finished; 1667 } >>> CID 1461328: Security best practices violations (TOCTOU) >>> Calling function "link" that uses "config_file" after a check function. This can cause a time-of-check, time-of-use race condition. 1668 if (link(config_file, config_file_sav) != 0) { 1669 vty_out(vty, 1670 "Can't backup old configuration file %s.\n", 1671 config_file_sav); 1672 goto finished; 1673 } ** CID 1461327: Security best practices violations (SECURE_TEMP) /lib/command.c: 1636 in file_write_config() ________________________________________________________________________________________________________ *** CID 1461327: Security best practices violations (SECURE_TEMP) /lib/command.c: 1636 in file_write_config() 1630 1631 1632 config_file_tmp = XMALLOC(MTYPE_TMP, strlen(config_file) + 8); 1633 sprintf(config_file_tmp, "%s.XXXXXX", config_file); 1634 1635 /* Open file to configuration write. */ >>> CID 1461327: Security best practices violations (SECURE_TEMP) >>> Calling "mkstemp" without securely setting umask first. 1636 fd = mkstemp(config_file_tmp); 1637 if (fd < 0) { 1638 vty_out(vty, "Can't open configuration file %s.\n", 1639 config_file_tmp); 1640 goto finished; 1641 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Results of FRR TSC 2017-10 Voting...
by Alistair Woodman 10 Nov '17

10 Nov '17

All, Here are the results of the FRR TSC vote. (sorry for the delay, I have been in transit) Eligible to vote: 18 Actually voted: 16 Turnout: 89% The following nominees were elected to the TSC: . Philippe Guibert . Donald Sharp . Renato Westphal . Russ White . Martin Winter . Quentin Young The following nominees were not: . Lou Berger . David Lamparter I'd like to thank everyone for participating in the process, and look forward to a repeat in 2018-10. /a

1 0