cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
391
Views
0
Helpful
7
Replies
Highlighted
Beginner

ABF ingress / NAT

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

7 REPLIES 7
Highlighted
Cisco Employee

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

Highlighted

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?

Highlighted

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
 
Highlighted

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

Highlighted

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

Highlighted

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

Highlighted

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