PBR - Not Working

Unanswered Question
Nov 21st, 2009
User Badges:

Hi Rick / GP,


Help me with this post. Time to time I get into issues with PBR.

Attached is config and diagram for HQ and Branch8

PBR Config I tested is after ---- lines


All VPN between HQ and Branches are over Internet and not private lines.

All Branches access Oracle at the HQ, only for Branch8 Oracle traffic should be on dedicated Link.
Branch8 has two links.
Branch8 Link#1 = 2MB all traffic expect Oracle
Branch8 Link#2 = 1MB dedicated for Oracle

Hq Link#1 = 8MB for all traffic to all sites excluding Oracle traffic for Branch8
HQ Link#2 = 1MB Only for Oracle return traffic to Branch8

Oracle Server in Hq = 10.10.10.25
Server-Farm VLAN is configured on Core-Switch (( oracle Server is under ServerFarm VLAN))

IP range for Users at Branch 8 = 192.168.77.0/24


-------------------------------------------------
The following PBR I tested and didnt work

At Branch8 I added static Route
Ip route 10.10.10.25 255.255.255.255 tunnel 56

** Once I added this route I start getting error from Branch8, host not reachable "TTL Expired in transit"
** I removed the static route and did sh ip route 10.10.10.25 and found reachable via Tunnel56 & Tunnel55


----------------------------------------------------------------------------

At HQ on VPN Router I configured
access-list 101 permit ip 10.10.10.25 192.168.77.0 255.255.255.0

route-map Oracle_srv
match address 101
set ip next-hop tunnel 56

interface GigabitEthernet0/1
description LAN facing interface
ip policy route-map Oracle_srv


** Once I configure this all Branches cannot access Oracle, so had to remove it...


Any Help

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Sat, 11/21/2009 - 11:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello,

if you want you can edit your profile and you can use the field "tell what are you doing" to show your name if you like.

if you try to access my profile you should be able to see mine in the popup window.


first note about PBR issue:

your ACL as reported in the post is wrong


access-list 101 permit ip 10.10.10.25 192.168.77.0 255.255.255.0


it should be


access-list 101 permit ip host 10.10.10.25 192.168.77.0 0.0.0.255


this can be the cause of your problems



Hope to help

Giuseppe

Amin Shaikh Sat, 11/21/2009 - 23:57
User Badges:

Hi

I will change my profile after this post.

I change the ACL but still have same problem.


At HQ do I need the PBR on VPN Router or on CoreSW.

I have tested PBR at HQ on VPN Router.

If I need to configure PBR on CoreSW then how can I set next-hop to Tunnel

Giuseppe Larosa Sun, 11/22/2009 - 05:00
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Amin,

I cannot open the files something has gone wrong I see all files marked as queued


PBR has to be configured on the device that has defined the tunnels.

Possible issue is the order of operations between PBR and encryption process.


Hope to help

Giuseppe

Amin Shaikh Sun, 11/22/2009 - 10:50
User Badges:

Hi

     No clue why attachment shows qeued, I have attached the config

    Hope to get this resolved.

=====================================

=====================================


(((HQ)))



crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
crypto isakmp key KEYNET address 98.35.128.10
crypto isakmp key KEYNET address 92.22.108.8
crypto isakmp key KEYNET address 92.66.66.6
crypto isakmp key KEYNET address 41.200.65.122
crypto isakmp key KEYNET address 49.231.244.20
crypto isakmp key KEYNET address 54.10.66.8


crypto ipsec transform-set V2P_B1 esp-3des esp-md5-hmac
crypto ipsec transform-set V2P_B8 esp-3des esp-md5-hmac
crypto ipsec transform-set V2P_B8.1 esp-3des esp-md5-hmac



### Branch#1
crypto map V2PG 10 ipsec-isakmp
set peer 98.35.128.10
set transform-set V2P_B1
match address V2P_B1


###Branch#8
crypto map V2PG 55 ipsec-isakmp
set peer 49.231.244.20
set transform-set V2P_B8
match address V2P_B8


###Branch#8.1
crypto map V2PG 56 ipsec-isakmp
set peer 54.10.66.8
set transform-set V2P_B8.1
match address V2P_B8.1


