Wednesday, 25 April 2012

MPLS spoke to spoke connectivity

So here’s a question for you.  In an MPLS hub and spoke design, can the spoke sites route to each other without adding any additional route-target (RT) values?  In a word yes, so let us see how.

So anyone familiar with MPLS will know that by using route-target values we can create any connectivity that we want.  However in order to make our topology manageable, most organisations limit the design teams to the following methods

  • Hub and spoke
  • Full mesh
  • Point-to-point (P2P) - this is just a full mesh VPN with two members
Just using these methods we can create most other topologies (ie partial mesh) by making VRFs members of multiple VPNs.  However this should be limited or well planned/documented, otherwise we end up with what I call a full-mess topology.

Hub and Spoke
One of the nice features in hub and spoke topologies is that spoke sites do not learn each other’s routes.  This is often used as a security mechanism within ASPs by putting all our customers in spoke VPNs and our upstream services at the hub.

If we want to create connectivity between two spoke sites then this can be done easily by adding a new common RT value on the two spoke VRFs.  This effectively creates a new P2P VPN between the two spoke VRFs.

However it is also possible to create connectivity between spoke sites by creating an aggregate route on the hub.  If we inject an aggregate route that covers all our spoke sites (or a sub set), then these spoke sites will be able to talk to each other by routing via the hub.  The hub will pop the VPN label (plus any TE/LDP label) and push a new label stack on.  So the hub router effectively routes the traffic between two LSPs.

If we are using hub and spoke topologies as a security mechanism to protect customers from each other, then we must also be aware that aggregate routes can break this model.

However this can also be used as a design tool and is sometimes used in Extranet designs.  

No comments:

Post a Comment