tuna created CLOUDSTACK-5516:
--------------------------------
Summary: 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.1.4#6159)