August 2018 - dev - lists.frrouting.org

Issues with EVPN Type-5 Routes
by Mohan Singamsetty 10 Aug '18

10 Aug '18

Hi all, I have simple two node setup with below configuration on each node. I am trying to verify functionality related to EVPN Type-5 routes and observing few issues as listed below. Node A ------------------ Node B Most of the configuration is from source: https://docs.cumulusnetworks.com/display/DOCS/Ethernet+Virtual+Private+Netw… Node A router bgp 65000 bgp router-id 203.0.113.1 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65001 neighbor fabric capability extended-nexthop neighbor 203.0.113.2 peer-group fabric ! address-family ipv4 unicast network 44.44.44.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65000 vrf Sri bgp router-id 203.0.113.1 ! address-family ipv4 unicast network 45.45.45.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! Node B router bgp 65001 bgp router-id 203.0.113.2 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65000 neighbor fabric capability extended-nexthop neighbor 203.0.113.1 peer-group fabric ! address-family ipv4 unicast network 54.54.54.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65001 vrf Sri bgp router-id 203.0.113.2 ! address-family ipv4 unicast network 55.55.55.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! * When I had this configuration in frr.conf and rebooted both the nodes, no Type-5 routes were advertised and the only routes I see are Type-3 and Type-2 routes and the output is as below. Node_A# show bgp evpn route BGP table version is 2, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:3 *> [2]:[0]:[48]:[00:50:56:b5:b4:53] 203.0.113.1 32768 i *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.1:4 *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.2:3 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Route Distinguisher: 203.0.113.2:4 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Displayed 5 prefixes (5 paths) dev# I remember about an issue that was discussed by Donald and others earlier, where VRF configuration sequence does matter for Type-5 Routes. The mail thread that talks about this issue is @ https://lists.frrouting.org/pipermail/frog/2018-July/000205.html * So I removed the bgp configuration from both the nodes as below Node_A# conf t Node_A (config)# no router bgp 65000 Node_A (config)# no router bgp 65000 vrf Sri Node_A (config)# Node_B# conf t Node_B (config)# no router bgp 65001 Node_B (config)# no router bgp 65001 vrf Sri Node_B (config)# * Configured bgp and associated VRF again on the two nodes (vrf Sri configuration was not removed so honoring the sequence requirements from the above thread). After this the bgp evpn routes on each node are as below. Node A Node_A# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 0.0.0.0 0 32768 i Displayed 1 prefixes (1 paths) Node B Node_B# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 203.0.113.1 0 0 65000 i Displayed 1 prefixes (1 paths) EdgeRouter-2# Some of the observations: 1. When the two nodes were brought for the first time, no Type-5 routes were advertised initially. Only Type-3 and Type-2. 2. Once I unconfigure BGP and configure again, neither Type-3 nor Type-2 routes were showing up. 3. After this, It looks like Node-A is advertising Type-5 route for one of the prefix that was added through network command and this indeed received by Node-B. But this is not happening from Node B to Node A. 4. IP-Prefix from VRF Sri was advertised by Node A, but this is not happening for the IP-Prefix that was available at global level. I am trying to understand the reason for above behavior. Can you help me to identify if I am missing anything in configuration ? If not what am I missing here ? Unfortunately, not many log messages were available in this part of the code and I am trying to add more and debug, but any quick help on this would be really useful. This is latest FRR (may be a month old). I do have the log files for both the nodes with all necessary BGP debugs enabled. Let me know if you need any more details on this. Thanks, Mohan

1 0

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

09 Aug '18

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 1472311: Null pointer dereferences (NULL_RETURNS) /staticd/static_nht.c: 45 in static_nht_update() ________________________________________________________________________________________________________ *** CID 1472311: Null pointer dereferences (NULL_RETURNS) /staticd/static_nht.c: 45 in static_nht_update() 39 struct vrf *vrf; 40 bool orig; 41 bool reinstall; 42 43 vrf = vrf_lookup_by_id(vrf_id); 44 >>> CID 1472311: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 45 if (!vrf->info) 46 return; 47 48 svrf = vrf->info; 49 stable = static_vrf_static_table(afi, SAFI_UNICAST, svrf); 50 if (!stable) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Static Daemon now part of master
by Donald Sharp 08 Aug '18

08 Aug '18

