01-16-2013 04:16 AM
Dear all,
I configured neftlow for CGN NAT44, an have few questions:
TIA
Samir
Solved! Go to Solution.
01-20-2013 03:11 AM
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.
01-16-2013 08:05 AM
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.
01-17-2013 12:07 AM
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
01-17-2013 07:21 AM
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.
01-17-2013 11:02 AM
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
01-20-2013 03:11 AM
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.
01-22-2013 11:55 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide