Kishore Aramalla [Mon, 10 Feb 2020 19:38:27 +0000 (11:38 -0800)]
bgpd: RFC compliance wrt invalid RMAC, GWIP, ESI and VNI
A route where ESI, GW IP, MAC and Label are all zero at the same time SHOULD
be treat-as-withdraw.
Invalid MAC addresses are broadcast or multicast MAC addresses. The route
MUST be treat-as-withdraw in case of an invalid MAC address.
As FRR support Ethernet NVO Tunnels only.
Route will be withdrawn when ESI, GW IP and MAC are zero or Invalid MAC
Test cases:
1) ET-5 route with valid RMAC extended community
2) ET-5 route no RMAC extended community
3) ET-5 route with Multicast MAC in RMAC extended community
4) ET-5 route with Broadcast MAC in RMAC extended community
Donald Sharp [Tue, 11 Feb 2020 00:25:52 +0000 (19:25 -0500)]
bgpd: Update failed reason to distinguish some NHT scenarios
Current failed reasons for bgp when you have a peer that
is not online yet is `Waiting for NHT`, even if NHT has
succeeded. Add some code to differentiate this.
eva# show bgp ipv4 uni summ failed
BGP router identifier 192.168.201.135, local AS number 3923 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor EstdCnt DropCnt ResetTime Reason
192.168.44.1 0 0 never Waiting for NHT
192.168.201.139 0 0 never Waiting for Open to Succeed
Total number of neighbors 2
eva#
eva# show bgp nexthop
Current BGP nexthop cache:
192.168.44.1 invalid, peer 192.168.44.1
Must be Connected
Last update: Mon Feb 10 19:05:19 2020
Ameya Dharkar [Thu, 6 Feb 2020 21:47:43 +0000 (13:47 -0800)]
bgpd: EVPN crash because of incorrect nexthop for IPv6 prefix
RCA:
When we install IPv6 prefix imported from EVPN RT-5 in vrf, nexthop of the IPv6
route should be IPv4 mapped IPv6 address. In function
install_evpn_route_entry_in_vrf, we generate a new attribute with IPv4 mapped
IPv6 nexthop, but we use parent->attr while creating the actual route.
Thus, Ipv4 nexthop is assigned to this route.
Because of this incorrect nexthop, we observed a crash in function
update_ipv6nh_for_route_install.
Fix:
Pass the new attribute with Ipv4 mapped Ipv6 nexthop to
bgp_create_evpn_bgp_path_info
Rafael Zalamena [Mon, 30 Sep 2019 13:34:49 +0000 (10:34 -0300)]
lib: implement route map northbound
Based on the route map old CLI, implement the route map handling using
the exported functions.
Use a curry-like programming pattern avoid code repetition when
destroying match/set entries. This is needed by other daemons that
implement custom route map functions and need to pass to lib their
specific destroy functions.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rafael Zalamena [Fri, 27 Sep 2019 22:32:10 +0000 (19:32 -0300)]
yang: update route map model
Important changes:
* Rename top container `route-map` to `lib`;
* Rename list `instance` to `route-map`;
* Move route map repeated data to list `entry`;
* Use interface reference instead of typedef'ed string;
* Remove some zebra specific route map conditions;
* Protect `tag` set value with `when "./action = 'tag'"`;
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Stephen Worley [Tue, 4 Feb 2020 16:35:31 +0000 (11:35 -0500)]
doc: indicate non-support for dynamic pbr maps
Indicate in the doc clearly that we do not support the dynamic
creation of pbr maps for sub-interfaces when the master has
an interface. Such as in vlans. It must be explicitly added.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Donald Sharp [Mon, 13 Jan 2020 21:11:46 +0000 (16:11 -0500)]
zebra: nexthop groups vrf's are only a function of namespaces
Nexthop groups as a whole do not make sense to have a vrf'ness
As that you can have a arbitrary number of nexthops that point
to separate vrf's.
Modify the code to make this distinction, by clearly delineating
the line between the nhg and the nexthop a bit better.
Nexthop groups having a vrf_id only make sense if you are using
network namespaces to represent them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 13 Jan 2020 21:00:33 +0000 (16:00 -0500)]
zebra: Modify 'show nexthop-group rib ip|ipv6'
The zebra implementation of nexthop groups has
two types of nexthops groups currently. Singleton
objects which have afi's and combined nexthop groups
that do not. Specifically call this out in the code
to make this distinction.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Santosh P K [Thu, 9 Jan 2020 17:53:27 +0000 (09:53 -0800)]
zebra: Capabality and stale route handling for GR client.
Handling capability received from client. It may contain
GR enable/disable, Stale time changes, RIB update complete
for given AFi, ASAFI and instance. It also has changes for
stale route handling.
Stephen Worley [Mon, 6 Jan 2020 18:33:45 +0000 (13:33 -0500)]
zebra: reset nexthop pointer in zread of nexthops
We were not resetting the nexthop pointer to NULL for each
new read of a nexthop from the zapi route. On the chance we
get a nexthop that does not have a proper type, we will not
create a new nexthop and update that pointer, thus it still
has the last valid one and will create a group with two
pointers to the same nexthop.
Then when it enters any code that iterates the group, it loops
endlessly.
This was found with zapi fuzzing.
```
0x00007f728891f1c3 in jhash2 (k=<optimized out>, length=<optimized out>, initval=12183506) at lib/jhash.c:138
0x00007f728896d92c in nexthop_hash (nexthop=<optimized out>) at lib/nexthop.c:563
0x00007f7288979ece in nexthop_group_hash (nhg=<optimized out>) at lib/nexthop_group.c:394
0x0000000000621036 in zebra_nhg_hash_key (arg=<optimized out>) at zebra/zebra_nhg.c:356
0x00007f72888ec0e1 in hash_get (hash=<optimized out>, data=0x7ffffb94aef0, alloc_func=0x0) at lib/hash.c:138
0x00007f72888ee118 in hash_lookup (hash=0x7f7288de2f10, data=0x7f728908e7fc) at lib/hash.c:183
0x0000000000626613 in zebra_nhg_find (nhe=0x7ffffb94b080, id=0, nhg=0x6020000032d0, nhg_depends=0x0, vrf_id=<optimized out>,
afi=<optimized out>, type=<optimized out>) at zebra/zebra_nhg.c:541
0x0000000000625f39 in zebra_nhg_rib_find (id=0, nhg=<optimized out>, rt_afi=AFI_IP) at zebra/zebra_nhg.c:1126
0x000000000065f953 in rib_add_multipath (afi=AFI_IP, safi=<optimized out>, p=0x7ffffb94b370, src_p=0x0, re=0x6070000013d0,
ng=0x7f728908e7fc) at zebra/zebra_rib.c:2616
0x0000000000768f90 in zread_route_add (client=0x61f000000080, hdr=<optimized out>, msg=<optimized out>, zvrf=<optimized out>)
at zebra/zapi_msg.c:1596
0x000000000077c135 in zserv_handle_commands (client=<optimized out>, msg=0x61b000000780) at zebra/zapi_msg.c:2636
0x0000000000575e1f in main (argc=<optimized out>, argv=<optimized out>) at zebra/main.c:309
```
Stephen Worley [Mon, 6 Jan 2020 17:58:41 +0000 (12:58 -0500)]
zebra: don't created connected if duplicate depend
Since we are using a UNIQUE RB tree, we need to handle the
case of adding in a duplicate entry into it.
The list API code returns NULL when a successfull add
occurs, so lets pull that handling further up into
the connected handlers. Then, free the allocated
connected struct if it is a duplicate.
This is a pretty unlikely situation to happen.
Also, pull up the RB handling of _del RB API as well.
This was found with the zapi fuzzing code.
```
==1052840==
==1052840== 200 bytes in 5 blocks are definitely lost in loss record 545 of 663
==1052840== at 0x483BB1A: calloc (vg_replace_malloc.c:762)
==1052840== by 0x48E1008: qcalloc (memory.c:110)
==1052840== by 0x44D357: nhg_connected_new (zebra_nhg.c:73)
==1052840== by 0x44D300: nhg_connected_tree_add_nhe (zebra_nhg.c:123)
==1052840== by 0x44FBDC: depends_add (zebra_nhg.c:1077)
==1052840== by 0x44FD62: depends_find_add (zebra_nhg.c:1090)
==1052840== by 0x44E46D: zebra_nhg_find (zebra_nhg.c:567)
==1052840== by 0x44E1FE: zebra_nhg_rib_find (zebra_nhg.c:1126)
==1052840== by 0x45AD3D: rib_add_multipath (zebra_rib.c:2616)
==1052840== by 0x4977DC: zread_route_add (zapi_msg.c:1596)
==1052840== by 0x49ABB9: zserv_handle_commands (zapi_msg.c:2636)
==1052840== by 0x428B11: main (main.c:309)
```
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Santosh P K [Thu, 9 Jan 2020 16:39:50 +0000 (08:39 -0800)]
zebra: Handling of connection disconnect and connect with GR.
Zebra will have special handling for clients with GR enabled.
When client disconnects with GR enabled, then a stale client
will be created and its RIB will be retained till stale timer
or client comes up and updated its RIB.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Soman K S <somanks@vmware.com> Signed-off-by: Santosh P K <sapk@vmware.com>
Santosh P K [Tue, 22 Oct 2019 14:01:58 +0000 (07:01 -0700)]
zebra: Header file changes and show commands.
Adding header files changes where structure to hold
received graceful restart info from client is defined.
Also there are changes for show commands where exisiting
commands are extended.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Soman K S <somanks@vmware.com> Signed-off-by: Santosh P K <sapk@vmware.com>
Santosh P K [Wed, 29 Jan 2020 06:50:27 +0000 (22:50 -0800)]
lib: Adding GR capabilites encode and decode.
For Graceful restart clients have to send GR capabilities
library functions are added to encode capabilities and
also for zebra to decode client capabilities.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Soman K S <somanks@vmware.com> Signed-off-by: Santosh P K <sapk@vmware.com>
projects / mirror_frr.git / log