April 2021 - dev - lists.frrouting.org

PATHD installation question
by Борис Хасанов 29 Apr '21

29 Apr '21

2 2

Annulé : FRR Telco meeting
by olivier.dugeon＠orange.com 28 Apr '21

28 Apr '21

Quand : mercredi 28 avril 2021 16:00-17:00. (UTC+01:00) Bruxelles, Copenhague, Madrid, Paris Où : BlueJean https://bluejeans.com/377688464 *~*~*~*~*~*~*~*~*~* Hi all, This is the invite for the regular be-weekly Telco's meeting for 2021. NOTE: THE MEETING ID CHANGE. Please use https://bluejeans.com/377688464 for the next Telco meetings Regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Logging changes for __FUNC__, errno and debug guards
by David Lamparter 21 Apr '21

21 Apr '21

Hi again all, while the previous logging changes I've been working on have all been non-intrusive - i.e. no touching any zlog_* or flog_* lines - there are a few things I'd like to do at some point that do touch a lot of the zlog_* lines: - "factor out" strerror() / errno printing. This is why "flog_err_sys" exists, it currently does the exact same thing as "flog_err" but the idea is that "flog_err_sys" is used when there's some system error and errno is valid. The logging code would print strerror() automatically without this being a parameter. And we can put errno into a keyword, like systemd-journald has with "ERRNO=". flog_err_sys is already being used in quite a bit of the code, but this would need some double checking, and the strerror() argument would be removed. - "factor out" the __FUNC__ argument used on a lot of debug calls. The logging code can prefix *all* debug messages with the calling function name, without this being an extra parameter to the call. Also, RFC5424 and journald log targets can include the file/line/func information in the message metadata. - the debug guards could use a dump of massage units too - assimilating the if() into the macro and getting rid of the indentation level. We already have DEBUG*() in lib/debug.h plus debugf() in nhrpd/debug.h & babeld/util.h. These 3 should be unified and zlog_debug() marked deprecated (i.e. warning on any unguarded debugs) A particular consideration for this last item is the "parametrized debugs", e.g. "debug bgp neighbor-events <A.B.C.D|X:X::X:X|WORD>" A lot of this stuff can be done with coccinelle, but it'll be a large and annoying change, so I'd like to discuss *what* and *when* to do it here. (For starters, the 2nd and 3rd thing should happen at the same time since it's affecting most/all zlog_debug() calls.) None of this is "urgent" and a lot could also be done in smaller steps, e.g. converting babeld & nhrpd first. I'd also make these non-breaking changes as much as possible, i.e. have old & new forms both work for some period of time. Opinions & Comments? -David

2 1

DockerHub FRR images cleanup warning
by Quentin Young 14 Apr '21

14 Apr '21

