Converting a Juniper MX BNG configuration to Netavo

If you terminate subscribers on a Juniper MX today, the constructs you rely on have direct equivalents on Netavo BNG. The difference is mostly shape: Junos spreads subscriber configuration across dynamic-profiles, access, interfaces and routing-instances; Netavo keeps it in one JSON file (/etc/netavo-bng/config.json) that you can hold in version control. This guide maps the usual pieces so you can plan a cutover rather than a redesign.

The shape of the migration

The MX does four jobs for a subscriber edge: it terminates the access protocol (PPPoE/IPoE), authenticates and accounts each session against RADIUS, hands out an address, and places the subscriber into a routing context (global or an L3VPN). Netavo does the same four jobs, so you can translate each part of the configuration without redesigning the architecture. Run the two edges side by side, move a pilot hand-off, then shift the rest.

The examples below are sections to add to a working config.json; they do not form a complete file.

Access and PPPoE / IPoE

On the MX, a PPPoE subscriber interface is instantiated from a dynamic profile over an underlying interface:

dynamic-profiles {
    pppoe-prof {
        interfaces {
            pp0 {
                unit "$junos-interface-unit" {
                    ppp-options { chap; }
                    pppoe-options { underlying-interface "$junos-underlying-interface"; server; }
                    family inet { unnumbered-address lo0.0; }
                }
            }
        }
    }
}
protocols pppoe { }
system services subscriber-management { enable; }

On Netavo you name the physical access ports in dataPlane.subscriberInterfaces, turn on the access protocols, and describe the wholesale hand-off as an access NNI (the outer S-tag the aggregator adds):

"dataPlane": {
  "subscriberInterfaces": [
    { "ifname": "eno1", "pci": "0000:04:00.0", "rxQueues": 4,
      "accessProtocols": ["pppoe", "ipoe"], "spray": "auto" }
  ]
},
"pppoe": { "enabled": true, "acName": "bng1.lon1" },
"ipoe":  { "enabled": true, "serverIp": "10.255.255.1" },
"subscribers": {
  "accessNnis": [
    { "name": "wholesale-south", "interface": "eno1", "sVlan": 200,
      "description": "Wholesale FTTP hand-off, C-VLANs inside the S-tag" }
  ]
}

Authentication and accounting (RADIUS)

Junos ties RADIUS to the subscriber through an access profile:

access {
    radius-server { 10.20.0.5 { secret "$9$secret"; port 1812; } }
    profile isp-auth {
        authentication-order radius;
        radius {
            authentication-server 10.20.0.5;
            accounting-server 10.20.0.5;
        }
        accounting { order radius; }
    }
}

Netavo points auth and accounting at the same servers. You keep your RADIUS (FreeRADIUS, or whatever your billing drives); only the NAS changes.

"auth": {
  "driver": "radius",
  "radius": {
    "servers": [ { "host": "10.20.0.5", "port": 1812, "secret": "op://netavo/radius/secret" } ],
    "nasIdentifier": "bng1.lon1",
    "nasIpAddress": "45.84.203.1",
    "option82Encoding": "bbf-vsa",
    "rateAttributeMode": "auto"
  }
},
"accounting": { "driver": "radius", "interimIntervalSeconds": 300 }

Moving from a MikroTik edge rather than an MX? rateAttributeMode can be set to mikrotik so the rate-limit VSAs your RADIUS already returns are honoured unchanged.

Address pools

A Junos address-assignment pool:

access address-assignment {
    pool residential-v4 { family inet { network 100.64.16.0/20; } }
}

Netavo pools are typed by family and bound to a VRF. Dual-stack is one pool set: a v4 range, a routed /64 WAN, and a delegated /56.

"addressPools": [
  { "name": "residential-v4", "family": "ipv4", "vrf": "fttx-south",
    "subnets": [ { "prefix": "100.64.16.0/20" } ],
    "exclude": [ "100.64.16.0", "100.64.16.1", "100.64.31.255" ] },
  { "name": "residential-v6-wan", "family": "ipv6-wan", "vrf": "fttx-south",
    "subnets": [ { "prefix": "2a0e:9f81:101::/52", "announce": true } ] },
  { "name": "residential-v6-pd", "family": "ipv6-pd", "vrf": "fttx-south",
    "delegationLength": 56,
    "subnets": [ { "prefix": "2a0e:9f81:110::/44", "announce": true } ] }
]

Routing and VRFs (L3VPN)

A Junos L3VPN instance:

routing-instances {
    business {
        instance-type vrf;
        route-distinguisher 208802:2100;
        vrf-target target:208802:2100;
    }
}

The Netavo routing stack runs on the same box, so the BNG is the PE. VRFs carry an RD and route-targets; BGP and the IGP are configured alongside.

"routing": {
  "asn": 208802,
  "routerId": "45.84.203.1",
  "isisInterfaces": ["ens3f0", "ens3f1"],
  "peers": [ { "address": "45.84.203.2", "description": "pe1", "bfd": true } ],
  "vrfs": [
    { "name": "business", "tableId": 2100, "rd": "208802:2100",
      "importRt": ["208802:2100"], "exportRt": ["208802:2100"],
      "gatewayIp": "45.84.203.15" }
  ]
}

CoA and Disconnect

Junos accepts RADIUS-initiated change-of-authorization through the access profile and its radius-server dynamic-request configuration. Netavo listens for RFC 5176 CoA and Disconnect natively:

"auth": {
  "radius": {
    "coaPort": 3799,
    "coaSecret": "op://netavo/radius/coa",
    "coaAllowedSources": ["10.20.0.5"]
  }
}

A mid-session rate change, a plan swap or a forced disconnect from your RADIUS reaches live sessions exactly as it did on the MX, with an Event-Timestamp skew window you can tune.

What doesn't map one for one

Check these differences before planning the cutover:

• Junos dynamic-profiles. The variable-driven profile language that instantiates per-subscriber interfaces and services has no direct counterpart. Netavo brings sessions up on the access NNI and shapes them from RADIUS reply attributes, so per-subscriber behaviour is expressed in RADIUS policy rather than a profile template. For most access deployments this is simpler; if you lean heavily on profile logic, plan to move that intent into RADIUS.
• Hierarchical CoS. Netavo applies a per-subscriber rate (from the plan or a RADIUS attribute); it does not reproduce a full Junos H-CoS scheduler tree. Confirm your QoS model maps to per-subscriber shaping before cutover.
• MX-specific knobs. Anything tied to the Trio/line-card forwarding model, enhanced subscriber-management features, or Junos-only protocol extensions should be checked against the Netavo manual rather than assumed.

Try the mapping on your own config

The fastest way to validate a translation is to run it. The free evaluation build is the production build, licensed for up to 50 concurrent subscribers with every feature enabled, so you can bring a pilot hand-off up on a VM and watch real sessions before committing. Start at netavobng.com/evaluation, and the full configuration reference is in the manual.