What no bites?

-----Original Message-----
From: Olmsted, Brian 
Sent: Tuesday, March 08, 2005 2:30 PM
To: '[email protected]'
Cc: Olmsted, Brian
Subject: RE: rules for NFS with NetApp and OOW packets


Y'all

I have for the most part been able to successfully to put filters in
place but still enable NFS connections to our NetApp filer to remain.

That is, it appears that the ports that NetApp has assigned for the
various services are static (as I believe the appliance is based on
NetBSD which I understand uses static ports).

For example, on two different NetApp filers I'm seeing the same port
assignments
--------------------------------------------------
[EMAIL PROTECTED] rpcinfo -p idc-na1-svc
   program vers proto   port  service
    100011    1   udp   4049  rquotad
    100021    4   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    1   tcp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    1   udp   4045  nlockmgr
    100024    1   tcp   4047  status
    100024    1   udp   4047  status
    100005    3   tcp   4046  mountd
    100005    2   tcp   4046  mountd
    100005    1   tcp   4046  mountd
    100005    3   udp   4046  mountd
    100005    2   udp   4046  mountd
    100005    1   udp   4046  mountd
    100003    4   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   udp   2049  nfs
    100000    2   tcp    111  rpcbind
    100000    2   udp    111  rpcbind
[EMAIL PROTECTED]
--------------------------------------------------


On occasion I'm seeing packets like below popping up in the logs; seems
like "late" packets past the window of the state table possibly as they
are labeled as OOW (out of window).

Am I understanding the nature of this OOW packet?   Seeing it on SSH,
SMTP connections too I believe.


Is there anything I can do to address these?   Would one of the tweaks
for /etc/system such as ipf.fr_tcpidletimeout or ipf.fr_tcpclosed be
able to fix this and if so what value / which way (up/down?)???
--------------------------------------------------
Feb 14 05:21:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:21:01.490859 3x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 212 -AP IN OOW
Feb 14 05:23:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:23:00.593585 3x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 212 -AP IN OOW
Feb 14 05:25:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:25:00.683303 3x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 212 -AP IN OOW
Feb 14 05:27:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:27:00.771147 3x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 212 -AP IN OOW
Feb 14 05:29:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:29:00.859800 3x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 212 -AP IN OOW
Feb 14 05:30:01 bw-sc1 ipmon[146]: [ID 702911 local0.notice]
05:30:01.087643 13x bge1 @101:101 p 10.207.6.5,2049 -> 10.206.6.254,768
PR tcp len 20 156 -AP IN OOW
--------------------------------------------------


Using: Solaris 8 on a V210/V240 architecture.   IP Filter 4.1.1



------------------------------------------------------------------------
Brian Olmsted, B.Sc
Sr. Technical Specialist             Office: 416-644-7406
IP Edge Technology                   Fax:    416-640-9303
MTS Allstream Inc.                   Mobile: 647-321-5556
438 University Avenue, 412D          Pager:  [EMAIL PROTECTED]
Toronto, ON  Canada  M5G 2K8         Email:  [EMAIL PROTECTED]
------------------------------------------------------------------------

Reply via email to