[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