nakaji@jp.freebsd.org wrote:

> On tlp1, DNS and NBT are mainly seen in the last packets.
> 
> 07:01:27.596723 IP 192.168.1.252.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
> 07:01:29.095517 IP 192.168.1.252.2133 > 203.139.160.74.domain:  46939+ A? www.heimat.gr.jp. (34)
> 07:01:31.095913 IP 192.168.1.252.2133 > www.domain:  46939+ A? www.heimat.gr.jp. (34)
 :

Only TX packets and no RX packets?

> On tlp0, icmp and NBT.
> 
> 07:04:26.401531 IP 60.32.13.195 > 60.32.13.193: icmp 64: echo request seq 153
> 07:04:27.402665 IP 60.32.13.195 > 60.32.13.193: icmp 64: echo request seq 154
> 07:04:27.827320 IP 60.32.13.194.137 > 60.32.13.199.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
> 07:04:27.827556 IP 60.32.13.194.137 > 60.32.13.199.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
> 07:04:28.403831 IP 60.32.13.195 > 60.32.13.193: icmp 64: echo request seq 155
 :

What IP address your Qube2 has?
i.e. is there any TX packets?

> In first 15 seconds, it shows no cpu int 1 and 2.

I'm confused. No interrupt, but there are some TX or RX packets
on tcpdump? It's unlikely...

> No buffer space available for all IPv4. But IPv6 is available.
 :
> With "tcpdump -i tlp1", I can see only DNS lookup by Solaris on tlp1.
> With "tcpdump -i tlp0", I can see ssh of IPv6 and ntp/snmp of IPv4.

If any packets are sent/received, it shouldn't be a driver problem
because lower drivers just handle raw mbufs and don't take care of
their protocols (except hwcksum, which is not supported by tlp(4)).
If only TCP4 or ICMP4 packets have trouble, it should be a problem
in upper layers (TCP in netinet or ipf), I believe.

Maybe you could try:
- disable CPUFLAGS (if there is some improper optimization)
- increase NMBCLUSTERS (if there is some resource shortage)
- check some more network stats (as discussed in tech-net,
  http://mail-index.netbsd.org/tech-net/2007/01/08/0001.html )
etc?
---
Izumi Tsutsui