Looking to move from IDNET

Hi,

I am looking to move from IDNET (Not for any performance reasons).

Before I move I want to ensure I have a decent route to:

80.241.77.253

I would really appreciate if someone could post a traceroute on Zen's FTTC network and also provide pings please.

Other then that I am thinking of going for the 400GB package, from what I understand it comes with a static IP unlimited uploads, and there is NO throttling, or traffic shaping (p2p etc..) whatsoever.

From what I recall Zen is pretty similar to iDNet. The only real difference seems to be in the size of the data allowances, where iDNet is usually more generous.

I wouldn't be leaving IDNET to be honest, but I have a routing issue on their network that no other ISP seems to have (I have traceroutes from other ISP - BT, Virgin, O2). I have asked them to look into and they have tried but it seems they can't do anything about it.

Since I depend on this route being as fast as possible for work, I have to move ISP

Hi Snake,

Can you please send me the phone number your service is currently on and also your contact details and ill ask a member of the team to give you a call.

There is clearly something wrong with the route from IDNET to 80.241.77.253. pings > 180 often much greater.

I don't have Zen but it is ok on Virgin Cable pings ~ 17ms.

Also it is OKish from IDNET (ping solid 32) if I go via a VPN (AirVPN NL server). Although not ok if I go from a UK VPN server. So I guess the problem isn't IDNET and hence a switch of ISP is a risky solution.

Why not get a VPN account it only costs 15e for three months. I've not tried it for remote desktop but it is ok for most stuff. I believe it is often used for p2p..

because that IP is a VPN connection, I dont want to (dont think its possible) to VPN to VPN

Its some ISP are affected, its the way the upstream peer is providing the route, it seems, BT, Virgin are not affected.

In reply to a post by nicktb:

There is clearly something wrong with the route from IDNET to 80.241.77.253. pings > 180 often much greater.

...

So I guess the problem isn't IDNET

I'm not sure how you reach that conclusion, as what you posted indicates the opposite.

The problem is not with IDNET per se.

There is a problem in the routing between IDNET and the target IP, but the problem node is actually closer to the target IP end than the IDNET end. Routing from other ISPs may take a path that avoids the problem node but one of my VPN servers, which is completley independent of IDNET, also manifested the same problem.

The point being that an ISP (or even an intermediate node) may arbitrailly change peering and hence the problem may just disappear or appear and the OP is at their mercy. That is why I suggested a VPN solution. The op has indicated he thinks this may interfere with his work VPN. Naively I would expect to be able to connect to a work VPN via this VPN proxy but obviously I don't know the OPs setup.

In reply to a post by nicktb:

The problem is not with IDNET per se.

I'm not sure what you mean. What else is an ISP apart from routing?
I agree with the OP that moving from IDnet will solve the problem, but I'm yet to see a Zen traceroute as requested.

Ok maybe I'm not understanding routing responsibilities properly.

My logic was that IDNET peer with some big boys and they take responsibility for routing/throughput and if there is a far away node that is slow/broken there isn't much IDNET could do about it. But reading what you have written perhaps this view was wrong? Why would an ISP use a poorly performing routing algorithm?

Anyway I'm about to drop IDNET too. In favour of VM which seems to have had no congestion/jitter problems on my line for over a year. So I can't see anything in IDNET's favour.