kernel-packages team mailing list archive

[Richard Laager <rlaager@xxxxxxxxxx>]

Public bug reported:

Steps to reproduce:
1) Mount NFS share from HA cluster with TCP.
2) Failover the HA cluster. (The NFS server's IP address moves from one
   machine to the other.)
3) Access the mounted NFS share.

Expected results:
Accessing the NFS mount works fine immediately.

Actual results:
Accessing the NFS mount hangs for 15 minutes. Then the TCP connection times out, a new connection is established, and it works fine again.

After the IP moves, the new server responds to the client with TCP RST
packets, just as I would expect. I would expect the client to tear down
its TCP connection immediately and re-establish a new one. But it
doesn't. Am I confused, or is this a bug?

For the duration of this test, ufw was disabled on the client machine. I
have a packet capture.

We've been using UDP instead of TCP as a work-around.

The system is running Ubuntu 14.04 with Linux 3.13.0-76-generic.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  Steps to reproduce:
  1) Mount NFS share from HA cluster with TCP.
- 2) Failover the HA cluster. (The NFS server's IP address moves from one machine to the other.)
+ 2) Failover the HA cluster. (The NFS server's IP address moves from one
+    machine to the other.)
  3) Access the mounted NFS share.
  
  Expected results:
  Accessing the NFS mount works fine immediately.
  
  Actual results:
  Accessing the NFS mount hangs for 15 minutes. Then the TCP connection times out, a new connection is established, and it works fine again.
  
- 
- After the IP moves, the new server responds to the client with TCP RST packets, just as I would expect. I would expect the client to tear down its TCP connection immediately and re-establish a new one. But it doesn't. Am I confused, or is this a bug?
+ After the IP moves, the new server responds to the client with TCP RST
+ packets, just as I would expect. I would expect the client to tear down
+ its TCP connection immediately and re-establish a new one. But it
+ doesn't. Am I confused, or is this a bug?
  
  For the duration of this test, ufw was disabled on the client machine. I
  have a packet capture.
  
  We've been using UDP instead of TCP as a work-around.

** Description changed:

  Steps to reproduce:
  1) Mount NFS share from HA cluster with TCP.
  2) Failover the HA cluster. (The NFS server's IP address moves from one
-    machine to the other.)
+    machine to the other.)
  3) Access the mounted NFS share.
  
  Expected results:
  Accessing the NFS mount works fine immediately.
  
  Actual results:
  Accessing the NFS mount hangs for 15 minutes. Then the TCP connection times out, a new connection is established, and it works fine again.
  
  After the IP moves, the new server responds to the client with TCP RST
  packets, just as I would expect. I would expect the client to tear down
  its TCP connection immediately and re-establish a new one. But it
  doesn't. Am I confused, or is this a bug?
  
  For the duration of this test, ufw was disabled on the client machine. I
  have a packet capture.
  
  We've been using UDP instead of TCP as a work-around.
+ 
+ The system is running Ubuntu 14.04 with Linux 3.13.0-76-generic.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1542826

Title:
  NFS Client Ignores TCP Resets

Status in linux package in Ubuntu:
  New

Bug description:
  Steps to reproduce:
  1) Mount NFS share from HA cluster with TCP.
  2) Failover the HA cluster. (The NFS server's IP address moves from one
     machine to the other.)
  3) Access the mounted NFS share.

  Expected results:
  Accessing the NFS mount works fine immediately.

  Actual results:
  Accessing the NFS mount hangs for 15 minutes. Then the TCP connection times out, a new connection is established, and it works fine again.

  After the IP moves, the new server responds to the client with TCP RST
  packets, just as I would expect. I would expect the client to tear
  down its TCP connection immediately and re-establish a new one. But it
  doesn't. Am I confused, or is this a bug?

  For the duration of this test, ufw was disabled on the client machine.
  I have a packet capture.

  We've been using UDP instead of TCP as a work-around.

  The system is running Ubuntu 14.04 with Linux 3.13.0-76-generic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1542826/+subscriptions