"Cease and Reprovide"

[Graham J]

Please can somebody explain what a "Cease and Reprovide" actually does?

I've had an ISP explain that BT hve performed a "Cease and Reprovide"
simply in order to reset the BRAS profile following a period of poor
performance caused by a faulty router that has now been replaced.

TIA

-- Graham J

[Plusnet Support Team]

I suspect they'll have moved you to a different DSLAM/MSAN line
card/port at the exchange.

--
|Bob Pullen Broadband Solutions for
|Support Home & Business @
|Plusnet Plc. www.plus.net
+--------------- twitter.com/plusnet ----------------

[Graham J]

Plusnet Support Team wrote:
> On 21/05/2014 15:35, Graham J wrote:
>> Please can somebody explain what a "Cease and Reprovide" actually does?
>>
>> I've had an ISP explain that BT hve performed a "Cease and Reprovide"
>> simply in order to reset the BRAS profile following a period of poor
>> performance caused by a faulty router that has now been replaced.
>
> I suspect they'll have moved you to a different DSLAM/MSAN line
> card/port at the exchange.
>

Would that explain why there's now no ADSL signal whatever on the line?
Or would that failure be caused by incompetence somewhere?


--
Graham J

[Kraftee]

"Graham J" <graham@invalid> wrote in message
news:537cc112$0$1417$5b6a...@news.zen.co.uk...

It will be the way the cease and re-provide has been structured.

Best thing to do is contact your service provider as soon as possible just
to make sure that the provision hasn't been delayed (by anything up to 7
days).

[Graham J]

Openreach is sending out an engineer tomorrow afternoon, at ISP's request.

My suspicion is that the engineer will find that the exchange equipment
has not been configured correctly.

All my previous experience with a variety of ISPs is that the BRAS
profile reset can be achieved without a "Cease and Reprovide". However
the ISP has this from Openreach (and I quote):

"... the reason for the cease and re-provide was because when BT
performed a line test an authentication issue was identified, it was
escalated internally and BT then performed the cease and re-provide."

I think my suspicion of incompetence stands.

--
Graham J

[alexd]

Graham J (for it is he) wrote:

> "... the reason for the cease and re-provide was because when BT
> performed a line test an authentication issue was identified, it was
> escalated internally and BT then performed the cease and re-provide."
>
> I think my suspicion of incompetence stands.

I can think of an explanation for this - ordering the circuit with the wrong
realm on it [bit after the @ in the username]. Doesn't seem like the sort of
thing that would just 'happen' to an otherwise OK line, however.

--
<http://ale.cx/> (AIM:troffasky) (UnSoEs...@ale.cx)
21:15:05 up 139 days, 22:53, 9 users, load average: 0.60, 0.48, 0.46
"If being trapped in a tropical swamp with Anthony Worral-Thompson and
Christine Hamilton is reality then I say, pass the mind-altering drugs"
-- Humphrey Lyttleton

[fred]

In article <llj1i8$p02$2...@dont-email.me>, alexd <trof...@hotmail.com>
writes

>Graham J (for it is he) wrote:
>
>> "... the reason for the cease and re-provide was because when BT
>> performed a line test an authentication issue was identified, it was
>> escalated internally and BT then performed the cease and re-provide."
>>
>> I think my suspicion of incompetence stands.
>
>I can think of an explanation for this - ordering the circuit with the wrong
>realm on it [bit after the @ in the username]. Doesn't seem like the sort of
>thing that would just 'happen' to an otherwise OK line, however.
>

I have experienced a f'ckd up transfer in the past where 2 sets of ADSL
exchange equipment (1 BT & 1 LLU) ended up connected to my line, causing
'authentication' problems. Took an initially sceptical but dedicated
ADSL tech quite a while to trace and sort it.

I could see a physical cease and reprovide been a more official way to
try and get round a similar sort of problem.
--
fred
it's a ba-na-na . . . .

[Plusnet Support Team]

On 21/05/2014 21:16, alexd wrote:
> Graham J (for it is he) wrote:
>
>> "... the reason for the cease and re-provide was because when BT
>> performed a line test an authentication issue was identified, it was
>> escalated internally and BT then performed the cease and re-provide."
>>
>> I think my suspicion of incompetence stands.
>
> I can think of an explanation for this - ordering the circuit with the wrong
> realm on it [bit after the @ in the username]. Doesn't seem like the sort of
> thing that would just 'happen' to an otherwise OK line, however.

Ordering a circuit with the wrong realm should just require a modify
order to remedy, rather than a complete cease/reprovide.

The fact the OP has no sync is certainly indicative of a 'cease' though ;)

[Kraftee]

"Graham J" <graham@invalid> wrote in message

news:537cfb69$0$1426$5b6a...@news.zen.co.uk...