Hi operators, For those of you who use our Docker images (https://hub.docker.com/r/frrouting/frr) you've probably noticed we have a bunch of messy tags on that repo. I'm planning on cleaning this up in a little while to delete unnecessary / unintentional tags. Tags corresponding to releases are named vX.Y.Z. So for example, the image with 7.5.1 is "frrouting/frr:v7.5.1". These won't be going anywhere. Neither will the "latest" tag - this tag is an automatic build off of our Git tree. (This also means you shouldn't be relying on it and should always be specifying a release tag, by the way). I'm going to delete the rest of the tags as they don't correspond to anything in particular. Specifically, I plan on deleting the following tags: frr-7.5.1 multiarch frr-7.3 base_7.3 I'm planning on deleting these tomorrow at 5pm EST. I see that frr-7.3 and frr-7.5.1 have been pulled recently. If you're pulling these tags please use tags v7.3.1 and v7.5.1 instead. Quentin

1 1

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

14 Apr '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1503803: Error handling issues (NEGATIVE_RETURNS) /nhrpd/linux.c: 75 in os_sendmsg() ________________________________________________________________________________________________________ *** CID 1503803: Error handling issues (NEGATIVE_RETURNS) /nhrpd/linux.c: 75 in os_sendmsg() 69 lladdr.sll_family = AF_PACKET; 70 lladdr.sll_protocol = htons(protocol); 71 lladdr.sll_ifindex = ifindex; 72 lladdr.sll_halen = addrlen; 73 memcpy(lladdr.sll_addr, addr, addrlen); 74 >>> CID 1503803: Error handling issues (NEGATIVE_RETURNS) >>> "os_socket()" is passed to a parameter that cannot be negative. 75 status = sendmsg(os_socket(), &msg, 0); 76 if (status < 0) 77 return -errno; 78 79 return status; 80 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

FlowSpec issue
by Birincsik Gábor 11 Apr '21

11 Apr '21

Hey Guy, I would need help. I got the following error message when I receive a flowspec update in our test env. I did not find solution for this. The iptables and ipset both are reachable for frr user. We are planning to implement flowspec in our system, but having trouble with it. Apr 10 20:24:59 test bgpd[399]: bgp_update_receive: rcvd End-of-RIB for IPv4 Flowspec from 10.1.0.13 in vrf default Apr 10 20:24:59 test bgpd[399]: BGP: adding FS PBR from 213.181.201.6/32 to 185.219.48.60/32, Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_ipset_match: name match0x5593c4adbfe0 type 1 1, ID 6 Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_ipset_entry_match: name match0x5593c4adbfe0 6 1, ID 6 Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_iptable: name match0x5593c4adbfe0 type 1 mark 0 1, ID 6 *Apr 10 20:24:59 test bgpd[399]: ipset_notify_owner: Received IPSET_FAIL_INSTALL** **Apr 10 20:24:59 test bgpd[399]: ipset_entry_notify_owner: Received IPSET_ENTRY_FAIL_INSTALL** **Apr 10 20:24:59 test bgpd[399]: iptable_notify_owner: Received IPTABLE_FAIL_INSTALL* I really hope you can help me, Gábor Birincsik CTO JZT Informatikai Kft

1 0

frr debian repo and frr-7.5.1
by Jan VECEK 01 Apr '21

01 Apr '21

Hello, please will be update FRR Debian repo https://deb.frrouting.org/ last 7.5.1 - https://github.com/FRRouting/frr/releases/tag/frr-7.5.1 ? Thanks Best, Jan

4 4

printfrr bikeshed color for [iana_][s]afi_t
by David Lamparter 01 Apr '21

01 Apr '21

Hi all, as I'm currently worming my way through the printfrr code, I'd like to add printfrr specifiers for afi_t/safi_t/iana_afi_t/iana_safi_t. However, unlike most other extension specifiers, there's no "obvious good" extension specifier for these, so here's a thread asking for suggestions. (extension specifier = "%pFX" & co.) For afi_t/safi_t/iana_afi_t/iana_safi_t the considerations are: - must start with "%d" or "%i" (if that eases a mnemonic, like with "%pFX", this might be a choice, but %i is probably better) - must then have one uppercase character, followed by one or more uppercase characters or digits, i.e. %i[A-Z][A-Z0-9][A-Z0-9]* - must not overlap with other extensions on a shorter length (i.e. no "%iAF" + "%iAFI") - this sequence must be different for all 4 AFI types for the typecheck to work correctly - should be short, the longest specifier currently existing is %pSG4 for "struct prefix_sg *", i.e. 3 characters after the %_ - needs to be not misunderstood for AF_INET type constants, so %iAF/%dAF is probably a bad choice - needs to be as understandable/obvious as possible Not adding an extension specifier for (some of) these types is also an option. Ultimatively the question is what makes the code the "nicest." The best I can come up with is: - %iFA (afi_t) - "F)rr A)fi" - %iFS (safi_t) - "F)rr S)afi" - %iIA (iana_afi_t) - "I)ana A)fi" - slight overlap with %pIA - %iIS (iana_safi_t) - "I)ana S)afi" But maybe something longer is better? Input requested! -David

2 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 01 Apr '21

01 Apr '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 5 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 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 5 of 5 defect(s) ** CID 1503597: Insecure data handling (TAINTED_SCALAR) /ospfd/ospf_te.c: 2464 in ospf_te_parse_ri() ________________________________________________________________________________________________________ *** CID 1503597: Insecure data handling (TAINTED_SCALAR) /ospfd/ospf_te.c: 2464 in ospf_te_parse_ri() 2458 2459 ote_debug(" |- Process Router Information LSA %pI4 for Vertex %pI4", 2460 &lsa->data->id, &node->router_id); 2461 2462 /* Initialize TLV browsing */ 2463 len = ntohs(lsah->length) - OSPF_LSA_HEADER_SIZE; >>> CID 1503597: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 2464 for (tlvh = TLV_HDR_TOP(lsah); sum < len; tlvh = TLV_HDR_NEXT(tlvh)) { 2465 struct ri_sr_tlv_sr_algorithm *algo; 2466 struct ri_sr_tlv_sid_label_range *range; 2467 struct ri_sr_tlv_node_msd *msd; 2468 uint32_t size, lower; 2469 ** CID 1503596: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 2580 in lib_route_map_entry_set_action_rmap_set_action_extcommunity_lb_finish() ________________________________________________________________________________________________________ *** CID 1503596: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 2580 in lib_route_map_entry_set_action_rmap_set_action_extcommunity_lb_finish() 2574 snprintf(str, sizeof(str), "%s", "num-multipaths"); 2575 } 2576 2577 if (yang_dnode_get_bool(args->dnode, "./two-octet-as-specific")) 2578 strlcat(str, " non-transitive", sizeof(str)); 2579 >>> CID 1503596: Error handling issues (CHECKED_RETURN) >>> Calling "generic_set_add" without checking return value (as is done elsewhere 27 out of 29 times). 2580 generic_set_add(rhc->rhc_rmi, 2581 "extcommunity bandwidth", str, 2582 args->errmsg, args->errmsg_len); 2583 } 2584 2585 /* ** CID 1503595: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 2401 in lib_route_map_entry_set_action_rmap_set_action_aggregator_finish() ________________________________________________________________________________________________________ *** CID 1503595: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 2401 in lib_route_map_entry_set_action_rmap_set_action_aggregator_finish() 2395 2396 /* Set destroy information. */ 2397 rhc->rhc_shook = generic_set_delete; 2398 rhc->rhc_rule = "aggregator as"; 2399 rhc->rhc_event = RMAP_EVENT_SET_DELETED; 2400 >>> CID 1503595: Error handling issues (CHECKED_RETURN) >>> Calling "generic_set_add" without checking return value (as is done elsewhere 27 out of 29 times). 2401 generic_set_add(rhc->rhc_rmi, rhc->rhc_rule, argstr, 2402 args->errmsg, args->errmsg_len); 2403 XFREE(MTYPE_ROUTE_MAP_COMPILED, argstr); 2404 } 2405 /* 2406 * XPath: ** CID 1503594: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 1017 in lib_route_map_entry_match_condition_rmap_match_condition_comm_list_finish() ________________________________________________________________________________________________________ *** CID 1503594: Error handling issues (CHECKED_RETURN) /bgpd/bgp_routemap_nb_config.c: 1017 in lib_route_map_entry_match_condition_rmap_match_condition_comm_list_finish() 1011 } else { 1012 rhc->rhc_rule = "extcommunity"; 1013 event = RMAP_EVENT_ECLIST_ADDED; 1014 rhc->rhc_event = RMAP_EVENT_ECLIST_DELETED; 1015 } 1016 >>> CID 1503594: Error handling issues (CHECKED_RETURN) >>> Calling "bgp_route_match_add" without checking return value (as is done elsewhere 20 out of 21 times). 1017 bgp_route_match_add(rhc->rhc_rmi, rhc->rhc_rule, argstr, event, 1018 args->errmsg, args->errmsg_len); 1019 1020 if (argstr != value) 1021 XFREE(MTYPE_ROUTE_MAP_COMPILED, argstr); 1022 } ** CID 1496618: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1496618: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn_mh.c: 949 in bgp_evpn_type1_route_update() 943 attr_new = pi->attr; 944 945 /* Perform route selection; 946 * this is just to set the flags correctly as local route in 947 * the ES always wins. 948 */ >>> CID 1496618: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "vpn" to "evpn_route_select_install", which dereferences it. 949 evpn_route_select_install(bgp, vpn, dest); 950 bgp_dest_unlock_node(dest); 951 952 /* If this is a new route or some attribute has changed, export the 953 * route to the global table. The route will be advertised to peers 954 * from there. Note that this table is a 2-level tree (RD-level + ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0