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>
ospfv3 shows this unconditionally, and ospfv2 does not show `ip ospf network ...` if the type of the interface matches the specified network.
Fixes: https://github.com/FRRouting/frr/issues/15817
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When usid is not used, the isis_srv6_topo1 test does not work.
The SID prefix allocated by isis is different when the usid
flags is set or not. When the flags is not transmitted to isis,
the SID allocated is supposed to be a 128 bit mask length SID,
which is not what the isis_srv6_topo1 test is supposed to obtain.
Fix this by exchanging the flags locator value in the zclient api.
Fixes: 9b7491e1fc ("lib: Add support for flags to the SRv6 locator")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
Before the patch-set, ce1 was sending an IPv6 Link-local as global and
link-local nexthop to pe1.
Set bgp_vrf_leaking_5549_routes in accordance with the previous fixes.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a peer sends an IPv4-mapped IPv6 global and a IPv6 link-local
nexthop, prefer the link-local unless a route-map tells to use the
global.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The code was expected that no IPv6 global address was present but the
previous commit was replacing nexthop.v6global by the link-local address
instead of un-setting it in case of removal of the IPv6 global.
Set also ipv4-mapped ipv6 address as nexthop when a link-local is found
and it is an ipv4 prefix over ipv6 nexthop.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a peer has no IPv6 global address to send as nexthop, it sends the
IPv6 link-local instead as global. "show bgp ipv6 json" displays the
same address in global and link-local scopes.
> "nexthops": [
> {
> "ip": "fe80::a495:38ff:fea6:6ea3",
> "afi": "ipv6",
> "scope": "global",
> "used": true
> },
> {
> "ip": "fe80::a495:38ff:fea6:6ea3",
> "afi": "ipv6",
> "scope": "link-local"
> }
> ]
However, "used" key is set on the global nexthop but not in link-local.
It is correct but it makes difficult to test JSON to expect the usage of
a link-local. The contrary is also correct.
Set "used" key on the link-local nexhop instead to facilitate the tests.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When the IPv6 global is removed on an interface towards a peer, the
IPv6 nexthop global that is sent is a IPv4-mapped IPv6 address. It
should be the link-local.
At removal, replace the global by the next global address or the
link-local as last resort.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add bgp_nexthop_mp_ipv4_6 topotest to test to nexhop value with
MP-BGP IPv4 and IPv6 on IPv4 peering. The test has route-reflector,
route-server, iBGP and eBGP peers.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
bgpd keeps on advertising IPv6 prefixes with a IPv6 link-local nexthop
after a valid IPv6 global appears.
At bgpd startup, the IPv6 global is announced by zebra after the
link-local. Only the link-local is advertised. Clearing the BGP sessions
make the global to to be announced.
Update the nexthops with the global IPv6 when available.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This reverts commit 0325116a27.
It was causing an issue where a nexthop for IPv6 over an IPv4 session
was always rewritten to an IPv4-mapped IPv6 address even when a valid
IPv6 global address was existing.
Link: https://github.com/FRRouting/frr/issues/15610
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
