We help IT Professionals succeed at work.

Domain authentication extremely slow

Medium Priority
999 Views
Last Modified: 2012-05-09
I should start off by saying we have a very large network, where one side of the company has probably made changes to the AD without my knowledge that is causing these issues.

We have a branch office connected to our network through a site to site VPN, on 192.168.9.0/24, to our main datacenter at 192.168.200.0/24 which hosts our primary DC and primary exchange server. A few months ago the site started to experience issues with logging on and opening outlook, where it would take 1-5 minutes for a user to log in, or outlook to actually connect to exchange.

Our domain users are set up with local administrator accounts on their computers, and any user that has cached credentials can login in less than 2 minutes. When I was at the site, i tried logging in to a PC using my domain admin credentials, and it took about 6-7 minutes to actually log me in for the first time.

With Outlook, the first time outlook is opened on a PC it will almost always fail to connect and pop up saying a connection couldn't be established, where you can choose to retry or work offline. It's about a 50/50 chance that outlook will connect the second time if we try retry, the third try almost always works.

This isn't specific to the computers at the site, as my laptop which works perfectly fine at every other location, has the same problems when i'm on their network.

This part of our network is configured and run by an outside company, who says everything is working 100% and they can't find a problem.

I've tried:

Changing the dhcp subnet from 192.168.9.0 to 10.80.9.0
changing the dhcp to point all clients to a different set of DC's at a different datacenter, & the AD sites and services to point to those dc's
uninstalling our antivirus, symantec endpoint, as it has a network access control feature
Using wireshark to watch what happens when outlook is opened, nothing stood out to me but i'm not a networking guy. (can post a wireshark if someone wants)


Based on a microsoft kb article i found i checked and confirmed that the web client network provider is at the bottom of the list, i have not tried disabling it completely. There is no service running on port 80 on the dc's.

Anyone have any suggestions to things i can try? I pretty much have free access to change anything for the site to try and fix this problem.


edit: Also, once a user has successfully connected to the exchange server, the user can open/close outlook as much as they won't and the problem will not happen again until after a reboot.
Comment
Watch Question

Top Expert 2010

Commented:
Is there a DC in this subnet
192.168.9.0/24

if so, can you try this

dcdiag /v /e /TEST:DNS > c:\dcdiagdns.txt

Please post back results here.

Also, since you mentioned wireshark
Did you try to filter out exchange traffic form 192.168.9.0/24 to your datacenter

let us know please
Are the DC's all global catalog servers?

Author

Commented:
There is no DC at the site, it's a fairly small location.

I just ran wireshark on the local PC, and looked at packets sent between the workstation and the DC/exchange server. I'll pull a fresh wireshark log and post it in a few.

Yes all dc's are global catalog severs.
Top Expert 2010

Commented:
Can you do this from remote site from a workstation

start>run

outlook /rpcdiag

See what pops-up in the Exchange connectivity box.
Top Expert 2010

Commented:
Bryon HSenior Technical Support Analyst
CERTIFIED EXPERT
Top Expert 2010

Commented:
you might back up a second and make sure the workstations have internal dns servers set properly on the nic (or from dhcp)

if they're pointing to a dns server that doesn't exist anymore, or is otherwise unreachable/broken, the login and outlook problems will be identical to what you described.

Top Expert 2010

Commented:
Very good point @ http:#33067280

Kudos !!

Author

Commented:
The DNS servers are correct, same as the other 25 site's in my region.

I ran the rpc diag on a pc where the user already had successfully opened and connected outlook. the result looked normal:

http://img88.imageshack.us/i/outlookafterauthed.jpg/

then I did a reboot, ran it again before opening outlook:

http://img704.imageshack.us/i/outlookbeforeauthed.jpg/

it sat there for a minute, then failed, with this:

http://img413.imageshack.us/i/outlookafterfailure.jpg/

then i hit the reconnect button, and got this:

http://img251.imageshack.us/i/outlookafterreconnect.jpg/
Top Expert 2010

