Hi, The first collector has an IP of 192.168.1.1. It has a flow-fanout wich was started like this:
flow-fanout 0/0/2054 127.0.0.1/0/2054 192.168.1.1/192.168.1.2/2054 It has a flow-capture listening on 127.0.0.1:2054. I have another collector at 192.168.1.2. Notice the logic of the flow-fanout. It says, for each flow arriving on all interfaces "including loopback" as denoted by "0/" in the first flow-fanout argument, send a copy to flow-capture which is listening on 127.0.0.1/0/2054, and to 192.168.1.2 When the packet arrives at the external interface (192.168.1.1, a copy is send to its loopback interface, and with the packet arriving at loopback, it will be seen again by flow-fanout as a new flow, having a parameter that tells "send a copy of all flows arriving on all interfaces", which creates a possible infinite loop, possibly sending tons of flows to another remote collector(s). Is there any way that the flow-fanout will detect that this flow he is currently seeing on loopback is the same as the one he saw previously on his external interface (in my case 192.168.1.1). I guess, the first flow-fanout argument should have been 192.168.1.0/0/2054, but as I see it(personal opinion only) , it is a limitation of the program being unable to anticipate this kind of looping scenario. Or was it originally by design, that user's should watch out what they put between these ///'s. Recently we just had a network wide outage. If that was what have caused our entire network to collapsed, eating up almost 100Mbps of bandwidth, then I guess its a good thing that I have uncovered a weakness in our LAN infrastructure. Our clients connected via E1 links could not possibly saturate our entire network even summing up their entire usage with the rest of our clients E1 connections. However, hosts having 100Mbps connection such as our LAN users, are free to saturate the entire upstream pipe. It has already happened to my previous job, but the responsible host is another host, which can easily be seen by the netflow collector, unfortunately, this time (although not 100% sure), it was the netflow collector itself who is probably causing the problem. Any suggestions? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
