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 microneted (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.

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."

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 L2-Aware NAT relies on a different algorithm than CGN. In L2-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 L2-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 L2-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.

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 outs of ports, the NAT subscriber runs of port. 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.

  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 L2-aware NAT.

show service nat lsn-subscribers subscriber 276824064

===============================================================================
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.

L2-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 L2-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.

CLI example:

--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
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-pol"
          prefix 192.168.0.64/30 nat-policy "l2aw-nat-pol"
          prefix 192.168.0.128/30 nat-policy "l2aw-nat-pol"
          prefix 192.168.1.0/30 nat-policy "another-l2aw-nat-pol"
          prefix 192.168.1.64/30 nat-policy "another-l2aw-nat-pol"
          prefix 192.168.1.128/30 nat-policy "another-l2aw-nat-pol" 
        exit        
    exit
#--------------------------------------------------
echo "Subscriber-mgmt Configuration"
#--------------------------------------------------
    subscriber-mgmt        
        sub-profile "sub_profile" create            
            nat-policy "def-nat-policy"
            nat-prefix-list "prefixlist1"            
        exit
        

As displayed in the example, multiple IP prefixes can be mapped to the same NAT policy.

The NAT prefix list cannot reference the default NAT policy. The default NAT policy is the one that is referenced directly under the subscriber profile.

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. For example:

config
   router
      nat
         inside 
             deterministic
               prefix 10.0.0.0/24 subscriber-type classic-lsn-sub nat-policy ‛one-to-one’
            map start 10.0.0.10       end 10.0.0.10    to 1.2.3.4
                     map start 10.0.0.15       end 10.0.0.15    to 1.2.3.20
                     map start 10.0.0.100    end 10.0.0.100 to 1.2.3.30
            

Static mappings are configured according to the map statements. In classic CLI, the map statement can be configured manually by the operator or automatically by the system. In MD-CLI, the map statement must be configured by the operator, but the tools perform nat deterministic calculate-maps command can be used to produce system-generated maps. The calculate-maps command outputs a set of system-generated map statements. The map parameters can then be copied and pasted into an MD-CLI candidate configuration by the operator.

IP addresses from the automatically-generated map statements are sequentially mapped into available outside IP addresses in the pool:

• The first inside IP address is mapped to the first available outside IP address from the pool.

• The second inside IP address is mapped to the second available outside IP address from the pool.

The following mappings apply to the example above:

Static mappings
   10.0.0.0 — 1.2.3.0
   10.0.0.1 — 1.2.3.1
   10.0.0.2  —  1.2.3.2
   10.0.0.3  —  1.2.3.3
   10.0.0.4  —  1.2.3.5
   10.0.0.5  —  1.2.3.6
   :
   10.0.0.9  —  1.2.3.10
   10.0.0.10  —  1.2.3.4
   10.0.0.11  —  1.2.3.11
   10.0.0.12  —  1.2.3.12
   :
   10.0.0.14  —  1.2.3.14
   10.0.0.15  —  1.2.3.20
   10.0.0.16  —  1.2.3.15
   :
   10.0.0.19  —  1.2.3.18
   10.0.0.20  —  1.2.3.19
   10.0.0.21  —  1.2.3.21
   :
   10.0.0.28  —  1.2.3.28
   10.0.0.29  —  1.2.3.29
   10.0.0.30  —  1.2.3.31
   :
   10.0.0.99  —  1.2.3.100
   10.0.0.100 — 1.2.3.30
   10.0.0.101  —  1.2.3.101
   :
   10.0.0.255  —  1.2.3.255

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).

With the exception of classic-lsn-max-subscriber-limit and dslite-max-subscriber-limit commands in the inside routing context, the deterministic NAT configuration blocks are for the most part common to LSN44 and DS-Lite.

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

The outside pools in deterministic NAT can contain an arbitrary number of address ranges, where each address range can contain an arbitrary number of IP addresses (up to the ISA maximum).

The maximum number of NAT subscribers that can be mapped to a single outside IP address is configurable using a subscriber-limit command under the pool hierarchy. For Deterministic NAT, this number is restricted to the power of 2 (2^n). The consequence of this is that the number of NAT subscribers must be configuration-wise organized in ranges with the boundary that must be power of 2.

For example, in LSN44 where the NAT subscriber is an IP address, the deterministic subscribers would be configured with prefixes (for example, 10.10.10.0/24 – 256 subscribers) instead of an IP address range that would contain an arbitrary number of addresses (for example, 10.10.10.10 – 10.10.10.50).

On the other hand, in DS-Lite the deterministic subscribers are for the most part already determined by the prefix with the subscriber-prefix-length command under the DS-Lite configuration node.

The number of subscribers per outside IP (the subscriber-limit command [2^n]) multiplied by the number of IP addresses over all address-range in an outside pool determines the maximum number of subscribers that a deterministic pool can support.

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.

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

The upper limit of the port range for static port forwards (wildcard range) is determined by the existing port-forwarding-range command.

The range of ports allocated for deterministic mappings (DetP) is determined by multiplying the number of subscribers per outside IP (subscriber-limit command) with the number of ports per deterministic block (deterministic>port-reservation command). The number of subscribers per outside IP in deterministic NAT must be power of 2 (2^n).

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

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

Examples:

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.

port-block-limit includes the deterministic port block 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 examples from above should give us a perspective on the size of deterministic and dynamic port blocks in relation to the number of subscribers (2^n) per outside IP address. Operators 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:

configure 
   service
      vprn
         nat
            outside
               pool mypool
                  port-reservation ports 180
                  deterministic
      port-reservation 300
                  subscriber-limit 128
                  port-forwarding-range 4023

Where:

128 subs * 300ports = 38,400 deterministic port range

128 subs * 180ports = 23,040 dynamic port range

Det+dyn available ports = 65,536 – 4024 = 61,512

Det+dyn usable pots = 128*300 + 128 *180 = 61,440 ports

72 ports per outside-ip are wasted.

configure
   service
      nat
         nat-policy mypolicy
            block-limit 5    1 deterministic port block + 4 dynamic port blocks

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 Outside address ranges.

Assuming that the above 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 is a CLI representation of a deterministic pool definition including the outside IP ranges:

pool ‛mypool’ nat-group 1 type large-scale
      port-reservation {blocks <dynBlocks>} | {ports <ports>}
      deterministic
            port-reservation <ports>
      subscriber-limit <sub-limit>
      port-forwarding-range <pfRange>
      address-range <start-ip-address> <end-ip-address>
      address-range <start-ip-address> <end-ip-address>

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 case that a prefixes from an inside routing instances is 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. 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 hashing algorithm is taking 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 t subscriber-limit parameter in any pool that is referenced from this inside routing instance.

Deterministic LSN44 configuration example 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 (we do not support the latter with non-deterministic NAT).

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.

A subscriber in non-deterministic DS-Lite is defined as v6 prefix, with the prefix length being configured under the DS-Lite NAT node:

config>service>vprn>nat>inside>dslite#
   subscriber-prefix-length [32..64 | 128]      (default is 128)

All incoming IPv6 traffic with source IPv6 addresses falling under a unique v6 prefix that is configured with 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 a v6 prefix (instead of v4). 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.

• Subscriber-type is set to dslite-lsn-sub.

config>service>vprn>nat>inside>deterministic#
   prefix <v6-prefix/length> subscriber-type dslite-lsn-sub nat-policy <policy-name> 

Example:

config>service>vprn>nat>inside>deterministic#
   prefix 2001:db8::/56 subscriber-type dslite-lsn-sub nat-policy det-policy 

config>service>vprn>nat>inside>dslite#
   subscriber-prefix-length 60

In this case, 16 v6 prefixes (from 2001:db8::/60 to 2001:db8:00:F0::/60) are considered DS-Lite subscribers. The source IPv4 addresses/ports inside of the IPv6 tunnels is mapped into respective deterministic port blocks within an outside IPv4 address according to the map statement.

The map statement contains minor modifications as well. It maps DS-Lite subscribers (IPv6 address or prefix) to corresponding outside IPv4 addresses. Continuing on the previous example:

map start 2001:db8::/60 end 2001:db8:00:F0::/60 to 192.168.1.1

The prefix length (/60) in this case must be the same as configured subscriber-prefix-length. If we assume that the subscriber-limit in the corresponding pool is set to 8 and outside IP address range is 192.168.1.1 to 192.168.1.10, then the actual mapping is the following:

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 (L2-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 L2-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.

DNAT is enabled in the config>service>nat>nat-policy context.

config>service>nat
nat-policy <nat-policy-name> create
dnat
dnat-only router <router-instance> nat-group <nat-group-id>
nat-classifier <classifier-name>
exit

DNAT function is triggered by the presence of the nat classifier (nat-classifier command), referenced in the NAT policy.DNAT-only option is configured in case where SNAPT is not required. This command is necessary to determine the outside routing context and the nat-group when SNAPT is not configured. Pool (relevant to SNAPT) and DNAT-only configuration 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 L2-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 filter-based diversion solution is supported for this case. The filter-based solution can be extended to a 5 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.

The routing approach relies on upstream traffic being directed (or diverted) to the NAT function based on the destination-prefix command in the config>service>vprn/router>nat>inside CLI context. 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 CLI for multiple NAT policies per inside routing context with routing based diversion to NAT is the following:

service vprn/router
   nat
        inside
              destination-prefix <ip-prefix/length>  nat-policy <policy-name>]
                           :
                           :

or, for example:

service vprn/router
   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

Different destination prefixes can reference a single NAT policy (policy-1 in this case).

In case that the destination-policy does not directly reference the NAT policy, the default NAT policy is used. The default NAT policy is configured directly in the vprn/router>nat>inside context.

After the destination-prefix command referencing the NAT policy is configured, an entry in the routing table is created that directs the traffic to the MS-ISA.

A filter-based approach diverts traffic to NAT based on the IP matching criteria shown in the CLI below.

