cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Mikhailovsky <and...@arhont.com.INVALID>
Subject Re: VR routing issues in Advanced Mode
Date Wed, 21 Feb 2018 14:53:11 GMT
Andrija, 

the vms are trying to reach each other using the public IP addresses, not the private addresses.

Cheers

Andrei
----- Original Message -----
> From: "Andrija Panic" <andrija.panic@gmail.com>
> To: "users" <users@cloudstack.apache.org>
> Sent: Wednesday, 21 February, 2018 12:48:57
> Subject: Re: VR routing issues in Advanced Mode

> Hi Andrei,
> 
> you dont have typo in your input, right ?
> 
> if I read this correctly, the case that don't work for you is as following:
> 
> VR1 ( XXX.XXX.XXX.10/26) --> Guest1 Network / VM  10.1.1.100/24
> 
> VR2 ( XXX.XXX.XXX.20/26)-- Guest1 Network / VM  10.1.1.200/24
> 
> Is this correct ?
> 
> If so, it's normal that VM1 can reach VM2 via following path VM1-->VR1 --->
> VR2 --> VM2:80 because both VM1 and VM2 are on the "same" subnet (
> 10.1.1.0/24) so the VM1 decides to BROADCAST traffic over "switch" to reach
> IP in the same network (VM2 IP 10.1.1.0). If this IP would be in the i.e.
> 10.2.1.0 netowrk, then VM would decided to send packet to it's default gtw
> (VR) and than things would work fine.
> 
> Otherwise, if this is single VR, you actually can not even create 2
> networks with same subnet since both are (per your input, if not typo)
> 10.1.1.0/24 subnets
> 
> ?
> 
> Cheers
> Andrija
> 
> On 21 February 2018 at 13:27, Andrei Mikhailovsky <andrei@arhont.com.invalid
>> wrote:
> 
>> Hello
>>
>> Could someone help me to identify the routing issues that we have. The
>> problem is the traffic from different guest networks can not reach each
>> other via the public IPs.
>>
>> Here is my ACS setup:
>> ACS 4.9.3.0 (both management and agents)
>> KVM Hypervisor based on Ubuntu 16.04
>> Ceph as primary storage. NFS as secondary storage
>> Advanced Networking with vlan separation
>> 2 x Public IP ranges with /26 netmask.
>>
>>
>>
>> Here is an example when routing DOES NOT work:
>>
>> Case 1 - Advanced Networking, vlan separation, VRs route all traffic and
>> provide all networking services (dhcp, fw, port forwarding, load balancing,
>> etc)
>>
>> Guest Network 1:
>>
>> Public IP: XXX.XXX.XXX.10/26
>> Private IP range: 10.1.1.0/24
>> guest vm1 IP: 10.1.1.100/24
>>
>> Guest Network 2:
>> Public IP: XXX.XXX.XXX.20/26
>> Private IP range: 10.1.1.0/24
>> guest vm2 IP: 10.1.1.200/24
>>
>>
>> I've created ACLs on both guest networks to allow traffic from 0.0.0.0/0
>> on port 80. I've created the port forwarding rules to forward port 80 from
>> public XXX.XXX.XXX.10 and XXX.XXX.XXX.XXX.20 onto 10.1.1.100 and 10.1.1.200
>> respectively.
>>
>> This setup works perfectly well when I am initiating the connections from
>> outside of our CloudStack. However, vm2 can't reach vm1 on port 80 using
>> the public IP XXX.XXX.XXX.10 and vice versa, vm1 can't reach vm2 on public
>> IP XXX.XXX.XXX.20.
>>
>>
>>
>>
>> Here is an example when the routing DOES work:
>>
>> Case 2 - Advanced Networking, vlan separation, VRs are not used. Public
>> IPs are given directly to a guest vm
>>
>> Guest Network 1:
>>
>> guest vm1 Public IP: XXX.XXX.XXX.100/26
>>
>> Guest Network 2:
>>
>> guest vm2 Public IP: XXX.XXX.XXX.110/26
>>
>> In the Case 2, the guest vm has a public IP address directly assigned to
>> its network interface. VRs are not used for this networking. Each guest has
>> a fw rule to allow incoming traffic on port 80 from 0.0.0.0/0. Both vm1
>> and vm2 can access each other on port 80. Also, vms from Case 1 above can
>> access port 80 on vms from Case 2, similarly, vms from Case 2 can access
>> port 80 on vms from Case 1.
>>
>>
>>
>> So, it seems that the rules on the VR in Case 1 do not allow traffic that
>> originates from other VRs within the same public network range. The trace
>> route shows the last hop being the VR's private IP address. How do I change
>> that behaviour and fix the networking issue?
>>
>> Thanks
>>
>> Andrei
>>
> 
> 
> 
> --
> 
> Andrija Panić

Mime
View raw message