Mailing List Archive

Hi Matt
ASA (like PaloAlto and many others) are firewall devices that emit flows when the flow starts and when the flow ends, this adding a verdict (e.g. pass or drop according to firewall rules). ASA is a family of devices and not all area alike, so configuration and ASA model can make quite some difference. The flow format (enclosed an example) is kind of incomplete (e.g. there is no begin/end of a flow but just the event time) but the main problem is that the device does not send periodic flow updates, so in essence you are blind until the flow arrives and when that happens the bytes/pkts stats are broken because the flow bytes needs to be spread backwards, making things complicated in particular for long flows

So with flow-devices that are following the standard such as nProbe you have near-realtime (near because netflow aggregates packets so you have a flow exported every X sec, and thus you have an average values compared to pure packet based apps such as ntopng) stats and better visibility compared to ASA. This said nProbe/ntopng also support ASA flows so you have the freedom to decide if you want to stay with ASA or move to nprobe

Regards Luca

> On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com> wrote:
>
> I asked part of this question previously, but it was buried in another thread where I was trying to fix problems.
>
> I'm currently exporting netflows from an asa and using nprobe on an evaluation basis to zmq that to ntopng.
>
> However, I'm reading the ASA's implementation of netflow isn't exactly "flow" oriented, but more based on network security events, so there's no mid-flow updates, etc.
>
> While it seems like router platforms are "best" for netflow with ntop, I don't really have one in a useful place in my network. I could however reconfigure to use a cisco switch to generate netflow data and use that. I've got a recent model cisco 3xxx series switch with ipbase licensing, which is capable of flexible netflow.
>
> Beyond the obvious differences in network visibility caused by using a different device, are there advantages to flexible netflow on the switch platforms compared to the ASA platform? Is the FNF implementation on the current 3xxx series models comparable with the implementation on router platforms, at least in terms of how "normal" the flows look to ntopng?
>
> Would there be any problems/benefits with bringing both back to ntopng? If so, would you do it with separate nprobe instance feeding a separate zmq to ntopng, or just bring it to the same probe?
>
>
>
>
>
>
>
>
>
> *This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THEINFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop

Hi Matt
ASA (like PaloAlto and many others) are firewall devices that emit flows when the flow starts and when the flow ends, this adding a verdict (e.g. pass or drop according to firewall rules). ASA is a family of devices and not all area alike, so configuration and ASA model can make quite some difference. The flow format (enclosed an example) is kind of incomplete (e.g. there is no begin/end of a flow but just the event time) but the main problem is that the device does not send periodic flow updates, so in essence you are blind until the flow arrives and when that happens the bytes/pkts stats are broken because the flow bytes needs to be spread backwards, making things complicated in particular for long flows

So with flow-devices that are following the standard such as nProbe you have near-realtime (near because netflow aggregates packets so you have a flow exported every X sec, and thus you have an average values compared to pure packet based apps such as ntopng) stats and better visibility compared to ASA. This said nProbe/ntopng also support ASA flows so you have the freedom to decide if you want to stay with ASA or move to nprobe

Regards Luca

> On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com> wrote:
>
> I asked part of this question previously, but it was buried in another thread where I was trying to fix problems.
>
> I'm currently exporting netflows from an asa and using nprobe on an evaluation basis to zmq that to ntopng.
>
> However, I'm reading the ASA's implementation of netflow isn't exactly "flow" oriented, but more based on network security events, so there's no mid-flow updates, etc.
>
> While it seems like router platforms are "best" for netflow with ntop, I don't really have one in a useful place in my network. I could however reconfigure to use a cisco switch to generate netflow data and use that. I've got a recent model cisco 3xxx series switch with ipbase licensing, which is capable of flexible netflow.
>
> Beyond the obvious differences in network visibility caused by using a different device, are there advantages to flexible netflow on the switch platforms compared to the ASA platform? Is the FNF implementation on the current 3xxx series models comparable with the implementation on router platforms, at least in terms of how "normal" the flows look to ntopng?
>
> Would there be any problems/benefits with bringing both back to ntopng? If so, would you do it with separate nprobe instance feeding a separate zmq to ntopng, or just bring it to the same probe?
>
>
>
>
>
>
>
>
>
> *This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THEINFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop

Thank you Luca, but you basically just summarized everything I already know, and kind of missed the question I was asking.


Is the implementation of netflow on a Cisco 3xxx switch any better from nprobe's perspective than the ASA?


When you say "move to nprobe", I'm already using nprobe. AFAIK, it is impossible to avoid using nprobe when collecting netflows, unless you're using span ports. ie: you can't send netflow from an ASA directly to ntopng. You have to send it to nprobe for translation..


If by "move to nprobe" you mean using a span port to allow nprobe directly collect ethernet frames, that isn't even something I'm considering. If I bother to set up a span port I may as well just have ntopng directly ingest the packets.


My two situations are:


ASA Netflow -> nprobe -> ntopng


vs


Cisco Switch Flexible Netflow -> nprobe -> ntopng


I'm not proposing this configuration, which you seem to be referring to as "nprobe":


Cisco switch span port -> nprobe -> ntopng


?

________________________________
From: ntop-bounces@listgateway.unipi.it <ntop-bounces@listgateway.unipi.it> on behalf of Luca Deri <deri@ntop.org>
Sent: Wednesday, March 8, 2017 1:23 AM
To: ntop@unipi.it
Cc: ntop@listgateway.unipi.it
Subject: Re: [Ntop] asa netflow vs switch flexible netflow

Hi Matt
ASA (like PaloAlto and many others) are firewall devices that emit flows when the flow starts and when the flow ends, this adding a verdict (e.g. pass or drop according to firewall rules). ASA is a family of devices and not all area alike, so configuration and ASA model can make quite some difference. The flow format (enclosed an example) is kind of incomplete (e.g. there is no begin/end of a flow but just the event time) but the main problem is that the device does not send periodic flow updates, so in essence you are blind until the flow arrives and when that happens the bytes/pkts stats are broken because the flow bytes needs to be spread backwards, making things complicated in particular for long flows

So with flow-devices that are following the standard such as nProbe you have near-realtime (near because netflow aggregates packets so you have a flow exported every X sec, and thus you have an average values compared to pure packet based apps such as ntopng) stats and better visibility compared to ASA. This said nProbe/ntopng also support ASA flows so you have the freedom to decide if you want to stay with ASA or move to nprobe

Regards Luca

On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com<mailto:matt.kettler@fourthdim.com>> wrote:

I asked part of this question previously, but it was buried in another thread where I was trying to fix problems.

I'm currently exporting netflows from an asa and using nprobe on an evaluation basis to zmq that to ntopng.

However, I'm reading the ASA's implementation of netflow isn't exactly "flow" oriented, but more based on network security events, so there's no mid-flow updates, etc.

While it seems like router platforms are "best" for netflow with ntop, I don't really have one in a useful place in my network. I could however reconfigure to use a cisco switch to generate netflow data and use that. I've got a recent model cisco 3xxx series switch with ipbase licensing, which is capable of flexible netflow.

Beyond the obvious differences in network visibility caused by using a different device, are there advantages to flexible netflow on the switch platforms compared to the ASA platform? Is the FNF implementation on the current 3xxx series models comparable with the implementation on router platforms, at least in terms of how "normal" the flows look to ntopng?

Would there be any problems/benefits with bringing both back to ntopng? If so, would you do it with separate nprobe instance feeding a separate zmq to ntopng, or just bring it to the same probe?









*This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THE[cid:F94B7907-C848-458F-9165-2A941A400921]INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it<mailto:Ntop@listgateway.unipi.it>
http://listgateway.unipi.it/mailman/listinfo/ntop

*This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THE INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.

Thank you Luca, but you basically just summarized everything I already know, and kind of missed the question I was asking.


Is the implementation of netflow on a Cisco 3xxx switch any better from nprobe's perspective than the ASA?


When you say "move to nprobe", I'm already using nprobe. AFAIK, it is impossible to avoid using nprobe when collecting netflows, unless you're using span ports. ie: you can't send netflow from an ASA directly to ntopng. You have to send it to nprobe for translation..


If by "move to nprobe" you mean using a span port to allow nprobe directly collect ethernet frames, that isn't even something I'm considering. If I bother to set up a span port I may as well just have ntopng directly ingest the packets.


My two situations are:


ASA Netflow -> nprobe -> ntopng


vs


Cisco Switch Flexible Netflow -> nprobe -> ntopng


I'm not proposing this configuration, which you seem to be referring to as "nprobe":


Cisco switch span port -> nprobe -> ntopng


?

________________________________
From: ntop-bounces@listgateway.unipi.it <ntop-bounces@listgateway.unipi.it> on behalf of Luca Deri <deri@ntop.org>
Sent: Wednesday, March 8, 2017 1:23 AM
To: ntop@unipi.it
Cc: ntop@listgateway.unipi.it
Subject: Re: [Ntop] asa netflow vs switch flexible netflow

Hi Matt
ASA (like PaloAlto and many others) are firewall devices that emit flows when the flow starts and when the flow ends, this adding a verdict (e.g. pass or drop according to firewall rules). ASA is a family of devices and not all area alike, so configuration and ASA model can make quite some difference. The flow format (enclosed an example) is kind of incomplete (e.g. there is no begin/end of a flow but just the event time) but the main problem is that the device does not send periodic flow updates, so in essence you are blind until the flow arrives and when that happens the bytes/pkts stats are broken because the flow bytes needs to be spread backwards, making things complicated in particular for long flows

So with flow-devices that are following the standard such as nProbe you have near-realtime (near because netflow aggregates packets so you have a flow exported every X sec, and thus you have an average values compared to pure packet based apps such as ntopng) stats and better visibility compared to ASA. This said nProbe/ntopng also support ASA flows so you have the freedom to decide if you want to stay with ASA or move to nprobe

Regards Luca

On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com<mailto:matt.kettler@fourthdim.com>> wrote:

I asked part of this question previously, but it was buried in another thread where I was trying to fix problems.

I'm currently exporting netflows from an asa and using nprobe on an evaluation basis to zmq that to ntopng.

However, I'm reading the ASA's implementation of netflow isn't exactly "flow" oriented, but more based on network security events, so there's no mid-flow updates, etc.

While it seems like router platforms are "best" for netflow with ntop, I don't really have one in a useful place in my network. I could however reconfigure to use a cisco switch to generate netflow data and use that. I've got a recent model cisco 3xxx series switch with ipbase licensing, which is capable of flexible netflow.

Beyond the obvious differences in network visibility caused by using a different device, are there advantages to flexible netflow on the switch platforms compared to the ASA platform? Is the FNF implementation on the current 3xxx series models comparable with the implementation on router platforms, at least in terms of how "normal" the flows look to ntopng?

Would there be any problems/benefits with bringing both back to ntopng? If so, would you do it with separate nprobe instance feeding a separate zmq to ntopng, or just bring it to the same probe?









*This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THE[cid:F94B7907-C848-458F-9165-2A941A400921]INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.
_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it<mailto:Ntop@listgateway.unipi.it>
http://listgateway.unipi.it/mailman/listinfo/ntop

*This e-mail is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you have received this e-mail in error, please notify the sender immediately, delete the e-mail from your computer and do not copy or disclose it to anyone else.* *THE INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Fourth Dimension is not responsible for any damages caused by your unauthorized use of the materials in this e-mail.

Hi Matt,
I run several ASA5510 and ASA5505 Firewalls running 9.1.7+ and they're
all sending V9 Netflow streams to several NProbe collectors on 1 server
(they listen on different ports) NTOPNG is running on the same machine.
This allows me to view different 'interfaces' so I can view traffic i/o
on the various ASAs.

