From netramet-owner Wed Jun 3 17:28:46 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id RAA13249 for netramet-outgoing; Wed, 3 Jun 1998 17:16:32 +1200 (NZST) Received: from mail.iconz.co.nz (mail.iconz.co.nz [202.14.100.36]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id RAA13186 for ; Wed, 3 Jun 1998 17:16:18 +1200 (NZST) Received: from andreas (e0.firewall.ak.iconz.net.nz [202.14.100.208]) by mail.iconz.co.nz (8.8.7/8.8.7) with SMTP id RAA134520896850974 for ; Wed, 3 Jun 1998 17:16:14 +1200 (NZST) From: "Andreas Hamberger" To: Subject: Result of comparison between Netramet an CISCO Accounting Date: Wed, 3 Jun 1998 17:18:24 +1200 Message-ID: <05c101bd8eaf$085ac7b0$2164a8c0@andreas.iconz.co.nz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05C2_01BD8F13.9D8FA7B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal X-MS-TNEF-Correlator: 00000000194A5C231AE6D1118D8F0080ADA7042804382600 Sender: netramet-owner@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_05C2_01BD8F13.9D8FA7B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HI guys We testet netramet in parallel with our current system (cisco - accounting) for about three weeks, the comparison brings up a couple of questions we might want to have answered: 1.) Mailserver (as server example): CISCO: 15849570221 bytes NETRAMET: 14341212888 bytes 2.) normal dial in user - my account) CISCO: 54124344 bytes NETRAMET: 47840816 bytes 3.) Office NAT CISCO: 1292607035 bytes NETRAMET: 556963968 bytes Netramet and Nemac are running on the same machine, a pentium 166 with 64 Mb of RAM, running Debian Linux (newest stable Kernel), 6GB of HD, CNET PCI eth-card (not the best one :( What astonishes me is the inconcistency between three different types of systems ( mailserver 1 IP, NAT 1 IP, dialin 1 IP) the NAT has the biggest difference!!! There are the following explanations from my point of few: 1.) The cisco is metering something we don't know of (scary!) 2.) the ethernet card in the NM machine is really bad 3.) too many packets (average is under 1000 per second though) 4.) some other problem. Has anybody else done some comparisons between systems? Does anybody have an idea where these inconcistent differences could come from? Any help is appreciated Andreas P. Hamberger, MA System Administrator ############################################ ICONZ - The Internet Company of New Zealand http://www.iconz.co.nz +64-9-3581186 ############################################ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.5.3i for non-commercial use iQA/AwUBNXQz4BM6nlSIRXjREQKZQQCgqEl9xny9nH/9Tzg16MlIquPU5tMAn2qB G1AxhVfZBaz5SXauUdWrfKJx =ptlJ -----END PGP SIGNATURE----- ------=_NextPart_000_05C2_01BD8F13.9D8FA7B0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhgFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM4HBgADABEAEgAAAAMABAEB A5AGALQKAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAOgAAAFJlc3VsdCBvZiBjb21wYXJpc29uIGJldHdlZW4gTmV0cmFtZXQgYW4gQ0lTQ08gQWNj b3VudGluZwAAAAIBcQABAAAAFgAAAAG9jq8DvVbSMTn47xHRjZwAgK2nBCgAAAIBHQwBAAAAFwAA AFNNVFA6WU9QRVJASUNPTlouQ08uTloAAAsAAQ4AAAAAQAAGDgB0pPmujr0BAgEKDgEAAAAYAAAA AAAAABlKXCMa5tERjY8AgK2nBCjCgAAACwAfDgEAAAADAAYQiZDAFwMABxCJBQAAHgAIEAEAAABl AAAALS0tLS1CRUdJTlBHUFNJR05FRE1FU1NBR0UtLS0tLUhBU0g6U0hBMUhJR1VZU1dFVEVTVEVU TkVUUkFNRVRJTlBBUkFMTEVMV0lUSE9VUkNVUlJFTlRTWVNURU0oQ0lTQ08tQQAAAAACAQkQAQAA APwFAAD4BQAAMQkAAExaRnV/YKbCAwAKAHJjcGcxMjVGMgD4C2BuZzUOIDlPAfcCpAPjAgBjaArA c/BldDAgBxMCgwBQBFa/CFUHsgKDDlAD1RF4MxBfbRFmfQqACMg7CW8OMDXPF18KYAKACoF1YwBQ CwPodWxuAiBlC6YWkgsKExTiAdAgLR0CQkVHQElOIFBHUAYASRBHTkVEBdBFU1NIQUdFHQNcbAuA ZUAgSGFzaDoGAEgGQRpDFoFISSBndV55FVAKsQqECoBXH2B0jweQIfAFQBrwdHJhB4CbBUALgCAK sQdAbGUDIJED8HRoIAhhIGMIcDMYwAIwIHMg4CHwbSDcKGMEAAWgHPAgANAFoMZ1AjALgGcpIAIQ BcB/AaAIYAVAI9AJ0SOgCeBr3HMsJxEfYAWgbQqxBAA5AiAgYgUQDyAEIHVwHyWwKCEpUCNwI/Bm IHE7ClAiEGkCIAQgJ4AgbehpZ2gFQHcAcCcBJYC9EPB2H2AAcSeAGME6IQqpIQQxLiZgTQtwbBEg dnIsEAXAKB+QJLAuhGUWeCKgKdEpLMtDSVMMQ08fwAyCIDE1OAA0OTU3MDIyMR0o0Hkh8SEEHiBU UkHFHmBUMTY0MzQOIA4gbjg0gDJaIQQyLgEa0HLbAMADIGQHMSLidS5xJZH0bXkltikwLyzADJMx cXY1NDE0ETQyXzNiMVM0QjcxwDA4MTY0vwo6My4BTwEgDeAfYE5BjlQ4Lzk4D1EyNjAyABwzNTpf O2cYgDY5Nr4zQpA0rzLxInYAcGQHsecAwSWwGMAgciYAAwAPIHcj8AOgJ/JzIqErAADQaJcfQSfQ KYBwJIFpdSUQ1zxQPGAjszY6QE0xgCoRxzNBJ9BFhkRlYgcwA6DyTAuAdXglIBrwJ4AiELcksAGR KeFLBJEjgCkn0Eg2R0IqAkhEJ9BDnzMRHaAw4C+AI9AtYwsRbUqhbycCH2BiSvIa4SD8OighZRDw RIEiEAIgBAD/KAAEIEaRBAAn4wuABaBRUN8EACHwUVA3gE6QdCeBRhLfJ0I2gAEgLIErknlHcAQg dyoRJMQEIChGsS5XMkBJ/lAn0D5BVXU2giLxVYImYJ8n8lXiEPBQ5EoAZ2dK8ttTBj4QIVlwIQRU KABFUe9FQifyAhAjYG8D8EXRL5A9C1FuT8AqkwNSN2Jwb+8LgE7BKiBTMHcsyy3yWgH/JDAlU1DR IrEGcUXRKKAisVdG8UXgKuFkAiAnBUBrNxrQB+AqESgE8ArAeSH/OBU10ifyTXFLsgVATbMi8X1X U01GtlDCGMAjUVIBYX8LMT1WK8AlgAOBXLEA0Gv/ETBUkSwBIpBYgFDCJgAEgf0xkDBowEdhBcAR IFFhRMDvI9AIYCswOBU0LgFgAiPwz2MiIxADYEthbS4hCh+B9SwxeQbgZDeAI4ARIGDCv0ZRatIo OAQgUiZUNT8K4/kKgERvB5Fs9iv1IuABAP0pgHdaEyfxbZFRSVi6BCC9JeFsRMAoMVrBA2E/IQo2 QWbhKABsKWBQ0WFw/2twBZAHMCHwZdUhCAswAEDPEWBEsGVBBCBQLh9xBtDLBJBYgHIn0E1BIQoG sHkk40FkKxBQMSKBK8ByvSEKI31Pfl9+9yEESTEQ7E5aJZFeokkCMGNECFDvKFFm4SoRB8JaZVFE oSEFHmMAQRqwIQQrQHRwOmgvL3eEsC4N4AIgevouBaAuhSCDcQ5QGrUhGWIrSIAtOS1AoDxAMfw4 NjlGiCt8/4o/fx6DgP8C0Q5QeCoBQCETeFYcLx0+6T5QVVIeylYEkACQAiA/H8AdsQNQCeArcEVR NS75ktAzaSZzGtFNoANwB4DOcndRAyA3ASA8hEkOAGRwaYVBbT4fIx8kaQBRQS9Bd1VCTgBYUXo0 Qk02biJsHfBSWGqQsFFLAFpRUUNncUVsBDl4ZuA5bkgvOYRUeg4QNk1sSSpAEFBVNXR6YG4ycQJC HyRHMUF4aFYAZlpCYXo1U1gAYXVVZFdyZkuUSngfIz0FMGxKHyR5j1NFTh5AkA8fFCEEfQGgAAMA EBAAAAAAAwAREAAAAAADAAB8BQAAAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAA 8BMAAB4ACIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQALAAyACCAGAAAAAADA AAAAAAAARgAAAAAGhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAWgAgg BgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAA AAMAGYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYAAAAA NoUAAAEAAAABAAAAAAAAAB4AKYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAe ACqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAygAggBgAAAAAAwAAAAAAA AEYAAAAAgoUAAAEAAAALADSACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsANoALIAYAAAAA AMAAAAAAAABGAAAAAAWIAAAAAAAAAgH4DwEAAAAQAAAAGUpcIxrm0RGNjwCAracEKAIB+g8BAAAA EAAAABlKXCMa5tERjY8AgK2nBCgCAfsPAQAAAH8AAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNU UFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xhbmR5XEFw cGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAMA/g8FAAAAAwAN NP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDE5NEE1QzIzMUFFNkQxMTE4RDhGMDA4MEFEQTcwNDI4 MDQzODI2MDAAAAAA8as= ------=_NextPart_000_05C2_01BD8F13.9D8FA7B0-- From netramet-owner Wed Jun 3 23:07:41 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id XAA06372 for netramet-outgoing; Wed, 3 Jun 1998 23:04:59 +1200 (NZST) Received: from beech.sucs.soton.ac.uk (beech.sucs.soton.ac.uk [152.78.129.138]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id XAA06363 for ; Wed, 3 Jun 1998 23:04:54 +1200 (NZST) Received: from cedar.sucs.soton.ac.uk (cedar.sucs.soton.ac.uk [152.78.128.92]) by beech.sucs.soton.ac.uk (8.8.8/relay-02) with ESMTP id MAA18597 for ; Wed, 3 Jun 1998 12:04:51 +0100 (BST) Received: from pogles.staff.sucs.soton.ac.uk (pogles.staff.sucs.soton.ac.uk [152.78.132.57]) by cedar.sucs.soton.ac.uk (8.8.8/relay-02) with SMTP id MAA00335 for ; Wed, 3 Jun 1998 12:02:58 +0100 (BST) From: Simon Lane Reply-To: S.J.Lane@soton.ac.uk To: netramet@auckland.ac.nz Subject: Suitable platform for NeTraMet on FDDI? Message-ID: Date: Wed, 3 Jun 1998 12:02:57 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="Part9806031256.C" Sender: netramet-owner@auckland.ac.nz Precedence: bulk --Part9806031256.C Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, I have been experimenting with NeTraMet to monitor an FDDI ring. The platform I am using is a Silicon Graphics R4000 (several years old now but still very usable). I want a high level of detail at the moment, so there are up to 19,000 flows active with a 15 minute collection interval. NeTraMet is reporting high packet loss (LSP counter) in its 'Stats' records whenever the Max Packet Rate (MPS counter) goes over about 1300 packets per second (a sample of the Stats records is attached). Unless someone can tell otherwise, I am inclined to believe that packets are most likely being lost at the FDDI interface - since the card in use is a first generation card from SG. Consequently, I am looking for suggestions as to a more suitable platform (processor, interface, OS) for monitoring this FDDI. If you run NeTraMet to monitor an FDDI, I would appreciate brief details. I will summarise replies to the list as I'm sure this information will be useful to others. Thank you Simon Lane, Computing Services, University of Southampton. --Part9806031256.C Content-Type: TEXT/Plain; name="t40.tmp" #Stats: aps=768 apb=0 mps=1609 mpb=0 lsp=0 avi=68.8 mni=26.8 fiu=42 frc=12732 gci=2 rpp=8.6 tpp=1.0 cpt=7.9 tts=24576 tsu=64981 #Stats: aps=929 apb=0 mps=2268 mpb=0 lsp=17556 avi=65.4 mni=28.6 fiu=3699 frc=0 gci=2 rpp=9.1 tpp=1.0 cpt=3.6 tts=24576 tsu=65725 #Stats: aps=1308 apb=0 mps=2310 mpb=0 lsp=31663 avi=53.1 mni=26.2 fiu=8415 frc=0 gci=2 rpp=9.3 tpp=1.0 cpt=6.7 tts=24576 tsu=65845 #Stats: aps=956 apb=0 mps=2089 mpb=0 lsp=209 avi=62.4 mni=38.7 fiu=11094 frc=2443 gci=2 rpp=8.6 tpp=1.0 cpt=7.7 tts=24576 tsu=65938 #Stats: aps=1085 apb=0 mps=2035 mpb=0 lsp=1922 avi=57.9 mni=30.2 fiu=12492 frc=4183 gci=2 rpp=8.8 tpp=1.1 cpt=10.9 tts=24576 tsu=66011 #Stats: aps=1084 apb=0 mps=1846 mpb=0 lsp=1190 avi=57.7 mni=16.0 fiu=14464 frc=4923 gci=2 rpp=8.7 tpp=1.0 cpt=10.9 tts=24576 tsu=66109 #Stats: aps=1131 apb=0 mps=2003 mpb=0 lsp=0 avi=55.8 mni=28.5 fiu=15430 frc=5400 gci=2 rpp=8.7 tpp=1.0 cpt=11.8 tts=24576 tsu=66194 #Stats: aps=1110 apb=0 mps=2042 mpb=0 lsp=584 avi=56.9 mni=30.6 fiu=14616 frc=6710 gci=2 rpp=8.7 tpp=1.0 cpt=10.5 tts=24576 tsu=66307 #Stats: aps=1198 apb=0 mps=2016 mpb=0 lsp=362 avi=54.0 mni=22.9 fiu=14402 frc=6170 gci=2 rpp=8.9 tpp=1.0 cpt=10.8 tts=24576 tsu=66394 #Stats: aps=1235 apb=0 mps=2281 mpb=0 lsp=2294 avi=52.9 mni=28.6 fiu=14100 frc=5952 gci=2 rpp=8.7 tpp=1.0 cpt=10.5 tts=24576 tsu=66472 #Stats: aps=1287 apb=0 mps=2269 mpb=0 lsp=923 avi=50.1 mni=29.0 fiu=18949 frc=5948 gci=2 rpp=8.6 tpp=1.1 cpt=15.1 tts=24576 tsu=66542 #Stats: aps=1382 apb=0 mps=2804 mpb=0 lsp=7886 avi=45.8 mni=24.8 fiu=19329 frc=5741 gci=2 rpp=8.8 tpp=1.1 cpt=20.5 tts=24576 tsu=66595 #Stats: aps=1123 apb=0 mps=2633 mpb=0 lsp=380 avi=56.2 mni=30.0 fiu=12982 frc=10905 gci=2 rpp=8.8 tpp=1.1 cpt=11.6 tts=24576 tsu=66704 #Stats: aps=1050 apb=0 mps=2378 mpb=0 lsp=1060 avi=59.1 mni=28.6 fiu=11887 frc=6556 gci=2 rpp=8.7 tpp=1.0 cpt=9.5 tts=24576 tsu=66820 #Stats: aps=1028 apb=0 mps=1929 mpb=0 lsp=437 avi=59.8 mni=35.1 fiu=13792 frc=4454 gci=2 rpp=8.7 tpp=1.0 cpt=9.2 tts=24576 tsu=66952 #Stats: aps=1075 apb=0 mps=1819 mpb=0 lsp=404 avi=57.9 mni=26.9 fiu=14585 frc=5037 gci=2 rpp=8.5 tpp=1.1 cpt=9.3 tts=24576 tsu=67012 #Stats: aps=1102 apb=0 mps=1852 mpb=0 lsp=559 avi=57.1 mni=25.0 fiu=15280 frc=6327 gci=2 rpp=8.5 tpp=1.1 cpt=9.8 tts=24576 tsu=67155 #Stats: aps=1194 apb=0 mps=2062 mpb=0 lsp=7815 avi=53.8 mni=31.4 fiu=17495 frc=5704 gci=2 rpp=8.6 tpp=1.1 cpt=11.2 tts=24576 tsu=67245 #Stats: aps=1181 apb=0 mps=1840 mpb=0 lsp=0 avi=53.7 mni=33.0 fiu=17014 frc=6680 gci=2 rpp=8.7 tpp=1.0 cpt=13.4 tts=24576 tsu=67308 #Stats: aps=1207 apb=0 mps=2040 mpb=0 lsp=627 avi=53.5 mni=26.0 fiu=15369 frc=7805 gci=2 rpp=8.7 tpp=1.0 cpt=11.8 tts=24576 tsu=67365 #Stats: aps=1105 apb=0 mps=2258 mpb=0 lsp=454 avi=57.0 mni=25.8 fiu=14912 frc=6276 gci=2 rpp=8.7 tpp=1.0 cpt=11.3 tts=24576 tsu=67438 #Stats: aps=1023 apb=0 mps=1858 mpb=0 lsp=474 avi=59.7 mni=33.0 fiu=14503 frc=6259 gci=2 rpp=8.7 tpp=1.0 cpt=10.7 tts=24576 tsu=67544 #Stats: aps=1208 apb=0 mps=2205 mpb=0 lsp=1619 avi=53.5 mni=29.1 fiu=13976 frc=6129 gci=2 rpp=8.6 tpp=1.0 cpt=12.5 tts=24576 tsu=67617 #Stats: aps=1169 apb=0 mps=1861 mpb=0 lsp=395 avi=54.8 mni=26.0 fiu=13962 frc=5868 gci=2 rpp=8.6 tpp=1.1 cpt=10.9 tts=24576 tsu=67721 #Stats: aps=1213 apb=0 mps=2083 mpb=0 lsp=641 avi=53.7 mni=28.3 fiu=14513 frc=5555 gci=2 rpp=8.8 tpp=1.0 cpt=10.5 tts=24576 tsu=67829 #Stats: aps=1121 apb=0 mps=2171 mpb=0 lsp=3885 avi=56.2 mni=20.0 fiu=14980 frc=5793 gci=2 rpp=8.8 tpp=1.0 cpt=11.2 tts=24576 tsu=67972 #Stats: aps=1048 apb=0 mps=2384 mpb=0 lsp=0 avi=58.7 mni=36.0 fiu=14802 frc=6025 gci=2 rpp=8.7 tpp=1.0 cpt=10.3 tts=24576 tsu=68054 #Stats: aps=1132 apb=0 mps=2089 mpb=0 lsp=3054 avi=56.1 mni=30.7 fiu=15102 frc=6180 gci=2 rpp=8.8 tpp=1.0 cpt=11.2 tts=24576 tsu=68167 --Part9806031256.C-- From netramet-owner Thu Jun 4 09:21:17 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id JAA09772 for netramet-outgoing; Thu, 4 Jun 1998 09:16:18 +1200 (NZST) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id JAA09759; Thu, 4 Jun 1998 09:16:12 +1200 (NZST) From: Nevil Brownlee To: Andreas Hamberger Cc: netramet@auckland.ac.nz Subject: Result of comparison between Netramet an CISCO Accounting In-Reply-To: <05c101bd8eaf$085ac7b0$2164a8c0@andreas.iconz.co.nz> Message-ID: Date: Thu, 4 Jun 1998 09:18:39 +1200 (New Zealand Standard Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: netramet-owner@auckland.ac.nz Precedence: bulk Hello Andreas: > We testet netramet in parallel with our current system (cisco - > accounting) for about three weeks, the comparison brings up a couple > of questions we might want to have answered: > 1.) Mailserver (as server example): > CISCO: 15849570221 bytes > NETRAMET: 14341212888 bytes > 2.) normal dial in user - my account) > CISCO: 54124344 bytes > NETRAMET: 47840816 bytes > 3.) Office NAT > CISCO: 1292607035 bytes > NETRAMET: 556963968 bytes > > There are the following explanations from my point of few: > > 1.) The cisco is metering something we don't know of (scary!) > 2.) the ethernet card in the NM machine is really bad > 3.) too many packets (average is under 1000 per second though) > 4.) some other problem. > > Has anybody else done some comparisons between systems? > Does anybody have an idea where these inconcistent differences could come > from? Your first two samples indicate that you weren't using the -l command-line option for NeTraMet. Without that NeTraMet counts the total number of bytes in all the Ethernet packets, including their Ethernet headers (14 bytes per IP packet, more for 802.3 packets). Using the -l option tells NeTraMet to use the packet length from the IP header, which is what Cisco Accounting does. (Of course this only works for IP - counting total bytes works for all the other protocols). Your third example suggests that the packets are coming in along the metered Ethernet to the router, being routed back out along the same piece of Ethernet and hence being counted twice. An instance of this was reported on this mailing list a month or two ago. Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From netramet-owner Thu Jun 4 10:50:36 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id KAA24941 for netramet-outgoing; Thu, 4 Jun 1998 10:48:07 +1200 (NZST) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id KAA24935 for ; Thu, 4 Jun 1998 10:48:04 +1200 (NZST) Received: from clear.co.nz (maggie.clear.co.nz [10.1.12.14]) by fep1-orange.clear.net.nz (1.5/1.9) with ESMTP id KAA18356; Thu, 4 Jun 1998 10:47:28 +1200 (NZST) Received: from falcon.clear.co.nz (falcon.mars.clear.co.nz [172.30.55.50]) by clear.co.nz (8.8.5/8.8.5) with ESMTP id KAA15605 for ; Thu, 4 Jun 1998 10:47:31 +1200 (NZST) Received: by falcon.mars.clear.co.nz with Internet Mail Service (5.5.1960.3) id ; Thu, 4 Jun 1998 10:45:17 +1200 Message-ID: From: Michael Clark To: "'Andreas Hamberger'" Cc: "'netramet@auckland.ac.nz'" Subject: RE: Result of comparison between Netramet an CISCO Accounting Date: Thu, 4 Jun 1998 10:36:12 +1200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: netramet-owner@auckland.ac.nz Precedence: bulk Andreas, I have experienced under counting using the DOS meter after moving from the 16-bit version 3.4 to the 32-bit version 4.0. We were using ISA bus 3c509s with the 3.4 DOS meter and after installing the 32-bit 4.0 DOS meter with the same hardware we found we were under counting by about 10% although LSP was measuring 0 lost packets. We finally solved the problem by changing our NIC to a PCI Accton 1207-TX. Your best bet is to set up a rule-set to monitor a single address and do some ping tests from it. We did a few tests and saw the packets being missed. We got them all after changing cards. 'Cos you're running NeMaC on the same box I'd also do these test while NeMaC is collecting and writing to the flow file. You may want to try the DOS meter as this has a lot less overhead than the UNIX meter, although you'll need another box to run NeMaC on. Michael. -- Michael Clark, Internet Product Developer, mailto:mclark@clear.co.nz CLEAR Net - a division of CLEAR Communications Ltd. Auckland, New Zealand. phone +64-9-912 4928 fax +64-9-912 5008 -----Original Message----- From: Andreas Hamberger [SMTP:yoper@iconz.co.nz] Sent: Wednesday, June 03, 1998 5:18 PM To: netramet@auckland.ac.nz Subject: Result of comparison between Netramet an CISCO Accounting -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HI guys We testet netramet in parallel with our current system (cisco - accounting) for about three weeks, the comparison brings up a couple of questions we might want to have answered: 1.) Mailserver (as server example): CISCO: 15849570221 bytes NETRAMET: 14341212888 bytes 2.) normal dial in user - my account) CISCO: 54124344 bytes NETRAMET: 47840816 bytes 3.) Office NAT CISCO: 1292607035 bytes NETRAMET: 556963968 bytes Netramet and Nemac are running on the same machine, a pentium 166 with 64 Mb of RAM, running Debian Linux (newest stable Kernel), 6GB of HD, CNET PCI eth-card (not the best one :( What astonishes me is the inconcistency between three different types of systems ( mailserver 1 IP, NAT 1 IP, dialin 1 IP) the NAT has the biggest difference!!! There are the following explanations from my point of few: 1.) The cisco is metering something we don't know of (scary!) 2.) the ethernet card in the NM machine is really bad 3.) too many packets (average is under 1000 per second though) 4.) some other problem. Has anybody else done some comparisons between systems? Does anybody have an idea where these inconcistent differences could come from? Any help is appreciated Andreas P. Hamberger, MA System Administrator ############################################ ICONZ - The Internet Company of New Zealand http://www.iconz.co.nz +64-9-3581186 ############################################ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.5.3i for non-commercial use iQA/AwUBNXQz4BM6nlSIRXjREQKZQQCgqEl9xny9nH/9Tzg16MlIquPU5tMAn2qB G1AxhVfZBaz5SXauUdWrfKJx =ptlJ -----END PGP SIGNATURE----- From netramet-owner Thu Jun 4 11:09:57 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id LAA27868 for netramet-outgoing; Thu, 4 Jun 1998 11:07:51 +1200 (NZST) Received: from mail.iconz.co.nz (mail.iconz.co.nz [202.14.100.36]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id LAA27852; Thu, 4 Jun 1998 11:07:46 +1200 (NZST) Received: from rbs (e0.firewall.ak.iconz.net.nz [202.14.100.208]) by mail.iconz.co.nz (8.8.7/8.8.7) with SMTP id LAA245730896915265; Thu, 4 Jun 1998 11:07:45 +1200 (NZST) From: "Rowan Smith" To: "Nevil Brownlee" , Subject: Re: Result of comparison between Netramet an CISCO Accounting Date: Thu, 4 Jun 1998 11:08:40 +1200 Message-ID: <01bd8f44$8bc73bc0$0b64a8c0@rbs.iconz> 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 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: netramet-owner@auckland.ac.nz Precedence: bulk Hi Nevil, Andreas isn't here right now so... >Your first two samples indicate that you weren't using the -l >command-line option for NeTraMet. Without that NeTraMet counts the >total number of bytes in all the Ethernet packets, including their >Ethernet headers (14 bytes per IP packet, more for 802.3 packets). We are running the software with the -l option. When we ommited the -l option (back in original testing with 3.5) our totals from Netramet were significantly _higher_ than those from the Ciscos. In these comparisons Netramet is always lower than Cisco. If the -l option was omitted I would expect the Netramet totals to be higher. These totals were generated from the same Netramet flow file, and Netramet was never restarted during the period which that flow file represents (2.5 weeks), nor was the ruleset ever altered. >Your third example suggests that the packets are coming in along the >metered Ethernet to the router, being routed back out along the same >piece of Ethernet and hence being counted twice. An instance of this >was reported on this mailing list a month or two ago. Our network configuration is as follows: We have a Cisco 3100 Switch at the core of the ethernet. Off port 24 we connect a HUB To this HUB we connect our gateway router (Cisco 3640) To this HUB we also connect Netramet. The 3640 above connects to another 3640 at the NZIX via a E1 circuit. Both 3640s are configured to capture ip accounting on their serial interfaces. Cisco IP accounting only captures packets which are leaving a interface. We then down load these statistics every 15 minutes performing an appropriate Clear IP accounting checkpoint sh ip accounting checkpoint As far as the ethernet segment is concerned, Andreas was unaware and so was I till now, that the NAT is bouncing packets off the gateway router and back into our Network for IPs that are local. However: These packets would not be accounted for by the Cisco IP Accounting (as they never leave the accounted interface). This double up of packets would cause Netramet to record much _higher_ statistics than the Cisco Accounting. Beacuse the packets would be going past Netramet twice, and never entering the Cisco IP Accounting tables. In all our cases Netramet is recording lower traffic stats. However the amount which Netramet varies on the three samples we tested is not constant. As can be seen in Andreas' originaly email. Unless someone can think of anything else? I feel our next best direction will be to change the Network card, and then possibly the hardware. If this fails as well, I will look into the feasibility of setting up a lab environment to throughly test it. -Rowan >> 1.) Mailserver (as server example): >> CISCO: 15849570221 bytes >> NETRAMET: 14341212888 bytes >> 2.) normal dial in user - my account) >> CISCO: 54124344 bytes >> NETRAMET: 47840816 bytes >> 3.) Office NAT >> CISCO: 1292607035 bytes >> NETRAMET: 556963968 bytes From netramet-owner Thu Jun 4 11:37:48 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id LAA02109 for netramet-outgoing; Thu, 4 Jun 1998 11:36:22 +1200 (NZST) Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.16]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id LAA02083 for ; Thu, 4 Jun 1998 11:36:16 +1200 (NZST) Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id JAA29000; Thu, 4 Jun 1998 09:35:41 +1000 (EST) Received: from mail-gw.fwall.telstra.com.au(192.148.147.16) via SMTP by mail.telstra.com.au, id smtpd028585; Thu Jun 4 09:34:30 1998 Received: (from uucp@localhost) by mail-gw.fwall.telstra.com.au (8.8.2/8.6.9) id JAA02646; Thu, 4 Jun 1998 09:34:25 +1000 (EST) Received: from cdn-mail.dn.itg.telecom.com.au(144.135.109.134) via SMTP by mail-gw.fwall.telstra.com.au, id smtpd002431; Thu Jun 4 09:33:48 1998 Received: from shiva.trl.OZ.AU (shiva.trl.oz.au [137.147.20.34]) by cdn-mail.dn.itg.telecom.com.au (8.8.2/8.6.9) with ESMTP id JAA03891; Thu, 4 Jun 1998 09:33:47 +1000 (EST) Received: (from kowalski@localhost) by shiva.trl.OZ.AU (8.8.8/8.6.12) id JAA15067; Thu, 4 Jun 1998 09:33:47 +1000 (EST) Date: Thu, 4 Jun 1998 09:33:47 +1000 (EST) From: Jacek Kowalski Message-Id: <199806032333.JAA15067@shiva.trl.OZ.AU> To: S.J.Lane@soton.ac.uk, netramet@auckland.ac.nz Subject: Re: Suitable platform for NeTraMet on FDDI? Sender: netramet-owner@auckland.ac.nz Precedence: bulk To: S.J.Lane@soton.ac.uk Subject: Re: Suitable platform for NeTraMet on FDDI? Simon, we tested Pentium II 300MHz with 128MB RAM, DEC DEFPA-DA FDDI card and ultra wide fast SCSI HD to run both NeTraMet and NeMaC on the same platform. The operating system was FreeBSD 2.2.2 with the BPF in the kernel. Depending on the rule file we could see well over an order of magnitude more flows than you did, at nearly 30K pps, with packet loss below 4%. However, in order to achieve this you would need to make some changes to the NeTraMet code which I described a few weeks ago. I've been in touch with Nevil who mentioned that the changes could be incorporated in the NeTraMet distribution files. Cheers, Jacek Kowalski PS. We also tried Linux but it's not as good as FreeBSD, most probably due to the BPF running in the user space. Also Brian Miller sent a posting about his extensive testing of Linux a few months ago. >Hi, >I have been experimenting with NeTraMet to monitor an FDDI ring. The >platform I am using is a Silicon Graphics R4000 (several years old now >but still very usable). >I want a high level of detail at the moment, so there are up to 19,000 >flows active with a 15 minute collection interval. >NeTraMet is reporting high packet loss (LSP counter) in its 'Stats' >records whenever the Max Packet Rate (MPS counter) goes over about 1300 >packets per second (a sample of the Stats records is attached). >Unless someone can tell otherwise, I am inclined to believe that >packets are most likely being lost at the FDDI interface - since the >card in use is a first generation card from SG. >Consequently, I am looking for suggestions as to a more suitable >platform (processor, interface, OS) for monitoring this FDDI. If you >run NeTraMet to monitor an FDDI, I would appreciate brief details. I >will summarise replies to the list as I'm sure this information will be >useful to others. >Thank you >Simon Lane, >Computing Services, >University of Southampton. From netramet-owner Thu Jun 4 11:37:51 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id LAA01963 for netramet-outgoing; Thu, 4 Jun 1998 11:35:33 +1200 (NZST) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id LAA01938; Thu, 4 Jun 1998 11:35:27 +1200 (NZST) From: Nevil Brownlee To: Rowan Smith Cc: netramet@auckland.ac.nz Subject: Re: Result of comparison between Netramet an CISCO Accounting In-Reply-To: <01bd8f44$8bc73bc0$0b64a8c0@rbs.iconz> Message-ID: Date: Thu, 4 Jun 1998 11:37:55 +1200 (New Zealand Standard Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: netramet-owner@auckland.ac.nz Precedence: bulk Hello Rowan: > We are running the software with the -l option. When we ommited the -l > option (back in original testing with 3.5) our totals from Netramet were > significantly _higher_ than those from the Ciscos. > > In these comparisons Netramet is always lower than Cisco. If the -l option > was omitted I would expect the Netramet totals to be higher. These totals > were generated from the same Netramet flow file, and Netramet was never > restarted during the period which that flow file represents (2.5 weeks), nor > was the ruleset ever altered. Oops, you're quite right, of course. > As far as the ethernet segment is concerned, Andreas was unaware and so was > I till now, that the NAT is bouncing packets off the gateway router and back > into our Network for IPs that are local. > > However: > These packets would not be accounted for by the Cisco IP Accounting > (as they never leave the accounted interface). > This double up of packets would cause Netramet to record much > _higher_ statistics than the Cisco Accounting. Beacuse the packets would be > going past Netramet twice, and never entering the Cisco IP Accounting > tables. > > In all our cases Netramet is recording lower traffic stats. However the > amount which Netramet varies on the three samples we tested is not constant. > As can be seen in Andreas' originaly email. AGain, you're right. I should have read Andreas' figures a bit more carefully! > Unless someone can think of anything else? I feel our next best direction > will be to change the Network card, and then possibly the hardware. If this > fails as well, I will look into the feasibility of setting up a lab > environment to throughly test it. > > -Rowan My current favoutite PCI card is the DEC DE500. We've been testing Debian linux with the latest experimental kernel (2.1.98) - performance of the meter (with the manager running on another machine) was astonishing, better than 8000 packets per second. Since then I've been working on the next release (4.2) - the latest beta is in the beta-versions directory of the ftp site, it includes a number of performance improvements. Our earlier experience with a linux meeting was much less promising, with the meter running out of steam at around 3000 pps. On the other hand, there are lots of sites running linux meters and managers .. Cheers, Nevil > >> 1.) Mailserver (as server example): > >> CISCO: 15849570221 bytes > >> NETRAMET: 14341212888 bytes > >> 2.) normal dial in user - my account) > >> CISCO: 54124344 bytes > >> NETRAMET: 47840816 bytes > >> 3.) Office NAT > >> CISCO: 1292607035 bytes > >> NETRAMET: 556963968 bytes > +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From netramet-owner Thu Jun 4 14:30:21 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id OAA26271 for netramet-outgoing; Thu, 4 Jun 1998 14:27:34 +1200 (NZST) Received: from mailhost.manawatu.gen.nz (postmaster@mailhost.manawatu.net.nz [202.36.148.91]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id OAA26245; Thu, 4 Jun 1998 14:27:25 +1200 (NZST) Received: from localhost (alanb@localhost) by mailhost.manawatu.gen.nz (8.8.8/8.8.7) with SMTP id OAA05083; Thu, 4 Jun 1998 14:27:16 +1200 Date: Thu, 4 Jun 1998 14:27:16 +1200 (NZST) From: Alan Brown X-Sender: alanb@mailhost.manawatu.net.nz To: Nevil Brownlee cc: netramet@auckland.ac.nz Subject: Re: Result of comparison between Netramet an CISCO Accounting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: netramet-owner@auckland.ac.nz Precedence: bulk On Thu, 4 Jun 1998, Nevil Brownlee wrote: > My current favoutite PCI card is the DEC DE500. The Dec "tulip" chipset in these is being incorporated into a wide range of PCI cards, including the Cnet 10/100 NIC. It's worth looking around, as the price range is as wide as the number of manufacturers using the chipset. AB From netramet-owner Thu Jun 4 16:15:46 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id QAA12449 for netramet-outgoing; Thu, 4 Jun 1998 16:11:41 +1200 (NZST) Received: from mail.iconz.co.nz (mail.iconz.co.nz [202.14.100.36]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id QAA12425; Thu, 4 Jun 1998 16:11:35 +1200 (NZST) Received: from rbs (e0.firewall.ak.iconz.net.nz [202.14.100.208]) by mail.iconz.co.nz (8.8.7/8.8.7) with SMTP id QAA063120896933492; Thu, 4 Jun 1998 16:11:32 +1200 (NZST) From: "Rowan Smith" To: "Alan Brown" , "Nevil Brownlee" Cc: Subject: Re: Result of comparison between Netramet an CISCO Accounting Date: Thu, 4 Jun 1998 16:12:31 +1200 Message-ID: <01bd8f6e$fec99440$0b64a8c0@rbs.iconz> 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 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: netramet-owner@auckland.ac.nz Precedence: bulk We are using the CNet 10/100 cards. I will let you know what the results are of the cards. I have had numerous other problems with the DEC chipset on the CNet cards. -Rowan -----Original Message----- From: Alan Brown To: Nevil Brownlee Cc: netramet@auckland.ac.nz Date: Thursday, June 04, 1998 3:22 PM Subject: Re: Result of comparison between Netramet an CISCO Accounting >On Thu, 4 Jun 1998, Nevil Brownlee wrote: > >> My current favoutite PCI card is the DEC DE500. > >The Dec "tulip" chipset in these is being incorporated into a wide >range of PCI cards, including the Cnet 10/100 NIC. > >It's worth looking around, as the price range is as wide as the >number of manufacturers using the chipset. > >AB > > > From netramet-owner Fri Jun 5 22:10:41 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id WAA28244 for netramet-outgoing; Fri, 5 Jun 1998 22:03:23 +1200 (NZST) Received: from themis.rus.uni-stuttgart.de (themis.rus.uni-stuttgart.de [129.69.1.2]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id WAA28237 for ; Fri, 5 Jun 1998 22:03:05 +1200 (NZST) Received: from kssun2.rus.uni-stuttgart.de (kssun2.rus.uni-stuttgart.de [129.69.30.63]) by themis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id MAA15103 for ; Fri, 5 Jun 1998 12:02:57 +0200 (MET DST) env-from (ingo@kssun2.rus.uni-stuttgart.de) Received: (from ingo@localhost) by kssun2.rus.uni-stuttgart.de (8.8.5/8.8.5) id LAA06853 for netramet@auckland.ac.nz; Fri, 5 Jun 1998 11:59:59 +0200 (MET DST) From: Ingo Seipp Message-Id: <199806050959.LAA06853@kssun2.rus.uni-stuttgart.de> Subject: flows not always exported? To: netramet@auckland.ac.nz Date: Fri, 5 Jun 1998 11:59:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netramet-owner@auckland.ac.nz Precedence: bulk Hello everybody, I was running Netramet4.1 on an OC3MON, a DOS Pentium PC with 166 MHz, 128 MB and two Fore PCA-200 PCI ATM interface cards, and on the local ethernet. >From a detailed look at the NeMaC output file I observed the following: a current flow is not always exported (i.e. does not show up in the output file). - the flow may show up again in the output file even after the flowtimeout parameter has expired. Thus, either the flowtimeout failed or the flow has been kept alive by traffic but was not exported. - it appears that sometimes the traffic is recorded (although the flow is not exported) and the accumulated Byte-counts get exported the next time the flow is written to the output file, but sometimes the traffic-data seems to be lost. - one flow f.ex. showed a "firsttime" much earlier than its first appearance in the output file. From the traffic-data in the output file it seems to have started just before its first output. Has the traffic-data between firsttime and the first output been lost here? Was there a previous discussion about things like that? Has anybody made similar observations? Is the hardware too slow for the Netramet4.1 version as pointed out in another discussion? >From your experience, is there a minimum time at which NeMaC should read from NeTraMet to ensure proper flow-export? Thanks for any comments, Ingo --------------------------------------------------------------- Ingo Seipp Rechenzentrum Universitaet Stuttgart Allmandring 30 70550 Stuttgart Tel: +49/0 711 6855988 , e-mail: seipp@rus.uni-stuttgart.de --------------------------------------------------------------- From netramet-owner Fri Jun 19 03:04:13 1998 Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id CAA17598 for netramet-outgoing; Fri, 19 Jun 1998 02:57:39 +1200 (NZST) Received: from themis.rus.uni-stuttgart.de (themis.rus.uni-stuttgart.de [129.69.1.2]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id CAA17539 for ; Fri, 19 Jun 1998 02:56:52 +1200 (NZST) Received: from kssun2.rus.uni-stuttgart.de (kssun2.rus.uni-stuttgart.de [129.69.30.63]) by themis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id QAA26002 for ; Thu, 18 Jun 1998 16:56:32 +0200 (MET DST) env-from (ingo@kssun2.rus.uni-stuttgart.de) Received: (from ingo@localhost) by kssun2.rus.uni-stuttgart.de (8.8.5/8.8.5) id QAA01842 for netramet@auckland.ac.nz; Thu, 18 Jun 1998 16:53:39 +0200 (MET DST) From: Ingo Seipp Message-Id: <199806181453.QAA01842@kssun2.rus.uni-stuttgart.de> Subject: ntmoc3: no llc_snap To: netramet@auckland.ac.nz Date: Thu, 18 Jun 1998 16:53:37 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netramet-owner@auckland.ac.nz Precedence: bulk Hello, I just installed the newest oc3mon-netramet release. It states to run netramet v4.2b1. There are two options in meter_oc.c which I set to: LINK_HAS_LLC_SNAP false ASSUME_ETHERTYPE_IS_IP 1 since I try to listen to an oc3 line which runs with aal5mux ip. It seems to get the # of packets and the TCP port right, but the byte count is wrong. Does anybody know what to do? Thanks, Ingo --------------------------------------------------------------- Ingo Seipp Rechenzentrum Universitaet Stuttgart Allmandring 30 70550 Stuttgart Tel: +49/0 711 6855988 , e-mail: seipp@rus.uni-stuttgart.de ---------------------------------------------------------------