Afrihost Capped DSL Feedback

AfriFella said:
BRAS tests purely show exchange performance. Your intermittent results are definitely concerning. :( Are you working with our CC Team?
Click to expand...

My previous statements on the matter might have been missed so I'll repeat.
No your CC team have NOT contacted me despite all you guys here suggesting that they will be.
 
AfriFella said:
Packet Loss and latency to BRAS is unfortunately outside of our control. :( This is exchange related.
Click to expand...

It would be highly coincidental, given the past weeks, for the exchange to have contributed. But let's say that this happened. Then it's ONE day (yesterday) in a month of days where AH performance has been subpar.

Can AH, who manage my line, please check the exchange logs and feedback to me ASAP.
 
AfriFella said:
Packet Loss and latency to BRAS is unfortunately outside of our control. :( This is exchange related.
Click to expand...

I, like the other folks here, have heard that performance to BRAS being outside AH control i.e.: is exchange related. Can you, or any of the other reps, please explain how BRAS is connected up and why it implies that there are exchange issues.
 
steel_dog said:
My previous statements on the matter might have been missed so I'll repeat.
No your CC team have NOT contacted me despite all you guys here suggesting that they will be.
Click to expand...

That's terrible. :( I'm not sure why the hold up... I'll follow up with them again today.
 
steel_dog said:
I, like the other folks here, have heard that performance to BRAS being outside AH control i.e.: is exchange related. Can you, or any of the other reps, please explain how BRAS is connected up and why it implies that there are exchange issues.
Click to expand...

In the not so distant past, all Telkom Exchanges responded to ICMP traffic, so on traceroutes, if there was congestion or a line issue it would be immediately visible on the second-hop of the traceroute.

However, this isn't possible anymore, as the DSLAM - most of them at least - don't respond to ICMP traffic. One of our Team did however figure out that if you ping 155.239.255.250 it will resolve to the BRAS or broadband remote access server on each Exchange.

Each Exchange has a BRAS and on each DSL Line, 155.239.255.250 will resolve to the BRAS on the Exchange that you are connected to. This in essence lets you test the latency to your Exchange even though the DSLAM doesn't respond to ICMP traffic. The BRAS is the point at which your traffic breaks out to the ISP networks.

We just created a DNS Record call bras.afrihost.com so that you don't have to remember 155.239.255.250, although, bras.afrihost.com will always resolve to your BRAS.

I hope that makes sense. :)
 
AfriGenie said:
However, this isn't possible anymore, as the DSLAM - most of them at least - don't respond to ICMP traffic. One of our Team did however figure out that if you ping 155.239.255.250 it will resolve to the BRAS or broadband remote access server on each Exchange.

Each Exchange has a BRAS and on each DSL Line, 155.239.255.250 will resolve to the BRAS on the Exchange that you are connected to. This in essence lets you test the latency to your Exchange even though the DSLAM doesn't respond to ICMP traffic. The BRAS is the point at which your traffic breaks out to the ISP networks.
Click to expand...

So, if 155.239.255.250 is assigned to the BRAS, and the BRAS doesn't respond to ICMP (pings), why do you get a response from that IP? I guess, the BRAS DOES respond to ICMP after all, or, the IP is in fact, NOT on the BRAS.... Only Telkom will know at the end of the day

Also quite ironic that Afrihost is the ONLY ISP that figured this out... :whistle:
 
savage said:
So, if 155.239.255.250 is assigned to the BRAS, and the BRAS doesn't respond to ICMP (pings), why do you get a response from that IP? I guess, the BRAS DOES respond to ICMP after all, or, the IP is in fact, NOT on the BRAS.... Only Telkom will know at the end of the day

Also quite ironic that Afrihost is the ONLY ISP that figured this out... :whistle:
Click to expand...

Technically it's the DSLAM which doesn't respond to ICMP traffic, and the BRAS sits between the DSLAM and the ISP network. :)

XDSL.jpg

This diagram gives a nice breakdown of typical DSL network infrastructure.
 
Last edited:
AfriGenie said:
Technically it's the DSLAM which doesn't respond to ICMP traffic, and the BRAS sits between the DSLAM and the ISP network. :)

https://en.wikipedia.org/wiki/Broadband_remote_access_server#/media/File:XDSL_Connectivity_Diagram_en.svg

This diagram gives a nice breakdown of typical DSL network infrastructure.
Click to expand...

Shrugs... OK :-)

You go on to make assumptions....

