Skip to content

Commit

Permalink
datapath: Recreate CT entry without removing stale equivalent
Browse files Browse the repository at this point in the history
Previously, when a stale CT entry (of non CT_SERVICE type) was detected
(from a previous connection to a service with the same IP/port, but
a different rev_nat_index), the entry was removed, and only afterwards
recreated.

The removal included the removal of related SNAT entries. However, in
such case there were no SNAT entries created, thus the removal of CT +
SNAT before the recreation was redundant.

Signed-off-by: Martynas Pumputis <m@lambda.lt>
  • Loading branch information
brb committed Apr 20, 2020
1 parent 14685b2 commit 56a2f84
Showing 1 changed file with 0 additions and 2 deletions.
2 changes: 0 additions & 2 deletions bpf/bpf_lxc.c
Expand Up @@ -199,7 +199,6 @@ static __always_inline int ipv6_l3_from_lxc(struct __ctx_buff *ctx,
case CT_ESTABLISHED:
/* Did we end up at a stale non-service entry? Recreate if so. */
if (unlikely(ct_state.rev_nat_index != ct_state_new.rev_nat_index)) {
ct_delete6(get_ct_map6(tuple), tuple, ctx);
goto ct_recreate6;
}
break;
Expand Down Expand Up @@ -557,7 +556,6 @@ static __always_inline int handle_ipv4_from_lxc(struct __ctx_buff *ctx,
case CT_ESTABLISHED:
/* Did we end up at a stale non-service entry? Recreate if so. */
if (unlikely(ct_state.rev_nat_index != ct_state_new.rev_nat_index)) {
ct_delete4(get_ct_map4(&tuple), &tuple, ctx);
goto ct_recreate4;
}
break;
Expand Down

0 comments on commit 56a2f84

Please sign in to comment.