Hi Scott. -> Hi, it’s been a while so if I’m wrong I’m happy to be corrected but in your case -> you’d sample on the input side of each of the individual interfaces facing the -> customer.
yes, pretty much what I had planned. At least to start. -> The load shouldn’t be an issue providing you’re running later code with out the -> JFlow related bugs such as the PR (I don’t recall the number) for the bug where -> flow processing blocked the PFE from accepting routes from the RE. These were -> pre 13.2 on the 480 if memory serves but this is going back in the haze a bit so -> feel free to sanity check. Inline JFlow does not have the same impact to -> processing of other platforms so you can be less concerned. -> The other thing to remember is that all sampling takes place at 1:1 and -> the sampling rate knob is more of a scaling factor rather than actually adjusting -> the rate of sampling. Setting this to 1/1 instead of 1/1000 or what ever value will -> help the data appear correctly. One thing that has come up, is that there are multiple routing instance vrf's running on each interface we want to monitor. Regular netflow cannot be exported outside of a vrf to the default without a workaround. But it appears inline jflow will do that. I'm just trying to work out if that will function for us. One thing about inline that Juniper config docs say is about the flow-table size. I had someone tell me enabling inline jflow will cause the fpc to reboot, but from what I read adjusting the size of the flow hash table will cause that. Any idea what is correct here? I would think that just enabling it would not cause an FPC to restart. Thanks, Keith _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
