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

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

Routing
57
the final target, e.g. it may be to an Ethernet interface, in which case an ARP is done for
192.168.0.100
to find the MAC to send the traffic.
There is logic to ensure that the next-hop is valid - the gateway specified must be routable somewhere and if
that is via an Ethernet interface then the endpoint must be answering ARP or ND packets. If not, then the route
using the gateway is supressed and other less specific routes may apply.
8.2.3. Special targets
It is possible to define two special targets :-
• 'black-hole' : packets routed to a black-hole are silently dropped. 'Silent' refers to the lack of any ICMP
response back to the sender.
• 'nowhere' (also called Dead End) : packets routed to 'nowhere' are also dropped but the FB6000 generates
ICMP error responses back to the sender.
The
blackhole
and
nowhere
top-level objects are used to specify prefixes which are routed to these special
targets. In the User Interface, these objects can be found under the Routes category icon.
When using BGP you can also define a network which is announced by default, along with any dead-end-
community, and treated otherwise the same as
nowhere
.
8.3. Dynamic route creation / deletion
For data links that have an Up/Down state, such as L2TP or FB105 tunnels, or PPP links, the ability to actually
send traffic to the route target will depend on the state of the link. For such links, you can specify route(s)
to automatically create each time the link comes up - when the link goes down these routes are removed
automatically. Refer to Chapter 11 for details on how to achieve this via the
routes attribute on the tunnel
definition objects.
This can be useful where a link such as PPPoE is defined with a given
localpref
value, and a separate
route is defined with a lower
localpref
value (i.e. less preferred), and therefore acts as a fallback route if
the PPPoE link drops.
8.4. Routing tables
The conventional routing logic described above operates using one of possibly many routing tables that the
FB6000 can support simultaneously. Routing tables are numbered, with the default being routing table 0 (zero).
The various ways to add routes allow the routing table to be specified, and so allow completely independent
routing for different routing tables. The default table (table zero) is used when optional routing-table
specification attributes or CLI command parameters are omitted.
Each
interface
is logically in a routing table and traffic arriving on it is processed based on the routes in
that routing table. Tunnels like FB105 and L2TP allow the wrapped tunnel packets to work on one routing
table and the tunnel payload packets to be on another. It is possible to jump between routing tables using a
rule in a rule-set.
Routing tables can be very useful when working with tunnels of any sort - placing the wrappers in one routing
table, allowing DHCP clients and so on, without taking over the default route for all traffic. The payload can
then be in the normal routing table 0.
8.5. Bonding
A key feature of the FB6000 is the ability to bond multiple links at a per packet level.