|
||||||||||
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. Jeff 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 > > |