[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] 3.4.x networking


  • To: "'Mike Williams'" <mike@xxxxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "Mark Chaney" <macscr@xxxxxxxxxx>
  • Date: Sun, 13 Sep 2009 15:09:54 -0500
  • Cc:
  • Delivery-date: Sun, 13 Sep 2009 13:10:39 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=macscr.com; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-soundwave-MailScanner-Information:X-soundwave-MailScanner-ID:X-soundwave-MailScanner:X-soundwave-MailScanner-SpamCheck:X-soundwave-MailScanner-From; b=ydc8aHgRwNN9EXFLbKkW+T4V5xI69K/f+BW90/28FZTl7IugH6z+d4IXSZo80mbgaceIr36aeRtpA63UMLxtcwmfp0QQ3qEEMdvK6TVuTCawjEhfgvABSbgoKQ60CVlz;
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: Aco0fgbpTsHQdncbTR++mUucrkRtuQAL5U6A

While it seems a bit dirty, what I have been addng to my firewall, which is
CSF (from configservers.net), I have a bash script that runs after the
normal rules are loaded to iptables:

[root@wheeljack ~]# cat /etc/csf/csfpost.sh
#!/bin/sh
# add iptables commands here
/sbin/iptables -A FORWARD -m physdev --physdev-in peth1 --physdev-out vif+
-j ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out peth1 --physdev-in vif+
-j ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-in peth0 --physdev-out vif+
-j ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out peth0 --physdev-in vif+
-j ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out vif+ --physdev-in vif+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-in vif+ --physdev-out vif+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out tap+ --physdev-in tap+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-in tap+ --physdev-out tap+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out vif+ --physdev-in tap+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-in vif+ --physdev-out tap+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-out tap+ --physdev-in vif+ -j
ACCEPT
/sbin/iptables -A FORWARD -m physdev --physdev-in tap+ --physdev-out vif+ -j
ACCEPT

It appears to work for the most part. Som im guessing I should be able to
comment out the handle_iptable for vif-bridge. BUT, according to my diff
findings the vif-bridge for 3.3.1 and 3.4.1 are exactly the same.

-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Williams
Sent: Sunday, September 13, 2009 9:25 AM
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] 3.4.x networking

On Sunday 13 September 2009 14:46:26 Pasi Kärkkäinen wrote:
> > I know it says the error is with vif-bridge, but that's stock, so I
don't
> > know what could be wrong with it. I dont get these errors witht he Xen
> > 3.3.1 and Kernel i mentioned earlier.
> 
> Did you diff vif-bridge script between xen 3.3.1 and xen 3.4.1 versions? 
> What are the differences? 
> 
> What's the failing iptables command? Please paste the whole command here, 
> including the parameters.

frob_iptables in /etc/xen/scripts/vif-common.sh has changed, mostly by the 
addition of:

iptables "$c" FORWARD -m state --state RELATED,ESTABLISHED -m physdev \
    --physdev-out "$vif" -j ACCEPT 2>/dev/null

I found this not only caused the probably innocuous physdev depreciation 
warning, but caused the conntrack modules to be loaded due to the state
check. 
The default conntrack size was far too small for me.
So either remove iptables, or comment out "handle_iptable" from 
/etc/xen/scripts/vif-bridge, I've no need for Xen to change iptables.

-- 
Mike Williams

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.