[j-nsp] Hub and Spoke VPN

[Pedro Roque Marques]

aszymajd at wp.pl (Adam Szymajda) writes:

> Let's say we have the following scenario:
>      _______         _______
> S----|     |         |     |
> S----|     |         |     |
> S----|     |         |     |-------Hub
> S----| PE1 |---------| PE2 |
> S----|     |         |     |
> S----|_____|         |_____|
> 
> S - spoke sites connected via different [sub]interfaces to the 
> same vrf.
> 
> The main goal is to force the spokes to communicate only via hub.

Yes, i believe that is what everybody understands by "hub & spoke".

> Putting all spoke subinterfaces into single vrf is the simplest 
> solution to maintain and most preffered, however you have to set 
> static routes in this vrf to reach a particular spoke site. This 
> will cause that it is possible to reach spoke site 1 from spoke 
> site 2 omitting the hub site. (traffic will be routed within PE1 
> even if hub will export default route pointing it)

You can do this w/ 2 VRFs on PE1. One VRF that is used for routing
information and for the forwarding information that is used downstream
(traffic received from other PEs) and one VRF that is used to switch
traffic from the PEs.

This would work like this:

All 'spoke' interfaces belong to 'spoke_main' VRF but have FBF nexthop
into 'spoke_upstream' VRF.

routing-intances {
    spoke_main {		/* this is the routing-instance
				   advertised via 2547 */
	interface <s1>;
	interface <s2>;
	...
	interface <sn>;
	vrf-import <reject-all>;
	vrf-export <RT-spoke>;
	/* whatever routing protocol you use to the spokes */
    }

    spoke_upstream {		/* used for local forwarding */
	vrf-import <RT-hub>;
	vrf-export <reject-all>;
    }
}



> There can be more PE's with spokes connected to it. Is there any 
> way to achieve it without complicating things, like separate VRF 
> for each site?
> 

I think 2 VRFs per PE is better than one VRF per spoke.

An alternative approach w/ a single VRF would be to configure
'forwarding-table export' policy to reject all routes from the spokes
from being installed in the VRF forwarding table. Thus the forwarding
lookup would only find the hub route.

Somehow my impression is that filtering of routing-updates to the
forwarding table is less intuitive and more tricky
operationally. i.e. you always have to remember that the contents of
the forwarding table itself may be filtered...

  Pedro.