Protecting Functionality

A functional zone is a unique type of zone. The SRX family has only one type of functional zone applicable to it. The management zone is designed to have a physical interface allocated to it which allows true out-of-band management. It allows an administrator to use, for example, a dedicated interface of a SRX110 for management. This is an alternative to assigning a vlan.0 interface or using console for access. This is an important consideration for branch SRX devices as they do not have a dedicated port. The EX2200-C which is used in micro and small branch deployments has one which makes me wish this SRX did.

The configuration below will assign a static address for the interface, allow administration via https and ssh, and label the use. If you wanted a dynamic allocation for this range, then DHCP must be allowed. DHCP and DNS go hand in hand and DNS must be added to the host-inbound-traffic list if utilised.

set interfaces fe-0/0/7 unit 0 family inet address
set security zones functional-zone management interfaces fe-0/0/7.0
set security zones functional-zone management host-inbound-traffic system-services ssh
set security zones functional-zone management host-inbound-traffic system-services https
set security zones functional-zone management description "OOB Management Interface"

Alright. Good start. Now the next logical step would to be to apply inbound policies for the zone. In this case we cannot do this as a functional zone does not transit traffic. A functional management zone does not forward or allow traffic to transit it. Therefore policies do not apply to it and it is not bound to the same processing as a standard security zone. With this in mind if you are using an OOB network attached to a host of SRX branch devices I would suggest tightly controlling entrance into your OOB network.

Now with this being my only point of management with my device I do not want to lock myself out. Locking myself out would cause some headaches. The ability to protect your configuration is important and with JUNOS you can do exactly that. By using the protect statement you can avoid accidentally deletion or any action that would alter a known working configuration.

protect interfaces fe-0/0/7 
protect security zones functional-zone management

By using the protect statement you actually cannot alter the protected configuration.

[email protected]# delete interfaces fe-0/0/7 
warning: [interfaces fe-0/0/7] is protected, 'interfaces fe-0/0/7' cannot be deleted

Note that if you issue a show configuration the section is marked clearly.

[email protected]# show interfaces fe-0/0/7 
## protect: interfaces fe-0/0/7
unit 0 {
family inet {

Not bad at all. This will protect my branch SRX’s from accidental slips. The fact that JUNOS is also commit based opposed to Cisco IOS instant write means you have more than apply opportunity to avoid disaster. This feature is going to get some heavy usage from now on. Very handy.

2 thoughts on “Protecting Functionality”

  1. So how do you handle routing to the rest of your network over the management interface, in this case? Wouldn’t a static route interfere with inet.0?

    I’ve typically just used a VR for a dedicated management interface.

Leave a Reply

Your email address will not be published. Required fields are marked *