Shashank's vpn log

Controlling VPN topology

   The topology for a VPN consists of a set of nodes interconnected via
   tunnels. The topology may be a full mesh, a hub and spoke topology,
   or an arbitrary topology. For a VPN the set of nodes will include
   all VPN edge devices that have attached sites for that VPN.
   Naturally, whatever the topology, all VPN sites are reachable from
   each other; the topology simply constrains the way traffic is routed
   among the sites. For example, in one topology traffic between site A
   and site B goes from one to the other directly over the VPN backbone;
   in another topology, traffic from site A to site B must traverse site
   C before reaching site B.

   The simplest topology is a full mesh, where a tunnel exists between
   every pair of VPN edge devices. If we assume the use of point-to-
   point tunnels (rather than multipoint-to-point), then with a full
   mesh topology there are N*(N-1)/2 duplex tunnels or N*(N-1) simplex
   tunnels for N VPN edge devices. Each tunnel consumes some resources
   at a VPN edge device, and depending on the type of tunnel, may or may
   not consume resources in intermediate routers or LSRs. One reason
   for using a partial mesh topology is to reduce the number of tunnels
   a VPN edge device, and/or the network, needs to support. Another
   reason is to support the scenario where an administrator requires all
   traffic from certain sites to traverse some particular site for
   policy or control reasons, such as to force traffic through a
   firewall, or for monitoring or accounting purposes. Note that the
   topologies used for each VPN are separate, and thus the same VPN edge
   device may be part of a full mesh topology for one VPN, and of a
   partial mesh topology for another VPN.

   An example of where a partial mesh topology could be suitable is for
   a VPN that supports a large number of telecommuters and a small
   number of corporate sites. Most traffic will be between
   telecommuters and the corporate sites, not between pairs of
   telecommuters. A hub and spoke topology for the VPN would thus map
   onto the underlying traffic flow, with the telecommuters attached to
   spoke VPN edge devices and the corporate sites attached to hub VPN
   edge devices. Traffic between telecommuters is still supported, but
   this traffic traverses a hub VPN edge device.

   The selection of a topology for a VPN is an administrative choice,
   but it is useful to examine protocol mechanisms that can be used to
   automate the construction of the desired topology, and thus reduce
   the amount of configuration needed. To this end it is useful for a
   VPN edge device to be able to advertise per-VPN topology information
   to other VPN edge devices. It may be simplest to advertise this at
   the same time as the membership information is advertised, using the
   same mechanisms.

   A simple scheme is where a VPN edge device advertises itself either
   as a hub or as a spoke, for each VPN that it has. When received by
   other VPN edge devices this information can be used when determining
   whether to establish a tunnel. A more comprehensive scheme allows a
   VPN edge device to advertise a set of topology groups, with tunnels
   established between a pair of VPN edge devices if they have a group
   in common.

[vpn] Controlling a VPN topology.