This repository was archived by the owner on Jun 20, 2024. It is now read-only.
This repository was archived by the owner on Jun 20, 2024. It is now read-only.
In some cases "Captured frame from MAC ... associated with another peer" is not an error #2877
Open
Description
TL;DR fastdp sometimes executes handleCapturedPacket
for received over tunnel packets, which leads to logging the "Captured frame from MAC ... associated with another peer"
error. The error is quite often seen in logs provided by users.
How it happens:
- peerC forwards a packet (p0) to peerA.
- peerA executes a vxlan miss handler which calls the handleForwardedPacket callback.
- the callback learns about p0.srcMAC -> peerC, and injects the packet with fastdp.InjectPacket.
- InjectPacket calls fastdp.bridge(..) which learns p0.srcMAC ->
routerBridgePortID
.
<..> - at some point peerB forwards a packet (p1, p1.dstMAC == p0.srcMAC) to peerA.
- peerA execs the same vxlan miss handler, learns about p1.srcMAC -> peerB, and injects the packet.
- this time, the fastdp.bridge(..) function knows about dstMAC -> vport mapping, and because of that calls fastdp.sendToPort[routerBridgePortID] which is the
handleCapturedPacket
callback. - the callback logs the infamous error because of the learnt mapping at the step 6.
Logs which illustrate the case usually look like the following:
Discovered remote MAC 06:66:e3:00:72:d0 at ...(k8s-node-3)
<..>
Discovered remote MAC 82:2f:27:ff:b5:53 at ...(k8s-node-2)
<..>
Captured frame from MAC (82:2f:27:ff:b5:53) to (06:66:e3:00:72:d0) associated with another peer ...(k8s-node-2)
An easy fix (before applying 17c8dc9) is to extend the if-clause by adding the following cases:
if dstPeer == nil{ // not found
InjectPacket // might be local container...
relayBroadcast // ...or not
}
if dstPeer != nil { // not us
relay // just relay, because destination is know
}
However, we should be super careful (and think twice) as we are changing the routing logic.
Activity