[
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)
