Nick the community concept was designed to address situations as the one you described. it seems it isn't enough for you. what is missing? I tell you in advance that creating hundred of virtual interfaces isn't a solution IMHO
Cheers Luca On Jan 6, 2009, at 5:45 PM, Nick Verdegem wrote: > Thanks for your response. > I've been experimenting with this this afternoon and I don't think it > will quite do what we need. > > Our infrastructure consists of 250-300 remote sites, generally > assigned > a /24 subnet. These sites come back to a series of data centres, > using > a variety of thick and thin client technology. Our requirement is to > be > able to identify on a site by site basis, using netflow data from > the on > site router, who is using the local circuit and what they're doing. > The > original plan was to create a Virtual Interface for each /24, allowing > the support team to quickly swap VI's for each site and identify > what is > going on. > > I have experimented with assigning a VI with a /16 subnet, but the > filtering within nTop doesn't seem to be able to cope with wildcards, > e.g. 192.168.2.*, meaning that it becomes extremely difficult to see > on > a site by site basis what is happening. > > I have also tried starting up with --local-subnets, defining each /24 > that I'm monitoring, but that doesn't seem to have any effect, simply > because I believe the NetFlow probe detects this from the received > flow > information anyway. > > I've tried with the 'community' definitions, but I can't see a way of > searching/filtering for this, other than sorting the column under > hosts. > I suspect that the 'subnet' drop down might be helpful, but all I > get is > 'All' or 'Unknown Subnets', and can't find a way of defining these. > > There may be another way of doing it, but I cant see anything reading > MAN. And surely we can't be the only people looking at having this > quantity of devices :) > > > > "This email and any file attachments do not form a contract unless > expressly stated. They may contain privileged, confidential and/or > copyright information. If you are not the intended recipient or the > service provider responsible for delivering this please delete the > material from any computer and return to the sender at once; do not > use, disclose or reproduce its contents. We do not accept liability > for any error or omission in the message arising from corruption of, > delay in or interference with, its transmission. We reserve the > right to monitor email communications through normal internal and > external networks. We believe but do not warrant that the email and > the file attachments are virus free." > > Interserve Plc. Registered in England, Number : 88456. > Registered Office: Interserve House, Ruscombe Park, Twyford, > Reading, Berkshire, RG10 9JU. > > _______________________________________________ > Ntop mailing list > Ntop@unipi.it > http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list Ntop@unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop
