@@ -329,6 +329,29 @@ challenges. Consider the example in :numref:`Figure %s
329329<fig-dc-firewall>`, in which a single firewall has been deployed to
330330filter traffic flows among a set of virtual machines in a datacenter.
331331
332+ Suppose that traffic sent from VM A to VM C needs to be processed at
333+ the firewall. To ensure it is filtered, traffic needs to be routed
334+ over a path that traverses the firewall, not necessarily the shortest
335+ path from A to C. In the more extreme case of traffic from VM A to VM
336+ B, the two VMs sit on the same host, so the traffic from A to B needs to be
337+ sent out of the host, across the network to the firewall, and then
338+ back to B. This is clearly not efficient, and consumes resources both
339+ within the network and at the network interface for the hairpinned
340+ traffic. Furthermore, the firewall itself has the potential to become
341+ a bottleneck, as all traffic requiring filtering must pass through to that
342+ centralized device.
343+
344+ Finally, there is considerable management overhead in supporting such
345+ an internal firewall. Assume that we start with some sensible
346+ default policies that deny all traffic flows aside from those
347+ explicitly allowed. Each new application that is deployed will require
348+ some new firewall rule to be created to allow traffic to flow between
349+ the component machines for that application. If a VM is moved, we may
350+ need to update the routing and the firewall rules to ensure that
351+ traffic continues to be filtered correctly. All of these concerns have
352+ led to internal firewalls being used rather sparingly.
353+
354+
332355
333356
334357.. _fig-dc-firewall :
@@ -338,7 +361,24 @@ filter traffic flows among a set of virtual machines in a datacenter.
338361
339362 A single firewall in a virtualized datacenter.
340363
341-
364+ The solution to the many issues with internal firewalls appeared as
365+ one of the features of network virtualization, the distributed
366+ firewall. :numref: `Figure %s <fig-dist-firewall >` illustrates a
367+ distributed firewall implementation. In this case, traffic sent from
368+ VM A to VM C can be processed by a firewall function at either (or
369+ both) of the virtual switches that it traverses, and still be sent
370+ over the shortest path through the network underlay between the two
371+ hosts, without hairpinning to a centralized firewall. Furthermore,
372+ traffic from VM A to VM B need never even leave the host on which
373+ those two VMs reside, passing only through the virtual switch on that
374+ host to receive the necessary firewall treatment.
375+
376+ A significant side effect of distributing a service in this way is
377+ that there is no longer a central bottleneck. Every time another
378+ server is added to host some more VMs, there is a new virtual switch
379+ with capacity to do some amount of distributed processing. This means
380+ it is relatively simple to scale out the amount of firewalling in this
381+ way.
342382
343383.. _fig-dist-firewall :
344384.. figure :: figures/Slide48.png
@@ -348,6 +388,14 @@ filter traffic flows among a set of virtual machines in a datacenter.
348388 A distributed firewall is implemented as part of the virtual
349389 switch in every host in a datacenter.
350390
391+ For further details on network virtualization and distributed services
392+ we recommend our companion book on software-defined networks.
393+
394+ .. admonition :: Further Reading
395+
396+ L. Peterson, C. Cascone, B. O’Connor, T. Vachuska,
397+ and B. Davie. `Software-Defined Networks: A Systems
398+ Approach. <https://sdn.systemsapproach.org> `__.
351399
3524006.5 Other Security Appliances
353401------------------------------
0 commit comments