 |  |
>At 3:33 PM -0500 8/25/00, Jerry Pasker wrote:
Re: Would QDNS fault tolerance/load balancing work for 2 DSL ISPs - 2 QDNS - 1 webserver
From: Jerry Pasker
Date: Saturday, August 26, 2000
Time: 3:45:23 pm
>><snip>
>>
>>Assuming that the Webstar/QDNS responder system can multihome with two IP
>>addresses, the following would work;
>>Put a Webstar box, running two IPs (virtual host for each IP address,
>>sharing the same 'root' folder so they both serve up the same content) and
>>a DNS server on each DSL line running the fault tollerance with load
>>ballencing. It's quite a smart idea acutally. Just plug both DSL boxes
>>into the same ethernet hub or switch (switches are the way to go), with the
>>DNS Servers, and web server. Assign DNS#1 with a routable IP from the DSL
>>line#1, DNS#2 a routable IP from DSL line #2, and the webserver with a
>>routable IP from DSL line one, and a nother routeable IP from DSL line #2.
>>
>>Set up load ballencing/fault tollerance as normal. That's it. There's
>>nothing more that needs to be done to make this work. It's just that
>>simple. If you try and think about it too much, it just complicates things.
>>
>>If DSL line #1 dies, DNS #1 can't reach the IP address of the web server
>>that's running on DSL line #2 (duh, if it's dead, no requests will come in
>>that DSL line anyway) DNS #2 won't be able to see the webserver IP of DSL
>>line #1, and will stop sending traffic to that IP.
>>
>>This is of course, if the Webstar/QDNS responder system, that's used to
>>detect faults can also multihome. Can it?
>
>The older Responder can't, but the newer Load Balancer can.
It should work then. In theory... heh.
>
>>>>The mac will pick the fastest link automatically for outbound traffic which
>>>>may or may not suck for you. But it will listen on both subnets. I am not
>>>>sure if a definitive test has been done to see if the mac will always
>>>>answer
>>>>on the same IP as a the inbound request originated, but if anybody wants to
>>>>check it out, I have a iMac running webstar on a t1 and a cable modem
>>>>207.149.222.9 & 24.19.200.137
>>
>>
>>When I connect to 207.149.22.9, the reply comes from the same address.
>>Weather or not it's set to use the default gateway of the cable modem, I
>>cannot tell. Same with 24.19.200.137.
>
>How did you determine the source IP address of the reply?
Regular old unix ping.
[jpasker@worf jpasker]$ ping www.jabber.org
PING www.jabber.org (208.245.212.29): 56 data bytes
64 bytes from 208.245.212.29: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 208.245.212.29: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 208.245.212.29: icmp_seq=2 ttl=255 time=0.2 ms
64 bytes from 208.245.212.29: icmp_seq=3 ttl=255 time=0.3 ms
--- www.jabber.org ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
[jpasker@worf jpasker]$
If the ping reply is from a different address, it'll show up as a different
"from" address. I've seen it happen.
>
>> If you want the traffic from the
>>24.19.200.137 to go out the T-1, point the default gateway for that IP
>>interface to the T-1 gateway. OT won't let you do this inthe TCP/IP
>>control pannel, but it might in the IP seccondary addresses file. I know I
>>do it Linux, and have done it with Windoze on several occasions (DOS 7, and
>>NT varients)
>
>That shouldn't work on any OS. The gateway/router IP address is
>supposed to be on the same subnet as the IP address of the host
>interface, as defined by the subnet mask - otherwise, that interface
>has no way to contact its gateway.
>
>All machines on a subnet need to agree on the subnet mask, or there
>will be problems.
>
>>>As was stated a few days ago on WebSTAR Talk, OT 2.6 and later will
>>>use the faster link for all outbound traffic, or at least the
>>>majority of it (it may try to load-balance the two links).
>>
>>How does it know what is "The faster link". They both look like an
>>ethernet to OT.
>
>Not true. You may have heard of OT sending over-large ping packets in
>response to incoming requests. It actually pings every host it
>contacts, measuring optimal MTU and connection speed. It builds its
>own little routing table.
So it measures latency, and keeps track of network latency for each network
it talks to? When you say speed, you mean latency, right? Speed is
ambiguous. It can mean bandwidth, latency, or a combination of the two.
I'm sure you know what I'm talking about.
>
>>That doesn't make sence. The most OT can do, is send it out the link with
>>the IP that resides on the subnet of the destination address. OT will
>>allways do that regardless.
>
>That's true, if by "destination address" you mean the destination of the
>reply.
I think so.
At this point, I'm so confused, I don't even know anymore. Can someone
kindly point me to what direction is up? :-)
>
>>Example. Webserver with the IP addresses of 4.4.4.4, and 1.1.1.1. If a
>>client IP 4.4.4.5 tries to connect to 4.4.4.4, OT will reply from 4.4.4.4.
>>If a client 1.1.1.2 tries to connect to 4.4.4.4, the webserver will send a
>>reply from 4.4.4.4 to the 1.1.1.1 network. But the reply HAS to be from
>>4.4.4.4.
>
>I'm not so sure about this.
>
>I can say this much - the reply may (or may not) be marked as coming
>from 4.4.4.4, but it will actually be sent over the 1.1.1.1 subnet,
>directly. OT will act as a router.
>
>>Simple rules of TCP/IP. A reply has to come from the same IP as the request.
>
>Unfortunately, either Apple or Mentat seems to have forgotten this.
>
>>>This will occasionally cause problems.
>>>
>>>The issue is clients behind proxy or NAT servers. Most proxy/NAT
>>>servers rely on port numbers to work their magic. For those that
>>>don't, they seem to rely on the source IP address of the reply, which
>>>should match the destination of the original request - this will fail
>>>with the two-link system and current OT.
>>
>>A reply can't originate from an IP other than the source. TCP doesn't work
>>that way.
>
>Correct - originate and source being related concepts. [Actually, not
>correct - you can insert packets onto an Ethernet network with a
>spoofed source IP address.]
Yeah, I've done this before too. Then you just specify a router that's not
on the same subnet as your machine's IP address, and the packets all flood
out.
>
>>It can't send a SYN to one IP, and have another IP send back a
>>SYNACK. DNS (using UDP) won't work that way either, it'll see the reply
>>from a different IP, and drop it as a bogus reply. This is true regardless
>>of NAT setups, or OS for that matter.
>
>OK, I will admit to being a bit fuzzy on the whole SYN vs SYNACK
>thing. In defense, I will point to a Microsoft tech article
>explaining how to work around this very problem.
>
><http://support.microsoft.com/support/kb/articles/q247/6/81.asp>
>
>A brief quote:
>____________________________________________________________________
>
>This problem occurs under the following circumstances:
>
>* A Microsoft DNS server on the inside of the firewall queries an
>authoritative name server on the outside of the firewall for a record.
>
>* The external DNS server that replies to the request has a different
>source IP address than the address to which the query was sent.
>____________________________________________________________________
>
>>Maybe I'm misunderstanding the questions that have been put forth.
>
>No, I'd say you're focusing on the correct problem.
Yeah, I can see where NAT would break with DNS. NAT just doctors the IP
packet headers, it doesn't dig into the data portion of the packet. The
data portion of a DNS packet contains IP addresses of the source, and
destination, right? (I may be wrong here, I'm too lazy to dig out TCP/IP
3rd Edition)
>
>>If you want to effectvely multihome, and get all the benifits with none of
>>the hassles, get a router, (Cisco 3600 series with 128MB of RAM will do
>>fine) an Autonomous System number, and run BGP-4. I doubt most DSL
>>providers will offer a BGP feed on a DSL line though. If you truely need a
>>multihomed setup, you're best off colocateing with a multihomed ISP.
>
>Agreed on all points.
>____________________________________________________________________
>Chris Buxton Men & Mice
>cbuxton@menandmice.com We Make DNS Easy!
Messages In This Thread:
Return to Digital Point Solutions' Home Page