Setting up RIP for failover

My client has a requirement to setup a failover system using RIP.

The idea is that there are 2 Solaris 9 server, one of which will be production and the other standby.  If one of the servers goes down, or if the one of the servers is nominated as production (in practice they want to alternate the which is the production server once a fortnight).

A working system  of this senario was demoed using Cisco routers advertising a RIP address and naturally it all works well.

My question is how to implement this (if at all possible) under Solaris.  I've had a quick scan through the man page for routed, but I'm a little unsure as to how to setup the server to advertise a RIP address that the clients will connect to.

Can anyone help?
LVL 48
TintinAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

neteducationCommented:
Rip will automatically be active in server-mode if the machine has multiple interfaces and neigther /etc/defaultrouter nor /etc/notrouter exist.

However you can also do it manually:

ndd -set /dev/ip ip_forwarding 1 # will make solaris act as a router
/usr/sbin/in.routed -s  # will start rip-daemon in servermode

those two command should be put into a startscript after /etc/rc2.d/S69inet (which is where the thing about defaultrouter and so on are tested)
TintinAuthor Commented:
I'm still doing research on implementing in the way I need.

At this stage, I'm thinking that I need to create a new physical interface (or psdeuo interface) on each of the Solaris boxes that will be like a VIP, then depending on which server is nominated as "production", this "VIP" address is advertised via RIP, so that the Cisco router can direct traffic to the appropriate Solaris server.

What I'm not sure about, is how to advertise the address (or not advertise it).  Also, in.routed will only automatically startup if /etc/defaultrouter isn't present, however, the default gateway will always be the same, so would I be better off creating my own custom in.routed startup script?
neteducationCommented:
Well the idea of RIP is not to have a production-stanby setup. Both servers would forward packets. However if one of the servers fail then all traffic is rerouted to the other.

If you want to have the traffic only routed via one server then I would not do this with RIP, but I would take up the idea of the virtual interface. you simply route allways to the same ipaddress and the server that should be in production takes this ipaddress on his virtual interface. The other server does not use any virtual interface. No need for routing daemons in this szenario.

As for custom in.routed versus no defaultrouter.... you will need a custom script in any way... eigther to add the default router or to start the in.routed... so you can choose, whatever you like better.
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

TintinAuthor Commented:
Indeed the idea is to use a virtual interface so that it acts like a VIP.  This interface would only be active on the "production" server.  However, the routers still need to know which server to route packets to, so the active server needs to advertise its VIP via RIP (or anything else that would be suitable.  RIP was chosen as it is supported natively in Solaris with in.routed).

Keep in mind, that the idea here is not automatic failover in the event the production server blows up.  There will still be a manual step involved from the database/application side to say that the host is now production and at that point, it will bring up it's virtual interface and advertise it.

Sound feasible?
TintinAuthor Commented:
Indeed the idea is to use a virtual interface so that it acts like a VIP.  This interface would only be active on the "production" server.  However, the routers still need to know which server to route packets to, so the active server needs to advertise its VIP via RIP (or anything else that would be suitable.  RIP was chosen as it is supported natively in Solaris with in.routed).

Keep in mind, that the idea here is not automatic failover in the event the production server blows up.  There will still be a manual step involved from the database/application side to say that the host is now production and at that point, it will bring up it's virtual interface and advertise it.

Sound feasible?
TintinAuthor Commented:
Indeed the idea is to use a virtual interface so that it acts like a VIP.  This interface would only be active on the "production" server.  However, the routers still need to know which server to route packets to, so the active server needs to advertise its VIP via RIP (or anything else that would be suitable.  RIP was chosen as it is supported natively in Solaris with in.routed).

Keep in mind, that the idea here is not automatic failover in the event the production server blows up.  There will still be a manual step involved from the database/application side to say that the host is now production and at that point, it will bring up it's virtual interface and advertise it.

Sound feasible?
neteducationCommented:
yeah, right, this is about a manual failover.

Let's suppose your first solaris box has ip 1.1.1.1 and your second has 1.1.1.2
Let's further suppose you configure your router routes the packets to 1.1.1.3

Now if your first solaris box should be production then you add the 1.1.1.3 ip as a virtual interface to your solaris box 1
If your second solaris box should be production then you add the 1.1.1.3 ip address as a virtual interface to your solaris box 2

