[ previous ] [ next ] [ threads ]
 From:  Jeff Buehler <jeff at buehlertech dot com>
 To:  Kristian Shaw <monowall at wealdclose dot co dot uk>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem
 Date:  Mon, 20 Feb 2006 10:22:01 -0800
Hi Kris -

Well, I think I must have assumed without adequate verification that RPC 
packets were 2048 bytes!  I can't find a reference to that anywhere (to 
verify or debunk) but because I think it would have come up a million 
times before I now have to assume that they are not 2048 bytes.  Sorry 
about that - I feel bad that my general dislike for Microsoft technology 
may have clouded my judgment!  I really thought someone had pointed it 
out clearly in the mailing list this month, but if so I can't find 
reference to it.

Anyway, I'm back to MTU research then.


Kristian Shaw wrote:
> Hello,
> I would be surprised if MTU adjustments will fix things, given that 
> you have now established that large packets pass through OK.
> I am not sure about your description of the AD setup. I sounds like 
> you have one domain but I am not sure about your sites configuration.
> If you have sites connected together using slower links it is common 
> to create sites in AD, and then define a subnet to that site. Clients 
> will then use that information to locate the nearest DC/GC. Exchange 
> will also use that information to find a DC/GC. I wonder if perhaps 
> the clients/exchange aren't always locating the best DC to use?
> Can I ask, where you found that RPC packets are 2048 bytes?
> Regards,
> Kris.
> ----- Original Message ----- From: "Jeff Buehler" <jeff at buehlertech dot com>
> To: "Kristian Shaw" <monowall at wealdclose dot co dot uk>
> Cc: <m0n0wall at lists dot m0n0 dot ch>
> Sent: Monday, February 20, 2006 3:04 AM
> Subject: Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem
>> Hi Kris -
>> I will try the different timeouts tonight.  The MTU sounds like a 
>> stretch to me, since every ping test I have tun is clean at 1472 (mtu 
>> 1500) and I have seen no evidence of a fragmented packet, aside from 
>> the RPC which is a packet size of 2048.  In addition, if it were 
>> actually necessary to make those changes on every client platform I 
>> add to the network and the server itself because of a very 
>> intermittent MTU fragmentation problem, that would imply to me that 
>> something serious is broken somewhere (and I strongly doubt it is on 
>> the T1 lines in question which have operated flawlessly for several 
>> years).
>> By the way, does anyone know why RPC enforces a packet size of 2048 
>> so that it is guaranteed to  fragment across most WANs, by the way?  
>> Is this just the Microsoft RPC implementation that does this?  It 
>> seems incredibly stupid to me to create a protocol that is going to 
>> fragment off the starting block across most LANs and almost any WAN.
>> The AD configuration is very standard.  There is actually one AD 
>> "site" that replicates across 3 DCs.  So each LAN knows about the 
>> users in the other LAN as they all belong in the same "scope" (is 
>> that the correct MS terminology?).  In sites and services there is a 
>> separate subnet for each LAN with the servers correctly specified.  
>> Keep in mind that each of these LANs operates flawlessly (except for 
>> this Outlook -> Exchange issue) - I have very few events of note in a 
>> given month which is unusual for any MS network I have seen.  
>> Replication is clean, file sharing across the VPN is clean, AD log in 
>> works fine, etc.
>> I'll let you know if IPSEC lifetime changes make a difference, but it 
>> will be a bit hard to tell until next weekend when the bees are away 
>> and I can go back to the IPSEC VPN from the now working RPC over 
>> HTTPS for testing. How do I change the TCP/IP Idle timeout?
>> Jeff
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch