Hub & Spoke Topology with separate VRFs at hub site

[mmelbourne]

Why is it necessary in an MPLS Hub & Spoke design for there to be two VRFs at the hub site (essentially one for inbound traffic from the spokes and one for traffic destined for the spokes from the hub)?

Could just one central VRF be used and appropriate RTs manipulated to import routes into the hub from the spokes and only export a default route from the hub?

[romccallum]

What you firstly speak about is quite rightly called hub & spoke VPNS - this is where the spokes can actually talk to each other but via the hub. You then go on to speak about Extranet vpns where the spokes can never speak to each other and all traffic is through the hub site.

[mmelbourne]

I don't think I mean Extranet VPNs. A Layer 3 VPN where the spokes can communicate, but only through a hub site. I've seen a configuration which uses separate VRFs on the spokes (to avoid spoke-spoke communication on spoke sites which are homed on the same PE), but also use separate VRFs for inbound and outbound traffic at the hub. I wondered whether this can be combined onto one VRF.

However, perhaps an alternative solution would be to utilise half-duplex VRFs, which appear to make hub and spoke topologies more scalable. However the examples on CCO use virtual-templates for dial-in scenarios; are virtual-templates a requirement?

[romccallum]

hi mate no virtual templates arent required - also half duplex vpns that makes me laugh - its a bit like Cisco saying scavenger class of service as well - who makes up these names?? Remember when utilising hub & spoke you need to use allowas-in on the PE (that is if all your CE's are in the same AS number)

[sachins_shinde]

HI...

I think in hub n spoke scenario, for spoke to spoke communication spoke traffic should come to HUB CE and then pass to destined spoke. in this HUB have controll on this traffic. In single vrf case spoke traffic will come to hub PE and from there it will go to destined spoke intead of passing through hub CE. Thats why we need two VRFs for hub n spoke scenario.

PLS. correct me if i m wrong

thks

[mheusinger]

Hello,

in Hub and Spoke - as in any other L3VPN - traffic will flow in the opposite direction of IP routing updates. In a Hub and Spoke setup the spoke sites should get routing updates from the hub site. Thus one faces a split horizon problem: updates learned at the hub CE from a neighbor (PE) will not be sent back over the same interface to that neighbor. Hence the simple solution is: one VRF and interface to announce spoke routes from the PE to the hub CE and another interface terminating in a second VRF to announce the routes from the hub CE back into the MPLS VPN environment.

Just as a side note: this results in an unusual load pattern on the two hub CE interfaces. Both interfaces will have nearly only load in one direction.

Hope this helps! Please rate all posts.

Regards, Martin

[sachins_shinde]

Hi Martin,

What if hub is importing routes from spoke and exporting default to spoke ? I dont think there will be any prob relate to split horizon.

[mheusinger]

Hello,

The default route (or a summary route) should work, if you enable MPLS label switching for the default route.

Router(config)#mpls ip default-route

Additionally you need to configure a central service VPN, i.e. different RT for export and import. Otherwise you get direct spoke to spoke communication.

And a last note: the first IP device after the PE must allow IP packets sent out of the interface they are received on. A PIX f.e. will not allow such forwarding for security reasons. The question also remains WHY you want hub and spoke (security? ip accounting? ...) and whether you can achieve your goal on a single router "redirecting" traffic on the incoming interface back out to the PE.

Hope this helps! Please rate all posts.

Regards, Martin