| 6.3. Defining an interface | ||
|---|---|---|
 | Chapter 6. Interfaces and Subnets |  |
| 6.3. Defining an interface | ||
|---|---|---|
| | Chapter 6. Interfaces and Subnets | |
To create or edit interfaces, select the Interface category in the top-level icons -
under the section headed "Ethernet interface (port-group/vlan) and subnets", you will see the list of existing interface top-level objects (if any),
and an "Add" link.
The primary attributes that define an interface are the name of the physical port group it uses, an optional VLAN ID, and an optional name. If the VLAN ID is not specified, it defaults to "0" which means only untagged packets will be received by the interface.
To create a new interface, click on the Add link to take you to a new interface defintion. Tick the port
checkbox and select one of the defined port groups. If the interface is to exist in a VLAN, tick the vlan checkbox and enter
the VLAN ID in the text field.
Editing an existing interface works similarly - click the Edit link next to the interface you want to modify.
An interface object can have the following child objects :-
Each interface can have one or more subnets definitions associated with it. The ability to specify multiple subnets on an interface can be used where it is necessary to communicate with devices on two different subnets and it is acceptable that the subnets exist in the same broadcast domain. For example, it may not be possible to reassign machine addresses to form a single subnet, but the machines do not require firewalling from each other.
As discussed in Section 6.1, an interface is associated with a broadcast domain ; therefore multiple subnets existing in a single broadcast domain are not 'isolated' (at layer 2) from each other. Effective firewalling (at layer 3) cannot be established between such subnets ; to achieve that, subnets need to exist in different broadcast domains, and thus be on different interfaces. An example of this is seen in the factory default configuration, which has two interfaces, "WAN" and "LAN", allowing firewalling of the LAN from the Internet.
You may also have both IPv4 and IPv6 subnets on an interface where you are also using IPv6 networking.
The primary attributes that define a subnet are the IP address range of the subnet, the IP address of the FB6000 itself on that subnet, and an optional name.
The IP address and address-range are expressed together using CIDR notation - if you are not familiar with this notation, please refer to Appendix B for an overview.
To create or edit subnets, select the Interface category in the top-level icons, then click Edit next to the appropriate interface -
under the section headed "IP subnet on the interface", you will see the list of existing subnet child objects (if any),
and an "Add" link.
In a factory reset configuration, there are two temporary subnets defined on the "LAN" interface : 2001:DB8::1/64 and
10.0.0.1/24. These subnet definitions provide a default IP address that the FB6000 can initially be accessed on, regardless of whether
the FB6000 has been able to obtain an address from an existing DHCP server on the network. Once you have added new subnets to suit your
requirements, and tested that they work as expected, these temporary definitions should be removed.
To create a new subnet, click on the Add link to take you to a new subnet object defintion. Tick the ip checkbox,
and enter the appropriate CIDR notation.
Editing an existing subnet works similarly - click the Edit link next to the subnet you want to modify.
You can create a subnet that is configured via DHCP by clearing the ip checkbox - the absence of an IP address/prefix specification
causes the FB6000 to attempt to obtain an address from a DHCP server (which must be in the same broadcast domain). It may help to use the Comment field
to note that the subnet is configured via DHCP.
In its simplest form, a DHCP configured subnet is created by the following XML :- <subnet />
The FB6000 can act as a DHCP server to dynamically allocate IP addresses to clients. Optionally, the allocation can be accompanied by information such as a list of DNS resolvers that the client should use.
Since the DHCP behaviour needs to be defined for each interface (specifically, each broadcast domain), the behaviour is controlled by
one or more dhcp objects, which are children of an interface object.
Address allocations are made from a pool of addresses - the pool is either explicitly defined using the ip
attribute, or if ip is not specified, it consists of all addresses on the interface i.e. from all subnets, but excluding
network or broadcast addresses, or any addresses that the FB6000 has seen ARP responses for (i.e. addresses already in use, perhaps through a
static address configuration on a machine).
The XML below shows an example of an explicitly-specified DHCP pool :-
<interface ...>
...
<dhcp name="LAN"
ip="172.30.16.50-80"
log="default"/>
...
</interface>
Every allocation made by the DHCP server built-in to the FB6000 is stored in non-volatile memory,
and as such will survive power-cycling and/or rebooting. The allocations can be seen using the "DHCP" item in the "Status" menu, or using the
show dhcp CLI command.
If a client does not request renewal of the lease before it expires, the allocation entry will show "expired". Expired entries remain stored, and are used to lease the same IP address again if the same client (as identified by its MAC address) requests an IP address. However, if a new MAC address requests an allocation, and there are no available IPs (excluding expired allocations) in the allocation pool, then the oldest expired allocation IP address is re-used for the new client.
'Fixed' (or 'static') allocations can be achieved by creating a separate dhcp object for each such allocation, and specifying the client MAC
address via the mac attribute on the dhcp object.
The XML below shows an example of a fixed allocation - note the MAC address is written without any colons, and is therefore a string of twelve hexadecimal digits (48-bits). This allocation also supplies DNS resolver information to the client.
<interface ...>
...
<dhcp name="laptop"
ip="81.187.96.81"
mac="0090F59E4F12"
dns="81.187.42.42 81.187.96.96"
log="default"/>
...
</interface>
If you are setting up a static allocation, but your client has already obtained an address (from your FB6000) from a pool, you will need to clear the allocation
and then force the client to issue another DHCP request (e.g. unplug ethernet cable, do a software 'repair connection' procedure or similar etc.).
See the show dhcp and clear dhcp CLI commands in the Appendix G for details on how to clear
the allocation. Chapter 17 covers the CLI in general.
In addition to specifying a full 48-bit (12 hexadecimal character) MAC address in a dhcp object, it is also possible to specify
part of a MAC address, specifically some number of leading bytes. The dhcp object will then apply for any client
whose MAC address has the same leading bytes.
For example, as discussed in Appendix C, the first three octets (bytes) of a MAC
address identify the organization (often the end product manufacturer) that can allocate that MAC address to an Ethernet device. By specifying only these first three bytes (six hexadecimal
characters, no colon delimiters), in the mac attribute, you could ensure that all devices from the associated manufacturer are allocated
addresses from a particular address pool. This is helpful if you have some common firewalling requirements for such a group of devices -
for example, if all your VoIP phones are from one manufacturer - as you can have appropriate firewall rule(s) that apply to addresses in that pool.
| |  | |
| 6.2. Defining port groups |  | 6.4. Physical port settings |