Cool Ideas Fibre ISP – Feedback Thread 4

[ripclaw]

Who is the FNO (fibre network operator)?

Vumatel Villages, formerly SADV.

 

[S.Claus]

Vumatel Villages, formerly SADV.

Log it with Cool Ideas or you could ping @PBCool and @TheRoDent for some assistance.

 

[zolly]

And it's back.

 

[zolly]

Also, have connected with someone who's connection is dying at the exact same time as mine on the Facebook group. I HATE it when providers go "Oh there's no problem". I'm not asking you if there's a problem, I'm telling you there's one!

I had the same issue with Telkom which I had to escalate all the way up to one of their highest techies years ago. I had to gather data and submit and submit and submit for three months before he eventually identified the issue!

 

[leppie]

I have done yet another complete reboot of all my internet hardware. Will report back, as I did this last week and it didn't fix anything then either.

Edit. Got a call from Buhle. Gave him all the info my side, but for now things seem to be looking better (guessing/hoping the maintenance last night may have fixed things and I needed to refresh my connection).

I give up too.

Been logging every disconnect on my ticket now. Octotel has actually called me, but I am not sure I have convinced them to look into the possibility that it is human error (because at this point nothing else makes sense anymore).

#COOL-20210827-757633

And the latest feedback from CI, they ask me to flash my own router with the TP-LINK C20 firmware...

 

[zolly]

I give up too.

Been logging every disconnect on my ticket now. Octotel has actually called me, but I am not sure I have convinced them to look into the possibility that it is human error (because at this point nothing else makes sense anymore).

#COOL-20210827-757633

And the latest feedback from CI, they ask me to flash my own router with the TP-LINK C20 firmware...

If you are in the Claremont/Kenilworth area and are experiencing a timeout issue, please join the Facebook Group and see if it lines up with the issue me and another person are having in the top most post regarding the Rondebosch node. If it is please join the discussion and reply to the rep there. We need more people to highlight this issue outside of this space.

Octotel- Southern Fibre | Facebook

Cape Town's Largest Independent Open Access Fibre Network.

www.facebook.com

 

[leppie]

If you are in the Claremont/Kenilworth area and are experiencing a timeout issue, please join the Facebook Group and see if it lines up with the issue me and another person are having in the top most post regarding the Rondebosch node. If it is please join the discussion and reply to the rep there. We need more people to highlight this issue outside of this space.

Octotel- Southern Fibre | Facebook

Cape Town's Largest Independent Open Access Fibre Network.

www.facebook.com

Nope, Cape Gate. Also not on FB.

But I do get SMS's to say they doing maintenance in Rondebosch and Rondebosch alone. But funny enough, I expect the connection to timeout then too. Does not matter where they do maintenance, everyone drops. It is like they turning off/on some global switch for a second of 2 every time.

When they do a 'port reset' like they did on Friday to me, I actually get a graceful disconnect and my router does not wait 15 minutes for a timeout to expire, because it actually knows it is disconnected.

 

[zolly]

But I do get SMS's to say they doing maintenance in Rondebosch and Rondebosch alone.

This maintenance is happening between 1 am and 5 am as far as I know. But ya, I've had this problem for a couple of weeks now and its just been getting worse, regardless of the maintenance. Hopefully they will fix something tonight...

 

[leppie]

This maintenance is happening between 1 am and 5 am as far as I know. But ya, I've had this problem for a couple of weeks now and its just been getting worse, regardless of the maintenance. Hopefully they will fix something tonight...

Someone should setup a Google sheet that everyone can use to enter roughly when they had disconnects. That way we could see if it mass timeouts/disconnects (like I suspect) or not.

 

[leppie]

Someone should setup a Google sheet that everyone can use to enter roughly when they had disconnects. That way we could see if it mass timeouts/disconnects (like I suspect) or not.

Or I could just setup a simple website for it. Would people on that group be interested? It would simply ask for the time of disconnect and the area.

 

[zolly]

Or I could just setup a simple website for it. Would people on that group be interested? It would simply ask for the time of disconnect and the area.

I've only found one other person who has identified the issue. Thing is only gamers will notice it because it causes disruption for about 3-4 seconds. If you don't play games and are just a regular user, only way you'll pick it up is if it's boning your zoom calls.

 

[TheRoDent]

Sigh, I'm reticent to do it, but I can probably pickup the spate of disconnections from our Pppoe servers for each Octotel VLAN and anon the data.

 