*A:right-a21>config>filter>ip-filter>entry# match 
  - match [protocol <protocol-id>]
  - no match

 <protocol-id>        : protocol numbers - [0..255] (Decimal, 
                                Hexadecimal, or Binary representation).
                        Supported IANA IP protocol names - 
                                none|crtp|crudp|egp|eigrp|encap|ether-ip|
                                gre|icmp|idrp|igmp|igp|ip|ipv6|ipv6-frag|ipv6-icmp|
                                ipv6-no-nxt|ipv6-opts|ipv6-route|isis|iso-ip|l2tp|
                                ospf-igp|pim|pnni|ptp|rdp|rsvp|sctp|stp|tcp|udp|vrrp
                        * - udp/tcp wildcard

 [no] dst-ip          - Configure dest. ip match condition
 [no] dst-port        - Configure destination port match condition
 [no] port            - Configure port match condition
 [no] src-ip          - Configure source ip match condition
 [no] src-port        - Configure source port match condition

The CLI for the filter-based diversion in conjunction with multiple NAT policies is shown below:

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.

Classic CLI

configure 
   filter
      ipv6-filter
         entry <entry-id> [create]
            action nat nat-type <nat-type> [nat-policy <nat-policy-name>]
            exit
         exit
      exit
   exit  

Where the nat-type parameter can be either dslite or NAT64.

The DS-Lite AFTR address and NAT64 destination prefix configuration under the corresponding (DS-Lite or NAT64) router/vprn>nat>inside context is mandatory. This is even when only filters are needed for traffic diversion to NAT.

For example, every AFTR address and NAT64 prefix that is configured as a match criteria in the filter, must also be duplicated in the router/vprn>nat>inside context. However, the opposite is not required.

IPv6 traffic with the destination address outside of the AFTR/NAT64 address/prefix follows normal IPv6 routing path within the 7750 SR.

The default nat-policy is always mandatory and must be configured under the router/vprn>nat>inside context. 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/ipv6-filter used for NAT diversion in LSN44/DS-Lite/NAT64.

The NAT CLI nodes fail to activate (be brought out of the no shutdown state), unless a valid NAT policy is referenced in the router/vprn>nat>inside 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.

Explicit requests are submitted either using NSP or the CLI:

tools perform nat port-forwarding-action lsn 
 - lsn create router <router-instance> [b4 <ipv6-address>] [aftr <ipv6-address>] ip <ip-address> protocol {tcp|udp} [port <port>] lifetime <lifetime> [outside-ip <ipv4-address>] [outside-port <port>] [nat-policy <nat-policy-name>]

In the absence of the NAT policy referenced in the SPF creation request, the default nat-policy command under the vprn/router>nat>inside context is used.

The consequence of this is that the operator 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.

When multiple NAT policies per inside routing context are deployed, a new policy-id parameter is added to specific syslog messages. The format of the policy-id is:

plcy-id XX

Where XX is an arbitrary unique number per inside routing context assigned by the router. This number, represents the corresponding NAT policy. Because the maximum number of NAT policies in the inside routing context is 8, the policy-id value is also a numerical value in the range 1 to 8.

The introduction of the policy-id in logs is necessary because of the bulk-operations associated with multiple NAT policies per inside routing context. A bulk operation, for example, represents the removal of the nat-policy from the configuration, shutting down the NAT pool, or removing an IP address range from the pool. Removing a NAT accounting policy in case of RADIUS NAT logging does not trigger a summarization log because an acct-off message is sent. Such operations have a tendency to be heavy on NAT logging because they affect a large number of NAT subscribers at the same time. Summarization logs are introduced to prevent excessive logging during bulk operations. For example, the NAT policy deletion can be logged with a single (summarized) entry containing the policy-id of the NAT policy that was removed and the inside service-id. Because all logs contain the policy-id, a single summarization free log can be compared to all map2 logs containing the same policy-id to determine for which subscribers the NAT mappings have ceased. Map and Free logs are generated when the port-block for the subscribers are allocated and de-allocated.

Summarization log is always generated on the CPM, regardless of whether the RADIUS logging is enabled or not. A summarization log simply cannot be generated via RADIUS logging because the RADIUS accounting message streams (start/interim-updates/stop) are always generated per subscriber. In other words, for RADIUS logging, the summarization log would need to be sent to each subscriber, which defeats the purpose of the summarization logs.

A summarization log on the CPM is generated:

When the NAT policy is removed, with a single NAT policy per inside routing context, a summarization log is generated with only one field: inside srvc-id (vprn or base). This is sufficient because there is only one NAT policy per inside routing context. To determine subscribers for which NAT mappings are terminated, the operator should search all most recent map logs matching the service-id from the summarization log.

With multiple NAT policies per inside routing context, the inside srvc-id and the policy-id are included in the summarization log (no outside IPs, outside srvc-id, port-block or source IP).

A log search based on the policy-id and inside srvc-id should reveal all subscribers whose mappings were affected by the NAT policy removal.

When the pool is shutdown, the router sends a summarization log that includes the outside srvc-id and all IP address ranges configured in the pool. No other parameters are included in the summarization log.

A log search based on the outside IP address and outside srvc-id should reveal all subscribers for which the NAT mappings have ceased.

When an IP address-range is removed from the pool. The router sends a summarization log that includes the outside srvc-id and the IP address range that has been removed. No other parameters are included in the summarization log.

A log search based on the outside IP addresses in the range and the outside srvc-id should reveal all subscribers for which the NAT mappings have ceased.

• when the last AFTR address is removed

• when DS-Lite/NAT64 node is shutdown

• when deterministic NAT prefixes are created or removed

Summarization logs in RADIUS logging:

The summarization log for bulk operation while RADIUS logging is generated only in the CPM (syslog). This means that for bulk operations with RADIUS logging, the operator has to rely on RADIUS logging as well as on the CPM logging.

An open log sequence in RADIUS, for example a map for the <inside IP 1, outside IP 1,port-block 1> followed at some later time with a map for <inside IP 2, outside IP 1, port-block 1>, is an indication that the free log for <inside IP 1, outside IP 1,port-block 1> is missing. This means that either the free log for <inside IP 1, outside IP 1,port-block 1> was lost or that a policy, pool, and address-range was removed from the configuration. In the latter case, the operator should look in the CPM log for the summarization message.

The summarization logs are enabled via the event control 2021 tmnxNatLsnSubBlksFree which is by default suppressed. The event control 2021 is also used to report when all blocks for the subscriber are freed.

The behavior for NAT policy changes via CoA for LSN and L2-Aware NAT is summarized in NAT policy changes via CoA .

In non-ESM environments, the NAT policy can be changed by replacing the interface filter via CLI for LSN case.

The SLA profile has to be changed and not just refreshed. In other words, replacing the existing SLA profile with the same one does not trigger a new accounting message.

Adding, removing or replacing DNAT parameters 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 L2-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 parameter 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 parameter are mutually exclusive.

nat-policy = nat-policy name → This is an optional parameter. If it is not present, then 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 parameters 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.

In classic CLI, NAT Static Port Forwards (SPFs) can be managed through configuration or with a tools command. In the MD-CLI and NETCONF, a tools command manages SPFs.

If the tools command is configured to manage SPFs and preserve SPFs across reboots, then persistency of the SPF must be enabled with the configure system persistence nat-port-forwarding command for both classic CLI and MD-CLI. With persistency enabled, SPF configuration is stored on the compact flash.

The following are command syntax and sample configuration for Large Scale NAT (LSN):

• MD-CLI

  A:admin@sr-1s# tools perform nat port-forwarding-action lsn ?
  
   lsn add router <string> [b4 <ipv6 address>] [aftr <ipv6 address>] ip <IP address> protocol <keyword> [port <number>] lifetime <string> [outside-ip <ipv4 address>] [outside-port <number>] [nat-policy <string>]
   lsn remove router <string> [b4 <ipv6 address>] ip <IP address> protocol <keyword> port <number> [nat-policy <string>]
  
  lsn modify router <string> [b4 <ipv6 address>] ip <IP address> protocol <keyword> port <number> lifetime <string> [nat-policy <string>]
  

• classic CLI

  A:cses-V22>config>service>nat>fwd# 
  lsn router <router-instance> [b4 <ipv6-address>] [aftr <ipv6-address>] ip <ip-address> protocol {tcp|udp} [port <port>] [outside-ip <ipv4-address>] [outside-port <port>] [nat-policy <nat-policy-name>]

  *A:Dut-C>config>service>nat>fwd# info detail 
  ----------------------------------------------
                  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"
  ----------------------------------------------
  *A:Dut-C>config>service>nat>fwd#

outside-ip ipv4-address

for the outside IP address

outside-port number

for the outside port

nat-policy string

for the NAT policy

The terms internal port and inside port are used interchangeably. They both refer to the original source port before NAT is performed.

The terms external port and outside port are used interchangeably. They both refer to the translated source port after NAT is performed.

The PCP PORT_SET option is defined in RFC 7753, Port Control Protocol (PCP) Extension for Port-Set Allocation, and is used by applications that require a consecutive block of port forwards. The reasons to provide a block of ports in a single request as opposed to multiple requests for single port in a MAP request are described in Section 2 of RFC 7753.

A PCP PORT_SET option indicates to the PCP server (SR OS) that a client needs a block of sequential port forwards. The number of requested port forwards must be greater than one (otherwise, a plain MAP opcode can be used). The ports in the block start at the Internal Port (in MAP opcode) and map to the same number of ports on the outside (or the external side), starting from either the Suggested External Port (in MAP opcode) or from an arbitrary external port. The returned number of ports may be fewer than the requested number, but the number cannot be larger. The allocated port set cannot fall outside of the range defined by the Internal Port (as requested in MAP opcode) plus the PORT_SET Size. Before a port set is assigned to a client, the SR OS always checks if any of the internal ports in the MAP request carrying the PORT_SET option has already been allocated.

