in a general manner, consider these interfaces as SVI or "tunnels" to connect your router to the service blade.
When loaded with a CGN image, the ServiceInfra interface is used for the management of the card. It's mandatory to have it configured to be able to boot properly the card.
The ServiceApp interfaces are used to send traffic (to be NATed or CGv6ed for instance) to and from your router.
It's necessary to configure an IP address on the serviceApp interface, we configure the router side of the tunnel. All other addresses in the range will be considered to be part of the service card side.
So if you define serviceApp1 10.1.1.1/30, 10.1.1.2 will be answered by the CGN card automatically.
These serviceApps must be part of different VRFs (vrf-lite generally) or at least one in the Global routing table and another in a VRF, to avoid routing loops ----> because you'll have to use static routes to send your i2o traffic into the CGN card and to attract back your o2i traffic to guarantee a symetrical path (important in the case of stateful translation).
So, let's take an example if you define a map pool of 220.127.116.11/24 where the external addresses will be allocated to your translations.
You define serviceApp1 in VRF "Inside" with 18.104.22.168/30.
You define serviceApp2 in VRF "Outside" with 22.214.171.124/30.
You need to configure a default route in the VRF Inside pointing to serviceApp1 (or 126.96.36.199), it will send the traffic to the CGN card to be NATed.
And you need to configure a static route 188.8.131.52/24 to serviceApp2 (or 184.108.40.206) to attract the traffic in the o2i direction.
As you said, the serviceApp addresses are only significant locally to the router and don't need to be advertised to the outside, so they can be RFC1918.
Hope it clarifies a bit (not easy without diagrams to describe such principles).
i2o = input to output
o2i = output to intput
I am not sure this thread is still open. But in anycase, here is my question:
I am using an ISM card/ASR9K. Although I would prefer to use a global outisde interface, it seems that is a requirement to have at least 2 pairs of ServiceApps and 3 of them must be in a vrf.
So I can create one "dummy' pair of serviceApp and place in respective vrfs. Then add a production pair, where inside is rightfully in a vrf but outside on global ?
starting from IOS XR 4.2.3 you can use a single outside VRF.
It doesn't remove the need for two pairs of serviceApp interfaces, but it reduces the number of necessary VRFs.
service cgn cgn1
service-location preferred-active 0/1/CPU0
service-type nat44 nat1
map outsideserviceapp serviceapp2 address-pool 220.127.116.11/24
That way you can "link" several inside-vrf to the global on the outside.
This is awesome and will certainly simply the routing part.
with regards to the minum 2 pairs, can 2nd pair be a dormant or inactive one. i.e just configured to optomise ISM card use. Or does it have to be passing traffic ?
I guess my question is reflecting my lack of knowledge about the limitation and its reasons.
the two pairs of ServiceApp interfaces should be configured to reach the full system capability.
You can NOT only configure both of them and simply use one.
It's necessary to use two static routes to spread traffic among them or to rely on ABF with carefully defined address ranges to balance traffic on each pair, based on the source addresses.
We followed your advice on this thread to get a CGN up and running with a single vrf instance (IOS XR 4.2)
Everything seems to be ok but we are getting the following error:
asr#show cgn nat44 NAT444 statistics
Unable to obtain requested information Error:'cgn' detected the 'warning' condition 'The instance has not yet been configured'
We have configured the service infra interface and we have also reloaded the line card.
Plus, we don´t see this error in any guide. Could you please enlighten us?
Thank you in advance,
I've seen this message usually when I mistyped the name of my NAT44 instance,
could you please share the "sh run service cgn *" config ?
I have also seen similar issues, NAT stats would also hang.
Ensure you have added all recommnded SMUs.
Hi Samir and enrique,
Just want to share, I also encountered this issue ('The instance has not yet been configured') back then, and possibly caused by typo of your nat44 instance.
Regarding the SMU, this is the active one installed on my box :