So are we now pinging the DSLAM (in the exchange) or the BRAS (I think there's 5 or so in the country the last time I looked at integration documentation)? There's a fundamental difference between those.

Ag you know what... Don't feel like even arguing with you about this TBH. AfriHost is SO awesome, it's the ONLY ISP in the country that figured this out yes. Everyone (including Telkom/OpenServe) must be wrong, except Afrihost, as usual.
 
AfriFella said:
Sorry to hear that! :( Are you using any specific DNS settings? Did things improve throughout the course of the evening?
Click to expand...

Nope, stock standard auto DNS. Not sure if improved, was watching a bit while getting kids ready for bed, didn't try again later.
 
AfriGenie said:
In the not so distant past, all Telkom Exchanges responded to ICMP traffic, so on traceroutes, if there was congestion or a line issue it would be immediately visible on the second-hop of the traceroute.

However, this isn't possible anymore, as the DSLAM - most of them at least - don't respond to ICMP traffic. One of our Team did however figure out that if you ping 155.239.255.250 it will resolve to the BRAS or broadband remote access server on each Exchange.

Each Exchange has a BRAS and on each DSL Line, 155.239.255.250 will resolve to the BRAS on the Exchange that you are connected to. This in essence lets you test the latency to your Exchange even though the DSLAM doesn't respond to ICMP traffic. The BRAS is the point at which your traffic breaks out to the ISP networks.

We just created a DNS Record call bras.afrihost.com so that you don't have to remember 155.239.255.250, although, bras.afrihost.com will always resolve to your BRAS.

I hope that makes sense. :)
Click to expand...

That sounds very logical however...
- I thought the BRAS was an aggregator located at point before breakout to ISP's at the local hub? Didn't think there was one at each exchange.
- I agree that high latency suggests a problem, but the nature of the problem can't be known until investigated. It certainly can't definitively indicate exchange congestion as is generally suggested here.
- If there's latency on the BRAS isn't it Afrihost's responsibility to get that investigated and resolved as it indicates a problem between the Telkom and the Afrihost networks? This is all the more relevant for clients, like myself, whose lines are managed by Afrihost.
 
savage said:
Shrugs... OK :-)

You go on to make assumptions....

So are we now pinging the DSLAM (in the exchange) or the BRAS (I think there's 5 or so in the country the last time I looked at integration documentation)? There's a fundamental difference between those.

Ag you know what... Don't feel like even arguing with you about this TBH. AfriHost is SO awesome, it's the ONLY ISP in the country that figured this out yes. Everyone (including Telkom/OpenServe) must be wrong, except Afrihost, as usual.
Click to expand...

It's probably not the best solution, but it does give us an idea of any latency before the traffic hits our part of the network.

I have honestly not looked at the Integration Documentation before, so you probably know better than I do in that regard. :)
 
steel_dog said:
That sounds very logical however...
- I thought the BRAS was an aggregator located at point before breakout to ISP's at the local hub? Didn't think there was one at each exchange.
- I agree that high latency suggests a problem, but the nature of the problem can't be known until investigated. It certainly can't definitively indicate exchange congestion as is generally suggested here.
- If there's latency on the BRAS isn't it Afrihost's responsibility to get that investigated and resolved as it indicates a problem between the Telkom and the Afrihost networks? This is all the more relevant for clients, like myself, whose lines are managed by Afrihost.
Click to expand...

It's just one part of the troubleshooting process, in that it helps us figure out where the latency is. We'll still need to log a fault with Telkom if latency appears on bras.afrihost.com and if the latency starts after that, we'll get our Network Team to investigate.
 
AfriGenie said:
... We'll still need to log a fault with Telkom if latency appears on bras.afrihost.com ...
Click to expand...

That's good to hear. I was concerned because it seemed as if it wasn't going to be investigated because it was exchange related.
Packet Loss and latency to BRAS is unfortunately outside of our control. This is exchange related.
Click to expand...

Not having a workable experience for a day is severe. I'd like to understand what had happened.
 
steel_dog said:
That's good to hear. I was concerned because it seemed as if it wasn't going to be investigated because it was exchange related.


Not having a workable experience for a day is severe. I'd like to understand what had happened.
Click to expand...

I do need to point out, that if we logged a fault with Telkom, and they indicate that there is congestion on the Exchange and that it is the congestion causing the latency, there isn't much more we can do from our side until Telkom upgrades the Exchange.

In most other cases though we'll push Telkom / Openserve to resolve the issue as quickly as possible.
 
AfriGenie said:
I do need to point out, that if we logged a fault with Telkom, and they indicate that there is congestion on the Exchange and that it is the congestion causing the latency, there isn't much more we can do from our side until Telkom upgrades the Exchange.

In most other cases though we'll push Telkom / Openserve to resolve the issue as quickly as possible.
Click to expand...

The discussion is hypotheical because there is no exchange congestion evident. Everything is back to normal. Whatever happened yesterday does need to be understood... just in case it is indeed pointing to / is a precursor to exchange congestion. So.. exchange logs should prove this. I'm presuming that AH can, and does, ask for these? I would have had I been managing my own line.
 
steel_dog said:
The discussion is hypotheical because there is no exchange congestion evident. Everything is back to normal. Whatever happened yesterday does need to be understood... just in case it is indeed pointing to / is a precursor to exchange congestion. So.. exchange logs should prove this. I'm presuming that AH can, and does, ask for these? I would have had I been managing my own line.
Click to expand...

We do keep a history of the faults that have been logged for your DSL Line, as well as any and all queries that you logged with us.

We don't have access to Exchange Logs, though we do keep track of Exchanges that have issues.
 
Kosmik said:
Nope, stock standard auto DNS. Not sure if improved, was watching a bit while getting kids ready for bed, didn't try again later.
Click to expand...

When you get a chance to test again, would you please let me know how it compares.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X