Tải bản đầy đủ
3 Storage, updating and recalculation of the routing table and routing database
The accuracy and stability of routing tables
Note: The communication ‘channel’ for the routing protocol is actually an IP
‘connection’ between the routers passing via the normal forwarding engine
part of the router (Figure 6.3). You may like to compare it with ITU-T’s c-plane
and m-plane communications model—Figure 3.31.
Typical router architecture — subdivided into forwarding and routing engines.
the routing engine of router A in Figure 6.2 would advertise the first five rows of Table 6.1
(these are the rows relevant to router A). The other routers would meanwhile independently
advertise the other rows. This enables each routing engine to maintain a complete and up-todate topology database (by listening to all relevant advertisements). As each update is received,
the router compares the new information with its existing database to determine whether any
topology changes have taken place. If so, a new routing table will be calculated, loaded into
the forwarding engine part of the router and activated.
By storing a complete image of the data used for the previous routing table calculation,
the re-calculation process can be simplified, and so speeded up. Furthermore, by storing all
the previously known data, the routing protocol usually needs only to send information about
real ‘changes’. This reduces the workload of the routing protocol and offloads traffic from the
IP forwarding network (with obvious cost and performance benefits).
There have been a number of different routing protocols developed over the years, and
each has its advantages and disadvantages. Each protocol is optimised for the particular mathematical method by which the shortest distance routes will be calculated. The format of the
protocols, as we shall see later in the chapter, usually directly reflect the data records which
are held in the related network topology or routing database.
6.4 The accuracy and stability of routing tables
Router networks work most efficiently when their routing tables are both accurate and stable.
Inaccurate routing tables lead to misrouting of packets — delivering them to the wrong address,
losing them or sending them in endless circular routes around the network.
Routing tables and protocols
Ageing routing table entries to ensure they are still current
One of the easiest ways in which routing tables can become inaccurate is as a result of the
withdrawal or failure of a previously operational route. Imagine driving along your favourite
country road to a particular destination. You have always driven that way. But today it’s
different — the road has been closed and barred, because it is to be dissected by a brand new
motorway and the roadworks have already started. How do you get through? You back up to
the previous junction and check the roadsigns. But these have not been updated, and there are
no ‘diversion’ signs — so you are lost, and you watch helplessly as other drivers follow the
signs and head down the old road to the same fate as you!
In router networks, the ‘severed country road problem’ (our analogy above) regularly
occurs — either as devices are taken out of service, moved from one location to another
or because they simply ‘fail’ as a result of an equipment fault. We cannot rely on being
informed about such link severences because typically the device which would have informed
us about the change in link status can no longer ‘talk’ to us (the communications path has
In the example of Figure 6.4, router D has failed because of an equipment fault — and
naturally router D is no longer able to inform the other routers of its fate! So how do
the other routers learn about the ‘change in topology’ of the network? The answer is they
don’t — directly. But if router D does not continue to advertise routing updates by means of
the routing protocol, then eventually the other routers delete the routing table entries which
have derived from router D’s previous advertisements. This is called ageing. (We met ageing
before — when talking about bridge source address tables (SATs) in Chapter 4.)
The ageing process demands that all routes are reconfirmed on a regular basis. Routes
which are not reconfirmed as still existing are assumed to have fallen out of use, and are
deleted from the routing table. Reconfirmation must occur at least once within the ageing time
period (typically 180–1800 seconds). Thus at least once every 3–30 minutes all the routes
must be advertised using routing protocols. Between these updates, the routing protocols send
only more urgent ‘change’ updates regarding network topology alterations.
The process of maintaining routing tables is a very onerous one! And the extra traffic load
on the network created by the routing protocols is considerable!
Reacting to unadvertised route withdrawals by means of routing table entry ageing.
The accuracy and stability of routing tables
Routers are repeatedly recalculating their routing tables and advertising the amendments they
make to them. The amendments, in turn, lead to routing table recalculation in other routers
and so to more advertisements of amendments and so to a new recalculation in the first router
and so on.
It is conceivable that a situation could arise in which the route choice of a given router to
a given destination oscillates between one path and another because of the repeated recalculation. This is an effect called route flapping. Route flapping can be very destructive — leading
rapidly to poor network performance. Counter-measures to prevent route flapping are called
Figure 6.5 illustrates an imaginary network in which route flapping can occur for one of
two different reasons. We are concerned with the choice of route from router A to router C.
At low link loadings, both links BC and DC will register a link distance of 1. So that both
routes ABC and ADC have equal routing distances of 2. Let us imagine router A randomly
chooses route ABC. Sometime later, router D will re-advertise its route to C as having a
distance of ‘1’. Prompted by the re-advertisement, router A recalculates the route via D and
discovers it has a total distance of 2 — i.e. equal to its currently established route via B. If
router A were to respond by replacing the route ABC with the route ADC, route flapping
would commence, because the next route advertisement by router B of its route to C would
lead to reversion to the original route and so on. So the first lesson in route damping is that
only routes with lower distances may replace existing routes.
Now let’s consider what happens when the total traffic between A and C reaches 50% of
the link loading. The initial route taken is ABC. The load on link BC exceeds 50% so router
B advertises the route BC with a distance of 2 while router D is still advertising its route
DC with a distance of value 1. Naturally A changes its preferred route to C to be the route
ADC. Whereupon the load on link DC immediately exceeds 50% and the load on BC drops
back below 50%. This, of course, leads to new route distance advertisements: BC distance = 1
and DC distance = 2. Router A dutifully recalculates the best route.. and reverts to the route
ABC.. and so on ad infinitum. Another case of route flapping! And a much harder one to spot
and to resolve!
A pragmatic approach to route damping is to restrict the frequency with which new routes
to a given destination are accepted (this is called holddown). But in doing so, we must be
careful to ensure that the network acts fast enough to real topology changes. When a link fails,
there must be quick action to divert around the problem.
The problem of route flapping.
Routing tables and protocols
Routing table convergence
The convergence time is the time taken by a router to develop its routing table after first being
introduced to the network or during its recovery after a network failure. The most efficient
modern routing protocols achieve fast convergence. Fast convergence is beneficial not only
when a router first comes into service, but also for re-routing (adapting routing tables) during
a period of network failure. Some older routing protocols (e.g. routing information protocol,
RIP ) are slow converging because several cycles of advertising of routing information and
re-calculation of routing tables are necessary before all the routes finally stabilise. Newer,
fast converging routing protocols, meanwhile (e.g. open shortest path first, OSPF ) allow the
entire information necessary for the calculation of a new router’s routing table to be requested
immediately by means of a hello procedure.
6.5 Representation of destinations in a routing table
In the discussion of this chapter so far, we have illustrated how routing protocols are used
to aid the process of routing table calculation — determining the best route from one router
(the source router) to another (the destination router). Ensuring the most efficient routing of
IP packets between routers is indeed the main purpose of a routing protocol, and hopefully
the discussion has given you a good understanding of the basic methodology of routing
table production. But what we have not yet discussed is how the destinations themselves are
represented in the routing table. After all, the ultimate destination is not the destination router
(as we implied in the example of Figure 6.2 and Table 6.1), but an IP address — typically
one of a range of IP addresses within a given LAN connected to the destination router. The
information held in Table 6.1 is actually insufficient to create any routing tables, because it
does not relate the ranges of IP addresses which pertain to each of the destination routers!
Routing protocols differ in how they convey the IP address and other destination information. In the earliest routing protocols (based on classful IP addressing — see Chapter 5),
the class address range was carried by the routing protocol to identify the range of addresses
connected to the destination router. Thus for example 220.127.116.11 meant a class C addressrange, equivalent to the addresses in the range 18.104.22.168 to 22.214.171.124. (There were also
class B and class A address-ranges). With the advent of classless interdomain routing (CIDR)
and variable length subnet masks (VLSMs), it became necessary to adapt routing protocols to
identify address ranges by carrying both the gateway address of the destination network and
the associated subnet mask.2
The destination network gateway address is the IP address of the router port connecting to the destination LAN (e.g. 126.96.36.199). The subnet mask is conveyed simultaneously
by the routing protocol in the IP-address-like-format (for a 2-bit subnet address the mask is
255.255.255.252). The gateway address 188.8.131.52 and the 30-bit subnet mask 255.255.255.252
thus represent a reachable address range at the destination LAN and router of: 184.108.40.206–173.
Each IP address range is treated by the routing protocol as if it were a different destination,
even if multiple different address-ranges are all used in the same destination LAN and all are
connected to the same destination router. In other words, there may be multiple routing table
entries for the different ranges of reachable addresses attached to the same destination router.
Some routing protocols (and their associated routing table calculation methods) concern
themselves only with calculating the ‘shortest’ route which will reach a given address range,
and repeat the same calculation for all the address ranges on the same destination router. Other
See Chapter 5.
Distributing routing information around an internetwork
protocols, meanwhile, associate all the destination IP address ranges with a given router-ID
(router identification) and perform the calculation only once — how best to reach the router.
6.6 Routing protocols and their associated algorithms and metrics
Routing protocols, as we have seen, provide a basis for routers to share routing information
and to calculate routing tables. Each routing protocol defines the data elements of a network
topology database (routing database, or equivalent otherwise-named database) which can be
communicated by means of the routing protocol and will provide the basis of the routing
table calculation. The routing protocol specification also defines the routing algorithm (i.e.
calculation methodology) which is to be used to calculate the ‘shortest’ route to any given
The earliest routing protocols (e.g. routing information protocol, RIP ) calculated the ‘shortest’ route as that requiring to traverse the least number of IP (Internet protocol) forwarding
hops. In the case of the network shown in Figure 6.2, for example, the route with the smallest
number of hops from router C to a destination connected to router B has two hops3 (the first
is the router-to-router link CB; the second is the hop from router B to the destination in the
As time has progressed, routing protocols have become more sophisticated. Network administrators have demanded that dynamic routing schemes adapt not just in the case of routing
topology changes (i.e. routing according to hop count) but also according to prevailing network operational conditions. Some modern routing protocols and modern routers thus allow
the distance values associated with outgoing links (sometimes also called the link cost) to be
made dependent on one or more of a number of other metrics:
• bandwidth (i.e. bit rate);
• least cost;
• path MTU;
In their default configuration for the OSPF (open shortest path first) routing protocol, Cisco
routers set the link cost (link distance value) to a value equal to 1000 million divided by the
link bandwidth (i.e. bit rate). Thus a link between two routers based on Gigabit ethernet has a
default link cost of 1. Meanwhile, a 64 kbit/s line has a link cost of 15625. By so biasing the
route distance (or total cost) calculation, the network administrator can force a preference for
the use of high bit rate routes. We saw such an example of route preference in Figure 6.2 and
Table 6.1. The ‘shortest’ route (measured according to the defined distance parameters) from
C-to-B in Figure 6.2 and Table 6.1 was the route CDFB and not the single hop route CB.
6.7 Distributing routing information around an internetwork
For the distribution of routing information around a network, a complete topology of routing
protocol ‘connections’ between neighbouring routers in the network has to be established.
The topology usually, but does not always, reflect the topology of the actual physical links
between the routers.
Directly connected hosts in the LAN local to the router are one hop away.
Routing tables and protocols
To simplify the task of distributing information and the complexity of calculating routing
tables, it is customary to divide large complex networks into smaller, more manageable areas,
subnetworks or domains and to create a hierarchy among the different routers. Specialised
routing protocols can then be used in the different levels of the network hierarchy to address
the different types of problems which arise. Figure 6.6 illustrates the basic hierarchy of routing
protocols and node types. We discuss these in turn in the following sections.
Autonomous systems (AS) and administrative domains (AD)
An autonomous system (AS) (sometimes also called an administrative domain (AD)) is a network of routers all under the same operational administration (and typically all owned by the
same network operator). The underlying assumption of routing protocols designed for interior
use within a single autonomous system (AS) is that no routing information need be hidden or
kept secret from other internal routers (IRs), and that the ‘shortest’ route through the network
will always be preferred.
Interior gateway protocol (IGP)
Interior gateway protocols (IGPs) are used for the distribution of routing information between
the routers within a single autonomous system (Figure 6.6). IGP is not a particular protocol
in itself, but a generic name used to denote any of a number of alternative protocols. The
best-known IGPs are RIP (routing information protocol), OSPF (open shortest path first),
IS-IS (intermediate system-intermediate system) and the Cisco proprietary IGPs: IGRP (interior
gateway routing protocol) and EIGRP (enhanced interior gateway routing protocol). The first
ARPANET IGP was the gateway-to-gateway protocol (GGP). This is now obsolete.
Border nodes (BN) (previously also known as exterior gateway nodes) assume the responsibility of exchanging routing information between different autonomous systems (Figure 6.6).
Basic routing hierachy and routing protocol types.
Distributing routing information around an internetwork
Border nodes always communicate on a peer-to-peer basis with their partner in the other
autonomous system, but are not necessarily directly physically connected to one another.
[But a TCP, transmission control protocol connection must exist between the BGP-speaking
Border gateway protocol (BGP) or exterior gateway protocol (EGP)
The routing protocol used to communicate inter-AS (autonomous system) routing information
directly between border nodes is called the border gateway protocol (BGP). The modern
version is version 4 (BGP4) and this is the default version in which all BGP sessions are
commenced (a negotiation for the use of an earlier version of BGP can be conducted if
necessary). A now-defunct protocol — the exterior gateway protocol (EGP) was replaced by
BGP, although the term EGP continues to be used sometimes to describe ‘generic’ protocols
of this nature. In this sense, BGP is a particular example of an EGP.
The border gateway protocol (BGP) introduces the concepts of reachability and routing
policy. Reachability is the term used to describe whether a route to a particular range of
exterior IP addresses is known by the border node or not. If the address range is not known,
then devices within the source AS (autonomous system) will be unable to reach the destination.
In attempting to reach a remote destination, a border node will try to discover the best
possible path, no matter how many different autonomous systems (AS) need to be transmitted
along the way. But maybe the owner of one of the autonomous systems along the way does not
want his network to be transmitted? After all, why should he or she have to carry third-party
traffic? To cater for such a situation, the border gateway protocol (BGP) introduced the idea of
routing policy. An import policy governs which incoming routing information updates will be
considered when calculating routes, and which ones will be ignored. The routes suggested by
an ‘untrusted’ partner, for example, could be filtered out. Similarly, the export or advertising
policy will govern which reachable destinations are made known to other parties. By hiding
the reachability of some destinations from other autonomous systems, unwanted transit traffic
can be avoided.
Within any given autonomous system (AS) network, it is normal to be running at least
one IGP (interior gateway protocol) internally, and also to be running BGP to neighbouring
autonomous systems (Figure 6.6). Some of the routing information gleaned from BGP needs
to be input to the IGP process (so that exterior address ranges are also reachable from internal
routers (IRs). Conversely, address ranges reachable within the AS need to be advertised by
means of BGP to external hosts which may want to communicate with them. The sharing of
routing information between BGP and the IGP (which is not straightforward, because of the
different mode of operation of the different protocols) is undertaken directly by the border
node and is called route redistribution.
In a case where there is more than one border node within an AS (as in the case of
Figure 6.6), some of the information derived from one of the BGP relationships may need to
be advertised via the other border node. In this way the ‘external autonomous system 1’ in
Figure 6.6 can learn about ‘external autonomous system 2’. The BGP routing information can
be transferred from one border node to another either by means of the IGP or, much better,
by using BGP internally within the AS. The latter approach avoids the need for a doubleconversion (back-to-back route redistribution) between different routing protocol formats.
Used internally between border nodes in this way, BGP is sometimes referred to as interior
border gateway protocol (IBGP). This distinguishes from the use of BGP externally: sometimes
called exterior border gateway protocol (EBGP). There are not two separate protocols!
When an autonomous system (AS) network is broken down into separate routing areas
(Figure 6.7), the routing tables for each area are worked out separately. Routing information
updates pertaining to internal routing within the area are not advertised to other areas, but
Routing tables and protocols
Breaking an autonomous system into routing areas.
instead are hidden. As a result, the routing protocol traffic between areas can be drastically
reduced, and the tasks of storing the network topology database and calculating the routing
table are greatly simplified.
By breaking an autonomous system into routing areas we impose a rigid hierarchy upon
the network. Some people see this as a drawback, since now not only the routing protocol
traffic, but all the IP forwarding traffic as well, can only pass from one area to another via the
backbone (or core) network (area 0 in Figure 6.7). But the rigid hierarchy can be a benefit
too, since only the backbone (or core network) routers need to store an extensive routing table
with a knowledge of all reachable IP addresses! Not only this, but the traffic flows and paths
in a hierarchical network are more predictable, thus simplifying the job of troubleshooting
network performance problems and tracing bottlenecks.
In any network in which more than one routing protocol is in use, routing information obtained
by means of one of the protocols may need to be used by the other protocol in calculating
route distances or costs (in practice nearly all networks use BGP in addition to at least one
IGP). This raises the question of the relative value we should place on routing information,
possible paths and path costs obtained from one routing protocol in comparison to similar information obtained from the other. In particular, routing information obtained from third-party
(‘untrusted’) network operators may be considered less reliable than that obtained internally.
In another case, we may prefer using certain third-party exterior routes more than others (for
cost, performance or other reasons).
Route redistribution allows for the transfer of routing information from one protocol type
to another and for the simultaneous ‘weighting’ of the information (i.e. purposely scaling-up
or scaling down the value of the relative distance or cost of the route). This allows the network
administrator to influence the preferred routes.
Distance vector and link state protocol routing methodologies
6.8 Distance vector and link state protocol routing methodologies
Routing protocols can be split into two categories — according to whether they are distance
vector protocols (DVP) or link state protocols (LSP). The difference between the two types
is the way in which they store and advertise the routing information (i.e. network topology
information), and in the way they calculate routes.
Distance vector protocols (DVPs)
As the name suggests, a distance vector protocol works by calculating the distance and the
direction (i.e. the vector — the destination, or the next hop) from each possible source router
to each possible destination. Once the distance and vector have been determined, they can be
advertised as routing information to other neighbouring routers within the network, which in
turn can then calculate their routing tables. We shall use the example of Figure 6.8 to explain
the basics of high a DVP works.
The example of Figure 6.8 comprises a network of 6 routers in which the source router
is router A and the destination we are concerned with is connected to router F. A simple
hop count is being used as the routing algorithm. We shall assume that router A’s neighbours — routers B, C and D have already calculated their routing tables for the shortest
path to reach the destination and each is advertising this information to router A (as well
as to all their other directly-connected neighbours) by means of the routing protocol. For the
calculation of the best route to the destination, router A only needs to:
• know that the destination is not directly reachable (i.e. is not in the range of addresses
configured into router A as being in the locally connected network); and then can
• deduce from the lowest advertised hop count of one of its neighbours, which of these
neighbours represents the best next hop for reaching the destination.
In our example, router A will conclude that its next hop to the destination should be via router
C, and that the hop count from router A to the destination will be 2 + 1 = 3 hops. A simple
process of deduction reaches this conclusion: the route advertised to the destination by router
Distance vector protocol — routing information.
Routing tables and protocols
C has two hops. Therefore a route from router A via router C will have three hops (since an
additional hop is required from A-to-C). Meanwhile, the minimum hop count via either router
B or router D (using similar logic) is 3 + 1 = 4 hops.
The chosen ‘shortest route’ via router C will now be adopted into router A’s routing table
and advertised using the routing protocol. In addition, the hosts directly connected to router A
will be advertised as being reachable within 1 hop. Other routers can then deduce that router
A is the destination router for these IP-address-ranges.
The main advantages of distance vector protocols are:
• the great simplicity of the algorithms required to calculate routing tables from the routing
information received from other routers;
• the low amount of processing effort and data storage involved in creating routing information in preparation for advertising. (The router simply advertises the contents of its
Put simply: distance vector protocols are not demanding in their use of router processor
power or data storage capacity. But they are rather crude in their derivation of routes and
each router has to keep on advertising its entire routing table (at least once per ageing time
period — typically 30–300 seconds for a DVP). This can represent a considerable additional
traffic load for the network.
Most of the early routing protocols were distance vector protocols (DVPs). Examples of
DVPs are: RIP (routing information protocol — both RIP-1 and RIP-2 ), Cisco’s IGRP (interior
gateway routing protocol) and BGP (border gateway protocol). We shall discuss RIP and BGP
in more detail later.
Link-state protocols (LSPs)
In contrast to distance vector routing protocols, link state routing protocols operate by distributing routing information about the state of the individual links of the network. By
listening to the routing protocol advertisements of other routers (which are broadcast or flooded
to all routers throughout the network), a router is able to build a complete ‘map’ of the topology of the network. Using its own ‘map’ (i.e. network topology database), each router can
work out the shortest path to each individual destination and so build an optimum routing table.
The main advantages of link state protocols over distance vector protocols are:
• the quality and efficiency of routes selected across a network;
• the ability to provide for reliable routing even in very large, complex networks (without
circular routes or similar routing instabilities); and
• the greatly reduced amount of routing information which has to be advertised by each router
(each router only advertises information about its own links — not the entire contents of
its routing table). The advertisements are called link state advertisements (LSAs).
The disadvantage of using a link state protocol is that routers must be equipped with large
amounts of data storage capacity to store the entire network topology database. They also
require high power processing capability to undertake the complex mathematics associated
with deriving the shortest path to each possible destination.
Examples of link state protocols are IS-IS (intermediate system-intermediate system) and
OSPF (open shortest path first). We shall discuss OSPF in detail later in the chapter.
Routing protocols and their relationship with the Internet protocol (IP)
6.9 Initiating router protocols: neighbour discovery
and the hello procedure
All routing protocols — no matter whether they are distance vector protocols or link state protocols — rely on routers knowing who their neighbours are, or at least having been configured
in such a way that they know how to discover them for themselves. As long as all routers
know who their neighbours are, a complete topology ‘map’ of the network can be worked out!
In the case of simple distance vector protocols (e.g. RIP), routers must be configured
by human network administrators to advertise routing information to their neighbours. This
involves activating the protocol (e.g. RIP) on relevant (point-to-point) links at all relevant
routers and configuring the neighbour’s IP address, so that it may be used as the destination
address for routing protocol messages. In the case of router A in Figure 6.8, the relevant links
are AB, AC and AD. Once the links are activated for RIP and the neighbour IP addresses are
known, router A will automatically advertise its routing table to the neighbouring routers: B,
C and D. And by knowing from which link (i.e. which neighbour) a given remote destination
was advertised as being reachable, the router can determine its own best next hop for this
In contrast to distance vector protocols, which exchange routing information only between
neighbouring routers, the link state advertisements (LSAs) of link state routing protocols are
flooded to all the internal routers within the network or network area. Nonetheless, the details
of the neighbour need to be known, so that these details can be advertised as link data in the
link state advertisements. Rather than have to configure the information about neighbouring
routers, many modern routers conduct neighbour discovery for themselves. For the purpose,
a hello procedure is defined as part of many modern routing protocols. It usually works
something like this.
When first introduced to the network, a router broadcasts a hello packet message across
all the interfaces which have been configured for the particular routing protocol (e.g. OSPF).
The interface might be either a point-to-point link or some kind of shared medium (e.g. a
LAN). The message says ‘hello . . . my router identification is xxxxx3 . . . I currently do not
know my neighbours’.4 All the routers neighbours (i.e. those which are reached by means of
a single IP hop — only neighbours will have received the hello packet ) reply with their own
hello packets. The responses go something like ‘hello, my router identification is xxxxx1; my
IP-address is n.n.n.n; my neighbours are xxxxx2 and xxxxx3’. On receipt of this message,
the new router (identification xxxxx3) knows that one of its neighbours is router xxxxx1! The
exchange of hello packets to enable neighbour discovery is called the hello procedure.
6.10 Routing protocols and their relationship with the Internet
Routing protocols play an important role in enabling the correct forwarding of Internet protocol
(IP) packets. But unlike the layered protocols of the OSI model as we discussed in earlier
chapters, routing protocols do not directly take part in the transfer of end-user data across the
network. Instead, routing protocols are network control protocols, used between the different
nodes of a network for steering the packet forwarding process. Nonetheless, they share the
routers‘ IP forwarding engines and lower layer networking protocols for basic carriage of
packets (as we illustrated in Figure 6.3).
The first hello packet is directed to an appropriate ‘all neighbouring routers’ IP multicast address. If necessary,
IEEE MAC-addresses necessary for the datalink (i.e. layer 2) transmission may be determined by means of the
address resolution protocol, ARP, as we shall discuss at the end of the chapter. Alternatively, a LAN-broadcast
address can be used.