Central Services Topology

> Question:  Have also seen comments in foreeum like. The best practice for this Hub and Spoke is to use TWO VRF in Hub site – “From-Spoke” and “To-Spoke”

 

This is immaterial implementation detail. Some shops do this, because their automation system abstracts VRF into set of import/export statements and clients share set and hubs share different set. Also if you have hub and spoke in the same PE, you’re going to need another name, if not, single name is fine, but may be more difficult to automate as name does not imply config.

 

ipv4 vrf hubs

  route-target export 42:hubs

  route-target import 42:spokes

ipv4 vrf spokes

  route-target export 42:spokes

  route-target import 42:hubs

 

Now the problem with this approach is that if you have >1 spokes in the same PE, they are able to communicate to each other. To workaround this, you’ll need ‘half duplex VRF’, where ingress and egress RIB/FIB are different.

Packets coming from spokes look at FibA, packets going to spokes look at FibB. FibA has only route to hubs, FibA has only routes to spokes.

 

ip vrf spokesIn

  route-target import 42:hubs

ip vrf spokesOut

  route-target export 42:spokes

ip vrf hubs

   route-target export 42:hubs

   route-target import 42:spokes

 

PE1:

int Spoke1

  ip vrf forwarding spokesIn downstream spokesOut int Spoke2

  ip vrf forwarding spokesIn downstream spokesOut int Hub1

  ip vrf hubs

int Hub2

  ip vrf hubs