- dev - lists.frrouting.org

Re: [dev] Need help to avoid ips getting published in LDP address message
by Renato Westphal 19 Mar '23

19 Mar '23

You can try one of the following commands under the LDP address family node: * *label local allocate for ACCESSLIST_NAME*: use an ACL to select which prefixes should have a local label allocated * *label local allocate host-routes*: allocate labels for host routes only (/32's and /128's) Em sex., 17 de mar. de 2023 às 08:59, Girish Patoliya via dev < dev(a)lists.frrouting.org> escreveu: > > > > ---------- Forwarded message ---------- > From: Girish Patoliya <girishkumar.patoliya(a)mavenir.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: Need help to avoid ips getting published in LDP address message > > Hi > > > > I am using FRR version 8.1 for OSPF, LDP & BGP. > I am enabling LDP on interface eth2, however once LDP is operational, it > shares Ips of eth0 & eth1 in address message with “IN USE” as NO. > > I want to completely avoid ips of eth0 & eth1 getting published via LSD > address message. > is there any way ? > > > > Thanks > > Girish > > > ------------------------------ > > This e-mail message may contain confidential or proprietary information of > Mavenir Systems, Inc. or its affiliates and is intended solely for the use > of the intended recipient(s). If you are not the intended recipient of this > message, you are hereby notified that any review, use or distribution of > this information is absolutely prohibited and we request that you delete > all copies in your control and contact us by e-mailing to > security(a)mavenir.com. This message contains the views of its author and > may not necessarily reflect the views of Mavenir Systems, Inc. or its > affiliates, who employ systems to monitor email messages, but make no > representation that such messages are authorized, secure, uncompromised, or > free from computer viruses, malware, or other defects. Thank You > > > > ---------- Forwarded message ---------- > From: Girish Patoliya via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: [dev] Need help to avoid ips getting published in LDP address > message > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Renato Westphal

1 0

Need help to avoid ips getting published in LDP address message
by Girish Patoliya 17 Mar '23

17 Mar '23

Hi I am using FRR version 8.1 for OSPF, LDP & BGP. I am enabling LDP on interface eth2, however once LDP is operational, it shares Ips of eth0 & eth1 in address message with "IN USE" as NO. I want to completely avoid ips of eth0 & eth1 getting published via LSD address message. is there any way ? Thanks Girish ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

1 0

Weekly FRR YANG Meeting
by Pushpasis Sarkar 13 Mar '23

13 Mar '23

Rescheduling this adjusting for daylight changes. Hi Resending the meeting invite for the weekly YANG meeting. Whoever are interested in the ongoing YANG related work in FRR community, are welcome to join this Bluejeans meeting. https://bluejeans.com/377688464 Thanks and regards, -Pushasis

1 0

SONIC FRR version @ https://github.com/sonic-net/sonic-frr (v7.0 & 8.2.2)
by raja.2001＠yahoo.com 10 Mar '23

10 Mar '23

Hi, We have a copy of FRR code for SONIC at https://github.com/sonic-net/sonic-frr which is dated back to May 2019 (7.0 FRR version) But the tags at https://github.com/sonic-net/sonic-frr/tags indicate 8.2.2 FRR version. Can someone please help clarify if the old copy of FRR code above in SONIC is no longer being used and 8.2.2 is the latest FRR version integrated with SONIC ? If FRR releases from https://github.com/FRRouting/frr/releases are being used for SONIC, it will help to delete the sonic-frr copy of the code to avoid confusion. Thank you Best Regards

1 1

Stop sorting routing table for static routes
by Alireza Arzehgar 07 Mar '23

07 Mar '23

After adding a new static route in the router via vtysh or some shells, FRR will add this route to its routing table. I think everythings stored on `struct route_table`. Using `show ip route` will display sorted routes. Even when we add a new route on configuration, It will store sorted. How can we stop sorting default routes on our router ?

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 27 Feb '23

