Bug 472959 - Xen antispoofing kicking in too early
Xen antispoofing kicking in too early
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
:
Depends On:
Blocks: 514498
  Show dependency treegraph
 
Reported: 2008-11-25 15:07 EST by Arturas Moskvinas
Modified: 2010-11-24 13:46 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-19 03:07:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Arturas Moskvinas 2008-11-25 15:07:51 EST
Description of problem:
Xen antispoofing functionality kicks in to fast. Here is transcript from logs:

Nov XX 02:52:41 some-host kernel: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
Nov XX 02:52:41 some-host kernel: ADDRCONF(NETDEV_UP): vif1.1: link is not ready
Nov XX 02:52:41 some-host logger: /etc/xen/scripts/vif-bridge: iptables -A FORWARD -m physdev --physdev-in vif1.0  -j ACCEPT failed. If you are using iptables, this may affect networking for guest domains.
Nov XX 02:52:42 some-host kernel: blkback: ring-ref 8, event-channel 27, protocol 1 (x86_64-abi)
Nov XX 02:52:45 some-host kernel: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
Nov XX 02:52:45 some-host kernel: xenbr1: topology change detected, propagating
Nov XX 02:52:45 some-host kernel: xenbr1: port 3(vif1.0) entering forwarding state
Nov XX 02:52:45 some-host kernel: ADDRCONF(NETDEV_CHANGE): vif1.1: link becomes ready
Nov 21 02:52:45 some-host kernel: xenbr3: topology change detected, propagating
Nov 21 02:52:45 some-host kernel: xenbr3: port 3(vif1.1) entering forwarding state


Version-Release number of selected component (if applicable):
xen-3.0.3-64.el5_2.3
kernel-xen-2.6.18-92.1.18.el5
Should be reproducible with other versions too

How reproducible:
Almost always

Steps to Reproduce:
1. Restart server
2. Wait until guest startup
3. Check domU network connectivity
  
Actual results:
Some domU guest might not have network functionality (packets are dropped)

Expected results:
All domU have network connectivity

Additional info:
Some check should be made, which would block antispoofing until interfaces are up.
Comment 4 Michal Novotny 2010-06-28 10:28:30 EDT
Hi Arturas,
could you please try testing using the latest kernel-xen and xen packages available in RHEL-5.5? If it's still an issue could you please attach more information about how is your guest being set (i.e. the guest configuration file) ?

Thanks,
Michal
Comment 5 Arturas Moskvinas 2010-06-28 12:29:46 EDT
Hello Michal,

Ok I try to check guest creation with RHEL5-5, I will write my findings.
Comment 6 Michal Novotny 2010-06-28 12:35:43 EDT
Ok, thanks. Let us know the guest configuration files when it's still an issue on RHEL 5.5 .

Thanks,
Michal
Comment 7 Miroslav Rezanina 2010-11-16 04:49:53 EST
Hi Arturas,
were you able to reproduce the problem with RHEL-5.5? I'm having trouble to reproduce this.
Comment 8 Arturas Moskvinas 2010-11-17 04:20:33 EST
I was unable to reproduce the problem too.
Comment 9 Miroslav Rezanina 2010-11-19 03:07:27 EST
Based on my testing and comment #8 closing.

Note You need to log in before you can comment on or make changes to this bug.