Skip to main content

BGP/OSPF Integration

Integrating AthenaBNG into a core that is migrating from OSPF to IS-IS, with native dual-stack iBGP over the loopbacks.

Overview​

AthenaBNG's control plane is built around two roles:

  • IS-IS is the IGP and carries only the router loopback reachability.
  • BGP carries subscribers and peers with the rest of the core over those loopbacks.

This page covers the interop story: how the BNG slots into an upstream that historically ran OSPF and is moving to IS-IS, and the FRR internals that implement it.

Reference topology​

In the reference deployment the upstream/border routers are MikroTik boxes running OSPF as a legacy IGP, migrating to IS-IS. The BNG integrates by:

  • speaking dual-stack IS-IS to the border routers to exchange loopback reachability (IPv4 /32 + IPv6 /128), and
  • running native IPv4 + IPv6 iBGP loopback-to-loopback for the subscriber and transit tables.

The IGP job is deliberately minimal: it exists so the loopbacks are reachable, which is all iBGP needs. Subscribers ride BGP, not the IGP.

MikroTik dual-stack IS-IS note​

On MikroTik, dual-stack IS-IS is a single instance carrying both address families (afi=ip,ipv6) — not two separate instances. This mirrors the BNG, where routing.isis is one FRR router isis instance advertising both AFIs (single-topology, metric-style wide). Keep both ends single-instance/dual-AFI so the adjacency and metrics line up.

OSPF during migration​

While the core still runs OSPF, the BNG can bring up routing.ospf alongside IS-IS if it needs to exchange loopbacks with an OSPF-only neighbour during transition. OSPF here redistributes the loopback (CONNECTED-TO-OSPF, matched to interface lo) and static routes only — same loopback-carrier role as IS-IS. Prefer IS-IS as the target IGP and retire OSPF once the core has migrated.

iBGP: loopback-to-loopback, native dual-stack​

Both address families peer over the loopbacks with update-source lo:

routing:
  bgp:
    enabled: true
    asn: 64512
    neighbors:
      - address: "10.255.0.1"        # BDR1 v4 loopback
        remote_as: 64512
        description: "BDR1 iBGP v4"
        update_source: "lo"
      - address: "2001:df4:2040::1"  # BDR1 v6 loopback
        remote_as: 64512
        description: "BDR1 iBGP v6"
        update_source: "lo"

FRR renders two peer-groups:

  • UPSTREAM — IPv4 neighbours, activated under address-family ipv4 unicast.
  • UPSTREAM6 — IPv6 neighbours, activated under address-family ipv6 unicast with next-hop-self.

no bgp default ipv4-unicast is emitted so a v6 peer is not auto-activated for IPv4. IPv6 iBGP runs natively over the v6 loopback session — v6 NLRI on a v6 transport — not v6-NLRI-over-a-v4-session.

How subscriber announcement works​

IPv4 — host routes, loopback excluded​

The prefix-list excludes the loopback and permits only host routes in the subscriber supernets:

ip prefix-list SUBSCRIBER-PREFIXES seq 5 deny 10.255.0.4/32
ip prefix-list SUBSCRIBER-PREFIXES seq 10 permit 100.64.0.0/10 ge 32 le 32
route-map SUB-ROUTES-TO-BGP permit 10
 match ip address prefix-list SUBSCRIBER-PREFIXES

Set host_routes_only: false to announce the subscriber_networks at their natural length instead of per-/32.

IPv6 — aggregate only​

IPv6 announces the aggregate, not per-customer prefixes:

ipv6 route 2001:df4:2040:1000::/52 blackhole      ! contributor + discard
router bgp 64512
 address-family ipv6 unicast
  aggregate-address 2001:df4:2040:1000::/52 summary-only
  • summary-only suppresses the per-customer /56//60 more-specifics from BGP while they still forward locally.
  • The blackhole route guarantees the aggregate always has a contributor, so it is announced even with zero active subscribers, and unallocated space is discarded rather than looped back to the border.

Per-subscriber IPv6 prefixes are RADIUS-assigned (fail-closed, no local pool).

Monitoring​

# IS-IS adjacencies and LSDB (should carry only loopbacks)
sudo vtysh -c "show isis neighbor"
sudo vtysh -c "show isis database detail"

# BGP sessions (v4 and v6 peers)
abng> show bgp summary
sudo vtysh -c "show bgp ipv4 unicast summary"
sudo vtysh -c "show bgp ipv6 unicast summary"

# What we advertise
sudo vtysh -c "show bgp ipv4 unicast neighbors 10.255.0.1 advertised-routes"
sudo vtysh -c "show bgp ipv6 unicast 2001:df4:2040:1000::/52"

Troubleshooting​

iBGP neighbour not establishing​

  1. Loopback reachable via the IGP? sudo vtysh -c "show isis database", then ping <peer-loopback>.
  2. update_source: lo set on both ends?
  3. v6 peer: is system.router_id_v6 set and the /128 in IS-IS?
  4. Firewall permits TCP 179 on the core interface.

IS-IS adjacency not forming​

  1. sudo vtysh -c "show isis neighbor".
  2. Both ends single-instance dual-AFI (MikroTik afi=ip,ipv6; FRR one router isis)?
  3. network_type and level agree on both ends of the P2P link.

IPv6 aggregate missing upstream​

The more-specifics are suppressed on purpose. Confirm:

  1. announce_subscriber_routes_v6: true and the subscriber_networks_v6 entry.
  2. The ipv6 route <net> blackhole contributor is present (show ipv6 route <net>).
  3. show bgp ipv6 unicast <net> shows the aggregate originating.

Advanced​

BGP communities​

Tag announced subscriber routes with a community (applied in both the v4 and v6 route-maps):

routing:
  bgp:
    community: "64512:100"

Loopback addressing​

Infrastructure sits outside the subscriber aggregate. In the reference plan the loopbacks live in 2001:df4:2040::/64 (BNG ::4, BDR1 ::1) and the BNG↔BDR1 P2P link is a /127 in 2001:df4:2040:1::/64 — kept entirely separate from the announced 2001:df4:2040:1000::/52 subscriber block.

Next steps​