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=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 wrote:
> On Thu, 9 Apr 2020 06:20:00 +
> Liam Farr 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 wrote:
> On Thu, 9 Apr 2020 06:20:00 +
> Liam Farr 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