The following figure shows an example of PORT_SET option format.

In the MAP request, the needed number of ports is specified in the PORT_SET Size field.

The First Internal Port is set to the same value as the Internal Port field in the MAP opcode.

In the MAP response, the PORT_SET Size represents the number of allocated ports. The First Internal Port represents the first internal port in the port set, which may be different than the Internal Port field in the MAP opcode (see example in Section 6.3 in RFC 7753, overlapping requests). The first external port is the value returned in Assigned External Port field in the MAP opcode.

The PORT_SET option is enabled with the following CLI:

Classic CLI:

config>service>nat>pcp-server-policy# 
    option 
        [no] port-set

MD-CLI:

configure
    service { 
        nat {
            pcp-server-policy <name> {
                option {
                    port-set <boolean>
                }
            }
        }
    }

The appropriate port set size is determined from the combination of the port set size received via the PORT_SET option and the locally configured policy which may limit the port set size.

If the requested port set is initially not available at the Suggested External Port, an attempt is made to find a new set of ports of the appropriate size. The appropriate PORT_SET size in this context means a combination of the requested PORT_SET size and the local limits set by the operator in the SR OS node.

If the available number of consecutive ports in a set for the specified external IP address is fewer that the requested amount or stated in the policy, the maximum number of available consecutive ports are allocated to the client.

In summary, the SR OS tries to find the biggest available port set (as dictated by the combination of the requested size and local policy), instead of allocating random port sets available at the suggested external port.

The maximum number of port forwards per subscriber can be limited with the following CLI:

Classic CLI:

config>service>nat>nat-policy# port-limits forwarding 
  - forwarding <limit>
  - no forwarding

MD-CLI:

configure
    service { 
        nat {
            nat-policy <name> {
                port-limits {
                }
            }
        }
    }

This limit is the total number of port forwards, regardless of the methods by which the port forwards are requested, either PCP MAP, PORT_SET, or static port forwards.

PCP clients should not request overlapping ports. Requesting overlapping ports produces an erroneous condition. If this condition occurs, then the request is considered as a refresh of the existing ports. This is described in RFC 7753, Section 4.4.1.

The following example depicts PCP port allocation with the PORT_SET option in action. For additional examples, see RFC 7753.

In this example, the sequence on the top of PORT_SET example represents the state of the port forwards for an external IP address before the PCP Request with the PORT_SET option is received. The port 1032 (in red) has already been mapped to a source port for the same client or to a different client.

A PCP client requesting an overlapping set of external ports (while internal ports are different) triggers the following action in SR OS (PCP server):

• The SR OS checks if the existing mapping is overlapping with the one for this client. It checks to see if the occupied external port is already mapped to one of the requested internal ports from the 20000 to 20009 range for the same client.

• If such overlap between internal and external ports is detected (for example, 20001 is mapped to 1032), then this is considered a refresh, and the response is:

  opcode: 1(MAP)
  internal port: 20,000
  assigned external port: 1032
  assigned external ip address:192.0.2.3
  

  Every overlapping pair of internal and external ports are individually acknowledged. No new mapping is allocated.

• If there is no overlap (when the external port is mapped to a port outside of the 20000 to 20009 range), and no limit is reached, then the SR OS honors the request where it finds any set containing consecutive 10 ports.

In PORT_SET example , there is no overlap (external port 1032 belongs to another client or the same client outside of the 20000 to 20009 range) and consequently a block of 10 ports (following parity) is allocated to the client.

Consider the following points when the when PCP PORT_SET option is enabled. Points listed below are in accordance with the RFC 7753:

• The SR OS attempts to allocate the first external port from the suggested external port. If the port is not available, another port is selected.

• Parity is honored.

• The PORT_SET size value 0xffff in the request indicates that the client is willing to accept as many ports as the SR OS can offer.

• If the requested PORT-SET request cannot be fully (or exactly) satisfied because of the unavailability of the requested consecutive port range, the SR OS tries to find and allocate the next largest port set.

• If the SR OS, because of the lack of contiguous port ranges, allocates only a single port, the PORT_SET option is not present in the response.

• If the SR OS receives a PCP MAP request, with or without a PORT_SET option that tries to map one or more internal ports or port sets belonging to already existing mappings, then the request is considered to be a refresh request. Each of the matching port or port set mappings is processed independently, as if a separate refresh request was received. Consequently, the SR OS sends a Mapping Update message for each of the mappings.

• If multiple PORT_SET options are present in a single PCP MAP request, a MALFORMED_OPTION error is returned.

• If the PORT_SET size is zero, a MALFORMED_OPTION error is returned.

• If a Prefer Failure option is present, a MALFORMED_OPTION error is returned.

• When a PCP request contains both the PORT_SET and Port Reservation Port (N/N+1) options, only the PORT_SET is honored.

• PCP (with PORT_SET option or otherwise) should not be configured simultaneously with static port forwards in the same NAT pool. PCP allows for dynamic refreshment of port forwards while static port forwards do not have this capability. As a result, PCP port refresh of a port forward allocated statically may lead to unwanted behavior.

• If the PORT_SET capability is added to or removed from an operationally up PCP server on an SR OS node, the server resets its Epoch time and sends a Version 2 ANNOUNCE message as described in the PCP specification.

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 based size for IPv6 packet is 1280 bytes, 8 fragments is enough to cover jumbo Ethernet frames.

configure 
   [router] | [service vprn]
        nat 
          inside
             dual-stack-lite 
address <IPv6 Addr>   
                   tunnel-mtu bytes
                  ip-fragmentation {disabled | fragment-ipv6 | fragment-ipv6-unless-ipv4-df-set}   

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.

configure 
   [router] | [service vprn]
        nat 
          inside
             nat64   
                ipv6-mtu bytes
            ip-fragmentation {disabled | fragment-ipv6 | fragment-ipv6-unless-ipv4-df-set}

Fragmentation statistics in DS-Lite can be observed by issuing the following command:

show isa nat-group <grp-id> mda <slot-id/mda-id> statistics

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

show isa nat-group 1 mda 1/2 statistics 
===============================================================================
ISA NAT Group 1 MDA 1/2
===============================================================================
--snip--
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
--snip--
===============================================================================

To interpret these counters, familiarity with the following terms in the context of fragmentation is required:

• packet

  An IP packet that is split into fragments (multiple frames) because of its original size being larger than the MTU configured on any node servicing this packet.

• fragment

  A fragment comprises the frames that make up a packet. Multiple fragments (frames on the wire) are eventually reassembled into the original packet.

• fragment list

  MS-ISA maintains a list of fragments belonging to a single packet. Each list represents a single fragmented packet and the list contains multiple fragments.

• fragment hole

  A hole refers to a fragment or a group of consecutive fragments in a fragment list. Fragments of a packet are sequentially numbered from first to last and they must be reassembled in the same order in which they are fragmented. For example, if a packet contains 9 fragments but only fragments [1,3,5,9] are received by MS-ISA, then there are 3 holes in this list [2],[3,4],[6,7,8].

• flow

  This is identified by 5 tuple <src IP, dst IP, src Port, dst Port, protocol>. Flows can have many packets and each packet of a flow can be fragmented.

Counter names and descriptions describes counter names.

Multi-chassis 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 multi-chassis 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 ISA redundancy, each ISA is subdivided into multiple logical 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 ISA fails, its members are downloaded by the CPM to the remaining active ISAs. Memory resources on each ISA are reserved to accommodate additional traffic from the failed ISAs. The amount of resources reserved per ISA depends on the number of ISAs in the system and the number of simultaneously supported ISA failures. The number of simultaneous ISA failures per system is configurable. Memory reservation affects NAT scale per ISA.

Traffic received on the inside is forwarded by the ingress forwarding complex to a predetermined member 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 ISAs in case of an ISA failure. The segmentation of ISAs into members for a single failure scenario is shown in Load distribution in active-active intra-chassis redundancy model. The protection mechanism in this example is designed to cover for one physical ISA failure. Each 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 ISA failure occurs, three members are delegated to the remaining ISAs. Each member from the failed ISA is mapped to a corresponding reserved member on the remaining ISAs.

Active-active ISA redundancy model supports multiple failures simultaneously. The protection mechanism shown in Multiple failures is designed to protect against two simultaneous ISA failures. As the previous case, each 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 active-active ISA redundancy model supporting single ISA failure shows resource utilization for a single ISA failure in relation to the total number of ISAs in the system. The resource utilization affects only scale of each ISA. However, bandwidth per ISA is not reserved and each 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 considered as an optional redundancy model in L2-Aware NAT which is mutually exclusive with the other two MS-ISA redundancy modes (active/active and active/standby).

L2-Aware bypass is enabled with the following CLI:

configure
 isa
   nat-group <id>
    redundancy {active-active|active-standby|l2aware-bypass}
 

A health value determines the activity of a NAT group within a pair of redundant nodes. The health value of a NAT group is internally calculated. The system can automatically decrease this value depending on the events that can negatively affect the system’s ability to perform NAT at a needed capacity.

A NAT group with a higher health value becomes active.

Activity states at equal health shows activity states, if paired NAT groups have equal health values on both nodes. Preferred is a configuration parameter that influences the activity state for a pair of NAT groups with equal health value (typical use case would be load balancing per NAT group).

The health parameter is initially set to a value of 1000 under the following circumstances:

• The number of active ISAs in a NAT group is matching the configured value for the active-mda-limit configuration parameter.

• There are no port failures that are being monitored.

• There are no failures within the operation groups that are being monitored.

The above circumstances imply that the system is fully operational with no failures that would affect NAT operation.

However, the health value can be influenced by the events that can affect NAT operation, and that are outside of ISA-related failures, for example, unhealthy ports and paths that lead traffic in and out of the NAT node. Such events are explicitly tracked or monitored for the purpose of dynamically adjusting the health value and therefore influencing the activity of the NAT groups.

