From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 14:02:43 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F9E16A41F for ; Mon, 19 Sep 2005 14:02:43 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC18B43D45 for ; Mon, 19 Sep 2005 14:02:42 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from [82.70.93.201] (helo=h1.trendhosting.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1EHMEC-0002mU-IS for freebsd-isp@freebsd.org; Mon, 19 Sep 2005 14:02:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1.trendhosting.net (Postfix) with ESMTP id D5652DEC23 for ; Mon, 19 Sep 2005 15:02:39 +0100 (BST) Message-ID: <432EC4FF.4030706@lvdx.com> Date: Mon, 19 Sep 2005 15:02:39 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-isp@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030405070201010404000400" X-Originating-Pythagoras-IP: [82.70.93.201] Subject: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 14:02:43 -0000 This is a cryptographically signed message in MIME format. --------------ms030405070201010404000400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've been told that FreeBSD performs routing computations in linear time, even with large routing tables (such as from BGP), and that it is therefore superior to Linux for use as a border router. Is this so, and are there any specific documents I should review about the performance of FreeBSD routing? As I haven't used FreeBSD before (I've been using Debian for about 10 years), I am wanting to make sure my expectations are not unreasonable. I've discovered that there is the 4.11 release and the 5.4 release. Are there any compelling reasons why I should choose one of these over the other, for my intended application? The only application I will be running is quagga. I'm planning to connect the FreeBSD server to a trunk port on a Cisco 2950 and put each interconnected IP provider into a separate VLAN. The documentation I've read so far suggests that FreeBSD is happy with VLANs - will this arrangement work and will it have any significant effect on performance? Regards, Daniel -------------------------------------- Director London Voice and Data Exchange Limited http://www.lvdx.com -------------------------------------- --------------ms030405070201010404000400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII4TCC AsswggI0oAMCAQICAw4bBzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjIyMTcwMTQ2WhcNMDYwMjIyMTcwMTQ2 WjBBMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9k YW5pZWxAbHZkeC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzR3Orw/fI sDm1pnwnQMEwiETBQcKtjolpydPqx0vhhZltrsd1pFxksr2kgylwclf1Ru2Jl/IoyjctJhZn VzADqrXjSlyf6efn/VBigEwKraH64ijM10aaTq72wMfs5/6i3YgxSHfOGkz0Tw5u2rwmL7cl teyP/Bv3PZxIqcfvaRVIKM6GhBrBUE+4UfOA5ggrQy1UKLjflnDgW5+UcIuPPvq5nPecfzKs FbmuGyG7m+tNzN+QRBp9//gIOWEuth9dvKI8g1RJ23PS6mHmH/2+nGeyT8n9F0bGjndCVAyk PUHv6JcAaTCeJcezOsJ96+8F+d66xIn+M1pey1XTwjx9AgMBAAGjLDAqMBoGA1UdEQQTMBGB D2RhbmllbEBsdmR4LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABUeLsOY W/0NBblgBJoUjD0lvoQyAi5M5chYlww19zWE4bL7XONYqp897JTJFumcN3nFwPJygWAgXozZ Qqd2tnw5bKyOUcISoO8w4+Ipna2Xs7gf+dLCAsYBPY7RY9ID2y/IEA5gvn7HpDf3N4AwtkYr kcCeQmqcuT5xUt/YbjBkMIICyzCCAjSgAwIBAgIDDhsHMA0GCSqGSIb3DQEBBAUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTAyMjIxNzAx NDZaFw0wNjAyMjIxNzAxNDZaMEExHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx HjAcBgkqhkiG9w0BCQEWD2RhbmllbEBsdmR4LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAPNHc6vD98iwObWmfCdAwTCIRMFBwq2OiWnJ0+rHS+GFmW2ux3WkXGSyvaSD KXByV/VG7YmX8ijKNy0mFmdXMAOqteNKXJ/p5+f9UGKATAqtofriKMzXRppOrvbAx+zn/qLd iDFId84aTPRPDm7avCYvtyW17I/8G/c9nEipx+9pFUgozoaEGsFQT7hR84DmCCtDLVQouN+W cOBbn5Rwi48++rmc95x/MqwVua4bIbub603M35BEGn3/+Ag5YS62H128ojyDVEnbc9LqYeYf /b6cZ7JPyf0XRsaOd0JUDKQ9Qe/olwBpMJ4lx7M6wn3r7wX53rrEif4zWl7LVdPCPH0CAwEA AaMsMCowGgYDVR0RBBMwEYEPZGFuaWVsQGx2ZHguY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEEBQADgYEAFR4uw5hb/Q0FuWAEmhSMPSW+hDICLkzlyFiXDDX3NYThsvtc41iqnz3s lMkW6Zw3ecXA8nKBYCBejNlCp3a2fDlsrI5RwhKg7zDj4imdrZezuB/50sICxgE9jtFj0gPb L8gQDmC+fsekN/c3gDC2RiuRwJ5Capy5PnFS39huMGQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenpruf ZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIB ADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw4bBzAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNTA5MTkxNDAyMzlaMCMGCSqGSIb3DQEJBDEWBBS/qT30Rarm j/2R+AvVkhUC4ikGRTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3 EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID DhsHMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAw4bBzANBgkqhkiG9w0BAQEFAASCAQC50h1Vjm/d0oYq2SQ+gWN1 U4s1XNVmEUqEGFhhkFa3rvI/1UJqxYOJzdRZ+N+Z+C41UyMCogG0NWE/+vAVyl3WlstJk4EN 1S7S1tUO9As3x8M0Bzcc4LbidQ0JeM4pLjdugt5lMZDO6Xif1zI0Kt5rnPopfkasWUKgGPu6 uM0SPLBvf7d1+GenDZGvuiFCeCVtSEvFH+5TLMfjHjUuvRytFy/liUJZpn17BHFovyURVWhz dfDzdvz3P6HcKsH8fVOkhk9qWR9TFFADoxvYHOvhmSRGCh/QjyYNOFdfvL0N7PpvICCl5iLe lkz6Z4Tokkvqj1GVn6Y4xp2Gg22Pxe82AAAAAAAA --------------ms030405070201010404000400-- From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 17:17:47 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52B7916A41F for ; Mon, 19 Sep 2005 17:17:47 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1439343D46 for ; Mon, 19 Sep 2005 17:17:46 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id j8JHHkXw029090; Mon, 19 Sep 2005 10:17:46 -0700 (PDT) Received: from [10.1.1.209] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j8JHHir8013248; Mon, 19 Sep 2005 10:17:45 -0700 (PDT) In-Reply-To: <432EC4FF.4030706@lvdx.com> References: <432EC4FF.4030706@lvdx.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AB0B562-974F-48EB-BCB4-B8491E7AEFF5@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 19 Sep 2005 13:17:22 -0400 To: Daniel Pocock X-Mailer: Apple Mail (2.734) Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 17:17:47 -0000 On Sep 19, 2005, at 10:02 AM, Daniel Pocock wrote: > I've been told that FreeBSD performs routing computations in linear > time, even with large routing tables (such as from BGP), and that > it is therefore superior to Linux for use as a border router. Is > this so, and are there any specific documents I should review about > the performance of FreeBSD routing? I believe FreeBSD uses a radix lookup for the routing table which is O (1); I don't know enough about the implementation in Linux to make claims about one platform being superior. > I've discovered that there is the 4.11 release and the 5.4 > release. Are there any compelling reasons why I should choose one > of these over the other, for my intended application? The only > application I will be running is quagga. If you are setting up a new system, you should go with 5.4. 4.11 is older and thus extremely well-tested by now, and might arguably be a bit more reliable, but 5.4 has better support for ACPI and recent hardware, as well as a significantly better SMP implementation. > I'm planning to connect the FreeBSD server to a trunk port on a > Cisco 2950 and put each interconnected IP provider into a separate > VLAN. The documentation I've read so far suggests that FreeBSD is > happy with VLANs - will this arrangement work and will it have any > significant effect on performance? This ought to work fine, but you might want to make sure your NICs supports VLAN_MTU and VLAN_HWTAGGING options to help offload some of the work: bge0: flags=8802 mtu 1500 options=1a "man 4 vlan" has a more complete discussion, including a list of NICs which have this kind of hardware support. The Broadcom bge's and Intel's em seem to work well. -- -Chuck From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 20:57:59 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9C9116A41F for ; Mon, 19 Sep 2005 20:57:59 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from complx.LF.net (complx.LF.net [212.9.190.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B9F43D45 for ; Mon, 19 Sep 2005 20:57:59 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from lists by complx.LF.net with local (Exim 4.43) id 1EHSi5-000BjU-RY; Mon, 19 Sep 2005 22:57:57 +0200 Date: Mon, 19 Sep 2005 22:57:57 +0200 From: Kurt Jaeger To: Daniel Pocock Message-ID: <20050919205757.GI62233@complx.LF.net> References: <432EC4FF.4030706@lvdx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432EC4FF.4030706@lvdx.com> Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pi@LF.net List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 20:58:00 -0000 Hallo, > I'm planning to connect the FreeBSD server to a trunk port on a Cisco > 2950 and put each interconnected IP provider into a separate VLAN. The > documentation I've read so far suggests that FreeBSD is happy with VLANs > - will this arrangement work and will it have any significant effect on > performance? We use this setup (with 4.x and 5.x as core routers). We do this since approx. 1996 (in those days with gated and fbsd 2.x and without the VLAN stuff), so it's very solid from our point of view. -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 21:39:42 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A205416A41F for ; Mon, 19 Sep 2005 21:39:42 +0000 (GMT) (envelope-from volfman@keystreams.com) Received: from mailbox.keystreams.com (mailbox.keystreams.com [207.158.28.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1305743D48 for ; Mon, 19 Sep 2005 21:39:42 +0000 (GMT) (envelope-from volfman@keystreams.com) Received: (qmail 35488 invoked by uid 1012); 19 Sep 2005 14:34:24 -0700 Received: from 10.8.0.6 by mail.keystreams.com (envelope-from , uid 1009) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.2/1001. spamassassin: 3.0.4. perlscan: 1.25-st-qms. Clear:RC:0(10.8.0.6):SA:0(-5.9/5.0):. Processed in 3.407291 secs); 19 Sep 2005 21:34:24 -0000 X-Spam-Status: No, hits=-5.9 required=5.0 X-Antivirus-Keystreams-Mail-From: volfman@keystreams.com via mail.keystreams.com X-Antivirus-Keystreams: 1.25-st-qms (Clear:RC:0(10.8.0.6):SA:0(-5.9/5.0):. Processed in 3.407291 secs Process 35456) Received: from unknown (HELO ?10.8.0.6?) (volfman@keystreams.com@10.8.0.6) by mailbox.keystreams.com with AES256-SHA encrypted SMTP; 19 Sep 2005 14:34:20 -0700 Message-ID: <432F3013.7090001@keystreams.com> Date: Mon, 19 Sep 2005 14:39:31 -0700 From: Roman Volf User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pi@LF.net References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> In-Reply-To: <20050919205757.GI62233@complx.LF.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 21:39:42 -0000 Kurt Jaeger wrote: >Hallo, > > > >>I'm planning to connect the FreeBSD server to a trunk port on a Cisco >>2950 and put each interconnected IP provider into a separate VLAN. The >>documentation I've read so far suggests that FreeBSD is happy with VLANs >>- will this arrangement work and will it have any significant effect on >>performance? >> >> > >We use this setup (with 4.x and 5.x as core routers). > >We do this since approx. 1996 (in those days with gated and fbsd 2.x and >without the VLAN stuff), so it's very solid from our point of view. > > > What kind of throughput do you get using FreeBSD and what kind of hardware? Doing a straight FTP transfer from one server to another through a CIsco 3640 seems to cap at about 40 Mbits/second so I was wondering how that compares to a x86 system running FreeBSD. -- Roman Volf Keystreams Internet Solutions volfman@keystreams.com From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 21:46:19 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA5C16A41F for ; Mon, 19 Sep 2005 21:46:19 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from complx.LF.net (complx.LF.net [212.9.190.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83D5943D46 for ; Mon, 19 Sep 2005 21:46:19 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from lists by complx.LF.net with local (Exim 4.43) id 1EHTSs-000BoI-I1; Mon, 19 Sep 2005 23:46:18 +0200 Date: Mon, 19 Sep 2005 23:46:18 +0200 From: Kurt Jaeger To: Roman Volf Message-ID: <20050919214618.GJ62233@complx.LF.net> References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432F3013.7090001@keystreams.com> Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 21:46:20 -0000 Hello, > >>I'm planning to connect the FreeBSD server to a trunk port on a Cisco > >>2950 and put each interconnected IP provider into a separate VLAN. > What kind of throughput do you get using FreeBSD and what kind of > hardware? Hardware: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2998.57-MHz 686-class CPU) real memory = 2146631680 (2096320K bytes) 12 fxp interfaces, 8 vlans on some of those fxp interfaces working as core.LF.net. Throughput: 100mbit peak was possible. All the hardware is 100mbit. We currently prepare a gigE testbed to spread the load. > Doing a straight FTP transfer from one server to another > through a CIsco 3640 seems to cap at about 40 Mbits/second so I was > wondering how that compares to a x86 system running FreeBSD. The tests I made using some shuttle.com barebone hardware etc seems to max out around 500 mbit/sec. It wasn't a full-blown BGP setup, far from it. More seems easily be possible, but we still need to test. -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 21:56:07 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440B516A41F for ; Mon, 19 Sep 2005 21:56:07 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from complx.LF.net (complx.LF.net [212.9.190.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF8C243D46 for ; Mon, 19 Sep 2005 21:56:06 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from lists by complx.LF.net with local (Exim 4.43) id 1EHTcL-000Bpy-Ng; Mon, 19 Sep 2005 23:56:05 +0200 Date: Mon, 19 Sep 2005 23:56:05 +0200 From: Kurt Jaeger To: Roman Volf Message-ID: <20050919215605.GK62233@complx.LF.net> References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050919214618.GJ62233@complx.LF.net> Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 21:56:07 -0000 Hi! > > Doing a straight FTP transfer from one server to another > > through a CIsco 3640 seems to cap at about 40 Mbits/second so I was > > wondering how that compares to a x86 system running FreeBSD. > > The tests I made using some shuttle.com barebone hardware etc > seems to max out around 500 mbit/sec. It wasn't a full-blown BGP setup, > far from it. More seems easily be possible, but we still need > to test. If you use ftp, the limit might be the IO from/to disk, not the cisco throughput. Use ttcp to test the transfer limits, not ftp. http://www.mirrors.wiretapped.net/security/packet-construction/ttcp/ttcp.c -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 22:57:00 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E598516A41F for ; Mon, 19 Sep 2005 22:57:00 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52EB043D5A for ; Mon, 19 Sep 2005 22:56:59 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8JMub6w007516; Tue, 20 Sep 2005 00:56:38 +0200 Message-ID: <432F4223.6030904@wm-access.no> Date: Tue, 20 Sep 2005 00:56:35 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Jaeger References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> In-Reply-To: <20050919214618.GJ62233@complx.LF.net> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Roman Volf , freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 22:57:01 -0000 > >>Doing a straight FTP transfer from one server to another >>through a CIsco 3640 seems to cap at about 40 Mbits/second so I was >>wondering how that compares to a x86 system running FreeBSD. > > > The tests I made using some shuttle.com barebone hardware etc > seems to max out around 500 mbit/sec. It wasn't a full-blown BGP setup, > far from it. More seems easily be possible, but we still need > to test. > 500mbit/sec throughput? that would be 1 gbit/sec input + output? can the PCI bus do any better than that? -- Sten Daniel Sørsdal From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 23:09:02 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A26DB16A41F for ; Mon, 19 Sep 2005 23:09:02 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C3243D46 for ; Mon, 19 Sep 2005 23:09:01 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from [82.70.93.201] (helo=h1.trendhosting.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1EHUku-0005QV-7B for freebsd-isp@freebsd.org; Mon, 19 Sep 2005 23:09:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1.trendhosting.net (Postfix) with ESMTP id B90FEDEC23 for ; Tue, 20 Sep 2005 00:08:55 +0100 (BST) Message-ID: <432F4507.4020708@lvdx.com> Date: Tue, 20 Sep 2005 00:08:55 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-isp@freebsd.org References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> <20050919215605.GK62233@complx.LF.net> In-Reply-To: <20050919215605.GK62233@complx.LF.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050300070800010409040502" X-Originating-Pythagoras-IP: [82.70.93.201] Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 23:09:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050300070800010409040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt Jaeger wrote: >Hi! > > > >>>Doing a straight FTP transfer from one server to another >>>through a CIsco 3640 seems to cap at about 40 Mbits/second so I was >>>wondering how that compares to a x86 system running FreeBSD. >>> >>> >>The tests I made using some shuttle.com barebone hardware etc >>seems to max out around 500 mbit/sec. It wasn't a full-blown BGP setup, >>far from it. More seems easily be possible, but we still need >>to test. >> >> > >If you use ftp, the limit might be the IO from/to disk, not the cisco >throughput. > >Use ttcp to test the transfer limits, not ftp. > >http://www.mirrors.wiretapped.net/security/packet-construction/ttcp/ttcp.c > > > Thanks for all the great answers. I think that packets per second is just as important as megabits per second when evaluating routing. We are a wholesale VoIP operator, so we switch many small packets (less than 100 bytes each) - it takes almost as much CPU power to make routing decisions for a 100 byte packet as for a 1500 byte FTP packet. You will find much of the Cisco specs talk about throughput in packets per second (pps, or kpps). The NIC I am using is the built in Intel i82555 in a DL360 1U server. According to vlan(4), the fxp driver doesn't do native VLAN, but can do large MTU for VLAN tagging. This should give enough performance for our initial requirements (up to 10mbit) and I'll review it later. I'm also curious about whether FreeBSD supports polled rather than interrupt driven behaviour in the NIC driver - that means that the system won't keep on re-entering an interrupt handler concurrently while under load (when a DoS attack is in progress). The server will be set up tommorrow - I'll do some tests and publish my experiences on my web site, as I know several of my customers want to duplicate this for their own redundancy plans. Regards, Daniel -------------------------------------- Director London Voice and Data Exchange Limited http://www.lvdx.com -------------------------------------- --------------ms050300070800010409040502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII4TCC AsswggI0oAMCAQICAw4bBzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjIyMTcwMTQ2WhcNMDYwMjIyMTcwMTQ2 WjBBMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9k YW5pZWxAbHZkeC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzR3Orw/fI sDm1pnwnQMEwiETBQcKtjolpydPqx0vhhZltrsd1pFxksr2kgylwclf1Ru2Jl/IoyjctJhZn VzADqrXjSlyf6efn/VBigEwKraH64ijM10aaTq72wMfs5/6i3YgxSHfOGkz0Tw5u2rwmL7cl teyP/Bv3PZxIqcfvaRVIKM6GhBrBUE+4UfOA5ggrQy1UKLjflnDgW5+UcIuPPvq5nPecfzKs FbmuGyG7m+tNzN+QRBp9//gIOWEuth9dvKI8g1RJ23PS6mHmH/2+nGeyT8n9F0bGjndCVAyk PUHv6JcAaTCeJcezOsJ96+8F+d66xIn+M1pey1XTwjx9AgMBAAGjLDAqMBoGA1UdEQQTMBGB D2RhbmllbEBsdmR4LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABUeLsOY W/0NBblgBJoUjD0lvoQyAi5M5chYlww19zWE4bL7XONYqp897JTJFumcN3nFwPJygWAgXozZ Qqd2tnw5bKyOUcISoO8w4+Ipna2Xs7gf+dLCAsYBPY7RY9ID2y/IEA5gvn7HpDf3N4AwtkYr kcCeQmqcuT5xUt/YbjBkMIICyzCCAjSgAwIBAgIDDhsHMA0GCSqGSIb3DQEBBAUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTAyMjIxNzAx NDZaFw0wNjAyMjIxNzAxNDZaMEExHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx HjAcBgkqhkiG9w0BCQEWD2RhbmllbEBsdmR4LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAPNHc6vD98iwObWmfCdAwTCIRMFBwq2OiWnJ0+rHS+GFmW2ux3WkXGSyvaSD KXByV/VG7YmX8ijKNy0mFmdXMAOqteNKXJ/p5+f9UGKATAqtofriKMzXRppOrvbAx+zn/qLd iDFId84aTPRPDm7avCYvtyW17I/8G/c9nEipx+9pFUgozoaEGsFQT7hR84DmCCtDLVQouN+W cOBbn5Rwi48++rmc95x/MqwVua4bIbub603M35BEGn3/+Ag5YS62H128ojyDVEnbc9LqYeYf /b6cZ7JPyf0XRsaOd0JUDKQ9Qe/olwBpMJ4lx7M6wn3r7wX53rrEif4zWl7LVdPCPH0CAwEA AaMsMCowGgYDVR0RBBMwEYEPZGFuaWVsQGx2ZHguY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEEBQADgYEAFR4uw5hb/Q0FuWAEmhSMPSW+hDICLkzlyFiXDDX3NYThsvtc41iqnz3s lMkW6Zw3ecXA8nKBYCBejNlCp3a2fDlsrI5RwhKg7zDj4imdrZezuB/50sICxgE9jtFj0gPb L8gQDmC+fsekN/c3gDC2RiuRwJ5Capy5PnFS39huMGQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenpruf ZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIB ADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw4bBzAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNTA5MTkyMzA4NTVaMCMGCSqGSIb3DQEJBDEWBBSsZZLIerVe p/dbiVk/+OjwuD/MjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3 EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID DhsHMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAw4bBzANBgkqhkiG9w0BAQEFAASCAQBeY0hlu2GwFeHQa0jjc/2I TKuBFu0osXBdYiP6qKCT2uDBarv+J8wj++tRxMUVHfHMDQJauL1SIjm5qp/KltKdx3tdSrzz /GeIEXJqtuv3f9+2ZmvxuK1uhKpejjKBt1QRehiXtERVXcve86ZbMJNTLfB6QfIzfyzbmuNA lY1dNnK28vJMsg+qetui0/SSXOkUrJY+6tM1ALqqzUFEz2VEgY5lr4MJpaDW4xxkjcKDcpuS BwmMQPeX2oWWiFK6kXJ+GXjhc81w48ylE3Xximpt8zbXbA4Dei+o3/+GuQcdA34Aul5vIAfw RlzwsQBVMSpMSW2++ITSiF1XZXDbylw6AAAAAAAA --------------ms050300070800010409040502-- From owner-freebsd-isp@FreeBSD.ORG Mon Sep 19 23:30:25 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 383BF16A41F for ; Mon, 19 Sep 2005 23:30:25 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C5A43D48 for ; Mon, 19 Sep 2005 23:30:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id E13055D5E; Mon, 19 Sep 2005 19:30:23 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19517-10; Mon, 19 Sep 2005 19:30:20 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-68-11.ny325.east.verizon.net [68.161.68.11]) by pi.codefab.com (Postfix) with ESMTP id 388BE5C3A; Mon, 19 Sep 2005 19:30:19 -0400 (EDT) Message-ID: <432F4A12.9090709@mac.com> Date: Mon, 19 Sep 2005 19:30:26 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Pocock References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> <20050919215605.GK62233@complx.LF.net> <432F4507.4020708@lvdx.com> In-Reply-To: <432F4507.4020708@lvdx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-isp@freebsd.org Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 23:30:25 -0000 Daniel Pocock wrote: [ ... ] > I'm also curious about whether FreeBSD supports polled rather than > interrupt driven behaviour in the NIC driver - that means that the > system won't keep on re-entering an interrupt handler concurrently while > under load (when a DoS attack is in progress). Indeed it does, see "man polling". Make sure you increase HZ to at least 1000... -- -Chuck From owner-freebsd-isp@FreeBSD.ORG Wed Sep 21 11:11:20 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02DCA16A41F for ; Wed, 21 Sep 2005 11:11:20 +0000 (GMT) (envelope-from Marco.Fretz@kyberna.com) Received: from mail.kyberna.net (mail.kyberna.net [194.183.142.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E6B43D49 for ; Wed, 21 Sep 2005 11:11:18 +0000 (GMT) (envelope-from Marco.Fretz@kyberna.com) X-SpamCatcher-Score: 2 [X] Received: from [194.208.56.7] (HELO mail.kyberna.com) by mail.kyberna.net (CommuniGate Pro SMTP 4.2.10) with ESMTP id 8043038 for freebsd-isp@freebsd.org; Wed, 21 Sep 2005 13:11:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Sep 2005 13:10:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HP DL140 with SATA Thread-Index: AcW57xRTPdBrp5iySym2HqbwPsUOAAErd7yg X-Priority: 1 Priority: Urgent Importance: high From: "Fretz Marco" To: "Rasmus Fauske" , Cc: Subject: AW: HP DL140 with SATA X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 11:11:20 -0000 Hello Thanks for your help. I had a dl140 g2 here some days ago. I booted from = a 5.4-release cd and got no support for this controller. May you send me = some kernel output? Dmesg? Thanks Kind regards marco=20 -----Urspr=FCngliche Nachricht----- Von: owner-freebsd-isp@freebsd.org = [mailto:owner-freebsd-isp@freebsd.org] Im Auftrag von Rasmus Fauske Gesendet: Donnerstag, 15. September 2005 14:14 An: freebsd-isp@freebsd.org Betreff: Re: HP DL140 with SATA Fretz Marco wrote: >Hi there > >We are an ips and looking for some pizza box server from HP. Do you got >any experiences with the HP DL140 with SATA Raid? Is this Controller >supported in Free 5.4? > =20 > It is a normal SATA non-raid kontroller, I am running a dl140 g2 with a=20 genom mirror. working great with 5.4 and 6.0 and 6.0/amd64 -- Rasmus Fauske _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" From owner-freebsd-isp@FreeBSD.ORG Wed Sep 21 15:06:54 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F47716A41F for ; Wed, 21 Sep 2005 15:06:54 +0000 (GMT) (envelope-from Marco.Fretz@kyberna.com) Received: from mail.kyberna.net (mail.kyberna.net [194.183.142.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id C224A43D46 for ; Wed, 21 Sep 2005 15:06:51 +0000 (GMT) (envelope-from Marco.Fretz@kyberna.com) X-SpamCatcher-Score: 32 [X] Received: from [194.208.56.7] (HELO mail.kyberna.com) by mail.kyberna.net (CommuniGate Pro SMTP 4.2.10) with ESMTP id 8047095 for freebsd-isp@freebsd.org; Wed, 21 Sep 2005 17:06:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Sep 2005 17:06:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: HP DL140 with SATA Thread-Index: AcW+nwGhHGgD0LznTK+Bou0i+HN6ZgAHs+NA From: "Fretz Marco" To: "Rasmus Fauske" , Cc: Subject: AW: AW: AW: HP DL140 with SATA X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 15:06:54 -0000 Hello news: no chance to get the SATA ICH5 run on 6.0 or 5.4. i got only = ATA_IDENTIFY time outs I tried freebsd 4.11 > no problem Why this? Anyone any idea? thanks -----Urspr=FCngliche Nachricht----- Von: Rasmus Fauske [mailto:rasmus@postboks.org]=20 Gesendet: Mittwoch, 21. September 2005 13:24 An: Fretz Marco Betreff: Re: AW: AW: HP DL140 with SATA It was working when I tried it, but I only used it fo some minutes. Fretz Marco wrote: >Hi > >Thanks. Ok but 6.0 isnt stable yet. So i need to run 5.4. you'r sure, = you have a DL140 G2 and SATA controller was working with free 5.4?=20 > >-----Urspr=FCngliche Nachricht----- >Von: Rasmus Fauske [mailto:rasmus@postboks.org]=20 >Gesendet: Mittwoch, 21. September 2005 13:12 >An: Fretz Marco >Betreff: Re: AW: HP DL140 with SATA >Wichtigkeit: Hoch > > =20 > >>Hello >> >>Thanks for your help. I had a dl140 g2 here some days ago. I booted = from a >>5.4-release cd and got no support for this controller. May you send me >>some kernel output? Dmesg? >> =20 >> > >This is the output for 6.0, I don't have for 5.4 any more as this box = is >in production now > >Copyright (c) 1992-2005 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. >FreeBSD 6.0-BETA5 #3: Sun Sep 18 08:22:37 CEST 2005 > admin@web.dialecta.no:/usr/obj/usr/src/sys/WEB >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 > = Features=3D0xbfebfbff > Features2=3D0x641d> > AMD Features=3D0x20100800 > Hyperthreading: 2 logical CPUs >real memory =3D 1073152000 (1023 MB) >avail memory =3D 1027723264 (980 MB) >ACPI APIC Table: >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >ioapic0 irqs 0-23 on motherboard >ioapic1 irqs 24-47 on motherboard >ioapic2 irqs 48-71 on motherboard >acpi0: on motherboard >acpi0: Power Button (fixed) >pci_link0: irq 5 on acpi0 >pci_link1: irq 10 on acpi0 >pci_link2: irq 10 on acpi0 >pci_link3: irq 0 on acpi0 >pci_link4: irq 0 on acpi0 >pci_link5: irq 0 on acpi0 >pci_link6: irq 0 on acpi0 >pci_link7: irq 0 on acpi0 >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >cpu0: on acpi0 >acpi_throttle0: on cpu0 >cpu1: on acpi0 >acpi_throttle1: on cpu1 >acpi_throttle1: failed to attach P_CNT >device_attach: acpi_throttle1 attach returned 6 >pcib0: port 0xcf8-0xcff on acpi0 >pci0: on pcib0 >pci0: at device 0.1 (no driver attached) >pcib1: irq 16 at device 2.0 on pci0 >pci1: on pcib1 >pcib2: irq 16 at device 4.0 on pci0 >pci2: on pcib2 >bge0: mem >0xdd100000-0xdd10ffff irq 16 at device 0.0 on pci2 >miibus0: on bge0 >brgphy0: on miibus0 >brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >1000baseTX-FDX, auto >bge0: Ethernet address: 00:14:38:a7:12:96 >pcib3: irq 16 at device 5.0 on pci0 >pci3: on pcib3 >bge1: mem >0xdd200000-0xdd20ffff irq 16 at device 0.0 on pci3 >miibus1: on bge1 >brgphy1: on miibus1 >brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >1000baseTX-FDX, auto >bge1: Ethernet address: 00:14:38:a7:12:97 >pcib4: irq 16 at device 6.0 on pci0 >pci4: on pcib4 >pcib5: at device 0.0 on pci4 >pci5: on pcib5 >pci4: at device 0.1 (no driver >attached) >pcib6: at device 0.2 on pci4 >pci6: on pcib6 >pci4: at device 0.3 (no driver >attached) >pcib7: at device 30.0 on pci0 >pci7: on pcib7 >pci7: at device 1.0 (no driver attached) >isab0: at device 31.0 on pci0 >isa0: on isab0 >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1430-0x143f at device 31.2 on = pci0 >atapci0: failed to enable memory mapping! >ata0: on atapci0 >ata1: on atapci0 >pci0: at device 31.3 (no driver attached) >acpi_button0: on acpi0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >orm0: at iomem 0xc0000-0xc7fff,0xdc000-0xdffff on = isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=3D0x300> >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 >Timecounters tick every 1.000 msec >acd0: CDROM at ata0-master PIO4 >ad2: 76319MB at ata1-master SATA150 >GEOM_MIRROR: Device gm0 created (id=3D2900722631). >GEOM_MIRROR: Device gm0: provider ad2 detected. >ad3: 76319MB at ata1-slave SATA150 >GEOM_MIRROR: Device gm0: provider ad3 detected. >GEOM_MIRROR: Device gm0: provider ad3 activated. >GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. >GEOM_MIRROR: Device gm0: rebuilding provider ad2. >SMP: AP CPU #1 Launched! >Trying to mount root from ufs:/dev/mirror/gm0s1a > > =20 > >>Thanks >> >>Kind regards >>marco >> >>-----Urspr=FCngliche Nachricht----- >>Von: owner-freebsd-isp@freebsd.org = [mailto:owner-freebsd-isp@freebsd.org] >>Im Auftrag von Rasmus Fauske >>Gesendet: Donnerstag, 15. September 2005 14:14 >>An: freebsd-isp@freebsd.org >>Betreff: Re: HP DL140 with SATA >> >>Fretz Marco wrote: >> >> =20 >> >>>Hi there >>> >>>We are an ips and looking for some pizza box server from HP. Do you = got >>>any experiences with the HP DL140 with SATA Raid? Is this Controller >>>supported in Free 5.4? >>> >>> >>> =20 >>> >>It is a normal SATA non-raid kontroller, I am running a dl140 g2 with = a >>genom mirror. working great with 5.4 and 6.0 and 6.0/amd64 >> >>-- >>Rasmus Fauske >>_______________________________________________ >>freebsd-isp@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-isp >>To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" >> >> =20 >> > > > =20 > From owner-freebsd-isp@FreeBSD.ORG Fri Sep 23 21:30:14 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54EF516A426 for ; Fri, 23 Sep 2005 21:30:09 +0000 (GMT) (envelope-from Blackstone@licht-labs.com) Received: from chb63.neoplus.adsl.tpnet.pl (chb63.neoplus.adsl.tpnet.pl [83.30.255.63]) by mx1.FreeBSD.org (Postfix) with SMTP id 760F043D53 for ; Fri, 23 Sep 2005 21:30:08 +0000 (GMT) (envelope-from Blackstone@licht-labs.com) Received: from 106.192.134.115 (EHLO repackage) by chb63.neoplus.adsl.tpnet.pl with SMTP; Fri, 23 Sep 2005 23:30:06 +0200 id 1989829755amortize72270 for freebsd-isp@freebsd.org; Fri, 23 Sep 2005 23:30:06 +0200 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <10586678034.12662414652@chb63.neoplus.adsl.tpnet.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-isp@freebsd.org From: Christie Date: Fri, 23 Sep 2005 23:30:05 +0200 X-Mailer: Apple Mail (2.728) Subject: No need to pay more - cheapest OEM online. X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 21:30:14 -0000 All the Software You'll Ever Need To Successfully Make Money Online! http://rcazfm.429msbsssnsum44zrm4hrm4m.restesibmb.com/?dgj Unjust dominion cannot be eternal. The more things change the more they remain the same. Most of the basic truths of life sound absurd at first hearing. Language is the picture and counterpart of thought. What power has law where only money rules. Shoot, coward, you are only going to kill a man. From owner-freebsd-isp@FreeBSD.ORG Sat Sep 24 14:06:54 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F15816A41F; Sat, 24 Sep 2005 14:06:54 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B01343D48; Sat, 24 Sep 2005 14:06:54 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id F10CF1F15; Sat, 24 Sep 2005 10:07:14 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-66.access.uk.tiscali.com [212.74.113.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 822D5A0; Sat, 24 Sep 2005 10:07:13 -0400 (EDT) Received: from brian by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1EJAjR-0000MJ-DY; Sat, 24 Sep 2005 15:10:25 +0100 Date: Sat, 24 Sep 2005 15:10:25 +0100 From: Brian Candler To: freebsd-cluster@freebsd.org, freebsd-isp@freebsd.org Message-ID: <20050924141025.GA1236@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 14:06:54 -0000 Hello, I was wondering if anyone would care to share their experiences in synchronising filesystems across a number of nodes in a cluster. I can think of a number of options, but before changing what I'm doing at the moment I'd like to see if anyone has good experiences with any of the others. The application: a clustered webserver. The users' CGIs run in a chroot environment, and these clearly need to be identical (otherwise a CGI running on one box would behave differently when running on a different box). Ultimately I'd like to synchronise the host OS on each server too. Note that this is a single-master, multiple-slave type of filesystem synchronisation I'm interested in. 1. Keep a master image on an admin box, and rsync it out to the frontends ------------------------------------------------------------------------- This is what I'm doing at the moment. Install a master image in /webroot/cgi, add packages there (chroot /webroot/cgi pkg_add ...), and rsync it. [Actually I'm exporting it using NFS, and the frontends run rsync locally when required to update their local copies against the NFS master] Disadvantages: - rsyncing a couple of gigs of data is not particularly fast, even when only a few files have changed - if a sysadmin (wrongly) changes a file on a front-end instead of on the master copy in the admin box, then the change will be lost when the next rsync occurs. They might think they've fixed a problem, and then (say) 24 hours later their change is wiped. However if this is a config file, the fact that the old file has been reinstated might not be noticed until the daemon is restarted or the box rebooted - maybe months later. This I think is the biggest fundamental problem. - files can be added locally and they will remain indefinitely (unless we use rsync --delete which is a bit scary). If this is done then adding a new machine into the cluster by rsyncing from the master will not pick up these extra files. So, here are the alternatives I'm considering, and I'd welcome any additional suggestions too. 2. Run the images directly off NFS ---------------------------------- I've had this running before, even the entire O/S, and it works just fine. However the NFS server itself then becomes a critical single-point-of-failure: if it has to be rebooted and is out of service for 2 minutes, then the whole cluster is out of service for that time. I think this is only feasible if I can build a highly-available NFS server, which really means a pair of boxes serving the same data. Since the system image is read-only from the point of view of the frontends, this should be easy enough: frontends frontends | | | | | | NFS -----------> NFS server 1 sync server 2 As far as I know, NFS clients don't support the idea of failing over from one server to another, so I'd have to make a server pair which transparently fails over. I could make one NFS server take over the other server's IP address using carp or vrrp. However, I suspect that the clients might notice. I know that NFS is 'stateless' in the sense that a server can be rebooted, but for a client to be redirected from one server to the other, I expect that these filesytems would have to be *identical*, down to the level of the inode numbers being the same. If that's true, then rsync between the two NFS servers won't cut it. I was thinking of perhaps using geom_mirror plus ggated/ggatec to make a block-identical read-only mirror image on NFS server 2 - this also has the advantage that any updates are close to instantaneous. What worries me here is how NFS server 2, which has the mirrored filesystem mounted read-only, will take to having the data changed under its nose. Does it for example keep caches of inodes in memory, and what would happen if those inodes on disk were to change? I guess I can always just unmount and remount the filesystem on NFS server 2 after each change. My other concern is about susceptibility to DoS-type attacks: if one frontend were to go haywire and start hammering the NFS servers really hard, it could impact on all the other machines in the cluster. However, the problems of data synchronisation are solved: any change made on the NFS server is visible identically to all front-ends, and sysadmins can't make changes on the front-ends because the NFS export is read-only. 3. Use a network distributed filesystem - CODA? AFS? ---------------------------------------------------- If each frontend were to access the filesystem as a read-only network mount, but have a local copy to work with in the case of disconnected operation, then the SPOF of an NFS server would be eliminated. However, I have no experience with CODA, and although it's been in the tree since 2002, the README's don't inspire confidence: "It is mostly working, but hasn't been run long enough to be sure all the bugs are sorted out. ... This code is not SMP ready" Also, a local cache is no good if the data you want during disconnected operation is not in the cache at that time, which I think means this idea is not actually a very good one. 4. Mount filesystems read-only ------------------------------ On each front-end I could store /webroot/cgi on a filesystem mounted read-only to prevent tampering (as long as the sysadmin doesn't remount it read-write of course). That would work reasonably well, except that being mounted read-only I couldn't use rsync to update it! It might also work with geom_mirror and ggated/ggatec, except for the issue I raised before about changing blocks on a filesystem under the nose of a client who is actively reading from it. 5. Using a filesystem which really is read-only ----------------------------------------------- Better tamper-protection could be had by keeping data in a filesystem structure which doesn't support any updates at all - such as cd9660 or geom_uzip. The issue here is how to roll out a new version of the data. I could push out a new filesystem image into a second partition, but it would then be necessary to unmount the old filesystem and remount the new on the same place, and you can't really unmount a filesystem which is in use. So this would require a reboot. I was thinking that some symlink trickery might help: /webroot/cgi -> /webroot/cgi1 /webroot/cgi1 # filesystem A mounted here /webroot/cgi2 # filesystem B mounted here It should be possible to unmount /webroot/cgi2, dd in a new image, remount it, and change the symlink to point to /webroot/cgi2. After a little while, hopefully all the applications will stop using files in /webroot/cgi1, so this one can be unmounted and a new one put in its place on the next update. However this is not guaranteed, especially if there are long-lived processes using binary images in this partition. You'd still have to stop and restart all those processes. If reboots were acceptable, then the filesystem image could also be stored in ramdisk pulled in via pxeboot. This makes sense especially for geom_uzip where the data is pre-compressed. However I would still prefer to avoid frequent reboots if at all possible. Also, whilst a ramdisk might be OK for the root filesystem, a typical CGI environment (with perl, php, ruby, python, and loads of libraries) would probably be too large anyway. 6. Journaling filesystem replication ------------------------------------ If the data were stored on a journaling filesystem on the master box, and the journal logs were distributed out to the slaves, then they would all have identical filesystem copies and only a minimal amount of data would need to be pushed out to each machine on each change. (This would be rather like NetApps and their snap-mirroring system). However I'm not aware of any journaling filesystem for FreeBSD, let alone whether it would support filesystem replication in this way. Well, that's what I've come up with so far. I'd be very interested to hear if people have any other strategies or suggestions, particularly with practical experience in a clustered/ISP environment. Regards, Brian Candler.