In the previous blog, we read about how BIG-IP and its modules can be used to consolidate critical network operations – from load balancing to application security to identity and access management and much more. We started with the most basic and most important module, the LTM, and went on to detail the different objects of an LTM structure… let’s continue.
What if you have a VIP but don’t want traffic to be routed to a member of one of your BIG-IP pools? What if you wanted to send traffic to a certain server based on its IP address, regardless of whether that server is part of your configuration, exists behind your BIG-IP, or belongs to a pool? The concept of a node is as follows – any destination IP to which traffic should be directed is referred to as a node. It’s not treated as a pool; no load balancing decisions are taken, no monitoring is performed; it’s more of a “fire and forget” approach. It has various applications, however, it is not recommended for the bulk of traffic flow in a typical application.
Much of the processing for each session that is established and travels via the BIG-IP is done using profiles. A VIP’s profile determines what type of traffic is expected, such as TCP or UDP, whether SSL offloading will be done on the client-side, which SSL profile will be used if it is, whether a specific protocol, such as HTTP or SIP, will be used, whether ONECONNECT will be enabled, and much more. Consider the profile associated with the VIP as the control center that tags, inspects, interprets, and categorizes the traffic once it arrives if the VIP is the destination for your application traffic.
A profile is necessary for a variety of reasons, especially because certain iRules commands are only available to VIPs who have particular profiles applied. The popular and often used HTTP commands, for example, are only available on VIPs who have an HTTP profile applied. This is because, as I previously stated, the VIP profile performs a significant amount of processing, and the instructions rely on some of the data obtained as a result of that processing and interrogation. When it comes to F5 technology, there are many distinct types of profiles. SSL profiles, Auth profiles, Protocol profiles, and other options are available. The premise is the same for all, but the details and outcomes change.
Other important terms to understand
The BIG-IP is a comprehensive proxy architecture, which implies that each side of the proxy – the client and the server, has its own IP stack. This means that as traffic passes through the BIG-IP, it is transferred from one stack to the other at some point, and vice versa on server-to-client answers. It’s crucial to understand if you’re seeking to or needing to affect client-side or server-side traffic in order to achieve your goals.
Something that happens on the server-side of the proxy architecture is referred to as server-side. This is normally how application servers respond, but keep in mind that the client and server sides of the transaction are fully dependent on which side of the proxy initiates the transaction. If a server in a pool uses your BIG-IP to conduct an activity on its own, that server is now the “client” for the purposes of the proxy discussion, and it is on the client-side of the transaction, despite the fact that it is a server.
Traffic Management Microkernel (TMM)
The Traffic Management Microkernel (TMM) is a microkernel for traffic management. It’s a custom kernel built by F5, particularly for traffic processing and routing. It was built from the ground up to be high-performing, dependable, and adaptable to our requirements. On any BIG-IP, the TMM is in charge of all traffic processing. It all happens within the TMM, whether it’s an iRule being run, a profile analyzing traffic as it passes through a VIP, or just about anything else that impacts traffic as it passes through an F5 device.
Check NetOps can easily provision application services on an F5 LTM using ADC+
F5 LTM Objects and meaning of their status
Green – The presence of a green circle indicates that an object is available and online.
Blue – A blue square indicates that the status of an object is unknown. It could be the result of a configuration error or a failed service check.
Red – The red diamond indicates that an object is inaccessible or offline. This happens when the object can’t be reached or isn’t listening for a specific service.
Yellow Triangle — The object is now unavailable, but it may become available without any user intervention at a later time.
Black – Objects that are disabled are indicated by black icons. It can be one of three x types: black circle (available but disabled), black diamond (unavailable but disabled), or black square (unavailable but disabled) (object unknown and disabled).
Grey – When a parent object is disabled or a connected object is unavailable, grey icons appear.
In the next blog, we’ll look into iRules as automation technology, including how they function, why they exist, and how to utilize them.