7.2.1. Principles of NAT

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 will occur. 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 will use 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 will generally prevent new connections to be established from the outside to the inside as may occur when an inside host wishes to be a server.

7.2.2. Application Compatibility

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:

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 will 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 will give better long-term support without the cost or complexity associated with NAT.

7.3.1. Port Range Blocks

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. Rather than log 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, rather than 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. Once 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 will be 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.

7.3.2. Timeouts

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. Rather than wait 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 will become active, greatly reducing the number of UDP mappings.

7.3.3. Watermarks

It is possible to define watermarks to monitor the actual usage of sessions and/or ports.

For each watermark, a high and a low value has to be set. Once the high value is reached, a notification will be send. As soon as the usage drops below the low watermark, another notification will be send.

Watermarks can be defined on nat-group, pool and policy level.

7.5.1. Static 1:1 NAT

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:

Static mappings are configured according to the map statements. The map statement can be configured manually by the operator or automatically by the system. IP addresses from the automatically generated map statements are sequentially mapped into available outside IP address in the pool:

The following mappings apply to the example above:

7.5.2. ICMP

In 1:1 NAT, certain ICMP messages contain an additional IP header embedded in the ICMP header. For example, when the ICMP message is sent to the source due to 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:

7.6.1. Overview

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 will be no logging as long as the translations are in the domain of the deterministic NAT. Once the dynamic port block is allocated for port extension, logging will be 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 will be 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) will be guaranteed access to NAT resources.

7.6.2. Supported Deterministic NAT Types

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 will focus on the features specific to DS-Lite.

7.6.3. Number of Subscribers per Outside IP and per Pool

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) rather than an IP address range that would contain an arbitrary number of addresses (e.g. 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 will determine the maximum number of subscribers that a deterministic pool can support.

7.6.4. Referencing a Pool

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.

7.6.5. Outside Pool Configuration

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 Figure 57.

Figure 57:  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:

The follow show three examples with deterministic Large Scale NAT44 where the requirements are:

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

The example in Table 32 shows how port ranges would be carved out in ideal scenario.

* — Signifies the fixed parameters (requirements).

The other values are calculated according to the fixed requirements.

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

Next, 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.

* — Signifies the fixed parameters (requirements).

The final example is similar as Table 32 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 Table 32 is displayed:

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.

This configuration will allow 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 Figure 58.

Figure 58:  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:

7.6.6. Mapping Rules and the map Command in Deterministic LSN44

The common building block on the inside in the deterministic LSN44 configuration is a IPv4 prefix. The NAT subscribers (inside IPv4 addresses) from the configured prefix will be deterministically mapped to the outside IP addresses and corresponding deterministic port-blocks. Any inside prefix in any routing instance can be mapped to any pool in any routing instance (including the one in which the inside prefix is defined).

The mapping between the inside prefix and the deterministic pool is achieved through a NAT policy that can be referenced per each individual inside IPv4 prefix. IPv4 addresses from the prefixes on the inside will be distributed over the IP addresses defined in the outside pool referenced by the NAT policy.

The mapping itself is represented by the map command under the prefix hierarchy:

The purpose of the map statement is to split the number of subscribers within the configured prefix over available sequences of outside IP addresses. The key parameter that governs mappings between the inside IPv4 addresses and outside IPv4 addresses in deterministic LSN44 is defined by the outside>pool>subscriber-limit command. This parameter must be power of 2 and it limits the maximum number of NAT subscribers that can be mapped to the same outside IP address.

The follow are rules governing the configuration of the map statement:

In case that the number of subscribers (IP addresses in LSN44) in the map statement is larger than the subscriber-limit per outside IP, then the subscribers must be split over a block of consecutive outside IP addresses where the outside-ip-address in the map statement represent only the first outside IP address in that block.

The number of subscribers (range of inside IP addresses in LSN44) in the map statement does not have to be a power of 2. Rather it has to be a multiple of a power of two  m * 2^n, where m is the number of consecutive outside IP addresses to which the subscribers are mapped and the 2^n is the subscriber-limit per outside IP.

An example of the map statement is given below:

In this case, the configured 10.0.0.0/24 prefix is represented by the range of IP addresses in the map statement (10.0.0.0-10.0.0.255). Since the range of 256 IP addresses in the map statement cannot be mapped into a single outside IP address (subscriber-limit=128), this range must be further implicitly split within the system and mapped into multiple outside IP addresses. The implicit split will create two IP address ranges, each with 128 IP addresses (10.0.0.0/25 and 10.0.0.128/25) so that addresses from each IP range are mapped to one outside IP address. The hosts from the range 10.0.0.0-10.0.0.127 will be mapped to the first IP address in the pool (128.251.0.1) as explicitly stated in the map statement (to statement). The hosts from the second range, 10.0.0.128-10.0.0.255 will be implicitly mapped to the next consecutive IP address (128.251.0.2).

Alternatively, the map statement can be configured as:

In this case the IP address range in the map statement is split into two non-consecutive outside IP addresses. This gives the operator more freedom in configuring the mappings.

However, the following configuration is not supported:

Considering that the subscriber-limit = 128 (2^n; where n=7), the lower n bits of the start address in the second map statement (map start 10.0.0.64 end 10.0.0.127 to 192.168.0.3) are not 0. This is in violation of the rule #1 that governs the provisioning of the map statement.

Assuming that we use the same pool with 128 subscribers per outside IP address, the following scenario is also not supported (configured prefix in this example is different than in previous example):

Although the lower n bits in both map statements are 0, both statements are referencing the same outside IP (192.168.0.1). This is violating rule #2 that governs the provisioning of the map statement. Each of the prefixes in this case will have to be mapped to a different outside IP address, which will lead to underutilization of outside IP addresses (half of the deterministic port-blocks in each of the two outside IP addresses will be not be utilized).

In conclusion, considering that the number of subscribers per outside IP (subscriber-limit) must be 2^n, the inside IP addresses from the configured prefix will be split on the 2^n boundary so that every deterministic port-block of an outside IP is utilized. In case that the originally configured prefix contains less subscribers (IP addresses in LSN44) than an outside IP address can accommodate (2^n), all subscribers from such configured prefix will be mapped to a single outside IP. Since the outside IP cannot be shared with NAT subscribers from other prefixes, some of the deterministic port-blocks for this particular outside IP address are not utilized.

Each configured prefix can evaluate into multiple map commands. The number of map commands will depend on the length of the configured prefix, the subscriber-limit command and fragmentation of outside address-range within the pool with which the prefix is associated.

7.6.7. Hashing Considerations in Deterministic LSN44

Support for multiple MS-ISAs in the nat-group calls for traffic hashing on the inside in the ingress direction. This will ensure 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 will be chosen according to the pool with the highest number of subscribers per outside IP address. This will ensure that subscribers mapped to the same outside IP address will be always hashed to the same MS-ISA.

In general, load distribution based on hashing is dependent on the sample. Large and more diverse sample will ensure 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 given pool that is referenced from this inside routing instance.

Figure 59:  Deterministic LSN44 Configuration Example 

The configuration example shown Figure 59 depicts 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).

