udp checksum implementation error in FreeBSD 7.2?
Hi We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box. This works for most of our customers, except ones with some kind of SonicWall Firewalls. We have analyzed the problem with the sonicwall tech support: We found the problem being in the sonicwall setting a UDP checksum of 0x for DHCP Requests. According to the RFC this is a valid value and tells the receiving UDP stack not to check the checksum: http://www.faqs.org/rfcs/rfc768.html If the value is different from 0x the receiving UDP stack can perform a checksum check and if this fails, silently drop that packet. What we observe is: DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and is being answered. DHCP Request with UDP checksum 0x => ICMP Port Unreachable from FreeBSD. Can someone confirm this non RFC conform behaviour and knows how to fix it? As I understand, setting net.inet.udp.checksum to zero would not fix the problem, as this is only for packet generation. Kind regards Benoit Panizzon -- I m p r o W a r e A G- __ Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 PrattelnFax +41 61 826 93 02 Schweiz Web http://www.imp.ch __
Re: udp checksum implementation error in FreeBSD 7.2?
Benoit Panizzon wrote:
> Hi
>
> We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box.
>
> This works for most of our customers, except ones with some kind of
> SonicWall
> Firewalls. We have analyzed the problem with the sonicwall tech
> support:
>
> We found the problem being in the sonicwall setting a UDP checksum of
> 0x
> for DHCP Requests.
>
> According to the RFC this is a valid value and tells the receiving UDP
> stack
> not to check the checksum:
>
> http://www.faqs.org/rfcs/rfc768.html
>
> If the value is different from 0x the receiving UDP stack can
> perform a
> checksum check and if this fails, silently drop that packet.
>
> What we observe is:
>
> DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and
> is being
> answered.
> DHCP Request with UDP checksum 0x => ICMP Port Unreachable from
> FreeBSD.
>
> Can someone confirm this non RFC conform behaviour and knows how to
> fix it?
>
Well, I took a quick look at the sources (which are in sys/netinet/udp_usrreq.c
in a function called udp_input() at about line#300) and it only does the
checksum if it is non-zero. It looks like:
if (uh->uh_sum) {
do checksum
(If you don't have kernel sources handy, you can find them here:
http://svn.freebsd.org/viewvc/base/releng/7.2)
So, I have no idea why the packet without the checksum doesn't make it
through, but it doesn't appear to be because the checksum field is set to 0.
In fact, if you do "netstat -s", you should see the count for UDP packets
with no checksum increase as it receives them.
If this count isn't increaing when the request with checksum == 0x is
being sent to the FreeBSD box, it isn't getting as far as the udp checksum
calculation. (The code fails a UDP packet with a 0 destination port#, for
example.) Or maybe your network hardware is trying to do the checksum and
then dropping the packet? Look at "ifconfig -a" and if RXCSUM is enabled,
you could try disabling it with "-rxcsum" on the ifconfig command line.
Otherwise, all I can suggest is good old fashioned printf()s in the
udp_input() function to try and figure out why the packet is being dropped?
(Oh, this assumes you've already looked at the packet via wireshark or
tcpdump to make sure that the UDP packet looks ok otherwise when it has
the checksum == 0x.)
> As I understand, setting net.inet.udp.checksum to zero would not fix
> the
> problem, as this is only for packet generation.
>
Yes, the code shouldn't ever try and calculate a UDP checksum when it's
0 in the packet.
Maybe others have better suggestions, rick
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: udp checksum implementation error in FreeBSD 7.2?
On 28.06.2011 13:48, Benoit Panizzon wrote: Hi We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box. This works for most of our customers, except ones with some kind of SonicWall Firewalls. We have analyzed the problem with the sonicwall tech support: We found the problem being in the sonicwall setting a UDP checksum of 0x for DHCP Requests. According to the RFC this is a valid value and tells the receiving UDP stack not to check the checksum: http://www.faqs.org/rfcs/rfc768.html If the value is different from 0x the receiving UDP stack can perform a checksum check and if this fails, silently drop that packet. What we observe is: DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and is being answered. DHCP Request with UDP checksum 0x => ICMP Port Unreachable from FreeBSD. Can someone confirm this non RFC conform behaviour and knows how to fix it? As I understand, setting net.inet.udp.checksum to zero would not fix the problem, as this is only for packet generation. DHCP (isc-dhcp) uses bpf(4) device for reading and writing dhcp packets. Since bpf(4) device provides raw access to ether frames, udp checksum calculation must take place in the dhcp server code. You could use ktrace(1) if you want to make sure that a icmp packet is generated by the dhcp server. Also, you have said that icmp error message is port unreachable, that means, that there is no any udp socket which listens on 67 port. Can you check if dhcp-server listens on 67-udp port and there is no any firewall rules, which forbids udp packet to 67 port? -- Dmitry Banschikov
RE: 1gbit LFN WAN link - odd tcp behavior
What is the effective latency under load, and the packet loss probability? Just to add some more detail. Richard Scheffenegger > -Original Message- > From: William Salt [mailto:williamejs...@googlemail.com] > Sent: Montag, 27. Juni 2011 12:15 > To: freebsd-net@freebsd.org > Subject: 1gbit LFN WAN link - odd tcp behavior > > Hi All, > For the last couple of months i have been pulling my hair out > trying to solve this problem. > We have a 1Gbps transatlantic link from the UK to the US, which has > successfully passed the RFC2544 test. > > At either end, we have a media converter, and a supermicro server with > an > intel quad port NIC running pfsense 2 (freebsd 8.1) with the NIC > running on > the yandex IGB driver. > > We can pass 1gbps either way with UDP. However we are experiencing very > strange issues with tcp connections. > > With window scaling enabled, and a max socket buffer set to 16MB, we > see no > difference. > Even disabling window scaling and setting the window to 16MB makes no > difference. > > Each TCP connection starts very slowly, and will max out at around > 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. > > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. > > I have followed guides like this: > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > With no luck, and have tweaked, disabled, and enabled nearly every > relevant > sysctl parameter with no luck. > > Can anyone shed some light on this? > > I am now doubting the IGB driver, and am looking to swap out the cards > as a > last ditch effort. > However, we have tried different hardware (L3 switches, media convertes > + > laptops etc), and the symptoms still persist... > The only constant is freebsd 8.1 (or 8.2 for production systems). > > > Cheers in advance > Will > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
On 6/27/2011 4:50 PM, Adrian Minta wrote: > Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel dump > after a system freeze. I put all the files at: > http://pluto.stsisp.ro/fbsd/ > > I hope this will help somebody in finding the race condition. Dont know about the race, but one thing I would get rid of in your kernel config is the FLOWTABLE option as it has a few bugs still Also get rid of device gre device tap # Bridging device if_bridge device lagg if you are not using them Are you loading any klds ? Why the linux.ko and linprocfs.ko ? If you dont use it, get rid of it. I would also not run snmpd and disable devd as they will do a lot of work traversing all those interfaces. Also, how come your nics all show no carrier in the crash dump ? ---Mike > > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: udp checksum implementation error in FreeBSD 7.2?
> > What we observe is:
> >
> > DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and
> > is being
> > answered.
> > DHCP Request with UDP checksum 0x => ICMP Port Unreachable from
> > FreeBSD.
> >
> > Can someone confirm this non RFC conform behaviour and knows how to
> > fix it?
> >
> Well, I took a quick look at the sources (which are in
> sys/netinet/udp_usrreq.c
> in a function called udp_input() at about line#300) and it only does the
> checksum if it is non-zero. It looks like:
>if (uh->uh_sum) {
> do checksum
> (If you don't have kernel sources handy, you can find them here:
> http://svn.freebsd.org/viewvc/base/releng/7.2)
As another poster commented, ISC dhcpd by default uses BPF, *not* the
kernel UDP implementation - this is done to be able to handle broadcast
packets. However, the mystery doesn't end here - because the ISC dhcpd
implementation *also* only cares about UDP packets with a non-zero
checksum. The code is in common/packet.c, routine decode_udp_ip_header()
which is used by BPF and other link level access methods (e.g. DLPI on
Solaris). From dhcp-4.2.0-P2/common/packet.c:
--
/* Compute UDP checksums, including the ``pseudo-header'', the UDP
header and the data. If the UDP checksum field is zero, we're
not supposed to do a checksum. */
data = upp + sizeof(udp);
len = ulen - sizeof(udp);
usum = udp.uh_sum;
udp.uh_sum = 0;
/* XXX: We have to pass &udp, because we have to zero the checksum
* field before calculating the sum...'upp' isn't zeroed.
*/
sum = wrapsum(checksum((unsigned char *)&udp, sizeof(udp),
checksum(data, len,
checksum((unsigned char *)&ip.ip_src,
8, IPPROTO_UDP + ulen;
udp_packets_seen++;
if (usum && usum != sum) {
udp_packets_bad_checksum++;
if (udp_packets_seen > 4 &&
(udp_packets_seen / udp_packets_bad_checksum) < 2) {
log_info ("%d bad udp checksums in %d packets",
udp_packets_bad_checksum, udp_packets_seen);
udp_packets_seen = udp_packets_bad_checksum = 0;
}
return -1;
}
--
The way I read the code - the UDP checksum is computed in all cases,
but is only *compared* with the original checksum field of the packet
if this field is non-zero.
Returning to the original claim of
> DHCP Request with UDP checksum 0x => ICMP Port Unreachable from
> FreeBSD.
I can see (e.g. using tcpdump) FreeBSD handle packets with a UDP checksum
field of 0 just fine - for instance on a busy name server. So I am quite
confident that your observed ICMP Port Unreachable is not generated by
the FreeBSD kernel, as long as you have the DHCP server listening on UDP
port 67.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
Good news ! Last night I remove FLOWTABLE option and since then the server is stable. No crash what so ever an I was able to increase the number of tunnels. > On 6/27/2011 4:50 PM, Adrian Minta wrote: >> Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel >> dump >> after a system freeze. I put all the files at: >> http://pluto.stsisp.ro/fbsd/ >> >> I hope this will help somebody in finding the race condition. > > Dont know about the race, but one thing I would get rid of in your > kernel config is the FLOWTABLE option as it has a few bugs still > > > Also get rid of > > > device gre > device tap > > # Bridging > device if_bridge > device lagg > > if you are not using them > > > Are you loading any klds ? Why the linux.ko and linprocfs.ko ? If you > dont use it, get rid of it. > > I would also not run snmpd and disable devd as they will do a lot of > work traversing all those interfaces. > > Also, how come your nics all show no carrier in the crash dump ? > > ---Mike > -- Best regards, Adrian MintaMA3173-RIPE +40726.110.369 +40212.022.660 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
Hi Adrian, > Good news ! > Last night I remove FLOWTABLE option and since then the server is stable. > No crash what so ever an I was able to increase the number of tunnels. Yeah, FLOWTABLE still needs work, good news on the stability. Could you perhaps drop us all a note in two weeks if things keep stable? I myself run similar setup, plan to increase traffic and number of sessions in few days, so I'm very interested in how things go for you. Cheers. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
On 6/28/2011 3:38 PM, Adrian Minta wrote: > Good news ! > Last night I remove FLOWTABLE option and since then the server is stable. > No crash what so ever an I was able to increase the number of tunnels. Thats great! If you are getting close to the CPU maxing out, consider getting rid of snmpd. Also, as a next step, try and run with ipv6 :) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
Hi, On Tue, 28 Jun 2011, Pawel Tyll wrote: Hi Adrian, Good news ! Last night I remove FLOWTABLE option and since then the server is stable. No crash what so ever an I was able to increase the number of tunnels. Yeah, FLOWTABLE still needs work, good news on the stability. Could you perhaps drop us all a note in two weeks if things keep stable? from all I have seen all the work FLOWTABLE needs is finally being dropped from the tree. Its a constant cause of trouble and from what I recall not even ipv6 capable. Greetings Christian I myself run similar setup, plan to increase traffic and number of sessions in few days, so I'm very interested in how things go for you. Cheers. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ixgbe> vlan addition and removal brings the interfaces down and up
Hi Andrew, could you please share the patch as I'm dying with this problem. What makes it worse is that on a busy router the DOWN/UP of the interfaces causes the ixgbe card to lose all network access until the box is rebooted. I can reproduce it easily on a variety of hosts from both HP and Dell. Therefore a patch that would not cause the card to reset would help a lot. -- Igor On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer wrote: > I have a patch that will fix this. Please give me a little while to clean it > up, and I will send it out on the list. > > -Andrew > > On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: > >> Hi All, >> >> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >> with direct attach cables and there is one thing keeps bothering me. >> I've been searching the Internet for any information with no luck. I >> would also assume that the problem is widely known, and I found one >> related PR kern/141285 but that one was closed unsolved. >> >> When a VLAN interface is added or removed to from the ix interfaces >> the parent interface is briefly brought down and up. This event is >> visible for all applications and the switches. With my use case I add >> and remove VLAN interfaces on the fly and the described behavior >> causes undesired effects, especially for BGP daemons that are >> configured to monitor one of permanent VLAN interfaces. >> >> I use FreeBSD 7-STABLE and the behavior is the same with stock >> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >> -vlanhwtso with no effect. >> >> Could someone help me to stop the cards behaving this way? I do not >> mind some performance penalties, nor running in permanent promiscuous >> mode. I just want the card to stay up all the time regardless of the >> vlan interfaces attached to it. >> >> Any help, links, patches are much appreciated. >> >> Regards, >> >> Igor Anishchuk >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > -- > Andrew Boyer abo...@averesystems.com > > > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
On Jun 28, 2011, at 8:27 PM, Christian Kratzer wrote: > Hi, > > On Tue, 28 Jun 2011, Pawel Tyll wrote: >> Hi Adrian, >> >>> Good news ! >>> Last night I remove FLOWTABLE option and since then the server is stable. >>> No crash what so ever an I was able to increase the number of tunnels. >> Yeah, FLOWTABLE still needs work, good news on the stability. Could >> you perhaps drop us all a note in two weeks if things keep stable? > > from all I have seen all the work FLOWTABLE needs is finally being > dropped from the tree. Its a constant cause of trouble and from what > I recall not even ipv6 capable. Well, I'd like to point you at http://svnweb.freebsd.org/base?view=revision&revision=219775 and as an example at: http://svnweb.freebsd.org/base/head/sys/net/route.c?r1=223334&r2=22&pathrev=223334 That said, for some workloads it may be a fairly reasonable option. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ixgbe> vlan addition and removal brings the interfaces down and up
Hello Igor, Sorry for the delay. I'm a little hesitant to share our ixgbe patch to change this behavior because Jack has checked in changes to igb that make me think that our change is not correct. Or, at least, that he's probably working on fixing ixgbe the right way. Jack, are you planning to copy the reorganization of igb_setup_vlan_hw_support() over to ixgbe_setup_vlan_hw_support? -Andrew On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > Hi Andrew, > > could you please share the patch as I'm dying with this problem. > > What makes it worse is that on a busy router the DOWN/UP of the > interfaces causes the ixgbe card to lose all network access until the > box is rebooted. I can reproduce it easily on a variety of hosts from > both HP and Dell. Therefore a patch that would not cause the card to > reset would help a lot. > > -- Igor > > On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer wrote: >> I have a patch that will fix this. Please give me a little while to clean >> it up, and I will send it out on the list. >> >> -Andrew >> >> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >> >>> Hi All, >>> >>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>> with direct attach cables and there is one thing keeps bothering me. >>> I've been searching the Internet for any information with no luck. I >>> would also assume that the problem is widely known, and I found one >>> related PR kern/141285 but that one was closed unsolved. >>> >>> When a VLAN interface is added or removed to from the ix interfaces >>> the parent interface is briefly brought down and up. This event is >>> visible for all applications and the switches. With my use case I add >>> and remove VLAN interfaces on the fly and the described behavior >>> causes undesired effects, especially for BGP daemons that are >>> configured to monitor one of permanent VLAN interfaces. >>> >>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>> -vlanhwtso with no effect. >>> >>> Could someone help me to stop the cards behaving this way? I do not >>> mind some performance penalties, nor running in permanent promiscuous >>> mode. I just want the card to stay up all the time regardless of the >>> vlan interfaces attached to it. >>> >>> Any help, links, patches are much appreciated. >>> >>> Regards, >>> >>> Igor Anishchuk >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> -- >> Andrew Boyerabo...@averesystems.com >> >> >> >> >> -- Andrew Boyerabo...@averesystems.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ixgbe> vlan addition and removal brings the interfaces down andup
Pretty sure this is already in the source tree as it sounds like the same as the alias fix:- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.51;content-type=text%2Fplain There's also some additional fixes in the latest head version:- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.52;content-type=text%2Fplain Regards Steve - Original Message - From: "Igor Anishchuk" To: "Andrew Boyer" Cc: Sent: Tuesday, June 28, 2011 9:02 PM Subject: Re: ixgbe> vlan addition and removal brings the interfaces down andup Hi Andrew, could you please share the patch as I'm dying with this problem. What makes it worse is that on a busy router the DOWN/UP of the interfaces causes the ixgbe card to lose all network access until the box is rebooted. I can reproduce it easily on a variety of hosts from both HP and Dell. Therefore a patch that would not cause the card to reset would help a lot. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
On Tue, Jun 28, 2011 at 10:44 PM, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > On Jun 28, 2011, at 8:27 PM, Christian Kratzer wrote: > > > Hi, > > > > On Tue, 28 Jun 2011, Pawel Tyll wrote: > >> Hi Adrian, > >> > >>> Good news ! > >>> Last night I remove FLOWTABLE option and since then the server is > stable. > >>> No crash what so ever an I was able to increase the number of tunnels. > >> Yeah, FLOWTABLE still needs work, good news on the stability. Could > >> you perhaps drop us all a note in two weeks if things keep stable? > > > > from all I have seen all the work FLOWTABLE needs is finally being > > dropped from the tree. Its a constant cause of trouble and from what > > I recall not even ipv6 capable. > > Well, I'd like to point you at > > http://svnweb.freebsd.org/base?view=revision&revision=219775 > and as an example at: > > http://svnweb.freebsd.org/base/head/sys/net/route.c?r1=223334&r2=22&pathrev=223334 > > That said, for some workloads it may be a fairly reasonable option. > Hi Bjoern, Perhaps it would be best to document what those particular workloads are. Apparently, systems with small and seldom changing routing tables are good candidates. However, the distinction is not immediately obvious by skimming through the list archives. Regards, Vlad -- Good, fast & cheap. Pick any two. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: ixgbe> vlan addition and removal brings the interfaces down and up
Hmmm, I'll have to take a look at the code, and if I hadn't done it by now there might be some reason I couldn't, or hell, maybe I just forgot :) Will let you know. Jack -Original Message- From: Andrew Boyer [mailto:abo...@averesystems.com] Sent: Tuesday, June 28, 2011 1:32 PM To: Igor Anishchuk; Vogel, Jack Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down and up Hello Igor, Sorry for the delay. I'm a little hesitant to share our ixgbe patch to change this behavior because Jack has checked in changes to igb that make me think that our change is not correct. Or, at least, that he's probably working on fixing ixgbe the right way. Jack, are you planning to copy the reorganization of igb_setup_vlan_hw_support() over to ixgbe_setup_vlan_hw_support? -Andrew On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > Hi Andrew, > > could you please share the patch as I'm dying with this problem. > > What makes it worse is that on a busy router the DOWN/UP of the > interfaces causes the ixgbe card to lose all network access until the > box is rebooted. I can reproduce it easily on a variety of hosts from > both HP and Dell. Therefore a patch that would not cause the card to > reset would help a lot. > > -- Igor > > On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer wrote: >> I have a patch that will fix this. Please give me a little while to clean >> it up, and I will send it out on the list. >> >> -Andrew >> >> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >> >>> Hi All, >>> >>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>> with direct attach cables and there is one thing keeps bothering me. >>> I've been searching the Internet for any information with no luck. I >>> would also assume that the problem is widely known, and I found one >>> related PR kern/141285 but that one was closed unsolved. >>> >>> When a VLAN interface is added or removed to from the ix interfaces >>> the parent interface is briefly brought down and up. This event is >>> visible for all applications and the switches. With my use case I add >>> and remove VLAN interfaces on the fly and the described behavior >>> causes undesired effects, especially for BGP daemons that are >>> configured to monitor one of permanent VLAN interfaces. >>> >>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>> -vlanhwtso with no effect. >>> >>> Could someone help me to stop the cards behaving this way? I do not >>> mind some performance penalties, nor running in permanent promiscuous >>> mode. I just want the card to stay up all the time regardless of the >>> vlan interfaces attached to it. >>> >>> Any help, links, patches are much appreciated. >>> >>> Regards, >>> >>> Igor Anishchuk >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> -- >> Andrew Boyerabo...@averesystems.com >> >> >> >> >> -- Andrew Boyerabo...@averesystems.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
> Perhaps it would be best to document what those particular workloads are. > Apparently, systems with small and seldom changing routing tables are good > candidates. However, the distinction is not immediately obvious by skimming > through the list archives. Start reading here: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf patches for documentation are surely welcome by the docs people. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iwn -CURRENT drivers on -STABLE?
On Mon, Jun 27, 2011 at 7:00 PM, Adrian Chadd wrote: > Just -ampdutx. Ampdu RX is fine. :) > > Well, I would have loved to help test but it seems I can't even get -HEAD to boot on my machine. If I move the drive to a different machine it boots fine, so it's clearly some sort of hardware issue. Unless I can figure this out, I guess I'm stuck with 11g. Thanks, Patrick ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 and MPD5 stability issues
On Tue, Jun 28, 2011 at 11:53 PM, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > > > Perhaps it would be best to document what those particular workloads are. > Apparently, systems with small and seldom changing routing tables are good > candidates. However, the distinction is not immediately obvious by skimming > through the list archives. > > Start reading here: > http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf > > patches for documentation are surely welcome by the docs people. > > Thanks! That was a suggestion, though, not a request :) I'm one happy flowtable user. -- Good, fast & cheap. Pick any two. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
