The BIG-IP system comes with a number of profiles straight of the box. Depending on your needs, these could be good go as they are. You can, of course, create your own custom profile should you need to tweak any setting according to your needs. This is the second part of a series to look at profiles on the BIG-IP system. The previous post looked at the Stream profile. This post will briefly take a look at the concept of child and parent profile relationships and inheritance.
Another key concept in this relationship is that of inheritance. Within inheritance any custom profile created will initially inherit all the settings from the parent profile. Any changes made to the parent profile will automatically trickle down to any child profile using that parent profile. If you have multiple layers of custom profiles whereby a custom profile is used as a parent, inheritance will trickle all the way down from the default profile unless you have overridden any settings in the custom profiles as explained below.
The following diagram illustrates the concept of the parent-child relationship and that of inheritance.
The diagram above shows three levels of profiles. We can see that in the middle tier we have a number of custom profiles that use the default profile as their parent. We then have the lower tier profiles that use the middle tier custom profiles as their parent.
When you create a custom profile you have next to each setting a check box:
The process of customising a setting on any custom profile automatically removes its ability to inherit that setting from its parent for that specific setting, meaning that modifying the parent's setting will have no effect on the child.
When you initially create a custom profile you are presented with one more of the default profiles that come pre-built for the service/type of profile you need to create. You are therefore restricted to choosing an appropriate default profile for the type of profile you are creating.
Although this may seem obvious it's worth mentioning that inheritance only works from top to bottom. Modifying a child profile does not affect the parent profile in any way.
Custom Profile 1:
Custom Profile 2:
Now if we apply custom profile 1 to our virtual server we can observe the absence of the Accept-Encoding header which should sit just below the Accept-Language header:
Finally if we apply the second custom profile we can observe the Accept-Encoding header is now back and we have a new custom header called New-Header:
Thanks for reading.
Custom and Parent Profiles
When creating a custom profile you have to specify a parent profile that the custom profile will inherit the base settings from. This parent-child relationship is fundamental to pretty much all profiles on a BIG-IP system and is important to understand.Another key concept in this relationship is that of inheritance. Within inheritance any custom profile created will initially inherit all the settings from the parent profile. Any changes made to the parent profile will automatically trickle down to any child profile using that parent profile. If you have multiple layers of custom profiles whereby a custom profile is used as a parent, inheritance will trickle all the way down from the default profile unless you have overridden any settings in the custom profiles as explained below.
The following diagram illustrates the concept of the parent-child relationship and that of inheritance.
The diagram above shows three levels of profiles. We can see that in the middle tier we have a number of custom profiles that use the default profile as their parent. We then have the lower tier profiles that use the middle tier custom profiles as their parent.
When you create a custom profile you have next to each setting a check box:
When you initially create a custom profile you are presented with one more of the default profiles that come pre-built for the service/type of profile you need to create. You are therefore restricted to choosing an appropriate default profile for the type of profile you are creating.
Although this may seem obvious it's worth mentioning that inheritance only works from top to bottom. Modifying a child profile does not affect the parent profile in any way.
Configuration
We'll do a simple example here just to demonstrate the concept. I am going to create two custom HTTP profiles:- The first one will be the child of the default HTTP profile.
- The second the child of the first custom HTTP profile.
- The first custom profile will remove the Accept-Encoding Request Header
- The second custom profile will add a new custom header and add the Accept-Encoding header back in
Custom Profile 1:
Custom Profile 2:
Now if we apply custom profile 1 to our virtual server we can observe the absence of the Accept-Encoding header which should sit just below the Accept-Language header:
Finally if we apply the second custom profile we can observe the Accept-Encoding header is now back and we have a new custom header called New-Header:
Summary
In my opinion using a custom profile is the better way to go rather than using the default profiles as it allows you to modify the settings should you require. If you do then having an understanding of inheritance is important to ensuring you get the desired results from the profile.Thanks for reading.