Export Device Placement

Hello - I'm looking for some suggestions on the best design strategy for where to have my NetFlow export devices.

My network is a large hub and spoke with all of the services located centrally at headquarters. We have nearly 100 sites (and growing) so I'm wary of having 100+ exporting devices out there. That said, I'm having difficulties having the collectors centralized as the IP scheme I have inherited is terrible so I would literally need to create 5-10 IP address groups per location if I want to get a view of what is going on across the WAN for each location. We are in the process of changing all of the IP issues but in the mean-time, what is the best way for me to get a view of the WAN activity for each location? Do I need to create all of the address groups? Or should I setup all of those remote devices to send all of that info across the WAN and view everything that way?

Note that I am not particularily concerned about the local traffic at each traffic - only the WAN. I would love to hear suggestions! Thanks.

Find more posts tagged with

Accepted answers

All comments

mcbridea

Hi scriag84,

Sounds like the IP address scheme is a mess. If you choose to collect at each spoke it will be easier to segregate that data by accessing reports from the spoke interface views, but you will be adding X amount of data to your WAN to export NetFlow to the hub collector. It might be worth it to try this on one spoke and monitor the port 2055 data as NetFlow to view the impact on the WAN. There is a catch, if you do this test in off hours you will not see many flows (no user data to report on). If you do it during production you will have more flows and X amount of additional data on the WAN between the exporter and the collector. If you have pleanty of spare bandwidth during peak hours this might be a good idea. If you don't have spare bandwidth......

The other path is Hub exporters only and create the IP Address Groups but this will be tedious.

Andy

scraig84

Yes - the scheme is ridiculous and we are actively going about changing it, but it will probably be at least 6 months before that is complete. I guess I'm thinking that the IP address groups is the way to go as it isn't going for the short-term fix that may have long-term implications.

Another thing I'm curious about though - I know that once you remove an existing group you basically "lose" all of the summary graphs which is one of the reasons I've avoided even attempting creating the groups in the first place because it made me nervous. My assumption is that the data is not gone but it won't be there again until all the groups have been added back in. I have to remove one of the private address groups so that I can build it back in smaller groups since the tool does not allow for subnets. Once all of this is complete, it will all still be there right? When you remove an address group you are not removing data correllated with it correct?

Thanks for any insight on that.

JHolmes763

It'd be _really_ nice if you could have more than one subnet in an IP address group. Or have the ability to at least choose more than one to graph together. Not having this really limits what I can get out of the tool for some of the requirements I have.

That being said, I think you could get away with just your "hub" router exporting flows. You'll still catch everything coming to/from the spoke sites. This is the configuration I currently use with a central hub and 50+ satellite based spoke sites off of it. There's no way I can afford to have the spokes export raw data over the low bandwidth, high latency satellite links. I still get a view of all the data going to and from them, though. The only thing you'd miss is spoke-to-spoke traffic, if that applies.

I sent you a PM on another tool that you may find useful, too.

---John Holmes...

scraig84

Well, you can still build reports based on multiple address groups but I agree that it is limiting only being able to put a single contiguous range into an address group.

The beef I have with the report tool though is that you can't copy an existing report and then modify it. Each one you have to start from scratch it seems which is extremely annoying. --edited to add that I just figured out the way around that by copying the report file itself outside of Report Writer and then going back in and modifying it.