[Bug 1163513] [NEW] dbus/udev send NFS client connection out out the wrong interface

Brian Morris 1163513 at bugs.launchpad.net
Tue Apr 2 18:40:41 UTC 2013 

Public bug reported:

I apologize for being vague , but I am not certain which package is
responsible for this bug. Both dbus and udev are the most likely
candidates as both contain recent change logs that mention "Interface
00" binding. Both were upgraded during the application of all waiting
system updates for Ubuntu Server 12.04.2 LTS on 03/22/2013, and the
previous patch application before that was mid-December 2012.

After applying all waiting updates on 03/22 we began to notice that MPI
jobs were failing on our HPC clusters. This behavior was traced down to
NFS (which was not updated in this patch cycle) clients improperly
routing traffic. These clients use NFS on a VLAN that is unique to each
cluster, which is only accessible to each node on their eth1 interface.
On the nodes that would still work we noticed that the NFS mount had
bound to the client address (clientaddr) of eth1, and on the nodes that
were no longer functioning they had bound to '0.0.0.0' instead. This
behavior was proven by finding a high count of discarded packets at hop
1, as the upstream router is not aware of each cluster's internal VLAN.

I could not get this behavior to change simply by remounting, but it can
definitely change after a reboot. For one 'up' cycle the NFS mount may
bind to eth1, and on the next it may bind to 0.0.0.0 instead. Manually
configuring each node's NFS mounts in /etc/fstab to use the client
address of eth1 (clientaddr=<eth1's address>) corrects the issue, but
this extra configuration has never been needed in the past, nor can I
find any documentation regarding this change.

Here is the complete list of what was updated in this patch cycle:

dmsetup
apparmor
apport
apt
apt-transport-https
apt-utils
base-files
bind9-host
dnsutils
dpkg
gir1.2-gudev-1.0
gnupg
gpgv
grub-common
grub-pc
grub-pc-bin
grub2-common
initramfs-tools
initramfs-tools-bin
iptables
isc-dhcp-client
isc-dhcp-common
language-pack-en
language-pack-en-base
language-selector-common
libapt-inst1.4
libapt-pkg4.12
libbind9-80
libdbus-glib-1-2
libdevmapper1.02.1
libdns81
libdrm-intel1
libdrm-nouveau1a
libdrm-radeon1
libdrm2
libfreetype6
libgnutls26
libgudev-1.0-0
libisc83
libisccc80
libisccfg82
liblwres80
libmysqlclient18
libnih-dbus1
libnih1
libpciaccess0
libplymouth2
libssl1.0.0
libudev0
libxml2
linux-headers-server
linux-image-server
linux-server
man-db
mountall
mysql-common
openssl
perl
perl-base
perl-modules
plymouth
Plymouth-theme-ubuntu-text
postfix
puppet
puppet-common
python-apport
python-problem-report
sudo
ubuntu-minimal
ubuntu-standard
udev
upstart
x11-common

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1163513

Title:
  dbus/udev send NFS client connection out out the wrong interface

Status in “dbus” package in Ubuntu:
  New

Bug description:
  I apologize for being vague , but I am not certain which package is
  responsible for this bug. Both dbus and udev are the most likely
  candidates as both contain recent change logs that mention "Interface
  00" binding. Both were upgraded during the application of all waiting
  system updates for Ubuntu Server 12.04.2 LTS on 03/22/2013, and the
  previous patch application before that was mid-December 2012.

  After applying all waiting updates on 03/22 we began to notice that
  MPI jobs were failing on our HPC clusters. This behavior was traced
  down to NFS (which was not updated in this patch cycle) clients
  improperly routing traffic. These clients use NFS on a VLAN that is
  unique to each cluster, which is only accessible to each node on their
  eth1 interface. On the nodes that would still work we noticed that the
  NFS mount had bound to the client address (clientaddr) of eth1, and on
  the nodes that were no longer functioning they had bound to '0.0.0.0'
  instead. This behavior was proven by finding a high count of discarded
  packets at hop 1, as the upstream router is not aware of each
  cluster's internal VLAN.

  I could not get this behavior to change simply by remounting, but it
  can definitely change after a reboot. For one 'up' cycle the NFS mount
  may bind to eth1, and on the next it may bind to 0.0.0.0 instead.
  Manually configuring each node's NFS mounts in /etc/fstab to use the
  client address of eth1 (clientaddr=<eth1's address>) corrects the
  issue, but this extra configuration has never been needed in the past,
  nor can I find any documentation regarding this change.

  Here is the complete list of what was updated in this patch cycle:

  dmsetup
  apparmor
  apport
  apt
  apt-transport-https
  apt-utils
  base-files
  bind9-host
  dnsutils
  dpkg
  gir1.2-gudev-1.0
  gnupg
  gpgv
  grub-common
  grub-pc
  grub-pc-bin
  grub2-common
  initramfs-tools
  initramfs-tools-bin
  iptables
  isc-dhcp-client
  isc-dhcp-common
  language-pack-en
  language-pack-en-base
  language-selector-common
  libapt-inst1.4
  libapt-pkg4.12
  libbind9-80
  libdbus-glib-1-2
  libdevmapper1.02.1
  libdns81
  libdrm-intel1
  libdrm-nouveau1a
  libdrm-radeon1
  libdrm2
  libfreetype6
  libgnutls26
  libgudev-1.0-0
  libisc83
  libisccc80
  libisccfg82
  liblwres80
  libmysqlclient18
  libnih-dbus1
  libnih1
  libpciaccess0
  libplymouth2
  libssl1.0.0
  libudev0
  libxml2
  linux-headers-server
  linux-image-server
  linux-server
  man-db
  mountall
  mysql-common
  openssl
  perl
  perl-base
  perl-modules
  plymouth
  Plymouth-theme-ubuntu-text
  postfix
  puppet
  puppet-common
  python-apport
  python-problem-report
  sudo
  ubuntu-minimal
  ubuntu-standard
  udev
  upstart
  x11-common

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

More information about the foundations-bugs mailing list