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:
> 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?
> ----- 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
>> 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?
> 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