cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4954
Views
0
Helpful
25
Replies

Carrier-grade NAT (CGSE): ¿do I need VRF on inbound ServiceApp?

rogelioalvez
Level 1
Level 1

Hello team:

We are going to populate an Internet Cisco CRS router with a CGSE module in order to carry out NAT44.

According to the CGSE documentation (http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/cg_nat/configuration/guide/cgc42cgn.html) the inbound ServiceApp is associated to a VRF. ¿Is this always necessary?

In other words: ¿ Can I just put an IPv4 address to my inbound and outbound ServiceApps, and avoid configuring a VRF on them? Then, I should add the proper "global" static routing sentences to route incoming packets to the corresponding ServiceApp interfaces.

Your kind answers will be greatly appreciated

Best regards

Rogelio Alvez

Argentina

1 Accepted Solution

Accepted Solutions

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hola Rogelio,

in the case of NAT44, you definitely need an inside VRF.

On the outside, you could use the global, but for inside, you must use a VRF.

Simply because you need to associate it to a map-pool:

service cgn demo

service-type nat44 nat1

  inside-vrf inside

   map address-pool 100.0.0.0/24

In other kind of translation mechanism like NAT64 or DS-Lite, it's not mandatory to use vrf since you can rely on address-families to discriminate the inside world and outside world.

HTH,

cheers,

Nicolas.

View solution in original post

25 Replies 25

Nicolas Fevrier
Cisco Employee
Cisco Employee

Hola Rogelio,

in the case of NAT44, you definitely need an inside VRF.

On the outside, you could use the global, but for inside, you must use a VRF.

Simply because you need to associate it to a map-pool:

service cgn demo

service-type nat44 nat1

  inside-vrf inside

   map address-pool 100.0.0.0/24

In other kind of translation mechanism like NAT64 or DS-Lite, it's not mandatory to use vrf since you can rely on address-families to discriminate the inside world and outside world.

HTH,

cheers,

Nicolas.

Thank you ver much Nicolas. Now I have a problem to solve, and I would appreciate your advice.

The interfaces (inbound and outbound) of my router are both global (public IP addresses on both sides). ¿Do I need to move the inbound interface to the same VRF to which the inbound ServiceApp will belong?

Otherwise, I do not see an easy way to "leap" from a global space to a VRF one when NAT must be involved for the incoming packets.

If you have experienced such an scenario, I would appreciate your sending me a sample configuration.

Thank you very much in advance again.

Rogelio

Hi Rogelio,

your inside addresses can be public too, even if it's not the common case (most people would like to use a private range to save the public addresses, being a scarse resource).

The serviceApp interfaces are "virtual tunnels" used by the router to communicate to and from the CGSE card.

For a NAT44 configuration, the inside serviceApp must be assigned to the same VRF than the inside physical interfaces or sub-interfaces. Check this config sample:

service cgn demo

service-location preferred-active 0/1/CPU0

!

vrf inside

address-family ipv4 unicast

!

vrf outside

address-family ipv4 unicast

!

interface te0/0/0/0

vrf inside

ipv4 add 10.1.1.1/24

!

interface te0/1/0/0

vrf outside

ipv4 add 100.1.1.1/24

!

service cgn demo

service-type nat44 nat1

  inside-vrf inside

     map address-pool 100.0.0.0/24

!

interface ServiceApp1

vrf inside

ipv4 address 1.1.1.1 255.255.255.252

service cgn demo service-type nat44

!

interface ServiceApp2

vrf outside

ipv4 address 2.1.1.1 255.255.255.252

service cgn demo service-type nat44

!

router static

vrf inside

  address-family ipv4 unicast

   0.0.0.0/0 ServiceApp1

  address-family ipv4 unicast

    100.0.0.0/24 ServiceApp2

Again, the outside VRF isn't mandatory, you can skip these statement and use the global.

Hope it answers your question,

Cheers,

Nicolas.

Hi Nicolas. Thanks a lot again for your kind answer.

For some reasons I have not mentioned before, I would prefer (moreover, need) to assign the inside AND the outside 10GE interfaces to the same VRF.

