Description

This article describes the issue of incorrect binding of the interfaces with the security zones and Routing instances resulting in the commit check-out failure.

Symptoms

The following example illustrates the commit check-out failure:

root@SRX-3# show
## Last changed: 2013-01-22 05:45:14 UTC
version 12.1R1.9;
system {
     root-authentication {
         encrypted-password " $ABC123 "; ## SECRET-DATA
     }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.10.3.3/24;
        }
    }
}
ge-0/0/1 {
     unit 0 {
         family inet {
             address 30.17.56.33/24;
         }
     }
}
ge-0/0/2 {
     unit 0 {
         family inet {
             address 172.30.12.33/24;
         }
     }
}
}
security {
     zones {
         security-zone trust {
             host-inbound-traffic {
                 system-services {
                     all;
                 }
protocols {
    all;
 }
             }
interfaces {
    ge-0/0/0.0;
    ge-0/0/1.0;
}
     }
security-zone DMZ {
    host-inbound-traffic {
        system-services {
            all;
        }
protocols {
    all;
}
    }
interfaces {
    ge-0/0/2.0;
}
}
}
}
routing-instances {
    VR1 {
        instance-type virtual-router;
        interface ge-0/0/1.0;
        interface ge-0/0/2.0;
    }
}



root@SRX-3# commit check
[edit security zones security-zone trust]
'interfaces ge-0/0/1.0'
Interface ge-0/0/1.0 must be in the same routing instance as other interfaces in the zone
error: configuration check-out failed

Solution

The ge-0/0/1.0 and ge-0/0/0.0 interfaces belong to the trust security zone trust and ge-0/0/0.0 is in the Primary routing instance (as it is not explicitly configured in a routing instance); whereas ge-0/0/1.0 belongs to the VR1 virtual router.

The ge-0/0/2.0 interface is configured in the DMZ  security zone and the VR1 virtual router.

The interfaces that belong to a particular security zone should be in the same routing Instance; whereas the interfaces in a single Routing Instance can belong to different security zones. This can be confirmed by deactivating the ge-0/0/1.0 interface in the instance, as well as the security zone hierarchy.

root@SRX-3# deactivate interfaces ge-0/0/1.0

[edit security zones security-zone trust]

root@SRX-3# deactivate interfaces ge-0/0/1.0


root@240-POE-5# commit check
configuration check succeeds