Re: performance of pptp with mpd
Francisco J. Medina Jimenez writes: > I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers > using W2k clients is much better than using XP or Win9x (in same > conditions). Are there any parameters to adjust or it's problem of pptp > client implementation? The different Windowses have different PPP characteristics. For Win9x, make sure you have the latest MS updates. Try playing with 'set link mtu ...', mpp-stateless, and enabling multilink. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the packet will get rejected when it reaches the other IPSEC node. You can create forwarding rules which NAT packets destined for other hosts and leave the IPSEC packets alone. You'll have to create an ipfw ruleset. You also probably need to understand the difference between tunnel mode and transport mode in IPSEC. Transport mode is host-to-host. Tunnel mode is network-to-network. (I may have those two backwards) You are trying to do a hybrid; I don't think that is allowed in IPSEC. One of the hardest things for me to get used to in IPSEC was the fact that two machines could actually not talk to one another normally, but could create an IPSEC tunnel. Also, two machines that could actually talk to one another was not sufficient to guarantee that they could set up a tunnel. Good luck, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
Where could I get the errata sheet? Could the numbers be packet thresholds? 28 and 128 packets respectively? Anything else that can be done? Does PCI width/speed affect the amount of time spent in the kernel interrupt or are the PCI transfers asynchronous? Pete - Original Message - From: "Jim McGrath" <[EMAIL PROTECTED]> To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]> Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 18, 2002 7:49 AM Subject: RE: ENOBUFS > Careful here. Read the errata sheet!! I do not believe the em driver uses > these parameters, and possibly for a good reason. > > Jim > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > Sent: Thursday, October 17, 2002 11:12 PM > > To: Petri Helenius > > Cc: Lars Eggert; [EMAIL PROTECTED] > > Subject: Re: ENOBUFS > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > ... > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > just reading the source code, yes, it appears that the card has > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > and usage in sys/dev/em/* . I don't know in what units are the values > > (28 and 128, respectively), but it does appear that tx interrupts are > > delayed a bit more than rx interrupts. > > > > They are not user-configurable at the moment though, you need to rebuild > > the kernel. > > > > cheers > > luigi > > > > > 50kpps the card generates 10k interrupts a second. Sending generates > > > way less. This is about 300Mbps so with the average packet size of > > > 750 there should be room for more packets on the interface queue > > > before needing to service an interrupt? > > > > > > What´s the way to access kernel adapter-structure? Is there an utility > > > that can view the values there? > > > > > > > Pete > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
> > just reading the source code, yes, it appears that the card has > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > and usage in sys/dev/em/* . I don't know in what units are the values > (28 and 128, respectively), but it does appear that tx interrupts are > delayed a bit more than rx interrupts. > The thing what is looking suspect is also the "small packet interrupt" feature which does not seem to get modified in the em driver but is on the defines. If that would be on by default, we´d probably see interrupts "too often" because it tries to optimize interrupts for good throughput on small number of TCP streams. Should these questions be posted to the authors of the driver? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: IPSEC/NAT issues
On a side note: For whoever tackles this project - a sysctl variable would be nice to turn the second ipsec processing(pre ipfw/ipf) on or off. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPsec/NAT FreeBSD
I was just looking at the latest postings from the net list and was reading yours when I found this e-mail you sent directly to me. I've had some success with IPSEC/IPFW and NATD. The problem lies in the kernel, ipsec and ipfw ordering of where the packets flow. What you are trying to do - makes perfect sense. But the kerenl is screwing you up. I took and duplicated your problem using a 4.6.2-R Machine with a Lan behind it and a 4.4-R machine. So here lies the problem: The outgoing packets from the lan get nat-ed and then ipsec-ed. The incoming packets are ipsec-ed but don't pass to natd as a regular packet. because ipsec takes place after ipfw. I think a solution to the problem would be to have ipsec processing take place both before and after ipfw(or ipf). Somebody else though will have to figure out how to make a custom kernel to do double ipsec processing because I'm not a C programmer. Hope somebody can make it happen, for both of us. - Jonathan Charles Henrich wrote: I've run across your postings in the FreeBSD mailing lists, and it looks like your trying to do what I am trying to do. I was wondering if you had solved it? That is, I have a nat'd network, and I want packets from any host on the inside of the network to be ESP encapsilated after nat translation to one particular host outside the network. It looks like it works, kinda. Packets hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way. Racoon even does a proper key exchange. On the return path however, the packed is unencapsilated, but nat seems to refuse to reverse the natting? Were you able to solve this problem? Thanks for any advice! -Crh Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPsec/NAT FreeBSD
On Thu, 17 Oct 2002, Jonathan Feally wrote: > > I think a solution to the problem would be to have ipsec processing take > place both before and after ipfw(or ipf). > Somebody else though will have to figure out how to make a custom kernel > to do double ipsec processing because I'm not a C programmer. > > Hope somebody can make it happen, for both of us. > - Jonathan > > Charles Henrich wrote: > > >I've run across your postings in the FreeBSD mailing lists, and it looks like > >your trying to do what I am trying to do. I was wondering if you had solved > >it? That is, I have a nat'd network, and I want packets from any host on the > >inside of the network to be ESP encapsilated after nat translation to one > >particular host outside the network. It looks like it works, kinda. Packets > >hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way. > >Racoon even does a proper key exchange. On the return path however, the > >packed is unencapsilated, but nat seems to refuse to reverse the natting? > >Were you able to solve this problem? > > > >Thanks for any advice! > > I don't let IPSEC packets be processed by natd through the divert socket, in fact I use ipfw skipto rules: 00100 skipto 65535 ip from 66.80.117.2 to 64.14.48.150 00200 skipto 65535 ip from 64.14.48.150 to 66.80.117.2 00300 skipto 65535 ip from 10.80.116.0/23 to 10.0.0.0/24 00400 skipto 65535 ip from 10.0.0.0/24 to 10.80.116.0/23 00500 divert 8668 ip from any to any via fxp0 65535 allow ip from any to any It works well. -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Oper @ efnet.dkom.atAilleCat@EFNet UNIXNet IRC Admin @ femme.ipv6.sapphite.org AilleCat@UNIXNet Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: ENOBUFS
I have to tread carefully here because I was under NDA at my previous company. My work was with the wx driver, but hardware problems are hardware problems. There are a lot of performance enhancing features in the 82544. You will notice that the em driver does not use them. This may be for a reason :-( Our implementation ran with transmit interrupts disabled, so I can't comment on TIDV and am not allowed to comment on RIDV. The Receive Descriptor Threshold interrupt showed promise under high load (Rx interrupts disabled) but you would need to add a timeout function, 1 msec. or faster, to process receive descriptors under low load. Jim > -Original Message- > From: [EMAIL PROTECTED] > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > Sent: Friday, October 18, 2002 12:56 AM > To: Jim McGrath > Cc: Petri Helenius; Lars Eggert; [EMAIL PROTECTED] > Subject: Re: ENOBUFS > > > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote: > > Careful here. Read the errata sheet!! I do not believe the em > driver uses > > these parameters, and possibly for a good reason. > > as if i had access to the data sheets :) > > cheers > luigi > > Jim > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > Sent: Thursday, October 17, 2002 11:12 PM > > > To: Petri Helenius > > > Cc: Lars Eggert; [EMAIL PROTECTED] > > > Subject: Re: ENOBUFS > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > ... > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > just reading the source code, yes, it appears that the card has > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > delayed a bit more than rx interrupts. > > > > > > They are not user-configurable at the moment though, you need > to rebuild > > > the kernel. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: ENOBUFS
> Where could I get the errata sheet? Product Specification Updates i.e. errata, and the Product Specification itself are available from Intel under a Non Disclosure Agreement. Unless you work for a company that is doing business with Intel, they are probably not obtainable. > > Could the numbers be packet thresholds? 28 and 128 packets respectively? > I can't answer that directly because of NDA. Let us apply some logic here. If they were packet counts, under very low load conditions e.g. a single telnet session, the telnet link would be unusable. This leads us to the conclusion that they must be time values. Jim > Anything else that can be done? Does PCI width/speed affect the amount of > time spent in the kernel interrupt or are the PCI transfers asynchronous? > > Pete > > - Original Message - > From: "Jim McGrath" <[EMAIL PROTECTED]> > To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]> > Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, October 18, 2002 7:49 AM > Subject: RE: ENOBUFS > > > > Careful here. Read the errata sheet!! I do not believe the em > driver uses > > these parameters, and possibly for a good reason. > > > > Jim > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > Sent: Thursday, October 17, 2002 11:12 PM > > > To: Petri Helenius > > > Cc: Lars Eggert; [EMAIL PROTECTED] > > > Subject: Re: ENOBUFS > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > ... > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > just reading the source code, yes, it appears that the card has > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > delayed a bit more than rx interrupts. > > > > > > They are not user-configurable at the moment though, you need > to rebuild > > > the kernel. > > > > > > cheers > > > luigi > > > > > > > 50kpps the card generates 10k interrupts a second. Sending generates > > > > way less. This is about 300Mbps so with the average packet size of > > > > 750 there should be room for more packets on the interface queue > > > > before needing to service an interrupt? > > > > > > > > What´s the way to access kernel adapter-structure? Is there > an utility > > > > that can view the values there? > > > > > > > > > Pete > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
For those who had problems with MPD server and win clients
IMHO, there is a combination of two bugs.
1) MPD (3.9, at least) calculates and sets mtu (bund.c/BundUpdateParams())
at wrong time -- when one of MIN() args is still zero. ioctl with bizzare mtu
value rejected, thus leaving the default (1500), which in turn is above
MRU requested from win client (1400 for multilink).
[at the same time on other end of connection]
2) MS clients has setting 'Negotiate multi-link for single link connections'.
Even when this option is negotiated, ms client does not understand partial MP
(RFC1990) fragments. When both (begin, end) flags set, then everything is fine,
as long as everything fits MRU.
Would anyone review and test this patches?
(bund.c patches a kind of nitpicking -- enabled is not negotiated :-))
--- bund.c.orig Tue Oct 8 13:40:15 2002
+++ bund.c Fri Oct 18 17:17:23 2002
@@ -548,22 +548,20 @@
mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */
break;
case 1:
- if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) {
- mtu = MIN(bund->links[the_link]->lcp.peer_mru,
- bund->links[the_link]->phys->type->mtu);
- break;
- }
- /* FALLTHROUGH */
+ mtu = bund->links[the_link]->lcp.peer_mru;
+ break;
default: /* We fragment everything, use bundle MRRU */
mtu = bund->mp.peer_mrru;
break;
}
- /* Subtract to make room for various frame-bloating protocols */
- if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION))
-mtu = CcpSubtractBloat(mtu);
- if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION))
-mtu = EcpSubtractBloat(mtu);
+ if (bm->n_up > 0) {
+/* Subtract to make room for various frame-bloating protocols */
+if (bund->ccp.xmit != NULL)
+ mtu = CcpSubtractBloat(mtu);
+if (bund->ecp.xmit != NULL)
+ mtu = EcpSubtractBloat(mtu);
+ }
/* Update interface MTU */
if (mtu > BUND_MAX_MTU)
--- iface.c.origTue Oct 8 14:28:09 2002
+++ iface.c Sat Oct 12 11:54:36 2002
@@ -346,6 +346,8 @@
/* Sanity */
assert(!iface->ip_up);
+ BundUpdateParams();
+
/* Set addresses and bring interface up */
snprintf(hisaddr, sizeof(hisaddr), "%s", inet_ntoa(iface->peer_addr));
ExecCmd(LG_IFACE, "%s %s %s %s netmask 0x %slink0",
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > packet will get rejected when it reaches the other IPSEC node. Not exactly true. I use a Windows Nortel Contivity client behind NAT just fine. If you're using an AH association (header authentication) that will not pass through NAT. I'm sure someone on this list may come up with a fancy trick for FreeBSD, but generally the statement is true. AH detects the NAT changes as header corruption. But if you're only using ESP (encryption of payload) that will work fine. Most turn on both AH and ESP by default, but that isn't always the case as in the Nortel boxes. On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel endpoint rather than my windows boxes. It's a dynamic IP, so it's catch-22 right now. I can't create a tunnel or SPD policy entry before I know the IP addresses, and IKE/racoon can't start without those things. So, if someone happens to be ripping the IPsec processing apart, something to eliminate this catch-22 would be nice (: (spd entries pointing to an unconfigured or dummy tunnel, for example) Thanks! - Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re[2]: IPSEC/NAT issues
Hello Matthew, Friday, October 18, 2002, 9:39:51 PM, you wrote: MZ> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: >> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the >> packet will get rejected when it reaches the other IPSEC node. MZ> Not exactly true. I use a Windows Nortel Contivity client behind NAT just MZ> fine. Yup, I use a Windows Nortel Contivity client behind a FreeBSD userland PPP NAT just fine too. -- Best regards, Michaelmailto:mikechoo@;opensos.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
pppd rechallenge bug?
Hi. Sorry for off-topic, but maybe authors of pppd reads this mail-list.. When porting latest pppd (2.4.1) to RTEMS OS I noticed that auth_withpeer_success() does not check current operation phase thus if we enable CHAP rechallenge , each rechallenge will bring us to network phase (by calling auth_withpeer_success()). Is this intent? -- - " Why do you call this software 'beta' ? " - " Cuz it beta than nothin' ! " To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
Matthew Zahorik wrote: On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the packet will get rejected when it reaches the other IPSEC node. Not exactly true. I use a Windows Nortel Contivity client behind NAT just fine. Reading his first post, the original poster wants to IPsec NAT'ed packets, not vice versa. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ENOBUFS
(I´ll throw in the address found in the README of the driver, maybe somebody there has access to appropriate documentation / is willing to work on documenting tunables and optimizing the performance) > I have to tread carefully here because I was under NDA at my previous > company. My work was with the wx driver, but hardware problems are hardware > problems. There are a lot of performance enhancing features in the 82544. The chips I have are 82546. Is your recommendation to steer away from Intel Gigabit Ethernet chips? What would be more optimal alternative? > You will notice that the em driver does not use them. This may be for a > reason :-( Our implementation ran with transmit interrupts disabled, so I > can't comment on TIDV and am not allowed to comment on RIDV. > Maybe I´ll play with the value and see what happens. Any comments on the question how to access the adapter structure from userland? > The Receive Descriptor Threshold interrupt showed promise under high load > (Rx interrupts disabled) but you would need to add a timeout function, 1 > msec. or faster, to process receive descriptors under low load. > Luigi´s polling work would be useful here. That would lead to incorrect timestamps on the packets, though? Pete > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > Sent: Friday, October 18, 2002 12:56 AM > > To: Jim McGrath > > Cc: Petri Helenius; Lars Eggert; [EMAIL PROTECTED] > > Subject: Re: ENOBUFS > > > > > > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote: > > > Careful here. Read the errata sheet!! I do not believe the em > > driver uses > > > these parameters, and possibly for a good reason. > > > > as if i had access to the data sheets :) > > > > cheers > > luigi > > > Jim > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > > Sent: Thursday, October 17, 2002 11:12 PM > > > > To: Petri Helenius > > > > Cc: Lars Eggert; [EMAIL PROTECTED] > > > > Subject: Re: ENOBUFS > > > > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > > ... > > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > > > just reading the source code, yes, it appears that the card has > > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > > delayed a bit more than rx interrupts. > > > > > > > > They are not user-configurable at the moment though, you need > > to rebuild > > > > the kernel. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: ENOBUFS
> The chips I have are 82546. Is your recommendation to steer away > from Intel > Gigabit Ethernet chips? What would be more optimal alternative? > The 82543/82544 chips worked well in vanilla configurations. I never played with an 82546. The em driver is supported by Intel, so any chip features it uses should be safe. When testing with a SmartBits, 64 byte packets and high line utilization, I ran into problems when RIDV was enabled. This may be fixed with the 82546, but I have no way of verifying this. > Maybe I´ll play with the value and see what happens. Any comments on > the question how to access the adapter structure from userland? > We added sysctls to the wx driver to allow tuning/testing of various parameters. The same could be done to the em driver. You will likely need to do more than just modify fields in the adapter structure. The control register you are targeting will need to be rewritten by the sysctl. Jim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
In reply to "Jim McGrath" <[EMAIL PROTECTED]> : > > > Where could I get the errata sheet? > > Product Specification Updates i.e. errata, and the Product Specification > itself are available from Intel under a Non Disclosure Agreement. Unless > you work for a company that is doing business with Intel, they are probably > not obtainable. > > > > Could the numbers be packet thresholds? 28 and 128 packets respectively? > > > I can't answer that directly because of NDA. Let us apply some logic here. > If they were packet counts, under very low load conditions e.g. a single > telnet session, the telnet link would be unusable. This leads us to the > conclusion that they must be time values. Based on the source code for the sk driver (look for "interrupt moderation" in if_sk.c) I would suspect that those values represent time in microseconds. My guess (based on no privileged information whatsoever) is that if we've not interrupted in microseconds and we have something to send (or we've received something) go ahead and raise an interrupt. Just a guess. I'm perfectly willing to be wrong about this --eli > > Jim > > Anything else that can be done? Does PCI width/speed affect the amount of > > time spent in the kernel interrupt or are the PCI transfers asynchronous? > > > > Pete > > > > - Original Message - > > From: "Jim McGrath" <[EMAIL PROTECTED]> > > To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]> > > Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Friday, October 18, 2002 7:49 AM > > Subject: RE: ENOBUFS > > > > > > > Careful here. Read the errata sheet!! I do not believe the em > > driver uses > > > these parameters, and possibly for a good reason. > > > > > > Jim > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > > Sent: Thursday, October 17, 2002 11:12 PM > > > > To: Petri Helenius > > > > Cc: Lars Eggert; [EMAIL PROTECTED] > > > > Subject: Re: ENOBUFS > > > > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > > ... > > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > > > just reading the source code, yes, it appears that the card has > > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > > delayed a bit more than rx interrupts. > > > > > > > > They are not user-configurable at the moment though, you need > > to rebuild > > > > the kernel. > > > > > > > > cheers > > > > luigi > > > > > > > > > 50kpps the card generates 10k interrupts a second. Sending generates > > > > > way less. This is about 300Mbps so with the average packet size of > > > > > 750 there should be room for more packets on the interface queue > > > > > before needing to service an interrupt? > > > > > > > > > > What´s the way to access kernel adapter-structure? Is there > > an utility > > > > > that can view the values there? > > > > > > > > > > > Pete > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message msg07192/pgp0.pgp Description: PGP signature
Re: High interrupt load on firewalls
On Wed, 9 Oct 2002, Attila Nagy wrote: With a dc ethernet card and ~45K packets per second, an XP1700 system went from > 50% interrupt to < 1%. I was astounded at the change! If all it takes to get Gb interfaces polling is to send Luigi a card then he needs to send me his shipping address:) --- David > Hello, > > > You might want to try out some of the Intel gigabit boards. At least > > we've got an engineer from Intel who maintains the driver. > I'm far from being a FreeBSD expert, but Luigi Rizzo's polling patch > helped me a lot in similar cases to get better performance. > > >From POLLING(4): > DESCRIPTION > "Device polling" (polling for brevity) refers to a technique to handle > devices that does not rely on the latter to generate interrupts when they > need attention, but rather lets the CPU poll devices to service their > needs. This might seem inefficient and counterintuitive, but when done > properly, polling gives more control to the operating system on when and > how to handle devices, with a number of advantages in terms of system > responsivity and performance. > > AFAIK there are only two problems about that: > SUPPORTED DEVICES > Polling requires explicit modifications to the device drivers. As of > this writing, the dc, fxp, rl and sis devices are supported, with other > in the works. > > (no Gigabit cards) > > and > sys/kern/kern_poll.c: > [...] > #ifdef SMP > #include "opt_lint.h" > #ifndef COMPILING_LINT > #error DEVICE_POLLING is not compatible with SMP > #endif > #endif > [...] > > (no SMP support) > > As stated above, I'm not an expert, but my opinion is that polling would > be the best on the Gigabit cards (due to their capacity) and not the Fast > Ethernet ones. > > Maybe we could start sending GE hardware to Luigi :) > > --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- > Attila Nagy e-mail: [EMAIL PROTECTED] > Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) > cell.: +3630 306 6758 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hardware" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Strange FTP TCP Window Problem
This has got me stumped. I must be missing something obvious. I am trying to download some files via FTP. There are four files. Three download just fine, one just won't go. Since the three work fine, I assume it's not PORT vs. PASV, NAT, or other firewall issues, that is, the usual suspects have been eliminated. But what is really strange is that it looks like _my client_ is the one causing the headaches. Here is a tcpdump(8) of the data connection. Keep an eye on the window values my client is sending back, 09:15:11.097800 a.b.c.136.29826 > d.e.f.17.18747: S [tcp sum ok] 2410623756:2410623756(0) win 16384 (ttl 64, id 50031, len 64) 09:15:11.118335 d.e.f.17.18747 > a.b.c.136.29826: S [tcp sum ok] 2932757104:2932757104(0) ack 2410623757 win 16384 (ttl 56, id 24108, len 60) 09:15:11.118443 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1 win 16500 (ttl 64, id 43640, len 52) 09:15:11.156424 d.e.f.17.18747 > a.b.c.136.29826: . 1:501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24111, len 552) 09:15:11.159468 d.e.f.17.18747 > a.b.c.136.29826: . 501:1001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24112, len 552) 09:15:11.227371 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1001 win 15500 [tos 0x8] (ttl 64, id 61006, len 52) 09:15:11.258205 d.e.f.17.18747 > a.b.c.136.29826: . 1001:1501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24113, len 552) 09:15:11.261225 d.e.f.17.18747 > a.b.c.136.29826: . 1501:2001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24114, len 552) 09:15:11.279923 d.e.f.17.18747 > a.b.c.136.29826: . 2001:2501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24115, len 552) 09:15:11.427395 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 2501 win 14000 [tos 0x8] (ttl 64, id 40196, len 52) 09:15:11.457865 d.e.f.17.18747 > a.b.c.136.29826: . 2501:3001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24116, len 552) 09:15:11.461105 d.e.f.17.18747 > a.b.c.136.29826: . 3001:3501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24117, len 552) 09:15:11.480485 d.e.f.17.18747 > a.b.c.136.29826: . 3501:4001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24118, len 552) 09:15:11.483702 d.e.f.17.18747 > a.b.c.136.29826: . 4001:4501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24119, len 552) 09:15:11.627707 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 4501 win 12000 [tos 0x8] (ttl 64, id 44302, len 52) 09:15:11.648692 d.e.f.17.18747 > a.b.c.136.29826: . 4501:5001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24120, len 552) 09:15:11.659731 d.e.f.17.18747 > a.b.c.136.29826: . 5001:5501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24121, len 552) 09:15:11.670448 d.e.f.17.18747 > a.b.c.136.29826: . 5501:6001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24122, len 552) 09:15:11.673581 d.e.f.17.18747 > a.b.c.136.29826: . 6001:6501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24123, len 552) 09:15:11.692780 d.e.f.17.18747 > a.b.c.136.29826: . 6501:7001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24124, len 552) 09:15:11.827393 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 7001 win 9500 [tos 0x8] (ttl 64, id 38068, len 52) 09:15:11.855900 d.e.f.17.18747 > a.b.c.136.29826: . 7001:7501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24125, len 552) 09:15:11.860077 d.e.f.17.18747 > a.b.c.136.29826: . 7501:8001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24126, len 552) 09:15:11.878834 d.e.f.17.18747 > a.b.c.136.29826: . 8001:8501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24127, len 552) 09:15:11.881856 d.e.f.17.18747 > a.b.c.136.29826: . 8501:9001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24128, len 552) 09:15:11.892382 d.e.f.17.18747 > a.b.c.136.29826: . 9001:9501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24129, len 552) 09:15:11.903415 d.e.f.17.18747 > a.b.c.136.29826: . 9501:10001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24130, len 552) 09:15:12.027385 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 10001 win 6500 [tos 0x8] (ttl 64, id 60342, len 52) 09:15:12.052757 d.e.f.17.18747 > a.b.c.136.29826: . 10001:10501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24131, len 552) 09:15:12.063589 d.e.f.17.18747 > a.b.c.136.29826: . 10501:11001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24132, len 552) 09:15:12.074515 d.e.f.17.18747 > a.b.c.136.29826: . 11001:11501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24133, len 552) 09:15:12.078151 d.e.f.17.18747 > a.b.c.136.29826: . 11501:12001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24134, len 552) 09:15:12.096930 d.e.f.17.18747 > a.b.c.136.29826: . 12001:12501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24135, len 552) 09:15:12.099980 d.e.f.17.18747 > a.b.c.136.29826: . 12501:13001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24136, len 552) 09:15:12.110647 d.e.f.17.18747 > a.b.c.136.29826: . 13001:13501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24137, len 552) 09:15:12.
Re: High interrupt load on firewalls
On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote: > On Wed, 9 Oct 2002, Attila Nagy wrote: > > With a dc ethernet card and ~45K packets per second, an XP1700 system went > from > 50% interrupt to < 1%. I was astounded at the change! that is partly cheating, because with polling, some of the work which was done in an interrupt context is done elsewere. Still you might have some significant load reduction, i admit :) > If all it takes to get Gb interfaces polling is to send Luigi a card then > he needs to send me his shipping address:) all it takes is to look at the source code in some of the supported cards -- the changes are clearly marked by #ifdef DEVICE_POLLING/#endif blocks and are rather trivial in most cases (not all of them, 'fxp' was particularly tricky to get right!). cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds. The em driver currently uses these to enable interrupt coalescing on the cards. Thanks, Prafulla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, 18 Oct 2002, Petri Helenius wrote:
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but it does appear that tx interrupts are
> > delayed a bit more than rx interrupts.
> >
> The thing what is looking suspect is also the "small packet interrupt" feature
> which does not seem to get modified in the em driver but is on the defines.
>
> If that would be on by default, we´d probably see interrupts "too often"
> because it tries to optimize interrupts for good throughput on small number
> of TCP streams.
>
Hmm. Might that explain the abysmal performance of the em driver with
packets smaller than 333 bytes?
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: ... > Hmm. Might that explain the abysmal performance of the em driver with > packets smaller than 333 bytes? what do you mean ? it works great for me. even on -current i can push out over 400kpps (64byte frames) on a 2.4GHz box. luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: High interrupt load on firewalls
On Fri, 18 Oct 2002, Luigi Rizzo wrote: > On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote: > > On Wed, 9 Oct 2002, Attila Nagy wrote: > > > > With a dc ethernet card and ~45K packets per second, an XP1700 system went > > from > 50% interrupt to < 1%. I was astounded at the change! > > that is partly cheating, because with polling, some of the work which > was done in an interrupt context is done elsewere. Still you might > have some significant load reduction, i admit :) Very significant. The system went from maxed out at 30K pps to 35% idle at > 40K pps. I suspect it's an extreme case with the dc card. I've observed less with the fxp. Thanks for all the work Luigi:) --- David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, Oct 18, 2002 at 06:21:37PM +0300, Petri Helenius wrote: ... > Luigi´s polling work would be useful here. That would lead to incorrect > timestamps > on the packets, though? polling introduce an extra uncertainty which might be as large as an entire clock tick, yes. But even with interrupts, you cannot trust the time when the interrupt driver is run -- there are cases where an ISR is delayed by 10ms or more. And even when it runs, it might take quite a bit of time (up to a few 100's of microseconds) to drain the receive queue from packets received earlier. in normal cases, timestamps are reasonably accurate in both cases. In special cases, the error induced by having interrupts blocked causes errors which are much larger than polling alone. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> ...
> > Hmm. Might that explain the abysmal performance of the em driver with
> > packets smaller than 333 bytes?
>
> what do you mean ? it works great for me. even on -current i
> can push out over 400kpps (64byte frames) on a 2.4GHz box.
>
> luigi
>
Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
plugged into PCI-X bus:
FrameSize TxFramesRxFramesLostFrames Lost (%)
330 249984 129518 120466 48.19
331 249144 127726 121418 48.73
332 248472 140817 107655 43.33
333 247800 247800 0 0
It has no trouble handling frames 333 bytes or larger. But for any frame
332 bytes or smaller we consistently see ~50% packet loss. This same machine
easily pushes ~100Mps with the very same frame sizes using a bge card rather
than em.
I've gotten the same results with both em driver version 1.3.14 and 1.3.15
on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
How is the measurement done, does the box under test act as a router
with the smartbit pushing traffic in and expecting it back ?
The numbers are strange, anyways.
A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps,
not the 249 or so you are seeing. Looks as if the times were 40% off.
cheers
luigi
On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
...
> > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> >
> > luigi
> >
>
> Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> plugged into PCI-X bus:
>
> FrameSize TxFramesRxFramesLostFrames Lost (%)
> 330 249984 129518 120466 48.19
> 331 249144 127726 121418 48.73
> 332 248472 140817 107655 43.33
> 333 247800 247800 0 0
>
> It has no trouble handling frames 333 bytes or larger. But for any frame
> 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> easily pushes ~100Mps with the very same frame sizes using a bge card rather
> than em.
>
> I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
>
> Kelly
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> FreeBSD, The Power To Serve: http://www.freebsd.org/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
FYI. 82543 doesn't support PCI-X protocol.
For PCI-X support use 82544, 82545 or 82546 based cards.
-Prafulla
Kelly Yancey [[EMAIL PROTECTED]] wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > ...
> > > Hmm. Might that explain the abysmal performance of the em driver with
> > > packets smaller than 333 bytes?
> >
> > what do you mean ? it works great for me. even on -current i
> > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> >
> > luigi
> >
>
> Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> plugged into PCI-X bus:
>
> FrameSize TxFramesRxFramesLostFrames Lost (%)
> 330 249984 129518 120466 48.19
> 331 249144 127726 121418 48.73
> 332 248472 140817 107655 43.33
> 333 247800 247800 0 0
>
> It has no trouble handling frames 333 bytes or larger. But for any frame
> 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> easily pushes ~100Mps with the very same frame sizes using a bge card rather
> than em.
>
> I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
>
> Kelly
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> FreeBSD, The Power To Serve: http://www.freebsd.org/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> How is the measurement done, does the box under test act as a router
> with the smartbit pushing traffic in and expecting it back ?
>
The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go
through a Foundry ServerIron switch for VLAN tagging and then to the GigE
interface (where they are untagged). The box is acting as a router and all
traffic is directed out the fxp interface where it returns to the SmartBit.
> The numbers are strange, anyways.
>
> A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
> for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps,
> not the 249 or so you are seeing. Looks as if the times were 40% off.
>
Yeah, I've never made to much sense of the actual numbers myself. Our
resident SmartBit expert runs the tests and provides me with the results. I
use them more for getting an idea of the relative performance of one
configuration over another and not as absolute numbers themselves. I'll check
with our resident expert and see if he can explain how it calculates those
numbers. The point being, though, that there is an undeniable drop-off with
332 byte or smaller packets. We have never seen any such drop-off using the
bge driver.
Thanks,
Kelly
> cheers
> luigi
>
> On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
> ...
> > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > >
> > > luigi
> > >
> >
> > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > plugged into PCI-X bus:
> >
> > FrameSize TxFramesRxFramesLostFrames Lost (%)
> > 330 249984 129518 120466 48.19
> > 331 249144 127726 121418 48.73
> > 332 248472 140817 107655 43.33
> > 333 247800 247800 0 0
> >
> > It has no trouble handling frames 333 bytes or larger. But for any frame
> > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > than em.
> >
> > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> >
> > Kelly
> >
> > --
> > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > FreeBSD, The Power To Serve: http://www.freebsd.org/
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
On Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote: > On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: > > > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > > packet will get rejected when it reaches the other IPSEC node. > > Not exactly true. I use a Windows Nortel Contivity client behind NAT just > fine. > > If you're using an AH association (header authentication) that will not > pass through NAT. I'm sure someone on this list may come up with a fancy > trick for FreeBSD, but generally the statement is true. AH detects the > NAT changes as header corruption. > > But if you're only using ESP (encryption of payload) that will work fine. > > Most turn on both AH and ESP by default, but that isn't always the case as > in the Nortel boxes. Not exactly true. The current ESP standard has its own header authentification mechanism. To verify end-to-end header integrity, you need only use ESP with this option turned on (excuse me if I don't go to the RFC to remind myself of the formal name of the option). And as another data point, the Cisco VPN Concentrator (formerly Altiga) run just fine through NAT by default. They do ESP without header integrity checks and UDP encapsulation of the ESP to make it easier to run it through NAT (although that isn't "real" IPsec anymore). > On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel > endpoint rather than my windows boxes. It's a dynamic IP, so it's > catch-22 right now. I can't create a tunnel or SPD policy entry before I > know the IP addresses, and IKE/racoon can't start without those things. > > So, if someone happens to be ripping the IPsec processing apart, something > to eliminate this catch-22 would be nice (: (spd entries pointing to an > unconfigured or dummy tunnel, for example) What's the problem with just having the script that builds the SPD discover the IP address on its own? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
Oh, I *thought* the numbers you reported were pps but now i see that
nowhere you mentioned that.
But if things are as you say, i am seriously puzzled on what you
are trying to measure -- the output interface (fxp) is a 100Mbit/s
card which cannot possibly support the load you are trying to offer
to saturate the input link.
You should definitely clarify how fast the smartbits unit is pushing
out traffic, and whether its speed depends on the measured RTT.
It might well be that what you are
seeing is saturation of ipintrq, which happens because of some
strange timing issue -- nothing to do with the board.
In any case, at least in my experience, a 1GHz box with two em
cards can easily forward between 350 and 400kpps (64-byte frames) with a
4.6-ish kernel, and a 2.4GHz box goes above 650kpps.
cheers
luigi
On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > How is the measurement done, does the box under test act as a router
> > with the smartbit pushing traffic in and expecting it back ?
> >
> The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
> configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go
> through a Foundry ServerIron switch for VLAN tagging and then to the GigE
> interface (where they are untagged). The box is acting as a router and all
> traffic is directed out the fxp interface where it returns to the SmartBit.
>
> > The numbers are strange, anyways.
> >
> > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
> > for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps,
> > not the 249 or so you are seeing. Looks as if the times were 40% off.
> >
>
> Yeah, I've never made to much sense of the actual numbers myself. Our
> resident SmartBit expert runs the tests and provides me with the results. I
> use them more for getting an idea of the relative performance of one
> configuration over another and not as absolute numbers themselves. I'll check
> with our resident expert and see if he can explain how it calculates those
> numbers. The point being, though, that there is an undeniable drop-off with
> 332 byte or smaller packets. We have never seen any such drop-off using the
> bge driver.
>
> Thanks,
>
> Kelly
>
> > cheers
> > luigi
> >
> > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
> > ...
> > > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > > >
> > > > luigi
> > > >
> > >
> > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > > plugged into PCI-X bus:
> > >
> > > FrameSize TxFramesRxFramesLostFrames Lost (%)
> > > 330 249984 129518 120466 48.19
> > > 331 249144 127726 121418 48.73
> > > 332 248472 140817 107655 43.33
> > > 333 247800 247800 0 0
> > >
> > > It has no trouble handling frames 333 bytes or larger. But for any frame
> > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > > than em.
> > >
> > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> > >
> > > Kelly
> > >
> > > --
> > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > > FreeBSD, The Power To Serve: http://www.freebsd.org/
> > >
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-net" in the body of the message
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
As I think about it, it isn't IPSEC that needs to process twice once before and once after ipfw. Its the other way around. IPFW should first allow the ESP packets into the machine, then IPSEC extracted the secured packet, and then IPFW will process the normal packet again, thus allowing the divert to natd to acutally recieve the non-ipsec version of the packet. I did some poking around with the kernel code last night, but can't seem to figure out where to cause a packet that was recieved as IPSEC to go back though ipfw. I'll keep trying. The files I've been looking though are sys/netinet/ip_input.c and sys/netinet/ip_outpuit.c Charles Henrich wrote: I apologize for not CC'ing originally! I have a network/firewall where I want to nat an entire network. However, I also want nat traffic to one remote host in particular out on the internet to be IPsec'd as well. [A] (10.x) [B] (Nat) [C] (Real IP) I've setup IPsec on both machines, and from either machine (B,C) I can ssh to the other, with ipsec packets all happening happy as a clam. However if try a connection from behind the nat box to the remote host (A,C) the key exchange works fine (between B&C), but then no data flows back and forth. Anyone have any suggestions on this? Thanks! -Crh Charles Henrich [EMAIL PROTECTED] http://www.sigbus.com/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, 18 Oct 2002, Prafulla Deuskar wrote:
> FYI. 82543 doesn't support PCI-X protocol.
> For PCI-X support use 82544, 82545 or 82546 based cards.
>
> -Prafulla
>
That is alright, we aren't expecting PCI-X speeds. It is just that our only
PCI slot on the motherboard (1U rack-mount system) is a PCI-X slot. Shouldn't
the 82543 still function normally but only as at PCI speeds?
Thanks,
Kelly
>
> Kelly Yancey [[EMAIL PROTECTED]] wrote:
> > On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> >
> > > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > > ...
> > > > Hmm. Might that explain the abysmal performance of the em driver with
> > > > packets smaller than 333 bytes?
> > >
> > > what do you mean ? it works great for me. even on -current i
> > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > >
> > > luigi
> > >
> >
> > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > plugged into PCI-X bus:
> >
> > FrameSize TxFramesRxFramesLostFrames Lost (%)
> > 330 249984 129518 120466 48.19
> > 331 249144 127726 121418 48.73
> > 332 248472 140817 107655 43.33
> > 333 247800 247800 0 0
> >
> > It has no trouble handling frames 333 bytes or larger. But for any frame
> > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > than em.
> >
> > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> >
> > Kelly
> >
> > --
> > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > FreeBSD, The Power To Serve: http://www.freebsd.org/
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"No nation is permitted to live in ignorance with impunity."
-- Thomas Jefferson, 1821.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
On Fri, 18 Oct 2002, Luigi Rizzo wrote: > Oh, I *thought* the numbers you reported were pps but now i see that > nowhere you mentioned that. > Sorry. I just checked with our tester. Those are the total number of packets sent during the test. Each test lasted 10 seconds, so divde by 10 to get pps. > But if things are as you say, i am seriously puzzled on what you > are trying to measure -- the output interface (fxp) is a 100Mbit/s > card which cannot possibly support the load you are trying to offer > to saturate the input link. > We don't want to saturate the input link, only saturate the outbound link (100Mps). Oddly enough, the em card cannot do this with any packets less than 333 bytes and drops ~50% of the packets. But clearly this isn't a bottlenext issue because the drop-off isn't smooth. 332 byte backs cause ~50% packet loss; 333 byte packets cause 0% packet loss. > You should definitely clarify how fast the smartbits unit is pushing > out traffic, and whether its speed depends on the measured RTT. > It doesn't sound like the box is that smart. As it was explained to me, the test setup includes a desired 'load' to put on the wire: it is measured as a percentage of the wire speed. Since our SmartBit unit only supports 100base-T and doesn't understand vlans, we have to use 7 separate outbound ports, each configured for 14.25% load. To the GigE interface, this should appear as 99.75 megabits of data (including all headers/framing). > It might well be that what you are > seeing is saturation of ipintrq, which happens because of some > strange timing issue -- nothing to do with the board. > I don't understand why it would only happen with the em card and not with the bge under the exact same traffic (or even more demanding traffic, i.e. 64byte frames). Also, wouldn't packet gradually subside as we approached the 333 byte magic limit rather than the sudden drop-off we are seeing? > In any case, at least in my experience, a 1GHz box with two em > cards can easily forward between 350 and 400kpps (64-byte frames) with a > 4.6-ish kernel, and a 2.4GHz box goes above 650kpps. > We expect our kernel to be slower than that (we typically see ~120kpps for 64-byte frames using the bge driver and a 5701-based card) because we are using an fxp card for outbound traffic and have added additional code to the ip_input() processing. The point isn't absolute numbers, though, but trying to figure out why when using the em driver (and only with the em driver!) we see ~50% packet loss with packets smaller than 333 bytes (no matter what size, just that it is smaller). That is, 64 byte frames: ~50% packet loss; 332 byte frames: ~50% packet loss; 333 byte frames: 0% packet loss. That sort of sudden drop doesn't look like a bottleneck to me. We've mostly written the em driver off because of this. The bge driver works just fine performance wise; it was the sporadic watchdog timeouts that led us to investigate the Intel cards to begin with. I only mentioned it on-list because earlier Jim McGrath alluded to similar performance issues with the Intel GigE cards and small frames. Actually, at this point, I'm hoping that your polling patches for the em driver workaround whatever problem is causing the packet loss and am eagerly awaiting them to be committed. :) Thanks, Kelly > > On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote: > > On Fri, 18 Oct 2002, Luigi Rizzo wrote: > > > > > How is the measurement done, does the box under test act as a router > > > with the smartbit pushing traffic in and expecting it back ? > > > > > The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is > > configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go > > through a Foundry ServerIron switch for VLAN tagging and then to the GigE > > interface (where they are untagged). The box is acting as a router and all > > traffic is directed out the fxp interface where it returns to the SmartBit. > > > > > The numbers are strange, anyways. > > > > > > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which > > > for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps, > > > not the 249 or so you are seeing. Looks as if the times were 40% off. > > > > > > > Yeah, I've never made to much sense of the actual numbers myself. Our > > resident SmartBit expert runs the tests and provides me with the results. I > > use them more for getting an idea of the relative performance of one > > configuration over another and not as absolute numbers themselves. I'll check > > with our resident expert and see if he can explain how it calculates those > > numbers. The point being, though, that there is an undeniable drop-off with > > 332 byte or smaller packets. We have never seen any such drop-off using the > > bge driver. > > > > Thanks, > > > > Kelly > > > > > cheers > > > luigi > > > > > > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yanc
Re: ENOBUFS
On Fri, 18 Oct 2002, Kelly Yancey wrote:
> > You should definitely clarify how fast the smartbits unit is pushing
> > out traffic, and whether its speed depends on the measured RTT.
> >
>
> It doesn't sound like the box is that smart. As it was explained to me, the
> test setup includes a desired 'load' to put on the wire: it is measured as a
> percentage of the wire speed. Since our SmartBit unit only supports
> 100base-T and doesn't understand vlans, we have to use 7 separate outbound
> ports, each configured for 14.25% load. To the GigE interface, this should
> appear as 99.75 megabits of data (including all headers/framing).
>
Oops. That was actually the explanation of the SmartBits 'desired ILoad'
which I didn't quote in the posted numbers. The actual number of packets
transmitted is based on RTT. Sorry for the confusion,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"No nation is permitted to live in ignorance with impunity."
-- Thomas Jefferson, 1821.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ENOBUFS
> In special cases, the error induced by having interrupts blocked > causes errors which are much larger than polling alone. Which conditions block interrupts for longer than, say, a millisecond? Disk errors / wakeups? Anything occurring in "normal" conditions? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Is anyone can help this ?
Hi, Friends Could anyone advise me how to configure the Ethernet Card on my PC with speed=100Mbps, duplex=Full parameters ? My PC is running FreeBSD 3.1-Relase, the interface name is fxp0. The config example will be appreciated greatly ! Thanks a lot in advnace ! Feng To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Is anyone can help this ?
On Fri, 18 Oct 2002, Feng Li wrote:
>
> Hi, Friends
>
> Could anyone advise me how to configure the Ethernet
> Card on my PC with speed=100Mbps, duplex=Full parameters ?
>
> My PC is running FreeBSD 3.1-Relase, the interface name
> is fxp0.
>
> The config example will be appreciated greatly !
>
> Thanks a lot in advnace !
>
I don't remember if it is the same in 3.1, but per `man ifconfig` and `man
fxp`:
ifconfig fxp0 media 100baseTX mediaopt full-duplex
ifconfig fxp0 media 100BaseT mediaopt full-duplex
By the way, this sort of question belongs on -questions. Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
mpd PPTP server; client gateway
Hi, I've succesfully configured mpd as PPTP server for VPNs. But I have one stumbling block: when I connect to the server from a Windows XP client, the new connection gets assigned the same IP address as the default gateway. For instance: Client IP address: 192.168.250.240 Client netmask:255.255.255.0 Client gateway:192.168.250.240 the latter _should_ be 192.168.250.1. I can't ping to any other IP addresses inside the VPN. Has any one been there? Best regards, Carlos. __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPSEC/NAT issues
On Fri, 18 Oct 2002, Me, Myself, and I blathered: > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > packet will get rejected when it reaches the other IPSEC node. I still stand by my original statement. However, it won't be true for much longer. There is now a draft document (as of August 18, 2002) for dealing with NAT traversal. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-02.txt a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [4] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP. b) Incompatibility between checksums and NAT. TCP/UDP/SCTP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked on receipt, they will be invalidated by passage through a NAT or reverse NAT device. As a result, IPsec ESP will only pass unimpeded through a NAT if TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel mode or IPsec/GRE), or checksums are not calculated (as is possible with IPv4 UDP) -a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph TCP/IP
+ Archie Cobbs wrote: | Are you intending to have this hook into the normal FreeBSD TCP/IP | stack or be truly standalone? I read your question as the latter but | others seem to read it as the former. I am very much a babe in the woods at this point. I have no plan aside from reading as much as possible. My original idea was for it to be completely separate, so individual nodes could be replaced easily to try new algorithms. The subsequent discussion has been valuable nonetheless, and my plans certainly aren't written in stone. | If the latter, I'd suggest splitting it up into several netgraph | nodes, eg.: | | | | | | | | | ng_udpng_tcp |\ / | \ / |ng_ip | | | | |ng_arp | | | | | | | ng_ether That was how I pictured it as well (well before your diagram got munged by my editor that is) - thanks :) -- Steve Tremblett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
