[AusNOG] Which NBN RSP are using PPPoE vs IP

[Jason Mikronis]

Hi,

Cisco LAC will pass the called station as well as DSLAM information (ie: "PPPoE Data") - but you will need a current Layer2 ADSL service with AAPT to check what they are doing. Telstra will pass DSLAM ID as well as PVC ID and even Row/Rack/Port numbers for L2-DSL-IG.

I would assume that this is achievable with the NBN NTU doing the PPPoE, on the assumption that they are not dropped as "unknown" tags (ie: they may describe different to what AAPT is expecting from a DSLAM).

Jason

-----Original Message-----
From: Chris Kawchuk [mailto:juniperdude at gmail.com] 
Sent: Wednesday, 6 April 2016 9:57 AM
To: Jason Mikronis <jason at ausbbs.com.au>
Cc: Tim Warnock <timoid at timoid.org>; Ausnog <ausnog at lists.ausnog.net>
Subject: Re: [AusNOG] Which NBN RSP are using PPPoE vs IP

Hi Jason,

Yep, very familiar with the setup. My question was more on whether or not the PPPoE Option 82 (Containing the NBN-NTU injected AVC ID) gets passed through to the ISP LNS; or if it dies at the LAC. (Since there's a protocol translation going on here....) Its NBN 'hijacking' the PPPoE PADI/PADO discovery process which adds that field on behalf of the end-user (nice of them, eh?)

Agreed "sorting" of the end-subsciber can be done on @realm, or by static-mapping of S/C Tags coming in from the POI. (many ways to skin the cat...); either way, agreed, the VPDN tunnel (L2TP) is setup to the ISP LNS and no authentication is done at the LAC side of things.

Agreed, worthy of a PCAP here on the ingress side of the LNS to see if that gets passed, or if't just the L2TP credentials only.

- Ck.



On 6 Apr 2016, at 11:51 am, Jason Mikronis <jason at ausbbs.com.au> wrote:

> Forwarding is done like this - PPPoE - AAPT LAC - L2TP - ISP LNS
> 
> I have not checked with AAPT, but in a past life, forwarding at the LAC was done without checking passwords based on conditions (realm for example) and then L2F to the ISP LNS. If the L2TP session to the ISP was up, so was the PPPoE session. The only "issue" I can see is potential for too many MACs being presented to a single interface, but there should be no problems designing around that.
> 
> It is worthy of more investigation.