Stateful inter-chassis NAT redundancy protects against the following failures:

• Nodal failure; if the active node fails, the standby node is notified of such an event by the lack of received keepalives.

• ISA failure; a NAT group must have exactly the active-mda-limit number of ISAs that are operationally up to participate in stateful inter-chassis NAT redundancy. If the number of operational ISAs falls below the configured limit, then the health of the NAT group drops to 0.

• Ports on the node can be monitored, and their operational state can trigger a change of the health value.

• BFD sessions on the node can be monitored using the oper-groups and their state change can trigger a change of the health value.

• VRRP instances under interface configurations can be monitored using the oper-groups and their state change can trigger a change of the health value.

• SAPs on the node can be monitored using the oper-groups and their operational state can trigger a change of the health value.

Port and oper-group state change influences the reachability of the NAT node and consequently this affects network-wide NAT operation. If that port or path capacity in and out of the NAT node drops below a specific level, a switchover to a healthier NAT node may be needed.

Port states can be tracked or monitored on the private side (inside) and on the public side (outside) of NAT.

Oper-groups are constructs that are tracking states of BFD enabled interfaces, SAPs, and VRRP instances.

BFD sessions targeted to the next hop can traverse intermediate Layer 2 nodes and can have longer reach than port tracking.

Another benefit of monitoring ports and paths is that it can help reduce the amount of traffic on the inter-chassis communication link (ICL) if that active node loses direct connection to the node downstream or upstream from it. The link for inter-chassis control communication (ICL) must always be present (for synchronization purposes). However, this link does not need to be designed for heavy traffic loads during extended periods of time occurs if traffic bearing ports are not colocated with the active node. However, this link is used for shorter transient periods that are caused by switchovers.

NAT-related routes are active only on the node with the active NAT group. On the outside, these are the pool routes that attract traffic in the downstream direction. On the inside, the destination-prefix (which can be configured per NAT policy) represents a route that diverts traffic to NAT in the upstream direction. In case of a filter-based diversion to NAT, a steering route is advertised only from the active node. The following are the steering-route contexts.

config>router>nat>inside>redundancy>steering-route ip-prefix/length

config>service>vprn>nat>inside>redundancy>steering-route ip-prefix/length

The route advertisement concept is shown in Route advertisement.

The goal of flow synchronization is to minimize service interruption after a switchover. Minimum service interruption in this context allows some packet drop during a switchover, but the user sessions are preserved without requiring a user to restart them. Flows are synchronized directly between the ISAs at the time of creation and deletion, and always only from the active side to the standby side.

The amount of traffic carried across the inter-chassis link is proportional to the number of flows that are synchronized, and it also depends on the NAT type (NAT44, DS-Lite or NAT64). The size of a flow record on the wire is around 100 bytes and a number of flow records can be packed into a single frame whose MTU is adjustable. With approximately 90 bytes of header overhead per frame, and the number of synchronized flows, it is relatively easy to estimate the required bandwidth of the inter-chassis links. The minimum recommended bandwidth of the inter-chassis link is 10 Gb/s.

Excluding short-lived flows from synchronization could further reduce the necessary bandwidth for synchronization. The flow replication threshold is configurable:

 configure
      isa
         nat-group <id>
            active-mda-limit <limit>   
            inter-chassis-redundancy
               replication-threshold <seconds>   [0..300]

For the replication-threshold, Nokia recommends choosing a value that is larger than any of the typical short-lived flows that are not closed by the protocol itself but rely on the timeout value for its expiration (udp-dns, udp-initial, or icmp-query).

After a switchover, a resynchronization of flows occurs. The new standby ISA starts clearing all its flows and the synchronization process restarts. This means that an attempt is made to resynchronize flows from the currently active side to the standby side. During this process, the active ISAs continue to forward traffic and create new flows.

While the flow synchronization is in progress, a switchover is not allowed unless the health on the active side drops to 0, which means that one or more ISAs on the active side have failed.

Excessive switchovers can be caused by unstable network elements. Events causing instability should be dampened at the source (ports may support event dampening). Event dampening control is not configurable under NAT. However, a dampening mechanism is built into stateful inter-chassis NAT redundancy by not allowing a switchover while synchronization is in progress.

Considering that a full re-synchronization is triggered after every switchover, the next switchover can occur only after the amount of time needed for full synchronization of flows. The new standby starts deleting flows and after this is completed, all flows from the newly active ISA are copied over to the standby.

Flow synchronization occurs directly between the ISAs, bypassing CPMs. Each ISA has its own IP address through which it communicates with its counterpart on the peering node.

Although each ISA has its own IP address, only one IP address in a NAT group is configured. This IP address is used by one of the ISAs and the rest of the ISAs are assigned consecutive IP addresses automatically by the system.

Preemption is a feature that allows one node to relinquish activity to a peering node when the health values are equal. This functionality can be enabled through configuration (preferred CLI command). If one of the nodes in the redundant pair is enabled for preemption (has a preferred keyword configured), then this node, upon a boot up, takes over the activity from the existing active peering node with the same health value.

In a setup with two nodes with the same health value and no preferred command is configured on either node, the currently active node remains active and does not relinquish its activity status to a just booted up node unless the health value is changed.

If the health values are different between the peering nodes, preemption is automatically disabled, and the activity is driven solely by the health value.

A freshly booted node that is about to take over the activity from an existing node (because of preemption), waits for all the flows to be synchronized and transferred from the currently active node. Only after this transfer is complete, does switchover occur.

Control messages originated by the CPM that pertain to NAT redundancy are treated with the highest priority and are marked by the system with a DSCP value of Network Control NC1 (48d). Those messages are crucial to stability of NAT redundancy (otherwise inadvertent switchovers could occur).

Flow synchronization control messages originated by ISAs are marked with EF (46d) for DSCP and 5 for dot1p, which are lower priorities than CPM-originated messages. The sync (ISA keepalive) messages are sent with DSCP NC1 and dot1p 6.

Flow synchronization messages are more tolerant to delays and loss.

Both of these types of control messages should be higher priority than any customer -originated traffic that is expected to cross the ICL. Customer traffic can be marked in SR OS node by the appropriate QoS configuration on egress interfaces.

Subscriber-aware information must be supplied to both nodes (active and standby) through RADIUS accounting.

With Nokia BNG, the following configuration ensures that subscriber information is sent through RADIUS to more than one target:

*A:BNG1>config>subscr-mgmt>sub-prof# info
----------------------------------------------
            radius-accounting
                policy "acct-nat-1" "acct-nat-2"
            exit

Accounting policies contain respective NAT node destinations and consequently the subscriber information is sent to both NAT nodes.

A pair of nodes participating in stateful NAT inter-chassis redundancy must have matching NAT configurations, the inside service-id and outside service-id. That is, parameters other than the configuration items referring to local objects, such as ports and interfaces, should be configured with the same values on both nodes.

For example,

config isa nat-group inter-chassis-redundancy keepalive interval dropcount count

must be the same on both nodes.

However, the statement

config isa nat-group inter-chassis-redundancy monitor-port port-id

does not need to match because each node can monitor its own set of unique ports, or not monitor ports at all.

Detection of configuration mismatch is logged in the system and operators are encouraged to check the logs periodically for any misaligned statements.

Certain NAT configuration changes can be performed online, which allows NAT to continue running in a redundant configuration.

In classic CLI, the user cannot perform the following online:

• delete flows

• block subscribers

In MD-CLI, these changes are allowed; however, during the commit, the inter-chassis NAT redundancy is temporarily disabled and then re-enabled after the commit is completed. Examples of configuration changes that require halting synchronization, include manipulation of NAT pools with active flows or subscribers, or removing NAT policies for active subscribers.

For configuration changes that can be performed online without halting the synchronization, there is a period during which the configuration between the nodes are misaligned (while the user is performing configuration changes). During these periods, the system continuously tries to synchronize the configuration. This perpetual attempt to synchronize flows is demanding for processing power and Nokia recommends it should be avoided.

A:admin@node-2# 
   isa
      nat-group 1 {        
          redundancy {            
              inter-chassis {
                  sync false
              }
          }
      }

----------------------------------------------
        nat-group 1 create
            no shutdown
            redundancy inter-chassis
            active-mda-limit 1
            exit
        exit
----------------------------------------------

This example relies on the following assumptions in Port monitoring scenario:

• Load sharing over redundant chassis is achieved through two nat-groups that are, under normal conditions (no failures), active on respective chassis:

  • nat-group 1 is active on NAT node 1.

  • nat-group 2 is active on NAT node 2.

• Two 100G links on the network/public/outside side are shared between the two NAT groups on each node (Internet access). These links are redundant, and failure of one link does not have a negative effect on the traffic.

• Each NAT group has five 10G ports connected on the subscriber/private/inside side. Planned traffic load over those links is between 30G and 40G, which means that one link can be safely lost, without affecting traffic in the NAT group.

The operator’s rules for managing failures are the following:

• The scheme protects against two access link failures per NAT group and one network link failure, simultaneously.

• The scheme protects against three access link failures per NAT group, simultaneously. However, in this case, there cannot be any network link failures.

• In the two above scenarios, if both network links fail on the same node (while on the other node at least one is available), the node with two failed links becomes standby.

According to those rules, the following configuration can be applied:

configure
   isa
      nat-group 1
         active-mda-limit 5   
         inter-chassis-redundancy
            monitor-port port-1 health-drop 6
            monitor-port port-2 health-drop 6
            monitor-port port-3 health-drop 6
            monitor-port port-4 health-drop 6
            monitor-port port-5 health-drop 6
            monitor-port port-11 health-drop 10
            monitor-port port-12 health-drop 10

The results for a randomly selected number of failure combinations (out of 360 valid combinations) is shown in Randomly selected number of failure combinations .

‟N” indicates that the priority is equal, and unless preemption is enabled, the node that becomes active first, remains active.

