Re: [j-nsp] Inline IPFIX sampling rate

I can confirm the rate=1 regardless of behavior up through 13.2 up through the PFE programming blocked by flow PR when that bug was addressed. > On Jul 25, 2017, at 1:39 PM, Euan Galloway wrote: > > Let's try that again, but to the list this time... > > *sigh* > > Euan > > On 25 July 2017 a

Re: [j-nsp] Inline IPFIX sampling rate

I would be interested in this as well. My understanding was that the sampling rate in hardware was always set to 1:1 and the sample rate value was sent as the scaling factor for the sampling / reporting tool. Changing the rate had no practical effect to the actual data. If this has changed I’

Re: [j-nsp] Netflow analyzer / collector

I would check out the good ol NFCAPD and NFDUMP. Pretty good set of open source tools for collection of data and then reporting. Thanks > On May 22, 2017, at 2:21 AM, John Luthcinson wrote: > > Hi list > > Could you recommend good Netflow/IPFIX analyzer / collector tools for SP > environment?

Re: [j-nsp] MX104 limitation

Hi, in hardware flow sampling like inline Flow, I believe all sampling is done at 1/1 and the sample rate is only a scaling factor and doesn’t effect the physical sampling rate of the card. It’s been a while though, I may be wrong on this but this was the case in code up through 13.2 or so.

Re: [j-nsp] Netflow/Jflow

+1, this is how I have set things up as well and yes, changing the table sizes will cause an FPC reboot. > On Nov 3, 2016, at 9:04 PM, Olivier Benghozi > wrote: > > Hi Keith, > > Adjusting the size of the flow hash table will reboot the FPC. > In 14.2 and previous, you have everything (15) fo

Re: [j-nsp] Netflow/Jflow

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. 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 re

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

Hi, I totally agree. I was just trying to learn about RSVP and it’s uses in a lab setting. Call this more of a personal growth and improving of skills, I’m not trying to build anything production related. I did build an LDP based environment and you’re right it was pretty straight forward and

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

fundamentals. I’ll give these a shot and appreciate your suggestion. On Oct 26, 2016, at 2:41 AM, Mark Tinka mailto:mark.ti...@seacom.mu>> wrote: On 26/Oct/16 02:34, Scott Granados wrote: Hi, this is a very basic question at least I think it is, apologies for being so green in advanc

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

install-to" and "install" knobs coupled with VRF nexthop rewriting to map different VRFs to different LSPs https://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guidelines/mpls-configuring-the-ingress-and-egress-router-addresses-for-lsps.html#id-95801 Thanks Alex On 26/10/

[j-nsp] Very basic question about MPLS and RSVP's place in the design

Hi, this is a very basic question at least I think it is, apologies for being so green in advance. I’m trying to wrap my head around MPLS and have built a small lab. I understand how provider routers label switch packets and how provider edges use VRF instances and their distinguishers and tar

Re: [j-nsp] dhcp not working across lacp link

Do you have any config snippets? Sounds pretty straight forward, maybe someone knows something obvious that I don’t but config pieces may shed some light. > On Aug 9, 2016, at 1:30 PM, joe mcguckin wrote: > > Ok, test setup is 2) ex2200 switched, reset back to factory defaults. > > Configuri

Re: [j-nsp] Wireless

I’d also add Aerohive to the mix of consideration if they are still out there doing it. Had good luck with their products and great support. > On May 26, 2016, at 10:47 AM, Tammy Firefly wrote: > > > > On 5/26/16 8:45 AM, Jared Mauch wrote: >> On Thu, May 26, 2016 at 07:35:35PM +0530, Mehul

Re: [j-nsp] Routing Engine filtering on EX with VRF

I believe this is correct. In order for a specific filter to have effect with in an routing instance you have to apply that filter to the loopback else I believe and am more than willing to be corrected but I believe the instance takes on the characteristics of the global filter when no filter

Re: [j-nsp] MX960 Power Options

8 AC inputs, I was always amazed by he amount of power the MX 960 used. My drier uses less.:) Then again when you think about being able to seat 100G cards and all sorts of goodies I suppose the power draw makes sense. > On Jan 26, 2016, at 8:23 AM, sth...@nethelp.no wrote: > >>> I recommend

Re: [j-nsp] RTBH

As a side note, this is how I’ve always seen it done. I believe even the RFC refers to this method. > On Jan 14, 2016, at 8:07 PM, chip wrote: > > A strategy that I've seen used is to pick some ip address and add a static > route for it pointing to discard on every router. Then when you recei

Re: [j-nsp] MX960 with 3 RE's?

Sounds correct, only 2 routing engines at a time. > On Jan 13, 2016, at 11:59 AM, Colton Conor wrote: > > Just to confirm though, its the extra RE that is different and not > supported in this config right? The MX960 can use 3 SCB's at once, but only > 2 REs? Or do I have the wrong too? > > >

Re: [j-nsp] juniper hack news

So I wonder about your statements about the governments. I would tend to agree and trust me there’s little about the scumbags in Washington (or insert your nations capitol here) that would surprise me but I’m not convinced. There’s been a ton of bellyaching at least in the US and probably glob

Re: [j-nsp] Analyzing traffic content

This sounds like a job for inline Flow or more generically called NetFlow although if memory serves that may be a Cisco term. (Flow is the Juniper term) You can collect this data with something like NFSEN / NFDUMP and glean from that the data you’re looking for using all sorts of included filte

Re: [j-nsp] Breaking an EX cluster?

while, I may have also followed the > instructions from: > > http://forums.juniper.net/t5/Ethernet-Switching/Disable-Virtual-Chasis-on-EX4200/td-p/46663 > > On 08/17/2015 01:32 PM, Scott Granados wrote: >> Ah very interesting. I didn’t think of that. >> >>

Re: [j-nsp] Breaking an EX cluster?

es/cables installed and then forming the > chassis one unit at a time did the trick. > > Kevin > On 08/17/2015 01:19 PM, Scott Granados wrote: >> So let me be a bit more clear. >> >> I have an existing lab chassis. It’s just something we use to test on etc. >&

Re: [j-nsp] Breaking an EX cluster?

