On 10/23/05, Miguel Veliz <[EMAIL PROTECTED]> wrote: > Thanks for this reply Vic, > > Thanks everyone who's helped me this issue... > > Regards, > > > Miguel Veliz > [EMAIL PROTECTED] > Novell Primary Support Engineer > Novell, Inc., The leading provider of informatioN solutions > Cellular Phone: +58-414-2379346 > Office Phone: +58-212-277-8000 > > > >>> [EMAIL PROTECTED] 10/23/05 8:23 pm >>> > Miguel Veliz wrote: > > >I read several threads on this and apparently there is a need for a > >routing daemon to be running. > >Why is there the need for a routing daemon? 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. > > > > > A routing daemon is needed to tell the other parts of your network how > to reach your VIPA(s). Ideally, for maximum availability, your VIPAs > should not be in the same subnet as any of your physical interfaces > (and > your physical interfaces should not be in the same subnet, but this is > becoming less important). Because your VIPAs are in a different > subnet, > your neighbouring router cannot reach your VIPA directly any more -- > it > needs an entry in its routing table to know how to reach the VIPAs. > 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. If you are using the "ip route" method, then you need to work with your router to tell it that the route to your dummy0 IP address is via the eth0/1/...n paths. If you are using quagga, then OSPF is going to do that for you and will register your dummy IP address with the router (s). I personally prefer the quagga method. > >What exactly should this daemon do?. Re- route incoming packets to > the > >"physical" interface that is up when the other one is down > dynamically. This is a network function. When one route is down, the other one is used. In the case of quagga, you get some load balancing as a bonus. Mind you, the load balancing is NOT on a packet by packet basis but on initiated transfers from other locations. When the route is disrupted (i.e. physical eth is down), then the traffic gets re-routed. Keep in mind that you need to also think about originating traffic (Source VIPA is one solution and IP ROUTE a better/easier method). > > > > > 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. > A dynamic routing daemon is not involved in the actual transmission of > packets. All it does is provide information to neighbouring routers > about the networks you can reach, and provide information to your own > kernel regarding the networks that other routers can reach. > > >What is IPA takeover is used for?. > > > > > IPA takeover is the capability for another host in your environment to > take on the VIPA addresses of a primary host should that primary host > become unavailable. It lets you implement a kind- of "hot- standby" > system where multiple servers running an application are available, > but > only one (the one where the VIPA is active) is receiving the traffic. > If that host fails, IPA takeover allows the IP address(es) to be > "moved" > to one of the standby hosts. > > >Is IPa for a manual take over procedure? > > > > > I'm not sure about this -- I would hope it was automatic. If it is > manual, I can think of a better way to do the same effect in an > automatic way :) > > >Do I need to set IPA takeover along with VIPA > > > > > No, IPA takeover is not required for your VIPA to work. > > >And last , any idea why I am not able to echo "1 or " to the enable > >folder. I issue the command: > > echo 1 > /sys/bus/ccwgroup/drivers/qeth/0.0.2210/ipa_takeover/enable > >The is no error shown or logged, but the set never happens. I do a > cat > >to enable and it comes back 0. > > > > > This probably means that some other configuration is required (like > setting the IP addresses that you are standby for). I suspect you > will > need to plug IP addresses into the "add4" or "add6" pseudofiles in > ipa_takeover to set it up. Otherwise, there are some driver > parameters > that can only be changed while the device is offline (fake_ll is an > example). > > Remeber that you only need to do this if you want IPA takeover > function > -- that is, you have another host that you want to service your VIPAs > in > the event of the failure of your main host. In that case, the > manipulation of the ipa_takeover nodes will happen on your backup > hosts, > not on the main host. > > I'd suggest referring to the "Linux Device Drivers" manual on > DeveloperWorks (taking my own advice I'm doing the same, since it's > been > a while since I looked at some of this). > > 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 > If you need further assistance please let me know.
---------------------------------------------------------------------- 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
