Home / Network / Routing / NAT / P-NAT / How is it NAT-friendly your Transit Network?

How is it NAT-friendly your Transit Network?

Application ports information

From an upper-layer point of view, the application have specific service ports that it passes to TCP and UDP (FTP application for example may use multiple TCP sessions) and that shouldn’t be altered (the service may break). How to store this information? in the payload? and reserve the header port fields for NAT (to ensure network continuity)? or at NATer level in its translation table?

Translation table size

Let’s note also that the translation tables (of all NAT nodes in the path) are of limited size. What happens if no port is available for the next translation? is there any mechanisms to hint on the end of a session? Yes, in TCP thanks to FIN and SYN packets, we may know when to drop a session. But it is another story using UDP…

As a summary

How NAT friendly is your network depends on two things : how your network is configured but also on you application behavior.

Pages: 1 2 3

Tagged:

Leave a Reply

802.11 (4) application (2) architecture (4) asm (4) automatisation (2) cagd (3) chd (2) cisco (6) command (5) controller (1) cost (6) coverage (5) debug (10) distance (6) dtls (2) dynamic rrm (5) firewall (2) fortinet (2) ieee (4) igmp (5) igp (8) interference (2) internet (3) ip (2) logique (2) loop (5) mac (3) machine learning (3) meraki (1) model (2) mpls (3) mroute (4) multicast (5) nat (2) ndp (2) network (3) next-hop (5) nurbs (3) osi (6) pat (2) pim (4) poisoning (6) projet (2) qos (2) radio (5) rib (5) rip (5) route (6) router (6) routing (15) rpf (4) rrm (10) security (3) show (5) simulation (2) sla (2) snr (2) solution (2) split-horizon (5) sql (1) ssl (2) ssm (4) static (6) stp (2) summarization (5) tcp (2) translation (1) travail (2) udp (2) vpn (3) vrf (3) wifi (11) wireshark (2) wlan (7) wlc (5)

October 2025
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  
Table of Contents
Copied!