Web Squad ISP

Status
Not open for further replies.
When is SADV and Frogfoot coming? :D

We're getting more and more requests regarding these two networks as well as Octotel and Openserve. I can't provide a set timeline yet, there are a few last issues to sort out and we'll confirm soonest. Thank you for the continued interest, it's definitely got us scrambling to finish up.
 
So my experience:
Signed up with web squad on Sunday, PMd @websquadza a couple of questions that I had.
He answered quickly...on Sunday evening i might add.

Accounts organised the Vumatel installation invoice for me on Monday which i paid.
Dealt with Martha over the phone, she was friendly and super helpful!
Called again a couple of times to follow up, never waited in a call queue, each time the staff where friendly, and answered all my questions.
Vuma did the install on Thursday.
Called WebSquad at 5:30 to ask if i could pay so i could get my login detail.
Lady said they will only invoice the next day, but gave me login details so i could connect anyways.
Static ip was configured, and my line is live.
I also really likes that the staff dont just give you standard replies, and dont treat you like an idiot.
They where all super friendly!
Thank you @websquadza , and keep up the epic work!!!!




International seems a bit weak, but im still a happy camper. (Am on wifi)

EDIT: Downloads from my Hetzner Germany server are maxing out my line so all good :)

Thank you for the great feedback. Always good to hear our team is keeping clients happy!
 
We're getting more and more requests regarding these two networks as well as Octotel and Openserve. I can't provide a set timeline yet, there are a few last issues to sort out and we'll confirm soonest. Thank you for the continued interest, it's definitely got us scrambling to finish up.

Octotel before end March 2019? :unsure:
 
That MTR looks good, a little loss on RD's upstream there (Hop 16 and 17), return route is via our HE route. Made a small adjustment our end, can you try again now and send updated MTR?
Packet loss is creating slow single thread performance of 150k to france.

This is a new problem. The sole thing I use my super duper fibre is to stream real debrid, and right now it's not working, I assume it's your upsteam provider.

I think maybe I'll go back to LTE.
 
Working fine on rain LTE:
View attachment 624990
As I mentioned, the MTR you sent me also shows that it's working fine, there are no errors on our MTR. I can't tell RD how to get back to our network. The above traceroute and the ones from my test show us reaching RD via Amsterdam IX (AMS-IX).

Can you try again? I've switched your routes over.
 
That MTR looks good, a little loss on RD's upstream there (Hop 16 and 17), return route is via our HE route. Made a small adjustment our end, can you try again now and send updated MTR?
Sorry, I switched off and stopped reading after reading mtr looks good and a little loss.

Cool beans, I will test again if you say you made a change, that was quick if it works.

I'll let you know.
 
As I mentioned, the MTR you sent me also shows that it's working fine, there are no errors on our MTR. I can't tell RD how to get back to our network. The above traceroute and the ones from my test show us reaching RD via Amsterdam IX (AMS-IX).

Can you try again? I've switched your routes over.
It's fixed :love:
Untitled.png
 
Packet loss is creating slow single thread performance of 150k to france.

This is a new problem. The sole thing I use my super duper fibre is to stream real debrid, and right now it's not working, I assume it's your upsteam provider.

I think maybe I'll go back to LTE.

Those losses aren't on our upstream unfortunately - they're on RDs. NTT is 2 hops away and directly attached to RD. Nonetheless we are able to work around these things, I've tried a switch. What I do see is that our one upstream is suffering a large latency difference to the same destination, which means they've lost a route to Europe- increasing latency. The difference between the two upstreams is about 50-60ms at the moment (they're usually identical).
 
Now this is the kind of thing I like, never experienced service like this.

5 stars :thumbsup:

EDIT: Thank You for solving so quickly.
 
Last edited:

Thanks for the feedback. Interesting behaviour from RD there... So as you can see, the logical return route is the one above, it's shorter and has fewer AS hops (networks in between). It never stopped learning about your IP from both our upstreams - We advertise equally on all upstreams to ensure we're always visible to the outside world. Basically, RD sees two roads to you, and should know which is shortest (not necessarily best quality - that's the only caveat of BGP). But it chose the route with more hops because that's where you sent your request from (which in today's case was also the the route with a performance issue).:unsure:
 
Thanks for the feedback. Interesting behaviour from RD there... So as you can see, the logical return route is the one above, it's shorter and has fewer AS hops (networks in between). It never stopped learning about your IP from both our upstreams - We advertise equally on all upstreams to ensure we're always visible to the outside world. Basically, RD sees two roads to you, and should know which is shortest (not necessarily best quality - that's the only caveat of BGP). But it chose the route with more hops because that's where you sent your request from (which in today's case was also the the route with a performance issue).:unsure:
Maybe this answers your question because it fell over again:
Untitled.png
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X