01-24-2014 08:48 AM - edited 03-04-2019 10:09 PM
What i want to achieve:
1. User 1,2,and 3 will be accessing the server resource from different locations
2. User 1, will use link A as its Primary link, B as secondary, C as tertiary such that in the event of A failing it will automatically switch over to B. IF B fails it will use link C.
3. The scenario 2 above is applicable to user 2 and 3
01-25-2014 09:21 AM
Hello
Then just to rectify my config to acheive the PBR you wish - you would still require ip sla relating you your 3 static's routes but with the same admin distance values.
server R1 R2 Users
10.1.1.1 link 1 - 2.2.2.1 - 2.2.2.2 1.1.1.0/24
link 3 - 3.3.3..1 - 3.3.3.2
link 3 - 4.4.4.1 - 4.4.4.2
R1
ip sla 1
icmp-echo 2.2.2.2 source-ip 2.2.2.1
timeout 2000
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 3.3.3.2 source-ip 3.3.3.1
timeout 2000
frequency 5
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 4.4.4.2 source-ip 4.4.4.1
timeout 2000
frequency 5
ip sla schedule 3 life forever start-time now
track 1 rtr 1
track 2 rtr 2
track 3 rtr 3
ip route 1.1.1.0 255.255.255.0 2.2.2.2 250 track 1
ip route 1.1.1.0 255.255.255.0 3.3.3.3 250 track 2
ip route 1.1.1.0 255.255.255.0 4.4.4.4 250 track 3
access-list 102 permit ip any host 1.1.1.4
access-list 103 permit ip any host 1.1.1.5
access-list 104 permit ip any host 1.1.1.6
route-map PBR permit 10
match ip address 102
set ip next-hop 2.2.2.2 3.3.3.2 4.4.4.2
set ip next-hop verify-availability
route-map PBR permit 20
match ip address 103
set ip next-hop 3.3.3.2 4.4.4.2 2.2.2.2
set ip next-hop verify-availability
route-map PBR permit 30
match ip address 104
set ip next-hop 4.4.4.2 2.2.2.2 3.3.3.2
set ip next-hop verify-availability
.
interface xxx
Description server facing interface
ip policy route-map PBR
R2
ip sla 1
icmp-echo 2.2.2.1 source-ip 2.2.2.2
timeout 2000
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 3.3.3.1 source-ip 3.3.3.2
timeout 2000
frequency 5
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 4.4.4.1 source-ip 4.4.4.2
timeout 2000
frequency 5
ip sla schedule 3 life forever start-time now
track 1 rtr 1
track 2 rtr 2
track 3 rtr 3
ip route 10.1.1.0 255.255.255.0 2.2.2.1 250 track 1
ip route 10.1.1.0 255.255.255.0 3.3.3.1 250 track 2
ip route 10.1.1.0 255.255.255.0 4.4.4.1 250 track 3
access-list 102 permit ip host 1.1.1.4 any
access-list 103 permit ip host 1.1.1.5 any
access-list 104 permit ip host 1.1.1.6 any
route-map PBR permit 10
match ip address 102
set ip next-hop 2.2.2.1 3.3.3.1 4.4.4.1
set ip next-hop verify-availability
route-map PBR permit 20
match ip address 103
set ip next-hop 3.3.3.1 4.4.4.1 2.2.2.1
set ip next-hop verify-availability
route-map PBR permit 30
match ip address 104
set ip next-hop 4.4.4.1 2.2.2.1 3.3.3.1
set ip next-hop verify-availability
interface xxx
Description User facing interface
ip policy route-map PBR
res
Paul
01-27-2014 12:26 PM
Hello Paul,
The config is actually runing however, there's a flaw in the setup.
a tracert from the User to the server and from ther server to the user shows that the route path is not consistent.
A trace to from Server to User would pass through Link A
on coming back it uses Link B.
01-27-2014 12:49 PM
Hi,
Can you upload your config so we know what are we looking at?
Problem with tracert dont have to be necessarily a problem.
I am sure you know how tracert is working. It is series of pings with incrementing value of TTL in each step.
PBR is working only for traffic which is received via interface where PBR route map is applied. When you execute tracert command, lets say from host1 to server, according to your diagram, ICMP echo packets in second step will not be policy routed. Reason for this is simple. Packets are send with TTL value 2, when packets arrive to R2, they are surely policy routed and sent to R1 via according link and TTL value is decremented to 1. After packets are received on R1, TTL is decremented to 0 so they will not be sent to final destination, but instead ICMP messages with TTL expired will be sent to source host. And this is problem, this answer can be dropped or sent back via another link because these answer will not be policy routed because they were not received via interface where PBR route map is applied. Answers are generated locally by router so local routing table is used to send answer.
Please make sure that this is not case before blaming PBR to not work
Best Regards
Please rate all helpful posts and close solved questions
01-27-2014 01:31 PM
R1#sh run
Building configuration...
!
interface GigabitEthernet0/0
description link to Server_LAN
ip address 10.255.255.1 255.255.255.0
ip policy route-map KUMASI
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
no ip address
shutdown
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/0/0
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0/1/0
no ip address
shutdown
negotiation auto
!
interface FastEthernet0/2/0
description Link B
ip address 10.20.20.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/2/1
description Link A
ip address 10.10.10.1 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.10.2
ip route 0.0.0.0 0.0.0.0 10.20.20.2 5
no ip http server
no ip http secure-server
!
!
!
ip access-list extended User_1
permit ip host 10.255.255.10 host 10.40.10.2
ip access-list extended User_2
permit ip host 10.255.255.10 host 172.16.20.2
route-map KUMASI permit 10
match ip address User_1
set ip next-hop 10.10.10.2 10.20.20.2 10.30.30.2
!
route-map KUMASI permit 20
match ip address User_2
set ip next-hop 10.20.20.2 10.30.30.2 10.10.10.2
end
R2 CONFIG
R2#sh run
Building configuration...
!
track 1 rtr 1 reachability
!
track 2 rtr 2 reachability
!
track 3 rtr 3 reachability
!
track 4 rtr 4 reachability
interface FastEthernet0/0
description Connection to LAN
ip address 10.30.30.1 255.255.255.0
ip policy route-map KUMASI
duplex auto
speed auto
!
interface FastEthernet0/0.10
description User1 VLAN
encapsulation dot1Q 10
ip address 10.40.10.1 255.255.255.0
!
interface FastEthernet0/0.20
description User2 VLAN
encapsulation dot1Q 20
ip address 172.16.20.1 255.255.255.0
!
interface FastEthernet0/0.30
description User3 VLAN
encapsulation dot1Q 30
ip address 192.168.10.1 255.255.255.0
!
interface FastEthernet0/1
ip address 10.10.10.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/3/0
description Link B
ip address 10.20.20.2 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.20.20.1
ip route 0.0.0.0 0.0.0.0 10.10.10.1
!
!
no ip http server
no ip http secure-server
!
ip access-list extended User_1
permit ip host 10.40.10.2 host 10.255.255.10
ip access-list extended User_2
permit ip host 172.16.20.2 host 10.255.255.10
!
ip sla 1
icmp-echo 10.10.10.1 source-ip 10.10.10.2
timeout 100
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.20.20.1 source-ip 10.20.20.2
timeout 100
frequency 3
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 10.10.10.1 source-ip 10.10.10.2
timeout 100
frequency 3
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo 10.20.20.1 source-ip 10.20.20.2
timeout 100
frequency 3
ip sla schedule 4 life forever start-time now
!
route-map KUMASI permit 10
match ip address User_1
set ip next-hop 10.10.10.1 10.20.20.1 10.30.30.1
!
route-map KUMASI permit 20
match ip address User_2
set ip next-hop 10.20.20.1 10.30.30.1 10.10.10.1
!
01-27-2014 02:19 PM
Hello
This config you have just posted doesn't resemble the diagram you posted earlier.
R1
1) R1 default routes have different admin values ( these should be the same) Also you haven't enable tracking on these static's of either router
2) These static routes should applied as
ip route
ip route
ip route
3) You also have to link Just 2 links to either router instead of 3 as per diagram
4) in your diagram and you 2ND post you have a switch separating R2 and the users are all in the same subnet - however in your last post you have enabled inter vlan routing on R2 and the users are now in different subnet's.and directly connected to the router
So in summary it looks like you have merge BLAUs configuration with mine and not followed the instructions we supplied.
The config I supplied was based on the information you originally posted, I have since labbed this up and it works accordingly, So looking at your last post I guess this is why you are getting a different output than you should .
res
Paul
Please don't forget to rate any posts that have been helpful.
Thanks.
01-27-2014 07:12 PM
... Yes i had to change the admin values just to accommodate certain things
i have also separated the users on R2 in a different subnet with inter vlan routing because of the number of ports on the router.
my router had limited number of ports hence the reduction in the number of links
01-28-2014 08:26 AM
.... The traffic from the user ends follow separate path as configured.
however the traffic from the server end returns via link A instead of Link B
this is the route pattern:
S* 0.0.0.0/0 [250/0] via 10.20.20.2
[250/0] via 10.10.10.2
01-29-2014 02:29 PM
Hello Blau,
the failover solution is working very fine , with user taking their respective path to reach the server.
however there is an issue with the return path of traffic.
as the traffic tend to use a different route from server to users
could it be that the route map is not intelligent enough to route traffic back via thesame route they came from.
01-31-2014 04:35 AM
Hi,
route-map is doing exactly what you told it. make sure that you configured initial and response traffic to take the same path.
If you paste here configurations from both routers we can check that with you.
Best Regards
Please rate all helpful posts and close solved questions
01-26-2014 03:50 PM
.... You mean thesame config should exist in the two routers ?
Sorry, which of the configs should be on R1 ?
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