October 2017 - dev - lists.frrouting.org

Missing developer documentation
by Olivier Dugeon 12 Dec '17

12 Dec '17

Hiall, There is missing developer documentation in FRR. In PR #805 I try to update an old Zebra hacking document, but that seems too old to be publish, so I prefer to remove it as suggested during the PR review. For me, the main problem is how to start writing a such documentation ? First, it is too huge and to complicated to be written by only one person. Second, we need a dedicated space (e.g. a new doc project inside FRRouting) to collectively write such documentation and then push into frr master documents when they are ready. Finally, we need to organize themselves in order to collectively decided how to write them, to formalize the document through a common template, to harmonize the documentation... I would start by proposing: * start discussion about this new topic (create a new issue in github) during regular meeting * decide the document format (Markdown, in line github Wiki, LaTeX, TeXi ...) * create a new doc project within FRRouting * propose template * propose Table of Content for each document (perhaps partially common) * open contribution to the different documents Comments are welcome. Regards Olivier

4 6

Redistribution based on source protocol's attributes
by Srinivas K 28 Nov '17

28 Nov '17

Does FRR support BGP route redistribution into OSPF using route-maps with filtering based on BGP attributes like Cisco. If not let me know how to archive it. Ex: Based on BGP community want to set metric-type, metric and tag values (in OSPF) route-map BGP-TO-OSPF deny 5 match community 1 set metric-type type-1 set metric 10 set tag 10101 exit router ospf redistribute bgp route-map BGP-TO-OSPF exit

3 4

[Action] Nominations for the TSC...
by Alistair Woodman 27 Oct '17

27 Oct '17

Dear Maintainers, I'm looking for nominations for the TSC election. (Per the by-laws this election is due this month). I intend to follow the following process. 1) ask you (the maintainers) for new nominations to the TSC. (These can include self nominations) 2) assume existing TSC members will wish to continue (i.e. They are automatically nominated) (Any exiting TSC member wishing to stand down may unicast me) 3) create the union of the two sets 4) run the election per the "Multi-winner Single Transferable Vote" process per the TSC doc. Please provide me with nominations by COB this Friday the 27th. /a Sent from my iPad

2 2

FRR Zebra/FPM interactions
by Donald Sharp 25 Oct '17

25 Oct '17

Thorvald - Hi! I'm Donald Sharp, I'm working on FRR, I'm discussing with you this PR: https://github.com/FRRouting/frr/pull/1350 First I'd like to apologize for the slow response to your enquiries on the PR. I decided to reach out directly to you because I feel like email might be a bit better medium to talk about what our plans are and to describe what I see the future of zebra is. Our plans are not currently set in stone but we do have some broad strokes of what we want to accomplish: 1) Separate the south bound API in such a manner that we use a starting function call. Currently both the FPM interactions and zebra/rt.h are our south bound interfaces As an example rib_install_kernel does this: rib_install_kernel hook_call (rib_update) -> FPM interactions kernel_route_rib -> Rib install for kernel we are working on. if (success) Set some values We want it to do this: rib_install_kernel kernel_route_rib -> List of hooks to call: FPM Interactions Rib install for kernel we are working on Anything else we add as a rib_update hook if (success) Call kernel_route_rib_success() function Now rinse/repeat this for all rt.h southbound api's. 2) Separate processing of southbound api into it's own true pthread( not lib/thread.h ): Currently the FPM has a TAILQ_ENTRY(rib_dest_t_) in rib_dest_t(rib.h) to track and process FPM install/deletes/whatever.. I would like to convert this data structure to the control point for what has been communicated south bound. Then allow the southbound api's to bundle the installation into whatever however they would like to do so in a timeframe that it would like to do so as well. I think this would allow us to do things like bundling of netlink messages to the kernel. Kernel insertion on linux as it stands is absurdly slow and needs to be sped up. 3) Arbitrary hook levels: We would also like the ability for FPM interactions and Rib install hooks have the ability to have sub hooks as well if they would like to as well. As an example the rib interactions could have a route-map application hook before passing to the kernel. 4) Allow which hooks to be used via a control mechanism( this is what you were really asking for ) to control who get's called. As you noticed it would be nice to have a way to control which soutbound hooks are actually installed and used. Now where to start? I personally think we need to start with #1. #2 and #4 will flow from that imo. donald PS - If you would like more immediate access than email, we use a public slack (frrouting.slack.com) if you would like an invite please let me know.

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 25 Oct '17

