Carrier-Grade NAT (CGNAT)

Source Address Translation is a technique that allows multiple devices on a private network to access external networks using a single or limited set of public IP addresses. It modifies the source IP address of outbound packets so they appear to originate from a public IP address. Usually the private network uses IPv4 addresses define in RFC 1918 because there are more hosts in the network than public IPv4 addresses allocated to the organization.

In most cases, TCP and UDP source ports are translated alongside the IP addresses. This is, strictly speaking, Port Address Translation rather than Network Address Translation. Port translation is necessary because two hosts on the private network may use the same source port and be translated to the same public IP address. Their communications must be kept separate. This technique allows thousands of internal devices to share a single public IP address.

In the example on the right-hand side, an IPv4 packet with source address ten dot zero dot zero dot three and a TCP source port of ten twenty-four is received on the private or local interface of the CG-NAT device. The CG-NAT device maintains a translation table that records all active translation rules. In this case, the combination of IP address and TCP port is translated into a source IPv4 address of one hundred ninety-two dot one hundred sixty-eight dot two dot one hundred and TCP source port forty-one twenty-three, and the packet is forwarded upstream to the public interface. If there is another device on the private network using the same TCP source address port, it can be translated to the same public IP address simply using a different public TCP source port, such as forty-two thirty-one. When response traffic arrives on the public interface, the CG-NAT device consults the translation table and performs the reverse translation - this time for the destination IP address and TCP port to ensure the traffic is correctly forwarded to the local interface.

Destination Network Address Translation is a form of NAT in which the destination IP address (and optionally the destination port) of incoming IP packets is modified as they pass through a NAT device. This allows traffic directed at a public IP address to be transparently redirected to an internal host on a private network. Destination NAT is typically applied on edge devices to enable inbound connections from the public internet to services hosted within a private network that uses RFC 1918 IPv4 address space. Destination NAT is commonly applied in the following scenarios:

To ensure proper return traffic flow, destination NAT is typically paired with source NAT or masquerading. This pairing prevents asymmetric routing, where response packets might bypass the NAT device and get dropped by external clients expecting replies from the public IP. In some cases, destination NAT can also be used to mask public IP addresses within a private network, adding an extra layer of abstraction and control.

There are two types of Network Address Translation: static and dynamic.

With dynamic NAT, internal IP addresses are mapped dynamically to available public IP addresses from a predefined pool. This is typically a many-to-one mapping. In this scenario, a translation rule is created dynamically when the first packet arrives on the local interface and is removed after a period of inactivity. The advantage of this approach is its ease of configuration and the efficient sharing of public IP resources by internal hosts. However, a key limitation is that connections cannot be initiated from the public network. On the plus side, dynamic NAT can serve as a security feature, as communication can only be initiated from inside the network.

If certain devices on the internal network need to be reachable from the public network, static NAT rules can be configured. These are manually created one-to-one mappings that assign a specific internal IP address to a specific public IP address.

Let’s briefly touch on some limitations of NAT in general:

Before configuring CGNAT, you must first configure the platform profile. The platform profile defines the resource scale available on a hardware platform based on the ASIC in use. Since hardware resources are limited, platform profiles allow allocation of resources based on specific use cases. These profiles are supported only on multiservice edge images.

By default, the 4q platform profile is enabled. This profile supports BNG functionality and allows for four queues per subscriber. If you want to use CGNAT in combination with BNG features, you must switch the platform profile to either nat_1q or nat_4q, depending on the number of queues required. If you’re using the CGNAT appliance functionality, you need to configure the nat_standalone profile.

In this section, we use a lab setup consisting of two Q2a-based switches. The two switches, named B1 and B2, are interconnected via 10G interfaces. Both switches are running RBFS multiservice-edge image with version 25.3.1. In addition, both switches are connected to a Linux server running BNG Blaster software to generate PPPoE sessions. A short introduction to the BNG Blaster can be found in the Supplementary Material in section BNG Blaster. For more details refer to the BNG Blaster Documentation.

In this subsection, we’ll configure the CGNAT-BNG feature on router B1. We assume, that you are familiar with PPPoE or IPoE configuration already.

We’ve already mentioned that you need to have the right platform profile active to run CGNAT. So, let’s do this first.

First, we need to define a NAT pool using the set forwarding-options address-translation pool <pool-name> command. If a NAT pool is exhausted, additional pools can simply be defined and daisy-chained using the next-pool option.

Next, we define a NAT profile with the command set forwarding-options address-translation profile profile-name.

Defining a NAT pool and a NAT profile alone have no effect. To achieve network address translation, we need to define where the translation should take place. NAT rules are defined from the inside interface (also called private or local interface) towards the outside interface (also known as public interface). The CGNAT service then ensures automatically that return traffic is translated accordingly.

The role of an interface can be defined using the set interface <name> unit <unit> address-translation direction command. It is also necessary to enable NAT in the appropriate routing instance using the `set instance default address-translation true command.

When configuring NAT in conjunction with BNG functionality, the NAT profile is part of the service definition. Therefore, it’s necessary to create a service profile - if none already exists - with the set access service-profile <profile-name> address-translation profile command. This profile can include additional service definitions, such as class-of-service or HTTP redirect services. This service profile needs to be assigned to an access interface using the set access interface

Now, that we have completed all configuration steps, we can use the BNG Blaster to generate a few PPPoE sessions and monitor the NAT operation.

Let’s first check whether subscriber sessions were successfully established and which IPv4 addresses were allocated to them:

In this example, ten PPPoE sessions are active and addresses were taken from the 10.1.100.0/24 address pool. Next, we can check the NAT pool:

The show address-translation allocation can be used to list all NAT pools and track how many resources from each pool are already consumed. The command can also be used to lists the public IP addresses and port ranges allocated to the PPPoE subscribers.

Finally, the active translation rules can be display using the show address-translation rule command.

In this subsection, we shift our focus to the CGNAT standalone feature, which we’ll configure on router B2.

Again, we need to make sure that we have the right platform profile active to run CGNAT.

The initial configuration steps are similar to the CGNAT-BNG use case, so we can go through them quickly. The following exercise serves as a repetition.

Enabling NAT in the appropriate routing instance and defining the upstream interfaces as public interfaces is done the same way as in the CGNAT-BNG scenario. When configuring CGNAT in standalone mode, we need to define the private interfaces using the set interface <name> unit <unit> address-translation direction local command. We also need to attach the NAT profile to this interface directly, using the set interface <name> unit <unit> address-translation profile <profile-name> command.

If the BNG Blaster is still running and generating traffic, we can verify the correct translation with the usual commands:

The main difference in the output compare to the BNG configuration is that there are no users any more. Thus the local interface is listed as user.

So far, we’ve demonstrated how to configure dynamic NAT, which is the most common scenario. However, in some cases, it is useful to create static NAT rules to ensure that a specific source IP address and source port are always translated to the same address and port combination on the public network. The configuration process for static NAT is the same for both CG-NAT BNG and standalone NAT.

Static NAT is configured by creating a NAT rule using the set forwarding-options address-translation rule <rule-name> command. A static NAT rule can include multiple mappings, each defined using an ordinal and an ordinal number. For each ordinal, you need to specify the routing instance to which it applies. You must also define the protocol, for instance UDP, followed by the private or local IP address and the local port. This local address port combination is then translated to the public IP address and port specified in the ordinal.

After committing the configuration, you can verify that the static rule has been added by running the show address-translation rule command. The output will reflect the static mapping we just created. You can also see that the static NAT rule is not bound to a specific interface, but acts globally.