From owner-freebsd-net Sun Jul 18 0:57:11 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 9D00114BE0 for ; Sun, 18 Jul 1999 00:57:07 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA17810; Sun, 18 Jul 1999 07:27:05 +0200 From: Luigi Rizzo Message-Id: <199907180527.HAA17810@labinfo.iet.unipi.it> Subject: Re: dummynet -> rate limiting To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sun, 18 Jul 1999 07:27:05 +0200 (MET DST) Cc: nagao@iij.ad.jp, des@flood.ping.uio.no, net@FreeBSD.ORG In-Reply-To: <199907172241.SAA24085@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Jul 17, 99 06:40:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1426 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Ok, i have no objections in principle, but i fail to see the use of > > pps limiting. What does it model in a context (IP) where packets for sure > > are not constant size ? > > Surely I shouldn't need to give this lesson to you, in particular, > Luigi. As we all know, performance of network elements can be broken > down into two components: per-packet cost, and per-bit (mostly ... > Cisco added a packet-rate-limiting feature in their ISP train some > time ago, and it made it into 12.0 on certain platforms, so at least > one big Cisco customer must think it's useful. But maybe IOS does not have bit-rate-limiting ? With dummynet you can achieve almost the same effect by setting a pipe with a very low bit rate, and yes, this will penalize big packets but if the purpose is protecting yourself, being conservative is not a such concern. Plus, for good protection you'd want both pps and bit-rate limiting, so this raises the issue whether these two features on a pipe should be mutually exclusive or not (in practice the first is ok since you can cascade pipes...). What i was wondering is whether this pps fits some economic or network model where a packet is major cost (or billing) component. other than that, i really don't mind having 'pps' limitations, or other things, in dummynet -- i am just trying to see if they solve problems that cannot be handled with already existing features. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 3:39:21 1999 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 73B2314E8D for ; Sun, 18 Jul 1999 03:39:09 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id MAA43635; Sun, 18 Jul 1999 12:38:39 +0200 (CEST) (envelope-from des) To: Garrett Wollman Cc: Luigi Rizzo , nagao@iij.ad.jp (NAGAO Tadaaki), net@FreeBSD.ORG Subject: Re: dummynet -> rate limiting References: <19990718034115X.nagao@iij.ad.jp> <199907171713.TAA16969@labinfo.iet.unipi.it> <199907172241.SAA24085@khavrinen.lcs.mit.edu> From: Dag-Erling Smorgrav Date: 18 Jul 1999 12:38:39 +0200 In-Reply-To: Garrett Wollman's message of "Sat, 17 Jul 1999 18:41:08 -0400 (EDT)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > It may be necessary to protect a part of the > network with high per-packet costs from an attacker intent on denying > service from that network or device -- think ping floods. More to the point, think SYN floods. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 4: 0:29 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.go2france.com (go2france.com [209.51.193.70]) by hub.freebsd.org (Postfix) with SMTP id 9EF951502C for ; Sun, 18 Jul 1999 04:00:26 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from superviseur [62.161.63.210] by mail.go2france.com with ESMTP (SMTPD32-4.03) id AF55B0D01B4; Sun, 18 Jul 1999 05:33:09 EDT Message-Id: <4.2.0.56.19990718124838.02eaa9d0@go2france.com> X-Sender: lconrad@go2france.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Sun, 18 Jul 1999 13:00:03 +0200 To: freebsd-net@freebsd.org From: Len Conrad Subject: Re: dummynet -> rate limiting In-Reply-To: <199907180527.HAA17810@labinfo.iet.unipi.it> References: <199907172241.SAA24085@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi > With dummynet you can achieve almost the same effect by setting a pipe with a very low bit rate, and yes, this will penalize big packets But if we could filter and rate-limit by protocol type, ie, icmp, smtp, ftp, then we could slice our pipe to fit our needs (icmp very low, smtp low, http hi, ftp wherever). I'm trying to decide between ET's bw-mgr or dummynet. Anybody here leaning on ET's bw-mgr in T1 and better throughputs with lotsa rules? Len To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 4:18:56 1999 Delivered-To: freebsd-net@freebsd.org Received: from orbitel.bg (ns.orbitel.bg [195.24.32.2]) by hub.freebsd.org (Postfix) with SMTP id 144FD1502C for ; Sun, 18 Jul 1999 04:18:49 -0700 (PDT) (envelope-from sstefanov@orbitel.bg) Received: (qmail 8883 invoked from network); 18 Jul 1999 11:16:52 -0000 Received: from pool3.orbitel.bg (HELO orbitel.bg) (stefan@195.24.32.131) by cow100.orbitel.bg with SMTP; 18 Jul 1999 11:16:52 -0000 Message-ID: <3791B81C.8EE31AC3@orbitel.bg> Date: Sun, 18 Jul 1999 14:18:52 +0300 From: Stefan Stefanov Organization: Orbitel Ltd X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Len Conrad Cc: freebsd-net@freebsd.org Subject: Re: dummynet -> rate limiting References: <199907172241.SAA24085@khavrinen.lcs.mit.edu> <4.2.0.56.19990718124838.02eaa9d0@go2france.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Len Conrad wrote: > > Luigi > With dummynet you can achieve almost the same effect by setting a > pipe with a very low bit rate, and yes, this will penalize big packets > > But if we could filter and rate-limit by protocol type, ie, icmp, smtp, > ftp, then we could slice our pipe to fit our needs (icmp very low, smtp > low, http hi, ftp wherever). > > I'm trying to decide between ET's bw-mgr or dummynet. > > Anybody here leaning on ET's bw-mgr in T1 and better throughputs with lotsa > rules? Just a warning I have been trying to use ET's products since a year and a half. I must say they are all CRAP! Simply there is no technical support for them... Mr. Denis Baah even called me and my colegue "fag", when we were trying to convince him, that his drivers are misbihaving. Even he called Alan Cox - "stupid"... For the Bandwidth Manager - it's quick and ugly hack like thing. sometimes it works, sometimes it does not. I have never had any consecutive equal results. And it makes a rock solid FreeBSD box very unstable indeed. I strongly suggets you NOT to buy their products. I would suggets you use dummynet, or ALTQ - Alternative Queing for FreeBSD. They all work like charm... PS: As from your message I think CBQ - a queing discipline from the ALTQ package is the way to go. -- Best Regards, Stefan Stefanov Orbitel Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 6:18:57 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 7CD2014C58 for ; Sun, 18 Jul 1999 06:18:53 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA18101; Sun, 18 Jul 1999 12:52:11 +0200 From: Luigi Rizzo Message-Id: <199907181052.MAA18101@labinfo.iet.unipi.it> Subject: Re: dummynet -> rate limiting To: lconrad@Go2France.com (Len Conrad) Date: Sun, 18 Jul 1999 12:52:10 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <4.2.0.56.19990718124838.02eaa9d0@go2france.com> from "Len Conrad" at Jul 18, 99 12:59:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 960 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Luigi > With dummynet you can achieve almost the same effect by setting a > pipe with a very low bit rate, and yes, this will penalize big packets > > But if we could filter and rate-limit by protocol type, ie, icmp, smtp, > ftp, then we could slice our pipe to fit our needs (icmp very low, smtp > low, http hi, ftp wherever). that's exactly what you can do with ipfw -- write reasonably detailted rulesets to filter on protocols, port, addresses, flags or not, etc. and use different limitations (= dummynet pipes) for the various things. I'll stay out of the bw-mgr/dummynet discussion since dummynet is my (third) baby and have never used bw-mgr. cheers luigi > I'm trying to decide between ET's bw-mgr or dummynet. > > Anybody here leaning on ET's bw-mgr in T1 and better throughputs with lotsa > rules? > > Len > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 7:17:35 1999 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4E13114DDE for ; Sun, 18 Jul 1999 07:17:32 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id QAA48419; Sun, 18 Jul 1999 16:14:31 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: pipes From: Dag-Erling Smorgrav Date: 18 Jul 1999 16:14:30 +0200 Message-ID: Lines: 52 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having trouble setting up a pipe to limit incoming SYN traffic. First, I set up a rule to allow incoming connections to the IRC daemon: root@efnet ~# ipfw add 20 allow tcp from any to any 6666,6667 setup in 00020 allow tcp from any to any 6666,6667 in setup After some light pummelling with a join flooder, I see the following: root@efnet ~# ipfw -a l 20 00020 18 796 allow tcp from any to any 6666,6667 in setup Next, let's add a pipe to limit incoming SYNs to 2 kBps: root@efnet ~# ipfw pipe 1 config bw 2 kBytes/s root@efnet ~# ipfw add 10 pipe 1 tcp from any to any setup in 00010 pipe 1 tcp from any to any in setup root@efnet ~# ipfw zero Accounting cleared. root@efnet ~# ipfw -a l 10 20 00010 0 0 pipe 1 tcp from any to any in setup 00020 0 0 allow tcp from any to any 6666,6667 in setup Then I run my flooder again for a short while and observe: root@efnet ~# ipfw -a l 10 20 00010 46 2188 pipe 1 tcp from any to any in setup 00020 0 0 allow tcp from any to any 6666,6667 in setup root@efnet ~# ipfw pipe list 1 00001: 2.000 bit/s 0 ms 50 sl. -- 49 pkts (2332 B) 29 drops So the pipe claims to have blocked only 29 out of 49 packets, but no packets reached rule 20. At this point I have to stop testing since the server is a live one, not a test box :) (BTW, I also tried the following: root@efnet ~# sysctl -w net.inet.ip.fw.one_pass=1 net.inet.ip.fw.one_pass: 0 -> 1 root@efnet ~# ipfw add 10 pipe 1 tcp from any to 195.198.116.23 6666,6667 setup 00010 pipe 1 tcp from any to 195.198.116.23 6666,6667 setup which should make the 'pipe' rule behave like the previously used 'allow' rule when the packet isn't dropped. It didn't work; nothing got through) What am I doing wrong? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 8:49:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 52ECC14FC3 for ; Sun, 18 Jul 1999 08:49:27 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA18272; Sun, 18 Jul 1999 15:21:04 +0200 From: Luigi Rizzo Message-Id: <199907181321.PAA18272@labinfo.iet.unipi.it> Subject: Re: pipes To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sun, 18 Jul 1999 15:21:04 +0200 (MET DST) Cc: net@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Jul 18, 99 04:14:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1984 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Next, let's add a pipe to limit incoming SYNs to 2 kBps: ... and here you hit a bug in ipfw processing, where k (lowercase) is not recognised and silently ignored, you need K (capital). in your case you have a nice pipe serving 2 bits per second -- basically a morse channel or slower! ... > Then I run my flooder again for a short while and observe: > > root@efnet ~# ipfw -a l 10 20 > 00010 46 2188 pipe 1 tcp from any to any in setup > 00020 0 0 allow tcp from any to any 6666,6667 in setup > root@efnet ~# ipfw pipe list 1 > 00001: 2.000 bit/s 0 ms 50 sl. -- 49 pkts (2332 B) 29 drops > > So the pipe claims to have blocked only 29 out of 49 packets, but no > packets reached rule 20. At this point I have to stop testing since as the listing says there are 49 more packets totalling 2332 bytes queued in the pipe, which has 50 slots. (i suppose between the two commands the flooder has generated some more packets...) As the pipe is believing to be a 2bit/s pipe, it will drain in 9328 seconds. I forgot to comment in my previous email, but generally when you use low bandwidths (even with the 2Kbytes/s you meant) you need short queues (and probably sized in bytes, not packets) to avoid long drain times. > (BTW, I also tried the following: > > root@efnet ~# sysctl -w net.inet.ip.fw.one_pass=1 this is certainly necessary, or ruleset writing becomes a little bit less obvious. It was a really bad choice the one i made on 3.1 to default to 0! cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 18 21:35:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from etri.re.kr (mail.etri.re.kr [129.254.9.28]) by hub.freebsd.org (Postfix) with ESMTP id 0BDDD14F18 for ; Sun, 18 Jul 1999 21:35:06 -0700 (PDT) (envelope-from syl@etri.re.kr) Received: from ns (syl.etri.re.kr [129.254.164.220]) by etri.re.kr (8.8.8+Sun/8.8.8) with SMTP id NAA25483 for ; Mon, 19 Jul 1999 13:34:06 +0900 (KST) Message-ID: <002a01bed1a0$29403980$dca4fe81@ns.etri.re.kr> From: "=?euc-kr?B?wMy9wsCx?=" To: Subject: subscribe freebsd-net Date: Mon, 19 Jul 1999 13:35:42 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01BED1EB.98B26360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0027_01BED1EB.98B26360 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIGZyZWVic2QtbmV0DQo= ------=_NextPart_000_0027_01BED1EB.98B26360 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48ST5zdWJzY3JpYmUgZnJlZWJzZC1uZXQ8L0k+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0027_01BED1EB.98B26360-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 8:21:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from topsecret.net (gill.apk.net [207.54.148.62]) by hub.freebsd.org (Postfix) with SMTP id 7E44414E74 for ; Mon, 19 Jul 1999 08:21:08 -0700 (PDT) (envelope-from gill@topsecret.net) Received: from stumpy by topsecret.net with SMTP (MDaemon.v2.7.SP5.R) for ; Mon, 19 Jul 1999 11:18:04 -0400 From: "James Gill" To: Subject: tomorrow a gateway... Date: Mon, 19 Jul 1999 11:18:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-Return-Path: gill@topsecret.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello :) I am new to FreeBSD and I'm working a FBSD 486 into my home network to act as a router and firewall, NAT, etc. but It's not quite ready yet. In the interim, I have both NICs in the machine and up on the same subnet and I keep getting these messages on the console: Jul 19 10:45:75 hostname /kernel: arp: 10.10.10.33 is on ed1 but got reply from 00:a0:24:23:78:e0 on ed0 It should be noted that the MAC address shown does correspond to the IP address, so that's all working fine. I think I understand the message; one NIC is ARPing for an IP and the other NIC is picking up the response thus confusing the host. It seems that this won't be a problem when I move to separate subnets, but having never set up a gateway before I don't think I'm ready to plop this machine in between my live network and the outside world. I think my question can be distilled down to: What do I have to know extra when putting two NICs of the same subnet in one host? Some more info: the network is connected up stream by an ISDN router that will be set to pass incoming packets to a single host, this will be the router box I'm working on. I am using an internal 10.*.*.* network, but only one class-C subnet of it. 10.10.10.* with a subnet mask of 255.255.255.192 dividing my network into four subnets. Here's what I got out of rfc1878 that I based all this on: Table 1-2 represents traditional subnetting of a Class C network address (which is identical to extended Class B subnets). Subnet Mask # of nets Net. Addr. Host Addr Range Brodcast Addr. Bits of Subnet hosts/subnet 255.255.255.192 4 nets N.N.N.0 N.N.N.1-62 N.N.N.63 2 bit Class C 62 N.N.N.64 N.N.N.65-126 N.N.N.127 10 bit Class B N.N.N.128 N.N.N.129-190 N.N.N.191 N.N.N.192 N.N.N.193-254 N.N.N.255 Currently, everything is in the first subnet, and when the gateway is activated, the internal stuff will be moved into the third subnet (by simply adding 100 to the host address). ...so currently the gateway has .2 and .29 and internal addresses are .30 - .33 but the gateway's internal interface will be .129 and internal will be .130 - .133 . Thanks in advance for any help... ===================================== James Gill * http://www.topsecret.net ===================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 8:27:21 1999 Delivered-To: freebsd-net@freebsd.org Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by hub.freebsd.org (Postfix) with ESMTP id 9A8CF14A12; Mon, 19 Jul 1999 08:27:12 -0700 (PDT) (envelope-from livensw@rc.bel.alcatel.be) Received: from btmq9s.rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id RAA02284; Mon, 19 Jul 1999 17:25:52 +0200 (MET DST) Received: from btmq9z.rc.bel.alcatel.be (btmq9z [138.203.65.192]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id RAA20831; Mon, 19 Jul 1999 17:28:08 +0200 (MET DST) Received: (from livensw@localhost) by btmq9z.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) id RAA02111; Mon, 19 Jul 1999 17:25:46 +0200 (MET DST) Date: Mon, 19 Jul 1999 17:25:46 +0200 From: Wim Livens To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: bug in ip_forward() ? Message-ID: <19990719172546.C1676@rc.bel.alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE. This is our network: +------+ +------+ +------+ +------+ | |4.2 4.1| |2.1 2.2| |5.1 5.2| | |btm22t|---------|btm22q|---------|btm22r|---------|btm22u| | | | | | | | | +------+ +------+ +------+ +------+ And this is what I do: btm22t# ping 192.168.5.2 ok, it works... btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 ok, ping stops. btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 ping doesn't work btm22t# ^C btm22t# ping 192.168.5.2 ping still doesn't work btm22t# ping 192.168.5.1 (or 192.168.2.2) this ping works and suddenly the ping to 192.168.5.2 works too ! Although: btm22t# ping 192.168.5.2 ok, it works... btm22t# ^C btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 btm22t# ping 192.168.5.2 ping works! After disabling the cache in ip_forward() (netinet/ip_input.c) i.e.: sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; < if ((rt = ipforward_rt.ro_rt) == 0 || < ip->ip_dst.s_addr != sin->sin_addr.s_addr ) > if (1) { ... the problem doesn't occur! Anyone has a clue what's wrong here ? Thanks a lot, Wim. ------- What follows is just some background info. Relevant routes: btm22t: 192.168/30 198.149.4.1 UGS1c 0 0 fxp0 192.168.1/30 198.149.4.1 UGS1c 0 0 fxp0 192.168.2/30 198.149.4.1 UGS1c 0 2 fxp0 192.168.4/30 link#2 UC 0 0 192.168.4.1 0:50:8b:7:50:12 UHLW 0 139 btm22q: 192.168/30 link#2 UC 0 0 192.168.0.1 link#2 UHLW 2 11 192.168.1/30 192.168.0.1 UGS1c 0 0 fxp1 192.168.2/30 link#3 UC 0 0 192.168.2.2 0:8:c7:b3:c8:c3 UHLW 1 44 fxp2 927 192.168.3/30 192.168.0.1 UGS1c 0 0 fxp1 192.168.4/30 link#1 UC 0 0 192.168.4.2 0:50:8b:7:54:2e UHLW 1 4534 fxp0 777 192.168.5/30 192.168.2.2 UGSc 0 2 fxp2 btm22r: 192.168/30 192.168.1.1 UGS1c 0 0 fxp2 192.168.1/30 link#3 UC 0 0 192.168.1.1 link#3 UHLW 1 103 192.168.2/30 link#2 UC 0 0 192.168.2.1 0:50:8b:7:49:17 UHLW 1 145 fxp1 895 192.168.4/30 192.168.2.1 UGS1c 1 21 fxp1 192.168.5/30 link#1 UC 0 0 192.168.5.2 0:50:8b:7:54:33 UHLW 0 275355 fxp0 505 btm22u: 192.168.2/30 192.168.5.1 UGS1c 0 16 fxp1 192.168.4/30 192.168.5.1 UGS1c 0 6 fxp1 192.168.5/30 link#2 UC 0 0 192.168.5.1 0:50:8b:7:49:7d UHLW 2 0 fxp1 489 dmesg on btm22q: FreeBSD 2.2.8-RELEASE #0: Fri Jul 16 15:34:52 CEST 1999 root@btm22u.rc.bel.alcatel.be:/usr/src/sys-cvs/sys/compile/CUSTOM CPU: Pentium II (quarter-micron) (348.49-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183f9ff,,MMX,< b24>> real memory = 67108864 (65536K bytes) avail memory = 63123456 (61644K bytes) altq: major number is 96 Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 2 on pci0:1:0 fxp0 rev 5 int a irq 11 on pci0:13:0 fxp0: Ethernet address 00:50:8b:07:50:12 fxp1 rev 5 int a irq 11 on pci0:14:0 fxp1: Ethernet address 00:50:8b:07:4b:f6 fxp2 rev 5 int a irq 11 on pci0:15:0 fxp2: Ethernet address 00:50:8b:07:49:17 chip2 rev 3 on pci0:16:0 chip3 rev 2 on pci0:20:0 chip4 rev 1 on pci0:20:1 chip5 rev 1 int d irq 11 on pci0:20:2 chip6 rev 2 on pci0:20:3 Probing for devices on PCI bus 1: vga0 rev 1 int a irq 11 on pci1:0:0 Probing for devices on PCI bus 2: de0 rev 34 int a irq 11 on pci2:4:0 de0: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2 de0: address 00:c0:95:e0:e3:70 de1 rev 34 int a irq 11 on pci2:5:0 de1: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2 de1: address 00:c0:95:e0:e3:71 de2 rev 34 int a irq 11 on pci2:6:0 de2: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2 de2: address 00:c0:95:e0:e3:72 de3 rev 34 int a irq 11 on pci2:7:0 de3: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2 de3: address 00:c0:95:e0:e3:73 Probing for PnP devices: No Plug-n-Play devices were found Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x300 psm0 not found at 0x60 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not found at 0xffffffff wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 4112MB (8421840 sectors), 8912 cyls, 15 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ep0 not found at 0x330 ep1 not found at 0x310 ep2 not found at 0x320 npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, default to accept, unlimited logging de0: enabling 100baseTX port de3: autosense failed: cable problem? de1: autosense failed: cable problem? de2: autosense failed: cable problem? -- Wim Livens. Alcatel - Corporate Research Center wim.livens@alcatel.be Fr. Wellesplein 1 livensw@rc.bel.alcatel.be B-2018 Antwerpen Tel: +32 3 240 7570 Belgium. Fax: +32 3 240 9932 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 10:33: 1 1999 Delivered-To: freebsd-net@freebsd.org Received: from hercules.crossthread.com (hercules.crossthread.com [139.142.137.200]) by hub.freebsd.org (Postfix) with ESMTP id 2773215149; Mon, 19 Jul 1999 10:32:57 -0700 (PDT) (envelope-from timp@orion.ab.ca) Received: from cgytpushor (shl-host1.shl.ca [209.135.106.225]) by hercules.crossthread.com (8.9.3/8.9.3) with SMTP id LAA48345; Mon, 19 Jul 1999 11:32:42 -0600 (MDT) Message-ID: <000d01bed20d$15024270$9828f99f@shl.com> From: "Tim Pushor" To: , Subject: 'Out of buffer space' problem Date: Mon, 19 Jul 1999 11:34:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I work for a rather large organization and have convinced management to replace our aging AIX SMTP relays/DNS servers with Compaq Servers running FreeBSD. Saturday I had officially turned off our old AIX boxes and were running on pure FreeBSD boxes. On the first full day of production, half way through (today) one of the boxes that the companies primary DNS was running on stopped responding. The error I was getting was 'out of buffer space'. I am now in Panic mode, as I am the one responsible for reccomending this solution. Can anyone out there help me track the problem down? I know there can be several factors involved, but I *really* have to get this one licked rather quickly. Thanks in advance, Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 10:43:15 1999 Delivered-To: freebsd-net@freebsd.org Received: from fw2.roguewave.com (fw2.roguewave.com [208.151.233.2]) by hub.freebsd.org (Postfix) with ESMTP id 5B0FC14EFA; Mon, 19 Jul 1999 10:43:06 -0700 (PDT) (envelope-from carey@roguewave.com) Received: by fw2.roguewave.com; id SAA21134; Mon, 19 Jul 1999 18:46:41 -0700 (PDT) Received: from cvo1.cvo.roguewave.com(10.68.4.36) via SMTP by hub.FreeBSD.ORG, id smtpd021116; Mon Jul 19 18:46:37 1999 Received: by CVO1 with Internet Mail Service (5.5.1960.3) id ; Mon, 19 Jul 1999 10:44:40 -0700 Message-ID: From: Woody Carey To: "'Tim Pushor'" , questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: RE: 'Out of buffer space' problem Date: Mon, 19 Jul 1999 10:44:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can you tell what program this error is coming from? > -----Original Message----- > From: Tim Pushor [mailto:timp@orion.ab.ca] > Sent: Monday, July 19, 1999 10:35 AM > To: questions@FreeBSD.ORG; net@FreeBSD.ORG > Subject: 'Out of buffer space' problem > > > Hello, > > I work for a rather large organization and have convinced > management to > replace our aging AIX SMTP relays/DNS servers with Compaq > Servers running > FreeBSD. Saturday I had officially turned off our old AIX > boxes and were > running on pure FreeBSD boxes. > > On the first full day of production, half way through (today) > one of the > boxes that the companies primary DNS was running on stopped > responding. The > error I was getting was 'out of buffer space'. > > I am now in Panic mode, as I am the one responsible for > reccomending this > solution. > > Can anyone out there help me track the problem down? I know > there can be > several factors involved, but I *really* have to get this one > licked rather > quickly. > > Thanks in advance, > Tim > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 12: 6:42 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id CB85D14DD2; Mon, 19 Jul 1999 12:06:38 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id MAA09022; Mon, 19 Jul 1999 12:05:30 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA24944; Mon, 19 Jul 1999 12:05:18 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA20473; Mon, 19 Jul 99 12:05:24 PDT Message-Id: <379376F4.129C4642@softweyr.com> Date: Mon, 19 Jul 1999 13:05:24 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Tim Pushor Cc: questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: 'Out of buffer space' problem References: <000d01bed20d$15024270$9828f99f@shl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tim Pushor wrote: > > Hello, > > I work for a rather large organization and have convinced management to > replace our aging AIX SMTP relays/DNS servers with Compaq Servers running > FreeBSD. Saturday I had officially turned off our old AIX boxes and were > running on pure FreeBSD boxes. > > On the first full day of production, half way through (today) one of the > boxes that the companies primary DNS was running on stopped responding. The > error I was getting was 'out of buffer space'. > > I am now in Panic mode, as I am the one responsible for reccomending this > solution. > > Can anyone out there help me track the problem down? I know there can be > several factors involved, but I *really* have to get this one licked rather > quickly. Sure, but you'll need to provide some useful information about your systems. What version of FreeBSD and BIND are you running? What is the configuration of your machine -- CPU(s), memory, and network cards certainly. Have you compiled a custom kernel for the machine; if so include the kernel config file you're using. If not, the problem is simple to diagnose: you need more network buffer space to handle the load. The simplest way to do this is to increase the "maxusers" figure in the configuration until the problem stops. If you're running the 3.2-RELEASE generic kernel, raise maxusers to 64 and try again. Please, post more information so we can help you. We don't want you to (and us by reference) to get embarrased on this. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 12:13:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0FCCB14DBC; Mon, 19 Jul 1999 12:13:05 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id MAA09158; Mon, 19 Jul 1999 12:11:09 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA25244; Mon, 19 Jul 1999 12:10:57 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA20769; Mon, 19 Jul 99 12:11:02 PDT Message-Id: <37937846.55C1867E@softweyr.com> Date: Mon, 19 Jul 1999 13:11:02 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Wim Livens Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: bug in ip_forward() ? References: <19990719172546.C1676@rc.bel.alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wim Livens wrote: > > I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE. > > This is our network: > > +------+ +------+ +------+ +------+ > | |4.2 4.1| |2.1 2.2| |5.1 5.2| | > |btm22t|---------|btm22q|---------|btm22r|---------|btm22u| > | | | | | | | | > +------+ +------+ +------+ +------+ > > And this is what I do: > > btm22t# ping 192.168.5.2 > ok, it works... > btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > ok, ping stops. > btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > ping doesn't work And it shouldn't, you haven't given it an appropriate route. From route(8): The other commands have the following syntax: route [-n] command [-net | -host] destination gateway where destination is the destination host or network, gateway is the next-hop intermediary via which packets should be routed. There's the important part right there: gateway is the *next-hop* intermediary via which packets should be routed. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 12:32:42 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 264D715247 for ; Mon, 19 Jul 1999 12:32:37 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id VAA14687; Mon, 19 Jul 1999 21:31:50 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id VAA96947; Mon, 19 Jul 1999 21:31:49 +0200 (MDT) Date: Mon, 19 Jul 1999 21:31:49 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: freebsd-net@freebsd.org Cc: Konference o transparentni proxy Subject: Tcp shadowing for use in HTTP proxy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, The goal of alobal project is to design and implement transparent proxy cache for the HTTP protocol, used on TCP/IP networks for transmitting WWW pages. One of alobal's important features is full transparency for communicating partners. Usual transparent cache takes over client's connections and gets the data for them. However, the server sees as his communicating partner the cache machine. To solve this missing transparency, cache should connect to http server using client's IP address. However, such address is in use by original client and we still need to communicate with it. Cache node will need a "shadow" interface, which is used to make such connections. Shadow interface accepts packets destined to specified hosts (and redirected to localhost) and delivers them to localhost. On the other hand, it is not used by routing to deliver packets originating from localhost. Setup and use of shadow interface is automatic - process creating TCP connection calls bind() to assign local IP address to socket. When such IP is not present on interfaces, it is added to the shadow interface list. When connection is terminated, address is removed from list. The list is for efficiency implemented as hash table with usage counts (we need to open multiple connections under one client's identity). Please take look at http://www.ms.mff.cuni.cz/~mkop5230/tcp-shadow/ and tell me what you think about it. There are patches against 3.2-RELEASE. Thanks Milan Kopacka -- ... a koho system nachyta na procesoru, tomu snizi prioritu. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 13:41:23 1999 Delivered-To: freebsd-net@freebsd.org Received: from hercules.crossthread.com (hercules.crossthread.com [139.142.137.200]) by hub.freebsd.org (Postfix) with ESMTP id 14B6E14D84; Mon, 19 Jul 1999 13:41:11 -0700 (PDT) (envelope-from timp@orion.ab.ca) Received: from cgytpushor (shl-host1.shl.ca [209.135.106.225]) by hercules.crossthread.com (8.9.3/8.9.3) with SMTP id OAA48755; Mon, 19 Jul 1999 14:41:07 -0600 (MDT) Message-ID: <006801bed227$664d92f0$9828f99f@shl.com> From: "Tim Pushor" To: , Subject: Out of buffer space - REVISITED Date: Mon, 19 Jul 1999 14:43:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Let me first apologize for this long message. I realize that I was in panic mode earlier and did not furnish near enough information to draw any sort of conclusion. Here are the facts. I replaced two aging AIX boxes with FreeBSD (after MUCH convincing of our senior management). They trust my judgement, so let me proceed. Saturday I brought the new servers online and shut off the AIX boxes. Today, one of the servers fell over - it couldn't communicate with anything over the network. Ping'ing anything resulting in an 'out of buffer space' error message. Rebooting the server brought it back to life - for about 10 minutes. I have since discovered that I can simply do a ifconfig tl0 down, and an ifconfig tl0 up, and it will begin working again. Another interesting point is that the boxes are the exact same configuration, and the exact same kernel. They are primarily SMTP relay boxes for our company, and have equal MX preferences. They are running sendmail 8.9.3. One of the machines is also running named (stock from the FreeBSD 2.2.8 distribution - 4.9.4 ?? ). This is the machine that falls over. I have found that if I don't run sendmail on the machine that is running named, it stabilizes (so far anyway). A further complication is that I am 3000 miles away from this server :( But I do have access to the console remotely (Compaq Remote Insight). I *really* hope someone can help, as I have put myself out on a limb to get FreeBSD in active use here. Hardware: Compaq Proliant 1600 - PII 450 w/512 MB RAM Integrated ThunderLAN 10/100 NIC running at 10M Integrated NCR SCSI adapter 4G Wide SCSI drive Software: FreeBSD 2.2.8-RELEASE Integrated BIND (4.9.4??) sendmail 8.9.3 Integrated xntpd running Integrated inetd running Integrated cron running Integrated syslogd running System loads: Internal DNS for ~10,000 users on one box Inbound SMTP relays - when both are running they handle approximately 40 sendmail sessions consistently, concurrently - peaking at a maximum of 75. Syslog errors: Jul 19 12:48:26 dalubsmtp01 named[100]: sysquery: sendto([159.249.55.1].53): No buffer space available Jul 19 12:48:26 dalubsmtp01 named[100]: sysquery: sendto([159.249.127.1].53): No buffer space available Jul 19 12:48:26 dalubsmtp01 named[100]: sysquery: sendto([159.249.96.71].53): No buffer space available Kernel: fairly standard configuration - but configured with maxusers 256, which I believe automatically sets NMBCLUSTERS to 4608. Could this really be the problem? Kernel config file: # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.77.2.28 1998/09/26 17:36:14 wpaul Exp $ machine "i386" cpu "I586_CPU" cpu "I686_CPU" ident SHLRELAY maxusers 256 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options FAILSAFE #Be conservative options IPFIREWALL options "MAXMEM=(512*1024)" options INCLUDE_CONFIG_FILE config kernel root on wd0 controller isa0 #controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ncr0 controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Mandatory, don't remove device npx0 at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device tl0 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device vn 4 pseudo-device tun 4 pseudo-device pty 32 pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 4 # This provides support for System V shared memory. # options SYSVSHM options SYSVMSG options SYSVSEM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 13:48: 8 1999 Delivered-To: freebsd-net@freebsd.org Received: from topsecret.net (gill.apk.net [207.54.148.62]) by hub.freebsd.org (Postfix) with SMTP id 4FD8F1528C for ; Mon, 19 Jul 1999 13:48:04 -0700 (PDT) (envelope-from gill@topsecret.net) Received: from stumpy by topsecret.net with SMTP (MDaemon.v2.7.SP5.R) for ; Mon, 19 Jul 1999 16:42:55 -0400 From: "James Gill" To: Subject: RE: tomorrow a gateway... Date: Mon, 19 Jul 1999 16:42:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-Return-Path: gill@topsecret.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have added a diagram with a little more info at http://www.topsecret.net/net Communicating the problem is half of my communications problem! -> -> Hello :) -> -> I am new to FreeBSD and I'm working a FBSD 486 into my home -> network to act -> as a router and firewall, NAT, etc. but It's not quite ready -> yet. In the -> interim, I have both NICs in the machine and up on the same subnet and I -> keep getting these messages on the console: -> -> Jul 19 10:45:75 hostname /kernel: arp: 10.10.10.33 is on -> ed1 but got reply -> from -> 00:a0:24:23:78:e0 on ed0 -> -> It should be noted that the MAC address shown does correspond to the IP -> address, so that's all working fine. I think I understand the -> message; one -> NIC is ARPing for an IP and the other NIC is picking up the -> response thus -> confusing the host. It seems that this won't be a problem when -> I move to -> separate subnets, but having never set up a gateway before I -> don't think I'm -> ready to plop this machine in between my live network and the -> outside world. -> -> I think my question can be distilled down to: What do I have -> to know extra -> when putting two NICs of the same subnet in one host? -> -> Some more info: -> -> the network is connected up stream by an ISDN router that will be set to -> pass incoming packets to a single host, this will be the router box I'm -> working on. -> -> I am using an internal 10.*.*.* network, but only one class-C -> subnet of it. -> 10.10.10.* with a subnet mask of 255.255.255.192 dividing my -> network into -> four subnets. Here's what I got out of rfc1878 that I based -> all this on: -> -> Table 1-2 represents traditional subnetting of a Class C network -> address (which is identical to extended Class B subnets). -> -> Subnet Mask # of nets Net. Addr. Host Addr Range -> Brodcast Addr. -> Bits of Subnet hosts/subnet -> -> 255.255.255.192 4 nets N.N.N.0 N.N.N.1-62 N.N.N.63 -> 2 bit Class C 62 N.N.N.64 N.N.N.65-126 N.N.N.127 -> 10 bit Class B N.N.N.128 N.N.N.129-190 N.N.N.191 -> N.N.N.192 N.N.N.193-254 N.N.N.255 -> -> Currently, everything is in the first subnet, and when the gateway is -> activated, the internal stuff will be moved into the third -> subnet (by simply -> adding 100 to the host address). ...so currently the gateway -> has .2 and .29 -> and internal addresses are .30 - .33 but the gateway's internal -> interface -> will be .129 and internal will be .130 - .133 . -> -> Thanks in advance for any help... -> -> ===================================== -> James Gill * http://www.topsecret.net -> ===================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 13:54:31 1999 Delivered-To: freebsd-net@freebsd.org Received: from trooper.velocet.ca (trooper.velocet.net [209.167.225.226]) by hub.freebsd.org (Postfix) with ESMTP id 9CDED14CC0; Mon, 19 Jul 1999 13:54:23 -0700 (PDT) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.9.3/8.9.3) id QAA32798; Mon, 19 Jul 1999 16:54:20 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14227.36987.537390.519829@trooper.velocet.ca> Date: Mon, 19 Jul 1999 16:54:19 -0400 (EDT) To: "Tim Pushor" Cc: , Subject: Out of buffer space - REVISITED In-Reply-To: <006801bed227$664d92f0$9828f99f@shl.com> References: <006801bed227$664d92f0$9828f99f@shl.com> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Tim" == Tim Pushor writes: Tim> I have since discovered that I can simply do a ifconfig tl0 down, Tim> and an ifconfig tl0 up, and it will begin working again. Another Tim> I *really* hope someone can help, as I have put myself out on a Tim> limb to get FreeBSD in active use here. My first reaction to this, given the up/down business is that you should just get someone onsite to pop in two PCI NE-2000 clones. A large number of new network drivers appeared in 3.0/3.1 and I've found the tx0, for one, to be very buggy. Buggy enough that I can't believe that anyone else is using it. (unless you undefine EARLY_RX, moderate amounts of traffic will turn this innocent looking ethernet card into a delay adapter... holding packets for arbitrary amounts of time. I have also found that the driver truncates skip packets.) I have found the following drivers to be stable: ed0 (ne2000) de0 (DEC tulip) I have found the following drivers to be aggrivatingly buggy: ep0 (3com) - random reboots with traffic when > 1 interface tx0 (tulip clone from SMC) - see above I have not used other drivers (I have used the tl0 once, but can't really comment). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 13:59:28 1999 Delivered-To: freebsd-net@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id A662B152B4 for ; Mon, 19 Jul 1999 13:59:26 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id NAA46480; Mon, 19 Jul 1999 13:58:45 -0700 (PDT) Date: Mon, 19 Jul 1999 13:58:45 -0700 (PDT) From: David Wolfskill Message-Id: <199907192058.NAA46480@pau-amma.whistle.com> To: freebsd-net@FreeBSD.ORG, gill@topsecret.net Subject: Re: tomorrow a gateway... In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From: "James Gill" >Date: Mon, 19 Jul 1999 11:18:39 -0400 >I think my question can be distilled down to: What do I have to know extra >when putting two NICs of the same subnet in one host? Familiarity with Spanning Tree Protocol would seem to be a distinct "plus" for such an effort. >I am using an internal 10.*.*.* network, but only one class-C subnet of it. >10.10.10.* with a subnet mask of 255.255.255.192 dividing my network into >four subnets. Here's what I got out of rfc1878 that I based all this on: >... >Currently, everything is in the first subnet, and when the gateway is >activated, the internal stuff will be moved into the third subnet (by simply >adding 100 to the host address). ...so currently the gateway has .2 and .29 >and internal addresses are .30 - .33 but the gateway's internal interface >will be .129 and internal will be .130 - .133 . >Thanks in advance for any help... It's not as if net 10 (or any other RFC 1918) addresses are in particularly short supply. I would recommend that each NIC be set up to be on a completely separate network. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 14:37: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E489215298 for ; Mon, 19 Jul 1999 14:37:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id OAA47439; Mon, 19 Jul 1999 14:35:57 -0700 (PDT) Message-ID: <37939A3C.FF6D5DF@whistle.com> Date: Mon, 19 Jul 1999 14:35:56 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: Milan Kopacka Cc: freebsd-net@FreeBSD.ORG, Konference o transparentni proxy Subject: Re: Tcp shadowing for use in HTTP proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Look at the 'fwd' option to the ipfw software. julian Milan Kopacka wrote: > > Hi, > > The goal of alobal project is to design and implement transparent proxy > cache for the HTTP protocol, used on TCP/IP networks for transmitting WWW > pages. One of alobal's important features is full transparency for > communicating partners. Usual transparent cache takes over client's > connections and gets the data for them. However, the server sees as his > communicating partner the cache machine. > > To solve this missing transparency, cache should connect to http server > using client's IP address. However, such address is in use by original > client and we still need to communicate with it. Cache node will need a > "shadow" interface, which is used to make such connections. Shadow > interface accepts packets destined to specified hosts (and redirected to > localhost) and delivers them to localhost. On the other hand, it is not > used by routing to deliver packets originating from localhost. > > Setup and use of shadow interface is automatic - process creating TCP > connection calls bind() to assign local IP address to socket. When such IP > is not present on interfaces, it is added to the shadow interface list. > When connection is terminated, address is removed from list. The list is > for efficiency implemented as hash table with usage counts (we need to > open multiple connections under one client's identity). > > Please take look at http://www.ms.mff.cuni.cz/~mkop5230/tcp-shadow/ > and tell me what you think about it. There are patches against > 3.2-RELEASE. > > Thanks > > Milan Kopacka > > -- > > ... a koho system nachyta na procesoru, tomu snizi prioritu. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 15:13: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 6331814E93; Mon, 19 Jul 1999 15:12:59 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA12077; Mon, 19 Jul 1999 15:11:20 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA02162; Mon, 19 Jul 1999 15:11:06 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA00657; Mon, 19 Jul 99 15:11:16 PDT Message-Id: <3793A284.203057B@softweyr.com> Date: Mon, 19 Jul 1999 16:11:16 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Tim Pushor Cc: questions@freebsd.org, net@freebsd.org Subject: Re: 'Out of buffer space' problem References: <000d01bed20d$15024270$9828f99f@shl.com> <379376F4.129C4642@softweyr.com> <004401bed21c$13430870$9828f99f@shl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tim Pushor wrote: > Wes Peters ranted: > > Tim Pushor wrote: > > > > > > I work for a rather large organization and have convinced management to > > > replace our aging AIX SMTP relays/DNS servers with Compaq Servers running > > > FreeBSD. Saturday I had officially turned off our old AIX boxes and were > > > running on pure FreeBSD boxes. > > > > > > On the first full day of production, half way through (today) one of the > > > boxes that the companies primary DNS was running on stopped responding. The > > > error I was getting was 'out of buffer space'. > > > > > > I am now in Panic mode, as I am the one responsible for reccomending this > > > solution. > > > > > > Can anyone out there help me track the problem down? I know there can be > > > several factors involved, but I *really* have to get this one licked rather > > > quickly. > > > > Sure, but you'll need to provide some useful information about your systems. > > What version of FreeBSD and BIND are you running? What is the configuration > > of your machine -- CPU(s), memory, and network cards certainly. Have you > > compiled a custom kernel for the machine; if so include the kernel config > > file you're using. If not, the problem is simple to diagnose: you need > > more network buffer space to handle the load. The simplest way to do this > > is to increase the "maxusers" figure in the configuration until the problem > > stops. If you're running the 3.2-RELEASE generic kernel, raise maxusers to > > 64 and try again. > > > > Please, post more information so we can help you. We don't want you to (and > > us by reference) to get embarrased on this. ;^) > > I'm sorry for not providing enough information, I am in panic mode here. > Thanks for listening to me ;-) I *really* hope someone can help.. OK, now we're getting somewhere. A quick point, though: until you've gotten a solution, keep mailing to the lists as well. I'm not necessarily the configuration expert, so we'll want to get lots of eyeballs on this. I've forwarded your reply and my observations to the original lists, which were probably a good starting place. > Hardware: > > Compaq Proliant 1600 PII-450 W/512M RAM, Integrated NCR SCSI, one 4G Wide > SCSI disk, Integrated ThunderLAN 10/100 NIC That should be sufficient for a DNS server. > Software: > > FreeBSD 2.2.8-RELEASE > Stock named (4.9.4?) > Maxusers 256 (so NMBclusters should be 4608) A reasonable starting point. > Config file: > ** BTW this is not really GENERIC So change the comments, like: > # # SHLRELAY, created dd/mm/yyyy from: > # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks > # > # For more information read the handbook part System Administration -> > # Configuring the FreeBSD Kernel -> The Configuration File. > # The handbook is available in /usr/share/doc/handbook or online as > # latest version from the FreeBSD World Wide Web server > # > # > # An exhaustive list of options and more detailed explanations of the > # device lines is present in the ./LINT configuration file. If you are > # in doubt as to the purpose or necessity of a line, check first in LINT. > # > # $Id: GENERIC,v 1.77.2.28 1998/09/26 17:36:14 wpaul Exp $ > machine "i386" > cpu "I586_CPU" > cpu "I686_CPU" > ident SHLRELAY > maxusers 256 > options INET #InterNETworking > options FFS #Berkeley Fast Filesystem > options MSDOSFS #MSDOS Filesystem > options "CD9660" #ISO 9660 Filesystem > options PROCFS #Process filesystem > options "COMPAT_43" #Compatible with BSD 4.3 [KEEP > THIS!] > options SCSI_DELAY=15 #Be pessimistic about Joe SCSI > device > options FAILSAFE #Be conservative > options IPFIREWALL > options "MAXMEM=(512*1024)" > options INCLUDE_CONFIG_FILE > config kernel root on wd0 > controller isa0 > #controller eisa0 > controller pci0 > controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr > disk fd0 at fdc0 drive 0 > disk fd1 at fdc0 drive 1 > options "CMD640" # work around CMD640 chip deficiency > controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr > controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr > options ATAPI #Enable ATAPI support for IDE bus > options ATAPI_STATIC #Don't do it as an LKM > device wcd0 #IDE CD-ROM > # A single entry for any of these controllers (ncr, ahb, ahc, amd) is > # sufficient for any number of installed devices. > controller ncr0 > controller scbus0 > device sd0 > device st0 > device cd0 #Only need one of these, the code dynamically grows > # syscons is the default console driver, resembling an SCO console > device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr > # Mandatory, don't remove > device npx0 at isa? port "IO_NPX" flags 0x1 irq 13 vector > npxintr > device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr > device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr > device lpt0 at isa? port? tty irq 7 vector lptintr > device tl0 > pseudo-device loop > pseudo-device ether > pseudo-device log > pseudo-device vn 4 > pseudo-device tun 4 > pseudo-device pty 32 > pseudo-device gzip # Exec gzipped a.out's > pseudo-device bpfilter 4 > # This provides support for System V shared memory. > # > options SYSVSHM > options SYSVMSG > options SYSVSEM I don't see anything obviously wrong here, either. Send the output of both netstat -m and netstat -s, so we can see what's going on in the network stack. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 17:48:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail-relay2.yahoo.com (mail-relay2.yahoo.com [206.251.17.77]) by hub.freebsd.org (Postfix) with ESMTP id AFCEF15012 for ; Mon, 19 Jul 1999 17:48:13 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from borogove.yahoo.com (borogove.yahoo.com [205.216.162.65]) by mail-relay2.yahoo.com (8.9.3/8.9.3) with ESMTP id RAA05306 for ; Mon, 19 Jul 1999 17:48:13 -0700 (PDT) Received: from yahoo-inc.com (milk.yahoo.com [206.132.89.117]) by borogove.yahoo.com (8.9.3/8.9.3) with ESMTP id RAA16646 for ; Mon, 19 Jul 1999 17:48:12 -0700 (PDT) Message-ID: <3793C74B.4DE61DCD@yahoo-inc.com> Date: Mon, 19 Jul 1999 17:48:11 -0700 From: Jayanth Vijayaraghavan X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: delay ack timer queue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Should there be a separate delay ack queue atleast because a lot of tcp control blocks will be scanned that do not have delayed ack turned on ? It is not scalable too, if there a large number of connections. regards jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 22:52: 9 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 17877151A0 for ; Mon, 19 Jul 1999 22:52:05 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id HAA27961; Tue, 20 Jul 1999 07:51:28 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id HAA08215; Tue, 20 Jul 1999 07:51:27 +0200 (MDT) Date: Tue, 20 Jul 1999 07:51:26 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG, Konference o transparentni proxy Subject: Re: Tcp shadowing for use in HTTP proxy In-Reply-To: <37939A3C.FF6D5DF@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 19 Jul 1999, Julian Elischer wrote: > Look at the 'fwd' option to the ipfw software. 'fwd' allows me being transparent for HTTP client. I need more - do not allow HTTP server to see the cache machine, cache machine uses client machines' IP's to connect to HTTP server (and to reply to the client). This is impossible under normal conditions. Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 19 23:20:45 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 6E4B814BD7 for ; Mon, 19 Jul 1999 23:20:35 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id IAA19335; Tue, 20 Jul 1999 08:19:45 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id IAA10830; Tue, 20 Jul 1999 08:19:44 +0200 (MDT) Date: Tue, 20 Jul 1999 08:19:44 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Alex Rousskov Cc: freebsd-net@FreeBSD.ORG, Konference o transparentni proxy Subject: Re: Tcp shadowing for use in HTTP proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Alex Rousskov wrote: > How do you solve a problem of server response packets being routed to the > real client instead of the proxy? Are you assuming that there is only one > way to get from the server to the real client, and that path always goes > through your proxy? Just curious... Yes, proxy must get all of the response packets. It is a limitation, but unavoidable, I'm afraid. Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 1:18:37 1999 Delivered-To: freebsd-net@freebsd.org Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by hub.freebsd.org (Postfix) with ESMTP id 028B3151A4; Tue, 20 Jul 1999 01:18:09 -0700 (PDT) (envelope-from livensw@rc.bel.alcatel.be) Received: from btmq9s.rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id KAA06904; Tue, 20 Jul 1999 10:11:13 +0200 (MET DST) Received: from btmq9z.rc.bel.alcatel.be (btmq9z [138.203.65.192]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id KAA27078; Tue, 20 Jul 1999 10:13:28 +0200 (MET DST) Received: (from livensw@localhost) by btmq9z.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) id KAA13057; Tue, 20 Jul 1999 10:10:57 +0200 (MET DST) Date: Tue, 20 Jul 1999 10:10:57 +0200 From: Wim Livens To: Wes Peters , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: bug in ip_forward() ? Message-ID: <19990720101057.D1676@rc.bel.alcatel.be> References: <19990719172546.C1676@rc.bel.alcatel.be> <37937846.55C1867E@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37937846.55C1867E@softweyr.com>; from Wes Peters on Mon, Jul 19, 1999 at 01:11:02PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 19, 1999 at 01:11:02PM -0600, Wes Peters wrote: > > +------+ +------+ +------+ +------+ > > | |4.2 4.1| |2.1 2.2| |5.1 5.2| | > > |btm22t|---------|btm22q|---------|btm22r|---------|btm22u| > > | | | | | | | | > > +------+ +------+ +------+ +------+ > > > > And this is what I do: > > > > btm22t# ping 192.168.5.2 > > ok, it works... > > btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > > ok, ping stops. > > btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > > ping doesn't work > > And it shouldn't, you haven't given it an appropriate route. From route(8): > > The other commands have the following syntax: > > route [-n] command [-net | -host] destination gateway > > where destination is the destination host or network, gateway is the > next-hop intermediary via which packets should be routed. > > There's the important part right there: gateway is the *next-hop* intermediary > via which packets should be routed. Note that the ping is done from btm22t while the route is deleted/added on btm22q. (I've ommited the 192.168 prefix in the addresses in the figure). Now, I think I did specify a correct next-hop, namely 192.168.2.2, which is a local destination for btm22q. Thanks anyway, I should have been more clear. Wim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 1:57:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from arc.netlab.sk (arc.netlab.sk [195.168.1.2]) by hub.freebsd.org (Postfix) with ESMTP id A5B1F152A5 for ; Tue, 20 Jul 1999 01:56:54 -0700 (PDT) (envelope-from palo.adamec@tecton.sk) Received: from wsadmin ([195.168.13.18]) by arc.netlab.sk (8.9.3/8.9.3) with SMTP id KAA09069 for ; Tue, 20 Jul 1999 10:55:26 +0200 (CEST) Received: by localhost with Microsoft MAPI; Tue, 20 Jul 1999 10:56:22 +0200 Message-ID: <01BED29E.810C5F50.palo.adamec@tecton.sk> From: Pavol Adamec To: "freebsd-net@FreeBSD.ORG" Subject: RE: Tcp shadowing for use in HTTP proxy Date: Tue, 20 Jul 1999 10:56:21 +0200 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm sorry but I think that the use of such a shadow interface would be very very limited. The main restriction is that a client PC sits on an isolated LAN connected to the world through exactly one router. The router is also doing the job of a proxy. I think that in such a case the router in many cases also applies NAT to the trafic, so the client's IP is changed anyway. Another point is that any misguided application or misguided configuration of an application could bind to any IP without an error message. As for me - I've already done such a mistake, especially when configuring a just installed application (wrong bind IP for squid, for example). It would be interesting to know the real purpose that led to the idea. Why is it so important for the server to see client's real IP or why is it so important for the proxy to have the server see client's real IP. Pavol Adamec > On Tue, 20 Jul 1999, Alex Rousskov wrote: > >> How do you solve a problem of server response packets being routed to the >> real client instead of the proxy? Are you assuming that there is only one >> way to get from the server to the real client, and that path always goes >> through your proxy? Just curious... > >Yes, proxy must get all of the response packets. It is a limitation, but >unavoidable, I'm afraid. > > Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 7:49: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 82BF1152F6 for ; Tue, 20 Jul 1999 07:49:02 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id QAA15120; Tue, 20 Jul 1999 16:46:44 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id QAA17386; Tue, 20 Jul 1999 16:46:44 +0200 (MDT) Date: Tue, 20 Jul 1999 16:46:44 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Pavol Adamec Cc: "freebsd-net@FreeBSD.ORG" , Konference o transparentni proxy Subject: RE: Tcp shadowing for use in HTTP proxy In-Reply-To: <01BED29E.810C5F50.palo.adamec@tecton.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Pavol Adamec wrote: > It would be interesting to know the real purpose that led to the idea. > Why is it so important for the server to see client's real IP or why > is it so important for the proxy to have the server see client's real > IP. Such feature is mainly academic - to try, if fully transparent proxying of HTTP can be achieved, what must be done and where are the limitations. Transparent means invisible - but how close can we get..? Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 8:10:22 1999 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id 5F8D015311 for ; Tue, 20 Jul 1999 08:10:19 -0700 (PDT) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id JAA16091; Tue, 20 Jul 1999 09:09:01 -0600 (MDT) (envelope-from rousskov@ircache.net) Date: Tue, 20 Jul 1999 09:09:01 -0600 (MDT) From: Alex Rousskov To: Milan Kopacka Cc: "freebsd-net@FreeBSD.ORG" , Konference o transparentni proxy Subject: RE: Tcp shadowing for use in HTTP proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Milan Kopacka wrote: > Such feature is mainly academic - to try, if fully transparent proxying of > HTTP can be achieved, what must be done and where are the limitations. > Transparent means invisible - but how close can we get..? I may be wrong, but I think there are commercial solutions that already offer true transparency. I suggest that you search around if you do not want to reinvent the wheel (the latter is OK for academic purposes). Unfortunately, I do not have any ready-to-use pointers to true transparency, but there are many Web sites devoted to caching and caching research... Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 8:32:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 41FCE1531A for ; Tue, 20 Jul 1999 08:32:53 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id RAA21832; Tue, 20 Jul 1999 17:32:04 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id RAA19722; Tue, 20 Jul 1999 17:32:03 +0200 (MDT) Date: Tue, 20 Jul 1999 17:32:03 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Alex Rousskov Cc: "freebsd-net@FreeBSD.ORG" , Konference o transparentni proxy Subject: RE: Tcp shadowing for use in HTTP proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Alex Rousskov wrote: > I may be wrong, but I think there are commercial solutions that > already offer true transparency. I suggest that you search around if > you do not want to reinvent the wheel (the latter is OK for academic > purposes). I do not know about any. :| (Besides our wheel :). > Unfortunately, I do not have any ready-to-use pointers to true > transparency, but there are many Web sites devoted to caching and > caching research... Maybe anyone else does know about something? Thanks. Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 8:46:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from messenger.cacheflow.com (messenger.cacheflow.com [208.2.250.90]) by hub.freebsd.org (Postfix) with ESMTP id 1E2BA15366 for ; Tue, 20 Jul 1999 08:46:46 -0700 (PDT) (envelope-from krowett@rowett.org) Received: from rowettpc (208.2.250.25) by messenger.cacheflow.com (Worldmail 1.3.167); 20 Jul 1999 08:45:34 -0700 Message-Id: <4.2.0.58.19990720084410.00a6c070@rowett.org> X-Sender: krowett@rowett.org@pop3.rowett.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 20 Jul 1999 08:45:53 -0700 To: freebsd-net@freebsd.org From: "Kevin J. Rowett" Subject: RE: Tcp shadowing for use in HTTP proxy Cc: Milan Kopacka In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:32 AM 7/20/99 , you wrote: >On Tue, 20 Jul 1999, Alex Rousskov wrote: > > > I may be wrong, but I think there are commercial solutions that > > already offer true transparency. I suggest that you search around if > > you do not want to reinvent the wheel (the latter is OK for academic > > purposes). > >I do not know about any. :| (Besides our wheel :). > > > Unfortunately, I do not have any ready-to-use pointers to true > > transparency, but there are many Web sites devoted to caching and > > caching research... > >Maybe anyone else does know about something? Thanks. Several "L4 switch" vendors provide such products - Arrowpoint, Foundry, Alteon - come to mnd. KR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 10:26:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id C889A15347 for ; Tue, 20 Jul 1999 10:26:10 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id TAA21710; Tue, 20 Jul 1999 19:26:08 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id TAA18840; Tue, 20 Jul 1999 19:26:07 +0200 (MDT) Date: Tue, 20 Jul 1999 19:26:07 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Remy Nonnenmacher Cc: palo.adamec@tecton.sk, freebsd-net@FreeBSD.ORG, Konference o transparentni proxy Subject: RE: Tcp shadowing for use in HTTP proxy In-Reply-To: <199907201635.SAA83507@rt2.synx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Remy Nonnenmacher wrote: > Luigi's BRIDGE code + ipfw + forward + 1 line change in kernel (to allow > an application for binding a 'foreign' local address) allows for > relaying, fully invisible, any TCP/UDP connections. Lot of application > area there. We are using something like, but instead of bridge just "shadow interface", which passes in only packets for 'foreign' IP's bound by some process. Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 20 10:31:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 54F2B15347 for ; Tue, 20 Jul 1999 10:31:28 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id TAA25089; Tue, 20 Jul 1999 19:30:23 +0200 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id TAA20962; Tue, 20 Jul 1999 19:30:23 +0200 (MDT) Date: Tue, 20 Jul 1999 19:30:22 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: "Kevin J. Rowett" Cc: freebsd-net@freebsd.org, Konference o transparentni proxy Subject: RE: Tcp shadowing for use in HTTP proxy In-Reply-To: <4.2.0.58.19990720084410.00a6c070@rowett.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999, Kevin J. Rowett wrote: > >Maybe anyone else does know about something? Thanks. > > Several "L4 switch" vendors provide such products - Arrowpoint, > Foundry, Alteon - come to mnd. Thanks, I'm currently looking at them. Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 21 1:55:50 1999 Delivered-To: freebsd-net@freebsd.org Received: from gw0.boostworks.com (gw0.boostworks.com [194.167.81.213]) by hub.freebsd.org (Postfix) with ESMTP id D8B7F14DBD for ; Wed, 21 Jul 1999 01:55:36 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id SAA83507; Tue, 20 Jul 1999 18:35:24 +0200 (CEST) Message-Id: <199907201635.SAA83507@rt2.synx.com> Date: Tue, 20 Jul 1999 18:35:18 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: RE: Tcp shadowing for use in HTTP proxy To: Milan.Kopacka@st.ms.mff.cuni.cz Cc: mkop5230@ss1000.ms.mff.cuni.cz, palo.adamec@tecton.sk, freebsd-net@FreeBSD.ORG, tpc-l@freebsd.cz In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20 Jul, Milan Kopacka wrote: > On Tue, 20 Jul 1999, Pavol Adamec wrote: > >> It would be interesting to know the real purpose that led to the idea. >> Why is it so important for the server to see client's real IP or why >> is it so important for the proxy to have the server see client's real >> IP. > > Such feature is mainly academic - to try, if fully transparent proxying of > HTTP can be achieved, what must be done and where are the limitations. > Transparent means invisible - but how close can we get..? > Luigi's BRIDGE code + ipfw + forward + 1 line change in kernel (to allow an application for binding a 'foreign' local address) allows for relaying, fully invisible, any TCP/UDP connections. Lot of application area there. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 21 7:24:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by hub.freebsd.org (Postfix) with ESMTP id AFC1A14E1C for ; Wed, 21 Jul 1999 07:24:35 -0700 (PDT) (envelope-from jacopo.pecci@erv.ericsson.se) Received: from ervgwy.eritel.se (ervgwy.erv.ericsson.se [192.71.49.65]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with SMTP id QAA16356 for ; Wed, 21 Jul 1999 16:23:26 +0200 (MET DST) Received: by ervgwy.eritel.se (4.1/SMI-4.1) id AA22446; Wed, 21 Jul 99 16:23:24 +0200 Received: from puh.erv.ericsson.se(193.234.208.14) by ervgwy.eritel.se via smap (V1.3) id sma022437; Wed Jul 21 16:23:03 1999 Received: from erv.ericsson.se by puh (SMI-8.6/SMI-SVR4) id QAA29619; Wed, 21 Jul 1999 16:23:01 +0200 Message-Id: <3795D7C5.20C39295@erv.ericsson.se> Date: Wed, 21 Jul 1999 16:23:01 +0200 From: Jacopo Pecci Organization: Ericsson Mobile Data Design AB X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en Mime-Version: 1.0 To: "freebsd-net@FreeBSD.ORG" Subject: congestion window Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am working on my thesis and I have to implement some of the typical enhancements on TCP to increase the performance of this protocol over wireless link. (Limited byte counting, New Reno algorithm, etc.) I need to keep track of some variable in particular "cwind" (the congestion window). Does anybody know an application which allows me to read such information? Thanks, Jacopo. -- -------------------------------------------------------- Jacopo Pecci (25) IMP student in Digital Communication System & Technology ICQ:7755676 Current address: Richertsgatan 2B/2005 41281 G=F6teborg, SWEDEN phone: +46 (0)707786698 -------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 21 23:33:14 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 1E66414F43 for ; Wed, 21 Jul 1999 23:33:09 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA25741; Thu, 22 Jul 1999 06:07:13 +0200 From: Luigi Rizzo Message-Id: <199907220407.GAA25741@labinfo.iet.unipi.it> Subject: ipfw/dummynet enhancement... To: net@freebsd.org Date: Thu, 22 Jul 1999 06:07:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1568 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, over time several people who use dummynet for testing asked me to add a way to simulate packet reordering. After some thinking triggered by the requests, i believe i have a decent solution: add a "match probability" to ipfw rules such that one can write things like this ipfw add ... pipe 1 ip from A to B prob P1 ipfw add ... pipe 2 ip from A to B prob P2 ipfw add ... pipe 3 ip from A to B prob P3 ipfw add ... pipe 4 ip from A to B and packets go to pipe 1 with prob. P1, pipe 2 w/ prob (1-P1)P2, pipe 3 w/ (1-P1)(1-P2)P3 ... and so on. This seems to be reasonably good to simulate multiple paths (main source of reordering) without introducing dependencies amoung queues/rules thayt would make the system more intrusive. Comments/objections to implement this (the overhead on a normal syztem is zero if "options DUMMYNET" is not used, one additional check for 0 in the normal case of deterministic rules, and one random number generation in case of probabilistic rules). I cannot think immediately of an use for probabilistic ipfw rules except for testing purposes... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 22 5:59:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.ftf.dk (mail.ftf.net [129.142.64.2]) by hub.freebsd.org (Postfix) with ESMTP id 7D64014C0B for ; Thu, 22 Jul 1999 05:59:39 -0700 (PDT) (envelope-from regnauld@ftf.net) Received: from ns.int.ftf.net (fw2.ftf.dk [192.168.1.2] (may be forged)) by mail.ftf.dk (8.9.3/8.9.3/gw-ftf-1.2) with ESMTP id OAA12347 for ; Thu, 22 Jul 1999 14:59:22 +0200 (CEST) X-Authentication-Warning: mail.ftf.dk: Host fw2.ftf.dk [192.168.1.2] (may be forged) claimed to be ns.int.ftf.net Received: (from regnauld@localhost) by ns.int.ftf.net (8.9.2/8.9.3) id PAA40825; Thu, 22 Jul 1999 15:14:52 +0200 (CEST) Message-ID: <19990722151451.13038@ns.int.ftf.net> Date: Thu, 22 Jul 1999 15:14:51 +0200 From: Phil Regnauld To: freebsd-net@freebsd.org Subject: Strange problem with Natd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e X-Operating-System: FreeBSD 3.1-RELEASE i386 Organization: FTFnet Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Natd is running fine on my box with two netcards: ---fxp0-[box]-xl0--- A win95 box sits on xl0, and a firewall is somewhere after fxp0. fxp0 address = 172.16.211.70 xl0 = 1.0.0.1 Win95 = 1.0.0.2 Natd works, excepts when it hits the firewall, for a specific address. I'm trying to run NetOp from Win95, through the FreeBSD box, through the firewall's (IBM SNG) DMZ interface to an NT box. NT box = 1.2.3.4 This is was tcpdump fxp0 shows: 14:50:46.929212 172.16.211.70.6502 > 1.2.3.4.6502: udp 108 14:50:49.895164 172.16.211.70.6502 > 1.2.3.4.6502: udp 108 ... and it fails. This is what the FW log shows: Jul 22 14:48:38 xxxx: 1999;9630: 2073;ICA1036i;#:;551;R:d; i:;x.x.x.129;s:;1.2.3.4;d:;1.0.0.2;p:;udp;sp:;6502;dp:;6502;r:;r;a:;n;f:;n;T:;0;e:;n;l:;134; Jul 22 14:48:41 xxxx: 1999;9630: 2073;ICA1036i;#:;551;R:d; i:;x.x.x.129;s:;1.2.3.4;d:;1.0.0.2;p:;udp;sp:;6502;dp:;6502;r:;r;a:;n;f:;n;T:;0;e:;n;l:;134; The x.x.x.129 is the Firewall DMZ interface (`i'nterface of transit) s = source d = destination What is REALLY strange, and worries me, is that the destination is 1.0.0.2, which is masqueraded! I can go to other hosts on the net, any protocol and it works... Question: am I seeing a NetOp specific thing ? Do they encapsulate the return address ? It looks like it. IMHO, there is no way the FW could know the address of the source host otherwise... -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 22 11:21:22 1999 Delivered-To: freebsd-net@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id F375215554 for ; Thu, 22 Jul 1999 11:20:54 -0700 (PDT) (envelope-from mike@ns1.seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id OAA27224 for ; Thu, 22 Jul 1999 14:20:39 -0400 (EDT) Date: Thu, 22 Jul 1999 14:20:39 -0400 (EDT) From: Mike Hoskins To: freebsd-net@freebsd.org Subject: Re: etherchannel support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I was curious about etherchannel/NIC aggregation in FreeBSD... browsing the archives turned up a thread that seemed to end up asking 'what does Cisco do?'. What's the status of this now? Someone (luigi?) had asked about methodology for choosing output interface, how to load balance, etc. How would we go about actually 'bonding' multiple interfaces into one logical trunk (single MAC, downed NIC detection, etc.)? Adaptec does this with their Dura* product line, but I think the software is NT only. http://www.adaptec.com/technology/whitepapers/portaggregationio1.html Later, -Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 22 11:38: 9 1999 Delivered-To: freebsd-net@freebsd.org Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.226]) by hub.freebsd.org (Postfix) with SMTP id 300E4155E8 for ; Thu, 22 Jul 1999 11:37:28 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18437; Thu, 22 Jul 1999 14:25:23 -0400 From: "Allen Smith" Message-Id: <9907221425.ZM18435@beatrice.rutgers.edu> Date: Thu, 22 Jul 1999 14:25:23 -0400 In-Reply-To: Mike Hoskins "Re: etherchannel support" (Jul 22, 2:10pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Mike Hoskins , freebsd-net@freebsd.org Subject: Re: etherchannel support Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jul 22, 2:10pm, Mike Hoskins (possibly) wrote: > Hello, > > I was curious about etherchannel/NIC aggregation in FreeBSD... > browsing the archives turned up a thread that seemed to end up asking > 'what does Cisco do?'. > > What's the status of this now? Someone (luigi?) had asked about > methodology for choosing output interface, how to load balance, etc. > How would we go about actually 'bonding' multiple interfaces into one > logical trunk (single MAC, downed NIC detection, etc.)? Adaptec does > this with their Dura* product line, but I think the software is NT > only. > > http://www.adaptec.com/technology/whitepapers/portaggregationio1.html There are a couple of different options available for doing something like this. The first is multiple path support for routing; a beta is at ftp://ftp.flirble.org/pub/unix/hacks/FreeBSD/mpath. It does not include any means of balancing other than equal volume, and necessitates routing to multiple gateways as opposed to an interface route. I've been considering some improvements, namely looking at characteristics like collisions, output errors, and queue drops on the next 2 interfaces in the queue and deciding whether to use the first or second either randomly or deterministically (i.e., whichever looks the best gets the packet). The second is the true bonding you're discussing above. This is available for Linux in the Beowulf project; see http://beowulf.gsfc.nasa.gov/software/bonding.html. I'm primarily looking at the former, for various reasons including that we might have one interface going to a hub with an outside connection and the other interfaces going to isolated hubs; we'd want to be able to use the outside-interface'd hub (probably connected with a bridge to reduce collisions) to also relay data. I'm not really planning on doing much work on either in the near future, however, since we'd mainly be interested in it for connecting together multiple SMP machines for heavy data-crunching work, and we don't have the budget yet for the SMP machines et al. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 22 23:29:20 1999 Delivered-To: freebsd-net@freebsd.org Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by hub.freebsd.org (Postfix) with SMTP id DC5F314F8F for ; Thu, 22 Jul 1999 23:29:17 -0700 (PDT) (envelope-from utterchaos@angelfire.com) Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Thu Jul 22 23:20:38 1999 To: freebsd-net@freebsd.org Date: Thu, 22 Jul 1999 23:20:38 -0700 From: "Shantanu R Kothavale" Message-ID: Mime-Version: 1.0 Cc: X-Sent-Mail: on Reply-To: X-Mailer: MailCity Service Subject: Question about radix trie & ether_output() X-Sender-Ip: 207.135.89.228 Organization: Angelfire (http://email.angelfire.com:80) Content-Type: text/plain; charset=us-ascii Content-Length: 2403 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi freebsd-net-folks, I have a question about the freeing of routes in if_ethersubr.c: ether_output(). In the following code: ---------------------------------------------------------------------- rt = rt0; if (rt) { if ((rt->rt_flags & RTF_UP) == 0) { rt0 = rt = rtalloc1(dst, 1, 0UL); if (rt0) rt->rt_refcnt--; else senderr(EHOSTUNREACH); } if (rt->rt_flags & RTF_GATEWAY) { if (rt->rt_gwroute == 0) goto lookup; ***** if (((rt = rt->rt_gwroute)->rt_flags & RTF_UP) == 0) { ***** rtfree(rt); rt = rt0; ***** lookup: rt->rt_gwroute = rtalloc1(rt->rt_gateway, 1, 0UL); if ((rt = rt->rt_gwroute) == 0) senderr(EHOSTUNREACH); } } /* Code deleted... */ } ---------------------------------------------------------------------- The code which frees the gwroute if it is down and rtalloc1()s a new gateway route...can rt->gwroute be re-used instead of having to allocate a new route entry? Assuming gwroute points to a next hop route entry, if rtrequest(RTM_DELETE) is called to delete the entry but multiple routes point to it, then the route is marked down (RTF_UP is cleared), it is removed from the trie, but not deallocated. All routes using this nexthop are still pointing to it, so as they try to access it, the reference count in the nexthop entry gets decremented until, finally, the entry is freed. Instead, if the nexthop entry could be fixed up and reused, all the routes would point to the correct (new) nexthop information, since their gwroute fields are still pointing to the entry. If there is a fatal flaw in this reasoning, please let me know. Otherwise, I'm curious to know why the route is freed and reallocated. Is this to have a clean processing of deleted routes, or is there some scenario where it must be left hanging around until the reference count has gone to zero? Thanks in advance, utter Angelfire for your free web-based e-mail. http://www.angelfire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 23 5: 5:39 1999 Delivered-To: freebsd-net@freebsd.org Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.2.7]) by hub.freebsd.org (Postfix) with ESMTP id 7788F14E73 for ; Fri, 23 Jul 1999 05:05:28 -0700 (PDT) (envelope-from rombout@gewis.win.tue.nl) Received: from gewis.win.tue.nl [131.155.71.116] by kweetal.tue.nl (8.9.3) for id OAA24646 (ESMTP). Fri, 23 Jul 1999 14:05:12 +0200 (MDT) Received: (from rombout@localhost) by gewis.win.tue.nl (8.9.2/8.9.2) id OAA66696 for freebsd-net@freebsd.org; Fri, 23 Jul 1999 14:05:12 +0200 (CEST) (envelope-from rombout) From: Rombout de Backer Message-ID: <19990723140511.B64214@gewis.win.tue.nl> Date: Fri, 23 Jul 1999 14:05:11 +0200 To: freebsd-net@freebsd.org Subject: ARP Proxy with fake network Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, Situation: We have a link to the internet, together with a few other companies on a subnet (212.61.24.0). We want to filter all packages going into our company. We have eight IP addresses. We installed a FreeBSD box with IPFIREWALL with two network cards. One wired to the subnet and one wired into the internal network. The server is configured as IP address A, the clients as B, C en D (we have three clients at the moment). The first problem we encountered is that the router of the internet provider doesn't route the packages for B, C and D via A. Although the FreeBSD bridge-code could solve this (by bridging instead of routing), it is not a very neat solution in this case (we only want to pass IP traffic that is for us). The first thing we tried was to let the server fool the router of the internet provider by pretending that A was B, C and D using ARP proxy (``arp -s''). This failed because when B would request it's own IP address it would scream and disables it interface (Windows NT, sigh). Then we found choparp which enabled us to specifically announce the ARP reply on an internet interface and announce the IP address of the internet provider on the internal interface. The next problem we encountered was routing. Since the router of the internet provider and our clients were on the same subnet, our server didn't know where to route a packet. We fooled around with route's -interface and stuff like that, but we kept failing. By introducing a ``fake'' network (192.168.1.*), we were able to get routing into track. Not a very neat solution, but it seemed to work. We added a routing entry for every client to the fake network (e.g., route add A 192.168.1.10) and then we added a static arp entry in the arp table for the 192.168.1.10 address. Although A didn't know it was 192.168.1.10, the packet was delivered there (for IP A) and handled. The inner-network was now configured as 192.168.1.1, so FreeBSD understood which network card to use when routing. The clients are now using the internet via the firewall and they have no clue about the fake network. The migration only took place on the server. The only probleming remaining is that when a connection is made from the freebsd box, the connection comes from 192.168.1.1. Although this is not a problem (since A for instance will route back the message, via the ethernet address of the internet provider server, which is spoofed to our ip address) we would have liked that the fake network was never visible. Our question is how to accomplish this. Can the ``route'' problem be fixed, or can applications automatically use the ip address of the other ethernet card? Thanks, Rombout/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 23 18:14:29 1999 Delivered-To: freebsd-net@freebsd.org Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by hub.freebsd.org (Postfix) with ESMTP id 7126114F1E for ; Fri, 23 Jul 1999 18:14:11 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.9.3/8.8.3) id LAA79145 for freebsd-net@freebsd.org; Sat, 24 Jul 1999 11:14:06 +1000 (EST) From: Ernie Elu Message-Id: <199907240114.LAA79145@spooky.eis.net.au> Subject: mpd to USR problem To: freebsd-net@freebsd.org Date: Sat, 24 Jul 1999 11:14:06 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to do a multilink ppp connection using mpd version 2.0b2 on FreeBSD 2.2.8 The connection is to a 3COM/USR Total Control rack using a pair of USR 56k modems. The first modem comes up fine, but when the second modem dials in there is some problem negotaiting and both links drop. Here is my config and log entries if someone could please try to point me in the right direction. ----------------- mpd.conf -------------------------------------- default: load eis.net eis.net: new eis.net modem0 modem1 set iface route default set iface disable on-demand set iface addrs 203.32.64.1 210.8.64.100 set iface idle 0 set bundle authname "aickin" set bundle enable multilink set link enable passive link modem1 set modem script DialPeer set modem var $Telephone "DT0392590000" link modem0 set modem script DialPeer set modem var $Telephone "DT0392590000" ----------------- end mpd.conf ------------------------------ ----------------- /var/log/mpd.log -------------------------- ul 24 10:04:58 dns mpd: mpd: pid 9980, version 2.0b2 (root@dns.aickin.com.au 22:08 19-Jul-1999) Jul 24 10:04:58 dns mpd: [eis.net] using interface tun0 Jul 24 10:05:09 dns mpd: [eis.net] rec'd signal usr1, opening Jul 24 10:05:09 dns mpd: [eis.net] IPCP: Open event Jul 24 10:05:09 dns mpd: [eis.net] IPCP: state change Initial --> Starting Jul 24 10:05:09 dns mpd: [eis.net] IPCP: LayerStart Jul 24 10:05:09 dns mpd: [eis.net] bundle: OPEN event in state CLOSED Jul 24 10:05:09 dns mpd: [eis.net] opening link "modem0"... Jul 24 10:05:09 dns mpd: [eis.net] opening link "modem1"... Jul 24 10:05:09 dns mpd: [eis.net] bundle: OPEN event in state OPENED Jul 24 10:05:09 dns mpd: [eis.net] opening link "modem0"... Jul 24 10:05:09 dns mpd: [eis.net] opening link "modem1"... Jul 24 10:05:09 dns mpd: [modem0] link: OPEN event Jul 24 10:05:09 dns mpd: [modem0] LCP: Open event Jul 24 10:05:09 dns mpd: [modem0] LCP: state change Initial --> Starting Jul 24 10:05:09 dns mpd: [modem0] LCP: LayerStart Jul 24 10:05:09 dns mpd: [modem1] link: OPEN event Jul 24 10:05:09 dns mpd: [modem1] LCP: Open event Jul 24 10:05:09 dns mpd: [modem1] LCP: state change Initial --> Starting Jul 24 10:05:09 dns mpd: [modem1] LCP: LayerStart Jul 24 10:05:09 dns mpd: [modem0] link: OPEN event Jul 24 10:05:09 dns mpd: [modem0] LCP: Open event Jul 24 10:05:09 dns mpd: [modem1] link: OPEN event Jul 24 10:05:09 dns mpd: [modem1] LCP: Open event Jul 24 10:05:09 dns mpd: [modem0] device: OPEN event in state DOWN Jul 24 10:05:09 dns mpd: [modem0] device is now in state OPENING Jul 24 10:05:09 dns mpd: [modem1] device: OPEN event in state DOWN Jul 24 10:05:09 dns mpd: [modem1] device is now in state OPENING Jul 24 10:05:10 dns mpd: [modem0] chat: Detected USR Sportster modem. Jul 24 10:05:10 dns mpd: [modem0] chat: Dialing server at DT0392590000... Jul 24 10:05:25 dns mpd: [modem1] chat: Detected USR U.S. Robotics 56K modem. Jul 24 10:05:25 dns mpd: [modem1] chat: Dialing server at DT0392590000... Jul 24 10:05:26 dns mpd: [modem0] chat: Connected at 52000. Jul 24 10:05:26 dns mpd: [modem0] chat: Initiating auto-login... Jul 24 10:05:28 dns mpd: [modem0] chat: Sending login... Jul 24 10:05:28 dns mpd: [modem0] chat: Sending password... Jul 24 10:05:28 dns mpd: [modem0] chat: Detected PPP frame. Jul 24 10:05:29 dns mpd: [modem0] chat script succeeded Jul 24 10:05:29 dns mpd: [modem0] device: UP event in state OPENING Jul 24 10:05:29 dns mpd: [modem0] device is now in state UP Jul 24 10:05:29 dns mpd: [modem0] link: UP event Jul 24 10:05:29 dns mpd: [modem0] LCP: Up event Jul 24 10:05:29 dns mpd: [modem0] LCP: state change Starting --> Req-Sent Jul 24 10:05:29 dns mpd: [modem0] LCP: phase shift DEAD --> ESTABLISH Jul 24 10:05:29 dns mpd: [modem0] LCP: SendConfigReq #1 Jul 24 10:05:29 dns mpd: ACFCOMP Jul 24 10:05:29 dns mpd: PROTOCOMP Jul 24 10:05:29 dns mpd: ACCMAP 0x000a0000 Jul 24 10:05:29 dns mpd: MRU 1500 Jul 24 10:05:29 dns mpd: MAGICNUM e7142314 Jul 24 10:05:29 dns mpd: MP MRRU 1600 Jul 24 10:05:29 dns mpd: MP SHORTSEQ Jul 24 10:05:29 dns mpd: ENDPOINTDISC [802.1] 00 00 c0 b7 e9 b5 Jul 24 10:05:29 dns mpd: [modem0] LCP: rec'd Configure Request #2 (Req-Sent) Jul 24 10:05:29 dns mpd: MRU 1500 Jul 24 10:05:29 dns mpd: MP MRRU 1500 Jul 24 10:05:29 dns mpd: ENDPOINTDISC [Magic] 8b c5 19 d9 Jul 24 10:05:29 dns mpd: ACCMAP 0x00000000 Jul 24 10:05:29 dns mpd: MAGICNUM 3ec2fe32 Jul 24 10:05:29 dns mpd: PROTOCOMP Jul 24 10:05:29 dns mpd: ACFCOMP Jul 24 10:05:29 dns mpd: [modem0] LCP: SendConfigAck #2 Jul 24 10:05:29 dns mpd: MRU 1500 Jul 24 10:05:29 dns mpd: MP MRRU 1500 Jul 24 10:05:29 dns mpd: ENDPOINTDISC [Magic] 8b c5 19 d9 Jul 24 10:05:29 dns mpd: ACCMAP 0x00000000 Jul 24 10:05:29 dns mpd: MAGICNUM 3ec2fe32 Jul 24 10:05:29 dns mpd: PROTOCOMP Jul 24 10:05:29 dns mpd: ACFCOMP Jul 24 10:05:29 dns mpd: [modem0] LCP: state change Req-Sent --> Ack-Sent Jul 24 10:05:29 dns mpd: [modem0] LCP: rec'd Configure Ack #1 (Ack-Sent) Jul 24 10:05:29 dns mpd: ACFCOMP Jul 24 10:05:29 dns mpd: PROTOCOMP Jul 24 10:05:29 dns mpd: ACCMAP 0x000a0000 Jul 24 10:05:29 dns mpd: MRU 1500 Jul 24 10:05:29 dns mpd: MAGICNUM e7142314 Jul 24 10:05:29 dns mpd: MP MRRU 1600 Jul 24 10:05:29 dns mpd: MP SHORTSEQ Jul 24 10:05:29 dns mpd: ENDPOINTDISC [802.1] 00 00 c0 b7 e9 b5 Jul 24 10:05:29 dns mpd: [modem0] LCP: state change Ack-Sent --> Opened Jul 24 10:05:29 dns mpd: [modem0] LCP: phase shift ESTABLISH --> AUTHENTICATE Jul 24 10:05:29 dns mpd: [modem0] LCP: auth: peer wants nothing, I want nothing Jul 24 10:05:29 dns mpd: [modem0] LCP: authorization successful Jul 24 10:05:29 dns mpd: [modem0] LCP: phase shift AUTHENTICATE --> NETWORK Jul 24 10:05:29 dns mpd: [eis.net] up: 1 link, total bandwidth 52000 bps Jul 24 10:05:29 dns mpd: [eis.net] IPCP: Up event Jul 24 10:05:29 dns mpd: [eis.net] IPCP: state change Starting --> Req-Sent Jul 24 10:05:29 dns mpd: [eis.net] IPCP: SendConfigReq #1 Jul 24 10:05:29 dns mpd: IPADDR 203.17.109.1 Jul 24 10:05:29 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:29 dns mpd: [modem0] LCP: LayerUp Jul 24 10:05:29 dns mpd: [eis.net] IPCP: rec'd Configure Request #1 (Req-Sent) Jul 24 10:05:29 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:29 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:29 dns mpd: 210.8.64.100 is OK Jul 24 10:05:29 dns mpd: [eis.net] IPCP: SendConfigAck #1 Jul 24 10:05:29 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:29 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:29 dns mpd: [eis.net] IPCP: state change Req-Sent --> Ack-Sent Jul 24 10:05:29 dns mpd: [eis.net] IPCP: rec'd Configure Nak #1 (Ack-Sent) Jul 24 10:05:29 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:29 dns mpd: 203.32.64.1 is OK Jul 24 10:05:29 dns mpd: [eis.net] IPCP: SendConfigReq #2 Jul 24 10:05:29 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:29 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:29 dns mpd: [eis.net] IPCP: rec'd Configure Ack #2 (Ack-Sent) Jul 24 10:05:29 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:29 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:29 dns mpd: [eis.net] IPCP: state change Ack-Sent --> Opened Jul 24 10:05:29 dns mpd: [eis.net] IPCP: LayerUp Jul 24 10:05:29 dns mpd: 203.32.64.1 -> 210.8.64.100 Jul 24 10:05:29 dns mpd: [eis.net] IFACE: Up event Jul 24 10:05:29 dns mpd: [eis.net] IFACE: Opening Jul 24 10:05:29 dns mpd: [eis.net] exec: /sbin/ifconfig tun0 203.32.64.1 210.8.64.100 netmask 0xffffffff -link0 Jul 24 10:05:29 dns mpd: [eis.net] exec: /sbin/route add 0.0.0.0 210.8.64.100 Jul 24 10:05:29 dns mpd: [modem0] rec'd unsupported protocol: CCP Jul 24 10:05:43 dns mpd: [modem1] chat: Connected at 45333. Jul 24 10:05:43 dns mpd: [modem1] chat: Initiating auto-login... Jul 24 10:05:45 dns mpd: [modem1] chat: Sending login... Jul 24 10:05:46 dns mpd: [modem1] chat: Sending password... Jul 24 10:05:46 dns mpd: [modem1] chat: Detected PPP frame. Jul 24 10:05:46 dns mpd: [modem1] chat script succeeded Jul 24 10:05:46 dns mpd: [modem1] device: UP event in state OPENING Jul 24 10:05:46 dns mpd: [modem1] device is now in state UP Jul 24 10:05:46 dns mpd: [modem1] link: UP event Jul 24 10:05:46 dns mpd: [modem1] LCP: Up event Jul 24 10:05:46 dns mpd: [modem1] LCP: state change Starting --> Req-Sent Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift DEAD --> ESTABLISH Jul 24 10:05:46 dns mpd: [modem1] LCP: SendConfigReq #1 Jul 24 10:05:46 dns mpd: ACFCOMP Jul 24 10:05:46 dns mpd: PROTOCOMP Jul 24 10:05:46 dns mpd: ACCMAP 0x000a0000 Jul 24 10:05:46 dns mpd: MRU 1500 Jul 24 10:05:46 dns mpd: MAGICNUM 687c05fc Jul 24 10:05:46 dns mpd: MP MRRU 1600 Jul 24 10:05:46 dns mpd: MP SHORTSEQ Jul 24 10:05:46 dns mpd: ENDPOINTDISC [802.1] 00 00 c0 b7 e9 b5 Jul 24 10:05:46 dns mpd: [modem1] LCP: rec'd Configure Request #2 (Req-Sent) Jul 24 10:05:46 dns mpd: MRU 1500 Jul 24 10:05:46 dns mpd: MP MRRU 1500 Jul 24 10:05:46 dns mpd: ENDPOINTDISC [Magic] 8b c5 19 d9 Jul 24 10:05:46 dns mpd: ACCMAP 0x00000000 Jul 24 10:05:46 dns mpd: MAGICNUM 8ca278d4 Jul 24 10:05:46 dns mpd: PROTOCOMP Jul 24 10:05:46 dns mpd: ACFCOMP Jul 24 10:05:46 dns mpd: [modem1] LCP: SendConfigAck #2 Jul 24 10:05:46 dns mpd: MRU 1500 Jul 24 10:05:46 dns mpd: MP MRRU 1500 Jul 24 10:05:46 dns mpd: ENDPOINTDISC [Magic] 8b c5 19 d9 Jul 24 10:05:46 dns mpd: ACCMAP 0x00000000 Jul 24 10:05:46 dns mpd: MAGICNUM 8ca278d4 Jul 24 10:05:46 dns mpd: PROTOCOMP Jul 24 10:05:46 dns mpd: ACFCOMP Jul 24 10:05:46 dns mpd: [modem1] LCP: state change Req-Sent --> Ack-Sent Jul 24 10:05:46 dns mpd: [modem1] LCP: rec'd Configure Ack #1 (Ack-Sent) Jul 24 10:05:46 dns mpd: ACFCOMP Jul 24 10:05:46 dns mpd: PROTOCOMP Jul 24 10:05:46 dns mpd: ACCMAP 0x000a0000 Jul 24 10:05:46 dns mpd: MRU 1500 Jul 24 10:05:46 dns mpd: MAGICNUM 687c05fc Jul 24 10:05:46 dns mpd: MP MRRU 1600 Jul 24 10:05:46 dns mpd: MP SHORTSEQ Jul 24 10:05:46 dns mpd: ENDPOINTDISC [802.1] 00 00 c0 b7 e9 b5 Jul 24 10:05:46 dns mpd: [modem1] LCP: state change Ack-Sent --> Opened Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift ESTABLISH --> AUTHENTICATE Jul 24 10:05:46 dns mpd: [modem1] LCP: auth: peer wants nothing, I want nothing Jul 24 10:05:46 dns mpd: [modem1] LCP: authorization successful Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift AUTHENTICATE --> NETWORK Jul 24 10:05:46 dns mpd: [eis.net] up: 2 links, total bandwidth 97333 bps Jul 24 10:05:46 dns mpd: [modem1] LCP: LayerUp Jul 24 10:05:46 dns mpd: [eis.net] IPCP: rec'd Configure Request #1 (Opened) Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:46 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:46 dns mpd: 210.8.64.100 is OK Jul 24 10:05:46 dns mpd: [eis.net] IPCP: LayerDown Jul 24 10:05:46 dns mpd: [eis.net] IFACE: Down event Jul 24 10:05:46 dns mpd: [eis.net] exec: /sbin/route delete 0.0.0.0 210.8.64.100 Jul 24 10:05:46 dns mpd: [eis.net] exec: /sbin/ifconfig tun0 down delete -link0 Jul 24 10:05:46 dns mpd: [eis.net] IPCP: SendConfigReq #3 Jul 24 10:05:46 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:46 dns mpd: [eis.net] IPCP: SendConfigAck #1 Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:46 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:46 dns mpd: [eis.net] IPCP: state change Opened --> Ack-Sent Jul 24 10:05:48 dns mpd: [eis.net] IPCP: SendConfigReq #4 Jul 24 10:05:48 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:48 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:49 dns mpd: [eis.net] IPCP: rec'd Configure Request #2 (Ack-Sent) Jul 24 10:05:49 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:49 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:49 dns mpd: 210.8.64.100 is OK Jul 24 10:05:49 dns mpd: [eis.net] IPCP: SendConfigAck #2 Jul 24 10:05:49 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:49 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:50 dns mpd: [eis.net] IPCP: SendConfigReq #5 Jul 24 10:05:50 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:50 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:52 dns mpd: [eis.net] IPCP: SendConfigReq #6 Jul 24 10:05:52 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:52 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:52 dns mpd: [eis.net] IPCP: rec'd Configure Request #3 (Ack-Sent) Jul 24 10:05:52 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:52 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:52 dns mpd: 210.8.64.100 is OK Jul 24 10:05:52 dns mpd: [eis.net] IPCP: SendConfigAck #3 Jul 24 10:05:52 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:52 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:54 dns mpd: [eis.net] IPCP: SendConfigReq #7 Jul 24 10:05:54 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:54 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:55 dns mpd: [eis.net] IPCP: rec'd Configure Request #4 (Ack-Sent) Jul 24 10:05:55 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:55 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:55 dns mpd: 210.8.64.100 is OK Jul 24 10:05:55 dns mpd: [eis.net] IPCP: SendConfigAck #4 Jul 24 10:05:55 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:55 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:56 dns mpd: [eis.net] IPCP: SendConfigReq #8 Jul 24 10:05:56 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:56 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:58 dns mpd: [eis.net] IPCP: SendConfigReq #9 Jul 24 10:05:58 dns mpd: IPADDR 203.32.64.1 Jul 24 10:05:58 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:58 dns mpd: [eis.net] IPCP: rec'd Configure Request #5 (Ack-Sent) Jul 24 10:05:58 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:58 dns mpd: IPADDR 210.8.64.100 Jul 24 10:05:58 dns mpd: 210.8.64.100 is OK Jul 24 10:05:58 dns mpd: [eis.net] IPCP: SendConfigAck #5 Jul 24 10:05:58 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:05:58 dns mpd: IPADDR 210.8.64.100 Jul 24 10:06:00 dns mpd: [eis.net] IPCP: SendConfigReq #10 Jul 24 10:06:00 dns mpd: IPADDR 203.32.64.1 Jul 24 10:06:00 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:06:01 dns mpd: [eis.net] IPCP: rec'd Configure Request #6 (Ack-Sent) Jul 24 10:06:01 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:06:01 dns mpd: IPADDR 210.8.64.100 Jul 24 10:06:01 dns mpd: 210.8.64.100 is OK Jul 24 10:06:01 dns mpd: [eis.net] IPCP: SendConfigAck #6 Jul 24 10:06:01 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid Jul 24 10:06:01 dns mpd: IPADDR 210.8.64.100 ------------- end /var/log/mpd.log -------------------------------- And then there are A few lines like Jul 24 10:15:31 dns mpd: [eis.net] IPCP: state change Ack-Sent --> Stopped Jul 24 10:15:31 dns mpd: [eis.net] IPCP: LayerFinish Jul 24 10:15:31 dns mpd: [eis.net] IPCP: parameter negotiation failed Jul 24 10:15:31 dns mpd: [eis.net] IPCP: LayerFinish Jul 24 10:15:31 dns mpd: [eis.net] bundle: CLOSE event in state OPENED Jul 24 10:15:31 dns mpd: [eis.net] closing link "modem0"... Jul 24 10:15:31 dns mpd: [eis.net] closing link "modem1"... Jul 24 10:15:31 dns mpd: [eis.net] bundle: CLOSE event in state CLOSED Jul 24 10:15:31 dns mpd: [eis.net] closing link "modem0"... Jul 24 10:15:31 dns mpd: [eis.net] closing link "modem1"... Jul 24 10:15:31 dns mpd: [modem1] link: CLOSE event Any suggestions? - Ernie. ernie@eis.net.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 23 20:59:20 1999 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (dynamic-88.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.88]) by hub.freebsd.org (Postfix) with ESMTP id 0996D14D41 for ; Fri, 23 Jul 1999 20:59:10 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id EAA08405; Sat, 24 Jul 1999 04:51:12 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id EAA07608; Sat, 24 Jul 1999 04:51:29 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199907240351.EAA07608@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Ernie Elu Cc: freebsd-net@FreeBSD.ORG Subject: Re: mpd to USR problem In-reply-to: Your message of "Sat, 24 Jul 1999 11:14:06 +1000." <199907240114.LAA79145@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jul 1999 04:51:28 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I am trying to do a multilink ppp connection using mpd version 2.0b2 on FreeBSD 2.2.8 > > The connection is to a 3COM/USR Total Control rack using a pair of USR 56k > modems. > > The first modem comes up fine, but when the second modem dials in there is > some problem negotaiting and both links drop. > > Here is my config and log entries if someone could please try to point me in > the right direction. [.....] > Jul 24 10:05:46 dns mpd: [modem1] LCP: phase shift AUTHENTICATE --> NETWORK Strange - this state machine shouldn't be per link (it isn't in ppp anyway). > Jul 24 10:05:46 dns mpd: [eis.net] up: 2 links, total bandwidth 97333 bps > Jul 24 10:05:46 dns mpd: [modem1] LCP: LayerUp > Jul 24 10:05:46 dns mpd: [eis.net] IPCP: rec'd Configure Request #1 (Opened) > Jul 24 10:05:46 dns mpd: COMPPROTO VJCOMP, 16 slots, no comp-cid > Jul 24 10:05:46 dns mpd: IPADDR 210.8.64.100 > Jul 24 10:05:46 dns mpd: 210.8.64.100 is OK The peer is misbehaving. It's asking to renegotiate IPCP. You should report this to 3com and/or your ISP. [.....] > Any suggestions? If you're interested in proving this from another ppp implementation, you can always try ppp too :-) > - Ernie. > ernie@eis.net.au -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 24 15: 7: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 3666F14C13 for ; Sat, 24 Jul 1999 15:07:04 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id RAA03294 for freebsd-net@freebsd.org; Sat, 24 Jul 1999 17:05:41 -0500 (CDT) From: Mohit Aron Message-Id: <199907242205.RAA03294@cs.rice.edu> Subject: FreeBSD tuning for webserver performance To: freebsd-net@freebsd.org Date: Sat, 24 Jul 1999 17:05:41 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, during my work on FreeBSD with Webservers, I've come across several minor tuning enhancements that need to be applied to the kernel for efficient performance with Web servers. I'm listing some of them below - perhaps these can be merged with other tuning information that the FreeBSD maintainers might be keeping with FreeBSD. Also I'd appreciate pointers to any other tuning information that people might have. - Mohit Aron aron@cs.rice.edu ------------------------------------------------------------------------------ Tuning FreeBSD-2.2.6 for Webserver Performance 1) Increase TCBHASHSIZE defined in netinet/tcp_subr.c. This speeds up the hash table lookup for a busy webserver that handles a lot of connections (can be as large as 50000 for Apache webserver). The default value of 512 can cause significant lookup delays. I usually increase this value to 16384. 2) Increase IP interface queue size (default 50). It can be changed by recompiling kernel after setting IFQ_MAXLEN in sys/net/if.h. This parameter determines the max number of packets in a burst that can be handled by the webserver. A value of 50 is rather small - SYN packets received from clients connecting simultaneously can overrun the IP queue. I usually increase this value to 1000. 3) Increase maxusers (default 10). This allocates more memory to mbuf pool. This is done in the kernel configuration file. I typically increase this value to 256. 4) Increase the number of connections that can be queued in the listen queue (default 128). This can be done by recompiling kernel after increasing SOMAXCONN in sys/socket.h. The above parameter determines the max number of clients that will be accepted assume they all connect simultaneously. I usually increase this value to 1024. 5) Increase the maximum socket send and receive buffer sizes (default 256K). This can be done by recompiling kernel after setting SB_MAX in sys/socketvar.h. A value of 256K can be short for high bandwidth-delay paths e.g. a 100Mbps link with a 60ms round-trip delay can contain 750K worth of data. Such WAN bandwidths are now becoming available. It might be worthwhile to set SB_MAX to 1024K. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 24 17:35:20 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 1F7D814F30 for ; Sat, 24 Jul 1999 17:35:17 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id AAA01871; Sun, 25 Jul 1999 00:10:33 +0200 From: Luigi Rizzo Message-Id: <199907242210.AAA01871@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Sun, 25 Jul 1999 00:10:33 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199907242205.RAA03294@cs.rice.edu> from "Mohit Aron" at Jul 24, 99 05:05:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1637 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi, > during my work on FreeBSD with Webservers, I've come across several > minor tuning enhancements that need to be applied to the kernel for efficient > performance with Web servers. I'm listing some of them below - perhaps these ... > 2) Increase IP interface queue size (default 50). It can be changed by > recompiling kernel after setting IFQ_MAXLEN in sys/net/if.h. This parameter > determines the max number of packets in a burst that can be handled by the > webserver. A value of 50 is rather small - SYN packets received from > clients connecting simultaneously can overrun the IP queue. I usually > increase this value to 1000. this one i'd be a bit careful about. The same parameter is used for both input (ipqmaxlen = IFQ_MAXLEN) and output queues. On the output side this means you can have up to 1.5MBytes queued on output on one interface -- that's over one second on a 10Mbit ethernet. If you are sending so much data to fill your 50-slot queues (and this can only be because of a burst) you do want drops so that you get immediate feedback and can de-synchronize the flows and avoid further bursts of the same kind. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message