et> [http://www.mankatonetworks.com/images/mn_logo_email.png] On Mon, Aug 17, 2015 at 12:33 PM, Scott Granados mailto:sc...@granados-llc.net>> wrote: Hi Ross, I had tried this but still no link. I believe I have a hardware problem at work causing the vc ports not to link. Zeroize seemed to do the

Re: [j-nsp] Breaking an EX cluster?

a little easier. > > Cheers > Ross > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Scott Granados > Sent: Thursday, August 13, 2015 9:23 PM > To: juniper-nsp > Subject: [j-nsp] Breaking an EX cluster

Re: [j-nsp] Breaking an EX cluster?

; On Aug 13, 2015, at 22:23, Scott Granados wrote: >> >> Hi, >> Have some EX 4300s that I want to break apart and start like they were >> factory new and reboot. I know about the factory default button on the >> front and the configuration option but no matter how I

[j-nsp] Breaking an EX cluster?

Hi, Have some EX 4300s that I want to break apart and start like they were factory new and reboot. I know about the factory default button on the front and the configuration option but no matter how I apply that I still have the node boot thinking it’s a member of the previous chassis. How do

Re: [j-nsp] MX104 Limitations

I have set up the 104 in over seas pops and taken several views with out issue. At a minimum 2 full table feeds + some peering. SHouldn’t be a problem. > On Jul 9, 2015, at 10:44 AM, sth...@nethelp.no wrote: > >>> But MX104 can't hold the full internet routing table in forwarding-table so >>> i

Re: [j-nsp] MX104 Limitations

I’m not sure about the BFD thing. As I recall and I would definitely suggest you take this with a few grains of salt and research a second source but BFD on directly connected paths will distribute to the line card. BFD say loopback to loopback or over a non direct path will be handled by the

Re: [j-nsp] eBGP Failover

I vote for #1 and #3. Both should give you fast fault detection. > On Jun 30, 2015, at 4:09 AM, Peter Ehiwe wrote: > > Possible options : > 1) link bundling technologies And run single ebgp session over the > bundle > 2) two ebgp sessions with shorter keep Alive > 3) two ebgp sessions with

Re: [j-nsp] Juniper 10G Switch Options

+1 for the EX 4600 or QFX 5100. For aggregation a 4600 should do the trick. On Jun 4, 2015, at 9:19 AM, Colton Conor wrote: > We need a Juniper switch with at least 24 built in SFP+ ports. Looks like > Juniper has a ton of options including the EX4500, EX4550, EX4600, and the > QFX line which I

Re: [j-nsp] AP oddness

I’m sorry but I have to say it, GUI is for the weak. These devices, especially network devices have no business having a web front end. That just causes laziness and dumbs down the target audience. Vendors of equipment, especially serious equipment really need to get ahold of this fact and st

[j-nsp] Upgrading firmware on an EX 4300 virtual chassis?

Hi, I’ve downloaded the latest recommended firmware from the web site which is indicated as jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz. I’ve been googling and keep finding procedures for upgrading that involve NSSU which I’ve seen go very badly all be it quite a while ago, before the fe

Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?

I’m not sure exactly what you’re looking for but the peer group system under JunOS is fairly efficient. If you set your export and import policies per group the bgp process will place these in a peer group and dynamically break off slow members in to their own groups so that one slower peer won

Re: [j-nsp] vMX availability

And the world is a better place for you spending your day job in BGP land.:) On May 6, 2015, at 8:39 AM, Jeff Haas wrote: > >> On May 6, 2015, at 12:13 AM, Nathan Ward wrote: >> >> On 6 May 2015 at 12:20:21, Jeff Haas (jh...@juniper.net >> ) wrote: >>> -- Jeff (who

Re: [j-nsp] Buying a used Juniper

Depends on the vendor and the application. This is probably a more true statement with Juniper than Cisco because there is so much used Cisco out there that you could buy a large router of similar size and all the spare parts you want far less expensively than buying the hardware new even with

Re: [j-nsp] Replacing a member of a virtual chassis?

Perfect and request virtual-chassis renumber to renumber the member from the newly assigned to the replaced value correct? Thanks for the pointers, I just found this article shortly after posting. On Apr 7, 2015, at 12:45 PM, Jonathan Call mailto:lordsit...@hotmail.com>> wrote: Shut off defec

[j-nsp] Replacing a member of a virtual chassis?

Good afternoon, I have an EX4300 stack consisting of 6 members connected together using the cables on the back in to a single chassis. I have VC-Ports flapping on member 3 which is leading me to believe I have a bad member on a hardware level. I have looked for a procedure to remove the membe

Re: [j-nsp] MX80 BGP Convergence

Yes, similar issues on the MX480 with Sampled when inline flow was enabled. On Mar 23, 2015, at 6:30 AM, Adam Vitkovsky wrote: > Does this affect other MX series boxes as well please? > > adam >> -Original Message- >> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Be

Re: [j-nsp] MX80 BGP Convergence

Depends on the version of code you’re running. At best you’re looking at minutes and in some cases as much as 10 minutes. With the wrong version of Code where the sampled bug is still present you might never get routes installed in the FIB. The fix applied for the PR does allow for convergenc

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

members method and reboot the cluster. On Mar 19, 2015, at 9:19 AM, Laurent CARON wrote: > On 19/03/2015 13:57, Scott Granados wrote: >> If I want to downgrade from 13.2 to 12.3R8 or R7.7 are there any special >> steps and or a document I should follow for this procedure or do I use t

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

AM, Tore Anderson mailto:t...@fud.no>> wrote: * Scott Granados mailto:sc...@granados-llc.net>> Hi, I’m wondering what people recommend for a software release for the EX 4500 switch in a virtual chassis configuration. I noted that there is 13.2 code installed in my cluster now but the

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

If I want to downgrade from 13.2 to 12.3R8 or R7.7 are there any special steps and or a document I should follow for this procedure or do I use the standard method? I did some googling and didn’t find anything that applied or a KB article dealing with downgrading. Thanks Scott On Mar 19, 201

[j-nsp] Recommended Junos version for EX-4500 virtual chassis

Hi, I’m wondering what people recommend for a software release for the EX 4500 switch in a virtual chassis configuration. I noted that there is 13.2 code installed in my cluster now but the recommended version on the web site is 12.3R8 which obviously doesn’t match. What are people using and o

Re: [j-nsp] show system boot-messages

Great point, thanks for clarification. On Jan 20, 2015, at 1:51 PM, Saku Ytti wrote: > On (2015-01-20 13:48 -0500), Scott Granados wrote: > > Hey, > >> Can’t you execute the dmesg command from the shell and watch the output >> there? > > That's only w

Re: [j-nsp] show system boot-messages

Can’t you execute the dmesg command from the shell and watch the output there? On Jan 20, 2015, at 1:38 PM, Saku Ytti wrote: > On (2015-01-20 11:26 +), Adam Vitkovsky wrote: > > Hey Adam, > >> I assume the cmd "show system boot-messages" shows just the Junos booting >> process >> Is there

Re: [j-nsp] MX80 JFlow Setup

You will definitely have to poke a hole in your firewall on your loopback. Also, make sure the loopback is part of the main routing instance not in another grouting instance, your source until very recent releases has to be in the global table. Use TCPDump to make sure that flow packets are re

Re: [j-nsp] MX80-1 JFlow

You do not want to run version 9 in this case. set forwarding-options sampling instance blah family output flow-server 199.b.c.d port version-ipfix template ipv4 set forwarding-options sampling instance blah family inet output inline-jflow source-address 199.loopback.0.address (or similar

Re: [j-nsp] MX80 JFlow Setup

Hi there, what you have will work well with a few modifications. If you’re using inline sampling you might as well set the rate to 1, the sampling is happening at 1:1 regardless and all the rate adjusts in this config is the scaling factor. You’re config also needs sample points so something li

Re: [j-nsp] MX80 Sampling - High CPU

Mikrotek, ouch, the only thing I found they were good for is target practice.:) On Dec 11, 2014, at 12:19 AM, Eduardo Schoedler wrote: > Em quarta-feira, 10 de dezembro de 2014, Jordan Whited > escreveu: > I found the issue still present in 12.3R8.7 running on an MX80. In 11.4R7.5 > with samp

Re: [j-nsp] MX80 Sampling - High CPU

I have 12.3R8.7 running on 2 MX-80s and 2 MX-480s with mixed results. The good news is the routers will reconverge with sampling enabled now and the PFE programming won’t block hard. The process is still slow however and while we did some testing it still seems that the processes hang during l

Re: [j-nsp] Dear Juniper...

I’ll take marketing people run amuck for 1000 Alex. On Sep 25, 2014, at 3:52 PM, Scott Harvanek wrote: > I agree with this more than the former. I haven't had any issues > finding specs etc. but it's certainly "fatty block buzzword" design. > > Scott H. > > On 9/25/14, 3:44 PM, Daniel Rohan

Re: [j-nsp] MX80 Sampling - High CPU

+1 here, definitely awaiting these releases. On Sep 23, 2014, at 4:28 PM, Graham Brown wrote: > 12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think > there are many people waiting for these two releases... > > Cheers, > > Graham Brown > Twitter - @mountainrescuer

Re: [j-nsp] Practice lab environments, any suggestions?

x27;t use it for a significant portion of the day, it can be a "waste" of money. Junosphere is due for v4 soon (there used to be a notice about potential downtime while systems are upgraded to support it--or something to that effect). --tc On Thu, Sep 4, 2014 at 9:17 AM, Scott Granad

Re: [j-nsp] Practice lab environments, any suggestions?

om/itm/MUST-SEE-1OFAKIND-JUNIPER-JNCIE-JNCIS-JNCIA-CCIE-CCNP-COUNTERPART-CISCO-LAB-/141393100611?pt=US_Wired_Routers&hash=item20ebaf7f43 (not my listing, just an example, buyer beware, etc etc) On Thu, Sep 4, 2014 at 11:58 AM, Scott Granados mailto:sc...@granados-llc.net>> wrote: Hi, I

[j-nsp] Practice lab environments, any suggestions?

Hi, I’m starting down the path of certifications and wondering what people use for practice labs in terms of hardware? I did some googling but have mostly found rack rental services. Is this the primary method? Is there anyone putting together bundles for sale of used equipment like you migh

Re: [j-nsp] NAT update commit script for SRX210

Can you use the interface tag instead of the IP. So something like match interface or the inverse of how you build a source nat? On Aug 26, 2014, at 6:25 PM, Mike Devlin wrote: > Hey Guys, > > Anyone know of a tested commit script that will update NAT config based on > a DHCP interface changin

Re: [j-nsp] ipv4/ipv6-flow-table-size

oes; > > Assumptions based on this data; > - I can operate on the defaults for my application [ very little > IPv6/VPLS ]. > - I can change it later if needed but that will cause the FPC to reboot. > > -SH > > On 8/25/14, 4:00 PM, Scott Granados wrote: >> Here’s a bit more

Re: [j-nsp] ipv4/ipv6-flow-table-size

flow-collector ] On Aug 25, 2014, at 3:56 PM, Scott Harvanek wrote: > Scott, > > Thanks, my next question then with that is - how/why is the default of > ipv4 15 and ipv6 1? That would break that constraint of 15 total? > > Scott H. > Login Inc. > > On 8/25/14, 3:

