Good — selector routes are the clean way to solve the exact problem you hit.

🧠 Core idea

Instead of trying to say:

“use Tokyo’s default route”

(which is ambiguous once it propagates)

You create:

a unique, identifiable route that represents “Tokyo as an exit”

🔧 What a selector route is

Each terminator advertises a unique /32:

Example:

Tokyo:    203.0.113.3/32
Montreal: 203.0.113.2/32
Dallas:   203.0.113.1/32

These are:

• NOT real services
• NOT used by clients directly
• Just routing anchors

🧩 What BGP does with them

Tokyo advertises:

203.0.113.3/32
AS path: 64515
community: exit-tokyo

Montreal learns it and re-advertises:

AS path: 64513 64515

pfSense learns:

• route to 203.0.113.3 via Montreal
• maybe another via Dallas (longer path)

👉 BGP naturally finds the best path to Tokyo

🔑 What you gain

Now pfSense has:

“the best path to Tokyo” (as a next-hop)

without needing a direct link

🚦 How you USE it (this is the magic)

On pfSense:

For Tokyo clients (198.18.80.0/24)

Create a rule:

• source: 198.18.80.0/24
• gateway: 203.0.113.3

pfSense will:

1. look up route to 203.0.113.3
2. see:

   via Montreal (best path)

1. send traffic that way

📦 Actual packet flow

Client → pfSense
        → (policy route to 203.0.113.3)
        → Montreal
        → Tokyo
        → Internet

⚠️ Important detail

The packet destination is still:

8.8.8.8 (or whatever)

The selector route is ONLY used to choose the next-hop path, not the destination.

🧠 Why this works

Because:

• routing lookup picks next-hop based on destination

• policy routing says:

  “pretend you're trying to reach 203.0.113.3 when choosing a gateway”

🆚 Why this is better than using default routes

Without selectors:

• multiple 0.0.0.0/0
• hard to distinguish origin after propagation
• BGP picks one globally

With selectors:

• each exit is uniquely identifiable
• BGP figures out how to reach it
• pfSense decides who uses it

🧱 Minimal FRR example (Tokyo)

router bgp 64515
 address-family ipv4 unicast
  network 203.0.113.3/32
 exit-address-family

(ensure it exists in RIB via loopback)

🧠 Mental model

• selector route = “handle to reach this exit”
• BGP = “how do I get there?”
• pfSense = “who should go there?”

🔥 TL;DR

• each exit advertises a unique /32
• pfSense learns best path to that /32 via BGP
• policy routing uses that /32 as a target to choose path
• traffic flows through mesh to the correct exit

👉 When this really shines

• no direct links needed
• full mesh or partial mesh works
• scalable to many regions

• clean separation of:

  • identity (selector)
  • transport (BGP)
  • policy (pfSense)

If you want next: 👉 we can combine selectors + communities cleanly so you get:

• “best region” default
• AND “force Tokyo” behavior without conflicts