interface Tunnel10
description V2P_B1
ip address 192.168.168.1 255.255.255.252
tunnel source GigabitEthernet0/0.5
tunnel destination 98.35.128.10
!
interface Tunnel55
description V2P_B8
  ip address 192.168.168.201 255.255.255.252
  tunnel source GigabitEthernet0/0.5
tunnel destination  49.231.244.20
!
interface Tunnel56
description V2P_B8.1
ip address 192.168.168.205 255.255.255.252
  tunnel source GigabitEthernet0/0.6
tunnel destination 54.10.66.8
!


interface Loopback1
ip address 192.199.1.1 255.255.255.255



interface GigabitEthernet0/0
no ip address
duplex full
speed 100


interface GigabitEthernet0/0.5
description 8MB Link
encapsulation dot1Q 5
ip address 200.158.6.14 255.255.255.248
crypto map V2PG
!
interface GigabitEthernet0/0.6
description 3MB Link
encapsulation dot1Q 6
ip address 198.64.64.4 255.255.255.248
crypto map V2PG
!
interface GigabitEthernet0/1
ip address 10.10.0.1 255.255.255.252
duplex full
speed 100

router eigrp 3
  network 10.10.0.1 0.0.0.0
network 192.168.168.1 0.0.0.0
network 192.168.168.201 0.0.0.0
network 192.168.168.205 0.0.0.0
distance eigrp 120 190
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 200.158.6.15
ip route 0.0.0.0 0.0.0.0 198.64.64.5   128



ip access-list extended V2P_B8
permit gre host 200.158.6.14 host 49.231.244.20


ip access-list extended V2P_B8.1
permit gre host 198.64.64.4 host 54.10.66.8



=============================================

================================================


(( BRANCH8)))



crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share


crypto isakmp key KEYNET address 200.158.6.14
crypto isakmp key KEYNET address 198.64.64.4


crypto ipsec transform-set VPN1 esp-3des esp-md5-hmac
crypto ipsec transform-set VPN2 esp-3des esp-md5-hmac




crypto map V2PG 55 ipsec-isakmp
set peer 200.158.6.14
set transform-set VPN1
match address VPN1



crypto map V2PG 56 ipsec-isakmp
set peer 198.64.64.4
set transform-set VPN2
match address VPN2



interface Tunnel55
  ip address 192.168.168.202 255.255.255.252
  tunnel source GigabitEthernet0/0.5
tunnel destination  200.158.6.14
!
interface Tunnel56
ip address 192.168.168.206 255.255.255.252
  tunnel source GigabitEthernet0/0.6
tunnel destination 198.64.64.4



interface GigabitEthernet0/0
no ip address
duplex full
speed 100


interface GigabitEthernet0/0.5
encapsulation dot1Q 5
ip address 49.231.244.20 255.255.255.248
crypto map V2PG
!
interface GigabitEthernet0/0.6
  encapsulation dot1Q 6
ip address 54.10.66.8 255.255.255.248
crypto map V2PG
!
interface GigabitEthernet0/1
ip address 192.168.76.1 255.255.255.252
  duplex full
speed 100


router eigrp 3

network 192.168.76.0 0.0.0.3
network 192.168.168.200 0.0.0.3
network 192.168.168.204 0.0.0.3
distance eigrp 120 190
no auto-summary


ip route 0.0.0.0 0.0.0.0 49.231.244.22
ip route 0.0.0.0 0.0.0.0 54.10.66.10   66



ip access-list extended VPN1
permit gre host 49.231.244.20 host 200.158.6.14


ip access-list extended VPN2
permit gre  host 54.10.66.8 host 198.64.64.4


access-list 50 permit 10.10.10.100

Attachment: 
Richard Burts Mon, 11/23/2009 - 12:17
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Amin


As Giuseppe points out the access list used at HQ is incorrect and that likely caused problems with access to the Oracle server. The specification of the server host source address was missing the mask (or theykeyword host) and the specification of the destination used a subnet mask rather than the wildcard mask that it should be (and that was the more serious error)


Also in the route map you appear to have the set ip next-hop pointing to an interface and I believe it would be better to point at the address of the peer on the other end of the tunnel.


