07-14-2015 09:47 PM
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
07-15-2015 01:55 AM
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
07-15-2015 02:08 AM
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?
07-15-2015 04:03 AM
Hi Tural,
I think config should be :-
07-15-2015 04:29 AM
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
07-15-2015 07:42 AM
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
07-16-2015 12:15 AM
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
07-16-2015 08:55 AM
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
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