ietf-key-chain depends on ietf-netconf-acm, and lib/ code sets up the
former, so ietf-netconf-acm needs to be embedded in the libfrr too.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
no form of 'ip pm msdp peer <> source <>' does not
accept source argument. Stip the 'source <>' part from
config line being deleted via frr-reload.
Ticket: #3874971
Testing:
Config:
vrf blue
ip msdp peer 1.1.1.1 source 1.1.1.1
frr-reload failure log:
2024-04-23 02:08:32,501 INFO: Failed to execute vrf blue no ip
msdp peer 1.1.1.1 source 1.1.1.1 exit
2024-04-23 02:08:32,501 ERROR: "vrf blue -- no ip msdp peer 1.1.1.1
source 1.1.1.1 -- exit" we failed to remove this command
2024-04-23 02:08:32,501 ERROR: % Unknown command: no ip msdp peer
1.1.1.1 source 1.1.1.1
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When no ip pim is performed subsequent pim related
configs under the interface also implicitly deleted.
The previous fix was attempting to remove from the same
list which was being integrated.
First collect the lines to remove in separate list
then at the end remove from the original lines_to_del.
commit 623af04e1c does not work properly if tries to delete
an entry from existing list which is being walked on.
Ticket: #3869779
Testing done:
frr.conf:
no interface config
running-config:
--------------
interface swp1
ip pim
ip pim active-active
ip pim allow-rp rp-list sample
ip pim bfd
ip pim use-source 1.1.1.1
ip multicast boundary oil test
exit
frr-reload log pointing only no ip pim config
is removed under interface:
2024-04-18 18:44:37,202 INFO: "frr defaults datacenter" cannot be removed
2024-04-18 18:44:37,202 INFO: "service integrated-vtysh-config" cannot be removed
2024-04-18 18:44:37,504 INFO: Executed "interface swp1 no ip pim exit"
2024-04-18 18:44:37,505 INFO: /var/run/frr/reload-YHS51E.txt content
Signed-off-by: Chirag Shah <chirag@nvidia.com>
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>
- by using symlinks in the rundir (/tmp) into the source/build directory
we avoid needing to copy the *.gcda stat files into the source/build dir.
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>
This commit adds the capabiity to filter OSPF neighbors using a
prefix-list with rules matching the neighbor's IP source address.
Configuration, filtering, immediate neighbor pruning, topo-tests,
and documentation are included. The command is:
ip ospf neighbor-filter <prefix-list> [A.B.C.D]
Signed-off-by: Acee Lindem <acee@lindem.com>
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>
