cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "frank zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-6933) [Automation] Registering an iso fails in KVM deployment.
Date Wed, 06 Aug 2014 00:43:12 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087034#comment-14087034
] 

frank zhang commented on CLOUDSTACK-6933:
-----------------------------------------

This is a corner case in storage network. The storage network is designed to have a separate
subnet from management subnet, however, we also allow mgmt network and storage network to
be the same subnet in case customer only has one network for both purpose.
In this case, you must set global setting "secstorage.allowed.internal.sites" to a smaller
CIDR than mgmt network CIDR. The best practice is to set it to ip to secondary storage.
By doing so, the routing issue is solved because Linux routing use most specific match.
 

> [Automation] 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
>            Assignee: frank zhang
>             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)

Mime
View raw message