Intermittent packet loss / route flapping on Cape Town to JNB transit (DiData / AS20011)

zerofivetwosix · Aug 21, 2026

Hi everyone / Webafrica Reps,

I wanted to see if anyone else on Webafrica FTTH (Cape Town) is seeing intermittent drops and packet loss specifically to destinations in Johannesburg over the last couple of days.

Summary of the issue:

Local CPT & International: Completely fine, rock solid with 0% packet loss.
JNB Destinations: Intermittent 20%–100% packet loss spikes happening every few minutes (affecting xneelo JNB DC, Google JNB nodes, and general north-bound traffic simultaneously).
Location / Subnet: Cape Town (152.110.132.x range).

Diagnostics:

Traces and feedback from upstream NOC teams indicate intermittent route changes / route flapping across the Dimension Data (DiData / AS20011) backhaul out of Cape Town.

Looking at the trace data, local hops (za-wc-tgw-bb-bng-2.as20011.net) are fine, but packet loss immediately begins upstream around 168.210.9.162 and carries all the way through to JNB targets during the drop events.

I have attached a PingPlotter capture below showing the simultaneous drops.

Has anyone else noticed brief drops or degraded latency north of CPT recently, or could a rep kindly flag this with the core network team to check the national transit links?

Thanks!

WishfulThinking · Wednesday at 6:21 PM

@zerofivetwosix

Apparently @Webafrica Helper isn't here to help these days, just lurk ?
Last posted something on the 8th May '26.

In that case, hope you got sorted out with them directly.

E=mc2 · Wednesday at 8:38 PM

Webafrica / Openserve – 140–170ms+ Evening Ping, Packet Loss & Slow Speeds in Klapmuts

Area: Klapmuts, Western Cape
FNO: Openserve
ISP: Webafrica

I’m posting this to find out whether other Webafrica customers on Openserve are experiencing the same peak-time problem.

Every evening, roughly 19:00–23:00, my fibre connection deteriorates badly.

During the day it is generally fine, but during the evening I experience:

140–170ms+ latency
Packet loss
Slower download/upload speeds
Unstable latency
Poor performance even to destinations in Cape Town

I have contacted both Webafrica and Openserve, but unfortunately I've basically been sent back and forth without the underlying problem being resolved.

I've now had enough and have submitted my cancellation notice to Webafrica.

Test 1 – Google

traceroute to www.google.com (142.251.156.119), 20 hops max 1 * * * 2 168-210-9-197.ipv4.as20011.net 111.789 ms 125.552 ms 151.682 ms 3 za-wc-tgw-bb-bng-2.as20011.net 140.648 ms 140.785 ms 143.244 ms 4 168-210-9-162.webafrica.ipv4.as20011.net 140.858 ms 168-210-9-160.webafrica.ipv4.as20011.net 157.459 ms * 5 * * * 6 173.194.121.190 165.006 ms * 154.424 ms 7 142.251.156.119 140.717 ms 136.158 ms 140.238 ms

Test 2 – Cloudflare 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 20 hops max 1 * * * 2 168-210-9-197.ipv4.as20011.net 141.281 ms 143.059 ms 168-210-9-185.ipv4.as20011.net 142.635 ms 3 za-wc-tgw-bb-bng-1.as20011.net 145.164 ms 141.790 ms za-wc-tgw-bb-bng-2.as20011.net 142.905 ms 4 * * 168-210-9-160.webafrica.ipv4.as20011.net 143.223 ms 5 cloudflare.ixp.capetown (196.60.70.198) 162.102 ms 152.727 ms 163.965 ms 6 172.68.184.13 142.189 ms * 143.416 ms 7 one.one.one.one (1.1.1.1) 150.629 ms 149.071 ms 140.447 ms
The Cloudflare test is particularly concerning because the route reaches cloudflare.ixp.capetown, yet I'm still seeing roughly 150–160ms latency.

More importantly, the latency is already present at the early AS20011/Webafrica BNG hops, where it is around 140–145ms.

This therefore does not appear to be an international routing issue.

Because the problem occurs consistently during 19:00–23:00 and improves outside peak periods, it looks very much like a congestion or capacity issue somewhere between the Openserve handover and Webafrica's network.

