creating a redundant link to a remote network using RIP

brad · ‎10-06-2016

I am trying set up redundant links to the Remote network 10.15.128.0. The switches R1 and R2 are running rip V2. vlan 17 is running over a metro e link so R1 and R3 are at one physical location while R2 and R4 are at another. R3 and R4 are provided/managed by a third parity. They are not running RIP. Inter net access is through the SonicWall and it is not running rip either.

I have tried may methods using static routes on each L3 switch for the 10.15.128.0 network. This includes using administrative distance and/ or metric. I know rip is not the best way to go, but that is what is configured in production.

The L3 Switches in my LAB system are 3650s running version 12.2(25) SEB2 the ipbase edition of the software. In the production environment they are 3750 running the universal edition of the software.

Any advice will be greatly appreciated.

R1 config

interface Vlan17
ip address 172.16.16.8 255.255.255.0
!
interface Vlan87
description Operations Center - Data VLAN
ip address 10.87.18.254 255.255.255.0

!
router rip
version 2
redistribute connected
redistribute static
passive-interface Vlan4
passive-interface Vlan5
passive-interface Vlan87
passive-interface Vlan187
network 10.0.0.0
network 172.16.0.0
network 192.168.100.0
neighbor 172.16.16.6
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.87.18.253
ip route 10.15.128.0 255.255.255.0 10.87.18.7
ip route 170.209.0.2 255.255.255.255 10.87.18.231
ip route 170.209.0.3 255.255.255.255 10.87.18.231
ip route 192.136.50.196 255.255.255.255 10.87.18.7
ip route 192.168.199.0 255.255.255.0 10.87.8.253
ip route 192.168.199.0 255.255.255.0 10.87.18.10
ip route 223.3.3.110 255.255.255.255 10.87.18.7
ip route 223.3.3.114 255.255.255.255 10.87.18.7

R2 config

interface Vlan17
ip address 172.16.16.6 255.255.255.0
!
interface Vlan86
ip address 10.86.203.252 255.255.255.0
!
router rip
version 2
redistribute connected
redistribute static
passive-interface Vlan86
passive-interface Vlan186
network 10.0.0.0
network 172.16.0.0
neighbor 172.16.16.8
no auto-summary
!
ip classless
ip route 10.15.128.0 255.255.255.0 10.86.203.7 125
ip route 172.16.1.0 255.255.255.0 10.86.203.251
ip route 172.16.253.21 255.255.255.255 10.86.93.200
ip http server

Mark Malone · ‎10-06-2016

without labbing this I cant confirm if it will exactly work but have you tried to use the offset list feature with an acl to make one side less preferred in hop count through RIP , that's a way to provide redundant path in RIP , other than that the feature itself is a bit limited to say EIGRP but that might work

Offset-list

An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via RIP. This is done to provide a local mechanism for increasing the value of routing metrics. Optionally, you can limit the offset list with either an access list or an interface.

example in this link

https://www.freeccnaworkbook.com/workbooks/ccna/configuring-rip-route-metric-offset-lists

brad · ‎10-06-2016

Yes I have tried offset-lists. As with many of the methods to manipulate the route path, it seems to work ok on devices connected to R2, but never overrides that static route on R1. I think this method only affects rip update, no anything locally defined.

I think the main problem is that routing does not seem to detect when the port on R1 that connects R3 goes down. So R1 keeps thinking he has the best route when he in fact he has no route at all at that moment.

brad · ‎10-06-2016

In doing some more testing I see the following.

Config R1

ip route 10.15.128.0 255.255.255.0 10.87.18.7

Config R2

ip route 10.15.128.0 255.255.255.0 10.86.203.7

if i "DEBUG IP RIP" on R1 I will see a routing update from 172.16.16.6 (R2);

10.15.128.0/24 via 0.0.0.0 in 1 hops

It then does a RIP Build update entry;

10.15.128.0/24 via 0.0.0.0, metric 1, tag 0

This proves that the routing update is getting to R1. The problem is that users connected to R1 go to 10.87.18.7 to get to 10.15.128.10 whiles users connected to R2 go to 10.86.203.7 to get to 10.15.125.10. This is not what is needed. We need everyone to go through 10.87.18.7 unless it is down then everyone should go to 10.86.203.7.

So I changed the config on R2 I added an administrative distance of 125 to the route:

ip route 10.15.128.0 255.255.255.0 10.86.203.7 125

Now the debug that is still running on R1 does not show a received entry for the 10.15.128.0 network.

Why?