Plusnet - New Network

[#1]

I THINK I've been switched over today - only thing thats immediately apparent is that the SNRM appears to have defaulted back to 6 -I've been running literally for years with an SNRM of ~3 -this has resulted in the "loss" of ~ 1.8Mbps in synch speed and  ~ 1.5Mbps in download speeds.
I PRESUME that, provided the line is stable at an SNRM of 6, then within a week or two I will be able to reconnect at a higher synch speed again

[#2]

Being switched to the new network has nothing to do with the sync - I suspect the DLM has intervened on your line.

[#3]

Quote from: davidj60

I THINK I've been switched over today - only thing thats immediately apparent is that the SNRM appears to have defaulted back to 6 -I've been running literally for years with an SNRM of ~3 -

The switch over can trigger a DLM reset, as most lines have never had a DLM change and are sat on 6dB fast this isn't a problem for most. We are working on a process to put the DLM settings back to where they were when they do which should've applied on your line already.

[#4]

Thanks very much Dave -I've actually had a resynch @ 9:40 -and I've got more than the "lost" speed back - 

[#5]

That is an interesting revelation.  Why does a change of PPP / IP routing across the core network bring about (a) a loss of synch and (b) a change in line configuration?  Changing how the account / domain authentication and routing is managed ought to have no impact on the last mile connectivity, surely it should just be a drop and reconnect on the PPP session?
Whatelse is "in play" here?
Had better get RS running again...

[#6]

It is the changeover "process", it has nothing to do with the PPP session/routing per se. Dave's words were -

Quote from: dave

The switch over can trigger a DLM reset

It's the DLM reset that will cause the loss of sync

[#7]

The change of network is issued by a change order into our suppliers rather than just a RADIUS or routing change. You may remember a while back a few people posting saying they had received an SMS by mistake saying their order had completed, the order that was referring to was the change order. The type of order that's being processed for ADSL2+ at can cause a DLM reset, it doesn't on fibre. If there's no DLM change then there's only a drop of PPP which happens for all fibre and most ADSL2+ orders, the DLM will be the cause of the resync.

[#8]

Does this 'change' cause reset to default for things such as maximum additional bandwidth spend (where applicable to legacy products), firewall status etc.?

[#9]

Assuming my PPP drop at 3am this morning was me being moved to the new network, I can confirm that my static IP block has remained with me, my firewall hasn't been reset, I've not been dumped on 40/2 from 40/10.

[#10]

Any difference to any traceroute's (noting previous comment from Plusnet)?

[#11]

It wasn't the 3am drop but the one at 12.30pm (45 minutes ago) according to my closed tickets.
Need to recheck my previous statement about the firewall... Firewall still off.
No noticable change to my traceroutes, but I'm on a static IP so I'll be seeing them go through BNGs anway.

traceroute to www.bbc.net.uk (212.58.246.94), 64 hops max, 48 byte packets
 1  thundertank (10.0.1.254)  0.515 ms  0.331 ms  0.245 ms
 2  lo0.13.central13.pcl-bng01.plus.net (195.166.130.141)  13.104 ms  13.206 ms  13.983 ms
 3  irb.13.pcl-cr02.plus.net (84.93.249.130)  13.480 ms  13.709 ms  13.488 ms
 4  ae2.pcl-cr01.plus.net (195.166.129.6)  14.103 ms  13.446 ms  13.232 ms
 5  ae1.ptw-cr01.plus.net (195.166.129.0)  13.491 ms  13.580 ms  14.485 ms
 6  kingston-gw.thdo.bbc.co.uk (212.58.239.6)  14.480 ms  13.919 ms  14.239 ms
 7  * * *
 8  ae0.er01.cwwtf.bbc.co.uk (132.185.254.93)  16.366 ms  14.934 ms  14.970 ms
 9  132.185.255.165 (132.185.255.165)  15.496 ms  15.538 ms  14.975 ms
10  bbc-vip015.cwwtf.bbc.co.uk (212.58.246.94)  14.725 ms  14.937 ms  14.730 ms

traceroute to www.google.com (74.125.206.106), 64 hops max, 48 byte packets
 1  thundertank (10.0.1.254)  0.501 ms  0.326 ms  0.367 ms
 2  lo0.13.central13.pcl-bng01.plus.net (195.166.130.141)  13.231 ms  13.957 ms  13.735 ms
 3  irb.13.pcl-cr01.plus.net (84.93.249.129)  13.232 ms  13.459 ms  13.734 ms
 4  ae1.ptw-cr01.plus.net (195.166.129.0)  13.731 ms  13.590 ms  56.080 ms
 5  72.14.222.97 (72.14.222.97)  13.979 ms  13.583 ms  13.606 ms
 6  209.85.246.242 (209.85.246.242)  13.604 ms  13.705 ms  13.735 ms
 7  209.85.143.67 (209.85.143.67)  14.231 ms  14.821 ms  14.356 ms
 8  216.239.41.236 (216.239.41.236)  19.853 ms  20.080 ms  22.725 ms
 9  216.239.51.207 (216.239.51.207)  20.230 ms  19.702 ms  19.229 ms
10  * * *
11  wk-in-f106.1e100.net (74.125.206.106)  19.613 ms  19.553 ms  20.480 ms

[#12]

Quote from: w23

Does this 'change' cause reset to default for things such as maximum additional bandwidth spend (where applicable to legacy products), firewall status etc.?

It doesn't change anything else, firewall, usage, static IP, product all stay the same and people who are going through a change such as product change or upgrade to fibre or who have reported a fault will have that take priority over the network change and we'll pick them up later on.

[#13]

Dave, thanks for the detail and update that you and Paul have provided, much appreciated.

[#14]

And when do we get the cuddly Toy ?

[#15]

When the fat lady sings.
But seriously, the roll out is slow, but the change will come.