Skip to main content

Routing

How AthenaBNG's control plane advertises subscribers and integrates with the core via FRRouting.

Overview​

AthenaBNG separates routing into two planes with distinct jobs:

  • IGP (IS-IS) carries only the router loopback reachability across the core, so iBGP can peer loopback-to-loopback.
  • BGP carries subscribers (as a route policy) and handles upstream/core peering.

Subscribers are never injected into the IGP. This keeps the IGP small and stable while BGP scales to hold the subscriber table.

The IGP: IS-IS (loopback carrier)​

IS-IS runs as a single, dual-stack (IPv4 + IPv6) instance — single-topology, metric-style wide. Its sole purpose is to advertise the router's loopback:

  • The IPv4 loopback (system.router_id/32) is exported into IS-IS via a route-map matched to the loopback only (ISIS-EXPORT / ISIS-LOOPBACK).
  • The IPv6 loopback (system.router_id_v6/128), when configured, is advertised via a passive interface lo stanza (ipv6 router isis + isis passive). This is a deliberate quirk: FRR isisd does not emit loopback /128s through redistribute ipv6 connected the way it does for IPv4, so the loopback address is activated passively (no hellos, just the address).

Core interfaces are activated explicitly (isis.interfaces), typically as point-to-point to skip DIS election. Subscribers stay out of IS-IS.

The subscriber plane: BGP​

IPv4 — per-host routes​

When announce_subscriber_routes is on:

  1. Subscriber session established (PPPoE or IPoE/DHCP).
  2. Subscriber IP assigned (e.g. 100.64.0.10).
  3. A /32 host route appears in the kernel (via the subscriber interface).
  4. FRR redistributes it into the BGP IPv4 unicast AF through the SUB-ROUTES-TO-BGP route-map, which permits only /32s that fall within the configured subscriber_networks and excludes the router loopback.
  5. The route is advertised to BGP neighbours; upstream can reach the subscriber directly.

When the subscriber disconnects the kernel route is removed, FRR withdraws it, and neighbours receive the withdrawal.

IPv6 — aggregate only​

IPv6 is handled differently. Instead of per-customer routes, BGP announces the aggregate only:

  • Each subscriber_networks_v6 entry renders aggregate-address <net> summary-only in the IPv6 unicast AF.
  • A matching ipv6 route <net> blackhole gives the aggregate a permanent contributing route, so the aggregate is announced even with zero active subscribers, and traffic to unallocated space is discarded (no loop back to the core).
  • Per-customer delegated prefixes (typically /56) are installed locally for forwarding but suppressed from BGP by summary-only.

Per-subscriber IPv6 prefixes come solely from RADIUS (fail-closed — no local pool); the BNG never invents a prefix, so a session with no RADIUS-supplied prefix degrades to IPv4-only.

iBGP: loopback-to-loopback​

iBGP peers are reached over the loopbacks that IS-IS carries, using update-source lo:

  • IPv4 neighbours join the UPSTREAM peer-group and are activated under address-family ipv4 unicast.
  • IPv6 neighbours join a separate UPSTREAM6 peer-group, activated under address-family ipv6 unicast with next-hop-self. IPv6 iBGP runs natively over the v6 loopbacks — v6 NLRI over a v6 session, not v6-over-v4.
  • no bgp default ipv4-unicast ensures a v6-only peer is not auto-activated for IPv4.

OSPF​

OSPF is still supported as a legacy IGP option (routing.ospf) but IS-IS is the current, recommended IGP. In the reference deployment the upstream routers run OSPF while migrating to IS-IS; see BGP/OSPF Integration for the interop detail.

Configuration​

system:
  router_id: "10.255.0.4"
  router_id_v6: "2001:df4:2040::4"

routing:
  isis:
    enabled: true
    net: "49.0001.0000.0000.0004.00"
    interfaces:
      - name: upstream0
        network_type: point-to-point
  bgp:
    enabled: true
    asn: 64512
    neighbors:
      - address: "10.255.0.1"
        remote_as: 64512
        update_source: "lo"
      - address: "2001:df4:2040::1"
        remote_as: 64512
        update_source: "lo"
    announce_subscriber_routes: true
    subscriber_networks: ["100.64.0.0/10"]
    announce_subscriber_routes_v6: true
    subscriber_networks_v6: ["2001:df4:2040:1000::/52"]

See Routing Configuration for every knob.

Monitoring​

abng> show bgp summary
abng> show routes
sudo vtysh -c "show isis neighbor"
sudo vtysh -c "show bgp ipv4 unicast"
sudo vtysh -c "show bgp ipv6 unicast"

Troubleshooting​

iBGP not establishing​

  1. Confirm the peer loopback is reachable via IS-IS, then ping it.
  2. Confirm update_source: lo on both ends.
  3. For v6 peers, confirm router_id_v6 is set and in IS-IS.

IPv4 subscriber routes not advertised​

  1. Check announce_subscriber_routes and that the IP is within subscriber_networks.
  2. sudo vtysh -c "show bgp ipv4 unicast".

IPv6 aggregate not advertised​

The per-customer prefixes are suppressed by design — check the aggregate:

sudo vtysh -c "show bgp ipv6 unicast 2001:df4:2040:1000::/52"

If it is missing, confirm the ipv6 route … blackhole contributor exists (announce_subscriber_routes_v6 must be on).

Best practices​

  1. Keep IS-IS loopback-only; let BGP carry subscribers.
  2. Peer iBGP loopback-to-loopback with update_source: lo.
  3. Announce the IPv6 aggregate, never per-customer more-specifics.
  4. Use point-to-point IS-IS on core links.
  5. Monitor BGP session state and IS-IS adjacencies.

Next steps​