- dev - lists.frrouting.org

Invitation for slack channel
by Himanshu S 18 Aug '18

18 Aug '18

Could you please get an invite?

2 1

FRR support for FPM
by Mayank Tiwari 16 Aug '18

16 Aug '18

Hi, We are using quagga in our solution for FPM connection and Reverse FPM connection with ONOS. In order to support BFD feature I need to upgrade from quagga to FRR. For that I was patching the changes present in quagga to FRR. During that patching process the following patch is causing compilation issue: diff --git a/zebra/zebra_vty.c b/zebra/zebra_vty.c index 43d76a6..03c4a6b 100644 --- a/zebra/zebra_vty.c +++ b/zebra/zebra_vty.c @@ -20,6 +20,7 @@ #include <zebra.h> +#include "zebra_fpm.h" #include "memory.h" #include "zebra_memory.h" #include "if.h" + +/* function to write the fpm config info */ +static int config_write_fpm (struct vty *vty) +{ + return fpm_remote_srv_write (vty); +} + +/* Zebra node */ +static struct cmd_node zebra_node = +{ + ZEBRA_NODE, + "", + 1 +}; /* Route VTY. */ void zebra_vty_init(void) { /* Install configuration write function. */ install_node(&table_node, config_write_table); install_node(&forwarding_node, config_write_forwarding); + install_node (&zebra_node, config_write_fpm); install_element(VIEW_NODE, &show_ip_forwarding_cmd); install_element(CONFIG_NODE, &ip_forwarding_cmd); diff --git a/zebra/zebra_fpm.h b/zebra/zebra_fpm.h new file mode 100644 index 0000000..9291ffa --- /dev/null +++ b/zebra/zebra_fpm.h @@ -0,0 +1,35 @@ +/* + * Router ID for zebra daemon. + * + * Copyright (C) 2004 James R. Leu + * + * This file is part of Quagga routing suite. + * + * Quagga is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * Quagga is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; see the file COPYING; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _ZEBRA_VTY_H_ +#define _ZEBRA_VTY_H_ + +#include <zebra.h> +#include "memory.h" +#include "prefix.h" +#include "zclient.h" +#include "if.h" + + +static int fpm_remote_srv_write (struct vty *vty ); + +#endif The function 'fpm_remote_srv_write' is already defined in zebra_fpm.c file which I need to use zebra_vty.c file. I have created a header with name zebra_fpm.h and declared that function there and later included this header in zebra_vty.c. The compilation of zebra_vty.c fails as it is not able to find 'fpm_remote_srv_write' function This is the compilation error: CCLD zebra/zebra_irdp.la CC zebra/zebra_fpm.lo CC zebra/zebra_fpm_netlink.lo ….. ….. CC zebra/zebra_vty.o In file included from zebra/zebra_vty.c:23:0: zebra/zebra_fpm.h:33:12: warning: 'fpm_remote_srv_write' used but never defined static int fpm_remote_srv_write (struct vty *vty ); ^ CC zebra/zebra_vxlan.o CC zebra/zserv.o CC zebra/zebra_netns_id.o CC zebra/zebra_netns_notify.o CC zebra/table_manager.o CC zebra/zapi_msg.o CCLD zebra/zebra zebra/zebra_vty.o: In function `config_write_fpm': /frr/zebra/zebra_vty.c:3697: undefined reference to `fpm_remote_srv_write' collect2: error: ld returned 1 exit status make[2]: *** [zebra/zebra] Error 1 Makefile:3246: recipe for target 'zebra/zebra' failed make[2]: Leaving directory '/frr' Makefile:4421: recipe for target 'all-recursive' failed make[1]: Leaving directory '/frr' make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I have observed that zebra_fpm.c is compiled as zebra_fpm.lo instead of zebra_fpm.o. I am not sure if that can cause this issue. Please suggest what I am missing here and what approach I need to take to fix this issue. Thanks and Regards, Mayank

2 4

Slack Channel Invitation
by Алексей 15 Aug '18

15 Aug '18

Hello, May I please request an invitation to the public FRR Slack Channel? -- С уважением, Алексей Черник ДП "ЦИТ Харьков Онлайн" Системный администратор +38 (050) 364-51-05 +38 (057) 707-67-05

2 1

RFC compliance
by Mike Mezeul 15 Aug '18

15 Aug '18

Hello; I am new to Free Range Routing and I am trying to find a compliance statement so that I can compare the FRR stack with the stack that we are currently using but I can't seem to find anything on this topic. Can anyone out there point me to such a list? Thanks, Mike Mezeul Michael J. Mezeul Senior Director R&D ADVA Optical Networking Inc., NA 2301 North Greenville Avenue, Suite 300 Richardson, Texas 75082 T: +1 972.759.1216 F: +1 972.759.1201 M: +1 214.448.9239 mmezeul(a)advaoptical.com<mailto:mmezeul@advaoptical.com> www.advaoptical.com<http://www.advaoptical.com/>

5 12

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

15 Aug '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 15 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 15 of 15 defect(s) ** CID 1472631: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1472631: Null pointer dereferences (FORWARD_NULL) /bfdd/bfdd_vty_clippy.c: 522 in bfd_show_peer() 516 } 517 #if 1 /* anything that can fail? */ 518 if (_failcnt) 519 return CMD_WARNING; 520 #endif 521 #endif >>> CID 1472631: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "peer_str" to "bfd_show_peer_magic", which dereferences it. 522 return bfd_show_peer_magic(self, vty, argc, argv, label, peer, peer_str, local, local_str, ifname, vrfname); ** CID 1472630: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1472630: Uninitialized variables (UNINIT) /bfdd/bfd_packet.c: 990 in bfd_recv_cb() 984 peer.family = AF_INET; 985 strcpy(peer_addr, inet_ntoa(sin.sin_addr)); 986 #endif 987 988 /* Implement RFC 5880 6.8.6 */ 989 if (mlen < BFD_PKT_LEN) { >>> CID 1472630: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "port" when calling "cp_debug". 990 cp_debug(is_mhop, &peer, &local, port, vrfname, 991 "too small (%ld bytes)", mlen); 992 return 0; 993 } 994 995 /* ** CID 1472629: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1472629: Memory - corruptions (OVERRUN) /bfdd/bfd_packet.c: 302 in ptm_bfd_echo_pkt_create() 296 297 /* Construct Echo packet information */ 298 ep.data.ver = BFD_ECHO_VERSION; 299 ep.data.len = BFD_ECHO_PKT_LEN; 300 ep.data.my_discr = htonl(bfd->discrs.my_discr); 301 #ifdef BFD_LINUX >>> CID 1472629: Memory - corruptions (OVERRUN) >>> Overrunning struct type udphdr of 8 bytes by passing it to a function which accesses it at byte offset 31 using argument "32". 302 ep.udp.check = 303 #endif /* BFD_LINUX */ 304 #ifdef BFD_BSD 305 ep.udp.uh_sum = 306 #endif /* BFD_BSD */ 307 udp4_checksum(&ep.ip, (uint8_t *)&ep.udp, ** CID 1472628: Security best practices violations (DC.WEAK_CRYPTO) /bfdd/bfd.c: 113 in ptm_bfd_start_xmt_timer() ________________________________________________________________________________________________________ *** CID 1472628: Security best practices violations (DC.WEAK_CRYPTO) /bfdd/bfd.c: 113 in ptm_bfd_start_xmt_timer() 107 * between 108 * 75% and 100% of nominal value, unless detect_mult is 1, then should 109 * be 110 * between 75% and 90%. 111 */ 112 maxpercent = (bfd->detect_mult == 1) ? 16 : 26; >>> CID 1472628: Security best practices violations (DC.WEAK_CRYPTO) >>> "random" should not be used for security related applications, as linear congruential algorithms are too easy to break. 113 jitter = (xmt_TO * (75 + (random() % maxpercent))) / 100; 114 /* XXX remove that division above */ 115 116 if (is_echo) 117 bfd_echo_xmttimer_update(bfd, jitter); 118 else ** CID 1472627: Memory - illegal accesses (USE_AFTER_FREE) /bfdd/control.c: 322 in control_queue_dequeue() ________________________________________________________________________________________________________ *** CID 1472627: Memory - illegal accesses (USE_AFTER_FREE) /bfdd/control.c: 322 in control_queue_dequeue() 316 control_queue_free(bcs, bcq); 317 318 /* Get the next buffer to send. */ 319 if (TAILQ_EMPTY(&bcs->bcs_bcqueue)) 320 goto empty_list; 321 >>> CID 1472627: Memory - illegal accesses (USE_AFTER_FREE) >>> Using freed pointer "bcs->bcs_bcqueue.tqh_first". 322 bcq = TAILQ_FIRST(&bcs->bcs_bcqueue); 323 bcs->bcs_bout = &bcq->bcq_bcb; 324 325 bcs->bcs_outev = NULL; 326 thread_add_write(master, control_write, bcs, bcs->bcs_sd, 327 &bcs->bcs_outev); ** CID 1472626: Memory - corruptions (OVERRUN) /bfdd/ptm_adapter.c: 387 in _ptm_msg_read() ________________________________________________________________________________________________________ *** CID 1472626: Memory - corruptions (OVERRUN) /bfdd/ptm_adapter.c: 387 in _ptm_msg_read() 381 return -1; 382 } 383 384 bpc->bpc_has_localif = ifnamelen > 0; 385 if (bpc->bpc_has_localif) { 386 STREAM_GET(bpc->bpc_localif, msg, ifnamelen); >>> CID 1472626: Memory - corruptions (OVERRUN) >>> Overrunning array "bpc->bpc_localif" of 33 bytes at byte offset 33 using index "ifnamelen" (which evaluates to 33). 387 bpc->bpc_localif[ifnamelen] = 0; 388 } 389 } 390 391 /* Sanity check: peer and local address must match IP types. */ 392 if (bpc->bpc_local.sa_sin.sin_family != 0 ** CID 1472625: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1472625: Null pointer dereferences (FORWARD_NULL) /bfdd/bfdd_vty_clippy.c: 399 in bfd_no_peer() 393 } 394 #if 1 /* anything that can fail? */ 395 if (_failcnt) 396 return CMD_WARNING; 397 #endif 398 #endif >>> CID 1472625: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "peer_str" to "bfd_no_peer_magic", which dereferences it. 399 return bfd_no_peer_magic(self, vty, argc, argv, peer, peer_str, local, local_str, ifname, vrfname); 400 } 401 402 /* bfd_show_peers => "show bfd peers [json]" */ 403 DEFUN_CMD_FUNC_DECL(bfd_show_peers) 404 #define funcdecl_bfd_show_peers static int bfd_show_peers_magic(\ ** CID 1472624: Control flow issues (DEADCODE) /bfdd/bfdd_vty.c: 728 in bfd_configure_peer() ________________________________________________________________________________________________________ *** CID 1472624: Control flow issues (DEADCODE) /bfdd/bfdd_vty.c: 728 in bfd_configure_peer() 722 bpc->bpc_local = *local; 723 724 if (peer) { 725 bpc->bpc_peer = *peer; 726 } else { 727 /* Peer configuration is mandatory. */ >>> CID 1472624: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "snprintf(ebuf, ebuflen, "no...". 728 snprintf(ebuf, ebuflen, "no peer configured"); 729 return -1; 730 } 731 732 bpc->bpc_mhop = mhop; 733 ** CID 1472623: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1472623: Uninitialized variables (UNINIT) /bfdd/bfd_packet.c: 990 in bfd_recv_cb() 984 peer.family = AF_INET; 985 strcpy(peer_addr, inet_ntoa(sin.sin_addr)); 986 #endif 987 988 /* Implement RFC 5880 6.8.6 */ 989 if (mlen < BFD_PKT_LEN) { >>> CID 1472623: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "vrfname" when calling "cp_debug". 990 cp_debug(is_mhop, &peer, &local, port, vrfname, 991 "too small (%ld bytes)", mlen); 992 return 0; 993 } 994 995 /* ** CID 1472622: (UNINIT) /bfdd/control.c: 517 in control_read() ________________________________________________________________________________________________________ *** CID 1472622: (UNINIT) /bfdd/control.c: 517 in control_read() 511 bcb->bcb_pos += bread; 512 bcb->bcb_left -= bread; 513 /* We need more data, return to wait more. */ 514 if (bcb->bcb_left > 0) 515 goto schedule_next_read; 516 >>> CID 1472622: (UNINIT) >>> Using uninitialized value "bcm.bcm_type". 517 switch (bcm.bcm_type) { 518 case BMT_REQUEST_ADD: 519 control_handle_request_add(bcs, bcb->bcb_bcm); 520 break; 521 case BMT_REQUEST_DEL: 522 control_handle_request_del(bcs, bcb->bcb_bcm); /bfdd/control.c: 537 in control_read() 531 control_handle_notify_del(bcs, bcb->bcb_bcm); 532 break; 533 534 default: 535 log_debug("%s: unhandled message type: %d", __func__, 536 bcm.bcm_type); >>> CID 1472622: (UNINIT) >>> Using uninitialized value "bcm.bcm_id" when calling "control_response". 537 control_response(bcs, bcm.bcm_id, BCM_RESPONSE_ERROR, 538 "invalid message type"); 539 break; 540 } 541 542 bcs->bcs_version = 0; ** CID 1472621: Possible Control flow issues (DEADCODE) /bfdd/bfd_packet.c: 340 in ptm_bfd_echo_snd() ________________________________________________________________________________________________________ *** CID 1472621: Possible Control flow issues (DEADCODE) /bfdd/bfd_packet.c: 340 in ptm_bfd_echo_snd() 334 ep->ip.ip_sum = 0; 335 ep->ip.ip_sum = checksum((uint16_t *)&ep->ip, IP_HDR_LEN); 336 #endif /* BFD_BSD */ 337 } 338 339 if (use_layer2) { >>> CID 1472621: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "pkt = bfd->echo_pkt;". 340 pkt = bfd->echo_pkt; 341 pktlen = BFD_ECHO_PKT_TOT_LEN; 342 } else { 343 pkt = &bfd->echo_pkt[ETH_HDR_LEN + IP_HDR_LEN + UDP_HDR_LEN]; 344 pktlen = BFD_ECHO_PKT_TOT_LEN 345 - (ETH_HDR_LEN + IP_HDR_LEN + UDP_HDR_LEN); ** CID 1472620: Possible Control flow issues (DEADCODE) /bfdd/bfd_packet.c: 1035 in bfd_recv_cb() ________________________________________________________________________________________________________ *** CID 1472620: Possible Control flow issues (DEADCODE) /bfdd/bfd_packet.c: 1035 in bfd_recv_cb() 1029 cp_debug(is_mhop, &peer, &local, port, vrfname, 1030 "no session found"); 1031 return 0; 1032 } 1033 1034 /* Handle VxLAN cases. */ >>> CID 1472620: Possible Control flow issues (DEADCODE) >>> Execution cannot reach the expression "ptm_bfd_validate_vxlan_pkt(bfd, &vxlan_info)" inside this statement: "if (is_vxlan && !ptm_bfd_va...". 1035 if (is_vxlan && !ptm_bfd_validate_vxlan_pkt(bfd, &vxlan_info)) 1036 return 0; 1037 1038 bfd->stats.rx_ctrl_pkt++; 1039 1040 /* ** CID 1472619: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1472619: Null pointer dereferences (FORWARD_NULL) /bfdd/bfdd_vty_clippy.c: 319 in bfd_peer_label() 313 } 314 #if 0 /* anything that can fail? */ 315 if (_failcnt) 316 return CMD_WARNING; 317 #endif 318 #endif >>> CID 1472619: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "label" to "bfd_peer_label_magic", which dereferences it. 319 return bfd_peer_label_magic(self, vty, argc, argv, label); 320 } 321 322 /* bfd_no_peer => "no peer <A.B.C.D|X:X::X:X>$peer [{multihop|local-address <A.B.C.D|X:X::X:X>$local|interface IFNAME$ifname|vrf NAME$vrfname}]" */ 323 DEFUN_CMD_FUNC_DECL(bfd_no_peer) 324 #define funcdecl_bfd_no_peer static int bfd_no_peer_magic(\ ** CID 1399484: Null pointer dereferences (NULL_RETURNS) /tools/permutations.c: 39 in main() ________________________________________________________________________________________________________ *** CID 1399484: Null pointer dereferences (NULL_RETURNS) /tools/permutations.c: 39 in main() 33 { 34 if (argc < 2) { 35 fprintf(stdout, USAGE "\n"); 36 exit(EXIT_SUCCESS); 37 } 38 struct cmd_element *cmd = calloc(1, sizeof(struct cmd_element)); >>> CID 1399484: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "cmd". 39 cmd->string = strdup(argv[1]); 40 41 struct graph *graph = graph_new(); 42 struct cmd_token *token = 43 cmd_token_new(START_TKN, cmd->attr, NULL, NULL); 44 graph_new_node(graph, token, NULL); ** CID 1399196: Error handling issues (CHECKED_RETURN) /tools/start-stop-daemon.c: 1028 in main() ________________________________________________________________________________________________________ *** CID 1399196: Error handling issues (CHECKED_RETURN) /tools/start-stop-daemon.c: 1028 in main() 1022 /* now close all extra fds */ 1023 for (i = getdtablesize() - 1; i >= 0; --i) 1024 close(i); 1025 /* change tty */ 1026 fd = open("/dev/tty", O_RDWR); 1027 if (fd >= 0) { >>> CID 1399196: Error handling issues (CHECKED_RETURN) >>> Calling "ioctl" without checking return value (as is done elsewhere 8 out of 10 times). 1028 ioctl(fd, TIOCNOTTY, 0); 1029 close(fd); 1030 } 1031 chdir("/"); 1032 umask(022); /* set a default for dumb programs */ 1033 setpgid(0, 0); /* set the process group */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

BFD daemon is now part of master
by Rafael Zalamena 15 Aug '18

15 Aug '18

Hi all, Today the BFD daemon (`bfdd`) got merged into master. It implements the Bidirectional Forwarding Detection protocol and its main purpose is to detect link failures to notify services. The daemon is automatically built on standard distribution on all platforms. Currently the following FRR daemons support BFD: * bgpd; * ospfd; * ospf6d; * pimd; --- Background: The BFD daemon was implemented re-using some Cumulus implementation, but it was extracted from another service ( https://github.com/CumulusNetworks/ptm/blob/master/src/ptm_bfd.c ). The code went through the following changes: * it became a stand alone daemon; * added new configuration interfaces: vtysh and control socket (using JSON); * replaced uthash.h with FRR's hash implementation; * added compatibility code to run on *BSDs; * changed event manager with FRR's; * minor code/protocol fixes; Related RFCs: * RFC 5880 (protocol description); * RFC 5881 (single hop IPv4/IPv6 implementation); * RFC 5883 (multi hop implementation); Thanks to everyone that helped reviewing the code! Rafael

5 4

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

11 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 09 Aug '18

09 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