Spark UFB with Chorus: a gotcha when moving from another ISP. And Orbi.

Forums › Spark New Zealand (including Skinny and BigPipe) › Spark UFB with Chorus: a gotcha when moving from another ISP. And Orbi.

getontoit99

85 posts

Master Geek
+1 received by user: 28

Lifetime subscriber

#319574 9-May-2025 10:50

Helping friends who had decided to change their provider from Nova to Spark.

Nova wanted their Nokia Beacon wifi router and satellite back so on my advice, a Netgear Orbi router and satellite were purchased. These were installed and immediately worked on the Nova service.

On the change day, the Internet service stopped working. The Spark shop assured us that everything was set up and it should "just work".

It was a few days later in a video call with Spark support, that I learnt that the LAN cable to the ONT had to be moved from port GE1 to port GE2, to make the Spark service work. How nuts is that?! My older friends had been pulling plugs and moving cables, only making things worse. They didn't know about the ONT which was in a basement storage area and somewhat hidden.

I wonder who the bright spark was (sorry) who came up with requiring the change of ONT port? Some historical artifact from the early days of UFB, I guess.

Something else...

The lady at the Spark shop that the Orbi router would not work on its own and required the use of another router, preferably one supplied by Spark, to connect to the ONT.

This was technically correct if the Orbi had been installed using only the Orbi phone app. The app doesn't provide a way to set up the PPPoE, username/password, VLAN 10, etc., in the Orbi router. These non-default settings are required for Spark and maybe Skinny, but not by many/most other ISPs who use IPoE.

Using a browser to the Orbi router (an RBR350), the settings could be changed for PPPoE and the Spark service started working!

Hopefully, someone out there finds this info useful and avoids wasting lots of time.

trig42

5889 posts

Uber Geek
+1 received by user: 2094

ID Verified

#3371656 9-May-2025 10:56

The change of port is a newish thing, and IMO it's great.

Previously, you had to wait for the losing service provider (in this case Nova) to disconnect their service so the port was open, then the Gaining provider to activate on that port. This would mean you lost service for the time the port was being changed over. Could be quick, could take hours, maybe more if someone or something got confused along the way. But, you, as the customer, had to basically time everything right with giving notice to the losing ISP and ensuring the gaining connected after the losing disconnected.

These days, they just activate another port.

The failure here was that apparently they didn't communicate that the service was being activated on port2 of the ONT (or maybe they did and it got 'lost in translation').

wellygary

8810 posts

Uber Geek
+1 received by user: 5287

#3371657 9-May-2025 10:57

I wonder who the bright spark was (sorry) who came up with requiring the change of ONT port? Some historical artifact from the early days of UFB, I guess.

NO, this is the best way to do it, It means the customer should be able to have an uninterrupted service,,

The old ISP remains on port 1 until they terminate their service, while the new one can provision separately on port 2

When they new service is ready all the customer does is change the cord and they are up and running...

In the "old days" of switching phone companies, you often had gaps of service as you could not load the new service on while an old provider remained connected.

freitasm

BDFL - Memuneh
80647 posts

Uber Geek
+1 received by user: 41030

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#3371663 9-May-2025 11:18

wellygary:

NO, this is the best way to do it, It means the customer should be able to have an uninterrupted service,,

The old ISP remains on port 1 until they terminate their service, while the new one can provision separately on port 2

When they new service is ready all the customer does is change the cord and they are up and running...

In the "old days" of switching phone companies, you often had gaps of service as you could not load the new service on while an old provider remained connected.

I disagree.

When I moved from ISP A to ISP B the downtime was seconds. No need to change cables or anything. I think forcing clients to physically move a cable is not helpful and can lead to very long waits if the customer is not at the premises to do it, or if it's not communicated, like in this case.

Referral links: Quic Broadband (free setup code: R587125ERQ6VE) | Samsung | AliExpress | Wise | Sharesies

Support Geekzone by subscribing (browse ads-free), or making a one-off or recurring donation through PressPatron.

nztim

4012 posts

Uber Geek
+1 received by user: 2710

ID Verified

Trusted

TEAMnetwork

Subscriber

#3371670 9-May-2025 11:36

There are two ways to do this now with pros/cons of each

If the RSP(s) you are moving from/to have the same settings (VLAN on/off and PPPoE/DHCP) then it makes sense to Churn (to do this you MUST have the Gaining RSP place a service order prior cancelling the losing service provider, this can be scheduled in 30 minute windows
If the RSP(s) you are moving from/to have the different settings (VLAN on/off and PPPoE/DHCP) then it makes sense to do a Port 2 activation, say a day or so in advance allowing you to adjust your settings and plug into Port2

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

freitasm

BDFL - Memuneh
80647 posts

Uber Geek
+1 received by user: 41030

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#3371672 9-May-2025 11:40

That's why I like Quic (aff link). I just checked the boxes in the sign up form "Keep VLAN, use DHCP"¹.

30 seconds drop. Back online. You can use the combination that suits your needs for least downtime.

But back to OP, Spark loses points here for this.

Referral links: Quic Broadband (free setup code: R587125ERQ6VE) | Samsung | AliExpress | Wise | Sharesies

Support Geekzone by subscribing (browse ads-free), or making a one-off or recurring donation through PressPatron.

nztim

4012 posts

Uber Geek
+1 received by user: 2710

ID Verified

Trusted

TEAMnetwork

Subscriber

#3371730 9-May-2025 12:45

freitasm:

But back to OP, Spark loses points here for this.

We don't know if the OP Cancelled his order with his current RSP therefore locking an inflight order on the ONT port prior to signing up with Spark

In any case spark should have told them in advance what was going to happen

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

Lenovo

Shop now for Lenovo laptops and other devices (affiliate link).

saf

221 posts

Master Geek
+1 received by user: 533

ID Verified

Trusted

Vetta Group

Subscriber

#3371731 9-May-2025 12:50

nztim:

We don't know if the OP Cancelled his order with his current RSP therefore locking an inflight order on the ONT port prior to signing up with Spark

Bang on, this is my guess too.

Spark usually will do a churn for residential connections for simplicity, so I suspect @nztim is probably correct that there was an open SO on Port 1, therefore Spark couldn't touch the service until the SO is completed, meaning activating port 2 was the best option for the minimal amount of downtime.

Either way, should have stated what port to connect on.

My views are as unique as a unicorn riding a unicycle. They do not reflect the opinions of my employer, my cat, or the sentient coffee machine in the break room.

freitasm

BDFL - Memuneh
80647 posts

Uber Geek
+1 received by user: 41030

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#3371732 9-May-2025 12:58

saf:

nztim:

We don't know if the OP Cancelled his order with his current RSP therefore locking an inflight order on the ONT port prior to signing up with Spark

Bang on, this is my guess too.

Spark usually will do a churn for residential connections for simplicity, so I suspect @nztim is probably correct that there was an open SO on Port 1, therefore Spark couldn't touch the service until the SO is completed, meaning activating port 2 was the best option for the minimal amount of downtime.

Either way, should have stated what port to connect on.

It's all well and good. But the customer, the "person on the street" has no knowledge of how this works. So Spark should have told the OP exactly what to expect.

The fact the "lady at the Spark shop [said] that the Orbi router would not work on its own and required the use of another router, preferably one supplied by Spark, to connect to the ONT." is even more infuriating. It could have led the OP down an expensive path of replacing hardware without needing to do it.

Ultimately Spark is still at fault for providing crap or no advice.

Referral links: Quic Broadband (free setup code: R587125ERQ6VE) | Samsung | AliExpress | Wise | Sharesies

Support Geekzone by subscribing (browse ads-free), or making a one-off or recurring donation through PressPatron.

Asteros

363 posts

Ultimate Geek
+1 received by user: 189

#3371735 9-May-2025 13:12

I agree that Spark is at fault here. However this is the sort of problem that I have experienced with all three telcos recently. I think it comes to down to a lack of training for the customer facing teams as well as a desire to minimise staffing costs. The in store staff mean well but often promise things that they cannot willingly deliver just because it is faster for them to move onto the next customer than resolving the situation correctly.

Wheelbarrow01

1784 posts

Uber Geek
+1 received by user: 2638

Trusted

Chorus

#3371906 9-May-2025 21:32

There definitely seems to have been a miscommunication here - the OP thought they were to receive a transfer of the existing service on port 1 from one RSP to another, whereas Spark has simply activated an additional service on Port 2.

As another commentor has mentioned, this may be because Nova had already placed a terminate order against their service, essentially blocking a transfer order from being raised by Spark.

I suspect (but not 100% sure offhand - @cbrpilot can probably confirm) that's Spark's automation is clever enough to pick this up, realise the terminate order could delay Spark's connection, and revert to a port 2 activation automatically to ensure the Spark service is activated on the correct date. Either way, the confirmation email and/or txt message from Spark would have stated which port the router should be connected to.

My only question now is "Did Nova actually terminate their service on port 1?" Or is the OP's friend now being billed for 2 separate services? Given the Nova service stopped working I would assume they did terminate, but it may be worth checking in with Nova to ensure the account has been closed.

The views expressed by me are not necessarily those of my employer Chorus NZ Ltd