All MS-ISA uses include support for service mirroring running with no feature interactions or impacts. For example, any service diverted to AA, IPsec, NAT, LNS, or supported combinations of MS-ISA application also supports service mirroring simultaneously.

Subscriber aware Large Scale NAT44 attempts to combine the positive attributes of Large Scale NAT44 and L2-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

Subscriber awareness in Large Scale NAT44 facilitates the release of NAT resources immediately after the BNG subscriber is terminated, without having to wait for the last flow of the subscriber to expire on its own (TCP timeout is 4hours by default).

The subscriber aware Large Scale NAT44 function leverages RADIUS accounting proxy built-in to the 7750 SR. The RADIUS accounting proxy allows the 7750 SR to inform Large Scale NAT44 application about individual BNG subscribers from the RADIUS accounting messages generated by a remote BNG and use this information in the management of Large Scale NAT44 subscribers. The combination of the two allows, for example, the 7750 SR running as a Large Scale NAT44 to make the correlation between the BNG subscriber (represented in the Large Scale NAT44 by the Inside IP Address) and RADIUS attributes such as User-Name, Alc-Sub-Ident-String, Calling-Station-Id or Class. These attributes can subsequently be used for either management of the Large Scale NAT44 subscriber, or in the NAT RADIUS Accounting messages generated by the 7750 SR Large Scale NAT44 application. Doing so simplifies both the administration of the Large Scale NAT44 and the logging function for port-range blocks.

As BNG subscribers authenticate and come online, the RADIUS accounting messages are ‛snooped’ through RADIUS accounting proxy which creates a cache of attributes from the BNG subscriber. BNG subscribers are correlated with the NAT subscriber by framed-ip address, and one of the following attributes that must be present in the accounting messages generated by BNG:

• username

• subscriber ID

• RADIUS Class attribute

• Calling-Station-id

• IMSI

• IMEI

Framed-ip address must also be present in the accounting messages generated by BNG.

Large Scale NAT44 Subscriber Aware application receives a number of cached attributes which are used for appropriate management of Large Scale NAT44 subscribers, for example:

• Delete the Large Scale NAT44 subscriber when the BNG subscriber is terminated.

• Report attributes in Large Scale NAT44 accounting messages according to configuration options.

Creation and removal of RADIUS accounting proxy cache entries related to BNG subscriber is triggered by the receipt of accounting start/stop messages sourced by the BNG subscriber. Modification of entries can be triggered by interim-update messages carrying updated attributes. Cached entries can also be purged via CLI.

In addition to passing one of the above attributes in Large Scale NAT44 RADIUS accounting messages, a set of opaque BNG subscriber RADIUS attributes can optionally be passed in Large Scale NAT44 RADIUS accounting messages. Up to 128B of these opaque attributes are accepted. The remaining attributes are truncated.

Large Scale NAT44 subscriber instantiation can optionally be denied in case that corresponding BNG subscriber cannot be identified in Large Scale NAT44 through RADIUS accounting proxy.

Configuration guidelines:

Configure RADIUS accounting proxy functionality in a routing instance that receives accounting messages from the remote or local BNG. Optionally forward received accounting message received by RADIUS accounting proxy to the final accounting destination (accounting server).

Point the BNG RADIUS accounting destination to the RADIUS accounting proxy – this way RADIUS accounting proxy receives and ‛snoop’ BNG RADIUS accounting data.

BNG subscriber can be associated with two accounting policies, therefore pointing to two different accounting destinations. For example, one to the RADIUS accounting proxy, the other one to the real accounting server.

Configure subscriber aware Large Scale NAT44. From Large Scale NAT44 Subscriber Aware application reference the RADIUS Proxy accounting server and define the string that is used to correlate BNG subscriber with the Large Scale NAT44 subscriber.

Optionally enable NAT RADIUS accounting that includes BNG subscriber relevant data.

(1)

*A:left-a20>config>service>vprn#
      radius-proxy
                server "proxy-acct" purpose accounting create
                    default-accounting-server-policy "lsn-policy"
                   description "two side server -interface:client ; default-plcy:real server"
                    interface "rad-proxy-loopback"
                    secret "TEg1UEZzemRMyZXD1HvvQGkeGfoQ58MF" hash2
                    no shutdown
                exit
            exit

RADIUS accounting proxy listens to accounting messages on interface ‛rad-proxy-loopback’.

The name ‛proxy-acct’ as defined by the server command is used to reference this proxy accounting server from Large Scale NAT44.

Received accounting messages can be relayed further from RADIUS accounting proxy to the accounting server which can be indirectly referenced in the default-accounting-policy ‛lsn-policy’.

The lsn-policy is defined as:
*A:left-a20>config>aaa#
               radius-server-policy "lsn-policy" create
            servers
                router "Base"
                source-address 192.168.1.12
                server 1 name "192"
            exit
        exit

This lsn-policy can then reference an external RADIUS accounting server with its own security credentials. This external accounting server can be configured in any routing instance.

*A:left-a20>config>router>radius-server# info 
----------------------------------------------
            server "192" address 192.168.1.10 secret "KRr7H.K3i0z9O/hj2BUSmdJUdl.zWrkE" hash2 port 1813 create
                description "real radius or acct server"
            exit

(2)

Two RADIUS accounting policies can be configured in BNG, one to the real RADIUS server, the other one to the RADIUS accounting proxy.

*A:left-a20>config>subscr-mgmt>sub-prof# info 
----------------------------------------------
            radius-accounting-policy "real-acct-srvr"  duplicate ‟lsn”
            egress
                agg-rate-limit 10000 
            exit
----------------------------------------------
*A:left-a20>config>subscr-mgmt>acct-plcy# info 

----------------------------------------------

            description ‟lsn  radius-acct-policy”
update-interval 5
            include-radius-attribute
                acct-authentic
                acct-delay-time
                called-station-id
                calling-station-id remote-id
                circuit-id
                framed-interface-id
                framed-ip-addr
                framed-ip-netmask
                mac-address
                nas-identifier
                nas-port-id  
                nas-port-type
                nat-port-range
                remote-id
                sla-profile
                sub-profile
                subscriber-id
                user-name
                alc-acct-triggered-reason
            exit
            session-id-format number
            radius-accounting-server
                router 10  (service id where proxy radius is configured)
                server 1 address 10.5.5.5 secret "cVi1sidvgH28Pd9QoN1flE" hash2    
   (radius proxy IP address is 10.5.5.5 on interface ‟rad-proxy-loopback”; the ‛secret’ is the same as configured on RADIUS accounting proxy)
            exit

(3)

Sub-aware Large Scale NAT44 references the RADIUS accounting proxy server ‛proxy-acct’ and defines the calling-station-id attribute from the BNG subscriber as the matching attribute:

*A:left-a20>config>service>vprn>nat>inside# info 
----------------------------------------------
   nat-policy "nat-base"
      destination-prefix 10.0.0.0/16
      subscriber-identification
          attribute vendor "standard" attribute-type "station-id"
      description "sub-aware CGN"
      radius-proxy-server router 10 name "proxy-acct"
      no shutdown
    exit
                    
----------------------------------------------

(4)

Optionally RADIUS NAT accounting can be enabled:

*A:left-a20>config>isa>nat-group# info 
----------------------------------------------
            active-mda-limit 1
            radius-accounting-policy "nat-acct-basic"
            mda 1/2
            no shutdown

*A:left-a20>config>aaa>isa-radius-plcy# info detail 
----------------------------------------------
            description "radius accounting policy for NAT"
            include-radius-attribute
                framed-ip-addr 
                nas-identifier 
                nat-subscriber-string 
                user-name 
                inside-service-id 
                outside-service-id 
                outside-ip 
                port-range-block 
                hardware-timestamp 
                release-reason 
                multi-session-id 
                frame-counters 
                octet-counters 
                session-time 
                called-station-id 
                subscriber-data 
            exit
            radius-accounting-server
                access-algorithm direct
                retry 3
                router "Base"
                source-address-range 192.168.1.20 192.168.1.20
                timeout sec 5 
                server 1 address 192.168.1.10 secret "KlWIBi08CxTyM/YXaU2gQitOu8GgfSD7Oj5hjese27A" hash2 port 1813
            exit
----------------------------------

Such setup would produce a stream of following Large Scale NAT44 RADIUS accounting messages:

Mon Jul 16 10:59:27 2012
        NAS-IP-Address = 10.1.1.1
        NAS-Identifier = "left-a20"
        NAS-Port = 37814272
        Acct-Status-Type = Start
        Acct-Multi-Session-Id = "500456500365a4de7c29a9a07c29a9a0"
        Acct-Session-Id = "500456500365a4de6201d7b87c29a9a0"
        Called-Station-Id = "00-00-00-00-01-01"
        User-Name = "remote0"
        Calling-Station-Id = "remote0"
        Alc-Serv-Id = 10
        Framed-IP-Address = 10.0.0.7
        Alc-Nat-Outside-Ip-Addr = 198.51.100.1
        Alc-Nat-Port-Range = "198.51.100.1 1054-1058 router base"
        Acct-Input-Packets = 0
        Acct-Output-Packets = 0
        Acct-Input-Octets = 0
        Acct-Output-Octets = 0
        Acct-Input-Gigawords = 0
        Acct-Output-Gigawords = 0
        Acct-Session-Time = 0
        Event-Timestamp = "Jul 16 2012 10:58:40 PDT"
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Event-Timestamp = "Jul 16 2012 10:58:24 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Acct-Unique-Session-Id = "10f8bce6e5e7eb41"
        Timestamp = 1342461567
        Request-Authenticator = Verified

