Tintin
asked on
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?
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?
ASKER
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?
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?
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.
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.
ASKER
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?
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?
ASKER
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?
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?
ASKER
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?
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?
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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).
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).
ASKER
Time to close this off.
Everything was working fine with routed.
I'm giving my points to neteduction for the effort and suggestions offered.
Everything was working fine with routed.
I'm giving my points to neteduction for the effort and suggestions offered.
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)