I am using openvswitch, that’s another rabbit hole and I don’t want to touch that unless I have to.
I found something interesting, I am using port mirroring on VyOS, egress interface is eth1.2805, on VyOS I do a tcpdump -i eth1.2805 I see all multicast packet, however, on other hosts which is under VLAN 2805 (fixed typo) which is controlled by openvswitch suffer heavy packet loss, how to explain this?
(Assuming 2804 is a typo or another redirect target)
You’ll have to crawl through packet/queue stats and tracing to see if they’re being dropped somewhere. There’s many potential points they might be discarded or ignored.
As a quick check for VyOS, see if packet counts are advancing on the mirror target at roughly the same rate they’re going up on the sampled interfaces (adding all sampled directions together), and then check mirror target error counts. If counts match and errors are stable, the frames have been handed to KVM and the problem is deeper.
I have done step by step trace and dump, found out the issue was coming from the tcpdump buffer size on the target VM, I will have to increase it by -B 8192 to make it work, I think we resolved it.
By the way, I am using port mirroring now instead of redirect, what tech behind port mirroring on VyOS?
Mirroring and redirect both use the same mechanism - traffic control mirred actions, applied to interface queues before it hits the application-level network stack.
Redirect moves the frame to an outbound queue, mirror copies it so that it’s still processed normally in the original destination. There is a small performance saving with redirect.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.