Cool Ideas Fibre ISP – Feedback Thread 6

Last edited:
CoolEscalator said:
HI there, would love to hear your thoughts..
What are your concerns in this regard?
Click to expand...
Less information is always bad. Whenever there is a hop that isn't replying to ICMP echo it makes troubleshooting harder. This is particularly true when dealing with inexperienced first line people. Especially when the first hop may give you some information about which POP or Access Concentrator or Aggregate Node you are connected to. And I know you guys will "know" all that but I refer to my first point when dealing with junior frontline, I just follow the checklist and do it by the book agents. You can no longer say well the packet loss started when hop 1 is XXX IP address but when its YYY its fine. And on a purely aesthetic level it slows down traceroutes while the device testing internally times out, every, single time.

And I include intermediary hops that restrict ICMP echo too - any loss of information makes troubleshooting harder. Would love to hear the good reason this was done. If the argument is "well when the CPU gets busy it drops ICMP packets and people get confused and claim the line is a problem" well what about all the other hops inbetween that suffer from the same problem? I assume u have a cut and paste answer of - packet loss is only relevant on a MTR if there is loss on the last hop too or something similar, to which you will now need to add - no don't worry total loss on the first hop is totes normal (but my friend ran his and it respond etc).
 
midasza said:
Less information is always bad. Whenever there is a hop that isn't replying to ICMP echo it makes troubleshooting harder. This is particularly true when dealing with inexperienced first line people. Especially when the first hop may give you some information about which POP or Access Concentrator or Aggregate Node you are connected to. And I know you guys will "know" all that but I refer to my first point when dealing with junior frontline, I just follow the checklist and do it by the book agents. You can no longer say well the packet loss started when hop 1 is XXX IP address but when its YYY its fine. And on a purely aesthetic level it slows down traceroutes while the device testing internally times out, every, single time.

And I include intermediary hops that restrict ICMP echo too - any loss of information makes troubleshooting harder. Would love to hear the good reason this was done. If the argument is "well when the CPU gets busy it drops ICMP packets and people get confused and claim the line is a problem" well what about all the other hops inbetween that suffer from the same problem? I assume u have a cut and paste answer of - packet loss is only relevant on a MTR if there is loss on the last hop too or something similar, to which you will now need to add - no don't worry total loss on the first hop is totes normal (but my friend ran his and it respond etc).
Click to expand...
Just calm down
 
midasza said:
Less information is always bad. Whenever there is a hop that isn't replying to ICMP echo it makes troubleshooting harder. This is particularly true when dealing with inexperienced first line people. Especially when the first hop may give you some information about which POP or Access Concentrator or Aggregate Node you are connected to. And I know you guys will "know" all that but I refer to my first point when dealing with junior frontline, I just follow the checklist and do it by the book agents. You can no longer say well the packet loss started when hop 1 is XXX IP address but when its YYY its fine. And on a purely aesthetic level it slows down traceroutes while the device testing internally times out, every, single time.

And I include intermediary hops that restrict ICMP echo too - any loss of information makes troubleshooting harder. Would love to hear the good reason this was done. If the argument is "well when the CPU gets busy it drops ICMP packets and people get confused and claim the line is a problem" well what about all the other hops inbetween that suffer from the same problem? I assume u have a cut and paste answer of - packet loss is only relevant on a MTR if there is loss on the last hop too or something similar, to which you will now need to add - no don't worry total loss on the first hop is totes normal (but my friend ran his and it respond etc).
Click to expand...
Thank you for your detailed response.

The main reasons I believe our network team has done this, is for Security reasons, and CPU load due to ICMP.
I will have to confirm with them on the exact reasonings, however this is likely the case.
I do agree that the less information is not ideal, however if you have a problem, our team has the access to determine if hop 2 is actually an issue on not, as we have the ability to trace from that hop back to you, to see if there is any loss over the last mile..

If you do an MTR , packet loss will now only show from Hop3, instead of hop 2, and again, we have tools to verify if its from layer 2, or from any other layer 3 hops.
You are also easily able to see what Access Router you are connected to, by looking at your router interface, it should display the IP there, and can be used for reference if you only experience an issue going via that Router.

Personally, I also would prefer ICMP being enabled, however this was the design. I'll be happy to request more information from the team to get clarity on the reasonings, but for now, I don't believe it would impact troubleshooting as much, as this has been implented for months already in JHB, and for years on Vumatel Trench. WC and EC is only the latest region we have installed the new equipment.

Your concerns are valid, and we are always happy to improve where we can.
Thank you again for the details :)
 
CoolEscalator said:
Thank you for your detailed response.

