05-24-2016 07:40 AM - edited 03-05-2019 04:05 AM
dhcp default route is taking precedence over pbr next hop in this dual wan + pbr + sla + floating static route scenario. In other offices with the same config approach for dual wan + pbr + sla + floating static route failover but with only static ip isp's I've been able to direct traffic to either isp on the fly with pbr route-map attached to the lan interface. At this office with one dhcp ip isp and one static ip isp, i put pbr policy on the lan interface and the traffic targeted by the acl on the route-map all still goes to the dhcp ip isp 1.1.1.1 unless i add static routes for the traffic pointed at 2.2.2.1 which negates the point of using the pbr. Any ideas?
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M1
c2900-universalk9-mz.SPA.152-4.M1.bin
2911#sh int G 0/1
GigabitEthernet0/1 is up, line protocol is up
Description: dhcp isp
Internet address is 1.1.1.2/28
!
2911#sh ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface processor,
B - BootP, S - Service selection gateway
DN - Default Network, T - Tracking object
L - TL1, E - OER, I - iEdge
D1 - Dot1x Vlan Network, K - MWAM Route
PP - PPP default route, MR - MRIPv6, SS - SSLVPN
H - IPe Host, ID - IPe Domain Broadcast
U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Tracked, P - permanent
Static local RIB for default
D 0.0.0.0/0 [1/0] via 1.1.1.1 [A]
T [200/0] via 2.2.2.1 [N]
!
interface GigabitEthernet0/0
description lan interface for 192.168.0.0/24 subnet hosts
ip address 192.168.0.1 255.255.255.0
ip policy route-map path-control
!
interface GigabitEthernet0/1
description wan dhcp isp
ip address dhcp
!
interface GigabitEthernet0/2
description wan static isp
ip address 2.2.2.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 2.2.2.1 200 name static-isp track 2
ip route 0.0.0.0 0.0.0.0 dhcp
!
ip nat inside source route-map DHCP_ISP_NAT interface GigabitEthernet0/1 overload
ip nat inside source route-map STATIC_ISP_NAT interface GigabitEthernet0/2 overload
!
ip access-list extended specific-traffic-acl
permit ip any object-group specific-hosts
deny ip any any
!
access-list 1 permit 192.168.0.0 0.0.0.255
access-list 101 permit ip host 1.1.1.2 object-group our-trusted-hosts
access-list 102 permit ip host 2.2.2.2 object-group our-trusted-hosts
!
ip local policy route-map LOCAL
!
ip sla 2
icmp-echo 2.2.2.1 source-interface GigabitEthernet0/2
frequency 5
ip sla schedule 2 life forever start-time now
!
route-map DHCP_ISP_NAT permit 10
match ip address 1
match interface GigabitEthernet0/1
!
route-map STATIC_ISP_NAT permit 10
match ip address 1
match interface GigabitEthernet0/2
!
!
route-map path-control permit 20
match ip address specific-traffic-acl
set ip next-hop verify-availability 2.2.2.1 1 track 2
!
route-map LOCAL permit 10
match ip address 101
set ip next-hop 1.1.1.1
!
route-map LOCAL permit 20
match ip address 102
set ip next-hop 2.2.2.1
Solved! Go to Solution.
05-25-2016 10:00 AM
Thank you for the update. If you have found a work around that is good. While it would be nice to solve the original problem sometimes we do need to accept that a work around is sufficient.
HTH
Rick
05-24-2016 08:00 AM
There may be some aspects of this situation that I do not understand yet but it seems to me that the PBR config is reasonable and should work. My first suggestion is that you check the tracking status of the interface for 2.2.2.1. If there is some reason why tracking believes that it is not up then it would explain why it is not using the PBR next hop.
HTH
Rick
05-24-2016 08:08 AM
2911#sh route-map
route-map path-control, permit, sequence 20
Match clauses:
ip address (access-lists): specific-traffic-acl
Set clauses:
ip next-hop verify-availability 2.2.2.1 1 track 2 [up]
Policy routing matches: 0 packets, 0 bytes
2911#sh track
Track 2
IP SLA 2 reachability
Reachability is Up
2 changes, last change 1w0d
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
ROUTE-MAP 0
STATIC-IP-ROUTING 0
05-24-2016 08:33 AM
Thank you for the additional information. So it is not an issue with SLA tracking. I am looking a bit more closely at the PBR logic and its acl
ip access-list extended specific-traffic-acl
permit ip any object-group specific-hosts
I do not see what is the definition of the object group specific-hosts. Can you provide clarification about that?
HTH
Rick
05-24-2016 08:50 AM
example -
object-group network specific-hosts
description voip service provider
3.3.3.0 255.255.248.0
4.4.4.0 255.255.248.0
targeted traffic on the route-map would be from 192.168.0.0/24 lan client to one of these public internet hosts. traceroute from lan client to voip provider subnets & netflow would confirm traffic is traversing dhcp isp interface rather than tracked static isp interface.
05-24-2016 09:05 AM
Thank you for the additional information. Would you post the output of the command
show access-list specific-traffic-acl
And would you post the output of the traceroute from a lan client?
HTH
Rick
05-24-2016 09:48 AM
found that putting a new route-map policy on the lan interface with identical copied/pasted config tied into same acl but using different route-map name resolves the problem. reverting back to the existing route-map on the lan interface recreates the original problem. going to consider this a fix for the time being due to time constraints, thanks.
05-25-2016 10:00 AM
Thank you for the update. If you have found a work around that is good. While it would be nice to solve the original problem sometimes we do need to accept that a work around is sufficient.
HTH
Rick
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