Applies To:
Show Versions
BIG-IP AAM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP APM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP GTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP Link Controller
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP LTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP AFM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP PEM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP ASM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Working with Partitions
What is an administrative partition?
An administrative partition is a logical container that you create, containing a defined set of BIG-IP® system objects. If you have the Administrator or User Manager user role assigned to the BIG-IP system user account, you can create administrative partitions to control other users’ access to BIG-IP objects. More specifically, when a specific set of objects resides in a partition, you can give certain users the authority to view and manage the objects in that partition only, rather than to all objects on the BIG-IP system. This gives a finer granularity of administrative control.
The following illustration shows an example of user objects within partitions on the BIG-IP system.
Sample administrative partitions on the BIG-IP system
For every administrative partition on the BIG-IP system, the BIG-IP system creates an equivalent high-level folder with an equivalent name.
About partition Common
During BIG-IP® system installation, the system automatically creates a partition named Common. At a minimum, this partition contains all of the BIG-IP objects that the system creates as part of the installation process.
Until you create other partitions on the system, all objects that you or other users create automatically reside in partition Common. If you create other partitions later, you cannot move an object in Common to one of the new partitions. Instead, you must delete the object from Common and recreate it in the new partition.
With respect to permissions, all users on the system except those with a user role of No Access have read access to objects in partition Common, and by default, partition Common is their current partition.
Some users, such as those with the user role of Administrator, can also create, update, and delete objects in partition Common. No user can delete partition Common itself.
About the current partition
The current partition is the specific partition to which the system is currently set for a logged-in user.
A user who has permission to access all partitions can actively select the current partition, that is, the specific partition he or she wants to view or manage. A user who has permission to access one partition only cannot actively select the current partition; the system sets the current partition for that user when he or she logs in to the system. For example:
- If user rsmith has a role of Manager and has access to all partitions on the system, then before creating or managing any object on the BIG-IP® system, she must select the partition that she wants to be the current partition. After selecting the current partition, any object that she creates will reside in that partition, and she can modify or delete only those objects that reside in the current partition.
- Conversely, if user rsmith has the role of Manager and is granted access to partition A only, then any object that she creates while logged into the BIG-IP system resides in partition A. Although she can view objects in partition Common, she cannot select Common as her current partition because she has read access only for that partition. For user rsmith, partition A is automatically her current partition, and she cannot change the current partition to create objects in another partition.
Relationship of partitions to user accounts
Partitions have a special relationship to user accounts. With respect to partitions and user accounts, you can:
- Assign partition access to user accounts
- You can configure a user account to grant the user access to a specific partition. A partition access assignment gives a user some level of access to the specified partition. As an option, for all user roles, you can assign universal access to partitions. This grants users permission to access all partitions instead of one non-Common partition only. Note that assigning partition access to a user does not necessarily give the user full access to all objects in the partition; the user role assigned to the user determines the type of access that the user has to each type of object in the partition.
- Create user accounts as partitioned objects
- Like other types of objects on the system, user account objects also reside in partitions. Placing user account objects into partitions controls other users’ administrative access to those user accounts. Also, like other object types, a BIG-IP® system user account cannot reside in more than one partition simultaneously. Note that when you first install the BIG-IP system, every existing user account (root and admin) resides in partition Common. Note that the partition in which a user account object resides does not affect the partition or partitions to which that user is granted access to manage other BIG-IP objects
Relationship of partitions to user accounts
Object referencing between partitions
Certain BIG-IP® system objects, such as virtual servers, always reference other objects. Examples of objects that a virtual server can reference are pools, profiles, and iRules®. On BIG-IP system, there are specific validation rules for object referencing with respect to the administrative partitions in which those objects reside.
Valid object referencing
Normally, when you create BIG-IP objects, a referenced object must reside either in the same partition as the object that is referencing it, or in partition Common. For example, this figure shows a valid object-referencing configuration where a virtual server and the pool it references reside in the same partition (named my_app):
Example of object referencing within a partition
Another valid object referencing case is when the object resides in one partition, while the object it references resides in partition Common. This figure shows an example of this configuration, where a virtual server in partition my_app references a pool in partition Common:
Example of object referencing from another partition to Common
In addition to these two valid object referencing configurations, the system also allows a third type of object referencing, specifically regarding iRules. That is, an iRule can reference any object, regardless of the partition in which the referenced object resides. For example, an iRule that resides in partition my_app_A can contain a pool statement that specifies a pool residing in partition my_app_B. Neither object is required to reside in Common.
Invalid object referencing
This figure shows an example of an invalid object-referencing configuration, where a virtual server resides in partition Common, but the pool the virtual server references resides in a different partition. In this case, the virtual server cannot successfully forward traffic to the pool that it is referencing:
Example of object referencing from Common to another partition
