Bug 1036534
| Summary: | ip neigh flush does not work | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Hangbin Liu <haliu> |
| Component: | iproute | Assignee: | Pavel Šimerda (pavlix) <psimerda> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.6 | CC: | haliu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-04-15 10:14:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Hangbin Liu
2013-12-02 09:17:36 UTC
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 |