Sarita Patra [Tue, 3 Mar 2020 09:51:03 +0000 (01:51 -0800)]
pimd: Clear (s,g,rpt) ifchannel on (*, G) prune received
Issue: After SPT switchover, do shut and no-shut the received connected
interface, traffic stops.
R2
| |
+ +
Client-----R1--------R3----Source
R2 is RP.
Root cause:
Client is sending join for G and Source is sending traffic for G.
Before SPT switchover, traffic flows R3-R2-R1, after SPT switchover,
traffic flows R3-R1. Now Check in R2, there will be 2 ifchannel gets
created. first is (*, G) ifchannel which gets created because of (*, G)
join received from R1, second is (S, G) ifchannel which gets created
because of (s,g,rpt) prune received from R1
Shut the receiver connected interface on R1, R1 will send a (*, G) prune
towards RP (R2). On receiving (*, G) prune, R2 deletes the (*, G) ifchannel.
(s,g) ifchannel with flag (s,g,rpt) set will be timeout after the prune timer
expires. Before this timer expires, do noshut the received connected inrterface
on R1. R1 will send a (*,G) join to R2(RP), So oil will be updated in (*, G),
but wont get updated in (s,g) since the flag (s,g,rpt) is set. So traffic flow
stops.
Fix: When (*, G) ifchannel is getting deleted because of (*, G) prune
received, as (*,G) prune indicates that the router no longer wishes
to receive shared tree traffic, so clear (S,G,RPT) flag on all the child (S,G)
ifchannel, which was created because of (S,G,RPT) prune received
Donald Sharp [Sat, 15 Feb 2020 20:38:48 +0000 (15:38 -0500)]
bgpd: Add a couple more spaces for output on MsgRcvd and MsgSent
annie# show bgp ipv4 uni summ
BGP router identifier 192.168.201.136, local AS number 64539 vrf-id 0
BGP table version 22458946
RIB entries 1458006, using 178 MiB of memory
Peers 4, using 68 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
45.33.5.119 4 0 0 0 0 0 0 never Active
65.19.134.122 4 15096 4611832 108292 0 0 0 6d22h55m 800670
107.13.46.23 4 0 0 0 0 0 0 never Connect
robot(192.168.201.139) 4 64540 1115997511365599 0 0 0 05w2d05h Connect
Total number of neighbors 4
On very busy systems The column output for MsgRcvd and MsgSent can quickly move past 7 columns.
Add a couple more to allow for even display.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sun, 16 Feb 2020 19:14:04 +0000 (14:14 -0500)]
lib: Fix so that `--enable-pcreposix` actually compiles
The `--enable-pcreposix` configure option was not actually compiling
properly. Follow pre-existing pattern for inclusion of regex.h
or the pcreposix.h header.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don Slice [Mon, 10 Feb 2020 18:58:41 +0000 (18:58 +0000)]
zebra: add all ipv6 global addresses to RA messages
RFC 4861 states that ipv6 RA messages sent out an interface should
contain all global ipv6 addresses on that interface. This fix adds
that capability. To override the default flags and timer settings
for a particular prefix, the existing "ipv6 nd prefix ..." command
should be used via vtysh under the appropriate interface.
Ticket: CM-20363 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
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>