Afrihost Business Uncapped Feedback - 2

Status
Not open for further replies.
AfriMan said:
Do you have a list of those BRAS/BNG IP's? Might be very helpful to our support team to be able to provide client's with this information to be able to troubleshoot better :)
Click to expand...

Unfortunately not, That IP should work on all lines where the exchange does not respond to ICMP.

Like so:

(Normal Tracert to Afrihost.com)
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 48 ms 51 ms 47 ms 41.181.54.85

(Tracert to 155.239.255.250)

1 <1 ms <1 ms <1 ms 192.168.0.1
2 9 ms 10 ms 9 ms 155.239.255.250
 
ghostR said:
Unfortunately not, That IP should work on all lines where the exchange does not respond to ICMP.

Like so:

(Normal Tracert to Afrihost.com)
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 48 ms 51 ms 47 ms 41.181.54.85

(Tracert to 155.239.255.250)

1 <1 ms <1 ms <1 ms 192.168.0.1
2 9 ms 10 ms 9 ms 155.239.255.250
Click to expand...

That's interesting, becuase usually if you trace to an IP that is not your local BRAS, you should still route via IPC. Actually, thinking about it now, clients usually still route via IPC to trace to their own local BRAS as well. So they would usually route ROUTER > BRAS > MTN NETWORK > BRAS

How is this actually routing? What is actually being pinged if it's not the client's local BRAS?
 
Yay for having interwebs again! let's hope it holds this time.
 
AfriMan said:
That's interesting, becuase usually if you trace to an IP that is not your local BRAS, you should still route via IPC. Actually, thinking about it now, clients usually still route via IPC to trace to their own local BRAS as well. So they would usually route ROUTER > BRAS > MTN NETWORK > BRAS

How is this actually routing? What is actually being pinged if it's not the client's local BRAS?
Click to expand...

From what I know and what I've seen, When an ISP's IPC is congested, It seems to bypass that. For example my pings while on my Afrihost account (third hop) are hovering at 50ms. If I ping that IP, I get around 9 - 11ms continuously.

So from what I'm seeing, It seems to bypass an ISP's IPC. (Hence why pinging that IP also works on the telkom guest account ;)
 
ghostR said:
From what I know and what I've seen, When an ISP's IPC is congested, It seems to bypass that. For example my pings while on my Afrihost account (third hop) are hovering at 50ms. If I ping that IP, I get around 9 - 11ms continuously.

So from what I'm seeing, It seems to bypass an ISP's IPC. (Hence why pinging that IP also works on the telkom guest account ;)
Click to expand...

If it's bypassing IPC, I'm not really sure what it would be demonstrating. What I've seen is that using the Guest account sometimes performs optimally where any ISP account shows congestion/latency, so I think that alternate routing can be problematic unless we can understand what routing is used and what we can reliably conclude from the results.
 
AfriMan said:
If it's bypassing IPC, I'm not really sure what it would be demonstrating. What I've seen is that using the Guest account sometimes performs optimally where any ISP account shows congestion/latency, so I think that alternate routing can be problematic unless we can understand what routing is used and what we can reliably conclude from the results.
Click to expand...

It basically tests the Exchange and Line for issues/congestion.

Ie. Tests to a congested exchange from a 10Mbps Line -

Pinging 155.239.255.250 with 32 bytes of data:
Reply from 155.239.255.250: bytes=32 time=1437ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1494ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1532ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1527ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1543ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1563ms TTL=63

Test from the same line during non peak times when the exchange is not congested -

Pinging 155.239.255.250 with 32 bytes of data:
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63

From these results, A support agent would be able to see whether the exchange/line is at fault, Or if the problem lies with the ISP network itself
 
Last edited:
ghostR said:
It basically tests the Exchange and Line for issues/congestion.

Ie. Tests to a congested exchange from a 10Mbps Line -

Pinging 155.239.255.250 with 32 bytes of data:
Reply from 155.239.255.250: bytes=32 time=1437ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1494ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1532ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1527ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1543ms TTL=63
Reply from 155.239.255.250: bytes=32 time=1563ms TTL=63

Test from the same line during non peak times when the exchange is not congested -

Pinging 155.239.255.250 with 32 bytes of data:
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=8ms TTL=63
Reply from 155.239.255.250: bytes=32 time=7ms TTL=63

From these results, A support agent would be able to see whether the exchange/line is at fault, Or if the problem lies with the ISP network itself
Click to expand...

I'm not sure I'm following though.
How does it know if/ when the IPC is congested?
 
AfriGuy said:
I'm not sure I'm following though.
How does it know if/ when the IPC is congested?
Click to expand...

You would need to be able to interpret it, So you would need to run a traceroute, Then look at the third/fourth hop (generally ISP IPC) if this is high, It could indicate either an issue with the ISP's network or exchange congestion.

You can then run a tracert to 155.239.255.250, If the pings are low on this traceroute, then it is not an exchange/line issue and the ISP would need to investagate on their side.

If the pings are high on the tracert, Then the issue lies on telkoms side.

Understand?
 
