IPv6 support on Virgin media

---

Anonymous wrote:

SH3 and SH4 were tested back to back on the same line. SH4 achieves near line rate performance with 6in4, SH3 throttles to 20Mbps (as we all see and report). SH2 has been reported to work with similar performance.

tested by whom? who confirmed that? published result? Can you explain Andy's results? and others who reported similar things.

LOL. That's true in theory but unfortunately modern hardware and software are a lot more complex.

is it? an example of a modem/router with the same 6in4 issues?

The Intel Puma architecture

---

has nothing to do with the issue.

Hi,

Just for the hell of it, I've just done another speed test (272 MBits/sec IPv4, 259 MBits/sec IPv6):

Still on SuperHub 3. I think we can say that almost certainly rules out any hardware issue. Don't necessarily expect it to stay like this for too long though...

Andy

I can't speak directly to the SH hardware VM are using, but I work with high-end Cisco switches and routers at work and we see similar problems to this regularly. The ASICs on linecards are highly optimised to process certain types of traffic very, very quickly to be able to maintain line speed. Any type of traffic that isn't specifically optimised gets handed over to the CPU instead. But if you see a large amount of this unexpected traffic (nb. I'm not saying this NON-STANDARD, it's all in the RFCs, it's just traffic that the hardware hasn't been OPTIMISED for) it can overwhelm the CPU in a badly designed system, or just result in poor performance for that traffic type. As I say, I have no knowledge of what's going on inside this hardware, but it seems very possible that this could be the issue here. It may not be on the CPE, either, but somewhere further upstream in the VM/LG network.

---

WiteWulf wrote:

I can't speak directly to the SH hardware VM are using, but I work with high-end Cisco switches and routers at work and we see similar problems to this regularly. The ASICs on linecards are highly optimised to process certain types of traffic very, very quickly to be able to maintain line speed.

We are on the same page here, yes high-end routers do that, but it is configurable behavior, you can configure it based on any protocol number. 6in4 is really simple if you not trying to extract encapsulated information from it, which makes no sense to do.

Any type of traffic that isn't specifically optimised gets handed over to the CPU instead. But if you see a large amount of this unexpected traffic (nb. I'm not saying this NON-STANDARD, it's all in the RFCs, it's just traffic that the hardware hasn't been OPTIMISED for) it can overwhelm the CPU in a badly designed system, or just result in poor performance for that traffic type.

but this "overwhelm" doesn't result in a constant 12mbit cap.

It may not be on the CPE, either, but somewhere further upstream in the VM/LG network.

---

This is what we are talking about, the issue is in the VM network, but the hardware used in the network is capable to cope with 6in4 with no problem unless configured to limit traffic.

I'm not wanting to be argumentative, nor completely agree/disagree with each of the assertions, however there are accepted flaws in the Intel Puma 6 CPU. Just look at the US class action lawsuit on the matter (e.g. Schubert Jonckheer & Kolbe Puma 6 Chipset Defect). When there is such an issue that affects a hardware platform, and in this case I would call it random, for the processing of packet data then all bets are off for other data types that are not well knows and processed through a hardware path. All other packets regardless of router or modem mode will traverse through the CPU. In Linux, when the in bridge mode the packets still use the kernel and thus the Puma CPU. This bit is speculation, but given the GUI is still accessible, the Hub 3 is running other applications which will take resource from the CPU at some level - and in an already constrained system could cause issues regardless of mode. I'm not a HFC expert, but as I understand from reading each consumer segment (CPE) also receives each of the packets (e.g. for neighbours) and filters them, not to mention the variation of local network traffic requiring WAN access that can affect any individual setup.

I also suspect there will be varying E2E network "issues" (e.g. network QoS or DPI or switch implementations) as well as those established and there may even be better binned versions of the Puma 6 (pure luck) that perform better. 

