From: Church, Chuck (cchurch@wamnetgov.com)
Date: Thu Jun 10 2004 - 15:20:36 GMT-3
That sort of explains why enabling path MTU on the tunnel interfaces
didn't really make a difference. I'll have to give that a shot.
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Thursday, June 10, 2004 12:49 PM
To: Halliburton, Larry G.; ccielab@cox.net; ccielab@groupstudy.com
Subject: RE: Windows networking over gre tunnel interface
Windows 2000 networking has the DF bit set by default for its IPC
communications.
You can verify this by doing ping from windows server to windows client
over the GRE tunnel by setting the do not fragment bit... You will
notice that the router tells you the packet is too big and throttle down
MTU, but Windoz doesn't pay attention.
Easiest way is to policy route that traffic. Write an ACL to match IPS
and then set the DF bit.
Example,
Route-map test permit 10
Match ip address 100
Set ip DF 0
Route-map test permit 20
Ip Access-list extended 100
permit ip any any
Int x/y
Ip policy route-map test
------------------------------
Another option, but less efficient because of added overhead, is to
build another tunnel before the tunnel you currently have. Then up the
MTU of the original tunnel to 1500. This will allow the original
packets to be encapsulated in a single packet and then fragmented for
transport over the second tunnel. Yuck! But it might be necessary in
some situations.
I'd go with the first option though.
HTH,
Andy
-----Original Message-----
From: Halliburton, Larry G. [mailto:Larry.Halliburton@ngb.ang.af.mil]
Sent: Thursday, June 10, 2004 9:19 AM
To: 'ccielab@cox.net'; ccielab@groupstudy.com
Subject: RE: Windows networking over gre tunnel interface
You may be having an issue with mtu size. The initial communication
between the client and DC uses small packets. This will allow the logon
to occur. However, when data is transferred the packets are maxed out
and segmented by TCP. When a 1520 byte packet receives the overhead
required to enter a GRE tunnel it is fragmented. TCP numbers the
fragments and lets the end station
re- construct the original data. These 2 fragments consist of another
maxed out packet and a small fragment. If there is any more overhead
for that larger fragment anywhere in the network path, it will be
fragmented. The result is that TCP's numbering scheme is compromised
and the destination device is unable to reconstruct the original packet.
The solution is to reduce the mtu size on a router/firewall or even on
the client/server to 1460 or less so that you do not fragment a fragment
in your network path.
This may not be the problem, but I've learned to look at this whenever
tunnels are involved.
Hth,
Larry Halliburton
-----Original Message-----
From: ccielab@cox.net [mailto:ccielab@cox.net]
Sent: Wednesday, June 09, 2004 11:49 PM
To: ccielab@groupstudy.com
Subject: OT: Windows networking over gre tunnel interface
Dear group, please help. I have several sites that have 100M comm and
windows clients and the server is at a central location. At each site
we are using Microsoft AD and Win2k, user logon to the primary server at
the central to get their profile. I now have come into a situation
where the connection to a site is now through GRE tunnels instead of
physical comm. The cleint logs on, but the connection drops after a
minute. I thought that MS networking with 2000 is supposed to be over
IP, and lnot relying on the NBT broadcast anymore. Is there an issue
running windows login over a network with gre tunnels between the cleint
and server?
TIA
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:37 GMT-3