ghostR said:
You would need to be able to interpret it, So you would need to run a traceroute, Then look at the third/fourth hop (generally ISP IPC) if this is high, It could indicate either an issue with the ISP's network or exchange congestion.

You can then run a tracert to 155.239.255.250, If the pings are low on this traceroute, then it is not an exchange/line issue and the ISP would need to investagate on their side.

If the pings are high on the tracert, Then the issue lies on telkoms side.

Understand?
Click to expand...

Kind of yeah.
When my home line was moved to a new ESR and the exchange stopped accepting ICMP packets I noticed my 3rd hop response time increase. My overall latency stayed the same though. Example below:

Code: 
Jeffs-Macbook:~ jeff$ traceroute mybroadband.co.za
traceroute to mybroadband.co.za (197.242.89.170), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.1.1)  1.053 ms  0.805 ms  0.674 ms
 2  * * *
 3  41.181.54.85 (41.181.54.85)  33.886 ms  83.564 ms  34.426 ms
 4  ipc-recieve-tb-2a.mtnbusiness.net (41.181.54.86)  28.471 ms  142.744 ms  19.436 ms
 5  tb-dca-2.za--qux-c.za.mtnbusiness.net (41.181.198.188)  26.426 ms  27.297 ms  20.452 ms
 6  compj-cpt-1.mtnns.net (196.44.18.2)  24.974 ms
    unc-cpt-1.mtnns.net (196.44.18.8)  19.997 ms
    compj-cpt-1.mtnns.net (196.44.18.2)  24.040 ms
 7  196.44.31.106 (196.44.31.106)  26.134 ms
    ct-cr-2.za--tb-cr-1.za.mtnns.net (196.44.31.134)  23.182 ms  35.819 ms
 8  nl-ha-2.za--rb-cr-1.za-a.mtnns.net (196.44.0.121)  20.416 ms  23.294 ms
    196.44.0.74 (196.44.0.74)  21.099 ms
 9  africainx.cinx.net.za (196.223.22.47)  27.984 ms  53.949 ms  30.684 ms
10  core.gp-cn-het-mee-1.to.gp-hv-ict-mee-1.dfa.p2p.10g.za.africainx.net (41.84.13.66)  52.056 ms  47.880 ms  48.172 ms
11  41-66-132-246-f6.het001-cpe-1-to-gp-cn-het-mee-1.africainx.net (41.66.132.246)  51.452 ms  53.572 ms  42.803 ms
12  core-access-switch1.jnb1.host-h.net (197.189.193.1)  44.121 ms  47.634 ms  57.055 ms
13  row-access-switch1-row3-4.jnb1.host-h.net (197.189.193.36)  51.511 ms  50.945 ms  53.988 ms
14  197.242.89.170 (197.242.89.170)  48.758 ms  48.495 ms  45.362 ms
Jeffs-Macbook:~ jeff$ ping 41.181.54.85
PING 41.181.54.85 (41.181.54.85): 56 data bytes
64 bytes from 41.181.54.85: icmp_seq=0 ttl=249 time=23.397 ms
64 bytes from 41.181.54.85: icmp_seq=1 ttl=249 time=21.626 ms
64 bytes from 41.181.54.85: icmp_seq=2 ttl=249 time=26.394 ms
64 bytes from 41.181.54.85: icmp_seq=3 ttl=249 time=36.532 ms
64 bytes from 41.181.54.85: icmp_seq=4 ttl=249 time=32.593 ms
64 bytes from 41.181.54.85: icmp_seq=5 ttl=249 time=25.634 ms
64 bytes from 41.181.54.85: icmp_seq=6 ttl=249 time=26.979 ms
64 bytes from 41.181.54.85: icmp_seq=7 ttl=249 time=27.948 ms
64 bytes from 41.181.54.85: icmp_seq=8 ttl=249 time=20.089 ms
64 bytes from 41.181.54.85: icmp_seq=9 ttl=249 time=25.239 ms
^C
--- 41.181.54.85 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.089/26.643/36.532/4.655 ms

So the third hop bounces around a bit, sometimes peaks up to the 100ms+, but pinging that IP shows a much more stable pattern.
Are the ICMP rejections on the exchange not causing increased response times on a traceroute?
 
AfriGuy said:
Kind of yeah.
When my home line was moved to a new ESR and the exchange stopped accepting ICMP packets I noticed my 3rd hop response time increase. My overall latency stayed the same though. Example below:

Code: 
Jeffs-Macbook:~ jeff$ traceroute mybroadband.co.za
traceroute to mybroadband.co.za (197.242.89.170), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.1.1)  1.053 ms  0.805 ms  0.674 ms
 2  * * *
 3  41.181.54.85 (41.181.54.85)  33.886 ms  83.564 ms  34.426 ms
 4  ipc-recieve-tb-2a.mtnbusiness.net (41.181.54.86)  28.471 ms  142.744 ms  19.436 ms
 5  tb-dca-2.za--qux-c.za.mtnbusiness.net (41.181.198.188)  26.426 ms  27.297 ms  20.452 ms
 6  compj-cpt-1.mtnns.net (196.44.18.2)  24.974 ms
    unc-cpt-1.mtnns.net (196.44.18.8)  19.997 ms
    compj-cpt-1.mtnns.net (196.44.18.2)  24.040 ms
 7  196.44.31.106 (196.44.31.106)  26.134 ms
    ct-cr-2.za--tb-cr-1.za.mtnns.net (196.44.31.134)  23.182 ms  35.819 ms
 8  nl-ha-2.za--rb-cr-1.za-a.mtnns.net (196.44.0.121)  20.416 ms  23.294 ms
    196.44.0.74 (196.44.0.74)  21.099 ms
 9  africainx.cinx.net.za (196.223.22.47)  27.984 ms  53.949 ms  30.684 ms
