Exact nature of Carrier Grade NAT

[steven.crutchley]

Hi everyone,

I'm running the follow lab in EVE-NG:

All devices are IOS-XE.

There are 5 customer sites all connecting to PE1 over a WAN connection in the 100.64.0.0/10 range.
Each CE is performing source based PAT translation.

For example:
Site 1 has range 192.168.1.0/24. CE1 will source NAT the range to 100.64.10.0/30
Site 2 has range 192.168.2.0/24. CE2 will source NAT the range to 100.64.20.0/30
and so on up to to Site 5.

ASN 100 is a simple SP network. ISIS with LDP is run across the core. PE1 sends a 100.64.0.0/10 summary to ASBR1.
ASBR1 peers externally with the INTERNET router and advertises both 100.64.0.0/10 and 200.200.200.0/24 (via null static) outbound.
The INTERNET router advertises 8.8.8.8 back as a dummy internet address.

If I ping 8.8.8.8 from any site, the CE will do the PAT translation and the ping works.

The goal of this lab is to configure CGN to hide the 100.64.0.0/10 range with IPs from the 200.200.200.0/24 range.

To that end I have done the following (I have omitted some config details like IGP and LDP config for the brevity, but the full lab configs are attached):

hostname ASBR1
!
interface GigabitEthernet1
 ip nat outside
!
interface GigabitEthernet2
 ip nat inside
!
router bgp 100
 neighbor 172.16.1.2 remote-as 200
!
 address-family ipv4
  network 200.200.200.0
  neighbor 172.16.1.2 activate
  neighbor 172.16.1.2 route-map TO-INTERNET out
 exit-address-family
!
ip nat settings mode cgn
!
ip nat pool NAT-POOL 200.200.200.50 200.200.200.51 prefix-length 24
ip nat inside source list 1 pool NAT-POOL overload
ip route 200.200.200.0 255.255.255.0 Null0
!
ip prefix-list TO-INTERNET seq 5 permit 200.200.200.0/24
ip access-list standard 1
 10 permit 100.64.0.0 0.63.255.255
!
route-map TO-INTERNET permit 10
 match ip address prefix-list TO-INTERNET
!

This works really well.

NB. As an aside, I've set the NAT pool to only 200.200.200.50 200.200.200.51 so I can play with what happens if the 100.64.0.0/10 addresses outnumber the public address - this doesn't matter for an overload configuration but it useful nonetheless.

ASBR1#sh ip nat translations 
Pro  Inside global         Inside local          Outside local         Outside global
icmp 200.200.200.51:10     100.64.10.1:10        ---                   ---
icmp 200.200.200.51:1      100.64.40.1:1         ---                   ---
icmp 200.200.200.51:5      100.64.20.1:5         ---                   ---
icmp 200.200.200.51:2      100.64.50.1:1         ---                   ---
icmp 200.200.200.51:4      100.64.30.1:4         ---                   ---
Total number of translations: 5

ASBR1#

However, I'm a little confused with what ip nat settings mode cgn does.
If I remove it from ASBR1, everything still works the same.

But according to this site, I need to add it.

So I guess my questions are:

• What does this command actually do?
• How is CGN different than just doing NAT twice? I understand how it can affect inbound traffic, if multiple customer NATed ranges are hidden behind the same CGNAT address, but is there something more fundamental that I'm missing?

Happy to provide more information if needed.

[balaji.bandi]

This is ok on the latest hardware and IOS XE version.

as i remember there is some Limitation i dont rember the version, carrier grade NAT and Traditional nat not work as expected in the same box. But i used for Labbing carrier grade using same simulator works, new ASR code also works.

[steven.crutchley]

Thanks for the response, however I'm not sure if you're answering my query.

How does the presence or absence of the ip nat settings mode cgn command affect the behaviour of this lab?

I'm trying to understand how CGN (and its associated commands) differs from simply NAT'ing twice. 

[balaji.bandi]

Some cases you need some features enable - as command clearly says 

• ip nat settings mode cgn : disables outside to inside mapping which is not required for cgnat case.

Note : depends on the plat form that features changes, so check the document of the device you using.

The lab does not show what image you using in the Lab, so better always check the documentation restriction section (the one you mentioned URL have same information).

[steven.crutchley]

I'm not sure I understand. The ip nat setting mode cgn command just disables NAT coming from the the outside interface to the inside on? Does this matter in the outbound PAT case I have configured for my lab?

I'm trying to think of a way to test this in my lab see a difference in behaviour with or without the command. 

[balaji.bandi]

If you don't need that option not required.

[steven.crutchley]

I still don't understand.

Telling me that if I don't need that option it is not required, is a tautology...

[Cristian Matei · Accepted solution]

Hi Steven,

   CGNAT, outside of usually being a second NAT layer in the traffic pipe, is just NAT on steroids aka supports high and very high number of translations, both new and concurrent. Based on vendor and NOS, several techniques have been used to reach these numbers: HW acceleration, more RAM, tweak RAM consumption per NAT entry.

   Now, on IOS-XE, as you can see, with or without configuring "ip nat setting mode cgn", it still works. Now, if you want to reach the upper numbers for scale with NAT (which you will always do in production networks), you must configure "ip nat setting mode cgn"; when you configure it:

     - IOS-XE no longer keeps track of "outside local" and 'outside global" addresses, as you can see in your outputs as well; this means saving memory consumption per NAT entry, thus more NAT entries in the table for same amount of RAM

      - as a result of no longer keeping track of "outside local" and 'outside global",  you no longer can configure "ip nat outside"; although it may look as a limitation, on the device you're doing CGNAT, you never ever need to perform "ip nat outside"

Note that, to reach scale numbers for CGNAT on IOS-XE, other functions might need to be enabled, additional to "ip nat setting mode cgn", depending on the HW platform.

There are few other guidelines for CGNAT, explained in RFC 6888 if you're curious.

Best,

Cristian.

[steven.crutchley]

Thanks Cristian, much appreciated.

Do you know if there is a way I can play with the limits of CG-NAT in a lab?

I'm thinking of things like port and IP pool exhaustion. I want to do some testing on what the behaviour is and how to deal with it. I'll have a poke around with the setting (presumably by lowering limits within the config) but if anything comes to mind that would be helpful to look at, that'd be helpful  

[Cristian Matei]

Hi,

   Testing port/pool exhaustion is not really related to CG-NAT, but I see where you aim. Easiest way is if you can use a traffic generator with different source IP addresses and various flows (https://trex-tgn.cisco.com/ , https://github.com/rtbrick/bngblaster , https://ostinato.org/).

Best,

Cristian.

Best,

Cristian.