Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <5458C62B.1090200@empolis.com>
Date: Tue, 4 Nov 2014 13:27:23 +0100
From: Martin Emrich <martin.emrich@empolis.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: <users@cloudstack.apache.org>
Subject: Re: GRE isolated network: wrong interface?
References: 
 <B272E777C2EA8846ABEDBA1B0F4C2E3B1A758A78@EX10MBOX1B.hosting.inetserver.de>
 <54589D2F.3090807@empolis.com> <5458A12C.8040203@niif.hu>
 <5458A4C0.9000303@empolis.com> <5458BCB3.7080205@niif.hu>
In-Reply-To: <5458BCB3.7080205@niif.hu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi!

Am 04.11.2014 12:46, schrieb Erdősi Péter:

> Hmm.. you mean isolated guest network right?
> If yes, the IP subnet can be changed, if the user define guest network
> (not auto, when first vm started)
> There is an option to: Guest Gateway, and Guest Netmask, and if it
> filled, the sysvm will use that subnet...

No, I do not mean the guest network (which works fine). I mean the 
network between the XenServers, where the guest traffic is carried.

My XenServers have the following interfaces:

- MANAGEMENT
- GUEST (which should be used for GRE-encapsulated private traffic)
- PUBLIC
- ISCSI1
- ISCSI2

All except PUBLIC have IP addresses: MANAGEMENT obviously for XenCenter 
and XAPI, ISCSI1/2 for the multipathed shared storage, and GUEST 
(intended for GRE traffic, although it is nowhere mentioned that the 
interface must have IP addresses).

The intended behaviour is that Cloudstack instructs the OpenVSwitches 
within the XenServer nodes to build the GRE tunnels between VMs within 
the same Cloudstack isolated Network across the GUEST interface.

But CloudStack chooses one of the other interfaces (MANAGEMENT or ISCSI) 
to carry the GRE traffic.

You can see this with "ovs-vsctl show" on one of the XenServers with 
currently running instances:

# ovs-vsctl show
...
     Bridge "xapi4"
         fail_mode: standalone
         Port "vif1.0"
             Interface "vif1.0"
         Port "t1074-8-9"
             Interface "t1074-8-9"
                 type: gre
                 options: {key="1074", remote_ip="10.33.1.5"}
         Port "xapi4"
             Interface "xapi4"
                 type: internal
...
Here you see the remote IP of the other XenServer for the GRE tunnel. 
But the IP is wrong, it is on the first ISCSI network.
This works, but of course we want to isolate storage traffic from guest 
traffic, so Cloudstack should do as expected and use the "GUEST" 
interface ip of the peer XenServer as remote_ip.

Ciao

Martin