Hello,
I've found an issue in the WireGuard plugin, which manifests itself when
a peer is replaced with another one with intersecting Allowed IPs.
The fix is here: https://gerrit.fd.io/r/c/vpp/+/44104
More detailed description:
If you have a route via the wg interface, it will not be updated when the
peer is removed and replaced, resulting in a problem like this one:
vpp# show ip fib 10.100.200.3
default, fib_index:0, flow hash:[src dst sport dport proto flowlabel ]
epoch:0 flags:none locks:[adjacency:1, default-route:1, lcp-rt:1, ]
10.100.200.3/32 fib:0 index:32 locks:2
lcp-rt refs:1 entry-flags:attached, src-flags:added,contributing,active,
path-list:[58] locks:2 flags:shared, uPRF-list:47 len:1 itfs:[13, ]
path:[91] pl-index:58 ip4 weight=1 pref=0 attached-nexthop:
oper-flags:resolved, cfg-flags:attached,
10.100.200.3 wg1
[@0]: ipv4 [features] via 10.100.200.3 wg1: mtu:1500 next:11
flags:[features ] 00000000:
4500000000000000401100760a6464010aff0114ca6cca6c0000000000000000
00000020: 000000000000000000000000
stacked-on entry:33:
[@4]: ipv4 via 10.255.0.20 GigabitEthernet0/6/0: mtu:1500
next:5 flags:[] 525400fdc7a45254006259f90800
forwarding: unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:34 buckets:1 uRPF:47 to:[0:0]]
[0] [@6]: ipv4 [features] via 10.100.200.3 wg1: mtu:1500 next:11
flags:[features ] 00000000:
4500000000000000401100760a6464010aff0114ca6cca6c0000000000000000
00000020: 000000000000000000000000
stacked-on entry:33:
[@4]: ipv4 via 10.255.0.20 GigabitEthernet0/6/0: mtu:1500 next:5
flags:[] 525400fdc7a45254006259f90800
Note that in stacked-on entry:33 we have ipv4 via 10.255.0.20, yet in the
rewrite data of the entry above it
00000000: 4500000000000000401100760a6464010aff0114ca6cca6c0000000000000000
00000020: 000000000000000000000000
we have
0a 64 64 01 -> Src IP = 10.100.100.1
0a ff 01 14 -> Dst IP = 10.255.1.20
Here, 10.255.1.20 in the rewrite data is the correct endpoint IP, but the
stacked-on entry has a stale one, 10.255.0.20, and according to the stale
entry's rewrite data, the packets are being sent to a wrong MAC address
corresponding to 10.255.0.20.
The fix is to use adj_midchain_delegate_remove() instead of
adj_midchain_delegate_unstack(), so that the midchain delegate is
re-created when a peer with similar allowed IPs is re-added.
adj_midchain_delegate_remove() was already being called from
wg_peer_adj_reset_stacking(), which in turn is used during endpoint
updates, but not when the peers were replaced via the API. I've adjusted
the code to use adj_midchain_delegate_remove() instead
of adj_midchain_delegate_unstack().
See also the new test case that I added, which fails with current VPP
master branch.
Regards,
Ivan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26509): https://lists.fd.io/g/vpp-dev/message/26509
Mute This Topic: https://lists.fd.io/mt/116227354/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