Re: [j-nsp] ipv4/ipv6-flow-table-size

ott, > > Thanks, my next question then with that is - how/why is the default of > ipv4 15 and ipv6 1? That would break that constraint of 15 total? > > Scott H. > Login Inc. > > On 8/25/14, 3:53 PM, Scott Granados wrote: >> When ever you set the flow table size

Re: [j-nsp] ipv4/ipv6-flow-table-size

When ever you set the flow table size you initiate a reboot of the FPC. The table size is a combined value of v4 and v6 so 15 total a subset of which is IPV4 and the remainder is IPV6. Thanks Scott On Aug 25, 2014, at 3:02 PM, Scott Harvanek wrote: > I'm wondering if anyone can clarify somet

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

I can confirm with inline flow sampling enabled and even with the code to fix the PR convergence is still slower. I hear there’s a better fix being released in later code 14.2 if memory serves but I’m not sure. On Aug 22, 2014, at 5:13 AM, Euan Galloway wrote: > On Thu, Aug 21, 2014 at 03:38

Re: [j-nsp] Using the FXP for flow sources

n mind that with the RE processing flow data, you can quickly kill your RE if your sampling rate is too low. 1:1 sampling with the MX isn't as problematic since it's processed by the PFE. --tc On Thu, Aug 21, 2014 at 10:47 AM, Scott Granados mailto:sc...@granados-llc.net>> w

