Network Address Translation

Network Address Translation devices modify the IP headers of packets between a host and server, changing some or all of the source address, destination address, source port (TCP/UDP), destination port (TCP/UDP), or ICMP query ID (for ping). The 7750 SR in both NAT modes performs Source Network Address and Port Translation (S-NAPT). S-NAPT devices are commonly deployed in residential gateways and enterprise firewalls to allow multiple hosts to share one or more public IPv4 addresses to access the Internet. The common terms of inside and outside in the context of NAT refer to devices inside the NAT (that is behind or masqueraded by the NAT) and outside the NAT, on the public Internet.

TCP/UDP connections use ports for multiplexing, with 65536 ports available for every IP address. Whenever many hosts are trying to share a single public IP address there is a chance of port collision where two different hosts may use the same source port for a connection. The resultant collision is avoided in S-NAPT devices by translating the source port and tracking this in a stateful manner. All S-NAPT devices are stateful in nature and must monitor connection establishment and traffic to maintain translation mappings. The 7750 SR NAT implementation does not use the well-known port range (1 to 1023).

In most circumstances, S-NAPT requires the inside host to establish a connection to the public Internet host or server before a mapping and translation occurs. With the initial outbound IP packet, the S-NAPT knows the inside IP, inside port, remote IP, remote port and protocol. With this information the S-NAPT device can select an IP and port combination (referred to as outside IP and outside port) from its pool of addresses and create a unique mapping for this flow of data.

Any traffic returned from the server uses the outside IP and outside port in the destination IP/port fields – matching the unique NAT mapping. The mapping then provides the inside IP and inside port for translation.

The requirement to create a mapping with inside port and IP, outside port and IP and protocol generally prevents new connections to be established from the outside to the inside as may occur when an inside host needs to be a server.

NAT traffic in SR OS is distributed over ISAs and ESAs within each NAT group. As a result, NAT capacity grows incrementally by adding more ISAs and ESAs to the system while each ISA or ESA participates equally in load sharing.

SR OS load balancing mechanisms in CGN (LSN44, DS-Lite, and NAT64) differ in the upstream and downstream directions, they are independent and unaware of each other,

• In the upstream direction, traffic is load balanced based on source IPv4 or IPv6 addresses or subnets.

• In the downstream direction, outside IP address ranges (NAT pool address ranges) are micronetted (divided into smaller subnets), and these micronets are assigned to individual ISAs or ESAs in a balanced way. Downstream traffic is assigned to each ISA or ESA based on the micronets.

Load balancing over ISAs and ESAs shows traffic load balancing within SR OS. In the upstream direction, traffic is hashed based on the source IP addresses or subnets from the10.10.0.0/16 range. A sample of 64000 source IP addresses guarantees equal load distribution.

In this example, in the downstream direction, a pool of 256 public addresses is divided into four equal subnets and each subnet is assigned to one ISA or ESA, each ISA or ESA is serving 64 public IP addresses.

If there are not enough IP addresses on the inside and outside in relation to the number of ISAs and ESAs, unequal load balancing and, in extreme cases, traffic blackholing can occur. Traffic blackholing shows an example of an extreme case, where a single IP address is assigned to a pool in a NAT group with four ISAs or ESAs. This single outside IP address can be assigned to a single ISA or ESA that serves downstream traffic. Upstream traffic is unaware of the downstream load distribution, so it sends traffic to all four ISAs and ESAs, and as a result this traffic is dropped at ISAs or ESAs that do not have the public IP address assigned.

The operator is notified when the number of outside IP addresses in a pool is smaller than the number of ISAs or ESAs in the NAT group. The notification is sent in the form of a log, as shown in the example below.

3 2020/04/03 18:48:42.010 CEST MINOR: NAT #2015 Base Resource problem
"The address configuration for pool 'test.' causes one or more ISAs not getting an IP address"
4 2020/04/03 18:48:42.010 CEST MINOR: NAT #2014 Base Resource alarm raised
"The status of the NAT resource problem indication changed to true."

In classic CLI, this configuration is permitted by the CLI, but a message is displayed directly in response to a pool activation.

configure router nat outside pool "test" no shutdown
INFO: BB #1221 The address configuration for this pool causes one or more members not getting an IP address - Router 'Base', pool 'test'

The load balancing mechanism in Layer 2–aware NAT relies on a different algorithm than CGN. In Layer 2–aware NAT, on the inside, traffic is distributed across ISAs and ESAs based on the resource utilization of each ISA or ESA. This load balancing mechanism is control plane driven, contrary to CGN which is forwarding plane driven (hashing is based purely on source IP addresses or subnets). In Layer 2–aware NAT, an ESM subscriber is directed to an ISA or ESA hosting a large number of subscribers, hosts, and port blocks, as an aggregate. In Layer 2–aware NAT, traffic is not blackholed when the number of outside IP addresses is smaller than the number of ISAs and ESAs in the pool within a single NAT group. Instead, the outside IP address is assigned to some of the ISAs or ESAs and the ESM host is directed to those. ISAs and ESAs without assigned outside IP addresses remains unused.

Applications which operate as servers (such as HTTP, SMTP, and so on) or peer-to-peer applications can have difficulty when operating behind an S-NAPT because traffic from the Internet cannot reach the NAT without a mapping in place.

Different methods can be employed to overcome this, including:

• Port forwarding

• STUN support

• Application Layer Gateways (ALG)

The 7750 SR supports all three methods following the best-practice RFC for TCP (RFC 5382, NAT Behavioral Requirements for TCP) and UDP (RFC 4787, Network Address Translation (NAT) Behavioral Requirements for Unicast UDP). Port Forwarding is supported on the 7750 SR to allow servers which operate on well-known ports <1024 (such as HTTP and SMTP) to request the appropriate outside port for permanent allocation.

STUN is facilitated by the support of Endpoint-Independent Filtering and Endpoint-Independent Mapping (RFC 4787) in the NAT device, allowing STUN-capable applications to detect the NAT and allow inbound P2P connections for that specific application. Many new SIP clients and IM chat applications are STUN capable.

Application Layer Gateways (ALG) allows the NAT to monitor the application running over TCP or UDP and make appropriate changes in the NAT translations to suit. The 7750 SR has an FTP ALG enabled following the recommendation of the IETF BEHAVE RFC for NAT (RFC 5382).

Even with these three mechanisms some applications still experience difficulty operating behind a NAT. As an industry-wide issue, forums like UPnP the IETF, operator and vendor communities are seeking technical alternatives for application developers to traverse NAT (including STUN support). In many cases the alternative of an IPv6-capable application gives better long-term support without the cost or complexity associated with NAT.

The S-NAPT service on the 7750 SR BNG incorporates a port range block feature to address scalability of a NAT mapping solution. With a single BNG capable of hundreds of thousands of NAT mappings every second, logging each mapping as it is created and destroyed logs for later retrieval (as may be required by law enforcement) could quickly overwhelm the fastest of databases and messaging protocols. Port range blocks address the issue of logging and customer location functions by allocating a block of contiguous outside ports to a single subscriber. Instead of logging each NAT mapping, a single log entry is created when the first mapping is created for a subscriber and a final log entry when the last mapping is destroyed. This can reduce the number of log entries by 5000x or more. An added benefit is that as the range is allocated on the first mapping, external applications or customer location functions may be populated with this data to make real-time subscriber identification, instead of having to query the NAT as to the subscriber identity in real-time and possibly delay applications.

Port range blocks are configurable as part of outside pool configuration, allowing the operator to specify the number of ports allocated to each subscriber when a mapping is created. When a range is allocated to the subscriber, these ports are used for all outbound dynamic mappings and are assigned in a random manner to minimize the predictability of port allocations (draft-ietf-tsvwg-port-randomization-05).

Port range blocks also serve another useful function in a Large Scale NAT environment, and that is to manage the fair allocation of the shared IP resources among different subscribers.

When a subscriber exhausts all ports in their block, further mappings are prohibited. As with any enforcement system, some exceptions are allowed and the NAT application can be configured for reserved ports to allow high-priority applications access to outside port resources while exhausted by low priority applications.

Pools with flexible port allocations are specialized pools that allow subscribers to configure per-port allocations instead of per port-block allocations for specific use cases. Logging of port allocations and deallocations within such pools is not facilitated. These pools are compatible with ESA-VM and vISA (VSR) and are not applicable to ISA2. These pools cater to users that have a dedicated private pool. Pools with flexible port allocations ensure that the external IP addresses of the pools are associated with a single user entity or a tenant even before the pool provisioning phase, which eliminates the need for logging.

When pools with flexible port allocations are configured, static port forwards are interspersed with dynamically allocated ports. These pool can only be linked via a NAT policy to a source prefix or to a static port forward. This allows NAT processing of traffic solely originating from the configured source prefix or address. Neither of these two mechanisms inherently steers traffic to the ESA-VM/vISA modules. Therefore, traffic for NAT processing is directed to pools with flexible port allocations based on either destination prefix or filter criteria. In this case, explicitly configured NAT policy is not allowed within a destination prefix or a filter . After the traffic is in the ESA-VM/vISA, the pool is selected based on the source prefix or an existing flow created under the static port forward, which does not have a NAT policy explicitly configured.

Execute the following command to configure pools with flexible port allocations:

• MD-CLI

  configure router nat outside pool applications flexible-port-allocation true

• classic CLI

  configure router nat outside pool flexible-port-allocation

The traffic is steered to ESA-VM/vISA based on a destination prefix or a filter criteria.

The following examples show configured NAT pools with flexible port allocations.

[ex:/configure service vprn nat inside large-scale]
A:admin@node-2# info
    traffic-identification {
        source-prefix-only true
    }
    nat44 {
        destination-prefix 0.0.0.0/0 {
        }
        source-prefix 10.10.10.0/24 {
            nat-policy "nat-pol-1"
        }
        source-prefix 10.10.11.0/24 {
            nat-policy "nat-pol-1"
        }
        source-prefix 10.10.12.0/25 {
            nat-policy "nat-pol-2"
        }
        source-prefix 10.10.12.128/25 {
            nat-policy "nat-pol-3"
        }
    }

A:node-2>config>service>vprn>nat>inside# info
----------------------------------------------
                    destination-prefix 0.0.0.0/0
                    traffic-identification
                        source-prefix-only
                    exit
                    source-prefix 10.10.10.0/24 nat-policy "nat-pol-1"
                    source-prefix 10.10.11.0/24 nat-policy "nat-pol-1"
                    source-prefix 10.10.12.0/25 nat-policy "nat-pol-2"
                    source-prefix 10.10.12.128/25 nat-policy "nat-pol-3"
----------------------------------------------

[ex:/configure filter ip-filter "demo-nat" entry 10]
A:admin@node-2# info    
    match {
        protocol 6
        dst-ip {
            address 0.0.0.0/1
        }
        dst-port {
            eq 2000
        }
    }
    action {
        nat {
        }
    }

