Introduction

Cisco's CGv6 (Carrier Grade IPv6) solution helps customer transitioning from IPv4 to IPv6 gradually, maintaining business continuity. VSM (Virtualized Services Module) on ASR9K is a Service Card which provides different CGv6 Applications. This is the next generation Service Card after ISM (Integrated Services Module). This document talks about how to deploy NAT44 (Network Address Translation - from IPv4 to IPv4), one of the applications fall under CGv6 suite of applications.

This document does NOT intend to cover details on VSM, how to install CGv6 software on VSM, how to trouble-shoot CGv6 issues, CGv6 Applications other than NAT44.

DISCLAIMER: This document contains some Public IP addresses to explain different deployment use-cases and features related to NAT44. The Public IP addresses are picked up randomly and matching of these addresses with any specific customer's or organization's public IP is purely coincidental. Please DO NOT use these public addresses in your NAT setup / deployment, unless the public IP addresses are not owned by you / your organization. Cisco is not responsible for any issues arising out of this.

Introduction to NAT44

1. Why NAT44 ?

IPv4 address is 32-bit long which means there can be 4,294,967,296 (i.e., 4 billions) unique addresses. However, population on earth has crossed 7 billions and is still growing. Also, nowadays, a single person can own multiple IP devices, each having its own IP address. Thus, we are running short of IPv4 addresses. In 2 of the 5 RIR (Regional Internet Registries), IPv4 address exhaustion is declared (in its last /8 stage).

Apat from moving to IPv6 (which uses 128-bit long IP address), an alternate mechanism is to use NAT44 where Private IP addresses can be re-used in different Private networks, but can be translated to a unique Public IP address when the packet enters Internet or Public network.

If you are a Service Provider and running short of Public IP addresses, NAT44 should be of great usefulness to you as an intermediate solution before you slowly convert your IPv4 network into IPv6.

2. NAT44 Overview

NAT44 literally means translating one IPv4 address to another IPv4 address. "Typically", first IPv4 address is "Private" IPv4 Address (defined by RFC 1918) and second IPv4 address is "Public" (non-Private) IPv4 address. As defined by RFC 1918, Private IPv4 addresses fall in the following blocks.

Start IP Address

End IP Address

Comments

10.0.0.0

10.255.255.255

10.0.0.0/8 prefix - contains 16,777,216 addresses

172.16.0.0

172.31.255.255

172.16.0.0/12 prefix - contains 1,048,576 addresses

192.168.0.0

192.168.255.255

192.168.0.0/16 prefix - contains 65,536 address

However, it is to be noted that not always "Private" IPv4 address is to be translated to "Public" IPv4 address. There are deployment cases where NAT44 is used to convert "Private" IPv4 address (say, 192.168.x.x range) to another "Private" IPv4 address (say, 10.x.x.x range) as well.

NOTE: In this document, however, we will refer "Private" side as the pre-NAT side of the NAT device and "Public" side as the post-NAT side of the NAT device, irrespective of the actual IP address being used.

One more important point, although NAT indicates Network Address Translation, it is actually NAPT (Network Address and Port Translation). What it means is - in addition to IPv4 address, Layer 4 (UDP/TCP) port is also translated by NAT44.

NOTE: Unless mentioned otherwise, in this document, NAT44 will indicate translation of both IPv4 address and Port.

Following Layer 4 Protocols are supported by NAT44 implementation on VSM.

Another useful property of NAT44 is multiple Private IP addresses can be mapped to one Public IP address. This is possible as all of the 65,536 ports (0 to 65,535) on any Private IP address are typically not used by Applications.

Following diagram shows how NAT44 works.

As shown above, the Private IP addresses 192.168.1.1 and 192.168.1.5 are translated to same Public IP address 20.1.1.1 (along with specific Layer 4 ports) by the NAT44 device (VSM on ASR9K). The translation entries are maintained in NAT DB at the NAT44 device.

3. Basic Terminologies

In this section, let us get introduced with different terminologies related to NAT44 deployment on VSM.

Terminology

Definition / What it means

Inside / Subscriber Side / Access Side / Private Side

Private side of the NAT44 device (which usually contains Private IPv4 addresses)

Outside / Network Side / Core Side

Public side of the NAT44 device (which usually contains Public IPv4 addresses)

Inside-to-Outside (I2O)

Traffic flowing from Inside to Outside across NAT44 device

Outside-to-Inside (O2I)

Traffic flowing from Outside to Inside across NAT44 device

Stateful (SF)

Which preserves State or Database. E.g. - NAT44 is Stateful protocol.

Endpoint Independent Filtering (EIF)

Any device (IP + Port) can send O2I traffic to a Public IP + Port which exists in NAT DB. VSM implements this behavior. It is also termed as "Full-Cone NAT".

Endpoint Dependent Filtering (EDF)

