Henrik Nordstrom wrote:
> Yar Tikhiy wrote:
>
> > But if it is not the case, you must take care of the ICMP messages,
> > or the remote www-servers' TCP stacks would not be able to determine
> > the correct PMTU.
>
> This should be clients. Right? The remote www-servers should only see
> the proxy by its normal IP. As I understand it the problem is downwards
> MTU discovery to the clients using transparent proxying.
Thanx, I've noticed the mistake. This should actually be the cache :-)
Let's consider the following case:
WWW-server ====== Router #0 ====== Router #1 ----- Router #2 ====== Client
MTU 1500 || 1500 512 1500
|| 1500
Cache
When the cache and the client set up a TCP session (of course, the
client thinks that it's a session with the WWW-server :-), they
both know nothing about the link with the MTU of 512 octets. So,
they set mss (max. segment size) to 1460 in the initial TCP packets
(SYN and the reply to it) telling each other to begin with that
value of mss.
Well, the cache got some data from the WWW-server and wants to send it
to the client now. Of course, the size of the first segment sent is
1460 octets. The router #1 receives the packet, drops it and sends
back the ICMP type 3 code 4 message. But it sends the message to
the WWW-server, as the source address in the TCP packet is of
the WWW-server, not of the cache. So we get the situation when
the cache tries continuously to resend an oversized TCP packet
because it cannot determine PMTU due to lack of the ICMP messages,
while the WWW-server gets bombarded with some weird ICMP packets of
unknown nature :-)
That situation can be easily avoided if the router #0 can do policy
routing of ICMP messages based on their data field. That's because
the ICMP message being sent on some error or problem contains
a piece of the IP datagram that caused the problem. The TCP source
and destination ports fit into the piece, so we could just redirect
to the cache those ICMP packets that have the TCP packet with source
port equal to 80 in them. Unfortunately, Cisco routers cannot do that,
forcing admins to devise some bogus solutions :-)
SY, Yar
Received on Thu Jan 08 1998 - 01:39:59 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:21 MST