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

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

Tunnels
82
If you wish to use a different UDP port number than the default of 1, specify the port number using the
port
attribute.
11.2.3. Viewing tunnel status
The status of all configured FB105 tunnels can be seen in the web User Interface by selecting "FB105" from
the "Status" menu. The tunnels are listed in ascending Local ID order, showing the far-end IP in use, the tunnel
name, and the state. The table row background colour is also used to indicate tunnel state, with green for Up
and red for Down.
Note that there is a third state that a tunnel can be in, that is "Up/Down" **TBC confirm** - this indicates
that tunnel wrapper packets are being received, but that they are informing this end-point that the far-end is
not receiving tunnel wrapper packets. This means the tunnel is essentially only established unidirectionally,
typically because of a firewalling, routing, NAT or similar issue that is prevent the correct bidirectional flow
of tunnels wrapper packets between the tunnel end-points.
Tunnel status can also be seen using the
show fb105
CLI command - see Appendix E.
11.2.4. Dynamic routes
Since a tunnel can only carry traffic properly when in the Up state, any traffic routed down a tunnel that is
not Up will be discarded. The ability to dynamically create a route when the tunnel enters the Up state (and
automatically delete the route when the tunnel leaves the Up state) allows the route to be present only when
traffic can actually be routed down the tunnel. In combination with the use of route preference values, you can
use this to implement fall-back to a less-preferred route if the tunnel goes down. Alternatively, you may want
to intentionally use a different tunnel to carry traffic, and use profiles to enable/disable tunnel(s) - the dynamic
route creation means that you do not need to manually change routing information to suit.
A dynamic route is defined by setting the
routes
attribute on the tunnel definition, specifying one or more
routing destinations in CIDR format, as discussed in Section 8.1.
11.2.5. Tunnel bonding
Multiple FB105 tunnels can be bonded together to form a set, such that traffic routed down the bonded tunnel
set is distributed across all the tunnels in the set. This distribution is done on a round-robin per-packet basis
i.e. the first packet to be sent is routed down the first tunnel in the set, each subsequent packet is routed down
the subsequent tunnel in the set, and the (N+1)'th packet (where N is the number of tunnels in the set) is again
routed down the first tunnel. This provides the ability to obtain aggregated bandwidths when each tunnel is
carried over a different physical link, for example, such as using multiple ADSL or VDSL (FTTC) connections.
Note
Using tunnel bonding to aggregate access-network connections such as ADSL or VDSL to provide a
single 'fat pipe' to the Internet requires there to be another FB105 tunnel end-point device to terminate
the tunnels. Ideally this 'head-end' device is owned and operated by your ISP, but it is also possible to
use a head-end device hosted by a third party, or in a datacentre in which you already have equipment.
ISPs that can offer tunnel-bonding for Internet access include Andrews & Arnold [http://aa.net.uk]
and Watchfront [http://www.watchfront.co.uk].
To form a bonded tunnel set, simply specify the
set
attribute of each tunnel in the set to be a value unique
to that set. Although not required, you would typically use a
set
value of 1 for the first set you have defined.
You can defined multiple bonded sets by using different values of the
set
attribute in each set.
11.2.6. Tunnels and NAT
If you are using NAT in your network, it may have implications for how to successfully use FB105 tunnelling.
The issues depend on where (on what device) in your network NAT is being performed.