Removing network interface

Removing an interface follows the reverse of the steps followed when adding a network.

About this task

There are two possible use cases:
  • A network cable is being removed and therefore its related subnet needs to be removed. This means removing the corresponding external_link section in switches > hosts > FabSw1a and also removing the related networkX section from the application_network section in the yaml. (This step is applicable for the reversal of both Adding a new network subnet (new cable) and Adding a new cable that does not have strict VLAN and uses the default VLAN (4080).)
  • A VLAN is being removed from an existing network cable. This means removing the VLAN from the list of VLANs in the corresponding external_link entry in the switches > hosts > FabSw1a section of the yaml, and also removing the related networkX section from the application_network section.

The two cases are described below:

Removing a network subnet (removing a cable)

To remove a network subnet, remove an external_link entry from the switch section.

This procedure handles reversal of both Adding a new network subnet (new cable) and Adding a new cable that does not have strict VLAN and uses the default VLAN (4080). In this case, whether or not a VLAN was created, since the entire cable is being removed we do not need to differentiate between teh two cases from the addition of a network scenario.

Before you begin

Information to gather:
  • VLAN(s) of the cable that is being removed
  • Network IP(s) of the cable that is being removed
  • external_link entry relating to the network IP
  • network entry relating to the network IP
  • New application network IP if this is going to change due to the removal of the cable.

Procedure

  1. Connect to node e1n1 by using the management floating IP.
  2. Follow Switch settings to delete the external_link section(s) that correspond to the VLAN(s)/cable being removed.
  3. Follow Shared application network variables to remove the networkX entry in the application_network of the yaml that corresponds to the VLAN/cable being removed. If the default_gateway value for this networkX entry is true, you will need to set default_gateway: true in an existing networkX entry. Discuss with your network team to determine which network should house the default gateway.
  4. If the application IP used to represent the application FQDN will be removed due to the removal of the networkX entry, discuss with your network team to determine which networkX floating_ip value should be used to resolve to the application FQDN. Follow Setting up a wildcard DNS entry to change the CNAME IP in the A record of the Zone Definition file on the customer's DNS server to match the new application floating IP.
  5. Validate the YAML file.
  6. Test the YAML and run the playbook.

Removing VLAN from a subnet

To remove VLAN from a subnet, edit the existing external_link entry in the switches > hosts > FabSw1a section of the yaml.

Before you begin

Information to gather:
  • VLAN number to remove
  • New application network IP if this is going to change due to the removal of the given VLAN.

Procedure

  1. Connect to node e1n1 by using the management floating IP.
  2. Follow Switch settings to remove the VLAN value from the existing vlans: ['VALUE'] list of the corresponding external_link.
  3. Follow Shared application network variables to remove the networkX entry in the application_network section of the yaml that corresponds to the VLAN value being removed. If this network has default_gateway: true, you must choose another networkX entry to set as the default_gateway. Check with your network team to determine which network should be the default (if there is still more than one).
  4. If the application IP used to represent the application FQDN will be removed due to the removal of the networkX entry, discuss with your network team to determine which networkX floating_ip value should be used to resolve to the application FQDN. Follow Setting up a wildcard DNS entry to change the CNAME IP in the A record of the Zone Definition file on the customer's DNS server to match the new application floating IP.
  5. Validate the YAML file.
  6. Test the YAML and run the playbook.