connectivity of load balancer

[haim-kermany]

Hi @kyorav @zivnevo @adisos
I Want to get a clear picture of load balancer connectivity.
What we have till now:
A load balancer has:

1. list of subnets
2. list of security groups
3. two private IPs, associated with two subnets
4. zero or two public IPs
5. a list of pools
6. a list of listeners
7. each pool has a list of members
8. each listener can have a default pool
9. each listener has a list of policies, (we do not have an example of it yet)
10. pools has a protocol
11. listener has a protocol

Currently, the naive implementation is:

1. add the private IPs to the subnets
2. in case we have public IPs, add FIP to the private IPs
3. apply the load balancer security group (not implemented yet)
4. ignore all the rest
   This implementation is based on the approach that the listeners are not filters. i.e, the LB is not effecting the connectivity, beside adding private IPs (Karen please elaborate why)

I have some points for discussion:
Q1. how to apply the lb security group?
Q2. why the load balancer is not effecting the connectivity?
Q3. do we want to change the approach that LB is not effecting the connectivity?
Q4. what to do with the rest of the subnets?
Q5. do we have another report, beside connectivity, that we can reflect the LB information (listeners, pools, protocol...)?
Q6. are the private IPs connected to each other?
Q7. is a private IPs connect to a "not a pool member"

Please fill free to add questions and answers.

For easy following:
When adding a question, please start with Q
When adding an answer, please start with A

Thank you

[haim-kermany]

Q8: how is a listener associate with a pool:
A8: (from Karen) There are two ways to setup listeners with pools. Option 1 is through a (single) default pool, which means the listener is connected only to one pool. Option 2 is using "listener policies" where you can setup rules, based on L7 attributes, where to forward the request. I think that with listener policies you can connect the same listener to multiple pools, but I haven't studied these in depth yet.

[zivnevo]

A5: Currently we only analyze connectivity (diff is just a variant). Explainability is still about connectivity, but may require the LB object to provide more details. In the future we plan to have other types of analysis, such as linting and exposure analysis. See Issues #479, #478, #116

[haim-kermany]

A5: we also have ARCH_drawio (and soon arch_html), there are reports that do not show connectivity, but only the architecture.
is there a textual version of it? is it a good place to show detailed load balancer information (pools, listeners, ect...)

[kyorav]

Yes, the information about pools and listeners can be part of the architecture

[haim-kermany]

A1: currently the SG is applied on the private IPs (already implemented), Karen, please confirm its the right implementation

[kyorav]

It is

[kyorav]

"Q6. are the private IPs connected to each other?"
A6: They may theoretically connect according to the regular analysis of SGs and nACLs. In practice the LB does not require them to be able to connect and it will never send anything between these two IPs.
Should we avoid from drawing this connectivity for the sake of clarity?

"Q7. is a private IPs connect to a "not a pool member"
A7 The rules of SGs and nACLs apply on the connection between any NIF and the LB's NIFs. The LB will never initiate such a connection, but the any instance that has access to the private IP may send a request to the LB (normal operation of a LB).

[haim-kermany]

main points from the discussion today:

1. tough we have only 2 private IPs, we should put a private IP at every subnet before analyze for connectivity.
2. All private IPs should have the same connectivity. if not, it should indicate that something is not right, and it should be reflect in the report
3. for reporting, we will have also an abstract mode. in this mode, all the private ips is presented as one Node. most reports will be in in this mode.
4. PIPs can not connect each other
5. the load balancer pools and listeners is also filtering some of the connections (protocols, policies, TBD)
6. might consider an architectural report, with pools and listener details (TBD)
7. did i miss something?

[kyorav]

[kyorav]

2. All private IPs should have the same connectivity. if not, it should indicate that something is not right, and it should be reflect in the report

This is too strong a statement. It is a good linting check, but not necessary to reflect in a regular report.

I would add to item 3 that when displaying an abstract node we will add a star in the case when a connection to the abstract node is possible only to one private IP and not the other