When testing SNMP service on FRR, the following error message may
appear on some distros.
> # snmpwalk -v2c -c public .1.3.6 1.1.1.1 <OID>
> Bad operator (INTEGER): At line 73 in /usr/share/snmp/mibs/ietf/SNMPv2-PDU
> [..then result ..]
>
The error message is due to the /etc/snmp/snmp.conf file. By default, this
file is used by both snmp server and client side. The net-snmp MIB parsing
routing loads MIBS, to bind oids with the naming scheme used by the MIBS.
> # cat /etc/frr/snmp.conf
> [snmp]
> mibs +ALL
>
A potential fix would consist in modifying the SNMPv2-PDU.mib file: the
problem is known on ubuntu distros, as the snmp-mibs-downloader package
has not updated the SNMPv2-PDU.mib file.
The choice is done to not modify the original distro where the test is run
on. Fix the topotests by ignoring the 'SNMPv2-PDU line 73" error message, and
keep the other error messages that may happen, for instance, when an
unknown oid name value is requested.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The define has inheritated from a wrong naming in sr-mpls.
Fix this by renaming ISIS_SRV6_LAN_BACKUP to ISIS_SRV6_ADJ_BACKUP.
Fixes: 2566656a6f ("isisd: Add data structure for SRv6 Adjacency SIDs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This was caught by the grpc_basic test which was receiving an invalid error
result, which was returned b/c inside zebra the libyang code was flagging the
value as invalid for a derived zebra interface type.
Signed-off-by: Christian Hopps <chopps@labn.net>
When a BFD down notification is received and the C-bit is set in both
directions, any ongoing graceful restart should be aborted and stale
routes removed from the RIB.
This commit updates the `bfd_bgp_cbit_topo3` topotest accordingly to
fix the expected outcomes in the `test_bfd_loss_intermediate` test.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC5492 says:
This document defines a new Error Subcode, Unsupported Capability.
The value of this Subcode is 7. The Data field in the NOTIFICATION
message MUST list the set of capabilities that causes the speaker to
send the message. Each such capability is encoded in the same way as
it would be encoded in the OPEN message.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Today, with the following bgp instance configured, the
local VRF label is allocated even if it is not used.
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export allocation-mode per-nexthop
> label vpn export auto
> rd vpn export 444:1
> rt vpn both 52:100
> export vpn
> import vpn
The 'show mpls table' indicates that the 16 label value
is allocated, but never used in the exported prefixes.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP vrf1 -
> 17 BGP 192.168.255.13 -
> 18 BGP 192.0.2.12 -
> 19 BGP 192.0.2.11 -
Fix this by only allocating new label values when really
used. Consequently, only 3 labels will be allocated instead
of previously 4.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP 192.168.255.13 -
> 17 BGP 192.0.2.11 -
> 18 BGP 192.0.2.12 -
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
RFC-7607 specifically calls out the allowed usage
of AS 0 to signal that the a particular address is
not in use and should be guarded against. Add
the ability to specify this special AS in the rpki
commands.
eva# show rpki as-number 0
RPKI/RTR prefix table
Prefix Prefix Length Origin-AS
2.57.180.0 22 - 24 0
2.58.144.0 22 - 22 0
2.59.116.0 24 - 24 0
4.42.228.0 22 - 22 0
5.57.80.0 22 - 22 0
<snip>
2a13:df87:b400:: 38 - 38 0
2a13:df84:: 32 - 32 0
2630:: 16 - 16 0
Number of IPv4 Prefixes: 1166
Number of IPv6 Prefixes: 617
eva# show rpki prefix 2630::/16 0
Prefix Prefix Length Origin-AS
2630:: 16 - 16 0
eva#
Fixes: #15778
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The debug command was removed in 17e9298e47 ("bgpd: Remove 'debug bgp
allow-martian'")
Cleanup all references to the debug command.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Operational data should not be used on validation stage. Move the usage
to apply stage only.
Fixes#15707.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
If a command is not marked as `YANG`-converted, the current command
batching buffer is flushed before executing the command. We shouldn't
flush the buffer when executing an `exit` command. It should only be
flushed if the next command is not `YANG`-converted, which is checked by
the command itself, not the previous `exit`.
Fixes#15706.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The 'table-direct' redistribute command is available for ipv4 unicast but
not for ipv6 unicast.
Add the command to ipv6 unicast as well.
Fixes: b6367f8460 ("bgpd: add redistribute table-direct support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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>