A:node-2>config>filter>ip-filter>entry# info
----------------------------------------------
                match protocol 6
                    dst-ip 0.0.0.0/1
                    dst-port eq 2000
                exit
                action
                    nat
                exit
----------------------------------------------

[ex:/configure service vprn “nat”]
A:admin@node-2# info
    admin-state enable
    service-id 20
    customer "1"
    nat {
        inside {
            large-scale {
                traffic-identification {
                    source-prefix-only true
                }
                nat44 {
                    destination-prefix 0.0.0.0/0 {
                    }
                    source-prefix 10.10.10.0/24 {
                        nat-policy "nat-pol-1"
                    }
                    source-prefix 10.10.11.0/24 {
                        nat-policy "nat-pol-1"
                    }
                    source-prefix 10.10.12.0/25 {
                        nat-policy "nat-pol-2"
                    }
                    source-prefix 10.10.12.128/25 {
                        nat-policy "nat-pol-3"
                    }
                }
            }
        }
    }
    interface "access" {
        admin-state enable
        ipv4 {
            primary {
                address 172.16.102.1
                prefix-length 24
            }
        }
        sap lag-4:2 {
            ingress {
                filter {
                    ip "demo-nat"
                }
            }
        }
    }

A:node-2>config>service>vprn# info
----------------------------------------------
            interface "access" create
                address 172.16.102.1/24
                sap lag-4:2 create
                    ingress
                        filter ip 1
                    exit
                exit
            exit
            nat
                inside
                    destination-prefix 0.0.0.0/0
                    traffic-identification
                        source-prefix-only
                    exit
                    source-prefix 10.10.10.0/24 nat-policy "nat-pol-1"
                    source-prefix 10.10.11.0/24 nat-policy "nat-pol-1"
                    source-prefix 10.10.12.0/25 nat-policy "nat-pol-2"
                    source-prefix 10.10.12.128/25 nat-policy "nat-pol-3"
                exit
            exit
            no shutdown
----------------------------------------------

A NAT subscriber can allocate ports on a single outside IP address or multiple IP addresses in a NAT pool. Nokia recommends that NAT subscribers allocate ports from a single outside IP address. If this IP address runs out of ports, the NAT subscriber runs out of ports. In other words, there is no attempt for a new port to be allocated from a different outside IP address. This method of address allocation to a NAT subscriber is referred to as Paired Address Pooling and is the default behavior in SR OS.

The alternative method of port allocation involves port exhaustion on the originally allocated IP address. An attempt is made to allocate ports from another IP addresses that has free ports available. This results in a NAT subscriber be associated with multiple outside IP addresses. This method is referred to as Arbitrary Address Pooling and can be optionally enabled in SR OS. See RFC 7857, Section 4 for more information.

Arbitrary address pooling may offer more efficient allocations of port-blocks across outside IP address in a NAT pool, but it may negatively affect some applications. For example, an application may require two channels for communication, a control channel and a data channel, each on a different source port from the client perspective on the inside of the NAT. The communication channel may be established on the outside address IP1 and outside port X. If port X is the last free port on the IP1, the SR OS attempts to allocate the next port Y for the data channel from a different outside address, IP2. If the application is robust enough to accept communication from the same client on two different IP addresses, there are no issues. However, some applications may not support this scenario and the communication fails.

Arbitrary address pooling implies the following:

• The subscriber limit per outside IP address loses its meaning because the subscriber can now be associated with multiple IP addresses. Hence, the following command cannot be set:

  • MD-CLI

    configure router nat outside pool large-scale subscriber-limit

  • classic CLI

    configure router nat outside pool subscriber-limit

  For more information about the subscriber-limit command in paired address pooling, see Managing port block space.

• The number of outside IP addresses in a pool must be at least double the number of ESA-VM in a NAT-group hosting the subscriber. Each subscriber is hashed to a single ESA-VM, ISA2, or vISA; therefore at least two outside IP addresses must be available per ESA-VM, ISA2, or vISA for the subscriber to use more than one outside IP address.

• The number of port blocks configured in a NAT policy using the following command is the aggregate limit that a NAT subscriber can be allocated across multiple outside IP addresses.

  configure service nat nat-policy block-limit

• Reserving a port block by SPF configuration (when an SPF is configured before any port blocks are allocated to the subscriber) is not supported. In other words, the following commands are not supported:

  MD-CLI

  configure router nat outside pool port-forwarding dynamic-block-reservation

  classic CLI

  configure router nat outside pool port-forwarding-dyn-block-reservation

• Arbitrary address pooling is not supported in Layer 2–aware NAT.

show service nat lsn-subscribers subscriber

===============================================================================
NAT LSN subscribers
===============================================================================
Subscriber                  : [LSN-Host@192.168.1.1]
NAT policy                  : nat-policy-lsn-deterministic
Subscriber ID               : 276824064
-------------------------------------------------------------------------------
Type                        : classic-lsn-sub
Inside router               : "Base"
Inside IP address prefix    : 192.168.1.1/32
ISA NAT group               : 1
ISA NAT group member        : 1
Outside router              : 4
Outside IP address          : 192.0.0.1*  

Creating a NAT mapping is only one half of the problem – removing a NAT mapping at the appropriate time maximizes the shared port resource. Having ports mapped when an application is no longer active reduces solution scale and may impact the customer experience should they exhaust their port range block. The NAT application provides timeout configuration for TCP, UDP and ICMP.

TCP state is tracked for all TCP connections, supporting both three-way handshake and simultaneous TCP SYN connections. Separate and configurable timeouts exist for TCP SYN, TCP transition (between SYN and Open), established and time-wait state. Time-wait assassination is supported and enabled by default to quickly remove TCP mappings in the TIME WAIT state.

UDP does not have the concept of connection state and is subject to a simple inactivity timer. Company-sponsored research into applications and NAT behavior suggested some applications, like the BitTorrent Distributed Hash Protocol (DHT) can make a large number of outbound UDP connections that are unsuccessful. Instead of waiting the default five (5) minutes to time these out, the 7750 SR NAT application supports an udp-initial timeout which defaults to 15 seconds. When the first outbound UDP packet is sent, the 15 second time starts – it is only after subsequent packets (inbound or outbound) that the default UDP timer becomes active, greatly reducing the number of UDP mappings.

Layer 2–aware NAT bypass refers to the functionality where the entire or partial traffic from a L2-Aware-NAT-enabled ESM1 subscriber circumvents local NAT function. There are three types of bypass supported for Layer 2–aware NAT in the SR OS:

• full ESM host bypass

• selective ESM host bypass based on an IP filter match

• the entire ESM subscriber bypass because of ISA/ESA failure. This type of bypass is described in NAT redundancy.

Multiple NAT policies for a L2-Aware subscriber can be selected based on the destination IP address of the packet. This allows the operator to assign different NAT pools and outside routing contexts based on the traffic destinations.

The mapping between the destination IP prefix and the NAT policy is defined in a NAT prefix list. This NAT prefix list is applied to the L2-Aware subscriber through a subscriber profile. After the subscriber traffic arrives to the MS-ISA where NAT is performed, an additional lookup based on the destination IP address of the packet is executed to select the specific NAT policy (and consequently the outside NAT pool). Failure to find the specific NAT policy based on the destination IP address lookup results in the selection of the default NAT policy referenced in the subscriber profile.

[ex:/configure service]
A:admin@node-2# info
    nat {
        prefix-list "prefixlist1" {
            prefix 192.168.0.0/30 {
                nat-policy "l2aw nat policy"
            }
            prefix 192.168.0.64/30 {
                nat-policy "l2aw nat policy"
            }
            prefix 192.168.0.128/30 {
                nat-policy "l2aw nat policy"
            }
            prefix 192.168.1.0/30 {
                nat-policy "another-l2aw-nat-policy"
            }
            prefix 192.168.1.64/30 {
                nat-policy "another-l2aw-nat-policy"
            }
            prefix 192.168.1.128/30 {
                nat-policy "another-l2aw-nat-policy"
            }
        }
        nat-policy "another-l2aw-nat-policy" {
            pool {
                router-instance "Base"
                name "another-l2-aw-nat-pool"
            }
        }
        nat-policy "default-nat-policy" {
            pool {
                router-instance "Base"
                name "default-nat-pool"
            }
        }
        nat-policy "l2aw nat policy" {
            pool {
                router-instance "Base"
                name "l2-aw-nat-pool"
            }
        }
    }

[ex:/configure subscriber-mgmt]
A:admin@node-2# info
     sub-profile "sub_profile" {
        nat {
            policy "default-nat-policy"
            prefix-list "prefixlist1"
        }
    }

A:node-2>config>service# info
----------------------------------------------
service
   nat  
     nat-policy "l2aw-nat-policy" create                
       pool "l2aw-nat-pool" router 1
     exit
     nat-policy "another-l2aw-nat-policy" create
        pool "another-l2aw-nat-pool" router 2
     exit
nat-policy "default-nat-policy" create
        pool "default-nat-pool" router Base
     exit
         
     nat-prefix-list "prefixlist1" application l2-aware-dest-to-policy create
        prefix 192.168.0.0/30 nat-policy "l2aw-nat-policy"
          prefix 192.168.0.64/30 nat-policy "l2aw-nat-policy"
          prefix 192.168.0.128/30 nat-policy "l2aw-nat-policy"
          prefix 192.168.1.0/30 nat-policy "another-l2aw-nat-policy"
          prefix 192.168.1.64/30 nat-policy "another-l2aw-nat-policy"
          prefix 192.168.1.128/30 nat-policy "another-l2aw-nat-policy" 
        exit        
    exit
----------------------------------------------

A:node-2>config>subscr-mgmt# info
----------------------------------------------
    subscriber-mgmt        
        sub-profile "sub_profile" create            
            nat-policy "default-nat-policy"
            nat-prefix-list "prefixlist1"            
        exit
----------------------------------------------     

In static 1:1 NAT, inside IP addresses are statically mapped to the outside IP addresses. This way, devices on the outside can predictably initiate traffic to the devices on the inside.

Static configuration is based on the CLI concepts used in deterministic NAT. The following example shows a deterministic NAT configuration.

