Want to stay in the loop...?
News updates:
REANNZ will never disclose your email address.
Tuning BGP
BGP is designed for routing between autonomous systems, or independently managed routing domains. This is the standard routing protocol that is used to connect systems over the commodity Internet.
BGP basics
BGP uses a path vector algorithm to determine network topology and paths to destination networks. The BGP routing update carries information about the entire path to the destination, including the details of each autonomous system that must be transited to reach the destination.
BGP requires that each autonomous system have a globally unique autonomous system (AS) number. These AS numbers are used to prevent routing loops as well as to influence preferred routing paths.
BGP cannot be automatically configured but requires each peering relationship to be explicitly configured between neighbours. By default BGP routers accept all BGP route updates from their configured neighbours and send all the information they have about network paths to each configured neighbour.
BGP attributes
Each BGP update contains various BGP attributes concerning that route. Some of the information is mandatory and must be included in the update, while other information is optional. The following list is not exhaustive, containing attributes that may be useful in managing your peering session with KAREN.
- ORIGIN (mandatory) – how the route was learned
- I – learned in the originating AS via an internal routing protocol (IGP)
- E – learned from another AS
- Incomplete – source is unknown
- AS_PATH (mandatory) – list of AS paths to the destination
- NEXT_HOP (mandatory) – contains the IP address of the next hop (BGP router) in the AS path towards the destination network
- LOCAL_PREF (optional) – relevant for internal routing protocols only and relates to the preferred exit point from the AS.
Third party next hop
Third party next hop refers to the ability of a BGP router to advertise an external peer router in the next hop attribute, provided that that next hop router and the external peer the route is advertised to, share the same subnet. For example, ANR1 (210.7.32.1) can advertise the REANNZ router (210.7.32.13) as the next hop to AS38299 or 210.7.40.0 /24 to any router on VLAN 900 (210.7.32.0/24).
The result of this configuration is that traffic between hosts on KAREN VLAN’s is switched and need not pass through the KAREN core routers. This is a more efficient way of communicating with destination networks in the same layer 2 broadcast domain.
Route flap damping
Route flap damping is a method of maintaining stable BGP routing that is not impacted by flapping routes. Flapping routes are caused by routing relationships (peers) that are intermittently failing.
As a route intermittently fails it is assigned points, based on preconfigured values, and the accumulation of those points will eventually cause the route to be suppressed, either for a predefined time period or until the accumulated points fall below the threshold. When this occurs KAREN members would receive the KAREN routing table, but the member’s route would be suppressed, so no return route would exist.
The default behaviour is that a prefix starts with a point value of 0, and is assigned 1000 points if the route is withdrawn or readvertised. 500 points are assigned if the BGP attributes change within the advertised route. Once 3000 points are accumulated then the suppression occurs, and lasts until the reuse threshold is reached. That threshold is 750 points by default with half the accumulated points being deducted every 15 minutes.
An example, based on default behaviour, follows:
- Router is restarted resulting in 1000 points for route drop, and then 1000 points for route availability
- Router is restarted again before 15 minutes has passed, resulting in a further 2000 points (based on the same criteria above)
- The route is suppressed based on having accumulated 4000 points
- After 15 minutes 2000 points remain, so the route is still suppressed
- After 30 minutes 1000 points remain, so the route is still suppressed
- After 45 minutes 500 points remain, so the route is no longer suppressed
Restarting a router running BGP twice within 15 minutes will result in service problems for 45 minutes.
Establishing BGP peering
Each directly connected KAREN member must peer with the core KAREN routers and exchange routing information to effectively use KAREN. This allows your router to make decisions on how to reach destinations that are available via KAREN and direct other traffic to the commodity Internet or other gateway of last resort.
The following example is based on a Juniper J6350 and uses details specific to REANNZ. Please contact techinfo@reannz.co.nz for assistance with other platforms.
Set the AS number for your AS. For REANNZ this is AS 38299 which was allocated by APNIC.
routing-options {
autonomous-system 38299;
}
Create a peering policy that will be applied to outbound routing updates. By default, every route in your routing table is sent to all BGP neighbours. You must not advertise KAREN routes to any external peer such as your ISP. You should also ensure that you only advertise the agreed range of addresses to the core KAREN routers.
policy-options {
policy-statement export-REANNZ-address-block {
term 1 {
from {
route-filter 210.7.40.0/24 exact;
}
then accept;
}
term 2 {
then reject;
}
}
Define the peering relationship, including the peer AS, the neighbour address and the MD5 authentication key. You will also apply the export policy you defined (above) to ensure that you have controlled the flow of routing information out of your router.
This can be repeated for other peers if you have joined more than one VLAN.
REANNZ recommends that you peer with at least two of the core KAREN routers for redundancy.
protocols {
bgp {
group KAREN-VLAN900{
type external;
traceoptions {
file bgp;
flag route send;
flag all;
}
export export-REANNZ-address-block;
peer-as 38022;
neighbor 210.7.32.1 {
local-address 210.7.32.13;
authentication-key "adagdwaoet797235r24qpo5ijqgasdfd"; ## SECRET-DATA
}
neighbor 210.7.32.2 {
local-address 210.7.32.13;
authentication-key "aa;ldgjoaijhwretnw;243;lkafdafjn282"; ## SECRET-DATA
}
Assuming that you had already configured the layer 2 and layer 3 properties (VLAN tag and IP address) of your KAREN facing network interface, you should now start receiving KAREN routes.
Please note that you will not be able to peer with the KAREN core routers without working with the appropriate parties as peering is strictly controlled.
Advanced BGP tuning for KAREN
There are a wide variety of ways to tune BGP to suit the individual needs of your organization. A few useful examples follow.
Adjusting Local Preference
The adjustment of local preference is very useful if you are connected to more than one of the KAREN VLAN’s. This configuration allows you to ensure that you control which path your traffic takes if both paths offer the same route.
The example below prefers routes that are offered by ANR2 on VLAN901, with routes learned from ANR2 on VLAN900 and ANR1 on either VLAN least preferred.
Create a policy statement that defines which routes you want to adjust the preference on, and the actual adjustment that you want to make. The definition can be based on a number of variables including next-hop, as-path, interface and origin.
policy-options {
policy-statement local-preference {
term 1 {
from next-hop 210.7.34.2;
then {
local-preference 100;
accept;
}
}
}
Apply the policy statement to the appropriate routing group, which contains the peering definitions that you want to alter.
protocols {
bgp {
group KAREN {
type external;
traceoptions {
file bgp;
flag route send;
flag all;
}
import local-preference;
family inet {
any;
}
family inet6 {
any;
}
}
}
Excluding Routes based on AS Number
It can sometimes be useful to exclude routes being imported based on an AS number. This could be the AS number of a destination network such as the REANNZ network AS38299 or it could be that you want to exclude everything that has transited a particular network such as the KAREN core AS38022.
It is important to understand the outcome you are trying to achieve. For example, a KAREN member that excluded any routes that transited AS38022 would exclude all KAREN routes from the routing table. In a similar fashion excluding AS38018 (the KAREN International AS) would allow domestic routes to be imported but no International routes.
Create a policy statement that defines the outcome you want to achieve. The statement shown below rejects any routes that include AS38299 in the path, then prefers routes learned via ANR2 on VLAN 901, and finally accepts all other routes.
policy-statement reject-reannz-as{
term 1 {
from as-path from-AS-38299;
then reject;
}
term 2 {
from next-hop 210.7.34.2;
then {
local-preference 100;
accept;
}
}
term 3 accept-others {
then accept;
}
}
as-path from-AS-38299 ".* 38299 .*";
That policy is then applied to the particular routing group that you want to alter the properties for.
protocols {
bgp {
group KAREN {
type external;
traceoptions {
file bgp;
flag route send;
flag all;
}
import reject-reannz-as{;
family inet {
any;
}
family inet6 {
any;
}
}
}
Please let us know by emailing techinfo@reannz.co.nz if there are other advanced tuning parameters that you have implemented in your interaction with KAREN.
Updated 10 November 2008