cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2828
Views
0
Helpful
24
Replies

Configuring Redundancy on 3 LINKS

okoroji80
Level 1
Level 1

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

24 Replies 24

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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.

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

Best Regards Please rate all helpful posts and close solved questions

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

!

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 track 1

ip route track 2

ip route track 3

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.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

... 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

.... 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

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.

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

Best Regards Please rate all helpful posts and close solved questions

okoroji80
Level 1
Level 1

.... You mean thesame config should exist in the two routers ?

Sorry, which of the configs should be on R1 ?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card