> Kraftee wrote:
>> "Graham J" <graham@invalid> wrote in message
>> news:537cc112$0$1417$5b6a...@news.zen.co.uk...
>>> Plusnet Support Team wrote:
>>>> On 21/05/2014 15:35, Graham J wrote:
>>>>> Please can somebody explain what a "Cease and Reprovide" actually
>>>>> does?
>>>>>
>>>>> I've had an ISP explain that BT hve performed a "Cease and Reprovide"
>>>>> simply in order to reset the BRAS profile following a period of poor
>>>>> performance caused by a faulty router that has now been replaced.
>>>>
>>>> I suspect they'll have moved you to a different DSLAM/MSAN line
>>>> card/port at the exchange.
>>>>
>>> Would that explain why there's now no ADSL signal whatever on the line?
>>> Or
>>> would that failure be caused by incompetence somewhere?
>>
>> It will be the way the cease and re-provide has been structured.
>>
>> Best thing to do is contact your service provider as soon as possible
>> just
>> to make sure that the provision hasn't been delayed (by anything up to 7
>> days).
>>
>>
> Openreach is sending out an engineer tomorrow afternoon, at ISP's request.
>
> My suspicion is that the engineer will find that the exchange equipment
> has not been configured correctly.

More likely not connected at all, as I've already stated it will all depend
on how the cease and reprovide has been actioned. To change exchange
equipment all you have to raise is a lift and shift, which can be arranged
by a engineer whilst on a fault.

>
> All my previous experience with a variety of ISPs is that the BRAS profile
> reset can be achieved without a "Cease and Reprovide". However the ISP
> has this from Openreach (and I quote):
>
> "... the reason for the cease and re-provide was because when BT performed
> a line test an authentication issue was identified, it was escalated
> internally and BT then performed the cease and re-provide."
>
> I think my suspicion of incompetence stands.

It's starting to become more and more probable

[Graham J]

Kraftee wrote:
> "Graham J" <graham@invalid> wrote in message
> news:537cfb69$0$1426$5b6a...@news.zen.co.uk...
>> Kraftee wrote:
>>> "Graham J" <graham@invalid> wrote in message
>>> news:537cc112$0$1417$5b6a...@news.zen.co.uk...
>>>> Plusnet Support Team wrote:
>>>>> On 21/05/2014 15:35, Graham J wrote:
>>>>>> Please can somebody explain what a "Cease and Reprovide" actually
>>>>>> does?
>>>>>>

>>>>>> I've had an ISP explain that BT have performed a "Cease and Reprovide"

BT engineer arrived, spent 20 minutes confirming that there really was
no ADSL signal.

Went to local green cabinet to check there, saying he would go to
exchange if nothing at cabinet.

2 hours later he returns! Says he could find no ADSL signal at the
exchange, so had to apply for a lift and shift. The cables he had to
disconnect were buried under other cables so clearly had not been moved
recently.

Connected his tester: FEC count in tens and rising, CRC count in single
figures.

Connected my router (Vigor 2800): up=800k down=4100k snr=6dB, loss=51dB
Uncorrected error count rising at tens per second.
Tried to measure download speed - too slow to get www.speedtest.net
Router then re-syncs, now up=800k down=4100k snr=8dB, loss=51dB
Uncorrected error count continues to rise.
Speed measurement: down about 400kbits/sec, up about 500kbits/sec
Engineer says ISP will have to reset the profile.

Connection drops several times.
Engineeer rings to arrange increase in SNR margin, first to 9dB then
12dB; and enable interleaving. Down sync speed reduces to 3500kbits sec
(and up reduces to about 650kbits/sec)

Speed test marginally better: down speed now about 500kbits/sec.

Router now shows corrected errors rising at tens per second, uncorrected
errors at one or two per second.

Previous experience with Vigor routers show that they don't tolerate
large numbers of corrected errors (they appear to lock up with the
processing overhead).

So replace with TP link TD-W8960N. Corrected errors continue rising at
tens per second, uncorrected errors at one or two per second; but I know
this router tolerates this level of errors.

BT Engineer connects his laptop, opens his VPN, and starts writing his
job report. As he finishes, he closes the job and arranges his next
call. At that point (this is after about 18 minutes connection) the
connection drops. We wait 2 minutes, no attempt by router to re-sync.
Engineer reconnects his tester; after about 3 minutes it starts to sync
then shows similar connection speed and error performance as before.
Because he has closed the job he cannot now stay to investigate the
cause of this failure; so I reconnect my TP-Link router and engineer leaves.

Engineer was very diligent, but his test equipment did not allow him to
find the cause of the noise. Also, I'm surprised that his training
appeared to suggest that he should ignore the quickly rising FEC count.

--
Graham J

[Plusnet Support Team]

On 22/05/2014 20:54, Graham J wrote:
> Engineer says ISP will have to reset the profile.

That's really not going to help.

[Kraftee]

"Plusnet Support Team" <sup...@plus.net> wrote in message
news:oLOdnffu-r5kxOLO...@brightview.co.uk...

> On 22/05/2014 20:54, Graham J wrote:
>> Engineer says ISP will have to reset the profile.
>
> That's really not going to help.

This appears to have been a screw up from the start with incorrect orders
being placed in the wrong order.