27 Feb '23

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 1535272: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1535272: Null pointer dereferences (FORWARD_NULL) /pimd/pim6_mld.c: 2474 in gm_show_if_vrf() 2468 2469 if (js) { 2470 js_if = json_object_new_object(); 2471 json_object_object_add(js_vrf, ifp->name, js_if); 2472 } 2473 >>> CID 1535272: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "tt" to "gm_show_if_one", which dereferences it. 2474 gm_show_if_one(vty, ifp, js_if, tt); 2475 } 2476 2477 /* Dump the generated table. */ 2478 if (!js && !detail) { 2479 table = ttable_dump(tt, "\n"); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Implementation for FRR C based APIs
by Bhanu Priya Bhardwaj 26 Feb '23

26 Feb '23

Hi, The intent of this mail is to use FRR APIs programmatically. We have C as the existing code base. Please suggest how we can integrate FRR APIs into our code. Regards Bhanupriya Bhardwaj DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

1 0

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

21 Feb '23

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 1534617: Uninitialized variables (UNINIT) /bgpd/bgp_rpki.c: 1417 in show_rpki_prefix_magic() ________________________________________________________________________________________________________ *** CID 1534617: Uninitialized variables (UNINIT) /bgpd/bgp_rpki.c: 1417 in show_rpki_prefix_magic() 1411 } 1412 1413 struct pfx_record *matches = NULL; 1414 unsigned int match_count = 0; 1415 enum pfxv_state result; 1416 >>> CID 1534617: Uninitialized variables (UNINIT) >>> Using uninitialized value "as" when calling "pfx_table_validate_r". 1417 if (pfx_table_validate_r(rtr_config->pfx_table, &matches, &match_count, 1418 as, &addr, prefix->prefixlen, 1419 &result) != PFX_SUCCESS) { 1420 if (!json) 1421 vty_out(vty, "Prefix lookup failed\n"); 1422 return CMD_WARNING; ** CID 1534616: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_route.c: 6985 in bgp_static_set_safi() ________________________________________________________________________________________________________ *** CID 1534616: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_route.c: 6985 in bgp_static_set_safi() 6979 bgp_static->valid = 0; 6980 bgp_static->igpmetric = 0; 6981 bgp_static->igpnexthop.s_addr = INADDR_ANY; 6982 bgp_static->label = label; 6983 bgp_static->prd = prd; 6984 >>> CID 1534616: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "rd_str" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 6985 if (rd_str) 6986 bgp_static->prd_pretty = XSTRDUP(MTYPE_BGP, rd_str); 6987 if (rmap_str) { 6988 XFREE(MTYPE_ROUTE_MAP_NAME, bgp_static->rmap.name); 6989 route_map_counter_decrement(bgp_static->rmap.map); 6990 bgp_static->rmap.name = ________________________________________________________________________________________________________ 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 17 Feb '23

17 Feb '23

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 1534606: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /bgpd/bgpd.c: 2766 in peer_group2peer_config_copy() ________________________________________________________________________________________________________ *** CID 1534606: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /bgpd/bgpd.c: 2766 in peer_group2peer_config_copy() 2760 /* capability extended-nexthop apply */ 2761 if (!CHECK_FLAG(peer->flags_override, PEER_FLAG_CAPABILITY_ENHE)) 2762 if (CHECK_FLAG(conf->flags, PEER_FLAG_CAPABILITY_ENHE)) 2763 SET_FLAG(peer->flags, PEER_FLAG_CAPABILITY_ENHE); 2764 2765 /* capability software-version apply */ >>> CID 1534606: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "peer->flags_override & (68719476736ULL /* 1ULL << 36 */)" is always 0 regardless of the values of its operands. This occurs as the logical operand of "!". 2766 if (!CHECK_FLAG(peer->flags_override, 2767 PEER_FLAG_CAPABILITY_SOFT_VERSION)) 2768 if (CHECK_FLAG(conf->flags, PEER_FLAG_CAPABILITY_SOFT_VERSION)) 2769 SET_FLAG(peer->flags, 2770 PEER_FLAG_CAPABILITY_SOFT_VERSION); 2771 ________________________________________________________________________________________________________ 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 14 Feb '23

14 Feb '23

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 1534507: (NULL_RETURNS) /zebra/zebra_l2_bridge_if.c: 214 in zebra_l2_bridge_if_vlan_update() /zebra/zebra_l2_bridge_if.c: 216 in zebra_l2_bridge_if_vlan_update() ________________________________________________________________________________________________________ *** CID 1534507: (NULL_RETURNS) /zebra/zebra_l2_bridge_if.c: 214 in zebra_l2_bridge_if_vlan_update() 208 struct zebra_l2_bridge_vlan *bvlan; 209 210 zif = (struct zebra_if *)ifp->info; 211 bvlan = zebra_l2_bridge_if_vlan_find(zif, bvl->vid); 212 213 if (chgflags & ZEBRA_BRIDGEIF_ACCESS_BD_CHANGE) >>> CID 1534507: (NULL_RETURNS) >>> Dereferencing "bvlan", which is known to be "NULL". 214 bvlan->access_bd = bvl->access_bd; 215 216 if (!bvlan->access_bd) 217 return zebra_l2_bridge_if_vlan_del(ifp, bvl->vid); 218 219 return 0; /zebra/zebra_l2_bridge_if.c: 216 in zebra_l2_bridge_if_vlan_update() 210 zif = (struct zebra_if *)ifp->info; 211 bvlan = zebra_l2_bridge_if_vlan_find(zif, bvl->vid); 212 213 if (chgflags & ZEBRA_BRIDGEIF_ACCESS_BD_CHANGE) 214 bvlan->access_bd = bvl->access_bd; 215 >>> CID 1534507: (NULL_RETURNS) >>> Dereferencing "bvlan", which is known to be "NULL". 216 if (!bvlan->access_bd) 217 return zebra_l2_bridge_if_vlan_del(ifp, bvl->vid); 218 219 return 0; 220 } 221 ** CID 1534506: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /zebra/rt_netlink.c: 1370 in _netlink_nexthop_encode_dvni_label() ________________________________________________________________________________________________________ *** CID 1534506: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /zebra/rt_netlink.c: 1370 in _netlink_nexthop_encode_dvni_label() 1364 mpls_lse_t *out_lse, 1365 size_t buflen, char *label_buf) 1366 { 1367 struct in_addr ipv4; 1368 1369 if (!nl_attr_put64(nlmsg, buflen, LWTUNNEL_IP_ID, >>> CID 1534506: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(_uint64_t)out_lse[0] >> 32" is 0 regardless of the values of its operands. This occurs as an argument to a function call. 1370 htonll((uint64_t)out_lse[0]))) 1371 return false; 1372 1373 if (nexthop->type == NEXTHOP_TYPE_IPV4_IFINDEX) { 1374 if (!nl_attr_put(nlmsg, buflen, LWTUNNEL_IP_DST, 1375 &nexthop->gate.ipv4, 4)) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0