These really don't serve much of a purpose, especially with how
inconsistently they're used.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Only pim_sgaddr uses are covered by this since regular in_addr is still
used for singular addresses, so only a part of pim_inet4_dump calls are
gone with this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Need a separate constant that is IPv6 when needed. Also assign the
whole struct rather than just s_addr.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replaces comparison against INADDR_ANY, so we can do IPv6 too.
(Renamed from "pim_is_addr_any" for "pim_addr_*" naming pattern, and
type fixed to bool.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... and replace with `%pSG` printfrr specifier. This actually used a
static buffer in the formatting function, so subsequent formatting would
overwrite earlier uses.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
'show bgp ... neighbor [routes|received-routes]' both incorrectly
used a json key of 'advertisedRoutes'.
This corrects the key to be 'receivedRoutes' for commands where
the displayed routes were received, not advertised.
before:
unet> r3 show ip bgp neigh 10.2.30.2 received-routes json | include Routes
"advertisedRoutes":{
after:
ub18# show ip bgp neighbors enp1s0 received-routes json | include Routes
"receivedRoutes":{
ub18# show ip bgp neighbors enp1s0 advertised-routes json | include Routes
"advertisedRoutes":{
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Instead of referring to the draft of IP Prefix Advertisement in
Ethernet VPN let's point to the recently published RFC9136.
Signed-off-by: Marlin Cremers <marlin@cbws.nl>
Adding an `s` after these printfrr specifiers replaces 0.0.0.0 / :: in
the output with a star (`*`). This is primarily intended for use with
multicast, e.g. to print `(*,G)`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
checkpatch.pl has a hardcoded list of printf extensions supported... by
the Linux kernel. This happens to have covered the ones we have in FRR
so far, but `%pPA` isn't on the list and others may not be either.
Since we have the frr-format GCC plugin (and CI runs that on Debian 11)
we don't really need these checks in checkpatch.pl.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Topology:
IXIA-----(ens192)FRR(ens224)------iXIA
Configuration:
1. Create 8 sub-interfaces on ens192 under Default VRF and configure 8
EBGP session between FRR and IXIA.
2. Create 1000 sub-interfaces on ens224 under Default VRF and configure
1000 EBGP session between FRR and IXIA.
3. 2M prefixes distributed from Left side Ixia each with 8 ECMP path.
4. So in total, there are 2M prefixes * 8 ECMP = 16M prefixes entries
in RIB and FIB.
Issue:
Shut ens192 and ens224, this is taking 1hr 15 mins to clean up the routes.
Root Cause:
In the case of route deletion, if the particular route node is having
nht count = 0, we are going to the parent and doing nht evaluation,
which is not needed.
Fix:
If the deleted the route node is having nht count > 0, then do a nht
evaluation on the parent node.
Shut ens192 and ens224, it is taking 1 min to clean up the routes
with the fix.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Track what conditionals apply when a DEFPY is encountered, and stack
them around the autogenerated clippy wrapper. Otherwise conditional
DEFPYs result in undefined function warnings.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Used for graceful-restart mostly.
Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi()
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Fix the code as per RFC 2236 section 2.5:
Note that IGMP messages may be longer than 8 octets, especially
future backwards-compatible versions of IGMP. As long as the Type is
one that is recognized, an IGMPv2 implementation MUST ignore anything
past the first 8 octets while processing the packet. However, the
IGMP checksum is always computed over the whole IP payload, not just
over the first 8 octets.
Fixes: #10331
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
As per test case IGMP Conformance test case 5.6, report
messages longer than 8 octets should be accepted to support
future-backward compatibilty.
Fix the code as per RFC 2236 section 2.5:
Note that IGMP messages may be longer than 8 octets, especially
future backwards-compatible versions of IGMP. As long as the Type is
one that is recognized, an IGMPv2 implementation MUST ignore anything
past the first 8 octets while processing the packet. However, the
IGMP checksum is always computed over the whole IP payload, not just
over the first 8 octets.
Fixes: #10331
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>