evilsee
Senior Member
My router would not authenticate with two Web africa accounts I have, I called there support line, and they have a message stating that there might be authentication problems, but no indication of when it will be fixed.
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: What's the most interesting small town you've visited in South Africa?
Web Africa - Problems
- Thread starter evilsee
- Start date
Prof.Merlin
Expert Member
WAJeff
Web Africa Representative
Hi guys,
Just after the migration we did experience authentication issues on our network. This seemed to have been related to server load at the time.
I can however confirm that this has been resolved. All accounts should be authenticating as per normal.
If anyone is still experiencing any issues please contact us on 0861 555 222 or you can mail [email protected]
Have a great evening further.
Just after the migration we did experience authentication issues on our network. This seemed to have been related to server load at the time.
I can however confirm that this has been resolved. All accounts should be authenticating as per normal.
If anyone is still experiencing any issues please contact us on 0861 555 222 or you can mail [email protected]
Have a great evening further.
Oreomitch
Senior Member
I concur...I had the "Invalid Username/password" message too...works great now.
Moederloos
Honorary Master
Driving me mad - my WA account fails to do anything with DNS despite auto DNS settings. Switch to any one of my other ISP DSL accounts and everything works just fine.
Getting real annoyed now - paying double for BW and it does not work.
Getting real annoyed now - paying double for BW and it does not work.
RoloTomasi
Well-Known Member
Did you flush the dns? Go to command prompt.
C:\>ipconfig /flushdns
Also reboot the router.
Prof.Merlin
Expert Member
that command will not workHi Moederloos
There is an issue affecting a small number of users in certain areas.
This has been tracked down to the following issue: Some regions the ESR (Telkom Edge routers) are not increasing the IP allocation for WA IP's fast enough due to the huge influx of new IP's onto the IPC network. The ESR also refreshes every 20 minutes and increases the pool size allowing more users to connect.
Telkom have been very helpful and are working to get it resolved ASAP
In the meantime we are setting up @wadsl.s multirealm capability on shaped. This means those users can get a SAIX IP if they use .s and are having trouble getting a WA one as a temporary fix. Will let you know once that is live.
I am a bit upset of the service levels experienced during the migration. Honestly I just switched our unshaped account to .v alternative and will leave it there for a while.
A really think that more pro-active communication should have taken place and migration should have been done in smaller blocks over a longer period ( and preferably over weekends).
And for the live of me I have not yet gotten a descent answer on what the exact difference is between their "shaped" and "unshaped" services if everything seems to happen over the same network. I got an answer about packet prioritization which is a bit irritating. The reason unshaped bandwidth is more expensive from other providers is that they have dedicated bandwidth allocation in their pool (separate from shaped services) with lower contention ratios. If VPN traffic is mixed with peer-to-peer traffic your VPN latency is going to suck even if it is prioritized - because you can only control outbound priority on your own network, peer-to-peer traffic just saturates the inbound connections and you cannot adjust the priority of that traffic. I must admit I have not yet seen performance figures ( we'll see after migration is complete and everything else is in place), but I am irritated of bandwidth costing double with only a dubious technical explanation on why this is so.
A really think that more pro-active communication should have taken place and migration should have been done in smaller blocks over a longer period ( and preferably over weekends).
And for the live of me I have not yet gotten a descent answer on what the exact difference is between their "shaped" and "unshaped" services if everything seems to happen over the same network. I got an answer about packet prioritization which is a bit irritating. The reason unshaped bandwidth is more expensive from other providers is that they have dedicated bandwidth allocation in their pool (separate from shaped services) with lower contention ratios. If VPN traffic is mixed with peer-to-peer traffic your VPN latency is going to suck even if it is prioritized - because you can only control outbound priority on your own network, peer-to-peer traffic just saturates the inbound connections and you cannot adjust the priority of that traffic. I must admit I have not yet seen performance figures ( we'll see after migration is complete and everything else is in place), but I am irritated of bandwidth costing double with only a dubious technical explanation on why this is so.
Prof.Merlin
Expert Member
Hi wamatt
Thanks for the response.
I work with Moederloos and we have been getting bad service from Web Africa for quite a while. In the beginning, Web Africa was all about service and support, but now its just like the other ISP's out there.
Not only ADSL, but connectivity to our servers hosted with Web Africa go down more and more. The communication from Web Africa to your clients is also not half of what it should be.
We are in a business where our website needs to be accessed all the time, even if its 3am on a sunday morning.
I know that some problems do occur no matter how much you try to avoid it, but it is just getting worse and worse. My own server that i pay R20 a month for has better uptime than Web Africa. AND it is hosted internationally.
I know you have migrated to a new network, but if these problems do not stop, we are going to have to move all connectivity away from Web Africa. We pay Web Africa more than R10 000 and i personally think that the service and support we get is not worth that R10 000.
Thanks
Service levels
@Prof.Merlin
Thank you for the feedback.
We most certainly are still all about our support and service and it is certainly most troubling to hear that you have not been experiencing this.
The decision to launch our own network has been made specifically with our customers in mind, that being said, this allows us to optimize our network according to what our customers need. The IPC network provides us far more control over the service levels provided allowing us to prevent/rectify outages that may have previously been out of our control.
Would you be so kind as to message me your customer details as I would like to further discuss your concerns.
@Prof.Merlin
Thank you for the feedback.
We most certainly are still all about our support and service and it is certainly most troubling to hear that you have not been experiencing this.
The decision to launch our own network has been made specifically with our customers in mind, that being said, this allows us to optimize our network according to what our customers need. The IPC network provides us far more control over the service levels provided allowing us to prevent/rectify outages that may have previously been out of our control.
Would you be so kind as to message me your customer details as I would like to further discuss your concerns.
Let me just step in there and give a bit of background:
We did 2 months of testing (amidst a market that is wanting things immediately).
- We went live on Thursday 3pm in the quietest month December. This was chosen for the following reasons. If we cut over on Friday, most Telkom tech's are off and we may have had downtime the whole weekend. Engineers also go home at 5 so we decide 3pm is the least interruption and most business work has been done.
- We did extensive planning ans migration strategy meetings. We put in place special pages that inform users how to get rid of old proxy settings. We rewrote the SMTP dns to use our own to help ease things etc. That said users are always going to have quirky settings and non-standard things that will break, those sort of things we've dealt with today on a case by case basis.
@wadsl is the largest migration ever done by Telkom (20000+ in one go). So it was a first for us and their team and considering its been a huge success (Thanks guys). Our clients are reporting a stable and fast network and the call center was never swamped (albeit very busy) Remember its an unprecedented switch over.
Furthermore to answer you on the splitting it up, it was not technically possible to split it into smaller chunks because you can only move a whole realm at a time. We have still a few hundred smaller realms to go though which we will get to next week.
On shaped vs unshaped question. Shaped is set to perform equal or better to the old SAIX shaped and unshaped has absolutely no shaping on it. Hence if there is congestion the unshaped user gets priority thus its better guarantees.
Hope that helps give you a bit more of a behind the scenes view
Cheers
Last edited:
1) Fair enough on the realm migration - you were obviously dependent on Telkom.
2) The unshaped vs. shaped issue is still not resolved. Let try and explain it further - on your router(s) you might classify packets by account type. But you can only do it once the packets have reached your router(s). So while you might set up your router to prioritize what traffic gets send first (outbound shaping) you can do nothing to traffic on your inbound links until it reaches your router. Hence the SAIX unshaped accounts actually have a different (sub)network (look at the IP's). If somebody starts up a peer to peer application that uses UDP without flow control it will simply try to saturate the inbound link - and without different networks you simply can't control it. While I believe you might have some very nifty outbound shaping in place, I have not heard any word on how inbound traffic will be handled. Unless you have so much bandwidth that this issue doesn't matter - but then again there would be no real differentiators between your shaped and unshaped packages.
Now don't get me wrong - I am very excited about the massive move you guys are making. And kudos for dropping server bandwidth prices. But you are growing bigger and you are moving up in the world and that places on you additional responsibility. I can say I WANT better prices but I absolutely NEED connectivity to work (or it is my ass). I can't tell my boss that work in the office is at a standstill because I am loyal to WebAfrica, and I believe in what they are doing.
Tinuva
The Magician
While in essence what you are saying about shaping is true, it is actually quite possible to do shaping on inbound bandwidth, as long as you know how. By choosing which protocol;s packets you drop by yourself you have a bit of control as to which packets still get pumped to your network at fullspeed and which ones you forcefully slow down by dropping their packets causing the sender to send slower to prevent it from resending packets too much.
Trust me, shaping is a very interesting concept but there are way around limitations and in the end you still get the same affect. I bet if you ask the trial testers, there were a point where p2p was completely killed with shaping to give other protocols the lead. It is essentially the same. Only difference is, now p2p has a fixed pool, and other protocols get priority once links get congested. With unshaped accounts having their own seperate pool of bandwidth which in turn give them their own contention ratio.
Trust me, shaping is a very interesting concept but there are way around limitations and in the end you still get the same affect. I bet if you ask the trial testers, there were a point where p2p was completely killed with shaping to give other protocols the lead. It is essentially the same. Only difference is, now p2p has a fixed pool, and other protocols get priority once links get congested. With unshaped accounts having their own seperate pool of bandwidth which in turn give them their own contention ratio.
Agreed - but this relies either on TCP flow control OR some UDP flow control mechanism. The problem with some peer-to-peer clients is that they simply use UDP without trying to do any flow control.And the real problem only rears its ugly head when P2P use UDP, encrypt the packets and run over VPN ports. Then there is no way to make distinction between my VPN traffic and P2P traffic.
P2P is an arms race. People are going out of their way worldwide to prevent ISP traffic shaping on P2P. And it won't be rocket science to bypass any shaping strategy. You simply download the appropriate P2P software and tick a couple of check boxes. http://www.google.com/search?q=bypass+traffic+shaping+P2P.
Yes. Giving unshaped accounts their own sub-network allowing traffic prioritization information to be propagated to the upstream routers will solve the problem. And this is exactly my unanswered question - does the new unshaped accounts have their own dedicated pool of bandwidth? So far the only response I have is that packets are prioritized.
Sorry - I seem like an attack dog. I don't try to be.I thought there might be a quick answer. I am actually hoping that the real long term answer is "Traffic Management and Bandwidth on our new network is so good that you can actually run your VPN over the shaped packages."
I will switch the accounts over tomorrow night and monitor the situation. In fact if they can delivery a consistent ~250ms latency to Europe over the next couple of months I would be happy and will probably send flowers! To give context - we work on application servers [not web based] in Europe, and unfortunately every click of the mouse depends on round trip latency. If somebody clicks a button and has to wait a couple of seconds for something to happen they normally are very unhappy and unproductive.
Tinuva
The Magician
I actually ended my previous post with the answer you were seeking.
Remember though, the ISP is doing the outbound traffic to the client, and such have full control over what the they upload to the client. Also, when one do now know what kind of traffic packets are, ie. general SSL doesn;t have as high priority as https_browsing, purely because that could be encrypted torrents. Most VPN traffic actually have a known footprint, and then some actually do not even use UDP/TCP but instead GRE/IPSEC and other protocols which is even easier to recognize.
But in the end, shaping is not there to restrict users, but to give them all a better experience.
Short answer, yes.Tinuva said:
Remember though, the ISP is doing the outbound traffic to the client, and such have full control over what the they upload to the client. Also, when one do now know what kind of traffic packets are, ie. general SSL doesn;t have as high priority as https_browsing, purely because that could be encrypted torrents. Most VPN traffic actually have a known footprint, and then some actually do not even use UDP/TCP but instead GRE/IPSEC and other protocols which is even easier to recognize.
But in the end, shaping is not there to restrict users, but to give them all a better experience.
Prof.Merlin
Expert Member
Something else that bothers me - and maybe i am missing something as to why this is happening.
We have a server at Web Africa(Cape Town) and a server at Internet Solutions in Bryanston). I live in Joburg and approx 20km from Bryanston.
Doing a trace to our server in cape town from joburg, gives me 8 hops(which is better than the previous 13). But doing a trace to our server 20km from me, gives me 15 hops.
How is that possible?
We have a server at Web Africa(Cape Town) and a server at Internet Solutions in Bryanston). I live in Joburg and approx 20km from Bryanston.
Doing a trace to our server in cape town from joburg, gives me 8 hops(which is better than the previous 13). But doing a trace to our server 20km from me, gives me 15 hops.
How is that possible?
Last edited:
MidnightWizard
Executive Member
Configuration
MY guess would be BAD routing
Do a tracert / traceroute to both and look up the IP's that are shown to see whose they are and where they are.
You could also do a ping on them.
I am under the impression that software exists that will do all this and MORE with the push of a couple of buttons. ( Network exploration and Identification )
MW
MY guess would be BAD routing
Do a tracert / traceroute to both and look up the IP's that are shown to see whose they are and where they are.
You could also do a ping on them.
I am under the impression that software exists that will do all this and MORE with the push of a couple of buttons. ( Network exploration and Identification )
MW
I get a steady 250-260ms from Atlanta (over ADSL) to the WA edge in CPT and it takes me 90-100ms to get to London. Ping times from the Atlanta datacentre are a little lower in the 240-255ms range.
You also have to remember that once it leaves the WA controlled network they can only address any issues with upstreams they are directly connected to.
You need to be introduced to the dark side of the web my friend. Any shaped connection can be beaten if it relies on filtering rules alone! But my original issue seems to have been a non-issue for the moment - we comfortably get 260ms pings to our German servers on our WebAfrica unshaped account at work. The only real issue is that we also get the same 260ms pings using the shaped WebAfrica connection !!!!
So if WA got enough bandwidth for shaping to be a non-issue that is frekking awesome. But tip for now - instead of paying for an unshaped connection anywhere else.. just get a shaped connection from WA ... it actually performs better latency wise than a SAIX unshaped connection!