March 2017 - dev - lists.frrouting.org

Organizational Name Change
by Donald Sharp 30 Mar '17

30 Mar '17

All - Please update your links to FreeRangeRouting on github to: https://github.com/frrouting/ As part of the name change this was necessary to do. As I understand it your fork's should still work. If they do not I apologize in advance. thanks! donald

1 0

[frr] New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 30 Mar '17

30 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 45 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 45 defect(s) ** CID 1422699: Memory - illegal accesses (USE_AFTER_FREE) /ldpd/ldpd.c: 419 in ldpd_shutdown() ________________________________________________________________________________________________________ *** CID 1422699: Memory - illegal accesses (USE_AFTER_FREE) /ldpd/ldpd.c: 419 in ldpd_shutdown() 413 msgbuf_clear(&iev_ldpe->ibuf.w); 414 close(iev_ldpe->ibuf.fd); 415 msgbuf_clear(&iev_lde->ibuf.w); 416 close(iev_lde->ibuf.fd); 417 418 config_clear(ldpd_conf); >>> CID 1422699: Memory - illegal accesses (USE_AFTER_FREE) >>> Dereferencing freed pointer "ldpd_conf". 419 QOBJ_UNREG(ldpd_conf); 420 421 log_debug("waiting for children to terminate"); 422 do { 423 pid = wait(&status); 424 if (pid == -1) { ** CID 1422698: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422698: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3978 in set_lcommunity_delete() 3972 char *str; 3973 3974 str = XCALLOC (MTYPE_TMP, strlen (argv[2]->arg) + strlen (" delete") + 1); 3975 strcpy (str, argv[2]->arg); 3976 strcpy (str + strlen (argv[2]->arg), " delete"); 3977 >>> CID 1422698: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3978 generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3979 "large-comm-list", str); 3980 3981 XFREE (MTYPE_TMP, str); 3982 return CMD_SUCCESS; 3983 } ** CID 1422697: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422697: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3934 in set_lcommunity_none() 3928 set_lcommunity_none_cmd, 3929 "set large-community none", 3930 SET_STR 3931 "BGP large community attribute\n" 3932 "No large community attribute\n") 3933 { >>> CID 1422697: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3934 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3935 "large-community", "none"); 3936 } 3937 3938 DEFUN (no_set_lcommunity, 3939 no_set_lcommunity_cmd, ** CID 1422696: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422696: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3671 in set_aspath_prepend_asn() 3665 { 3666 int idx_asn = 3; 3667 int ret; 3668 char *str; 3669 3670 str = argv_concat (argv, argc, idx_asn); >>> CID 1422696: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3671 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3672 "as-path prepend", str); 3673 XFREE (MTYPE_TMP, str); 3674 3675 return ret; 3676 } ** CID 1422695: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422695: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3889 in set_community_delete() 3883 char *str; 3884 3885 str = XCALLOC (MTYPE_TMP, strlen (argv[idx_comm_list]->arg) + strlen (" delete") + 1); 3886 strcpy (str, argv[idx_comm_list]->arg); 3887 strcpy (str + strlen (argv[idx_comm_list]->arg), " delete"); 3888 >>> CID 1422695: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3889 generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "comm-list", str); 3890 3891 XFREE (MTYPE_TMP, str); 3892 return CMD_SUCCESS; 3893 } 3894 ** CID 1422694: (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422694: (NULL_RETURNS) /bgpd/bgp_routemap.c: 4443 in no_set_ipx_vpn_nexthop() 4437 arg = NULL; 4438 else 4439 arg = argv[idx_ip]->arg; 4440 if (argv_find_and_parse_afi (argv, argc, &idx, &afi)) 4441 { 4442 if (afi == AFI_IP) >>> CID 1422694: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_delete". 4443 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 4444 "ip vpn next-hop", arg); 4445 else 4446 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 4447 "ipv6 vpn next-hop", argv[idx_ip]->arg); 4448 } /bgpd/bgp_routemap.c: 4446 in no_set_ipx_vpn_nexthop() 4440 if (argv_find_and_parse_afi (argv, argc, &idx, &afi)) 4441 { 4442 if (afi == AFI_IP) 4443 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 4444 "ip vpn next-hop", arg); 4445 else >>> CID 1422694: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_delete". 4446 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 4447 "ipv6 vpn next-hop", argv[idx_ip]->arg); 4448 } 4449 return CMD_SUCCESS; 4450 } 4451 ** CID 1422693: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422693: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4047 in set_ecommunity_soo() 4041 { 4042 int idx_asn_nn = 3; 4043 int ret; 4044 char *str; 4045 4046 str = argv_concat (argv, argc, idx_asn_nn); >>> CID 1422693: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4047 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4048 "extcommunity soo", str); 4049 XFREE (MTYPE_TMP, str); 4050 return ret; 4051 } 4052 ** CID 1422692: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422692: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4013 in set_ecommunity_rt() 4007 { 4008 int idx_asn_nn = 3; 4009 int ret; 4010 char *str; 4011 4012 str = argv_concat (argv, argc, idx_asn_nn); >>> CID 1422692: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4013 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4014 "extcommunity rt", str); 4015 XFREE (MTYPE_TMP, str); 4016 4017 return ret; 4018 } ** CID 1422691: (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422691: (NULL_RETURNS) /bgpd/bgp_routemap.c: 3834 in set_community() 3828 3829 if (additive) 3830 { 3831 argstr = XCALLOC (MTYPE_TMP, strlen (str) + strlen (" additive") + 1); 3832 strcpy (argstr, str); 3833 strcpy (argstr + strlen (str), " additive"); >>> CID 1422691: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3834 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3835 "community", argstr); 3836 XFREE (MTYPE_TMP, argstr); 3837 } 3838 else 3839 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), /bgpd/bgp_routemap.c: 3839 in set_community() 3833 strcpy (argstr + strlen (str), " additive"); 3834 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3835 "community", argstr); 3836 XFREE (MTYPE_TMP, argstr); 3837 } 3838 else >>> CID 1422691: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3839 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3840 "community", str); 3841 3842 community_free (com); 3843 3844 return ret; ** CID 1422690: (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422690: (NULL_RETURNS) /bgpd/bgp_routemap.c: 4079 in set_origin() 4073 "remote EGP\n" 4074 "local IGP\n" 4075 "unknown heritage\n") 4076 { 4077 int idx_origin = 2; 4078 if (strncmp (argv[idx_origin]->arg, "igp", 2) == 0) >>> CID 1422690: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4079 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4080 "igp"); 4081 if (strncmp (argv[idx_origin]->arg, "egp", 1) == 0) 4082 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4083 "egp"); 4084 if (strncmp (argv[idx_origin]->arg, "incomplete", 2) == 0) /bgpd/bgp_routemap.c: 4082 in set_origin() 4076 { 4077 int idx_origin = 2; 4078 if (strncmp (argv[idx_origin]->arg, "igp", 2) == 0) 4079 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4080 "igp"); 4081 if (strncmp (argv[idx_origin]->arg, "egp", 1) == 0) >>> CID 1422690: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4082 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4083 "egp"); 4084 if (strncmp (argv[idx_origin]->arg, "incomplete", 2) == 0) 4085 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4086 "incomplete"); 4087 /bgpd/bgp_routemap.c: 4085 in set_origin() 4079 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4080 "igp"); 4081 if (strncmp (argv[idx_origin]->arg, "egp", 1) == 0) 4082 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4083 "egp"); 4084 if (strncmp (argv[idx_origin]->arg, "incomplete", 2) == 0) >>> CID 1422690: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4085 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "origin", 4086 "incomplete"); 4087 4088 return CMD_WARNING; 4089 } 4090 ** CID 1422689: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422689: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4310 in set_ipv6_nexthop_global() 4304 IN6_IS_ADDR_LINKLOCAL(&addr)) 4305 { 4306 vty_out (vty, "%% Invalid global nexthop address%s", VTY_NEWLINE); 4307 return CMD_WARNING; 4308 } 4309 >>> CID 1422689: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4310 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4311 "ipv6 next-hop global", argv[idx_ipv6]->arg); 4312 } 4313 4314 4315 DEFUN (no_set_ipv6_nexthop_global, ** CID 1422688: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422688: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3606 in set_local_pref() 3600 "set local-preference (0-4294967295)", 3601 SET_STR 3602 "BGP local preference path attribute\n" 3603 "Preference value\n") 3604 { 3605 int idx_number = 2; >>> CID 1422688: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3606 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3607 "local-preference", argv[idx_number]->arg); 3608 } 3609 3610 3611 DEFUN (no_set_local_pref, ** CID 1422687: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422687: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4240 in set_ipv6_nexthop_peer() 4234 "set ipv6 next-hop peer-address", 4235 SET_STR 4236 IPV6_STR 4237 "Next hop address\n" 4238 "Use peer address (for BGP only)\n") 4239 { >>> CID 1422687: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4240 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4241 "ipv6 next-hop peer-address", NULL); 4242 } 4243 4244 DEFUN (no_set_ipv6_nexthop_peer, 4245 no_set_ipv6_nexthop_peer_cmd, ** CID 1422686: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422686: Null pointer dereferences (NULL_RETURNS) /ospfd/ospf_routemap.c: 623 in set_metric_type() 617 SET_STR 618 "Type of metric for destination routing protocol\n" 619 "OSPF[6] external type 1 metric\n" 620 "OSPF[6] external type 2 metric\n") 621 { 622 char *ext = argv[2]->text; >>> CID 1422686: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 623 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 624 "metric-type", ext); 625 } 626 627 DEFUN (no_set_metric_type, 628 no_set_metric_type_cmd, ** CID 1422685: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422685: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3636 in set_weight() 3630 "set weight (0-4294967295)", 3631 SET_STR 3632 "BGP weight for routing table\n" 3633 "Weight value\n") 3634 { 3635 int idx_number = 2; >>> CID 1422685: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3636 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "weight", 3637 argv[idx_number]->arg); 3638 } 3639 3640 3641 DEFUN (no_set_weight, ** CID 1422684: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422684: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4155 in set_aggregator_as() 4149 4150 argstr = XMALLOC (MTYPE_ROUTE_MAP_COMPILED, 4151 strlen (argv[idx_number]->arg) + strlen (argv[idx_ipv4]->arg) + 2); 4152 4153 sprintf (argstr, "%s %s", argv[idx_number]->arg, argv[idx_ipv4]->arg); 4154 >>> CID 1422684: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4155 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4156 "aggregator as", argstr); 4157 4158 XFREE (MTYPE_ROUTE_MAP_COMPILED, argstr); 4159 4160 return ret; ** CID 1422683: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422683: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 4113 in set_atomic_aggregate() 4107 DEFUN (set_atomic_aggregate, 4108 set_atomic_aggregate_cmd, 4109 "set atomic-aggregate", 4110 SET_STR 4111 "BGP atomic aggregate attribute\n" ) 4112 { >>> CID 1422683: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 4113 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 4114 "atomic-aggregate", NULL); 4115 } 4116 4117 DEFUN (no_set_atomic_aggregate, 4118 no_set_atomic_aggregate_cmd, ** CID 1422682: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422682: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3581 in set_ip_nexthop_peer() 3575 "set ip next-hop peer-address", 3576 SET_STR 3577 IP_STR 3578 "Next hop address\n" 3579 "Use peer address (for BGP only)\n") 3580 { >>> CID 1422682: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3581 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3582 "ip next-hop", "peer-address"); 3583 } 3584 3585 DEFUN (set_ip_nexthop_unchanged, 3586 set_ip_nexthop_unchanged_cmd, ** CID 1422681: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422681: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3724 in set_aspath_exclude() 3718 { 3719 int idx_asn = 3; 3720 int ret; 3721 char *str; 3722 3723 str = argv_concat (argv, argc, idx_asn); >>> CID 1422681: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3724 ret = generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), 3725 "as-path exclude", str); 3726 XFREE (MTYPE_TMP, str); 3727 return ret; 3728 } 3729 ** CID 1422680: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1422680: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3854 in set_community_none() 3848 set_community_none_cmd, 3849 "set community none", 3850 SET_STR 3851 "BGP community attribute\n" 3852 "No community attribute\n") 3853 { >>> CID 1422680: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3854 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "community", 3855 "none"); 3856 } 3857 3858 DEFUN (no_set_community, 3859 no_set_community_cmd, ________________________________________________________________________________________________________ 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

[frr] Please make your membership public on Github
by Martin Winter 30 Mar '17

30 Mar '17

I’ve noticed that only 3 members are “public” visible on the Github FRR. I would appreciate if everyone considers changing the setting to public. Would be nice to see a broader membership. Right now it looks like a very small community as most people are not seen (But there are another 18 members private and invisible) So, unless you prefer to keep your membership private, please go to https://github.com/orgs/freerangerouting/people and change your account to public. Thanks, Martin

2 1

[frr] making frr more public
by JR Rivers 28 Mar '17

28 Mar '17

As most of you know, we've been working with the Linux Foundation to host FRR. Open Network Summit is coming up in early April, and given the release readiness of FRR, it seems like a good time to make FRR more public. We have a few pieces of work associated to make this happen; one is a website, and the second is a blog post that Linux Foundation will issue. I've been working with a web designer on the site, and I've attached a non-interactive mock up below. I've also put together a straw proposal to introduce FRR. Looking for comments on these. There are two sections that announce participants in the FRR community, one is in the blog post, and the second is in the "Contributors" section at the bottom of the website. I took the blog list from Martin's presentation... please let me know directly if your company wants to be included in either section. Also happy to have people in your marketing departments speak with all of the others and the Linux Foundation people; just make the introduction, and I'll get the ball rolling. cheers, JR https://docs.google.com/document/d/1_9VRlQkvCiGfQPMtqND094gZuRGDq22tad_GdGQ…

6 9

Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route
by David Ahern 27 Mar '17

27 Mar '17

Eric's question below is basically adding labels at tunnel ingress vs while traversing the LSP. I was generically increasing both to more than 2 labels. Opinions? -------- Forwarded Message -------- Subject: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route Date: Sat, 25 Mar 2017 14:15:54 -0500 From: Eric W. Biederman <ebiederm(a)xmission.com> To: David Ahern <dsa(a)cumulusnetworks.com> CC: netdev(a)vger.kernel.org, roopa(a)cumulusnetworks.com, rshearma(a)brocade.com David Ahern <dsa(a)cumulusnetworks.com> writes: > Bump the maximum number of labels for MPLS routes from 2 to 12. To keep > memory consumption in check the labels array is moved to the end of mpls_nh > and mpls_iptunnel_encap structs as a 0-sized array. Allocations use the > maximum number of labels across all nexthops in a route for LSR and the > number of labels configured for LWT. > > The mpls_route layout is changed to: > > +----------------------+ > | mpls_route | > +----------------------+ > | mpls_nh 0 | > +----------------------+ > | alignment padding | 4 bytes for odd number of labels; 0 for even > +----------------------+ > | via[rt_max_alen] 0 | > +----------------------+ > | alignment padding | via's aligned on sizeof(unsigned long) > +----------------------+ > | ... | > > Meaning the via follows its mpls_nh providing better locality as the > number of labels increases. UDP_RR tests with namespaces shows no impact > to a modest performance increase with this layout for 1 or 2 labels and > 1 or 2 nexthops. > > The new limit is set to 12 to cover all currently known segment > routing use cases. How does this compare with running the packet a couple of times through the mpls table to get all of the desired labels applied? I can certainly see the case in an mpls tunnel ingress where this might could be desirable. Which is something you implement in your last patch. However is it at all common to push lots of labels at once during routing? I am probably a bit naive but it seems absurd to push more than a handful of labels onto a packet as you are routing it. Eric

4 4

Re: [frr] Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route
by Rodny Molina 27 Mar '17

27 Mar '17

> An MPLS packet may in transit receive additional labels. I most cases (all?), this will be most properly seen as a LSP hierarchy (tunneling one LSP into another LSP), so closer to a notion of ingress rather than something related to the initial LSP. But I don't know if the distinction is of importance. > > The cases that comes to mind would be: > - tunneling into a fast-reroute bypass LSP (possibly a segment routing LSP, see segment routing TI LFA) > - seamless MPLS > - carrier's carrier type of deployment <Rodny> I would add SR-policy as the most generic example. Ideally, any router along the path, being the (real / app-facing) head-end or not, should be capable of injecting a SID-list to enforce any given forwarding policy. So i believe that David’s patch is needed as is: to cover both ip->mpls and mpls->mpls scenarios. https://datatracker.ietf.org/doc/html/draft-filsfils-spring-segment-routing… <https://datatracker.ietf.org/doc/html/draft-filsfils-spring-segment-routing…> >> How does this compare with running the packet a couple of times through >> the mpls table to get all of the desired labels applied? <Rodny> I would like to know more about this one too. /Rodny > On Mar 26, 2017, at 3:23 PM, David Ahern via frr <frr(a)lists.nox.tf> wrote: > > > From: David Ahern <dsa(a)cumulusnetworks.com <mailto:dsa@cumulusnetworks.com>> > Subject: Re: Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route > Date: March 26, 2017 at 3:22:51 PM PDT > To: Thomas Morin <thomas.morin(a)orange.com <mailto:thomas.morin@orange.com>>, DUGEON Olivier IMT/OLN <olivier.dugeon(a)orange.com <mailto:olivier.dugeon@orange.com>>, "amine.kherbouche(a)6wind.com <mailto:amine.kherbouche@6wind.com>" <amine.kherbouche(a)6wind.com <mailto:amine.kherbouche@6wind.com>>, "jefftant(a)gmail.com <mailto:jefftant@gmail.com>" <jefftant(a)gmail.com <mailto:jefftant@gmail.com>>, "frr(a)lists.nox.tf <mailto:frr@lists.nox.tf>" <frr(a)lists.nox.tf <mailto:frr@lists.nox.tf>>, Bruno Decraene <bruno.decraene(a)orange.com <mailto:bruno.decraene@orange.com>>, roopa <roopa(a)cumulusnetworks.com <mailto:roopa@cumulusnetworks.com>> > > > On 3/26/17 11:02 AM, Thomas Morin wrote: >> Hi David, >> >> [adding my colleague Bruno to the list, he may correct things I might >> have oversimplified on segment routing, or have a idea about 12] >> >> 2017-03-25, David Ahern: >>> Eric's question below is basically adding labels at tunnel ingress vs >>> while traversing the LSP. I was generically increasing both to more than >>> 2 labels. Opinions? >> >> An MPLS packet may in transit receive additional labels. I most cases >> (all?), this will be most properly seen as a LSP hierarchy (tunneling >> one LSP into another LSP), so closer to a notion of ingress rather than >> something related to the initial LSP. But I don't know if the >> distinction is of importance. >> >> The cases that comes to mind would be: >> - tunneling into a fast-reroute bypass LSP (possibly a segment routing >> LSP, see segment routing TI LFA) >> - seamless MPLS >> - carrier's carrier type of deployment >> >> In these cases a router could receive an MPLS packet, and possibly after >> popping the topmost, push a stack of labels onto the packet. > > And that's my takeaway from past discussions on this topic (number of > labels). > >> >> About the email below: >> - how did 12 end up being considered "covering all currently known >> segment routing use cases" ? it seems that SR could use an arbitrary >> number of labels (not saying 12 is a bad number, but...) > > I believe the consensus was 8 but Olivier had a use case for more. The > way I have this coded means the performance impact is to users adding > more and more labels - which is expected and appropriate. > > >> - I'm not sure what Eric's idea of "running the packet a couple of times >> through the mpls table to get all of the desired labels applied" would >> mean: after the first lookup, what data would be used as key for the >> following lookup ? > > no idea. I need him to clarify. > > >> - back to your question, which seems to imply one could possibly >> increase number of labels for ingress without increasing number of >> labels for transit: isn't the same datastructure used in both to >> represent an mpls next hop (in RFC3031, both the ILM and FTN point to >> NHLFE entries, but I haven't digged enough to identify how these maps to >> the kernel implementation) > > no. Ingress is handled by a lightweight tunnel infrastructure. In 'ip' > terms the route specifies lwt with mpls encap. LSP MPLS is handled as a > typical protocol family with its own route database. > >> - would a concept of a linked list of mpls_nh make sense, each with one >> label to impose, make sense, so that no hard limit is put on the label >> stack depth? > > each nexthop has its own label stack. The nexthops are essentially an > array at the end of the mpls route. > > > > _______________________________________________ > frr mailing list > frr(a)lists.nox.tf <mailto:frr@lists.nox.tf> > https://lists.nox.tf/listinfo/frr <https://lists.nox.tf/listinfo/frr> On Mar 26, 2017, at 1:16 PM, Jeff Tantsura <jefftant(a)gmail.com> wrote: Hi Thomas, Good points. There’s no free lunch in fast path universe, packet recalculation has price associated with it, the most obvious things are increased latency and reduced throughput, there’s more. Sorry for repeating myself - not being linux kernel expert myself - I’d appreciate pros/cons analysis of taking different approaches, the impact of adding new code and system behavior with it. Those who expect the underlying platform to be not X86 only (Cumulus?) what are your expectation from HAL/ HW SDK prospective? Cheers, Jeff > On Mar 26, 2017, at 12:02, Thomas Morin <thomas.morin(a)orange.com> wrote: > > Hi David, > > [adding my colleague Bruno to the list, he may correct things I might have oversimplified on segment routing, or have a idea about 12] > > 2017-03-25, David Ahern: >> Eric's question below is basically adding labels at tunnel ingress vs >> while traversing the LSP. I was generically increasing both to more than >> 2 labels. Opinions? > > An MPLS packet may in transit receive additional labels. I most cases (all?), this will be most properly seen as a LSP hierarchy (tunneling one LSP into another LSP), so closer to a notion of ingress rather than something related to the initial LSP. But I don't know if the distinction is of importance. > > The cases that comes to mind would be: > - tunneling into a fast-reroute bypass LSP (possibly a segment routing LSP, see segment routing TI LFA) > - seamless MPLS > - carrier's carrier type of deployment > > In these cases a router could receive an MPLS packet, and possibly after popping the topmost, push a stack of labels onto the packet. > > About the email below: > - how did 12 end up being considered "covering all currently known segment routing use cases" ? it seems that SR could use an arbitrary number of labels (not saying 12 is a bad number, but...) > - I'm not sure what Eric's idea of "running the packet a couple of times through the mpls table to get all of the desired labels applied" would mean: after the first lookup, what data would be used as key for the following lookup ? > - back to your question, which seems to imply one could possibly increase number of labels for ingress without increasing number of labels for transit: isn't the same datastructure used in both to represent an mpls next hop (in RFC3031, both the ILM and FTN point to NHLFE entries, but I haven't digged enough to identify how these maps to the kernel implementation) > - would a concept of a linked list of mpls_nh make sense, each with one label to impose, make sense, so that no hard limit is put on the label stack depth? > > -Thomas > > > >> -------- Forwarded Message -------- >> Subject: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure >> more labels per route >> Date: Sat, 25 Mar 2017 14:15:54 -0500 >> From: Eric W. Biederman <ebiederm(a)xmission.com> >> To: David Ahern <dsa(a)cumulusnetworks.com> >> CC: netdev(a)vger.kernel.org, roopa(a)cumulusnetworks.com, rshearma(a)brocade.com >> >> David Ahern <dsa(a)cumulusnetworks.com> writes: >> >>> Bump the maximum number of labels for MPLS routes from 2 to 12. To keep >>> memory consumption in check the labels array is moved to the end of mpls_nh >>> and mpls_iptunnel_encap structs as a 0-sized array. Allocations use the >>> maximum number of labels across all nexthops in a route for LSR and the >>> number of labels configured for LWT. >>> >>> The mpls_route layout is changed to: >>> >>> +----------------------+ >>> | mpls_route | >>> +----------------------+ >>> | mpls_nh 0 | >>> +----------------------+ >>> | alignment padding | 4 bytes for odd number of labels; 0 for even >>> +----------------------+ >>> | via[rt_max_alen] 0 | >>> +----------------------+ >>> | alignment padding | via's aligned on sizeof(unsigned long) >>> +----------------------+ >>> | ... | >>> >>> Meaning the via follows its mpls_nh providing better locality as the >>> number of labels increases. UDP_RR tests with namespaces shows no impact >>> to a modest performance increase with this layout for 1 or 2 labels and >>> 1 or 2 nexthops. >>> >>> The new limit is set to 12 to cover all currently known segment >>> routing use cases. >> >> How does this compare with running the packet a couple of times through >> the mpls table to get all of the desired labels applied? >> >> I can certainly see the case in an mpls tunnel ingress where this might >> could be desirable. Which is something you implement in your last >> patch. However is it at all common to push lots of labels at once >> during routing? >> >> I am probably a bit naive but it seems absurd to push more >> than a handful of labels onto a packet as you are routing it. >> >> Eric >> > _______________________________________________ frr mailing list frr(a)lists.nox.tf https://lists.nox.tf/listinfo/frr

1 0

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

25 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1420923: Null pointer dereferences (REVERSE_INULL) /pimd/pim_msg.c: 112 in pim_msg_get_jp_group_size() ________________________________________________________________________________________________________ *** CID 1420923: Null pointer dereferences (REVERSE_INULL) /pimd/pim_msg.c: 112 in pim_msg_get_jp_group_size() 106 107 size += sizeof (struct pim_encoded_group_ipv4); 108 size += 4; // Joined sources (2) + Pruned Sources (2) 109 110 size += sizeof (struct pim_encoded_source_ipv4) * sources->count; 111 >>> CID 1420923: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "sources" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 112 js = listgetdata(listhead(sources)); 113 if (js && js->up->sg.src.s_addr == INADDR_ANY) 114 { 115 struct pim_upstream *child, *up; 116 struct listnode *up_node; 117 ** CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_route.c: 948 in ospf6_route_match_head() ________________________________________________________________________________________________________ *** CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_route.c: 948 in ospf6_route_match_head() 942 struct ospf6_route *route; 943 944 /* Walk down tree. */ 945 node = table->table->top; 946 while (node && node->p.prefixlen < prefix->prefixlen && 947 prefix_match (&node->p, prefix)) >>> CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Taking address with "&prefix->u.prefix" yields a singleton pointer. 948 node = node->link[prefix_bit(&prefix->u.prefix, node->p.prefixlen)]; 949 950 if (node) 951 route_lock_node (node); 952 while (node && node->info == NULL) 953 node = route_next (node); ** CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_lsdb.c: 252 in ospf6_lsdb_lookup_next() ________________________________________________________________________________________________________ *** CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_lsdb.c: 252 in ospf6_lsdb_lookup_next() 246 node = lsdb->table->top; 247 /* walk down tree. */ 248 while (node && node->p.prefixlen <= p->prefixlen && 249 prefix_match (&node->p, p)) 250 { 251 matched = node; >>> CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Taking address with "&p->u.prefix" yields a singleton pointer. 252 node = node->link[prefix_bit(&p->u.prefix, node->p.prefixlen)]; 253 } 254 255 if (matched) 256 node = matched; 257 else ________________________________________________________________________________________________________ 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

[frr] New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 21 Mar '17

21 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1420265: Resource leaks (RESOURCE_LEAK) /zebra/label_manager.c: 229 in assign_label_chunk() ________________________________________________________________________________________________________ *** CID 1420265: Resource leaks (RESOURCE_LEAK) /zebra/label_manager.c: 229 in assign_label_chunk() 223 else 224 lmc->start = ((struct label_manager_chunk *) 225 listgetdata(listtail(lbl_mgr.lc_list)))->end + 1; 226 if (lmc->start > MPLS_MAX_UNRESERVED_LABEL - size + 1) { 227 zlog_err("Reached max labels. Start: %u, size: %u", lmc->start, 228 size); >>> CID 1420265: Resource leaks (RESOURCE_LEAK) >>> Variable "lmc" going out of scope leaks the storage it points to. 229 return NULL; 230 } 231 lmc->end = lmc->start + size - 1; 232 lmc->proto = proto; 233 lmc->instance = instance; 234 lmc->keep = keep; ** CID 1420264: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1420264: Null pointer dereferences (NULL_RETURNS) /pimd/pim_nht.c: 563 in pim_parse_nexthop_update() 557 case NEXTHOP_TYPE_IPV6: 558 stream_get (&nexthop->gate.ipv6, s, 16); 559 break; 560 case NEXTHOP_TYPE_IPV6_IFINDEX: 561 stream_get (&nexthop->gate.ipv6, s, 16); 562 nexthop->ifindex = stream_getl (s); >>> CID 1420264: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "if_lookup_by_index(nexthop->ifindex, 0)" when calling "pim_neighbor_find_if". 563 nbr = 564 pim_neighbor_find_if (if_lookup_by_index 565 (nexthop->ifindex, VRF_DEFAULT)); 566 /* Overwrite with Nbr address as NH addr */ 567 if (nbr) 568 nexthop->gate.ipv4 = nbr->source_addr; ** CID 1420263: Null pointer dereferences (NULL_RETURNS) /ldpd/lde.c: 1624 in on_get_label_chunk_response() ________________________________________________________________________________________________________ *** CID 1420263: Null pointer dereferences (NULL_RETURNS) /ldpd/lde.c: 1624 in on_get_label_chunk_response() 1618 struct label_chunk *new_label_chunk; 1619 1620 log_debug("Label Chunk assign: %u - %u", start, end); 1621 1622 new_label_chunk = calloc(1, sizeof(struct label_chunk)); 1623 >>> CID 1420263: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "new_label_chunk". 1624 new_label_chunk->start = start; 1625 new_label_chunk->end = end; 1626 new_label_chunk->used_mask = 0; 1627 1628 listnode_add(label_chunk_list, (void *)new_label_chunk); 1629 ** CID 1420262: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nht.c: 519 in pim_parse_nexthop_update() ________________________________________________________________________________________________________ *** CID 1420262: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nht.c: 519 in pim_parse_nexthop_update() 513 __PRETTY_FUNCTION__, buf); 514 } 515 return; 516 } 517 } 518 >>> CID 1420262: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "pnc". 519 pnc->last_update = pim_time_monotonic_sec (); 520 distance = stream_getc (s); 521 metric = stream_getl (s); 522 nexthop_num = stream_getc (s); 523 524 if (PIM_DEBUG_TRACE) ________________________________________________________________________________________________________ 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

[frr] New Label manager has been committed
by Donald Sharp 21 Mar '17

21 Mar '17

Bingen has implemented a label manager. This allows the sharing of Label space across the whole of FRR. Thanks Bingen and everyone who's spent time working on this! donald

2 1

[frr] Todays Technical Meeting 11 am EDT
by Donald Sharp 21 Mar '17

21 Mar '17

https://bluejeans.com/9192742159 1) Stable/2.0 Release 2) Issues 3) PR's 4) I am at IETF next week no meeting 5) Anything else? donald

4 5