however in both cases your router routes the packets to 1.1.1.3 (which once points to solaris box 1 and once to solaris box 2), and therefore you dont need no advertising of the routes as they can be kept static.
TintinAuthor Commented:
Static routes won't work (as far as I'm aware).

If server1 and server2 share the same virtual IP address and one of them goes down, how is the router going to know to route packets to the host that is up?


I finally got an opportunity for testing in the real environment and it mostly went fine, but I'm not sure if I'm doing it as cleanly as possible.

The steps I did were:

ndd -set /dev/ip ip_forwarding 1
ifconfig eri0:1 plumb
ifconfig eri0:1 10.51.210.10 netmask 255.255.255.0 broadcast 10.51.210.255 up

ifconfig eri0 metric 3
ifconfig eri0:1 metric 2

/usr/sbin/in.routed -s

# cat /etc/gateways
ripv2
host 10.51.210.10 gateway 10.51.10.254 metric 1 active

Doing a 'rtquery' however, showed up the default route, ie: 0.0.0.0 being advertised.  I also had to change the metrics on the interfaces, to get the virtual address (eri0:1) to be a higher priority.

We're doing another test this week, so I'd like to nail this one down by then.
neteducationCommented:
Ok, not I'm kind of confused on what you want. In some of your posts you are talking about a manual failover, and in some about an automatic failover.

if you want manual failover then just do static routing and assign the static route to eigther the one or the other machine.

If you want automatic failover then you need a routing protocol. However I cant see no reason for additional interfaces then. The fact that you see the default route being advertised is expected behaviour, rip is announcing everything in the machines routing table plus the things you configure in /etc/gateways.
TintinAuthor Commented:
I'll try to explain the senario again.

There are two servers, where one will be production and the other in standby mode.  Users will connect to the production server (which ever it happens to be) using a single IP address.  The routing for this is determined by the core router (which we have no access to).

The idea is to switch over the servers on a regular basis (ie: swap production/standby modes), however, there may be a senario where the current production server blows up, in which case the standby server will become production.

This will always be a manual step due to the processes needed to setup the application.

The networking admin suggested using RIP to advertise the virtual IP address from whatever server is nominated as production, so that users are routed to the correct server.  To be safe, the standby server will disable its virtual IP address and not advertising any routes via RIP.

I was hoping there was a simple way to just advertise that single route, rather than mucking around with metrics.  While googling, I did come across a small C program that just did advertising of specific RIP routes and nothing else.  However, the code was out of date and wouldn't compile on Solaris without a lot of changes.


Does that make things clearer?
neteducationCommented:
Ok, let me take the most important parts of your posting.

>> The idea is to switch over the servers on a regular basis (ie: swap production/standby modes), however, there may be a senario where the current production server blows up, in >> which case the standby server will become production.

>> This will always be a manual step due to the processes needed to setup the application.

My conclusion (correct me if I'm wrong)

- normal situation is that both servers are up and running, one of them for production and one of them for testing.
- if the production server blows up you have manual work to convert the standby server into the production server.

If I'm correct, then you definitly dont need any routing protocol. See my Comment fom 07/07/2005 04:02PM

>> If server1 and server2 share the same virtual IP address and one of them goes down, how is the router going to know to route packets to the host that is up?

You said you have manual work to get the standbyserver into production. one step of this manual work would then be to assign the production ip address (1.1.1.3 in my example above) to the NEW production server. The router still routes to 1.1.1.3, so he does not need to be aware of any ip-change, this is just a different machine now.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
TintinAuthor Commented:
Thanks for perservering with me neteducation.

Your conclusions are mostly correct.

The one thing that is very important in this whole setup is that the swapover of the server roles is to be totally transparent to the users, ie:  they won't know which physical server they are connecting to as they will only ever use one IP address.

Note that it is very important to retain the real IP addresses of the servers, as there are several processes (monitoring, synching etc) that need to know the real address of the server.  That's why a virtual IP address has been suggested to avoid messy base IP address changes (which would effect alot of other stuff).

TintinAuthor Commented:
Time to close this off.

Everything was working fine with routed.

I'm giving my points to neteduction for the effort and suggestions offered.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.