Policy based routing

[shallugarg6343]

hi Guys,

I have CISCO1921/K9 router and have two interfaces configured i.e. Gi0/0 going towards ISP and Gi0/1 going towards LAN where i have switch configured.

I am using DMVPN for WAN traffic that goes to datacenter and using Gig0/0 for internet traffic. However. we have subscription to firewalls in the cloud (GPCS) Global protect cloud firewall for internet traffic inspection.

So, i have made a tunnel towards those GPCS Firewall.

Config:-

route-map INTERNAL-TO-TU999-MAP, permit, sequence 10
Match clauses:
ip address (access-lists): INTERNAL-TO-TU999-ACL
Set clauses:
ip next-hop 172.19.164.254
Policy routing matches: 46 packets, 4492 bytes

Extended IP access list INTERNAL-TO-TU999-ACL
10 permit ip any 172.19.164.0 0.0.3.255
20 deny ip any 10.0.0.0 0.255.255.255
30 deny ip any 172.16.0.0 0.15.255.255 (29 matches)
40 deny ip any 192.168.0.0 0.0.255.255
50 permit ip any any (46 matches)

Further, i have created two sub interfaces i.e. Gi0/1.1 for LAN workstations and Gi0/1.61 for Voice subnet on the router itself.

Now, if i enable policy routing on the sub interface in Gi0/1.1, i cannot ping internet from the switch.

If i put the policy on the physical interface then i can reach internet from the switch.

Is there a solution to achive this from sub-interface point of view. 

[rampr]

Please share the configuration templates that you are using with sub-interfaces and physical interfaces ?

I assume, you have received default route from ISP - Gi-0/0 interface. Share me the source IP and destination IP address  for the ping that you are trying to reach.

[shallugarg6343]

The config of the interface which goes to ISP

interface GigabitEthernet0/0
description Spectrum-Internet - CID #xxxxxx - Support xxx-xxx-xxxx ip=
ip address 74.142.xx.xx 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow monitor GCI-NETFLOW input
ip flow monitor GCI-NETFLOW output
ip nat outside
ip virtual-reassembly in
zone-member security Untrust
duplex full
speed auto
no cdp enable
service-policy output UW-QoS
end

*****

interface GigabitEthernet0/1
description Connection to CFT-2960X
no ip address
ip helper-address 172.20.0.157
ip helper-address 172.30.0.60
ip helper-address 10.6.58.93
no ip redirects
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
zone-member security Trust
duplex full
speed 100
end 

interface GigabitEthernet0/1.1
encapsulation dot1Q 1 native
ip address 10.6.12.1 255.255.255.0
ip helper-address 172.20.0.157
ip helper-address 172.30.0.60
ip helper-address 10.6.58.93
no ip redirects
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
zone-member security Trust
delay 1000
service-policy input ENT-QoS-Mark
end

****************

interface Tunnel999
description GPCS
ip unnumbered GigabitEthernet0/1.1
zone-member security Trust
ip tcp adjust-mss 1350
load-interval 30
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 34.99.91.69
tunnel protection ipsec profile GPCS-IPSEC-PROFILE
end

***********

crypto ikev2 proposal GPCS-PROPOSAL
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy GPCS-POLICY
match address local 74.142.22.86
proposal GPCS-PROPOSAL
!
crypto ikev2 keyring GPCS-KEYRING
peer GPCS-PEER
address 34.99.91.69
pre-shared-key 9N2nskjfm234jbP
!
!
!
crypto ikev2 profile GPCS-PROFILE
match address local 74.142.22.86
match identity remote address 34.99.91.69 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local GPCS-KEYRING

route-map INTERNAL-TO-TU999-MAP, permit, sequence 10
Match clauses:
ip address (access-lists): INTERNAL-TO-TU999-ACL
Set clauses:
ip next-hop 172.19.164.254
Policy routing matches: 1211 packets, 187834 bytes

Extended IP access list INTERNAL-TO-TU999-ACL
10 permit ip any 172.19.164.0 0.0.3.255
20 deny ip any 10.0.0.0 0.255.255.255 (625 matches)
30 deny ip any 172.16.0.0 0.15.255.255 (1697 matches)
40 deny ip any 192.168.0.0 0.0.255.255
50 permit ip any any (1214 matches)

[rampr]

I understand that you are not able to reach internet from the downstream switch that is directly connected to the router.

