[Bug 221137] FreeBSD 11+ does not send ICMP redirects
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221137 --- Comment #12 from commit-h...@freebsd.org --- A commit references this bug: Author: ae Date: Tue Aug 28 07:24:10 UTC 2018 New revision: 338343 URL: https://svnweb.freebsd.org/changeset/base/338343 Log: MFC r337736: Restore ability to send ICMP and ICMPv6 redirects. It was lost when tryforward appeared. Now ip[6]_tryforward will be enabled only when sending redirects for corresponding IP version is disabled via sysctl. Otherwise will be used default forwarding function. PR: 221137 Changes: _U stable/11/ stable/11/sys/netinet/ip_input.c stable/11/sys/netinet6/ip6_input.c -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 221137] FreeBSD 11+ does not send ICMP redirects
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221137 Andrey V. Elsukov changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #13 from Andrey V. Elsukov --- Fixed in stable/11 and head/. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Mon, Aug 27, 2018, at 20:45, Marius Halden wrote: > On Mon, Aug 27, 2018, at 17:13, Navdeep Parhar wrote: > > On Mon, Aug 27, 2018 at 04:19:29PM +0200, Marius Halden wrote: > > > Hi, > > > > > > We have some routers with Chelsio T540-CR NICs using 1Gbps SFPs (1000 > > > Base-LX IIRC) to connect to our ISPs. After upgrading them to FreeBSD > > > 11.2-p2 (BSDRP v1.91) we have run into some issues. When the machines > > > are rebooted networking does not function at all through the ports > > > connected with SFPs, ports connected with DAC cables work properly. > > > According to ifconfig the SFPs are detected properly and they both > > > > What exact ifconfig command do you use to bring the interfaces up? > > It's just the normal rc.conf lines with `ifconfig_cxl0="inet …"` and > `ifconfig_cxl0_ipv6="inet6 …"`, nothing special beyond that. > > > Provide the output of these commands when the link isn't up: > > # ifconfig -mvvv > > # sysctl -n dev.t5nex.0.misc.devlog Output from these commands follows. (Ip addresses has been changed.) -- Marius Halden # ifconfig -mvvv cxl0 cxl0: flags=8843 metric 0 mtu 1500 options=e800bb capabilities=ecc7bb ether 00:07:43:42:cb:30 hwaddr 00:07:43:42:cb:30 inet 1.2.3.4 netmask 0xfffc broadcast 1.2.3.4 inet6 fe80::207:43ff:fe42:cb30%cxl0 prefixlen 64 scopeid 0x5 inet6 a:b:c:d::e prefixlen 126 nd6 options=21 media: Ethernet 1000baseSX status: active supported media: media 1000baseSX mediaopt full-duplex,rxpause,txpause media 1000baseSX mediaopt full-duplex,rxpause media 1000baseSX mediaopt full-duplex,txpause media 1000baseSX mediaopt full-duplex plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) vendor: Fiberworks PN: SFP-L80D-C49-U SN: FBSW491434 DATE: 2017-09-27 module temperature: 40.41 C Voltage: 3.26 Volts RX: 0.28 mW (-5.50 dBm) TX: 1.62 mW (2.10 dBm) SFF8472 DUMP (0xA0 0..127 range): 03 04 07 00 00 00 02 10 10 10 01 01 0D 00 50 FF 00 00 00 00 46 69 62 65 72 77 6F 72 6B 73 20 20 20 20 20 20 00 8A 34 BC 53 46 50 2D 4C 38 30 44 2D 43 34 39 2D 55 20 20 31 2E 30 20 05 D2 00 29 00 1A 00 00 46 42 53 57 34 39 31 34 33 34 20 20 20 20 20 20 31 37 30 39 32 37 20 20 68 90 01 B8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # sysctl -n dev.t5nex.0.misc.devlog Seq# Tstamp Level Facility Message 15 893704 INFO PORT module[0]: gpio 11 vendor id 8a34bc, identifier 0x03, SFP28(byte 36/192) 0xff, SFP(byte 3/131) 0x00, 1G (byte 6) 0x02 16 893706 INFO PORT optical length(byte 15/142) 255, copper cable(byte 8/147) 0xff, length(byte 18/146) 0, module_type 0x02 17 893708 INFO PORT hw_mac_init_port[0], ptype 0x9, speed 0x2, lanes 0x1, fec 0x0 18 893748 INFOTM pktsched channel 0 sets speed (from 0) to 100 kbps 19 893763 INFO PORT hw_mac_init_port[1], ptype 0x9, speed 0x4, lanes 0x2, fec 0x0 20 893795 INFOTM pktsched channel 1 sets speed (from 0) to 1000 kbps 21 893807 INFO PORT hw_mac_init_port[2], ptype 0x9, speed 0x4, lanes 0x4, fec 0x0 22 893840 INFOTM pktsched channel 2 sets speed (from 0) to 1000 kbps 23 897131 INFO PORT module[3]: gpio 7 vendor id 78a714, identifier 0x03, SFP28(byte 36/192) 0xff, SFP(byte 3/131) 0x00, 1G (byte 6) 0x00 24 897132 INFO PORT optical length(byte 15/142) 0, copper cable(byte 8/147) 0x04, length(byte 18/146) 3, module_type 0x04 25 897133 INFO PORT hw_mac_init_port[3], ptype 0x9, speed 0x4, lanes 0x8, fec 0x0 26 897165 INFOTM pktsched channel 3 sets speed (from 0) to 1000 kbps 27 921140 INFOTM pktsched_cl_rl[0:0]: mode | unit | rate 0x010001 min 0 max 10 pktsize 1500 28 922146 INFOTM pktsched_cl_rl[0:1]: mode | unit | rate 0x010001 min 0 max 20 pktsize 1500 29 923161 INFOTM pktsched_cl_rl[0:2]: mode | unit | rate 0x010001 min 0 max 40 pktsize 1500 30 924167 INFOTM pktsched_cl_rl[0:3]: mode | unit | rate 0x010001 min 0 max 50 pktsize 1500 31 925176 INFOTM pktsched_cl_rl[0:4]: mode | unit | rate 0x010001 min 0 max 80 pktsize 1500 32 926192 INFOTM pktsched_cl_rl[0:5]: mode | unit | rate 0x010001 min 0 max 100 pktsize 1500 33 927208 INFOTM pktsched_cl_rl[0:6]: mode | unit | rate 0x010001 min 0 max 120 pktsize 1500 34 927209NOTICETM ch_cl_rate[0/6]: capped deficit_incr from required 12000 to 1000
[Bug 166724] [re] if_re watchdog timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #32 from Mark Johnston --- I hit this a couple of times on a NFS server running 12.0-ALPHA3 while running highly parallel buildworlds with an NFS-mounted obj dir. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On 8/28/18 2:35 AM, Marius Halden wrote: > ... > media: Ethernet 1000baseSX > status: active > supported media: > media 1000baseSX mediaopt full-duplex,rxpause,txpause > media 1000baseSX mediaopt full-duplex,rxpause > media 1000baseSX mediaopt full-duplex,txpause > media 1000baseSX mediaopt full-duplex > plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) This shows that the SFP+ is recognized properly and the link is up (active). Can you please provide the outputs of ifconfig and sysctl from when the system is in the problem state, when the link doesn't come up? Regards, Navdeep ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote: > On 8/28/18 2:35 AM, Marius Halden wrote: > > ... > > media: Ethernet 1000baseSX > > status: active > > supported media: > > media 1000baseSX mediaopt full-duplex,rxpause,txpause > > media 1000baseSX mediaopt full-duplex,rxpause > > media 1000baseSX mediaopt full-duplex,txpause > > media 1000baseSX mediaopt full-duplex > > plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) > > This shows that the SFP+ is recognized properly and the link is up > (active). Can you please provide the outputs of ifconfig and sysctl > from when the system is in the problem state, when the link doesn't come up? This is from when it's in the problem state. According to ifconfig there is link and everything looks fine to me, but it doesn't seem to pass any traffic through the interface at all. -- Marius Halden ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On 8/28/18 11:27 AM, Marius Halden wrote: > On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote: >> On 8/28/18 2:35 AM, Marius Halden wrote: >>> ... >>> media: Ethernet 1000baseSX >>> status: active >>> supported media: >>> media 1000baseSX mediaopt full-duplex,rxpause,txpause >>> media 1000baseSX mediaopt full-duplex,rxpause >>> media 1000baseSX mediaopt full-duplex,txpause >>> media 1000baseSX mediaopt full-duplex >>> plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) >> >> This shows that the SFP+ is recognized properly and the link is up >> (active). Can you please provide the outputs of ifconfig and sysctl >> from when the system is in the problem state, when the link doesn't come up? > > This is from when it's in the problem state. According to ifconfig there is > link and everything looks fine to me, but it doesn't seem to pass any traffic > through the interface at all. > Try passing some network traffic through the interface and look at before/after state of the MAC counters in sysctl dev.cxl.0.stats. Do you see the tx_frames/rx_frames counter move at all? Regards, Navdeep ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 Martians
IPv6 Martians are blocked by forwarding code in 11-STABLE, but all this noise fills kernel message buffer: cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot forward src fe80:10::yxz:a50f:fcb6:5f1e, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fcb6:5f1e, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::268a:7ff:feeb:d250, dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc8a:9024, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc8a:9024, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan4 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan4 cannot forward src fe80:10::250:56ff:fe86:1b36, dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 Dear subscribes, could you please prompt how to get rid of this noise? So far I have not found appropriate sysctl for disabling this messages. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: cxl nic not working after reboot
On Tue, Aug 28, 2018, at 20:32, Navdeep Parhar wrote: > On 8/28/18 11:27 AM, Marius Halden wrote: > > On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote: > >> On 8/28/18 2:35 AM, Marius Halden wrote: > >>> ... > >>> media: Ethernet 1000baseSX > >>> status: active > >>> supported media: > >>> media 1000baseSX mediaopt full-duplex,rxpause,txpause > >>> media 1000baseSX mediaopt full-duplex,rxpause > >>> media 1000baseSX mediaopt full-duplex,txpause > >>> media 1000baseSX mediaopt full-duplex > >>> plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) > >> > >> This shows that the SFP+ is recognized properly and the link is up > >> (active). Can you please provide the outputs of ifconfig and sysctl > >> from when the system is in the problem state, when the link doesn't come > >> up? > > > > This is from when it's in the problem state. According to ifconfig there is > > link and everything looks fine to me, but it doesn't seem to pass any > > traffic through the interface at all. > > > > Try passing some network traffic through the interface and look at > before/after state of the MAC counters in sysctl dev.cxl.0.stats. Do > you see the tx_frames/rx_frames counter move at all? tx_frames does move, rx_frames is stuck at zero. The following counters are non-zero and does increase when traffic is sent through the interface, all other are stuck at zero: dev.cxl.0.stats.tx_frames_65_127: 26083 dev.cxl.0.stats.tx_frames_64: 4084 dev.cxl.0.stats.tx_mcast_frames: 26083 dev.cxl.0.stats.tx_bcast_frames: 4084 dev.cxl.0.stats.tx_frames: 30167 dev.cxl.0.stats.tx_octets: 2608846 Anything else I should look at? -- Marius Halden ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On 8/28/18 12:30 PM, Marius Halden wrote: > On Tue, Aug 28, 2018, at 20:32, Navdeep Parhar wrote: >> On 8/28/18 11:27 AM, Marius Halden wrote: >>> On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote: On 8/28/18 2:35 AM, Marius Halden wrote: > ... > media: Ethernet 1000baseSX > status: active > supported media: > media 1000baseSX mediaopt full-duplex,rxpause,txpause > media 1000baseSX mediaopt full-duplex,rxpause > media 1000baseSX mediaopt full-duplex,txpause > media 1000baseSX mediaopt full-duplex > plugged: SFP/SFP+/SFP28 1000BASE-LX (LC) This shows that the SFP+ is recognized properly and the link is up (active). Can you please provide the outputs of ifconfig and sysctl from when the system is in the problem state, when the link doesn't come up? >>> >>> This is from when it's in the problem state. According to ifconfig there is >>> link and everything looks fine to me, but it doesn't seem to pass any >>> traffic through the interface at all. >>> >> >> Try passing some network traffic through the interface and look at >> before/after state of the MAC counters in sysctl dev.cxl.0.stats. Do >> you see the tx_frames/rx_frames counter move at all? > > tx_frames does move, rx_frames is stuck at zero. The following counters are > non-zero and does increase when traffic is sent through the interface, all > other are stuck at zero: > > dev.cxl.0.stats.tx_frames_65_127: 26083 > dev.cxl.0.stats.tx_frames_64: 4084 > dev.cxl.0.stats.tx_mcast_frames: 26083 > dev.cxl.0.stats.tx_bcast_frames: 4084 > dev.cxl.0.stats.tx_frames: 30167 > dev.cxl.0.stats.tx_octets: 2608846 > > Anything else I should look at? > What is on the other side of the link? Look at the peer's rx stats and see if it received the frames that cxl0 claims it has transmitted or not. Regards, Navdeep ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: IPv6 Martians
> IPv6 Martians are blocked by forwarding code in 11-STABLE, but all this noise > fills kernel message buffer: > > cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot > forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot > forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot > forward src fe80:10::yxz:a50f:fcb6:5f1e, dst 2001:xyz:zxy::f00b, nxt 58, rcvif > vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fcb6:5f1e, dst > 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, > outif > vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst > 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::268a:7ff:feeb:d250, dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif > vlan2 cannot forward src fe80:10::yxz:a50f:fc8a:9024, dst > 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::yxz:a50f:fc8a:9024, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, > outif > vlan2 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt 58, rcvif > vlan4, outif vlan4 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt > 58, rcvif vlan4, outif vlan4 cannot forward src fe80:10::250:56ff:fe86:1b36, > dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif > vlan2 cannot forward src fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, > nxt 58, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, > outif > vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst > 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src > fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, > outif > vlan2 > > Dear subscribes, could you please prompt how to get rid of this noise? > So far I have not found appropriate sysctl for disabling this messages. I can confirm the same issue on stable-11. I just ignored it as I thought it was a badly coded client. Seems there is something else going on then. > > Marek Zarychta > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Martians
29.08.2018 2:35, Dries Michiels wrote: >> IPv6 Martians are blocked by forwarding code in 11-STABLE, but all this noise >> fills kernel message buffer: >> >> cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >> forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >> forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >> forward src fe80:10::yxz:a50f:fcb6:5f1e, dst 2001:xyz:zxy::f00b, nxt 58, >> rcvif >> vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fcb6:5f1e, dst >> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >> outif >> vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst >> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::268a:7ff:feeb:d250, dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif >> vlan2 cannot forward src fe80:10::yxz:a50f:fc8a:9024, dst >> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::yxz:a50f:fc8a:9024, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >> outif >> vlan2 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt 58, rcvif >> vlan4, outif vlan4 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt >> 58, rcvif vlan4, outif vlan4 cannot forward src fe80:10::250:56ff:fe86:1b36, >> dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >> outif >> vlan2 cannot forward src fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, >> nxt 58, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >> outif >> vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst >> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >> outif >> vlan2 >> >> Dear subscribes, could you please prompt how to get rid of this noise? >> So far I have not found appropriate sysctl for disabling this messages. > > I can confirm the same issue on stable-11. > I just ignored it as I thought it was a badly coded client. > Seems there is something else going on then. As workaround, use sysctl net.inet6.ip6.log_interval=2147483647 This means "log this once per 68 years". ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote: > On 8/28/18 12:30 PM, Marius Halden wrote: > > tx_frames does move, rx_frames is stuck at zero. The following counters are > > non-zero and does increase when traffic is sent through the interface, all > > other are stuck at zero: > > > > dev.cxl.0.stats.tx_frames_65_127: 26083 > > dev.cxl.0.stats.tx_frames_64: 4084 > > dev.cxl.0.stats.tx_mcast_frames: 26083 > > dev.cxl.0.stats.tx_bcast_frames: 4084 > > dev.cxl.0.stats.tx_frames: 30167 > > dev.cxl.0.stats.tx_octets: 2608846 > > > > Anything else I should look at? > > > > What is on the other side of the link? Look at the peer's rx stats and > see if it received the frames that cxl0 claims it has transmitted or not. Our ISPs router is connected to the other side. Unfortunately I don't have access to any of the counters, but from what I understood when originally debugging this with our ISP they did not see any traffic. If needed I can ask them to check the rx counters tomorrow. -- Marius Halden ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Tue, Aug 28, 2018 at 1:14 PM Marius Halden wrote: > On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote: > > On 8/28/18 12:30 PM, Marius Halden wrote: > > > tx_frames does move, rx_frames is stuck at zero. The following > counters are non-zero and does increase when traffic is sent through the > interface, all other are stuck at zero: > > > > > > dev.cxl.0.stats.tx_frames_65_127: 26083 > > > dev.cxl.0.stats.tx_frames_64: 4084 > > > dev.cxl.0.stats.tx_mcast_frames: 26083 > > > dev.cxl.0.stats.tx_bcast_frames: 4084 > > > dev.cxl.0.stats.tx_frames: 30167 > > > dev.cxl.0.stats.tx_octets: 2608846 > > > > > > Anything else I should look at? > > > > > > > What is on the other side of the link? Look at the peer's rx stats and > > see if it received the frames that cxl0 claims it has transmitted or not. > > Our ISPs router is connected to the other side. Unfortunately I don't have > access to any of the counters, but from what I understood when originally > debugging this with our ISP they did not see any traffic. If needed I can > ask them to check the rx counters tomorrow. > > -- > Marius Halden > This looks a lot like either a routing or NDP issue with the adjacent router. Well, an NDP issue devolves to a routing issue. It also possible that RDP is an issue, but, if you can't ping the opposite end, that eliminates RDP. You might check for NDP traffic with tcpdump or wireshark when the connection is restored. If you are not IPv6 conversant, NDP is the IPv6 replacement for ARP and it's pretty obvious how this would impact your connectivity. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Wed, Aug 29, 2018, at 01:50, Kevin Oberman wrote: > On Tue, Aug 28, 2018 at 1:14 PM Marius Halden wrote: > > > On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote: > > > On 8/28/18 12:30 PM, Marius Halden wrote: > > > > tx_frames does move, rx_frames is stuck at zero. The following > > counters are non-zero and does increase when traffic is sent through the > > interface, all other are stuck at zero: > > > > > > > > dev.cxl.0.stats.tx_frames_65_127: 26083 > > > > dev.cxl.0.stats.tx_frames_64: 4084 > > > > dev.cxl.0.stats.tx_mcast_frames: 26083 > > > > dev.cxl.0.stats.tx_bcast_frames: 4084 > > > > dev.cxl.0.stats.tx_frames: 30167 > > > > dev.cxl.0.stats.tx_octets: 2608846 > > > > > > > > Anything else I should look at? > > > > > > > > > > What is on the other side of the link? Look at the peer's rx stats and > > > see if it received the frames that cxl0 claims it has transmitted or not. > > > > Our ISPs router is connected to the other side. Unfortunately I don't have > > access to any of the counters, but from what I understood when originally > > debugging this with our ISP they did not see any traffic. If needed I can > > ask them to check the rx counters tomorrow. > > > > -- > > Marius Halden > > > > This looks a lot like either a routing or NDP issue with the adjacent > router. Well, an NDP issue devolves to a routing issue. It also possible > that RDP is an issue, but, if you can't ping the opposite end, that > eliminates RDP. You might check for NDP traffic with tcpdump or wireshark > when the connection is restored. If you are not IPv6 conversant, NDP is the > IPv6 replacement for ARP and it's pretty obvious how this would impact your > connectivity. I do see ARP requests and neighbor solicitations with tcpdump, but not any replies for either. Though I'm pretty sure that's just a symptom of the problem and not the root cause considering both ipv4 and ipv6 will start working again if the SFP is removed and reinserted. What is RDP in this context? -- Marius Halden ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Martians
On 8/29/18 12:01 AM, Eugene Grosbein wrote: > 29.08.2018 2:35, Dries Michiels wrote: > >>> IPv6 Martians are blocked by forwarding code in 11-STABLE, but all this >>> noise >>> fills kernel message buffer: >>> >>> cannot forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >>> forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >>> forward from :: to 2001:xyz:zxy::f00b nxt 58 received on vlan5 cannot >>> forward src fe80:10::yxz:a50f:fcb6:5f1e, dst 2001:xyz:zxy::f00b, nxt 58, >>> rcvif >>> vlan4, outif vlan2 cannot forward src fe80:10::yxz:a50f:fcb6:5f1e, dst >>> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >>> outif >>> vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst >>> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::268a:7ff:feeb:d250, dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, >>> outif >>> vlan2 cannot forward src fe80:10::yxz:a50f:fc8a:9024, dst >>> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::yxz:a50f:fc8a:9024, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >>> outif >>> vlan2 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, nxt 58, rcvif >>> vlan4, outif vlan4 cannot forward src fe80:10::1, dst 2001:xyz:zxy::f00b, >>> nxt >>> 58, rcvif vlan4, outif vlan4 cannot forward src fe80:10::250:56ff:fe86:1b36, >>> dst 2001:xyz:zxy::d1, nxt 17, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >>> outif >>> vlan2 cannot forward src fe80:10::yxz:a50f:fc90:9d4, dst 2001:xyz:zxy::f00b, >>> nxt 58, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >>> outif >>> vlan2 cannot forward src fe80:10::yxz:a50f:fc89:e1a0, dst >>> 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, outif vlan2 cannot forward src >>> fe80:10::yxz:a50f:fc89:e1a0, dst 2001:xyz:zxy::f00b, nxt 58, rcvif vlan4, >>> outif >>> vlan2 >>> >>> Dear subscribes, could you please prompt how to get rid of this noise? >>> So far I have not found appropriate sysctl for disabling this messages. >> >> I can confirm the same issue on stable-11. >> I just ignored it as I thought it was a badly coded client. >> Seems there is something else going on then. > > As workaround, use sysctl net.inet6.ip6.log_interval=2147483647 > This means "log this once per 68 years". > Block these in firewall, as another workaround. > > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: cxl nic not working after reboot
On Tue, Aug 28, 2018 at 5:17 PM Marius Halden wrote: > On Wed, Aug 29, 2018, at 01:50, Kevin Oberman wrote: > > On Tue, Aug 28, 2018 at 1:14 PM Marius Halden wrote: > > > > > On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote: > > > > On 8/28/18 12:30 PM, Marius Halden wrote: > > > > > tx_frames does move, rx_frames is stuck at zero. The following > > > counters are non-zero and does increase when traffic is sent through > the > > > interface, all other are stuck at zero: > > > > > > > > > > dev.cxl.0.stats.tx_frames_65_127: 26083 > > > > > dev.cxl.0.stats.tx_frames_64: 4084 > > > > > dev.cxl.0.stats.tx_mcast_frames: 26083 > > > > > dev.cxl.0.stats.tx_bcast_frames: 4084 > > > > > dev.cxl.0.stats.tx_frames: 30167 > > > > > dev.cxl.0.stats.tx_octets: 2608846 > > > > > > > > > > Anything else I should look at? > > > > > > > > > > > > > What is on the other side of the link? Look at the peer's rx stats > and > > > > see if it received the frames that cxl0 claims it has transmitted or > not. > > > > > > Our ISPs router is connected to the other side. Unfortunately I don't > have > > > access to any of the counters, but from what I understood when > originally > > > debugging this with our ISP they did not see any traffic. If needed I > can > > > ask them to check the rx counters tomorrow. > > > > > > -- > > > Marius Halden > > > > > > > This looks a lot like either a routing or NDP issue with the adjacent > > router. Well, an NDP issue devolves to a routing issue. It also possible > > that RDP is an issue, but, if you can't ping the opposite end, that > > eliminates RDP. You might check for NDP traffic with tcpdump or wireshark > > when the connection is restored. If you are not IPv6 conversant, NDP is > the > > IPv6 replacement for ARP and it's pretty obvious how this would impact > your > > connectivity. > > I do see ARP requests and neighbor solicitations with tcpdump, but not any > replies for either. Though I'm pretty sure that's just a symptom of the > problem and not the root cause considering both ipv4 and ipv6 will start > working again if the SFP is removed and reinserted. > > What is RDP in this context? > > -- > Marius Halden > Router Discovery Protocol. Since you are unable to communicate with the adjacent system, RDP is not relevant. I do agree that this is almost certainly a hardware/driver issue. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
