
Internet Service Providers
129
20.8.2. BGP with carrier
This interlink is usually ised soley for the purpose of a BGP link to the carrier, and all other IPs used by the ISP
or carrier are announced via that BGP connection. You may want to configure filters on the BGP connection
to limit the prefixes accepted from the carrier or announced to the carrier.
An alternative approach is to configure the interlink interface on a separate routing table. The FB2700 can have
separate routing tables which act as completely separate internets. Using a separate table means you do not
have to worry about what prefixes are announced on the BGP link as they will only apply to that routing table.
Whilst we would recommend using a BGP connection like this, if the carrier does not handle BGP then you
will need static routes. Using a separate routing table can make this much simpler as you can set a default route
to the carrier gateway on the interlink subnet.
If using a separate routing table, you have to take care to correctly configure the routing table on the interface,
BGP, RADIUS, L2TP and loopback configuration elements.
20.8.3. RADIUS session steering
We recommend using RADIUS session steering with the carrier, if they support it. Session steering means
that the carrier sends a RADIUS request to the ISP before connecting each session by L2TP. The reply steers
the connection to a specific LNS. The connection details include the target (IP address) which will be one of
the FireBrick's address, and a pre-agreed hostname which identifies the tunnel level connection, along with a
secret to authentication the connection. Obviously these details have to match what the FireBrick is expecting
in its L2TP configuration. Session steering gives a lot of control to the ISP, and is ideal if you operate bonding
connections where multiple links need to use the same LNS.
The carrier will typically expect you to have two RADIUS endpoints to which they can send requests. One
for master and one for backup. Whilst the FB2700 will answer RADIUS on any of its IP addresses, we know
some carriers have issues using the interlink IP addresses. We recommend you create two additional loopback
addresses for session steering RADIUS.
These addresses are configured as a BGP announced loopback address. You can use MEDs to steer which IP is
on which LNSs. If you have more than two LNSs you can ensure that the same IPs are announced from more
than one LNS, and let BGP decide which LNS gets the RADIUS requests. RADIUS is a simple question and
answer protocol so it does not matter which LNS gets the request.
The session steering configuration (Platform RADIUS) is very flexible. We suggest you use the same
configuration on each LNS so that the replies are consistent regardless of where the request goes. The reply
says where to connect the session (as well as hostname and password to use). The reply can be a single LNS
or can be more than one reply with a priority tagging if the carrier supports this. The FB2700 can pick an LNS
randomly from a set, or pick one based on a hash of the username, part of the username, or circuit ID. This can
be useful when multiple lines are in a bonded arrangement where using the same prefix on a username ensures
all of the connections are steered to the same LNS for bonding.
If you have a lot of LNSs we recommend an N+1 arrangement. E.g. if you have 4 LNSs you may set your
RADIUS session steering to reply with one of three active LNSs as the first choice (perhaps ussing a hash)
and the 4th (backup) LNS as a second choice. This keeps one LNS as a hot standby for failure and also allows
maintenance on it, such as s/w updates. You can then change which of the there LNSs are active and either wait
for lines to move when the reconnect or clear lines on the new backup LNS. This makes it easy to do rolling
upgrades on s/w or other maintenance.
Session steering also allows specific configurations to be based on username, and circuit and so on, so allowing
different responses for different carriers and different end users to be customised if necessary. It is also possible
to send a copy of the session steering RADIUS to your own RADIUS server for logging.