Network Deployment Guide
This topic describes the various scenarios possible for deploying the gateway within a network. For increased organizational security, CA Technologies recommends separating service networks from management networks.
Container Gateway Users
This topic is intended for appliance-based API Gateway users. As of this writing, Kubernetes pods are set up to connect to one network interface by default via the Container Network Interface (CNI). For multiple network interface connection requirements, you may need to look to third-party vendors for extensions or plugins (e.g., Multus CNI). For other networking information related to Kubernetes, please consult Kubernetes documentation here.
If you are looking for the reference architecture for the Container Gateway deployed to the cloud, see this Techdocs topic.
This topic describes the various scenarios possible for deploying the
Layer7 API Gatewaywithin a network. For increased organizational security, Layer7 Broadcom recommends separating service networks from management networks.
CentOS 7 and Changes to Network Interface Naming Scheme
Unlike past versions of the API Gateway installed on older releases of CentOS/RHEL (i.e., 6.x or older), the traditional kernel-based network interface naming scheme (e.g., eth0, eth1, eth2) no longer applies as the default convention. Rather, to ensure more consistent and predictable network device naming for network interfaces, CentOS 7 now relies primarily on names based on Firmware or BIOS provided index numbers for on-board devices (e.g., en1) or PCI Express hotplug slot index numbers (e.g, ens1), and names based on the physical location of the hardware connector (e.g., enp0). Previously, the kernel-based names could change unpredictably if devices were removed, added, or swapped prior to a reboot.
For the operation of Gateway version 10.0+, consistent network device naming is applied differently across different Gateway form factors. Before reviewing the network deployment scenarios on this page, you must ensure that you've correctly identified your network interfaces as their kernel-based names have likely changed (i.e., eth0 is now ssg_eth0). This is especially important since Gateway version 10.0 can only be installed on CentOS 7 for the hardware/virtual appliance, AMI, and Azure form factors.
Impact on Gateway Version 10.0 Installed on Oracle X8-2, X7-2, or X5-2 Appliance
For the operation of the API Gateway on X8-2, X7-2, or X5-2 appliances, the Gateway has customized the names of all known network interfaces with the "ssg_eth#" naming convention. The following table summarizes this naming customization.
Kernel-Based Name (Pre CentOS 7)
Consistent Name (CentOS 7)
Equivalent Name Given by Gateway Ver 10.0+
Impact on Gateway Version 10.0 Installed on an Open Virtual Appliance (OVA)
For the OVA form-factor of the API Gateway, the primary network interface now adopts a consistent name (e.g., "ens160", formerly "eth0" to Gateway 8/9.x users). For the operation of the OVA API Gateway version 10.0+, this consistent name has been renamed to "ssg_eth0" by the Gateway.
Impact on Gateway Version 10.0 Installed on Amazon Machine Images (AMI) and Azure
Similar to OVA API Gateways, the same naming logic applies for the operation of Gateway version 10.0+ running on AMI using a single interface. The "ens5" (formerly "eth0" to Gateway 8/9.x users) network interface has been renamed to "ssg_eth0" by the Gateway.
For the operation of Gateway version 10.0+ running on Azure using a single interface, the "eth0" network interface has been renamed to "ssg_eth0" by the Gateway.
Impact on Firewall Rules and the API Gateway
Due to the network interface name change from the traditional "eth#", the appliances' firewall rules found in the iptables/ip6tables have also been updated to use the Gateway's "ssg_eth#" naming convention upon image deployment.
How Will Additional Network Interfaces Be Named?
If your organization requires additional network interfaces to be connected to the OVA, AMI, or Azure Gateway, be aware that the consistent naming convention of CentOS 7 still applies. How those consistent names appear will depend on the device type you're connecting. Should you require additional network interfaces, you'll need to track their consistent names manually and modify the iptables as required to adjust firewall rules.
How are the Network Configuration Files Named?
Network configuration files found in /etc/sysconfig/network-scripts/ shall retain their consistent name (e.g., "ifcg-ens160"). The Gateway will not modify the network configuration file names but will
- Change the NAME and DEVICE attributes of those files to the new "ssg_eth#" name.
- Add the HWADDR attribute with the MAC address of the network interface.
Why Do the Predicable Network Interface Names Still Appear in the Network Service Log?
This does not have any operational impact on the Gateway.
You may be confused with the appearance of a predictable network interface name (e.g., "ens160") in the network service log, despite the same interface being renamed with Gateway's "ssg_eth#' naming scheme. Because the actual network interface configuration files (ifcfg) files have retained CentOS 7's predictable interface naming scheme, those names may still appear in the network service log, as shown in the following hardware appliance Gateway example:
Dec 04 17:27:50 cpu-02.hello.broadcom.net systemd: Starting LSB: Bring up/down networking... Dec 04 17:27:51 cpu-02.hello.broadcom.net network: Bringing up loopback interface: [ OK ] Dec 04 17:27:51 cpu-02.hello.broadcom.net network: Bringing up interface eno1: [ OK ] Dec 04 17:27:51 cpu-02.hello.broadcom.net network: Bringing up interface eno1: [ OK ] Dec 04 17:27:52 cpu-02.hello.broadcom.net network: Bringing up interface enp0s20f0u8u3c2: [ OK ] Dec 04 17:27:52 cpu-02.hello.broadcom.net network: Bringing up interface enp0s20f0u8u3c2: [ OK ]
In the following network deployment scenarios, a hardware appliance form factor of Gateway version 10.0 is used.
If you are using an OVA, Azure, or AMI form factor of the Gateway, network interfaces in addition to "ssg_eth0" will use their original consistent network interface name that was assigned by the OS.
- Single domain network:All network communication is handled within the internal management LAN ("ssg_eth0").
- Two domain network:Two networks are used:
- Wide Area Network representing the public LAN ("ssg_eth1")
- two internal service LANs ("ssg_eth2" and "ssg_eth3").
- Three and four domain network:Three or more networks are used:
- Wide Area Network for the public LAN ("ssg_eth1")
- internal management LAN for the private side ("ssg_eth0")
- one or two internal service LANs ("ssg_eth2" and "ssg_eth3")
Single Domain Network
Use the single network configuration in scenarios where there is no need to separate management from message and back end traffic. For example, the Gateway is used for proof of concept, development, and testing setups, or in an ESB deployment. In this configuration, all networking occurs within the internal management LAN (ssg_eth0).
The single network configuration is simple and straightforward, but is not a common production deployment.
The following diagram illustrates the components within a single network configuration.
Two Domain Network
The two domain network is used in more complex layouts, where the service consumers are separate from the services that are protected by the Gateway cluster. In this layout, the services and resources are connected to the internal service LANs (ssg_eth2, ssg_eth3)
,while the "public side" is connected to the WAN (ssg_eth1).
This layout assumes that no workstations on the public side are allowed to access management functions. You can use a load balancer on the public side to provide load sharing and high availability.
The following diagram illustrates the components within a two domain network configuration.
Three and Four Domain Network
In high security environments, management workstations are separated from services networks. In this multi-network setting, the "public side" is expected to have a load balancer and be on the WAN (ssg_eth1)
.The management network is on the internal management LAN (ssg_eth0). The service networks are on the internal service LANs (ssg_eth2, ssg_eth3). This means there is no direct access from management nodes to the service systems, except through the Gateway cluster.
The following diagram illustrates how to separate web services from corporate resources using all four network interfaces.
Installing Additional Network Interfaces to An Existing Gateway 10.x Appliance on CentOS 7
After successfully installing Gateway version 10.x on your CentOS 7 machine and configuring the required network interfaces at the time of installation with the SSG Configuration menu, you may need to add one or more network interfaces later on. In order for the Gateway configuration to detect the new network interface with the 'ssg_eth#' naming scheme, perform the following steps:
- Navigate to directory/etc/sysconfig/network-scriptsin your Gateway machine.
- Create a network configuration file with the name that best represents the network interface that you are adding.For example, you may choose to create the file with the name 'ifcfg-ssg_eth#' where # represents the sequential number of the new network interface you are adding. If you have one network interface already installed (ssg_eth0) and wish to add on more, the file name should be named 'ifcfg-ssg_eth1'. Similarly if you are adding an interface to an existing three-interface setup (ssg_eth0, ssg_eth1, ssg_eth2), the file name should be 'ifcfg-ssg_eth3'. Or, you may choose to adopt the default consistent name to repeat the naming pattern of other similar network configuration files in the directory, such as 'ifcfg-ens#'.
- Change permissions for the new ifcfg file with the following command (replace 'ifcfg-ssg_eth1' with your chosen ifcfg file name):chmod 644 ifcfg-ssg_eth1
- Generate a UUID for the ifcfg file with the following command (replace 'ifcfg-ssg_eth1' with your chosen ifcfg file name):uuidgen ifcfg-ssg_eth1
- The following step assumes you are adding an interface to an existing one-interface setup. Modify as required - note that the NAME and DEVICE values for your interface should be the same and must follow the Gateway's 'ssg_eth#' naming convention.Add the following lines to your file:HWADDR= [Enter your the hardware address of your new network interface] TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=ssg_eth1 [Replace with appropriate ssg_eth# name] UUID= [Enter the UUID for your new network interface. See Step 4.] DEVICE=ssg_eth1 [Replace with appropriate ssg_eth# name] ONBOOT=yes AUTOCONNECT_PRIORITY=999
- Restart your appliance and navigate to the SSG Configuration menu again to configure your new network interface. The API Gateway should now detect the new interface with the 'ssg_eth#' name.