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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to