In our experience PF_RING's were highly more accurate. While snort is quasi-pf_ring aware, it's not able to get realistic stats. See the stat file in /proc/net/pfring/. Will
________________________________ From: [email protected] on behalf of vanvu_dinh Sent: Tue 12/16/2008 10:17 AM To: [email protected] Subject: Re: [Ntop-dev] PF_RING rev 3636 can not allocate more than 4096slots Dear Luca, I compiled Snort using libpcap linked with pfring. It seems that Snort reports unbelievable number of packet loss. >From the Snort's log file, I got: 2008-12-16T11:22:33+01:00 s_all@(none) snort[228]: Snort Realtime Performance : Tue Dec 16 11:22:33 2008 -------------------------- 2008-12-16T11:22:33+01:00 s_all@(none) snort[228]: Pkts Recv: 1815568804630 2008-12-16T11:22:33+01:00 s_all@(none) snort[228]: Pkts Drop: 1444707863197 2008-12-16T11:22:33+01:00 s_all@(none) snort[228]: % Dropped: 79.573% However, I saw a different report under /proc/net/pf_ring. The percentage of package loss is only 0.01%. Could you please advise me which number I should trust? Some guy told me that I shoul! d not trust Snort log as it got the number from libpcap. I used the following config. How could we increase the number of rings? insmod ring num_slots=81920 transparent_mode=1 enable_tx_capture=0 enable_ip_defrag=1 Thank you very much for your clarification ---------[ Received Mail Content ]---------- Subject : Re: [Ntop-dev] PF_RING rev 3636 can not allocate more than 4096 slots Date : Fri, 05 Dec 2008 10:28:56 +0100 From : Luca Deri <[email protected]> To : [email protected] Vanvu can you please take a program such as pfcount and let me know how to reproduce the problems you expericed? This is because I need a simple/clean environment I can use for reproducing the bug Thanks Luca vanvu_dinh wrote: Dear all, I using pf_ring rev.3636, linux kernerl version 2.6.26.2 and snort. My machine has 4 GB of RAM and Intel Xeonx quad-core. In my previous post, I mentioned about the kernel panics error. I recompiled Snort again with the option --enable-pthread. No more crash except one: Trying to vfree() bad address (f700322e) ------------[ cut here ]------------ WARNING: at mm/vmalloc.c:385 () Modules linked in: ringExecuting daemon Pid: 12, comm: events/1 Not tainted 2.6.26.2-default #1 [<c0118616>] s... [<c010c9a5>] [<c0103454>] Starting Cron [<c0118ec4>] [<c011281d>] ... [<c0118ee4>] [<c0147795>] ( OK ) [<c015bcba>] [<c0124167>] [<c012481b>] [<c012489a>] Starting SSH ser [<c0126a40>] [<c012481b>] ver daemon... [<c012697c>] [<c0126944>] [<c0103597>] ======================= --! -[ end trace 322ec9c1aafa41ed ]--- Trying to vfree() bad address (f74ce8c0) bad addr or host------------[ cut here ]------------ WARNING: at mm/vmalloc.c:385 () : (Temporary faModules linked in: ringilure in name re Pid: 12, comm: events/1 Tainted: G W 2.6.26.2-default #1 solution) INIT: [<c012489a>] [<c0126a40>] [<c012481b>] [<c012697c>] Entering runleve [<c0126944>] l: 3 [<c0103597>] ======================= [<c015bcd1>] [<c0124167>] [<c012481b>] ---[ end trace 322ec9c1aafa41ed ]--- I see a strange behaviour. 1> I can not allocate more slots than the default number of 4096. 2> After some time, pf-ring seems to stop working. First, Snort does not report any more alerts though I attacks it. Second, the number of free slots are the same. I have feeling that the issue has been mentioned before in the post: http://listgateway.unipi.it/pipermail/ntop-misc/2006-June/000705.html I just want to mention that if I use pf_ring rev 3610, I did not experience problem 2 but problem 1. I am wondering if something wrong with my VM configuration. 1> Should I choose option HIGHMEM64G in the Linux kernel configure? 2> Should I choose another memory spliting scheme? 3> Should I choose another version of Linux kernel? Any advice are appreciated very much Here is my configuration settings: CONFIG_HIGHMEM4G=y CONFIG_VMSPLIT_3G_OPT=y CONFIG_PAGE_OFFSET=0xB0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_ZONE_DMA_FLAG=1 On the machine: more /proc/buddyinfo Node 0, zone DMA 5 5 3 4 3 3 2 1 1 1 2 Node 0, zone Normal 33 4 2 4 1 2 1 1 2 1 269 Node 0, zone HighMem 2 0 1 1 0 2 0 1 1 0 34 Boot message: Linux version 2.6.26.2-default (v...@workstation) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Thu Dec 4 11:13:16 EST 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 00000000cfeb2000 (usable) BIOS-e820: 00000000cfeb2000 - 00000000cfec8000 (reserved) BIOS-e820: 00000000cfec8000 - 00000000cfee7c00 (ACPI data) BIOS-e820: 00000000cfee7c00 - 00000000d0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fe000000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000130000000 (usable) Warning only 4GB will be used. Use a HIGHMEM64G enabled kernel. 3200MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at [c00fe710] 000fe710 Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 1048576 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 1048576 DMI 2.5 present. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. Memory: 3368156k/4194304k available (1929k kernel code, 37260k reserved, 708k data, 568k init, 2489032k highmem) virtual kernel memory layout: fixmap : 0xfff52000 - 0xfffff000 ( 692 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc0399000 - 0xc0427000 ( 568 kB) .data : 0xc02e244c - 0xc0393468 ( 708 kB) .text : 0xc0100000 - 0xc02e244c (1929 kB) "L'homme propose, Dieu dispose" /Van Mobile nr. (45)40783319 ________________________________ _______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev "L'homme propose, Dieu dispose" /Van Mobile nr. (45)40783319 -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean.
<<winmail.dat>>
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