Note: In this example is the inside prefix 10.10.10.0/24 that is present in VPRN 1 and VPRN 2. In both VPRNs, this prefix is mapped to the same pool - pool-1 with the subscriber-limit of 64. Four outside IP addresses per prefix per VPRN (eight in total) are allocated to accommodate the mappings for all hosts in prefix 10.10.10.0/24. But the hashing prefix length in VPRN1 is based on the subscriber-limit 64 (VPRN1 references only pool-1) while the hashing prefix length in VPRN2 is based on the subscriber-limit 256 in pool-2 (VPRN2 references both pools, pool-1 and pool-2 and we must select the larger subscriber-limit). The consequence of this is that the traffic from subnet 10.10.10.0/24 in VPRN 1 can be load balanced over 4 MS-ISA (hashing prefix length is 26) while traffic from the subnet 10.10.10.0/24 in VPRN 2 is always sent to the same MS-ISA (hashing prefix length is 24).

7.6.8. Sharing of Deterministic NAT Pools

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

7.6.9. Simultaneous support of dynamic and deterministic NAT

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 given time.

Ingress hashing for all NATed traffic within the VRF will in this case be performed based on the subnets driven by the classic-lsn-max-subscriber-limit parameter.

7.6.10. Selecting Traffic for NAT

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:

7.6.11. Inverse Mappings

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.

7.6.12. Logging

Every configuration change concerning the deterministic pool will be logged and the script (if configured for export) will be 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 will be 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.

7.6.13. Deterministic DS-Lite

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

All incoming IPv6 traffic with source IPv6 addresses falling under a unique v6 prefix that is configured with subscriber-prefix-length command will be considered as a single subscriber. As a result, all source IPv4 addresses carried within that IPv6 prefix will be 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:

Example:

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:

7.7.1. Combination of SNAPT and DNAT

In certain cases SNAPT is required along with DNAT. In other cases only DNAT is required without SNAPT. The following table shows the supported combinations of SNAPT and DNAT in SR OS.

The SNAPT/DNAT address translations are shown in Figure 60.

Figure 60:  IP Address/Port Translation Modes 

7.7.2. Forwarding Model in DNAT

NAT forwarding in SR OS is implemented in two stages:

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

7.7.3. DNAT Traffic Selection via NAT Classifier

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 whether:

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

7.7.4. Configuring DNAT

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

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 in order 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.

7.7.4.2. Micro-Netting Original Source (Inside) IP Space in DNAT-Only Case

In order to forward upstream and downstream traffic for the same NAT binding to the same MS-ISA, the original source IP address space must be known in advance and consequently hashed on the inside ingress towards the MS-ISAs and micro-netted on the outside.This will be performed with the following CLI:

router | service vprn <id>

nat

inside

classic-lsn-max-subscriber-limit <max> 

dnat-only

source-prefix <nat-prefix-list-name>

 

service nat

nat-prefix-list <name> application dnat-only-subscribers create

prefix <ip-prefix>

