cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daan Hoogland (JIRA)" <>
Subject [jira] [Closed] (CLOUDSTACK-5516) Handling of broadcast traffic in GRE-based SDN
Date Wed, 08 Feb 2017 09:23:58 GMT


Daan Hoogland closed CLOUDSTACK-5516.
    Resolution: Won't Fix

> Handling of broadcast traffic in GRE-based SDN
> ----------------------------------------------
>                 Key: CLOUDSTACK-5516
>                 URL:
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: tuna
>             Fix For: Future
>     The overlay network creates a virtual layer-2 broadcast domain spanning over the
hosts where a VM for a given network is deployed. This could result in a fairly large virtual
layer-2 broadcast domain.
>     In order to improve the performance of the network it would be vital to ensure the
impact of broadcasts on network throughout is minimized.
>     To this aim, Cloudstack knowledge about the topology of the cloud can be used for
reducing the amount of broadcast traffic in the following way:
>       - DHCP traffic - DHCP requests could be redirected to a local tap port which is
connected to a dnsmasq process populated and updated by Cloudstack. DHCP traffic could then
be squelched over the tunnels. Another benefit is that the initial IP configuration for the
NICs might happen independently of the state of the tunnel mesh.
>       - ARP traffic - A similar approach can be adopted for ARP broadcast, which can
be redirected to a tap port connected to a process which reads ARP requests and sends ARP
replies reading info from a cache maintained by Cloudstack itself
>     While this clearly reduces the amount of broadcast traffic on the network, it increases
the management burden for Cloudstack. It is vital that entries are added and invalidated into
this cache in an appropriate way. While invalidation should always occur in cases such as
VM stop, VM pause, and VM migration, there are several strategies for populating this cache,
for instance:
>     1. Cloudstack could add entries to the cache as soon as the deployment plan for a
VM is known
>     2. The cache upon a miss, might send an update request to the Cloudstack management
server, which will provide the requested information (e.g.: MAC corresponding to a given IP).

This message was sent by Atlassian JIRA

View raw message