CGN Netflow

[cisco_lad2004]

Dear all,

I configured neftlow for CGN NAT44, an have few questions:

1. I am assuming flows are sourced from Router's Loopback address. I do not seem to find specific configuration under CGN sesction.
2. What are the commands to be sued to debug or validate if flows are being recorded and sent. These are for CGN flows, not the regular Netflow data.

TIA

Samir

[Nicolas Fevrier]

Hi Samir,

1. The NF records will be sourced with the serviceInfra interface addresses, not the router loopback

2. the system doesn't allow to monitor or simply troubleshoot the NFv9 records generated (it's performed at the linux level of the card, not the IOS XR level).

You can check the number of packets sent through the serviceInfra interface, but that's pretty much it.

Kind regards,

N.

[cisco_lad2004]

Many thanks Nicolas !

I thought about that, but ignored it due to documentation stating that ServiceInfra is not routed. This interface needs to be routed if must be allowed through Firewalls for example. This leads me to another issue, security.

I secured ServiceInfra as per documentation, but it seems the ACL has not effect. I can still ping ServiceInfra from remote locations. To be accurate, .69 cannot be reached regardless of whether I am using ACL or not, .68 is reached at all times.

interface ServiceInfra1

ipv4 address 10.1.1.68 255.255.255.254

service-location 0/3/CPU0

ipv4 access-group ServiceInfraFilter egress

!

ipv4 access-list ServiceInfraFilter

10 permit ipv4 host 10.1.1.68 any

20 permit ipv4 host 10.1.1.69 any

Any thoughts ?

Samir

[Nicolas Fevrier]

Hi Samir,

The service interfaces (ServiceApp or ServiceInfra) should always be considered from the router perspective.

So your config makes sense: egress on serviceInfra, means filter from the router to the CGN card, we will allow the destinations described in line 10 and 20: 10.1.1.68 and 10.1.1.69 and will deny anything else.

I suppose that you should probably take a closer look at the routing side of things to figure out why you can't reach the .69. --> It could be that the .69 address isn't advertised, hence reachable, from the network.

Or it could be reachable from the outside, but it may be not able to reach the source of the ping on the way back.

I don't have access to my lab at the moment but should be able to make some test tomorrow to confirm the behavior.

Cheers,

N.

[cisco_lad2004]

Hi Nicolas,

am slightly confused. I assumed the idea was to not reach .68 or .69 from outside the specific /31
Also, I am unable to reach .69 when pinging from .68.

Regards

Samir

Sent from Cisco Technical Support iPad App

[Nicolas Fevrier · Accepted solution]

Hello Samir,

I did check with our engineering and here is how it works:

ipv4 access-group ServiceInfraFilter egress

---> we apply a filter from the MSC to the PLIM CGSE.

10 permit ipv4 host 10.1.1.68 any

---> we allow traffic from the MSC 10.1.1.68 to the PLIM

20 permit ipv4 host 10.1.1.69 any

---> using the online diagnostics for the data path, the cores send hello packets via ServiceInfra interface. In this case, the packets will have source IP set to 1.1.1.68 and these packets go to fabric and come back to the PLIM via the same ServiceInfra1. So traffic sourced from the 10.1.1.69 will go back into the serviceInfra1 and will be allowed by the access-list.

We have an implicit deny for the remaining packets.

Now, regarding your ping tests:

- with or without the egress ACL, you'll be able to ping 10.1.1.68 (the service infra address) because it's directly connected

- in your second ping to 10.1.1.69:

     - without the access-list: the cores will receive the icmp packets but are not designed to answer them, you don't receive any icmp replies

     - with the access-list: the cores will be protected and you won't receive anything either.

Hope it clarifies a bit,

Cheers,

N.

[cisco_lad2004]

Hi Nicolas,

Many thanks for taking time to get this thoroughly validated !

The behavior in my set up confirms that  I have things configured correctly, but I think it woudl have been nice to have a way to acertain if tis doing excately what it says. By having no response from 10.1.1.69 not responding regardeless of whether an ACL is applied or not does cloud things slightly.

Once again, many thanks !

Samir