Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kitz]

BT are in the fortunate position of being about the only ISP that is straight on to the BT core network. 
Other BTw based ISPs have to worry about things like Centrals/APs/EPs/MSILs etc and L2TP which masks the BT core. 

I think the problem we have here is that the ISP's RADIUS  & session times for some reason or other cant be set to meet those of BTs      

[ColinS]

I think the problem we have here is that the ISP's RADIUS  & session times for some reason or other cant be set to meet those of BTs   

Indeed it is Kitz.  First of all, as you refer to, these are Edge routers (to the BT network) that are policing these timeouts, and the values chosen were to accomodate ADSL, not SIN 498 (VDSL).  They hadn't caught up with that (SIN) and because VDSL and ADSL traffic are (apparently) roted with the same Vlan, they can't sort it for VDSL without the risk of upsetting their larger number of ADSL users.

Stuffed, I think the expression is? 

[waltergmw]

@ Colin,

But I thought  "All animals were supposed to be equal" ??  !!

Kind regards,
Walter

[Chrysalis]

possibly but plusnet seem to have a lot of unusual unique problems I dont see reported on other isp's.

Requiring the amount of time reported in this thread to recconect sounds very excessive.

[ColinS]

But I thought  "All animals were supposed to be equal" ??  !!

But some are more equal than others! 

Requiring the amount of time reported in this thread to recconect sounds very excessive.

It is, which is why they are reducing it.

[ColinS]

It seems that at least one BTw EU believes that they may also suffer from IP Profiles not updating immediately after an 'on-the-fly' DLM resync ...

from this thread http://forum.kitz.co.uk/index.php/topic,12834.0.html

Looks like the link went down and came back early this morning. The stats have certainly improved with a higher sync and lower interleaving. I had to reboot the HomeHub to get a new IP profile as the PPP session hadn't dropped during the resync.

[Chrysalis]

yesterday BT booted me of my ppp sessions, so I did some maitnenance on my router, also rebooted my modem as I had spare snrm to get increased speed.

I had instant access to that speed.

[Chrysalis]

so a further comment.

plusnet are using a 120s keepalive, that in itself is very high (as already stated the timeout is multiples of that).  openreach (or BTw) cant remember which have a published document that says isp's are expected to have the ppp timeout quicker than the modem resyncs, and they list a expected resync time for modems.  I think they said ppp should timeout in under 30s (or something around that number).

So does look like plusnet have some work to do.

[ColinS]

yesterday BT booted me of my ppp sessions, so I did some maitnenance on my router, also rebooted my modem as I had spare snrm to get increased speed.
I had instant access to that speed.

Good for you. But I bet it took far longer that the 10 secs resync time of a DLM-initiated 'on-the-fly' resync?  Probably a lot longer than 120s too?  So you're not actually talking about the same thing here are you? 

I understood your concern was the separate issue that

plusnet have already said in an earlier post on their forums the reason they have slow profile updates is that they process profile updates in batches in intervals, not when the user recconects.

My post above was simply to demonstrate that at least one BTw EU differs from you in your belief that in all instances

its unique to plusnet.

since that EU believes it happened on BTw too. Perhaps you don't believe him either that it can happen in certain circumstances even with BTw?

plusnet are using a 120s keepalive, that in itself is very high (as already stated the timeout is multiples of that).  openreach (or BTw) cant remember which have a published document that says isp's are expected to have the ppp timeout quicker than the modem resyncs, and they list a expected resync time for modems.  I think they said ppp should timeout in under 30s (or something around that number).
So does look like plusnet have some work to do.

Yes, it is still too long, as I have already said to you in reply#9 of this thread http://forum.kitz.co.uk/index.php/topic,12822.15.html

They know that, and have acknowledged that they have further work to do, but also said that they could not do so immediately without risking a service disruption to all of their current ADSL users; but as of today the keep-alive is now 30s.  I personally think that that is a very open, honest, and reasonable decision in the circumstances. It appears you don't.   Perhaps you might feel differently if you were one of their ADSL users?

Since you can't remember it exactly, let me refresh your memory for you, a reference to 20s comes from SIN495 and was quoted by Kitz at reply#1 above. However, as I explained at reply#3, also above, SIN498 goes further, and consequently a suitable value for the PPP timeout would be less than the minimum resync time of the modem, quoted in that document as

anywhere between 10 and 60 seconds, with (only) typical values in the 20-30 second range

[Bald_Eagle1]

Any idea what the timeout is on BT Infinity connections?

A typical "Retrain Reason: 2" resync, using a HG612 on my connection takes 16 seconds:-

2013-8-17 16:32:1 Notice 104500 DSL activate succeed
2013-8-17 16:31:45 Notice 104500 DSL deactivate

That seems to be too quick to initiate a new PPP session & I almost always have to manually initiate a new PPP session via the ROUTER.

I have seen forum posts from numerous BT Infinity users stating they also have to force a new PPP session in order to get their IP Profile updated following one of these quick resyncs.

[Chrysalis]

On BT its high as well actually, the only time I have not had my profile update is due to my own deliberate extending the PPP timeout on my router.

On my router i set the timeout to 150s so if I do have an outage I keep my ip.

If BT were timing it out quickly then me extending the timeout on my router wouldnt work.

So thinking about the plusnet issue more I think their problem isnt so much to do with timeouts but more to do with that they only allow one session at a time per customer whilst I bet BT dont have that restriction.

eg. if you drop the ppp session deliberatly via a terminate then there should be no timeout to run down as its been terminated.

if it drops via loss of connection or maybe power cycling router, so not a clean terminate then the session will stay alive isp side until it times out but the router will initiate a new session.  If plusnet block the new session until the old one is timed out it indicates the problem is more to do with session limits.

The default ppp timeout on most routers is quite low, especially commercial based routers.  The LCP echo settings on my shibby firmware cant even be set to what plusnet have, its not allowed, the max is 60 secs for LCP echo intervals.  I set mine to 15 with 10 failures required for the ppp to drop router side.  I can do things like disconnect my modem, swap it with an eci modem, let the eci sync, recconect to router, and it keeps the same ppp session.  That means BT are not timing out my session quickly, so we have been off track.  However on the default router settings if I did that the ppp would be timed out and the router would instead be starting a new ppp session.  I expect BT allow new sessions to start before old expired hence us on BT dont have the same problem.

With that in mind tho plusnet supply static ip's and a static ip configuration may not allow ghost sessions as the same ip is bound to the session.

[ColinS]

Copy of an update by PN's Bob Pullen as to the the limitations imposed upon them in trying to comply with BT's SIN498 while using Juniper Edge Routers:

(The fact that they are unable to comply) Doesn't detract from the fact that the kit we're using (link follows) can't do that. (i.e. reduce it below 30s x 3 retries)

Options

seconds—Keepalive timeout period, in the range 30–64800 seconds for high-density mode, 1–64800 seconds for POS uplink interfaces in low-density mode, or 10–64800 seconds for all other HDLC interfaces in low-density mode; default value is 30 seconds

[kitz]

Thanks for the update Colin ^

With that in mind tho plusnet supply static ip's and a static ip configuration may not allow ghost sessions as the same ip is bound to the session.

Something just occurred to me, the very first day I got vdsl it seemed to take ages to authenticate on to PNs network, I remember moaning about it the very first night.  I now have a static IP and dont appear to have any issue at all.   In fact the opposite is true & I often re-sync so quick that neither PN RADIUS nor BTs WOOSH pick up that Ive lost sync.

[ColinS]

Me too, exactly.