tserv1.mci3 bandwith issues.

[Kizaki]

Is tserv1.mci3 having issues?

I haven't been able to get more than about 1 -2 megabit off it in the past few weeks.  YouTube runs very slow on it.  I ended up having to disable IPv6 on several of my computers in order to be able to use YouTube without it buffering constantly.

I used to get about 25-30 Mbit/s off that tunnel before.

[kasperd]

If you are lucky another user of the same tunnel server will read this thread and tell us, if he has seen the same problem. But you might not get any response in this thread. If you think the problem is on the tunnel server or the HE network, then you should email ipv6@he.net about it.

[Kizaki]

I don't know if the problem is with HE or 1and1.  I disabled IPv6 on some of my individual computers so sites like YouTube are usable again.  Windows prefers to use IPv6 over IPv4, and it's causing a ton of problems.

I used to get over 30-40Mbit/s over that tunnel, but I am not sure what happened to slow it down so much.  Anyone have any ideas?  At this point I am going to have to take down the IPv6 tunnel.

Here is a trace-route to the tunnel server.

traceroute to 216.66.77.230 (216.66.77.230), 30 hops max, 60 byte packets
1  10.255.255.253 (10.255.255.253)  0.985 ms  1.237 ms  1.241 ms
2  vl-1950.gw-distp-a.slr.lxa.oneandone.net (74.208.1.162)  0.406 ms  0.422 ms  0.665 ms
3  ae-1.bb-d.slr.lxa.us.oneandone.net (74.208.1.97)  0.645 ms  0.651 ms  0.908 ms
4  ae-10.bb-d.ga.mkc.us.oneandone.net (74.208.1.66)  0.926 ms  1.177 ms  1.176 ms
5  206.51.7.5 (206.51.7.5)  0.903 ms  1.146 ms  1.156 ms
6  10gigabitethernet1-1.core1.mci3.he.net (184.105.213.38)  0.897 ms  1.040 ms  1.032 ms
7  tserv1.mci3.he.net (216.66.77.230)  0.878 ms  0.856 ms  1.083 ms

[Kizaki]

This is the speeds I got before.




This is what I get now

[tpnet6]

This is the speeds I got before.




This is what I get now

Based on what you have just posted.  You are connected to a tunnel server in Kansas City.  Your test before was to server in California.  Your test now is to a server in France.  Testing overseas is most likely what is causing your issue, although I cannot say for sure.  I get very poor speeds to that speed test server in france right now as well.  Upload under 1Mbit. 

[Kizaki]

The California server isn't listed anymore.  I wish I had tested on the French server months ago to compare.  That is the best I could do thou.  I only get about 2Mbit/s from YouTube over IPv6.  

Does HE have it's own speed test tool?  Is there a way to find out if the connection between 1and1 and HE is saturated?

[kasperd]

Here are results using the Frankfurt tunnel server for comparison. For some unknown reason most of the speed test servers give me faster results when tunnelling IPv6 over IPv4 than by using IPv4 directly.

[tpnet6]

Kizaki:  I PM'd you with a link to a speedtest.net server that I operate over IPv6. I dont have native IPv6 yet, I am running bgp over an HE tunnel at the moment.  Latency may look a bit high because my server is in toronto canada and my tunnel server is in virginia.

[broquea]

You can email ipv6@he.net and have them see if there are any saturation issues (aka attacks). You can also ask if they have an iperf testing server available. I can turn one up on my fmt2 colo if you need, but I'm fairly certain HE can provide you with one to test against.

[Kizaki]

I appreciate the help you guys provided.

I ended up taking down the tunnel; it slowed down even further. 

I attempted to inquire from 1and1 the status of their connection to the Kansas city internet exchange.  This is where HE and 1and1 are peered.  They both apparently have a 1 gigabit Ethernet connection to that exchange according to this site, http://www.kcix.net/members.html.  I haven't been able to get that information, and I honestly give up.

What I might end up doing is getting rid of 1and1 and finding a new hosting provider.  The IPv6 issue isn't the only problem I am having with 1and1.  Their connection to Time Warner cable goes though Telia, and it's just bad.
 

[Kizaki]

My mistake about Telia; 1and1 seems to use XO to get to Time Warner.  Time Warner uses Telia to get to 1and1.  I am not a network admin, so I forget that these routes are asymmetric a lot of times.

I did a little bit of research on BGP, and from what I understand you can control how your traffic gets to it's destination, but not how it arrives to you.  Correct me if I am wrong thou, I am still trying to learn how BGP works.

[kasperd]

I did a little bit of research on BGP, and from what I understand you can control how your traffic gets to it's destination, but not how it arrives to you.  Correct me if I am wrong thou, I am still trying to learn how BGP works.

You have some control over both. But obviously you have more control over where you send packets than you do over which direction others send them to you.

A network with multiple peerings does not have to announce its entire address space through all peerings. If some of your addresses are announced through only one of your peerings, then all packets to those addresses have to go through that peering. But that isn't good for reliability.

You can also get some control by splitting your address space into longer prefixes. For example if you are announcing 2001:db8::/32, then you can split that in half and announce both 2001:db8::/33 and 2001:db8:8000::/33. Anybody who can reach the /33s are supposed to use those. The /32 is only to be used by sources, which cannot reach the /33s. This indicates a preference, which as far as I recall is mandatory to follow according to some standard. But of course it is still technically possible for some sources to ignore that and send through the /32 anyway.

Another way to indicate a preference is by making the AS path longer. By announcing the same prefix through two different peerings, you can make one of them less preferred by sending a longer AS path. If there is only a small difference between the length of the path you announce, then there may be networks which see them as having the same length because the actual between the source and your network is different and cancels out the difference in your announcements.

None of the above methods can specify which source IPs they apply to. You announce the prefix through some peering, and only by looking at the packets you receive, will you learn for sure, which source IPs got to use those announcements. The set of IPs that are announced back to you through the peering will give you some hint about which source IPs you can expect to see.

I have also read about some people using a hack with the AS path to gain a bit more control over who uses that path. They simply insert a few ASes, which they do not want to use the announcement in the AS path, which they are announcing. This makes the path look longer and thus less preferred, but the specific ASes, which got inserted will never use the path, as it will look to them as if this announced path would lead to a loop.

[Kizaki]

I just tried setting up a tunnel in Chicago now that I have a lot of spare time; I get 20 - 30 Mbit/s off it.

The Kansas city server is still limited to only a few Mbit/s for some reason. It bursts up to 10Mbit/s then drops off to about 2-3mbit/s.  Anyone know if some of the tunnel servers are rate limited?

I would prefer to keep the Kansas city tunnel since the latency to it is under 1 ms.  The Chicago server has a latency of 15ms from me.