[Bro] Problem: Bro listening on two ethernet interfaces

Aashish Sharma aashish at uiuc.edu
Tue May 31 11:30:13 PDT 2005


Jason : 

Thanks for all the help.

Here is the output you'd ask for: 

[/tmp]# bro -i eth2 -i eth3 mt.bro print-filter.bro
listening on eth2
listening on eth3
Reading .state/state.bst ...
((((((((port 111) or (port telnet or tcp port 513)) or (port finger)) or ((ip[6:2] & 0x3fff != 0) and tcp)) or (tcp[13] & 7 != 0)) or (udp port 69)) or (por
t ftp)) or (tcp port 113)) or (udp port 123)


[/tmp]# /usr/local/bro/bin/bro -i eth2 -i eth3 mt.bro
listening on eth2
listening on eth3
Reading .state/state.bst ...
1117554540.647671 received termination signal
3374 packets received on interface eth2, 479 dropped
3602 packets received on interface eth3, 610 dropped

[ Re-ran the cammond ] 

[/tmp]# /usr/local/bro/bin/bro -i eth2 -i eth3 mt.bro
listening on eth2
listening on eth3
1117554872.292885 received termination signal
2297 packets received on interface eth2, 50 dropped
2435 packets received on interface eth3, 48 dropped



[/tmp]#  /usr/bin/time tcpdump -c 25000 -i eth2 -n -w /dev/null
tcpdump: listening on eth2
26277 packets received by filter
1270 packets dropped by kernel
0.04user 0.25system 0:03.88elapsed 7%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (189major+123minor)pagefaults 0swaps


[/tmp]#  /usr/bin/time tcpdump -c 25000 -i eth3 -n -w /dev/null
tcpdump: listening on eth3
25188 packets received by filter
184 packets dropped by kernel
0.04user 0.12system 0:04.17elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (189major+123minor)pagefaults 0swaps


Also, Here is bro capture filter which is seen in the info.log once I start bro. Since, we are adding some some capture filter in site policy file, I thought I should paste the capture filter too.

Bro Version: 0.9a8
Started with the following command line options:  -i eth2 -i eth3 bro
listening on eth2
listening on eth3
Reading .state/state.bst ...
Capture filter: (((((((((((((((((((((port 53) or (port smtp)) or (port 111)) or (port 111)) or (port 143)) or (tcp src port 3128 or tcp src port 3120)) or (port smtp)) or (tcp[2:2] > 32770 and tcp[2:2] < 32901 and tcp[0:2] != 80 and tcp[0:2] != 22 and tcp[0:2] != 139)) or (port ftp)) or (port 161 or port 162)) or ( icmp)) or ((ip[6:2] & 0x3fff != 0) and tcp)) or (tcp dst port 3128 or tcp dst port 3120)) or (tcp port 80 or tcp port 8080 or tcp port 8000 or tcp port 8001)) or (port telnet or tcp port 513)) or (port ftp)) or (tcp[13] & 7 != 0)) or (tcp port 514)) or (port 512 or port 513 or port 515)) or (udp port 69)) or (port telnet)) or ((src net 141.142.0.0/16) and (dst port 135 or dst port 137 or dst port 139 or dst port 445))

Thanks a lot for looking into this. 

Aashish 


On Tue, May 24, 2005 at 12:59:47PM -0700, Jason Lee wrote:
> 
> Aashish,
> 
> Maybe I can help.
> 
>  Can you give me a feel for how much traffic you are looking at?
>  Number of pkts per second per interface.
>  What is the filter that you are running bro with?
>  (ie. bro -i eth1 -i eth2 mt.bro print-filter.bro)
>  should print the filter (sub in your filter for where I have mt.bro above)
> 
>   What kinds of numbers you get if you control-c it after
>   a 30 seconds or so:
> 
> [/tmp]# /usr/local/bro/bin/bro -i eth2 -i eth3 mt.bro
> pcap bufsize = 8192
> listening on eth2
> pcap bufsize = 8192
> listening on eth3
> 1116964082.421280 received termination signal
> 27771 packets received on interface eth2, 0 dropped
> 54353 packets received on interface eth3, 0 dropped
> 
> 
> And maybe  snaps of what packet rates you are seeing
> on the interfaces:
> 
> [/tmp]# /usr/bin/time tcpdump -c 25000 -i eth3 -n -w /dev/null
> tcpdump: listening on eth3
> 25012 packets received by filter
> 0 packets dropped by kernel
> 0.02user 0.13system 0:03.56elapsed 4%CPU
> 
> /tmp]# /usr/bin/time tcpdump -c 25000 -i eth2 -n -w /dev/null
> tcpdump: listening on eth2
> 25006 packets received by filter
> 0 packets dropped by kernel
> 0.00user 0.07system 0:04.44elapsed 1%CPU
> 
> 
> Cheers,
> jason
> 
>  
> 
> 
> Aashish Sharma wrote:
> 
> >>Look for AckAboveHole and ContentGap notices.  These can both happen for
> >>other reasons, but primarily happen due to dropped packets.
> >>    
> >>
> >
> >I looked in previous logs and found no alerts what so ever for AckAboveHole and ContentGap to realize that brolite had notice_ignore for them. 
> >
> ># Remove these notices from logging since they can be too noisy.
> >redef notice_action_filters += {
> >        [[ContentGap, AckAboveHole]] = notice_ignore,
> >};
> >
> >Which I changed to file_notice. 
> >        [[ContentGap, AckAboveHole]] = file_notice,
> >
> >
> >So. in last 1h15m I have 165065 ContentGap and 36596 AckAboveHole notices. Is this normal (noisy?) or is this the traffic getting dropped ? 
> >
> >And by getting dropped - do we mean that bro is not processing this traffic ? 
> >
> >2) Also Can I put it this way : 
> >
> >Of all traffic we get on interfaces we filter a part using bro filter (packetdrop notices) and then there are dropped packets (AckAboveHole and ContentGap notices)  and then rest of the traffic is processed by bro ? 
> >
> >
> >  
> >
> >>I'm not sure what you mean by "because of bro filter", but those reports
> >>    
> >>
> >Here, I meant is since we have applied bro-filter, all these packet drops could be accounted for. (they are dropped by the bro-filter) 
> >
> >
> >Thanks a lot for all the help. We have been constantly tuning bro and results are great. 
> >
> >
> >Aashish 
> >
> >
> >
> >On Thu, May 19, 2005 at 12:08:36PM -0700, Vern Paxson wrote:
> >  
> >
> >>>t=3D1116392591.523558 no=3DDroppedPackets na=3DNOTICE_FILE msg=3D4475\ pack=
> >>>ets\ dropped\ after\ filtering,\ 21924\ received
> >>>
> >>>Looking at the policy file (netstats.bro) I am inclined to think that these=
> >>> notices are generated because of bro filter. Please correct me here.=20
> >>>      
> >>>
> >>I'm not sure what you mean by "because of bro filter", but those reports
> >>are generated based on retrieving statistics from libpcap, and "after
> >>filtering" means after applying the filter Bro specified to pcap, which
> >>you can see using print-filter.bro.
> >>
> >>    
> >>
> >>>What I cannot answer/understand right now is:
> >>>
> >>>Is there any way I can find out is bro actually dropping packets, if at all=
> >>> ?
> >>>      
> >>>
> >>Look for AckAboveHole and ContentGap notices.  These can both happen for
> >>other reasons, but primarily happen due to dropped packets.
> >>
> >>		Vern
> >>_______________________________________________
> >>Bro mailing list
> >>bro at bro-ids.org
> >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> >>    
> >>



More information about the Bro mailing list