Hi again,
> If that is the case, then why is the following configuration allowed ?
>
> nat44 deterministic add in 20.20.20.2/32 out 10.10.10.15/32
> nat44 deterministic add in 40.40.40.2/32 out 10.10.10.15/32
Think of VPP as an ASIC. Or as a set of Lego pieces.
You are responsible yourself how you assemble it.
(but sure I wouldn't mind if there was a check prohiting illegal
configurations. feel free to provide a patch).
> With the above two commands, I am trying to map two internal-src-ip-addresses
> to one external-src-ip-address (10.10.10.15) . This configuration takes
> affect and in2out translations are successful. May be I am missing some
> understanding here. Trying to see what that may be.
Deterministic NAT uses algorithmic mapping. That is an inside address block
gets a corresponding block of the outside pool statically allocated. The
mapping is bidirectional, so given an outside address, there is a 1:1
correspondence with the inside block.
Your above mappings violate that.
You could imagine doing something like:
in 20.20.20.2/32 out 10.10.10.15/32 psid-len 2 psid 0
in 40.40.40.2/32 out 10.10.10.15/32 psid-len 2 psid 1
Where you split the port space among the two inside blocks.
The downside of that approach is that you would not be able to support
protocols without ports.
The typical deterministic NAT case is more similar to MAP-E. E.g. for each
subscriber you map 192.168.0.0/16 -> <single extern address>.
Or a port range.
What is it you are trying to do?
Cheers,
Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15953): https://lists.fd.io/g/vpp-dev/message/15953
Mute This Topic: https://lists.fd.io/mt/72672377/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