The classic-lsn-max-subscriber-limit parameter was introduced by deterministic NAT and it is reused here. This parameter affects the distribution of the traffic across multiple MS-ISA in the upstream direction traffic. Hashing mechanism based on source IPv4 addresses/prefixes is used to distribute incoming traffic on the inside (private side) across the MS-ISAs. Hashing based on the entire IPv4 address will produce the most granular traffic distribution, while hashing based on the IPv4 prefix (determined by prefix length) will produce less granular hashing. For further details about this command, consult the CLI command description. The source IP prefix is defined in the nat-prefix-list and then applied under the DNAT-only node in the inside routing context. This will instruct the SR OS to create micro-nets in the outside routing context. The number of routes installed in this fashion is limited by the following configuration:

router | service vprn <id>

nat

outside

dnat-only

route-limit <route-limit>

The configurable range is 1-128K with the default value of 32K.DNAT provisioning concept is shown in Figure 61.

Figure 61:  DNAT Provisioning Model 

7.8.1. Restrictions

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

7.8.2. Multiple NAT Policies Per Inside Routing Context

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:

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

Figure 62:  Pool Selection Based on Traffic Destination 

Diversion of the traffic to NAT based on the source of the traffic is shown in Figure 63.

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

Figure 63:  NAT Pool Selection Based on the Inside Source IP Address 

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

7.8.3. Routing Approach for NAT Diversion

The routing approach relies on upstream traffic being directed (or diverted) to the NAT function based on the destination-prefix command in the configure>service>vprn/router>nat>inside CLI context. In other words, the upstream traffic will be NATed 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 will divert all traffic with the destination IP address that matches the created entry, towards the MS-ISA. The NAT function itself will be performed once the traffic is in the proper context in the MS-ISA.

The CLI for multiple NAT policies per inside routing context with routing based diversion to NAT is the following:

or, for example:

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 will be used. The default NAT policy is configured directly in the vprn/router>nat>inside context.

Once that destination-prefix command referencing the NAT policy is configured, an entry in the routing table will be created that will direct the traffic to the MS-ISA.

7.8.4. Filter-Based Approach

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

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

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

7.8.5. Multiple NAT Policies with DS-Lite and NAT64

DS-Lite and NAT64 diversion to NAT with multiple nat-policies is supported only through IPv6 filters:

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 desired 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 will follow normal IPv6 routing path within the 7750 SR.

7.8.6. Default NAT Policy

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 desired 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 will 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.

7.8.7. Scaling Considerations

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

7.8.8. Multiple NAT Policies and SPF Configuration Considerations

Any given 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 request will be submitted either via SAM or via CLI:

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 will be 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, since 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:

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

7.8.8.1. Multiple NAT Policies and Forwarding Considerations

Figure 64 and Figure 65 describe certain scenarios that are more theoretical and are less likely to occur in reality. However, they are described here for the purpose of completeness.

Figure 64 represents the case where traffic from the WEB server 10.1.1.1 is initiated toward the destined network 10.11.0.0/8. Such traffic will end up translated in the Pool B and forwarded to the 10.11.0.0/8 network even though the static port forward has been created in Pool A. In this case the NAT policy rule (dest 10.11.0.0/8 pool B) will determine the pool selection in the upstream direction (even though the SPF for the WEB server already exists in the Pool A).

Figure 64:  SPF With Multiple NAT Policies 

The next example in Figure 65 shows a case where the Flow 1 is initiated from the outside. Since the partial mapping matching this flow already exist (created by SPF) and there is no more specific match (FQF) present, the downstream traffic will be mapped according to the SPF (through Pool A to the Web server). At the same time, a more specific entry (FQF) will be created (initiated by the very same outside traffic). This FQF will now determine the forwarding path for all traffic originating from the inside that is matching this flow. This means that the Flow 2 (reverse of the Flow 1) will not be mapped to an IP address from the pool B (as the policy dictates) but instead to the Pool A which has a more specific match.

A more specific match would be in this case fully qualified flows (FQF) that contains information about the foreign host: <host, inside IP/port, outside IP/port, foreign IP address/port, protocol>.

Figure 65:  Bypassing NAT Policy Rule  

7.8.9. Logging

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

where XX is an arbitrary unique number per inside routing context assigned by the router. This number, represents the corresponding NAT policy. Since 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 — 8.

Introduction of the policy-id in logs is necessary due to 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 will not trigger a summarization log since an acct-off message is sent. Such operations have a tendency to be heavy on NAT logging since they affect a large number of NAT subscribers at once. 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 srvc-id. Since 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 since 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:

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.

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

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.

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 will have 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.

7.9.1. Logging

In L2-Aware NAT with multiple nat-policies, the NAT resources are allocated in each pool associated with the subscriber. This NAT resource allocation is performed at the time when the ESM subscriber is instantiated. Each NAT resource allocation will be followed by log generation.

For example, if RADIUS logging is enabled, one Alc-NAT-Port-Range VSA per NAT policy will be included in the acct START/STOP message.

[Alc-Nat-Port-Range = "192.168.20.1 1024-1055 router base nat-pol-1"

Alc-Nat-Port-Range = "193.168.20.1 1024-1055 router base nat-pol-2".

Alc-Nat-Port-Range = "194.168.20.1 1024-1055 router base" nat-pol-3.]

7.9.2. Static Port Forwards

Unless the specific NAT policy is provided during Static Port Forward (SPF) creation (SPF creation command), the port forward will be created in the pool referenced in the default NAT policy. Nat-policy can be part of the command used to modify or delete SPF. If the NAT policy is not provided, then the behavior will be:

A match is considered when at least these parameters from the modify or delete command are matched (mandatory parameters in the spf command):

For a Layer 2-Aware NAT, an alternative AAA interface can be used to specify SPF. An alternative AAA interface and CLI-based port forwards are mutually exclusive. Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for more details.

7.9.3. L2-Aware Ping

Similar to the non-L2-Aware ping command, understanding how the ICMP Echo Request packets are sourced in L2-Aware ping is crucial for the proper execution of this command and the interpretation of its results. The ICMP Echo Reply packets must be able to reach the source IP address that was used in ICMP Echo Request packets on the SR OS node on which the L2-Aware ping command was executed. See Figure 66.

The return packet (the ICMP Echo reply sent by the targeted host) is subject to L2- Aware NAT routing executed in the MS-ISA. The L2-Aware NAT routing process looks at the destination IP address of the upstream packet and then directs the packet to the correct outside routing context. The result of this lookup is a NAT policy that references the NAT pool in an outside routing context. This outside routing context must be the same as the one from which the L2-Aware ping command was sourced. Otherwise, the L2-Aware ping command fails.

The L2-Aware ping command can be run in two modes:

Figure 66 shows the traffic flow for an L2-Aware ping command targeting the subscriber’s IP address 10.2.3.4, sourced from the Base routing context using an arbitrary source IP address of 10.6.7.8 (it is not required that this IP address belong to the L2-Aware ping originating node).

When the host 10.2.3.4 replies, the incoming packets with the destination IP address of 10.6.7.8 are matched against the destination-prefix 10.6.7.0/24 referencing the nat-policy-1. nat-policy-1 contains the Pool B which resides in the Base routing context. Hence, the loop is closed and the execution of the L2-Aware ping command is successful.

Figure 66:  L2-Aware Ping 

L2-Aware ping is always sourced from the outside routing context, never from the inside routing context. If the router is not specifically configured as an option in the L2-Aware ping command, the Base routing context is selected by default. If that the Base routing context is not one of the outside routing contexts for the subscriber, the L2-Aware ping command execution fails with the following error message:

“MINOR: OAM #2160 router ID is not an outside router for this subscriber.”

7.9.4. UPnP

UPnP will use the default NAT policy.

7.10.1. CoA and NAT Policies

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

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

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

7.10.2. CoA and DNAT

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 Table 37.In L2-Aware NAT, CoA can be used to:

Once 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 → is mutually exclusive with the DNAT-ip-addr parameter.

DNAT-ip-addr = Provides an implicit enable with the destination IPv4 address in dotted format (a.b.c.d) → is mutually exclusive with DNAT-state parameter.

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 will negate any previous DNAT related override in the default nat-policy. Consequently, the DNAT functionality will be 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 will be sent back to the originator.

Alc-DNAT-Override =none,nat-pol-1 → This will re-enable 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 will be 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 will change the default DNAT IP address to 1.1.1.1 in the default NAT policy. In case DNAT was disabled prior to receiving this CoA, it will be implicitly enabled.

Alc-DNAT-Override =10.1.1.1,nat-pol-1 → This will change the default DNAT IP address to 10.1.1.1 in the specific NAT policy named nat-policy-1. DNAT will be implicitly enabled if it was disabled prior to receiving this CoA.

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

If multiple Alc-DNAT-Override attributes with conflicting actions are received in the same CoA or Access-Accept, the action that occurred last will take 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 will be disabled in the default NAT policy:

Alc-DNAT-Override = “10.1.1.1“

Alc-DNAT-Override = “disable“

7.10.3. Modifying an Active NAT Prefix List or Nat Classifier via CLI

The following table describes the outcome when the active NAT prefix list or NATclassifier is modified via CLI.

7.12.1. Configuring UPnP IGD Service

7.13.1. PPTP Protocol

There are two components of PPTP:

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.

7.13.2. PPTP ALG Operation

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 in order 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:

In addition, the following applies:

The basic principle of PPTP NAT ALG is shown in Figure 67.

Figure 67:  NAT PPTP Operation 

The scenario where multiple clients behind the NAT are terminated to the same PPTP server is shown in Figure 68. 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. Since the endpoints of the GRE tunnel from the NAT to the PPTP server will be 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.

Figure 68:  Merging of Endpoints in NAT 

7.13.3. Multiple Sessions Initiated From the Same PPTP Client Node

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.

7.13.4. Selection of Call IDs in NAT

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

7.15.1. Syslog/SNMP/Local-File Logging

The simplest form of LSN and L2-Aware NAT logging is via logging facility in the 7750 SR, commonly called logger. Each port-block allocation/de-allocation event will be recorded and send to the system logging facility (logger). Such an event can be:

In this mode of logging, all applications in the system share the same logger.

Syslog/SNMP/Local-File logging on LSN is mutually exclusive with NAT RADIUS-based logging.

Syslog/SNMP/local-file logging must be separately enabled for LSN and L2-Aware NAT in log even-control. The following displays relevant MIB events:

7.15.1.2. NAT Logging to a Local File

In this case, the destination of log-id 5 in the following example would be a local file instead of memory:

*A:left-a20>config>log# info  

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

        file-id 5  

            description "nat logging" 

            location cf1:  

            rollover 15 retention 12  

        exit  

         

        log-id 5  

            filter 1  

            from main  

            to file 5 

        exit  

The events will be logged to a local file on the compact flash cf1 in a file under the /log directory.

Note: Logging to the compact flash (CF) represents a single point of failure. Performance (logs per second) of logging onto the CF is limited in comparison to other logging methods (RADIUS, Syslog, and IPFIX). Failure to generate logs due to failed a CF or performance limitation will result in dropped NAT traffic. For this reason, local NAT logging in the SR OS is recommended only in a lab environment.

7.15.2. SNMP Trap Logging

In case of SNMP logging to a remote node, the log destination should be set to SNMP destination. Allocation de-allocation of each port block will trigger sending a SNMP trap message to the trap destination.

 

7.15.3. NAT Syslog

NAT logs can be sent to a syslog remote facility. A separate syslog message is generated for every port-block allocation/de-allocation.

 

Severity level for this event can be changed via CLI:

7.15.4. LSN RADIUS Logging

LSN RADIUS logging (or accounting) is based on RADIUS accounting messages as defined in RFC 2866. It requires an operator to have RADIUS accounting infrastructure in place. For that reason, LSN RADIUS logging and LSN RADIUS accounting terms can be used interchangeably.

This mode of logging operation is introduced so that the shared logging infrastructure in 7750  SR can be offloaded by disabling syslog/SNMP/Local-file LSN logging. The result is increased performance and higher scale, particularly in cases when multiple BB-ISA cards within the same system are deployed to perform aggregated LSN functions.

An additional benefit of LSN RADIUS logging over syslog/SNMP/local-file logging is reliable transport. Although RADIUS accounting relies on unreliable UDP transport, each accounting message from the RADIUS client must be acknowledged on the application level by the receiving end (accounting server).

Each port-block allocation or de-allocation is reported to an external accounting (logging) server in the form of start, interim-update or stop messages. The type of accounting messages generated depends on the mode of operation:

The accounting messages are generated and reported directly from the BB-ISA card, therefore bypassing accounting infrastructure residing on the Control Plane Module (CPM).

LSN RADIUS logging is enabled per nat-group. To achieve the required scale, each BB-ISA card in the nat-group group with LSN RADIUS logging enabled runs a RADIUS client with its own unique source IP address. Accounting messages can be distributed to up to five accounting servers that can be accessed in round-robin fashion. Alternatively, in direct access mode, only one accounting server in the list is used. When this server fails, the next one in the list is used.

Configuration steps:

Each BB-ISA card is assigned one unique IPv4 address from the source-address-range command and this IPv4 address must be accessible from the accounting server.

The IP addresses are consecutively assigned to each BB-ISA, starting from the IP address configured by this command. The number of IP addresses allocated internally by the system corresponds to the number of BB-ISAs in the system.

Each BB-ISA is provisioned automatically with the first free IP address available, starting from the IP address that is configured in the source-address-range command. Once a BB-ISA is removed from the system (or NAT group), it releases that IP address to be available to the next BB-ISA that comes online within the NAT group.

It is important to be mindful of the internally-allocated IP addresses, since they are not explicitly configured in the system (other than the first IP address in the source-address-range command). However, those internally-assigned IP addresses can be seen using show commands in the routing table.

In the following example there is only one BB-ISA card in the nat-group 1. It source IP address is 192.168.1.20.

It is possible to load-balance accounting messages over multiple logging servers by configuring the access-algorithm to round-robin mode. Once the LSN RADIUS accounting policy is defined, it will have to be applied to a nat-group:

The RADIUS accounting messages for the case where a Large Scale NAT44 subscriber has allocated two port blocks in a logging mode where acct start/stop is generated per port-block is shown below.

Port-blocks allocation for the NAT44 subscriber:

Port-blocks de-allocation

The inclusion of acct-multi-session-id in the NAT accounting policy will enable generation of start/stop messages for each allocation/de-allocation of a port-block within the subscriber. Otherwise, only the first and last port-block for the subscriber would generate a pair of start/stop messages. All port-block in between would trigger generation of interim-update messages.

The User-Name attribute in accounting messages is set to app-name@inside-ip-address, whereas the app-name can be any of the following: LSN44, DS-Lite or NAT64.

7.15.5. LSN and L2-Aware NAT Flow Logging

LSN and L2-aware NAT flow logging allows each BB-ISA card to export the creation and deletion of NAT flows to an external server. A NAT flow, or a Fully Qualified Flow, consists of the following parameters: inside IP, inside port, outside IP, outside port, foreign IP, foreign port, and protocol (UDP, TCP, ICMP).

The foreign IP address is the original IPv4 destination address as received by NAT on the inside. The destination IP address is the translated foreign IP address if that destination NAT is active (the destination NAT translates the destination IPv4 address of the packet).

Additional information, such as the inside or outside service ID and subscriber string, can be added to a flow record.

Flow logging can be deployed as an alternative to port-range logging or can be complementary (providing a more granular log for offline reporting or compliance). Certain operators have legal and compliance requirements that require extremely detailed logs, created per flow, to be exportable from the NAT node.

Because the setup rate of new flows is excessive, logging to an internal facility (like compact flash) is not possible except in debugging mode (which must specify match criteria down to the inside IP and service level).

Flow logging can be enabled on a per-NAT policy basis and, consequently, it is initiated from each BB-ISA card. The flow records can be exported to an external collector in an IPFIX format or a syslog format, both of which use UDP as the transport protocol. These UDP streams are stateless due to the significant volume of transactions. However they do contain sequence numbers so packet loss can be identified. They egress the chassis at the fc nc.

IPFIX and SYSLOG flow logging are configured using respective flow logging policies (such as ipfix-export-policy and syslog-export-policy). Each flow logging policy supports two destinations (collectors). One ipfix-export-policy and one syslog-export-policy can be used simultaneously in any one NAT group.

7.15.5.4. Configuration Example

Large Scale NAT44 Flow Logging with Format2:

1. A collector node along with other local transport parameters must be defined through an IPFIX export policy.
    

   *A:BNG1>config>service>ipfix# info detail 

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

               ipfix-export-policy "flow-logging" create

                   no description

                   template-format format2

                   collector router "Base" ip 192.168.115.1 create

                       mtu 1500

                       source-address 192.0.2.2

                       template-refresh-timeout min 5 

                       no shutdown

                   exit

               exit
   To export flow records using UDP stream, the BB-ISA card must be configured with an appropriate IPv4 address within a designated VPRN. This address (/32) acts as the source for sending all IPFIX records and is shared by all ISA.
2. Once the IPFIX export policy is defined, it must be applied within the NAT policy:
   *A:BNG1>config>service>nat#     info 

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

               nat-policy "mnp" create

                   pool "mnp" router Base

                   ipfix-export-policy "flow-logging"

               exit

Flow creation and flow deletion templates for format2, as captured in Wireshark, are shown in Figure 69.

Figure 69:  Format2 Templates 

IPFIX flow creation data set, as captured in Wireshark, is shown in Figure 70.

Figure 70:  Flow Creation Data Set 

IPFIX flow destruction data set, as captured in Wireshark, is shown in Figure 71.

Figure 71:  Flow Destruction 

7.16.1. Overview

In general, fragmentation functionality is invoked when the size of a fragmentation eligible packet exceeds the size of the MTU of the egress interface/tunnel. Packets eligible for fragmentation are:

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

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:

In upstream direction, IPv4 packets can be fragmented once they are decapsulated in DS-lite or translated in NAT64. The fragmentation will occur in the IOM.

7.16.2. IPv6 Fragmentation in DS-Lite

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 will be 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 + 8 bytes for extended IPv6 fragmentation header. NAT implementation in the routers does not insert any extension IPv6 headers other than fragmentation header.

Figure 72:  DS-Lite 

In case that the IPv4 packet is larger than the value set by the tunnel-mtu, the fragmentation action will depend on the configuration options and the DF bit setting in the header of the received IPv4 header:

In case that the IPv4 packet is dropped due to fragmentation not being allowed, an ICMPv4 Datagram Too Big message will be returned to the source. This message will carry the information about the size of the MTU that is supported, in essence 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 1280bytes, 8 fragments is enough to cover jumbo Ethernet frames.

7.16.3. NAT64

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/v6 headers are translated. Consequently, the fragmented IPv6 packet size will be 28bytes larger than the translated IPv4 packet  20bytes difference in basic IP header sizes (40bytes IPv6 header vs 20byte IPv4 header) plus 8 bytes for extended fragmentation IPv6 header. The only extended IPv6 header that NAT64 generates is the fragmentation header.

In case that the IPv4 packet is dropped due to the fragmentation not being allowed, the returned ICMP message will contain MTU size of ipv6-mtu minus 28 bytes.

Otherwise the fragmentation options are the same as in DS-lite.

7.17.1. Interpreting Fragmentation Statistics

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.

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) due to its original size being larger than the MTU configured on any node servicing this packet

Fragment – 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 whole 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 – Identified by 5 tuple <src IP, dst IP, src Port, dst Port, protocol>. Flow can have many packets and each packet of a flow can be fragmented.

7.18.1. Configuration

The output of this command displays the port usage in a given pool per protocol per subscriber. The output is organized in a configurable number of port-buckets.

In the following example there is 1 subscriber that is using between 20 and 39 UDP ports in the pool named det. The pool is configured in the Base routing instance.

7.19.1. NAT Stateless Dual-Homing

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 (NATed traffic within this inside routing context will be 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 since some pools referenced from the routing instance might be active on one node while other pools might 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):

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. Once the traffic arrives to the NAT node, it will be 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 to 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 Figure 73.

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 will ensure that the inside traffic will be always mapped to pools that are active in a single box.

