I've been able to narrow the scope down, the issue is with macsec
itself. I setup two hosts with a macsec link between them, and let a
couple iperf3 sessions blast traffic across. At approximately 4.2
billion packets / 6TB data transferred one end stopped transmitting
packets. Doing a tcpdump
I'm actually leaning towards macsec now. I'm at 6TB transferred in a
double hop, no macsec over the bridge setup without triggering the
fault. I'm going to let it continue to churn and setup a second
testbed that JUST uses macsec without traffic control bridging to see
if I can trip the issue
On Wed, Oct 10, 2018 at 8:54 AM Josh Coombs wrote:
>
> 2.3 billion 1 byte packets failed to re-create the bug. To try and
> simplify the setup I removed macsec from the equation, using a single
> host in the middle as the bridge. Interestingly, rather than 1.3Gbits
> a second in both
2.3 billion 1 byte packets failed to re-create the bug. To try and
simplify the setup I removed macsec from the equation, using a single
host in the middle as the bridge. Interestingly, rather than 1.3Gbits
a second in both directions, it ran around 8Mbits a second. Switching
the filter from
Hello all, I'm looking for some guidance in chasing what I believe to
be a bug in kernel traffic control filters. If I'm pinging the wrong
list let me know.
I have a homebrew MACSec bridge setup using two pairs of PCs. I
establish a MACSec link between them, and then use TC to bridge a
second