Commented:
You said
>> Our domain users are set up with local administrator accounts on their computers

What do you mean ?

also
Where is this DC located physically
C1-DC-01.POCOLD.INT

and
bc-ex-01.POCOLD.INT

Can you do this

 Go to command prompt from the DC and run this.

dcdiag /v /e /TEST:DNS > c:\dcdiagdns.txt

please upload the file here.

(Dont worry, we will clean-up all your attachments once the case is closed. We dont want this info. floating around ...)

Author

Commented:
We configure domain users with local accounts so that they can login to a computer when there is no DC available (wan failure, laptops, etc.) by adding a local user with our domain.

bc-dc-01 and bc-ex-01 are both located at the main datacenter, that also hosts our primary router. The branch office is 1 hop away from the main datacenter through the site to site vpn.

c1-dc-01 is located at a different branch, and is the secondary dc/dns.

wireshark of the workstation trying to connect is here: http://jeremyhicks.net/workstation.pcap

This time it failed to connect the first 2 tries, and succeeded on the third.
dcdiagdns.txt

Author

Commented:
Forgot to clarify, for the wireshark.

bc-dc-01 = 192.168.200.90
bc-ex-01 = 192.168.200.92
c1-dc-01 = 10.80.35.19
the workstation = 10.80.9.54
Top Expert 2010

Commented:
what happens when you do this from the workstation

pathping bc-dc-01

How many hops to the DC ?

Author

Commented:
workstation > site router > VPN ip > bc-dc-01
no packets lost.

i ran wireshark on c1-dc-01 as i tried to connect on the workstation.

the logs are just filled with SMB errors

http://img197.imageshack.us/img197/7928/c1dc01errors.jpg

I can host the pcap if you want, but its 50mb.
Bryon HSenior Technical Support Analyst
CERTIFIED EXPERT
Top Expert 2010

Commented:
zipped it would be 1mb
Top Expert 2010

Commented:
let me go through this.
Top Expert 2010

Commented:
hi

Your comments above:
bc-dc-01 and bc-ex-01 are both located at the main datacenter, that also hosts our primary router.
The branch office is 1 hop away from the main datacenter through the site to site vpn.

c1-dc-01 is located at a different branch, and is the secondary dc/dns.

bc-dc-01 = 192.168.200.90
bc-ex-01 = 192.168.200.92
c1-dc-01 = 10.80.35.19
the workstation = 10.80.9.54
----------------------
I filtered the wireshark log which you uploaded.
FILTER's
From workstation to DC
ip.src==10.80.9.54 and ip.dst==192.168.200.90
>> NO PACKETS

From workstation to Exchange
ip.src==10.80.9.54 and ip.dst==192.168.200.92 > No packets
>> NO PACKETS

All packets from workstation
ip.src==10.80.9.54
>> Lots of them.
All of them are goiing to c1-dc-01 = 10.80.35.19
But you mentioned that - that is the secondary DC not the main one. The main one is 192.168.200.90

I guess the reason you have slow domain authentication is may have something to do with network setup / DNS

I am trying to explore this more..
Top Expert 2010

Commented:
I noticed something which is a little odd.

TEST: Basic (Basc)
                   Microsoft(R) Windows(R) Server 2003, Standard Edition (Service Pack level: 2.0) is supported
                  NETLOGON service is running
                  kdc service is running
                  DNSCACHE service is running
                  DNS service is running
                  DC is a DNS server
                  Network adapters information:
                  Adapter [00000009] BASP Virtual Adapter:
                     MAC address is 00:19:B9:E9:62:FE
                     IP address is static
                     IP address: 192.168.200.90
                     DNS servers:
                        127.0.0.1 (<name unavailable>) [Valid]
                        Warning: 192.168.35.19 (<name unavailable>) [Invalid (unreachable)]


