Uploaded image for project: 'vpp'
  1. vpp
  2. VPP-1485

Undesired dependency between static mapping and address from the pool

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Medium Medium
    • 18.10, 19.01
    • None
    • S-NAT
    • None

      In Contiv we use NAT plugin to configure DNAT for services via static mappings and also SNAT for Interface access via NAT address pool and the output feature.
      In our (endpoint-dependent) setup, DNAT and SNAT are pretty much independent entities and as such are configured by two separate components in the agent. However, if external IP of a static/identity mapping is also in the NAT address pool, then NAT plugin requires that in order to just remove the address from the pool, the mapping has to be removed first (and created again afterwards). This adds a dependency into the control plane and unnecessarily increases the complexity.

      Example:
      With NAT address pool:

      NAT44 pool addresses:
      192.168.16.10
        tenant VRF independent
        1 busy udp ports
        0 busy tcp ports
        0 busy icmp ports
      NAT44 twice-nat pool addresses:
      10.1.1.254
        tenant VRF independent
        0 busy udp ports
        0 busy tcp ports
        0 busy icmp ports
      

      and mappings like:

      identity mapping 192.168.16.10:4789 vrf 0
      identity mapping 192.168.16.10 vrf 1 vrf 0 
      tcp local 10.3.1.10:12379 external 192.168.16.10:32379 vrf 0 self-twice-nat out2in-only
      tcp external 192.168.16.10:42400 self-twice-nat out2in-only
        local 10.1.1.2:2400 vrf 1 probability 1
        local 10.1.1.3:2400 vrf 1 probability 1
      

      In order to remove/change 192.168.16.10 from the pool, the mappings have to be removed/updated first, otherwise we get an error:

      nat44 add address: NAT address used in static mapping.
      

            matfabia Matus Fabian
            milanlenco Milan Lenco
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: