In some cases "Captured frame from MAC ... associated with another peer" is not an error

[brb]

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:

1. peerC forwards a packet (p0) to peerA.
2. peerA executes a vxlan miss handler which calls the handleForwardedPacket callback.
3. the callback learns about p0.srcMAC -> peerC, and injects the packet with fastdp.InjectPacket.
4. InjectPacket calls fastdp.bridge(..) which learns p0.srcMAC -> routerBridgePortID.
   <..>
5. at some point peerB forwards a packet (p1, p1.dstMAC == p0.srcMAC) to peerA.
6. peerA execs the same vxlan miss handler, learns about p1.srcMAC -> peerB, and injects the packet.
7. this time, the fastdp.bridge(..) function knows about dstMAC -> vport mapping, and because of that calls fastdp.sendToPort[routerBridgePortID] which is the handleCapturedPacket callback.
8. 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.

[rade]

to extend the if-clause

or, rather, turn it into a switch dstPeer ...

[mcortinas]

We also can see these error messages, any plan in order to silence this?

[brb]

@mcortinas I'm going to prioritize this issue after the 2.2 release.

[timanovsky]

Is it only logging problem, or does it have other consequences? We see a lot of those

[bboreham]

@timanovsky it depends on the cause. If you have the same cause as described at the top, exactly, then it is only a logging problem. But if your cause is different then the impact could be different.

Best to open a new issue and post the logs.