I guess the ping traffic that you initiate is passing through  sub-interface always irrespective of where you apply the policy-map. 

That is why when you remove the policy-map from sub interface. It is working. From some reason,  the ping traffic is  getting matched with the "ACL" that you have configured with the policy map.

Have you checked the ACL counters if you send the ping traffic along with the policy-map called in sub-interface ?

May be you can run trace-route and check where did the packets travel ? It will be better you can perform live troubleshooting with the help of some one

[shallugarg6343]

just now i tried.

Once i applied the policy on the sub-interface. i tried to ping from switch and started getting drops.

CFT-2960#ping 8.8.8.8 rep 1000000000
Type escape sequence to abort.
Sending 1000000000, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!................................................
..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

it did hit the policy however traffic was dropped (OQD) (pkts dropped from output queue)

CFT-UW01#show route-map INTERNAL-TO-TU999-MAP
route-map INTERNAL-TO-TU999-MAP, permit, sequence 10
Match clauses:
ip address (access-lists): INTERNAL-TO-TU999-ACL
Set clauses:
ip next-hop 172.19.164.254
Policy routing matches: 108 packets, 15999 bytes
CFT-UW01#




Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
-----------------------------------------------------------------------------------------------------------------
Em0/0 0 0 0 0 0 0 0 0 0
* GigabitEthernet0/0 0 0 0 0 18000 11 20000 10 0
* GigabitEthernet0/1 0 0 0 0 8000 8 9000 6 0
* GigabitEthernet0/1.1 - - - - - - - - -
* GigabitEthernet0/1.61 - - - - - - - - -
* Loopback0 0 0 0 0 0 0 0 0 0
* NVI0 0 0 0 0 0 0 0 0 0
* Tunnel2 0 0 0 8 32000 11 24000 12 0
* Tunnel999 0 0 0 5 0 0 0 0 0

[rampr]

Did you meant the return traffic is getting dropped coming from Router towards switch ?

[shallugarg6343]

looks like you are correct. the return traffic is being blocked.

Will call Global Protect FW and check with them

[rampr · Accepted solution]

Did you manage to find the root cause of the issue ? 

[shallugarg6343]

Not yet. But these are the logs and if you can try understand and help

sh platform packet-trace packet all


Packet: 4 CBUG ID: 2231
Summary
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
State : DROP 48 (FirewallInvalidZone)
Timestamp
Start : 2303150253219 ns (02/20/2020 22:01:39.444399 UTC)
Stop : 2303150264929 ns (02/20/2020 22:01:39.444411 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Source : 10.6.67.10
Destination : 8.8.8.8
Protocol : 1 (ICMP)
Feature: DEBUG_COND_INPUT_PKT
Entry : Input - 0x81339474
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Lapsed time : 2080 ns
Feature: IPV4_INPUT_DST_LOOKUP_CONSUME
Entry : Input - 0x81339484
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Lapsed time : 1760 ns
Feature: IPV4_INPUT_FOR_US_MARTIAN
Entry : Input - 0x81339488
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Lapsed time : 1280 ns
Feature: IPV4_INPUT_VFR
Entry : Input - 0x813395b8
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Lapsed time : 800 ns
Feature: IPV4_INPUT_PBR
Entry : Input - 0x8137ef80
Input : GigabitEthernet0/0/1.67
Output : <unknown>
Lapsed time : 27360 ns
Feature: IPV4_INPUT_LOOKUP_PROCESS
Entry : Input - 0x8133948c
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 4480 ns
Feature: IPV4_INPUT_IPOPTIONS_PROCESS
Entry : Input - 0x813394f0
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 960 ns
Feature: IPV4_INPUT_GOTO_OUTPUT_FEATURE
Entry : Input - 0x81339560
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 5120 ns
Feature: IPV4_OUTPUT_TCP_ADJUST_MSS
Entry : Output - 0x81386ac4
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 2720 ns
Feature: ZBFW
Action : Drop
Reason : Firewall back pressure
Zone-pair name : N/A
Class-map name : N/A
Input interface : GigabitEthernet0/0/1.67
Egress interface: Tunnel999
Feature: OUTPUT_DROP_EXT
Entry : Output - 0x8133f02c
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 4480 ns
Feature: OUTPUT_DROP_EXT
Entry : Output - 0x8133f02c
Input : GigabitEthernet0/0/1.67
Output : Tunnel999
Lapsed time : 30880 ns