cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1268
Views
0
Helpful
7
Replies

dhcp wan interface gateway overriding pbr next hop

wayfaring
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

HTH

Rick

View solution in original post

7 Replies 7

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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

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

HTH

Rick

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.

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

HTH

Rick

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.

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

HTH

Rick