5.3 EXTERIOR PROTOCOLS

63

5.3EXTERIOR PROTOCOLS

Exterior protocols are necessary for the exchange of routing information between autonomous systems. It would be impractical to use an IGP for this purpose for a number of reasons. As mentioned earlier, IGPs are optimized for small sets of prefixes. Exterior protocols, on the contrary, are optimized for the exchange and manipulation of very large sets of prefixes.

5.3.1BORDER GATEWAY PROTOCOL (BGP)

BGP is the only exterior gateway protocol in widespread use in the Internet, today. The current version of BGP is version 4. It is safe to say that every multihomed network (not just multiply connected but truly multihomed to different upstream providers) needs to run BGP in order to provide any dynamic resilience to their network.

BGP runs over the Transmission Control Protocol (TCP), which means that it is based on a peering system whereby two routers maintain a TCP connection over which all BGP messages are exchanged. Any single router may be maintaining many such sessions at any one time.

As an exterior gateway protocol, BGP is used for exchange of routing information between autonomous systems, which are groups of routers and the links between them controlled by a single administrative authority. Each autonomous system requires a globally unique identifier, which is a 16-bit integer (0 to 65535, 0 is reserved, 64512 to 65535 are available for private use and, since they should not be announced into the Internet, do not need to be globally unique).

BGP is a path vector protocol. This is not a true distance vector protocol but has significant similarities. The path to the destination is described as a list of these identifiers representing each of the autonomous systems back to the originating autonomous system in the order in which they must be traversed. Every time a prefix is advertised to another autonomous system, the router adds its own AS number to this list, the AS PATH. Thus, the AS PATH is created as the announcement of the prefix passes from the destination towards the source. Each AS number in the AS PATH is analogous to a ‘hop’ with a distance of one in a distance vector protocol.

In addition to providing details of the ‘distance’ to a particular prefix, the AS PATH also performs another function. Upon receiving a prefix from a neighbour, a BGP speaker checks to see if its own AS number is in the AS PATH. If it is, then this prefix would create a routing loop. Therefore, such prefixes are rejected.

Although BGP is fundamentally designed to exchange routing information between autonomous systems, it is still necessary to use BGP to exchange routing information between routers in the same autonomous system. The former configuration is known as external BGP (eBGP) and the latter is known as internal BGP (iBGP). While the underlying protocol is fundamentally the same, there are some important differences in the way it is operated and some different constraints on each.

64	ROUTING PROTOCOLS

5.3.1.1 External BGP (eBGP)

BGP is fundamentally a protocol designed for the exchange of inter-autonomous system NLRI. External BGP includes all BGP sessions between devices in your own autonomous system and those in any other autonomous system. This includes your upstream transit providers (potentially including other parts of your own company operated as separate autonomous systems), your peers and your customers. There is no inherent difference between the mechanisms used to exchange routes in these different types of eBGP session. However, each type of eBGP session has different aims and needs to be treated differently. Policy mechanisms are used to achieve this. Policy is discussed fully in Chapter 6. However, below is a brief description of the aims and requirements of each type of eBGP session:

•Transit providers. This is a session over which you learn all Internet routes (or a significant subset of those routes, e.g. all European routes). It is usually treated as the route of last resort, since you will almost inevitably be paying for traffic going over the link to your transit providers.

•Peers. This is a session over which two organizations exchange their own routes and those of their customers at ‘no cost’5 to each other. The cost of connecting to each other is usually shared equally. Routes learned via this type of session are likely to be preferred over those learned from a transit provider since there is little or no cost6 associated with traffic to peers.

•Customers. This is a session to a customer, which pays you to carry their traffic. Generally, you provide either full Internet routes or a subset of Internet routes and a default route. In effect, this makes you their transit provider. Routes learned from customers are generally preferred over all other sources because customers pay you for carrying traffic.

5.3.1.2 Internal BGP (iBGP)

If you use more than one router to connect to external BGP neighbours, then those routers must be connected by a contiguous path of BGP-enabled routers. In the most basic configuration, all routers running BGP in a network must peer with all other routers running BGP in the same network.

This constraint is necessary because no prefixes learned from an iBGP neighbour may be announced to another iBGP neighbour. This is a measure to prevent routing loops. This additional constraint is required because a router cannot add its own AS number

5 There	is usually no fee paid by one party to the other for the transport of their customers’ data.
6 There	is usually some cost associated with joining the Internet exchange point or the provision

of the circuit between the peers, even if it is simply the cost of a Gigabit Ethernet port on both parties’ routers and the fibre between them. However, compared to the cost of transit service, this is likely to be negligible.

