6in4 IPv6 Tunnel traffic shaping

[#1]

I found 6in4 tunnel performance to be very heavily traffic shaped, with downloads coming in consistently at 128Kbps, from tunnelbroker.net and my home-grown tunnel using a VPS and /48 prefix.
That was until I encrypted the tunnel between myself and the VPS and I'm now consistently getting around 700Kbps.
I'll do some IPv6 speedtests when I get home to demonstrate.
jim:green Title changed when split off mod:end

[#2]

There should be nothing causing that on our side, but something clearly is doing something.
First just to confirm. Given what you are doing with your connection (per your ping graphing), there is nothing in place that may cause that?
Are you able to provide any packet captures of the tunneled traffic so that we can review what is happening?
Bear in mind, the capture needs to be started before you bring the tunnel up and showing tunneled traffic that is problematic.

[#3]

Hi Phil,
I've not got anything that specifies a fixed data transfer rate, my management is based on queue priority rather than fixed speed pipes.
I'll see if I can get a good capture for you tonight.
Cheers,
A.

[#4]

Quote from: P

Are you able to provide any packet captures of the tunneled traffic so that we can review what is happening? Bear in mind, the capture needs to be started before you bring the tunnel up and showing tunneled traffic that is problematic.

Hi Phil,
I don't need to do anything more than

 tshark -ni tun0 -w tunnel-2.pcap host 212.110.185.xxx

to show the tunnel coming up do I?
I'm using a GRE 6in4 tunnel and monitoring the wan interface as above after dropping the tunnel and re-establishing it shows the encapsulated traffic right away, but with a DSF of 0x00.
Running it encrypted the DSF is 0x80.
But I could be doing the capture wrong, I freely admit this
(Edited as it transpires I'm not using GRE but a 6in4,my knowledge is out of date ;))

[#5]

Hi Avatastic,
I may be wrong... but I think this will capture traffic inside the tunnel, we will only tag the IPv4 packets that make up the tunnel, not the IPv6 traffic inside the tunnel. Perhaps you need to run this command on your normal Ethernet interface (assuming this is the interface the tunnel is routed over).
Matt

[#6]

Indeed, using the -i flag on tun0 is capturing packets on that interface only. This is after the are de-capsulated.
Depending on your system, you probably need to be capturing eth0 or eth1 before initiating the comment to bring the tun0 interface up.

[#7]

tun0 is my  WAN/ppp interface, the GRE 6in4 tunnel runs on gif0.
IOW IPv6 traffic from my lan would go:
(Lan interface) fxp0 -> gif0 -> tun0 -~~ IPv4 INTERNET ~~- tun-vps - eth0 -~~ IPv6 INTERNET ~~
(Edited as above, I'm using a 6in4 not a GRE as previously assumed)

[#8]

Ahh, Ok.
Then yes, it looks like you have the right interface.
Can you provide two captures please. One as you bring up GRE without encryption and one with please?
We may need you to do this again as you bring them up as we check the flows setup on the traffic management switches and see specifically what it is doing.
With what you describe, this should be 0x80 regardless of the encryption.
I gather your capture shows the encapsulated traffic is GRE (protocol 47) in both occasions and you are not using standard IPv6 encapsulation (protocol 41)?

[#9]

Split off to its own topic

[#10]

Cheers Jim.
I'm seeing 41 and 50. I was expecting 47 tbh.
But I'll check again, I'm now not convinced the tunnels dropped when I restarted it the second time which, if I understand it, is why I'm seeing the DSF of 0x00 rather than it being assigned a value?
FWIW, I'm using a FreeBSD generic tunnel interface (gif) at my local end and a Linux IPv6-in-IPv4 interface on the VPS.
I've just read my man pages and it looks like the gif is what FreeBSD now uses for its IP[46] tunnels and the  encapsulating network device (gre) is what is used for encapsulation.
(When i started using freebsd gif tunnels they were encapsulated, I used to have proto 47 open in the firewall for them.)
I'll drop them and re-capture tonight, there are somethings I don't relish doing over ssh!

[#11]

A capture will show plenty of useful information without seeing the tunnel initiation. There is no requirement for this to be in the capture, for it to be correctly shown as 0x80 in the capture (or more accurately, you are not seeing 0x00 just because you didn't restart the tunnel correctly).
The tunnel initiation is important in a capture so that we can look at the first and following packets, which helps us manually lookup what triggered the relevant TOS marking. AKA, it tells us the why, not just the what.
IPv6 in IPv4 is indeed protocol 41, which strongly suggests why you are seeing that for non-encrypted. Proto 50 is ESP which I would expect in a lot of cases for encrypted tunneled payload data.
http://manpages.ubuntu.com/manpages/gutsy/man4/gif.4.html
GIF interfaces don't use GRE, so this goes back to potentially capturing the wrong interface. It sounds like your are using a tunnel in a tunnel. So LAN -> Encapslation A -> Encapsulation B -> PPP -> External network (sounds like your capture is on Encapsulation A, but our network is transporting packets in the format of Encapsulation B).
I am trying to get my head around use of GIF interfaces a little more and the diagnostic output I need from your to understand them further. Could you provide me the output from ifconfig in a PM, so I can see more specific details on the interfaces that are active please?

[#12]

Thanks for the detail via PM.
So the routing table confirms tun0 as the primary interface for IPv4 traffic, which naturally means the encapsulated traffic of the type we want to see should be there.
Next step will be the captures so we can see the actual sample data.

[#13]

Unencrypted capture details sent by PM.
For the observers, to my untrained eye it looks like 'tunnel' doesn't have a start-stop phase and the 6in4 packets are being wrapped and sent without any negotiation.
IOW, my IPv6 traffic would be wrapped up in IPv4 and sent to the remote host with out checking a permanent connection for it had been established. IE, its not a persistent tunnel, packets are wrapped and sent without the sender knowing if they'll get there.
I'm sure Phil and I will have fun working this out and sharing the details with you all

[#14]

I've had to read over them a few times to get my head around them.
The latest of the captures, which shows a mixture of IPv4 and v6 traffic without any encryption, it shows that it is correctly prioritised.
Just a random frame (720) shows a return IPv6 HTTP packet classified as Gold, which is correct for this traffic. Another one (709) is a return IPv4 ICMP ping is correctly classified as Titanium.
I've had to recheck over this thread just to make sure, but you had indicated this was incorrect when capturing unencrypted, but ok when encrypted. Although I have not seen the encrypted version of this yet (which is not in dispute), the unencrypted one looks fine.
Other than IPv6 traffic for HTTP, there was very limited IPv6 traffic (some DNS and the expected IPv6 ICMP packets), but all had correct TOS marking on IPv4.

[#15]

Quote from: avatastic

For the observers, to my untrained eye it looks like 'tunnel' doesn't have a start-stop phase and the 6in4 packets are being wrapped and sent without any negotiation.

That is correct. A 6in4 tunnel is essentially a connectionless tunnel - there is no negotiation, establishment, keepalives etc. It 'exists' (in the loosest sense of the term as it is only virtual) purely on the basis on the configuration in place at either end.

Quote

IOW, my IPv6 traffic would be wrapped up in IPv4 and sent to the remote host with out checking a permanent connection for it had been established. IE, its not a persistent tunnel, packets are wrapped and sent without the sender knowing if they'll get there.

That's right. Packets are sent on a packet-by-packet basis and, being connectionless (i.e. with nothing like TCP managing the connection and providing reliability) if the IPv4 packet doesn't arrive then it is down to the connection manager of the wrapped (IPv6) packet to recover and resend as required.
For problems such as MTU issues en route the encapsulator will try and pass back relevent guidance (e.g. ICMP packet too big messages) if it knows where/who to send them to - the problem here is that not all routers behave the same way in what clues they provide when dropping packets so there is plenty of potential for tunnels to effectively collapse in particular circumstances. For example, if your IPv6 client send packets that are too big to pass through the IPv4 network without fragmentation then an IPv4 ICMP packet-too-big response will be sent by a router to the tunnel start point (i.e. the source address of the IPv4 packet). If that ICMP message doesn't contain enough of the offending packet to identify the IPv6 client address then the tunnel encapsulator will not know where to send an ICMPv6 packet-too-big message too. The IPv6 client may end up sitting there wondering what the problem is and not know how to recover. For this reason MTU sizes may be set as part of the tunnel configuration at the outset.
Mathew