Welcome

F5 configuration analyzer.

Partition	Full path	Destination	Pool	iRules	Profiles	Source NAT	Enabled
klausbot	/klausbot/vs_corp-finance-dashboard_http	/klausbot/172.31.11.221:80		/Common/_sys_https_redirect	/Common/http,/Common/tcp	none	Yes
klausbot	/klausbot/vs_corp-finance-dashboard_https	/klausbot/172.31.11.221:443	/klausbot/pool_corp-finance-dashboard_web		/Common/http,/Common/tcp,/klausbot/clientssl_f5demo	automap	Yes
klausbot	/klausbot/vs_corp-hr-portal_http	/klausbot/172.31.11.220:80		/Common/_sys_https_redirect	/Common/http,/Common/tcp	none	Yes
klausbot	/klausbot/vs_corp-hr-portal_https	/klausbot/172.31.11.220:443	/klausbot/pool_corp-hr-portal_web		/Common/http,/Common/tcp,/klausbot/clientssl_f5demo	automap	Yes
klausbot	/klausbot/vs_corp-intranet_http	/klausbot/172.31.11.222:80		/Common/_sys_https_redirect	/Common/http,/Common/tcp	none	Yes
klausbot	/klausbot/vs_corp-intranet_https	/klausbot/172.31.11.222:443	/klausbot/pool_corp-intranet_web		/Common/http,/Common/tcp,/klausbot/clientssl_f5demo	automap	Yes
klausbot	/klausbot/vs_corp-service-desk_http	/klausbot/172.31.11.223:80		/Common/_sys_https_redirect	/Common/http,/Common/tcp	none	Yes
klausbot	/klausbot/vs_corp-service-desk_https	/klausbot/172.31.11.223:443	/klausbot/pool_corp-service-desk_web		/Common/http,/Common/tcp,/klausbot/clientssl_f5demo	automap	Yes
klausbot	/klausbot/vs_f5demo_https	/klausbot/172.31.11.204:443	/klausbot/pool_f5demo_web		/Common/http,/Common/tcp,/klausbot/clientssl_f5demo	automap	Yes


    Virtual Server
    ├─ iRule 1
    ├─ iRule 2
    ├─ Client SSL Profile
    │  ├─ Certificate
    │  └─ Private Key
    ├─ Server SSL Profile (optional)
    └─ Default Pool
    ├─ Pool Member 1
    │  └─ Node 1
    ├─ Pool Member 2
    │  └─ Node 2
    └─ Pool Member 3
    └─ Node 3

For a typical F5 BIG-IP LTM setup, the components are connected roughly like this:

Virtual Server
iRules
Profiles, including SSL profiles
Pool
Pool Members
Nodes
SSL certificate/key inside the SSL profile

A clean way to think about it is:

Traffic flow hierarchy

Client
-> Virtual Server
-> iRules / Profiles / policies applied on the Virtual Server
-> Pool
-> Pool Member
-> Node

And for TLS:

Client
-> Virtual Server
-> Client SSL Profile
-> SSL Certificate + Private Key

Optionally on server-side TLS:

Virtual Server
-> Server SSL Profile
-> trusted CA / client cert settings / server-side TLS behavior
-> Pool Member / Node

Main component relationships

Here is the direct relationship map for one Virtual Server.

A. Virtual Server
The Virtual Server is the main entry point.

It is connected to:

destination IP and port
one or more iRules
one default Pool
one or more Profiles
optionally SSL profiles
optionally persistence profiles
optionally SNAT settings
VLAN restrictions, source restrictions, etc.

So:

Virtual Server

has a destination
references a Pool
references zero or more iRules
references zero or more Profiles
may reference a Client SSL Profile
may reference a Server SSL Profile

B. iRules
iRules are attached directly to the Virtual Server.

They can:

inspect incoming requests
change pool selection
redirect requests
manipulate headers
reject/drop traffic
select a specific node or pool member
use data groups
influence SSL behavior indirectly

So:

iRule

is attached to a Virtual Server
may override the default Pool
may select a different Pool
may select a Node directly
may depend on data groups or other objects

Important:
A Virtual Server can have multiple iRules.
The order of iRules can matter.

C. Pool
The Pool is the backend group the Virtual Server sends traffic to.

It is connected to:

the Virtual Server as default target
health monitors
pool members
load-balancing method

So:

Pool

is referenced by a Virtual Server
contains Pool Members
may have one or more health Monitors
defines load-balancing behavior

D. Pool Member
A Pool Member is usually:

node + service port

Example:

Node: 10.1.1.10
Pool member: 10.1.1.10:443

So:

Pool Member

belongs to a Pool
references a Node
defines the service port for that Node within that Pool

Important:
The same Node can appear in multiple pools with different ports.

E. Node
A Node is just the backend server IP or hostname object.

So:

Node

is referenced by one or more Pool Members
represents the actual backend host address

Relationship:

Node

does not directly belong to the Virtual Server
is reached through Pool Member association
may be selected directly by iRule in some designs

F. SSL Certificate
The certificate is not normally attached directly to the Virtual Server.
It is usually attached through an SSL profile.

Relationship:

Virtual Server
-> Client SSL Profile
-> Certificate
-> Private Key

So:

SSL Certificate

belongs to a Client SSL Profile
that profile is attached to the Virtual Server

For server-side TLS:

Virtual Server
-> Server SSL Profile
-> trust / validation / client cert settings

Full connection chain

For one standard HTTPS VIP:

Virtual Server /Common/vs_app_https
iRule /Common/irule_redirect_logic
Pool /Common/pool_app_https
Pool members:
- /Common/10.10.20.11:443
- /Common/10.10.20.12:443
Nodes:
- /Common/10.10.20.11
- /Common/10.10.20.12
Client SSL Profile /Common/clientssl_app
Certificate /Common/app.example.com.crt
Key /Common/app.example.com.key

Connections:

Virtual Server /Common/vs_app_https
- uses iRule /Common/irule_redirect_logic
- uses Pool /Common/pool_app_https
- uses Client SSL Profile /Common/clientssl_app
Client SSL Profile /Common/clientssl_app
- uses certificate /Common/app.example.com.crt
- uses private key /Common/app.example.com.key
Pool /Common/pool_app_https
- contains pool member /Common/10.10.20.11:443
- contains pool member /Common/10.10.20.12:443
Pool member /Common/10.10.20.11:443
- references Node /Common/10.10.20.11
Pool member /Common/10.10.20.12:443
- references Node /Common/10.10.20.12

In graph form

You can represent it like this:

text

Virtual Server
├─ iRule 1
├─ iRule 2
├─ Client SSL Profile
│  ├─ Certificate
│  └─ Private Key
├─ Server SSL Profile (optional)
└─ Default Pool
   ├─ Pool Member 1
   │  └─ Node 1
   ├─ Pool Member 2
   │  └─ Node 2
   └─ Pool Member 3
      └─ Node 3

Important F5-specific nuances

A. Virtual Server to Pool is usually one default reference
A Virtual Server usually has:

one default pool

But:

an iRule can send traffic to a different pool
a policy can do the same

So the true runtime path can be:

Virtual Server
-> default Pool

Virtual Server
-> iRule logic
-> alternate Pool

B. Pool Member is not the same as Node
This is a very important distinction.

Node = backend host identity
Pool Member = node plus service port in a specific pool

Example:

Node: 10.10.20.11
Pool member A: 10.10.20.11:80
Pool member B: 10.10.20.11:443

Same node, different members.

C. SSL cert is usually indirect
Usually:

Virtual Server does not point directly to cert
Virtual Server points to SSL profile
SSL profile points to cert/key

D. iRules can alter the topology
Even if a Virtual Server is configured with Pool A, an iRule may:

choose Pool B
choose a specific member
reject the request
redirect client elsewhere

So from a config dependency perspective:

Virtual Server
-> iRules
-> potential Pools or Nodes referenced inside iRule code

That means if you are mapping dependencies, parsing only the Virtual Server object is not enough. You may also need to inspect iRule text.

Dependency list for one Virtual Server

If you want a concise dependency list, use this model:

Primary object:

Virtual Server

Direct dependencies:

iRules attached to the Virtual Server
default Pool referenced by the Virtual Server
SSL profiles attached to the Virtual Server
other LTM profiles attached to the Virtual Server

Indirect dependencies:

certificate and key referenced by the Client SSL Profile
pool members contained in the Pool
nodes referenced by the Pool Members
health monitors referenced by the Pool
additional pools/nodes referenced inside iRules

Example dependency table

text

Component Type      Component Name                  Connected To
Virtual Server      /Common/vs_app_https            Pool, iRules, SSL Profile
iRule               /Common/irule_redirect_logic    Virtual Server
Pool                /Common/pool_app_https          Virtual Server, Pool Members
Pool Member         /Common/10.10.20.11:443         Pool, Node
Pool Member         /Common/10.10.20.12:443         Pool, Node
Node                /Common/10.10.20.11             Pool Member
Node                /Common/10.10.20.12             Pool Member
Client SSL Profile  /Common/clientssl_app           Virtual Server, Cert, Key
Certificate         /Common/app.example.com.crt     Client SSL Profile
Private Key         /Common/app.example.com.key     Client SSL Profile

If you want to model it in C#

A useful object model would be:

text

VirtualServerDependencyGraph
- VirtualServer
- List<iRule>
- Pool
- List<PoolMember>
- List<Node>
- List<SslProfile>
- List<SslCertificate>
- List<SslKey>

Practical F5 REST endpoints for these connections

To build this mapping from REST, you typically inspect:

Virtual server:
- /mgmt/tm/ltm/virtual/<name>
Pool:
- /mgmt/tm/ltm/pool/<name>
Pool members:
- /mgmt/tm/ltm/pool/<pool>/members
Nodes:
- /mgmt/tm/ltm/node
iRules:
- /mgmt/tm/ltm/rule
SSL profiles:
- /mgmt/tm/ltm/profile/client-ssl
- /mgmt/tm/ltm/profile/server-ssl
SSL certs/keys:
- /mgmt/tm/sys/file/ssl-cert
- /mgmt/tm/sys/file/ssl-key

Short answer

The core connections are:

Virtual Server -> iRules
Virtual Server -> Pool
Pool -> Pool Members
Pool Member -> Node
Virtual Server -> SSL Profile
SSL Profile -> SSL Certificate + Private Key

And optionally:

iRule -> alternate Pool or Node
Pool -> Monitor
Virtual Server -> persistence / HTTP / TCP / SSL profiles

If you want, I can next create:

a dependency diagram in Mermaid format
C# classes representing this relationship graph
code that reads BIG-IP REST JSON and builds the graph automatically

Basic Mermaid diagram:

graph TD
    C[Client] --> VS[Virtual Server]
    
    VS --> IR1[iRule 1]
    VS --> IR2[iRule 2]
    
    VS --> CSP[Client SSL Profile]
    CSP --> CERT[SSL Certificate]
    CSP --> KEY[Private Key]
    
    VS --> SSP[Server SSL Profile]
    
    VS --> POOL[Default Pool]
    
    POOL --> MON[Health Monitor]
    
    POOL --> PM1[Pool Member 1 10.10.20.11:443]
    POOL --> PM2[Pool Member 2 10.10.20.12:443]
    
    PM1 --> N1[Node 1 10.10.20.11]
    PM2 --> N2[Node 2 10.10.20.12]

More realistic F5-oriented diagram with object names:

