Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
TOC
TOC
Include Page
KBCOMMON:KB-CSSstyle
KBCOMMON:KB-CSSstyle

...

(info) NetworkManager is disabled on Charon-SSP AWS. Therefore, the interface configuration relies on ifcfg-files in /etc/sysconfig/network-scripts.

(warning) The information in this chapter is not comprehensive. Please refer to the Amazon AWS documentation for up-to-date and comprehensive information.

...

Instance: An instance is a virtual machine that is launched into a VPC. It is associated with an image (e.g., Charon-SSW SSP AMI) and a certain instance type representing the virtual hardware.

...

  • If the instance has only one network interface, it is automatically assigned a private IP address and a public IP address from the address range assigned to the public subnet and a public IP address. This network interface is the primary network interface. It is called eth0 on the AWS level (please refer to the interface naming section to learn about the interface names presented to the operating system).
  • If the instance has more than one network interface, it is automatically assigned a private IP address for each of the network interfaces - but no public IP address.

...

  • The first (primary) interface is called ensX (where X is an integer denoting the interface number; example: ens5).
  • When a second interface is added to a running instance, it maybe initially called eth0.
    However, the command ethtool -i eth0 shows that the enhanced network driver (ena) will be used for this interface. This interface will change its name to ensY (where Y is X+1) after restarting the instance. This means that any configuration file created for this interface must use the final name of the interface instead of eth0. Otherwise, the instance may become unreachable after a restart because there is no valid interface configuration (NetworkManager is not enabled on Charon-SSP AWS, so a configuration file must exist to configure the interface properly).
    (warning) This numbering scheme may change in the future. Currently, it is based on the PCI slot on which the Ethernet controller is presented and which is incremented by one for each additional Ethernet interface added. On the Charon host system, the slot can be verified with the following command:
    # lspci -vv | grep -A20 Ethernet

(info) To avoid confusion before the instance can be restarted, the new interface can be renamed to its final name using the command 
     ip link set eth0 name ensY && ip link set ensY up

...

  1. Internal virtual bridge on the host system:
    Such a bridge has several TAP interfaces. The host and the guest systems are connected to this bridge and can communicate directly to one another using L3 and L2 protocols. The bridge uses its own IP subnet that can be defined by the user. Setting up such a configuration is supported by the Charon Manager.
  2. Communication via the AWS subnet LAN:
    In this case, a second interface is added to the Charon host system. The second interface is then assigned to the emulated guest system. After the correct configuration, the host and guest can communicate across the AWS LAN using IP. L2 protocols or any protocols that require changing the MAC address to something different than the MAC address assigned to the second interface by AWS will not work.
    To connect the guest system to the LAN, the following basic configuration steps must be performed:
    • Add the additional interface to the Charon host system.
    • Create a configuration file for the additional interface.
    • Remove the private IP address assigned to the second interface by AWS from the Linux configuration (if it has been configured).
    • Use the Charon Manager to assign the interface to the emulated SPARC system.
    • Use the Charon Manager to set the MAC address of the emulated SPARC system to the same value as the one used on the host system Ethernet interface.
    • On the Solaris system, configure the private IP address that was previously assigned to the second interface on Linux and configure the appropriate default route for the LAN.
    • Additional steps may be required:
      • If the primary interface has an automatically assigned public IP address, this will be released when the instance is stopped and restarted. Hence the configuration must be changed to use a persistent Elastic IP address first to maintain reachability of the host system.

...

(info) If Layer 2 communication between guests on different Charon hosts is required, a bridged tunnel solution must be set up between the two Charon host systems.

...

External Communication Considerations

...

Access to the Internet for private VPC subnets is possible across a gateway instance providing VPN access to the customer network and allowing (NATted) Internet access via this path. Alternatively, a NAT gateway in the cloud can be used to map the private addresses to public addresses. The NAT gateway can be implemented on a Charon host system or it can be provided by AWS for a charge.
(info) Please note that the Charon host always needs either direct Internet access or Internet access via NAT from a NAT gateway in the AWS cloud to access the license server.

Direct Solaris guest access to the Internet:

This not a recommended standard solution for security reasons. However, should it be required, two interfaces with public IP addresses can be assigned to the Charon host.
One of these interfaces is then dedicated to the guest system which uses the private interface address and the MAC address assigned to the Charon host by AWS (similar to point 2 in section Host to Guest Communication Considerations above).see also Dedicated NIC for Guest System).

Div
classpagebreak


Using a Charon host system as a Router

If a Charon host system is to be used as a router (for example as shown in Example of a More Complex Network Configuration or to provide Internet connectivity to other Charon host and guest systems), it is not sufficient to configure Linux for IP forwarding.

...

For each interface, the source/destination check has to be disabled. Unless this is configured correctly, traffic from and to and an AWS instance will only be allowed if either source or destination address belongs to the instance. Transit traffic destined to be forwarded by the router, would be discarded.

...

Should L2 protocols be required between two guest systems on different host systems, a bridge/tunnel solution similar to the one described in SSH VPN - Connecting Charon Host and Guest to Customer Network must be set up between the two host systems to allow the L2 traffic to pass.

...

Asymmetric Routing Considerations

...

  1. Create a configuration file (/etc/sysconfig/network-scripts/ifcfg-<interface-name>) for the second interface (if there is no configuration file for the primary interface, create it as well).
  2. Set the correct interface for default route in /etc/sysconfig/network (example: GATEWAYDEV=eth0).
  3. To prevent the cloud-init from resetting your custom network configurations, add the following lines to the /etc/cloud/cloud.cfg file:
    network:
      ; config: disabled
  4. Restart the network.
  5. Create an additional routing table (use the command: ip route add <path> dev <interface-name> table <table-id>). There must be an entry for every IP address assigned to the second interface and any other route to be used.
  6. Set rules in the Routing Policy Database (use the command: ip rule add from <ip-address-of-second-interface> lookup <table-id>)
  7. Create a static route file (/etc/sysconfig/network-scripts/route-<interface-name>)
  8. Create a static rule file (/etc/sysconfig/network-scripts/rule-<interface-name>)

...