[j-nsp] Netflow config for MX204

[Liam Farr]

Hi,

Got things working in the end, thanks everyone for their help and patience.

Also thanks @John Kristoff especially for the template at
https://github.com/jtkristoff/junos/blob/master/flows.md it was
very helpful.

As I suspected I was doing something dumb, or rather a combination of the
dumb.

1. I had initially tried to use fxp0 as my export interface, it seems this
is not supported.
2. I then tried to use an interface in a VRF to export the flows, I think
some additional config may be required for this (
https://kb.juniper.net/InfoCenter/index?page=content&id=KB28958).
3. It's always MTU... I suspect in one of my various config attempts flow's
were being sent, but dropped because of the 1500 MTU on the flow collector
and a larger MTU on the MX204 interface generating them.

In the end I set up a new link-net on a new vlan interface attached to
inet0 between the MX204 and netflow collector, set the inet mtu to 1500
and 🍾 everything started working.


Again thanks everyone for the help, I now have some really interesting flow
stats to examine :)



On Fri, 10 Apr 2020 at 07:10, John Kristoff <jtk at depaul.edu> wrote:

> On Thu, 9 Apr 2020 06:20:00 +0000
> Liam Farr <liam at maxumdata.com> wrote:
>
> > However I am getting export packet failures.
>
> Some loss of flows being exported may be unavoidable depending on
> your configuration and environment.  If you want to see fewer errors
> you may just have to sample less frequently.  The numbers reported in
> your "accounting errors" don't seem that large.
>
> In my repo page were the example config is from you'll see a couple of
> images at the bottom that show the difference between the two modes.  I
> was aware of the flex mode when I originally did this.  I think at the
> time I was under the impression that setting the memory pools manually
> offered some desirable predictability.
>
> Looking back at my notes, I think it was when Juniper TAC told me this
> that led me to that conclusion: "And regarding flex-flow-sizing; this
> configuration results in a first-come-first-serve creation of flows.
> Whichever flow comes first, that is allowed to occupy the flow-table if
> there is space in the table. Otherwise, the flow is dropped and an
> error count is created."  Rightly or wrongly, I recall seeming to want
> to ensure some amount of reasonable memory for both v4 and v6 flows.
>
> John
>


-- 
Kind Regards


Liam Farr

Maxum Data
+64-9-950-5302

On Fri, 10 Apr 2020 at 07:10, John Kristoff <jtk at depaul.edu> wrote:

> On Thu, 9 Apr 2020 06:20:00 +0000
> Liam Farr <liam at maxumdata.com> wrote:
>
> > However I am getting export packet failures.
>
> Some loss of flows being exported may be unavoidable depending on
> your configuration and environment.  If you want to see fewer errors
> you may just have to sample less frequently.  The numbers reported in
> your "accounting errors" don't seem that large.
>
> In my repo page were the example config is from you'll see a couple of
> images at the bottom that show the difference between the two modes.  I
> was aware of the flex mode when I originally did this.  I think at the
> time I was under the impression that setting the memory pools manually
> offered some desirable predictability.
>
> Looking back at my notes, I think it was when Juniper TAC told me this
> that led me to that conclusion: "And regarding flex-flow-sizing; this
> configuration results in a first-come-first-serve creation of flows.
> Whichever flow comes first, that is allowed to occupy the flow-table if
> there is space in the table. Otherwise, the flow is dropped and an
> error count is created."  Rightly or wrongly, I recall seeming to want
> to ensure some amount of reasonable memory for both v4 and v6 flows.
>
> John
>


-- 
Kind Regards


Liam Farr

Maxum Data
+64-9-950-5302