The point is that some incoming packets will need NAT (origin IP with private addressing) whereas other packets (already with public IP address in their origin IP field) will not need it.

So I am plannig ACL-based forwarding on the input 10GE interfaces in order to redirect "private IP" packets to the internal ServiceApp and let the other (public IP) packets follow their path to the outside interfaces with traditional destination routing. This would be easy to accomplish if the input and output interfaces belong to the same VRF, since the router will be able to route "non NATable" packets with the same FIB.

Since the documentation in principle does not prevent me from doing it: ¿Can I have the ServiceApps of your example both in the same VRF?

I promise this is going to be my last question!!

Thank you very much in advance again

Best regards, Rogelio

Hi Rogelio,

Using the ABF to direct some part of your traffic to the NAT and some other to be directly routed (pass-thru) based on source addresses is indeed supported, but I'm not sure it can be done in one single VRF (for both inside and outside world).

I've never seen this nor configured such a setup myself (on the contrary, the ABF setups are usually using an extra dummy VRF).

I'm afraid you will have to test first this solution since it looks like a very particular requirement.

Let us know if it works

Cheers,

N.

Hi Nicolas

We are facing a similar scenario, we are using a vrf  for the inside traffic and for the outside traffic, we are using the  global.

The traffic which need NAT (with Nat44) is  working fine, the issue that we are facing is for the traffic which dont  need the NAT, we are using ABF based on ths source (public ip), to  route the traffic from the vrf direct to the global and to route the  traffic from the global to the public ips inside the vrf, we are trying  to use route-leaking, we dont know if that is possible with the CRS  chassis and CGN.

We have done some tests but so far we could not make it work,

Thank you in advanced for your help.

Kind regards.

Gustavo

Would not it be easier if you put the outside interfaces in the same VRF to which the internal interfaces belong?

Then your packets that do not need NAT would be simply routed towards the interfaces on the same FIB and so you wouldn`t need any leaking in any of the directions of the traffic.

regards, Rogelio

One more comment, I realize that I may have create a confusion.

Only the serviceApp interface (inside) MUST be in the VRF Inside, but not necessarily the physical interfaces connecting your router to the network. You can use static routing in the global pointing to the ServiceApp in the VRF or you can use ABF to direct traffic to your serviceApp interface, but the interfaces of the router can be in the global.

Thank you very much Nicolas. I am sorry I have not answered you before.

Best regards, Rogelio

Hi Gustavo, can you share the configuration you tried?

It should work,

Thanks,

N.

Hi Nicolas,

I'd like to ask some question : I followed the configuration from this link (http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/cg_nat/configuration/guide/cgc42cgn.html
) and then I can't commit the command when I applied configuration for inside and outside address pool map :

service cgn cgn1

service-type nat44 nat1

  inside-vrf inside

   map outside-vrf outside address-pool x.x.x.x/26

there's an output of  "cgn' detected the 'warning' condition 'Host bits not set as 0'".

could you please assist me on how to fix this things since I didn't find any clue when i googling it.

many thanks for your attention

ps: i'm using 1 inside vrf map to 1 outside vrf map

Hi Adiyudha,

I found the same message when trying to configure overlapping map pools,

so please check if it's not configured in some other instance in the chassis.

If not, I'm afraid you'l have to raise a TAC case.

BR,

N.

Hi Nicholas,

thanks for your information, and yes i found it overlap.

-adiyudha

Hi Nicholas,

Again, I have another question regarding the concept and mechanism on CGN IOS XR :

- what is the keypoint / functionality of interface serviceapp & interface serviceinfra ? also how to determine the ip address because on the example i always see either 1.1.1.1/30 or 2.1.1.1/30 but i didn't see the correlation on the topology ( refers to Cisco ASR 9000 Series Aggregation Services Router Carrier Grade NAT Configuration Guide - NAT44 configuration example). can I just assume it's a dummy ip segment ?

- just wondering, how to route the packet from each serviceapps whether from inside / outside ? because you put the inside serviceapp as a default gateway and outside serviceapp as a static route.

really appreciate your response