You explain that you created a host specific static route on Br8 but that it did not work. When you removed the host specific route you found that Oracle was reachable through both tunnels. This implies that you have static default routes configured on Br8 pointing to both tunnels. This is not correct. You do not want a default route pointing to the 1 Mb link. You only want the host specific route pointing to that link.


In another post in this thread you ask whether PBR should be on the core switch or on the VPN router. In a different thread I had recommended having two different VPN routers. In that case PBR would be done on the core switch. In the design posted in this thread there is a single VPN router. In that case PBR would be on the VPN router.


Other than the first post in this thread you have not provided any PBR config info. And we know that there were problems with the original PBR config. It is not clear whether you have addressed those issues. The config info that you have posted has been the crypto info so let me comment on that part of it. In the Br8 config I see several things that I believe that you should change to get this to work. You have static default routes pointing to both tunnels. This tells the branch router to send all kinds of traffic over both links. But you want the 1 Mb link to carry only Oracle traffic. So you need to remove the static default route pointing to tunnel 56.You should replace it by either the host specific static route that I suggested or by some PBR config on Br8.


Also I note that you are running EIGRP over both tunnels. With EIGRP why do you need a default route at Br8? Will Br8 not learn all the routes that it needs from EIGRP? And if you are running EIGRP over both tunnels then it will attempt to send mixed traffic (both Oracle and non-Oracle) over both tunnels. This is not what you want to accomplish. So I suggest removing EIGRP from tunnel 56.


In looking at the configs of HQ I believe that you have the same issues that I have described at the Br8: there are static default routes pointing at both tunnels, you are running EIGRP on both tunnels.


In that other thread I had expressed my concern about trying to establish 2 seperate IPSec tunnels between the same 2 hosts and had recommended having 2 VPN routers at HQ. I still think that would be a better approach.


HTH


Rick

Amin Shaikh Mon, 11/23/2009 - 12:53
User Badges:

Hello Rick
Thank you for supporting the post & help

Our IT is still in stabilizing position and driven by business Urgent needs


On your reply I noted these
(1) Recheck the ACL and mask  [access-list 101 permit ip host 10.10.10.25 192.168.77.0 0.0.0.255 ]
(2) Set IP next-hop to Tunnel
(3) On Br8 replace static route with specific static route
(4) Remove Eigrp for Tunnel 56 at HQ and Br8
(5) 2 VPN Router at HQ


Due to Business needs and limitation from Service provider to increase Bandwidth
We would be forced to have 3rd Service Provider with 3MB on another VPN Router in coming weeks.


This also needs to hook with Br8 for all traffic as loadsharing or redundancy except Oracle.


How do you see this? and guide me in way forward.

  Thanks so much once again for the help

Giuseppe Larosa Mon, 11/23/2009 - 23:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Amin,

another aspect of initial PBR configuration is that if you want to specify an outgoing interface in a route-map used for PBR you should use the set interface command, set ip next-hop expects an IP address as parameter.


so use

set interface tunnel56


In your attached configuration there is no trace of PBR. Have you tried the configuration of initial post? I think the router should complain when you use set ip next-hop tunnel56 and shouldn't accept it.


I would consider to remove all static routes instead of removing EIGRP from the tunnels as we have discussed in the other thread you should be able to perform unequal cost load balancing with EIGRP that is not possible with static routes.


A single host static route for Oracle server on BB8 is indeed needed to override EIGRP routing.


I would leave EIGRP in place but I would use far higher metric on lower tunnel so that is not used for normal routing but it is still there in case of failure of primary GRE tunnel.


having two VPN HQ routers would move the PBR rule on the core switch this is possible; as Rick has noted two VPN HQ routers are a good choice to provide fault tolerance.


Hope to help

Giuseppe

Amin Shaikh Tue, 11/24/2009 - 07:49
User Badges:

Hi Giuseppe


Thank U for your reply. Having 3 Service Provider on Two VPN Router a good approach.

Branch8 will have 3 Tunnels from HQ. Do you see any complication on this? Getting downtime is tight so have to be careful.


Are you aware of any simulator where I can plug the config and test before applying on production Router



Thanks again

Amin Shk

Actions

This Discussion