The main reasons I believe our network team has done this, is for Security reasons, and CPU load due to ICMP.
I will have to confirm with them on the exact reasonings, however this is likely the case.
I do agree that the less information is not ideal, however if you have a problem, our team has the access to determine if hop 2 is actually an issue on not, as we have the ability to trace from that hop back to you, to see if there is any loss over the last mile..

If you do an MTR , packet loss will now only show from Hop3, instead of hop 2, and again, we have tools to verify if its from layer 2, or from any other layer 3 hops.
You are also easily able to see what Access Router you are connected to, by looking at your router interface, it should display the IP there, and can be used for reference if you only experience an issue going via that Router.

Personally, I also would prefer ICMP being enabled, however this was the design. I'll be happy to request more information from the team to get clarity on the reasonings, but for now, I don't believe it would impact troubleshooting as much, as this has been implented for months already in JHB, and for years on Vumatel Trench. WC and EC is only the latest region we have installed the new equipment.

Your concerns are valid, and we are always happy to improve where we can.
Thank you again for the details :)
Click to expand...
Hi there @midasza @kyton @Jason-ZA
The team has made the changes to allow ICMP now, please let me know if all is in order?
 
@PBCool I am guessing the Microsoft cache you guys deployed is going to be quite busy tonight, looks like there are new windows updates, and general updates to microsoft products like Visual Studio, etc.

Every 2nd Tuesday of the month is "patch day" for Microsoft.
 
Last edited:
Jason-ZA said:
@PBCool I am guessing the Microsoft cache you guys deployed is going to be quite busy tonight, looks like there are new windows updates, and general updates to microsoft products like Visual Studio, etc.

Every 2nd Tuesday of the month is "patch day" for Microsoft.
Click to expand...
Yeah I believe so, will check stats on it.

Looks like we've managed to qualify for a valve cache as well finally.
 
Hi @CoolEscalator

Please could you kindly take a look at the sixty60 app it doesn't want to load over IPv6 so the app just hangs

This seems to be for auth.sixty60.co.za

hk7nCbP9gn.png


IPV4 is ok

vEq8iMW4VX.png


WARP

4hTiJNrXgG.png
 
adam_g said:
Hi @CoolEscalator

Please could you kindly take a look at the sixty60 app it doesn't want to load over IPv6 so the app just hangs

This seems to be for auth.sixty60.co.za

hk7nCbP9gn.png


IPV4 is ok

vEq8iMW4VX.png


WARP

4hTiJNrXgG.png
Click to expand...
I am having multiple issues with emails, certain sites like UPS, a banking app and Sixty60 also.. On Metrofibre through WebAfrica
 
dontcryforme said:
I am having multiple issues with emails, certain sites like UPS, a banking app and Sixty60 also.. On Metrofibre through WebAfrica
Click to expand...
I think you are having different issues. WebAfrica is known to be pretty kak. The issue I am experiencing on my end is due to the rollout of IPv6 to some Cool Ideas customers on some FNO'S. Some of us have asked for "Early Access" to dual-stack IPv4 and IPv6 .

Because it's still in a testing phase (I think), there are some issues with routing and such, which we report back here to get ironed out.
 
adam_g said:
I think you are having different issues. WebAfrica is known to be pretty kak. The issue I am experiencing on my end is due to the rollout of IPv6 to some Cool Ideas customers on some FNO'S. Some of us have asked for "Early Access" to dual-stack IPv4 and IPv6 .

Because it's still in a testing phase (I think), there are some issues with routing and such, which we report back here to get ironed out.
Click to expand...
Yeah I have also noticed that some sites dont get picked up locally yet. Some of the things goes via UK when using IPv6. But when v6 is switched off it gets picked up locally via V4 again
 
TheLostPacket said:
Yeah I have also noticed that some sites dont get picked up locally yet. Some of the things goes via UK when using IPv6. But when v6 is switched off it gets picked up locally via V4 again
Click to expand...
HI there, are you able to share some of these destinations with me?
Would be happy to take a look.

@adam_g were still looking into auth.sixty60.co.za, I do see when I ping the V6 addess on our looking glass it resolves , however latency seems to be 312ms, so not so ideal (lg.cisp.co.za)

PING 2600:9000:20d9:7200:d:be1d:7140:93a1(2600:9000:20d9:7200:d:be1d:7140:93a1) 56 data bytes
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=1 ttl=53 time=312 ms
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=2 ttl=53 time=312 ms
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=3 ttl=53 time=312 ms
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=8 ttl=53 time=312 ms
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=9 ttl=53 time=312 ms
64 bytes from 2600:9000:20d9:7200:d:be1d:7140:93a1: icmp_seq=10 ttl=53 time=312 ms

--- 2600:9000:20d9:7200:d:be1d:7140:93a1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2808ms
rtt min/avg/max/mdev = 311.817/311.852/311.873/0.019 ms, ipg/ewma 311.973/311.850 ms
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter