I am trying to understand the configuration points surrounding service graph template to insert a load-balancing service between 2 EPG's. Please let me know if my understanding is correct:
. When creating a service graph template, indicate "2-Arm mode" will create 2 logical interfaces "Internal" and "External". Traffic through the "External" interface will be tagged with a Vlan from the pool and placed into the "Consumer EPG" and traffic through the "Internal" interface will also be tagged with a different Vlan from the pool and be placed into the "Provider EPG".
. a Load-balancer can provide service to multiple VIP's by creating multiple Service Template and insert those between different "Provider" and "Consumer" EPG pair?
In my understanding the Service Graph is a template you can use it to render LB (now they call it ADC) specific services.
A SG template is abstract logic component, when you apply a SG for speicific EPGs (with contract) it will let you select concrete device, that is when the real hardware resource are reserved and configured for the service. You can apply same SG template to multiple different EPGs for different services requiring LB.
From ADC itself perspective, the VIPs can be in same pool for different services (real servers), you can also do multiple contexts for different VIPs, it is irrelevant with the SG in my understanding.
In our case, we are running ADC in unmanaged mode, so the SG is only used to redirect traffics to the ADC/context. Configuration on ADC is done by its own management system.
Hi Fei Li,
So when you apply the same SG template to different EPGs, are the self-IP addresses for the external and internal interfaces changed?
And you mentioned ADC runs in unmanaged mode, so why do you need SG? From my understanding, you only need to configure the "network" portion of the ADC with EPG and BD.
For the interfaces yes it changes if you use different concrete devices.
SG is a method the fabric redirects traffics to your ADC, it can configure your ADC (managed mode) but it is optional.
In managed mode, after SG is appiled, the VIP pool information, the real servers EPG you specified during the configuration will be parsed as varabiles to device package function and then ADC configuration is automated by the device package. somehow, the VIP/Real mapping automatically happens but you still need set some figures in the SG configuration. For example, if you apply a SG with firewall service in transparent mode, you have to specifiy the bridge-group IP address for the firewall then APIC uses device package generates the firewall configuration and applies it. If you don't put the required figures for APIC to setup a firewall, SG is applied with fault and won't work.
With unmanaged mode, you still need tell fabric to send traffics between real servers and clients, they are both fabric logic components and you cannot (or very difficut) send the traffics by tunning Vlan/IGP. SG here automates the traffic steering part for you, because when you select concrete device for the SG, APIC knows the fabric interface you are on (in virtualised device case, it knows your DVS/AVS portgroup) and then stitches the BDs and interface encap Vlans for you. you probably can do this by mannually assign Vlan/Vxlan to the physical leaf ports where your L4-7 devices are connected, but it would not be a happy job to do so.
Hi Fei Li, In all of the F5 and ACI integration videos that I have seen, they all put the external Self-IP and Internal Self-IP in the same subnets as the Consumer and Provider. If this is the case, then when you want to load-balance for different Consumer and Provider subnets, then you have to change the External Self-IP and Internal Self-IP to match? Can you have the External Self-IP and Internal-Self IP of the load balancer in their own subnets so you don't have to change from graph to graph?
The ExternalSelfIP and InternalSelfIP addresses are the interface IP of ADC in two armed mode. When you apply the SG template to a specific set of EPGs on APIC, you will have to enter these IP addresses by yourself. It is required everytime when you render the SG template (to concrete devices), these IP addresses will be passed to device package by APIC as varables and ADC device local configuration then is generated by device package and implemented locally on the ADC device.
If you are re-using a existing rendered SG contract there is no configuration change on the ADC device, I think you will not need to reconfigure these settings for ADC.
Additionally, you can treat device package is an optional component in SG: When the L4-7 device is managed device, ACI SG uses device package to build a communication bridge to the L4-7 device, otherwise in unmanaged mode, SG does not talk with L4-7 device at all. The automation part on L4-L7 devices mainly is function of device package, rather than APIC.