ABF ingress / NAT

TuralLachinov · ‎07-14-2015

Hello,

I am using VSM for NAT on the Core ASR 9k for pppoe subscribers prefixes received through bgp/vpnv4. Everything is working fine.

Now I am trying to nat my local connected subnets on the Core ASR 9k, but it is not working.I am using abf for redirecting my connected interface to

the VSM, but it is not working. Here is the config,

I am trying to nat my 172.16.5.0/24, but it is not working CG NAT for pppoe subscribers is working .please advice

ipv4 access-list NAT_ABF

10 permit ipv4 172.16.5.0 0.0.0.255 any nexthop1 vrf inside ipv4 2.2.2.1

!

interface ServiceApp1

vrf inside

ipv4 address 2.2.2.1 255.255.255.252

service cgn aztcgn service-type nat44

!

router static

address-family ipv4 unicast

158.x.x.0/23 ServiceApp2

158.x.x.0/23 ServiceApp4

158.x.x.0/23 ServiceApp6

158.x.x.0/23 ServiceApp8

!

vrf inside

address-family ipv4 unicast

0.0.0.0/0 ServiceApp1

!

interface Bundle-Ether3.15

description *** LINK_TO_SWITCH_3850_SERVER_VLAN ***

vrf inside

ipv4 address 172.16.5.80 255.255.255.0

encapsulation dot1q 15

ipv4 access-group NAT_ABF ingress

ipv4 access-list NAT_ABF

10 permit ipv4 172.16.5.0 0.0.0.255 any nexthop1 vrf inside ipv4 2.2.2.1

!

interface ServiceApp1

vrf inside

ipv4 address 2.2.2.1 255.255.255.252

service cgn aztcgn service-type nat44

!

router static

address-family ipv4 unicast

158.x.x.0/23 ServiceApp2

158.x.x.0/23 ServiceApp4

158.x.x.0/23 ServiceApp6

158.x.x.0/23 ServiceApp8

!

vrf inside

address-family ipv4 unicast

0.0.0.0/0 ServiceApp1

!

interface Bundle-Ether3.15

description *** LINK_TO_SWITCH_3850_SERVER_VLAN ***

vrf inside

ipv4 address 172.16.5.80 255.255.255.0

encapsulation dot1q 15

ipv4 access-group NAT_ABF ingress

Tural

Aleksandar Vidakovic · ‎07-15-2015

Hi Tural,

do you see any matches on the ACL? Do you see ingress traffic on interface ServiceApp1?

Since the Bundle-Ether3.15 is already in vrf "inside" and you have a default static route to ServiceApp1, you don't need ABF on that sub-interface.

In case you haven't already, please refer to the CGN deployment guide at https://supportforums.cisco.com/docs/DOC-38784.

hth,

Aleksandar

TuralLachinov · ‎07-15-2015

Hi Aleksandr,

I changed the topology,traffic is now coming from bng/bras router through bgp/vpnv4,even i see nat translation on the core..but seems return traffic is not going back to bras through bgp/vpnv4 i assume..Traceroute on the server is displaying that traffic is stopping on the core..but as i see nat translation on the core from in to out and out to in.this means that return traffic is not working while it is working for pppoe subscribers..

Any idea?

Nitin Pabbi · ‎07-15-2015

Hi Tural,

I think config should be :-

10 permit ipv4 172.16.5.0 0.0.0.255 any nexthop1 vrf inside ipv4 2.2.2.1 ---> Here NH we can try of ServiceAP1 IP if we are doing ABH which is I believe 2.2.2.2.

I'm thinking the reasons behind this is when you configure ABF for the i2o traffic, you don’t need to do it for the o2i traffic o2i traffic must be routed to the correct Inside (default) VRF when it comes out of the Inside Service App.

Thanks

Nitin Pabbi

TuralLachinov · ‎07-15-2015

Hi Nitti,

Your option also did not help, changed NH ip to 2.2.2.2 did not work. what is interesting is that I can see nat translation, but there is not internet..

RP/0/RSP0/CPU0:AZT_CORE_2#sh cgn nat44 nat1 inside-translation protocol icmp inside-vrf inside1 inside-address 172.16.5.1 port$
Wed Jul 15 16:26:51.479 UTC
Inside-translation details
---------------------------
NAT44 instance : nat1
Inside-VRF : inside1
--------------------------------------------------------------------------------------------
Outside Protocol Inside Outside Translation Inside Outside
Address Source Source Type to to
Port Port Outside Inside
Packets Packets
--------------------------------------------------------------------------------------------
158.181.43.40 icmp 15995 16615 dynamic 117 117

===================================================================================================================================

P/0/RSP0/CPU0:AZT_CORE_2#sh cgn nat44 nat1 outside-translation protocol icmp outside-address 158.181.43.40 port start 1 end 6$
Wed Jul 15 16:26:49.742 UTC
Outside-translation details
---------------------------
NAT44 instance : nat1
Outside-VRF : default
--------------------------------------------------------------------------------------------
Inside Protocol Outside Inside Translation Inside Outside
Address Destination Destination Type to to
Port Port Outside Inside
Packets Packets
--------------------------------------------------------------------------------------------
172.16.5.1 icmp 16615 15995 dynamic 116 116

Tural

Aleksandar Vidakovic · ‎07-15-2015

Hi Tural,

outside-to-inside packet counter is incrementing, meaning that the translation is correct. You may want to check the SW and HW CEF entry for 172.16.5.1 on the VSM. Check also the NP counters on VSM for any drops that match the increment of the outside-to-inside packet counter.

What XR release are you using?

/Aleksandar

TuralLachinov · ‎07-16-2015

Hi Aleksandr,

I am using XR release 5.3.0, and I see cef entry for both ingress and egress for 172.16.5.1 client.

RP/0/RSP0/CPU0:AZT_CORE_2#sh cef 172.16.5.1 hardware ingress detail
Thu Jul 16 12:14:28.833 UTC
172.16.5.0/24, version 4508503, attached, connected, glean adjacency, internal 0x3000061 0x0 (ptr 0x71e809b8) [1], 0x0 (0x71dc9b18), 0x0 (0x0)
Updated Jul 16 11:26:54.953
Prefix Len 24, traffic index 0, precedence n/a, priority 0
gateway array (0x71c0c3a0) reference count 1, flags 0x0, source rib (7), 0 backups
[2 type 3 flags 0x8081 (0x71cd1558) ext 0x0 (0x0)]
LW-LDI[type=3, refc=1, ptr=0x71dc9b18, sh-ldi=0x71cd1558]
via Bundle-Ether3.15, 2 dependencies, weight 0, class 0 [flags 0x8]
path-idx 0 NHID 0x0 [0x7138d8a0 0x0]
glean adjacency

Load distribution: 0 (refcount 2)

Hash OK Interface Address
0 Y Bundle-Ether3.15 glean
RP/0/RSP0/CPU0:AZT_CORE_2#sh cef 172.16.5.1 hardware egress detail
Thu Jul 16 12:14:35.125 UTC
172.16.5.0/24, version 4508503, attached, connected, glean adjacency, internal 0x3000061 0x0 (ptr 0x71e809b8) [1], 0x0 (0x71dc9b18), 0x0 (0x0)
Updated Jul 16 11:26:54.953
Prefix Len 24, traffic index 0, precedence n/a, priority 0
gateway array (0x71c0c3a0) reference count 1, flags 0x0, source rib (7), 0 backups
[2 type 3 flags 0x8081 (0x71cd1558) ext 0x0 (0x0)]
LW-LDI[type=3, refc=1, ptr=0x71dc9b18, sh-ldi=0x71cd1558]
via Bundle-Ether3.15, 2 dependencies, weight 0, class 0 [flags 0x8]
path-idx 0 NHID 0x0 [0x7138d8a0 0x0]
glean adjacency

Load distribution: 0 (refcount 2)

Hash OK Interface Address
0 Y Bundle-Ether3.15 glean

Which command will display np output for vsm ?

Tural

Aleksandar Vidakovic · ‎07-16-2015

Hi Tural,

VSM is effectively a Typhoon line card with an additional service module. It uses the same FIA and NPs as the other Typhoon line cards. If the outside-to-inside translation is completed, the service module forwards the packet to one of the two NPs on the line card. This will be ingress traffic from NP's perspective. To get the SW/HW CEF entry from the VSM line card (that is the Typhoon part of it), use "sh cef 172.16.5.1 hardware ingress detai location <location_of_the_VSM_card>". All the "show controller np" commands apply to the VSM line card as well. The NP counters should help confirm whether the outside-to-inside traffic is hitting the NP and, if it does, what the NP is doing with it.

Regards,

Aleksandar