August 2020 - dev - lists.frrouting.org

Notice: Telco call for 16:00 CET; 07:00 PT (tomorrow) Wednesday 5th is canceled
by Alistair Woodman 05 Aug '20

05 Aug '20

due to vacation time. (As discussed on the FRR weekly today) /a

1 0

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

04 Aug '20

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. 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 1 of 1 defect(s) ** CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) ________________________________________________________________________________________________________ *** CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) /zebra/zebra_rib.c: 2162 in rib_process_dplane_notify() 2156 2157 done: 2158 if (rn) 2159 route_unlock_node(rn); 2160 2161 /* Return context to dataplane module */ >>> CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) >>> Calling "dplane_ctx_fini" dereferences freed pointer "ctx". 2162 dplane_ctx_fini(&ctx); 2163 } 2164 2165 static void process_subq_nhg(struct listnode *lnode) 2166 { 2167 struct nhg_ctx *ctx = NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Pottential bugs RPKI States at FRR 7.3.1 (debian packages)
by Dewangga Alam 04 Aug '20

04 Aug '20

Hello! I am new at FRR, and trying to found a reference that indicated (bugs?) or miss configuration at version 7.3.1 using debian buster packages from deb.frrouting.org (http://deb.frrouting.org) Here’s our configuration: https://pastebin.com/xKE3AJij Already adjusted bgpd using rpki options, and when I restart frr service, the tagging was not working. > vtysh > sh bgp ipv4 103.241.24.0 BGP routing table entry for 103.241.24.0/24 Paths: (3 available, best #3, table default) Not advertised to any peer 38515 58820 103.28.75.36 from 103.28.75.0 (103.28.75.0) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.255 (103.28.74.255) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.129 (103.28.74.127) Origin IGP, localpref 5100, valid, internal, best (Router ID) Community: 38515:58820 Last update: Sat Aug 1 10:54:34 2020 The rpki states aren’t show, and when I paste the route-map configuration into vtysh, the loc-pref tag are valids and working. The full command pasted here: https://pastebin.com/n3VY4gNm Any hints to fix this issue ? Any helps are appreciated. Thanks in advance! Many thanks. -- Sent from Canary (https://canarymail.io)

2 1

zebra nexthop-tracking/reachability questions
by Mark Stapp 03 Aug '20

03 Aug '20

I've got a couple of questions about nexthop-tracking in zebra - these are a bit down in the details, but I thought I'd ask if any of the folks on the list have some insight... 1. the nht code makes a copy (mostly) of the route_entry that satisfies some client registration. the code copies all of the nexthops - even the recursive ones, even ones that are not ACTIVE. the code that sends nexthops to the nht client(s) has an rnh_nexthop_valid() function that is pretty strict about what will actually be sent. would it be reasonable to have the nht code capture only a list of the nexthops that are actually valid, that actually will be sent to the clients? 2. the show command for nht, ‘sho ip nht’, only shows the top-level nexthops - not the actual installed nexthops that, again, will be sent to the clients. would it be ok to change that, to try to have the show command show what will actually be sent to clients? 3. the route-map filtering in there also operates only on the top-level nexthops, not the exact ones that are "valid" and will be sent to clients. is that intentional, or should the route-map get a shot at the nexthops that the nht code would try to send? Thanks, Mark

1 0