Static Routing
Static Routing Usually
an experienced network administrator will seek to minimize any manual
configuration. In the case of Exterior routing, this may be different,
as static routing offers a number of advantages when routing between
Autonomous Systems. These advantages can be summarized as follows:
The downsides
are obvious. Static routes do not adapt to link failures, and manual
configuration can be a headache to maintain. Despite these downsides,
static routing is often a popular choice for connecting internetworks
that do not "trust" each other. Lets say Autonomous System 1 consists of
network numbers 45.0.0.0 and 46.0.0.0, and Autonomous System 2 consists
of network numbers 47.0.0.0 and 48.0.0.0. This is illustrated in the
following figure:
Static Routing Between Autonomous Systems
To complete static routing for connecting these two autonomous systems together, use the following commands:
RouterA(config)#ip route 47.0.0.0 255.0.0.0 80.4.4.5
RouterA(config)#ip route 48.0.0.0 255.0.0.0 80.4.4.5
RouterA(config)#ip route 48.0.0.0 255.0.0.0 80.4.4.5
RouterB(config)#ip route 45.0.0.0 255.0.0.0 80.4.4.4
RouterB(config)#ip route 46.0.0.0 255.0.0.0 80.4.4.4
RouterB(config)#ip route 46.0.0.0 255.0.0.0 80.4.4.4
This tells each Autonomous System how to get to networks in the other Autonomous System.
Exterior Gateway Protocol
As its name suggests, the Exterior Gateway Protocol, or EGP, was the first example of an exterior gateway protocol. EGP has three components, Neighbor acquisition, Neighbor reachability and routing information. EGP was designed to add a measure of automation to the configuration of routes between different Autonomous Systems.
As its name suggests, the Exterior Gateway Protocol, or EGP, was the first example of an exterior gateway protocol. EGP has three components, Neighbor acquisition, Neighbor reachability and routing information. EGP was designed to add a measure of automation to the configuration of routes between different Autonomous Systems.
The
routing information of EGP is similar to distance vector protocols, but
it omits the metric for routes advertised. EGP was implemented like
this because it was designed for the Internet, when it was assumed that
there would be a core network, with separate routing domains connected
to this core by one router. The major problem with using EGP in a more
generalized network is that, since no use is made of metrics, if there
is more than one path to a destination, packets can very easily get
caught in routing loops.
EGP has been superseded by the Border Gateway Protocol, BGP.
Border Gateway Protocol - BGP
BGP was introduced to improve upon EGP. The main features of BGP are that it introduced a reliable transport protocol, to ensure that route updates are received. BGP also implements a keepalive mechanism, ensuring that BGP routers know if neighboring BGP routers fail. BGP does not transmit metrics with it's route updates, but does transmit a path for each AS that lists the AS's to be visited on the way to the destination AS. BGP thus avoids the circulating packet problem of EGP.
BGP was introduced to improve upon EGP. The main features of BGP are that it introduced a reliable transport protocol, to ensure that route updates are received. BGP also implements a keepalive mechanism, ensuring that BGP routers know if neighboring BGP routers fail. BGP does not transmit metrics with it's route updates, but does transmit a path for each AS that lists the AS's to be visited on the way to the destination AS. BGP thus avoids the circulating packet problem of EGP.
BGP
works on the principle of enforcing policies. A policy is manually
configured and allows a BGP enabled router to rank possible routes to
other Autonomous Systems, selecting the best path.
Configuring BGP
We can use an example to discuss how to configure BGP on a router. In this example, let's take router R6. To configure BGP we will perform the following:
We can use an example to discuss how to configure BGP on a router. In this example, let's take router R6. To configure BGP we will perform the following:
Network Configuration for BGP Example
This
is a basic configuration for BGP, there are however many many further
configuration customizations that can be made. For a fuller discussion
of BGP configuration, refer to "Multi-Homing Your Internet Service With BGP" .
The following commands are entered in to router R6.
Router6(config)#router bgp 3
Router6(config-router)#network 147.30.0.0
Router6(config-router)#network 150.1.0.0
Router6(config-router)#neighbor 147.30.1.1 remote-as 3
Router6(config-router)#neighbor 160.4.5.5 remote-as 2
Router6(config-router)#network 147.30.0.0
Router6(config-router)#network 150.1.0.0
Router6(config-router)#neighbor 147.30.1.1 remote-as 3
Router6(config-router)#neighbor 160.4.5.5 remote-as 2
The
first line in this configuration defines BGP for Autonomous System 3 on
router 6. The next two lines define the network numbers internal to AS 3
that will be advertised via BGP. The fourth line defines an internal
neighbor, that is in the same AS. The BGP process on router 6 will now
exchange information with a BGP process defined on R5. The fifth line
defines the neighbor in a different AS that router 6 will exchange
information with.
The
effect of this configuration is that R6 will share information about
network s 147.30.0.0 and 150.1.0.0 with the two specified routers via
BGP updates.
The
last thing left to do in our basic configuration of BGP, is to assign
administrative weights to control the path selection process. In the
following example, a weight of 40,000 is assigned to the path to router
R4
Router6(config-router)#neighbor 160.4.5.5 40000
This
administrative weight can vary between 0 and 65535, the default being
32768. The effect of increasing the weight to R4 is to make it less
attractive when R6 is calculating which paths to use.
Redistributing Route Information Between Protocols
If you have the opportunity of building a network from scratch, and could design it such that the only devices to run routing protocols are routers, you could choose your favorite protocol and use that exclusively. Typically, though, the situation is that there is an existing network with an existing routing protocol in place, and more often than not, UNIX machines have some routing responsibilities in a network. As many UNIX machines only support RIP and it is unlikely that RIP will be the best choice of routing protocol for an internetwork of any size, the question arises how more than one routing protocol can co-exist on an internetwork, either permanently, or during a period of migration.
If you have the opportunity of building a network from scratch, and could design it such that the only devices to run routing protocols are routers, you could choose your favorite protocol and use that exclusively. Typically, though, the situation is that there is an existing network with an existing routing protocol in place, and more often than not, UNIX machines have some routing responsibilities in a network. As many UNIX machines only support RIP and it is unlikely that RIP will be the best choice of routing protocol for an internetwork of any size, the question arises how more than one routing protocol can co-exist on an internetwork, either permanently, or during a period of migration.
The
answer is Redistribution. A router can be configured to run more than
one routing protocol and Redistribute route information between the two
protocols. The idea is that there will be multiple domains on the
internetwork, each operating with a different routing protocol. At the
border between these domains, one router has the responsibility of
running both routing protocols and informing each domain about the
other's networks in the appropriate routing protocol. This is
illustrated below:
A Border Router Configured to Redistribute Between RIP and IGRP
In
this example, router 1 has to run both RIP and IGRP, then inform Domain
A about the networks in Domain B with RIP updates and inform Domain B
about Domain A's networks using IGRP updates. The router in this figure
will only be able to assign one metric to all the routes that it
redistributes from one Domain to another. It cannot translate metrics
between protocols. At first this may seem to be a drawback, that all
networks are redistributed with the same metric value, no matter where
they are located in the other Domain. In reality this is not a problem,
since to get from Domain A to Domain B, all connections have to go
through the same router, so the initial part of the journey is identical
when sending packets between Domains.
In
this example, a packet destined for Domain A, originating in Domain B
reaches router 1. Router 1 then has a routing table filled with entries
for the networks in Domain A that have been calculated using RIP
updates. The packet will then follow the best path to it's destination
network.
The
following is an example of how the routing protocol processes could be
configured on router 1, to redistribute routes between the RIP and IGRP
Domains.
Given a basic configuration for both RIP and IGRP, the redistribute commands are in bold:
router igrp 12
timers basic 15 45 0 60
network 164.8.0.0
network 193.1.1.0
no metric holddown
metric maximum-hop 50
redistribute rip
default - metric 300 344 200 200 200
timers basic 15 45 0 60
network 164.8.0.0
network 193.1.1.0
no metric holddown
metric maximum-hop 50
redistribute rip
default - metric 300 344 200 200 200
router rip
network 150.1.0.0
network 120.0.0.0
redistribute igrp 12
default-metric 3
network 150.1.0.0
network 120.0.0.0
redistribute igrp 12
default-metric 3
This
assumes that Domain A has network numbers 150.1.0.0 and 120.0.0.0 in it
and Domain B has networks 164.8.0.0 and 193.1.1.0 in it.
The
five values following the default-metric entry in the router IGRP
section are the metrics that will be sent out in IGRP updates, for
routes learned about via RIP. In the router RIP section, routes learned
from IGRP updates will be advertised with a metric of 3. It must be
noted that the numbers shown here are random. In most instances this
does not matter, as all cross domain traffic has to go through router 1
as previously explained.
As
you can see, once you start to configure subnets and use multiple
network numbers, autonomous systems and redistribution, life can get
tricky! The best advice we can leave you with is to be careful out
there!
Answers to subnet questions
Subnet 164.2.34.32
Usable host addresses 164.2.34.33 to 164.2.34.62
Broadcast address 164.2.34.63
Usable host addresses 164.2.34.33 to 164.2.34.62
Broadcast address 164.2.34.63
Subnet 101.2.0.0
Usable host addresses 101.2.0.1 to 101.2.255.254
Broadcast address 101.2.255.255
Usable host addresses 101.2.0.1 to 101.2.255.254
Broadcast address 101.2.255.255
0 comments: