The test case is with `redirect-off` in evpn multi-homing environment:
```
evpn mh redirect-off
```
After the environment is setup, do the following steps:
1) Let one member of ES learn one mac:
```
2e:52:bb:bb:2f:46 dev ae1 vlan 100 master bridge0 static
```
Now everything is ok and the mac can be synced to other ES peers.
2) Shutdown bond1. At this time, zebra will get three netlink messages,
not one as current code expected. Like:
```
e4:f0:04:89:b6:46 dev vxlan10030 vlan 30 master bridge0 static <-A
e4:f0:04:89:b6:46 dev vxlan10030 nhid 536870913 self extern_learn <-B
e4:f0:04:89:b6:46 dev vxlan10030 vlan 30 self <-C
```
With A), zebra will wrongly remove this mac again:
```
ZEBRA: dpAdd remote MAC e4:f0:04:89:b6:46 VID 30
ZEBRA: Add/update remote MAC e4:f0:04:89:b6:46 intf vxlan10030(26) VNI 10030 flags 0xa01 - del local
ZEBRA: Send MACIP Del f None MAC e4:f0:04:89:b6:46 IP (null) seq 0 L2-VNI 10030 ESI - to bgp
```
With C), zebra will wrongly add this mac again:
```
ZEBRA: Rx RTM_NEWNEIGH AF_BRIDGE IF 26 VLAN 30 st 0x2 fl 0x2 MAC e4:f0:04:89:b6:46 nhg 0
ZEBRA: dpAdd remote MAC e4:f0:04:89:b6:46 VID 30
```
zebra should skip the two messages with `vid`. Otherwise, it will send many
*wrong* messages to bgpd, and the logic is wrong.
`nhg/dst` is in 2nd message without `vid`, it is useful to call
`zebra_evpn_add_update_local_mac()`. But it will fail with "could not find EVPN"
warning for no `vid`, can't call `zebra_evpn_add_update_local_mac()`:
With B):
```
ZEBRA: Rx RTM_NEWNEIGH AF_BRIDGE IF 26 st 0x2 fl 0x12 MAC e4:f0:04:89:b6:46 nhg 536870913
ZEBRA: dpAdd local-nw-MAC e4:f0:04:89:b6:46 VID 0
ZEBRA: Add/Update MAC e4:f0:04:89:b6:46 intf ae1(18) VID 0, could not find EVPN
```
Here, we can get `vid` from vxlan interface instead of from netlink message.
In summary, `zebra_vxlan_dp_network_mac_add()` will process the three messages
wrongly expecting only one messsage, so its logic is wrong. Just skip the two
unuseful messages with `vid`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
`struct prefix` is a superset of `struct prefix_ipv4` and
`struct prefix_ipv6`. Let's let coverity figure it out
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The format message checks done by clippy/xrelfo were still guarded
behind `--enable-dev-build`. They've been clean and reliable, so it's
time to enable them unconditionally.
Fixes: #11680
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add a send time into the BFD Echo packet. When the BFD Echo
packet is received back store time it took in usec. When
user issues a show bfd peer(s) command calculate and display
minimum, average, and max time it took for the BFD Echo packet
to be looped back.
Signed-off-by: Lynne Morrison <lynne.morrison@ibm.com>
Change the show running commands for bsm and vxlan pimv4 and pimv6
debug commands based on the address family.
Including bsm and vxlan in no debug pimv6 debug.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
In CSPF topo test, valgrind detects uninitialized bytes when exporting TE
Opaque information through ZEBRA. This is due to C pragma compilation directive
__attribute__(aligned(8)) in struct ls_node_id in link_state.h. Valgrind
consideris that struct ls_node_id nid = {} doesn't initialized the padding
bytes introduced by gcc.
This patch simply removes the C pragma compilation directive and also takes
opportunity to remove the transmission of remote node id for vertices and
subnets which is not known. Indeed, remote node id is only pertinent for
edges.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
The bgp_path_info_to_ipv6_nexthop will correctly set
the nexthop value. There is no need to test this to
display something that won't be used in debug
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test is sometimes failing when it looks at the
v6 routes in the fib. Since the step before is
ensuring that v3 ospf has just converged let's
give it a bit of time to find and see if things
have had a chance to install the routes too.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test directory takes almost 7 minutes to complete splitting
this up into 3 test files drops it down to just over 3 minutes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
fixes the recent support bmp monitor of VPNv4 afi/safi
the bmp updates messages (MP_REACH_NLRI) are never sent for VPNv4 and bmp withdraws (MP_UNREACH_NRLI) are sent instead
this is caused by bgp_node_lookup which fails to find VPNv4 bgp_node in the rib which results in NULL path info attributes passed to bmp_monitor
using bgp_afi_node_lookup instead of bgp_node_lookup solves the problem
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
Updated /doc/topotests.rst with socat details,
which is needed to run PIMv6 tests. Socat tool
is used to send PIMv6 join and traffic.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Allow the same group/source route to be configured on more than one interface.
Currently FRR doesn't allow adding the same mroute on different input interfaces.
Current behavior, if we have the following config:
```
interface eth1
ip mroute eth0 239.0.0.1
interface eth2
ip mroute eth0 239.0.0.1
```
Only one multicast route will be installed with an input interface of the last
interface configured.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Topology:
R1(LHR) ---- R2 ----R4(FHR)
---- R3 ----
R2 = RP
Steps to reproduce:
1. R1(LHR) sends IGMP join, R4(FHR) sends multicast traffic.
Verify traffic is flowing from FHR to LHR.
2. Restart R1(LHR).
3. Below sequence of events are happening after FRR restart in R1(LHR).
4. R1(LHR) Register RP address to Zebra.
5. R1(LHR) Receive update from Zebra that R2(RP) is reachable via R3.
6. R1(LHR) Receive IGMP join for group 225.1.1.1, will create pim upstream
and (*,G) mroute with IIF towards R3.
7. R1(LHR) Receive update from Zebra that RP is reachable via R2(RP).
8. R1(LHR) Update the PIM upstream IIF, but not updating the (*,G) IIF
even there is RPF change.
9. R1(LHR) receives IGMP join for group 225.1.1.2, will create (*,G) with
IIF towards R2(RP), both upstream and (,G) created with IIF towards R2(RP).
Root Cause:
Mroute IIF is not getting updated when better route update
received. It is still pointing to the older nexthop.
Fix:
Update the mroute IIF when there is change in nexthop.
Fixing Issue #11675
Signed-off-by: Sarita Patra <saritap@vmware.com>
New function setsockopt_tcp_keepalive() is added to enable TCP keepalive
mechanism for specified socket. Also TCP keepalive idle time, interval
and maximum probes are configured.
Signed-off-by: Xiaofeng Liu <xiaofeng.liu@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
