Bug 650097
| Summary: | network in host become unavailable for few secs when guest quit | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Shirley Zhou <szhou> | ||||||
| Component: | kernel | Assignee: | Neil Horman <nhorman> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 5.6 | CC: | berrange, herbert.xu, jolsa, mshao, mwagner, nhorman, tgraf | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | 626678 | Environment: | |||||||
| Last Closed: | 2010-11-12 12:08:29 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 626678 | ||||||||
| Bug Blocks: | 580948 | ||||||||
| Attachments: |
|
||||||||
|
Description
Shirley Zhou
2010-11-05 08:05:42 UTC
As Herbert suggest, I take packet dump on the host.
To escape public network interruption, I run guest on private bridge virbr0.
# brctl show
bridge name bridge id STP enabled interfaces
breth0 8000.b8ac6f3b09be no eth0
virbr0 8000.626e8c676ff8 no tap1
tap0
Reproduce this issue as https://bugzilla.redhat.com/show_bug.cgi?id=626678#c3.
# ping 192.168.122.43
PING 192.168.122.43 (192.168.122.43) 56(84) bytes of data.
64 bytes from 192.168.122.43: icmp_seq=1 ttl=64 time=0.176 ms
64 bytes from 192.168.122.43: icmp_seq=2 ttl=64 time=0.138 ms
64 bytes from 192.168.122.43: icmp_seq=3 ttl=64 time=0.137 ms
64 bytes from 192.168.122.43: icmp_seq=4 ttl=64 time=0.147 ms
64 bytes from 192.168.122.43: icmp_seq=5 ttl=64 time=0.160 ms
64 bytes from 192.168.122.43: icmp_seq=6 ttl=64 time=0.120 ms
64 bytes from 192.168.122.43: icmp_seq=43 ttl=64 time=1.66 ms
64 bytes from 192.168.122.43: icmp_seq=44 ttl=64 time=0.115 ms
64 bytes from 192.168.122.43: icmp_seq=45 ttl=64 time=0.108 ms
64 bytes from 192.168.122.43: icmp_seq=46 ttl=64 time=0.120 ms
64 bytes from 192.168.122.43: icmp_seq=47 ttl=64 time=0.121 ms
64 bytes from 192.168.122.43: icmp_seq=48 ttl=64 time=0.119 ms
64 bytes from 192.168.122.43: icmp_seq=49 ttl=64 time=0.140 ms
64 bytes from 192.168.122.43: icmp_seq=50 ttl=64 time=0.162 ms
64 bytes from 192.168.122.43: icmp_seq=51 ttl=64 time=0.156 ms
--- 192.168.122.43 ping statistics ---
51 packets transmitted, 15 received, 70% packet loss, time 50008ms
Capture package using tcpdump -i virbr0 -w tcpdump.dump, please see attachment for reference.
Created attachment 458974 [details]
tcpdump
Can you show me the output of ifconfig before you shut down the guest and reproduced the problem? Thanks! OK, the problem with this is pretty clear, your virtbr0 MAC address changed after shutting down the guest (because virtbr0 doesn't have a stable MAC address of its own). So if you assign a stable MAC address to virtbr0 either by hand or through an interface that's always there, then it should work correctly. However, this doesn't explain why you saw an outage with from external. Can you please repeat the test from external and take a packet dump on the external Ethernet interface? Thanks! *** Bug 626678 has been marked as a duplicate of this bug. *** (In reply to comment #5) > OK, the problem with this is pretty clear, your virtbr0 MAC address changed > after shutting down the guest (because virtbr0 doesn't have a stable MAC > address of its own). So if you assign a stable MAC address to virtbr0 either > by hand or through an interface that's always there, then it should work > correctly. > > However, this doesn't explain why you saw an outage with from external. Can > you please repeat the test from external and take a packet dump on the external > Ethernet interface? > > Thanks! Hi, Herbert Thanks a lot for your comment. I take package dump from external host to host running guest, reproduce this bug, you can get package dump from attached dump file. [root@dhcp-91-53 ~]# ping 10.66.91.145 PING 10.66.91.145 (10.66.91.145) 56(84) bytes of data. 64 bytes from 10.66.91.145: icmp_seq=1 ttl=64 time=0.191 ms 64 bytes from 10.66.91.145: icmp_seq=2 ttl=64 time=0.173 ms 64 bytes from 10.66.91.145: icmp_seq=3 ttl=64 time=0.185 ms 64 bytes from 10.66.91.145: icmp_seq=4 ttl=64 time=0.164 ms 64 bytes from 10.66.91.145: icmp_seq=5 ttl=64 time=0.170 ms 64 bytes from 10.66.91.145: icmp_seq=6 ttl=64 time=0.173 ms 64 bytes from 10.66.91.145: icmp_seq=39 ttl=64 time=1.28 ms 64 bytes from 10.66.91.145: icmp_seq=40 ttl=64 time=0.151 ms 64 bytes from 10.66.91.145: icmp_seq=41 ttl=64 time=0.159 ms 64 bytes from 10.66.91.145: icmp_seq=42 ttl=64 time=0.164 ms 64 bytes from 10.66.91.145: icmp_seq=43 ttl=64 time=0.167 ms 64 bytes from 10.66.91.145: icmp_seq=44 ttl=64 time=0.149 ms 64 bytes from 10.66.91.145: icmp_seq=45 ttl=64 time=0.183 ms 64 bytes from 10.66.91.145: icmp_seq=46 ttl=64 time=0.163 ms 64 bytes from 10.66.91.145: icmp_seq=47 ttl=64 time=0.172 ms 64 bytes from 10.66.91.145: icmp_seq=48 ttl=64 time=0.177 ms 64 bytes from 10.66.91.145: icmp_seq=49 ttl=64 time=0.150 ms 64 bytes from 10.66.91.145: icmp_seq=50 ttl=64 time=0.141 ms 64 bytes from 10.66.91.145: icmp_seq=51 ttl=64 time=0.148 ms 64 bytes from 10.66.91.145: icmp_seq=52 ttl=64 time=0.158 ms Created attachment 459622 [details]
tcpdump_public
I'm looking at this tcpdump, and I see no interruption of service, in the icmp traffic or any other ip traffic between the .53 address or the .145 address. When you say you reproduced this bug, do you mean that you followed the test steps you previously outlined, or did you note the outage in some other way? wait, scratch that, I see the interruption now, its too early for me here :( although it looks from the trace like you didn't assign a fixed mac address to the virbr0 interface, or that despite setting it, it changed anyway. The source mac from 10.66.91.145 changes from frame 31 to frame 150 from 62:5f:c6:19:df:a9 (which appears locally assigned) to b8:ac:6f:3b:0c:30 (which has a Dell OUI, and is the physical MAC of eth0). Its almost as if the bridge is completely dissappearing when the guest exits, and traffic starts getting sent through the physical interface, rather than getting proxied through the bridge. That certainly seems to be the case In comment 4 you indicated what ifconfig output looked like before the guest shut down. What doe ifconfig and ip route show output after the guest shuts down. Triage assignment. If you feel this bug doesn't belong to you, or that it cannot be handled in a timely fashion, please contact me for re-assignment |