Afrihost - Pure Fibre Feedback Thread Part 2

OryxGazella said:
Thanks Afrigirl and Frogfoot Fibre organizing a technician to be sent out. Root cause was an install the previous day in another flat in our block which damaged our cable.

Since getting reconnected my packet loss hasn't been great.

Interestingly, the IPV4 graph is ugly, but ipv6 is fairly clean (note the differences in scale, from up to 3.8% packet averaged every minute to 0 loss on IPV6 (which I don't roll out to my home network).

Monitoring ips are: 169.1.254.1 and fe80::e678:76ff:febc:ab61

View attachment 1771234View attachment 1771239
Click to expand...
Hi.

I will check with the team and FF.
 
Afrigirl said:
Hi.

I will check with the team and FF.
Click to expand...
Thanks. Just out of interest I changed my monitoring ip to cloudflare's public dns and it looks squeaky clean ~11:10 - 13:00 in first graph. It might be that the ipv4 gateway (169.1.254.1) does not reliably respond to ping requests. I'm going to change it back to the ipv4 gateway for the rest of this day. I'll edit the post to add that graph at the end of today. e:(afrihost gataway has _some_ packet loss from 15:03 to 21:40ish)
1730891113355.png1730922044934.png
 
Last edited:
Afrigirl said:
Hi.

I will check with the team and FF.
Click to expand...
I don't think this is an issue at all. After reading up it's common practice for isps to put lower priority and sometimes drop icmp traffic, which explains why monitoring on cloudflare was fine.

[edit:] Is there some server on afrihost's side that I could use for a health check.
 
OryxGazella said:
Thanks Afrigirl and Frogfoot Fibre organizing a technician to be sent out. Root cause was an install the previous day in another flat in our block which damaged our cable.

Since getting reconnected my packet loss hasn't been great.

Interestingly, the IPV4 graph is ugly, but ipv6 is fairly clean (note the differences in scale, from up to 3.8% packet averaged every minute to 0 loss on IPV6 (which I don't roll out to my home network).

Monitoring ips are: 169.1.254.1 and fe80::e678:76ff:febc:ab61

View attachment 1771234View attachment 1771239
Click to expand...

So fe80: is your router

You can try these.

JHB:
169.1.1.25
2c0f:f4c0::25

CPT:
169.1.2.59
2c0f:f4c0:2000:0:5054:ff:fe52:9b6f

DUR:
169.1.3.19
2c0f:f4c0:3000::301
 
cavedog said:
So fe80: is your router

You can try these.

JHB:
169.1.1.25
2c0f:f4c0::25

CPT:
169.1.2.59
2c0f:f4c0:2000:0:5054:ff:fe52:9b6f

DUR:
169.1.3.19
2c0f:f4c0:3000::301
Click to expand...
Thanks, I have updated my ipv4 & ipv6 monitoring.

fe80::e678:76ff:febc:ab61 <-- Seems to be my isp provided link-local style gateway. It's also the monitoring ip that opnsense chose from the out of the box setup.

When I ping it from the router I have a jitter of about 0.5 ms similar to 2c0f:f4c0:2000:0:5054:ff:fe52:9b6f that you provided.

frogfoot's delegation prefix only allows for 4 vlans, so I don't have ipv6 rolled out anywhere but my guest wifi / vlan.

From the router (igc0 is my wan port):

Code: 
root@router:~ # netstat -rn -f inet6
Routing tables

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::e678:76ff:febc:ab61%igc0 UG        igc0
 
OryxGazella said:
Thanks, I have updated my ipv4 & ipv6 monitoring.

fe80::e678:76ff:febc:ab61 <-- Seems to be my isp provided link-local style gateway. It's also the monitoring ip that opnsense chose from the out of the box setup.

When I ping it from the router I have a jitter of about 0.5 ms similar to 2c0f:f4c0:2000:0:5054:ff:fe52:9b6f that you provided.

frogfoot's delegation prefix only allows for 4 vlans, so I don't have ipv6 rolled out anywhere but my guest wifi / vlan.

From the router (igc0 is my wan port):

Code: 
root@router:~ # netstat -rn -f inet6
Routing tables

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::e678:76ff:febc:ab61%igc0 UG        igc0
Click to expand...
fe80::e678:76ff:febc:ab61 is not an internet route table address. It is a self-assigned IP.
Please continue monitoring the servers Cavedog shared; those are Afrihost's Test servers
 
@Afrigirl

Do you have any idea why this part of the client zone allows you to change the password for a DHCP account?

Afrihost MetroFibre DHCP Reset Password.jpg

Usernames and passwords are not relevant on DHCP, only when using PPPoE.

It is quite an adventure to try and troubleshoot PPPoE fibre accounts when it should be in fact be using DHCP.

Unless I missed it, there is no indication which type of authentication is being used in the client zone?

The icing on the cake is that two neighboring Afrihost and Axxess clients on MetroFibre are on different setups. One is on DHCP and the other on PPPoE.

Who decides which method to use? The ISP or the FNO?
 
Last edited:
Apogee said:
Do you have any idea why this part of the client zone allows you to change the password for a DHCP account?
Click to expand...
We will also be moving to PPPoE soon will our other FNOs, for now we have Vodacom, Openserve, TT Connect on PPPoE and the new FNOs that we are onboarding will be on PPPoE.
Apogee said:
@Afrigirl

Do you have any idea why this part of the client zone allows you to change the password for a DHCP account?

View attachment 1771830

Usernames and passwords are not relevant on DHCP, only when using PPPoE.
Click to expand...
We do use the username for DHCP to map your service to the correct line speed that you signed up for.
Apogee said:
It is quite an adventure to try and troubleshoot PPPoE fibre accounts when it should be in fact be using DHCP.

Unless I missed it, there is no indication which type of authentication is being used in the client zone?

The icing on the cake is that two neighboring Afrihost and Axxess clients on MetroFibre are on different setups. One is on DHCP and the other on PPPoE.

Who decides which method to use? The ISP or the FNO?
Click to expand...
It is the ISP that decides.
What issues is your client experiencing in their line.
 
Afrigirl said:
We will also be moving to PPPoE soon will our other FNOs, for now we have Vodacom, Openserve, TT Connect on PPPoE and the new FNOs that we are onboarding will be on PPPoE.

We do use the username for DHCP to map your service to the correct line speed that you signed up for.

It is the ISP that decides.
What issues is your client experiencing in their line.
Click to expand...
Excellent, thanks so much for the informative answer.

That is very helpful.

Client is back online after I tried DHCP as a last resort when PPPoE just wouldn't authenticate.
 
Apogee said:
Excellent, thanks so much for the informative answer.

That is very helpful.

Client is back online after I tried DHCP as a last resort when PPPoE just wouldn't authenticate.
Click to expand...
You had switched a MFN client to PPPoE?
 
Afrigirl said:
You had switched a MFN client to PPPoE?
Click to expand...
No, the original D-Link router called it a day, as it wouldn't even do a reset.

A brand new router was installed and seeing as everyone and their dog is using PPPoE that is how we tried to set up the WAN connection initially.

If the client zone did not have the option to change the password for this DHCP account, it would have pointed me in the right direction sooner.

I have another client close by on MFN via Axxess and they just switched to PPPoE this month.

That one did not authenticate for two weeks using the PPPoE details on any router we tried, until it spontaneously connected this week.

I noticed they also have an IPv6 WAN address now.
 
Last edited:
Looks like Zoom is no longer working with Dynamic IP.
In-laws fibre went down yesterday, its backup this morning but using PPPoe and Dual Stack.
 
cavedog said:
Metrofibre Gauteng. You guys can now get a /56 pd on ipv6. We increased it from /62.
Click to expand...
Bruh can you post in the IPv6 thread for this stuff? Some of us watch that thread.
Also MFN Nokia okes still on their knees praying.
 
It seems Google is facing some issues with their network in SA and has since last night withdrawn prefixes at NAP JHB. As a result traffic shifted to EU and some traffic is filling from Sydney Australia.

We colocate Google caches in each region and we have our network setup to fill between each other for the best performance. These caches are running hot but still within limits but Google may decide at their discretion when to send traffic elsewhere.

The impact on our network seems minimal, but we keep monitoring and have an open Noc ticket with Google for updates.
 
AfriNatic said:
It seems Google is facing some issues with their network in SA and has since last night withdrawn prefixes at NAP JHB. As a result traffic shifted to EU and some traffic is filling from Sydney Australia.

We colocate Google caches in each region and we have our network setup to fill between each other for the best performance. These caches are running hot but still within limits but Google may decide at their discretion when to send traffic elsewhere.

The impact on our network seems minimal, but we keep monitoring and have an open Noc ticket with Google for updates.
Click to expand...
Was wondering why things were a little slow in loading ie images etc. Must be that.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X