[j-nsp] large subnet/no memory

Eric Van Tol eric at atlantech.net
Mon Feb 11 15:09:03 EST 2013


> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Phil Shafer
> Sent: Monday, February 11, 2013 2:40 PM
> To: The Drifter
> Cc: Juniper TAC
> Subject: Re: [j-nsp] large subnet/no memory
> 
> The Drifter writes:
> >Sounds great. Now need to get a buy-in from  the ops folks :)
> >How would you weigh the effectiveness of using your suggestion
> versus Cristian's?
> 
> The prefix-limit statement is much simpler and more efficient for
> the specific case that it is targeting.  In contrast, commit scripts
> allow a broader range of tests and abilities, but require more work
> (writing the script, deploying it, configuring it).  If you see
> this as being an isolated instance, the prefix-limit will be the
> simpler solution.   If you see yourself defining a larger set of
> rules that all configurations should follow (sanity checks,
> co-constraints, mandatory statements, derived configuration, etc),
> then this may be your first step toward commit scripts.
> 

Someone please correct me if I'm wrong, but I read this as the OP asking about a bad mask on what I assume to be an ethernet interface, not a BGP configuration.  As such, I'm not sure what good a prefix-limit would do in this case.  The commit script seems to be the best option, IMO.

I know that JUNOS used to throw up an error when the same or overlapping subnets were configured on two different interfaces in a routing instance (in this case, 'default'), but I'm not sure whatever happened to those errors.  I personally liked them because it was easy to spot fat-finger or accidental double-allocation mistakes.

-evt



More information about the juniper-nsp mailing list