Hi Wayne, Thanks for this - that's actually a really good solution I hadn't even considered - I can take it a step further and use wildcards on the zone to solve my multiple address-book on a single zone request:
set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book address U-HOST1 200.1.1.1/32 set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book address U-HOST2 200.1.1.2/32 set groups HQ-UNTRUST-HOSTS security zones security-zone <*> address-book address U-HOST3 200.1.1.3/32 set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book address D-HOST1 100.1.1.1/32 set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book address D-HOST2 100.1.1.2/32 set groups HQ-DMZ-HOSTS security zones security-zone <*> address-book address D-HOST3 100.1.1.3/32 set security zones security-zone WAN apply-groups [HQ-UNTRUST-HOSTS HQ-DMZ-HOSTS] Neat! On 12/06/2012, at 12:49 PM, Wayne Tucker wrote: > On Mon, Jun 11, 2012 at 5:04 PM, Ben Dale <bd...@comlinx.com.au> wrote: > What would really help though is if Junos allowed multiple address-books to > be bound to a single zone - that way, SRXs buried deeper in your network > would have access to all address-book entries on a single upstream zone with > very little configuration management. I'm sure this concept would make tools > like Space and NSM easier to use as well - Juniper SRX PLMs are you listening > out there? SAVE US! > > > It takes some getting used to, but this can be accomplished through > configuration groups: > > Here's a vanilla address book on a Junos 10.4 box: > > # show security zones security-zone trust address-book > address ironman 192.168.0.16/32; > address knife 192.168.0.8/32; > > Create a couple of groups and apply them: > > # set groups group1 security zones security-zone trust address-book address > address1 192.168.0.1/32 > # set groups group2 security zones security-zone trust address-book address > address2 192.168.0.1/32 > # set apply-groups [ group1 group2 ] > > And now the address book contains the additional entries: > > # show security zones security-zone trust address-book | display inheritance > address ironman 192.168.0.16/32; > address knife 192.168.0.8/32; > address inet6:sandman 2001:470:ea7c:0:221:6aff:fe66:bdcc/128; > ## > ## 'address1' was inherited from group 'group1' > ## '192.168.0.1/32' was inherited from group 'group1' > ## > address address1 192.168.0.1/32; > ## > ## 'address2' was inherited from group 'group2' > ## '192.168.0.1/32' was inherited from group 'group2' > ## > address address2 192.168.0.1/32; > > An added bonus of having the address book (or almost other configuration) in > a group is that you can use "load replace" (or the equivalent in the XML API) > to keep it consistent when you distribute it around. Add a few more layers > and you could have a fully fledged system for managing any configuration bits > on a device. > > :w > > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
