[j-nsp] Juniper BNG - Termination of N:1 subscribers into different RI (DEMUX)

[Fraser McGlinn]

Hey Guys,

I’ve got a requirement from a customer where they are needing to terminate multiple different subscribers on the same layer 2 domain (delivered via a last mile provider that doesn't support unique vlan per subscriber, retarded I know!) into different routing instances via IP based demux.
I’ve got the IP Based demux stuff working fine with triggers via DHCP, however this seems to only work for a single RI and just errors out with:

Apr 27 22:36:26.755944 [MSTR][WARN] [default:default][SVR][INET][xe-0/0/1.3558][SID=201546] cedb_entry_rc_update_required: Required move of client 142407 from routing instance default:default to routing instance default:cgnat is invalid. Client's incoming interface config in wholesale(0x9fff98d8) or retail(0) INET routing context could not be retrieved.
Apr 27 22:36:26.755996 [MSTR][INFO] [default:default][SVR][INET][xe-0/0/1.3558][SID=201546] jdhcpd_local_server_auth_request_ack_common: Invalid logical-system/routing-instance supplied during authentication, dropping

This seems expected based on my experience with VLAN based demux where you have to drop the first dip of the double dip auth into the new RI in order for DHCP to be running in the same RI as the subscriber is terminated in.
So the problem I’m trying to solve is how to build the same style configuration as the double dip with dynamic VLANs but for a single shared switching domain with multiple subs.

The topology is as follows: 
Subscribers, shared layer 2 domain in last mile provider -> MX on vlan 3558 -> demux per household -> IP interface

I’ve tried playing around with line-identity auto-configure but I can’t seem to get it working at all. Possible I’m trying to use it in the wrong way, the documentation seems to be missing bits of glue to tie all the concepts together.

Has anyone else solved this problem? Is this even possible? I do understand that even if it is possible there are many pitfalls with this approach, its just the old have to fudge a solution based on requirements outside of your control. Naturally PPPoE works great in this instance, but anyhow requirements are pushing to at least try for IPOE.

Cheers,
Fraser