ExtremeXOS Network-Zone support allows you to create a network-zone, add multiple IP addresses and/or MAC addresses to it, and use the network-zone in policy files.
This feature provides the ability to add a single attribute “source-zone,” or “destination-zone” to an entry of a policy file. This entry is then expanded into multiple entries depending upon the number of IP and/or MAC addresses configured in that particular zone. If the zone is added to the policy with the keyword “source-zone,” the attributes that are configured in that particular zone are added as either a “source-address” or an “ethernet-source-address” in the policy. Conversely, if the network-zone is added as a “destination-zone,” the attributes are added to the policies as a “destination-address,” or an “ethernet-destination-address.”
After you make changes in the zones and issue a refresh of a specific zone, or all the zones, the policies that have the corresponding zones configured as source-zone or destination-zone in their entries are expanded and refreshed in the hardware.
If you configure the following policy to a port or VLAN (Virtual LAN), or through applications like IdMgr or Extreme Network Virtualization (XNV),
Print
this page
Email this topic
Feedback
View PDF
Download EPUB
Policy: test
entry e1 {
if match all {
source-zone zone1 ;
}
Then {
permit ;
}
}
and the network-zone “zone1” that is part of the policy is configured as below:
create access-list network-zone zone1 configure access-list network-zone zone1 add ipaddress 10.1.1.1 255.255.255.255 configure access-list network-zone zone1 add ipaddress 10.1.1.1 255.255.255.240 configure access-list network-zone zone1 add ipaddress 12.1.1.0 255.255.255.0
When you refresh the network-zone “zone1,” the policy is expanded as follows, and is applied in the hardware:
entry Cl0:0_10.1.1.1_E1 {
if match all {
source-address 10.1.1.1 / 32 ;
} then {
permit ;
}
}
entry Cl0:0_10.1.1.1_E2 {
if match all {
source-address 10.1.1.1 / 28 ;
} then {
permit ;
}
}
entry Cl0:0_12.1.1.0_E3 {
if match all {
source-address 12.1.1.0 / 24 ;
} then {
permit ;
}
}
When the policy is configured with the network-zone, the zone may or may not have attributes configured in it. In cases where the network-zone does not have any attributes, the policy is created with entries that do not have the network-zone attribute alone.
So, if you create the following policy:
Policy: test2
entry e1 {
if match all {
source-zone zone2 ;
protocol udp ;
}
Then {
permit ;
}
}
entry e2 {
if match all {
protocol tcp ;
}
Then {
permit ;
}
}
And the network-zone “zone2” is just created, but is not configured with any attributes, the policy appears as follows and has only the second entry “e2,” and not “e1”.
entry e2 {
protocol tcp;
}
Then {
permit;
}
}
Once the network-zone “zone2” is configured with one or more attributes, and refreshed, the policy is updated accordingly. In this instance, the name of the entries that have a source-zone or a destination-zone are changed. This is because each entry in the original policy that has a source-zone/destination-zone is converted to a maximum of eight entries in the new policy.
A single policy can have one or more network-zones configured in it. It can also have the same network-zone in multiple entries with different combinations, as well as support for other attributes in the policy file. Similarly, the same network-zone can be configured to multiple policies. In cases where the policy has multiple network-zones, and only some of those network-zones are refreshed, the entries that correspond to those specific network-zones are alone refreshed, and not entries that correspond to the other network-zones.
After you refresh a network-zone, all the policies that have the specified network-zone are modified, and a refresh for each of those policies is sent to the hardware. The command succeeds only after receiving a successful return for all the policies that have this particular network-zone. If for some reason one of the policy‘s refresh fails in the hardware, all the policies that are supposed to refresh are reverted back to their previous successful state, and the command is rejected.
Additionally, the configuration or refresh can fail if the attributes in the network-zone are not compatible with the attributes in the corresponding entries of the policy. For example, in platforms that do not support wide-key or UDF, a policy entry cannot have Layer 2 attributes and Layer4 attributes. In such cases, if the entry has “protocol tcp” and a network-zone that has an ethernet source address, the configuration fails in the hardware.
In cases where the refresh fails, the content of the policy and the content of the network-zone may go out of sync, because the policy reverts back to the last successful state, whereas the network-zone will contain the last configured values.
Here is an example:
create access-list network-zone zone1 configure access-list network-zone zone1 add ipaddress 10.1.1.1/32 configure access-list network-zone zone1 add ipaddress 10.1.1.1/28
Once this configuration is refreshed and is successfully installed in the hardware, the policy will look like the following:
entry Cl0:0_10.1.1.1_E1 {
if match all {
source-address 10.1.1.1 / 32 ;
} then {
permit ;
}
}
entry Cl0:0_10.1.1.1_E2 {
if match all {
source-address 10.1.1.1 / 28 ;
} then {
permit ;
}
}
If you remove 10.1.1.1/28, and adds 10.1.1.1/24 to the network-zone and perform a refresh,
configure access-list network-zone zone1 delete ipaddress 10.1.1.1/28 configure access-list network-zone zone1 add ipaddress 12.1.1.0/24
and if for some reason the policy refresh fails, the policy and the network-zone will look like this:
entry Cl0:0_10.1.1.1_E1 {
if match all {
source-address 10.1.1.1 / 32 ;
} then {
permit ;
}
}
entry Cl0:0_10.1.1.1_E2 {
if match all {
source-address 10.1.1.1 / 28 ;
} then {
permit ;
}
}
create access-list network-zone zone1
configure access-list network-zone zone1 add ipaddress 10.1.1.1 255.255.255.255
configure access-list network-zone zone1 add ipaddress 12.1.1.0 255.255.255.0