Mon Jul 16 11:03:56 2012
        NAS-IP-Address = 10.1.1.1
        NAS-Identifier = "left-a20"
        NAS-Port = 37814272
        Acct-Status-Type = Interim-Update
        Acct-Multi-Session-Id = "500456500365a4de7c29a9a07c29a9a0"
        Acct-Session-Id = "500456500365a4de6201d7b87c29a9a0"
        Called-Station-Id = "00-00-00-00-01-01"
        User-Name = "remote0"
        Calling-Station-Id = "remote0"
        Alc-Serv-Id = 10
        Framed-IP-Address = 10.0.0.7
        Alc-Nat-Outside-Ip-Addr = 198.51.100.1
        Alc-Nat-Port-Range = "198.51.100.1 1054-1058 router base"
        Acct-Input-Packets = 0
        Acct-Output-Packets = 1168
        Acct-Input-Octets = 0
        Acct-Output-Octets = 86432
        Acct-Input-Gigawords = 0
        Acct-Output-Gigawords = 0
        Acct-Session-Time = 264
        Event-Timestamp = "Jul 16 2012 11:03:04 PDT"
        Acct-Delay-Time = 5
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Acct-Session-Time = 279
        Event-Timestamp = "Jul 16 2012 11:03:04 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Acct-Unique-Session-Id = "10f8bce6e5e7eb41"
        Timestamp = 1342461836
        Request-Authenticator = Verified

Mon Jul 16 11:04:34 2012
        NAS-IP-Address = 10.1.1.1
        NAS-Identifier = "left-a20"
        NAS-Port = 37814272
        Acct-Status-Type = Stop
        Acct-Multi-Session-Id = "500456500365a4de7c29a9a07c29a9a0"
        Acct-Session-Id = "500456500365a4de6201d7b87c29a9a0"
        Called-Station-Id = "00-00-00-00-01-01"
        User-Name = "remote0"
        Calling-Station-Id = "remote0"
        Alc-Serv-Id = 10
        Framed-IP-Address = 10.0.0.7
        Alc-Nat-Outside-Ip-Addr = 198.51.100.1
        Alc-Nat-Port-Range = "198.51.100.1 1054-1058 router base"
        Acct-Terminate-Cause = Host-Request
        Acct-Input-Packets = 0
        Acct-Output-Packets = 1321
        Acct-Input-Octets = 0
        Acct-Output-Octets = 97754
        Acct-Input-Gigawords = 0
        Acct-Output-Gigawords = 0
        Acct-Session-Time = 307
        Event-Timestamp = "Jul 16 2012 11:03:47 PDT"
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Acct-Session-Time = 279
        Event-Timestamp = "Jul 16 2012 11:03:04 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Acct-Unique-Session-Id = "10f8bce6e5e7eb41"
        Timestamp = 1342461874
        Request-Authenticator = Verified

The matching accounting stream generated on the BNG is shown below:

Mon Jul 16 10:59:11 2012
        Acct-Status-Type = Start
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Address = 10.0.0.7
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        Calling-Station-Id = "remote0"
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Event-Timestamp = "Jul 16 2012 10:58:24 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        ADSL-Agent-Circuit-Id = "cgn_1_ipoe"
        ADSL-Agent-Remote-Id = "remote0"
        Alc-Subsc-ID-Str = "CGN1"
        Alc-Subsc-Prof-Str = "nat"
        Alc-SLA-Prof-Str = "tp_sla_prem"
        Alc-Client-Hardware-Addr = "2001:db8:65:05:10:01"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Acct-Unique-Session-Id = "9c1723d05e87c043"
        Timestamp = 1342461551
        Request-Authenticator = Verified

Mon Jul 16 11:03:51 2012
        Acct-Status-Type = Interim-Update
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Address = 10.0.0.7
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        Calling-Station-Id = "remote0"
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Acct-Session-Time = 279
        Event-Timestamp = "Jul 16 2012 11:03:04 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        ADSL-Agent-Circuit-Id = "cgn_1_ipoe"
        ADSL-Agent-Remote-Id = "remote0"
        Alc-Subsc-ID-Str = "CGN1"
        Alc-Subsc-Prof-Str = "nat"
        Alc-SLA-Prof-Str = "tp_sla_prem"
        Alc-Client-Hardware-Addr = "2001:db8:65:05:10:01"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Alcatel-IPD-Attr-163 = 0x00000001
        Alc-Acct-I-Inprof-Octets-64 = 0x00010000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x00010000000000020468
        Alc-Acct-I-Inprof-Pkts-64 = 0x00010000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x0001000000000000052a
        Alc-Acct-I-Inprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-I-Inprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-I-Inprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-I-Inprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-O-Inprof-Octets-64 = 0x00010000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00010000000000003154
        Alc-Acct-O-Inprof-Pkts-64 = 0x00010000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x0001000000000000009a
        Alc-Acct-O-Inprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-O-Inprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-O-Inprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-O-Inprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x00050000000000000000
        Acct-Unique-Session-Id = "9c1723d05e87c043"
        Timestamp = 1342461831
        Request-Authenticator = Verified

Mon Jul 16 11:04:34 2012
        Acct-Status-Type = Stop
        NAS-IP-Address = 10.1.1.1
        User-Name = "cgn_1_ipoe"
        Framed-IP-Address = 10.0.0.7
        Framed-IP-Netmask = 255.255.255.0
        Class = 0x63676e2d636c6173732d7375622d6177617265
        Calling-Station-Id = "remote0"
        NAS-Identifier = "left-a20"
        Acct-Session-Id = "D896FF0000000550045640"
        Acct-Session-Time = 322
        Acct-Terminate-Cause = User-Request
        Event-Timestamp = "Jul 16 2012 11:03:47 PDT"
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1/1/5:5.10"
        ADSL-Agent-Circuit-Id = "cgn_1_ipoe"
        ADSL-Agent-Remote-Id = "remote0"
        Alc-Subsc-ID-Str = "CGN1"
        Alc-Subsc-Prof-Str = "nat"
        Alc-SLA-Prof-Str = "tp_sla_prem"
        Alc-Client-Hardware-Addr = "2001:db8:65:05:10:01"
        Acct-Delay-Time = 0
        Acct-Authentic = RADIUS
        Alc-Acct-I-Inprof-Octets-64 = 0x00010000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x000100000000000248c4
        Alc-Acct-I-Inprof-Pkts-64 = 0x00010000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x000100000000000005d9
        Alc-Acct-I-Inprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-I-Inprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-I-Inprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-I-Outprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-I-Inprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-I-Outprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-O-Inprof-Octets-64 = 0x00010000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00010000000000003860
        Alc-Acct-O-Inprof-Pkts-64 = 0x00010000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x000100000000000000b0
        Alc-Acct-O-Inprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00030000000000000000
        Alc-Acct-O-Inprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x00030000000000000000
        Alc-Acct-O-Inprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-O-Outprof-Octets-64 = 0x00050000000000000000
        Alc-Acct-O-Inprof-Pkts-64 = 0x00050000000000000000
        Alc-Acct-O-Outprof-Pkts-64 = 0x00050000000000000000
        Acct-Unique-Session-Id = "9c1723d05e87c043"
        Timestamp = 1342461874
        Request-Authenticator = Verified

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.

MAP-T deployment scenario 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.

Routes related to MAP-T are advertised through IPv4 and IPv6 routing protocols. MAP-T routes in the VSR are owned by ‟protocol 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. Determining the rule IPv6 prefix 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 VSR; 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 VSR (transit messages), or are terminated or generated in or from a VSR.

The NAT-related ICMPv4 behavior is described in RFC 5508. The following NAT messages are supported in the MAP-T 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)

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). In the case where the IPv4-to-IPv6 translated packet is larger than the IPV6 MTU, the original IPv4 packet is fragmented so that the size of the translated IPv6 packet is within IPv6 MTU. IPv6 packets are never fragmented, although they may contain the fragmentation header that carries fragmentation information related to the original IPv4 packet/fragment.

The IPv6 MTU in the VSR is configurable for each MAP-T domain. The L2 header is excluded from the IPv6 MTU.

The MSS Adjust feature is used to prevent fragmentation of TCP traffic. The TCP synchronize/start (SYN) packets are intercepted and their MSS value inspected to ensure that it conforms with the configured MSS value. If the inspected value is greater than the value configured in the VSR BR, the MSS value in the packet is lowered to match the configured value before the TCP SYN packet is forwarded.

As the end nodes governing the MSS value are IPv4 nodes, this feature is supported for IPv4 packets only.

An MSS adjust is performed in both the upstream and downstream directions.

The VSR BR maintains a count of the forwarded and dropped packets/octets per MAP-T-domain per direction. The statistics are collected on ingress (upstream v6 and downstream v4) and stored in 64-bit counters.

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 shutdown/no shutdown, corresponding MAP domain is associated/dissociated from the routing context, corresponding MAP domain is shutdown /no shutdown, and so on)

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

Example:

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"

A valid MAP-T license is required to enable the MAP-T functionality in the VSR BR. A MAP-T domain can only be instantiated with the appropriate license, which enables the following CLI command:

configure 
   service 
      vprn <id> customer <cust-id> create
          map-domain <domain-name>

The MAP-T configuration consists of defining MAP-T parameters within a template. The MAP-T domain is then instantiated by applying (referencing) this template within a routing (router or VPRN) context.

Defining a MAP domain template:

configure 
  service 
    nat 
       map-domain <domain-name> create
          [no] shutdown
          dmr-prefix <ipv6-prefix>     
          tcp-mss-adjust  <segment-size>      
          mtu <mtu-size>
          ip-fragmentation 
             [no] v6-frag-header 
          mapping-rule <rule-name>
             [no] shutdown
             rule-prefix <ipv6-prefix>
             ipv4-prefix <ipv4-prefix> 
             ea-length <ea-bits-length>        
             psid-offset <psid-offset-len> 
          :
          mapping-rule <rule-name>
             [no] shutdown
             rule-prefix <ipv6-prefix>
             ipv4-prefix <ipv4-prefix>
             ea-length <ea-bits-length>         
             psid-offset <psid-offset-len> 
          :
          up to 256 rules per domain 

