You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Marcus Sorensen (JIRA)" <ji...@apache.org> on 2012/11/26 22:45:01 UTC
[jira] [Commented] (CLOUDSTACK-540) KVM network trouble
[ https://issues.apache.org/jira/browse/CLOUDSTACK-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504131#comment-13504131 ]
Marcus Sorensen commented on CLOUDSTACK-540:
--------------------------------------------
What do you see in '/proc/sys/net/bridge/bridge-nf-call-*'?
I would also try bringing up an IP address on your cloudVirBr700 (that's where the vm is, right?) on both bh1 and bh2, see if they can ping. If not then it's probably a switch/port config issue and needing to add the tagged vlans to the ports. If the two bridges can ping each other, then it's likely some sort of filtering at the host.
> KVM network trouble
> --------------------
>
> Key: CLOUDSTACK-540
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-540
> Project: CloudStack
> Issue Type: Bug
> Components: Network Controller
> Affects Versions: 4.0.0
> Environment: 2x Node CentOS 6.3
> 1x node Cloudstack 4.0.0.1234
> Hypervisor: KVM
> Primary: CLVM
> Reporter: Iliya
>
> I setup "the advanced setup".
> cloudbrm - private
> cloudbr0 - guest
> cloudbr1 - public
> VLAN50 - public
> VLAN500-1000 - guest
> I created an instance (template CentOS 5.5(64-bit) no GUI (KVM)) and added a new network (DefaultIsolatedNetworkOfferingWithSourceNatService) in step 5 of the wizard. This network is deployed in cloudVirBr700
> bh1 - 1 KVM host
> bh2 - 2 KVM host
> The VM booted successfully, but when router and vm is same host - ping good.
> When router on bh1 and vm on bh2 network wasn't reachable:
> 1. The VM couldn't ping the public network gateway
> 2. The VM couldn't ping the Virtual Router
> 3. The Virtual Router couldn't ping the VM
> When tcpdump-ing cloudVirBr700 on the bh1 KVM host, I noticed "ICMP echo requests", but no reply's.
> I also noticed there were no iptables rules regarding cloudVirBr700. it's good or no?
> [root@bh2 1234]# iptables -L -n
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED
> ACCEPT all -- 192.168.122.0/24 0.0.0.0/0
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@bh2 1234]#
> [root@bh2 1234]# brctl show
> bridge name bridge id STP enabled interfaces
> cloud0 8000.fe00a9fe03da no vnet1
> cloudVirBr50 8000.707be8f0d200 no bond2.50
> vnet2
> cloudVirBr700 8000.fc48ef2fbd38 no bond1.700
> vnet0
> cloudbr0 8000.fc48ef2fbd38 yes bond1
> cloudbr1 8000.707be8f0d200 yes bond2
> cloudbrm 8000.fc48ef2fbd38 no bond1.40
> virbr0 8000.525400c8b796 yes virbr0-nic
> [root@bh2 1234]#
> it's freesh installation.
> i try it on 4.0.0.140 and 4.0.0.1234 releases the problem is the same everywhere
> [root@bh2 cloud]# tail -100 security_group.log
> 2012-11-27 00:39:23,025 - Cleaned up rules for 0 chains
> 2012-11-27 00:39:24,049 - iptables-save | grep '^:' | grep -v '.*-def' | grep -v '.*-eg' | awk '{print $1}' | cut -d':' -f2
> 2012-11-27 00:39:24,055 - ebtables-save |grep :i |awk '{print $1}' |sed -e 's/\-in//g' |sed -e 's/\-out//g' |sed -e 's/^://g'
> 2012-11-27 00:39:24,069 - Cleaned up rules for 0 chains
> 2012-11-27 01:01:41,150 - iptables-save | grep BF | grep r-4 | grep physdev-is-bridged | sed 's/-A/-D/'
> 2012-11-27 01:01:41,156 - ebtables -t nat -L PREROUTING | grep r-4-VM
> 2012-11-27 01:01:41,161 - ebtables -t nat -L POSTROUTING | grep r-4-VM
> 2012-11-27 01:01:41,166 - ebtables -t nat -F r-4-VM-in
> 2012-11-27 01:01:41,169 - Ignoring failure to delete ebtables chain for vm r-4-VM
> 2012-11-27 01:01:41,170 - ebtables -t nat -F r-4-VM-out
> 2012-11-27 01:01:41,174 - Ignoring failure to delete ebtables chain for vm r-4-VM
> 2012-11-27 01:01:41,174 - iptables -F r-4-def
> 2012-11-27 01:01:41,178 - Ignoring failure to delete chain r-4-def
> 2012-11-27 01:01:41,178 - iptables -X r-4-def
> 2012-11-27 01:01:41,182 - Ignoring failure to delete chain r-4-def
> 2012-11-27 01:01:41,182 - iptables -F r-4-VM
> 2012-11-27 01:01:41,186 - Ignoring failure to delete chain r-4-VM
> 2012-11-27 01:01:41,186 - iptables -X r-4-VM
> 2012-11-27 01:01:41,190 - Ignoring failure to delete chain r-4-VM
> 2012-11-27 01:01:41,190 - iptables -F r-4-VM-eg
> 2012-11-27 01:01:41,193 - Ignoring failure to delete chain r-4-VM-eg
> 2012-11-27 01:01:41,194 - iptables -X r-4-VM-eg
> 2012-11-27 01:01:41,197 - Ignoring failure to delete chain r-4-VM-eg
> 2012-11-27 01:01:41,197 - iptables -t nat -S | grep vnet0 | sed 's/-A/-D/'
> 2012-11-27 01:01:41,202 - iptables -t nat
> 2012-11-27 01:01:41,205 - Igoring failure to delete dnat:
> 2012-11-27 01:01:41,206 - Failed to delete rule log file /var/run/cloud/r-4-VM.log
> 2012-11-27 01:10:47,269 - which iptables
> 2012-11-27 01:10:47,273 - which ebtables
> 2012-11-27 01:10:47,276 - iptables-save | grep '^:' | grep -v '.*-def' | grep -v '.*-eg' | awk '{print $1}' | cut -d':' -f2
> 2012-11-27 01:10:47,282 - ebtables-save |grep :i |awk '{print $1}' |sed -e 's/\-in//g' |sed -e 's/\-out//g' |sed -e 's/^://g'
> 2012-11-27 01:10:47,298 - Cleaned up rules for 0 chains
> 2012-11-27 01:10:48,209 - iptables-save | grep '^:' | grep -v '.*-def' | grep -v '.*-eg' | awk '{print $1}' | cut -d':' -f2
> 2012-11-27 01:10:48,215 - ebtables-save |grep :i |awk '{print $1}' |sed -e 's/\-in//g' |sed -e 's/\-out//g' |sed -e 's/^://g'
> 2012-11-27 01:10:48,230 - Cleaned up rules for 0 chains
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira