On 02/11/2005, at 6:38am, Yu Safin wrote:
I am not sure I understand what you are talking about. There is no
routing daemon involved. There are two methods to set up VIPA, static
using "ip route" and dynamic using quagga (zebra/ospf). Maya be you
are talking about quagga, which does require both the zebra and ospfd
daemons to be running.
Some more clarity required.
The configuration of VIPA has nothing to do with static or dynamic
routing. VIPA is a means of providing an IP address for a system
that is independent of the physical network interfaces linking the
system to the network, so that the potential impact caused by
failures of network devices is minimised.
The routing consideration arises because the rest of the network
needs to know how to reach your VIPA address. Think of a phone
number as a (fairly imperfect) analogy: if you get a new phone
number, you have the choice of having an unlisted number that people
can only reach you on if you tell them the number, or listing
yourself in the phone book which means that people can look you up
"automatically".
So to be pedantic, it is the routing configuration required to
*support* VIPA that is set up statically using route commands or
dynamically using zebra/quagga.
There is some confussion here. The VIPA MUST be on different subnets
(i.e. the IP address assigned to your dummy0 must be on a different
subnet than your physical eth0/1/...n OSA cards.
No confusion with me: I'm glad you agree. I mentioned it because I
have seen implementations where the VIPA address is on the same
subnet as the physical interfaces (even where the VIPA is implemented
without a dummy interface, with the IP address configured as an alias/
secondary IP on one of the interfaces).
Earlier, I wrote:
Because you have multiple physical interfaces through which traffic
can
reach your VIPAs, and you want failures to be routed- around
automatically, the routing daemon tells neighbouring routers how to
reach your VIPAs. If one of your physical interfaces (or one of the
neighbouring routers) fails, the network will learn that that path is
no
longer available and your VIPA stays contactable automatically.
I believe this to be key in a VIPA implementation. Without a dynamic
routing daemon, you would have to recover manually (by recoding
static
routes, etc). IMHO, you have lost much of the value VIPA offers.
If you work with your router as pointed out then this is not the case.
With quagga (zebra/ospfd), this is an incorrect statement.
With quagga, the statement does not exist! :) I was talking about
the situation where zebra/quagga is not present.
In my opinion, the purpose of VIPA is to maximise uptime and
availability by providing a facility to *automatically* keep network
traffic flowing in the event of a hardware or network failure. My
point was that if you use VIPA without a dynamic routing daemon in
support, you will have to make manual routing changes in the event of
a failure. That probably means waking up a router guy at 3am, which
is not my idea of automatic. The use of zebra/quagga as a dynamic
routing daemon is what I'm suggesting -- in fact VIPA on z/OS (where
this concept came from for most of us) is documented as *requiring*
OSPF or RIP, if I recall.
I think we're actually saying the same things, just using different
words... :)
One thing I forgot to mention last time is for those who are running
Linux under z/VM 5.1, give more-than-serious thought to using VSWITCH
instead of Linux guests with multiple interfaces and VIPA. z/VM will
do the heavy-lifting as far as interface redundancy is concerned, and
you don't have the processor overhead of a bunch of Linux guests
chattering to each other and to the routers nor the storage overhead
of all those additional qeth devices.
Cheers,
Vic Cross
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
