This guide will show you basic steps for how to configure a network interface on your BrickStor. This guide assumes a single interface is being used, not bonded and without VLAN tagging or any other more advanced features, less commonly implemented.
Steps for setting up a single non-aggregated interface. It is important to have an understanding for how the system is configured and wired, before making these changes. Depending on the model of the device, you may observe a mixture of 10GbE and 1GbE interfaces, all 1GbE interfaces or with more recent models all 10GbE interfaces. In the case of all 10GbE interfaces system may have a mix of standard copper, commonly known as RJ45 interfaces (10GBaseT) and SFP+ interfaces. Generally, both traditional and SFP+ interfaces will appear to have the same name: ixgbe, which refers to the underlying driver used by the system.
It is critical to understand the numeric value that follows the driver name, because that value represents a specific device on the system. If you are unable to ascertain which physical port maps to interfaces reported by the system, be sure to contact RackTop Support for further assistance. As a general rule, the ordering in the list will follow this basic principle. Lowest onboard interface (as seen from label on the chassis) will have smallest identifying number. The number increases by 1 with each interface. Generally, interfaces are enumerated from lowest onboard to highest on add-on controllers, etc.
A useful tool is the dladm command, which as exemplified in first step below, will report speed and duplex of all detected interfaces. It is often prudent to compare what is physically plugged into the chassis against this output, since we can rapidly tell which links are actually online and what they map to in terms of logical name.
First we get a list of all physical links on the system with dladm show-phys, which returns a list generally ordered as described in the Summary above. You will note that interfaces here are of two types, igb and ixgbe. Interfaces identified as igb0 will invariably be 1GbE capable, but actual speed of course could be lower, depending on the switch end. Interfaces identified as ixgbe0 will be 10GbE capable, and could be either 10GBaseT or SFP+.
In this step we will create a virtual interface on ixgbe0 called data0. Virtual interfaces give us the ability to create many instances of a network interface with a unique MAC and IP address over a single physical link. Unlike an alias, resulting interface would have a unique MAC, which in effect presents it as a completely independent interface from any other created over this physical link. ARP tables on remote devices will treat each such interface as though it is an entirely stand-alone physical interface.
If we want to create an interface that uses VLAN tags, we have to alter the command slightly. We are going to assume that we want to use VLAN ID 10, and it is perhaps reasonable to consider including the ID in the name of the resulting virtual interface. In this case we could choose to name it data10010, where the part after 100 correlates with vlan ID. The reason for having 100 as a prefix is actually idiosyncratic implementation of the interface naming standard, which does not allow for leading zeroes, unless 0 is the ONLY digit that follows prefix, such as data0, in other words this is illegal: data010, but it is also perfectly fine to assume some sequentially incrementing value prefixed with word data, in cases where some number of tagged interfaces is required. In this example we still use same name as above, the only difference being -v argument and its parameter.
Next, we need to place an IP interface over this newly created virtual interface (vnic). An IP interface is necessary to be able to assign an IP address to a given interface.
Now we will assign a static IPv4 address 10.1.2.25 with a /24 subnet to the data0 virtual interface (vnic).
If the interface is meant to be dynamically addressed, please use the following command instead.