SUMMARY OF DNS TEST on the FOREST >

                                            Auth Basc Forw Del  Dyn  RReg Ext  
               ________________________________________________________________
            Domain: POCOLD.INT
               mtl-dc-01                    PASS PASS FAIL PASS PASS PASS n/a  
               C1-DC-01                     PASS PASS FAIL PASS PASS PASS n/a  
               mtl-DC-02                    PASS PASS n/a  n/a  n/a  PASS n/a  
               NV-DC-02                     PASS PASS FAIL PASS PASS PASS n/a  
               la-dc-01                     PASS PASS FAIL PASS PASS PASS n/a  
               la-dc-02                     PASS PASS FAIL PASS PASS PASS n/a  
               NV-DC-01                     PASS PASS FAIL PASS PASS PASS n/a  
               bc-dc-01                     PASS WARN FAIL PASS PASS PASS n/a  
         
         ......................... POCOLD.INT failed test DNS

===
COMMENT >>
Either you have forwarders or you have root hints in your DNS
The test summary lists that you dont have forwarders setup (FAIL for Forw column)
Also your root-hints are giving errors.

You might want to look into that.

=======
         Summary of test results for DNS servers used by the above domain controllers:

            DNS server: 202.12.27.33 (m.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 202.12.27.33
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 198.41.0.4 (a.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 198.41.0.4
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 198.32.64.12 (l.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 198.32.64.12
               [Error details: 1460 (Type: Win32 - Description: This operation returned because the timeout period expired.)]
               
            DNS server: 193.0.14.129 (k.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 193.0.14.129
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 192.58.128.30 (j.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.58.128.30
               [Error details: 9002 (Type: Win32 - Description: DNS server failure.)]
               
            DNS server: 192.5.5.241 (f.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.5.5.241
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 128.63.2.53 (h.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 128.63.2.53
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 128.8.10.90 (d.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 128.8.10.90
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 192.112.36.4 (g.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.112.36.4
               [Error details: 9002 (Type: Win32 - Description: DNS server failure.)]
               
            DNS server: 192.36.148.17 (i.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.36.148.17
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 192.33.4.12 (c.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.33.4.12
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 192.203.230.10 (e.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.203.230.10
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 192.228.79.201 (b.root-servers.net.)
               7 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.228.79.201
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 66.209.64.21 (<name unavailable>)
               2 test failures on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 66.209.64.21
               [Error details: 9005 (Type: Win32 - Description: DNS operation refused.)]
               
            DNS server: 192.168.35.19 (<name unavailable>)
               1 test failure on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.168.35.19
               [Error details: 1460 (Type: Win32 - Description: This operation returned because the timeout period expired.)]
               Name resolution is not functional. _ldap._tcp.POCOLD.INT. failed on the DNS server 192.168.35.19
               [Error details: 1460 (Type: Win32 - Description: This operation returned because the timeout period expired.)]
               
            DNS server: 199.7.83.42 (l.root-servers.net.)
               1 test failure on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 199.7.83.42
               [Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
               
            DNS server: 66.209.64.20 (<name unavailable>)
               1 test failure on this DNS server
               This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 66.209.64.20
               [Error details: 9005 (Type: Win32 - Description: DNS operation refused.)]
Top Expert 2010

Commented:
Jeremy
Can you check the dcdiag DNS reports and the pcap with your network guys and let us know if you get something which can give pointers towards this.

Right now your workstation is authenticating with c1-dc-01 - backup DC
http:#33068196

Please post updates.

thanks

Author

Commented:
I've fixed the wrong secondary DNS entry on bc-dc-01. c1-dc-01 was changed from 192.168.35.19 to 10.80.35.19 a few weeks ago. Well after these issues began though.

The root-hints were set up ages ago by a company we merged with, we merged into their domain, and they have always been a mess. Not really sure where they were going with those but we haven't had any issues with DNS resolution so i've left them. I can't really touch these as there are over 120 sites using this domain that i have no authority to change things for.
Top Expert 2010

Commented:
I understand.

if you can see that the new DNS is working..then try to run these tests again.

dcdiag /v /e /TEST:DNS > c:\dcdiagdns1.txt

Lets see what we get.

Author

Commented:
did it on both this time since they are going to c1-dc-01

c1-dc-01
dcdiagdnsc1dc01.txt

Author

Commented:
Top Expert 2010

Commented:
It worked :-)

All root servers are resolving too.

                                            Auth Basc Forw Del  Dyn  RReg Ext  
               ________________________________________________________________
            Domain: POCOLD.INT
               NV-DC-01                     PASS PASS PASS PASS PASS PASS n/a  
               mtl-DC-02                    PASS PASS n/a  n/a  n/a  PASS n/a  
               NV-DC-02                     PASS PASS PASS PASS PASS PASS n/a  
               bc-dc-01                     PASS PASS PASS PASS PASS PASS n/a  
               la-dc-02                     PASS PASS PASS PASS PASS PASS n/a  
               mtl-dc-01                    PASS PASS PASS PASS PASS PASS n/a  
               C1-DC-01                     PASS PASS PASS PASS PASS PASS n/a  
               la-dc-01                     PASS PASS PASS PASS PASS PASS n/a  
Top Expert 2010

Commented:
ok the above comment was for C1-DC-01
Top Expert 2010

Commented:
BC-DC-01 failed - same as the first DC diag. You need to check the DNS settings here too.


                                            Auth Basc Forw Del  Dyn  RReg Ext  
               ________________________________________________________________
            Domain: POCOLD.INT
               C1-DC-01                     PASS PASS FAIL PASS PASS PASS n/a  
               mtl-dc-01                    PASS PASS FAIL PASS PASS PASS n/a  
               la-dc-02                     PASS PASS FAIL PASS PASS PASS n/a  
               NV-DC-01                     PASS PASS FAIL PASS PASS PASS n/a  
               NV-DC-02                     PASS PASS FAIL PASS PASS PASS n/a  
               bc-dc-01                     PASS PASS FAIL PASS PASS PASS n/a  
               la-dc-01                     PASS PASS FAIL PASS PASS PASS n/a  
               mtl-DC-02                    PASS PASS n/a  n/a  n/a  PASS n/a  
Top Expert 2010

Commented:
hey.
I have to drop off a bit. please check the DNS on bc-dc-01 and post back dcdiag's.

I will check back in a few hours and let you know.

Author

Commented:
i "fixed" the problem. bc-dc-01 had an old version of the dcdiag exe, i copied the dcdiag from c1-dc-01 and ran it on bc-dc-01 and it now comes up clean on the test.
Top Expert 2010

Commented:
So how is our original problem @ slow logon ?

Author

Commented:
unchanged.

I have at least found out an easy way of checking if its working by simply doing a runas /user:** cmd

doing a runas for a user takes 2-3 minutes to open a cmd prompt.
Top Expert 2010

Commented:
so we did all DC tests and made sure that DC's are responding properly to login requests.
We found that some of the DC's were not responding properly because of some DNS resolving issues. We fixed that.

But you still have a real slow network and slow user desktops + outlook are real slow.

Author

Commented:
Its just that one site though, every other site that is set up the exact same as far as i can tell has been perfectly fine all this time.

I'm thinking more and more this is a networking issue.
Top Expert 2010

Commented:
Possibly.
I am not sure how are your routes configured.

What's the OS version of your DC's

and OS version of workstation + outlook.

Author

Commented:
server 2003, xp, outlook 2003 and outlook 2007

interestingly, my outlook 2010 beta would still take much longer than normal to connect, but never timed out. I would assume they've changed the timeout duration in 2010.
Top Expert 2010

Commented:
You can control the timeout duration in outlook 2003

Control Panel > mail  > view or change
change
> More Settings
> Advanced
Server Timeouts.

Drag the slider to extreme right.

There is something else going on here.

Can you try to do this

pathping dc_name
pathping exchange_server_name

nslookup yourdomain.com
> who is resolving now?

Author

Commented:
the pocold nslookup resolves to bc-dc-01

pathpings came up clean

http://img171.imageshack.us/img171/7657/pathpings.jpg

Author

Commented:
c1-dc-01's system log has WINS errors happening every 30 minutes since may 25, which is probably around the time that it's ip was changed.

The connection was aborted by the remote WINS. Remote WINS may not be configured to replicate with the server.

Author

Commented:
Looks like the WINS replication partner wasn't updated with the ip change. I've corrected that and started a push from bc-dc-01 to c1-dc-01.
Top Expert 2010

Commented:
I was thinking about this -- we still dont know what's causing this issue.

If you have time can you try this:
Can you disconnect the LAN cable in one of the workstations. Then shut it down
Then restart.

Try to login using local administrator. See if things are faster.
If it doesnt work the first time. Restart it one more time.

i am trying to ascertain if the PC itself is slow or it's a network issue.
If PC is slow - then we are going to go in a different direction.

WINS event logs - makes sense. Is there anyway you can upload the logs from exchange server and the 2 dc's.

Author

Commented:
It's definitely an issue that only applies when a computer has a DC available to try and authenticate against.

The site is a 2-3 hour drive from my usual office, I'll be there early next week to run more tests if i can't solve it before then. The last time I was there when this problem was happening, mine and my co-worker
's laptops, which behave normally everywhere else, were also exhibiting these same problems.

I'll pull event logs tomorrow morning.
Top Expert 2010

Commented:
Jeremy

I have a theory (I might be wrong, and please feel free to bounce this with other Sysads)

I think the reason you have a slow domain authentication is because you dont have a domain controller.
when you have a DC - all WAN connections are resolved by it's DNS.- most connections are cached. When the workstation comes looking for something - the DC solves it. The only traffic in WAN - is your DC-DC replication which doesnt generate so much traffic unless you are moving files across WAN.

Right now - all your workstations are going out right up to the third-hop and trying to find someone to authenticate.

You wont need a exchange server there. You can have exchange come in as RPC/HTTP and that will be much faster than going the WAN route.
But you definitely do need a DC - otherwise you are trusting the name resolution and other important tasks to workstations who are not much capable of doing these things.

(test this -
go here
c:\Windows\System32\drivers\etc\

open hosts and lmhosts (drag and drop in a notepad)
enter a static IP address for your DC's Exchange

bc-dc-01 = 192.168.200.90
bc-ex-01 = 192.168.200.92
c1-dc-01 = 10.80.35.19
the workstation = 10.80.9.54

See if the situation improves)

Restart the workstation and see what happens.

It's just a theory and it has legs (I hope it has legs...:-))

Let me know what you think. Bounce it off your internal IT.
Top Expert 2010

Commented:
let me know what you think.
please disregard the previous post

(that's my previous desktop experience with 5 user networks trying to think WAY ahead... :-) )
Top Expert 2010

Commented:
I mean let me know what you think about putting a DC @ branch office.

Author

Commented:
putting a DC at the site is a no go. We have a 'no servers outside the datacenters' policy. While putting a DC at the site would probably resolve the issue, it doesn't really fix the underlying cause of whatever is causing this problem.

That site went through a network overhaul in 2006 and has not been touched since. Our main DC has been in operation since probably before then, there has never been a problem with that site until just recently. Something must have been changed in the AD or network configuration somewhere that's causing this. We have over 120 locations in NA and as far as i know there isn't a DC at any of them.

The only difference between this site and the rest is that it is the only site that still uses a site to site VPN, as it is connected through 2 multi linked verizon DSL's. It's a very small site compared to most though, 4-5 workstations and 2-3 laptops at most.

Author

Commented:
I'll try adding static hosts tomorrow morning as well.
Top Expert 2010

Commented:
You mentioned this one is the only branch that uses site to site vpn.

How do the other branches connect to the dc

Author

Commented:
I don't exactly understand it myself, as far as i can tell its basically a site to site vpn on the ISP side instead of ours. So the network that comes out of the modem is already directly linked to the datacenter network. I can get more details if needed from the company that runs our network.
Top Expert 2010

Commented:
Also when you get a chance, see if there are any other entry's in the lmhosts / hosts file on workstations -> pointing to the previous IP.
A ipconfig /all - from the workstation will be helpful.

thanks
Top Expert 2010

Commented:
someone else was postulating similar design - but since you cant implement it this is for reference only.
http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1248634_mem1,00.html

I am checking what other options are there..
Commented:
When applying any PPP protocol it add overhead to the packets. The MTU settings for standard windows is 1500 bytes. If the site-to-site connection adds to those packets, they can be too big to go through your VPN pipe. This is called Maximum Segment Size Exceded.

It's like trying to shove a golf ball through a garden hose.

With MSS exceded, you must have ICMP to renegotiate the packet size and split these packets up into smaller chunks. This is called PMTUD (Packet Maximum Transmision Unit Discovery). If ICMP for segement size is disabled, you will end up with a packet that will NOT reach its destination. So, TCP will ask for those packets again and again and again. The problem being is you are flooding the VPN connection with repetitive sending of packets, as well as having to resize the packets.

Also, think of a VPN connection as adding overhead to the packet for 1) routing the packet 2) encrypting the packet.

An article you should look at is this one from Cisco:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

The anser can come in two forms:
Allow ICMP to renegotiate the packets
and/or allow your tunneling adapters to route larger packet sizes

Please NOTE: You can seriously hose up network performance by messing with these. In a large business like this with 120 sites, it is worth while to hire a consulting network engineer on this project.

Top Expert 2010

Commented:
Jeremy
How are things with this case ?

thanks
Sunny

Author

Commented:
i'm having our the company that runs our network check into the MTU settings now, will see if they can find anything.

If not i'll post up event logs and try editing the hosts file.

MTU is currently 1400

Author

Commented:
Bingo. Thanks to this thread they finally believed me that something might be wrong with the VPN tunnel and have discovered that they can't even send 1400 bytes with do not fragment over the tunnel.
Top Expert 2010

Commented:
great. thanks for the quick updates jeremy. Let me know when they resolve the MTU issues.

Author

Commented:
Well, they tried changing the mtu down to 1300 but it seemed to just make things worse, more packet errors than before now.

They're going to go over the wireshark logs over the weekend. I'll upload them if anyone else wants to take a look.

The only thing that stood out to me on them was that alot of the packets being set by the workstation were flagged with do not fragment, and were over 1300 bytes in size. Which i would guess means some of them are getting dropped?
Top Expert 2010

Commented:
The only thing that stood out to me on them was that alot of the packets being set by the workstation were flagged with do not fragment, and were over 1300 bytes in size. Which i would guess means some of them are getting dropped?

>> I will check this over the weekend.

Author

Commented:
Top Expert 2010

Commented:
I flagged a zone-advisor on this case. I hope he drops-in to assist.

Commented:
Most ISPs allow for larger packet sizes to accomodate Point to Point Protocols, Like a VPN. You might consider calling your ISP and seeing if you can use the default of a 1500 byte packet with overhead. Then change your VPN tunnel adapters to permit packets of size greater than 1500. As a result you can use the 1500 byte default packet size, and still tunnel through with the added load to the packet.

Author

Commented:
Finally this issue is resolved.

The router wasn't sending back messages to the clients that packets were being dropped because of the do not fragment flag, preventing auto negotiation of MSS.

We enabled that on the router and everything is fixed.

Thanks for the help everyone.

Commented:
Please remember that if you choose to route smaller packets, Lets say 1400. That is configured on EVERY node on the networks.

It's best to stick with the default 1500 MTU settings and see if you can make your routing adapters allow larger packets sizes, let's say 1560. That creates less work for the router to fragment the packets. Like I said, most ISPs and CLECs allow for larger packet sizes.
Top Expert 2010

Commented:
Kudos ChiefIT !!

Explore More ContentExplore courses, solutions, and other research materials related to this topic.