cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjeev Neelarapu <>
Subject RE: GRE isolated network: wrong interface?
Date Wed, 05 Nov 2014 04:20:48 GMT

Are you using the proper traffic labels for all the traffic types in the physical network?
Since you have multiple PIFs on XenServer you must specify traffic labels on zone's physical
network for different traffics(guest,management,public and storage) to go through the intended
PIFs on XenServer.

Please refer to CS admin guides on setting traffic labels.


-----Original Message-----
From: Martin Emrich [] 
Sent: Tuesday, November 04, 2014 5:57 PM
Subject: Re: GRE isolated network: wrong interface?


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:

- GUEST (which should be used for GRE-encapsulated private traffic)

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

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=""}
         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.


View raw message