Routing Protocols and Concepts Chapter 5 Case Study

woonsocketpoliticalΔίκτυα και Επικοινωνίες

28 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

69 εμφανίσεις



CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
Objectives:
• Enforce RIPv1 poor metric calculation (hop count).
• Enforce importance of smooth routing protocol migration.
• Introduce the concept of Load Balance.
• Consolidate the interface bandwidth command importance to routing protocols.

Intro:
In order to achieve redundancy Tred Inc. hired another link and called you to configure it.

Topology:





CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
Scenario:
As you know, Tred has 3 physically separate offices. From a network perspective, they are identified as
Branch 1 (B1), Branch 2 (B2) and Main (M). Main was the first office created and it has a connection to
Internet. As shown on the topology above, B1 and B2 reach Internet via M.
Tred hired 2 512Kb WAN links from the telephony company to interconnect all 3 sites. The first WAN link
connects B1 to B2 and the second, B2 to M. A third 2Mb link connects M to the internet. In order to
provide a second redundant path to M, a third 1Mb/s link was hired. The new link connects B1 directly to
M. M is responsible for providing Internet connectivity to all Tred Inc. sites and for routing packets to/from
Network 3 (192.168.3.0/24).
After a study on Tred network, you decide not only configure the new link but also, update Tred’s network
routing protocol. Currently Tred network runs RIPv1 but because the new link has different bandwidth,
RIPv1 will no longer be able to accurately calculate and choose the best path.

Question 1:
Why are RIPv1 routes’ metrics no longer accurate within Tred Inc. network?
Answer: Since a new link with different bandwidth is about to be added to the network and RIPv1 doesn’t
consider bandwidth when calculating the best route (RIPv1 only considers the number of hops to a
destination), the updated topology obsoletes RIPv1.

You decide to accomplish the task in 2 steps:
1. Migrate from RIPv1 to another routing protocol.
2. Configure the new link.
Step 1 - The Migration
The new routing protocol to be run by Tred must consider bandwidth as a parameter when calculating
routes’ metric. Because Tred’s routers do not have much processing resources (CPU, memory, etc) you
choose Cisco IGRP as their new routing protocol.
Note: Newer Cisco IOS versions don’t support IGRP anymore. Even though IGRP fits the needs of this
Case Study, a more reliable and more robust protocol should be considered when designing a new
network.
At router M, you configure IGRP. Because IGRP uses bandwidth as a parameter when calculating a
route’s metric, you use the interface command bandwidth xxx to configure a bandwidth on that interface.
Notice you kept RIPv1 configuration for now. The commands are documented below:
M(config)# int se0/1
M(config-if)# bandwidth 512


CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
M(config)# router igrp 100
M(config-router)# network 192.168.3.0
M(config-router)# network 192.168.6.0
M(config-router)# end


Question 2:
Does the interface bandwidth command change the actual bandwidth of the interface?
Answer: No. The bandwidth command simply sets a string value (alphanumeric value) which has no
relation to the actual bandwidth of the interface. Even though no relation to the actual interface bandwidth
exists, some routing protocols base their functions and calculations on that string.
Note: The default value for the bandwidth string on Cisco routers’ serial interfaces is 1.544Mb/s. This
value was chosen as default because the router assumes a T1 link will be connected to that interface.
When the actual bandwidth of the link connected to a specific serial port is different of 1.544Mb/s, the
bandwidth value has to be manually adjusted to keep routing protocols from taking wrong decisions.
Ethernet and Fast-Ethernet link don’t need such adjust because their default value already represents the
actual bandwidth (10Mb/s and 100Mb/s, respectively).

Question 3:
Why RIPv1 was kept on M?
Answer: Tred’s network is in production which means it should not be stopped. By keeping RIPv1
configuration while working on IGRP ensure no loss of connectivity during the migration.
Still on M, you issue a show ip protocols command to confirm IGRP configuration. Everything looks good.

Question 4:
How many routing protocols are shown on M’s sh ip protocols output?
Answer: 2. RIPv1 and IGRP.
From M, you connect to B2 via telnet and configure IGRP. Once more, you keep RIPv1 configuration on
B2. The commands are documented below:
B2(config)# int se0/0
B2(config-if)# bandwidth 512
B2(config)# int se0/1
B2(config-if)# bandwidth 512
B2(config)# router igrp 100
B2(config-router)# network 192.168.2.0
B2(config-router)# network 192.168.5.0
B2(config-router)# network 192.168.6.0
B2(config-router)# end


CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
Question 5:
Why the number 100 is repeated on the command router igrp 100? Is it necessary or a different number
could be used?
Answer: This number is the Autonomous System ID (AS ID). It differentiates internal IGRP routers from
external IGRP routers and it should be the same in all routers speaking IGRP within an organization.
You check B2’s routing table and notice a few routes learnt from M via IGRP are already in place. You
also notice some of the routes previously learnt from M via RIPv1 are now replaced by routes learnt from
M via IGRP. A quick look at M’s routing table (after B2 has its IGRP process configured) shows the same
behavior: IGRP routes learnt from B2 replaced RIPv1 routes. You also notice B2 and M still have RIPv1
routes learnt from B1.

Question 6:
Even though RIPv1 is still running on B2 and M, IGRP routes replaced RIPv1 routes on both routers. Is
this correct? Why?
Answer: Yes. The routing table keeps only the best route. Even though RIPv1 is still running on both
routers, IGRP administrative distance is smaller than RIPv1 administrative distance. This difference
makes IGRP routes better than RIPv1 routes and leads to the replacement into the routers’ routing tables.
Because of your strategy of keeping RIPv1 running, the network is still running. From B2 you issue a
telnet to B1. You configure B1’s IGRP process and check its routing table. Routes learnt via IGRP from
B2 and M replaced the same routes learnt via RIPv1. The IGRP commands issued in B1 are documented
below:
B1(config)# int se0/0
B1(config-if)# bandwidth 512
B1(config)# router igrp 100
B1(config-router)# network 192.168.1.0
B1(config-router)# network 192.168.5.0
B1(config-router)# end

You issue a few pings and watch them flow successfully through the network.
Since IGRP is working, it is time to remove RIPv1 from the routers using the command no router rip. You
are already connected to B1 and start by it. Then you remove RIPv1 from B2 and finally from M. A look at
the routers configuration, routing table and routing protocols confirms RIPv1 was successfully removed
and IGRP runs flawlessly. A few more successful pings show the connectivity is still guaranteed.





CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
Step 2 – Configuring the new link
Once the migration is done, it’s time to configure the new link.
You ensure the cables are properly connected to M and B1. You notice that since there is a telephony
company providing the link, both M and B1 will be DTE ends of the connection (the telephony company’s
modem device (CSU/DSU) will work as DCE end) and therefore, no clock rate configuration is necessary
on M or B1.
Starting by router M, you configure IP address, mask, bandwidth and add the new network to M’s IGRP
process. The commands are listed below:
M(config)# int se1/0
M(config-if)# ip address 192.168.7.1 255.255.255.0
M(config-if)# bandwidth 1024
M(config-if)# no shutdown
M(config-if)# router igrp 100
M(config-router)# network 192.168.7.0
M(config-if)# end


You connect to B1 and configure the same. Once more, the commands are documented below:
B1(config)# int se0/1
B1(config-if)# ip address 192.168.7.2 255.255.255.0
B1(config-if)# bandwidth 1024
B1(config-if)# no shutdown
B1(config)# router igrp 100
B1(config-router)# network 192.168.7.0
B1(config-if)# end

You check M’s and B1’s routing table and routing protocols configuration and notice it looks correct. To
ensure everything is according to the expected, you check B2 routing table: B2 now has 2 equal cost
routes to network 7 on its routing table: One via M and the other via B1, both learnt via IGRP.

Question 6:
“B2 now has 2 equal cost routes to network 7 via M and via B1 on its routing table”. If only the best path is
placed on the routing table, how can B2 have 2 paths to network 7? Is this correct?
Answer: Yes, it is correct. Since the links connecting B2 to M and B2 to B1 have the same bandwidth,
IGRP calculates the very same metric to both routes. Since the metric are the same, both routes are
equally good. When this situation happens, Cisco Routers place both routes in the routing table and use
them both to forward packets. This technique is called Load Balancing and is the default behavior on
Cisco Routers.



CCNA Exploration: Routing Protocols and Concepts 
Chapter 5 Case Study


© 2009 Cisco Learning Institute
 
 
Question 7:
What would happen if the interface bandwidth value was changed to 64Kb/s on B2’s se0/1 interface?
Answer: Even though the actual bandwidth of the interface would be untouched, IGRP would be forced
to recalculate the metrics of all routes which use that interface based on the new bandwidth value. B2’s
serial0/1 connects B2 to M. Since 64Kb/s is slower than 512Kb/s, the route to network 7 learnt from B1
(faster interface) would get a better metric than the route via M (slower interface, from IGRP standpoint).
IGRP, choosing the best route, would place only the route to network 7 via B1 into B2’s routing table.
You issue a few pings from different points of Tred’s network and all of them are successful. The
migration and link configuration is complete.