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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp