| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2091.1 | | 12368::thomas | The Code Warrior | Wed Jul 24 1996 13:26 | 7 |
| Windows NT is doing Path MTU discovery. It's set the DF and expects back a
datagram too big ICMP message when that packet can not be forwarded due to
a smaller link. The bridge should be smart enough to send that ICMP message.
If it isn't (or can't be configured to), Windows NT will need to configured
to send 1500 byte messages.
How one does that it not something I know.
|
| 2091.2 | | NPSS::RAUHALA | | Wed Jul 24 1996 13:52 | 8 |
| There is a problem in the DEFEB series of bridges where is will
not send back the ICMP message if it can not fragment. Now if
this was an easy fix, it would be fixed a long time ago...
The only alternative, was a "hack", where the DEFEB would always
fragment the packet, regardless of DF bit, but that has not been
implemented as of now. I beleive the 900 switch works ok.
ken
|
| 2091.3 | | NETCAD::STEFANI | | Wed Jul 24 1996 15:18 | 24 |
| >>Customer asked me about IP fragmentation of DEFPA running on WNT 3.51.
>>He uses the newest driver, V2.7.
>>DEFPA seems to be set DF (Don't Fragment) bit in it's IP packet.
>>So the ip packet from DEFPA can not be sent to ethernet through a router
>>with FDDI and Ethernet interfaces.
As Matt already stated, this is not a DEFPA HW or DEFPA.SYS driver
issue. Windows NT's TCP/IP stack and NDIS layer are responsible for
building and interpreting the FDDI IP packets, not the driver.
>>If it is true, would you please tell me how he can change value of the bit?
There might be a Registry keyword for the TCP/IP stack that would
toggle this, or perhaps it's hard-coded into the stack. I don't know.
>>Or do you need any other information (ex. about router)?
If it helps, the DEFPA.SYS driver has a keyword that can be used to
lower the driver advertised MTU size. If you're always going to be
sending max Ethernet sized packets, then this *might* help. There's
also a MTU keyword that is specific to the TCP/IP stack. That may
be even better.
- Larry
|
| 2091.4 | Thanks | TKOV51::TAGUCHI | tag | Thu Jul 25 1996 11:23 | 13 |
| >> There might be a Registry keyword for the TCP/IP stack that would
>> toggle this, or perhaps it's hard-coded into the stack. I don't know.
Thank you for your prompt reply.
It is very helpfull for me!
Best regards,
Tag
|
| 2091.5 | | KEIKI::WHITE | MIN(2�,FWIW) | Thu Jul 25 1996 16:17 | 26 |
|
From Microsofts NT3.5/3.51: TCP/IP Implementation Details
EnablePMTUDiscovery
Key:Tcpip\Parameters
Value Type:REG_DWORD - Boolean
Valid Range:0,1 (False,True)
Default: 1(True)
Description: Setting this parameter to 1 (True) causes TCP to attempt
the Maximum Transmission Unit (MTU or largest packet size) over the
path to the remote host. By discovering the Path MTU and limiting
TCP segments to this size, TCP can eliminate gragmentation at the
routers along the path that connect networks with diffeent MTU's.
Fragmentation adversely affects TCP throughput and network congestion.
Setting this parameter to 0 causes an MTU of 576 bytes to be used
for all connections that are not to machines on the local subnet.
So for routers that do not abide by all the new rules for MTU
Discovery and ICMP replies you will have to toggle or turn off
the above parameter.
Bill
|