Swapping NetWall Ethernet interfaces using "Set interface Ethernet"

Last modified on 30 Mar, 2022. Revision 8
How to swap two NetWall Ethernet interfaces with each other without having to update the entire cOS Core configuration with regard to object references.
Up to date for
cOS Core 14.00.03
Supported since
cOS Core 9.xx
Not valid for
cOS Core 8.xx
Status OK
Author
Peter Nilsson

Summary

There may be situations that for whatever reason there is a need to change an Ethernet interface from one to another. There are several examples but one would be if for instance one interface is damaged/broken and we want to use another available interface temporary while we wait for replacement, another example would be if we want to move from a 1 GB interface to a 10 GB interface.

By swapping the hardware reference setting on the Ethernet object we avoid the situation where we have to update every object in the configuration to point to the new interface.

Gathering the needed information

First we must start by gathering information on the current state of all Ethernet interfaces, we do this by running the CLI command: “Show interface ethernet <iface>”. An example:

VSG-1:/> show Interface Ethernet If1
Property Value Remarks
-------------------------- ---------------------------------------- ---------
Name: If1
EthernetDevice: 0:If1 1:If1

(There are lots of more data from this output but it’s not relevant to what we want to do)

Note-1: “0:if1” means the EthernetDevice setting used by the Master in a cluster and “1:if1” means similar but for the Slave node.

Note-2: If the unit is not a cluster, it will look like this:

EthernetDevice: 0:if1 1:<empty>

Next we gather the data from the other interface:

VSG-1:/> show Interface Ethernet If2
Property Value Remarks
-------------------------- ---------------------------------------- ---------
Name: If2
EthernetDevice: 0:If2 1:If2

So now we have all the information we need to perform the change.

Performing the change

In this example we want to swap the interface if1 with if2, the idea then is that after the change we only need to change (or swap) the cable(s) from if1 and if2 and we are all done. No need to make any additional changes in the configuration. To do this we perform the following two CLI commands:

set Interface Ethernet If1 EthernetDevice:0=if2 EthernetDevice:1=if2
set Interface Ethernet If2 EthernetDevice:0=if1 EthernetDevice:1=if1

For standalone units only EthernetDevice:0=” needs to be changed

So we swap the Ethernetdevice references of if1 and if2 with each other. We then activate + commit the changes, if management is on either these interfaces you may need to be quick in changing the cables and/or perform ARP flushes (as the MAC address changes for the IP assigned to these two interfaces).

All done, interface if1 is now interface if2 and wise versa and there is no need to manually have to update potentially thousands of objects manually or in the CLI. Although we can probably make the change semi-easy using the CLI and scripting (search & replace).

Recommendation: A last thing to do afterwards would be to change the Ethernet name to reflect the actual interface. Especially on appliances it would be confusing if the configuration says "if2" while if you look at the hardware physically it is "if1". This change can be done in the WebUI/InControl as well, we simply go to the interface and change it’s name. Although we may need to perform this in two steps if the target name is already used (a catch-22 problem). So temporary rename them to e.g. if1_temp and if2_temp then the next step would be to give them the correct names. Also making a comment on each interface that this operation has been done is recommended for history’s sake as it’s an easy thing to forget after some time, it never hurts to document as this operation is fairly unusual to do.

This also applies to the objects assigned to the interface, if we have assigned for example if1_ip to if1 and we now rename the interface to if2 in the above recommendation we should also rename the object to be called if2_ip (the catch-22 of conflict existing name may still happen though).

Question: Why not just change the Ethernet name only and then move the cables?

The reason for that is because an Ethernet interface consists several object references,

  1. The main Ethernet object/interface
    1. This object contains settings such as IP, network etc. and is the object exposed in the configuration and you can use for IP polices, routes etc.
  2. The Ethernet device object reference on the Ethernet interface
    1. This is basically the hardware settings, the firewall will look for an object called "EthernetDevice" with the name i1 and if2 which contains information such as bus, slot, port and driver the interface should use. This object is not exposed in the WebUI, only the CLI (or if you look at a configuration backup in a text editor). There should be no reason to ever change the EthernetDevice object directly (and we will not go into any details about that in this KB).

So the reason why this change can only be done in the CLI (or by Clavister support staff manually) is because the Ethernet Device object is not directly exposed for change in the WebUI. If you rename the interface in e.g. the WebUI the EthernetDevice references will NOT be updated.

Known limitations

  1. If we swap two interfaces that means that we also "swap" the MAC address between them. So the MAC address on e.g. if1 will now be on if2 and wise versa. This means that the ARP cache may need updating on connected equipment after the change. Gratuitous ARP is being sent out on all interface IP addresses however, so a simply solution may be to simply restart the firewall after the change. Alternatively use the CLI command "ARP -notify=If1_ip if1" to manually send out a gratuitous ARP to connected equipment to (try) force them to update their ARP cache (depends on behavior/settings of connected equipment though).
    1. It is the same problem as if we were to change hardware basically.


Related articles

Assigning additional IPs to cOS Core Ethernet interfaces
7 May, 2021 core ethernet vlan arp garp