Hide Forgot
Description of problem: ip neigh flush does not work Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: # ip neigh show 1.1.1.2 dev eth3 lladdr 00:11:22:33:44:68 PERMANENT 10.66.87.254 dev eth3 lladdr ec:30:91:e2:4b:00 DELAY # ip neigh flush dev eth3 # echo $? 0 Actual results: # ip neigh show 1.1.1.2 dev eth3 lladdr 00:11:22:33:44:68 PERMANENT 10.66.87.254 dev eth3 lladdr ec:30:91:e2:4b:00 REACHABLE Expected results: no neighbour exist Additional info: upstream iproute also have this issue
Current upstream version of iproute seems to require more arguments to "ip neigh flush", e.g. "ip neigh flush all".
(In reply to Pavel Šimerda (pavlix) from comment #1) > Current upstream version of iproute seems to require more arguments to "ip > neigh flush", e.g. "ip neigh flush all". Does dev $DEV not enough? I don't want to flush all the neighbor info.
(In reply to Hangbin Liu from comment #2) > (In reply to Pavel Šimerda (pavlix) from comment #1) > > Current upstream version of iproute seems to require more arguments to "ip > > neigh flush", e.g. "ip neigh flush all". > > Does dev $DEV not enough? I don't want to flush all the neighbor info. Yes, that should work (and works upstream, see below), missed that in the bug report. Using current upstream, the behavior is not exactly as described in the expected result but all records turn to FAILED for me and after some time they get recovered. We'll have to see whether the problem is in iproute, kernel or the reproducer itself.
I'm re-testing this issue for a dynamic neighbour entry in a VM and it apparently behaves correctly but one has to check the results with a good timing to avoid having them spoiled by new discovery. [root@rhel6 iproute2]# ip neighbor 192.168.122.1 dev eth0 lladdr fe:54:00:03:b4:de REACHABLE [root@rhel6 iproute2]# ip neighbor flush dev eth0; ip neighbor 192.168.122.1 dev eth0 INCOMPLETE [root@rhel6 iproute2]# ip neighbor 192.168.122.1 dev eth0 lladdr fe:54:00:03:b4:de REACHABLE Also upstream documentation (man ip-neighbour) clearly says that permanent and noarp entries are excluded from flushing and therefore it is unlikely that they will accept patches changing that. Is there any reason not to close the bug? Tested components: iproute-2.6.32-45.el6.x86_64 kernel-2.6.32-540.el6.x86_64
(In reply to Pavel Šimerda (pavlix) from comment #5) > I'm re-testing this issue for a dynamic neighbour entry in a VM and it > apparently behaves correctly but one has to check the results with a good > timing to avoid having them spoiled by new discovery. > > [root@rhel6 iproute2]# ip neighbor > 192.168.122.1 dev eth0 lladdr fe:54:00:03:b4:de REACHABLE > > [root@rhel6 iproute2]# ip neighbor flush dev eth0; ip neighbor > 192.168.122.1 dev eth0 INCOMPLETE > > [root@rhel6 iproute2]# ip neighbor > 192.168.122.1 dev eth0 lladdr fe:54:00:03:b4:de REACHABLE > > Also upstream documentation (man ip-neighbour) clearly says that permanent > and noarp entries are excluded from flushing and therefore it is unlikely > that they will accept patches changing that. > > Is there any reason not to close the bug? Closing. According to my tests 'ip neighbor flush' behaves as documented.
remove the needinfo flag since we have closed this bug