A
apoc7
Aktives Mitglied
- Dabei seit
- 21.02.2003
- Beiträge
- 271
- Reaktionspunkte
- 0
Nachdem ich beim Entwicklerteam von Airport wegen MTU nachgefragt habe, erhielt ich folgende Antwort:
There is no user method to change the MTU on the base station. The MTU is
negotiated by the base station with remote destinations for each connection.
It's a calculation done as needed between hosts on the internet. According
to spec there is no reason to change the MTU. The TCP session for getting a
web page should start with a request to the server for data, and then the
server starts sending large packets of data. If a router between the two
hosts (the base station and the web server) can't pass a packet that large
for some reason it should reply to the sender of the over-large packet (web
server) and tell the web server to step the packet size down to xxx.
The same would happen if the base station was sending up large chunks of
data to a remote site and a router in between couldn't handle the large
chunks. This is all transparent and usually happens flawlessly. The failure
occurs if a router in the middle of a session doesn't reply to the sender
that it can't handle packets of a certain size. The sender is never told to
send smaller packets, and the destination never receives the packets, and
the connection would fail. This is called an "MTU black hole".
A couple relevant topics on MTU.
http://docs.info.apple.com/article.html?artnum=107488
http://docs.info.apple.com/article.html?artnum=107474
When a client machine on the NAT side of the base station uses a NAT address
from the base station the MTU will automatically be set lower than the IP
1500 byte size because of overhead in the headers for the NAT transferral.
The problem you're experiencing with the base station is known not to be an
MTU issue. If you want to verify this, try DNS lookups (using Network
Utility). DNS packets are very small and wouldn't ever run into an MTU
"black hole" situation. Also, try to ping 17.254.0.91 (the IP address of
www.apple.com) using Network Utility. Again, very small packets.
What we have observed as common reports in the case of this AirPort Extreme
problem is that routes through the NAT to hosts on the WAN port (upstream
internet) cannot be created. Existing routes (such as an AIM session or
iTunes music stream) continue to function at least until the route cache
times out (60 minutes). Trying to create new routes through the NAT setup
fails, and this is what we're trying to investigate.
There is no user method to change the MTU on the base station. The MTU is
negotiated by the base station with remote destinations for each connection.
It's a calculation done as needed between hosts on the internet. According
to spec there is no reason to change the MTU. The TCP session for getting a
web page should start with a request to the server for data, and then the
server starts sending large packets of data. If a router between the two
hosts (the base station and the web server) can't pass a packet that large
for some reason it should reply to the sender of the over-large packet (web
server) and tell the web server to step the packet size down to xxx.
The same would happen if the base station was sending up large chunks of
data to a remote site and a router in between couldn't handle the large
chunks. This is all transparent and usually happens flawlessly. The failure
occurs if a router in the middle of a session doesn't reply to the sender
that it can't handle packets of a certain size. The sender is never told to
send smaller packets, and the destination never receives the packets, and
the connection would fail. This is called an "MTU black hole".
A couple relevant topics on MTU.
http://docs.info.apple.com/article.html?artnum=107488
http://docs.info.apple.com/article.html?artnum=107474
When a client machine on the NAT side of the base station uses a NAT address
from the base station the MTU will automatically be set lower than the IP
1500 byte size because of overhead in the headers for the NAT transferral.
The problem you're experiencing with the base station is known not to be an
MTU issue. If you want to verify this, try DNS lookups (using Network
Utility). DNS packets are very small and wouldn't ever run into an MTU
"black hole" situation. Also, try to ping 17.254.0.91 (the IP address of
www.apple.com) using Network Utility. Again, very small packets.
What we have observed as common reports in the case of this AirPort Extreme
problem is that routes through the NAT to hosts on the WAN port (upstream
internet) cannot be created. Existing routes (such as an AIM session or
iTunes music stream) continue to function at least until the route cache
times out (60 minutes). Trying to create new routes through the NAT setup
fails, and this is what we're trying to investigate.
) und 1min um 1 Uhr abschaltet. Und es läuft 100%ig. 
