On 11/2/05, Vic Cross <[EMAIL PROTECTED]> wrote: > 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. Agree, I apologize for the poor use of words. However, I am still confused as to the explanation about using a routing daemon. can you be more specific as to what this is all about. We have our solution fully implemented and we have no such daemon. > > 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. Right on. We now have a solution for getting to our VIPA dummy address from the network. However, we have done nothing yet about the return IP address from our network services. Most of them would use the first eth. Source-VIPA and "ip route" will get us to the complete solution. > > > 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. Agree, we are going zVM first QTR 2006 and VSWITCH soon after. Our VIPA has done its work for our LPAR based Linux on zSeries. > > 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 >
---------------------------------------------------------------------- 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
