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