Re: IPv6 works on em0 () but not on em1 () - what's wrong?,IPv6 works on em0 () but not on em1 () - what's wrong?
Hello Hiroki, Wednesday, January 11, 2017, 2:43:28 AM, you wrote: > What happens by typing the following command? > % ping6 ff02::1%em1 % ping6 ff02::1%em1 PING6(56=40+8+8 bytes) fe80::225:90ff:fe24:6bf8%em1 --> ff02::1%em1 16 bytes from fe80::225:90ff:fe24:6bf8%em1, icmp_seq=0 hlim=64 time=0.163 ms 16 bytes from fe80::222:4dff:fe9d:e093%em1, icmp_seq=0 hlim=64 time=0.737 ms(DUP!) 16 bytes from fe80::225:90ff:fe24:6bf8%em1, icmp_seq=1 hlim=64 time=0.132 ms 16 bytes from fe80::222:4dff:fe9d:e093%em1, icmp_seq=1 hlim=64 time=0.766 ms(DUP!) 16 bytes from fe80::225:90ff:fe24:6bf8%em1, icmp_seq=2 hlim=64 time=0.086 ms 16 bytes from fe80::222:4dff:fe9d:e093%em1, icmp_seq=2 hlim=64 time=0.713 ms(DUP!) ... BTW, when I add address and default route by hands, everything starts to work. So, this NIC doesn't have problems with IPv6 per se! Looks like some weird configuration problem. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
General question about 1GB vs 10GB NIC's
I want to build a router that has 2 x 500mb/s radio ISP facing, 2 x 500mb/s radio's facing another site, plus a 1gb/s link to the LAN. I plan to plug everything into a switch so I can have redundant routers. So my question is should I go with 5 x 1GB NIC's or 2x10GB NIC's on the motherboard. Assume NIC's will be Intel or IBM. Going 10GB pushes the switch price ten-times, so I'd like to avoid that if possible. I'm planning to get a 4 core Xeon @3.4GHz and it would be nice to know if this is a moot point or not. Thanks -- lee ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPv6 works on em0 () but not on em1 () - what's wrong?,IPv6 works on em0 () but not on em1 () - what's wrong?
Lev Serebryakov wrote in <58756dde.5000...@freebsd.org>,<58756dde.5000...@freebsd.org>: le> le> I have MoBo (Supermicro X9SCL-F) with two 1G NICs, first one (em0) is le> based on 82579LM, and second one (em1) is based on 82574L. le> le> When I'm using em0 with simple config: le> le> ifconfig_em0="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000" le> ifconfig_em0_ipv6="inet6 accept_rtadv" le> le> everything works fine - em0 get IPv6 prefix from rtadvd of my router le> and "tspdump -n -i em0 icmp6" shows some traffic, like router and prefix le> announcements. So far so good. le> le> I want to use em1 (and don't use em0 at all), because 82579LM has some le> known bugs according to SuperMicro support and someties hangs whole system. le> le> So, I change config to le> le> ifconfig_em1="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000" le> ifconfig_em1_ipv6="inet6 accept_rtadv" le> le> connect em1 instead of em0 to the switch and reboot. And after that le> interface (em1) can not get IPv6 prefix, don't get global address (and le> shows only link-local one)and "tcpdump -n -i em1 icmp6" shows nothing at le> all! IPv4 works fine, though. le> le> What do I do wrong? Is it known issue of 82574L? le> le> I'm running 10-STABLE r311462. What happens by typing the following command? % ping6 ff02::1%em1 -- Hiroki pgppEPUNeQglf.pgp Description: PGP signature
IPv6 works on em0 () but not on em1 () - what's wrong?
I have MoBo (Supermicro X9SCL-F) with two 1G NICs, first one (em0) is based on 82579LM, and second one (em1) is based on 82574L. When I'm using em0 with simple config: ifconfig_em0="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000" ifconfig_em0_ipv6="inet6 accept_rtadv" everything works fine - em0 get IPv6 prefix from rtadvd of my router and "tspdump -n -i em0 icmp6" shows some traffic, like router and prefix announcements. So far so good. I want to use em1 (and don't use em0 at all), because 82579LM has some known bugs according to SuperMicro support and someties hangs whole system. So, I change config to ifconfig_em1="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000" ifconfig_em1_ipv6="inet6 accept_rtadv" connect em1 instead of em0 to the switch and reboot. And after that interface (em1) can not get IPv6 prefix, don't get global address (and shows only link-local one)and "tcpdump -n -i em1 icmp6" shows nothing at all! IPv4 works fine, though. What do I do wrong? Is it known issue of 82574L? I'm running 10-STABLE r311462. -- // Lev Serebryakov AKA Black Lion signature.asc Description: OpenPGP digital signature
Re: Cannot update system from 11-RELEASE-p2 to 11-RELEASE-p6
2017-01-07 23:38 GMT+01:00 Holger Kipp : > Dear Fernando, > > > On 7 Jan 2017, at 23:27, Fernando Herrero Carrón > wrote: > > > > Hi, > > > > I am seeing a strange behaviour. I run freebsd-update fetch: > > > > % sudo freebsd-update fetch > > Password: > > Looking up update.FreeBSD.org mirrors... 4 mirrors found. > > Fetching metadata signature for 11.0-RELEASE from update6.freebsd.org... > > done. > > Fetching metadata index... done. > > Inspecting system... done. > > Preparing to download files... done. > > > > No updates needed to update system to 11.0-RELEASE-p6. > > > > But: > > > > % uname -a > > FreeBSD pantera 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 > > 06:55:27 UTC 2016 > > > > Does this make sense? > > uname -a gives the version of the running OS. > > freebsd-version -ku gives installed versions for kernel and userland. > > Hi! Indeed that is the case: %% freebsd-version -ku 11.0-RELEASE-p2 11.0-RELEASE-p6 Thanks for the info! Best, Fernando ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
Hi All, I ported the changes from projects/ipsec to stable/11 branch. So, if it is more suitable for testing, please, welcome. You can checkout the sources from github: https://github.com/bu7cher/freebsd/tree/stable/11 Also I made the standalone patch: https://people.freebsd.org/~ae/ipsec.diff Unfortunately, I did only compile test for stable branch. I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. Currently all, except the last one is mostly done. So, I decided ask for a help to test the what already done, while I will work on the last task. How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=revision&revision=309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=revision&revision=309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=revision&revision=309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch. If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. IPsec as kernel modules was reported here: https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046762.html Some additional testing also needed with this... -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Vestibular SENAI 2017/1 - Oportunidade de 50% de desconto no 1º semestre para ex-aluno SENAI
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
objcopy on 11-STABLE vs 10-STABLE
I run an iscsi setup booting using ixpe, which I build on the FreeBSD server. the last few steps of the build do this: objcopy -O binary -R .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.bin objcopy -O binary -j .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.zinfo This runs fine on 10-STABLE, but on 11-STABLE I get these warnings from the first command: objcopy: moving loadable section .bss.data16, is this intentional? objcopy: moving loadable section .bss.textdata, is this intentional? the resulting .bin file is not then useable and the build fails. If I copy over the objcopy from 10 and run that instead manually then it succeeds. Have been looking at the svn logs for the objcopy, and the thing which stands out is the PIE support stuff, but from my reading that has been reverted ? So I am a bit stumped - is this a bug in objcopy in 11 ? Or is is a change in default behaviour and the ipxe build needs to supply extra flags to get the old behaviour ? -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
intel 10gbe nic bug in 10.3 - no carrier
Hello everyone, we're trying to tackle a rare bug that is very hard to debug. Our 10.3-RELEASE servers can panic boot and subsequently can come up without network (2x - no carrier). We've seen this on 10.3-RELEASE-p0 we have never seen this before. root@storage ~ # pciconf -lv | grep -B3 network ix0@pci0:2:0:0:class=0x02 card=0xd10f19e5 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599ES 10-Gigabit SFI/SFP+ Network Connection' class = network -- ix1@pci0:2:0:1:class=0x02 card=0xd10f19e5 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599ES 10-Gigabit SFI/SFP+ Network Connection' class = network Our network is configured as active/passive using lagg. (/etc/rc.conf): ifconfig_ix0="up" ifconfig_ix1="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport ix0 laggport ix1 10.1.2.31/16" After panic boot the network show up like this: ix0: flags=8843 metric 0 mtu 1500 options=8407bb ether 60:08:10:d0:4e:9f nd6 options=29 media: (autoselect) status: no carrier ix1: flags=8843 metric 0 mtu 1500 options=8407bb ether 60:08:10:d0:4e:9f nd6 options=29 media: (autoselect) status: no carrier The network switch sees the connection as online. The LED's of the nic's suggest the same, they see the network as online (led's are on like in normal operation). Unplugging/replugging the network cable will get the network online. Shutting the port on the switch and reenabling it wil also get the network online. However another reboot will return the machine into the no-carrier state. I've built various kernels trying to find where the regression is without success. I tried porting the 10.2 nic driver (2.8.3) to 10.3 and subsequently the lagg code as well. I ported nic driver 3.1.14 from pfsense into 10.3-STABLE (2 december kernel) to no avail, also porting lagg code from 10.2 did not make any difference. Rebooting with those kernels the server remains in the no carrier state. We install our systems using mfsbsd for PXE boot. If I boot a machine which has the "no carrier" state using the 10.3 PXE boot, both nic's come online. If I then boot from disk again the machine returns into the "no carrier" state. Recently we got some new machines, so we can shuffle more around and also to try to debug this. We baseinstalled it using mfsbsd 10.3 pxe and configured it like always. Here interestingly one of the two nic's entered the "no carrier" state, the other nic remained operational. This remained persistent across reboots. The issue disappears after many reboots but it's not conclusive. I've had 2 machines with which I could experiment with. On one the problem it disappeared on it's own after a reboot (kernel 10.3-STABLE git hash d99ba5c aka r299900(?)). On the other one I pxe booted 10.1 live environment and then subsequently I booted into kernel 10.3-STABLE git hash 3673260fc9 aka r308456(?)). But I don't think anything can be concluded from that. That was the machine which had both nic's online after booting into the 10.3 pxe environment but subsequently returned into no carrier state when booting 10.3 from disk. We also tried many sysctl flags (and many reboots), but without success. For example: hw.ix.enable_msix=0 and hw.ix.enable_msi=0 At the moment I have no spare/empty machine in this state, we will empty one machine though which currently has this state (but is in production right now). I don't know how to trigger this state manually, which doesn't help for debugging. I could link reference where others report similar issues, for example https://www.reddit.com/r/PFSENSE/comments/45bcuq/10_gig_woes/ Here they suggest that the new intel nic driver 3.1.14 fixes it. Though I was not able to resolve the state by booting into a kernel with this driver. If I can provide any additional information please do not hesitate to ask. Any tips and suggestions for debugging are most welcome! With kind regards, Daniel ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
