[jira] [Created] (CLOUDSTACK-10152) egress destination cidr with 0.0.0.0/0 is failing

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-10152:
--

 Summary: egress destination cidr with 0.0.0.0/0 is failing
 Key: CLOUDSTACK-10152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10152
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy


egress destination cidr with 0.0.0.0/0 is failing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9948) [UI] Network update to new offering ( with services removed ) pops up forced update confirmation with incorrect functionality

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9948:
--
Summary: [UI] Network update to new offering  ( with services removed ) 
pops up forced update confirmation with incorrect functionality  (was: Network 
update to new offering  ( with services removed ) pops up forced update 
confirmation with incorrect functionality)

> [UI] Network update to new offering  ( with services removed ) pops up forced 
> update confirmation with incorrect functionality
> --
>
> Key: CLOUDSTACK-9948
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9948
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>  Labels: PVR
> Fix For: 4.10.0.0
>
> Attachments: management-server.log
>
>
> - In Ad zone , Create an Isolated Network N1 with offering ( 
> DefaultIsolatedNetworkOfferingWithSourceNatService).
> - configure PF , FW , LB rules.
> - Now create a new offering which doesnt have PF , FW , LB services enabled .
> - Update the Nw N1 with the new offering .
> Observations :
> - User is popped with the following confirmation " Do you want to make a 
> force update?" . when clicked on "yes" no action is seen on the UI , but 
> update is implemented  with forced parameter set to "TRUE". New VR is 
> recreated with the depleted Services.[ job id : 883 ]
> - When the user clicks on "NO" the window closes down but still the api sends 
> forced parameter as "True" . [ job - 889]
> Following exception is observed post clicking Yes followed by No Option due 
> to multiple requests sent :
> 2017-06-08 07:34:41,085 ERROR [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-65:ctx-3fa1135c job-889/job-890) (logid:ac0e4c63) Unable 
> to complete AsyncJobVO {id:890, userId: 2, accountId: 2, instanceType: null, 
> instanceId: null, cmd: com.cloud.vm.VmWorkStop, cmdInfo: 
> rO0ABXNyABdjb20uY2xvdWQudm0uVm1Xb3JrU3RvcALQ4GymiWjjAgABWgAHY2xlYW51cHhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAUXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwA,
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 6760647622781, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: Thu Jun 08 07:34:35 EDT 2017}, job origin:889
> java.lang.NullPointerException
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4689)
> at sun.reflect.GeneratedMethodAccessor431.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4833)
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2017-06-08 07:34:41,086 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-65:ctx-3fa1135c job-889/job-890) (logid:ac0e4c63) Complete 
> async job-890, jobStatus: FAILED, resultCode: 0, result: 
> 

[jira] [Resolved] (CLOUDSTACK-8871) Basic zone security group ingress/egress rules are not working for some cidrs

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-8871.
---
Resolution: Fixed

> Basic zone security group ingress/egress rules are not working for some cidrs
> -
>
> Key: CLOUDSTACK-8871
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8871
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. Create a basic zone with xenserver 6.2.
> 2. Configure the ingress/egress rules in security group with cidrs /32
> 3. Rules got applied on UI but the traffic is not working.
> Reason:
> CIDR mentioned in the rules are failed to add ipset. 
> output from the SMLog:
> Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: 
> '', stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
> Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for 
> more information.
> Sep 16 10:52:39 localhost SM: [25871] '



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-8871) Basic zone security group ingress/egress rules are not working for some cidrs

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-8871:
--
Fix Version/s: (was: Future)
   4.10.0.0

> Basic zone security group ingress/egress rules are not working for some cidrs
> -
>
> Key: CLOUDSTACK-8871
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8871
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. Create a basic zone with xenserver 6.2.
> 2. Configure the ingress/egress rules in security group with cidrs /32
> 3. Rules got applied on UI but the traffic is not working.
> Reason:
> CIDR mentioned in the rules are failed to add ipset. 
> output from the SMLog:
> Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: 
> '', stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
> Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for 
> more information.
> Sep 16 10:52:39 localhost SM: [25871] '



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CLOUDSTACK-9946) When multiple PF rules are deleted , the 1st PF rule added is still retained in forwardingrules.json file in VPC VR .

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy edited comment on CLOUDSTACK-9946 at 6/29/17 6:22 AM:


When two PF rules delete concurrently then there is race condition. When second 
rule delete command is send,  the second rule revoke is set to true where the 
first one revoke set to false. Due to this rule is still there in the VR.