10  core.gp-cn-het-mee-1.to.gp-hv-ict-mee-1.dfa.p2p.10g.za.africainx.net (41.84.13.66)  52.056 ms  47.880 ms  48.172 ms
11  41-66-132-246-f6.het001-cpe-1-to-gp-cn-het-mee-1.africainx.net (41.66.132.246)  51.452 ms  53.572 ms  42.803 ms
12  core-access-switch1.jnb1.host-h.net (197.189.193.1)  44.121 ms  47.634 ms  57.055 ms
13  row-access-switch1-row3-4.jnb1.host-h.net (197.189.193.36)  51.511 ms  50.945 ms  53.988 ms
14  197.242.89.170 (197.242.89.170)  48.758 ms  48.495 ms  45.362 ms
Jeffs-Macbook:~ jeff$ ping 41.181.54.85
PING 41.181.54.85 (41.181.54.85): 56 data bytes
64 bytes from 41.181.54.85: icmp_seq=0 ttl=249 time=23.397 ms
64 bytes from 41.181.54.85: icmp_seq=1 ttl=249 time=21.626 ms
64 bytes from 41.181.54.85: icmp_seq=2 ttl=249 time=26.394 ms
64 bytes from 41.181.54.85: icmp_seq=3 ttl=249 time=36.532 ms
64 bytes from 41.181.54.85: icmp_seq=4 ttl=249 time=32.593 ms
64 bytes from 41.181.54.85: icmp_seq=5 ttl=249 time=25.634 ms
64 bytes from 41.181.54.85: icmp_seq=6 ttl=249 time=26.979 ms
64 bytes from 41.181.54.85: icmp_seq=7 ttl=249 time=27.948 ms
64 bytes from 41.181.54.85: icmp_seq=8 ttl=249 time=20.089 ms
64 bytes from 41.181.54.85: icmp_seq=9 ttl=249 time=25.239 ms
^C
--- 41.181.54.85 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.089/26.643/36.532/4.655 ms

So the third hop bounces around a bit, sometimes peaks up to the 100ms+, but pinging that IP shows a much more stable pattern.
Are the ICMP rejections on the exchange not causing increased response times on a traceroute?
Click to expand...

It shouldn't increase your response times higher up on the traceroute.

Have you tried running a traceroute on a different ISP?

I personally, have a vox fatpipe account, At around 6pm on the dot, my latency on hop 3 goes through the roof (After hours Uncapped starts at that time)

I actually thought originally that it might of been my exchange, But after testing with that IP, Getting 9ms pings while a ping to a normal website 100ms +

I also found that testing with other ISPs like WA, Afrihost etc, my pings lowered significantly on the third hop.

Which shows, That testing with that IP can provide quite a bit of insight into your line/exchange.
 
The below is on vox over the past week - Shows how congested their network becomes at 6pm.

VOX-Telkom-BRAS_last_604800.png


The below on Internet Solutions over the past week - same period.

IS-Telkom-BRAS_last_604800.png


The below is Afrihost over the past week - same period.

Afrihost-Telkom-BRAS_last_604800.png
 
Last edited:
ghostR said:
It shouldn't increase your response times higher up on the traceroute.

Have you tried running a traceroute on a different ISP?

I personally, have a vox fatpipe account, At around 6pm on the dot, my latency on hop 3 goes through the roof (After hours Uncapped starts at that time)

I actually thought originally that it might of been my exchange, But after testing with that IP, Getting 9ms pings while a ping to a normal website 100ms +

I also found that testing with other ISPs like WA, Afrihost etc, my pings lowered significantly on the third hop.

Which shows, That testing with that IP can provide quite a bit of insight into your line/exchange.
Click to expand...

Indeed, it's the same across the board for me.
Either way, it seems like quite a lengthy was of determining whether or not the exchange is congested. Interesting nonetheless :)
 
Another Interesting graph for you guys to look at - Afrihost's network over the past 24 hours -

Afrihost-Telkom-BRAS_last_86400.png
 
AfriGuy said:
Quite similar to mine, but my instance of smokeping runs on my DSL connection which is in use most of the time.
View attachment 215684
Click to expand...

By those results, Can see your in Cape town :D

It's very interesting, Have quite a few ISPs on Smokeping monitoring so can see if an ISP develops an issue in realtime.

Telkoms DSL network over the past 24 hours -

Telkom-DSL-BRAS_last_86400.png
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X