You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Bharat Kumar (JIRA)" <ji...@apache.org> on 2014/06/18 15:41:02 UTC

[jira] [Created] (CLOUDSTACK-6933) registering an iso fails in KVM deployment.

Bharat Kumar created CLOUDSTACK-6933:
----------------------------------------

             Summary: registering an iso fails in KVM deployment.
                 Key: CLOUDSTACK-6933
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6933
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: Automation
    Affects Versions: 4.4.0
         Environment: KVM advanced network
            Reporter: Bharat Kumar
             Fix For: 4.4.0


registing an iso fails with the connection refused error in KVM deployment.

below are the iptable rules on the relevant SSVM in the env.

Chain INPUT (policy DROP 28 packets, 1340 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  eth2   *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:443
    0     0 ACCEPT     tcp  --  eth2   *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:80
    0     0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:3922
  172 13277 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 4122  469K ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  196 10976 ACCEPT     all  --  eth2   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth3   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    3   180 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:3922

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 511 packets, 81586 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      eth1    0.0.0.0/0            172.16.88.0/24       state NEW tcp
 2576  155K ACCEPT     tcp  --  *      eth1    0.0.0.0/0            172.16.88.0/24       state NEW tcp
    0     0 REJECT     tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:80 reject-with icmp-port-unreachable
    0     0 REJECT     tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:443 reject-with icmp-port-unreachable

Chain HTTP (0 references)
 pkts bytes target     prot opt in     out     source               destination         

root@s-54-QA:~# route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.171.1    0.0.0.0         UG    0      0        0 eth2
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.16.88.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
172.16.88.0     0.0.0.0         255.255.255.0   U     0      0        0 eth3
172.16.171.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2

As per the above config when a packet is sent to 172.16.88.x/24 subnet  we are routing it via interface eth1. but we also have a reject rule in the OUTPUT chain for the packets leaving from eth1. as a result the packets get dropped. 

if we interchange the routes i.e. if the route related to eth3 is hit before hitting the eth1 route the register iso is successful. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)