Options

Netflow help

hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
Hey folks,

I would like to implement Netflow into my environment. Never-mind the back end collector, I have not figured out that part of the equation yet (previously used Solarwinds though). I am unsure how to get started with the way my environment is laid out. Our branch offices consist of routers capable of the job and is nothing new to me, but our HQ and DRDC environments have me a bit puzzled. Our Nexus 5500 core appears to not support Netflow, which is where things like the load-balancers and server-farms plug into. Our access-layer consists of a variety of switches, such as 3650s,3750s, 6500s, etc. I have never set up netflow on a layer 2 device and am not even sure if it is possible. Setting netflow up on the edge router will be useless, as all traffic will appear to come from our public address. That leaves the ASA, but I am not sure if that is something we would want to do either. Does anyone here have suggestions? I have been reading some articles trying to figure this out, but am a bit puzzled.

Comments

  • Options
    EANxEANx Member Posts: 1,077 ■■■■■■■■□□
    Suggest you post this in the Cisco area, not the general "off-topic" area.
  • Options
    hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    Maybe. This section is for technology but not certs so seemed promising, but if nothing turns up then maybe.
  • Options
    networker050184networker050184 Mod Posts: 11,962 Mod
    This is the perfect area to spot this type of question. It's not related to a certification.


    Netflow is mostly supported on routers only so you're probably not going to have much luck with an L2 core. Why would it be an issue for public IP addresses to appear in your netflow data? Can you not trace your important services back to a NAT?
    An expert is a man who has made all the mistakes which can be made.
  • Options
    hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    This is the perfect area to spot this type of question. It's not related to a certification.


    Netflow is mostly supported on routers only so you're probably not going to have much luck with an L2 core. Why would it be an issue for public IP addresses to appear in your netflow data? Can you not trace your important services back to a NAT?

    Hey networker. The core is layer 3, but on Nexus 5500UP series switches, which do not seem to support netflow. We can do netflow on the edge router, and we can see traffic from one public IP is all user traffic, traffic from another is this set of servers, etc etc. It's not bad, but it's not totally granular either. If some guy is torrenting all day or streaming or whatever, I still can't track it down. But your idea beats nothing.
  • Options
    IristheangelIristheangel Mod Posts: 4,133 Mod
    Check out Stealthwatch. If you use it to collect Netflow on your edge routers/firewalls, it'll do NAT stitching where you can see pre-NAT and post-NAT IPs. If you use Cisco Routers with NBAR2, you can also collect URI information. It's pretty useful for keeping long term storage for the flow records as well since it does flow stitching (each netflow record is unidirectional so it takes both records that are going each way and stitches it together to one flow record) and dedepulication (removing duplicate netflow records). That might solve the problem you're looking to solve and depending on the size of the environment and the size of the flow collector, you'll probably end up with 6 months to 12 months of records retention for every netflow conversation
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • Options
    hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    Check out Stealthwatch. If you use it to collect Netflow on your edge routers/firewalls, it'll do NAT stitching where you can see pre-NAT and post-NAT IPs. If you use Cisco Routers with NBAR2, you can also collect URI information. It's pretty useful for keeping long term storage for the flow records as well since it does flow stitching (each netflow record is unidirectional so it takes both records that are going each way and stitches it together to one flow record) and dedepulication (removing duplicate netflow records). That might solve the problem you're looking to solve and depending on the size of the environment and the size of the flow collector, you'll probably end up with 6 months to 12 months of records retention for every netflow conversation

    Awesome, I'll look into this. Thank you.
  • Options
    hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    Check out Stealthwatch. If you use it to collect Netflow on your edge routers/firewalls, it'll do NAT stitching where you can see pre-NAT and post-NAT IPs. If you use Cisco Routers with NBAR2, you can also collect URI information. It's pretty useful for keeping long term storage for the flow records as well since it does flow stitching (each netflow record is unidirectional so it takes both records that are going each way and stitches it together to one flow record) and dedepulication (removing duplicate netflow records). That might solve the problem you're looking to solve and depending on the size of the environment and the size of the flow collector, you'll probably end up with 6 months to 12 months of records retention for every netflow conversation

    It looks very cool, but it seems to do way more than what I need. Unfortunately, we use some free stuff for graphing stats from SNMP. I hate it, it's hard to use, but it's probably going to be our netflow collector. I have never done netflow on an ASA. It seems possible but with limitations. What are your thoughts on that?
  • Options
    IristheangelIristheangel Mod Posts: 4,133 Mod
    It's fine on an ASA. If can send NSEL data that gives metrics on the flows, NAT information, and flow action (denied, allow, etc). Don't expect URL information though
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • Options
    IristheangelIristheangel Mod Posts: 4,133 Mod
    Note: If you can dissemble the raw flow, you'll get that NAT data. It's just going to be a lot more manual
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
Sign In or Register to comment.