All - Static route handling has been moved from within zebra to it's own daemon `staticd`. This daemon is automatically built as part of the standard distribution and both redhat and debian packaging has been updated to point to it as well. If you are using static routes you now must run `staticd`. Please update your startup scripts to reflect this: 1) Modify /etc/frr/daemons or /etc/frr/daemons.conf as necesary. 2) If you are using an integrated config, you do not need to modify any configuration file. 3) If you are not using an integrated config, staticd has been modified to allow it to read the zebra.conf file to get it's static routes. It is recommended that you do a write mem after bring up to get staticd it's own configuration file. Why was this change made? It was done for 2 reasons: 1) Zebra has rib_add_multipath for route entry from higher level protocols. static routes were violating this coding standard and we ended up with 2 code paths for handling new routes in the system. This simplfiies this to 1 entry point, which is good because we are working on further zebra changes in how it handles nexthop groups and having 2 code paths would make this work more complicated than what it needed to be. 2) Moving static routes to it's own daemon simplifies a bunch of code paths in zebra as that we do not need to keep track of special case code for static routes. I'd Like to thank everyone who's had their hand in this, Martin Winter, Renato Westphal, Quentin Young, Philippe Guibert, Lou Berger and David Lamparter! thanks! donald

1 0

Slack Channel Invitation
by Richard Mayhew [directel] 08 Aug '18

08 Aug '18

Hello, May I please request an invitation to the public FRR Slack Channel? Kind Regards Richard ________________________________ This e-mail is subject to the Directel Communications (Pty) Ltd electronic communication legal notice, available at: http://www.directel.co.za/emaildisclaimer ________________________________

2 1

Группа в ВК
by Алексей Болдырев 08 Aug '18

08 Aug '18

1 0

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

07 Aug '18

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. 2 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 1472310: Error handling issues (CHECKED_RETURN) /bgpd/bgp_debug.c: 624 in bgp_debug_parse_evpn_prefix() ________________________________________________________________________________________________________ *** CID 1472310: Error handling issues (CHECKED_RETURN) /bgpd/bgp_debug.c: 624 in bgp_debug_parse_evpn_prefix() 618 evpn_type = 0; 619 620 if (evpn_type == BGP_EVPN_MAC_IP_ROUTE) { 621 memset(&ip, 0, sizeof(struct ipaddr)); 622 623 argv_find(argv, argc, "mac", &mac_idx); >>> CID 1472310: Error handling issues (CHECKED_RETURN) >>> Calling "prefix_str2mac" without checking return value (as is done elsewhere 5 out of 6 times). 624 prefix_str2mac(argv[mac_idx + 1]->arg, &mac); 625 626 argv_find(argv, argc, "ip", &ip_idx); 627 str2ipaddr(argv[ip_idx + 1]->arg, &ip); 628 629 build_evpn_type2_prefix((struct prefix_evpn *)argv_p, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Slack public channel
by Brian Gleason 06 Aug '18

06 Aug '18

Dev, I need to request an invite to the Slack public channel. Is it possible to send me one? Thank you, Brian Gleason C: (512) 956-7319 E: <mailto:Packets@BytesOfCloud.net> Packets(a)BytesOfCloud.net W: <https://www.bytesofcloud.net/> https://www.BytesOfCloud.net T: <https://twitter.com/bytesofcloud> @bytesofcloud

2 2

Quick note on Zebra
by Donald Sharp 04 Aug '18

04 Aug '18

Commit: 8619629ada22ed19eb95d491799cc03a13d6d8aa on master provides a fix for zebra shutdown that stops a infinite loop from happening if you have routemaps. This was introduced by commit 75a2b29dd6b25725274bb8d8bd145e198a37d5f5. This was committed mid/late June in master, so if you have something in that time please feel free to upgrade to a newer version. thanks! donald

1 0

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

02 Aug '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 16 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 26 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 16 of 16 defect(s) ** CID 1472239: (RESOURCE_LEAK) /bgpd/bgp_flowspec_vty.c: 361 in route_vty_out_flowspec() /bgpd/bgp_flowspec_vty.c: 361 in route_vty_out_flowspec() ________________________________________________________________________________________________________ *** CID 1472239: (RESOURCE_LEAK) /bgpd/bgp_flowspec_vty.c: 361 in route_vty_out_flowspec() 355 unit++; 356 } 357 if (unit) 358 vty_out(vty, ")"); 359 vty_out(vty, "\n"); 360 list_delete_all_node(list_bpm); >>> CID 1472239: (RESOURCE_LEAK) >>> Variable "list_bpm" going out of scope leaks the storage it points to. 361 } else 362 vty_out(vty, "\tnot installed in PBR\n"); 363 } 364 } 365 366 int bgp_show_table_flowspec(struct vty *vty, struct bgp *bgp, afi_t afi, /bgpd/bgp_flowspec_vty.c: 361 in route_vty_out_flowspec() 355 unit++; 356 } 357 if (unit) 358 vty_out(vty, ")"); 359 vty_out(vty, "\n"); 360 list_delete_all_node(list_bpm); >>> CID 1472239: (RESOURCE_LEAK) >>> Variable "list_bpm" going out of scope leaks the storage it points to. 361 } else 362 vty_out(vty, "\tnot installed in PBR\n"); 363 } 364 } 365 366 int bgp_show_table_flowspec(struct vty *vty, struct bgp *bgp, afi_t afi, ** CID 1472238: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2831 in no_bgp_evpn_advertise_default_vni_gw() ________________________________________________________________________________________________________ *** CID 1472238: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2831 in no_bgp_evpn_advertise_default_vni_gw() 2825 VTY_DECLVAR_CONTEXT_SUB(bgpevpn, vpn); 2826 2827 if (!bgp) 2828 return CMD_WARNING; 2829 2830 if (!vpn) >>> CID 1472238: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 1;". 2831 return CMD_WARNING; 2832 2833 evpn_unset_advertise_default_gw(bgp, vpn); 2834 2835 return CMD_SUCCESS; 2836 } ** CID 1472237: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_table.c: 160 in bgp_table_range_lookup() ________________________________________________________________________________________________________ *** CID 1472237: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_table.c: 160 in bgp_table_range_lookup() 154 break; 155 } 156 node = bgp_node_from_rnode(node->link[prefix_bit( 157 &p->u.prefix, node->p.prefixlen)]); 158 } 159 >>> CID 1472237: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "node". 160 if ((matched == NULL && node->p.prefixlen > maxlen) || !node->parent) 161 return; 162 else if (matched == NULL) 163 matched = node = bgp_node_from_rnode(node->parent); 164 165 if (matched->info) { ** CID 1472236: (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 1472236: (NEGATIVE_RETURNS) /zebra/kernel_netlink.c: 1086 in kernel_init() 1080 if (fcntl(zns->netlink_cmd.sock, F_SETFL, O_NONBLOCK) < 0) 1081 zlog_err("Can't set %s socket error: %s(%d)", 1082 zns->netlink_cmd.name, safe_strerror(errno), errno); 1083 1084 /* Set receive buffer size if it's set from command line */ 1085 if (nl_rcvbufsize) >>> CID 1472236: (NEGATIVE_RETURNS) >>> "zns->netlink.sock" is passed to a parameter that cannot be negative. 1086 netlink_recvbuf(&zns->netlink, nl_rcvbufsize); 1087 1088 netlink_install_filter(zns->netlink.sock, 1089 zns->netlink_cmd.snl.nl_pid); 1090 zns->t_netlink = NULL; 1091 /zebra/kernel_netlink.c: 1088 in kernel_init() 1082 zns->netlink_cmd.name, safe_strerror(errno), errno); 1083 1084 /* Set receive buffer size if it's set from command line */ 1085 if (nl_rcvbufsize) 1086 netlink_recvbuf(&zns->netlink, nl_rcvbufsize); 1087 >>> CID 1472236: (NEGATIVE_RETURNS) >>> "zns->netlink.sock" is passed to a parameter that cannot be negative. 1088 netlink_install_filter(zns->netlink.sock, 1089 zns->netlink_cmd.snl.nl_pid); 1090 zns->t_netlink = NULL; 1091 1092 thread_add_read(zebrad.master, kernel_read, zns, 1093 zns->netlink.sock, &zns->t_netlink); ** CID 1472235: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1472235: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_debug_clippy.c: 114 in no_debug_bgp_update_prefix_afi_safi() 108 } 109 #if 0 /* anything that can fail? */ 110 if (_failcnt) 111 return CMD_WARNING; 112 #endif 113 #endif >>> CID 1472235: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "afi" to "no_debug_bgp_update_prefix_afi_safi_magic", which dereferences it. 114 return no_debug_bgp_update_prefix_afi_safi_magic(self, vty, argc, argv, afi, safi, mac, ip); ** CID 1472234: Error handling issues (CHECKED_RETURN) /pimd/pim_rp.c: 855 in pim_rp_g() ________________________________________________________________________________________________________ *** CID 1472234: Error handling issues (CHECKED_RETURN) /pimd/pim_rp.c: 855 in pim_rp_g() 849 prefix2str(&g, buf1, sizeof(buf1)); 850 zlog_debug( 851 "%s: Nexthop cache not found for RP %s grp %s register with Zebra", 852 __PRETTY_FUNCTION__, buf, buf1); 853 } 854 pim_rpf_set_refresh_time(pim); >>> CID 1472234: Error handling issues (CHECKED_RETURN) >>> Calling "pim_ecmp_nexthop_lookup" without checking return value (as is done elsewhere 6 out of 7 times). 855 pim_ecmp_nexthop_lookup(pim, 856 &rp_info->rp.source_nexthop, 857 &nht_p, &rp_info->group, 1); 858 } 859 return (&rp_info->rp); 860 } ** CID 1472233: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1472233: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_debug_clippy.c: 56 in debug_bgp_update_prefix_afi_safi() 50 } 51 #if 0 /* anything that can fail? */ 52 if (_failcnt) 53 return CMD_WARNING; 54 #endif 55 #endif >>> CID 1472233: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "afi" to "debug_bgp_update_prefix_afi_safi_magic", which dereferences it. 56 return debug_bgp_update_prefix_afi_safi_magic(self, vty, argc, argv, afi, safi, mac, ip); 57 } 58 59 /* no_debug_bgp_update_prefix_afi_safi => "no debug bgp updates prefix <l2vpn>$afi <evpn>$safi type <macip mac WORD [ip WORD]|multicast ip WORD |prefix ip WORD>" */ 60 DEFUN_CMD_FUNC_DECL(no_debug_bgp_update_prefix_afi_safi) 61 #define funcdecl_no_debug_bgp_update_prefix_afi_safi static int no_debug_bgp_update_prefix_afi_safi_magic(\ ** CID 1472232: Error handling issues (CHECKED_RETURN) /bgpd/bgp_route.c: 5204 in bgp_static_set_safi() ________________________________________________________________________________________________________ *** CID 1472232: Error handling issues (CHECKED_RETURN) /bgpd/bgp_route.c: 5204 in bgp_static_set_safi() 5198 sizeof(struct eth_segment_id)); 5199 str2esi(esi, bgp_static->eth_s_id); 5200 } 5201 if (routermac) { 5202 bgp_static->router_mac = 5203 XCALLOC(MTYPE_ATTR, ETH_ALEN + 1); >>> CID 1472232: Error handling issues (CHECKED_RETURN) >>> Calling "prefix_str2mac" without checking return value (as is done elsewhere 6 out of 7 times). 5204 prefix_str2mac(routermac, 5205 bgp_static->router_mac); 5206 } 5207 if (gwip) 5208 prefix_copy(&bgp_static->gatewayIp, &gw_ip); 5209 } ** CID 1472231: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2811 in bgp_evpn_advertise_default_gw_vni() ________________________________________________________________________________________________________ *** CID 1472231: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2811 in bgp_evpn_advertise_default_gw_vni() 2805 VTY_DECLVAR_CONTEXT_SUB(bgpevpn, vpn); 2806 2807 if (!bgp) 2808 return CMD_WARNING; 2809 2810 if (!vpn) >>> CID 1472231: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 1;". 2811 return CMD_WARNING; 2812 2813 evpn_set_advertise_default_gw(bgp, vpn); 2814 2815 return CMD_SUCCESS; 2816 } ** CID 1472230: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2976 in bgp_evpn_advertise_vni_subnet() ________________________________________________________________________________________________________ *** CID 1472230: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2976 in bgp_evpn_advertise_vni_subnet() 2970 VTY_DECLVAR_CONTEXT_SUB(bgpevpn, vpn); 2971 2972 if (!bgp) 2973 return CMD_WARNING; 2974 2975 if (!vpn) >>> CID 1472230: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 1;". 2976 return CMD_WARNING; 2977 2978 bgp_vrf = bgp_lookup_by_vrf_id(vpn->tenant_vrf_id); 2979 if (!bgp_vrf) 2980 return CMD_WARNING; 2981 ** CID 1472229: (RETURN_LOCAL) /bgpd/bgp_updgrp_adv.c: 766 in subgroup_default_originate() /bgpd/bgp_updgrp_adv.c: 771 in subgroup_default_originate() /bgpd/bgp_updgrp_adv.c: 792 in subgroup_default_originate() ________________________________________________________________________________________________________ *** CID 1472229: (RETURN_LOCAL) /bgpd/bgp_updgrp_adv.c: 766 in subgroup_default_originate() 760 UNSET_FLAG(subgrp->sflags, SUBGRP_STATUS_DEFAULT_ORIGINATE); 761 } else { 762 if (!CHECK_FLAG(subgrp->sflags, 763 SUBGRP_STATUS_DEFAULT_ORIGINATE)) { 764 765 if (bgp_flag_check(bgp, BGP_FLAG_GRACEFUL_SHUTDOWN)) { >>> CID 1472229: (RETURN_LOCAL) >>> Using "info", which points to an out-of-scope variable "tmp_info". 766 bgp_attr_add_gshut_community(info->attr); 767 } 768 769 SET_FLAG(subgrp->sflags, 770 SUBGRP_STATUS_DEFAULT_ORIGINATE); 771 subgroup_default_update_packet(subgrp, info->attr, /bgpd/bgp_updgrp_adv.c: 771 in subgroup_default_originate() 765 if (bgp_flag_check(bgp, BGP_FLAG_GRACEFUL_SHUTDOWN)) { 766 bgp_attr_add_gshut_community(info->attr); 767 } 768 769 SET_FLAG(subgrp->sflags, 770 SUBGRP_STATUS_DEFAULT_ORIGINATE); >>> CID 1472229: (RETURN_LOCAL) >>> Using "info", which points to an out-of-scope variable "tmp_info". 771 subgroup_default_update_packet(subgrp, info->attr, 772 from); 773 774 /* The 'neighbor x.x.x.x default-originate' default will 775 * act as an 776 * implicit withdraw for any previous UPDATEs sent for /bgpd/bgp_updgrp_adv.c: 792 in subgroup_default_originate() 786 &p, NULL); 787 bgp_adj_out_unset_subgroup( 788 rn, subgrp, 0, 789 BGP_ADDPATH_TX_ID_FOR_DEFAULT_ORIGINATE); 790 } 791 } >>> CID 1472229: (RETURN_LOCAL) >>> Using "info", which points to an out-of-scope variable "tmp_info". 792 aspath_unintern(&info->attr->aspath); 793 } 794 795 /* 796 * Announce the BGP table to a subgroup. 797 * ** CID 1472228: (RESOURCE_LEAK) /bgpd/bgp_debug.c: 1504 in no_debug_bgp_update_prefix_afi_safi_magic() /bgpd/bgp_debug.c: 1533 in no_debug_bgp_update_prefix_afi_safi_magic() /bgpd/bgp_debug.c: 1533 in no_debug_bgp_update_prefix_afi_safi_magic() ________________________________________________________________________________________________________ *** CID 1472228: (RESOURCE_LEAK) /bgpd/bgp_debug.c: 1504 in no_debug_bgp_update_prefix_afi_safi_magic() 1498 safiz = safi ? bgp_vty_safi_from_str(safi) : SAFI_UNICAST; 1499 1500 /* check for evpn route type */ 1501 if (afiz == AFI_L2VPN && safiz == SAFI_EVPN) { 1502 ret = bgp_debug_parse_evpn_prefix(vty, argv, argc, &argv_p); 1503 if (ret != CMD_SUCCESS) >>> CID 1472228: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1504 return ret; 1505 } else { 1506 (void)str2prefix(argv[idx_ipv4_ipv6_prefixlen]->arg, argv_p); 1507 apply_mask(argv_p); 1508 } 1509 /bgpd/bgp_debug.c: 1533 in no_debug_bgp_update_prefix_afi_safi_magic() 1527 vty_out(vty, "BGP updates debugging is off for %s\n", 1528 argv[idx_ipv4_ipv6_prefixlen]->arg); 1529 else 1530 vty_out(vty, "BGP updates debugging was not enabled for %s\n", 1531 argv[idx_ipv4_ipv6_prefixlen]->arg); 1532 >>> CID 1472228: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1533 return CMD_SUCCESS; 1534 } 1535 1536 1537 DEFUN (debug_bgp_update_prefix, 1538 debug_bgp_update_prefix_cmd, /bgpd/bgp_debug.c: 1533 in no_debug_bgp_update_prefix_afi_safi_magic() 1527 vty_out(vty, "BGP updates debugging is off for %s\n", 1528 argv[idx_ipv4_ipv6_prefixlen]->arg); 1529 else 1530 vty_out(vty, "BGP updates debugging was not enabled for %s\n", 1531 argv[idx_ipv4_ipv6_prefixlen]->arg); 1532 >>> CID 1472228: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1533 return CMD_SUCCESS; 1534 } 1535 1536 1537 DEFUN (debug_bgp_update_prefix, 1538 debug_bgp_update_prefix_cmd, ** CID 1472227: (DEADCODE) /ospfd/ospf_lsa.c: 1899 in ospf_translated_nssa_refresh() /ospfd/ospf_lsa.c: 1912 in ospf_translated_nssa_refresh() /ospfd/ospf_lsa.c: 1921 in ospf_translated_nssa_refresh() ________________________________________________________________________________________________________ *** CID 1472227: (DEADCODE) /ospfd/ospf_lsa.c: 1899 in ospf_translated_nssa_refresh() 1893 return NULL; 1894 } 1895 1896 /* do we have valid translated type5? */ 1897 if (type5 == NULL || !CHECK_FLAG(type5->flags, OSPF_LSA_LOCAL_XLT)) { 1898 if (IS_DEBUG_OSPF_NSSA) >>> CID 1472227: (DEADCODE) >>> Execution cannot reach the expression ""(null)"" inside this statement: "zlog_debug("ospf_translated...". 1899 zlog_debug( 1900 "ospf_translated_nssa_refresh(): No translated Type-5 " 1901 "found for Type-7 with Id %s", 1902 type7 ? inet_ntoa(type7->data->id) : "(null)"); 1903 return NULL; 1904 } /ospfd/ospf_lsa.c: 1912 in ospf_translated_nssa_refresh() 1906 /* Delete LSA from neighbor retransmit-list. */ 1907 ospf_ls_retransmit_delete_nbr_as(ospf, type5); 1908 1909 /* create new translated LSA */ 1910 if ((new = ospf_lsa_translated_nssa_new(ospf, type7)) == NULL) { 1911 if (IS_DEBUG_OSPF_NSSA) >>> CID 1472227: (DEADCODE) >>> Execution cannot reach the expression ""(null)"" inside this statement: "zlog_debug("ospf_translated...". 1912 zlog_debug( 1913 "ospf_translated_nssa_refresh(): Could not translate " 1914 "Type-7 for %s to Type-5", 1915 type7 ? inet_ntoa(type7->data->id) : "(null)"); 1916 return NULL; 1917 } /ospfd/ospf_lsa.c: 1921 in ospf_translated_nssa_refresh() 1915 type7 ? inet_ntoa(type7->data->id) : "(null)"); 1916 return NULL; 1917 } 1918 1919 if (!(new = ospf_lsa_install(ospf, NULL, new))) { 1920 if (IS_DEBUG_OSPF_NSSA) >>> CID 1472227: (DEADCODE) >>> Execution cannot reach the expression ""(null)"" inside this statement: "zlog_debug("ospf_translated...". 1921 zlog_debug( 1922 "ospf_translated_nssa_refresh(): Could not install " 1923 "translated LSA, Id %s", 1924 type7 ? inet_ntoa(type7->data->id) : "(null)"); 1925 return NULL; 1926 } ** CID 1472226: (RESOURCE_LEAK) /bgpd/bgp_debug.c: 1436 in debug_bgp_update_prefix_afi_safi_magic() /bgpd/bgp_debug.c: 1449 in debug_bgp_update_prefix_afi_safi_magic() /bgpd/bgp_debug.c: 1462 in debug_bgp_update_prefix_afi_safi_magic() ________________________________________________________________________________________________________ *** CID 1472226: (RESOURCE_LEAK) /bgpd/bgp_debug.c: 1436 in debug_bgp_update_prefix_afi_safi_magic() 1430 safiz = safi ? bgp_vty_safi_from_str(safi) : SAFI_UNICAST; 1431 1432 /* check for evpn route type */ 1433 if (afiz == AFI_L2VPN && safiz == SAFI_EVPN) { 1434 ret = bgp_debug_parse_evpn_prefix(vty, argv, argc, &argv_p); 1435 if (ret != CMD_SUCCESS) >>> CID 1472226: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1436 return ret; 1437 } else { 1438 (void)str2prefix(argv[idx_ipv4_ipv6_prefixlen]->arg, argv_p); 1439 apply_mask(argv_p); 1440 } 1441 /bgpd/bgp_debug.c: 1449 in debug_bgp_update_prefix_afi_safi_magic() 1443 bgp_debug_update_prefixes = list_new(); 1444 1445 if (bgp_debug_list_has_entry(bgp_debug_update_prefixes, NULL, argv_p)) { 1446 vty_out(vty, 1447 "BGP updates debugging is already enabled for %s\n", 1448 argv[idx_ipv4_ipv6_prefixlen]->arg); >>> CID 1472226: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1449 return CMD_SUCCESS; 1450 } 1451 1452 bgp_debug_list_add_entry(bgp_debug_update_prefixes, NULL, argv_p); 1453 1454 if (vty->node == CONFIG_NODE) { /bgpd/bgp_debug.c: 1462 in debug_bgp_update_prefix_afi_safi_magic() 1456 } else { 1457 TERM_DEBUG_ON(update, UPDATE_PREFIX); 1458 vty_out(vty, "BGP updates debugging is on for %s\n", 1459 argv[idx_ipv4_ipv6_prefixlen]->arg); 1460 } 1461 >>> CID 1472226: (RESOURCE_LEAK) >>> Variable "argv_p" going out of scope leaks the storage it points to. 1462 return CMD_SUCCESS; 1463 } 1464 1465 DEFPY (no_debug_bgp_update_prefix_afi_safi, 1466 no_debug_bgp_update_prefix_afi_safi_cmd, 1467 "no debug bgp updates prefix <l2vpn>$afi <evpn>$safi type <macip mac WORD [ip WORD]|multicast ip WORD |prefix ip WORD>", ** CID 1472225: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2999 in no_bgp_evpn_advertise_vni_subnet() ________________________________________________________________________________________________________ *** CID 1472225: Control flow issues (DEADCODE) /bgpd/bgp_evpn_vty.c: 2999 in no_bgp_evpn_advertise_vni_subnet() 2993 VTY_DECLVAR_CONTEXT_SUB(bgpevpn, vpn); 2994 2995 if (!bgp) 2996 return CMD_WARNING; 2997 2998 if (!vpn) >>> CID 1472225: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 1;". 2999 return CMD_WARNING; 3000 3001 evpn_unset_advertise_subnet(bgp, vpn); 3002 return CMD_SUCCESS; 3003 } 3004 ** CID 1302499: Control flow issues (DEADCODE) /ospfd/ospf_lsa.c: 1889 in ospf_translated_nssa_refresh() ________________________________________________________________________________________________________ *** CID 1302499: Control flow issues (DEADCODE) /ospfd/ospf_lsa.c: 1889 in ospf_translated_nssa_refresh() 1883 } 1884 } 1885 1886 /* do we have type7? */ 1887 if (!type7) { 1888 if (IS_DEBUG_OSPF_NSSA) >>> CID 1302499: Control flow issues (DEADCODE) >>> Execution cannot reach the expression ""(null)"" inside this statement: "zlog_debug("ospf_translated...". 1889 zlog_debug( 1890 "ospf_translated_nssa_refresh(): no Type-7 found for " 1891 "Type-5 LSA Id %s", 1892 type5 ? inet_ntoa(type5->data->id) : "(null)"); 1893 return NULL; 1894 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

no soft bgp clear is triggered on modification to prefixlist / routemap
by François 02 Aug '18

02 Aug '18

Hello, This issue has been discussed here : https://github.com/FRRouting/frr/issues/126 To sum up, when a route-map is modified (tried 2 things: adding a new entry and modifying prefix-list involved), no soft bgp clear is performed, so it looks like other peers never get new results (the "show advertised route" output is correct). Looks like "no route-map ... " and "route-map ..." again does the trick. My question is: do someone has an idea on how to fix that? I can give a shot, but I would appreciate some inputs ;) Ps: I use version 2 of FRR (because Vincent Jardin told that version 3 was not production ready at FRNog 29 ;)) Thanks! -- François

3 6