I haven't had many answers, I've actually had 2 :) Thanks to Darren Dunham to point out to the following Sun Blueprint: http://www.sun.com/blueprints/1102/806-7230.pdf What I found was that the current configuration ( test address on virtual interfaces ) is due to a series of problems from configuring the "service" IP address on virtual interfaces, it seems that things like NIS+ or Bootparamd didn't behave very well with such configuration. So if you are not planning to run a NIS server, a Jumpstart server or DHCP Server. you could use the old configuration and set the test IP addresses on the physical interfaces... but it is recommended to have the test IP addresses on logical interfaces and the "real" IP addresses on the physical ones. Something else I've noticed, Is that with the recommended configuration load balancing doesn't seem to work at all. I've monitored the outgoing traffic, making sure that 2 connection where made through the two different host-IP addresses ( hence different interfaces), and the bandwidth was divided 50%. When as with the configuration I pointed out I could be transferring 2 outgoing datastreams at the same time using 100% of both interfaces. Thanks to all! ORIGINAL QUESTION ------------------------------------------------------------------------ ------------------------------------------------------ Hi gents, This more than a problem is a collection of thoughts regarding IPMP configuration. All the documentation I've read states that the "Test IP" addresses should be set up as aliases, that is to say int0 => TEST-IP0 (no failover) GROUP1 int1 => TEST-IP1 (no failover) GROUP1 int0:1 => HOST-IP (failover) int1:1 => DUMB-IP (failover) Taking into account this configuration, the outgoing traffic will use the IP addresses TEST-IP0 providing Load Balancing As I didn't like it, I configured the IPMP as follows. int0 => TEST-IP0 (no failover) int1 => TEST-IP1 (no failover) int0:1 => HOST-IP (failover) GROUP1 Now all the packets are load balanced as well, but all the outgoing traffic is marked with the HOST-IP, which is perfect. I've checked pulling the cable and it works fine as well. Here is my configuration "ukbhu032t" is the "virtual IP" that will switch to the other interface, [ukbhu032t] [~] # cat /etc/hostname.ce0 ukbhu032t-ce0-test netmask + broadcast + group v1280 deprecated -failover up addif ukbhu032t netmask + broadcast + failover up [ukbhu032t] [~] # cat /etc/hostname.ce1 ukbhu032t-ce1-test netmask + broadcast + group v1280 deprecated -failover up This is my route table. Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.168.0.0 192.168.0.115 U 1 3119 ce0:1 192.168.0.0 192.168.0.115 U 1 0 ce0 192.168.0.0 192.168.0.115 U 1 780 ce1 224.0.0.0 192.168.0.115 U 1 0 ce0:1 default 192.168.0.1 UG 1 4 127.0.0.1 127.0.0.1 UH 3 482091 lo0 So... I don't understand why is the first configuration is the one recommended. Am I missing anything? is there any reason that I fail to see? Any comments/thought will be highly appreciated! Best regards, Kenneth Modrego UNIX Systems Administrator Europe & Africa Region Toyota Financial Services (UK) PLC Tel: +44 (0)1737 365509 Fax: +44 (0)1737 365520 mailto:kenneth.modrego@toyota-fs.com ----- Forwarded by Kenneth Modrego/TFSEUK/TFSE on 15/10/2004 12:32 ----- Kenneth Modrego <Kenneth.Modrego@toyota-fs.com> Sent by: sunmanagers-bounces@sunmanagers.org 12/10/2004 16:19 To sunmanagers@sunmanagers.org cc Subject IPMP Questions Hi gents, This more than a problem is a collection of thoughts regarding IPMP configuration. All the documentation I've read states that the "Test IP" addresses should be set up as aliases, that is to say int0 => TEST-IP0 (no failover) GROUP1 int1 => TEST-IP1 (no failover) GROUP1 int0:1 => HOST-IP (failover) int1:1 => DUMB-IP (failover) Taking into account this configuration, the outgoing traffic will use the IP addresses TEST-IP0 providing Load Balancing As I didn't like it, I configured the IPMP as follows. int0 => TEST-IP0 (no failover) int1 => TEST-IP1 (no failover) int0:1 => HOST-IP (failover) GROUP1 Now all the packets are load balanced as well, but all the outgoing traffic is marked with the HOST-IP, which is perfect. I've checked pulling the cable and it works fine as well. Here is my configuration "ukbhu032t" is the "virtual IP" that will switch to the other interface, [ukbhu032t] [~] # cat /etc/hostname.ce0 ukbhu032t-ce0-test netmask + broadcast + group v1280 deprecated -failover up addif ukbhu032t netmask + broadcast + failover up [ukbhu032t] [~] # cat /etc/hostname.ce1 ukbhu032t-ce1-test netmask + broadcast + group v1280 deprecated -failover up This is my route table. Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.168.0.0 192.168.0.115 U 1 3119 ce0:1 192.168.0.0 192.168.0.115 U 1 0 ce0 192.168.0.0 192.168.0.115 U 1 780 ce1 224.0.0.0 192.168.0.115 U 1 0 ce0:1 default 192.168.0.1 UG 1 4 127.0.0.1 127.0.0.1 UH 3 482091 lo0 So... I don't understand why is the first configuration is the one recommended. Am I missing anything? is there any reason that I fail to see? Any comments/thought will be highly appreciated! Best regards, Kenneth Modrego UNIX Systems Administrator Europe & Africa Region Toyota Financial Services (UK) PLC Tel: +44 (0)1737 365509 Fax: +44 (0)1737 365520 mailto:kenneth.modrego@toyota-fs.com This correspondence is for the intended recipient only. It may contain confidential or legally privileged information or both. No confidentiality or privilege is waived or lost by any mistransmission or unauthorised alteration during transmission. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Toyota. This message has been checked for viruses but the recipient is strongly advised to rescan the message before opening any attachments or attached executable files. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers This correspondence is for the intended recipient only. It may contain confidential or legally privileged information or both. No confidentiality or privilege is waived or lost by any mistransmission or unauthorised alteration during transmission. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Toyota. This message has been checked for viruses but the recipient is strongly advised to rescan the message before opening any attachments or attached executable files. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Fri Oct 15 07:48:56 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:38 EST