FireBrick FB6402, Руководство пользователя

Страница: 56 / 196

Interfaces and Subnets
39
Note
While this may seem rather complex, it achieves the intuitively-expected result in most cases - for
example it allows a pool to be set up for a general class of device or a range of MAC addresses, and
for more specific pool entries to be included which will take precedence for individual devices, eg
with a full MAC address or a specific client-name.
6.2.2.3. Special DHCP options
For each pool, in addition to the common DHCP options to be supplied to the client device which you can
configure using recognized attributes (eg
gateway
,
dns
,
domain
), you can also supply other DHCP options,
specified as a string, IPv4 address or number, or even as raw data in hexadecimal. You can force sending of
an option even if not requested.
For vendor-specific options (ID 43) you can either specify in hex as ID 43, or you can specify the code to use
and set the vendor flag; this adds an option type 43 with the code and length for the option which can be string,
IPv4 address, number, or hexadecimal.
6.2.3. DHCP Relay Agent
You can configure the FireBrick to operate as a DHCP/BOOTP Relay agent simply by setting the dhcp-relay
in the interface object to the IPv4 address of the remote DHCP server.
If you also configure a DHCP allocation on the same interface, this is checked first, and if there are no suitable
allocation pools or IP addresses available then the request is relayed. Normally you would configure either a
relay or a pool and not both.
The top level dhcp-relay configuration allows you to configure the FireBrick to be the remote server for a
DHCP/BOOTP Relay Agent. The relay attribute allows specific pools to be set up for specific relays. The table
and allow allow you to limit the use of the DHCP Remote server to requests from specific sources - note that
renewal requests come from the allocated IP, or NAT IP if behind NAT and not necessarily from the relay IP.
The allocation-table attribute allows for this pool of IPs to be placed in a separate table, thus allowing it to
be independant from other DHCP allocations on the FireBrick and to allow different overlapping pools for
different relay endpoints, which is not uncommon if the endpoints are behind separate NAT routers.
6.3. Physical port settings
The detailed operation of each physical port can be controlled by creating
ethernet
top-level objects, one
for each port that you wish to define different behaviour for vs. default behaviour.
To create a new
ethernet
object, or edit an existing object, select the Interface category from the top-level
icons. Under the section headed "Ethernet port settings", you will see the list of existing
ethernet
objects
(if any), and an "Add" link.
In a factory reset configuration, there are no
ethernet
objects, and all ports assume the following defaults :-
• Link auto-negotiation is enabled - both speed and duplex mode are determined via auto-negotiation, which
should configure the link for highest performance possible for the given link-partner (which will need to be
capable of, and participating in, auto-negotiation for this to happen)
• Auto-crossover mode is enabled - the port will swap Receive and Transmit pairs if required to adapt to cable /
link-partner configuration
• The green port LED is configured to show combined Link Status and Activity indication - the LED will be
off if no link is established with a link-partner. When a link is established (at any speed), the LED will be
on steady when there is no activity, and will blink when there is activity.