The usage of the `bgp bestpath med missing-as-worst` command
was being accepted and applied during bestpath, but during output
of the routes affected by this it would not give any indication
that this was happening or what med value was being used.
Fixes: #15718
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit bc9885b22e)
With a BGP configuration with ipv4 peering, and ipv6 peering, an snmpwalk
is stopped while walking over the bgp4v2NlriTable
snmpwalk -c TEST -v2c -On -Ln 1.1.1.2 .1.3.6.1.3.5.1.1.4
[...]
.1.3.6.1.3.5.1.1.4.1.2.1.2.32.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = Gauge32: 13380
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
>= .1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0
The walk stopped because the index used in the NlriTable entries is
decrementing, and this is against the snmp specifications. Also, the
computed index is wrong, and does not match the provided
draft-ietf-idr-bgp4-mibv2-1 specification.
Fix this by computing a valid index, and by finding out the next
consecutive prefix.
The resulting changes do not break the walk, and the output is changed:
root@dut-vm:~# snmpwalk -v 2c -c public -Ln -On localhost 1.3.6.1.3.5.1.1.9.1
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A C8 00 00
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A F4 00 00
Fixes: c681e937d7 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 1)
Fixes: 2ce69011c4 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 2)
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit fc3c9b177c)
Fix the documentation for the pbr map command with
correct syntax.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit df3d91f085)
With the deprecation of the global "bgp enforce-first-as" command back
in https://github.com/FRRouting/frr/pull/2259 the newly introduced
option to enable that setting on a specific peer was not documented.
This commit adds the necessary documentation and states the command's
default.
Signed-off-by: Manuel Schweizer <manuel.schweizer@cloudscale.ch>
(cherry picked from commit 3acc6ae932)
Add the new command "show debugging labeltable" to show allocated label
chunks in the label table managed with label_manager.c
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
requirements.txt was pinning sphinx at a very old version. This version
doesn't work in recent versions of Python; the new RTD configuration
made RTD respect our requirements file, breaking the build.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
As of Sep 25 2023, RTD projects require config files to build. This
patch is necessary for docs to continue to build.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
No such thing exists.
/root/frr/doc/user/ospfd.rst:624: WARNING: Cannot analyze code. No Pygments lexer found for "frr".
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
/root/frr/doc/user/ospfd.rst:609: WARNING: Bullet list ends without a blank line; unexpected unindent.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Provide a paragraph for srv6 multiple segs SIDs in documentation
to describe the multiple segs functionality.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
This patch includes:
* Implementation of RFC 5709 support in OSPF. Using
openssl library and FRR key-chain,
one can use SHA1, SHA256, SHA384, SHA512 and
keyed-MD5( backward compatibility with RFC 2328) HMAC algs.
* Updating documentation of OSPF
* add topotests for new HMAC algorithms
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
