In muc.lists.netbsd.tech.net Miles Nordin wrote:

>>>>>> "gd" == Gert Doering <gert@greenie.muc.de> writes:

>    gd> Due to Sparc64-recursive-softinterrupts issues,

>I'm about to colocate a 1U sparc64, and it needs to do tunnels.  So,
>it won't work?  Is there a workaround for this---for example if I do
>only IPv4-in-IPv4 and only IPv6-in-IPv6 tunnels, will it work ok?  Or
>is there a reasonable way to make the max packet delay 10ms?

Only mixed-protocol tunnels exhibit the problem (you're inside of
an IPv4 softinterrupt, and after unpacking an IPv6 packet, you schedule
an IPv6 softinterrupt, which is then delayed for some high amount of
time - typically 500ms...1s on my systems).

IPv4-in-IPv4 is fine, and IPv6-in-IPv6 should also be fine.

I haven't tried IPv6-in-IPv6 myself yet, though.  gre(7) can't do it (just 
because it's not implemented, not due to any basic impossibilities - Cisco
does it just fine), but maybe gif(7) can.

If you *need* IPv6-in-IPv4 tunneling on Sparc64 and *need* 10ms max delay, 
you need to resort to drastic measures - setup something that generates
a non-recursive IPv6 softirq all 10ms, like "ping -i 0.01 ::1".  IPv6
packets that come in via non-tunneled interfaces also start processing
for anything that might have come in via a tunnel and still sits in the
respective queue.

gert
-- 
I've got a signature breakdown! Anybody got a spare one?

Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3243328                         gert.doering@physik.tu-muenchen.de