Karsten Thomann via juniper-nsp writes: >Who can get a message over to the Documentation group, it would >be great if you could update the doc on the "insert" command to >note that you have to create the object first, and then move it >with the insert. > >May be common knowledge to old hands, but I'm still learning the >ins and outs of JunOS. Looking at the doc, it seems that the order >of operations would be this: > >edit firewall family inet filter foo >insert term bar before term xyzzy >error: statement 'bar' not found > >But it's actually this: > >edit firewall family inet filter foo >set term bar from source-prefix-list source >set term bar from destination-prefix-list dest >set term bar from protocol tcp >set term bar from destination-port ssh >insert term bar before term xyzzy
This is fallout from the fact that "term bar" is a statement that can't exist without contents. Internally we call these "remove-empty" and in the YANG terminology, they are called an equally-cryptic "non-presence container". But the results are the same: you can't have an empty "term": [edit firewall filter foo] user@cli# set term bar ^ missing argument. [edit firewall filter foo] user@cli# set term bar ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups filter Filter to include > from Define match criteria > then Action to take if the 'from' condition is matched [edit firewall filter foo] user@cli# set term bar There must be something inside "term" for it to make any sense. When you delete the last item under a "term", the "term" is removed automatically. In comparison, a non-remove-empty statement, like "ip-options" does the "create on insert" behavior that you're after. [edit firewall filter foo term last] user@cli# insert from ip-options stream-id before route-record [edit firewall filter foo term last] user@cli# show from { ip-options [ stream-id route-record ]; } If we allowed "insert term new-term before term old-term", then we'd make it and immediately remove it, which would be quite annoying. So we prevent the referencing of non-existent remove-empty statements. I'll pass all this along to the doc team so we can make it more clear in the documentation. Thanks, Phil _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp