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

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

BGP
102
Note
There is an option relating to imported routes
reduce-recursion
which, when set, changes any
received next hop to the peer address unless the next hop relates to a locally connected Ethernet subnet.
This helps reduce the recursion involved, and is important in some cases for route reflectors if they
pass recursive routes on to routers that do not handle BGP recursive routes properly (such as BIRD).
15.2.13. Diagnostics
The web control pages have diagnostics allowing routing to be show, either for a specific target IP (finding
the most specific route which applies), or for a specified prefix. This lists the routes that exist in order, and
indicates if they are supressed (e.g. route feasibility has removed the route). There are command line operation
to show routing as well.
It is also possible, using the command line, to confirm what routes are imported from or exported to any peer.
The diagnostics also allow ping and traceroute which can be useful to confirm correct routing.
15.2.14. Router shutdown
On router shutdown/reboot (e.g. for software load) all established BGP sessions are closed cleanly. Before the
sessions are closed all outgoing routes are announced with a lower priority (high MED, low localpref, prefix
stuffed) and then a delay allows these to propagate. This is a configurable option per peer and the maximum
delay of all active peers is used as the delay. Setting to zero will not do the low priority announcement. A
special case of setting this delay to a negative value on a peer causes routes to be specifically withdrawn before
the delay rather than announced low priority.
15.2.15. TTL security
The FireBrick supports RFC5082 standard TTL security. Simply setting ttl-security="1" on the peer settings
causes all of the BGP control packets to have a TTL of 255 and expects all received packets to be TTL 255
as well.
You can configure multiple hops as well, setting ttl-security="2" for example still sends TTL 255 but accepts
254 or 255. This works up to 127.
You can also configure a non standard forced TTL mode by setting a negative TTL security (-1 to -128)
which forces a specific TTL on sending packets but does not check received packets. For example, setting ttl-
security="-1" causes a TTL of 1 on outgoing packets. This simulates the behaviour of some other routers in
IBGP mode. Using -2, -3, etc, will simulate the behaviour of such routers in EBGP multi-hop mode. This is
non standard as RFCs recommend a much higher TTL and BGP does not require TTLs to be set differently.
Without ttl-security set (or set to 0) the RFC recommended default TTL us used on all sent packets and not
checked on received packets.