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
Detecting MTU misconfigurations and raise alarms would be a big plus.
Some early thoughts:
When sfunnel is attached in INGRESS, there is no way to know the egress interface at that point in time.
Likewise, route MTU checking happens after sfunnel has been executed when attached on INGRESS and before sfunnel is executed when attached on EGRESS. There is literally no way to know that.
Sidenote: If IPv4 DF=1 is set, Interface counters dropped and/or tx_dropped should increase
What might be more realistic is to define an env variable $DETECT_MAX_MTU=value, and that sfunnel can emit bpf_printk() warnings,with a clear pattern, when funneling exceeds $DETECT_MAX_MTU.
The text was updated successfully, but these errors were encountered:
Detecting MTU misconfigurations and raise alarms would be a big plus.
Some early thoughts:
sfunnel
is attached in INGRESS, there is no way to know the egress interface at that point in time.sfunnel
has been executed when attached on INGRESS and beforesfunnel
is executed when attached on EGRESS. There is literally no way to know that.DF=1
is set, Interface countersdropped
and/ortx_dropped
should increaseWhat might be more realistic is to define an env variable
$DETECT_MAX_MTU=value
, and thatsfunnel
can emitbpf_printk()
warnings,with a clear pattern, when funneling exceeds$DETECT_MAX_MTU
.The text was updated successfully, but these errors were encountered: