You get into "fragmentation" issues with MTU sizes and devices that can't handle
whatever the size might be set to. MTU is a "size" setting and if something is
too big to transfer by the device trying to transfer it, then it has to be
broken into smaller parts (fragmented). I believe it is usually the VPN
Servers/Routers (concentrators) that are the failure points. The MTU should be
set to whatever the hardware "likes" (whatever that may be) and the
devices/clients should probably "agree" on what that setting should be.
That is the only way I know to view it anyway. I have not had it happen to be
so I don't have any practical experience with that issue.
--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------
"sumGirl" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Hi all! I had a weird problem this week where I could connect to one
> of my office's VPN concentrators and work just fine no problems, but
> if I connected to another concentrator in a different office then I
> could not browse file shares. We noticed lots of kerberos messages in
> a trace via the bad connection, but we could ping all the servers we
> could browse or map to (with both IP and resolved names). It wasnt
> WINS related either, we ruled that out quick.
>
> We actually founf that if we changed the MTU on the client side then
> the problem went away. Can someone just help me understand how that
> might work? I am guessing that the connection to the "good vpn
> concentrator" somehow allowed for a larger MTU awhile the patch to the
> "bad concentrator" did not?
>
> Please educate!
> -sumGirl
>
Similar Threads
Linear Mode