Only the device (IP + Port) which has received I2O traffic can send O2I traffic to a public IP + Port which exists in NAT DB. Destination IP and port information is also maintained in NAT DB in this case. VSM implements this behavior (Address-Dependent as well as Address and Port-Dependent)

Port Parity Preservation

Odd port should be translated to Odd port and Even port should be translated to Even port. VSM supports this.

Basic Deployment Scenario: NAT444

5. Network Diagram

Following diagram depicts NAT444.

In the above diagram, there are 2 NAT44 instances shown (hence, it is termed as "Dual NAT44" or "NAT444").

CPE (Customer Premise Equipment) NAT44 - This typically happens within customer premise. Each customer / end user is given one (or, more) IPv4 address (10.8.1.11 in the above example) by the Service Provider. There could be multiple devices within customer premise which will have IPv4 addresses in 192.168.1.x network (as shown in the above diagram). As an example, CPE NAT44 device translates IPv4 address/Port of 192.168.1.1:4128 to 10.8.1.11:6593, while sending the packet out to provider network. A NAT table is maintained at CPE NAT level as well. But, the scale of this is less (as there won't be too many end devices). As you can see, both Private-side and Public-side IP addresses used here are from RFC 1918 (i.e., Private IPv4 addresses).

CGN (Carrier Grade NAT) or LSN (Large Scale NAT) - This happens within the Service Provider network. CGN device (as per the diagram) translates Private IPv4 address/Port of 10.8.1.11:6593 to a public IPv4 address/Port of 170.0.0.1:9185 before sending the packet to Internet. A relatively huge NAT table is maintained at CGN level as it may need to deal with millions of CPEs.

6. NAT44 on VSM Configuration

Before we start configuring NAT44 on VSM, let us understand the following concepts related to NAT44 implementation on VSM.

CGN Instance - On each VSM card, we can configure one CGN instance (<cgn1> in the diagram below).

NAT44 Instance - On each VSM card, we can configure one NAT44 instance (<nat1> in the diagram below).

ServiceInfra interface - ServiceInfra interface is a virtual interface which is used by the internal (to ASR9K) management / control traffic. We need 1 ServiceInfra interface per VSM card. ServiceInfra interface cannot be in any VRF (needs to be in default VRF).

NOTE: ServiceInfra and ServiceApp interfaces are used within the ASR9K router only and do not need to be announced/redistributed into IGP.

Inside VRF instance - Within one NAT44 instance, we can have multiple Inside VRF instances. For each Inside VRF instance, we can have different NAT44 parameters configured. Inside ServiceApp must be within one unique Inside VRF. Outside ServiceApp may or may not be within a (Outside) VRF.

NOTEs:- We cannot have multiple Inside ServiceApps within same Inside VRF. - We can, however, have multiple Outside ServiceApps within same Outside VRF or default VRF.- Inside and Outside VRF cannot be same.

Logical Partitioning inside VSM - Internally, VSM is divided into 2 Logic Partitions. Hence, in order to achive full throughput and scale limit (per VSM), you should have minimal of 2 Inside VRFs, 4 ServiceApp interfaces (2 in each partition), 2 Public IP address pool, etc. Traffic / subscribers which needs to avail NAT44 service also needs to be divided into 2 groups (each one associated to each Inside VRF). Following table shows the partitioning of ServiceApp interfaces between these 2 groups (which needs to be kept in mind during configuration).

Logical Partition / Group 1

Logical Partition / Group 2

ServiceApp 1, ServiceApp 2

ServiceApp 3, ServicApp 4

ServiceApp 5, ServiceApp 6

ServiceApp 7, ServiceApp 8

ServiceApp 9, ServicApp 10

ServiceApp 11, ServiceApp 12

...

...

ServiceApp 253, ServiceApp 254

ServiceApp 255, ServiceApp 256

NOTE: ServiceApp interafce pair needs to be selected from same Logical Partition (as per the above table). Otherwise, packets will be dropped. Using consecutive numbers for ServiceApp interface pair will be recommended (as shown above).

Step 3: NAT44 Application performs necessary action for the packet. As it is Inside-to-Outside packet, it first checks if there is a NAT entry exists for the source IP (10.10.10.2) and port (5000). If it does not exists, it allocates a Public IP (from the Public IP pool configured) and port and creates a NAT entry. From the NAT entry, it finds the corresponding Public IP (100.2.0.192) and port (23156) and replaces the existing Source IP and port with the same.

Step 4: After NAT translation is done, a forwarding lookup is done in Outside VRF (ovrf1) for the destination IP address (5.5.5.2) which forwards the packet to egress LC interface.

Step 5: Egress Line Card interface sends the packet out to Outside / Public side.

Step 3: NAT44 Application performs necessary action for the packet. As it is Outside-to-Inside packet, it first checks if there is a NAT entry exists for the Destination IP (100.2.0.192) and port (23156). If it does not exists, packet is dropped. Otherwise, from the NAT entry, it finds the corresponding Private IP (10.10.10.2) and port (5000) and replaces the existing Destination IP and port with the same.

Step 4: After (reverse) NAT translation is done, a forwarding lookup is done in Inside VRF (ivrf1) for the destination IP address (10.10.10.2) which forwards the packet to egress LC interface.

Parameters to be considered before Deployment

Before deploying NAT44 solution with VSM, you need to analyze the deployment scenario/requirement and come up with the appropriate values of different configurable parameters related to NAT44. Improper selection of the parameters may not address the deployment goals accurately.

9. Performance and Scale

These are possibly the most important parameters to be considered during deployment. These are not configurable parameters, but these will determine how many VSM cards will be needed for the NAT44 solution.

12. Port Limit (Per-User)

As NAT DB is shared among all users, there could be a situation where few users (Private IP owners) uses lots of NAT entries (in thousands) and because of the same, new users cannot create NAT entries. In order to keep control on creation of NAT entries by a single user, Port Limit parameter is introduced. Port limit indicates how many port numbers are allowed per Private / Inside IP address. If any flow arrives after Port Limit is reached, no NAT entry will be created for the same and the packets for the new flows will be dropped. The Port limit value will be same for all Private IP addresses.

NOTE: Port Limit is specified per Private / Inside IP address and NOT per Public / Outside IP address.

13. External Logging (Netflow and Syslog)

As you have seen above, a NAT DB entry is created for each new flow (Private IP address and port) which keeps the mapping of Private / Inside IP address + Port and Public / Outside IP address + Port. The NAT DB entry is deleted when the flow terminates (because of timeout and any user intervention).

On VSM, we support millions of NAT translations with high (in thousands and millions) setup and deletion rate (Please refer to CGv6 on VSM Feature List for scale numbers). This produces huge amount of NAT translation entries / records which cannot be stored / saved on VSM or ASR9K because of limited disk space. Hence, there is a need of having external servers where these translations can be saved.

The creation and deletion of NAT transactions (also called "Logging Records") are very important to be saved to get association of different IP addresses. In almost all countries, it is mandated by the Lawful Agencies / Authorities that the Service Provide must provide these records accurately so that the agencies can find out the owner of these APIs for different reasons. Thus it becomes a very important feature for deployment of NAT44.

On VSM, we support the 2 formats of logging records - Netflow (version 9) and Syslog. Table below compares the two.

Logging records are sent to Logging Server (IP address and Port for which is configurable) either when the Logging packet is complete or timeout occurs. Logging packets are sent with ServiceInfra interface's remote IP (for e.g., 100.1.1.2 is the remote IP of 100.1.1.1) as Source address.

Destination-Based Logging (DBL)

In some countries, Lawful Agencies also require the Service Provider to provide the Destination IP address and Port (along with Source IP address and Port information) as part of Logging Record. This is termed as Destination-Based Logging (DBL).

NOTE: Including Destination (IP + Port) information in the Logging Record will increase the size of the Record.

DBL can be supported with Netflow v9 as well as with Syslog.

Bulk Port Allocation (BPA)

In order to reduce the size of the logging record, a feature called Bulk Port Allocation (BPA) is introduced.

Without BPA, for every new flow, a Port is allocated for the Public IP and a new logging record is created with Private IP + Port and Public IP + Port. Similarly, another Logging record is created when a flow or NAT entry is deleted.

Following table captures the working of it (without BPA) with some sample IP addresses and port numbers.

Event

Inside Source IP + Port

Outside Source IP + Port

Logging Record

Additional Comments

A new flow arrives

10.1.1.1:1000

170.0.0.5:8175

10.1.1.1:1000 <-> 170.0.0.5:8175

New port (8175) allocation happens.

New logging record is created

Existing flow arrives

10.1.1.1:1000

170.0.0.5:8175

N/A

No new Port allocation happens.

No logging record is created

A new flow arrives (with new port, but same IP)

10.1.1.1:2000

170.0.0.5:13591

10.1.1.1:2000 <-> 170.0.0.5:13591

New port (13591) allocation happens.

New logging record is created.

With BPA, for the first new flow, a bulk (group) of Ports are allocated (but only one port from the group is assigned for the new flow) for the Public IP and a logging record is created with Private IP and Public IP + Start Port + End Port. Next time, a new flow comes, a new port from the already allocated pool is taken and no logging record is created. Only when all the ports in the group are used, a new bulk is allocated and logging record is created. Similarly, when all the ports from a group is released, a (deletion) logging record is generated.

Following table captures the working of it (with BPA enabled) with sample IP addresses and port numbers.

Event

Inside Source + Port

Bulk Port Allocation (size 64)

Outside Source IP + Port

Logging Record

Additional Comments

A new flow arrives

10.1.1.1:1000

Allocates Bulk Port range (8192 - 8255) for 170.0.0.5

170.0.0.5:8201

10.1.1.1 <-> 170.0.0.5:8192-8255

Bulk port allocation and new port (8201) assignment happens.

New logging record is created.

Existing flow arrives

10.1.1.1:1000

N/A

170.0.0.5:8201

N/A

No new Port allocation happens.

No logging record is created.

A new flow arrives (with new port, but same IP)

10.1.1.1:2000

N/A

170.0.0.5:8199

N/A

New Port (8199) allocation happens (from same port range).

No logging record is created.

A new flow arrives (with new port, but same IP)

10.1.1.1:5000

N/A

170.0.0.5:8236

N/A

New Port (8236) allocation happens (from same port range).

No logging record is created.

Following table illustrates the amount stoage space needed per second with varying translation creation + deletion rate for both Netflow and Syslog (with DBL disabled). It also shows the impact of BPA on the storage.

NAT translation creation + deletion rate per second

Netflow without BPA

Syslog without BPA

Netflow with Bulk size 256 and 50% utilization

Syslog with Bulk size 256 and 50% utilization

20,000

0.8 MB

2.8 MB

6.25 KB

21.875 KB

50,000

2 MB

7 MB

15.625 KB

54.6875 KB

100,000

4 MB

14 MB

31.25 KB

109.375 KB

500,000

20 MB

70 MB

156.25 KB

546.875 KB

1,000,000

40 MB

140 MB

312.5 KB

1.093 MB

NOTE: Both DBL and BPA cannot be enabled at the same time. This is because BPA requires logging record to be generated for a set of NAT entries whereas DBL requires logging record to be generated for each NAT entry. These are conflicting requirements.

14. NAT Session Timeouts (TCP, UDP, ICMP)

As the new flows creates NAT entries, we need a way to delete those NAT entries as well. Protocols like UDP is connection-less and hence, there is no way to identify when a session / connection has ended by inspecting the packets. Also, in some cases, if no packet flows between the applications for a long period of time, there is no point in holding on to the NAT entries, as that will disallow creation of new NAT sessions.

Due the above reasons, NAT entries are deleted when session timeout happens.

For every protocol (TCP, UDP, ICMP), we have different types and values of session timeouts, as depicted below.

TCP - It has two timeouts.

Initial Timeout - It kicks in before the connection moves into Active state. Default: 120 sec.

Active Timeout - It kicks in when the connection is in Active state. Default: 30 Minutes.

UDP - It has two timeouts as well.

Initial Timeout - It kicks in before the connection moves into Active state. Default: 30 sec.

Active Timeout - It kicks in when the connection is in Active state. Default: 120 sec.

ICMP - It has one timeout. Default: 60 sec.

If the timeout is configured to be too less, NAT sessions will be deleted too soon, resulting in changing of Public IP addresses. This may cause issues with the Applications.

If the timeout is configured to be too high, NAT sessions will remain in the system for long time (even though there is no data is flowing using the session) and it will restrict new sessions to be created as well (resulting in dropping of those packets).

Hence, timeout value needs to be set appropriately.

NOTE: These timeouts are set for the NAT44 instance (per VSM card) and cannot be configured differently for each Inside VRF.

You need to have some knowledge about the following, to determine the timeout values.

Application traffic that is going through the network

How sensitive it is with respect to change in IP address ?

How periodically, it would generate packets

How many NAT sessions are expected ?

Following table shows how to configure timeout values for different protocols.

15. Endpoint Independent and Dependent Filtering (EIF / EDF)

When an internal endpoint opens an outgoing session through a NAT, the NAT assigns a filtering rule for the mapping between an internal IP:port (X:x) and external IP:port (Y:y) tuple. The key behavior to describe is what criteria are used by the NAT to filter (Outside-to-Inside, O2I) packets originating from specific external endpoints. We have the following 3 options here:

Address-Dependent Filtering - NAT forwards any packet destined to X:x, provided it is coming from the external IP to which I2O packets were sent earlier.

Address and Port-Dependent Filtering - NAT forwards any packet destined to X:x, provided it is coming from the external IP:port to which I2O packets were sent earlier.

All the behavior are explained in the following diagram with an example scenario.

As shown above, depending on the filtering policy and NAT session DB, O2I packets coming from specific IP and port will be either allowed to cross NAT device (VSM card) or dropped by CGv6 Application on VSM.

Table below shows how to configure CGv6 application on VSM to support different filtering policy.

Configuration for Endpoint-Independent and Endpoint-Dependent Filtering

16. Traffic Diversion (to VSM)

We can use different mechanisms to divert the traffic to VSM card (to specific ServiceApp interface).

Default Route

If the inside traffic is arriving on a (Inside) VRF and ALL traffic needs to undergo NAT44 operation, we can add a default route under the VRF to divert traffic to the Inside ServiceApp (as shown below).

Static Route

In some cases, Outside ServiceApp interfaces reside in same / default VRF. Hence, in order to divert O2I traffic to specific Outside ServiceApp interfaces, static route can be used in the following way.

Deployment Use-case 2: Customer wants to distribute subscriber traffic into different Inside VRFs which may go to same VSM card or different VSM cards (but, will certainly using different Public IP pool).

Deployment Use-case 3: Subscriber / Access / Inside traffic comes in default / global VRF and we need to distribute the traffic to different Inside ServiceApps which are in different Inside VRFs.

NOTE: Typically, ABF is to be used in Private side / Subscriber side and NOT towards Public / Core / Network side.

In the above cases, ABF provides a very good solution. Below is sample configuration on how to use ABF for traffic diversion.

17. Static Port Forwarding

There is a very important point about Dynamic NAT44. All the NAT translations / sessions are created by I2O traffic. If O2I traffic reaches VSM for which there is no NAT entry, the packets will be dropped. This works fine for most of the cases as the session / traffic is initiated by Applications which reside on Private side.

However, there are cases, where a server resides on the Private side of the network. In this case, there are 2 issues.

Clients (on Public side) cannot initiate session to this Server, as those (O2I) packets will be dropped by VSM.

Clients do not know the Public IP of the Server (and cannot use Private IP to communicate either)

To address these problems related to Server sitting on Private side of the network, a new feature called "Static Port Forwarding" is introduced. Following diagram explains "Static Port Forwarding" feature functionality.

Using Static Port Forwarding, user can provide the Private IP address and Port (via CLI) and NAT44 Application on VSM generates (dynamically) the corresponding Public IP and Port. Also, these mapping are made permanent - i.e., they do not get timed out and get deleted. The Public IP and port generated by the Application can be added to DNS database and thus made available to all.

With this design, any device on Public side of network can now send traffic to the known Public IP and port (to reach the Server sitting inside Private network). Also, as the NAT entry is permanent, O2I traffic always finds the entry and using the same can translate the packet (without dropping it).

Staic Port Forwarding entries can be created separately for each protocol - TCP, UDP and ICMP. To know the maximum number of such entries, please check CGv6 on VSM Feature page.

- Outside / Public IP is generated by the NAT44 Application and hence, can be random.

- Outside port is usually assigned same as Inside Port, unless the Outside port is already being used

As these are used for Servers located in Private network, it is desirable that the Public IP address remain constant across RP failover.

As Outside / Public IP address for a Static Port Forwarding entry is allocated by NAT44 application based on the instant situation of Public IP availability stock as well as the allocation algorithm's state, it is highly probable that if the Static Port Forwarding entry is deleted and re-added or, if the VSM card is reloaded), it may allocate a different Public IP address.

In order to keep the same Outside IP address, it is recommended to add the Static Port Forwarding configuration as a first thing after VSM card comes up and when there is no NAT traffic on the router / VSM card (could be in a "maintenance window"). That way, every time, VSM is reloaded, the Public IP addresses assigned for Static Port Forwarding entries will remain the same.

Try to find out the following, before using Static Port Forwarding.

Will there be any Servers sitting in the Private side of the deployment network ?

How many of those Servers will be ?

Can the Public IP address of the Servers be random and can be published via DNS or similar mechanism ?

18. Application Layer Gateway (ALG)

Application Layer Gateway (ALG) is a device which has the capability of inspecting into a packet beyond layer 4 and can change Application layer content to meet certain need.

NAT44 changes IP address and Layer 4 (UDP/TCP/ICMP etc.) port. There are certain applications which embeds IP address and/or Port information in Application content. Now, the issue is while the packet traverses across a NAT44 device, layer 3 and 4 addresses get changed. However, in the Application layer, the content still contains old layer 3 and / or layer 4 addresses. This causes an issue in the Application as this is unexpected. Hence, the need of ALG functionality within a NAT device which while changing Layer 3 and 4 packet content, also changes Application content where Layer 3 and 4 addresses were embedded. With this change, end Application will be happy as it does not need to deal with 2 sets of addresses any more.

However, there are 2 ways this problem can be solved.

Adding ALG functionality to NAT device - ALG functionality needs to be added to NAT device for each such Applicaton which embeds Layer 3 and/or 4 addresses in Application content.

Changing the Application to deal with NAT device in the network - Application needs to assume that the Layer 3 and/or 4 address can get changed on the way (as there could be NAT device in the network) and hence, either avoid embedding Layer 3/4 addresses in Application content or find other mechanism to handle 2 sets of addresses.

The main challenges in adding ALG functionality to NAT device are:

Every time a new Application is written which embeds Layer 3/4 address in Application content, all NAT devices need to be changed to address the new Application. This is not scalable as lot of new Applications are written everyday.

In order to implement ALG for an Application, NAT device needs to understand the Application protocol as well as packet formt/content. Many Applications implement proprietary protocol and hence, do not want to make the same as public information. Hence, those Application packets will face issues with NAT device.

There are applications (like, crypto) which do not want any intermediate device to understand / peek into the Application content and modify it. These packets should only be encoded/decoded by end Applications. These application packets would not be able to deal with intermediate NAT device.

On the contrary,

Application can be written in such a way not to use Layer 3/4 addresses in Application content and to use Application-level ID, instead.

There can be other mechanisms, e.g. - using STUN (Session Traversal Utilities for NAT) that applications can take to handle intermediate NAT device.

NOTE: Due to the above reasons, our solution does not encourage to support ALG within NAT44 functionality.

However, few basic ALG functionality is implemented with NAT44 Application. These are:

19. Redundancy

Redundancy is an integral part of CGN (Carrier Grade NAT). Majority of the Service Providers want Redundancy in their network to make it more resilient. It helps in minimizing the traffic outage when one device fails.

On VSM, we support 2 types of redundancy.

N:1 ABF-based redundancy (N can be 1 as well)

1:1 Warm Stand-by Redundancy (starting from XR release 5.2.2)

N:1 ABF-Based Redundancy

In this case, there needs to be N Primary VSM card and 1 Backup VSM card. Value of N can be 1 as well, but typically would be 2 or 3. Following are different characteristics of this solution.

Each VSM card needs to be configured independently

Configuration (usually) should be similar (w.r.to parameters, number of ServiceApp interfaces, etc.)

20. NAT44 Licenses

In order to use NAT44 functionality on ASR9K, Licenses needs to be purchased. Depending on the number of Stateful Translations needed by the solution, required number of NAT44 specific licenses can be purchased. This fits nicely with "Pay as you grow" model as well.

Following licenses need to be purchased for NAT44 and other CGv6 applications.

License Part Number

License Description

Additional Comments

A9K-VM-LIC

Cisco ASR 9000 Application VM License

For launching (activating) any Application VM, this license is needed. When CGN software is ordered, one free A9K-VM-LIC will be provided along with it.

21. Summary of parameter values

In the following table, all the useful parameters are listed along with their default and valid range of values. You can consult this table to come up with the parameter value for your deployment case.

Parameter (CLI)

Defined at what level

Default Value

Range of Values

Supported from XR Release

Additional Comments

alg ActiveFTP

per NAT44 instance

Disabled

Enable / Disable

5.1.1

Active FTP ALG

alg pptpAlg

per NAT44 instance

Disabled

Enable / Disable

5.1.1

PPTP ALG

alg rtsp

per NAT44 instance

Disabled

Enable / Disable

5.1.1

RTSP ALG

bulk-port-alloc size

per Inside VRF

Disabled

16, 32, 64, 128, 256, 512, 1024, 2048, 4096

5.1.1

dynamic-port-range start

per NAT44 instance

1024

1 - 65535

5.1.1

Starting port number (for Public IP address) to be used for Dynamic NAT entries.

25. Multiple Outside ServiceApps sharing same Outside VRF

It is very common to have default VRF as Outside VRF and when there are multiple Inside VRFs mapped to the same. In the following table, a sample ServiceApp and VRF configuration is shown. Please note that in this case, multiple Outside ServiceApps share share a comon Outside VRF.

Inside VRF

Inside ServiceApp

Outside VRF

Outside ServiceApp

ivrf1

ServiceApp 1

default or ovrf

ServiceApp 2

ivrf2

ServiceApp 3

default or ovrf

ServiceApp 4

To handle this scenario, we need to specify "outsideServiceApp" parameter configuration to indicate what is the Outside ServiceApp to be used with the mapping. Static route rule for specific Public IP address pool should guide the traffic to specific Outside ServiceApp. Only these configurations are shown below. Rest of the configuration remain the same.

26. NAT Bypass

There is an use-case where traffic selected traffic coming onto ASR9K via a Private side interface needs to go via NAT44 application, whereas remaining traffic can bypass NAT44 and should get forwarded via regular forwarding rule. This is called NAT bypass.

To implement NAT bypass, let's consider this situation:

Private Traffic enters ASR9K via one VRF (say, RED)

Selected traffic gets diverted to VSM card's Inside ServiceApp which is in different VRF (say, BLUE) and after translation comes out of Outside ServiceApp and eventually goes out of ASR9K via core-facing interface which is in RED VRF.

Rest of the traffic (which bypasses NAT44) goes out of ASR9K via same core-facing i/f in RED VRF.

Please note that other than NAT bypass, there could be other deployment scenario where preserving VRF (across VSM) becomes a necessity. But, the solution would be same / very similar.

The above scenario can be achieved using VSM with some additional ABF and Static Route and appropriate VRF configuration.

Let us take a look at the following diagram as a sample scenario.

In the above diagram, traffic enters and exits out of ASR9K in RED VRF. Also, please note that Inside ServiceApp is in BLUE vrf whereas Outside ServiceApp is in RED VRF.

Following table shows the specific or additional configuration that is needed for appropriate traffic diversion.

27. MPLS (Layer 3) VPN and NAT Interworking

An Multiprotocol Label Switching (MPLS) Layer 3 Virtual Private Network (L3VPN) consists of a set of sites that are interconnected by means of an MPLS provider core network. At each customer site, one or more customer edge (CE) routers attach to one or more provider edge (PE) routers.

MPLS VPNs are easier to manage and expand than conventional VPNs. When a new site is added to an MPLS VPN, only the edge router of the service provider that provides services to the customer site needs to be updated. The components of the MPLS VPN are described as follows:

Provider (P) router — Router in the core of the provider network. PE routers run MPLS switching and do not attach VPN labels to routed packets. VPN labels are used to direct data packets to the correct private network or customer edge router.

Provider Edge (PE) router — Router that attaches the VPN label to incoming packets based on the interface or subinterface on which they are received, and also attaches the MPLS core labels. A PE router attaches directly to a CE router.

Customer edge (CE) router — Edge router on the network of the ISP that connects to the PE router on the network. A CE router must interface with a PE router.

Service providers and enterprises that have network application services they want to offer or share with customers and partners will want to minimize any connectivity burden placed on the user of the service. It is desirable, even mandatory, to extend the offering to as many potential users as needed to achieve the desired goals or return.

By deploying NAT within the common MPLS VPN infrastructure, communications service providers can relieve some of the connectivity burden on customers and accelerate their ability to link more shared application services to more consumers of those services

There are two options for NAT deployment within the MPLS provider edge:

Distributed with ingress NAT PEs

Centralized with egress NAT PEs

Following diagram shows Distrbuted NAT scenario with Ingress NAT PEs.

With this design, scalability is maintained to a large extent while performance is optimized by distributing the NAT function over many edge devices. Each NAT PE handles traffic for sites locally connected to that PE. NAT rules and access control lists or route maps control which packets require translation.

In the above case, at ingress PE router, customer private IP addresses are NAT'ed to public IP address by VSM card and then MPLS labels are added by it before the packet goes out of ASR9K. On the return path, MPLS label(s) are removed by MPLS-facing LC and IT packets are sent to VSM. VSM performs reverse NAT and sends the packet to LC which then sends it back to CE router.

Following diagram shows Distrbuted NAT scenario with Ingress NAT PEs.

With this design, scalability is reduced to some degree since the central PE must maintain routes for all customer networks that access the shared service. The application performance requirements must also be considered so that the traffic does not overburden the router that must translate the IP addresses of the packets. Because NAT occurs centrally for all customers using this path, IP address pools can be shared; thus, the total number of subnets required is reduced.

In the above case, in the egress PE router, first MPLS labels are removed by ingress LC and the IP packet is sent to VSM card. Customer private IP addresses are NAT'ed to public IP address by VSM card and the packets are forwarded to shared service network. In the reverse path, VSM translates Public destination IP to private IP addresses and then adds MPLS labels before sending it to egress LC. Egress LC swaps one label and sends the packet out of ASR9K towards MPLS network.

NOTE: MPLS labels should be removed by LC before sending the packet to VSM as IP packet. However, VSM can add the required MPLS labels before sending the packet to egress LC.

28. NAT Hairpining

Host behind a NAT device (on Private side) communicating with another host behind the same NAT device (on Private side) is called "NAT Hairpinning". Let us consider the following deployment use-case.

We have a server behind a NAT device which has a Public IP as well, created using Static Port Forwarding configuration. Now, this server can be accessed from hosts on public side of NAT device as well as Private side of the NAT device. When a host on Private side of the NAT device tries to communicate with the Server, it uses NAT Hairpinning. Following diagram depicts how NAT hairpinning works with NAT44 on VSM.

In this case, we first add a Static Port Forwarding entry for a service offered by the Server at 10.100.1.2:2055. Let's say, the Public IP pool configured is 200.2.0.0/24. NAT44 application allocates Public IP and port as 200.2.0.210:2055 (Please note that the port is preserved here). This Public IP and port is published / made available to the hosts. Let's the packet flow now when a host with Private IP 10.10.10.2 tries to access the service.

Step 1: Host sends a packet (with Source IP 10.10.10.2 and port 3000) to Server's Public IP and port and the packet reaches ASR9K on TenGigE 0/0/0/0.1 which is in VRF ivrf.

Step 3: Application treats this as I2O packet. A new dynamic NAT entry is created by NAT44 application and it translates source IP/Port from (Private) 10.10.10.2:3000 to (Public) 200.2.0.192:23516. Please note that the Destination IP address and port are not touched here. The packet is sent out and because of Static route definition for Public IP pool, the packet comes back to VSM card via (Outside) ServiceApp 2.

Step 4: Application treats this as O2I packet. As there is already a (Static) NAT entry exists for Destination IP and port, NAT44 application translates Destination IP address/Port from (Public) 200.2.0.210:2055 to (Private) 10.100.1.2:2055. Please note that the Source IP address and port are not touched here. The packet is sent out and via regular forwarding rule, it reaches egress i/f TenGigE 0/0/0/0.2.

Step 5: The packet is forwarded to the Server with Source IP/Port as 200.2.0.192:23516 and Destination IP/Port as 10.100.1.2:2055 and the server consumes it.

Response from the Server will take the reverse path and it will use Dynamic NAT rule in first reverse NAT and then Static NAT rule in second NAT processing, to reach the host.

In this case, Static Port Forwarding configuration is used for Server as an use-case. But, it can be another host as well for which there is no Static Port Forwarding configuration. Only important thing is sender needs to know the Public IP and port of the receiver.

Please note that there is no specific NAT44 configuration is needed for this. Regular / basic NAT44 configuration will work here. Hence, no configuration is provided here.

Unlike ISM card, we do NOT need to make any special configuration (like, dividing traffic into 2 sub-groups) for VSM. As long as I2O + O2I traffic do not exceed the capacity of the CGv6 Application instances, direction of traffic does not matter i.e., I2O and O2I traffic do not need to be equally balanced.

Validation of Configuration

Once NAT44 on VSM is configured, we need different ways (mainly, via "show" CLIs) to validate those. In this section, important NAT44 related CLIs are listed and also explained how those can be used for validation.

Above table shows all Inside IPs (10.2.5.134, 10.2.5.142) and Port combination for Inside IP (100.200.2.75) and Port Range (1 through 65535). In this case, there are multiple Inside IP addresses are mapped to one Public IP address.

and later for ServiceApp3 there is a vrf named ivrf3. interface ServiceApp3 vrf ivrf3

I am interested if that interface ServiceApp3 should be in ivrf2 like in command in ACL for nexthop1? I presume that IP address 6.1.1.2 (from ACL) is some other end of P2P link of a ServiceApp3 interface?

And one other question about VSMs, if I put a two VSM in one ASR9k chassis, with a full utillization of VSM, which ServiceApp ports should be there? ServiceApp1-2, ServiceApp3-4 on VSM1 and ServiceApp5-6, ServiceApp7-8 on VSM2? What about an inside VRFs in that redundant scenario?

Regarding the logical partitioning section: it is my understanding that for me to use full VSM throughput, I would have to configure, at least, two inside serviceapp interfaces (plus 2 corresponding outside serviceapps). Is this correct? What would be the expected behavior if I just configure SA1/SA2? Would only half the throughput be available to me?

The reason I ask is that I currently have a setup with single in/out serviceapps and yet the VSM is processing around 30G in peak hours (2G in2out, 28G out2in), which is about what I expected full throughput to be around.

I don’t have graphics for number of sessions on hand to be quite honest, but considering twice as much as what we have at this moment which is the start of peak hours, I’m pretty sure it should be below 1M.

MTU for serviceapps is 9216, but since it’s a DOCSIS access network, I don’t expect anything above 1500.

I’d just like to confirm that since I only have one vrf configured, I’m very close to the maximum performance allowed with only one vrf. I’m assuming one vrf = ½ total throughput (half of 60G)Can anyone confirm this?

I have some issues with VSM configurations. My previous version was 5.3.4 where i had successfully configured vsm and other related configs. But later it was upgraded to 6.2.3 but then Nat was not in use. Now on the same version i.e 6.2.3, I am trying to configure Nat configurations and i am unable to add "service cgn cgnat service-type nat44" in ServiceApp2.

% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors

Is there any way to remove virtual-service vnics configuration without vsm card? I uninstalled vsm card without removing the vsm config. And now, I am unable to remove the config. It gives the following error with committing. % Failed ...
view more

Multiple Cisco IAD2431-16FXS units convert analogue phones to VOIP through separate SIP trunks. This has been working for a year but just last week outgoing calls failed (incoming are fine). Dial tone is available but after dialling, the line goes silent....
view more

Hi all, I am trying to lab a scenario for L3VPN where I do have a BGP VPNv4 RR and multihomed customers (CEs).I wonder if we can utilize the mulitpathing using BGP diverse-path (IOS XE) or BGP Add-path (IOS XR) on the RR without changing the RDs.The ...
view more

We are facing call transfer issue where using Genesys PBX where VGW is Cisco 4431 router ...how do we troubleshoot on VGW end ...MGCP gateway configured ..attaching VGW config..which debug command will give idea when the call transfer fail

I am using Cisco 7606-3CXL with Sip-400 and due to hardware issue m going to change router to 7603-S (Available in market)But in router 7603-S 15Mpps and in router 7606 is 30Mpps.i want to know that, how can i check in router 7606 currently mp...
view more