Sanjeev N created CLOUDSTACK-5815:
-------------------------------------

             Summary: [Hyper-v] Two SNAT rules for one isolated network if 
acquired ip is from different vlan
                 Key: CLOUDSTACK-5815
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5815
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: Hypervisor Controller, Network Controller
    Affects Versions: 4.3.0
         Environment: Latest build from 4.3 branch with 
commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
            Reporter: Sanjeev N
             Fix For: 4.3.0


[Hyper-v] Two SNAT rules for one isolated network if acquired ip is from 
different vlan

Steps to Reproduce:
=================
1.Bring up CS in advanced zone with hyper-v cluster
2.Create isolated guest network and deploy few vms in the network
3.Exhaust all the public IP addresses present in the zone (in user_ip_address 
table set the allocated=now())
4.Add new public IP range in new vlan and new subnet
5.Acquire one ip address from the new ip range and configure PF and assign one 
vm deployed at step2 

Expected Result:
==============
In isolated network there is only one SNAT ip address for the entire network. 
So even the acquired IP address is from different vlan, new SNAT rule should 
not be configured with the acquired ip address.

Actual Result:
============
Since the ip address acquired at step5 is from new vlan and is the ip address 
from that vlan additional SNAT rule got configured on VR with the acquired ip 
address.

Following is the output from iptables on VR:
root@r-4-VM:~# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 279 packets, 28169 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  eth2   *       0.0.0.0/0            
10.147.31.240        tcp dpt:22 to:10.1.1.26:22
    0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            
10.147.31.240        tcp dpt:22 to:10.1.1.26:22

Chain INPUT (policy ACCEPT 4 packets, 240 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 4 packets, 304 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            
10.147.31.240        tcp dpt:22 to:10.1.1.26:22

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       tcp  --  *      eth0    10.1.1.0/24          10.1.1.26   
         tcp dpt:22 to:10.1.1.1
    4   304 SNAT       all  --  *      eth2    0.0.0.0/0            0.0.0.0/0   
         to:10.147.48.5
    0     0 SNAT       all  --  *      eth2    0.0.0.0/0            0.0.0.0/0   
         to:10.147.31.240

ip address configuration on eth2 as follows:
root@r-4-VM:~# ip addr show eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
    link/ether 06:78:3c:00:00:17 brd ff:ff:ff:ff:ff:ff
    inet 10.147.48.5/24 brd 10.147.48.255 scope global eth2
    inet 10.147.31.240/24 brd 10.147.31.255 scope global eth2
    inet6 fe80::478:3cff:fe00:17/64 scope link
       valid_lft forever preferred_lft forever

Following is the IpAssocCmd got executed after configuring PF rule on the 
acquired ip address:
2014-01-07 11:30:39,274 DEBUG [c.c.a.t.Request] (Job-Executor-31:ctx-26e587af 
ctx-d423299a) Seq 4-2034961238: Sending  { Cmd , MgmtId: 132129494109518, via: 
4(10.147.40.31), Ver: v1, Flags: 100001, 
[{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"publicIp":"10.147.48.5","sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":true,"broadcastUri":"vlan://48","vlanGateway":"10.147.48.1","vlanNetmask":"255.255.255.0","vifMacAddress":"06:88:76:00:00:17","networkRate":200,"trafficType":"Public"}],"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"10.147.40.230","router.name":"r-4-VM"},"wait":0}},{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"publicIp":"10.147.31.240","sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":true,"broadcastUri":"vlan://31","vlanGateway":"10.147.31.1","vlanNetmask":"255.255.255.0","vifMacAddress":"06:78:3e:00:00:17","networkRate":200,"trafficType":"Public"}],"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"10.147.40.230","router.name":"r-4-VM"},"wait":0}}]
 }
2014-01-07 11:30:39,275 DEBUG [c.c.a.t.Request] (Job-Executor-31:ctx-26e587af 
ctx-d423299a) Seq 4-2034961238: Executing:  { Cmd , MgmtId: 132129494109518, 
via: 4(10.147.40.31), Ver: v1, Flags: 100001, 
[{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"publicIp":"10.147.48.5","sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":true,"broadcastUri":"vlan://48","vlanGateway":"10.147.48.1","vlanNetmask":"255.255.255.0","vifMacAddress":"06:88:76:00:00:17","networkRate":200,"trafficType":"Public"}],"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"10.147.40.230","router.name":"r-4-VM"},"wait":0}},{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"publicIp":"10.147
31.240","sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":true,"broadcastUri":"vlan://31","vlanGateway":"10.147.31.1","vlanNetmask":"255.255.255.0","vifMacAddress":"06:78:3e:00:00:17","networkRate":200,"trafficType":"Public"}],"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"10.147.40.230","router.name":"r-4-VM"},"wait":0}}]
 }

In the above IpAssocCommand sourceNat is set to true even for the new acquired 
ip address in the same netowrk.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to