Introduce a "detail" keyword for per-neighbor/per-afi-safi
advertised-routes and received-routes show commands.
Includes json support.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When FRR receives a netlink message that it decides to stop parsing
it returns a 0 ( instead of a -1 ). Just make the dplane continue
reading other data instead of aborting the read.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The build failed if two conditions are met at the same time:
1. Configure with `--disable-dependency-tracking`
2. Set an indenpendent build directory
```
anlan@host:~/frr/build$ make
make: Entering directory '/home/anlan/frr/build'
true
/usr/bin/perl ../vtysh/daemons.pl zebra bgpd ripd ripngd ospfd ospf6d isisd fabricd nhrpd ldpd babeld eigrpd pimd pim6d pbrd staticd bfdd vrrpd pathd > vtysh/vtysh_daemons.h
/bin/bash: line 1: vtysh/vtysh_daemons.h: No such file or directory
make: *** [Makefile:17644: vtysh/vtysh_daemons.h] Error 1
make: Leaving directory '/home/anlan/frr/build'
```
`~/frr/` is source directory, `~/frr/build/` is the specified build
directory.
So, just create necessary directory - `vtysh/`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The override.css/js files for sphinx docs were not being included into
the tarball created by `make dist`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If symvalid is false, looking at symidx is bogus.
This fixes a build-time SEGV on mips64el.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
mips64el does not have a 64-bit PC-relative relocation, which is needed
to emit the ELF note for xrefs. Disabling the ELF note means clippy
takes the fallback path using section headers, so everything does still
work (... unless you strip the section headers.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Most 32-bit architectures cannot do atomic loads and stores of data
wider than their pointer size, i.e. 32 bit. Funnily enough they
generally *can* do a CAS2, i.e., 64-bit compare-and-swap, but while a
CAS can emulate atomic add/bitops, loads and stores aren't available.
Replace with a mutex; since this is 99% used from the zserv thread, the
mutex should take the local-to-thread fast path anyway. And while one
atomic might be faster than a mutex lock/unlock, we're doing several
here, and at some point a mutex wins on speed anyway.
This fixes build on armel, mipsel, m68k, powerpc, and sh4.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Alpine upstream changed the name of the isl package to isl-dev. This
caused the build breakage. Since FRR doesn't use it, we chose to solve
this issue by removing it.
Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
When FRR receives a route from the kernel about the route
offload success/failure. The metric being reported is not
going to be correct since we may not know it appropriately
at this point in time. If we can set the metric to something
appropriate.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we are notified about the kernel about a route being offloaded
or not correctly set the distance.
Ticket: CM-33097
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Added ipv4 and ipv6 option to existing "show bgp nexthop"
command to be able to query nexthops that belong to a
particular address-family.
Also fixed the warnings of MR 12171
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
When creating one interface "vxlan66" ( ip link add vxlan66 type vxlan ... ),
which initially maintains down status, saw one unexpected EC log:
```
zebra[37906]: [ZAG0W-VSNSD] interface vxlan66 vrf default(0) index 35 becomes active.
zebra[37906]: [HPWGA-Y527W] IFLA_VXLAN_LINK missing from VXLAN IF message
...
zebra[37906]: [W6BZR-YZPAB] RTM_NEWLINK update for vxlan66(35) sl_type 0 master 0 flags 0x1002
zebra[37906]: [MR3ZF-ATDBY] Intf vxlan66(35) has gone DOWN
zebra[37906]: [T44X9-FFNVB] Intf vxlan66(35) L2-VNI 66 is DOWN
zebra[37906]: [KEGYY-K8XVV] Send EVPN_DEL 66 to bgp
zebra[37906]: [HPWGA-Y527W] IFLA_VXLAN_LINK missing from VXLAN IF message
bgpd[37911]: [TV0XP-3WR0A] Rx VNI del VRF default VNI 66 tenant-vrf default SVI ifindex 0
bgpd[37911]: [MDW89-YAXJG][EC 33554497] 0: VNI hash entry for VNI 66 not found at DEL
```
Since commit `6f908ded80eeba40a850e8d1f6246fb3ed31e648` support interfaces
from down to down, and bgpd doesn't know "VNI 66" at all. So, remove this
EC log.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
New show command "show evpn mac vni xx detail [json]"
to display details of all the mac entries for the
requested VNI.
Output of show evpn mac vni xx detail json:
{
"numMacs":2,
"macs":{
"ca:be:63:7c:81:05":{
"type":"local",
"intf":"veth100",
"ifindex":8,
"uptime":"00:06:55",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false,
"syncNeighCount":0,
"neighbors":{
"active":[
"fe80::c8be:63ff:fe7c:8105"
],
"inactive":[
]
}
}
}
}
Also added remoteEs field in the JSON output of
"show evpn mac vni xx json".
Output of show evpn mac vni xx json:
"00:02:00:00:00:0d":{
"type":"remote",
"remoteEs":"03:44:38:39:ff:ff:02:00:00:02",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Previously, routes leaked from one VRF to another VRF were associated
with the original nexthop interface.
Commit 14aabc0156 replaced the nexthop
interface with the index of incoming VRF interface.
Due to this change, the `bgp_srv6l3vpn_route_leak` topotest always fails
because it still expects the nexthop interface.
This commit fixes the expected interface name in the
`bgp_srv6l3vpn_route_leak` topotest.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