[ex:/configure router "Base" nat inside large-scale nat44 deterministic]
A:admin@node-2# info
    prefix-map 10.10.0.220/30 nat-policy "one-to-one-agnostic" {
        map 10.10.0.220 to 10.10.0.220 {
            first-outside-address 192.168.255.206
        map 10.10.0.221 to 10.10.0.221 {
            first-outside-address 192.168.255.207
        map 10.10.0.222 to 10.10.0.222 {
            first-outside-address 192.168.255.208
        map 10.10.0.223 to 10.10.0.223 {
            first-outside-address 192.168.255.209
        }
    }

A:node-2>config>router>nat>inside>deterministic# info
----------------------------------------------
 prefix-map 10.10.0.220/30 subscriber-type classic-lsn-sub nat-policy "one-to-one-agnostic" create
         map start 10.10.0.220 end 10.10.0.220 to 192.168.255.206
         map start 10.10.0.221 end 10.10.0.221 to 192.168.255.207
         map start 10.10.0.222 end 10.10.0.222 to 192.168.255.208
         map start 10.10.0.223 end 10.10.0.223 to 192.168.255.209
         no shutdown
    exit
----------------------------------------------

In 1:1 NAT, specific ICMP messages contain an additional IP header embedded in the ICMP header. For example, when the ICMP message is sent to the source because of the inability to deliver datagram to its destination, the ICMP generating node includes the original IP header of the packet plus 64bits of the original datagram. This information helps the source node to match the ICMP message to the process associated with this message.

When these messages are received in the downstream direction (on the outside), 1:1 NAT recognizes them and changes the destination IP address not only in the outside header but also in the ICMP header. In other words, a lookup in the downstream direction is performed in the ISA to determine if the packet is ICMP with a specific type. Depending on the outcome, the destination IP address in the ICMP header is changed (reverted to the original source IP address).

Messages carrying the original IP header within ICMP header are:

• Destination Unreachable Messages (Type 3)

• Time Exceeded Message (Type 11)

• Parameter Problem Message (Type 12)

• Source Quench Message (Type 4)

In deterministic NAT the subscriber is deterministically mapped into an outside IP address and a port block. The algorithm that performs this deterministic mapping is revertive, which means that a NAT subscriber can be uniformly derived from the outside IP address and the outside port (and the routing instance). Thus, logging in deterministic NAT is not needed.

The deterministic [subscriber <-> outside-ip, deterministic-port-block] mapping can be automatically extended by a dynamic port-block in case that deterministic port block becomes exhausted of ports. By extending the original deterministic port block of the NAT subscriber by a dynamic port block yields a satisfactory compromise between a deterministic NAT and a non-deterministic NAT. There is no logging as long as the translations are in the domain of the deterministic NAT. After the dynamic port block is allocated for port extension, logging is automatically activated.

NAT subscribers in deterministic NAT are not assigned outside IP address and deterministic port-block on a first come first serve basis. Instead, deterministic mappings are pre-created at the time of configuration regardless of whether the NAT subscriber is active or not. In other words we can say that overbooking of the outside address pool is not supported in deterministic NAT. Consequently, all configured deterministic subscribers (for example, inside IP addresses in LSN44 or IPv6 address/prefix in DS-Lite) are guaranteed access to NAT resources.

The routers support Deterministic LSN44 and Deterministic DS-Lite. The basic deterministic NAT principle is applied equally to both NAT flavors. The difference between the two stem from the difference in interpretation of the subscriber – in LSN44 a subscriber is an IPv4 address, whereas in DS-Lite the subscriber is an IPv6 address or prefix (configuration dependent).

Deterministic DS-Lite section at the end of this section focuses on the features specific to DS-Lite.

The maximum number of NAT subscribers that can be mapped to a single outside IP address is configurable using the following command.

• MD-CLI

  configure router nat outside pool large-scale subscriber-limit
  configure service vprn nat outside pool large-scale subscriber-limit

• classic CLI

  configure router nat outside pool subscriber-limit
  configure service vprn nat outside pool subscriber-limit

For Deterministic NAT in a system with multiple ESA-VMs in a NAT group, this number is restricted to the power of 2 (2^n). In a system with a single ESA-VM in a NAT-group and NAT44, this restriction does not apply and a flexible number of NAT subscribers can be mapped to an outside IP address. See Flexible number of subscribers per outside IP (single IP) address.

For example, in a multi-ESA-VM system with NAT44 where the NAT subscriber is an IP address, the deterministic subscribers are configured with prefixes (for example, a prefix 10.10.10.0/24 corresponds to 256 or 2^8 subscribers) as opposed to an IP address range that would contain a flexible number of addresses (for example, a range of 10.10.0.5 – 10.10.0.104 which would contain a 100 IP addresses).

However, in a system with a single ESA-VM in a NAT group, deterministic NAT44 subscribers can be configured with an address map with a flexible number of IP addresses, that is, not restricted by the 2^n rule.

In deterministic NAT, the outside pool can be shared amongst subscribers from multiple routing instances. Also, NAT subscribers from a single routing instance can be selectively mapped to different outside pools.

The number of deterministic mappings that a single outside IP address can sustain is determined through the configuration of the outside pool.

The port allocation per an outside IP is shown in Outside pool configuration (classic CLI).

The well-known ports are predetermined and are in the range 0 to 1023.

The remaining ports, extending from the end of the deterministic port range to the end of the total port range (65535) are used for dynamic port allocation. The size of each dynamic port block is determined with the existing port-reservation command.

The deterministic port-reservation command enables deterministic mode of operation for the pool.

Three examples follow, with deterministic Large Scale NAT44, where the requirements are:

• 300, 500, or 700 (three separate examples) ports are in each deterministic port block.

• A subscriber (an inside IPv4 address in LSN44) can extend its deterministic ports by a minimum of one dynamic port-block and by a maximum of four dynamic port blocks.

• Each dynamic port-block contains 100 ports.

• Oversubscription of dynamic port blocks is 4:1. This means that 1/4th of inside IP addresses may be starved out of dynamic port blocks in worst case scenario.

• The wildcard (static) port range is 3000 ports.

In the first case, the ideal case is examined where an arbitrary number of subscribers per outside IP address is allocated according to our requirements described above. Then the limitation of the number of subscribers being power of 2 is factored in.

The example in Contiguous number of subscribers shows how port ranges would be carved out in ideal scenario.

The other values are calculated according to the fixed requirements.

The port-block limit includes the deterministic port blocks plus all dynamic port blocks.

Next, in Preserving Det/Dyn port ratio with 2^n subscribers, a more realistic example with the number of subscribers being equal to 2^n are considered. The ratio between the deterministic ports and the dynamic ports per port block just like in the example above: 3/1, 5/1 and 7/1 are preserved. In this case, the number of ports per port block is dictated by the number of subscribers per outside IP address.

The final example (Fixed number of deterministic ports with 2^n subscribers) is similar as Contiguous number of subscribers with the difference that the number of deterministic port blocks fixed are kept, as in the original example (300, 500 and 700).

The three preceding examples should give a perspective on the size of deterministic and dynamic port blocks in relation to the number of subscribers (2^n) per outside IP address. Users should run a similar dimensioning exercise before they start configuring their deterministic NAT.

The CLI for the highlighted case in the Contiguous number of subscribers is displayed.

[ex:/configure service vprn "7"]
A:admin@node-2# info
    customer "1"
    nat {
        outside {
            pool "mypool" {
                type large-scale
                nat-group 1
                port-forwarding {
                    range-end 4023
                }
                port-reservation {
                    ports 180
                }
                large-scale {
                    subscriber-limit 128
                    deterministic {
                        port-reservation 300
                    }
                }
            }
        }
    }

A:node-2>config>service>vprn$ info
----------------------------------------------
            no shutdown
            nat
                outside
                    pool "mypool" nat-group 1 type large-scale create
                        shutdown
                        port-reservation ports 180
                        port-forwarding-range 4023
                        subscriber-limit 128
                        deterministic
                            port-reservation 300
                        exit
                    exit
                exit
            exit
----------------------------------------------

[ex:/configure service nat]
A:admin@node-2# info
    nat-policy "mypolicy" {
        block-limit 5
    }

A:node-2>config>service>nat# info
----------------------------------------------
            nat-policy "mypolicy" create
                block-limit 5      1 deterministic port block + 4 dynamic port blocks
            exit
----------------------------------------------

This configuration allows 128 subscribers (inside IP addresses in LSN44) for each outside address (compression ratio is 128:1) with each subscriber being assigned up to 1020 ports (300 deterministic and 720 dynamic ports over 4 dynamic port blocks).

The outside IP addresses in the pool and their corresponding port ranges are organized as shown in the following diagram. .

Assuming that the preceding graph depicts an outside deterministic pool, the number of subscribers that can be accommodated by this deterministic pool is represented by purple squares (number of IP addresses in an outside pool * subscriber-limit). The number of subscribers across all configured prefixes on the inside that are mapped to the same deterministic pool must be less than the outside pool can accommodate. In other words, an outside address pool in deterministic NAT cannot be oversubscribed.

The following example displays a CLI representation of a deterministic pool definition including the outside IP ranges.

[ex:/configure service vprn "1"]
A:admin@node-2# info
    customer "1"
    nat {
        outside {
            pool "mypool" {
                type large-scale
                nat-group 1
                port-forwarding {
                    range-end 4023
                }
                port-reservation {
                    ports 461
                }
                large-scale {
                    subscriber-limit 64
                    deterministic {
                        port-reservation 2
                    }
                }
            }
        }
    }

A:node-2>config>service>vprn$ info
----------------------------------------------
            shutdown
            nat
                outside
                    pool "mypool" nat-group 1 type large-scale create
                        shutdown
                        port-reservation ports 461
                        port-forwarding-range 4023
                        subscriber-limit 64
                        deterministic
                            port-reservation 2
                        exit
                    exit
                exit
            exit
----------------------------------------------

Support for multiple MS-ISAs in the NAT group calls for traffic hashing on the inside in the ingress direction. This ensures fair load balancing of the traffic amongst multiple MS-ISAs. While hashing in non-deterministic LSN44 can be performed per source IP address, hashing in deterministic LSN44 is based on subnets instead of individual IP addresses. The length of the hashing subnet is common for all configured prefixes within an inside routing instance. In the case where prefixes from an inside routing instance are referencing multiple pools, the common hashing prefix length is chosen according to the pool with the highest number of subscribers per outside IP address. This ensures that subscribers mapped to the same outside IP address are always hashed to the same MS-ISA.

In general, load distribution based on hashing is dependent on the sample. A large and more diverse sample ensures better load balancing. Therefore, the efficiency of load distribution between the MS-ISAs is dependent on the number and diversity of subnets that the hashing algorithm takes into consideration within the inside routing context.

A simple rule for good load balancing is to configure a large number of subscribers relative to the largest subscriber limit in any pool that is referenced from this inside routing instance.

Deterministic LSN44 configuration example (classic CLI) shows a case in which prefixes from multiple routing instances are mapped to the same outside pool and at the same time the prefixes from a single inside routing instance are mapped to different pools (Nokia does not support the latter with non-deterministic NAT).

In a deterministic NAT with a single ESA-VM in a NAT group, the number of subscribers per outside IP address does not have to be restricted to 2^n. Instead, a flexible number of subscribers can be mapped to an outside IP address. This mode of operation is enabled via configuration. The default mode of operation is the one with discrete number (2^n) of subscribers per outside IP address. To enable this feature, the NAT group must contain a single ESA-VM.

[ex:/configure service vprn "demo-vprn" nat inside large-scale nat44]
A:admin@node-2# info
    deterministic {
        address-map 10.10.0.5 to 10.10.0.104 nat-policy "demo-nat-policy" {
            admin-state enable
            outside-range 192.0.2.15
        }
    }

A:node-2>config>service>vprn>nat>inside# info 
----------------------------------------------
                    deterministic
                        address-map 10.10.0.5 to 10.10.0.10 subscriber-type classic-lsn-sub nat-policy "demo-nat-policy" create
                            no shutdown
                            outside-range start 192.0.2.15
                        exit
                    exit

[ex:/configure router "Base" nat outside pool "pool-1"]
A:admin@node-2# info
    type large-scale
    nat-group 1
    port-forwarding {
        range-end 5534
    }
    large-scale {
        subscriber-limit 20
        deterministic {
            port-reservation 3000
        }
    }
    address-range 192.0.2.15 end 192.0.2.19 {
    }

A:node-2>config>router>nat>outside>pool# info
----------------------------------------------
                    shutdown
                    port-forwarding-range 5534
                    subscriber-limit 20
                    deterministic
                        port-reservation 3000
                    exit
                    address-range 192.0.2.15 192.0.2.19 create
                    exit
----------------------------------------------

Sharing of the deterministic pools between LSN44 and DS-Lite is supported.

Simultaneous support for deterministic and non-deterministic NAT inside of the same routing instance is supported. However, an outside pool can be only deterministic (although expandable by dynamic ports blocks) or non-deterministic at any time.

Ingress hashing for all NAT’d traffic within the VRF, in this case, is performed based on the subnets driven by the classic-lsn-max-subscriber-limit parameter.

Deterministic NAT does not change the way how traffic is selected for the NAT function but instead only defines a predictable way for translating subscribers into outside IP addresses and port-blocks.

Traffic is still diverted to NAT using the existing methods:

• routing based

  Traffic is forwarded to the NAT function if it matches a configured destination prefix that is part of the routing table. In this case inside and outside routing context must be separated.

• filter based

  Traffic is forwarded to the NAT function based on any criteria that can be defined inside an IP filter. In this case the inside and outside routing context can be the same.

The inverse mapping can be performed with a MIB locally on the node or externally via a script sourced in the router. In both cases, the input parameters are <outside routing instance, outside IP, outside port. The output from the mapping is the subscriber and the inside routing context in which the subscriber resides.

Every configuration change concerning the deterministic pool is logged and the script (if configured for export) is automatically updated (although not exported). This is needed to keep current track of deterministic mappings. In addition, every time a deterministic port-block is extended by a dynamic block, the dynamic block is logged just as it is today in non-deterministic NAT. The same logic is followed when the dynamic block is de-allocated.

All static port forwards (including PCP) are also logged.

PCP allocates static port forwards from the wildcard-port range.

All incoming IPv6 traffic with source IPv6 addresses falling under a unique IPv6 prefix that is configured with the subscriber-prefix-length command is considered as a single subscriber. As a result, all source IPv4 addresses carried within that IPv6 prefix are mapped to the same outside IPv4 address.

The concept of deterministic DS-Lite is very similar to deterministic LSN44. The DS-Lite subscribers (IPv6 addresses/prefixes) are deterministically mapped to outside IPv4 addresses and corresponding deterministic port-blocks.

Although the subscriber in DS-Lite is considered to be either a B4 element (IPv6 address) or the aggregation of B4 elements (IPv6 prefix determined by the subscriber-prefix-length command), only the IPv4 source addresses and ports carried inside of the IPv6 tunnel are actually translated.

The prefix statement for deterministic DS-Lite remains under the same deterministic CLI node as for the deterministic LSN44. However, the prefix statement parameters for deterministic DS-Lite differ from the one for deterministic LSN44 in the following fashion:

• DS-Lite prefix is an IPv6 prefix (instead of IPv4). The DS-Lite subscriber whose traffic is mapped to a particular outside IPv4 address and the deterministic port block is deduced from the prefix statement and the subscriber-prefix-length statement.

• In the classic CLI, the subscriber type is set to dslite-lsn-sub.

[ex:/configure service vprn "10"]
A:admin@node-2# info
    customer "1"
    nat {
        inside {
            large-scale {
                dual-stack-lite {
                    max-subscriber-limit 128
                    subscriber-prefix-length 60
                    deterministic {
                        prefix-map 2001:db8::/56 nat-policy "det-policy" {
                        }
                    }
                }
            }
        }
    }

A:node-2>config>service>vprn# info
----------------------------------------------
            shutdown
            nat
                inside
                    dslite-max-subscriber-limit 128
                    deterministic
                        prefix-map 2001:db8::/56 subscriber-type dslite-lsn-sub nat-policy "det-policy" create
                            shutdown
                        exit
                    exit
                    dual-stack-lite
                        shutdown
                        subscriber-prefix-length 60
                    exit
                exit
            exit
----------------------------------------------

[ex:/configure service vprn "10" nat inside large-scale dual-stack-lite deterministic prefix-map 2001:db8::/56 nat-policy "policy-1"]
A:admin@node-2# info
    map 2001:db8::/60 to 2001:db8:0:f0::/60 {
        first-outside-address 192.168.1.1
    }

A:node-2>config>service>vprn>nat>inside>deterministic>prefix-map# info
	map start 2001:db8::/60 end 2001:db8:00:F0::/60 to 192.168.1.1

2001:db8::/60 to 2001:db8:00:70::/60 to 192.168.1.1 
2001:db8:00:80::/60 to 2001:db8:00:F0::/60 to 192.168.1.2

In specific cases SNAPT is required along with DNAT. In other cases only DNAT is required without SNAPT. Supported combinations of SNAPT and DNAT shows the supported combinations of SNAPT and DNAT in SR OS.

The SNAPT/DNAT address translations are shown in IP address/port translation modes.

NAT forwarding in SR OS is implemented in two stages:

1. Traffic is first directed toward the MS-ISA. This is performed via a routing lookup, via a filter or via a subscriber-management lookup (Layer 2–aware NAT). DNAT does not introduce any changes to the steering logic responsible for directing traffic from the I/O line card toward the MS-ISA.

2. When traffic reaches the MS-ISA, translation logic is performed. DNAT functionality incurs an additional lookup in the MS-ISA. This lookup is based on the protocol type and the destination port of the packets, as defined in the nat-classifier.

As part of the NAT state maintenance, the SR OS maintains the following fields for each DNATed flow:

<inside host /port, outside IP/port, foreign IP address/port, destination IP address/port, protocol (TCP,TCP,ICMP)> Note that the inside host in LSN is inside the IP address and in Layer 2–aware NAT it is the <inside IP address + subscriber-index>. The subscriber index is carried in session-id of the L2TP.

The foreign IP address represents the destination IP address in the original packet, while the destination IP address represents the DNAT address (translated destination IP address).

Traffic intended for DNAT processing is selected via a NAT classifier. The NAT classifier has configurable protocol and destination ports. The inclusion of the classifier in the NAT policy is the trigger for performing DNAT. The configuration of the NAT classifier determines which of the following is true:

• A specific traffic defined in the match criteria is DNATed while the rest of the traffic is transparently passed through the NAT classifier.

• A specific traffic defined in the match criteria is transparently passed through the NAT classifier while the rest of the traffic is DNATed.

Classifier cannot drop traffic (no action drop). However, a non-reachable destination IP address in DNAT causes traffic to be black-holed.

The DNAT function is triggered by the presence of the NAT classifier, referenced in the NAT policy. The dnat-only command is configured in cases where SNAPT is not required. This command is necessary to determine the outside routing context and the NAT group (nat-group command), when SNAPT is not configured. The pool (relevant to SNAPT) and dnat-only command options within the NAT policy are mutually exclusive.

The following restrictions apply to multiple NAT policies per inside routing context:

• There is no support for Layer 2–aware NAT.

• DS-Lite and NAT64 diversion to NAT is supported only through IPv6 filters.

• The default NAT policy is counted toward this limit (8).

The selection of the NAT pool and the outside routing context is performed through the NAT policy. Multiple NAT policies can be used within an inside routing context. This feature effectively allows selective mapping of the incoming traffic within an inside routing context to different NAT pools (with different mapping properties, such as port-block size, subscriber-limit per pool, address range, port-forwarding range, deterministic vs non-deterministic behavior, port-block watermarks, and so on) and to different outside routing contexts. NAT policies can be configured:

• via filters as part of the action nat command

• via routing with the destination-prefix command within the inside routing context

The concept of the NAT pool selection mechanism based on the destination of the traffic via routing is shown in Pool selection based on traffic destination.

Diversion of the traffic to NAT based on the source of the traffic is shown in NAT pool selection based on the inside source IP address.

Only the filter-based diversion solution is supported for this case. The filter-based solution can be extended to a five tuple matching criteria.

The following considerations must be taken into account when deploying multiple NAT policies per inside routing context:

• The inside IP address can be mapped into multiple outside IP addresses based on the traffic destination. The relationship between the inside IP and the outside IP is 1:N.

• In case where the source IP address is selected as a matching criteria for a NAT policy (or pool) selection, the inside IP address always stays mapped to the same outside IP address (relationship between the inside IP and outside IP address is, in this case, 1:1)

• Static Port Forwards (SPF); each SPF can be created only in one pool. This means that the pool (or NAT policy) must be an input parameter for SPF creation.

In other words, the upstream traffic is NAT’d only if it matches a preconfigured destination IP prefix. The destination-prefix command creates a static route in the routing table of the inside routing context. This static route diverts all traffic with the destination IP address that matches the created entry, toward the MS-ISA. The NAT function itself is performed when the traffic is in the correct context in the MS-ISA.

The following example displays the configuration of multiple NAT policies per inside routing context with routing based diversion to NAT.

[ex:/configure service vprn "66"]
A:admin@node-2# info
    customer "1"
    nat {
        inside {
            large-scale {
                nat44 {
                    destination-prefix 10.20.10.0/24 {
                        nat-policy "policy-1"
                    }
                    destination-prefix 10.30.30.0/24 {
                        nat-policy "policy-1"
                    }
                    destination-prefix 10.40.40.0/24 {
                        nat-policy "policy-2"
                    }
                }
            }
        }
    }

[ex:/configure router "Base"]
A:admin@node-2# info
    nat {
        inside {
            large-scale {
                nat44 {
                    max-subscriber-limit 256
                    destination-prefix 10.20.10.0/24 {
                        nat-policy "policy-1"
                    }
                    destination-prefix 10.30.30.0/24 {
                        nat-policy "policy-1"
                    }
                    destination-prefix 10.40.40.0/24 {
                        nat-policy "policy-2"
                    }
                }
            }
        }
    }

A:node-2>config>service>vprn# info
----------------------------------------------
            shutdown
            nat
                inside
                    destination-prefix 10.20.10.0/24 nat-policy "policy-1"
                    destination-prefix 10.30.30.0/24 nat-policy "policy-1"
                    destination-prefix 10.40.40.0/24 nat-policy "policy-2"
                exit
            exit
----------------------------------------------

A:node-2>config>router# info
...
#--------------------------------------------------
echo "NAT Configuration"
#--------------------------------------------------
            shutdown
            nat
                inside
                    destination-prefix 10.20.10.0/24 nat-policy "policy-1"
                    destination-prefix 10.30.30.0/24 nat-policy "policy-1"
                    destination-prefix 10.40.40.0/24 nat-policy "policy-2"
                exit
            exit
----------------------------------------------

configure filter ip-filter entry match

configure filter ip-filter entry action nat [nat-policy nat-policy-name]

The association with the NAT policy is made after the filter is applied to the SAP.

DS-Lite and NAT64 diversion to NAT with multiple NAT policies is supported only through IPv6 filters. The following example displays the configuration of NAT traffic diversion based on an IPv6 filter NAT64.

[ex:/configure filter]
A:admin@node-2# info
    ipv6-filter "1" {
        entry 1 {
            action {
                nat {
                    nat-policy "policy-1"
                    nat-type nat64
                }
            }
        }
    }

A:node-2>config>filter# info
----------------------------------------------
        ipv6-filter 1 name "1" create
            entry 1 create
                action
                    nat nat-type nat64 nat-policy "policy-1"
                exit
            exit
        exit
----------------------------------------------

This default NAT policy can reference any configured pool in the needed ISA group. The pool referenced in the default NAT policy can be then overridden by the NAT policy associated with the destination prefix in LSN44 or by the NAT policy referenced in the IPv4 filter or IPv6-filter used for NAT diversion in LSN44, DS-Lite, NAT64.

The NAT CLI nodes fail to activate, unless a valid NAT policy is referenced in the preceding context.

Each subscriber using multiple policies is counted as one subscriber for the inside resources scaling limits (such as the number of subscribers per MS-ISA), and counted as one subscriber per (subscriber and policy combination) for the outside limits (subscriber-limit subscribers per IP; port-reservation port/block reservations per subscriber).

Any Static Port Forward (SPF) can be created only in one pool. This pool, which is referenced through the NAT policy, has to be specified at the SPF creation time, either explicitly through the configuration request or implicitly via defaults.

The consequence of this is that the user must know the NAT policy in which the SPF is to be created. The SPF cannot be created via PCP outside of the pool referenced by the default NAT policy, because PCP does not provide means to communicate NAT policy name in the SPF creation request.

The static port forward creation and their use by the subscriber types must follow these rules:

• default NAT policy

  Any subscriber type can use an SPF created in the pool referenced by the default NAT policy.

• deterministic LSN44 NAT policy

  Only deterministic LSN44 subscribers matching the configured prefix can use the SPF created in the pool referenced by the deterministic LSN44 prefix NAT policy.

• deterministic DS-Lite NAT policy

  Only deterministic DS-Lite subscribers matching the configured prefix can use the SPF created in the pool referenced by the deterministic DS-Lite prefix NAT policy.

• LSN44 filter based NAT policy

  Only LSN44 subscribers matching the configured filter entry can use the SPF created in the pool referenced by the non-deterministic LSN44 NAT policy within the filter.

• DS-Lite filter based NAT policy

  Only DS-Lite subscribers matching the configured filter entry can use the SPF created in the pool referenced by the DS-Lite NAT policy within the filter.

• NAT64 filter based NAT policy

  Only NAT64 subscribers matching the configured filter entry can use the SPF created in the pool referenced by the NAT64 NAT policy within the filter.

When the last relevant policy for a specific subscriber type is removed from the virtual router, the associated port forwards are automatically deleted.

The behavior for NAT policy changes via CoA for LSN and Layer 2–aware NAT is summarized in NAT policy changes via CoA.

Adding, removing, or replacing DNAT options in LSN44 can be achieved through NAT policy manipulation in an IP filter for ESM subscriber. The rules for NAT policy manipulation via CoA are given in NAT policy changes via CoA. In Layer 2–aware NAT, CoA can be used to:

• enable or disable DNAT functionality while leaving the Source Network Address and Port Translation (SNAPT) uninterrupted

• modify the default destination IP address in DNAT

After the DNAT configuration is modified via CoA (enable or disable DNAT or change the default DNAT IP address), the existing flows affected by the change remain active for 5 more seconds while the new flows are created in accordance with the new configuration. After a 5 second timeout, the stale flows are cleared from the system.

The RADIUS attribute used to perform DNAT modifications is a composite attribute with the following format:

Alc-DNAT-Override (234) = ‟{<DNAT_state> | <DNAT-ip-addr>},[nat-policy]”

where: DNAT_state = none | disable and the DNAT-ip-addr option are mutually exclusive.

DNAT-ip-addr – Provides an implicit enable with the destination IPv4 address in dotted format (a.b.c.d) and the DNAT-state option are mutually exclusive.

nat-policy = NAT policy name – This is an optional option. If it is not present, the default NAT policy is assumed.

For example:

Alc-DNAT-Override=none – This negates any previous DNAT-related override in the default NAT policy. Consequently, the DNAT functionality is set as originally defined in the default NAT policy. In case that the none value is received while DNAT is already enabled, a CoA ACK is sent back to the originator.

Alc-DNAT-Override = none,nat-pol-1 – This re-enables DNAT functionality in the specific NAT policy with the name "nat-policy-1".

Alc-DNAT-Override = none,10.1.1.1 – The DNAT_state and DNAT-ip-addr options are mutually exclusive within the same Alc-DNAT-Override attribute. Although a CoA ACK reply is returned to the RADIUS server, an error log message is generated in the SR OS indicating that the attempted override failed.

Alc-DNAT-Override =10.1.1.1 – This changes the default DNAT IP address to 1.1.1.1 in the default NAT policy. In case DNAT was disabled before receiving this CoA, it is implicitly enabled.

Alc-DNAT-Override =10.1.1.1,nat-pol-1 – This changes the default DNAT IP address to 10.1.1.1 in the specific NAT policy named "nat-policy-1". DNAT is implicitly enabled if it was disabled before receiving this CoA.

The combination of sub-fields with the Alc-DNAT-Override RADIUS attribute and the corresponding actions are shown in CoA and DNAT.

If multiple Alc-DNAT-Override attributes with conflicting actions are received in the same CoA or Access-Accept, the action that occurred last takes precedence.

For example, if the following two Alc-DNAT-Override attributes are received in the same CoA, the last one takes effect and consequently DNAT is disabled in the default NAT policy:

Alc-DNAT-Override = ‟10.1.1.1‟

Alc-DNAT-Override = ‟disable‟

Modifying active NAT prefix list or NAT classifier describes the outcome when the active NAT prefix list or NAT classifier is modified using CLI.

Use the command options in the following command to manage port forwarding for Large Scale NAT (LSN):

• MD-CLI, NETCONF, and classic CLI

  In the MD-CLI, NETCONF, and classic CLI, use the options under the following command to manage NAT Static Port Forwards (SPFs). This command enables large-scale NAT port forwarding actions.

  tools perform nat port-forwarding-action lsn

  For the preceding tools command, if you do not explicitly configure the following optional fields, the system selects them automatically:

  • port number – number of the source port
  • outside IP – IPv4 address for the outside IP address
  • outside-port number – number of the outside port
  • NAT policy – name of the NAT policy

  If the preceding tools command is configured to manage SPFs and preserve SPFs across reboots, you must use the following command to enable persistency of the SPF. With persistency enabled, SPF configuration is stored on the compact flash.

  configure system persistence nat-port-forwarding

• classic CLI

  In the classic CLI, you can manage SPFs through the preceding tools command or the following configuration command. This command creates NAT static port forwards for LSN44, Ds-Lite and NAT64.

  configure service nat port-forwarding lsn

[/tools perform nat port-forwarding-action]
A:admin@node-2# lsn add router 100 ip 10.2.3.4 protocol udp lifetime infinite outside-port 888

[/]
*A:node-2# configure system persistence nat-port-forwarding location cf3

[/]
*A:node-2# tools dump persistence nat-port-forwarding
----------------------------------------
Persistence Info
----------------------------------------
Client : nat-fwds
File Info :
Filename : cf3:\nat_fwds.002
File State : CLOSED (Not enough space on disk)
Subsystem Info :
Nbr Of Registrations : 524288
Registrations In Use : 2
Subsystem State : NOK

*A:node-2# tools perform nat port-forwarding-action lsn create router 100
ip 10.2.3.4 protocol udp lifetime infinite outside-port 888
*A:node-2# configure system persistence nat-port-forwarding location cf3:
*A:node-2# tools dump persistence nat-port-forwarding
----------------------------------------
Persistence Info
----------------------------------------
Client : nat-fwds
File Info :
Filename : cf3:\nat_fwds.002
File State : CLOSED (Not enough space on disk)
Subsystem Info :
Nbr Of Registrations : 524288
Registrations In Use : 2
Subsystem State : NOK

*A:node-2>config>service>nat>fwd# lsn router 101 ip 11.11.13.7 protocol udp port 12345 outside-ip 130.0.255.254 outside-port 3171 nat-policy "pol1_for_2001-pool-0"

PCP is a protocol that operates between subscribers and the NAT directly. This makes the protocol similar to DHCP or PPP in that the subscriber has a limited but direct control over the NAT behavior.

PCP is designed to allows the configuration of static port-forwards, obtain information about existing port forwards and to obtain the outside IP address from software running in the home network or on the CPE.

PCP runs on each MS-ISA as its own process and make use of the same source-IP hash algorithm as the NAT mappings themselves. The protocol itself is UDP based and is request/response in nature, in some ways, similar to UPnP.

PCP operates on a specified loopback interface in a similar way to the local DHCP server. It operates on UDP and a specified (in CLI) port. As Epoch is used to help recover mappings, a unique PCP service must be configured for each NAT group.

When epoch is lowered, there is no mechanism to inform the clients to refresh their mappings en masse. External synchronization of mappings is possible between two chassis (epoch does not need to be synchronized). If epoch is unsynchronized then the result is clients re-creating their mapping on next communication with the PCP server.

     0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 1  |R|   OpCode    |      Reserved (16 bits)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Requested Lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The R-bit (0) indicates request and (1) indicates response. This is a request so (0).

OpCode defined as:

Requested Lifetime: Lifetime 0 means delete.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 1  |R|   OpCode    |   Reserved    |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Lifetime                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Epoch                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) OpCode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Options                                :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As this is a response, R = (1).

The Epoch field increments by 1 every second and can be used by the client to determine if state needs to be restored. On any failure of the PCP server or the NAT to which it is associated Epoch must restart from zero (0).

Result Codes:

0 SUCCESS, success.

1 UNSUPP_VERSION, unsupported version.

2 MALFORMED_REQUEST, a general catch-all error.

3 UNSUPP_OPCODE, unsupported OpCode.

4 UNSUPP_OPTION, unsupported option. Only if the Option was mandatory.

5 MALFORMED_OPTION, malformed option.

6 UNSPECIFIED_ERROR, server encountered an error

7 MISORDERED_OPTIONS, options not in correct order

Creating a Mapping

Client Sends

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |          Reserved (24 bits)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Internal port          |   Suggested external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Suggested External IP Address (32 or 128, depending on OpCode):
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MAP4 opcode is (1). Protocols: 0 – all; 1 – ICMP; 6 – TCP; 17 – UDP.

MAP4 (1), PEER4 (3) and PREFER_FAILURE are supported. FILTER and THIRD_PARTY are not supported.

Universal Plug and Play (UPnP), which is a set of specifications defined by the UPnP forum. One specification is called Internet Gateway Device (IGD) which defines a protocol for clients to automatically configure port mappings on a NAT device. Today, many gaming, P2P, VoIP applications support the UPnP IGD protocol. The SR OS supports the following UPnP version 1 InternetGatewayDevice version 1 features:

• Supports only Layer 2–aware NAT hosts.

• Distributed subscriber management is not supported.

• The UPnP server runs on NAT ISA and only serves the local Layer 2–aware NAT hosts on the same ISA.

• The UPnP server can be enabled per subscriber by configuring a UPnP policy in the sub-profile in the following command.

  configure subscriber-mgmt sub-profile upnp-policy 

• UPnP discovery is supported.

• UPnP event notification (eventing) is not supported.

• The following IGD devices and services are supported:

  • WANDevice

  • WANConnectionDevice

  • WANIPConnection service

• For WANIPConnection services:

  • Optional state variables in a WANIPConnection service are not supported.

  • Optional actions in a WANIPConnection services are not supported.

  • Wildcard ExternalPort is not supported.

  • Only supports wildcard RemoteHost.

  • Up to 64 bytes of port mapping description are supported.

  • The SR OS supports a vendor specific action X_ClearPortMapping. This clears all port mappings of the subscriber belonging to the requesting host. This action has no in or out arguments.

• If the NewExternalPort in an addPortMapping request is same as the external port of one existing UPnP port mapping:

  • If NewInternalClient is different from InternalClient of existing mapping, then the system rejects the request.

  • If NewInternalClient is same as InternalClient of existing mapping:

    • With strict-mode on, if the source IP address of the request is same as InternalClient of existing mapping, then the request is accepted; otherwise the request is rejected.

    • With strict-mode off, the request is accepted.

• The system also supports the Alc-UPnP-Sub-Override-Policy RADIUS VSA which can be included in access-accept or CoA request. It can be used to override the upnp-policy command configured in sub-profile or disable UPnP for the subscriber. See RADIUS reference guide for detail usage.

There are two components of PPTP:

• TCP control connection between the two endpoints

• an IP tunnel operating between the same endpoints. These are used to transport GRE encapsulated PPP packets for user sessions between the endpoints. PPTP uses an extended version of GRE to carry user PPP packets.

The control connection is established from the PPTP clients (for example, home users behind the NAT) to the PPTP server which is located on the outside of the NAT. Each session that carries data between the two endpoints can be referred as call. Multiple sessions (or calls) can carry data in a multiplexed fashion over a tunnel. The tunnel protocol is defined by a modified version of GRE. Call ID in the GRE header is used to multiplex sessions over the tunnel. The Call-ID is negotiated during the session/call establishment phase.

PPTP ALG is aware of the control session (Start Control Connection Request/Replay) and consequently it captures the Call ID field in all PPTP messages that carry that field. In addition to translating inside IP and TCP port, the PPTP ALG process data beyond the TCP header to extract the Call ID field and translate it inside of the Outgoing Call Request messages initiated from the inside of the NAT.

The GRE packets with corresponding Call IDs are translated through the NAT as follows:

• The inside source IP address is replaced by the outside IP address and the opposite is true for traffic in the opposite direction. This is standard IP address translation technique. The key is to keep the outside IP address of the control packets and corresponding data packets (GRE tunnel) the same.

• The Call-ID in the GRE packets in the direction of outside to inside is translated by the NAT according to the mappings that were created during session negotiation.

In addition, the following applies:

• GRE packets are translated and passed through the NAT only if they can be matched to an existing PPTP call for which the mapping already exists.

• Translation of the Call-IDs advertised by the PPTP server in the Outgoing Call Reply control message (this message is sent from the outside of the NAT to the inside) are not translated. Subsequently the Call ID in such messages are transparently passed through the NAT. There is no need to translate those Call IDs as their uniqueness between the two endpoints are guaranteed by the selection algorithm of the PPTP server. This can be thought of as destination TCP/UDP ports. They are not translated in the NAT. Instead only the source ports are translated.

• PPTP session initiation in the outside to inside direction through the NAT is not supported.

• Call-ID’s are allocated and used in the same fashion as the outside TCP/UDP ports (random with parity). They are taken from the same port range as ICMP ports.

The basic principle of PPTP NAT ALG is shown in NAT PPTP operation.

The scenario where multiple clients behind the NAT are terminated to the same PPTP server is shown in Merging of endpoints in NAT. In this case, it is possible that the source IP addresses of the two PPTP clients are mapped to the same outside address of the NAT. Because the endpoints of the GRE tunnel from the NAT to the PPTP server are the same for both PPTP clients (although their real source IP addresses are different), the NAT must ensure the uniqueness of the Call-IDs in the outbound data connection. This is where Call-ID translation in the NAT becomes crucial.

The routers supports a deployment scenario where multiple calls (or tunnels) are established from a single PPTP node within a single control connection. In this case, there is only one set of Start-Control-Connection-Req/Reply messages (one control channel) and multiple sets of Outgoing-Call-Req/Reply messages.

Call-Id are taken from the same pool as the ICMP port ranges. Port-ranges and Call-IDs are both 16-bit values. Call-id selection mechanism is the same as the outside TCP/UDP port selection mechanism (random with parity).

Fragmentation functionality is invoked when the size of a fragmentation eligible packet exceeds the size of the MTU of the egress interface or tunnel. Packets eligible for fragmentation are:

• IPv4 packets or fragments with the DF bit in the IPv4 header cleared. Fragmentation can be performed on any routing node between the source and the destination of the packet.

• IPv6 packets on the source node. Fragmentation of IPv6 packet on the transient routing nodes is not allowed.

The best practice is to avoid fragmentation in the network by ensuring adequate MTU size on the transient or source nodes. Drawbacks of the fragmentation are:

• increased processing and memory demands to the network nodes (especially during reassembly process)

• increased byte overhead

• increased latency

Fragmentation can be particularly deceiving in a tunneled environment whereby the tunnel encapsulation adds extra overhead to the original packet. This extra overhead could tip the size of the resulting packet over the egress MTU limit.

Fragmentation could be one solution in cases where the restriction in the mtu size on the packet’s path from source to the destination cannot be avoided. Routers support IPv6 fragmentation in DS-Lite and NAT64 with some enriched capabilities, such as optional packet IPv6 fragmentation even in cases where DF-bit in corresponding IPv4 packet is set.

In general, the lengths of the fragments must be chosen such that resulting fragment packets fit within the MTU of the path to the packets destinations.

In downstream direction fragmentation can be implemented in two ways:

• IPV4 packet can be fragmented in the carrier IOM before it reaches ISA for any NAT function.

• IPv6 packet can be fragmented in the ISA, after the IPv4 packet is IPv6 encapsulated in DS-Lite or IPv6 translated in NAT64.

In upstream direction, IPv4 packets can be fragmented after they are decapsulated in DS-Lite or translated in NAT64. The fragmentation occurs in the IOM.

In the downstream direction, the IPv6 packet carrying IPv4 packet (IPv4-in-IPv6) is fragmented in the ISA in case the configured DS-Lite tunnel MTU is smaller than the size of the IPv4 packet that is to be tunneled inside of the IPv6 packet. The maximum IPv6 fragment size is 48bytes larger than the value set by the tunnel MTU. The additional 48 bytes is added by the IPv6 header fields: 40 bytes for the basic IPv6 header plus 8 bytes for extended IPv6 fragmentation header. NAT implementation in the routers does not insert any extension IPv6 headers other than fragmentation header.

DS-Lite shows DS-Lite IPv6 fragmentation.

If the IPv4 packet is larger than the value set by the tunnel MTU, the fragmentation action depends on the configuration options and the DF bit setting in the header of the received IPv4 header:

• The IPv4 packet can be dropped regardless of the DF bit setting. IPv6 fragmentation is disabled.

• The IPv4 packet can be encapsulated in IPv6 packet and then the IPv6 can be fragmented regardless of the DF bit setting in the IPv4 tunneled packet. The IPv6 fragment payload is limited to the value set by the tunnel MTU.

• The IPv4 packet can be encapsulated in IPv6 packet and then the IPv6 can be fragmented only if the DF bit is cleared. The IPv6 fragment payload is limited to the value set by the tunnel MTU.

If the IPv4 packet is dropped because of fragmentation not being allowed, an ICMPv4 Datagram Too Big message is returned to the source. This message carries the information about the size of the MTU that is supported, by notifying the source to reduce its MTU size to the requested value (tunnel MTU).

The maximum number of supported fragments per IPv6 packet is 8. Considering that the minimum standard base size for IPv6 packet is 1280 bytes, 8 fragments is enough to cover jumbo Ethernet frames.

Use the following commands to configure downstream IPv6 fragmentation behavior in DS-Lite and the DS-Lite tunnel MTU for this DS-Lite address:

• MD-CLI

  configure router nat inside large-scale dual-stack-lite endpoint ip-fragmentation
  configure router nat inside large-scale dual-stack-lite endpoint tunnel-mtu
  configure service vprn nat inside large-scale dual-stack-lite endpoint ip-fragmentation
  configure service vprn nat inside large-scale dual-stack-lite endpoint tunnel-mtu
  

• classic CLI

  configure router nat inside dual-stack-lite address ip-fragmentation
  configure router nat inside dual-stack-lite address tunnel-mtu
  configure service vprn nat inside dual-stack-lite address ip-fragmentation
  configure service vprn nat inside dual-stack-lite address tunnel-mtu
  

Downstream fragmentation in NAT64 works in similar fashion. The difference between DS-Lite is that in NAT64 the configured ipv6-mtu represents the mtu size of the IPv6 packet (as opposed to payload of the IPv6 tunnel in DS-Lite). In addition, IPv4 packet in NAT64 is not tunneled but instead IPv4 or IPv6 headers are translated. Consequently, the fragmented IPv6 packet size is 28 bytes larger than the translated IPv4 packet 20 bytes difference in basic IP header sizes (40-bytes IPv6 header versus a 20-byte IPv4 header) plus 8 bytes for extended fragmentation IPv6 header. The only extended IPv6 header that NAT64 generates is the fragmentation header.

If the IPv4 packet is dropped because of the fragmentation not being allowed, the returned ICMP message contains MTU size of ipv6-mtu minus 28 bytes. Otherwise, the fragmentation options are the same as in DS-Lite.

Use the following commands to configure downstream IPv6 fragmentation behavior in NAT64 and the size of the IPv6 downstream packet in NAT64:

• MD-CLI

  configure router nat inside large-scale nat64 ip-fragmentation
  configure router nat inside large-scale nat64 endpoint ipv6-mtu
  configure service vprn nat inside large-scale nat64 ip-fragmentation
  configure service vprn nat inside large-scale nat64 ipv6-mtu

• classic CLI

  configure router nat inside nat64 ip-fragmentation
  configure router nat inside nat64 ipv6-mtu
  configure service vprn nat inside nat64 ip-fragmentation
  configure service vprn nat inside nat64 ipv6-mtu

Use the following command to display fragmentation statistics in DS-Lite.

show isa nat-group statistics mda

The command output displays only relevant DS-Lite fragmentation counters. The remaining counters are removed from the output for easier reading.

show isa nat-group 1 statistics mda 1/2

===============================================================================
ISA NAT Group 1 MDA 1/2
===============================================================================
...
too many fragments for IP packet                        : 0
too many fragmented packets                             : 0
too many fragment holes                                 : 0
too many frags buffered                                 : 0
fragment list expired                                   : 0
Reassembly Failures                                     : 0
Fragments RX DSL                                        : 0
Fragments RX DORMANT                                    : 0
Fragments TX DSL                                        : 0
Fragments TX DORMANT                                    : 0
Fragments RX OUT                                        : 0
Fragments TX OUT                                        : 0
too many frag. lists for flow                           : 0
frag. list cleanup in progress                          : 0
...
===============================================================================

Multichassis stateless NAT redundancy is based on a switchover of the NAT pool that can assume active (master) or standby state. The inside/outside routes that attract traffic to the NAT pool are always advertised from the active node (the node on which the pool is active).

This dual-homed redundancy based on the pool mastership state works well in scenarios where each inside routing context is configured with a single NAT policy (NAT’d traffic within this inside routing context is mapped to a single NAT pool).

However, in cases where the inside traffic is mapped to multiple pools (with deterministic NAT and in case when multiple NAT policies are configured per inside routing context), the basic per pool multichassis redundancy mode can cause the inside traffic within the same routing instance to fail because some pools referenced from the routing instance may be active on one node while other pools may be active on the other node.

Imagine a case where traffic ingressing the same inside routing instance is mapped as follows (this mapping can be achieved via filters):

• Source ip-address A → Pool 1 (nat-policy 1) active on Node 1

• Source ip-address B → Pool 2 (nat-policy 2) active on Node 2

Traffic for the same destination is normally attracted only to one NAT node (the destination route is advertised only from a single NAT node). Assume that this node is Node 1 in the example. After the traffic arrives to the NAT node, it is mapped to the corresponding pool according to the mapping criteria (routing based or filter based). But if active pools are not co-located, traffic destined for the pool that is active on the neighboring node would fail. In our example traffic from the source ip-address B would arrive to the Node 1, while the corresponding Pool 2 is inactive on that node. Consequently the traffic forwarding would fail.

To remedy this situation, a group of pools targeted from the same inside routing context must be active on the same node simultaneously. In other words, the active pools referenced from the same inside routing instance must be co-located. This group of pools is referred to as Pool Fate Sharing Group (PFSG). The PFSG is defined as a group of all NAT pools referenced by inside routing contexts whereby at least one of those pools is shared by those inside routing contexts. This is shown in Active/Standby intra-chassis redundancy model.

Even though only Pool 2 is shared between subscribers in VRF 1 and VRF 2, the remaining pools in VRF 1 and VRF 2 must be made part of PFSG 1 as well.

This ensures that the inside traffic is always mapped to pools that are active in a single box.

Pool fate sharing group shows the pool fate sharing group.

There is always one lead pool in PFSG. The Lead pool is the only pool that is exporting/monitoring routes. Other pools in the PFSG are referencing the lead pool and they inherit its (activity) state. If any of the pools in PFSG fails, all the pools in the PFSG switch the activity, or in another words they share the fate of the lead pool (active/standby/disabled).

There is one lead pool per PFSG per node in a dual-homed environment. Each lead pool in a PFSG has its own export route that must match the monitoring route of the lead pool in the corresponding PFSG on the peering node.

PFSG is implicitly enabled by configuring multiple pools to follow the same lead pool.

In active/active (A/A) ESA-VM or ISA redundancy, each ESA-VM or ISA is subdivided into multiple logical ESA-VM or ISAs. These logical sub-entities are referred to as members. NAT configuration of each member is saved in the CPM. In case that any one ESA-VM or ISA fails, its members are downloaded by the CPM to the remaining active ESA-VM or ISAs. Memory resources on each ESA-VM or ISA are reserved to accommodate additional traffic from the failed ESA-VM or ISAs. The amount of resources reserved per ESA-VM or ISA depends on the number of ESA-VM or ISAs in the system and the number of simultaneously supported ESA-VM or ISA failures. The number of simultaneous ESA-VM or ISA failures per system is configurable. Memory reservation affects NAT scale per ESA-VM or ISA.

Traffic received on the inside is forwarded by the ingress forwarding complex to a predetermined member ESA-VM or ISAs for further NAT processing. Each ingress forwarding complex maintains an internal link per member. The number of these internal links, along with other factors, determine the maximum number of members per system and with this, the granularity of traffic distribution over remaining ESA-VM or ISAs in case of an ESA-VM or ISA failure. The segmentation of ESA-VM or ISAs into members for a single failure scenario is shown in Load distribution in A/A intra-chassis redundancy model. The protection mechanism in this example is designed to cover for one physical ESA-VM or ISA failure. Each ESA-VM or ISA is divided into four members. Three of those carry traffic during normal operation, while the fourth one has resources reserved to accommodate traffic from one of the members in case of failure. When an ESA-VM or ISA failure occurs, three members are delegated to the remaining ESA-VM or ISAs. Each member from the failed ESA-VM or ISA is mapped to a corresponding reserved member on the remaining ESA-VM or ISAs.

A/A ESA-VM or ISA redundancy model supports multiple failures simultaneously. The protection mechanism shown in Multiple failures is designed to protect against two simultaneous ESA-VM or ISA failures. As the previous case, each ESA-VM or ISA is divided into six members, three of which are carrying traffic under normal circumstances while the remaining three members have reserved memory resources.

Load distribution in A/A ESA-VM or ISA redundancy model supporting single ESA-VM or ISA failure shows resource utilization for a single ESA-VM or ISA failure in relation to the total number of ESA-VM or ISAs in the system. The resource utilization affects only scale of each ESA-VM or ISA. However, bandwidth per ESA-VM or ISA is not reserved and each ESA-VM or ISA can operate at full speed at any time (with or without failures).

L2-Aware bypass provides the basis for traffic continuity if an MS-ISA fails. With L2-Aware bypass functionality disabled and without an intra-chassis redundancy scheme deployed (such as active/active or active/standby), the traffic to be processed by the failed MS-ISA is blackholed. This means that traffic continues to be sent to the failed MS-ISA. By enabling L2-Aware bypass, instead of being blackholed, the traffic is routed outside of the SR OS node without being NAT’d in accordance to the routing table in the inside routing context. The intent is that non-NAT’d traffic is intercepted by a central NAT node that performs the NAT function. This way, traffic served by the failed MS-ISA continues to be NAT’d by a central NAT node. The central NAT node provides redundancy for multiple SR OS nodes, therefore reducing the need to equip each individual SR OS node with multiple MS-ISAs which are normally used in an active/active or active/standby intra-chassis redundancy mode.

This concept is shown in L2-Aware bypass. The example shows the base router as an inside routing context where the global routing table (GRT) is used to decide where to send traffic if an MS-ISA is unavailable. Apart from this example, the inside routing context is not limited to the base router but instead can be an VPRN instance.

L2-Aware bypass is an optional redundancy model in Layer 2–aware NAT which is mutually exclusive with the other two MS-ISA redundancy modes (active/active and active/standby).

Use the following command option to enable L2-Aware bypass:

• MD-CLI

  configure isa nat-group redundancy intra-chassis l2aware-bypass

• classic CLI

  configure isa nat-group redundancy l2aware-bypass

Stateful inter-chassis NAT redundancy provides seamless NAT failover between the two redundant SR OS nodes. A pair of redundant nodes operates in active or standby modes per NAT group. If traffic distribution between the nodes is needed, then up to four NAT groups per node can be deployed, and with each NAT group having its own set of ISAs. In this scenario, traffic between the nodes can be load-balanced per NAT group.

CGN stateful inter-chassis redundancy shows a scenario where inside routes are advertised from the node with the active NAT group that ensures traffic is symmetric. This means that upstream and downstream traffic is fully flowing through the same node. Although this scenario represents the majority of use cases, it is allowed for the upstream traffic to arrive on the node with a standby NAT group and be shunted over to the node with active nat-group over a link that interconnects the two nodes. This scenario is shown in Asymmetric traffic.

The redundant pair of NAT nodes protect against the following:

• node failure

• ISA failure

• link failure

• path failure (BFD, VRRP)

The basic premise of stateful inter-chassis NAT redundancy is as follows:

• ISAs/ESAs within a NAT group can be either active or standby. This means that in a pair of redundant NAT nodes, only one node attracts traffic per NAT group while the NAT group on the peering node is in a standby state with synchronized flows (or sessions).

• The activity (active or standby) of a NAT group is determined by an internal health value that represents the node’s ability to perform NAT at full capacity. The value of the health value can change dynamically and is based on the events that are related to various failures against which the stateful inter-chassis NAT redundancy offers protection. The health value is communicated between the redundant (or peering) nodes on the CPM level.

• In case of equal health, a user can, through configuration, influence the activity of a NAT group.

• The activity of a NAT group is characterized by the advertisement of the NAT- related routes on the inside (steering and destination-prefix) and the outside (pool routes).

• Only TCP/UDP/ICMP flows that are older than the preconfigured amount of time are synchronized.

• Flow synchronization is performed directly between the ISAs, bypassing the CPM. The CPM’s main role is to determine the activity of a NAT group with health related options as shown in NAT synchronization.

• Flows are created on the active NAT group and are synchronized from the active NAT group to the standby NAT group.

• Immediately following the switchover, all flows on the newly standby NAT group are resynchronized from the newly active NAT group.

• If the link between the chassis is lost, then each chassis operates in a standalone mode.

A reliable and redundant link should always be available between the two redundant NAT nodes. This link is referred to as Inter-Chassis Link (ICL) and is used for:

• CPM communication (activity negotiation and presence detection)

• ISA-to-ISA communication (flow synchronization)

• transient forwarding of data traffic during switchovers

All MS-ISA features and applications support simultaneous service mirroring, without impact. For example, a service that is diverted to AA, IPsec, NAT, LNS, or supported combinations of MS-ISA applications also supports service mirroring simultaneously.

Subscriber aware Large Scale NAT44 attempts to combine the positive attributes of Large Scale NAT44 and Layer 2–aware NAT, namely:

• the ability for some traffic to bypass the NAT function, such as IPTV traffic and VoIP traffic whenever a unique IP address per subscriber is used (for example, not L2-Aware NAT where all subs share the same IP). This can be achieved using existing Large Scale NAT44 mechanisms (ingress IP filters)

• the use of RADIUS Acct for logging of port ranges, including multiple port-range blocks

• the use of subscriber-identification/RADIUS username to identify the customer to simplify management of Large Scale NAT44 subscribers

MAP-T rules control the address translation in a MAP-T domain. The mapping rules can be delivered to the devices in the MAP domain using RADIUS or DHCP, or be statically provisioned.

The MAP-T rules are:

• Basic Mapping Rule (BMR)

  The BMR is used to translate the public IPv4 address and port-range assigned to the CE into the IPv6 MAP address. It is composed of the following parameters:

  • rule IPv6 prefix (including prefix length)

  • rule IPv4 prefix (including prefix length)

  • rule Embedded Address bits (EA-bits) define the portion of the IA-PD that encodes the IPv4 suffix and port-range

  • rule Port Parameters (optional)

• Forwarding Mapping Rule (FMR)

  The FMR is used for forwarding within the MAP domain. FMRs are instantiated in the BR so that the BR can forward traffic to the CEs. FMRs can also be instantiated in CEs to forward traffic directly between CEs, effectively bypassing BR. The FMR is composed of the same set of parameters as the BMR:

  • rule IPv6 prefix (including prefix length)

  • rule IPv4 prefix (including prefix length)

  • rule Embedded Address (EA) bits that define the portion of the IA-PD that encodes the IPv4 suffix and port-range

  • rule Port Parameters (optional)

• Default Mapping Rule (DMR)

  The DMR is used to forward traffic outside the MAP domain. This rule contains the IPv6 prefix of the BR in MAP-T and it is used as the default route.

The public IPv4 address and the port-range information of the CE is encoded in its assigned IPv6 delegated prefix (IA-PD). The BMR holds the key to decode this information from the IA-PD of the CE. The BMR identifies the portion of bits of the IA-PD that contain the suffix of the IPv4 address and the port set ID (PSID). These bits are called the EA bits. The PSID represents the port range assigned to the CE.

The public IPv4 address of the CE is constructed by concatenating the IPv4 prefix carried in the BMR and the suffix, which is extracted from the EA bits within the IA-PD. The port range is identified by the remaining EA bits (PSID portion). The EA bits uniquely identify the CE within the IPv6 network in a MAP domain.

The PSID offset value must be set to a value greater than 0. It represents ports that are omitted from the mapping (for example, well-known ports).

An IPv4 address and port on the private side of the CE must be statefully translated to a public IPv4 address, and the port within the assigned port must be set on the public side of the CE. This ensures that the BR, based on the same MAP rules, can extrapolate the IPv4 source of the packet for verification (anti-spoofing) purposes in the upstream direction, and conversely, to determine the destination IPv6 MAP address (CE address) in the downstream direction (based on the destination IPv4+port).

The IPv6 MAP address is constructed by setting the subnet ID in the delegated IPv6 prefix to 0. In this way, the subnet ID of 0 is reserved for MAP function. The remaining subnets can be delegated on the LAN side of the CE.

The interface ID is set to the IPv4 public address and PSID. This is described in RFC 7599, §6.

In this way, the IPv4 and IPv6 addresses of the CE are defined and easily converted to each other based on the BMR and the port information in the packet. A+P mapping shows the A+P mapping algorithm.

The following figure shows a MAP-T deployment scenario.

The routes related to MAP-T are:

• IPv4 prefixes from the MAP-rules

  These routes are advertised in the upstream direction.

• DMR

  This is the BR prefix for a specific domain. This route is advertised in the downstream direction.

MAP-T routes in the 7750 SR and VSR are owned by configuring the protocol to nat with a metric of 50. This can be used to configure an export routing policy when advertising MAP-T routes in IGP or BGP.

Multiple MAP-T domains can be supported in the same routing context.

In the upstream direction, when the BR receives an IPv6 packet destined for the BR prefix, a source-based IPv6 address lookup (anti-spoofing) is performed to verify that the packet is sent by the credible CE.

In the downstream direction, a destination-based IPv4 lookup is performed. This leads to the MAP-T rule entry, which provides the information necessary to derive the IPv6 address of the destination CE.

The MAP-T forwarding function in the VSR is also responsible for:

• address conversion between IPv4 and IPv6 based on the BMR rule

• header translation between IPv4 and IPv6, as described in RFC 6145

In address-sharing scenarios, address translation is performed for TCP/UDP and a subset of ICMP traffic; everything else is dropped. In contrast, 1:1 and prefix-sharing scenarios are protocol agnostic.

This section examines an example MAP-T deployment with three MAP rules. The deployment assumes the following:

• There are about 12,000 private IPv4 addresses that need to be translated via MAP-T.

• Each such address should have approximately 4000 ports available per CE. Therefore, the IP address sharing ratio is 16:1; that is, 16 CEs share the same public IP address.

• The public IPv4 addresses that are available to the operator for this translation are from three /24 subnets (10.11.11.0/24, 10.12.12.0/24 and 10.13.13.0/24).

• All users (or CEs) are assigned a /60 IA-PD.

The 12,000 private IPv4 addresses (CEs) in a 16:1 sharing scenario can be covered using three /24 subnets as follows:

(3 * 2^8 * 16 = 12,288)

The IPv4 rule prefix and EA bits length per rule in this scenario are:

• 10.11.11.0/24 EA length: 12 bits (8 bits for the IPv4 suffix and 4 bits for PSID)

• 10.12.12.0/24 EA length: 12 bits (8 bits for the IPv4 suffix and 4 bits for PSID)

• 10.13.13.0/24 EA length: 12 bits (8 bits for the IPv4 suffix and 4 bits for PSID)

The first 6 bits of the 16 bit port-range are set to 000000 and are reserved for psid-offset (ports 0-1023 are reserved); therefore, the user-allocated port space is calculated as follows:

4000 - 64 = 4032 ports

The IPv6 rule prefix is the next parameter in the MAP rule. The following figure shows the relevant bits in the IPv6 address: only bits /32 to /64 are considered; the irrelevant bits of the IPv6 addresses are ignored in this example.

The following three rules are created in this example:

• Rule 1 covers subnet 1.

• Rule 2 covers subnet 2.

• Rule 3 covers subnet 3.

In each of the three cases, the EA bits extend from the PD length (/60) to the IPv6 rule prefix length (/48).

The IPv6 rule prefix length is determined for each of the three rules. However, the IPv6 rule prefixes must not overlap, see section Rule prefix overlap for more information. Non-overlapping IPv6 rule prefixes ensure that each CE is assigned a unique IA-PD. IPv6 rule prefixes describes the rules.

The final step is to ensure that the DHCPv6 server hands out correct end-user prefixes (IA-PD), and the rules are also delegated.

In this example, each /48 IPv6 rule prefix supports 4,000 MAP-T CEs, where each CE can further delegate 15 IPv6 ‟subnets” on the LAN side and each CE is allocated about 4,000 ports to use in stateful NAT44.

The following ICMPv4 messages are supported in MAP-T on the 7750 SR and VSR platforms; other types of ICMP messages are not supported:

• ICMP Query messages

  These messages contain an identifier field in the ICMP header, which is referred to as the ‟query identifier” or ‟query ID” and it is used in MAP-T in the same way as the L4 ports are used in TCP or UDP. ICMP Echo Req/Rep (PING) and traceroute are examples that rely on ICMP Query messages.

• ICMP Error messages

  These messages contain the embedded original datagram that triggers the ICMP error message. The ICMP error messages do not contain the query-id field.

The ICMP Query messages and ICMP Error messages are supported regardless of whether they are just passing through a 7750 SR and VSR (transit messages), or are terminated or generated in or from a 7750 SR and VSR.

The NAT-related ICMPv4 behavior is described in RFC 5508. The following NAT messages are supported in the MAP-T 7750 SR and VSR (RFC 5508, §7, Requirement 10a):

• ICMPv4 Error Message: Destination Unreachable Message (Type 3)

• ICMPv4 Error Message: Time Exceeded Message (Type 11)

• ICMPv4 Query Message: Echo and Echo Reply Messages (Type 8 and Type 0)

In fragmentation, the following cases are distinguished:

• SR/VSR fragments packets

  • In the downstream direction, SR/VSR fragments IPv6 packets but not IPv4 packets.

  • In the upstream direction, no additional translation is required. IPv4 fragmentation occurs after translation, following standard behavior.

• SR/VSR receives fragments that need to be translated

  • In the downstream direction, fragments are translated into IPv6, and caching is required.

    Note: The received fragments may undergo further fragmentation.

  • In the upstream direction, fragments are translated into IPv4 and caching is NOT required.

The IPv6 header of the IPv4-translated packet in MAP-T can be up to 28 bytes larger than the IPv4 header (40-byte IPv6 header plus 8-byte fragmentation header versus 20-byte IPv4 header).

The IPv6 MTU in the 7750 SR and VSR is configurable for each MAP-T domain. The Layer 2 header is excluded from the IPv6 MTU.

MAP natively provides multichassis redundancy through the use of the anycast BR prefix that is advertised from multiple nodes.

As there is no state maintenance in the MAP-T BR, any BR node can process traffic for the same domain at all times. The only traffic interruption during the switch-over is for the fragmented traffic in the downstream direction being handled at the time of switchover (the flow record cache is not synchronized between the nodes).

As with any NAT operation where the identity of the user is hidden behind the NAT identity, logging of the NAT translation information is required. In the MAP-T domain, NAT logging is based on configuration changes because the user identity can be derived from the configured rules.

A system can have a large number of rules and each configured MAP rule generates a separate log. As a result, the amount of logs generated can be substantial. Logging is explicitly enabled using a log event.

A NAT log contains information about the following:

• MAP type (Map-T)

• map-domain name

• map-rule name

• v6 rule-prefix

• v4 rule-prefix

• EA bits

• psid-offset bits

• associated routing context for the MAP-T rule

• timestamp

A MAP rule log is generated when both of the following conditions are met:

• a MAP rule is activated and deactivated in the system (administratively enabled or disabled, corresponding MAP domain is associated or dissociated from the routing context, corresponding MAP domain is administratively enabled or disabled, and so on)

• event tmnxNatMapRuleChange (id=2036) has been enabled in event-control

551 2016/04/22 14:56:35.44 UTC MINOR: NAT #2036 vprn220 NAT MAP
"map-type=map-t map-domain=domain-name-1 rule-name=rule-name-1 rule-prefix=2001:db8::/44 ipv4-prefix=192.168.10.0/24 ea-length=12 psid-offset=6 enabled router=vprn220 at 2016/04/22 14:56:35"

VSR-specific implementation is described in the following sections.