ASR-920-4SZ-A PBR Not working

[tsan99]

As per diagram below this is a simple setup to test PBR policy. The ASR has two ports enables, WAN & LAN. WAN is on g/0/0/0 and LAN on g0/0/1. WAN ip is dhcp from ISP router. LAN its 10.10.10.0/24 & PC connects on the same port for testing using LAN dhcp, works fine. Also using usb to link directly to router. No issues in any physical connections.

The issue is while I can ping both directions from the WAN port but I cannot ping ISP router from the LAN port (using ping xxx source yyy) so in effect LAN has no ISP access hence no internet, trying to ping from PC has the same issue. ISP router has no additional security for physical LAN connections so that is not the issue. Issue seems with the ASR and/or config.

Any help is appreciated.

config file:

!
!
!
version 16.12
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
platform punt-keepalive disable-kernel-core
platform bfd-debug-trace 1
platform xconnect load-balance-hash-algo mac-ip-instanceid
platform tcam-parity-error enable
platform tcam-threshold alarm-frequency 1
!
hostname asr920
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
logging buffered 16384 warnings
logging console critical
!
aaa new-model
!
!
!
aaa session-id common
clock timezone PST -8 0
no ip source-route
!
!
!
ip name-server 8.8.8.8 1.1.1.1
ip domain name abc.local
ip dhcp excluded-address 10.10.10.1 10.10.10.10
!
ip dhcp pool LAN
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 8.8.8.8 1.1.1.1
!
!
!
login on-success log
no ipv6 source-route
!
!
!
license udi pid ASR-920-4SZ-A sn CAT2423U19Q
license accept end user agreement
license boot level metroipaccess
no license smart enable
memory free low-watermark processor 5140
!
!
spanning-tree extend system-id
sdm prefer default
diagnostic bootup level minimal
!
!
!
redundancy
!
!
!
transceiver type all
 monitoring
!
lldp run
!
!
!
interface GigabitEthernet0/0/0
 ip address dhcp
 ip policy route-map RM-TO-ISP
 media-type rj45
 negotiation auto
!
interface GigabitEthernet0/0/1
 ip address 10.10.10.1 255.255.255.0
 media-type rj45
 negotiation auto
!
interface TenGigabitEthernet0/0/2
 no ip address
 shutdown
!
interface TenGigabitEthernet0/0/3
 no ip address
!
interface TenGigabitEthernet0/0/4
 no ip address
!
interface TenGigabitEthernet0/0/5
 no ip address
!
interface GigabitEthernet0
 description Mgmt-Interface
 vrf forwarding Mgmt-intf
 no ip address
 shutdown
 negotiation auto
!
ip local policy route-map RM-TO-ISP
ip forward-protocol nd
!
no http server
no http secure-server
ip tftp source-interface GigabitEthernet0
ip ssh version 2
ip route 0.0.0.0 0.0.0.0 192.168.1.254
ip route vrf Mgmt-intf 0.0.0.0 0.0.0.0 192.168.1.254
!
ip access-list extended ACL-TO-ISP
 10 permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255
!
logging alarm informational
!
route-map RM-TO-ISP permit 10
 match ip address ACL-TO-ISP
 match interface GigabitEthernet0/0/0
 set ip next-hop 192.168.1.254
 set ip next-hop verify-availability
!
!
!
control-plane
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
 stopbits 1
line vty 0 4
 exec-timeout 60 0
 privilege level 15
 transport input ssh
line vty 5 15
 exec-timeout 60 0
 privilege level 15
 transport input ssh
!
ztp disable
!

!
end
 

[Flavio Miranda]

@tsan99 

 when you ping the ISP router from the LAN network, the ISP does not know how to reply as it dont have the network 10.10.10.0 on its routing table.

What you can do is create a NAT overload and translate 10.10.10.0 to 192.168.1.X

[tsan99]

Flavio, thanks but ... nat config that we normally use in Cisco routers does not work with the 920 series or at least the model that I have, NAT command not accepted hence the workaround. I will try the "Ramblin Tech" recommendation, if anyone has any other ideas plz let me know, will post once I find a solution.

[MHM Cisco World]

https://community.cisco.com/t5/routing/cisco-asr-920-12cz-a-is-not-accepting-quot-ip-nat-quot-command/td-p/3950353

If that so then this platform dont support NAT check this post

MHM

[Ramblin Tech]

The ASR900/RSP2 requires “sdm prefer video” to support PBR, as only the video template allocates TCAM resources for PBR routes. Yes, it is confusing to use the video template if your use-case has nothing to do with video traffic, but that is the one that supports PBR. This may not be your config’s only issue, but it is a place to start. 

Why am I bringing this up with your ASR 920? Because the 920 is essentially a fixed-configuration router built around the RSP2. 

[MHM Cisco World]

First not need Pbr at all since both defualt route and pbr point to same next-hop

Second you need NAT overload 

MHM

[paul driver]

Hello @tsan99 
You do not require policy-based routing, but you do require either nat translation or allow your internal lan to use the same subnet being dynamically learned from your ISP, and the reason this is applicable is due to the fact the addressing you are receiving from your isp rtr is a private non routable subnet that is already network translated.

So to accomplish connectivity if nat is not applicable you could simply attach a small switch directly you your isp rtr port and share the 192.168.1.x/24 subnet for your lan users or bridge your ISP connection via your ASR.

Try the following but if this doesn’t work you may need to use BDI instread.

Cisco IRB
conf t
no ip route 0.0.0.0 0.0.0.0 192.168.1.254
bridge irb
bridge 1 protocol ieee
bridge 1 route ip

interface GigabitEthernet0/0
no ip address
no ip policy route-map
bridge-group 1

interface GigabitEthernet0/1
no ip address
bridge-group 1

interface BVI1
ip address dhcp

ip route 0.0.0.0 0.0.0.0 bvi1 dhcp

Cisco BDI
interface GigabitEthernet0/0
no ip address
no ip policy route-map
service instance 1 ethernet
encapsulation untagged
bridge-domain 1

interface GigabitEthernet0/1
no ip address
service instance 1 ethernet
encapsulation untagged
bridge-domain 1

interface BDI1
ip address dhcp

ip route 0.0.0.0 0.0.0.0 BDI 1 dhcp

[Richard Burts]

The title of the post identifies this as a problem with PBR. But the biggest problem is not PBR but is NAT. As several posts have already identified for 10.10.10.x to access outside destinations the addresses must be translated (or the inside network needs a different set of addresses which must be public - this would be a challenge).

As far as PBR is concerned there are several issues with the posted config:

- PBR should be configured on the interface where the traffic is received (which logically would be the inside interface). This config puts it on the interface where traffic will be forwarded. So move the PBR to the inside interface.

- this route map has a match for the interface. Match for the interface is used when the route map is for NAT. It is not appropriate for this situation.

- there are several references for 192.168.1.254. But nothing in the config indicates how to access this address.