When setting maximum-prefix-out on peer-group, the applied value on
member is 0.
Fix usage of maximum-prefix-out on peer-group.
The peer_maximum_prefix_out_(un)set functions are derived from
peer_maximum_prefix_(un)set.
Fixes: fde246e835 ("bgpd: Add an option to limit outgoing prefixes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Test the ability to use the following configure command with a Y value:
no neighbor X.X.X.X maximum-prefix-out Y
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Specifying a number is not possible with command no neighbor X.X.X.X
maximum-prefix-out
> frr(config-router-af)# no neighbor 192.168.1.2 maximum-prefix-out 1
> % Unknown command: no neighbor 192.168.1.2 maximum-prefix-out 1
This patch allows it.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The current maximum-prefix-out topo-test starts a configuration with a
maximum-prefix-out.
Test the application of new maximum-prefix-out value without clearing
the neighbor.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Abstract:
- The command "neighbor PEER maximum-prefix-out NUMBER" cannot be applied
without clearing the BGP neighbor.
- Apply the maximum-prefix-out value as soon as it is modified without
clearing the neighbor.
subgroup_update_packet() and subgroup_withdraw_packet() respectively
manages the announcement and withdrawal BGP message to the peer.
subgrp->scount counter counts the number of sent prefixes.
Before the patch, the maximum out prefix limitation was applied in
subgroup_update_packet() in order that subgrp->scount never exceeds the
limit. Setting a limit inferior to the effective number of sent prefix
did not result in sending any withdrawal message to reduce the number of
sent prefixes. Without clearing the BGP neighbor, the limitation only
applied to the announcement of new prefixes when the limitation was
over.
With the patch, the limitation is checked in subgroup_announce_check().
The function is intended to say whether a prefix has to be announced in
regards to the prefix-list, route-map... Now when a maximum-prefix-out
value is changed/removed, the neighbor AFI/SAFI table is re-parsed in
the same way as for the application of route-map, prefix-lists...
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Take into account the maximum-prefix-out value when calculating the
update-group hash.
Fixes: fde246e835 ("bgpd: Add an option to limit outgoing prefixes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Renamed frr-igmp.yang to frr-gmp.yang, igmp to gmp container.
to support IGMP and MLD protocol.
frr-gmp.yang, created a list of address family under mgmd
container. For PIMV4 the key is IPV4, where as for PIMV6
the key is IPV6. This is done for PIMV6 development.
This commit will have all the northbound changes to support
IPV4 address family.
Signed-off-by: sarita patra <saritap@vmware.com>
'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>
frr-pim.yang, created a list of address family under pim
container. For PIMV4 the key is IPV4, where as for PIMV6
the key is IPV6. This is done for PIMV6 development.
This commit will have all the northbound changes to support
IPV4 address family.
Signed-off-by: sarita patra <saritap@vmware.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>
