Objectives: Consolidate routing table reading skills. Introduce the idea of more than 1 routing protocol running into the same router. Explain the use of routes to Null0 interface. Intro: Connex Inc. is having trouble on their network and needs help. Part of their network has no connectivity. Topology:
Scenario: According to the report, network 1 is not able to reach network 2. As shown on Connex Network Topology above, Connex 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. Step 1 Checking the routers You connect to R4 via console port to check its configuration. R4 is a RIPv2 speaker and a quick look at its configuration does not show anything unexpected: RIPv2 is correctly configured at R4, R4 has valid routes learnt via RIPv2, and all interfaces are up. R4 also has a default route, learnt via RIPv2 and pointing to R3 s serial 0/0. Still from R4, you issue pings to a few PCs under network 2, to R3 s interfaces, to R2 s interfaces, to R1 s interfaces and watch them flow successfully. You also issue a few pings from a few PCs under network 2 towards a few PCs under network 1 but all of such pings fail. You switch the console cable to R3 and check its configuration. Once more, the configuration looks good: all R3 s interfaces are up, RIPv2 is correctly configured and R3 has RIPv2 routes installed into its routing table. R3 also has a default route pointing to R2 s serial 0/1 which was learnt via RIPv2. You issue a few pings from R3 to different points of Connex network. All pings are successful. Since the configuration are correct so far, you suspect R1 has wrong routes to network 2. You move the console cable once more and connect it to R1. R1 speaks EIGRP to R2. You confirm EIGRP is configured correctly in R1, all R1 interfaces are up and R1 s routing table has all expected EIGRP routes. R1 also has a static default route pointing to R2 s serial 0/0. A few pings from R1 to different points of Connex network are successful but all pings to network 2 fail. R1 s configuration seems to be correct. You take a moment to analyze Connex network. Its structure keeps the RIPv2 section and the EIGRP section completely unaware of each other or formally speaking, no route redistribution is being performed. If a packet is to be sent from one section to another, default routes are used. Because of this, R1 uses its default route when it has packets to network 2. As mentioned before, R1 has a static default route. You connect the console cable to R2 and check its configuration. Because R2 is the junction point of both routing protocols (RIPV2 and EIGRP), R2 speaks both protocols at the same time.
Question 1: R2 speaks 2 routing protocols simultaneously. How many routing tables R2 keeps? Answer: Only 1 routing table. Despites the number of routing protocols running into a router, only one routing table is kept and only the best route is installed into the routing table. Many parameters are considered when selecting the best route. The most common are administrative distance, metric, and subnet mask length. EIGRP and RIPv2 were correctly configured into R2. All R2 s interfaces are up and it has RIPv2 and EIGRP routes installed into its routing table. R2 also have an interface connecting Connex Inc. to the outside world and Internet. R2 s default route uses this link to reach the world and any network outside Connex network address range. You decide to take a closer look at R2 s routing table. It is listed below: R2#sh ip route *Jan 31 21:37:04.091: %SYS-5-CONFIG_I: Configured from console by console Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 200.200.200.2 to network 0.0.0.0 C* 200.200.200.0/24 is directly connected, Loopback0 192.168.10.0/27 is subnetted, 3 subnets R 192.168.10.32 [120/1] via 192.168.10.2, 00:00:07, Serial0/0/1 C 192.168.10.0 is directly connected, Serial0/0/1 S 192.168.10.0/24 is directly connected, Null0 S 192.168.10.96 [1/0] via 192.168.20.2 192.168.20.0/27 is subnetted, 2 subnets D 192.168.20.32 [90/2297856] via 192.168.20.2, 00:50:41, Serial0/0/0 C 192.168.20.0 is directly connected, Serial0/0/0 S 192.168.20.0/24 is directly connected, Null0 R2# R2 s routing table shows a few interesting things: 1. It shows a direct connected route to 200.200.200.0/24. The * right after the C means it is a candidate to default-route. This route is being used as the link to outside and Internet. 2. It shows a RIPv2 route to 192.168.10.32/27 via 192.168.10.2. This route has metric 1 and administrative distance 120 which is the default administrative distance to RIP routes. 3. It shows a direct connected route to 192.168.10.0/27 representing R2 s serial interface 0/1 4. It shows a static route to 192.168.10.96/27 point to R1. This is the route used by R2 to reach network 2 but it points to R1 instead of R3. 5. An EIGRP route to 192.168.20.32/27 via 192.168.20.2 with administrative distance 90 (AD=90) which is the default AD to internal EIGRP routes. This route is used by R2 to reach network 1 and it is correct
Question 2: EIGRP routes have administrative distance 90 while RIPv2 routes have administrative distance 120. Why is this difference important? Answer: Different routing protocols calculate route metrics using different ways. Because of this, the administrative distance is necessary to let the router know which protocol is more accurate than the other, no matter the metric value. Because EIGRP has smaller AD than RIPv2, the router knows EIGRP routes are always better than RIPv2 routes, no matter the metric. After a look at R2 s routing table, you find the problem: R2 has a route to 192.168.10.96/27 (network 2) but it points to R1 when it should point to R3. Because R1 itself has no route to network 2, it forwards the packet according to its default route, this is R2. Since R2 s route to 192.168.10.96/27 points to R1, the packet is sent back to R1 creating a routing loop and keeping network 1 from reaching network 2. Caution is highly recommended when working with static routing. Question 3: If R4, R3 and R2 have their RIPv2 process correctly configured, why is R2 learning and installing a wrong route into its routing table? Answer: R2 is not learning this wrong route via RIPv2. R2 s routing table shows the wrong route is a static route which means it was manually configured. Since static routes have AD=1, by default, they override any routes learnt via any routing protocol. In this specific case, the static route (AD=1) overrides the route learned via RIPv2 (default AD=120). You connect to R2, remove the static route from its configuration and allow a few seconds to RIPv2 update the neighbors. You check R2 s routing table again and notice a correct route to network 2 is now installed. You issue a few pings to confirm and conclude the problem is solved. Question 4 (Challenge Question): There are 2 odd static routes installed into R2 s routing table: 192.168.10.0/24 and 192.168.20.0/24, both pointing to the null0 interface. a. Is there a Null0 interface on Cisco routers? b. Since those are static routes, it is correct to assume they were manually configured. Why such routes were manually installed into R2 s routing table? Answers: a. Not exactly. Null0 interface are logical interfaces which behave a lot like Loopback interfaces. They are generally used by IOS as an elegant way to discard packets. b. Because Connex Inc addressing scheme is not contiguous (there are subnets not assigned to links), it could happen an internal device tried to send a packet to an inexistent subnet range.
Since the address space used internally by Connex Inc is private (belongs to RFC 1918) and all Connex internal routers have default routes pointing to R2, such packet would eventually hit R2 requiring to be routed. But since the destination address belongs to an inexistent subnet range, R2 would not have a specific route to it and would wrongly forward it, via its default network, to the outside world. To avoid this situation, a route to the major classful network, pointing to Null0 is installed into the routing table. Cisco IOS s longest match rule guarantees the Null0 route will only be used when no other more specific route is found. Below is an example based on this case study: PC1 (under network 1) sends a packet to 192.168.20.130/27 which belongs to the inexistent network 192.168.20.128/27. R4 has no specific route to 192.168.20.128/27 simply because it does not exist and forward the packet to R3 based on its own default route. R3, by its turn, has no route to 192.168.20.128/27 either and forward the packet to R2 based on R3 s default route. Since 192.168.20.128/27 does not exist, R2 has no route to it as well and ends up forwarding the packet, based on its own default route, out to ISP in a try to find the destination of the packet. Because this is a RFC 1918 ip address, if the address is not within Connex network, it isn t anywhere else and forward it to ISP is unnecessary. To avoid this situation a route to the major classful network is manually installed into R2 s routing table. If R2 has no better route (longer mask than the major classful mask) the packet is discarded.