[j-nsp] Re: Interfaces, deactivate vs disable

[Eric Van Tol]

This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list?  should they be accepted or
denied?

See PR59806 for pitfalls of this idea.  While I agree that empty
prefix-lists can be helpful, one of our support techs made a grave
mistake when deleting the last prefix out of a prefix-list that was
referenced in a firewall filter.  Junos did not issue an error and let
him commit the config, but then proceeded to deny all traffic transiting
the interfaces on which the filter was applied.

-evt

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Wednesday, June 08, 2005 12:46 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Re: Interfaces, deactivate vs disable

On Wed, Jun 08, 2005 at 06:06:04PM +0200, Daniel Roesen wrote:
> On Wed, Jun 08, 2005 at 05:56:04PM +0200, Johannes Resch wrote:
> > also, it would be really helpful if "disable" used on a physical
> > interface also disabled the physical layer. (as opposed to
deactivating
> > the whole PIC to disable L1 functionality - which is not really an
option
> > on PICs with more than 1 port)
> 
> Absolutely, a great annoyance right now that you cannot disable L1
> properly.
> 
> And while we're at it, I (and many others) still way for "disable" on
> BGP groups and neighbors. :-)

Yes please, and yes please. It is pretty darn annoying not being able to

turn off the laser or make the port stop being green without powering
off 
the entire PIC, confuses the heck out of remote hands monkeys.

It is also pretty darn annoying that you have to deactivate an entire 
group when you deactivate its only/last remaining neighbor, leads to a
lot 
of weird corner cases with automated config management that just
shouldn't 
be.

While we're on the subject of small silly but annoying things, fix the 
empty prefix-list problem too. :P Sometimes I want a prefix-list to be 
empty (so that it can be easily filled with something later), and if I
am 
referencing it in a standardized config I can't deactivate it without
also 
breaking the policy that references it. The only work around it to 
intentionally put junk data in, and reserve a prefix on which the junk 
data can be applied harmlessly, which is just plain stupid. :)

Oh and can't we find the guy who wrote the firewall language and the guy

who wrote the policy language and lock them in the same room together 
until they add a termless "then whatever" default action that ALWAYS
STAYS 
ON THE BOTTOM to the firewall filters. Inserting the "default action"
term 
to the bottom after adding every new term is a pain in the ass.

Bleh must stop asking for easy things, will just make me disappointed
when 
I don't get them. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp