The input queue limit does not belong under router bgp. This
is a dev escape and should just be removed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Consider this scenario:
Lots of peers with a bunch of route information that is changing
fast. One of the peers happens to be really slow for whatever
reason. The way the output queue is filled is that bgpd puts
64 packets at a time and then reschedules itself to send more
in the future. Now suppose that peer has hit it's input Queue
limit and is slow. As such bgp will continue to add data to
the output Queue, irrelevant if the other side is receiving
this data.
Let's limit the Output Queue to the same limit as the Input
Queue. This should prevent bgp eating up large amounts of
memory as stream data when under severe network trauma.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Until we have a consensus how we ship stable/X.Y docker images.
For now we build images based on release tags, not based on HEAD of the branch.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Tests are failing in micronet because linux kernel needs are 4.19
not 4.15
2023-01-11 17:15:06,657.657 INFO: topolog.r1: vtysh command => "show zebra"
2023-01-11 17:15:06,657.657 DEBUG: topolog.r1: LinuxNamespace(r1): cmd_status("['/bin/bash', '-c', 'vtysh -c "show zebra" 2>/dev/null']", kwargs: {'encoding': 'utf-8', 'stdout': -1, 'stderr': -2, 'shell': False, 'stdin': None})
2023-01-11 17:15:06,729.729 INFO: topolog.r1: vtysh result:
OS Linux(4.15.0-193-generic)
Notice the missing pimreg11 device needed in vrf blue:
2023-01-11 17:15:06,731.731 DEBUG: topolog.r1: LinuxNamespace(r1): cmd_status("['/bin/bash', '-c', 'vtysh -c "show int brief" 2>/dev/null']", kwargs: {'encoding': 'utf-8', 'stdout': -1, 'stderr': -2, 'shell': False, 'stdin': None})
2023-01-11 17:15:06,781.781 INFO: topolog.r1: vtysh result:
Interface Status VRF Addresses
--------- ------ --- ---------
blue up blue 192.168.0.1/32
r1-eth0 up blue 192.168.100.1/24
r1-eth1 up blue 192.168.101.1/24
Interface Status VRF Addresses
--------- ------ --- ---------
erspan0 down default
gre0 down default
gretap0 down default
lo up default
pimreg up default
Interface Status VRF Addresses
--------- ------ --- ---------
r1-eth2 up red 192.168.100.1/24
r1-eth3 up red 192.168.101.1/24
red up red 192.168.0.1/32
While on a 5.4 machine we have this:
mininet310# show int brief
Interface Status VRF Addresses
--------- ------ --- ---------
blue up blue
dummy1 up blue
dummy2 up blue
pimreg11 up blue
As such let's limit the test to a 4.19 kernel or above that our
documentations states we need for proper pim operation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For now, if the order was mixed, most of the commands are just silently
ignored. Let the operator notice that.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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 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>
