You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 4, 2022. It is now read-only.
When Stenographer records traffic, it appears to strip the outermost VLAN tag. I don't know if I would consider this a bug, but I definitely wasn't expecting this. I am aware of several environments that use QinQ tagging to signal which taps traffic is coming from and it would be convenient to make this a configurable setting.
The text was updated successfully, but these errors were encountered:
When Stenographer records traffic, it appears to strip the outermost VLAN tag. I don't know if I would consider this a bug, but I definitely wasn't expecting this. I am aware of several environments that use QinQ tagging to signal which taps traffic is coming from and it would be convenient to make this a configurable setting.
I am assuming this is due to Stenographer using AF_PACKET. The VLAN tags are stripped at a lower layer and, unfortunately with my work on a few other things using AF_PACKET, it isn’t trivial to put them back together. It is possible, but with a decent performance impact as they have to be, per packet, re-applied. It is, perhaps, possible and may make sense to maintain a small state-store that could be built overtime and thus the performance penalties would smooth over the running time of stenographer.
When Stenographer records traffic, it appears to strip the outermost VLAN tag. I don't know if I would consider this a bug, but I definitely wasn't expecting this. I am aware of several environments that use QinQ tagging to signal which taps traffic is coming from and it would be convenient to make this a configurable setting.
The text was updated successfully, but these errors were encountered: