Comment # 8
on bug 11654
from David Baril
I few notes of clarification may help.
First, I attached a second pcap file that includes the NFS mount packets also.
This allows Wireshark to decode the filenames, like nfs.name and nfs.full_name,
so it is easier to follow the trace.
Second, there are 4 packets as part of the locking handshake ... and they are
all in the example capture file.
rpc.program==100021 (NLM)
LOCK_MSG (rpc.procedure==7) lock request from client to server
LOCK_RES (rpc.procedure==12) lock response from server
UNLOCK_MSG (rpc.procedure==9) unlock request from client to server
UNLOCK_RES (rpc.procedure==14) unlock response from server
If you just use rpc.procedure as the filter, you will get multiple versions of
NLM (but there is only one version in the capture file.
If you want to filter just for NLM version 4, you can either add
"rpc.program_version==4" or you can change the rpc.procedure== clauses to
nlm.procedure_v4==
The third issue, and this is what may be confusing Service Response Time
reports.
This is a capture from a client mounting the NFS file system using a IP address
alias, assigned to a DNS round-robin group.
So the NFS requests are being sent to 10.1.41.94 (the DNS alias), but replies
are returning from 10.1.41.12.
If you check the Ethernet MAC addresses, they both resolve to
Myricom_45:07:84 (00:60:dd:45:07:84)
So you may want to use the Ethernet endpoint addresses rather than the IP
addresses.
The NFS Service Response Time reports (using packets that are not in the
example capture), handled the IP aliasing properly ... when using the TCP
protocol. I did not test with UDP/NFS
I am wondering of the NLM Service Response time reports are being confused due
to the IP alias. It is also using UDP ... but the STAT protocol Service
Response time reports worked properly with the STAT/UDP protocol and the IP
aliasing.
You are receiving this mail because:
- You are watching all bug changes.