[Cage Rattler]

I've only found one other person who has identified the issue. Thing is only gamers will notice it because it causes disruption for about 3-4 seconds. If you don't play games and are just a regular user, only way you'll pick it up is if it's boning your zoom calls.

Or Teams, VPNs to corporate networks, neighbour who was streaming tv, etc. Pretty irritating.

 

[zolly]

Sigh, I'm reticent to do it, but I can probably pickup the spate of disconnections from our Pppoe servers for each Octotel VLAN and anon the data.

So if the timeout is enough to trigger a registerable drop (I don't think it is, at least for my connection), then maybe this isn't a bad idea, but otherwise I think hold off for now. Touch wood but things seem to have stabilised, and me and one other forum member were complaining hard to the Octotel rep on Facebook. I mean, our problems were literally in sync with each other, with our connections timing out at the same time. Even someone who doesn't know squat about networking could go "ya, it's probably connected hey".

 

[leppie]

So if the timeout is enough to trigger a registerable drop (I don't think it is, at least for my connection), then maybe this isn't a bad idea, but otherwise I think hold off for now. Touch wood but things seem to have stabilised, and me and one other forum member were complaining hard to the Octotel rep on Facebook. I mean, our problems were literally in sync with each other, with our connections timing out at the same time. Even someone who doesn't know squat about networking could go "ya, it's probably connected hey".

In my case, the connection becomes a zombie. I have to reconnect (PPPoE) or my router will do so after 15 minutes. And I pretty much always get a new IP every time. Maybe some routers are much faster to timeout and reconnect, but a couple of seconds sounds a bit quick.

Is it an actual disconnect in your case, or just just dead traffic for a couple of seconds? Does your router log a new PPPoE connection? I would suspect game servers to knock you out if you had a new IP.

Edit: The whole disconnect is not really an issue for me. It is the fact that I get a new IP. This means going thru 2FA for cloud services and registering my new IP on multiple servers' firewalls. This takes a good 15-20 minutes (I should probably find out if I can script this). I have had these disconnects in the middle of production deployments. This is not good for my heart.

 

[zolly]

In my case, the connection becomes a zombie. I have to reconnect (PPPoE) or my router will do so after 15 minutes. And I pretty much always get a new IP every time. Maybe some routers are much faster to timeout and reconnect, but a couple of seconds sounds a bit quick.

Is it an actual disconnect in your case, or just just dead traffic for a couple of seconds? Does your router log a new PPPoE connection? I would suspect game servers to knock you out if you had a new IP.

Edit: The whole disconnect is not really an issue for me. It is the fact that I get a new IP. This means going thru 2FA for cloud services and registering my new IP on multiple servers' firewalls. This takes a good 15-20 minutes (I should probably find out if I can script this). I have had these disconnects in the middle of production deployments. This is not good for my heart.

For me it's just a lengthy timeout. 3-4 seconds of no traffic. Your issue definitely sounds like a different kettle of fish.

 

[TheRoDent]

So if the timeout is enough to trigger a registerable drop (I don't think it is, at least for my connection), then maybe this isn't a bad idea, but otherwise I think hold off for now. Touch wood but things seem to have stabilised, and me and one other forum member were complaining hard to the Octotel rep on Facebook. I mean, our problems were literally in sync with each other, with our connections timing out at the same time. Even someone who doesn't know squat about networking could go "ya, it's probably connected hey".

PPPoE is a very stateful protocol.

If 3 LCP echo messages are missed within 90 seconds then, the NAS and/or the CPE will consider the connection as dead. Which is correct.

I'm tempted to deploy straight forward DHCP on our Octotel VLANS (which will have internet access, but behind CGNAT).

That way some of our more advanced users can setup a DHCP and a PPPoE connection and monitor pings via the Octotel DHCP connection if they are capable. Or just choose to use DHCP, or PPPoE.

It would basically require two routers plugged into the ONT, or some further cleverness, or a specific choice between protocols.

I'm pretty sure that the pings over PPPoE and DHCP will show the same amount of outages with PPPoE possibly showing a longer outage due to the time to re-establish a connection (purely due to Octotel flakiness).

But outage-time-line wise, I feel we'll see the same....

Octotel have been blaming this on our NAS's and because we're using PPPoE. Yet the same NAS'es offer services to at least 20 other FNO's on the same pool of NAS'es without issues.

Clarification:
NAS = the PPPoE server you see from your Octotel ONT, which is the server that CISP uses to terminate your PPPoE session.
FNO = Fibre Network Operator


So perhaps it's time to just got pure IP over Ethernet and prove them wrong.

An IPoE (IP over Ethernet/DHCP) disconnection will just result in packet loss obviously, so it might be less "sensitive" to the end user. But the packet loss would still be an issue, and the disconnect would still exist, just not on a PPPoE level. So not a "hard disconnect", but for the period that Octotel's network is dead, you would still have 100% packet loss.

Basically allow Octotel users to connect using DHCP (behind CGNAT) or PPPoE.

Votes to implement ? Volunteers ?

 

[zolly]

PPPoE is a very stateful protocol.

If 3 LCP echo messages are missed within 90 seconds then, the NAS and/or the CPE will consider the connection as dead. Which is correct.

I'm tempted to deploy straight forward DHCP on our Octotel VLANS (which will have internet access, but behind CGNAT).

That way some of our more advanced users can setup a DHCP and a PPPoE connection and monitor pings via the Octotel DHCP connection if they are capable.

It would basically require two routers plugged into the ONT, or some further cleverness...

I'm pretty sure that the pings over PPPoE and DHCP will show the same amount of outages with PPPoE possibly showing a longer outage due to the time to re-establish a connection. But outage-time-line wise, I feel we'll see the same....

Octotel have been blaming this on our NAS's and because we're using PPPoE. Yet the same NAS'es offer services to at least 20 other FNO's on the same pool of NAS'es without issues.

Clarification:
NAS = the PPPoE server you see from your Octotel ONT, which is the server that CISP uses to terminate your PPPoE session.
FNO = Fibre Network Operator


So perhaps it's time to just got pure IP over Ethernet and prove them wrong.

An IPoE (IP over Ethernet) disconnection will just result in packet loss obviously, so it might be less "sensitive" to the end user. But the packet loss would still be an issue, and the disconnect would still exist, just not on a PPPoE level. So not a "hard disconnect".

Votes to implement ? Volunteers ?

I just want to be able to play games without flipping a coin and asking myself "Will my connection be stable enough to play?"

If this can help us get to that point, and the people in this house can still carry on with their work during the day (including myself), I am happy to help in any way I can.

 

[eddief1]

Octotel have been blaming this on our NAS's and because we're using PPPoE. Yet the same NAS'es offer services to at least 20 other FNO's on the same pool of NAS'es without issues.

What a load of BS from Octotel, cant believe they even said that.

 

[Tinuva]

PPPoE is a very stateful protocol.

If 3 LCP echo messages are missed within 90 seconds then, the NAS and/or the CPE will consider the connection as dead. Which is correct.

I'm tempted to deploy straight forward DHCP on our Octotel VLANS (which will have internet access, but behind CGNAT).

That way some of our more advanced users can setup a DHCP and a PPPoE connection and monitor pings via the Octotel DHCP connection if they are capable. Or just choose to use DHCP, or PPPoE.

It would basically require two routers plugged into the ONT, or some further cleverness, or a specific choice between protocols.

I'm pretty sure that the pings over PPPoE and DHCP will show the same amount of outages with PPPoE possibly showing a longer outage due to the time to re-establish a connection (purely due to Octotel flakiness).

But outage-time-line wise, I feel we'll see the same....

Octotel have been blaming this on our NAS's and because we're using PPPoE. Yet the same NAS'es offer services to at least 20 other FNO's on the same pool of NAS'es without issues.

Clarification:
NAS = the PPPoE server you see from your Octotel ONT, which is the server that CISP uses to terminate your PPPoE session.
FNO = Fibre Network Operator


So perhaps it's time to just got pure IP over Ethernet and prove them wrong.

An IPoE (IP over Ethernet/DHCP) disconnection will just result in packet loss obviously, so it might be less "sensitive" to the end user. But the packet loss would still be an issue, and the disconnect would still exist, just not on a PPPoE level. So not a "hard disconnect", but for the period that Octotel's network is dead, you would still have 100% packet loss.

Basically allow Octotel users to connect using DHCP (behind CGNAT) or PPPoE.

Votes to implement ? Volunteers ?

Not on Octotel myself, but I will vote to get it set up if you have the time to do so. It doesn't sound like a complete win but if it reduce complaints just by 10% it kinda is a win for you, and hopefully allow more time to twist Ocotel's arm further to get their behind in gear and look at the actual problem.