Multiple nics for public traffic will be seen on VR if we use public IP addresses from multiple CIDRs(multiple subnets in different vlans) e.g: consume all public IP addresses from one cidr then add another cidr of public ip addresses(in diff vlan) and use them for any of the SNAT/PF/LB services. In that case one more nic will be plugged in on VR for public traffic.
-Sanjeev -----Original Message----- From: Eric Neumann - AOD [mailto:eric.neum...@aod-cloud.com] Sent: Thursday, July 17, 2014 6:53 AM To: 'users@cloudstack.apache.org' Subject: RE: CS VR on VMware And after even further testing, it seems these issues (no source nat entries, additional nics being created in another public port group) do not occur with a VPC VR, only with a isolated network VR. Has anyone encountered anything similar to this? From: Eric Neumann - AOD Sent: Thursday, 17 July 2014 12:38 AM To: 'users@cloudstack.apache.org' Subject: RE: CS VR on VMware Hi Jayapal, Thanks very much for the reply. This is a custom network offering with a default egress policy of deny. Slight correction from earlier, it appears the default iptable entries are identical between Xen VR & VMware VR of the same network offering. Also I’ve tested and confirmed that additional egress policies do successfully get applied to the iptables in both scenarios. What I found though was that the source nat entry on the VMware VR was missing, so it seems that isn’t being created for some reason. I’ve also noticed that the VMware VR had 5 NICs, rather than the 3 NICs I was expecting – 1xmgmt_network, 1xcloud.guest.916.10000.VDSNAME, 1xcloud.public.3004.10000.VDSNAME and then an additional 2x in cloud.public.3004.0.VDSNAME which doesn’t seem right. network_offerings table’s entry of the offering in question - http://pastebin.com/h4V8aKW9 (just to recap though, the problem seems to present on VMware only, not Xen even though they share the same network offering…) the management server log output when creating a new network/VR is here - http://pastebin.com/UmMDYrt2 The juicy bit seems to be this part (thought I’m not entirely sure what it means… ☺ ): 2014-07-16 14:08:45,297 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-322:ctx-4b3460ba <<ESXHOST_IP>>) Failed to find DomR VIF to associate/disassociate IP with. 2014-07-16 14:08:45,297 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-322:ctx-4b3460ba <<ESXHOST_IP>>) Unexpected exception: com.cloud.exception.InternalErrorException: Failed to find DomR VIF to associate/disassociate IP with. will shortcut rest of IPAssoc commands com.cloud.exception.InternalErrorException: Failed to find DomR VIF to associate/disassociate IP with. at com.cloud.hypervisor.vmware.resource.VmwareResource.assignPublicIpAddress(VmwareResource.java:1910) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2092) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeNetworkElementCommand(VmwareResource.java:431) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:502) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) 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:47) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) Thanks again, Eric [cid:image001.png@01CFA1A0.BEBA8D90] Eric Neumann Cloud Services Manager 5/19 Wotan Street, Innaloo WA 6018 www.aod-cloud.com<http://www.aod-cloud.com> <http://www.addaxsolutions.com/> -----Original Message----- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Wednesday, 16 July 2014 6:36 PM To: <users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>> Subject: Re: CS VR on VMware Hi Eric, Did you created network with default network offering or customer network offering ? What is egress default policy value (true) in the network offering ? Can you please send iptables rules on VR, MS server log after VR start and network_offerings, network table output in pastebin.com Thanks, Jayapal On 16-Jul-2014, at 3:48 PM, Eric Neumann - AOD <eric.neum...@aod-cloud.com<mailto:eric.neum...@aod-cloud.com<mailto:eric.neum...@aod-cloud.com%3cmailto:eric.neum...@aod-cloud.com>>> wrote: > Hi All, > > I’ve encountered a strange issue whereby egress firewall rules don’t seem to > apply to any CS VRs that are running on our VMware cluster, whereas any CS > VRs running on our XenServer cluster work as expected (these are in the same > and only zone). Even more strangely, port forwarding and ingress firewall > rules do apply correctly in either scenario. > > Has anyone encountered anything similar or has any troubleshooting tips for > this? I have confirmed WAN connectivity, etc. from the VRs console and can > see that there’s no matching entry in the iptables. > > We are running Citrix CloudPlatform 4.3.0.1. > > Any pointers would be greatly appreciated! > Thanks, > Eric >
