6to4 status (again)

[Martin Millnert]

Hi,

On Tue, 2013-02-26 at 12:57 +0200, Max Tulyev wrote:
> It does. Other similar configurations routes 20+ Gbps easy, but IPv4.
> 
> On 26.02.13 12:36, Ivan Pepelnjak wrote:
> > Maybe it's time someone rewrites that code ;) The box you have should be
> > pushing Gbps. See also
> >
> > http://erratasec.blogspot.co.at/2013/02/custom-stack-it-goes-to-11.html

(I once worked in a project on a (very proprietary) stack on x86 that do
40Gbps @ 64B on 1x nehalem core. available cycles is *not* the
bottleneck in the hardware... )

> > I know it's not going to happen ...
> > Ivan

I once considered investing a lot of time into making miredo fast, but
decided I don't get paid for it so I let go of that thought quite fast.
It's not a problem of miredo per se, but the whole miredo on top of
linux stack issues... as ivans link describes.

The CPU spends like 97%+ of its time *not* doing packet forwarding when
you use miredo on Linux today; it's mostly busy with context switching
and suboptimal & non-optimized per-packet operations.
Put differently, the memory bus is pushing like 97% instructions and 3%
"valueable" Data.



As a side note, in regards to:

> The most of the traffic is 6to4<->Teredo. The second position is for
> BitTorrent. But a 'good' traffic is significally increased too, as
> there is Facebook, Google, Yandex, Vkontakte enabled IPv6 by default.

What do you think is inside the 6to4-Teredo traffic?

Best regards,
Martin

> > On 26.02.2013 11:29 , Max Tulyev wrote:
> >> I believe you are using some kind of Linux/BSD box as 6to4 relay. So
> >> just launch tcpdump/ethereal/wireshark and see it ;)
> >>
> >> We operate the 6to4 relay in Ukraine. There is 400mbps traffic, and it
> >> seems it hits maximum available CPU usage (dual QuadXeon L5420) during
> >> a peak time.
> >>
> >> The most of the traffic is 6to4<->Teredo. The second position is for
> >> BitTorrent. But a 'good' traffic is significally increased too, as
> >> there is Facebook, Google, Yandex, Vkontakte enabled IPv6 by default.
> >>
> >> I see the root of the problem is in algoritm chooses the IPv4/IPv6
> >> preference. Mostly it uses IPv6 if it is available, whatever IPv4 path
> >> enabled or not. So it used to connect two IPv4-enabled boxes CAN
> >> connect through IPv4 - through IPv4<->6to4<->teredo<->IPv4 path. It is
> >> not good at all, and should be explained good to all vendors.
> >>
> >> May be it will be a good idea to block some kind of IPv6 traffic on
> >> the relay to force use IPv4 instead of chains of tunnels?
> >>
> >> On 25.02.13 23:48, Kevin Day wrote:
> >>>
> >>> I know this was brought up in November, but I didn't see much of a
> >>> consensus…
> >>>
> >>> We run one of the public 6to4 relays. Lately traffic to it has been
> >>> growing very rapidly and I'm really not sure why. Other people
> >>> shutting their public relays down? More AAAA records are making more
> >>> people fall back to 6to4? Idiots using it for DDoS?
> >>>
> >>> For most of 2012 the usage averaged about 50-100mbps, but lately
> >>> we're seeing sustained levels of 500mbps-900mbps. I'd rather not
> >>> deploy 10GE on our 6to4 box just to handle the traffic growth.
> >>>
> >>> Has anyone here looked at public 6to4 usage recently and seen similar
> >>> trends?
> >>>
> >>> Part of me is thinking we should just rate limit the box to something
> >>> more reasonable. While it's still running, it'll be slow enough that
> >>> hopefully people will move to a better transitional technology. My
> >>> fear is that it will cause more "v6 sucks, it's so slow" and people
> >>> shut it off without looking at why.
> >>>
> >>>
> >>>
> >>
> >
> >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130226/a1483c09/attachment.sig>