graph TD
    CLIENT[Client Request] --> VS["Virtual Server
    /Common/vs_app_https"]

    VS --> IR1["iRule
    /Common/irule_redirect_logic"]

    VS --> IR2["iRule
    /Common/irule_security_headers"]

    VS --> CSP["Client SSL Profile
    /Common/clientssl_app"]

    CSP --> CERT["SSL Certificate
    /Common/app.example.com.crt"]

    CSP --> KEY["SSL Private Key
    /Common/app.example.com.key"]

    VS --> SSP["Server SSL Profile
    /Common/serverssl_app"]

    VS --> POOL["Default Pool
    /Common/pool_app_https"]

    POOL --> MON1["Monitor
    /Common/https"]

    POOL --> PM1["Pool Member
    /Common/10.10.20.11:443"]

    POOL --> PM2["Pool Member
    /Common/10.10.20.12:443"]

    PM1 --> NODE1["Node
    /Common/10.10.20.11"]

    PM2 --> NODE2["Node
    /Common/10.10.20.12"]

This version shows that iRules may override the default pool selection.:

graph TD
    CLIENT[Client] --> VS[Virtual Server]

    VS --> IR[iRule]
    VS --> POOL1[Default Pool]

    IR -. may select alternate .-> POOL2[Alternate Pool]
    IR -. may select direct node .-> NODEX[Specific Node]

    POOL1 --> PM1[Pool Member 1]
    POOL1 --> PM2[Pool Member 2]

    PM1 --> N1[Node 1]
    PM2 --> N2[Node 2]

    VS --> CSSL[Client SSL Profile]
    CSSL --> CERT[Certificate]
    CSSL --> KEY[Private Key]

If you want a pure dependency graph rather than traffic flow:

graph LR
    VS[Virtual Server] --> IRULES[iRules]
    VS --> POOL[Pool]
    VS --> CLIENTSSL[Client SSL Profile]
    VS --> SERVERSSL[Server SSL Profile]

    CLIENTSSL --> CERT[SSL Certificate]
    CLIENTSSL --> KEY[Private Key]

    POOL --> MEMBERS[Pool Members]
    POOL --> MONITORS[Health Monitors]

    MEMBERS --> NODES[Nodes]

If this is for design or documentation, I’d recommend this one:

graph TD
    VS["Virtual Server"] --> IR["Attached iRules"]
    VS --> P["Default Pool"]
    VS --> CSP["Client SSL Profile"]
    VS --> SSP["Server SSL Profile (optional)"]

    CSP --> CERT["Certificate"]
    CSP --> KEY["Private Key"]

    P --> MON["Health Monitor(s)"]
    P --> PM1["Pool Member 1"]
    P --> PM2["Pool Member 2"]
    P --> PM3["Pool Member 3"]

    PM1 --> N1["Node 1"]
    PM2 --> N2["Node 2"]
    PM3 --> N3["Node 3"]

    IR -. may override .-> ALT["Alternate Pool or Node"]

If you want subgraphs
Here’s a cleaner Mermaid version using subgraphs:

graph TD
    CLIENT[Client] --> VS[Virtual Server]

    subgraph VS_CFG[Virtual Server Configuration]
        IR1[iRule 1]
        IR2[iRule 2]
        CSP[Client SSL Profile]
        SSP[Server SSL Profile]
        POOL[Default Pool]
    end

    VS --> IR1
    VS --> IR2
    VS --> CSP
    VS --> SSP
    VS --> POOL

    subgraph SSL_CFG[SSL Dependencies]
        CERT[Certificate]
        KEY[Private Key]
    end

    CSP --> CERT
    CSP --> KEY

    subgraph POOL_CFG[Pool Dependencies]
        MON[Health Monitor]
        PM1[Pool Member 1]
        PM2[Pool Member 2]
        N1[Node 1]
        N2[Node 2]
    end

    POOL --> MON
    POOL --> PM1
    POOL --> PM2
    PM1 --> N1
    PM2 --> N2