In symmetric routing, when local ESI is down,
the MH peer learnt local mac-ip
prefix is installed into teannt vrf (given l3vni).
When ESI is back up and associated to evi/vni then
remove the local synced mac-ip imported routes from the
tenant vrf as local neigh/arp is present.
Ticket: #3878699
Testing:
peer advertised mac-ip route:
*> [2]:[0]:[48]:[aa:aa:aa:00:00:01]:[32]:[45.0.0.51] RD 27.0.0.4:9
27.0.0.4 (spine-1)
0 64435 65016 i
ESI:03:44:38:39:ff:ff:01:00:00:01
RT:65016:1000 RT:65016:4000 ET:8 Rmac:44:38:39:ff:ff:16
When local ESI is flapped
torm-11:# ip neigh show 45.0.0.51
45.0.0.51 dev vlan1000 lladdr aa:aa:aa:00:00:01 REACHABLE proto zebra
Before fix:
(The imported route remained in tenant-vrf)
torm-11:# ip route show vrf vrf1 45.0.0.51
45.0.0.51 nhid 257 proto bgp metric 20
After fix:
torm-11# ip route show vrf vrf1 45.0.0.51
torm-11#
trace:
2024/10/11 18:19:29 BGP: [JMP3T-178G8] route [2]:[0]:[48]:[00:02:00:00:00:08]:[32]:[21.1.0.5]
is matched on local esi 03:00:00:00:77:01:04:00:00:0e, uninstall from VRF tenant1 route table
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 3f00709a39)
They are managed under `frr-route-map`, not under `frr-bgp-route-map`.
Fixes: https://github.com/FRRouting/frr/issues/17055
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b9a9be492e)
Add bgp_nexthop_ipv6 to check the ipv6 link-local nexthop conformity in
several situations.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 6dc4d95061)
If the "nexthop-local unchanged" setting is enabled, it preserves the
IPv6 link-local nexthop from the originating peer. However, if the
originating and destination peers are not on the same network segment,
the originating peer's IPv6 link-local address will be unreachable from
the destination peer.
In such cases, reset the IPv6 link-local nexthop, even if "nexthop-local
unchanged" is set on the destination peer.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 5bb99ccad2)
Do not add an IPv6 link-local nexthop if the originating peer does not
provide one and the nexthop-local unchanged setting is enabled.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 34c1dd076e)
Recent PR #17009 introduced a crash in pw handing
for deletion. Let's fix that problem.
Fixes: #17041
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 154a89bc31)
Currently FRR is limiting the nexthop count to a uint8_t not a
uint16_t. This leads to issues when the nexthop count is 256
which results in the count to overflow to 0 causing problems
in the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the zebra pw code has setup a retry to install the
pw after 30 seconds when it is decided that reachability to
the pw is gone. This causes a failure mode where the
pw code just goes and re-installs the pw after 30 seconds
in the non-reachability case. Instead it should just be
reinstalling after reachability is restored.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the pw code sets the status of the pw for install
and uninstall immediately when notifying the dplane. This
is incorrect in that we do not actually know the status at
this point in time. When we get the result is when to set
the status.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Mgmtd makes use of libyang's internal ietf-yang-library module to add
support for said module to FRR management. Previously, mgmtd was loading
this module explicitly; however, that required that libyang's
`ietf-yang-library.yang` module definition file be co-located with FRR's
yang files so that it (and ietf-datastore.yang) would be found when
searched for by libyang using FRRs search path. This isn't always the
case depending on how the user compiles and installs libyang so mgmtd
was failing to run in some cases.
Instead of doing it the above way we simply tell libyang to load it's
internal version of ietf-yang-library when we initialize the libyang
context.
This required adding a boolean to a couple of the init functions which
is why so many files are touched (although all the changes are minimal).
Signed-off-by: Christian Hopps <chopps@labn.net>
```
anlan# show run
!
interface eth0
ip router isis A
exit
!
router isis A
metric-style narrow <- NOT wide
exit
!
end
anlan (config)# int eth0
anlan (config-if)# no isis topology ipv6-unicast
% Configuration failed.
Error type: validation
Error description: Multi topology IS-IS can only be used with wide metrics
```
The MT commands are mainly controlled by the binded area, not by interface.
Currently if there is any MT configuration in the area, `metric-style` must
be with the `wide` mode, this requirement is sufficient. So, the
unnecessary/wrong check for MT in the interface should be removed.
Signed-off-by: anlan_cs <anlan_cs@126.com>
The issue is we can't remove all pim configurations including some
special configurations (e.g., `no ip pim bsm`) for one interface.
For one pim-disable interface, all such pim depdendent options
(including `ip pim ` and `no ip pim `) should be completely removed.
Also append `no ip multicast` for the same purpose, it is no use at present,
but for future use.
The running config:
```
interface A
ip pim
no ip pim bsm
exit
```
Reload the new config:
```
interface A
exit
```
Before:
```
2024-10-05 20:52:33,467 INFO: Executed "interface A no ip pim exit"
2024-10-05 20:52:33,482 INFO: Executed "interface A ip pim bsm exit"
```
And the pim configurations in running configuration are not removed after reloading:
```
interface A
ip pim <- Wrong
exit
```
After:
```
2024-10-05 20:56:27,489 INFO: Executed "interface A no ip pim exit"
```
And all the pim configuration are removed.
Signed-off-by: anlan_cs <anlan_cs@126.com>
fpm_enqueue_rmac_table expects an fpm_rmac_arg* as its argument.
The issue can be reproduced by dropping the TCP session using:
ss -K dst 127.0.0.1 dport = 2620
I used Fedora 40 and frr 9.1.2 and I got the gdb backtrace:
(gdb) bt
0 0x00007fdd7d6997ea in fpm_enqueue_rmac_table (bucket=0x2134dd0, arg=0x2132b60) at zebra/dplane_fpm_nl.c:1217
1 0x00007fdd7dd1560d in hash_iterate (hash=0x21335f0, func=0x7fdd7d6997a0 <fpm_enqueue_rmac_table>, arg=0x2132b60) at lib/hash.c:252
2 0x00007fdd7dd1560d in hash_iterate (hash=0x1e5bf10, func=func@entry=0x7fdd7d698900 <fpm_enqueue_l3vni_table>,
arg=arg@entry=0x7ffed983bef0) at lib/hash.c:252
3 0x00007fdd7d698b5c in fpm_rmac_send (t=<optimized out>) at zebra/dplane_fpm_nl.c:1262
4 0x00007fdd7dd6ce22 in event_call (thread=thread@entry=0x7ffed983c010) at lib/event.c:1970
5 0x00007fdd7dd20758 in frr_run (master=0x1d27f10) at lib/libfrr.c:1213
6 0x0000000000425588 in main (argc=10, argv=0x7ffed983c2e8) at zebra/main.c:492
Signed-off-by: Igor Zhukov <fsb4000@yandex.ru>