Are there any other Klapmuts / Western Cape Webafrica customers on Openserve experiencing the same?

If so, please post your area, FNO, ISP, ping to 1.1.1.1 and traceroute results so we can compare.

Webafrica Helper · Thursday at 11:10 AM

Hi @zerofivetwosix, thanks for putting together the detailed diagnostics. We’ve seen the reports around intermittent packet loss affecting Cape Town to Johannesburg traffic, including the route changes you’ve highlighted around the AS20011/Dimension Data path. We’d like to investigate this properly rather than make assumptions based on traceroutes alone. (MyBroadband)

If you’re still experiencing the issue, please DM us your Webafrica account details and the affected service address. We’ll get this in front of the relevant network team so they can correlate your service with the network path and investigate the packet loss and route changes you’re seeing.

If you have recent PingPlotter/MTR results captured while the issue is occurring, please include those too. They’ll be useful for the investigation.

We’re happy to take a proper look at this with you and help get to the bottom of what’s happening. We look forward to your update via DM.

Warm regards,
Webafrica Crew

Webafrica Helper · Thursday at 11:30 AM

E=mc2 said:
Webafrica / Openserve – 140–170ms+ Evening Ping, Packet Loss & Slow Speeds in Klapmuts

Area: Klapmuts, Western Cape
FNO: Openserve
ISP: Webafrica

I’m posting this to find out whether other Webafrica customers on Openserve are experiencing the same peak-time problem.

Every evening, roughly 19:00–23:00, my fibre connection deteriorates badly.

During the day it is generally fine, but during the evening I experience:

140–170ms+ latency

Packet loss

Slower download/upload speeds

Unstable latency

Poor performance even to destinations in Cape Town

I have contacted both Webafrica and Openserve, but unfortunately I've basically been sent back and forth without the underlying problem being resolved.

I've now had enough and have submitted my cancellation notice to Webafrica.

Test 1 – Google
traceroute to www.google.com (142.251.156.119), 20 hops max 1 * * * 2 168-210-9-197.ipv4.as20011.net 111.789 ms 125.552 ms 151.682 ms 3 za-wc-tgw-bb-bng-2.as20011.net 140.648 ms 140.785 ms 143.244 ms 4 168-210-9-162.webafrica.ipv4.as20011.net 140.858 ms 168-210-9-160.webafrica.ipv4.as20011.net 157.459 ms * 5 * * * 6 173.194.121.190 165.006 ms * 154.424 ms 7 142.251.156.119 140.717 ms 136.158 ms 140.238 ms

Test 2 – Cloudflare 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 20 hops max 1 * * * 2 168-210-9-197.ipv4.as20011.net 141.281 ms 143.059 ms 168-210-9-185.ipv4.as20011.net 142.635 ms 3 za-wc-tgw-bb-bng-1.as20011.net 145.164 ms 141.790 ms za-wc-tgw-bb-bng-2.as20011.net 142.905 ms 4 * * 168-210-9-160.webafrica.ipv4.as20011.net 143.223 ms 5 cloudflare.ixp.capetown (196.60.70.198) 162.102 ms 152.727 ms 163.965 ms 6 172.68.184.13 142.189 ms * 143.416 ms 7 one.one.one.one (1.1.1.1) 150.629 ms 149.071 ms 140.447 ms
The Cloudflare test is particularly concerning because the route reaches cloudflare.ixp.capetown, yet I'm still seeing roughly 150–160ms latency.

More importantly, the latency is already present at the early AS20011/Webafrica BNG hops, where it is around 140–145ms.

This therefore does not appear to be an international routing issue.

Because the problem occurs consistently during 19:00–23:00 and improves outside peak periods, it looks very much like a congestion or capacity issue somewhere between the Openserve handover and Webafrica's network.

Are there any other Klapmuts / Western Cape Webafrica customers on Openserve experiencing the same?

If so, please post your area, FNO, ISP, ping to 1.1.1.1 and traceroute results so we can compare.

Hi, thanks for tagging us and for putting together such detailed testing. Our official MyBroadband account receives notifications only when it’s tagged in a thread, and we do our best to respond when customers mention us (tag us) for any assistance or discussion here.
Looking at the results you've shared, there are a few things worth separating.

The 140–170ms latency appearing early in the trace is certainly interesting, particularly because it is also present on the Cloudflare test. However, a traceroute showing a high response time at an intermediate hop does not, on its own, prove that hop is introducing the delay. Network devices can deprioritise or rate-limit traceroute/ICMP responses while continuing to forward normal traffic correctly.

What is more useful here is the combination of sustained latency, packet loss and the very clear 19:00–23:00 pattern. The fact that performance improves outside those hours is an important clue and would make peak-period utilisation or congestion somewhere along the path worth investigating.

The Cloudflare result is also interesting. Seeing cloudflare.ixp.capetown does establish that the traffic is reaching a Cape Town exchange point, but the ~150ms response doesn't necessarily mean the physical traffic has travelled internationally. We'd want to establish exactly where the latency is introduced and whether it persists on the actual traffic path, rather than relying on the displayed traceroute hop alone.

There are also multiple paths visible in your tests, including different BNG hops, so comparing results taken during and outside the affected period could help establish whether there is a consistent change in routing or utilisation.

If you're still experiencing this, please DM us your Webafrica account details, and we'll gladly take a closer look from our side. If possible, please also include:

Your service address/suburb
Confirmation that you're on Openserve
Approximate times the issue occurs
A couple of MTR/PingPlotter results taken during 19:00–23:00
The same test taken outside peak hours for comparison
Whether the packet loss is visible all the way to the destination, rather than only on an intermediate hop

That gives the relevant teams something much more useful to work with than a single traceroute.

We're happy to investigate this with you. It's important to us to understand what you're seeing and help get to the bottom of it.

Warm regards,
Webafrica Crew

E=mc2 · Thursday at 7:34 PM

Webafrica Helper said:
Hi, thanks for tagging us and for putting together such detailed testing. Our official MyBroadband account receives notifications only when it’s tagged in a thread, and we do our best to respond when customers mention us (tag us) for any assistance or discussion here.
Looking at the results you've shared, there are a few things worth separating.

The 140–170ms latency appearing early in the trace is certainly interesting, particularly because it is also present on the Cloudflare test. However, a traceroute showing a high response time at an intermediate hop does not, on its own, prove that hop is introducing the delay. Network devices can deprioritise or rate-limit traceroute/ICMP responses while continuing to forward normal traffic correctly.

What is more useful here is the combination of sustained latency, packet loss and the very clear 19:00–23:00 pattern. The fact that performance improves outside those hours is an important clue and would make peak-period utilisation or congestion somewhere along the path worth investigating.

The Cloudflare result is also interesting. Seeing cloudflare.ixp.capetown does establish that the traffic is reaching a Cape Town exchange point, but the ~150ms response doesn't necessarily mean the physical traffic has travelled internationally. We'd want to establish exactly where the latency is introduced and whether it persists on the actual traffic path, rather than relying on the displayed traceroute hop alone.

There are also multiple paths visible in your tests, including different BNG hops, so comparing results taken during and outside the affected period could help establish whether there is a consistent change in routing or utilisation.

If you're still experiencing this, please DM us your Webafrica account details, and we'll gladly take a closer look from our side. If possible, please also include:

Your service address/suburb

Confirmation that you're on Openserve

Approximate times the issue occurs

A couple of MTR/PingPlotter results taken during 19:00–23:00

The same test taken outside peak hours for comparison

Whether the packet loss is visible all the way to the destination, rather than only on an intermediate hop

That gives the relevant teams something much more useful to work with than a single traceroute.

We're happy to investigate this with you. It's important to us to understand what you're seeing and help get to the bottom of it.

Warm regards,
Webafrica Crew

Klapmuts Area / Openserve happens every day afternoon between 18:30 until 23:00

Following up on my post from yesterday.

I ran 10-minute PingPlotter tests this evening (27 Aug, around 19:10) on two separate Openserve lines using Webafrica, and both are showing the same behaviour.

Key findings:

Local router: 1–2 ms
First Webafrica/AS20011 hop (168.210.8.66): 80–117 ms
Cloudflare (1.1.1.1): ~110 ms average
Google: ~106 ms average

The latency jump happens immediately after leaving my LAN and persists all the way to the destination. The intermediate packet loss appears to be ICMP rate limiting, but the high latency is genuine because it continues through to Google and Cloudflare.