{noformat}
{"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"82:82","destination_ip_address":"10.1.1.68","destination_port_range":"82:82"},{"revoke":true,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"83:83","destination_ip_address":"10.1.1.68","destination_port_range":"83:83"}],"type":"forwardrules"}

{noformat}


was (Author: jayapal):
When two PF rules delete concurrently then there is race condition. The second 
rule revoke is set to true where the first one revoke set to true. Due to this 
rule is still there in the VR.

{noformat}
{"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"82:82","destination_ip_address":"10.1.1.68","destination_port_range":"82:82"},{"revoke":true,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"83:83","destination_ip_address":"10.1.1.68","destination_port_range":"83:83"}],"type":"forwardrules"}

{noformat}

> When multiple PF rules are deleted , the 1st PF rule added is still retained 
> in forwardingrules.json file in VPC VR .
> -
>
> Key: CLOUDSTACK-9946
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9946
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>  Labels: PVR
> Fix For: 4.10.0.0
>
> Attachments: MS_log_deletion_pf_rules.txt
>
>
> - Create a VPC , and deploy a VM in the Tier.
> - Navigate to PUblick IP address in the VPC and acquire an IP.
> - Create Multiple PF rules as below . Was able to sucessfully ssh and access 
> HTTP to the VM.
> - Now delete all the rules configured .
> Observation :
> - All  the rules are cleaned up in the UI & DB . But the 1st rule added is 
> still  retained in the IPtables and forwardingrules.json file .
> - and user is still able to access the rule. 
> Logs when rules are added : 
> acquired ip and assigned 5 pf rules : 
> root@r-53-VM:/etc/cloudstack# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:c3 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.195/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:3d:52:00:00:0d brd ff:ff:ff:ff:ff:ff
> inet 10.147.30.112/24 brd 10.147.30.255 scope global eth1
> inet 10.147.30.113/24 brd 10.147.30.255 scope global secondary eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:4b:3f:00:14 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.1/24 brd 172.16.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:67:bb:00:04 brd ff:ff:ff:ff:ff:ff
> inet 172.16.2.1/24 brd 172.16.2.255 scope global eth3
> 
> root@r-53-VM:/etc/cloudstack# cat forwardingrules.json
> {
> "10.147.30.113": [
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "10:10",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "10:10",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "20:20",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "20:20",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "30:30",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "30:30",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "22:22",
> "protocol": "tcp",
> "public_ip": 

[jira] [Assigned] (CLOUDSTACK-9943) Remote access VPN fails to establish from Windows Machine.

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-9943:
-

Assignee: Jayapal Reddy

> Remote access VPN fails to establish from Windows Machine.
> --
>
> Key: CLOUDSTACK-9943
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9943
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>Assignee: Jayapal Reddy
>Priority: Blocker
>  Labels: pvr
> Fix For: 4.10.0.0
>
> Attachments: management-server.log
>
>
> - Create an isolated Network N1 and deploy a VM.
> - On the Source Nat IP enable Remote Access VPN.
> - Configure the VPN connection from a window machine by providing the Public 
> IP of VR , TYpe of VPN : L2TP / IPSec and provide preshared key for 
> authentication.
> - Try connecting by providing the VPN users details.
> Observation : 
> Remote access VPn fails to establish .
> ==
> Please find the relevant logs below :
> root@r-42-VM:/etc/cloudstack# ipsec --version
> Linux strongSwan U5.2.1/K3.2.0-4-amd64
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil, Switzerland
> See 'ipsec --copyright' for copyright information.
> ===
> root@r-42-VM:/etc/cloudstack# ipsec status
> Security Associations (0 up, 0 connecting):
>   none
> auth.log==
> Jun  6 09:54:44 r-42-VM charon: 14[IKE] 10.233.89.32 is initiating a Main 
> Mode IKE_SA
> Jun  6 09:54:44 r-42-VM charon: 16[IKE] IKE_SA L2TP-PSK[1] established 
> between 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> Jun  6 09:54:44 r-42-VM charon: 03[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c217d307_i dc6d5497_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 01[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs cbeda395_i 21bba84d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 11[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c217d307_i (0 bytes) dc6d5497_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 12[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c9a8105d_i 28d44ba0_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 13[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs cbeda395_i (0 bytes) 21bba84d_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 04[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs ccd1db39_i 17c5c576_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 03[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c9a8105d_i (0 bytes) 28d44ba0_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 11[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c3dcf5e4_i 40af5f4d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 06[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs ccd1db39_i (0 bytes) 17c5c576_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session opened 
> for user root by (uid=0)
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session closed 
> for user root
> Jun  6 09:55:09 r-42-VM charon: 16[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c8d60ec4_i f675adb5_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:09 r-42-VM charon: 05[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c3dcf5e4_i (0 bytes) 40af5f4d_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:19 r-42-VM charon: 02[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c8d60ec4_i (0 bytes) f675adb5_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:19 r-42-VM charon: 01[IKE] deleting IKE_SA L2TP-PSK[1] between 
> 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> auth.log==
> IPsec status when ike is established : 
> root@r-42-VM:/etc/cloudstack# ipsec status
> Security Associations (1 up, 0 connecting):
> L2TP-PSK[3]: ESTABLISHED 31 seconds ago, 
> 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> L2TP-PSK{3}:  INSTALLED, TRANSPORT, ESP in UDP SPIs: c600_i a020e46f_o
> L2TP-PSK{3}:   

[jira] [Resolved] (CLOUDSTACK-9943) Remote access VPN fails to establish from Windows Machine.

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9943.
---
Resolution: Fixed

> Remote access VPN fails to establish from Windows Machine.
> --
>
> Key: CLOUDSTACK-9943
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9943
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>Assignee: Jayapal Reddy
>Priority: Blocker
>  Labels: pvr
> Fix For: 4.10.0.0
>
> Attachments: management-server.log
>
>
> - Create an isolated Network N1 and deploy a VM.
> - On the Source Nat IP enable Remote Access VPN.
> - Configure the VPN connection from a window machine by providing the Public 
> IP of VR , TYpe of VPN : L2TP / IPSec and provide preshared key for 
> authentication.
> - Try connecting by providing the VPN users details.
> Observation : 
> Remote access VPn fails to establish .
> ==
> Please find the relevant logs below :
> root@r-42-VM:/etc/cloudstack# ipsec --version
> Linux strongSwan U5.2.1/K3.2.0-4-amd64
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil, Switzerland
> See 'ipsec --copyright' for copyright information.
> ===
> root@r-42-VM:/etc/cloudstack# ipsec status
> Security Associations (0 up, 0 connecting):
>   none
> auth.log==
> Jun  6 09:54:44 r-42-VM charon: 14[IKE] 10.233.89.32 is initiating a Main 
> Mode IKE_SA
> Jun  6 09:54:44 r-42-VM charon: 16[IKE] IKE_SA L2TP-PSK[1] established 
> between 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> Jun  6 09:54:44 r-42-VM charon: 03[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c217d307_i dc6d5497_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 01[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs cbeda395_i 21bba84d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 11[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c217d307_i (0 bytes) dc6d5497_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 12[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c9a8105d_i 28d44ba0_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 13[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs cbeda395_i (0 bytes) 21bba84d_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 04[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs ccd1db39_i 17c5c576_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 03[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c9a8105d_i (0 bytes) 28d44ba0_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 11[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c3dcf5e4_i 40af5f4d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 06[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs ccd1db39_i (0 bytes) 17c5c576_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session opened 
> for user root by (uid=0)
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session closed 
> for user root
> Jun  6 09:55:09 r-42-VM charon: 16[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c8d60ec4_i f675adb5_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:09 r-42-VM charon: 05[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c3dcf5e4_i (0 bytes) 40af5f4d_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:19 r-42-VM charon: 02[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c8d60ec4_i (0 bytes) f675adb5_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:19 r-42-VM charon: 01[IKE] deleting IKE_SA L2TP-PSK[1] between 
> 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> auth.log==
> IPsec status when ike is established : 
> root@r-42-VM:/etc/cloudstack# ipsec status
> Security Associations (1 up, 0 connecting):
> L2TP-PSK[3]: ESTABLISHED 31 seconds ago, 
> 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> L2TP-PSK{3}:  INSTALLED, TRANSPORT, ESP in UDP SPIs: c600_i a020e46f_o
> L2TP-PSK{3}:   

[jira] [Resolved] (CLOUDSTACK-9712) Establishing Remote access VPN is failing due to mismatch of preshared secrets post Disable/Enable VPN.

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9712.
---
Resolution: Fixed
  Assignee: Wei Zhou

PR is merged. So marking it resolved.


> Establishing Remote access VPN  is failing due to mismatch of preshared 
> secrets post Disable/Enable VPN.
> 
>
> Key: CLOUDSTACK-9712
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9712
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
>Reporter: DeepthiMachiraju
>Assignee: Wei Zhou
>Priority: Critical
>  Labels: PVR
> Attachments: management-server.rar
>
>
> - On a Isolated Network enable VPN , and configure few VPN users.
> - Deploy a windows 2012R2 VM in the shared network . Create a new VPN 
> connection by providing the NAt ip , select L2tp in the confguration and 
> provide the psk provided by cloudstack.
> - Try logging with the vpn users created above.
> Observations : 
> - User fails to login with the following error message at client : " Error 
> 789 : The L2TP connection attempt failed because the security layer 
> encountered a processing error during initial negotiations with the remote 
> computer ".
> - Each time VPN is DIsabled/Enabled , new key is stored in ipsec.any.secrets.
> root@r-5-VM:~# cat /etc/ipsec.d/ipsec.any.secrets
> : PSK "O3rEXqxgMXRvNkPRXaqtkg43"
> : PSK "ZwEcGeHKnE9z2zpPht9eh77T"
> : PSK "7CUjMgwO8sbMJXjyHhRg2NDp"
> Note : when the older psk are deleted and only the current key is retained in 
> the file  , remote vpn is established sucessfully.
> =auth.log==
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: ignoring 
> Vendor ID payload [MS NT5 ISAKMPOAKLEY 0009]
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: received 
> Vendor ID payload [RFC 3947] method set to=109
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: received 
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already 
> using method 109
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: ignoring 
> Vendor ID payload [FRAGMENTATION]
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: ignoring 
> Vendor ID payload [MS-Negotiation Discovery Capable]
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: ignoring 
> Vendor ID payload [Vid-Initial-Contact]
> Dec 28 10:49:30 r-5-VM pluto[2828]: packet from 10.147.52.62:500: ignoring 
> Vendor ID payload [IKE CGA version 1]
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> responding to Main Mode from unknown peer 10.147.52.62
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: multiple 
> ipsec.secrets entries with distinct secrets match endpoints: first secret used
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: multiple 
> ipsec.secrets entries with distinct secrets match endpoints: first secret used
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> STATE_MAIN_R1: sent MR1, expecting MI2
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: multiple 
> ipsec.secrets entries with distinct secrets match endpoints: first secret used
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: multiple 
> ipsec.secrets entries with distinct secrets match endpoints: first secret used
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: 
> STATE_MAIN_R2: sent MR2, expecting MI3
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: next 
> payload type of ISAKMP Identification Payload has an unknown value: 255
> Dec 28 10:49:30 r-5-VM pluto[2828]: "L2TP-PSK"[3] 10.147.52.62 #18: probable 
> authentication failure (mismatch of preshared secrets?): malformed payload in 
> packet
> Dec 28 

[jira] [Commented] (CLOUDSTACK-9943) Remote access VPN fails to establish from Windows Machine.

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9943:
---

In VR the tunnel got established and deleted in few seconds. But in windows 809 
error is shown.
This is not bug from the ACS but issue from the windows.
The work around in is adding a register entry.

Procedure:

Step 1: Login to the PC as Administrator or an user who is a member of the 
Administrator Group.

Step 2: Click Start > Run or Start > All Programs > Accessories > Run and type 
regedit.

Step 3: Locate the entry 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent.

Step 4: Create a new DWORD (32-bit) value (Edit > New).

Step 5: Add AssumeUDPEncapsulationContextOnSendRule and save.

Step 6: Modify the new entry and change Value Data from 0 to 2.

Value 0 -> Cannot establish security associations with servers that are 
localted behind NAT devices.
Value 2 -> Can establish security associations with servers that are located 
behind NAT devices.

Step 7: Reboot the computer and try to setup the connection one more time.


Ref: https://support.sonicwall.com/kb/sw13197


> Remote access VPN fails to establish from Windows Machine.
> --
>
> Key: CLOUDSTACK-9943
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9943
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>Priority: Blocker
>  Labels: pvr
> Fix For: 4.10.0.0
>
> Attachments: management-server.log
>
>
> - Create an isolated Network N1 and deploy a VM.
> - On the Source Nat IP enable Remote Access VPN.
> - Configure the VPN connection from a window machine by providing the Public 
> IP of VR , TYpe of VPN : L2TP / IPSec and provide preshared key for 
> authentication.
> - Try connecting by providing the VPN users details.
> Observation : 
> Remote access VPn fails to establish .
> ==
> Please find the relevant logs below :
> root@r-42-VM:/etc/cloudstack# ipsec --version
> Linux strongSwan U5.2.1/K3.2.0-4-amd64
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil, Switzerland
> See 'ipsec --copyright' for copyright information.
> ===
> root@r-42-VM:/etc/cloudstack# ipsec status
> Security Associations (0 up, 0 connecting):
>   none
> auth.log==
> Jun  6 09:54:44 r-42-VM charon: 14[IKE] 10.233.89.32 is initiating a Main 
> Mode IKE_SA
> Jun  6 09:54:44 r-42-VM charon: 16[IKE] IKE_SA L2TP-PSK[1] established 
> between 10.147.30.117[10.147.30.117]...10.233.89.32[10.233.89.32]
> Jun  6 09:54:44 r-42-VM charon: 03[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c217d307_i dc6d5497_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 01[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs cbeda395_i 21bba84d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:44 r-42-VM charon: 11[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c217d307_i (0 bytes) dc6d5497_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 12[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c9a8105d_i 28d44ba0_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:47 r-42-VM charon: 13[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs cbeda395_i (0 bytes) 21bba84d_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 04[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs ccd1db39_i 17c5c576_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:51 r-42-VM charon: 03[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs c9a8105d_i (0 bytes) 28d44ba0_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 11[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c3dcf5e4_i 40af5f4d_o and TS 10.147.30.117/32[udp/l2f] === 
> 10.233.89.32/32[udp/l2f]
> Jun  6 09:54:59 r-42-VM charon: 06[IKE] closing CHILD_SA L2TP-PSK{1} with 
> SPIs ccd1db39_i (0 bytes) 17c5c576_o (0 bytes) and TS 
> 10.147.30.117/32[udp/l2f] === 10.233.89.32/32[udp/l2f]
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session opened 
> for user root by (uid=0)
> Jun  6 09:55:01 r-42-VM CRON[8238]: pam_unix(cron:session): session closed 
> for user root
> Jun  6 09:55:09 r-42-VM charon: 16[IKE] CHILD_SA L2TP-PSK{1} established with 
> SPIs c8d60ec4_i f675adb5_o and TS 

[jira] [Commented] (CLOUDSTACK-9946) When multiple PF rules are deleted , the 1st PF rule added is still retained in forwardingrules.json file in VPC VR .

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9946:
---

When two PF rules delete concurrently then there is race condition. The second 
rule revoke is set to true where the first one revoke set to true. Due to this 
rule is still there in the VR.

{noformat}
{"rules":[{"revoke":false,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"82:82","destination_ip_address":"10.1.1.68","destination_port_range":"82:82"},{"revoke":true,"protocol":"tcp","source_ip_address":"10.147.52.103","source_port_range":"83:83","destination_ip_address":"10.1.1.68","destination_port_range":"83:83"}],"type":"forwardrules"}

{noformat}

> When multiple PF rules are deleted , the 1st PF rule added is still retained 
> in forwardingrules.json file in VPC VR .
> -
>
> Key: CLOUDSTACK-9946
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9946
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>  Labels: PVR
> Fix For: 4.10.0.0
>
> Attachments: MS_log_deletion_pf_rules.txt
>
>
> - Create a VPC , and deploy a VM in the Tier.
> - Navigate to PUblick IP address in the VPC and acquire an IP.
> - Create Multiple PF rules as below . Was able to sucessfully ssh and access 
> HTTP to the VM.
> - Now delete all the rules configured .
> Observation :
> - All  the rules are cleaned up in the UI & DB . But the 1st rule added is 
> still  retained in the IPtables and forwardingrules.json file .
> - and user is still able to access the rule. 
> Logs when rules are added : 
> acquired ip and assigned 5 pf rules : 
> root@r-53-VM:/etc/cloudstack# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:c3 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.195/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:3d:52:00:00:0d brd ff:ff:ff:ff:ff:ff
> inet 10.147.30.112/24 brd 10.147.30.255 scope global eth1
> inet 10.147.30.113/24 brd 10.147.30.255 scope global secondary eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:4b:3f:00:14 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.1/24 brd 172.16.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:67:bb:00:04 brd ff:ff:ff:ff:ff:ff
> inet 172.16.2.1/24 brd 172.16.2.255 scope global eth3
> 
> root@r-53-VM:/etc/cloudstack# cat forwardingrules.json
> {
> "10.147.30.113": [
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "10:10",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "10:10",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "20:20",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "20:20",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "30:30",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "30:30",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "22:22",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "22:22",
> "type": "forward"
> },
> {
> "internal_ip": "172.16.2.10",
> "internal_ports": "80:80",
> "protocol": "tcp",
> "public_ip": "10.147.30.113",
> "public_ports": "80:80",
> "type": "forward"
> }
> ],
> "id": "forwardingrules"
> 
> root@r-53-VM:/etc/cloudstack# iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target prot opt source   destination
> DNAT   tcp  --  anywhere 10.147.30.113tcp dpt:10 
> to:172.16.2.10:10
> DNAT   tcp  --  anywhere 

[jira] [Resolved] (CLOUDSTACK-9761) Custom NW offering with Default Egress policy as " Allow" : only new ICMP rule is created as "accept" instead of " DROP"

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9761.
---
Resolution: Cannot Reproduce
  Assignee: Jayapal Reddy

> Custom NW offering with Default Egress policy as " Allow" : only new ICMP 
> rule is created as "accept" instead of " DROP"
> 
>
> Key: CLOUDSTACK-9761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9761
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0.1
>Reporter: DeepthiMachiraju
>Assignee: Jayapal Reddy
>  Labels: pvr
> Fix For: 4.10.0.0
>
>
> - Create a new network offering say 'nw1' with Default Egress policy as " 
> Allow".
> - deploy a network with the above offering.
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
> - on UI , select ICMP protocol and add the rule . 
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> ACCEPT icmp --  10.1.1.0/24  0.0.0.0/0icmptype 255
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
> - tcp/udp rules are added appropriately as drop .
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> DROP   udp  --  10.1.1.0/24  0.0.0.0/0udp dpts:250:360
> DROP   tcp  --  10.1.1.0/24  0.0.0.0/0tcp dpts:1:1000
> ACCEPT icmp --  10.1.1.0/24  0.0.0.0/0icmptype 255
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9761) Custom NW offering with Default Egress policy as " Allow" : only new ICMP rule is created as "accept" instead of " DROP"

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9761:
--
Summary: Custom NW offering with Default Egress policy as " Allow" : only 
new ICMP rule is created as "accept" instead of " DROP"  (was: Custom NW 
offering with Default Egress policy as " Allow" : new ICMP rule is created as 
"accept" instead of " DROP")

> Custom NW offering with Default Egress policy as " Allow" : only new ICMP 
> rule is created as "accept" instead of " DROP"
> 
>
> Key: CLOUDSTACK-9761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9761
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0.1
>Reporter: DeepthiMachiraju
>  Labels: pvr
> Fix For: 4.10.0.0
>
>
> - Create a new network offering say 'nw1' with Default Egress policy as " 
> Allow".
> - deploy a network with the above offering.
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
> - on UI , select ICMP protocol and add the rule . 
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> ACCEPT icmp --  10.1.1.0/24  0.0.0.0/0icmptype 255
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
> - tcp/udp rules are added appropriately as drop .
> 
> Chain FW_EGRESS_RULES (1 references)
> target prot opt source   destination
> DROP   udp  --  10.1.1.0/24  0.0.0.0/0udp dpts:250:360
> DROP   tcp  --  10.1.1.0/24  0.0.0.0/0tcp dpts:1:1000
> ACCEPT icmp --  10.1.1.0/24  0.0.0.0/0icmptype 255
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> 
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9968) VR iptables rules are not properly processed due to this rule config is failing.

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9968:
--
Description: 
1. enable and disable the static nat you will observe the below issue.
In CsNetfilter.py to_str method is inefficient, it can't handle CONNMARK target 
 iptables rules option. It receives a dictionary which contains iptables value 
(hex) as key.

1. iptables mangle rule when iptables-save is run.
-A PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK --save-mark 
--nfmask 0x --ctmask 0x

2. To_str method recieved the following dictionary in which only one 0x 
and it is a key.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:287 Before to_str rule: : 
{u'--save-mark': u'--nfmask', u'-A': u'PREROUTING', u'-s': u'10.1.1.68/32', 
u'-j': u'CONNMARK', u'0x': u'--ctmask', u'--state': u'NEW', u'-m2': 
u'state'}

3. Based on the above the below incorrect rule is framed.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:303 After str rule: : -D 
PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK

4. Rule execution fails because of the missing options.
2017-06-20 08:40:37,682  CsNetfilter.py get_unseen:129 unseen cmd:  iptables -t 
mangle -D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK
2017-06-20 08:40:37,688  CsHelper.py execute:188 Executed: iptables -t mangle 
-D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK -* exitstatus=2*

  was:
In CsNetfilter.py to_str method is inefficient, it can't handle CONNMARK target 
 iptables rules option. It receives a dictionary which contains iptables value 
(hex) as key.

1. iptables mangle rule when iptables-save is run.
-A PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK --save-mark 
--nfmask 0x --ctmask 0x

2. To_str method recieved the following dictionary in which only one 0x 
and it is a key.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:287 Before to_str rule: : 
{u'--save-mark': u'--nfmask', u'-A': u'PREROUTING', u'-s': u'10.1.1.68/32', 
u'-j': u'CONNMARK', u'0x': u'--ctmask', u'--state': u'NEW', u'-m2': 
u'state'}

3. Based on the above the below incorrect rule is framed.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:303 After str rule: : -D 
PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK

4. Rule execution fails because of the missing options.
2017-06-20 08:40:37,682  CsNetfilter.py get_unseen:129 unseen cmd:  iptables -t 
mangle -D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK
2017-06-20 08:40:37,688  CsHelper.py execute:188 Executed: iptables -t mangle 
-D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK -* exitstatus=2*


> VR iptables rules are not properly processed due to this rule config is 
> failing.
> 
>
> Key: CLOUDSTACK-9968
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9968
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. enable and disable the static nat you will observe the below issue.
> In CsNetfilter.py to_str method is inefficient, it can't handle CONNMARK 
> target  iptables rules option. It receives a dictionary which contains 
> iptables value (hex) as key.
> 1. iptables mangle rule when iptables-save is run.
> -A PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK --save-mark 
> --nfmask 0x --ctmask 0x
> 2. To_str method recieved the following dictionary in which only one 
> 0x and it is a key.
> 2017-06-20 08:40:37,682  CsNetfilter.py to_str:287 Before to_str rule: : 
> {u'--save-mark': u'--nfmask', u'-A': u'PREROUTING', u'-s': u'10.1.1.68/32', 
> u'-j': u'CONNMARK', u'0x': u'--ctmask', u'--state': u'NEW', u'-m2': 
> u'state'}
> 3. Based on the above the below incorrect rule is framed.
> 2017-06-20 08:40:37,682  CsNetfilter.py to_str:303 After str rule: : -D 
> PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK
> 4. Rule execution fails because of the missing options.
> 2017-06-20 08:40:37,682  CsNetfilter.py get_unseen:129 unseen cmd:  iptables 
> -t mangle -D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK
> 2017-06-20 08:40:37,688  CsHelper.py execute:188 Executed: iptables -t mangle 
> -D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK -* 
> exitstatus=2*



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-9968) VR iptables rules are not properly processed due to this rule config is failing.

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9968:
-

 Summary: VR iptables rules are not properly processed due to this 
rule config is failing.
 Key: CLOUDSTACK-9968
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9968
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.9.0
Reporter: Jayapal Reddy
 Fix For: 4.10.0.0


In CsNetfilter.py to_str method is inefficient, it can't handle CONNMARK target 
 iptables rules option. It receives a dictionary which contains iptables value 
(hex) as key.

1. iptables mangle rule when iptables-save is run.
-A PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK --save-mark 
--nfmask 0x --ctmask 0x

2. To_str method recieved the following dictionary in which only one 0x 
and it is a key.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:287 Before to_str rule: : 
{u'--save-mark': u'--nfmask', u'-A': u'PREROUTING', u'-s': u'10.1.1.68/32', 
u'-j': u'CONNMARK', u'0x': u'--ctmask', u'--state': u'NEW', u'-m2': 
u'state'}

3. Based on the above the below incorrect rule is framed.
2017-06-20 08:40:37,682  CsNetfilter.py to_str:303 After str rule: : -D 
PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK

4. Rule execution fails because of the missing options.
2017-06-20 08:40:37,682  CsNetfilter.py get_unseen:129 unseen cmd:  iptables -t 
mangle -D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK
2017-06-20 08:40:37,688  CsHelper.py execute:188 Executed: iptables -t mangle 
-D PREROUTING -s 10.1.1.68/32 -m state --state NEW -j CONNMARK -* exitstatus=2*



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-9967) [VPC] static nat on additional public subnet ip is not working.

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9967:
-

 Summary: [VPC] static nat on additional public subnet ip is not 
working.
 Key: CLOUDSTACK-9967
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9967
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.9.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


Steps to reproduce.
1. configure the VPC and deploy a vm in tier network.
2. Acquire an ip from the additional public subnet ips.
3. configure the static nat on the additional public subnet ip and allow port 
22 on 
4. access the vm using ssh to public ip. 
5. ssh is failed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CLOUDSTACK-9934) Traffic is not routed correctly on addtional public interface from static nat enabled vm

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy edited comment on CLOUDSTACK-9934 at 6/14/17 12:04 PM:
-

moved ACL_OUTBOUND_eth3 to last to make correct the behaviour.

{noformat}
root@r-138-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:b3 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.179/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:b5:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:0d:61:00:08 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.1/24 brd 10.1.2.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:50:fe:00:10 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:21:00:00:34 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.101/24 brd 10.147.52.255 scope global eth4
root@r-138-QA:~# iptables -t mangle -L -nv
Chain PREROUTING (policy ACCEPT 303 packets, 16393 bytes)
 pkts bytes target prot opt in out source   destination 

2   168 CONNMARK   all  --  eth3   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
0 0 CONNMARK   all  --  eth2   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
0 0 ACL_OUTBOUND_eth2  all  --  eth2   *   10.1.2.0/24 
!10.1.2.1 state NEW
0 0 CONNMARK   all  --  eth1   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x1
0 0 CONNMARK   all  --  eth4   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x4
3   213 MARK   all  --  *  *   10.1.1.680.0.0.0/0   
 state NEW MARK set 0x4
3   213 CONNMARK   all  --  *  *   10.1.1.680.0.0.0/0   
 state NEW CONNMARK save
184 ACL_OUTBOUND_eth3  all  --  eth3   *   10.1.1.0/24 
!10.1.1.1 state NEW

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

0 0 MARK   all  --  *  *   10.2.0.0/16  10.1.0.0/16 
 MARK set 0x524

Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)
 pkts bytes target prot opt in out source   destination 

6   504 VPN_STATS_eth4  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 MARK   all  --  *  *   10.2.0.0/16  10.1.0.0/16 
 MARK set 0x524
0 0 MARK   all  --  *  *   10.1.0.0/16  10.2.0.0/16 
 MARK set 0x525
6   504 VPN_STATS_eth1  all  --  *  *   0.0.0.0/0
0.0.0.0/0   

Chain OUTPUT (policy ACCEPT 295 packets, 36038 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill
0 0 MARK   all  --  *  *   10.1.0.0/16  10.2.0.0/16 
 MARK set 0x525

Chain POSTROUTING (policy ACCEPT 301 packets, 36542 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill

Chain ACL_OUTBOUND_eth2 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/0224.0.0.18  

0 0 ACCEPT all  --  *  *   0.0.0.0/0225.0.0.50  

0 0 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain ACL_OUTBOUND_eth3 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/0224.0.0.18  

0 0 ACCEPT all  --  *  *   0.0.0.0/0225.0.0.50  

184 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain VPN_STATS_eth1 (1 references)
 pkts bytes target prot 

[jira] [Commented] (CLOUDSTACK-9934) Traffic is not routed correctly on addtional public interface from static nat enabled vm

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9934:
---

root@r-138-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:b3 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.179/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:b5:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:0d:61:00:08 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.1/24 brd 10.1.2.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:50:fe:00:10 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:21:00:00:34 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.101/24 brd 10.147.52.255 scope global eth4
root@r-138-QA:~# iptables -t mangle -L -nv
Chain PREROUTING (policy ACCEPT 303 packets, 16393 bytes)
 pkts bytes target prot opt in out source   destination 

2   168 CONNMARK   all  --  eth3   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
0 0 CONNMARK   all  --  eth2   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
0 0 ACL_OUTBOUND_eth2  all  --  eth2   *   10.1.2.0/24 
!10.1.2.1 state NEW
0 0 CONNMARK   all  --  eth1   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x1
0 0 CONNMARK   all  --  eth4   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x4
3   213 MARK   all  --  *  *   10.1.1.680.0.0.0/0   
 state NEW MARK set 0x4
3   213 CONNMARK   all  --  *  *   10.1.1.680.0.0.0/0   
 state NEW CONNMARK save
184 ACL_OUTBOUND_eth3  all  --  eth3   *   10.1.1.0/24 
!10.1.1.1 state NEW

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

0 0 MARK   all  --  *  *   10.2.0.0/16  10.1.0.0/16 
 MARK set 0x524

Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)
 pkts bytes target prot opt in out source   destination 

6   504 VPN_STATS_eth4  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 MARK   all  --  *  *   10.2.0.0/16  10.1.0.0/16 
 MARK set 0x524
0 0 MARK   all  --  *  *   10.1.0.0/16  10.2.0.0/16 
 MARK set 0x525
6   504 VPN_STATS_eth1  all  --  *  *   0.0.0.0/0
0.0.0.0/0   

Chain OUTPUT (policy ACCEPT 295 packets, 36038 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill
0 0 MARK   all  --  *  *   10.1.0.0/16  10.2.0.0/16 
 MARK set 0x525

Chain POSTROUTING (policy ACCEPT 301 packets, 36542 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill

Chain ACL_OUTBOUND_eth2 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/0224.0.0.18  

0 0 ACCEPT all  --  *  *   0.0.0.0/0225.0.0.50  

0 0 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain ACL_OUTBOUND_eth3 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/0224.0.0.18  

0 0 ACCEPT all  --  *  *   0.0.0.0/0225.0.0.50  

184 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain VPN_STATS_eth1 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0all  --  *  eth10.0.0.0/0 

[jira] [Updated] (CLOUDSTACK-9940) Rules ( PF , Firewall )when deleted during the VR stopped state are still persistent on the VR iptables.

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9940:
--
Labels: PVR  (was: )

> Rules ( PF , Firewall )when deleted during the VR stopped state are still 
> persistent on the VR iptables.
> 
>
> Key: CLOUDSTACK-9940
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9940
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
>Reporter: DeepthiMachiraju
>  Labels: PVR
> Fix For: 4.10.0.0
>
> Attachments: cloud.log
>
>
> - Create a network and configure PF , FW , LB rules on the source Nat IP.
> - Stop the VR and delete the above rules , and add new rules with different 
> port numbers.
> - Start the VR and check if the above rules are configured .
> Observation : 
> - Rules which are newly added during the VR stop state are configured 
> properly.
> - Rules which are deleted are still retained in the respective json files and 
> reflecting in the iptable rules.
> - Rules which are deleted are cleaned up from the DB and UI , but still 
> persistent in iptables.
> **
> mysql> select * from port_forwarding_rules;
> ++-+-+-+---+
> | id | instance_id | dest_ip_address | dest_port_start | dest_port_end |
> ++-+-+-+---+
> | 38 |   4 | 172.16.1.227|  22 |22 |
> | 51 |  23 | 10.1.1.18   | 888 |   888 |
> ++-+-+-+---+
> < forwardingrules.json >
> - 2000 port is the one which was deleted when router is in stopped state.
> - 888 port is the newly added rule when VR in stopped state .
> root@r-29-VM:/etc/cloudstack# cat forwardingrules.json
> {
> "10.147.52.21": [
> {
> "internal_ip": "10.1.1.18",
> "internal_ports": "2000:2000",
> "protocol": "tcp",
> "public_ip": "10.147.52.21",
> "public_ports": "2000:2000",
> "type": "forward"
> },
> {
> "internal_ip": "10.1.1.18",
> "internal_ports": "888:888",
> "protocol": "tcp",
> "public_ip": "10.147.52.21",
> "public_ports": "888:888",
> "type": "forward"
> }
> ],
> "id": "forwardingrules"
> **
> Firewall Rules :
> mysql> select * from firewall_rules where network_id=209 and 
> purpose='Firewall';
> ++--+---++--++--+--++---++--+-+---+---+-+--++--+-+
> | id | uuid | ip_address_id | start_port | 
> end_port | state  | protocol | purpose  | account_id | domain_id | network_id 
> | xid  | created | icmp_code | 
> icmp_type | related | type | vpc_id | traffic_type | display |
> ++--+---++--++--+--++---++--+-+---+---+-+--++--+-+
> | 50 | a41a75b3-ba8b-4126-b098-f52fa8151891 |12 |    |
>   | Active | tcp  | Firewall |  2 | 1 |209 | 
> e608b208-6e27-41c4-9163-40f3f3829929 | 2017-06-05 10:29:02 |  NULL |  
> NULL |NULL | User |   NULL | Ingress  |   1 |
> ++--+---++--++--+--++---++--+-+---+---+-+--++--+-+
> 1 row in set (0.00 sec)
> < firewallrules.json >
> - 555 port was deleted when VR in stopped state .
> -  port was added when VR in stopped state
> root@r-29-VM:/etc/cloudstack# cat firewallrules.json
> {
> "0": {
> "already_added": false,
> "default_egress_policy": false,
> "id": 0,
> "protocol": "all",
> "purpose": "Firewall",
> "revoked": false,
> "source_cidr_list": [],
> "src_ip": "",
> "traffic_type": "Egress"
> },
> 

[jira] [Commented] (CLOUDSTACK-9885) VPC RVR: On deleting first tier and configuring Private GW both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9885:
---

PR raised
https://github.com/apache/cloudstack/pull/2128

> VPC RVR: On deleting first tier and configuring Private GW  both VRs becoming 
> MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> - Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
> getting  into MASTER state.
> r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
> {noformat}
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> root@r-269-QA:~#
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
> root@r-269-QA:~# checkrouter.sh
> Status: MASTER
> root@r-269-QA:~#
> {noformat}
> root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface 
> and delete 10.2.1.1 ip on ethic interface.
>After some time it configured 10.2.1.1 ip on eth4 and it became master.
> {noformat}
> root@r-268-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
> inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 

[jira] [Created] (CLOUDSTACK-9934) Traffic is not routed correctly on addtional public interface from static nat enabled vm

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9934:
-

 Summary: Traffic is not routed correctly on addtional public 
interface from static nat enabled vm
 Key: CLOUDSTACK-9934
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9934
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Reporter: Jayapal Reddy
 Fix For: 4.10.0.0


1. Configure static nat on additional public subnet ip  in VPC.
2. Now ping google.com from the static nat enabled vm.
3. The traffic supposed to leave out from the additional public ip interface 
(static nat enabled ip).

Bug: The traffic is leaving via default source nat interface (eth1).
Reason:
In iptables mangle table ACL_OUTBOUND_ethX chain is accepting the traffic 
before the connmark rule is hit  the packet.

Please look at the below logs.
{noformat}
root@r-135-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:13 brd ff:ff:ff:ff:ff:ff
inet 169.254.1.19/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:f9:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:29:c5:00:05 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.1/24 brd 10.1.2.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:45:73:00:06 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth4
8: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:2a:00:00:34 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.101/24 brd 10.147.52.255 scope global eth2
root@r-135-QA:~# 
root@r-135-QA:~# iptables -t mangle -L -nv
Chain PREROUTING (policy ACCEPT 328 packets, 19964 bytes)
 pkts bytes target prot opt in out source   destination 

   77  6453 CONNMARK   all  --  eth4   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
7   541 CONNMARK   all  --  eth3   *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED CONNMARK restore
2   144 ACL_OUTBOUND_eth3  all  --  eth3   *   10.1.2.0/24 
!10.1.2.1 state NEW
0 0 CONNMARK   all  --  eth1   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x1
   34  2832 ACL_OUTBOUND_eth4  all  --  eth4   *   10.1.1.0/24 
!10.1.1.1 state NEW
   12   801 CONNMARK   all  --  *  *   10.1.1.680.0.0.0/0   
 state NEW CONNMARK save
0 0 CONNMARK   all  --  eth2   *   0.0.0.0/00.0.0.0/0   
 state NEW CONNMARK set 0x2
2   129 MARK   all  --  *  *   10.1.2.128   0.0.0.0/0   
 state NEW MARK set 0x2
2   129 CONNMARK   all  --  *  *   10.1.2.128   0.0.0.0/0   
 state NEW CONNMARK save

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


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

4   336 VPN_STATS_eth2  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
  209 17520 VPN_STATS_eth1  all  --  *  *   0.0.0.0/0
0.0.0.0/0   

Chain OUTPUT (policy ACCEPT 291 packets, 35814 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill

Chain POSTROUTING (policy ACCEPT 295 packets, 36150 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CHECKSUM   udp  --  *  *   0.0.0.0/00.0.0.0/0   
 udp dpt:68 CHECKSUM fill

Chain ACL_OUTBOUND_eth3 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 ACCEPT all  --  *  *   0.0.0.0/0224.0.0.18  

0 0 ACCEPT all  --  *  *   0.0.0.0/0225.0.0.50  

2   144 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0   


Chain ACL_OUTBOUND_eth4 (1 references)
 pkts bytes target prot opt in out source   

[jira] [Created] (CLOUDSTACK-9930) SNAT rule is incorrectly added on for PF rule

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9930:
-

 Summary: SNAT rule is incorrectly added on for PF rule
 Key: CLOUDSTACK-9930
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9930
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
 Fix For: 4.10.0.0


1. Acquire an ip from the additional public subnet.
2. Configure a port forwarding rule on the isolated network.
3. Check the snat rule added in nat table. It is added on default source nat 
interface instead of additional public subnet interface.

eth3 - additional public subnet interface.


{noformat}
root@r-133-QA:~# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 CONNMARK   tcp  --  eth3   *   0.0.0.0/0
10.147.52.100tcp dpt:22 state NEW CONNMARK save
0 0 DNAT   tcp  --  eth3   *   0.0.0.0/0
10.147.52.100tcp dpt:22 to:10.1.1.182:22
0 0 DNAT   tcp  --  eth0   *   0.0.0.0/0
10.147.52.100tcp dpt:22 to:10.1.1.182:22
0 0 MARK   tcp  --  eth3   *   0.0.0.0/0
10.147.52.100tcp dpt:22 MARK set 0x3

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


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

0 0 DNAT   tcp  --  *  *   0.0.0.0/0
10.147.52.100tcp dpt:22 to:10.1.1.182:22

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

   10   500 SNAT   all  --  *  eth20.0.0.0/00.0.0.0/0   
 to:10.147.46.107
0 0 SNAT   all  --  *  eth20.0.0.0/00.0.0.0/0   
 to:10.147.52.100
0 0 SNAT   tcp  --  *  eth010.1.1.0/24  10.1.1.182  
 tcp dpt:22 to:10.1.1.1
root@r-133-QA:~# 
root@r-133-QA:~# 
root@r-133-QA:~# 
root@r-133-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:24:c6:00:07 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:b7 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.183/16 brd 169.254.255.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:1e:00:00:13 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.107/24 brd 10.147.46.255 scope global eth2
7: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:e0:00:00:33 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth3
root@r-133-QA:~# 
root@r-133-QA:~# ip route show table Table_eth3
default via 10.147.52.1 dev eth3  proto static 
throw 10.1.1.0/24  proto static 
throw 169.254.0.0/16  proto static 
root@r-133-QA:~# ip route show table Table_eth2
default via 10.147.46.1 dev eth2  proto static 
throw 10.1.1.0/24  proto static 
throw 169.254.0.0/16  proto static 
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9709) DHCP/DNS offload: Use correct thread pool for IP fetch task

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9709.
---
Resolution: Fixed

> DHCP/DNS offload: Use correct thread pool for IP fetch task
> ---
>
> Key: CLOUDSTACK-9709
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9709
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Currently IP fetch task is using the same thread pool as VM expunge. This can 
> lead to confusion
> Also the IP fetch task uses another thread pool (name of the variable 
> _vmIpFetchThreadExecutor) which is not initialized. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9657) Ipset command fails for VM's with long internal name

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9657.
---
Resolution: Fixed

> Ipset command fails for VM's with long internal name
> 
>
> Key: CLOUDSTACK-9657
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9657
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.1.0
>
>
> ipset rules configuration in security groups is failing for the VM with 
> longer name 
> ipset -N 12345677 nethash
> ipset v6.11: Syntax error: setname '12345677' is 
> longer than 31 characters



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9756) IP address must not be allocated to other VR if releasing ip address is failed

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9756.
---
Resolution: Fixed

>  IP address must not be allocated to other VR if releasing ip address is 
> failed
> ---
>
> Key: CLOUDSTACK-9756
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9756
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Apply rule (delete) is success on failure of ip assoc on back end. Cloudstack 
> ignored the ip assoc failure.
> Due to this the ip got freed and assigned to another network/account. It 
> caused the ip to be present in more than one router.
> Fix: Failing the apply rule (delete) on ipassoc failure
> Repro steps:
> 1. Configure PF/static nat/Firewall rules
> 2. Delete the rule configured.
> On deleting the rule, fail the ip assoc on the router.
> 3. Delete rule fails because ip assoc got failed.
> For RVR:
> 1. acquire several public ips,
> 2. add some rules on those public ips, so ips should show up in RVR,
> 3. change ipassoc.sh in RVR, make it always returns error on disassociate ip.
> 4. disassociate ip from  UI, ip should  is freed even though disassociate 
> fails inside VR.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (CLOUDSTACK-9756) IP address must not be allocated to other VR if releasing ip address is failed

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reopened CLOUDSTACK-9756:
---

>  IP address must not be allocated to other VR if releasing ip address is 
> failed
> ---
>
> Key: CLOUDSTACK-9756
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9756
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Apply rule (delete) is success on failure of ip assoc on back end. Cloudstack 
> ignored the ip assoc failure.
> Due to this the ip got freed and assigned to another network/account. It 
> caused the ip to be present in more than one router.
> Fix: Failing the apply rule (delete) on ipassoc failure
> Repro steps:
> 1. Configure PF/static nat/Firewall rules
> 2. Delete the rule configured.
> On deleting the rule, fail the ip assoc on the router.
> 3. Delete rule fails because ip assoc got failed.
> For RVR:
> 1. acquire several public ips,
> 2. add some rules on those public ips, so ips should show up in RVR,
> 3. change ipassoc.sh in RVR, make it always returns error on disassociate ip.
> 4. disassociate ip from  UI, ip should  is freed even though disassociate 
> fails inside VR.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9711) Remote Access vpn user add fail ignored when the VR in stopped state

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9711.
---
Resolution: Fixed

> Remote Access vpn user add fail ignored when the VR in stopped state
> 
>
> Key: CLOUDSTACK-9711
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9711
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. Create multiple networks in an account
> 2. Enable remote access vpn.
> 3. Stop the VR for one of the network.
> 4. Configure vpn user. 
> If configuring vpn user in one of the network fails the failure is ignored.
> Failure should be shown in API response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9715.
---
Resolution: Fixed

> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf
> -
>
> Key: CLOUDSTACK-9715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.
> We checked the parameter of "somaxconn" in the virtual router. 
> # cat /proc/sys/net/net/core/somaxconn 
> 128 
> And we checked the file "sysctl.conf" in virtual router. 
> # cat /etc/sysctl.conf | grep somaxconn 
> net.core.somaxconn=100 
> #sysctl -p # output
> .
> sysctl: setting key "net.core.somaxconn": Invalid argument
> net.core.somaxconn = 100
> ..



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9723) Enable unique mac address across different deployments and networks

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9723.
---
Resolution: Fixed

> Enable unique mac address across different deployments and networks
> ---
>
> Key: CLOUDSTACK-9723
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9723
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Specify the MAC address range for VMs created in ACS
> If there are Multiple CCP environments, There is  difficulty in identifying 
> VMs based on their MAC addresses since the addresses are duplicated across 
> environments.
> Specifying the MAC address range in zone will avoid the conflict.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9756) IP address must not be allocated to other VR if releasing ip address is failed

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9756.
---
Resolution: Fixed

>  IP address must not be allocated to other VR if releasing ip address is 
> failed
> ---
>
> Key: CLOUDSTACK-9756
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9756
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Apply rule (delete) is success on failure of ip assoc on back end. Cloudstack 
> ignored the ip assoc failure.
> Due to this the ip got freed and assigned to another network/account. It 
> caused the ip to be present in more than one router.
> Fix: Failing the apply rule (delete) on ipassoc failure
> Repro steps:
> 1. Configure PF/static nat/Firewall rules
> 2. Delete the rule configured.
> On deleting the rule, fail the ip assoc on the router.
> 3. Delete rule fails because ip assoc got failed.
> For RVR:
> 1. acquire several public ips,
> 2. add some rules on those public ips, so ips should show up in RVR,
> 3. change ipassoc.sh in RVR, make it always returns error on disassociate ip.
> 4. disassociate ip from  UI, ip should  is freed even though disassociate 
> fails inside VR.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9757) VPC traffic from vm to additional public subnet is not working

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9757.
---
Resolution: Fixed

> VPC traffic from vm to additional public subnet is not working
> --
>
> Key: CLOUDSTACK-9757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9757
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. Add additional Public IP to Physical Network (specify a VLAN ID to isolate 
> traffic),
> 2. Create PortForward rule in VPC
> i) Acquire New IP , which used additional Public IP
> ii) Map a VM instance to use this Public IP
> 3. Observe that when VM ping additional public subnet then it is  not working
> For additional public subnet ip SNAT rules are not configured when 
> PF/Staticnat is configured. Due to this PF/StaticNAT VM traffic from to 
> additional public subnet is not SNATed to public ip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9728) query to traffic sentinel requesting for usage stats is too long resulting in traffic sentinel sending HTTP 414 error response

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9728.
---
Resolution: Fixed

> query to traffic sentinel requesting for usage stats is too long resulting in 
> traffic sentinel sending HTTP 414 error response
> --
>
> Key: CLOUDSTACK-9728
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9728
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> The query sent to the traffic sentinel to retrieve network usage information 
> is rejected with a 414 error because the string is too long for it to process



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9848.
---
Resolution: Fixed

> VR commands exist status is not checked in python config files
> --
>
> Key: CLOUDSTACK-9848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>
> When iptables rules are configured on the VR failures or exceptions are not 
> detected in VR because iptables commands exit/return status is not 
> checked.Also in exception catch failure is not returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9855) VPC RVR when master guest interface is down backup VR is not switched to Master

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9855:
--
Description: 
1. Create a vpc RVR setup.
2. Deploy a VM in tier network
3. SSH to master VR and down the guest interface.
4. Backup VM is not becoming master.

Also both the VRs are having VRRP ip 10.1.1.1



  was:
1. Create a vpc RVR setup.
2. Deploy a VM in tier network
3. SSH to master VR and down the guest interface.
4. Backup VM is not becoming master.

Also both the VRs are having VRRP ip 10.1.1.1

This issue is happening because in keepalived.conf:vrrp_instance config state 
is set to EQUAL. This is causing the issue.


> VPC RVR when master guest interface is down backup VR is not switched to 
> Master
> ---
>
> Key: CLOUDSTACK-9855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9855
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.1.0
>
>
> 1. Create a vpc RVR setup.
> 2. Deploy a VM in tier network
> 3. SSH to master VR and down the guest interface.
> 4. Backup VM is not becoming master.
> Also both the VRs are having VRRP ip 10.1.1.1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLOUDSTACK-9855) VPC RVR when master guest interface is down backup VR is not switched to Master

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy edited comment on CLOUDSTACK-9855 at 5/25/17 9:37 AM:


If we set the state to BACKUP in keepalived.conf the issues are solved.


was (Author: jayapal):
If we set the state to BACKUP the issues are solved.

> VPC RVR when master guest interface is down backup VR is not switched to 
> Master
> ---
>
> Key: CLOUDSTACK-9855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9855
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.1.0
>
>
> 1. Create a vpc RVR setup.
> 2. Deploy a VM in tier network
> 3. SSH to master VR and down the guest interface.
> 4. Backup VM is not becoming master.
> Also both the VRs are having VRRP ip 10.1.1.1
> This issue is happening because in keepalived.conf:vrrp_instance config state 
> is set to EQUAL. This is causing the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9883) VPC RVR private gateway interface is not configured correctly

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9883.
---
Resolution: Fixed

> VPC RVR private gateway interface is not configured correctly
> -
>
> Key: CLOUDSTACK-9883
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9883
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Network Devices
>Reporter: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> 1. create a Redundant VPC.
> 2. Deploy a VM in the tier network.
> 3. Create a private gateway in VPC.
> On master it is observed that the private gateway interface is configured 
> with the privategateway ip and start ip in the subnet. Ex: private gateway ip 
> is 10.147.52.100 then it is also configured with the 10.147.52.1.
> If 10.147.52.1 is the gateway then it will create issues.
> {noformat}
> root@r-256-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:00:02 brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.2/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:dd:6c:00:00:10 brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:01:28:00:07 brd ff:ff:ff:ff:ff:ff
> inet 10.2.1.253/24 brd 10.2.1.255 scope global eth2
> inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:01:6a:00:00:24 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.100/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.1/24 brd 10.147.52.255 scope global secondary eth3
> root@r-256-QA:~# checkrouter.sh
> Status: MASTER
> root@r-256-QA:~#
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9724) VPC tier network restart with cleanup, missing public ip on VR interface

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-9724.
---
Resolution: Fixed

> VPC tier network restart with cleanup, missing public ip on VR interface
> 
>
> Key: CLOUDSTACK-9724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9724
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> On vpc tier network restart with clean up missing secondary ip addresses on 
> the VR public interface.
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9885) VPC RVR: On deleting first tier and configuring Private GW both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9885:
--
Summary: VPC RVR: On deleting first tier and configuring Private GW  both 
VRs becoming MASTER  (was: VPC RVR: On deleting first tier network both VRs 
becoming MASTER)

> VPC RVR: On deleting first tier and configuring Private GW  both VRs becoming 
> MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> - Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
> getting  into MASTER state.
> r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
> {noformat}
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> root@r-269-QA:~#
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
> root@r-269-QA:~# checkrouter.sh
> Status: MASTER
> root@r-269-QA:~#
> {noformat}
> root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface 
> and delete 10.2.1.1 ip on ethic interface.
>After some time it configured 10.2.1.1 ip on eth4 and it became master.
> {noformat}
> root@r-268-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
> inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 

[jira] [Commented] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9885:
---

The problem of both VRs becoming master is when private gateway interface is 
configured as eth2. For this a. configure t1 and t2 tiers b. delete t1 c. 
configure private gateway.  You will get the VRRP running on eth2 and both VRs 
will be master.

1. What I have observed is that both VRs are send broadcast and both are 
accepting VRRP packets.

2. The private gateway interface nw_type is save as guest in ips.json. Tried 
nw_type as 'private' and the issue is not seen. Any way private gateway 
interface  nw_type is not supposed be guest. 
VRRP is not supposed to be run on the private gateway interface.

3. What is not clear here is for private gateway interface why VRRP is sent 
accepted on both VRs.

[~ustcweiz...@gmail.com] The fix you mentioned above will clean up the 
interface but it will not stop configuring the VRRP on private gateway 
interface. 

{noformat}
root@r-127-QA:~# checkrouter.sh 
Status: MASTER
root@r-127-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:db brd ff:ff:ff:ff:ff:ff
inet 169.254.2.219/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:c3:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
6: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:78:75:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.76/24 brd 10.1.2.255 scope global eth3
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth3
11: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:6a:00:00:2e brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth2
inet 10.147.52.200/24 brd 10.147.52.255 scope global secondary eth2
root@r-127-QA:~# 


root@r-128-QA:~# checkrouter.sh 
Status: MASTER
root@r-128-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:69 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.105/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:c3:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
6: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:57:8a:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.244/24 brd 10.1.2.255 scope global eth3
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth3
11: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:7c:00:00:2e brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth2
inet 10.147.52.200/24 brd 10.147.52.255 scope global secondary eth2
root@r-128-QA:~# 

vrrp_instance inside_network {
state EQUAL
interface eth2
virtual_router_id 51
nopreempt

.
virtual_ipaddress {
10.147.52.200/24 brd 10.147.52.255 dev eth2
10.1.2.1/24 brd 10.1.2.255 dev eth3
}

ips.json
"eth2": [
{
"add": true, 
"broadcast": "10.147.52.255", 
"cidr": "10.147.52.100/24", 
"device": "eth2", 
"first_i_p": false, 
"gateway": "10.147.52.200", 
"netmask": "255.255.255.0", 
"network": "10.147.52.0/24", 
"new_nic": false, 
"nic_dev_id": 2, 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.147.52.100", 
"size": "24", 
"source_nat": true, 
"vif_mac_address": "1e:00:6a:00:00:2e"
},
{noformat}


> VPC RVR: On deleting first tier network both VRs becoming MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 

[jira] [Assigned] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-9885:
-

Assignee: Jayapal Reddy

> VPC RVR: On deleting first tier network both VRs becoming MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> - Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
> getting  into MASTER state.
> r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
> {noformat}
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> root@r-269-QA:~#
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
> root@r-269-QA:~# checkrouter.sh
> Status: MASTER
> root@r-269-QA:~#
> {noformat}
> root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface 
> and delete 10.2.1.1 ip on ethic interface.
>After some time it configured 10.2.1.1 ip on eth4 and it became master.
> {noformat}
> root@r-268-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
> inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast 

[jira] [Commented] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9885:
---

10.147.52.x is the private gateway. Its "nw_type": "guest", due to this its 
interface has two ip addresses configured.

root@r-113-QA:~# ip a show eth2
12: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:87:40:00:00:27 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.1/24 brd 10.147.52.255 scope global eth2
inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth2
root@r-113-QA:~# 
{noformat}
root@r-113-QA:~# cat /etc/cloudstack/ips.json 
{
"eth0": [
{
"add": true, 
"broadcast": "169.254.255.255", 
"cidr": "169.254.3.120/16", 
"device": "eth0", 
"gateway": "None", 
"netmask": "255.255.0.0", 
"network": "169.254.0.0/16", 
"nic_dev_id": "0", 
"nw_type": "control", 
"one_to_one_nat": false, 
"public_ip": "169.254.3.120", 
"size": "16", 
"source_nat": false
}
], 
"eth1": [
{
"add": true, 
"broadcast": "10.147.46.255", 
"cidr": "10.147.46.108/24", 
"device": "eth1", 
"first_i_p": true, 
"gateway": "10.147.46.1", 
"netmask": "255.255.255.0", 
"network": "10.147.46.0/24", 
"new_nic": false, 
"nic_dev_id": 1, 
"nw_type": "public", 
"one_to_one_nat": false, 
"public_ip": "10.147.46.108", 
"size": "24", 
"source_nat": true, 
"vif_mac_address": "06:38:a6:00:00:14"
}
], 
"eth2": [
{
"add": true, 
"broadcast": "10.147.52.255", 
"cidr": "10.147.52.1/24", 
"device": "eth2", 
"first_i_p": false, 
"gateway": "10.147.52.100", 
"netmask": "255.255.255.0", 
"network": "10.147.52.0/24", 
"new_nic": false, 
"nic_dev_id": 2, 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.147.52.1", 
"size": "24", 
"source_nat": true, 
"vif_mac_address": "06:87:40:00:00:27"
}, 
{
"add": false, 
"broadcast": "10.1.1.255", 
"cidr": "10.1.1.151/24", 
"device": "eth2", 
"gateway": "10.1.1.1", 
"netmask": "255.255.255.0", 
"network": "10.1.1.0/24", 
"nic_dev_id": "2", 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.1.1.151", 
"size": "24", 
"source_nat": false
}, 
{
"add": false, 
"broadcast": "10.1.1.255", 
"cidr": "10.1.1.245/24", 
"device": "eth2", 
"gateway": "10.1.1.1", 
"netmask": "255.255.255.0", 
"network": "10.1.1.0/24", 
"nic_dev_id": "2", 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.1.1.245", 
"size": "24", 
"source_nat": false
}
], 
"eth3": [
{
"add": false, 
"broadcast": "10.1.2.255", 
"cidr": "10.1.2.64/24", 
"device": "eth3", 
"gateway": "10.1.2.1", 
"netmask": "255.255.255.0", 
"network": "10.1.2.0/24", 
"nic_dev_id": "3", 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.1.2.64", 
"size": "24", 
"source_nat": false
}, 
{
"add": true, 
"broadcast": "10.1.2.255", 
"cidr": "10.1.2.170/24", 
"device": "eth3", 
"gateway": "10.1.2.1", 
"netmask": "255.255.255.0", 
"network": "10.1.2.0/24", 
"nic_dev_id": "3", 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.1.2.170", 
"size": "24", 
"source_nat": false
}
], 
"eth4": [
{
"add": false, 
"broadcast": "10.1.3.255", 
"cidr": "10.1.3.82/24", 
"device": "eth4", 
"gateway": "10.1.3.1", 
"netmask": "255.255.255.0", 
"network": "10.1.3.0/24", 
"nic_dev_id": "4", 
"nw_type": "guest", 
"one_to_one_nat": false, 
"public_ip": "10.1.3.82", 
"size": "24", 
"source_nat": false
}
], 
"id": "ips"

{noformat}

> VPC RVR: On deleting first tier network 

[jira] [Commented] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9885:
---

Repro steps:
1. configure t1 and t2 tier networks and deploy vm in the networks t1, t2.
2. Delete the t1 network.
3. Now configure the private gateway.
4. Check the router redundant state. Both will be in the master state.

> VPC RVR: On deleting first tier network both VRs becoming MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> - Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
> getting  into MASTER state.
> r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
> {noformat}
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> root@r-269-QA:~#
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
> root@r-269-QA:~# checkrouter.sh
> Status: MASTER
> root@r-269-QA:~#
> {noformat}
> root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface 
> and delete 10.2.1.1 ip on ethic interface.
>After some time it configured 10.2.1.1 ip on eth4 and it became master.
> {noformat}
> root@r-268-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
> inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 

[jira] [Updated] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9885:
--
Description: 
- Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
getting  into MASTER state.

r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
{noformat}
root@r-269-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
root@r-269-QA:~#


root@r-269-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
root@r-269-QA:~# checkrouter.sh

Status: MASTER
root@r-269-QA:~#
{noformat}

root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface and 
delete 10.2.1.1 ip on ethic interface.
   After some time it configured 10.2.1.1 ip on eth4 and it became master.
{noformat}
root@r-268-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:09:1d:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.49/24 brd 10.1.2.255 scope global eth4
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
root@r-268-QA:~#
root@r-268-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
 

[jira] [Updated] (CLOUDSTACK-9162) Handle the vpn user add when vpn is not enabled on the account

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9162:
--
Summary: Handle the vpn user add when vpn is not enabled on the account  
(was: Unable to add VPN user via API with Required Parameters)

> Handle the vpn user add when vpn is not enabled on the account
> --
>
> Key: CLOUDSTACK-9162
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9162
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
>
> With the following API request 
> 127.0.0.1:8096/client/api?command=addVpnUser=password111=api123
>  VPN user fails with following reason : Failed to apply vpn for user api123, 
> accountId=1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9885) VPC RVR: On deleting first tier network both VRs becoming MASTER

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9885:
-

 Summary: VPC RVR: On deleting first tier network both VRs becoming 
MASTER
 Key: CLOUDSTACK-9885
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
Priority: Blocker
 Fix For: 4.10.0.0


- Configure two tier networks t1 and t2. Delete the t2 network. Both VRs are 
getting  into MASTER state.

r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
{noformat}
root@r-269-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
root@r-269-QA:~#


root@r-269-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
root@r-269-QA:~# checkrouter.sh

Status: MASTER
root@r-269-QA:~#
{noformat}

root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface and 
delete 10.2.1.1 ip on ethic interface.
   After some time it configured 10.2.1.1 ip on eth4 and it became master.
{noformat}
root@r-268-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:15:ab:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.189/24 brd 10.1.1.255 scope global eth2
inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:67:ce:00:00:29 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:09:1d:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.49/24 brd 10.1.2.255 scope global eth4
inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
root@r-268-QA:~#
root@r-268-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc 

[jira] [Updated] (CLOUDSTACK-9883) VPC RVR private gateway interface is not configured correctly

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9883:
--
Priority: Critical  (was: Major)

> VPC RVR private gateway interface is not configured correctly
> -
>
> Key: CLOUDSTACK-9883
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9883
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Network Devices
>Reporter: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> 1. create a Redundant VPC.
> 2. Deploy a VM in the tier network.
> 3. Create a private gateway in VPC.
> On master it is observed that the private gateway interface is configured 
> with the privategateway ip and start ip in the subnet. Ex: private gateway ip 
> is 10.147.52.100 then it is also configured with the 10.147.52.1.
> If 10.147.52.1 is the gateway then it will create issues.
> {noformat}
> root@r-256-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:00:02 brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.2/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:dd:6c:00:00:10 brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:01:28:00:07 brd ff:ff:ff:ff:ff:ff
> inet 10.2.1.253/24 brd 10.2.1.255 scope global eth2
> inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:01:6a:00:00:24 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.100/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.1/24 brd 10.147.52.255 scope global secondary eth3
> root@r-256-QA:~# checkrouter.sh
> Status: MASTER
> root@r-256-QA:~#
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9883) VPC RVR private gateway interface is not configured correctly

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9883:
---

Another issue observed that the password server is also started on 
privategateway ip.
{noformat}
root@r-268-QA:~# ps axu | grep passwd_server
root  5494  0.0  0.6  19624  1584 ?S08:54   0:00 /bin/bash 
/opt/cloud/bin/passwd_server_ip 10.147.52.100 dummy
root  5496  0.0  3.1  48472  7908 ?S08:54   0:00 python 
/opt/cloud/bin/passwd_server_ip.py 10.147.52.100
root  5503  0.0  0.6  19624  1588 ?S08:54   0:00 /bin/bash 
/opt/cloud/bin/passwd_server_ip 10.1.1.1 dummy
root  5505  0.0  3.1  48472  7912 ?S08:54   0:00 python 
/opt/cloud/bin/passwd_server_ip.py 10.1.1.1
root  7567  0.0  0.3   8272   896 pts/0S+   09:09   0:00 grep 
passwd_server
{noformat}

Also observe the issue of assigning ips incorrectly to the interface after 
creating the private gateway. Once this issue is seen after that I am not able 
to reproduce.
{noformat}
- rVPC with private gateway has issues

  Logs after PGW configuration.
root@r-226-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:3f brd ff:ff:ff:ff:ff:ff
inet 169.254.2.63/16 brd 169.254.255.255 scope global eth0
5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:5c:96:00:04 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
inet 10.2.1.109/24 brd 10.2.1.255 scope global eth1
inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth1
7: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:2c:56:00:00:22 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth2
inet 10.147.52.1/24 brd 10.147.52.255 scope global secondary eth2
root@r-226-QA:~# checkrouter.sh
Status: MASTER
root@r-226-QA:~#

root@r-227-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:73 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.115/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ab:30:00:00:10 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
inet 10.2.1.45/24 brd 10.2.1.255 scope global eth1
inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:79:63:00:05 brd ff:ff:ff:ff:ff:ff
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:b4:c6:00:00:22 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.1/24 brd 10.147.52.255 scope global secondary eth3
root@r-227-QA:~#
root@r-227-QA:~# checkrouter.sh
Status: MASTER
root@r-227-QA:~#

Logs after PGW removal:
root@r-226-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:02:3f brd ff:ff:ff:ff:ff:ff
inet 169.254.2.63/16 brd 169.254.255.255 scope global eth0
5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:5c:96:00:04 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
inet 10.2.1.109/24 brd 10.2.1.255 scope global eth1
inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth1
root@r-226-QA:~# checkrouter.sh

Status: MASTER
root@r-226-QA:~#
root@r-227-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:73 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.115/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ab:30:00:00:10 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
inet 10.2.1.45/24 brd 10.2.1.255 scope global eth1
inet 

[jira] [Created] (CLOUDSTACK-9883) VPC RVR private gateway interface is not configured correctly

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9883:
-

 Summary: VPC RVR private gateway interface is not configured 
correctly
 Key: CLOUDSTACK-9883
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9883
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller, Network Devices
Reporter: Jayapal Reddy
 Fix For: 4.10.0.0


1. create a Redundant VPC.
2. Deploy a VM in the tier network.
3. Create a private gateway in VPC.
On master it is observed that the private gateway interface is configured with 
the privategateway ip and start ip in the subnet. Ex: private gateway ip is 
10.147.52.100 then it is also configured with the 10.147.52.1.
If 10.147.52.1 is the gateway then it will create issues.

{noformat}
root@r-256-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:02 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.2/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:dd:6c:00:00:10 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.104/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:01:28:00:07 brd ff:ff:ff:ff:ff:ff
inet 10.2.1.253/24 brd 10.2.1.255 scope global eth2
inet 10.2.1.1/24 brd 10.2.1.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:01:6a:00:00:24 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.100/24 brd 10.147.52.255 scope global eth3
inet 10.147.52.1/24 brd 10.147.52.255 scope global secondary eth3
root@r-256-QA:~# checkrouter.sh
Status: MASTER
root@r-256-QA:~#
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9099) SecretKey is returned from the APIs

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9099:
--
Affects Version/s: 4.9.0
Fix Version/s: 4.9.3.0
   4.10.0.0

> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
> Fix For: 4.10.0.0, 4.9.3.0
>
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9855) VPC RVR when master guest interface is down backup VR is not switched to Master

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9855:
-

 Summary: VPC RVR when master guest interface is down backup VR is 
not switched to Master
 Key: CLOUDSTACK-9855
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9855
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller, Network Devices
Affects Versions: 4.10.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.10.1.0


1. Create a vpc RVR setup.
2. Deploy a VM in tier network
3. SSH to master VR and down the guest interface.
4. Backup VM is not becoming master.

Also both the VRs are having VRRP ip 10.1.1.1

This issue is happening because in keepalived.conf:vrrp_instance config state 
is set to EQUAL. This is causing the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9855) VPC RVR when master guest interface is down backup VR is not switched to Master

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9855:
---

If we set the state to BACKUP the issues are solved.

> VPC RVR when master guest interface is down backup VR is not switched to 
> Master
> ---
>
> Key: CLOUDSTACK-9855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9855
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, Network Devices
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.1.0
>
>
> 1. Create a vpc RVR setup.
> 2. Deploy a VM in tier network
> 3. SSH to master VR and down the guest interface.
> 4. Backup VM is not becoming master.
> Also both the VRs are having VRRP ip 10.1.1.1
> This issue is happening because in keepalived.conf:vrrp_instance config state 
> is set to EQUAL. This is causing the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy edited comment on CLOUDSTACK-9848 at 3/23/17 1:30 PM:


Currently for add_chain exist status is not checked because the iptables rules 
add processing fails when iptables chain policy is added. This needs to be 
fixed.

 please see my below debug log.
For '-P INPUT DROP' in compare method it is trying add chain without name 
(actually there is no need to add chain for policy add rule) 'iptables -t 
filter -N'


2017-03-23 09:34:06,048  CsNetfilter.py compare:139 fw ['filter', '', '-P INPUT 
DROP']
2017-03-23 09:34:06,048  CsHelper.py execute2:209 Executing: iptables -t filter 
-N
2017-03-23 09:34:06,056  configure.py main:1032 Exception while configuring 
router
Traceback (most recent call last):
  File "/opt/cloud/bin/configure.py", line 1015, in main
nf.compare(config.get_fw())
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 143, in compare
self.add_chain(new_rule)
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 193, in add_chain
raise Exception("iptables command got failed with error: {}".format(error))
Exception: iptables command got failed with error:



was (Author: jayapal):
Currently for add_chain exist status is not checked because the iptables rules 
add processing fails when iptables chain policy is added. please see my below 
debug log.

For '-P INPUT DROP' in compare method it is trying add chain without name 
(actually there is no need to add chain for policy add rule) 'iptables -t 
filter -N'


2017-03-23 09:34:06,048  CsNetfilter.py compare:139 fw ['filter', '', '-P INPUT 
DROP']
2017-03-23 09:34:06,048  CsHelper.py execute2:209 Executing: iptables -t filter 
-N
2017-03-23 09:34:06,056  configure.py main:1032 Exception while configuring 
router
Traceback (most recent call last):
  File "/opt/cloud/bin/configure.py", line 1015, in main
nf.compare(config.get_fw())
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 143, in compare
self.add_chain(new_rule)
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 193, in add_chain
raise Exception("iptables command got failed with error: {}".format(error))
Exception: iptables command got failed with error:


> VR commands exist status is not checked in python config files
> --
>
> Key: CLOUDSTACK-9848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>
> When iptables rules are configured on the VR failures or exceptions are not 
> detected in VR because iptables commands exit/return status is not 
> checked.Also in exception catch failure is not returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9848:
---

Currently for add_chain exist status is not checked because the iptables rules 
add processing fails when iptables chain policy is added. please see my below 
debug log.

For '-P INPUT DROP' in compare method it is trying add chain without name 
(actually there is no need to add chain for policy add rule) 'iptables -t 
filter -N'


2017-03-23 09:34:06,048  CsNetfilter.py compare:139 fw ['filter', '', '-P INPUT 
DROP']
2017-03-23 09:34:06,048  CsHelper.py execute2:209 Executing: iptables -t filter 
-N
2017-03-23 09:34:06,056  configure.py main:1032 Exception while configuring 
router
Traceback (most recent call last):
  File "/opt/cloud/bin/configure.py", line 1015, in main
nf.compare(config.get_fw())
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 143, in compare
self.add_chain(new_rule)
  File "/opt/cloud/bin/cs/CsNetfilter.py", line 193, in add_chain
raise Exception("iptables command got failed with error: {}".format(error))
Exception: iptables command got failed with error:


> VR commands exist status is not checked in python config files
> --
>
> Key: CLOUDSTACK-9848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>
> When iptables rules are configured on the VR failures or exceptions are not 
> detected in VR because iptables commands exit/return status is not 
> checked.Also in exception catch failure is not returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9848:
-

 Summary: VR commands exist status is not checked in python config 
files
 Key: CLOUDSTACK-9848
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy


When iptables rules are configured on the VR failures or exceptions are not 
detected in VR because iptables commands exit/return status is not checked.Also 
in exception catch failure is not returned.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-9848:
-

Assignee: Jayapal Reddy

> VR commands exist status is not checked in python config files
> --
>
> Key: CLOUDSTACK-9848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>
> When iptables rules are configured on the VR failures or exceptions are not 
> detected in VR because iptables commands exit/return status is not 
> checked.Also in exception catch failure is not returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CLOUDSTACK-9821) Unable to deploy user VM in Basic Zone

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy edited comment on CLOUDSTACK-9821 at 3/7/17 11:00 AM:


If the xenserver host is previously added in basic zone set then to test this 
ticket remove the existing file /var/cache/cloud/ipset.keyword  in the 
xenserver hypervisor.  If it is fresh installation of xenserver then 
ipset.keyword file won't there first time.



was (Author: jayapal):
To test this ticket remove the existing file /var/cache/cloud/ipset.keyword  in 
the xenserver hypervisor. Otherwise it will not hit the code.

> Unable to deploy user VM in Basic Zone
> --
>
> Key: CLOUDSTACK-9821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: Ubuntu 12.04 for CS MS
>Reporter: Mike Tutkowski
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> From my e-mails on dev@ concerning this issue (messages listed oldest to 
> newest):
> I see the following exception when trying to deploy a user VM in a Basic Zone 
> with two XenServer 6.5 hosts in one cluster. My system VMs have all deployed 
> properly. The user template gets downloaded fine. I can see the user VM begin 
> to start on a XenServer host, then it goes away. We then automatically try on 
> the other host. I can see the VM begin to start there for a moment, then it 
> goes away.
> I am just deploying the user VM’s template and root disk to NFS (same place 
> where the template and root disks of my system VMs are).
> I am using the built-in XenServer CentOS 5.6 (64 bit) template with 1 vCPU, 
> 500 MHz, and 256 MB memory.
> WARN  [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-7:ctx-35aded78) 
> (logid:aab9c320) Expected 1 answers while executing VmDataCommand but 
> received 2
> WARN  [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-14:ctx-27fb1ac3) (logid:2c342f23) VM state was updated 
> but update time is null?! vm id: 6
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) Begin cleanup expired 
> async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) End cleanup expired 
> async-jobs
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 removed accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 inactive domains to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled projects to cleanup
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) callHostPlugin failed for cmd: default_network_rules with 
> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP: 10.117.40.53, vmMAC: 
> 06:b2:f4:00:00:22,  due to There was a failure communicating with the plugin.
> WARN  [c.c.h.x.r.w.x.CitrixStartCommandWrapper] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) Catch Exception: class 
> com.cloud.utils.exception.CloudRuntimeException due to 
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:338)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1691)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> at 
> 

[jira] [Commented] (CLOUDSTACK-9821) Unable to deploy user VM in Basic Zone

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9821:
---

To test this ticket remove the existing file /var/cache/cloud/ipset.keyword  in 
the xenserver hypervisor. Otherwise it will not hit the code.

> Unable to deploy user VM in Basic Zone
> --
>
> Key: CLOUDSTACK-9821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: Ubuntu 12.04 for CS MS
>Reporter: Mike Tutkowski
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> From my e-mails on dev@ concerning this issue (messages listed oldest to 
> newest):
> I see the following exception when trying to deploy a user VM in a Basic Zone 
> with two XenServer 6.5 hosts in one cluster. My system VMs have all deployed 
> properly. The user template gets downloaded fine. I can see the user VM begin 
> to start on a XenServer host, then it goes away. We then automatically try on 
> the other host. I can see the VM begin to start there for a moment, then it 
> goes away.
> I am just deploying the user VM’s template and root disk to NFS (same place 
> where the template and root disks of my system VMs are).
> I am using the built-in XenServer CentOS 5.6 (64 bit) template with 1 vCPU, 
> 500 MHz, and 256 MB memory.
> WARN  [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-7:ctx-35aded78) 
> (logid:aab9c320) Expected 1 answers while executing VmDataCommand but 
> received 2
> WARN  [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-14:ctx-27fb1ac3) (logid:2c342f23) VM state was updated 
> but update time is null?! vm id: 6
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) Begin cleanup expired 
> async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) End cleanup expired 
> async-jobs
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 removed accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 inactive domains to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled projects to cleanup
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) callHostPlugin failed for cmd: default_network_rules with 
> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP: 10.117.40.53, vmMAC: 
> 06:b2:f4:00:00:22,  due to There was a failure communicating with the plugin.
> WARN  [c.c.h.x.r.w.x.CitrixStartCommandWrapper] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) Catch Exception: class 
> com.cloud.utils.exception.CloudRuntimeException due to 
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:338)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1691)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> 

[jira] [Commented] (CLOUDSTACK-9821) Unable to deploy user VM in Basic Zone

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9821:
---

{noformat}
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] ['/bin/bash', '-c', 'ipset', 
'-N', 'ipsetqzvxtmp', 'nethash']
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] FAILED in util.pread: (rc 2) 
stdout: '', stderr: 'ipset v6.11: No command specified.
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] Try `ipset help' for more 
information.
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] '
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] ['/bin/bash', '-c', 'ipset', 
'-F', 'ipsetqzvxtmp']
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] FAILED in util.pread: (rc 2) 
stdout: '', stderr: 'ipset v6.11: No command specified.
Mar  6 18:49:44 xenserver-ownpphln SM: [8771] Try `ipset help' for more 
information.
{noformat}

> Unable to deploy user VM in Basic Zone
> --
>
> Key: CLOUDSTACK-9821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: Ubuntu 12.04 for CS MS
>Reporter: Mike Tutkowski
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> From my e-mails on dev@ concerning this issue (messages listed oldest to 
> newest):
> I see the following exception when trying to deploy a user VM in a Basic Zone 
> with two XenServer 6.5 hosts in one cluster. My system VMs have all deployed 
> properly. The user template gets downloaded fine. I can see the user VM begin 
> to start on a XenServer host, then it goes away. We then automatically try on 
> the other host. I can see the VM begin to start there for a moment, then it 
> goes away.
> I am just deploying the user VM’s template and root disk to NFS (same place 
> where the template and root disks of my system VMs are).
> I am using the built-in XenServer CentOS 5.6 (64 bit) template with 1 vCPU, 
> 500 MHz, and 256 MB memory.
> WARN  [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-7:ctx-35aded78) 
> (logid:aab9c320) Expected 1 answers while executing VmDataCommand but 
> received 2
> WARN  [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-14:ctx-27fb1ac3) (logid:2c342f23) VM state was updated 
> but update time is null?! vm id: 6
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) Begin cleanup expired 
> async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) End cleanup expired 
> async-jobs
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 removed accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 inactive domains to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled projects to cleanup
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) callHostPlugin failed for cmd: default_network_rules with 
> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP: 10.117.40.53, vmMAC: 
> 06:b2:f4:00:00:22,  due to There was a failure communicating with the plugin.
> WARN  [c.c.h.x.r.w.x.CitrixStartCommandWrapper] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) Catch Exception: class 
> com.cloud.utils.exception.CloudRuntimeException due to 
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:338)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> 

[jira] [Commented] (CLOUDSTACK-9821) Unable to deploy user VM in Basic Zone

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9821:
---

{noformat}

Mar  6 18:34:39 xenserver-ownpphln SM: [28875] ['ipset', '-N', 'ipsetqzvxtmp', 
'nethash']
Mar  6 18:34:39 xenserver-ownpphln SM: [28875]   pread SUCCESS
Mar  6 18:34:39 xenserver-ownpphln SM: [28875] ['/bin/bash', '-c', 'iptables -A 
INPUT -m set --set ipsetqzvxtmp src -j ACCEPT']
Mar  6 18:34:39 xenserver-ownpphln SM: [28875]   pread SUCCESS
Mar  6 18:34:39 xenserver-ownpphln SM: [28875] ['/bin/bash', '-c', 'iptables -D 
INPUT -m set --set ipsetqzvxtmp src -j ACCEPT']
Mar  6 18:34:39 xenserver-ownpphln SM: [28875]   pread SUCCESS
Mar  6 18:34:39 xenserver-ownpphln SM: [28875] ['ipset', '-X', 'ipsetqzvxtmp']
Mar  6 18:34:39 xenserver-ownpphln SM: [28875]   pread SUCCESS
{noformat}

# /bin/bash -c ipset -N ipsetqzvxtmp nethash
ipset v6.11: No command specified.
Try `ipset help' for more information.
[root@xenserver-ownpphln ~]# /bin/bash -c "ipset -N ipsetqzvxtmp nethash"
[root@xenserver-ownpphln ~]# 

> Unable to deploy user VM in Basic Zone
> --
>
> Key: CLOUDSTACK-9821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: Ubuntu 12.04 for CS MS
>Reporter: Mike Tutkowski
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> From my e-mails on dev@ concerning this issue (messages listed oldest to 
> newest):
> I see the following exception when trying to deploy a user VM in a Basic Zone 
> with two XenServer 6.5 hosts in one cluster. My system VMs have all deployed 
> properly. The user template gets downloaded fine. I can see the user VM begin 
> to start on a XenServer host, then it goes away. We then automatically try on 
> the other host. I can see the VM begin to start there for a moment, then it 
> goes away.
> I am just deploying the user VM’s template and root disk to NFS (same place 
> where the template and root disks of my system VMs are).
> I am using the built-in XenServer CentOS 5.6 (64 bit) template with 1 vCPU, 
> 500 MHz, and 256 MB memory.
> WARN  [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-7:ctx-35aded78) 
> (logid:aab9c320) Expected 1 answers while executing VmDataCommand but 
> received 2
> WARN  [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-14:ctx-27fb1ac3) (logid:2c342f23) VM state was updated 
> but update time is null?! vm id: 6
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) Begin cleanup expired 
> async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) End cleanup expired 
> async-jobs
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 removed accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 inactive domains to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled projects to cleanup
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) callHostPlugin failed for cmd: default_network_rules with 
> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP: 10.117.40.53, vmMAC: 
> 06:b2:f4:00:00:22,  due to There was a failure communicating with the plugin.
> WARN  [c.c.h.x.r.w.x.CitrixStartCommandWrapper] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) Catch Exception: class 
> com.cloud.utils.exception.CloudRuntimeException due to 
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: default_network_rules with args secIps: 0:, vmName: i-2-6-VM, vmID: 6, 
> vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22,  due to There was a failure 
> communicating with the plugin.
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:338)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)

[jira] [Commented] (CLOUDSTACK-9821) Unable to deploy user VM in Basic Zone

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-9821:
---

In vmops file ipset command 'ipset -N' in single string causing the issue.

Error from the /var/log/SMlog
{noformat}

Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['ipset', '-N', 'i-2-47-QA', 
'nethash']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133]   pread SUCCESS
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['ipset', '-A', 'i-2-47-QA', 
'10.147.40.158']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133]   pread SUCCESS
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['/bin/bash', '-c', "ipset -v | 
awk '{print $5}'"]
Mar  6 16:32:35 xenserver-ownpphln SM: [21133]   pread SUCCESS
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['/bin/bash', '-c', 'ipset -N ', 
'ipsetqzvxtmp', 'nethash']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] FAILED in util.pread: (rc 2) 
stdout: '', stderr: 'ipset v6.11: Missing mandatory argument to command create
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] Try `ipset help' for more 
information.
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] '
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['/bin/bash', '-c', 'ipset -F ', 
'ipsetqzvxtmp']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133]   pread SUCCESS
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['/bin/bash', '-c', 'iptables -A 
INPUT -m set --set ipsetqzvxtmp src -j ACCEPT']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] FAILED in util.pread: (rc 2) 
stdout: '', stderr: '--set option deprecated, please use --match-set
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] iptables v1.4.16.3: Set 
ipsetqzvxtmp doesn't exist.
Mar  6 16:32:35 xenserver-ownpphln SM: [21133]
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] Try `iptables -h' or 'iptables 
--help' for more information.
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] '
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] ['/bin/bash', '-c', 'ipset -X 
ipsetqzvxtmp']
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] FAILED in util.pread: (rc 1) 
stdout: '', stderr: 'ipset v6.11: The set with the given name does not exist
Mar  6 16:32:35 xenserver-ownpphln SM: [21133] '


{noformat}

> Unable to deploy user VM in Basic Zone
> --
>
> Key: CLOUDSTACK-9821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: Ubuntu 12.04 for CS MS
>Reporter: Mike Tutkowski
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> From my e-mails on dev@ concerning this issue (messages listed oldest to 
> newest):
> I see the following exception when trying to deploy a user VM in a Basic Zone 
> with two XenServer 6.5 hosts in one cluster. My system VMs have all deployed 
> properly. The user template gets downloaded fine. I can see the user VM begin 
> to start on a XenServer host, then it goes away. We then automatically try on 
> the other host. I can see the VM begin to start there for a moment, then it 
> goes away.
> I am just deploying the user VM’s template and root disk to NFS (same place 
> where the template and root disks of my system VMs are).
> I am using the built-in XenServer CentOS 5.6 (64 bit) template with 1 vCPU, 
> 500 MHz, and 256 MB memory.
> WARN  [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-7:ctx-35aded78) 
> (logid:aab9c320) Expected 1 answers while executing VmDataCommand but 
> received 2
> WARN  [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-14:ctx-27fb1ac3) (logid:2c342f23) VM state was updated 
> but update time is null?! vm id: 6
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) Begin cleanup expired 
> async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce) (logid:a56a9a8c) End cleanup expired 
> async-jobs
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 removed accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled accounts to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 inactive domains to cleanup
> INFO  [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-383a632c) 
> (logid:541e9ba5) Found 0 disabled projects to cleanup
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-16:ctx-7c901443) 
> (logid:aab9c320) callHostPlugin failed for cmd: default_network_rules with 
> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP: 10.117.40.53, vmMAC: 
> 06:b2:f4:00:00:22,  due to There was a failure communicating with the 

[jira] [Commented] (CLOUDSTACK-8871) Basic zone security group ingress/egress rules are not working for some cidrs

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-8871:
---

xenserver 6.2:
[root@localhost ~]# ipset -v
ipset v4.5, protocol version 4.
Kernel module protocol version 4.

xenserver 6.5:
[root@xenserver-ownpphln ~]# ipset -v 
ipset v6.11, protocol version: 6

> Basic zone security group ingress/egress rules are not working for some cidrs
> -
>
> Key: CLOUDSTACK-8871
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8871
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: Future
>
>
> 1. Create a basic zone with xenserver 6.2.
> 2. Configure the ingress/egress rules in security group with cidrs /32
> 3. Rules got applied on UI but the traffic is not working.
> Reason:
> CIDR mentioned in the rules are failed to add ipset. 
> output from the SMLog:
> Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: 
> '', stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
> Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for 
> more information.
> Sep 16 10:52:39 localhost SM: [25871] '



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9757) VPC traffic from vm to additional public subnet is not working

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9757:
-

 Summary: VPC traffic from vm to additional public subnet is not 
working
 Key: CLOUDSTACK-9757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9757
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


1. Add additional Public IP to Physical Network (specify a VLAN ID to isolate 
traffic),
2. Create PortForward rule in VPC
i) Acquire New IP , which used additional Public IP
ii) Map a VM instance to use this Public IP
3. Observe that when VM ping additional public subnet then it is  not working


For additional public subnet ip SNAT rules are not configured when PF/Staticnat 
is configured. Due to this PF/StaticNAT VM traffic from to additional public 
subnet is not SNATed to public ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9756) IP address must not be allocated to other VR if releasing ip address is failed

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9756:
-

 Summary:  IP address must not be allocated to other VR if 
releasing ip address is failed
 Key: CLOUDSTACK-9756
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9756
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


Apply rule (delete) is success on failure of ip assoc on back end. Cloudstack 
ignored the ip assoc failure.
Due to this the ip got freed and assigned to another network/account. It caused 
the ip to be present in more than one router.

Fix: Failing the apply rule (delete) on ipassoc failure

Repro steps:
1. Configure PF/static nat/Firewall rules
2. Delete the rule configured.
On deleting the rule, fail the ip assoc on the router.
3. Delete rule fails because ip assoc got failed.

For RVR:
1. acquire several public ips,
2. add some rules on those public ips, so ips should show up in RVR,
3. change ipassoc.sh in RVR, make it always returns error on disassociate ip.
4. disassociate ip from  UI, ip should  is freed even though disassociate fails 
inside VR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9728) query to traffic sentinel requesting for usage stats is too long resulting in traffic sentinel sending HTTP 414 error response

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9728:
-

 Summary: query to traffic sentinel requesting for usage stats is 
too long resulting in traffic sentinel sending HTTP 414 error response
 Key: CLOUDSTACK-9728
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9728
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


The query sent to the traffic sentinel to retrieve network usage information is 
rejected with a 414 error because the string is too long for it to process



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9724) VPC tier network restart with cleanup, missing public ip on VR interface

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9724:
-

 Summary: VPC tier network restart with cleanup, missing public ip 
on VR interface
 Key: CLOUDSTACK-9724
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9724
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


On vpc tier network restart with clean up missing secondary ip addresses on the 
VR public interface.

1. Create a vpc and deploy a vm in tier.
2. Acquire a public ip and configure PF rule
3. check that the VR interface has two ip addresses.
4. Restart the tier network with cleanup.
5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9723) Enable unique mac address across different deployments and networks

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9723:
-

 Summary: Enable unique mac address across different deployments 
and networks
 Key: CLOUDSTACK-9723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9723
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


Specify the MAC address range for VMs created in ACS

If there are Multiple CCP environments, There is  difficulty in identifying VMs 
based on their MAC addresses since the addresses are duplicated across 
environments.

Specifying the MAC address range in zone will avoid the conflict.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9715) "somaxconn" value on VR is not reflecting value from /etc/sysctl.conf

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9715:
-

 Summary: "somaxconn" value on VR is not reflecting value from 
/etc/sysctl.conf
 Key: CLOUDSTACK-9715
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9715
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.10.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


"somaxconn" value on VR is not reflecting value from /etc/sysctl.conf.

We checked the parameter of "somaxconn" in the virtual router. 
# cat /proc/sys/net/net/core/somaxconn 
128 

And we checked the file "sysctl.conf" in virtual router. 
# cat /etc/sysctl.conf | grep somaxconn 
net.core.somaxconn=100 

#sysctl -p # output
.
sysctl: setting key "net.core.somaxconn": Invalid argument
net.core.somaxconn = 100
..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9713) LB rule return traffic on additional public NIC on VPC VR is on default gateway interface

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9713:
-

 Summary: LB rule return traffic on additional public NIC on VPC VR 
is on default gateway interface
 Key: CLOUDSTACK-9713
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9713
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


1.  Configure LB rule on additional public subnet ip address.(ex: LB rule for 
SSH)
2.  ssh to to the ip address on which LB is configured
3. Capture the traffic on additional public subnet interface and source nat 
public interface.
4. The traffic is coming on the additional public subnet interface but the 
return traffic is going on the source nat public interface.

Due to this the LB connection will fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9711) Remote Access vpn user add fail ignored when the VR in stopped state

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9711:
-

 Summary: Remote Access vpn user add fail ignored when the VR in 
stopped state
 Key: CLOUDSTACK-9711
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9711
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


1. Create multiple networks in an account
2. Enable remote access vpn.
3. Stop the VR for one of the network.
4. Configure vpn user. 

If configuring vpn user in one of the network fails the failure is ignored.
Failure should be shown in API response.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9709) DHCP/DNS offload: Use correct thread pool for IP fetch task

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9709:
-

 Summary: DHCP/DNS offload: Use correct thread pool for IP fetch 
task
 Key: CLOUDSTACK-9709
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9709
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.10.0.0


Currently IP fetch task is using the same thread pool as VM expunge. This can 
lead to confusion
Also the IP fetch task uses another thread pool (name of the variable 
_vmIpFetchThreadExecutor) which is not initialized. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9702) VR iptables configuration issues

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9702:
-

 Summary: VR iptables configuration issues
 Key: CLOUDSTACK-9702
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9702
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy


1. If there is a exception in configure.py while adding the iptables rule the 
error is not reported back to API, API response shows success.

- If there is failure in delete (due to iptables rule is incorrectly framed) 
then this rule stays in VR till VR reboots.

a. In CsNetfilter.py: __convert_to_dict() method is inefficient. With this 
method it is not possible to include the option if it is there multiple times.
b. Second thing is it rely on the key value pair of iptable option and value. 
It will not work for iptables.
Example rule for the a and b
iptables -A FW_EGRESS_RULES -p tcp -m set --match-set sourceCidrIpset  src -m 
set --match-set destCidrIpset dst -m tcp --dport 22 -j DROP

In the above example -m option is present multiple times.
If we slit key value for the dictionary then you will get destCidrIpset will 
get as key which is a variable (not a iptables option)

With the existing code of CsNetfilter it will not frame the exact rule for the 
deletion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9669) Add destination CIDR for the advanced zone isolated network egress rules

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9669:
-

 Summary: Add destination CIDR for the advanced zone isolated 
network egress rules
 Key: CLOUDSTACK-9669
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9669
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.9.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy


Current egress rules implementation has only source cidr.
Add destination CIDR in rules  to control destination cidr traffic



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9657) Ipset command fails for VM's with long internal name

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9657:
-

 Summary: Ipset command fails for VM's with long internal name
 Key: CLOUDSTACK-9657
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9657
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.9.1.0


ipset rules configuration in security groups is failing for the VM with longer 
name 
ipset -N 12345677 nethash
ipset v6.11: Syntax error: setname '12345677' is longer 
than 31 characters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9617) Enabling Remote access Vpn Fails when there is a portforwarding rule of the reserved ports ( 1701 , 500 , 4500) under TCP protocol.

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9617:
-

 Summary: Enabling Remote access Vpn Fails when there is a 
portforwarding rule of the reserved ports ( 1701 , 500 , 4500) under TCP 
protocol.
 Key: CLOUDSTACK-9617
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9617
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.9.2.0


Navigate to Network -> Configuration -> Portforwarding
Create a new rule 1701 under both private and public ports for TCP Protocol and 
assign a VM.
Now Enable Remote access VPN on the Network .

observation :
Enabling VPN acess is failing with the following error "The range 
specified, 1701-1701, conflicts with rule 53 which has 1701-1701 "

Expected Result :

Enabling VPN should be sucessful , as the port forwarding rule added is TCP 
protocol , and the firewall rules populated when VPN is enabled is UDP protocol.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9615) Ingress Firewall Rules with blank start and End ports doesnt get applied

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9615:
-

 Summary: Ingress Firewall Rules with blank start and End ports 
doesnt get applied
 Key: CLOUDSTACK-9615
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9615
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.9.2.0


   1.  Navigate to Network -> view ip adress -> Source Nat -> Configuration -> 
Firewall.
   2.  Add new TCp rule without giving any start port or end port.
   3. The rule creation is success in API, but its not applied in VR .
   4.  Only when specific port are provided the rule is applied .




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9612) Restart Network with clean up fails for networks whose offering has been changed from Isolated -> RVR

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-9612:
-

Assignee: Jayapal Reddy

> Restart Network with clean up fails for networks whose offering has been 
> changed from Isolated -> RVR
> -
>
> Key: CLOUDSTACK-9612
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9612
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
> Deploy a network N1 with " Offering for Isolated networks with Source Nat 
> service enabled" . Ensure both vm and vr are UP .
> Create a RVR offering and edit the network offering from the current to 
> RVR ofefring .
> Ensure both Master and Backup are up and running.
> Now restart the network with clean up option enabled.
> Observations :
> Restarting the nw with clean up is creating is failing with the below error.
> {noformat}
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Start completed for VM VM[DomainRouter|r-21-QA]
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Done executing VM work job: 
> com.cloud.vm.VmWorkStart{"dcId":0,"rawParams":{"RestartNetwork":"rO0ABXNyABFqYXZhLmxhbmcuQm9vbGVhbs0gcoDVnPruAgABWgAFdmFsdWV4cAE"},"userId":2,"accountId":2,"vmId":21,"handlerName":"VirtualMachineManagerImpl"}
> 2016-11-24 15:49:32,432 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Complete async job-104, jobStatus: SUCCEEDED, resultCode: 0, 
> result: null
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Publish async job-104 complete on message bus
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs related to job-104
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Update db status for job-104
> 2016-11-24 15:49:32,435 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs joined with job-104 and disjoin all subjobs 
> created from job- 104
> 2016-11-24 15:49:32,446 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done with 
> run of VM work job: com.cloud.vm.VmWorkStart for VM 21, job origin: 99
> 2016-11-24 15:49:32,446 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done 
> executing com.cloud.vm.VmWorkStart for job-104
> 2016-11-24 15:49:32,448 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Remove 
> job-104 from job monitoring
> 2016-11-24 15:49:32,455 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-10:ctx-d835fe9f job-99 ctx-2cd2b41c) (logid:fb2d5b7b) 
> Failed to implement network Ntwk[204|Guest|16] elements and resources as a 
> part of network restart due to 
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Can't find all necessary running routers!
>   at 
> com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:226)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1132)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2740)
>   at 
> com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1907)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> 

[jira] [Updated] (CLOUDSTACK-9612) Restart Network with clean up fails for networks whose offering has been changed from Isolated -> RVR

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-9612:
--
Fix Version/s: 4.9.2.0

> Restart Network with clean up fails for networks whose offering has been 
> changed from Isolated -> RVR
> -
>
> Key: CLOUDSTACK-9612
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9612
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.2.0
>
>
> Deploy a network N1 with " Offering for Isolated networks with Source Nat 
> service enabled" . Ensure both vm and vr are UP .
> Create a RVR offering and edit the network offering from the current to 
> RVR ofefring .
> Ensure both Master and Backup are up and running.
> Now restart the network with clean up option enabled.
> Observations :
> Restarting the nw with clean up is creating is failing with the below error.
> {noformat}
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Start completed for VM VM[DomainRouter|r-21-QA]
> 2016-11-24 15:49:32,432 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Done executing VM work job: 
> com.cloud.vm.VmWorkStart{"dcId":0,"rawParams":{"RestartNetwork":"rO0ABXNyABFqYXZhLmxhbmcuQm9vbGVhbs0gcoDVnPruAgABWgAFdmFsdWV4cAE"},"userId":2,"accountId":2,"vmId":21,"handlerName":"VirtualMachineManagerImpl"}
> 2016-11-24 15:49:32,432 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Complete async job-104, jobStatus: SUCCEEDED, resultCode: 0, 
> result: null
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Publish async job-104 complete on message bus
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs related to job-104
> 2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Update db status for job-104
> 2016-11-24 15:49:32,435 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
> (logid:fb2d5b7b) Wake up jobs joined with job-104 and disjoin all subjobs 
> created from job- 104
> 2016-11-24 15:49:32,446 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done with 
> run of VM work job: com.cloud.vm.VmWorkStart for VM 21, job origin: 99
> 2016-11-24 15:49:32,446 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done 
> executing com.cloud.vm.VmWorkStart for job-104
> 2016-11-24 15:49:32,448 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Remove 
> job-104 from job monitoring
> 2016-11-24 15:49:32,455 WARN  [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-10:ctx-d835fe9f job-99 ctx-2cd2b41c) (logid:fb2d5b7b) 
> Failed to implement network Ntwk[204|Guest|16] elements and resources as a 
> part of network restart due to 
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Can't find all necessary running routers!
>   at 
> com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:226)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1132)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2740)
>   at 
> com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1907)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> 

[jira] [Created] (CLOUDSTACK-9612) Restart Network with clean up fails for networks whose offering has been changed from Isolated -> RVR

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-9612:
-

 Summary: Restart Network with clean up fails for networks whose 
offering has been changed from Isolated -> RVR
 Key: CLOUDSTACK-9612
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9612
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy



Deploy a network N1 with " Offering for Isolated networks with Source Nat 
service enabled" . Ensure both vm and vr are UP .
Create a RVR offering and edit the network offering from the current to RVR 
ofefring .
Ensure both Master and Backup are up and running.
Now restart the network with clean up option enabled.

Observations :
Restarting the nw with clean up is creating is failing with the below error.

{noformat}
2016-11-24 15:49:32,432 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Start completed for VM VM[DomainRouter|r-21-QA]
2016-11-24 15:49:32,432 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Done executing VM work job: 
com.cloud.vm.VmWorkStart{"dcId":0,"rawParams":{"RestartNetwork":"rO0ABXNyABFqYXZhLmxhbmcuQm9vbGVhbs0gcoDVnPruAgABWgAFdmFsdWV4cAE"},"userId":2,"accountId":2,"vmId":21,"handlerName":"VirtualMachineManagerImpl"}
2016-11-24 15:49:32,432 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Complete async job-104, jobStatus: SUCCEEDED, resultCode: 0, 
result: null
2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Publish async job-104 complete on message bus
2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Wake up jobs related to job-104
2016-11-24 15:49:32,434 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Update db status for job-104
2016-11-24 15:49:32,435 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104 ctx-8f4ab192) 
(logid:fb2d5b7b) Wake up jobs joined with job-104 and disjoin all subjobs 
created from job- 104
2016-11-24 15:49:32,446 DEBUG [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done with 
run of VM work job: com.cloud.vm.VmWorkStart for VM 21, job origin: 99
2016-11-24 15:49:32,446 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Done 
executing com.cloud.vm.VmWorkStart for job-104
2016-11-24 15:49:32,448 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-47:ctx-a1f65072 job-99/job-104) (logid:fb2d5b7b) Remove 
job-104 from job monitoring
2016-11-24 15:49:32,455 WARN  [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-10:ctx-d835fe9f job-99 ctx-2cd2b41c) (logid:fb2d5b7b) Failed 
to implement network Ntwk[204|Guest|16] elements and resources as a part of 
network restart due to 
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
unreachable: Can't find all necessary running routers!
at 
com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:226)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1132)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2740)
at 
com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1907)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 

[jira] [Commented] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-8876:
---

Below is the fix diff for this issue. I don't have the time to run the tests on 
it. I am unassinging it, some one can pick it up.


diff --git a/server/src/com/cloud/network/IpAddressManagerImpl.java 
b/server/src/com/cloud/network/IpAddressManagerImpl.java
index 28df971..46e0614 100644
--- a/server/src/com/cloud/network/IpAddressManagerImpl.java
+++ b/server/src/com/cloud/network/IpAddressManagerImpl.java
@@ -456,6 +456,12 @@ public class IpAddressManagerImpl extends ManagerBase 
implements IpAddressManage
 }
 } else {
 if (activeCount != null && activeCount > 0) {
+if (network.getVpcId() != null) {
+// If there are more than one ip in the vpc tier 
network and services configured on it.
+// restart network with cleanup case, on network 
reprogramming this needs to be return true
+// because on the VR ips has removed.
+return true;
+}
 continue;
 } else if (addCount != null && addCount.longValue() == 
totalCount.longValue()) {
 s_logger.trace("All rules are in Add state, have to 
assiciate IP with the backend");

>  VPC tier network restart, missing ip on VR interface
> -
>
> Key: CLOUDSTACK-8876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Reproducing steps:
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8881) [Blocker] PF , static nat , LB , egress rules not working in case of isolated networks

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-8881:
---

1. This PR includes the changes for static nat and PF. 
2. For LB there is no firewall rules configuration in VR. It can be take it as 
separate task/ticket.
3. For egress rules there is PR#881

> [Blocker] PF , static nat , LB , egress rules not working in case of isolated 
> networks
> --
>
> Key: CLOUDSTACK-8881
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8881
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> BVTs are failing as - 
> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
> integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat
> integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_src_nat
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule
> integration.smoke.test_network.TestRebootRouter.test_reboot_router
> Repro steps:
> 1.Create a advance zone setup
> 2. Create a VM in isolated network 
> 3. add PF rules, LB rules, Static nat rules ,firewall rules , Egress rules to 
> the network
> ( i added the rules for port 22 and on different public ips by acquiring ips )
> Bug: 
> none of the rules works
> Routers iptables shows following entries
> Chain INPUT (policy DROP 1330 packets, 79806 bytes)
> pkts bytes target prot opt in out source dest ination
> 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8881) [Blocker] PF , static nat , LB , egress rules not working in case of isolated networks

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-8881:
---

This is separate issue and it is not depended on the  CLOUDSTACK-8795.
I fixed the static nat , PF issue. I will add the PR.


> [Blocker] PF , static nat , LB , egress rules not working in case of isolated 
> networks
> --
>
> Key: CLOUDSTACK-8881
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8881
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> BVTs are failing as - 
> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
> integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat
> integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_src_nat
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule
> integration.smoke.test_network.TestRebootRouter.test_reboot_router
> Repro steps:
> 1.Create a advance zone setup
> 2. Create a VM in isolated network 
> 3. add PF rules, LB rules, Static nat rules ,firewall rules , Egress rules to 
> the network
> ( i added the rules for port 22 and on different public ips by acquiring ips )
> Bug: 
> none of the rules works
> Routers iptables shows following entries
> Chain INPUT (policy DROP 1330 packets, 79806 bytes)
> pkts bytes target prot opt in out source dest ination
> 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8795) outgoing public traffic blocked in vm created using DefaultIsolatedNetworkOfferingWithSourceNatService

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-8795.
---
Resolution: Duplicate

> outgoing public traffic blocked in vm created using 
> DefaultIsolatedNetworkOfferingWithSourceNatService 
> ---
>
> Key: CLOUDSTACK-8795
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8795
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: Xenserver 6.5, advanced zone, CS 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> in case of vm launched in vpc, outgoing public traffic worked (I was able to 
> ping google.com)
> But, in case of default isolated 
> network(DefaultIsolatedNetworkOfferingWithSourceNatService) vm, outgoing 
> public traffic was blocked even after adding egress rule.
> It only worked after running the following on isolated VR
> iptables -I FW_OUTBOUND -j FIREWALL_EGRESS_RULES
> This issue is observed while reviewing PR #765 
> https://github.com/apache/cloudstack/pull/765#issuecomment-136962555



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8795) outgoing public traffic blocked in vm created using DefaultIsolatedNetworkOfferingWithSourceNatService

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-8795:
---

[~rajanik] [~wilder.rodrigues]
Added the PR for this in https://issues.apache.org/jira/browse/CLOUDSTACK-8905

> outgoing public traffic blocked in vm created using 
> DefaultIsolatedNetworkOfferingWithSourceNatService 
> ---
>
> Key: CLOUDSTACK-8795
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8795
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: Xenserver 6.5, advanced zone, CS 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> in case of vm launched in vpc, outgoing public traffic worked (I was able to 
> ping google.com)
> But, in case of default isolated 
> network(DefaultIsolatedNetworkOfferingWithSourceNatService) vm, outgoing 
> public traffic was blocked even after adding egress rule.
> It only worked after running the following on isolated VR
> iptables -I FW_OUTBOUND -j FIREWALL_EGRESS_RULES
> This issue is observed while reviewing PR #765 
> https://github.com/apache/cloudstack/pull/765#issuecomment-136962555



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-8905) [Blocker] Egress rules are not configured in VR

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-8905:
-

Assignee: Jayapal Reddy

> [Blocker] Egress rules are not configured in VR
> ---
>
> Key: CLOUDSTACK-8905
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8905
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> 1. Deployed CS Advanced zone.
>  2. Created an isolated network.
>  3. Navigate to Egress rule:
>  Observing a pop up message:
>  "Configure the rules to allow Traffic"
> Inside VR :
> root@r-9-VM:~# iptables-save
> 1.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015
>  *filter
>  :INPUT DROP [0:0]
>  :FORWARD DROP [0:0]
>  :OUTPUT ACCEPT [65:7867]
>  :FW_OUTBOUND - [0:0]
>  :NETWORK_STATS - [0:0]
>  -A INPUT -j NETWORK_STATS
>  -A INPUT -d 224.0.0.18/32 -j ACCEPT
>  -A INPUT -d 225.0.0.50/32 -j ACCEPT
>  -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A INPUT -p icmp -j ACCEPT
>  -A INPUT -i lo -j ACCEPT
>  -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED 
> -j ACCEPT
>  -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED 
> -j ACCEPT
>  -A INPUT -d 224.0.0.18/32 -j ACCEPT
>  -A INPUT -d 225.0.0.50/32 -j ACCEPT
>  -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A INPUT -p icmp -j ACCEPT
>  -A INPUT -i lo -j ACCEPT
>  -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT
>  -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
>  -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT
>  -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
>  -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
>  -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED 
> -j ACCEPT
>  -A FORWARD -j NETWORK_STATS
>  -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT
>  -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
>  -A OUTPUT -j NETWORK_STATS
>  -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A NETWORK_STATS -i eth0 -o eth2
>  -A NETWORK_STATS -i eth2 -o eth0
>  -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp
>  -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp
>  COMMIT
> 2.Completed on Wed Sep 23 10:46:46 2015
> 3.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015
>  *nat
>  :PREROUTING ACCEPT [21:1428]
>  :INPUT ACCEPT [21:1428]
>  :OUTPUT ACCEPT [2:152]
>  :POSTROUTING ACCEPT [0:0]
>  -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.9
>  COMMIT
> 4.Completed on Wed Sep 23 10:46:46 2015
> 5.Generated by iptables-save v1.4.14 on Wed Sep 23 10:46:46 2015
>  *mangle
>  :PREROUTING ACCEPT [331:33456]
>  :INPUT ACCEPT [352:35052]
>  :FORWARD ACCEPT [0:0]
>  :OUTPUT ACCEPT [331:44643]
>  :POSTROUTING ACCEPT [331:44643]
>  :FIREWALL_10.147.47.9 - [0:0]
>  :VPN_10.147.47.9 - [0:0]
>  -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK 
> --restore-mark --nfmask 0x --ctmask 0x
>  -A PREROUTING -d 10.147.47.9/32 -j FIREWALL_10.147.47.9
>  -A PREROUTING -d 10.147.47.9/32 -j VPN_10.147.47.9
>  -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK 
> --restore-mark --nfmask 0x --ctmask 0x
>  -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark 
> 0x2/0x
>  -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
>  -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
>  -A FIREWALL_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A FIREWALL_10.147.47.9 -j DROP
>  -A VPN_10.147.47.9 -m state --state RELATED,ESTABLISHED -j ACCEPT
>  -A VPN_10.147.47.9 -j RETURN
>  COMMIT
> 6.Completed on Wed Sep 23 10:46:46 2015
>  root@r-9-VM:~#



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8891) Isolated network VR default iptables rules in INPUT chain are missing

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-8891:
--
Description: 
Repro steps:
1.Create a advance zone setup
2. Create a VM in isolated network
Bug
VM is not assigned its guest ip as dhcp port in router is not open
Also dns, http ports missing.
iptables -L INPUT -nvx
Chain INPUT (policy DROP 1330 packets, 79806 bytes)
pkts bytes target prot opt in out source dest ination
1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0
0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
NEW,ESTABLISHED
0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state NEW,ESTABLISHED
0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state NEW,ESTABLISHED
Summary: Isolated network VR default iptables rules in INPUT chain are 
missing  (was: Isolated network VM not getting its guest ip as dhcp port not 
open in router)

> Isolated network VR default iptables rules in INPUT chain are missing
> -
>
> Key: CLOUDSTACK-8891
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8891
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.6.0
>
>
> Repro steps:
> 1.Create a advance zone setup
> 2. Create a VM in isolated network
> Bug
> VM is not assigned its guest ip as dhcp port in router is not open
> Also dns, http ports missing.
> iptables -L INPUT -nvx
> Chain INPUT (policy DROP 1330 packets, 79806 bytes)
> pkts bytes target prot opt in out source dest ination
> 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8891) Isolated network VM not getting its guest ip as dhcp port not open in router

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8891:
-

 Summary: Isolated network VM not getting its guest ip as dhcp port 
not open in router
 Key: CLOUDSTACK-8891
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8891
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8876:
-

 Summary:  VPC tier network restart, missing ip on VR interface
 Key: CLOUDSTACK-8876
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.5.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


Reproducing steps:
1. Create a vpc and deploy a vm in tier.
2. Acquire a public ip and configure PF rule
3. check that the VR interface has two ip addresses.
4. Restart the tier network with cleanup.
5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8877) Show error msg on VPN user add failure.

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8877:
-

 Summary: Show error msg on VPN user add failure.
 Key: CLOUDSTACK-8877
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8877
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.2
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


On vpn user add failure report error message to the API/UI



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8871) Basic zone security group ingress/egress rules are not working for some cidrs

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-8871:
--
Description: 
1. Create a basic zone with xenserver 6.2.
2. Configure the ingress/egress rules in security group with cidrs /32
3. Rules got applied on UI but the traffic is not working.

Reason:
CIDR mentioned in the rules are failed to add ipset. 
output from the SMLog:
Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: '', 
stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for more 
information.
Sep 16 10:52:39 localhost SM: [25871] '

  was:
1. Create a basic zone.
2. Configure the ingress/egress rules in security group with cidrs /32
3. Rules got applied on UI but the traffic is not working.

Reason:
CIDR mentioned in the rules are failed to add ipset. 
output from the SMLog:
Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: '', 
stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for more 
information.
Sep 16 10:52:39 localhost SM: [25871] '


> Basic zone security group ingress/egress rules are not working for some cidrs
> -
>
> Key: CLOUDSTACK-8871
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8871
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.6.0
>
>
> 1. Create a basic zone with xenserver 6.2.
> 2. Configure the ingress/egress rules in security group with cidrs /32
> 3. Rules got applied on UI but the traffic is not working.
> Reason:
> CIDR mentioned in the rules are failed to add ipset. 
> output from the SMLog:
> Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: 
> '', stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
> Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for 
> more information.
> Sep 16 10:52:39 localhost SM: [25871] '



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8871) Basic zone security group ingress/egress rules are not working for some cidrs

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8871:
-

 Summary: Basic zone security group ingress/egress rules are not 
working for some cidrs
 Key: CLOUDSTACK-8871
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8871
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


1. Create a basic zone.
2. Configure the ingress/egress rules in security group with cidrs /32
3. Rules got applied on UI but the traffic is not working.

Reason:
CIDR mentioned in the rules are failed to add ipset. 
output from the SMLog:
Sep 16 10:52:39 localhost SM: [25871] FAILED in util.pread: (rc 2) stdout: '', 
stderr: 'ipset v4.5: Out of range cidr `10.147.52.30/32' specified
Sep 16 10:52:39 localhost SM: [25871] Try `ipset -H' or 'ipset --help' for more 
information.
Sep 16 10:52:39 localhost SM: [25871] '



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8874) Nslookup is failing from the remote access vpn client

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8874:
-

 Summary: Nslookup is failing from the remote access vpn client
 Key: CLOUDSTACK-8874
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8874
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.3.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


Steps to reproduce:
1. Enable VPN for a guest network.
2. connect to the VPN using any supported VPN client, make sure the DNS is 
provided by the VPN(default).
3. After connecting check the name server in use by 'NSlookup'.
4. Try resolving any hostname, either an instance name or any other.
5. It should fail.
6. Login to the VR.
7. run 'netstat -anp | grep 53' output should only have dnsmasq listening on 
guest interface.
8. modify /etc/dnsmasq.conf' and add 'interface=ppp0' , as per the output of 
ifconfig ppp0 is the name, or pppX.
9. Restart the dnsmasq service and the netstat output now contains the VPN 
tunnel interface IP for port 53.
10. Name resolution works from VPN client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8875) Nslookup is failing from the remote access vpn client

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8875:
-

 Summary: Nslookup is failing from the remote access vpn client
 Key: CLOUDSTACK-8875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8875
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.3.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


Steps to reproduce:
1. Enable VPN for a guest network.
2. connect to the VPN using any supported VPN client, make sure the DNS is 
provided by the VPN(default).
3. After connecting check the name server in use by 'NSlookup'.
4. Try resolving any hostname, either an instance name or any other.
5. It should fail.
6. Login to the VR.
7. run 'netstat -anp | grep 53' output should only have dnsmasq listening on 
guest interface.
8. modify /etc/dnsmasq.conf' and add 'interface=ppp0' , as per the output of 
ifconfig ppp0 is the name, or pppX.
9. Restart the dnsmasq service and the netstat output now contains the VPN 
tunnel interface IP for port 53.
10. Name resolution works from VPN client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-8843) Guest VMs are not getting IPs as the DHCP port is not opened in VR

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy reassigned CLOUDSTACK-8843:
-

Assignee: Jayapal Reddy

> Guest VMs are not getting IPs as the DHCP port is not opened in VR
> --
>
> Key: CLOUDSTACK-8843
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8843
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: manasaveloori
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.6.0
>
>
> 1. Deployed CS with latest build.
> 2. Deployed a guest VM.
> 3. VM is not assigned any ip address.
> Observation:
> In VR 67 port is not opened
> root@r-9-VM:~# iptables-save
> # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015
> *filter
> :INPUT DROP [10:3400]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [117:15233]
> :FW_OUTBOUND - [0:0]
> :NETWORK_STATS - [0:0]
> -A INPUT -j NETWORK_STATS
> -A INPUT -d 224.0.0.18/32 -j ACCEPT
> -A INPUT -d 225.0.0.50/32 -j ACCEPT
> -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -p tcp -m tcp --dport 3922 -m state --state NEW,ESTABLISHED 
> -j ACCEPT
> -A FORWARD -j NETWORK_STATS
> -A OUTPUT -j NETWORK_STATS
> -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A NETWORK_STATS -i eth0 -o eth2
> -A NETWORK_STATS -i eth2 -o eth0
> -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp
> -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp
> COMMIT
> # Completed on Mon Sep 14 09:02:39 2015
> # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015
> *nat
> :PREROUTING ACCEPT [83:8482]
> :INPUT ACCEPT [25:1716]
> :OUTPUT ACCEPT [5:380]
> :POSTROUTING ACCEPT [0:0]
> -A POSTROUTING -o eth2 -j SNAT --to-source 10.147.47.7
> COMMIT
> # Completed on Mon Sep 14 09:02:39 2015
> # Generated by iptables-save v1.4.14 on Mon Sep 14 09:02:39 2015
> *mangle
> :PREROUTING ACCEPT [391:44422]
> :INPUT ACCEPT [367:42880]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [342:47621]
> :POSTROUTING ACCEPT [342:47621]
> :FIREWALL_10.147.47.7 - [0:0]
> :VPN_10.147.47.7 - [0:0]
> -A PREROUTING -d 10.147.47.7/32 -j FIREWALL_10.147.47.7
> -A PREROUTING -d 10.147.47.7/32 -j VPN_10.147.47.7
> -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark 
> --nfmask 0x --ctmask 0x
> -A PREROUTING -i eth2 -m state --state NEW -j CONNMARK --set-xmark 
> 0x2/0x
> -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
> -A FIREWALL_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FIREWALL_10.147.47.7 -j DROP
> -A VPN_10.147.47.7 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A VPN_10.147.47.7 -j RETURN
> COMMIT
> # Completed on Mon Sep 14 09:02:39 2015
> root@r-9-VM:~#



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-8690.
---
Resolution: Fixed

> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8823) Isolated network VR is failed to come up because of wrong interface order

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8823:
-

 Summary: Isolated network VR is failed to come up because of wrong 
interface order
 Key: CLOUDSTACK-8823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Priority: Blocker
 Fix For: 4.6.0


In the isolated network VR is failed to come up because it is failed to ssh to 
VR.
Earlier the order of interfaces in the VR is as follows, which is fixed.
eth0 - guest interface
eth1 - link local
eth2 - public .
Now the order is changed due to which the sushi_configured to listen on eth1 
which is public interface now on the VR.

ip addr output:
root@r-4-VM:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:e1 brd ff:ff:ff:ff:ff:ff
inet 169.254.1.225/16 brd 169.254.255.255 scope global eth0
inet 169.254.2.106/16 brd 169.254.255.255 scope global secondary eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:1b:6c:00:00:08 brd ff:ff:ff:ff:ff:ff
inet 10.147.30.243/24 brd 10.147.30.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:68:8a:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth2
root@r-4-VM:~#

Recent interface order commit caused the regression.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-8710.
---
Resolution: Fixed

 site2site vpn iptables rules are not configured on VR
 -

 Key: CLOUDSTACK-8710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Priority: Critical

 1. Configure vpc 
 2. Configure site2site vpn 
 3. After configuration go to VR and check the iptables rules of VR.
 Observed that there no rules configured on ports 500, 4500.
 In configure.py there is method 'configure_iptables' which is having rules 
 but these are not getting applied on VR on site2site vpn configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR

[Jayapal Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694813#comment-14694813
 ] 

Jayapal Reddy commented on CLOUDSTACK-8710:
---

[~remibergsma]

I can see the iptables rules in the in configure.py:configure_iptables(). But 
these are not getting applied on VR on s2s configuration.
Can you please update here once you find the exact point where this execute of 
rules is missed.



 site2site vpn iptables rules are not configured on VR
 -

 Key: CLOUDSTACK-8710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Remi Bergsma
Priority: Critical

 1. Configure vpc 
 2. Configure site2site vpn 
 3. After configuration go to VR and check the iptables rules of VR.
 Observed that there no rules configured on ports 500, 4500.
 In configure.py there is method 'configure_iptables' which is having rules 
 but these are not getting applied on VR on site2site vpn configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR

[Jayapal Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694900#comment-14694900
 ] 

Jayapal Reddy commented on CLOUDSTACK-8710:
---

[~remibergsma]
If you did not start working on this bug assign it to me.
I found the issue and added patch for it.


 site2site vpn iptables rules are not configured on VR
 -

 Key: CLOUDSTACK-8710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Remi Bergsma
Priority: Critical

 1. Configure vpc 
 2. Configure site2site vpn 
 3. After configuration go to VR and check the iptables rules of VR.
 Observed that there no rules configured on ports 500, 4500.
 In configure.py there is method 'configure_iptables' which is having rules 
 but these are not getting applied on VR on site2site vpn configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[Jayapal Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-8690:
--
Priority: Blocker  (was: Critical)

 VR remote access vpn config is not applied
 --

 Key: CLOUDSTACK-8690
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Priority: Blocker
 Fix For: 4.6.0


 Enabling remote access vpn on the network source nat ip address is not 
 configuring the VR ipsec for remote access vpn. But the command is returning 
 success.
 The below are the logs shown in the VR /var/log/cloud.log
 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
 remoteaccessvpn
 2015-07-30 02:00:20,788 Loading data bag type ips
 2015-07-30 02:00:20,789 Loading data bag type cmdline



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8682) Replace openswan ipsec with strongswan ipsec

[Jayapal Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14692925#comment-14692925
 ] 

Jayapal Reddy commented on CLOUDSTACK-8682:
---

FS: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Replacing+openswan+ipsec+with+strongswan+ipsec

 Replace openswan ipsec with strongswan ipsec
 

 Key: CLOUDSTACK-8682
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8682
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


 Currently VR is using openswan ipsec solution. Openswan is currently not 
 maintained by community.  Where as stronswan is maintained by Debian 
 community. So updates are easy with the strongswan.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8707) Site2Site vpn config esp policy set with esp lifetime

[Jayapal Reddy (JIRA)]

Jayapal Reddy created CLOUDSTACK-8707:
-

 Summary: Site2Site vpn config esp policy set with esp lifetime
 Key: CLOUDSTACK-8707
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8707
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


In ipsec site to site vpn configuration esp policy on VR is mis configured.
The configuration file location  is /etc/ipsec.d/*.conf





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)