Re: [j-nsp] Using the FXP for flow sources

ou know it's actually being sent), it's handled by the PFE. --tc On Thu, Aug 21, 2014 at 10:09 AM, Scott Granados mailto:sc...@granados-llc.net>> wrote: Hi, So I’m still a bit confused on what can or can’t be used in the flow monitoring processes. In this case I have an

[j-nsp] Using the FXP for flow sources

Hi, So I’m still a bit confused on what can or can’t be used in the flow monitoring processes. In this case I have an SRX 3600 with a routing instance. I found a config example that illustrates how to enable flow sampling in this type of environment. It specifically mentions that you

Re: [j-nsp] flow sampling on redundant ethernet on Branch SRX?

formation-products/topic-collections/release-notes/12.1x46/junos-release-notes-12.1X46.pdf > > > > On Wed, Aug 20, 2014 at 10:55 AM, Scott Granados > wrote: > >> Hi, another SRX flow related question. >> >> Doing some googling it appears that you can’t

Re: [j-nsp] flow sampling on redundant ethernet on Branch SRX?

I cannot find a workaround for this limitation, still seems to be present >> in 12.1x46 >> http://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/topic-collections/release-notes/12.1x46/junos-release-notes-12.1X46.pdf >> On Wed, Aug 20, 2014 at 10:55 AM, Scott Granado

[j-nsp] flow sampling on redundant ethernet on Branch SRX?

