Networking · Routing & MPLS
A full MPLS provider edge, on the subscriber gateway.
Netavo BNG runs BGP with VPNv4 and VPNv6 address families, your choice of IGP — IS-IS or OSPF — and MPLS L3VPN with per-service VRFs: a complete PE role on the same system that terminates your subscribers. No adjacent router, no default-route dependency.
The routing view on the BNG itself — live BGP sessions (VPNv4/VPNv6), IS-IS adjacencies and per-VRF tables.
The BNG participates in your core as a first-class provider-edge device. It peers iBGP with your route reflectors carrying VPNv4 and VPNv6, and can hold full or partial Internet tables over eBGP where the design calls for it.
Subscribers land directly in the routing domain they belong to. Retail Internet, wholesale voice, walled garden and management each live in their own VRF, each with its own routing policy — on one system.
iBGP to the core route reflectors with VPNv4/VPNv6; full-table eBGP where required.
Per-neighbour state, address families and route counts — the view your NOC works from.
Both VPN address families are first-class: dual-stack subscriber services ride the same L3VPNs as the rest of your network, with IPv6 routes carried natively as VPNv6 — not tunnelled or approximated.
Per-peer policy, route reflection client operation and per-VRF import/export targets behave the way your existing PE estate does, so the BNG drops into an established MPLS design without special-casing.
The BNG runs the IGP your core already runs. Select IS-IS or OSPF per instance — or none at all, where the core is static or eBGP-routed.
IS-IS carries IPv4 and IPv6 over a single adjacency using multi-topology, with level-1/level-2 operation.
OSPF runs OSPFv2 and OSPFv3 together on a dual-stack box — two protocols, two adjacencies per neighbour, as the standards intend. Areas are assigned per interface, so a BNG can sit in the backbone area with a link into another without prefix-match ordering to reason about.
The choice is contained: loopback addressing, kernel MPLS and LDP are keyed off your core interfaces, not off the IGP, so label switching and every VPNv4/VPNv6 route behave identically whichever you pick.
Adjacency state over the management API — OSPFv2 and OSPFv3 rows are distinguished, so a dual-stack neighbour legitimately appears twice. IS-IS is served the same way at /routing/isis/neighbors, and both render as adjacency cards in the web interface.
LDP distributes transport labels across the core, and equal-cost multipath uses flow-consistent hashing so subscriber flows never reorder across parallel links. Label operations run in the data plane at forwarding rate: transport and VPN label push on ingress, penultimate-hop and double-label pop on egress.
A VPN route as the data plane forwards it — label stack, next-hop and ECMP state in one view.
Wholesale hand-offs are where this matters most: terminate L2TP or PPPoE subscribers and place them straight into the correct customer or service VPN, with the voice VRF, the walled garden and the management plane kept strictly apart.
| Capability | Detail | Status |
|---|---|---|
| BGP / MP-BGP | VPNv4 · VPNv6 · route-reflector client · per-peer policy | shipping |
| IGP — selectable | IS-IS, OSPF, or none · chosen per instance · LDP and loopback addressing unaffected by the choice | shipping |
| IS-IS | IPv4 + IPv6 over one adjacency (multi-topology) · level-1/level-2 | shipping |
| OSPFv2 / OSPFv3 | both on a dual-stack box · per-interface area assignment | shipping |
| MPLS L3VPN | LDP signalling · PE role · per-service VRFs · RD/RT policy | shipping |
| Label operations | transport + VPN push · PHP · double-label pop, at forwarding rate | shipping |
| ECMP | flow-consistent hashing · no intra-flow reordering | shipping |