5.3 EXTERIOR PROTOCOLS

65

to the AS PATH when sending prefixes to an iBGP neighbour. If it were to do so, the neighbour would detect its own AS in the AS PATH and reject the prefix.

The full mesh of internal BGP sessions is the basis of the n2 problem. In fact, using the basic configuration, you will have n(n−1) peering sessions configured, where n is the total number of BGP speakers in the network. Thus, when you add the n+1th BGP router to your network, you actually must reconfigure every single BGP router in your network (n devices). As your network grows, this can become a huge administrative burden. Two mechanisms have been developed to reduce this burden: route reflectors and confederations.

5.3.1.3 Route Reflectors

Route reflection is a mechanism which allows network operators to configure only partial meshes of routers while maintaining full connectivity. The mechanism relies upon special BGP routers called route reflectors. These special devices are permitted to break some of the basic rules of internal BGP. Specifically, the route reflectors may announce routes learned from one iBGP neighbour to another iBGP neighbour (as mentioned above, this is forbidden in basic iBGP). In order to restore the protection against routing loops, extra BGP attributes have been created. Those attributes are ORIGINATOR and CLUSTER ID. A router announcing a prefix into a BGP autonomous system sets the ORIGINATOR to its own router-id. Each route reflection cluster has a CLUSTER ID on the route reflector, which is added to the CLUSTER ID LIST as the prefix crosses the boundaries of BGP clusters.

All route reflectors must be fully meshed within a ‘core’. It is permissible to either fully mesh all clients in a particular route reflection cluster or to instruct the route reflector to reflect announcements from one client to another within the same cluster.

The choice of whether to run clients in a full mesh or use client-to-client reflection raises some interesting issues. Intuitively, the benefits of client-to-client reflection are pretty clear. This certainly places the lowest administrative load on the network operator. Adding a new client simply involves configuring the client and the reflectors for that cluster. However, client-to-client reflection can be a contributory factor in the problem described as persistent route oscillation. This problem is more fully described in Chapter 6 and in great detail in RFC 3345.

Clearly, a full mesh inside the cluster imposes its own n2 scaling issues as each of your clusters grows. If a cluster grows unwieldy, it is perfectly valid to create clusters within clusters, thus creating a hierarchy of route reflection (see Figure 5.4).

It is common practice to run route reflectors in pairs. When a pair of route reflectors service a single cluster, it is not obligatory for those route reflectors to use the same CLUSTER ID. There are valid arguments for both options. If you use the same CLUSTER ID on both route reflectors, then you reduce the total amount of state held on each router right across the network. This extra routing information will inherently impose extra load upon the processors, causes more protocol exchanges between iBGP neighbours and requires more memory. However, depending upon the way in which iBGP has been implemented by the operator, it is possible that the extra state may provide extra

66	ROUTING PROTOCOLS

Cluster

2.2.2.2

			Cluster
RR	RR	RR	RR 3.3.3.2

Cluster

1.1.1.1 Cluster 3.3.3.1

Layer 2	RR
Switch		RR

Figure 5.4 Route reflection

resilience. For example, if the alternate path is already available to the route reflector clients upon failure of the preferred path, then the time taken to restore traffic flow would be slightly reduced.

5.3.1.4 Confederations

Using BGP confederations is another mechanism for reducing the full mesh of iBGP sessions. It works on the premise of dividing a large autonomous system into a set of smaller sub-autonomous systems (confederation members), which are each interconnected in a limited and controlled fashion. Every router within any single confederation member (or sub-AS) must be either fully meshed or must employ route reflection mechanisms as described above.

Between sub-ASes, routers talk eiBGP (also known as confederation eBGP). As the name suggests, it is a bit of eBGP and a bit of iBGP. There are some differences between eiBGP and both eBGP and iBGP. For example, LOCAL PREFERENCE is exchanged by iBGP neighbours but not by eBGP neighbours. LOCAL PREFERENCE is also exchanged by eiBGP neighbours.

Conversely, the Multi-Exit Discriminator (MED) is used by eBGP neighbours to decide which path to use, but not by iBGP neighbours. MEDs are used by eiBGP neighbours for the same purpose. Also, when announcing a prefix to a different confederation member via an eiBGP session, the BGP speaker will add his own sub-AS number to the AS PATH (in a special object known as an AS CONFED SEQUENCE), just as is done on eBGP sessions. This provides the same level of loop prevention as is provided by the AS PATH in traditional ASes.

When announcing a prefix to an AS that is not a member of the confederation, the entire AS CONFED SEQUENCE is purged from the AS PATH and the confederation’s