[
https://issues.apache.org/jira/browse/CLOUDSTACK-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland closed CLOUDSTACK-5516.
-------------------------------------
Resolution: Won't Fix
> Handling of broadcast traffic in GRE-based SDN
> ----------------------------------------------
>
> Key: CLOUDSTACK-5516
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5516
> 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
(v6.3.15#6346)
