[OpenAFS] best way to debug windows 1.7.11 cache/rx/NAT problems?
Brandon Allbery
allbery.b@gmail.com
Tue, 8 May 2012 17:37:02 -0400
--e89a8ff1c772ee8e8c04bf8d2f9d
Content-Type: text/plain; charset=UTF-8
On Tue, May 8, 2012 at 3:42 PM, Derrick Brashear <shadow@gmail.com> wrote:
> On Tue, May 8, 2012 at 3:39 PM, Brandon Allbery <allbery.b@gmail.com>
> wrote:
> > On Tue, May 8, 2012 at 2:27 PM, Derrick Brashear <shadow@gmail.com>
> wrote:
> >> the surprising thing is NAT ping should keep the port open unless
> >> 1) the timeout interval is aggressively short, like, 20 seconds.
> >> 2) there's a hard timeout on NAT at least for UDP where regardless of
> >> use, you lose your timeout.
> >
> > 3) your NAT device has a very small table for UDP mappings, which at
> least
> > some of the commercial boxes do; overflowing will cause mappings to be
> lost,
> > typically in LRU fashion.
>
> indeed, i forgot (to mention) that. but it happens.
Mostly I mentioned because (and I forgot to note this) NAT ping won't help
in that case; if anything, it might make triggering it that much more
likely to happen sooner rather than later.
--
brandon s allbery allbery.b@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
--e89a8ff1c772ee8e8c04bf8d2f9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, May 8, 2012 at 3:42 PM, Derrick Brashear <span dir=
=3D"ltr"><<a href=3D"mailto:shadow@gmail.com" target=3D"_blank">shadow@g=
mail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div class=3D"im">On Tue, May 8, 2012 at 3:39 PM, Brandon Allbery <<a hr=
ef=3D"mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br>
> On Tue, May 8, 2012 at 2:27 PM, Derrick Brashear <<a href=3D"mailto=
:shadow@gmail.com">shadow@gmail.com</a>> wrote:<br>
>> the surprising thing is NAT ping should keep the port open unless<=
br>
>> 1) the timeout interval is aggressively short, like, 20 seconds.<b=
r>
>> 2) there's a hard timeout on NAT at least for UDP where regard=
less of<br>
>> use, you lose your timeout.<br>><br>
> 3) your NAT device has a very small table for UDP mappings, which at l=
east<br>
> some of the commercial boxes do; overflowing will cause mappings to be=
lost,<br>
> typically in LRU fashion.<br>
<br>
</div>indeed, i forgot (to mention) that. but it happens.</blockquote><div>=
<br></div><div>Mostly I mentioned because (and I forgot to note this) NAT p=
ing won't help in that case; if anything, it might make triggering it t=
hat much more likely to happen sooner rather than later.</div>
</div><div><br></div>-- <br>brandon s allbery =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:allbery.b@gmail.com" targe=
t=3D"_blank">allbery.b@gmail.com</a><br>wandering unix systems administrato=
r (available) =C2=A0 =C2=A0 (412) 475-9364 vm/sms<br>
<br>
</div>
--e89a8ff1c772ee8e8c04bf8d2f9d--