quick update: git bisect points at commit 2724680. it appears that
net.ipv4.neigh.default.gc_thresh1 conf is now being used to skip pruning
of table entries. setting gc_thresh1=0 brings back old (desired)
behavior. we are continuing to investigate this problem.
```
git bisect start
# bad: [51f68c26bc65b2e885d01cab48856ddb7d514841] UBUNTU: Ubuntu-3.11.0-23.40
git bisect bad 51f68c26bc65b2e885d01cab48856ddb7d514841
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# bad: [736a2dd2571ac56b11ed95a7814d838d5311be04] Merge tag
'virtio-next-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
git bisect bad 736a2dd2571ac56b11ed95a7814d838d5311be04
# bad: [5bc7c33ca93a285dcfe7b7fd64970f6314440ad1] mtd: nand: reintroduce
NAND_NO_READRDY as NAND_NEED_READRDY
git bisect bad 5bc7c33ca93a285dcfe7b7fd64970f6314440ad1
# bad: [7ed214ac2095f561a94335ca672b6c42a1ea40ff] Merge tag 'char-misc-3.9-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 7ed214ac2095f561a94335ca672b6c42a1ea40ff
# bad: [a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8
# bad: [98d5fac2330779e6eea6431a90b44c7476260dcc] Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into
for-davem
git bisect bad 98d5fac2330779e6eea6431a90b44c7476260dcc
# bad: [cdda88912d62f9603d27433338a18be83ef23ac1] net: avoid to hang up on
sending due to sysctl configuration overflow.
git bisect bad cdda88912d62f9603d27433338a18be83ef23ac1
# bad: [580d9d081341aad5341884f9e6b070c01512e94c] bnx2x: correct memory release
scheme
git bisect bad 580d9d081341aad5341884f9e6b070c01512e94c
# good: [1cc7a3a14fa60f31ca4ff69f0dd31f369e0a51c2] e1000e: Invalid Image CSUM
bit changed for I217
git bisect good 1cc7a3a14fa60f31ca4ff69f0dd31f369e0a51c2
# good: [b27b28cb445975dc02d2e7d9437d23af76a51571] ipv6: Make
ipv6_addr_is_XXX() return boolean.
git bisect good b27b28cb445975dc02d2e7d9437d23af76a51571
# good: [100204147be9a2b87be2b118959b12eeaf8ef5d0] Merge branch 'dsa'
git bisect good 100204147be9a2b87be2b118959b12eeaf8ef5d0
# good: [463d413cb7dcd5509bc01e1108c2e2dcf8104683] drivers/net: delete old x86
variant of the seeq8005 driver
git bisect good 463d413cb7dcd5509bc01e1108c2e2dcf8104683
# bad: [ba418fa357a7b3c9d477f4706c6c7c96ddbd1360] soreuseport: UDP/IPv4
implementation
git bisect bad ba418fa357a7b3c9d477f4706c6c7c96ddbd1360
# bad: [0cc8d8df9bb931f1d4ab376f59d8ab8a49f9d4d4] netfilter: Use
IS_ERR_OR_NULL().
git bisect bad 0cc8d8df9bb931f1d4ab376f59d8ab8a49f9d4d4
# bad: [8fbcec241df21d1ba2aba09974ea9017832b69b0] net: Use IS_ERR_OR_NULL().
git bisect bad 8fbcec241df21d1ba2aba09974ea9017832b69b0
# bad: [2724680bceee94eac391552863771af105a7355c] neigh: Keep neighbour cache
entries if number of them is small enough.
git bisect bad 2724680bceee94eac391552863771af105a7355c
# good: [360eb5da665566a110993c58ed2a63e98f6720bf] ipmr: fix sparse warning
when testing origin or group
git bisect good 360eb5da665566a110993c58ed2a63e98f6720bf
# first bad commit: [2724680bceee94eac391552863771af105a7355c] neigh: Keep
neighbour cache entries if number of them is small enough.
ubuntu@ip-10-142-142-139:/mnt/work/ubuntu-trusty$ git bisect good
2724680bceee94eac391552863771af105a7355c is the first bad commit
commit 2724680bceee94eac391552863771af105a7355c
Author: YOSHIFUJI Hideaki / 吉藤英明 <yoshf...@linux-ipv6.org>
Date: Tue Jan 22 05:20:05 2013 +0000
neigh: Keep neighbour cache entries if number of them is small
enough.
Since we have removed NCE (Neighbour Cache Entry) reference from
routing entries, the only refcnt holders of an NCE are its timer
(if running) and its owner table, in usual cases. As a result,
neigh_periodic_work() purges NCEs over and over again even for
gateways.
It does not make sense to purge entries, if number of them is
very small, so keep them. The minimum number of entries to keep
is specified by gc_thresh1.
Signed-off-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org>
Signed-off-by: David S. Miller <da...@davemloft.net>
:040000 040000 af5aa6cdf5aa292d54a3d137410e9c09191d0158
5b940ff5eea0de763dc3373e6d57ed4e9a6607f4 M Documentation
:040000 040000 e4f34175b385b2d3acf9b1d5e4ea39f7d8da0232
c0674559693fba1d9b5b315b42a70f16335fba40 M net
```
--
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/1331150
Title:
arp fails to update, 3.13.0-{24,29}
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
in an AWS environment managed by BOSH, we saw tcp connectivity
problems between pairs of VMs.
VM A and VM B are up, running ubuntu 14.04-based images, and in the
same vpc subnet.
VM B is terminated, and another VM is created that uses the IP address
from VM B
The new VM tries to make a tcp connection to VM A. In some cases, the
connection fails.
Investigation reveals that VM A has the old MAC address in its
neighbor list. In some cases, running arp -d <IP Address> on VM A
"fixes the problem". Also in some cases, running arping in gratuitous
arp mode on the new VM also fixes the problem.
The problem does not occur if VM A is running an ubuntu 10.04-based
image.
The problem seems to occur only on machines with lots of tcp
connection traffic between them.
'arp -d' and arping on the new VM do not seem to "fix" the problem if
there are processes on the VMs that are trying to create new TCP
connections.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331150/+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
