Junos OS

Platform / SW

• MX204 as BNG (master) – Junos 23.4R2‑S3.9

• Remote “test” BNG in the same MPLS/LDP core (no dedicated port; pure LDP/MPLS)

• L2circuit handoff from access vendor into ps IFD; we want to selectively L2‑backhaul some subs to the remote BNG

Goal
Selective L2 backhaul (retail/L2BSA) of certain subscribers (identified by DHCP Option‑82 Remote‑ID).
Authentication is not PPPoE user/pass; we authenticate by Remote‑ID as username. RADIUS should:

• return ERX‑Client‑Profile‑Name = L2BSA (or L2BSA‑1TAG) → profile creates a vlan-vpls IFL on the access ps IFD

• return ERX‑Redirect‑VR‑Name = L2BSAVS (also tried ERX‑Virtual‑Router‑Name, ERX‑LSRI‑Name) → move that IFL into routing‑instance L2BSAVS (instance-type l2backhaul-vpn) which signals VPLS to the remote BNG

What happens (problem)

• RADIUS arrives and is parsed; logs show:

  • set authdAttrDynamicProfileName to L2BSA(-1TAG)

  • relocation to LS: default, RI: L2BSAVS (seen as LSRI in logs)

• But no dynamic VPLS IFL is ever created on the master BNG.

• Because of that, the VPLS instance remains LD (not Up). There’s no MAC learning and no traffic toward the remote BNG.

• We do not use any static ps0.900 (or similar) for VPLS on either side; the intention is fully dynamic IFL injection via the dynamic profile.

• Sessions often get torn down shortly after AAA, sometimes with:

  
  MALFORMED REQUEST – username invalid (dvlan-client path)
  
  
  

  and many occurrences of:

  
  authd_access_profile_get: profile local found
  
  
  

• arlier we also saw:

  
  NASPortID = 56%ps101.32767:3024
  authd_get_interface_nas_port_options Interface Radius-Options for Interface ps101 not found
  
  
  
  
  

  (We can add access radius-options on ps101 if that’s required; tried both ways.)

Access side (sanitized)

• Access handoff is a pseudowire‑service IFD (ps101) carrying L2circuit from the vendor; unit 0 is ethernet-ccc.

• We keep auto‑configure on ps101 only as the AAA trigger; it must admit mixed VLAN/QinQ. The auto‑configure dynamic profiles used locally are dummies (no RI bind).

• RADIUS is supposed to switch the subscriber to L2BSA / L2BSA‑1TAG and redirect to RI L2BSAVS, which should create the dynamic vlan-vpls IFL and insert it into L2BSAVS.

Dynamic profiles (key parts)

dynamic-profiles {
  L2BSA {
    routing-instances { "$junos-routing-instance" { interface "$junos-interface-name"; } }
    interfaces {
      "$junos-interface-ifd-name" {
        unit "$junos-interface-unit" {
          encapsulation vlan-vpls;
          vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id";
          family vpls;
        }
      }
    }
  }
  L2BSA-1TAG {
    routing-instances { "$junos-routing-instance" { interface "$junos-interface-name"; } }
    interfaces {
      "$junos-interface-ifd-name" {
        unit "$junos-interface-unit" {
          encapsulation vlan-vpls;
          vlan-id "$junos-vlan-id";
          family vpls;
        }
      }
    }
  }
  # DUMMY-NOP / DUMMY-NOP-1TAG exist only so auto-configure can trigger AAA (no RI bind).
}

Routing‑instance

routing-instances {
  L2BSAVS {
    instance-type l2backhaul-vpn;
    protocols { vpls { vpls-id 1001; neighbor 172.20.47.53; no-tunnel-services; } }
    vlan-model one-to-one;
    instance-role access;
    no-local-switching;
    # No static interface bound; we expect the dynamic IFL injected by the DP.
  }
} 

RADIUS (for a subscriber that must be backhauled)

ERX-Client-Profile-Name = L2BSA-1TAG      # also tried L2BSA (QinQ)
ERX-Redirect-VR-Name    = L2BSAVS         # also tried ERX-Virtual-Router-Name = L2BSAVS and ERX-LSRI-Name = default:L2BSAVS

Net effect

• We can see the AAA relocation intent to L2BSAVS and the DP name, but no dynamic vlan-vpls IFL is created, so VPLS stays LD and traffic never reaches the remote BNG.

• There is no static ps*.900 used for VPLS anywhere; the design depends on the dynamic IFL.

Questions

1. Is dynamic creation of a vlan-vpls IFL on a ps IFD (whose unit 0 is ethernet-ccc) supported on MX204 in this BNG/L2 backhaul context? Any FPC/PIC or platform caveats?

2. Is instance-type l2backhaul-vpn the right RI type for L2BSA on MX when the intent is a dynamic VPLS IFL? Or should this be a plain vpls instance?

3. Which ERX VSA is authoritative for RI relocation here (ERX-Redirect-VR-Name vs ERX-Virtual-Router-Name vs ERX-LSRI-Name), and should we send L2BSAVS or default:L2BSAVS?

4. Do we need any specific auto-configure constraints (e.g., a particular accept or encapsulation on the dummy profiles) so that the dvlan-client path doesn’t throw “MALFORMED REQUEST – username invalid”?

5. Could system services dhcp-local-server on this access segment interfere with L2 backhaul (do we need to remove it from the ps IFD for backhauled subs)?

6. Any known restrictions about using family vpls in a dynamic profile on a ps IFD vs needing family bridge for BNG L2 backhaul?

If anyone has a working example (RADIUS‑driven dynamic vlan-vpls IFL + RI relocation from a ps IFD) or can confirm the supported pattern on MX204, that would be hugely helpful. I’m happy to add exact log lines showing authdAttrDynamicProfileName = L2BSA(-1TAG) and the immediate logout if needed.

Thanks!