This is affecting both independent fibre connections, which makes me suspect a shared Webafrica/Openserve backhaul or AS20011 congestion issue rather than customer equipment.

CrypticZA · Thursday at 7:39 PM

E=mc2 said:
Klapmuts Area / Openserve happens every day afternoon between 18:30 until 23:00

Following up on my post from yesterday.

I ran 10-minute PingPlotter tests this evening (27 Aug, around 19:10) on two separate Openserve lines using Webafrica, and both are showing the same behaviour.

Key findings:

Local router: 1–2 ms

First Webafrica/AS20011 hop (168.210.8.66): 80–117 ms

Cloudflare (1.1.1.1): ~110 ms average

Google: ~106 ms average

The latency jump happens immediately after leaving my LAN and persists all the way to the destination. The intermediate packet loss appears to be ICMP rate limiting, but the high latency is genuine because it continues through to Google and Cloudflare.

This is affecting both independent fibre connections, which makes me suspect a shared Webafrica/Openserve backhaul or AS20011 congestion issue rather than customer equipment.
View attachment 1932740
View attachment 1932739

View attachment 1932738

Being on Openserve you can dial a PPPoE of another ISP. Reach out to an ISP rep on the forum and ask for a test account and test via their network would give you results pretty quickly

E=mc2 · Thursday at 8:19 PM

Update – Tested with a different ISP account, high latency remains

Another update to my testing tonight.

To rule out Webafrica specifically, I changed the PPPoE authentication on the same Openserve connection and tested using a Cool Ideas test account.

The result is interesting: the high latency remains even when using Cool Ideas.

PingPlotter to 1.1.1.1 using the Cool Ideas account:

 192.168.1.1 ~0.7 ms 100.100.101.64 ~142 ms <-- huge jump starts here 100.100.101.64 ~141 ms 154.0.0.234 ~142 ms Cool Ideas 154.0.0.231 ~141 ms Cool Ideas 154.0.2.119 ~144 ms Cool Ideas backbone 172.68.184.13 ~144 ms 1.1.1.1 ~141 ms 
So far I have now tested:

Webafrica PPPoE: approximately 100–140 ms during peak time
Cool Ideas PPPoE: approximately 141 ms during the same peak period

My LAN latency remains below 1–2 ms.

This seems to significantly reduce the likelihood of the problem being Webafrica-specific, because changing to a completely different ISP account did not resolve it.

The common denominator is now the Openserve access/aggregation infrastructure before the traffic reaches the respective ISP networks.

I also have two separate Openserve fibre lines, and both experience the high latency during the evening.

I'm going to repeat the exact same Webafrica and Cool Ideas tests after peak time / around midnight. If both drop back to normal latency outside peak hours, that would seem to point quite strongly towards peak-time congestion somewhere on the shared Openserve path/aggregation.

Webafrica Helper · Friday at 8:36 AM

Morning

Thank you for putting in the effort to gather these results and, importantly, for testing the same performance using another provider. That comparison is particularly useful as it gives our teams additional data points to work with.

We’ve submitted the information shared on this thread, together with the results and details provided during our DM conversation, to our Tech teams. They are actively reviewing the data and working to isolate where the performance degradation is occurring.

We also want to set a clear expectation around the investigation. At this stage, we don’t want to speculate on the cause or attribute the issue to any particular network component until the technical analysis has been completed.

Once the root cause has been established, we’ll be able to determine the appropriate resolution path. If the investigation identifies an issue within the portion of the network managed by us, our teams will take the necessary action to address it. If the evidence points to the fibre access portion of the service, we’ll raise this through the appropriate FNO process so that the relevant network engineers can investigate and address the underlying fault.

The comparison testing you’ve provided should help us distinguish between these possibilities, particularly when looking at latency, packet loss, routing behaviour and whether the performance changes are consistent across different connections.

We’ll keep working with the available data rather than simply closing this off based on an individual speed test or traceroute. Once the Technical team has completed the initial analysis, we’ll provide an update via DM on what they’ve established and the next appropriate step.

Thanks again for working with us on this, @E=mc2. We genuinely appreciate the detailed information you’ve provided.

Warm regards,
Webafrica Crew

Join the MyBroadband community

Get started