I would be really interested in seeing/comparing flows if you sent flows
from FNF to 1 instance of Nprobe, and flows from V9 from the ASA to
another instance of Nprobe (this is similar to my setup of using
multiple Nprobe collectors all running on different ports.

From the Cisco docs..."NetFlow version 9 is a flexible and extensible
NetFlow format used by Flexible NetFlow" So I'm really interested in
finding out how and why Flex Netflow differs from Netflow V9. I thought
it was just marketing department stuff... but it seems you might have
spotted a huge difference.

Sorry, you probably know this already.. but FYI
My ntop config shard is

-i=tcp://127.0.0.1:5555
-i=tcp://127.0.0.1:5556
-i=tcp://127.0.0.1:5557
-i=tcp://127.0.0.1:5558
-i=tcp://127.0.0.1:5560
-i=tcp://127.0.0.1:5561
-i=tcp://127.0.0.1:5563
-i=tcp://127.0.0.1:5564
-i=tcp://127.0.0.1:5565
-i=tcp://127.0.0.1:5566

and then I start nprobe several times...

nprobe --zmq tcp://*:5555 -i none -n none --collector-port 2055
nprobe --zmq tcp://*:5556 -i none -n none --collector-port 2056
nprobe --zmq tcp://*:5557 -i none -n none --collector-port 2057
nprobe --zmq tcp://*:5558 -i none -n none --collector-port 2058
nprobe --zmq tcp://*:5559 -i none -n none --collector-port 2059
nprobe --zmq tcp://*:5560 -i none -n none --collector-port 2060
nprobe --zmq tcp://*:5561 -i none -n none --collector-port 2061
nprobe --zmq tcp://*:5562 -i none -n none --collector-port 2062
nprobe --zmq tcp://*:5563 -i none -n none --collector-port 2063
nprobe --zmq tcp://*:5564 -i none -n none --collector-port 2064
nprobe --zmq tcp://*:5565 -i none -n none --collector-port 2065
nprobe --zmq tcp://*:5566 -i none -n none --collector-port 2066

and on my ASA1 I send to 192.168.x.x port 2055, ASA2 I send to
192.168.x.x port 2056 etc.. etc..


On 08/03/17 15:55, Matt Kettler wrote:
>
> Thank you Luca, but you basically just summarized everything I already
> know, and kind of missed the question I was asking.
>
>
> Is the implementation of netflow on a Cisco 3xxx switch any better
> from nprobe's perspective than the ASA?
>
>
> When you say "move to nprobe", I'm already using nprobe. AFAIK, it is
> impossible to avoid using nprobe when collecting netflows, unless
> you're using span ports. ie: you can't send netflow from an ASA
> directly to ntopng. You have to send it to nprobe for translation..
>
>
> If by "move to nprobe" you mean using a span port to allow nprobe
> directly collect ethernet frames, that isn't even something I'm
> considering. If I bother to set up a span port I may as well just have
> ntopng directly ingest the packets.
>
>
> My two situations are:
>
>
> ASA Netflow -> nprobe -> ntopng
>
>
> vs
>
>
> Cisco Switch Flexible Netflow -> nprobe -> ntopng
>
>
> I'm not proposing this configuration, which you seem to be referring
> to as "nprobe":
>
>
> Cisco switch span port -> nprobe -> ntopng
>
>
> ?
>
> ------------------------------------------------------------------------
> *From:* ntop-bounces@listgateway.unipi.it
> <ntop-bounces@listgateway.unipi.it> on behalf of Luca Deri <deri@ntop.org>
> *Sent:* Wednesday, March 8, 2017 1:23 AM
> *To:* ntop@unipi.it
> *Cc:* ntop@listgateway.unipi.it
> *Subject:* Re: [Ntop] asa netflow vs switch flexible netflow
> Hi Matt
> ASA (like PaloAlto and many others) are firewall devices that emit
> flows when the flow starts and when the flow ends, this adding a
> verdict (e.g. pass or drop according to firewall rules). ASA is a
> family of devices and not all area alike, so configuration and ASA
> model can make quite some difference. The flow format (enclosed an
> example) is kind of incomplete (e.g. there is no begin/end of a flow
> but just the event time) but the main problem is that the device does
> not send periodic flow updates, so in essence you are blind until the
> flow arrives and when that happens the bytes/pkts stats are broken
> because the flow bytes needs to be spread backwards, making things
> complicated in particular for long flows
>
> So with flow-devices that are following the standard such as nProbe
> you have near-realtime (near because netflow aggregates packets so you
> have a flow exported every X sec, and thus you have an average values
> compared to pure packet based apps such as ntopng) stats and better
> visibility compared to ASA. This said nProbe/ntopng also support ASA
> flows so you have the freedom to decide if you want to stay with ASA
> or move to nprobe
>
> Regards Luca
>
>> On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com
>> <mailto:matt.kettler@fourthdim.com>> wrote:
>>
>> I asked part of this question previously, but it was buried in
>> another thread where I was trying to fix problems.
>>
>> I'm currently exporting netflows from an asa and using nprobe on an
>> evaluation basis to zmq that to ntopng.
>>
>> However, I'm reading the ASA's implementation of netflow isn't
>> exactly "flow" oriented, but more based on network security events,
>> so there's no mid-flow updates, etc.
>>
>> While it seems like router platforms are "best" for netflow with
>> ntop, I don't really have one in a useful place in my network. I
>> could however reconfigure to use a cisco switch to generate netflow
>> data and use that. I've got a recent model cisco 3xxx series switch
>> with ipbase licensing, which is capable of flexible netflow.
>>
>> Beyond the obvious differences in network visibility caused by using
>> a different device, are there advantages to flexible netflow on the
>> switch platforms compared to the ASA platform? Is the FNF
>> implementation on the current 3xxx series models comparable with the
>> implementation on router platforms, at least in terms of how "normal"
>> the flows look to ntopng?
>>
>> Would there be any problems/benefits with bringing both back to
>> ntopng? If so, would you do it with separate nprobe instance feeding
>> a separate zmq to ntopng, or just bring it to the same probe?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *This e-mail is intended solely for the addressee. Access to this
>> email by anyone else is unauthorized. If you have received this
>> e-mail in error, please notify the sender immediately, delete the
>> e-mail from your computer and do not copy or disclose it to anyone
>> else.* *THEINFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE
>> THE PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.*
>> Any disclosure, copying, distribution or any action taken or omitted
>> to be taken in reliance on it, is prohibited and may be unlawful.
>> Fourth Dimension is not responsible for any damages caused by your
>> unauthorized use of the materials in this e-mail.
>> _______________________________________________
>> Ntop mailing list
>> Ntop@listgateway.unipi.it <mailto:Ntop@listgateway.unipi.it>
>> http://listgateway.unipi.it/mailman/listinfo/ntop
>
> *This e-mail is intended solely for the addressee. Access to this
> email by anyone else is unauthorized. If you have received this e-mail
> in error, please notify the sender immediately, delete the e-mail from
> your computer and do not copy or disclose it to anyone else.* *THE
> INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS CONSTITUTE THE
> PROPRIETARY INFORMATION OF FOURTH DIMENSION ENGINEERING, LLC.* Any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. Fourth
> Dimension is not responsible for any damages caused by your
> unauthorized use of the materials in this e-mail.
>
>
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop

Hi,

On Wed, Mar 8, 2017 at 12:10 PM, Warren Daly (OPUS) <warren@opus.com.kh>
wrote:

> Hi Matt,
> I run several ASA5510 and ASA5505 Firewalls running 9.1.7+ and they're all
> sending V9 Netflow streams to several NProbe collectors on 1 server (they
> listen on different ports) NTOPNG is running on the same machine. This
> allows me to view different 'interfaces' so I can view traffic i/o on the
> various ASAs.
>
> I would be really interested in seeing/comparing flows if you sent flows
> from FNF to 1 instance of Nprobe, and flows from V9 from the ASA to another
> instance of Nprobe (this is similar to my setup of using multiple Nprobe
> collectors all running on different ports.
>
> From the Cisco docs..."NetFlow version 9 is a flexible and extensible
> NetFlow format used by Flexible NetFlow" So I'm really interested in
> finding out how and why Flex Netflow differs from Netflow V9. I thought it
> was just marketing department stuff... but it seems you might have spotted
> a huge difference.
>
> Sorry, you probably know this already.. but FYI
> My ntop config shard is
>
> -i=tcp://127.0.0.1:5555
> -i=tcp://127.0.0.1:5556
> -i=tcp://127.0.0.1:5557
> -i=tcp://127.0.0.1:5558
> -i=tcp://127.0.0.1:5560
> -i=tcp://127.0.0.1:5561
> -i=tcp://127.0.0.1:5563
> -i=tcp://127.0.0.1:5564
> -i=tcp://127.0.0.1:5565
> -i=tcp://127.0.0.1:5566
>
> and then I start nprobe several times...
>
> nprobe --zmq tcp://*:5555 -i none -n none --collector-port 2055
> nprobe --zmq tcp://*:5556 -i none -n none --collector-port 2056
> nprobe --zmq tcp://*:5557 -i none -n none --collector-port 2057
> nprobe --zmq tcp://*:5558 -i none -n none --collector-port 2058
> nprobe --zmq tcp://*:5559 -i none -n none --collector-port 2059
> nprobe --zmq tcp://*:5560 -i none -n none --collector-port 2060
> nprobe --zmq tcp://*:5561 -i none -n none --collector-port 2061
> nprobe --zmq tcp://*:5562 -i none -n none --collector-port 2062
> nprobe --zmq tcp://*:5563 -i none -n none --collector-port 2063
> nprobe --zmq tcp://*:5564 -i none -n none --collector-port 2064
> nprobe --zmq tcp://*:5565 -i none -n none --collector-port 2065
> nprobe --zmq tcp://*:5566 -i none -n none --collector-port 2066
>
> and on my ASA1 I send to 192.168.x.x port 2055, ASA2 I send to 192.168.x.x
> port 2056 etc.. etc..
>

In the latest ntopng dev we have added a feature that creates new
interfaces on the basis of the exporter ip address. This means that you no
longer need to spawn multiple nprobe instances. You you can point all your
routers to a single nprobe instance and then enable the dynamic interface
creation from the ntopng preferences page.

You only have to make sure nprobe is sending EXPORTER_IPV4_ADDRESS template
field.


>
>
> On 08/03/17 15:55, Matt Kettler wrote:
>
> Thank you Luca, but you basically just summarized everything I already
> know, and kind of missed the question I was asking.
>
>
> Is the implementation of netflow on a Cisco 3xxx switch any better from
> nprobe's perspective than the ASA?
>
>
> When you say "move to nprobe", I'm already using nprobe. AFAIK, it is
> impossible to avoid using nprobe when collecting netflows, unless you're
> using span ports. ie: you can't send netflow from an ASA directly to
> ntopng. You have to send it to nprobe for translation..
>
>
> If by "move to nprobe" you mean using a span port to allow nprobe directly
> collect ethernet frames, that isn't even something I'm considering. If I
> bother to set up a span port I may as well just have ntopng directly ingest
> the packets.
>
>
> My two situations are:
>
>
> ASA Netflow -> nprobe -> ntopng
>
>
> vs
>
>
> Cisco Switch Flexible Netflow -> nprobe -> ntopng
>
>
> I'm not proposing this configuration, which you seem to be referring to as
> "nprobe":
>
>
> Cisco switch span port -> nprobe -> ntopng
>
>
> ?
> ------------------------------
> *From:* ntop-bounces@listgateway.unipi.it <ntop-bounces@listgateway.
> unipi.it> <ntop-bounces@listgateway.unipi.it> on behalf of Luca Deri
> <deri@ntop.org> <deri@ntop.org>
> *Sent:* Wednesday, March 8, 2017 1:23 AM
> *To:* ntop@unipi.it
> *Cc:* ntop@listgateway.unipi.it
> *Subject:* Re: [Ntop] asa netflow vs switch flexible netflow
>
> Hi Matt
> ASA (like PaloAlto and many others) are firewall devices that emit flows
> when the flow starts and when the flow ends, this adding a verdict (e.g.
> pass or drop according to firewall rules). ASA is a family of devices and
> not all area alike, so configuration and ASA model can make quite some
> difference. The flow format (enclosed an example) is kind of incomplete
> (e.g. there is no begin/end of a flow but just the event time) but the main
> problem is that the device does not send periodic flow updates, so in
> essence you are blind until the flow arrives and when that happens the
> bytes/pkts stats are broken because the flow bytes needs to be spread
> backwards, making things complicated in particular for long flows
>
> So with flow-devices that are following the standard such as nProbe you
> have near-realtime (near because netflow aggregates packets so you have a
> flow exported every X sec, and thus you have an average values compared to
> pure packet based apps such as ntopng) stats and better visibility compared
> to ASA. This said nProbe/ntopng also support ASA flows so you have the
> freedom to decide if you want to stay with ASA or move to nprobe
>
> Regards Luca
>
> On 8 Mar 2017, at 05:31, Matt Kettler <matt.kettler@fourthdim.com> wrote:
>
> I asked part of this question previously, but it was buried in another
> thread where I was trying to fix problems.
>
> I'm currently exporting netflows from an asa and using nprobe on an
> evaluation basis to zmq that to ntopng.
>
> However, I'm reading the ASA's implementation of netflow isn't exactly
> "flow" oriented, but more based on network security events, so there's no
> mid-flow updates, etc.
>
> While it seems like router platforms are "best" for netflow with ntop, I
> don't really have one in a useful place in my network. I could however
> reconfigure to use a cisco switch to generate netflow data and use that.
> I've got a recent model cisco 3xxx series switch with ipbase licensing,
> which is capable of flexible netflow.
>
> Beyond the obvious differences in network visibility caused by using a
> different device, are there advantages to flexible netflow on the switch
> platforms compared to the ASA platform? Is the FNF implementation on the
> current 3xxx series models comparable with the implementation on router
> platforms, at least in terms of how "normal" the flows look to ntopng?
>
> Would there be any problems/benefits with bringing both back to ntopng? If
> so, would you do it with separate nprobe instance feeding a separate zmq to
> ntopng, or just bring it to the same probe?
>
>
>
>
>
>
>
>
>
> *This e-mail is intended solely for the addressee. Access to this email by
> anyone else is unauthorized. If you have received this e-mail in error,
> please notify the sender immediately, delete the e-mail from your computer
> and do not copy or disclose it to anyone else.* *THEINFORMATION IN THIS
> EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH
> DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any
> action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful. Fourth Dimension is not responsible for any damages caused
> by your unauthorized use of the materials in this e-mail.
>
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
>
> *This e-mail is intended solely for the addressee. Access to this email by
> anyone else is unauthorized. If you have received this e-mail in error,
> please notify the sender immediately, delete the e-mail from your computer
> and do not copy or disclose it to anyone else.* *THE INFORMATION IN THIS
> EMAIL AND ANY ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH
> DIMENSION ENGINEERING, LLC.* Any disclosure, copying, distribution or any
> action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful. Fourth Dimension is not responsible for any damages caused
> by your unauthorized use of the materials in this e-mail.
>
> _______________________________________________
> Ntop mailing listNtop@listgateway.unipi.ithttp://listgateway.unipi.it/mailman/listinfo/ntop
>
>
>
> _______________________________________________
> Ntop mailing list
> Ntop@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop
>

Thank you. This simplifies the config and is a great new feature. ~W


On 08/03/17 19:13, Simone Mainardi wrote:
> Hi,
>
> On Wed, Mar 8, 2017 at 12:10 PM, Warren Daly (OPUS)
> <warren@opus.com.kh <mailto:warren@opus.com.kh>> wrote:
>
> Hi Matt,
> I run several ASA5510 and ASA5505 Firewalls running 9.1.7+ and
> they're all sending V9 Netflow streams to several NProbe
> collectors on 1 server (they listen on different ports) NTOPNG is
> running on the same machine. This allows me to view different
> 'interfaces' so I can view traffic i/o on the various ASAs.
>
> I would be really interested in seeing/comparing flows if you sent
> flows from FNF to 1 instance of Nprobe, and flows from V9 from the
> ASA to another instance of Nprobe (this is similar to my setup of
> using multiple Nprobe collectors all running on different ports.
>
> From the Cisco docs..."NetFlow version 9 is a flexible and
> extensible NetFlow format used by Flexible NetFlow" So I'm really
> interested in finding out how and why Flex Netflow differs from
> Netflow V9. I thought it was just marketing department stuff...
> but it seems you might have spotted a huge difference.
>
> Sorry, you probably know this already.. but FYI
> My ntop config shard is
>
> -i=tcp://127.0.0.1:5555 <http://127.0.0.1:5555>
> -i=tcp://127.0.0.1:5556 <http://127.0.0.1:5556>
> -i=tcp://127.0.0.1:5557 <http://127.0.0.1:5557>
> -i=tcp://127.0.0.1:5558 <http://127.0.0.1:5558>
> -i=tcp://127.0.0.1:5560 <http://127.0.0.1:5560>
> -i=tcp://127.0.0.1:5561 <http://127.0.0.1:5561>
> -i=tcp://127.0.0.1:5563 <http://127.0.0.1:5563>
> -i=tcp://127.0.0.1:5564 <http://127.0.0.1:5564>
> -i=tcp://127.0.0.1:5565 <http://127.0.0.1:5565>
> -i=tcp://127.0.0.1:5566 <http://127.0.0.1:5566>
>
> and then I start nprobe several times...
>
> nprobe --zmq tcp://*:5555 -i none -n none --collector-port 2055
> nprobe --zmq tcp://*:5556 -i none -n none --collector-port 2056
> nprobe --zmq tcp://*:5557 -i none -n none --collector-port 2057
> nprobe --zmq tcp://*:5558 -i none -n none --collector-port 2058
> nprobe --zmq tcp://*:5559 -i none -n none --collector-port 2059
> nprobe --zmq tcp://*:5560 -i none -n none --collector-port 2060
> nprobe --zmq tcp://*:5561 -i none -n none --collector-port 2061
> nprobe --zmq tcp://*:5562 -i none -n none --collector-port 2062
> nprobe --zmq tcp://*:5563 -i none -n none --collector-port 2063
> nprobe --zmq tcp://*:5564 -i none -n none --collector-port 2064
> nprobe --zmq tcp://*:5565 -i none -n none --collector-port 2065
> nprobe --zmq tcp://*:5566 -i none -n none --collector-port 2066
>
> and on my ASA1 I send to 192.168.x.x port 2055, ASA2 I send to
> 192.168.x.x port 2056 etc.. etc..
>
>
> In the latest ntopng dev we have added a feature that creates new
> interfaces on the basis of the exporter ip address. This means that
> you no longer need to spawn multiple nprobe instances. You you can
> point all your routers to a single nprobe instance and then enable the
> dynamic interface creation from the ntopng preferences page.
>
> You only have to make sure nprobe is sending EXPORTER_IPV4_ADDRESS
> template field.
>
>
>
> On 08/03/17 15:55, Matt Kettler wrote:
>>
>> Thank you Luca, but you basically just summarized everything I
>> already know, and kind of missed the question I was asking.
>>
>>
>> Is the implementation of netflow on a Cisco 3xxx switch any
>> better from nprobe's perspective than the ASA?
>>
>>
>> When you say "move to nprobe", I'm already using nprobe. AFAIK,
>> it is impossible to avoid using nprobe when collecting netflows,
>> unless you're using span ports. ie: you can't send netflow from
>> an ASA directly to ntopng. You have to send it to nprobe for
>> translation..
>>
>>
>> If by "move to nprobe" you mean using a span port to allow nprobe
>> directly collect ethernet frames, that isn't even something I'm
>> considering. If I bother to set up a span port I may as well just
>> have ntopng directly ingest the packets.
>>
>>
>> My two situations are:
>>
>>
>> ASA Netflow -> nprobe -> ntopng
>>
>>
>> vs
>>
>>
>> Cisco Switch Flexible Netflow -> nprobe -> ntopng
>>
>>
>> I'm not proposing this configuration, which you seem to be
>> referring to as "nprobe":
>>
>>
>> Cisco switch span port -> nprobe -> ntopng
>>
>>
>> ?
>>
>> ------------------------------------------------------------------------
>> *From:* ntop-bounces@listgateway.unipi.it
>> <mailto:ntop-bounces@listgateway.unipi.it>
>> <ntop-bounces@listgateway.unipi.it>
>> <mailto:ntop-bounces@listgateway.unipi.it> on behalf of Luca Deri
>> <deri@ntop.org> <mailto:deri@ntop.org>
>> *Sent:* Wednesday, March 8, 2017 1:23 AM
>> *To:* ntop@unipi.it <mailto:ntop@unipi.it>
>> *Cc:* ntop@listgateway.unipi.it <mailto:ntop@listgateway.unipi.it>
>> *Subject:* Re: [Ntop] asa netflow vs switch flexible netflow
>> Hi Matt
>> ASA (like PaloAlto and many others) are firewall devices that
>> emit flows when the flow starts and when the flow ends, this
>> adding a verdict (e.g. pass or drop according to firewall rules).
>> ASA is a family of devices and not all area alike, so
>> configuration and ASA model can make quite some difference. The
>> flow format (enclosed an example) is kind of incomplete (e.g.
>> there is no begin/end of a flow but just the event time) but the
>> main problem is that the device does not send periodic flow
>> updates, so in essence you are blind until the flow arrives and
>> when that happens the bytes/pkts stats are broken because the
>> flow bytes needs to be spread backwards, making things
>> complicated in particular for long flows
>>
>> So with flow-devices that are following the standard such as
>> nProbe you have near-realtime (near because netflow aggregates
>> packets so you have a flow exported every X sec, and thus you
>> have an average values compared to pure packet based apps such as
>> ntopng) stats and better visibility compared to ASA. This said
>> nProbe/ntopng also support ASA flows so you have the freedom to
>> decide if you want to stay with ASA or move to nprobe
>>
>> Regards Luca
>>
>>> On 8 Mar 2017, at 05:31, Matt Kettler
>>> <matt.kettler@fourthdim.com <mailto:matt.kettler@fourthdim.com>>
>>> wrote:
>>>
>>> I asked part of this question previously, but it was buried in
>>> another thread where I was trying to fix problems.
>>>
>>> I'm currently exporting netflows from an asa and using nprobe on
>>> an evaluation basis to zmq that to ntopng.
>>>
>>> However, I'm reading the ASA's implementation of netflow isn't
>>> exactly "flow" oriented, but more based on network security
>>> events, so there's no mid-flow updates, etc.
>>>
>>> While it seems like router platforms are "best" for netflow with
>>> ntop, I don't really have one in a useful place in my network. I
>>> could however reconfigure to use a cisco switch to generate
>>> netflow data and use that. I've got a recent model cisco 3xxx
>>> series switch with ipbase licensing, which is capable of
>>> flexible netflow.
>>>
>>> Beyond the obvious differences in network visibility caused by
>>> using a different device, are there advantages to flexible
>>> netflow on the switch platforms compared to the ASA platform? Is
>>> the FNF implementation on the current 3xxx series models
>>> comparable with the implementation on router platforms, at least
>>> in terms of how "normal" the flows look to ntopng?
>>>
>>> Would there be any problems/benefits with bringing both back to
>>> ntopng? If so, would you do it with separate nprobe instance
>>> feeding a separate zmq to ntopng, or just bring it to the same
>>> probe?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *This e-mail is intended solely for the addressee. Access to
>>> this email by anyone else is unauthorized. If you have received
>>> this e-mail in error, please notify the sender immediately,
>>> delete the e-mail from your computer and do not copy or disclose
>>> it to anyone else.* *THEINFORMATION IN THIS EMAIL AND ANY
>>> ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH
>>> DIMENSION ENGINEERING, LLC.* Any disclosure, copying,
>>> distribution or any action taken or omitted to be taken in
>>> reliance on it, is prohibited and may be unlawful. Fourth
>>> Dimension is not responsible for any damages caused by your
>>> unauthorized use of the materials in this e-mail.
>>> _______________________________________________
>>> Ntop mailing list
>>> Ntop@listgateway.unipi.it <mailto:Ntop@listgateway.unipi.it>
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>> <http://listgateway.unipi.it/mailman/listinfo/ntop>
>>
>> *This e-mail is intended solely for the addressee. Access to this
>> email by anyone else is unauthorized. If you have received this
>> e-mail in error, please notify the sender immediately, delete the
>> e-mail from your computer and do not copy or disclose it to
>> anyone else.* *THE INFORMATION IN THIS EMAIL AND ANY ATTACHMENTS
>> CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION
>> ENGINEERING, LLC.* Any disclosure, copying, distribution or any
>> action taken or omitted to be taken in reliance on it, is
>> prohibited and may be unlawful. Fourth Dimension is not
>> responsible for any damages caused by your unauthorized use of
>> the materials in this e-mail.
>>
>>
>> _______________________________________________
>> Ntop mailing list
>> Ntop@listgateway.unipi.it <mailto:Ntop@listgateway.unipi.it>
>> http://listgateway.unipi.it/mailman/listinfo/ntop
>> <http://listgateway.unipi.it/mailman/listinfo/ntop>
> _______________________________________________ Ntop mailing list
> Ntop@listgateway.unipi.it <mailto:Ntop@listgateway.unipi.it>
> http://listgateway.unipi.it/mailman/listinfo/ntop
> <http://listgateway.unipi.it/mailman/listinfo/ntop>
>