The only real way to prove the Hub 3 is the root cause, rather than just another part of the problem is via a standalone test configuration in a lab environment (and that's unlikely to happen), running with a varying degree of local network scenarios.

Disclaimer: I'm not running 6in4, just interested in the progress (or lack of) IPv6 on Virgin Media's network.

It's doable on the Hub 3, just how and when VM decide to implement it. 

---

jonathanm wrote:

accepted flaws in the Intel Puma 6 CPU.

has nothing to do with the VM 6in4 issue, not even similar or related.

This bit is speculation, but given the GUI is still accessible, the Hub 3 is running other applications which will take resource from the CPU at some level - and in an already constrained system could cause issues regardless of mode. I'm not a HFC expert, but as I understand from reading each consumer segment (CPE) also receives each of the packets (e.g. for neighbours) and filters them, not to mention the variation of local network traffic requiring WAN access that can affect any individual setup.

can't see how any of this will affect 6in4, even in full software mode it is a very light and trivial task, there is no difference in processing 6in4 or UDP package in this matter for the router mode. additionally, examples on the forum ruled out your theory several times, thanks Andy who confirmed that recently again.

Disclaimer: I'm not running 6in4, just interested in the progress (or lack of) IPv6 on Virgin Media's network.

---

then try and see for yourself, you can check latency, speeds, and CPU utilization, other traffic, etc, there are no signs of high CPU usage for 6in4 traffic on Hub 3, several users confirmed having full speed at times on Hub 3. I do not understand why you suddenly decided to believe this is Hub 3 issue? because VM said so? we know they are not competent enough to even setup the tunnel.

I think his point is more of the fact that without a ton of testing, where the environment can be fixed at all times, we will never discover where the fault really is.

There's several equipment places it could be, and in those places it could be hardware or firm/software based.  Virgin are not going to invest the time and effort to find this problem.  Perhaps a few staff to look at it in passing and that's about it.

If the problem goes away (or is not initially seen) when testing on newer hardware then they will just stick to the idea that it will go away.  Plus they are probably of the view that once we move to IPv6 it wont matter.

@VMCopperUser, indeed, my point exactly. 

The rough evidence/anecdotes as I've seen it so far (as reported by users or through news articles, and I may have missed some):

• There have been no reported issues with 6in4 from Hub 4 users (I think?)
• Hub 3 users have reported sporadic successes achieving their connection speed (or near enough), with a range of 12Mbps, 20Mbps and full speed (sometimes). 
• Other network/switch issues have not been ruled out. 
• Having been a software/hardware tester something slightly nonstandard (or should I say non-typical) is likely not the most throughly tested and cannot be assumed to be trivial for the components handling it (whatever/where ever in the path they are)
• The Hub 3 has had problems and VM are, reportedly, offering users Hub 4's for free in some areas even if not on the Gigabit package. 

In short, we don't really know. 

Personally, there's enough going on in the world, work & personal projects, that testing 6in4 is not something I currently care enough about to add (plus I can only control my local network variables and can only test CPU utilisation by seeing whether it gets hotter than it already does :-D) ... Testing with a "proper" v6 implementation is something different I'd be happy to do however, for which I hope VM engineers are working on making it so 🙂 

Just to reiterate James comment. I too have been in contact with the engineering team at VM. They have run back to back performance tests of SH3 and SH4 in their lab with Hurricane Electric 6in4 tunnels. The results they saw were identical to the other 6in4 tunnel users in this thread with poor performance of the SH3.

This doesn't explain adhawkins result where the SH3 performs well. I wonder if this is because they were connected to a different flavour of UBR from the majority of the VM estate. This could interact with the SH3 in a different way. DOCSIS 3.x is a complicated beast.

Contrary to ksim's assertions (😂) the VM engineering team appear to be very competent. I totally understand why they have appeared to put this issue on the back burner. It's a pretty minority interest, sadly, even compared to the wider deployment of IPv6.

I've just had an email from virgin telling me that "we’re constantly investing in our network and to help us continue this work, the price of your package will go up by £3.50 a month".

hmm.. they're not investing it in ipv6 from the available evidence...