Date: Fri, 18 Aug 2023 14:54:01 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: =?UTF-8?B?Sm9zw6kgUMOpcmV6?= <fbl@aoek.com> Cc: freebsd-net@freebsd.org Subject: Re: em0: No buffer space available for IPv6 traffic but IPv4 is OK Message-ID: <CAN6yY1t80K6PibY_iOfsfyrbOE--yRyE0=DXX1Fpjk0pBJZ=fA@mail.gmail.com> In-Reply-To: <503561ece3e7201318c298c2d5b91eb5@mail.yourbox.net> References: <503561ece3e7201318c298c2d5b91eb5@mail.yourbox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Fri, Aug 18, 2023 at 1:02 AM José Pérez <fbl@aoek.com> wrote: > Hi, > on this intel em0 > # dmesg |fgrep em0 > em0: <Intel(R) Gigabit CT 82574L> port 0xd800-0xd81f mem > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 48 at device 0.0 on pci1 > em0: Using 1024 TX descriptors and 1024 RX descriptors > em0: Using 2 RX queues 2 TX queues > em0: Using MSI-X interrupts with 3 vectors > em0: Ethernet address: xx:xx:xx:xx:xx:xx > em0: netmap queues/slots: TX 2/1024, RX 2/1024 > > IPv4 and IPv6 used to work seamlessly for the past 6+ years. > > # ifconfig em0 > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu > 1500 > > > options=81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER> > ether xx:xx:xx:xx:xx:xx > inet xxx.xxx.xxx.xxx netmask 0xffffff00 broadcast > xxx.xxx.xxx.255 > inet6 fe80::xxxx:xxxx:xxxx:xxxx%em0 prefixlen 64 scopeid 0x1 > inet6 2xxx:xxxx:xxxx:xxxx::1 prefixlen 64 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> > > Nevertheless, now IPv6 traffic does not work anymore: > # ping6 www.google.com > PING6(56=40+8+8 bytes) 2xxx:xxxx:xxxx:xxxx::1 --> 2yyy:yyyy:yyyy:yyyy::1 > ping6: sendmsg: No buffer space available > ping6: wrote www.google.com 16 chars, ret=-1 > > From send(2): > [...] > [ENOBUFS] The system was unable to allocate an internal > buffer. > The operation may succeed when buffers become > available. > > [ENOBUFS] The output queue for a network interface was > full. > This generally indicates that the interface has > stopped sending, but may be caused by transient > congestion. > [...] > > There is little traffic on the interface and it seems that buffers are > available: > # netstat -m > 2108/3472/5580 mbufs in use (current/cache/total) > 2062/1336/3398/1018874 mbuf clusters in use (current/cache/total/max) > 15/1250 mbuf+clusters out of packet secondary zone in use > (current/cache) > [...] > > Interestingly, there is incoming IPv6 local broadcast traffic as sniffed > by > # tcpdump -n -i em0 ip6 > (ICMP6, neighbor solicitation, UDP from LAN link local addresses). > > Has anyone seen this before and can suggest a fix? > > Reboot did not solve, no software updates made, no config changes, just > stop working from one day to the next. > > Thank you. > > -- > José Pérez > Oddly, ENOBUFS is the error I get when my firewall is blocking transmit traffic. There may well be other causes. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">On Fri, Aug 18, 2023 at 1:02 AM José Pérez <<a href="mailto:fbl@aoek.com">fbl@aoek.com</a>> wrote:</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> on this intel em0<br> # dmesg |fgrep em0<br> em0: <Intel(R) Gigabit CT 82574L> port 0xd800-0xd81f mem <br> 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 48 at device 0.0 on pci1<br> em0: Using 1024 TX descriptors and 1024 RX descriptors<br> em0: Using 2 RX queues 2 TX queues<br> em0: Using MSI-X interrupts with 3 vectors<br> em0: Ethernet address: xx:xx:xx:xx:xx:xx<br> em0: netmap queues/slots: TX 2/1024, RX 2/1024<br> <br> IPv4 and IPv6 used to work seamlessly for the past 6+ years.<br> <br> # ifconfig em0<br> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu <br> 1500<br> <br> options=81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER><br> ether xx:xx:xx:xx:xx:xx<br> inet xxx.xxx.xxx.xxx netmask 0xffffff00 broadcast <br> xxx.xxx.xxx.255<br> inet6 fe80::xxxx:xxxx:xxxx:xxxx%em0 prefixlen 64 scopeid 0x1<br> inet6 2xxx:xxxx:xxxx:xxxx::1 prefixlen 64<br> media: Ethernet autoselect (100baseTX <full-duplex>)<br> status: active<br> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL><br> <br> Nevertheless, now IPv6 traffic does not work anymore:<br> # ping6 <a href="http://www.google.com" rel="noreferrer" target="_blank">www.google.com</a><br> PING6(56=40+8+8 bytes) 2xxx:xxxx:xxxx:xxxx::1 --> 2yyy:yyyy:yyyy:yyyy::1<br> ping6: sendmsg: No buffer space available<br> ping6: wrote <a href="http://www.google.com" rel="noreferrer" target="_blank">www.google.com</a> 16 chars, ret=-1<br> <br> From send(2):<br> [...]<br> [ENOBUFS] The system was unable to allocate an internal <br> buffer.<br> The operation may succeed when buffers become<br> available.<br> <br> [ENOBUFS] The output queue for a network interface was <br> full.<br> This generally indicates that the interface has<br> stopped sending, but may be caused by transient<br> congestion.<br> [...]<br> <br> There is little traffic on the interface and it seems that buffers are <br> available:<br> # netstat -m<br> 2108/3472/5580 mbufs in use (current/cache/total)<br> 2062/1336/3398/1018874 mbuf clusters in use (current/cache/total/max)<br> 15/1250 mbuf+clusters out of packet secondary zone in use <br> (current/cache)<br> [...]<br> <br> Interestingly, there is incoming IPv6 local broadcast traffic as sniffed <br> by<br> # tcpdump -n -i em0 ip6<br> (ICMP6, neighbor solicitation, UDP from LAN link local addresses).<br> <br> Has anyone seen this before and can suggest a fix?<br> <br> Reboot did not solve, no software updates made, no config changes, just <br> stop working from one day to the next.<br> <br> Thank you.<br> <br> -- <br> José Pérez<br></blockquote><div><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">Oddly, ENOBUFS is the error I get when my firewall is blocking transmit traffic. There may well be other causes.<br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Kevin Oberman, Part time kid herder and retired Network Engineer<br>E-mail: <a href="mailto:rkoberman@gmail.com" target="_blank">rkoberman@gmail.com</a><br></div><div>PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683</div></div></div></div></div></div></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1t80K6PibY_iOfsfyrbOE--yRyE0=DXX1Fpjk0pBJZ=fA>