Hi, another SRX flow related question. Doing some googling it appears that you can’t sample flow data on RETH (redundant ethernet) interfaces. example set interfaces RETH0.30 family inet sampling input Is there a work around for this? should I sample on the redundant member interfaces or is t

Re: [j-nsp] Are there any conditions where a forwarding engine will reboot on a Branch SRX when enabling netflow?

, Morgan McLean mailto:wrx...@gmail.com>> wrote: I've never had an issues when enabling flow sampling, just make sure the sample rate isn't too heavy as the branch firewalls are a bit dinky. Thanks, Morgan On Wed, Aug 20, 2014 at 9:47 AM, Scott Granados mailto:sc...@granados-llc

[j-nsp] Are there any conditions where a forwarding engine will reboot on a Branch SRX when enabling netflow?

Hi, the title just about sums it up but the details are this. I have several different offices with various sized SRX firewalls. I am enabling inline flow sampling on each per the Juniper KB article. It doesn’t mention any possible reboots like you get when enabling inline sampling on an MX.

Re: [j-nsp] Viability of EX4300 in a primarily l3 environment?

+1 on the 4200. Had very good luck with the 4200 series. Also had good luck with the 4300 but there were some bugs. In a basic operation mode though they are quite stable. That being said I was really pleased with the 4200 and you might want to check them out assuming the lower arp limit isn

Re: [j-nsp] MX80 stops forwarding after enabling inline flow sampling

from the RE to the PFE was blocked. Several releases are available with the fix in place. Thanks Scott On Jul 10, 2014, at 12:19 PM, Justin M. Streiner wrote: > On Wed, 9 Jul 2014, Scott Granados wrote: > >> I have an interesting problem. I have an MX80 where I wish t

[j-nsp] MX80 stops forwarding after enabling inline flow sampling

Hi, I have an interesting problem. I have an MX80 where I wish to enable inline flow sampling. I used the kb entry as a template and configured. When setting the table size the PFE rebooted which is expected but when it came back online forwarding stopped. I rebooted again and had th

Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?

Wow, peeks and pokes, I feel like I woke up in 1982 with an Apple 2E.:) Good times. On Jun 24, 2014, at 9:17 AM, Chuck Anderson wrote: > On Wed, Jun 11, 2014 at 03:49:16PM +0100, Phil Mayers wrote: >> On 11/06/14 15:01, Chuck Anderson wrote: >> >>> Jun 10 11:40:54 ex4200 chassism[1293]: XCVR:

[j-nsp] Quewstion about IP flow table size for inline flow sampling

Hi, I am presently using inline flow sampling on a series of MX480s. There is an IP table that can be set from 1 to 15 and is based in multiples of 256. I’m not sure how to calculate my IPv4 table size. It’s presently set to 5 per the KB article but I’m wondering if this is correct.

Re: [j-nsp] Redundant RE setup useful?

I have seen one of the RE modules fail and the backup saved our bacon. There was a bad batch of SSD drive components that caused issues and the card to crash. I’ve also seen an upgrade fail and the disk not format correctly rendering the card useless. Again very remote possibility of happenin

Re: [j-nsp] EX4550 apparently dropping IPv6 RA

I thought that was standard operating procedure for the systems guys to blame the network? :) On Jun 17, 2014, at 1:59 PM, Morgan McLean wrote: > If I had a dollar for every time the systems guys changed something and > then cried to neteng... :) > > Thanks, > Morgan > > > On Mon, Jun 16, 2

Re: [j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces

ilto:juniper-nsp-boun...@puck.nether.net] On Behalf >> Of Scott Granados >> Sent: Wednesday, June 11, 2014 11:13 AM >> To: juniper-nsp@puck.nether.net >> Subject: [j-nsp] Question about inline flow sampling on MX 480 / Treo >> based interfaces >> >> Wha

[j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces

Hi, I am configuring flow sampling for traffic analysis on several MX480 routers with Treo based cards. Right now I have the sample rate set to 1:1000 and things are working / flow data is being generated. My question is is there a rule of thumb or guideline to what sample rate is saf