The interface has an option to source-filter traffic received from the interface. This means checking the source IP of all traffic that arrives.

Setting source filtering to true will only allow IPs that would be routed back down that interface. That is the most restrictive setting, and can be useful for restricting customer connections to only originate traffic from their assigned IP addresses.

Setting source filtering to blackhole is less restrictive. It allows IPs to which there is a valid route even if to a different interface. If the IP is routed to a black hole or a dead end or not in the routing table then it is not accepted.

Obviously, having a firewall setting allows much more control over source address checking. These options are independant of firewall rules and mainly applicable to devices where firewalling is not available.

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 FB2500 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 />

For IPv6 you do not create a separate subnet, instead the interface level has an ra-client setting, which defaults to true. This allows an IPv6 address to be set up on the Interface if a suitable router accouncement is seen. The router announcement can also set up a gateway and DNS servers automatically.

Note that the gateway localpref is not something that can be configured, and defaults to 1000, 2000, 3000, or 4000 depending on the priority setting in the router announcement.

If creating an IPv6 subnet and announcement on an interface you may want to disable ra-client in the interface settings.

The PPPoE configuration allows one or more interfaces to have prefix delegation, i.e. an IPv6 subnet configuraed automatically based on settings provided by youyr Internet Service Provider. This may be only one /64 network on one interface, but the configuration for PPPoE allows you to define which interface(s) and even select that none apply.

Once prefix delegation is set up, the assigend subnet is used to provide IPv6 addresses and gateway to devices on the interface using SLAAC.

'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, or the client name using the client-name attribute.

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>

You can also lock an existing dynamic allocation to prevent it being re-used for a different MAC address even if it has expired.

You can restrict a pool to apply only to devices with specific MAC addresses, client names or vendor class names using the mac, client-name and class attributes on the dhcp object. The client and class names can be specified using wildcard strings, where the characters '*' and '?' stand for any run of characters, and any single character, respectively. The value specified for the mac attribute can be a list of partial MAC addresses, where each item can be less than a full 6-byte address. Any device whose MAC's leading bytes match one of the items in the mac list is acceptable. [The fixed-allocation example above is actually a special case of this general method for restricting allocation pools, where a single MAC address was specified in full.]

For example, as discussed in Appendix C, the first three octets (bytes) of a MAC address identify the organization (often the end product manufacturer) which is registered to 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 can 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 of your VoIP phones are from one manufacturer, as you can have appropriate firewall rule(s) that apply to addresses in that pool.

The following example illustrates this technique. It will match any devices which have MAC addresses beginning 00:04:13 or 00:0E:08, and which also have a vendor class name containing the string phone:

  <interface ...>
  ...
    <dhcp name="VoIP"
        ip="10.20.30.40-50"
        mac="000413 000E08"
	class="*phone*"
        dns="8.8.8.8"
        log="DHCP-Phones"
        comment="VoIP phones"/>
  ...
  </interface>

The algorithm used to determine which pools apply to a particular device is as follows:

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.