You are referring to the http reply packet (or any tcp/udp traffic) as
observed on the network. I'm talking about httpd putting bits
together and asking the kernel to schedule it for delivery.
Internally on the server, before the packet reaches the tcp/ip stack,
it doesn't have a source ip address, because it didn't come from any
tcp/ip source, it was created by the application itself. The kernel
is going to decide the outbound interface to use based on the routing
table (assuming there's a choice), and it defies common sense to
suggest that that interface can then be used in the routing decision.
I'd sure be relieved if someone would back me up here, OR make me stop
before saying anything else foolish, or both...
Brad Boyer wrote:
Actually, an HTTP reply has a clearly defined source address. It came
from a connected TCP socket which by definition has both a source
address/port and a destination address/port. You can do the same with
UDP, although the notion of a "reply" is somewhat less clearly defined
there.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Brown
Sent: Friday, July 25, 2008 4:25 PM
To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list
Subject: Re: [rhelv5-list] problem with multiple interfaces not a router
Tom Sightler wrote:
So I've added a rule, with a higher priority than the main rule, which
says, if the source IP address 120.207.9.13, you should use route
table
#1, not the main route table, to determine the outbound interface and
gateway. Everything else continues to fall to the main route table.
With all due respect, this is crazy talk. ;-) It's circular logic,
or something. When a dns reply (or http reply, or echo reply, etc) is
queued for delivery, it does not HAVE a source address. By the time
it gets associated with 120.207.9.13, by the time it gets to the
physical interface, it's on it's way out, it has already been routed.
I'm sorry, you talk a good line, but I believe you're constantly
blurring the distinction between routers and multi-homed servers. (I
am however, taking my bib home with me.)
Some very good references:
http://lartc.org/howto/lartc.rpdb.html
http://lartc.org/howto/lartc.rpdb.multiple-links.html
These references are totally about routers, just as you defined them,
devices that move packets from one interface to another. They have NO
bearing on this 'multiple interfaces, not a router' discussion.
-Ed
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
