- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 11 Jan '22

11 Jan '22

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 1510738: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1510738: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_vty.c: 4243 in bgp_shutdown_msg_magic() 4237 if (msgstr && strlen(msgstr) > BGP_ADMIN_SHUTDOWN_MSG_LEN) { 4238 vty_out(vty, "%% Shutdown message size exceeded %d\n", 4239 BGP_ADMIN_SHUTDOWN_MSG_LEN); 4240 return CMD_WARNING_CONFIG_FAILED; 4241 } 4242 >>> CID 1510738: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "msgstr" to "bgp_shutdown_enable", which dereferences it. 4243 bgp_shutdown_enable(bgp, msgstr); 4244 XFREE(MTYPE_TMP, msgstr); 4245 4246 return CMD_SUCCESS; 4247 } 4248 ** CID 1510737: Null pointer dereferences (REVERSE_INULL) /bgpd/bgpd.c: 4344 in bgp_shutdown_enable() ________________________________________________________________________________________________________ *** CID 1510737: Null pointer dereferences (REVERSE_INULL) /bgpd/bgpd.c: 4344 in bgp_shutdown_enable() 4338 /* continue, if peer is already in administrative shutdown. */ 4339 if (CHECK_FLAG(peer->flags, PEER_FLAG_SHUTDOWN)) 4340 continue; 4341 4342 /* send a RFC 4486 notification message if necessary */ 4343 if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->status)) { >>> CID 1510737: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 4344 if (msg) 4345 bgp_notify_send_with_data( 4346 peer, BGP_NOTIFY_CEASE, 4347 BGP_NOTIFY_CEASE_ADMIN_SHUTDOWN, data, 4348 datalen + 1); 4349 else ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Eesppsspdlpppllapllkk
by Karuppiah, Jeyachandran 10 Jan '22

10 Jan '22

Jve Get Outlook for Android<https://aka.ms/AAb9ysg>

1 0

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

22 Dec '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 1510459: Null pointer dereferences (NULL_RETURNS) /ospf6d/ospf6_abr.c: 454 in ospf6_abr_originate_summary_to_area() ________________________________________________________________________________________________________ *** CID 1510459: Null pointer dereferences (NULL_RETURNS) /ospf6d/ospf6_abr.c: 454 in ospf6_abr_originate_summary_to_area() 448 return 0; 449 } 450 451 /* Do not generate if area is NSSA */ 452 route_area = 453 ospf6_area_lookup(route->path.area_id, area->ospf6); >>> CID 1510459: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "route_area", which is known to be "NULL". 454 if (IS_AREA_NSSA(route_area)) { 455 if (is_debug) 456 zlog_debug( 457 "%s: The route comes from NSSA area, skip", 458 __func__); 459 ospf6_abr_delete_route(summary, summary_table, old); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Discussion about the Future of Telco Meeting
by olivier.dugeon＠orange.com 21 Dec '21

21 Dec '21

Hi all, This is the invit to discuss the future of the Telco Meeting following the thread on the FRR dev list. 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

OSPF/LDP in a mesh of tunnels
by Eivind Naess 11 Dec '21

11 Dec '21

I have been reading up on MPLS and been doing some experiments. Topology I have the following topology, where the PEs are members of a network interconnected with tunnels (i.e. ssh -oTunnel=Ethernet -w any:any <host>) on the 192.168.2.0/24 network running OSPF and LDP enabled. The CEs connects to the cloud of PEs and is terminated to a TAP adapter with IP-addresses in the 172.20.2.0/24 domain. The PEs uses OSPF to distribute the routes on both domains, and each tap interface is capable of forwarding mpls datagrams. In addition, each of the PEs have a dummy0 interface configured with the ip-address of the router-id (i.e. PE1 10.0.0.1, PE2: 10.0.0.2).All CEs/PEs are Ubuntu Server 21.10 VMs. +---+---+ | CE1 | +---+---+ tap0: 172.20.2.2/32 | | tap1: 172.20.2.1/32 +---+---+ | PE1 | +---+---+ tap0: 192.168.2.1 | | tap0: 192.168.2.2 +---+---+ | PE2 | +---+---+ tap1: 172.20.2.3/32 tap2: 172.20.2.5/32 / \ / \ tap0: 172.20.2.4/32 tap0: 172.20.2.6/32 +---+---+ +---+---+ | CE2 | | CE3 | +---+---+ +---+---+ OSPF configuration PE1, for PE2 change router-id with 10.0.0.2: ``` interface tap0 ip ospf network point-to-point router ospf ospf router-id 10.0.0.1 redistribute static redistribute connected network 172.20.2.0/24 area 0 network 192.168.2.0/24 area 0 ``` Then the ldpd configuration on PE1, for PE2 change router-id and transport-address with 10.0.0.2: ``` mpls ldp router-id 10.0.0.1 address-family ipv4 discovery transport-address 10.0.0.1 interface tap0 ``` I am able to create MPLS routes and forward these between the nodes. However, when adding the address to e.g. tap2 for PE2: "ip route add 172.20.2.5/32 peer 172.20.2.6 dev tap2"; you'll get the following routes installed on PE1: 172.20.2.3 nhid 20 via 192.168.2.2 dev tap0 proto ospf metric 20 onlink 172.20.2.4 nhid 20 via 192.168.2.2 dev tap0 proto ospf metric 20 onlink 172.20.2.5 nhid 20 via 192.168.2.2 dev tap0 proto ospf metric 20 onlink 172.20.2.6 nhid 20 via 192.168.2.2 dev tap0 proto ospf metric 20 onlink Note that the entries for 172.20.2.4 and .6 are not there if OSPF if you remove "distribute connected" routes or avoid using "peer" clause when adding address to adapter, e.g. "ip addr add 172.20.2.2/32 peer 172.20.2.1 dev tap1". What I want to be able to do here is to emulate a MPLS network where a datagram is being decapsulated and forwarded on a particular Tap device. Say I add a route on PE1 like this "ip route add 172.20.2.6/32 encap mpls 33 via inet 192.168.2.2 dev tap0", and then on PE2 add a MPLS route "ip -f mpls 33 via 172.20.2.6 dev tap2". I can now see ICMP echo request from CE1 get encapsulated and forwarded on PE1/tap0 and correctly decapsulated on PE2 before it is forwarded on PE2/tap2. As I understand MPLS, a MPLS header is removed and forwarded on the host prior to the final destination (unless explit-null is set). Typically, PE1 would decapsulate the packet before it forwarded it to PE2 (i.e. 172.20.2.6 is available at the next hop 10.0.0.2, ip nexthop ls reports id 20 via 192.168.2.2 dev tap0 scope link proto zebra onlink). This is generally fine, but with the mesh of tunnels approach; the final destination is at the peer end of the tunnel, i.e. PE2 needs to decapsulate and forward onto link between 172.20.2.5 to 172.20.2.6, and not PE1 decapsulate the datagram before sending it to PE2. It's like 172.20.2.4 and .6 should belong to a different next-hop group than 172.20.2.3 and 5 and thus require MPLS encapsulation before it is forwarded to PE2. If I omit the "peer <addr>" when assigning the adapter the address (and later add it manually), the address isn't re-distributed to the other nodes. The problem I am trying to solve here is that CE2 and CE3 provides access to two possibly overlapping customer networks. PE1 will have custom software for managing tap1 to tag arriving packets with appropriate MPLS header for CE2 or CE3 before it injects it into the local networking stack. Q1: Is there any way I can change my setup/configuration to make this work (dummy interfaces, whatever else Linux is capable of)? Q2: I can tag a IP-datagram on PE1/tap1, but PE1 needs an incoming label / swap route defined for it, e.g. ip -f mpls add 16 as to 16 via inet 192.168.2.2 dev tap0 Q3: What is the best way to assign and distribute labels for a new CE attaching to this network? Can I create a static entry on the PE it is attached to, and all other PEs would learn this? The documentation / Google regarding LSP/static label binding is a bit thin on this. And if a static label needs to be created and assigned, should there a convention to avoid conflict with labels assigned via LDPD? I haven't played too much with the tc/flower configuration, but I could match all incoming MPLS packets and mirror them to an egress interface. However, the PEs will likely be configured in a full-mesh so determine which interface when dealing with a 1:1 mapping is likely going to be hairy. Any better idea? Cheers, - Eivind

1 0

frr for ubuntu impish 21.10
by sascha a. 07 Dec '21

07 Dec '21

Hello, sadly frr on ubuntu impish is struggling with https://github.com/FRRouting/frr/pull/9964. And there's currently no way around it, except building our own sources. Would love to see a version of FRR supported for impish (ubuntu 21.10) Much appreciated! Greetings Sascha Arthur

1 0

FRR Telco meeting
by olivier.dugeon＠orange.com 06 Dec '21

06 Dec '21

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

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

29 Nov '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 1510197: (RETURN_LOCAL) /bgpd/bgp_route.c: 12285 in show_ip_bgp_magic() /bgpd/bgp_route.c: 12355 in show_ip_bgp_magic() ________________________________________________________________________________________________________ *** CID 1510197: (RETURN_LOCAL) /bgpd/bgp_route.c: 12285 in show_ip_bgp_magic() 12279 /* show bgp: AFI_IP6, show ip bgp: AFI_IP */ 12280 if (community) 12281 return bgp_show_community(vty, bgp, community, 12282 exact_match, afi, safi, 12283 show_flags); 12284 else >>> CID 1510197: (RETURN_LOCAL) >>> Using "output_arg", which points to an out-of-scope variable "p". 12285 return bgp_show(vty, bgp, afi, safi, sh_type, 12286 output_arg, show_flags, 12287 rpki_target_state); 12288 } else { 12289 /* show <ip> bgp ipv4 all: AFI_IP, show <ip> bgp ipv6 all: 12290 * AFI_IP6 */ /bgpd/bgp_route.c: 12355 in show_ip_bgp_magic() 12349 12350 if (community) 12351 bgp_show_community(vty, bgp, community, 12352 exact_match, afi, 12353 safi, show_flags); 12354 else >>> CID 1510197: (RETURN_LOCAL) >>> Using "output_arg", which points to an out-of-scope variable "p". 12355 bgp_show(vty, bgp, afi, safi, sh_type, 12356 output_arg, show_flags, 12357 rpki_target_state); 12358 if (uj) 12359 vty_out(vty, "}\n"); 12360 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

about ospf multi-process
by yam 19 Nov '21

19 Nov '21

I am newer to frr, and have a question.Does frr support ospf multi-process? If not, is there a development plan? Thanks in advance.

2 1

Announcing FRR Release 8.1
by Jafar Al-Gharaibeh 10 Nov '21

10 Nov '21

Hi all, We are pleased to announce the 8.1 release of FRRouting. This release brings a long list of enhancements and fixes with 1200 commits from 75 developers. Thanks to all contributors. Packages: Debian Packages - https://deb.frrouting.org/ RPM Packages - https://rpm.frrouting.org/ Snaps - https://snapcraft.io/frr Docker - frrouting/frr:v8.1.0 Some major highlights: * Lua hooks are now feature complete, with one hook available for use * Improvements to Prefix-SID (Type 5) * EVPN route type-5 gateway IP overlay Index * OSPFv3 NSSA and NSSA totally stub areas * OSPFv3 ASBR summarization * OSPFv3 Graceful Restart * OSPFv2 Graceful Restart (restarting mode added, helper was already implemented) Please see the release notes for the detailed changelog: * Github release: https://github.com/FRRouting/frr/releases/tag/frr-8.1 * FRRouting website: https://frrouting.org/release/8.1/ During this period we also hosted an FRRouting 2021 GSOC Project! FRRouting's GSOC student implemented the infrastructure needed to add the ability to call out to user provided Lua scripts from within FRR. Keep an eye out for developments in this area. You can read about the work at: - https://frrouting.github.io/frr-gsoc/year-2021/projects/lua-hook-points - https://dlqs.dev/frr-gsoc-2021.html - Presentation at Netdev 0x15: https://www.youtube.com/watch?v=_8R1MYP7M48&t=1051s Thank you @dlqs! Thanks again to all contributors! Cheers, -- Jafar

1 0