MAP-T domain instantiation:

configure 
   service vprn <id>   |  router
     nat
      map-t
         map-domain <domain-name> 

MAP domain example template:

The following example shows the MAP domain template for the BMRs defined BMR rules implementation example.

configure 
   service 
     nat
        map-domain domain_1 create 
           no shutdown
           dmr-prefix 2001:db8:0100::/64     
           mapping-rule rule_1
             no shutdown
             rule-prefix 2001:db8:0000::/48
             ipv4-prefix 10.11.11.0/24 
             ea-length 12  
             psid-offset 6 
           mapping-rule rule_2
             no shutdown
             rule-prefix 2001:db8:0001::/48
             ipv4-prefix 10.12.12.0/24
             ea-length 12
             psid-offset 6 
           mapping-rule rule_3
             no shutdown
             rule-prefix 2001:db8:0002::/48
             ipv4-prefix 10.13.13.0/24
             ea-length 12
             psid-offset 6 

MAP-T domain instantiation example:

The following example shows the MAP-T domain instantiation for the BMRs defined in BMR rules implementation example.

configure
   service 
      vprn 10
         nat 
           map-t
             map-domain domain_1 

MAP natively provides multi-chassis 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).

The 7750 SR supports ISA redundancy to provide reliable NAT even when an MDA fails. The active-mda-limit command allows an operator to specify how many MDAs are active in a NAT group. Any number of MDAs configured above the active-mda-limit are spare MDAs; they take over the NAT function if one of the current active MDAs fail.

A sample configuration is as follows:

configure
    isa
        nat-group 1 create
            active-mda-limit 1
            mda 1/2
            mda 2/2
            no shutdown
        exit
    exit
exit

Show commands are available to display the actual state of a nat-group and its corresponding MDAs:

show isa nat-group 1          
===============================================================================
ISA NAT Group 1
===============================================================================
Admin state       : inService           Operational state : inService
Active MDA limit  : 1                   Reserved sessions : 0
High Watermark (%): (Not Specified)     Low Watermark (%) : (Not Specified)
Last Mgmt Change  : 01/11/2010 15:05:36 
===============================================================================
===============================================================================
ISA NAT Group 1 members
===============================================================================
Group Member     State          Mda  Addresses  Blocks     Se-% Hi Se-Prio     
-------------------------------------------------------------------------------
1     1          active         1/2  0          0          0    N  0           
-------------------------------------------------------------------------------
No. of members: 1
===============================================================================

A nat-group cannot become active (no shutdown) if the number of configured MDAs is lower than the active-mda-limit.

An MDA can be configured in several nat-groups but it can only be active in a single nat-group at any moment in time. Spare MDAs can be shared in several nat-groups, but a spare can only become active in one nat-group at a time. Changing the active-mda-limit, adding or removing MDAs can only be done when the nat-group is shutdown.

Nat-groups that share spare MDAs must be configured with the same list of MDAs. It is possible to remove/add spare MDAs to a nat-group while the nat-group is admin enabled.

Configure
    isa
        nat-group 1 create
            active-mda-limit 1
            mda 1/2
            mda 2/2
            mda 3/1
            no shutdown
        exit
        nat-group 2 create
            active-mda-limit 1
            mda 1/2
            mda 2/2
            mda 3/1
            no shutdown
        exit
    exit
exit

Through show commands, it is possible to display an overview of all the nat-groups and MDAs.

show isa nat-group 
===============================================================================
ISA NAT Group Summary
===============================================================================
Mda  Group 1            Group 2           
-------------------------------------------------------------------------------
1/1  active             busy           
2/2  busy               active    
3/1  standby            standby 
===============================================================================

If an MDA fails, the spare (if available) takes over. All active sessions are lost, but new incoming sessions makes use of the spare MDA.

In case of an MDA failure in a nat-group without any spare MDA, all traffic toward that MDA is black-holed.

For L2-aware NAT, the operator has the possibility to clear all the subscribers on the affected MDA (clear nat isa), terminating all the subscriber leases. New incoming subscribers make use of the MDAs that are still available in the nat-group.

The following sections provide NAT Layer 2-Aware configurations.

#--------------------------------------------------
echo "Card Configuration"
#--------------------------------------------------
    card 1
        card-type iom4-e-b
        mda 1
            mda-type m48-1gb-xp-tx
        exit
        mda 2
            mda-type isa-bb
        exit
    exit
    card 2
        card-type iom4-e-b
        mda 1
            mda-type m48-1gb-xp-tx
        exit
        mda 2
            mda-type isa-bb
        exit
    exit

#--------------------------------------------------
echo "ISA Configuration"
#--------------------------------------------------
    isa
        nat-group 1 create
            description "1 active + 1 spare"
            active-mda-limit 1
            mda 1/2
            mda 2/2
            no shutdown
        exit
    exit
#--------------------------------------------------
echo "Router (Network Side) Configuration"
#--------------------------------------------------
    router 
        ...
#--------------------------------------------------
echo "NAT (Network Side) Configuration"
#--------------------------------------------------
        nat
            outside
                pool "pool1" nat-group 1 type l2-aware create 
                    address-range 10.81.0.0 10.81.0.200 create
                    exit
                    no shutdown
                exit
            exit
        exit
#--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
    service
        customer 1 create
            description "Default customer"
        exit
        ...
        vprn 100 customer 1 create
            ...
            nat
                outside
                    pool "pool2" nat-group 1 type l2-aware create 
                        address-range 10.0.0.0 10.0.0.200 create
                        exit
                        no shutdown
                    exit
                exit
            exit
        exit

        vprn 101 customer 1 create
            ...
            nat
                inside
                    l2-aware
                        # Hosts in this service with IP addresses in these ranges
                        # will be subject to l2-aware NAT.
                        address 10.0.0.1/29
                        address 10.1.0.1/29
                    exit
                exit
            exit
        exit
        ...
        nat
            nat-policy "l2-aware-nat-policy1" create 
                pool "pool1" router Base
            exit
            nat-policy "l2-aware-nat-policy2" create 
                pool "pool2" router 100
            exit
        exit
        ...
    exit
#--------------------------------------------------
echo "Subscriber-mgmt Configuration"
#--------------------------------------------------
    subscriber-mgmt
        # Subscribers using these sub-profiles will be subject to l2-aware NAT.
        # The configured nat-policies will determine which IP pool will be used.
        sub-profile "l2-aware-profile1" create
            nat-policy "l2-aware-nat-policy1"
        exit
        sub-profile "l2-aware-profile2" create
            nat-policy "l2-aware-nat-policy2"
        exit
        ...
    exit 

The following sections provide Large Scale NAT configuration examples.

configure
#--------------------------------------------------
echo "Card Configuration"
#--------------------------------------------------
    card 3
        card-type iom3-xp
        mda 1
            mda-type isa-bb
        exit
        mda 2
            mda-type isa-bb
        exit
    exit
#--------------------------------------------------
echo "ISA Configuration"
#--------------------------------------------------
    isa
        nat-group 1 create
            active-mda-limit 2
            mda 3/1
            mda 3/2
            no shutdown
        exit
    exit
#--------------------------------------------------
echo "Filter Configuration"
#--------------------------------------------------
    filter 
        ip-filter 123 create
            entry 10 create
                match 
                    src-ip 10.0.0.1/8
                exit 
                action nat
            exit 
        exit 
    exit 
#--------------------------------------------------
echo "NAT (Declarations) Configuration"
#--------------------------------------------------
    service
        nat
            nat-policy "ls-outPolicy" create 
            exit
        exit
    exit
#--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
    service
        customer 1 create
            description "Default customer"
        exit
        vprn 500 customer 1 create
            interface "ip-192.168.113.1" create
            exit
            nat
                outside
                    pool "nat1-pool" nat-group 1 type large-scale create 
                        port-reservation ports 200 
                        address-range 10.81.0.0 10.81.6.0 create
                        exit
                        no shutdown
                    exit
                exit
            exit
        exit
        vprn 550 customer 1 create
            interface "ip-192.168.13.1" create
            exit
        exit
        nat
            nat-policy "ls-outPolicy" create 
                pool "nat1-pool" router 500
                timeouts
                    udp hrs 5 
                    udp-initial min 4 
                exit
            exit
        exit
        vprn 500 customer 1 create
            router-id 10.21.1.2
            route-distinguisher 500:10
            vrf-target export target:500:1 import target:500:1
            interface "ip-192.168.113.1" create
                address 192.168.113.1/24
                static-arp 192.168.113.5 2001:db8:01:01:00:01
                sap 1/1/1:200 create
                exit
            exit
            no shutdown
        exit
        vprn 550 customer 1 create
            router-id 10.21.1.2
            route-distinguisher 550:10
            vrf-target export target:550:1 import target:550:1
            interface "ip-192.168.13.1" create
                address 192.168.13.1/8
                sap 1/2/1:900 create
                    ingress
                        filter ip 123
                    exit
                exit
            exit
            nat
                inside
                    nat-policy "ls-outPolicy"
                exit
            exit
            no shutdown
        exit
    exit
exit all

The following output displays example configurations.

VPRN service example:

configure service vprn 100 nat
                inside
                    nat-policy "priv-nat-policy"
                    destination-prefix 0.0.0.0/0
                    dual-stack-lite
                        subscriber-prefix-length 128
                        address 2001:db8:470:1F00:FFFF:190
                            tunnel-mtu 1500
                        exit
                        no shutdown
                    exit
                    redundancy
                        no peer
                        no steering-route
                    exit
                    subscriber-identification
                        shutdown
                        no attribute
                        no description
                        no radius-proxy-server
                    exit
                    l2-aware
                    exit
                exit
                outside
                    no mtu
                exit

Router NAT example:

