TTR Networks

Intermediate · Edge and core: building out a VyOS network · section 1 of 10

Why split edge and core

✓ Lab-tested 17 October 2026 on VyOS 2026.10.16-0024-rolling, FRR 10.2.1

Split one BGP router into edge routers that face the outside world and a core that carries traffic inside: loopbacks, OSPF for infrastructure, iBGP between loopbacks, next-hop-self, and what happens when a link fails. Built and broken on three real VyOS routers.

By the end you will be able to:

  • Explain what belongs on edge routers and what belongs in the core, and why
  • Plan loopback and point-to-point addressing for a small AS
  • Run OSPF for infrastructure only, and iBGP between loopbacks with a peer group
  • Diagnose inaccessible and wrongly resolved next hops, and fix them with next-hop-self
  • Show that iBGP between loopbacks survives a link failure while OSPF reroutes
  • Plan the next steps: route reflectors, more edges, BFD and core redundancy

Prerequisites: Setting up VyOS with basic BGP, OSPF Fundamentals

The previous lesson's R1 did everything: it held the transit session, the IX session, the policy, and the LAN. That's fine for one rack. It stops being fine when you need a second upstream, a second site, or the ability to reboot a router without an outage.

The usual next step is to split the network into two layers:

  • Edge routers face the outside world. Each one holds external BGP (eBGP) sessions to transit providers or IXs, and does all of the external filtering. Nothing else connects to them.
  • Core routers face inwards. They connect the edges to each other and to everything inside: LANs, servers, customer links. They never talk BGP to anyone outside your AS.

The two layers are glued together by two protocols with very different jobs:

Interior Gateway Protocol (IGP), here OSPFInternal BGP (iBGP)
CarriesYour infrastructure: loopbacks and the links between routersEverything else: external routes, and your customer and LAN prefixes
SizeSmall, a few dozen routesAs big as the internet, if you take full tables
Reacts to failuresIn seconds, by rerouting around a broken linkStays up as long as the IGP can still reach the peer's loopback

This split is what makes the network build out cleanly. Adding an edge means one new set of iBGP sessions and a few OSPF links, with no change to anyone's external policy. Losing a link means OSPF finds another way round, and BGP doesn't even notice.

This lesson builds the smallest useful version: edge1 with the upstream from the previous lesson, edge2 with the IX, and core1 with the LAN, connected in a triangle. Everything runs as three VyOS virtual machines (rolling 2026.10.16) with the same FRR upstream, route server and IX member as before, and every output is copied from that lab.

Diagram: Two edges and a core — The lab for this lesson. Step through how the pieces fit together.
  1. OSPF learns the loopbacks. OSPF runs only on the three internal links and the loopbacks. Within seconds every router can reach every other router's loopback, by more than one path.
  2. iBGP between loopbacks. Each router has an iBGP session to both of the others, sourced from and addressed to loopbacks. core1 originates our /24 aggregate and the LAN /25 into iBGP.
  3. The edges talk to the outside. edge1 announces only the /24 to the upstream and receives a default route. edge2 announces only the /24 to the route server and receives the member's prefix. All external filtering lives here.
  4. Next-hop-self. The edges pass external routes into iBGP with themselves as the next hop. Otherwise core1 would see next hops on links it has no route to, and couldn't use the routes at all.
  5. Traffic to the IX member. core1 prefers the IX path (local preference 150, set by edge2's import policy and carried across iBGP), so it forwards to edge2's loopback, which OSPF resolves to the direct link.
  6. Everything else via edge1. The default route points at edge1's loopback, so all other traffic leaves through the upstream.
  7. A link fails. The core1–edge2 link goes down. OSPF reroutes edge2's loopback via edge1, the iBGP session to edge2 stays up, and IX traffic now takes core1 → edge1 → edge2. No BGP routes change.

Check your understanding

Which routes should OSPF carry in this design?

  • Everything, including the default route and IX routes
  • Only loopbacks and the links between your routers
  • Only the LAN prefixes
  • Nothing; iBGP can work without an IGP