Problèmes de reordering TCP avec Anycast BGP et NAPT sur Egress

NAPT avec Anycast c'est un combo explosif. Le problème classique c'est l'asymétrie. Un client envoie un `SYN` via le NAT vers l'IP Anycast. Le paquet est traduit par le NAT. Le `SYN` est routé par BGP vers l'instance Anycast A.

L'instance A répond. Le `SYN-ACK` de A revient via le NAT qui le dé-traduit et l'envoie au client. Jusque là ok.

Le problème c'est si les paquets suivants du client (genre le `ACK` final ou les data) sont routés par BGP vers l'instance Anycast B (parce qu'un lien A est tombé, ou une métrique BGP a changé, ou juste load balancing).

Exact. Et en plus, l'instance B reçoit un paquet dont l'IP source/port est celle du NAT (si le NAT est `full-cone` ou `port-restricted`). Ou si c'est un NAT `address-restricted` ou `symmetric`, le NAT a une `flow entry` pour le tuple (SrcIP, SrcPort, DstIP, DstPort) avec DstIP comme IP interne de A.

Quand le client envoie un paquet et qu'il arrive sur B, B répond avec sa propre IP. Si cette réponse ne passe pas par le même NAT qui a créé le flow, le client ne voit pas le bon paquet. Ou le NAT d'origine ne voit pas le retour de B et invalide le flow. Le reordering est un symptôme d'une connexion qui cherche son chemin.

Je vois. Donc le NAPT crée une `stateful entry` basée sur la destination réelle (l'instance Anycast interne A) du premier paquet. Si un paquet suivant arrive à une autre instance (B), le NAT ne reconnaît pas le flow ou la réponse de B est routée différemment.

C'est ça ? Le `DstIP` pour le NAT est l'IP interne de l'instance Anycast, pas l'IP publique Anycast.

Non, pas exactement. Le NAT maintient un état de traduction pour (client-original-IP:port -> NAT-public-IP:port). Ce tuple est ensuite utilisé pour communiquer avec l'Anycast-IP. L'instance Anycast A voit le paquet comme venant de `NAT-public-IP:port`.

Si BGP reroute les paquets vers l'instance Anycast B, B voit le même `NAT-public-IP:port`. Le problème n'est pas tant que B ne connaît pas le NAT. Le problème crucial c'est le `return path`.

Oui, le `return path`. Si la réponse de l'instance Anycast A (qui a vu le SYN) revient via le NAT, tout va bien. Le NAT fait sa dé-traduction. Mais si la réponse de l'instance Anycast B (qui a vu un ACK perdu) est routée *directement* vers l'IP originale du client (sans passer par le NAT), le NAT ne voit pas le retour, et la connexion TCP est cassée du point de vue du NAT.

Le `reordering` c'est juste le client qui reçoit des paquets de A et B en désordre, ou des paquets qui ne sont plus reconnus par sa propre `TCP state machine`.

Ok, donc le problème fondamental est que le NAT s'attend à voir *tout* le trafic bidirectionnel passer par lui pour maintenir son état. Mais avec l'Anycast, le `return path` peut devenir asymétrique : le client envoie via NAT et l'Anycast lui répond directement ou via un autre chemin BGP.

Comment diable je force la symétrie dans un monde Anycast BGP ? C'est le Graal.

C'est super chaud. Soit tu brises l'Anycast pour ces clients NATés, soit tu forces une `sticky session` ultra-robuste. Si tu as un `load balancer` ou un `routeur` qui fait du `ECMP` devant le NAT, tu peux essayer de configurer une `hashing policy` basée sur le `source IP` ou le `source IP/port` pour que le même client aille toujours vers le même Anycast backend.

Mais si c'est du BGP pur avec juste les instances Anycast qui annoncent la route, c'est plus compliqué. Les `router BGP` vont faire leur propre `ECMP` ou `best path` et tu n'as pas de contrôle granulaire sur la session.

La meilleure approche ici, c'est d'arrêter d'utiliser l'Anycast pour le trafic qui doit passer par le NAT. S'il n'y a qu'un seul point de NAT, il faut forcer ce trafic à n'atteindre qu'une seule instance Anycast spécifique.

Tu peux faire ça en ne distribuant pas la route Anycast BGP à l'edge router qui est juste en amont de ton NAPT. Au lieu de ça, tu configures une route statique (`/32`) du NAPT vers l'IP interne d'une instance Anycast désignée.

Ah, donc l'idée c'est de désactiver l'Anycast pour le segment réseau qui contient le NAPT. Et à la place, pointer explicitement ce NAPT vers une seule de mes instances Anycast.

Ça me fait perdre la résilience Anycast pour ces clients mais ça devrait stabiliser les connexions. C'est un compromis acceptable pour ces clients legacy.

Oui, c'est le compromis habituel. Soit tu acceptes l'instabilité, soit tu perds un peu de la flexibilité d'Anycast pour les clients via NAT.

Sur ton `routeur BGP` qui est le `next-hop` du NAPT, tu peux utiliser un `route-map` pour filtrer l'advertisement de la route Anycast BGP pour cette interface spécifique.

router bgp 65000
 neighbor 192.168.1.1 route-map NO_ANYCAST_TO_NAT out

ip prefix-list ANYCAST_PREFIX seq 5 deny 10.0.0.0/24
ip prefix-list ANYCAST_PREFIX seq 10 permit 0.0.0.0/0 le 32

route-map NO_ANYCAST_TO_NAT permit 10
 match ip address prefix-list ANYCAST_PREFIX

Et ensuite, sur ton NAPT ou son routeur upstream, tu as ta route statique ou une route BGP avec une métrique plus élevée vers une instance Anycast spécifique.

C'est une solution robuste. Je vais implémenter un `route-map` FRR pour bloquer l'annonce de l'Anycast `10.0.0.0/24` vers le `peer BGP` du NAPT.

Puis je rajoute une `static route` sur le NAPT qui pointe `10.0.0.0/32` vers l'IP interne de l'instance Anycast la plus proche. Ça devrait forcer le trafic à être symétrique pour ce `flow`.

Merci beaucoup pour cette explication détaillée et les solutions. Ça m'a éclairci les idées sur ce piège de l'Anycast et du NAPT.