- dev - lists.frrouting.org

FRR 7.5.1 oficial debian package
by ivaylo 19 May '21

19 May '21

Hello, First thanks to of you about the work around FRR softaware ! After clean install (or upgrade from 7.3.1) on Debian 9/10 the oficial package of frr 7.5.1 (from frr-stable debian repository), I observe broken config file after edit via CLI (telnet or when starting bgpd with -t ) in route-map sections For example: bgpd# show running-config .... ! route-map IPV4-AAA-OUT permit 10 match as-path localas set as-path prepend 60349 60349 match ip address prefix-list v4_prep_nets route-map IPV4-AAA-OUT permit 60 match community c_CLS_2_AAA set as-path prepend 60349 ! .... First there is no comment between the two rules in the route map, second the match clauses are separate with set. Example2: extrestr# conf t extrestr(config)# route-ma extrestr(config)# route-map AAA1 permi extrestr(config)# route-map AAA1 permit 10 extrestr(config-route-map)# match as-path our_asn extrestr(config-route-map)# match community c_gws extrestr(config-route-map)# exit extrestr(config)# route-map AAA1 deny 5 extrestr(config-route-map)# show running-config ... route-map RS-OUT permit 10 match as-path our_asn set ipv6 next-hop global 2a09:a947:bac:252::133 set ipv6 next-hop prefer-global set ip next-hop 185.200.158.133 set ip next-hop 185.200.158.133 route-map AAA1 permit 10 match as-path our_asn match community c_gws ! route-map AAA1 deny 5 ... Commenting lines (!) are set strange (maybe random?) the. The rules in the route-map are not in the right sequence (I think they are add one after another without sequence). The other problem set clause of ip next-hop they are always added two times .... extrestr# conf t extrestr(config)# route-map RS-OUT permit 10 extrestr(config-route-map)# no set ip next-hop 185.200.158.133 extrestr(config-route-map)# show running-config .... route-map RS-OUT permit 10 match as-path our_asn set ipv6 next-hop global 2a09:a947:bac:252::133 set ipv6 next-hop prefer-global ! route-map AAA1 permit 10 match as-path our_asn match community c_gws ! route-map AAA1 deny 5 .... extrestr(config-route-map)# set ip next-hop 185.200.158.133 extrestr(config-route-map)# show running-config .... ! route-map RS-OUT permit 10 match as-path our_asn set ipv6 next-hop global 2a09:a947:bac:252::133 set ipv6 next-hop prefer-global set ip next-hop 185.200.158.133 set ip next-hop 185.200.158.133 route-map AAA1 permit 10 match as-path our_asn match community c_gws ! route-map AAA1 deny 5 ! When the bgpd.conf is writen it is same as is shown with running-config command, show route-map XXXX shows right sequence of the chains, so maybe it works at all, but I am not sure what will be with complicated route maps rules when you jump from one to another RM and back. Also with larger config files it is night mare to trace route map sequence. After build my own (package for debian10) stable 7.5 , stable 7.4 , stable 7.3 I see the problems starts from 7.4 and up. I have and version 7.6-dev build on Slackware and same is there. Currnet stable/7.3 branch and old debian 7.3.1 package (from frr repository) are ok. Current master 7.7 is totaly unusable on debian 10 because libyang2 (maybe the CI package of libyang 2 is broken not sure) but the cli (via telnet) is very slow (laggy, hard to write even a command) and bgpd connects and disconnects constantly. If you need debug or test more let me know. Ivaylo Josifov VarnaIX / Varteh LTD +359 52 969393 Varna, Bulgaria

1 0

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

13 May '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1504731: Control flow issues (DEADCODE) /pathd/path_cli.c: 425 in segment_list_has_prefix() ________________________________________________________________________________________________________ *** CID 1504731: Control flow issues (DEADCODE) /pathd/path_cli.c: 425 in segment_list_has_prefix() 419 } 420 inet_ntop(AF_INET6, &prefix_cli.u.prefix6, buf_prefix, 421 sizeof(buf_prefix)); 422 pre_ipaddr.ipa_type = IPADDR_V6; 423 pre_ipaddr.ip._v6_addr = prefix_cli.u.prefix6; 424 } else { >>> CID 1504731: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 2;". 425 return CMD_ERR_NO_MATCH; 426 } 427 snprintf(xpath, XPATH_MAXLEN, "./segment[index='%s']/nai/local-address", 428 index_str); 429 nb_cli_enqueue_change(vty, xpath, NB_OP_MODIFY, buf_prefix); 430 snprintf(xpath, XPATH_MAXLEN, ** CID 1504730: Control flow issues (DEADCODE) /pathd/path_cli.c: 532 in srte_segment_list_segment_magic() ________________________________________________________________________________________________________ *** CID 1504730: Control flow issues (DEADCODE) /pathd/path_cli.c: 532 in srte_segment_list_segment_magic() 526 } else { 527 segment_list_has_prefix( 528 vty, xpath, index, index_str, prefix_ipv4, 529 prefix_ipv4_str, prefix_ipv6, prefix_ipv6_str, has_algo, 530 algo, algo_str, has_iface_id, iface_id, iface_id_str); 531 if (status != CMD_SUCCESS) >>> CID 1504730: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return status;". 532 return status; 533 } 534 535 return nb_cli_apply_changes(vty, NULL); 536 } 537 ** CID 1504729: Control flow issues (DEADCODE) /pathd/path_cli.c: 355 in segment_list_has_src_dst() ________________________________________________________________________________________________________ *** CID 1504729: Control flow issues (DEADCODE) /pathd/path_cli.c: 355 in segment_list_has_src_dst() 349 node_src_id = adj_src_ipv4_str; 350 } else if (adj_src_ipv6_str != NULL) { 351 nb_cli_enqueue_change(vty, xpath, NB_OP_MODIFY, 352 "ipv6_adjacency"); 353 node_src_id = adj_src_ipv6_str; 354 } else { >>> CID 1504729: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 2;". 355 return CMD_ERR_NO_MATCH; 356 } 357 /* addresses */ 358 snprintf(xpath, XPATH_MAXLEN, "./segment[index='%s']/nai/local-address", 359 index_str); 360 nb_cli_enqueue_change(vty, xpath, NB_OP_MODIFY, node_src_id); ** CID 1504728: Null pointer dereferences (REVERSE_INULL) /pathd/pathd.c: 203 in srte_segment_entry_set_nai() ________________________________________________________________________________________________________ *** CID 1504728: Null pointer dereferences (REVERSE_INULL) /pathd/pathd.c: 203 in srte_segment_entry_set_nai() 197 { 198 int32_t status = 0; 199 struct prefix pre = {0}; 200 segment->nai_type = type; 201 memcpy(&segment->nai_local_addr, local_ip, sizeof(struct ipaddr)); 202 >>> CID 1504728: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "segment" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 203 if (!segment || !local_ip || !remote_ip) 204 return 1; 205 206 switch (type) { 207 case SRTE_SEGMENT_NAI_TYPE_IPV4_NODE: 208 case SRTE_SEGMENT_NAI_TYPE_IPV6_NODE: ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

05 May '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 1504610: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1504610: Uninitialized variables (UNINIT) /zebra/connected.c: 437 in connected_down() 431 * one. 432 */ 433 for (ALL_LIST_ELEMENTS_RO(ifp->connected, cnode, c)) { 434 struct prefix cp; 435 436 PREFIX_COPY(&cp, CONNECTED_PREFIX(c)); >>> CID 1504610: Uninitialized variables (UNINIT) >>> Using uninitialized value "cp.family" when calling "apply_mask". 437 apply_mask(&cp); 438 439 if (prefix_same(&p, &cp)) 440 count++; 441 442 if (count >= 2) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

04 May '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 1504585: Insecure data handling (TAINTED_SCALAR) /ospfclient/ospf_apiclient.c: 334 in ospf_apiclient_send_request() ________________________________________________________________________________________________________ *** CID 1504585: Insecure data handling (TAINTED_SCALAR) /ospfclient/ospf_apiclient.c: 334 in ospf_apiclient_send_request() 328 /* Wait for reply */ /* NB: New "msg" is allocated by "msg_read()". */ 329 msg = msg_read(oclient->fd_sync); 330 if (!msg) 331 return -1; 332 333 assert(msg->hdr.msgtype == MSG_REPLY); >>> CID 1504585: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "reqseq" as a loop boundary. 334 assert(ntohl(msg->hdr.msgseq) == reqseq); 335 336 msgreply = (struct msg_reply *)STREAM_DATA(msg->s); 337 rc = msgreply->errcode; 338 msg_free(msg); 339 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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 15 Apr '21

15 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