Figure 75:  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 will switch the activity, or in another words they will 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 will have 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.

7.19.1.1. Configuration Considerations

Attracting traffic to the active NAT node (from inside and outside) is based on the routing.

On the outside, the active pool address range will be advertised. On the inside, the destination prefix or steering route (in case of filter based diversion to the NAT function) will be advertised by the node with the active pool.

The advertisement of the routes will be driven by the activity of the pools in the pool fate sharing group:

configure

   router/service vprn

      nat

         outside

            pool <name>

               redundancy                  

                  export <ip-prefix/length>

                  monitor <ip-prefix/length>[no] shutdown

                  follow router  <rtr-id> pool <master-pool>

 

For example:

router/service vprn

    nat

        outside

          pool "nat0-pool" nat-group 1 type large-scale create 

             port-reservation ports 252 

            redundancy

               follow router 500 pool "nat500-pool"

            exit

           address-range 192.168.12.0 192.168.12.10 create

           exit

            no shutdown

          exit

       exit

     exit

 

A pool can be one of the following:

1. A leading pool: configure export- and monitor-route and put in no shutdown
2. A following pool: configure follow

Both sets of options are thus mutually exclusive.

For a leading pool redundancy will only be enabled when the redundancy node is in no shutdown. For a following pool, the administrate has no effect, and the redundancy will only be enabled when the leading pool is enabled.

Before a lead pool is enabled, consistency check will be performed to make sure that PFSG is properly configured and that the all pools in the given PFSG belong to the same NAT isa-group. PFSG is implicitly enabled by configuring multiple pools to follow the same lead pool. Adding or removing pools from the fate-share-group is only possible when the leading pool is disabled.

For example in the following case, the consistency check would fail since pool 1 is not part of the PFSG 1 (where it should be).

Figure 76:  Consistency Check 

7.19.2. Active-Active ISA Redundancy Model

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 will be downloaded by the CPM to the remaining active ISAs. Memory resources on each ISA will be reserved in order to accommodate additional traffic from the failed ISAs. The amount of resources reserved per ISA will depend 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 will affect NAT scale per ISA.

Traffic received on the inside will be 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 will, among 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 Figure 77. 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 will carry traffic during normal operation, while the fourth one will have resources reserved to accommodate traffic from one of the members in case of failure. When an ISA failure occurs, three members will be delegated to the remaining ISAs. Each member from the failed ISA will be mapped to a corresponding reserved member on the remaining ISAs.

Figure 77:  Load Distribution in Active-Active Intra-Chassis Redundancy Model 

Active-active ISA redundancy model supports multiple failures simultaneously. The protection mechanism shown in Figure 78 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.

Figure 78:  Multiple Failures 

Table 47shows resource utilization for a single ISA failure in relation to the total number of ISAs in the system. The resource utilization will affect only scale of each ISA. However, bandwidth per ISA is not reserved and each ISA can operate at full speed at any given time (with or without failures).

7.19.3. L2-Aware Bypass

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 NATed in accordance to the routing table in the inside routing context. The intent is that non-NATed 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 NATed by a central NAT node. The central NAT node provides redundancy for multiple SR OS nodes, thus 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 Figure 79. 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 other two MS-ISA redundancy modes (active/active and active/standby).

L2-Aware bypass is enabled with the following CLI:

Figure 79:  L2-Aware Bypass  

7.20.1. MS-ISA Use with Service Mirrors

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.

7.20.2. LNS, Application Assurance and NAT

Multiple uses of MS-ISAs can be combined at one time by daisy-chaining use of the MS-ISAs. Services and subscribers terminated on the LNS ISA are full supported by Application Assurance per AA subscriber and service capabilities, and by the full NAT capabilities.

When Application Assurance and NAT are used in combination (for both ESM and SAP service contexts):

7.20.3. Subscriber Aware Large Scale NAT44

Subscriber aware Large Scale NAT44 attempts to combine the positive attributes of Large Scale NAT44 and L2-Aware NAT, namely:

Subscriber awareness in Large Scale NAT44 will facilitate 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 will simplify 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’ via RADIUS accounting proxy which creates a cache of attributes from the BNG subscriber. BNG subscribers are correlated with the NAT subscriber via framed-ip address, and one of the following attributes that must be present in the accounting messages generated by BNG:

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

Large Scale NAT44 Subscriber Aware application will receive a number of cached attributes which will then be used for appropriate management of Large Scale NAT44 subscribers, for example:

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 such opaque attributes will be accepted. The remaining attributes will be truncated.

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

Configuration guidelines:

Configure RADIUS accounting proxy functionality in a routing instance that will receive 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 will receive 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 will be used to correlate BNG subscriber with the Large Scale NAT44 subscriber.

Optionally enable NAT RADIUS accounting that will include BNG subscriber relevant data.

(1)

RADIUS accounting proxy will listen to accounting messages on interface ‘rad-proxy-loopback’.

The name ‘proxy-acct’ as defined by the server command will be 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’.

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.

(2)

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

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

