[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Hi Just an update, Thanks for all the responces to the task. I have started to re-rollout using the LARTC section 4.2, and 4.2.2.method. My previous method was updating the main tables only. I did notice when using the "route" command the table list was not instant. I thought it was working OK, But later discovered that the defined IPs that i had appended worked but not all default routes worked The IP range 169.254. has DHCP setup and binds ip to mac address. This had been in place when i took the network role, I beleive it came about as MS default IP range. We use the the third oct value of the IP to define machine type or area, so 8 would be a SIP phone and 2 would be a server etc. One thing i am not 100% sure of is, Will routing be enough to bridge all traffic across the 2 NICs. ie traffic from 169.254.*.* and default GW 10.0.2.41. If i define a ip/32 then routing appears to work. should i be doing any iptables -jump etc to ensure defaults routes. Another thing i also want to do which have not found a how to for is a way of defining extra DHCP options like you get on MS server .ie like the TFTP server IP, IE atuo discovery etc. is there a list some which defines all the options that can be used? Regards Sam -----Original Message----- From: list-bounces@xxxxxxxxxxxxx [mailto:list-bounces@xxxxxxxxxxxxx]On Behalf Of Simon Waters Sent: 13 March 2007 13:42 To: list@xxxxxxxxxxxxx Subject: Re: [LUG] FW: What would you use for this? sam@xxxxxxxxxxxxxxxxx wrote: > Hi All > > Just thought i would post this problem to see what options would suit best. > > has anyone rolled out a multi gateway as in the attachment? First you appear to be abusing 169.254.x.x. Probably time to deploy DHCP, and allocate a random portion of 10.x.x.x to those boxes currently using 169.254.x.x. Routing, and load balancing across multiple vendors for outbound traffic is covered in LARTC section 4.2, and 4.2.2. Inbound traffic is more complex. The cheap and tacky solution is allocate 2 IP addresses to each server (either directly, or via a NAT/PAT device), and use the normal TCP connectivity behaviour to try another address if the first fails. Doesn't load balance well, doesn't fail-over quickly, but maybe good enough. The right way is to do it at the routing level, but that may require changing arrangements for the lines to use BGP, renumbering etc. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/721 - Release Date: 13/03/2007 16:51 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/721 - Release Date: 13/03/2007 16:51 -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html