SRX

Since I run a default-deny policy for my equipment, there are zones that have no egress policies set.  However I have discovered that if I set a policy for "from zone blah to zone blah2" then delete it, Junos won't let me have no policy.

root# commit
[edit security policies]
  'from-zone DROPUB to-zone untrust'
    Missing mandatory statement: 'policy'
error: commit failed: (missing mandatory statements)

and if I look:

root# edit security policies from-zone DROPUB to-zone untrust

{primary:node0}[edit security policies from-zone DROPUB to-zone untrust]
root# show
## Warning: missing mandatory statement(s): 'policy'

{primary:node0}[edit security policies from-zone DROPUB to-zone untrust]

yet clearly I have lots of other policy zones that have no policies and the system previously committed just fine.  Is this a bug or what?  What's my best option then?  Create some obscure stand-alone policy?  Gah, more retard logic from Juniper....

Yep so I created

policy just-a-placeholder {
    match {
        source-address any;
        destination-address any;
        application junos-bootps;
    }
    then {
        deny;
    }
}

dumb dumb dumb

Oh, i'll be danged here is what the deal is incase anyone else runs into it.  When you define that first context (edit security policy from-zone bob to-zone ed) with the default-deny the system expects a policy for the context.

Issuing the command:

"delete security policies from-zone bob to-zone ed"

deletes the policies AND the context and then everything is happy and commits. 

Still silly if you ask me. LOL

It's really just a convention.

If you're going to have a definition for policies between zone A and zone B, then Junos is going to expect to see a policy there.

By creating that definition, you're saying "I want some polices between these zones," so it's going to complain if there aren't any policies.  

If you don't want any policies between zone A and zone B, then you don't create the definition for polices between those zones.

-kr

I think the logic is flaky at best.  If you have a default-deny environment, then the default action when you delete the last policy from a context is to destroy the context.  At the very least the error message is misleading and should be altered to warn that the context exists and expects at least *A* policy. 

I think you are nit picking on this one..

When you go to commit it validates the config as a whole.. you created an incomplete config item so it complained...