25 Oct '17

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. 24 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 1458607: Uninitialized variables (UNINIT) /vtysh/vtysh.c: 811 in vtysh_rl_describe() ________________________________________________________________________________________________________ *** CID 1458607: Uninitialized variables (UNINIT) /vtysh/vtysh.c: 811 in vtysh_rl_describe() 805 } else if (rl_end && isspace((int)rl_line_buffer[rl_end - 1])) 806 vector_set(vline, NULL); 807 808 fprintf(stdout, "\n"); 809 810 /* Ambiguous and no match error. */ >>> CID 1458607: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 811 switch (ret) { 812 case CMD_ERR_AMBIGUOUS: 813 cmd_free_strvec(vline); 814 fprintf(stdout, "%% Ambiguous command.\n"); 815 rl_on_new_line(); 816 return 0; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

VTY status 13 while sending config over vty socket
by $iddhe$h Divekar 23 Oct '17

23 Oct '17

Hi, Am getting following error when sending config over vty socket. VTY status 13. Below is the config am trying to send. It happens when "redistribute connected" is sent over the socket. configure terminal router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown address-family ipv6 unicast redistribute connected exit-address-family address-family ipv6 unicast redistribute static exit-address-family address-family ipv4 unicast redistribute connected exit-address-family address-family ipv4 unicast redistribute static exit-address-family end If I do show running I see following config applied. router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown ! address-family ipv6 unicast redistribute connected exit-address-family ! Is there anything wrong with the config. Copy pasting the config directly works fine. -- -$iddhesh.

2 3

Problems regarding BGP code 2, sub-code 7 when peering with Cisco IOS-XR Version 4.2.3 over IPv6
by Christoffer Hansen 19 Oct '17

19 Oct '17

FRRouting-Dev <dev(a)lists.frrouting.org> Hit an interesting issue today. (for reference a lot of technical details below) I found myself unable to locate the option of turning BGP code 2, sub-code 7 off when sending capabilities to a neighbor. (Spent some time googling around but mostly found Cisco IOS-XR related stuff) It appears Cisco IOS-XR does not yet support the use off 'additional-paths' (BGP code 2, sub-code 7) when exchanging neighbor capabilities. But ONLY for IPv6 (IPv4 is supported). So my question to the list (if anyone finds the time to answer) is: Does FFRouting contain an option to turn off the multi-path feature / specific sub-code when announcing BGPv4 capabilities to it's neighbor(s) over IPv6 (or both IPv4/v6) ? Nb: And yes. Have tried disabling sending capabilities to the IOS-XR router altogether. But the the Cisco router just refuses because no capabilities is announced from neighbor. Nb(2): Capability option is set to 'Dynamic' when announcing to neighbor. -- Regards, Christoffer. gpg: c8b3 82a8 a1cd cdb7 71fe b24c c654 948f da86 becd Software Details ================ pfSense v2.3.4 -------------- * Name: frr * Category: net * Version: 0.0.2 * Description: FRR routing daemon for BGP, OSPF, and OSPF6 Conflicts with Quagga OSPF and OpenBGPD. These packages cannot be installed at the same time. Debug output from Cisco IOS XR Software, Version 4.2.3[Default] =============================================================== * NOTE(1): IPv6 network prefix replaced with '2001:db8::' RP/0/RSP0/CPU0:Sep 26 16:49:36.532 MEST: bgp[1048]: [default-ioct] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Idle to Connect RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: Received message from 2001:db8:::250:56ff:febd:7e57 with type 1, length (incl. header) 102 RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: Receive message dump for 2001:db8:::250:56ff:febd:7e57: RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: ffff ffff ffff ffff ffff ffff ffff ffff RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0066 0104 ff4c 0078 5774 0604 4902 0601 RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0400 0100 0102 0280 0002 0202 0002 0641 RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0400 00ff 4c02 0645 0400 0101 0102 0242 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 0002 0243 0002 1949 1715 6677 3031 2e6c RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 6162 2e6e 6574 7261 766e 656e 2e65 7500 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 0204 4002 8078 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: Received OPEN from 2001:db8:::250:56ff:febd:7e57, version 4, holdtime 120 secs RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has MULTIPROTOCOL_EXTENSION capability for afi/safi: 1/1 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has ROUTE-REFRESH capability(old) for all address-families RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has ROUTE-REFRESH capability for all address-families RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has 4-byte AS capability with AS 65356 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 Addr-family 1/1 not supported: Ignoring the ADDPATH capability RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 66, length 0 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 67, length 0 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 25 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 73, length 23 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 4 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: bgp_io_read_schedule_updgrp: NO updgrp scheduled after Open processing: nbr=2001:db8:::250:56ff:febd:7e57, nbrfl=0x08314080 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Connect to OpenSent RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: Sending OPEN to 2001:db8:::250:56ff:febd:7e57, version 4, my as: 31027, holdtime 120 seconds RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has capabilities with no supported address-family. RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: Sending NOTIFICATION 2/7 (unsupported/disjoint capability) to 2001:db8:::250:56ff:febd:7e57 (0 bytes: ) RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from OpenSent to Closing RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: 2001:db8:::250:56ff:febd:7e57 send message type 3, length (incl. header) 21 RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: Send message dump for 2001:db8:::250:56ff:febd:7e57: RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: ffff ffff ffff ffff ffff ffff ffff ffff RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: 0015 0302 07 RP/0/RSP0/CPU0:Sep 26 16:49:36.762 MEST: bgp[1048]: [default-event] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Closing to Idle RP/0/RSP0/CPU0:Sep 26 16:49:36.762 MEST: bgp[1048]: [default-event] VRF Internet: 2001:db8:::250:56ff:febd:7e57 reset due to BGP Notification sent Output from pfSense FRR routing daemon ====================================== * NOTE(1): IPv6 network prefix replaced with '2001:db8::' * NOTE(2): IPv4 next-hop replaced with TEST-NET-3 address 203.0.113.4 BGP neighbor is 2001:db8::1, remote AS #ISP-ASN#, local AS 65356, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Idle Last read 00:00:27, Last write 00:00:11 Hold time is 120, keepalive interval is 40 seconds Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens: 4 0 Notifications: 0 4 Updates: 0 0 Keepalives: 0 0 Route Refresh: 0 0 Capability: 0 0 Total: 4 4 Minimum time between advertisement runs is 0 seconds Update source is 2001:db8::250:56ff:febd:7e57 For address family: IPv4 Unicast Not part of any update group Community attribute sent to this neighbor(extended) 0 accepted prefixes Connections established 0; dropped 0 Last reset 00:00:27, due to NOTIFICATION received (OPEN Message Error/Unsupported Capability) Local host: 2001:db8::250:56ff:febd:7e57, Local port: 57277 Foreign host: 2001:db8::1, Foreign port: 179 Nexthop: 203.0.113.4 Nexthop global: 2001:db8::250:56ff:febd:7e57 Nexthop local: fe80::250:56ff:febd:7e57 BGP connection: shared network BGP Connect Retry Timer in Seconds: 120 Next start timer due in 5 seconds Read thread: off Write thread: off

2 5

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 17 Oct '17

17 Oct '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 9 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 9 of 9 defect(s) ** CID 1458175: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 391 in if_set_index() ________________________________________________________________________________________________________ *** CID 1458175: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 391 in if_set_index() 385 386 return if_create(name, vrf_id); 387 } 388 389 void if_set_index(struct interface *ifp, ifindex_t ifindex) 390 { >>> CID 1458175: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "vrf" = null return value from "vrf_lookup_by_id". 391 struct vrf *vrf = vrf_lookup_by_id(ifp->vrf_id); 392 393 if (ifp->ifindex == ifindex) 394 return; 395 396 if (ifp->ifindex != IFINDEX_INTERNAL) ** CID 1458174: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 244 in if_lookup_by_name() ________________________________________________________________________________________________________ *** CID 1458174: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 244 in if_lookup_by_name() 238 : IFINDEX_INTERNAL; 239 } 240 241 /* Interface existance check by interface name. */ 242 struct interface *if_lookup_by_name(const char *name, vrf_id_t vrf_id) 243 { >>> CID 1458174: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "vrf" = null return value from "vrf_lookup_by_id". 244 struct vrf *vrf = vrf_lookup_by_id(vrf_id); 245 struct interface if_tmp; 246 247 if (!name || strnlen(name, INTERFACE_NAMSIZ) == INTERFACE_NAMSIZ) 248 return NULL; 249 ** CID 1458173: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 197 in if_delete() ________________________________________________________________________________________________________ *** CID 1458173: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 197 in if_delete() 191 list_delete_all_node(ifp->nbr_connected); 192 } 193 194 /* Delete and free interface structure. */ 195 void if_delete(struct interface *ifp) 196 { >>> CID 1458173: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "vrf" = null return value from "vrf_lookup_by_id". 197 struct vrf *vrf = vrf_lookup_by_id(ifp->vrf_id); 198 199 IFNAME_RB_REMOVE(vrf, ifp); 200 if (ifp->ifindex != IFINDEX_INTERNAL) 201 IFINDEX_RB_REMOVE(vrf, ifp); 202 ** CID 1458172: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 216 in if_lookup_by_index() ________________________________________________________________________________________________________ *** CID 1458172: Null pointer dereferences (NULL_RETURNS) /lib/if.c: 216 in if_lookup_by_index() 210 XFREE(MTYPE_IF, ifp); 211 } 212 213 /* Interface existance check by index. */ 214 struct interface *if_lookup_by_index(ifindex_t ifindex, vrf_id_t vrf_id) 215 { >>> CID 1458172: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "vrf" = null return value from "vrf_lookup_by_id". 216 struct vrf *vrf = vrf_lookup_by_id(vrf_id); 217 struct interface if_tmp; 218 219 if_tmp.ifindex = ifindex; 220 return RB_FIND(if_index_head, &vrf->ifaces_by_index, &if_tmp); 221 } ** CID 1458171: (NULL_RETURNS) /pimd/pim_iface.c: 906 in pim_find_primary_addr() /pimd/pim_iface.c: 908 in pim_find_primary_addr() ________________________________________________________________________________________________________ *** CID 1458171: (NULL_RETURNS) /pimd/pim_iface.c: 906 in pim_find_primary_addr() 900 * and use that as the primary address 901 */ 902 if (!v4_addrs && v6_addrs && !if_is_loopback(ifp)) { 903 struct interface *lo_ifp; 904 // DBS - Come back and check here 905 if (ifp->vrf_id == VRF_DEFAULT) >>> CID 1458171: (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 906 lo_ifp = if_lookup_by_name("lo", vrf->vrf_id); 907 else 908 lo_ifp = if_lookup_by_name(vrf->name, vrf->vrf_id); 909 910 if (lo_ifp) 911 return pim_find_primary_addr(lo_ifp); /pimd/pim_iface.c: 908 in pim_find_primary_addr() 902 if (!v4_addrs && v6_addrs && !if_is_loopback(ifp)) { 903 struct interface *lo_ifp; 904 // DBS - Come back and check here 905 if (ifp->vrf_id == VRF_DEFAULT) 906 lo_ifp = if_lookup_by_name("lo", vrf->vrf_id); 907 else >>> CID 1458171: (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 908 lo_ifp = if_lookup_by_name(vrf->name, vrf->vrf_id); 909 910 if (lo_ifp) 911 return pim_find_primary_addr(lo_ifp); 912 } 913 ** CID 1458170: Null pointer dereferences (NULL_RETURNS) /pimd/pim_nht.c: 651 in pim_parse_nexthop_update() ________________________________________________________________________________________________________ *** CID 1458170: Null pointer dereferences (NULL_RETURNS) /pimd/pim_nht.c: 651 in pim_parse_nexthop_update() 645 struct pim_rpf rpf; 646 struct pim_nexthop_cache *pnc = NULL; 647 struct pim_neighbor *nbr = NULL; 648 struct interface *ifp = NULL; 649 struct interface *ifp1 = NULL; 650 struct vrf *vrf = vrf_lookup_by_id(vrf_id); >>> CID 1458170: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 651 struct pim_instance *pim = vrf->info; 652 653 s = zclient->ibuf; 654 memset(&p, 0, sizeof(struct prefix)); 655 p.family = stream_getw(s); 656 p.prefixlen = stream_getc(s); ** CID 1458169: Null pointer dereferences (NULL_RETURNS) /pimd/pim_iface.c: 800 in pim_if_addr_del_all() ________________________________________________________________________________________________________ *** CID 1458169: Null pointer dereferences (NULL_RETURNS) /pimd/pim_iface.c: 800 in pim_if_addr_del_all() 794 void pim_if_addr_del_all(struct interface *ifp) 795 { 796 struct connected *ifc; 797 struct listnode *node; 798 struct listnode *nextnode; 799 struct vrf *vrf = vrf_lookup_by_id(ifp->vrf_id); >>> CID 1458169: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 800 struct pim_instance *pim = vrf->info; 801 802 /* PIM/IGMP enabled ? */ 803 if (!ifp->info) 804 return; 805 ** CID 1458168: Null pointer dereferences (NULL_RETURNS) /ospfd/ospfd.c: 252 in ospf_new() ________________________________________________________________________________________________________ *** CID 1458168: Null pointer dereferences (NULL_RETURNS) /ospfd/ospfd.c: 252 in ospf_new() 246 zlog_debug("%s: Create new ospf instance with vrf_name %s vrf_id %d", 247 __PRETTY_FUNCTION__, name, new->vrf_id); 248 if (vrf) 249 ospf_vrf_link(new, vrf); 250 } else { 251 new->vrf_id = VRF_DEFAULT; >>> CID 1458168: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "vrf" = null return value from "vrf_lookup_by_id". 252 vrf = vrf_lookup_by_id(VRF_DEFAULT); 253 ospf_vrf_link(new, vrf); 254 } 255 ospf_zebra_vrf_register(new); 256 257 new->abr_type = OSPF_ABR_DEFAULT; ** CID 1458167: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 351 in pim_zebra_if_address_del() ________________________________________________________________________________________________________ *** CID 1458167: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 351 in pim_zebra_if_address_del() 345 static int pim_zebra_if_address_del(int command, struct zclient *client, 346 zebra_size_t length, vrf_id_t vrf_id) 347 { 348 struct connected *c; 349 struct prefix *p; 350 struct vrf *vrf = vrf_lookup_by_id(vrf_id); >>> CID 1458167: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "vrf". 351 struct pim_instance *pim = vrf->info; 352 353 /* 354 zebra api notifies address adds/dels events by using the same call 355 interface_add_read below, see comments in lib/zclient.c 356 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Final Request for Review
by Donald Sharp 16 Oct '17

16 Oct '17

https://github.com/FRRouting/frr/pull/1272 This PR is now 17 days old without anyone reviewing it. I will auto push this in on Thur Oct 19 in the absence of comments. thanks! donald

1 0

bgpd: Fix AS_PATH size calculation for long paths
by Mike Tancsa 13 Oct '17

13 Oct '17

Hi, I got caught up with the bug below https://github.com/donaldsharp/frr/commit/084002351fbfd6b4e2d9c4c218288b232… triggered by the announcement discussed here https://mailman.nanog.org/pipermail/nanog/2017-September/092536.html I see its not been ported to either stable branch. I am guessing its safe to apply the patch as is to both stable 2.0 and 3.0 ? While on this topic is 3.0 considered stable enough to run in production ? Or better to stick with 2.0 ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/

2 2