ldpd: fix wrong gtsm count #16226
ldpd: fix wrong gtsm count #16226
Conversation
There was a problem hiding this comment.
In linux networking stack, the received mpls packets will be processed by the host twice, one as mpls packet, the other as ip packet, so its ttl decreased 1.
@anlancs Thanks for troubleshoothing this. As we discussed on Slack, this behavior is reproducible on kernel 5.10 but not on 6.1. It's a kernel bug that was fixed along the way.
That said, we definitely need this workaround on FRR's side. I think it'd be good however to add a comment explaining why this TTL decrement is necessary, for future reference.
|
reproducible on new kernel 5.10 and 6.1 ( there maybe no this issue in older versions ), and this PR should work with all version if older kernel version is involved. |
In linux networking stack, the received mpls packets will be processed by the host *twice*, one as mpls packet, the other as ip packet, so its ttl decreased 1. So, we need release the `IP_MINTTL` value if gtsm is enabled, it is for the mpls packets of neighbor session caused by the command: `label local advertise explicit-null`. This change makes the gtsm mechanism a bit deviation. Fix PR FRRouting#8313 Signed-off-by: anlan_cs <[email protected]>
|
@Mergifyio backport dev/10.1 stable/10.0 stable/9.1 stable/9.0 |
✅ Backports have been created
|
|
@frrbot rereview |
ldpd: fix wrong gtsm count (backport #16226)
ldpd: fix wrong gtsm count (backport #16226)
ldpd: fix wrong gtsm count (backport #16226)
ldpd: fix wrong gtsm count (backport #16226)
In linux networking stack, the received mpls packets will be processed by the host twice, one as mpls packet, the other as ip packet, so its ttl decreased 1.
So, we need release the
IP_MINTTLvalue if gtsm is enabled, it is for the mpls packets of neighbor session caused by the command:label local advertise explicit-null.This change makes the gtsm mechanism a bit deviation.
Fix #8313