CCNA Exploration: Routing Protocols and Concepts Chapter 9 Case ...

finnishburroNetworking and Communications

Oct 28, 2013 (3 years and 9 months ago)

86 views



CCNA Exploration: Routing Protocols and Concepts 
Chapter 9 Case Study


© 2009 Cisco Learning Institute
 
 
Objectives:
• Consolidate EIGRP knowledge.
• Introduce the Route Redistribution concept.
• Introduce the EIGRP External Routes concept.
• Introduce the Default Metric concept.

Intro:
OTB Inc. is having trouble on their network and needs help. Part of their network has no connectivity.

Topology:




CCNA Exploration: Routing Protocols and Concepts 
Chapter 9 Case Study


© 2009 Cisco Learning Institute
 
 
Scenario:
According to the report, network 1 and network 2 are not able to reach network 3. As shown on OTB
Network Topology above, OTB Inc. has 2 routing protocols running due transition issues. The goal is to
have only one protocol running within the network but for now the older protocol must be kept. In order to
achieve full connectivity, OTB routes generated by one routing protocol must be injected into the other
one.

Step 1 – Checking the routers
You connect to R3 via console port to check its configuration. R3 is a RIPv2 speaker and a quick look at
its configuration does not show anything unexpected: RIPv2 is correctly configured at R3, all R3
interfaces are up but R3 learned no routes via RIPv2.
Still from R3, you issue a few pings: pings to a few PCs under network 3 and to R4’s serial 0/0 interface
are successful. Pings to R2’s interfaces and to R1’s interfaces fail.
You also issue a few pings from a few PCs under network 3 towards a few PCs under network 1 but all of
such pings fail.
A quick look into R3’s routing table reveals it has no default route or routes to the EIGRP side of OTB’s
network. Since R3’s configuration is correct, you assume some router was incorrectly configured and
thus, wrongly advertising routes.
Since R3 is not learning routes from the EIGRP side, you decided to check EIGRP configuration into the
EIGRP routers. You move to the EIGRP side, switch the console cable to R1 and check its configuration.
Once more, the configuration is correct: all R1’s interfaces are up, EIGRP is correctly configured and R1
has EIGRP routes installed into its routing table. R1 has a default route pointing to R4’s fa0/0 which was
learnt via EIGRP from R4.
R1 also has EIGRP routes to network 3 (192.168.3.0/24). Such routes were learnt from R4 and are
flagged as external EIGRP routes.

Question 1:
What is the meaning of an EIGRP External Route?
Answer: EIGRP flags any route learnt from outside of the local EIGRP Autonomous System as external.
Usually such routes were generated by another routing protocol OR by another EIGRP instance running
under a different AS number and redistributed into the local AS EIGRP.





CCNA Exploration: Routing Protocols and Concepts 
Chapter 9 Case Study


© 2009 Cisco Learning Institute
 
 
Question 2:
How are EIGRP external routes identified?
Answer: EIGRP flags external routes with ‘EX’ in the router’s routing table.
You issue a few pings from R1 to different points of OTB network. Pings sent to the EIGRP side and to
the Internet are successful but pings sent to the RIPv2 side fail.
You switch the console cable to R2’s console port and check its configuration. A quick check reveals no
problems into R2. EIGRP routes exist into R2’s routing table, all of its interfaces are up and the
configuration is correct. As R1, R2 pings successfully the EIGRP side and random locations out on the
Internet but fails to ping OTB’s RIPv2 portion. Just as R1, R2 also has routes generated by the RIPv2
side and flagged as EIGRP external routes.
Since R1 and R2 both have correct routes to the RIP side, you suspect R4 has the cause of the problem.
You move the console cable once more and connect it to R4.
You connect the console cable to R4 and check its configuration. Because R4 is the junction point of both
routing protocols (RIPV2 and EIGRP), R2 speaks both protocols at the same time.
R4 speaks EIGRP to R1 and R2 and RIPv2 with R3. Because there are 2 different protocols running into
R4 and they need to know about each other’s routes, a technique called 2-Way Route Redistribution
must be used.
Route Redistribution consists in injecting routes learnt from sources external to the routing protocol into
the routing protocol domain. In OTB’s network, RIPv2 routes must be injected into the EIGRP domain and
EIGRP routes must be injected into the RIPv2 domain. R4 is responsible for the redistribution because it
is the router speaking both protocols. After injected, the routes become part of that routing protocol. Some
routing protocols differentiate redistributed routes from local routes (EIGRP, OSPF, IS-IS, etc), others
don’t (RIP).
You confirm EIGRP is configured correctly in R4, all R4 interfaces are up and R4’s routing table has all
expected EIGRP routes. R4 also has a static default route pointing to R4’s serial 0/1 and despites R4
advertises it via EIGRP to its EIGRP neighbors, R4 is not advertising its default route via RIPv2.
Because R4 runs both RIPv2 and EIGRP, its routing table has routes learnt from both routing protocols.
Pings from R4 to different points of OTB network are successful but you notice R4’s RIPv2 configuration
is wrong.
Even though, RIPv2 routes are being correctly redistributed into EIGRP, EIGRP routes are not being
redistributed into RIPv2. This scenario is called One-Way Redistribution and even though it is suitable in
some cases, OTB network requires a Two-Way Redistribution.





CCNA Exploration: Routing Protocols and Concepts 
Chapter 9 Case Study


© 2009 Cisco Learning Institute
 
 
Question 3:
What is Two-Way Redistribution?
Answer: Two-way redistribution is when a router speaks 2 routing protocols and both routing protocols
are injecting their routes into each other.
You take a closer look into RIPv2 configuration in R4. The redistribution command was entered but no
default metric was defined.
Default metric is a value set as metric of redistributed routes. Different routing protocols have different
default metric values. Since RIPv2 uses infinite as default metric, if no manual defined default metric is
set, RIPv2 sets the redistributed routes’ metric to infinite. Routes with metric set to infinite are not
reachable and thus, not advertised. This leads R3 to never learn about routes generated by the EIGRP
side.
Note: Redistributed connected and static routes are treated differently by RIP: when redistributing
connected and static routes into RIP, the default metrics are 0 for connected routes and 1 for static
routes.
Still in R4, you set the RIPv2 default metric to 3. From now on, all EIGRP 100 routes redistributed into
RIPv2 will have their metric set to 3. The commands are documented below:
R4(config)# router rip
R4(config-router)# redistribute eigrp 100 metric 3
R4(config-router)# end

Question 4:
Why was the default metric set to 3?
Answer: The good practice says default-metrics to redistributed routes must be higher than the largest
metric of the internal routes. This practice helps to keep the router from installing sub-optimal paths into
the routing table.
You check R3’s routing table once more and notice the routes generated at the EIGRP side are now
installed into it.
For more info about route redistribution visit:
http://www.cisco.com/warp/public/105/redist.html

Still from R3, you issue a few pings to the EIGRP networks and watch them flow successfully.
Note: As RIP, EIGRP also sets the metric of routes redistributed into it to infinite by default. In this Case
Study, EIGRP in R4 was declared “correctly configured” which includes the manually set default metric.



CCNA Exploration: Routing Protocols and Concepts 
Chapter 9 Case Study


© 2009 Cisco Learning Institute
 
 
Question 5:
How do the EIGRP generated routes appear into R3’s routing table? Are they flagged as EIGRP routes or
as RIP routes?
Answer: Since they were redistributed (injected) into RIPv2, they are flagged as RIP routes.

Question 6 – Challenge Question:
Is network 3 able to reach the Internet or any other network out of OTB? Explain. If not, what should be
changed to allow network 3 reaching networks other than OTB’s?
Answer: No. Because the default network was not included into RIPv2 process in R4 and no static
default-route was configured in R3, R3 has no default-network (neither advertised by R4 or static).
Two solutions are shown:
1. Create a static default-route in R3 pointing to R4
2. Configure R4 to advertise the network 200.200.200.0/24 to R3 as a default network.

Note: Even though option 3 is correct, to redistribute directly connected routes is not a common practice.