Multi-Region Fabric Basics

A small overlay can be a full mesh of IPsec tunnels. A global overlay cannot. If every branch builds a tunnel to every other branch, the tunnel count and the OMP table grow faster than the branch routers can handle. Multi-Region Fabric, or MRF, is Cisco's way to split one fabric into access regions plus a core, so most tunnels stay inside a region.

This post is the basics: regions, edge versus border roles, and what the lab shows when MRF is off. The platform is Cisco Catalyst SD-WAN 20.18.2.1 with C8000v routers on IOS XE 17.18.02, built in my home lab. I did not create a second region or promote either edge to a border router. One Controller and two sites already share a flat overlay, and this host does not have the RAM for another pair of controllers plus border routers.

This is part of the Cisco SD-WAN series. Previous: Transport-side static routes and BGP to an MPLS PE. Next: SD-WAN segmentation end to end.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

The problem: one mesh does not scale

Take three continents, a few hundred branches, and a full mesh. Every edge would keep BFD and IPsec state for every other edge it is allowed to reach. Policy can trim that mesh, but you still manage one flat network: one tunnel scale problem, one transport choice, one topology.

MRF (Cisco also called it Hierarchical SD-WAN) divides the overlay the way OSPF areas divide a large IGP.

• Access regions (region IDs 1 to 63) hold ordinary WAN edges. Edges build tunnels to other edges in the same region, and to the border routers assigned to that region. They do not build tunnels to edges in a different access region.
• The core region (region 0) holds border routers. A border router belongs to one access region and to the core. Inter-region traffic takes three tunnels: edge to local border, border to the far region's border, and that border to the far edge.
• Intra-region traffic still takes one direct tunnel.

You can pick a different topology per access region (full mesh in one, hub and spoke in another) and a different transport for the core. Cisco recommends a full mesh among border routers in the core so inter-region routing stays simple.

The default role of any WAN edge is edge router. A border router is an explicit role you assign.

What this lab shows with MRF left off

There is one Controller at 1.1.1.2 and two edges at site 100 and site 200. They are a two-site mesh, not a hierarchy.

edge1#show sdwan control local-properties
device-role                       edge-router
region-id-set                     N/A
mrf-management-region             no

show sdwan running-config system has a system-ip, a site-id, an organization name, and a Validator. It has no region and no role border-router.

OMP still has a column for it. show sdwan omp routes vpn 10 prints REGION ID and REGION PATH as None and - on every path. The legend includes BR-R -> Border-Router reoriginated, which is how a border router marks prefixes it has taken from one region into another. Nothing in this table is BR-R.

TENANT  VPN  PREFIX           FROM PEER  STATUS   TLOC IP   COLOR         REGION ID
0       10   192.168.10.0/24  0.0.0.0    C,Red,R  10.0.0.1  mpls          None
0       10   192.168.10.0/24  0.0.0.0    C,Red,R  10.0.0.1  biz-internet  None
0       10   192.168.20.0/24  1.1.1.2    C,I,R    10.0.0.2  mpls          None
0       10   192.168.20.0/24  1.1.1.2    C,I,R    10.0.0.2  biz-internet  None

TLOCs tell the same story: region-id None and mrf-route-originator not set. BFD is a straight pair of tunnels between the two sites. That is exactly what a flat overlay should look like.

I left it that way. Standing up MRF properly means creating regions in Manager's network hierarchy, assigning controllers to regions, adding border routers that can reach both an access transport and a core transport, and then watching tunnel counts change. This lab has two edges and one Controller. It is the wrong place to pretend we have a core.

How you would turn MRF on later

On Manager you enable Multi-Region Fabric and create access regions in the network hierarchy. Controllers are assigned so that access regions and the core have someone to talk to. Cisco's FAQ treats regional hubs as border routers and branches as edge routers.

On an IOS XE edge the region assignment is a system command:

system
 region 1

A subregion (1 to 63) is optional and arrived in 17.10.1a:

system
 region 1
  subregion 5

A border router keeps an access region and takes the border role:

system
 region 1
 role border-router

The default role is edge router. no role returns a box to that default. These C8000v routers already report device-role edge-router without any role line.

Border routers reoriginate OMP routes between their access region and the core so you do not have to write a static control policy for every inter-region prefix. Affinity groups (1 to 63) are an extra preference knob if you have several border routers and want an edge to prefer one of them.

Secondary regions, management regions, and transport-gateway behavior are later chapters. The core idea is enough for this post: edges stay inside a region, borders stitch regions together, and the core is where you spend the expensive long-haul transport.

Verify the flat overlay you actually have

What breaks

• Assigning two edges different region IDs without border routers. They will stop building a direct tunnel, and there will be no path to replace it.
• A border router with no core-facing transport, or no core peers. Inter-region traffic has nowhere to go.
• Sharing one Controller across too many roles without reading the current MRF controller rules. Some management-region designs want dedicated controllers.
• Treating MRF as a substitute for segmentation. Regions scale tunnels and routing. VPNs still separate user traffic. That is the next post.
• Trying this on a two-edge lab to "see what happens." You can lose the only data-plane path you have.

Key takeaways

• Multi-Region Fabric splits an overlay into access regions and a core. Edges mesh inside a region. Border routers carry traffic between regions, usually in three hops.
• This lab is a flat overlay: both edges report edge-router, region-id-set N/A, and OMP prefixes with REGION ID None. Direct BFD sessions are up between the two sites.
• I did not create regions or border routers. The host cannot honestly represent a multi-region core with the controllers and RAM that are here.
• Keep the flat two-site fabric until you have extra edges, extra controllers, and a reason to count tunnels before and after.