(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:

(4)

Optionally RADIUS NAT accounting can be enabled:

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

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

7.21.1. MAP-T Rules

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:

7.21.2. A+P Mapping Algorithm

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 given 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. Figure 81 shows the A+P mapping algorithm.

Figure 81:  A+P Mapping 

7.21.3. Routing Considerations

Figure 82 shows a MAP-T deployment scenario.

Figure 82:  MAP-T Deployment Scenario 

The routes related to MAP-T are:

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.

Note: IPv6 IA-PD end-user prefixes are carved out of the IPv6 rule prefix. Aside from MAP-T, IA-PD is used for native IPv6 end-to-end traffic outside of MAP-T. Although the IPv6 rule prefix is not marked as a NAT route in the routing table, it is nonetheless advertised in the upstream direction.

7.21.4. Forwarding Considerations in the BR

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:

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.

7.21.4.1. IPv6 Addresses

An IPv6 address of the MAP-T node is constructed according to RFC 7597, §5.2 and RFC 7599, §6. Figure 83 shows the IPv6 address of the MAP-T node.

Figure 83:  IPv6 Address Construction 

The subnet ID for a MAP node (CE) is set to 0. Figure 84 shows the node interface (PSID is left-padded with zeros to create a 16-bit field and the IPv4 address is the public IPv4 address assigned to the CE).

Figure 84:  Node Interface 

This constructed IPv6 address represents the source IPv6 address of traffic sent from the CE to BR (upstream direction), and the destination IPv6 address in the opposite direction (downstream traffic sent from the BR to the CE).

The source IPv6 address in the downstream direction is a combination of the BR IPv6 prefix and the source IPv4 address (per RFC 7599, §5.1) received in the original packet.

The destination IPv6 address in the upstream direction is a combination of the BR IPv6 prefix and the IPv4 destination address (RFC 7599, §5.1) in the original packet.

7.21.4.4. Rule Prefix Overlap

Rule prefix overlap is not supported because it can cause lookup ambiguity. Figure 85 shows a rule prefix overlap example.

Figure 85:  IPv6 Rule Prefix Overlap 

In the case where rule IPv6 prefix 1 is a subset of rule IPv6 prefix 2, the overlapping bits between the EA-bits in end user prefix 2 and the overlapping bits in rule prefix 1 (represented by the shaded sections in Figure 85) could render end-user prefixes 1 and 2 indistinguishable (everything else being the same) when anti-spoof lookup is performed in the upstream direction. This could result in an incorrect anti-spoofing lookup.

A similar logic can be applied to overlapping IPv4 prefixes in the downstream direction, where the longest prefix match will always lead to the same CE, while the shortest match (leading to a different CE) will not be evaluated.

7.21.5. BMR Rules Implementation Example

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

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:

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 will be calculated as follows:

4000 - 64 = 4032 ports

The IPv6 rule prefix is the next parameter in the MAP rule. Figure 86 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.

Figure 86:  Determining the Rule IPv6 Prefix 

The following three rules are created in this example:

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 7.21.4.4 for more information. Non-overlapping IPv6 rule prefixes ensure that each CE is assigned a unique IA-PD. Table 48 describes the rules.

The final step is to ensure that the DHCPv6 server hands out proper 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.

Note: The VSR-BR supports only IPv6 rule prefixes of the same length within a given domain. To accommodate a different prefix length assignment for IA-PD (for example /56), create another domain with a different IPv6 rule prefix (/44 instead of /48).

7.21.6. ICMP

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

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

7.21.7. Fragmentation

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 will be fragmented so that the size of the translated IPv6 packet is within IPv6 MTU. IPv6 packets will never be 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.

7.21.7.1. Fragmentation in the Downstream Direction

All fragments of the same IPv4 packet are translated and sent towards the same CE. As the second and consecutive fragments do not contain any port information, the translation is performed based on the <SA, DA, Prot, Ident> cached flow records extracted from the IPv4 header.

Note that the VSR may further fragment an IPv4 fragment that it has received in order to fit it within the IPv6 MTU.

Figure 87 shows downstream fragmentation scenarios.

Figure 87:  Fragmentation in the Downstream Direction 

7.21.7.2. Fragmentation in the Upstream Direction

In the upstream direction, the received IPv6 fragments are artifacts of the IPv4 packets being fragmented on the CP side, before they are translated into IPv6. No flow caching is performed in the upstream direction. The BR performs an anti-spoof for each fragment and if the anti-spoof is successful, the fragment is translated to IPv4. Figure 88 shows the upstream fragmentation scenario.

Figure 88:  Fragmentation in the Upstream Direction 

7.21.8. Maximum Segment Size (MSS) Adjust

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.

7.21.9. Statistics Collection

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

7.21.10. Logging

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:

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

Example:

7.21.11. Licensing

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:

7.21.12. Configuration

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

MAP-T Domain Instantiation

MAP Domain Example Template

The following example shows the MAP domain template for the BMRs defined BMR Rules Implementation Example.

MAP-T Domain Instantiation Example

The following example shows the MAP-T domain instantiation for the BMRs defined in BMR Rules Implementation Example.

7.21.13. Inter-Chassis Redundancy

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