Hub-and-spoke topology is by far the most complex topology I’ve ever encountered in the MPLS/VPN (and now EVPN) world. It’s used when you want to push all the traffic between sites attached to a VPN (spokes) through a central site (hub), for example, when using a central firewall.

You get the following diagram when you model the traffic flow requirements with VRFs. The forward traffic uses light yellow arrows, and the return traffic uses dark orange ones.

Notes:

• In a generic scenario, you need an ingress and an egress firewall interface for routing purposes. Please note that these are not inside and outside interfaces, as all traffic enters through the ingress interface and leaves through the egress interface.
• From the firewall perspective, you could use a one-arm design where all the traffic enters and exists the firewall through the same interface. Getting that to work on the adjacent routers (a router is hiding behind every VRF box) requires interesting tricks like Policy-Based Routing. I might cover them in another blog post.
• Trying to get stateful firewall traffic inspection to work in scenarios where all traffic (including the return traffic) enters through one interface and exists through another interface is an interesting exercise in futility.
• Each spoke site has to be connected to a different VRF. Two sites connected to the same VRF could communicate directly.

TL&DR: Just because you could does not mean that you should. You’ve been warned.

Still here? Let’s move to the next bit of the puzzle: routing. The traffic in a network always flows in the opposite direction of the route propagation¹, which means that the route propagation in our design should go:

• From the spoke VRFs to egress VRF
• Through the firewall into the ingress VRF²
• Finally, from the ingress VRF into the spoke VRFs.

The dark orange arrows in the following diagram are routing protocol updates; the light yellow ones are route leaks between VRFs³.

The final piece of the puzzle: the routing protocols. We’re assuming that the route leaking between VRFs uses some unspecified mechanism (usually involving BGP) and that the leaked routes get redistributed into the PE-CE routing protocol.

• RIP would work just fine.
• OSPFv2/OSPFv3 would have no problem as long as the OSPF instances running in the Hub Ingress and the Hub Egress VRFs use different OSPF router IDs⁴.
• BGP would work, but as the AS number of the router behind the Hub Ingress VRF is probably the same as the AS number of the router behind the Hub Egress VRF, you’d have to bypass the BGP AS-path loop prevention logic. You could, for example, use AS override on the firewall.

Next: Hub-and-Spoke VPN on a Single PE-Router Continue