Routing protocols serve one function: To let nearby routers know how to get
to them and the networks they serve. There are two basic types of routing
protocols: distance vector protocols and link state protocols.
The simplest protocols are perhaps those that classify as Distance Vector
protocols. They base their routing decisions on the number of intermediate
routers along a given path. This has the advantage of taking very few resources
but has the disadvantages of not considering bandwidth or the load of the
available link. They also suffer limitations when long distances are present.
The path may be valid but because of the high metric, the routers decide that
the remote host or network is unreachable. In addition, these types of protocols
usually broadcast their entire routing tables at preset intervals. This can take
quite a bit of time and consume considerable bandwidth. Protocols that fall
under this classification are RIP, IGRP, and BGP.
Link State protocols function by maintaining a database of advertisements
they have received from other routers called the link state database. This means
that each router is wholly responsible for determining the best path to a given
location from its point of view and already has an idea of an alternate path, if
any, should the first path become unavailable.
It is entirely possible (and often necessary) to exchange routes learned by
one protocol into another. An example of such a case would be where a network
cannot be managed by a single protocol due to software or hardware limitations.
Such limitations might be due to a lack of adequate memory in the router or a
router that does not support the desired protocol. It might also be the case
that functionality provided by one protocol is not sufficient in a particular
area of the network and another protocl must be left to manage that section. In
order for the rest of the network to know the routes to those other sections and
vice versa, the protocols must exchange routing information.
Assume that a collection of routers only speak RIP but that these routes need
to make their way into EIGRP and the EIGRP routes neet to be injected into RIP.
Redistribution would occur at the boundry router and would look similar to the
example that follows.
-
I. Configuring RIP
-
The Routing Information Protocol (RIP) is perhaps the simplest of routing
protocols. It functions by broadcasting its entire routing table to all
participating networks once every 60 seconds for IP or once every 90 seconds for
IPX. When a route is heard from a remote router, the metric is increased by one.
This number cannot exceed 15. A metric of 16 describes an unreachable network.
The simplicity of this protocol means that there is very little that the
router must do each update. This allows the processor to perform other tasks. At
the same time, there is no database being maintained. Its all contained in the
routing tables. This simplicity, however, requires increased bandwidth as the
entire routing table must be sent across the network. In a large network, this
can take considerable time. In addition, It is not uncommon for networks to be
more than 15 hops apart. This means that end nodes will not be able to contact
each other because the metrics surpass the "unreachable" point.
Configuration is a 3 step procedure. First, create a RIP process and
determine if any other routing process (such as IGRP or OSPF) is to redistribute
its routes into this one. Second, specify which networks will receive RIP
broadcasts. Third, configure any non-broadcast neighbors.
A sample configuration might look like
router rip redistribute igrp 1000 network 2.3.4.0 network 4.5.3.0 neighbor 4.5.5.2 neighbor 4.5.5.3
-
II. Configuring IGRP
-
The Interior Gateway Routing Protocol (IGRP) is a dynamic distance-vector
routing protocol designed by Cisco Systems in the mid-1980s. The advantages of
IGRP over RIP include the maximum diameter of the network. Networks over 15 hops
are unreachable in a RIP controlled network. IGRP allows up to 100 hops by
default and can be set to accept paths as far away as 255 hops.
IGRP uses a combination of user-configurable metrics including internetwork
delay, bandwidth, reliability, and load. Unlike RIP, IGRP routes are shared in
proportion to their cost to provide equal or unequal cost load balancing with up
to 4 paths to a given destination. Equal or unequal cost can be specified with a
variance factor. The variance determines how unequal paths can be when
performing load balancing. A variance of 1 (the default) specifies load
balancing only when all paths are of an equal cost. This behavior can be
overridden with the "traffic-share" command. To permit only the path with the
lowest cost to be used, specify "traffic-share min". "traffic-share balanced" is
the default.
Basic IGRP configuration is very similar to that of RIP. An IGRP routing
process must be created on the router and given a list of participating
networks. IGRP also accepts an optional Autonomous System number. When running
IGRP over a non-broadcast network, systems which will accept updates can be
entered individually with the "neighbor" command, as in RIP. Interfaces included
in the range of addresses specified with a network statement that should not
participate in IGRP (an example would be if that interface is managed through
some other protocol such as OSPF), it can be designated passive with the
"passive-interface" statement.
Example configuration:
router igrp 1000 variance 3 network 203.4.22.0 network 204.103.24.0 neighbor 204.103.24.5 neighbor 204.103.24.6 neighbor 204.103.24.7 passive-interface Ethernet4/1 passive-interface Fddi3/0
-
III. Configuring Enhanced IGRP
-
Enhanced IGRP is a redesign by Cisco of IGRP. It is intended to overcome some
of the limitations that became apparent when IGRP was put into heavy use.
Principally, improvements concentrated on the convergance time. Towards that
end, a new convergence algorithm, DUAL (Diffusing Update Algorithm) was
introduced. Among the benefits gained by the new algorithm is a guarantee of
loop-free routing tables where EIGRP is the controlling protocol. EIGRP also
introduces partial updates. This allows fewer routing messages to be exchanged
between routers which, in turn, consume less bandwidth, leaving the data path
free for user data. Partial updates also allow the receiving router to spend
less time recalculating routing tables since routes not included in the update
do not have to be recalculated.
Two key features of EIGRP are support for variable-length subnet masks and
arbitrary route summarization. This allows for the removal of "classfull" routes
in favor of CIDR routes, reducing the size of the routing table as a whole and
allowing for easier maintenance of routing tables. EIGRP is also capable of
automatically summarizing routes into common routes when possible. This feature
can be disabled by specifying "no auto-summary" in the EIGRP configuration.
Additional summarization can be performed within the router configuration on a
per interface basis by placing "ip summary-address eigrp" statements in the
interface configuration commands to advertise a specific aggregate as belonging
to a given autonomous system as shown below.
interface Ethernet0 ip summary-address eigrp 1234 201.200.8.0 255.255.224.0The result of this command is that advertisements of networks within the 201.200.8.0 block are reduced to a single advertisement of the aggregate block. So rather than sending routes for 32 class C networks, as RIP would do, a single advertisement encompassing all 32 networks can be made instead. Another addition to EIGRP is support for the exchange of hello messages. When an EIGRP process is started, the router will send out hello packets on all participating interfaces using multicast packets when appropriate. Once the router determines which other routers are participating in EIGRP, the process of exchanging updates can begin. This allows for routers to quickly determine when new routers are added to the network or when existing routers become unreachable. Basic configuration of EIGRP does not differ significantly from that of IGRP except that the router configuration command requires an EIGRP process ID instead of the optional autonomous system number. Like IGRP, EIGRP supports unequal cost load balancing. But because of EIGRP's rapid convergence, enabling this feature is not only desirable from a traffic standpoint, when enabled, the other paths are already in use so fall over time in the event of a failure is minimal. To ease the transition from IGRP to EIGRP, routes are automatically redistributed between the two protocols.
-
IV. Configuring OSPF
-
The Open Shortest Path First (OSPF) Protocol was designed by the IETF as an
IGP expressly for use with TCP/IP networks belonging to a single Autonomous
System. It is designed as a link state protocol and is scalable to all but the
most complex networks.
OSPF operates by forming adjacencies between routers and creating a
topological database containing information about the state of all the links in
the OSPF network. This information includes weights placed on various interfaces
based on the bandwidth of the link and the type of interface or placed there
manually by the network administrator. The cost of an internal path is
determined by calculating the sum of the cost of traversing each link in the
database. The path with the lowest cost (shortest path) is chosen as the best
route. If there are multiple paths with equal cost, OSPF will load balance
across up to 4 of these paths.
This database is updated whenever an adjacency is formed or dropped. Because
a complete picture of the network is maintained by every router, when an
adjacency drops and the corrosponding link is no longer availible, a new path
can quickly be chosen from information the router already has. However, because
it must hold a complete copy of the topological database, the memory
requirements are quite substantial.
On large networks, the number of links in the database can grow to immense
proportions. In these cases, a single link change can have a significant impact
on every router in the system. A link that is intermittantly availible and
unavailible can lead to high processor use for all routers, diminishing the
performance of the network. OSPF provides a method of segmenting the network
into several areas. These areas act as described above and are connected to a
"backbone" area (area 0). The area boundry routers, rather than propegating
every link state advertizement (LSA) into the backbone, only propegate "summary"
advertizements describing the area they are linked to. This summary
advertizement describes the entire area database in a single message, thus
reducing the computational overhead and memory usage. Dividing the network into
areas also reduces the impact of a single router or interface changing states on
the rest of the network. only the attached area must recalculate the paths
through that router or interface.
Use of stub areas and route summarization between areas can also help to
reduce the number of entries in the topological database and reduce the memory
requirements and CPU requirements for recalculating paths when changes occur in
the network even further. Stub areas do not receive external LSAs (those
injected into OSPF via redistribution from another protocol, such as RIP) and do
not have to maintain any link state records except those within the stub area.
Routers configured with OSPF discover other OSPF routers by multicasting or
unicasting hello packets to all SPF routers (multicast address 224.0.0.5). These
hello packets are used to form and maintain adjacencies between routers.
Adjacencies are formed automatically across point to point links. On
multiaccess networks such as ethernet, a "Designated Router" (DR) is elected.
This router forms adjacencies with all other routers on the multi-access network
and is responsible for synchronizing the topological database. In addition, a
backup designated router (BDR) is also selected. In the event of a failure which
disconnects the DR from the network, the BDR takes over and a new BDR is
elected. This reduces traffic across the network since each router does not have
to form an adjacency with every other router. This also reduces the CPU usage on
all other routers connected to this network when a router becomes unavailable.
Which routers are DR and BDR can be determined with either "show ip ospf
neighbors" or "show ip ospf interface <interface>".
OSPF is enabled by creating an OSPF routing process and specifying a process
ID. Which networks OSPF operates over is controlled by "network" statements (as
in RIP or IGRP). At the same time, these networks are assigned an area number.
Neighbors can be hinted at by using the "neighbor" statement. Note that a
neighbor does not necessarily form an adjacency. The exec command "show ip ospf
neighbor" can be used to determine which routers are viewed as neighbors and the
state of the link (whether they are simple neighbors, adjacent neighbors, BDR,
or DR.) A simple OSPF configuration is shown below.
Interface Ethernet0/0 ip address 1.1.1.1 255.255.255.0 Interface Serial1/2 ip address 1.1.2.1 255.255.255.0 Interface Fddi2/0 ip address 1.1.3.1 255.255.255.0 router ospf 1234 network 1.1.1.0 0.0.0.255 area 1 network 1.1.2.0 0.0.0.255 area 2 network 1.1.3.0 0.0.0.255 area 0
This sequence of commands configures OSPF on the three interfaces listed assigning Ethernet0/0 to area 1, Serial1/2 to area 2, and Fddi2/0 to the backbone area (area 0). Note that the network statements require a wildcard mask and not a network mask. OSPF also supports variable length subnetting and route sumarization though it must be configured manualy. Sumarization takes place between areas and into the OSPF backbone area. Configuration of summary networks is done at area border routers with the "area <area ID> range <network> <network mask>" command. Using route sumarization can greatly decrease the size of the topological database and reduce the amount of recalculation that needs to be done when a route becomes inaccessible or other topological changes occur. The backbone area should not be sumarized. If all other areas are summarized properly, all the backbone area will contain is summary routes. Similarly, sumarization can be done when another protocol is redistributed into OSPF with a "summary-address <network> <network mask>"
-
V. Configuring BGP
-
The Border Gateway Protocol (BGP) is another in the family of distance vector
protocols. However, unlike most routing protocols, BGP views its paths in terms
of Autonomous Systems (ASs). An AS is loosely defined as a collection of routers
under common administration. For example, Primenet is one AS, MCI is another,
AT&T a third, and so on. Each of these ASs has their own AS number, which is
used in the BGP exchange. Primenet's AS number (ASN) is 3549, MCI is 3561, and
so forth.
BGP functions by setting up peering sessions with neighboring routers. An
important advantage of BGP over other protocols is the use of TCP to transmit
update messages and maintain peering sessions. Because of this, these sessions
are not intended directly to be a measure of the link integrity, but more to
provide an idea of the health of the neighboring router. If the router becomes
unreachable or stops responding, the peering session will drop and the routes
received over that link will be deleted from the BGP tables and other routers
subsequently informed.
This loss of conectivity can be caused by the router going down due to a
failure or loss of power, a problem with the link the session is transmitting
over, or simply congestion which causes BGP information packets to be dropped.
With the explosion of the internet over the last several years, routers which
experience repeated BGP or EGP neighbor state changes have become more
problematic. This is usually caused by the router rebooting multiple times or by
an intermittant link. Most recently, a cause of such problems has been routers
simply being overwhelemd by update messages and being unable to maintain peering
sessions as a result. The term coined to describe this repeated advertizement
and deletion of routes is "route flap" or a router "flapping". The result is
that neighboring routers (and quite probably routers two or three links
downstream) being overwhelemd with these messages and spending all their time
recalculating paths. The effect of this is that those routers' services are
degraded until stability returns. It can even cause those routers to begin to
"flap" as well as the number of updates goes beyond what that router is capable
of processing, creating a cascade failure. A great deal of research and
development is being done by many companies at a feverish rate to produce
routers capable of handling these updates and many service providers have
instituted policies designed to reduce the size of the routing tables to reduce
flap or to protect themselves from flap by "dampening" routes that flap
repeatedly in a given interval.
A BGP route contains only a few pieces of information. The first is the
network that the route describes. Second, the AS path necessary to get to that
destination. Third, the origin of the route (External BGP or EBGP, Internal BGP
or IBGP, another Interior Gateway Protocol or IGP, or incomplete.) Fourth, the
router ID of the advertizing router, and finally, the BGP next hop address.
BGP provides a simple, yet effective loop detection method. Simply, the AS
path of the learned route is checked against the router's own AS number. If this
number apears anywhere in the path, the route is unusable and is discarded.
There are also a few weights and metrics associated with a BGP route which
are used to aid in the path selection process. The first is litterally known as
a "weight" and is used only by the router which sets it. This weight is not
propegated to other routers. The second is a "local prefference" value. This is
propegated to all routers belonging to a single AS. The last value availible is
a "metric" or "Multi Exit Descriminator" (MED). MEDs are advertized to EBGP
neighbors and is used to hint at the best path into an AS. The MED is reset when
the route is readvertized to a third AS.
The BGP path selection process is straight forward.
- If the next hop is inaccessible, do not consider it.
- Consider larger BGP administrative weights first.
- If the routers have the same weight, consider the route with higher local preference.
- If the routes have the same local preference, prefer the route that the local router originated.
- If no route was originated, prefer the shorter autonomous system path.
- If all paths are of the same autonomous system path length, prefer the lowest origin code (IGP < EGP < INCOMPLETE).
- If origin codes are the same and all the paths are from the same autonomous system, prefer the path with the lowest Multi Exit Discriminator (MED) metric. A missing metric is treated as zero.
- If the MEDs are the same, prefer external paths over internal paths.
- If IGP synchronization is disabled and only internal paths remain, prefer the path through the closest neighbor.
- Prefer the route with the lowest IP address value for the BGP router ID.
router bgp 3549 neighbor 1.2.3.4 remote-as 3549 neighbor 2.3.4.5 remote-as 380Advertizements of reachable networks can be controlled by redistributing another protocol into BGP or by manualy configuring these networks as in the following example.
network 1.0.0.0The class A network 1.0.0.0 is placed in the iBGP routing tables and becomes eligible for advertizement to eBGP peers with an origin code of "IGP". In general, this is the prefered method of advertizing BGP networks as redistribution of other protocols into BGP results in the loss of information about those networks learned by the IGP and mutual redistribution can lead to routing loops. In the normal case, BGP must synchronize with an IGP. This means that a route learned by an eBGP peer will not be readvertized to another eBGP peer until the IGP has propegated this route to all routers in the local autonomous system. This has the effect of making certain that the route is not used before all routers know about it, resulting in data loss and serving to stabalize the network somewhat. However, this can slow convergance when routes change and increase the size of the IGP tables. To disable synchronization, use the BGP "no synchronization" command. If redistribution is not used, synchronization must be disabled for BGP to function. Beginning with BGP version 4, BGP supports CIDR and route summarization. Summarization is enabled by default and can be disabled using the "no summarization" command. Routes are summarized by creating aggregate addresses. This has the effect of advertizing a single supernet for multiple related routes when possible in addition to the individual routes. Using the "summary-only" option, these more specific routes can be surpressed. router A:
router bgp 3549 neighbor 1.2.3.5 remote-as 3549 network 1.2.0.0 mask 255.255.0.0 network 1.3.0.0 mask 255.255.0.0 network 1.1.8.0 mask 255.255.248.0router B:
router bgp 3549 aggregate address 1.0.0.0 255.0.0.0 summary-only neighbor 1.2.3.4 remote-as 3549 neighbor 2.3.4.5 remote-as 1111In the preceding example, router A is configured with one iBGP peer and begins advertizing 3 subnets of the 1.0.0.0 class A. Router B configures one iBGP neighbor and one eBGP neighbor and summarizes routes learned from router A into a single advertizement which is sent to the eBGP peer. Often, the closest path to a site may not be the best path, either because of bandwidth limitations or performance problems. The most direct way to prefer one neighbor's routes over another is to simply filter the advertizements to remove the unwanted routes. This can be done based on network prefix or AS path.
router bgp 3549 neighbor 1.2.3.4 remote-as 1111 neighbor 1.2.3.4 distribute-list 1 in neighbor 2.3.4.5 remote-as 2222 neighbor 2.3.4.5 filter-list 7 in access-list 1 deny 10.0.0.0 0.255.255.255 access-list 1 permit any ip as-path access-list 7 deny _5555$ ip as-path access-list 7 permit .*The preceding example prevents neighbor 1.2.3.4 for advertizing that it can reach the network 10.0.0.0/8 and prevents neighbor 2.3.4.5 from advertizing that it can reach any path where ASN 5555 is the last ASN in the path. The as-path regular expressions are documented in the cisco documentation set and follow general regular expression rules. Note that access lists and route maps (as illustrated below) can be applied to either inbound or outbound advertizements. Filtering advertizements is an easy way to determine how you want your network to route but it has one big drawback: if the primary route is down, the destination simply becomes unreachable. The filter prevents the secondary route from ever appearing in the first place. BGP provides two alternative ways of influencing the path selection process: weights and local prefference values.
router bgp 3549 neighbor 1.2.3.4 remote-as 1111 neighbor 1.2.3.4 weight 300 neighbor 2.3.4.5 remote-as 2222Configuring weights for all of a neighbor's routes requires no more than an additional statement in the BGP configuration, specifying the weight that should be assigned to these routes. If two neighbors advertize that they can reach the same network, the path with more weight will be selected. It should be noted that the configured weight is only used by the router that sets it. If you want every router in your AS to prefer the same path, you can use a "route map" to set a local preference value. This value will be propegated to every iBGP peer that receives this route. Routes with no local preference set receive a local preference of 100. Higher local preferences are selected first.
router bgp 3549 neighbor 1.2.3.4 remote-as 1111 neighbor 1.2.3.4 route-map set-weight in route-map set-weight permit 10 set local-preference 200Route maps allow complex filtering to be performed based on multiple conditions. There can be multiple statements underneath a route-map to alter a variety of attributes. The routes altered can also be limited by further filtering the advertizements by using an access-list (prefix or AS path) to "match" a subset of the routes being processed. It is also possible to apply multiple policies to the same neighbor. These policies are ordered sequentially according to the number listed after the "permit" or "deny" statement. The following example illustrates some of these capabilities.
router bgp 3549 neighbor 1.2.3.4 remote-as 1111 neighbor 1.2.3.4 route-map local-policy in neighbor 1.2.3.4 distribute-list 25 in route-map local-policy permit 10 match as-path 1 set weight 300 route-map local-policy permit 20 match ip address 20 set local-preference 125 route-map local-policy permit 30 set as-path prepend 1111 ip as-path access-list 1 deny _350_ ip as-path access-list 1 permit .* access-list 20 permit 120.10.0.0 0.0.255.255 access-list 20 deny anyThis example also demonstrates that it is possible to alter the AS path of a given route. By prepending the appropriate AS number, it is possible to increase the path length of a BGP route, making it further away. One problem with running iBGP is the requirement of BGP for a "full mesh" within the AS (every router must establish a peering session with every other router). Clearly, this is not possible in all settings and can create problems when a great meny peering sessions must be maintained on a single router. There are ways to reduce the mesh needed to propegate iBGP routes and simplify the structure of the autonomous system. The first of these is router reflectors. Normaly, when a route is received from one iBGP speaker, it is not readvertized to another. Route reflectors provide a way to permit this occurence. Each client's routes are reflected to every other iBGP router that the server peers with. The clients are configured as normal iBGP speakers. The server simply designates clients as such.
router bgp 3549 neighbor 1.2.3.4 remote-as 3549 neighbor 1.2.3.4 route-reflector-client neighbor 1.2.3.5 remote-as 3549 neighbor 1.2.3.5 route-reflector-clientWith such a configuration, peering between 1.2.3.4 and 1.2.3.5 is not necessary since the route server reflects the routes received by each neighbor to the other neighbor. Another method of reducing the iBGP mesh is to create a confederation, effectively splitting the single AS into several smaller autonomous systems. These "mini-ASs" must be fully meshed but only require one connection between themselves and other mini-ASs. Confederations allow the smaller ASs to exchange routes between themselves as if they were using iBGP (local preference values, MEDs, etc are all preserved). To the rest of the world, the confederation appears as a single AS.
router bgp 65501 bgp confederation identifier 3549 bgp confederation peers 65502 65503 neighbor 1.2.3.4 remote-as 65501 neighbor 1.2.3.5 remote-as 65501 neighbor 2.3.4.5 remote-as 65502 neighbor 2.3.4.6 remote-as 65503 neighbor 2.3.4.6 weight 300 neighbor 5.5.5.5 remote-as 1050 neighbor 5.5.5.5 route-map set-preference inThe local router is identified to the confederation as 65501. It is identified to non-confederation peers as ASN 3549. AS 65502 and 65503 are also members of this confederation. iBGP connections are configured between this router and the routers listed as 1.2.3.4 and 1.2.3.5. Peering sessions are established between this router and the confederation members 65502 and 65503. There is also an eBGP session established with router 5.5.5.5 with the remote ASN of 1050. This router will view the peer as AS 3549 and not be aware of 65501, 65502, or 65503. This router sets the local preference for AS 1050 and passes it to every iBGP peer and the rest of the confederation.
VI. Exchanging Routes Between Protocols
router eigrp 10 redistribute rip router rip redistribute eigrp 10The routes that one protocol learns are now visible to the other. But assume for a momment that the network running RIP only needs to default out to the network running EIGRP. In this case, the RIp network does not need to see the eigrp routes and the redistribution is only necessary into EIGRP. This saves memory on the RIP routers, network bandwidth, calculation time, etc and generaly makes things run cleaner. It also eliminates one problem with the configuration shown above. Once the routes from the RIP process are distributed into the EIGRP process, they become EIGRP routes and are eligigle to be distibuted BACK into the RIP process. This can create routing loops and destroy the connectivity of the network. When using such mutual redistribution, careful filtering is required to avoid such pitfalls. This filtering is set by using a route-map along with the redistribution statement. In this example, the RIP network needs to learn the EIGRP routes and send its routes back. The RIP network manages routes for 10.2.3.0/24 and 10.2.4.0/24. The EIGRP network routes the rest of the 10.0.0.0/8 network.
router eigrp 10 redistribute rip route-map rip-in router rip redistribute eigrp 10 route-map eigrp-in route-map rip-in permit 10 match ip address 20 route-map eigrp-in permit 10 match ip address 21 access-list 20 permit 10.2.3.0 0.0.0.255 access-list 20 permit 10.2.4.0 0.0.0.255 access-list 21 deny 10.2.3.0 0.0.0.255 access-list 21 deny 10.2.4.0 0.0.0.255This effectively limits the routes seen by the two processes. This is not the only method of filtering, however. Assuming the same access lists, the following two configurations would also work.
router rip redistribute eigrp 10 metric 2 distribute-list 21 in router eigrp 10 redistribute rip default-metric 1000 100 250 100 200Or
router rip redistribute eigrp 10 distribute-list 20 out router eigrp 10 redistribute rip distribute-list 21 outThese two examples accomplish the same end result as the route-map example above. In addition, two other features are demonstrated. The first is the setting of a metric on the inbound routes. The second is a default metric used when the metric cannot properly be calculated or when information is missing (as in the redistribution). This information is specific to the protocol and the command refference guide should be used to determine which values to use.
No comments:
Post a Comment