Deterministic LSN44 is supported in combination with multiple NAT policies (MNP) based on the destination prefix or on a filter term in non-deterministic LSN44. For simplicity, the destination prefix configuration is used throughout this section instead of the filter terms. However, the combination of deterministic and non-deterministic LSN44 can lead to conflicting scenarios for which the outcomes must be well defined.
The reasons for these conflicting scenarios are the following:
In private to public (or inside to outside) direction, deterministic NAT uses source IP addresses of the traffic as a match criterion to find the correct NAT pool and outside routing context. This is performed through configuration where each source prefix is associated with a NAT policy.
In contrast, non-deterministic NAT uses destination IP addresses of the traffic as a match criterion to find the correct NAT pool and outside routing context. This is performed through configuration where each destination prefix is explicitly associated with its own NAT policy.
If both NAT variants are used simultaneously in the same inside NAT routing context, then the conflict resulting from different NAT policies for the same traffic must be resolved. Deterministic and non-deterministic NAT must always use different NAT policies within the same inside routing context.
The rules used to resolve this conflict are:
Destination prefixes are used to determine the outside routing context from their associated NAT policies. A NAT policy must be explicitly defined for each destination prefix.
When the outside routing context is determined, the pool selection within that routing context is selected based on the NAT policies associated with the source prefixes.
This means that the outside routing context in both NAT policies must match. If they do not match, traffic is dropped.
This logic ensures that traffic intended for NAT processing is identified based on the traffic destination (destination-prefix) while the pool selection (with outside IP addresses) is determined by the source prefix.
This is useful when non-deterministic NAT and static 1:1 NAT are simultaneously used in the same inside routing context. In this case, a customer to which NAT’d traffic is destined can change and re-purpose its routes that can then be dynamically advertised to the NAT operator. At the same time, the NAT operator who is providing static 1:1 NAT can ensure that its clients are predictably mapped to static outside IP addresses because the source prefixes and their associated NAT policies are not changed, even if the destination prefixes are changed.
An example of a supported scenario is shown in Figure: MNP and deterministic NAT44 where all destination prefixes are explicitly associated with NAT policies (no destination-prefix is using a default NAT policy) and the source prefixes are explicitly mapped to a different set of NAT policies. The outside routing contexts in the two NAT policies for traffic matching destination and source prefixes simultaneously, must match.
As shown in Figure: MNP and deterministic NAT44, traffic from the source network 10.10.0.0/24 is mapped to two different pools in two different outside VPRNs based on the pool names configured in NAT policies associated with the source prefixes. The actual outside VPRN is selected based on the NAT policy associated with the relevant destination prefix.