What should have been raised is a lift and shift type order, this can easily
be done by the man on the scene and indeed was done by the engineer who
visited to investigate the ongoing loss of service.

What was done was a cease and provide, which does exactly that. The first
ceases the service and then after X amount of days the service is provided
on new equipment, which can be just another port (hopefully) on the exchange
DSLAM but (when it goes completely wrong) can lead to brand new exchange
port, new DSLAM port and new network all the way from exchange to end user
( problem is that this could still happen at this late stage), effectively
cutting off the end user entirely. I do hope that it doesn't go this far
but......it has been known.

[Graham J]

Not sure you've followed this from the beginning ....

The initial problem I reported to the ISP was slow ADSL sync speed.
About 256kbits/sec downstream, with 29dB SNR margin; but upstream about
800kbits/sec. This was to be expected since there had been a faulty
router connnected, which I replaced.

ISP said BT would implement a "Cease and re-provide", which to me seemed
the wrong response. I thought a DSLAM reset would have been sufficient.

Apparently as a result of the "Cease and re-provide", the service failed
completely.

Engineer on site on Thursday afternoon confirmed no ADSL signal, and
spent 2 hours doing a lift & shift. Result, 3.6 Mbits/sec downstream
sync speed; upstream about 800kbits/sec.

However, BRAS profile (according to ISP) = adsl750 - consistent with
performance measured using www.speedtest.net. Complained yesterday to
ISP.

This morning, about 11am, speed test shows improvement to about 3.2
Mbits/sec.

Is this the fault of an incompetent ISP, or incompetence within BT?

--
Graham J

[Kraftee]

"Graham J" <graham@invalid> wrote in message

news:5380cc72$0$1465$5b6a...@news.zen.co.uk...

Now read what I posted and fill in the gaps.

Cease and Re-provide is a cease and then a provision order, not necessarily
at the same time (time delay can be 7 days or more)
Lift and Shift is literally a change from one DSLAM port to another,
hopefully (but not always) on another card.

[Graham J]

Kraftee wrote:
[snip]

>>
>> Is this the fault of an incompetent ISP, or incompetence within BT?
>>
>
> Now read what I posted and fill in the gaps.
>
> Cease and Re-provide is a cease and then a provision order, not necessarily
> at the same time (time delay can be 7 days or more)
> Lift and Shift is literally a change from one DSLAM port to another,
> hopefully (but not always) on another card.
>
>

So how is a Cease and Re-Provide the appropriate remedial action to
correct the slow ADSL sync speed?

--
Graham J

[Graham.]

The implication seems to be that a percentage of DSLAM ports are
faulty, and rather them fix them, they play musical chairs with the
subscribers (?)

--

Graham.

%Profound_observation%

[Graham J]

OK I see that a Lift and Shift does that.

But the Cease and Re-Provide would stil seem to be overkill - however in
this case the ISP reported having been told by BT: "when they performed

a line test an authentication issue was identified, it was escalated
internally and BT then performed the cease and re-provide".

Presumably the Cease and Re-Provide allows BT to re-enter the correct
username and password for the service ...?

--
Graham J

[Kraftee]

"Graham J" <graham@invalid> wrote in message

news:53827261$0$1465$5b6a...@news.zen.co.uk...

It isn't, a lift and shift will do the job in one go and can easily be done
on an engineering visit to investigate the end users problems. Cease and
Re-provide are 2 work orders, not one and as already stated if fumbled by
the call centre can lead to complete loss of all services for the end user.

Simples

[Kraftee]

"Graham J" <graham@invalid> wrote in message

news:5382ee98$0$1414$5b6a...@news.zen.co.uk...

That can still be done with a lift and shift. As you have stated a Cease
and Re-Provide is complete overkill.

[Kraftee]

"Graham." <m...@privicy.net> wrote in message
news:qos4o9p1vcspb5pvs...@4ax.com...

Yes it has been known to be done by various 'service providers', especially
if they can't be bothered to send in their own engineers to see what is
wrong with their kit.

[George Weston]

It would be nice to know which ISP is involved in this problem...

[Kraftee]

"George Weston" <geow...@NOSPAMgmail.com> wrote in message
news:bugvkm...@mid.individual.net...

It's not so much the ISP, it's the call centre person who causes the
problem. It's when they can't be bothered to deal with the actual problem
when they start raising the wrong type of orders and then start the 'running
around in circles'.

I've got a contact on another group where they've been lead down that path
for the last 6 months. For some reason he won't move to another and has
just resigned himself to a virtually non usable service for around 8 hours
each day, after which they are required to do a restart to get a 'reasonably
more stable' circuit for the other 16 hours.

I've known of many many more instances.

[Graham J]

George Weston wrote:
[ snip]

>>
>>
> It would be nice to know which ISP is involved in this problem...
>

http://www.intouchsystems.co.uk/

--
Graham J

[bert]

In message <5382ee98$0$1414$5b6a...@news.zen.co.uk>, Graham J
<graham@invalid.?.invalid> writes

Maybe it also restarts the clock so you can't complain to Ofcom because
it's a new service.
--
bert