PPPOE authentication with Plusnet FTTP not working

[#1]

Ahhhh right ok, sorry obviously just skimmed some of the posts!! Thanks for helping!!

[#2]

running a 440 on  11.1

[#3]

Hi thanks for raising a call with Palo, I am running a PA-220 with software version: 10.2.3-h4

[#4]

@leighboy - that's brave lol, how you finding 11?

@witherford cheers!

Update: had the first remote session today. It went about as well as you'd expect with PAN.

We checked DNS entries, added a few rules, added some NAT rules, deleted some nat rules, I drew him some pictures, we set the interface to DHCP Client, set it back to PPPoE, re typed the account password, pinged Google from the management interface. Explained a few times that just asking BTW to set their infrastructure to ignore the end of list tag wasn't going to happen, explained that we couldn't bypass the intermediary (BTW) and connect straight to the ISP and finally captured the same logs I'd attached when I opened the case 3/4 days ago so he could see if he could recreate it in his lab (based outside of the UK)

I have a call again tomorrow so will update then.

[#5]

Not that much of an update but hopefully some progress.

We didn't waste as much time today which was nice, the end result was the same but after the call I got an update on the ticket summarising what we'd done, as the next steps he is going to look over the logs again but with a view to escalating it to a tier 3 tech which I'm hoping it's a step closer to the dev team which I'm guessing is where this is going to end up.

Full disclosure I'm not with plusnet but Zen (connected via Openreach's infra not City Fibre's) and obviously seeing the same behaviour so assuming it's the same issue with BTW's new Nokia kit.

Next update will be next week I suspect but if I hear anything sooner I will report back.

@dave your input has been invaluable in being able to push them when they were trying to say it was an ISP issue/not related to the End Of Line tag so thankyou again

Have a good weekend all

[#6]

Hi All,

So not much to update I'm afraid. The case has now been escalated. The status went to 'Waiting for TAC handoff' and has now been assigned to a different person.

We ran through a few more PCAPs after a few changes but to no avail. I've seen a few posts, primarily on reddit where people have had success, interestingly mostly where BT has been the ISP so maybe they're using the Huawei routers the other side of the ONT which are just ignoring the EOL tag.

I have a session scheduled on Friday with the next level engineer so we shall see.

[#7]

Right we may be getting somewhere. I've had another remote session but this time with the T3 guy who seemed abit more clued up. We went through the usual set it to passive, checked the username and password and did some PCAPs which he's taken away. However he is now opening an engineering case which sounds like it maybe Pan's dev team so hopefully my next update will be it's fixed lol, not that hopeful bit it does now feel like we're moving on the right direction. As usual I'll update this thread with any changes. If anyone has any input/questions let me know, it was really useful to be able to give other examples of os and platform combinations that didn't work so thanks for that.

[#8]

If they need any assistance from us I'll PM you my email address and they can get in touch. I don't have any Palo Alto kit to test with but do have access to an FTTP line and happy test with a loaner if they have any and need further testing (not sure which vendor I'm on, I'd need to check). I have colleagues that also have FTTP so we can try those too if needs be.

[#9]

Not much to report, PAN keep flitting between we aren't appending an EOL tag to yes we are appending an EOL tag but it's fine we're only putting it in once we're done. 

One question I'd like to get resolved which is probably an @dave question:

PAN are (potentially fairly) saying the EOL tag is going in at the end once they've done sending traffic. 

My question is:
Where is the following information being appended from:

[0x01] Agent-Circuit-Id: "XXXX-OLT1 xpon X/X/X:X.XXX"
[0x02] Agent-Remote-Id: "BBEUXXXXXXXX"

My first theory was the ONT is doing something as the session setup is being done?

Cheers

[#10]

They're added by Openreach between the Openreach OLT and the BTW MSE device. The traffic path looks something like this:

CPE -> ONT -> Fibre cable back to the exchange -> OLT -> Openreach network -> BT Wholesale network -> BTW MSE -> BTW Network -> Plusnet network

The BBEU number and circuit ID are added either by the OLT or something within the Openreach network. BBEU looks like BBEU12345678 and circuit ID like 1234-OLT-1 xpon 1/1/1:1.1234 and are unique per circuit, the BBEU (standing for broadband end user) is a unique reference like a phone number for broadband and the circuit ID is essentially which bit of kit the line is connected to.

The confusing thing is why this works on FTTC and not FTTP and the main thing I can think of is that the way the Palo Alto and the FTTP work together is different, possibly the DSLAM in the FTTC world does something different e.g. ignores the EOL tag on FTTC or the vendor on FTTP is different and we might find it works on other FTTP lines which use a different vendor.

[#11]

Well since that information isnt known to either your router ( or the Hub 2 ) it must be being inserted upstream.

This http://ruwanindikaprasanna.blogspot.com/2007/05/pppoe-circuit-id-tagging-feature-in.html seems to indicate its the BRAS or whatever the FTTP equivalent is. That would probably explain why its after the EOL tag. Its not checking what's in the PPPoE tags , its just adding its vendor specific at the end.

edit Dave beat me to it, but nice to know I got it more or less right😀

[#12]

Hi,

Cheers for that. That's about what I was expecting I think!

This does seem to be escalating within Palo Alto which is good, I've just had one of their core engineers make contact with me directly which is promising

I have heard of Palo's working on other ISP lines BT (the ISP) in some areas work however I suspect this maybe more to do with the kit in the exchange than the end user ISP

Cheers

Pete

[#13]

Yeah that's exactly my thinking too. Openreach use multiple vendors for their FTTP kit Nokia, ECI, Huawei and Adtran I think from just checking ISPReview so it could just be one or more but not all of them for example and for those customers that upgraded from working FTTC to FTTP they could've switched vendor in the process. If the FTTP kit was the same vendor then it could work, or at least in theory that could explain why it would work on some lines.

The BTWholesale guys told me that the type of fault here would mean it wouldn't work on any BTWholesale ISP line, so it wouldn't work on Plusnet, BT or EE or any of the other ISPs that use the BTW network. Whether it would work on an ISP like Sky that doesn't use BTW we couldn't say as it would depend whether they use that value and how they've set things up to handle this situation.

[#14]

Whether it would work on an ISP like Sky that doesn't use BTW we couldn't say as it would depend whether they use that value and how they've set things up to handle this situation.

Sky ( and Talktalk ) dont use PPPoE , they use DHCP, so it likely won't be a problem.

[#15]

@dave thanks for that and thanks for getting back to me so quickly.

All - I'm hoping to have abit of a more meaningful update this week.

Cheers