Telkom Internet Capped/Uncapped User Feedback (Pt2)

It's again that time of the month where everyone in the area tries to use the internet at the same time :/



Or could it be a Telkom issue?

EDIT
========================

Afrihost DSL


I guess it's TI then/
I'm puzzled why the 2nd hop is not timing out like everyone else's?
 
There was a routing incident at 10h10. It was identified at 10h20, localised at 10h25 and resolved at 10h30. However, at 10h35 only about 50% of the traffic present at 10h00 returned. So, most likely abput 50% of our subscribers re-swt their modems between 10h10 and 10h30. This resulted in problema with SAIX AAA. Once that was resolved, the TI AAA servers also took some strain for some time.

We have seen a similar incident in the past (early morning), but it resolved itself before anyone was able to investigate. We have now identified the root cause, and will implement a permanent fix later today.
 
TI authentication is fooked. The cherry on top is you can't even call 10210 as you get a NU tone or absolutely nothing! Also tried 10217 for busnesses and once you select the fault reporting option same thing NU tone or nothing. So you can't even call the company if you have issues, so much for being a telecoms company.

Switched to a different ISP, sort your schite out please!!!

Doesn't sound like an ISP issue if you can't place a call ...
 
It's again that time of the month where everyone in the area tries to use the internet at the same time :/

Everyone on your DSLAM.

Or could it be a Telkom issue?

EDIT
========================

Afrihost DSL


I guess it's TI then/

No:

Code:
2 47 ms 48 ms 165 ms wwg-ip-bng-1.south.dsl.telkomsa.net [105.225.8.1
]
3 990 ms 559 ms 47 ms ipc-4-up.south.dsl.telkomsa.net [105.226.0.30]

In the trace above, hop 2 is the BNG, and your latency should be < 20ms, but during the few seconds the TTL sent by your traceroute was 2, the latency varied between 47 and 165ms.

1 49 ms 44 ms 62 ms 105-236-249-65-esr-lo.mtnbusiness.co.za [105.236
.249.65]
2 45 ms 58 ms 48 ms ipc-recieve-tb-2a.mtnbusiness.net [41.181.54.86]

In this trace, you seem to have run the traceroute from the same place as the PPPoE session, so hop 1 is the BNG, and the latency while TTL was 1 varied from 19ms to 62ms.

I would say it is fairly conclusively DLSAM congestion, the severity of the DSLAM congestion varied between one traceroute and the other, but in a case like this you can't trust anything beyond the ESR, because the congestion has changed by the time your traceroute has a TTL of 3 or 5 or 10.

mtr or winmtr is better in a case like this, as you can get results with more samples.
 
Just tried Afrihost and nada.
Just tested Afrihost capped - no problems.

... TI on the other hand (sorted most recent to oldest)

Code:
12:03:45	pppd[30923]	Exit.
12:03:45	pppd[30923]	Connection terminated.
12:03:45	pppd[30923]	Modem hangup
12:03:45	pppoe[30924]	Sent PADT
12:03:45	pppoe[30924]	Session 1 terminated -- received PADT from peer
12:03:45	pppd[30923]	LCP terminated by peer
12:03:45	pppd[30923]	PAP authentication succeeded
12:03:45	pppd[30923]	Remote message: Login ok
12:03:34	pppoe[30924]	PPP session is 1 (0x1)
12:03:34	pppoe[30924]	PADS: Service-Name: ''
12:03:34	pppd[30923]	Connect: ppp0 <--> /dev/pts/0
12:03:34	pppd[30923]	Using interface ppp0
12:03:34	pppd[30923]	pppd 2.4.7 started by root, uid 0
12:03:34	red	Dialling TI 10MB Uncapped.
12:03:34	red	Starting RED device wan-1 type PPPOE.
 
Everyone on your DSLAM.



No:

Code:
2 47 ms 48 ms 165 ms wwg-ip-bng-1.south.dsl.telkomsa.net [105.225.8.1
]
3 990 ms 559 ms 47 ms ipc-4-up.south.dsl.telkomsa.net [105.226.0.30]

In the trace above, hop 2 is the BNG, and your latency should be < 20ms, but during the few seconds the TTL sent by your traceroute was 2, the latency varied between 47 and 165ms.



In this trace, you seem to have run the traceroute from the same place as the PPPoE session, so hop 1 is the BNG, and the latency while TTL was 1 varied from 19ms to 62ms.

I would say it is fairly conclusively DLSAM congestion, the severity of the DSLAM congestion varied between one traceroute and the other, but in a case like this you can't trust anything beyond the ESR, because the congestion has changed by the time your traceroute has a TTL of 3 or 5 or 10.

mtr or winmtr is better in a case like this, as you can get results with more samples.
I will report back later, things have improved this morning though, but I'll have to check.
 
This load shedding is causing havoc with TI's authentication servers, it's taking up to an hour for clients to log on after power is restored doubtless due to the sudden surge in requests.

@ranger - do you know if anything is planned to resolve this problem?

We haven't been able to determine whether it is anything within our (Telkom Internet's) control, or only related to:
- Migration from one vendor to another for the Wholesale network BNGs.
- Migration from DSLAMs to MSANs
- Upgrades to the Wholesale AAA.

We haven't made any significant changes to our AAA in the last 3 months, and we reverted the only change we made in the last 6 months when Wholesale claimed it was a problem on our side.

In the few cases we have been able to investigate while we had contact with someone experiencing the problem, we weren't receiving any RADIUS Access-Request packets from Wholesale's AAA proxies. They couldn't show that they had sent any Access-Requests for that username to us. We are working on some AAA upgrades anyway (normal infrastructure lifecycles).
 
@ Ranger: Sorry mate but I missed the bit where "Wholesale AAA" crept in. What does that acronym stand for?
 
Doesn't sound like an ISP issue if you can't place a call ...

I did not say the two were related, just that it's an extra inconvenience when you cannot even report a TI fault via a number they provide as their fault/contact number. 10210 did not work this morning, I could dial other numbers just fine so the problem was with 10210 and then there was the problem with TI authentication as well which I needed to report.

To make it crystal clear,
1. TI had authentication issues this morning.
2. Telkom 10210 service was out of order this morning and not related to the TI authentication issues.
 
Already had 5 calls from TI clients this morning who can't get internet despite line synching OK.
 
I switched to a free axxess account and that immediately took, did not try any others.
I don't have an Axxess account - and since they require an ID book to sign up I probably wont - but I did find the details of my WA account and that works. Hope Telkom ISP sorts theirs out soon.
 
Still up here... been out all morning, PC always on.
Yep, hang your router off a UPS that's good for >2hrs and you're good to go.

... though with 3 outages scheduled for our area today it's going to be interesting to see if the UPS's can take the strain.
 
I did not say the two were related, just that it's an extra inconvenience when you cannot even report a TI fault via a number they provide as their fault/contact number. 10210 did not work this morning, I could dial other numbers just fine so the problem was with 10210 and then there was the problem with TI authentication as well which I needed to report.

To make it crystal clear,
1. TI had authentication issues this morning.
2. Telkom 10210 service was out of order this morning and not related to the TI authentication issues.
How is it that TI doesn't know that 10210 doesn't work? It's looking more like a communication disaster.
 
Just came back online... been off since around 10am, line fine, but would not authenticate. 10210 just 'boooopped' for hours, couldn't get hold of them

And to add to my pain, now that webs back up, load shedding hitting in 35min:( What a wasted day, a whole 1hr 30min work done... (&^%*&^* *spit* I can't afford to lose one hour let alone a whole day
 
Last edited:
Top
Sign up to the MyBroadband newsletter
X