configure router nat
            outside
                no mtu
                pool "privpool" nat-group 3 type large-scale create 
                    no description
                    port-reservation blocks 128 
                    port-forwarding-range 1023
                    redundancy
                        no export
                        no monitor
                    exit
                    subscriber-limit 65535
                    no watermarks
                    mode auto
                    address-range 10.0.0.5 10.0.0.6 create
                        no description
                        no drain
                    exit
                    no shutdown
                exit
                pool "pubpool" nat-group 1 type large-scale create 
                    no description
                    port-reservation blocks 1 
                    port-forwarding-range 1023
                    redundancy
                        no export
                        no monitor
                    exit
                    subscriber-limit 65535
                    no watermarks
                    mode auto
                    address-range 192.168.8.241 192.168.8.247 create
                        no description
                        no drain
                    exit
                    no shutdown
                exit
            exit

Service NAT example:

configure service nat
            nat-policy "priv-nat-policy" create
                alg
                    ftp
                    rtsp
                    sip
                exit
                block-limit 4
                no destination-nat
                no description
                filtering endpoint-independent
                pool "privpool" router Base
                no ipfix-export-policy
                port-limits
                    forwarding 64
                    no reserved
                    no watermarks
                exit
                priority-sessions
                exit
                session-limits
                    max 65535
                    no reserved
                    no watermarks
                exit
                timeouts
                    icmp-query min 1 
                    sip min 2 
                    no subscriber-retention
                    tcp-established hrs 2 min 4 
                    tcp-syn sec 15 
                    no tcp-time-wait
                    tcp-transitory min 4 
                    udp min 5 
                    udp-initial sec 15 
                    udp-dns sec 15 
                exit
                no tcp-mss-adjust
                no udp-inbound-refresh
            exit
            nat-policy "pub-nat-policy" create
                alg
                    ftp
                    no rtsp
                    no sip
                exit
                block-limit 1
                no destination-nat
                no description
                filtering endpoint-independent
                pool "pubpool" router Base
                no ipfix-export-policy
                port-limits
                    no forwarding
                    no reserved
                    no watermarks
                exit
                priority-sessions
                exit
                session-limits
                    max 65535
                    no reserved
                    no watermarks
                exit
                timeouts
                    icmp-query min 1 
                    sip min 2 
                    no subscriber-retention
                    tcp-established hrs 2 min 4 
                    tcp-syn sec 15 
                    no tcp-time-wait
                    tcp-transitory min 4 
                    udp min 5 
                    udp-initial sec 15 
                    udp-dns sec 15 
                exit
                no tcp-mss-adjust
                no udp-inbound-refresh
            exit

Appropriate licensing is required to enable the VSR-NAT functionality in the system. However, no further licensing enforcement is performed based on resource utilization, such as the consumed bandwidth or the number of NAT bindings.

The following NAT-related functionality is enabled through licensing:

• LSN (LSN44, DS-Lite, and NAT64)

• L2-Aware NAT

• UPnP

• geo-redundancy

You can use the CLI or MIB on VSR-NAT to get more information about the number of LSN bindings and LSN bandwidth.

NAT licenses required to unlock NAT functionality describes the licenses required to unlock the VSR-NAT functionality.

A NAT subscriber is an internal entity whose true identity is hidden outside the network. The NAT subscriber is represented by a binding that is a set of stateful mappings between the internal and external representations of the subscriber. From the licensing perspective, the terms ‟NAT bindings” and ‟NAT subscribers” can be used interchangeably.

VSR-NAT collects the number of LSN subscribers for licensing purposes; the L2-Aware NAT subscribers are excluded from this count. An LSN subscriber is defined as follows:

• Large Scale NAT44 (or CGN)

  The subscriber is an internal IPv4 address.

• DS-Lite

  The subscriber is identified by the CPE IPv6 address (B4 element) or an IPv6 prefix. The selection of the address or prefix as the representation of a DS-Lite subscriber is configuration-dependent.

• NAT64

  The subscriber is an IPv6 address.

The number of LSN subscribers (LSN44, DS-Lite, and NAT64) in VSR-NAT is sampled every hour on the hour (for example, at 00:00 am, 01:00 am, 02:00 am, and so on). Each sample is a snapshot of the number of subscribers at the time that the statistics are collected.

The CLI can be used to view the following information:

• 24 samples (one per hour) in the current day

• Maximum value for each of the last 7 days

• Average value for each of the last 7 days

• Maximum value since the system booted

For the list of CLI commands available for use, see VSR-NAT show command examples.

The measurement of LSN bandwidth includes translated packets and octets in the upstream and downstream direction. Packets that are rejected for any reason and traffic carrying logging information are both excluded from the statistics.

LSN bandwidth statistics for VSR-NAT are collected every 10 minutes. The bandwidth is derived as a difference in octet count between the two consecutive collection intervals, divided by a 10 minute interval. There is no bandwidth differentiation per LSN type (LSN44, DS-Lite, and NAT64) or per direction. Aggregate bandwidth values per node are maintained in kb/s units. L2-Aware NAT and WLAN gateway statistics are not included in the statistics collection.

The CLI can be used to view the following LSN bandwidth information:

• 144 bandwidth values for the current day (bandwidth statistics are collected every 10 minutes)

• Maximum bandwidth value for each of the last 7 days

• Average bandwidth value for each of the last 7 days

• Maximum bandwidth value since the system booted

For the list of CLI commands available for use, see VSR-NAT show command examples.

The following CLI commands are available for use:

• show system license-statistics 24-hours application nat

• show system license-statistics week application nat

• show system license-statistics peak application nat

The following output shows examples of NAT statistics.

Weekly display example:

*A:Dut-A>show system license-statistics week application nat
=====================================================================
week license statistics for nat
========================================================================
index       time                average              peak
---------------------------------------------------------------------
LSN subscribers
1           2016/02/01 00:00:00 370                  456
2           2016/01/31 00:00:00 375                  512
3           2016/01/30 00:00:00 374                  510
4           2016/01/29 00:00:00 373                  478
5           2016/01/28 00:00:00 360                  450
6           2016/01/27 00:00:00 370                  496
7           2016/01/26 00:00:00 373                  503
LSN bandwidth
1           2016/02/01 00:00:00 12472623             12472623
2           2016/01/31 00:00:00 12472623             12472623
3           2016/01/30 00:00:00 12472623             12472623
4           2016/01/29 00:00:00 12472623             12472623
5           2016/01/28 00:00:00 12472623             12472623
6           2016/01/27 00:00:00 12472623             12472623
7           2016/01/26 00:00:00 12472623             12472623
---------------------------------------------------------------------
No. of license statistics entries: 14 
=====================================================================

24-hour display example:

*A:Dut-A# show system license-statistics 24-hours application nat 
========================================================================
24 hours license statistics for nat
========================================================================
index       time                value                
------------------------------------------------------------------------
LSN subscribers
1           2016/06/29 19:00:00 512                  
2           2016/06/29 20:00:00 512                  
LSN bandwidth
1           2016/06/29 18:10:00 0                    
2           2016/06/29 18:20:00 0                    
3           2016/06/29 18:30:00 0                    
4           2016/06/29 18:40:00 2996286              
5           2016/06/29 18:50:00 12472524             
6           2016/06/29 19:00:00 12472424             
7           2016/06/29 19:10:00 12471020             
8           2016/06/29 19:20:00 12471980             
9           2016/06/29 19:30:00 12471566             
10          2016/06/29 19:40:00 12471881             
11          2016/06/29 19:50:00 12472116             
12          2016/06/29 20:00:00 12472623             
------------------------------------------------------------------------
No. of license statistics entries: 14
========================================================================

Peak display example:

========================================================================
*A:Dut-A# show system license-statistics peak application nat     
========================================================================
peak license statistics for nat
========================================================================
                                      time                peak
------------------------------------------------------------------------
LSN subscribers                       2016/06/29 19:00:00 512
LSN bandwidth                         2016/06/29 20:00:00 12472623
------------------------------------------------------------------------
No. of license statistics entries: 2
========================================================================

NAT statistics output fields describes the NAT statistics output fields.

NAT on ESA offers two scaling profiles, each of them adapted to the amount of memory allocated to the VM.

• profile1

  A lower scaling profile that requires 8 CPU cores and 32 GB of DRAM memory per ESA-VM.

• profile2

  A medium scaling profile that requires 11 CPU cores and 96 GB of DRAM memory per ESA-VM.

• profile3

  A high scaling profile that requires 15 CPU cores and 115 GB of DRAM memory per ESA-VM.

The default scaling profile is profile1.

Contact your Nokia representative for more specific information about the NAT scaling figures in each profile.

Scaling profiles are configurable under the following CLI hierarchy:

Classic CLI

*A:cses-V22# configure isa
*A:cses-V22>config>isa# nat-group 1 create
*A:cses-V22>config>isa>nat-group# scaling-profile
  - scaling-profile <scaling-profile-id>
 <scaling-profile-id> : {profile1|profile2|profile3}

MD-CLI

*[pr:/configure isa nat-group 1]
A:admin@cses-V27# scaling-profile ?
 scaling-profile <keyword>
 <keyword>  - (profile1|profile2|profile3)
 Default    - profile1
    Scaling profile for the NAT group
    Warning: Modifying this element toggles
    'configure isa nat-group 1 admin-state' automatically for the new value to
    take effect.
    Warning: Modifying this element clears ISA state, such as flow state, for
    the new value to take effect.
*[pr:/configure isa nat-group 1]

A scaling profile can be changed using CLI only when all ESA-VMs in a NAT group are removed from the configuration.

For example, in the following case, transitioning from profile2 to profile1 is not possible until esa-vm 1/1 is removed from the CLI:

config
   isa
    nat-group 1
      esa-vm 1/1
        scaling-profile profile2
config>isa>nat-group# scaling-profile profile1
MINOR: BBGRPMGR #1052 Cannot change scale-profile with MDAs or ESA-VMs provisioned