Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett
Yüklə 22,5 Mb. Pdf görüntüsü
|
- Bu səhifədəki naviqasiya:
- Verifying Your Configuration
- Administrative Distances
- TABLE 9.1
- Routing Protocols
- Advanced distance vector
- Routing Information Protocol (RIP)
|
SF The SF router is directly connected to networks 172.16.10.0/30 and 192.168.10.0/24, which means I’ve got to configure the following static routes on the SF router: 10.10.10.0/24 192.168.20.0/24 172.16.10.4/30 The configuration for the SF router is revealed in the following output. Remember that we’ll never create a static route to any network we’re directly connected to as well as the fact that we must use the next hop of 172.16.10.1 since that’s our only router connection. Let’s check out the commands: SF(config)#
SF(config)# ip route 172.16.10.4 255.255.255.252 172.16.10.1 150 SF(config)# ip route 192.168.20.0 255.255.255.0 172.16.10.1 150 SF(config)# do show run | begin ip route ip route 10.10.10.0 255.255.255.0 172.16.10.1 150 ip route 172.16.10.4 255.255.255.252 172.16.10.1 150 ip route 192.168.20.0 255.255.255.0 172.16.10.1 150 By looking at the routing table, you can see that the SF router now understands how to find each network: SF(config)#
C 192.168.10.0/24 is directly connected, FastEthernet0/0 L 192.168.10.1/32 is directly connected, FastEthernet0/0 172.16.0.0/30 is subnetted, 3 subnets S 172.16.10.4 [150/0] via 172.16.10.1 C 172.16.10.0 is directly connected, Serial0/0/0 L 172.16.10.2/32 is directly connected, Serial0/0 S 192.168.20.0/24 [150/0] via 172.16.10.1 10.0.0.0/24 is subnetted, 1 subnets S 10.10.10.0 [150/0] via 172.16.10.1 And we now can rest assured that the SF router has a complete routing table as well. As soon as the LA router has all the networks in its routing table, SF will be able to communicate with all remote networks!
The LA router is directly connected to 192.168.20.0/24 and 172.16.10.4/30, so these are the routes that must be added: 10.10.10.0/24 172.16.10.0/30 192.168.10.0/24 And here’s the LA router’s configuration: LA#
config t LA(config)# ip route 10.10.10.0 255.255.255.0 172.16.10.5 150 LA(config)# ip route 172.16.10.0 255.255.255.252 172.16.10.5 150 LA(config)# ip route 192.168.10.0 255.255.255.0 172.16.10.5 150 LA(config)# do show run | begin ip route ip route 10.10.10.0 255.255.255.0 172.16.10.5 150 ip route 172.16.10.0 255.255.255.252 172.16.10.5 150 ip route 192.168.10.0 255.255.255.0 172.16.10.5 150 This output displays the routing table on the LA router: LA(config)# do sho ip route S 192.168.10.0/24 [150/0] via 172.16.10.5 172.16.0.0/30 is subnetted, 3 subnets C 172.16.10.4 is directly connected, Serial0/0/1 L 172.16.10.6/32 is directly connected, Serial0/0/1 S 172.16.10.0 [150/0] via 172.16.10.5 C 192.168.20.0/24 is directly connected, FastEthernet0/0
L 192.168.20.1/32 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets S 10.10.10.0 [150/0] via 172.16.10.5 LA now shows all five networks in the internetwork, so it too can now communicate with all routers and networks. But before we test our little network, as well as our DHCP server, let’s cover one more topic. Default Routing The SF and LA routers that I’ve connected to the Corp router are considered stub routers. A stub indicates that the networks in this design have only one way out to reach all other networks, which means that instead of creating multiple static routes, we can just use a single default route. This default route is used by IP to forward any packet with a destination not found in the routing table, which is why it is also called a gateway of last resort. Here’s the configuration I could have done on the LA router instead of typing in the static routes due to its stub status: LA#
config t LA(config)# no ip route 10.10.10.0 255.255.255.0 172.16.10.5 150 LA(config)# no ip route 172.16.10.0 255.255.255.252 172.16.10.5 150 LA(config)# no ip route 192.168.10.0 255.255.255.0 172.16.10.5 150 LA(config)# ip route 0.0.0.0 0.0.0.0 172.16.10.5 LA(config)# do sho ip route [output cut] Gateway of last resort is 172.16.10.5 to network 0.0.0.0 172.16.0.0/30 is subnetted, 1 subnets C 172.16.10.4 is directly connected, Serial0/0/1 L 172.16.10.6/32 is directly connected, Serial0/0/1 C 192.168.20.0/24 is directly connected, FastEthernet0/0 L 192.168.20.0/32 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 172.16.10.5 Okay—I’ve removed all the initial static routes I had configured, and adding a default route is a lot easier than typing a bunch of static routes! Can you see the default route listed last in the routing table? The S* shows that as a candidate for the default route. And I really want you to notice that the gateway of last resort is now set too. Everything the router receives with a destination not found in the routing table will be forwarded to 172.16.10.5. You need to be careful where you place default routes because you can easily create a network loop! So we’re there—we’ve configured all our routing tables! All the routers
have the correct routing table, so all routers and hosts should be able to communicate without a hitch—for now. But if you add even one more network or another router to the internetwork, you’ll have to update each and every router’s routing tables by hand—ugh! Not really a problem at all if you’ve got a small network like we do, but it would be a time- consuming monster if you’re dealing with a large internetwork! Verifying Your Configuration But we’re not done yet—once all the routers’ routing tables are configured, they must be verified. The best way to do this, besides using the
show ip route command, is via Ping. I’ll start by pinging from the Corp router to the SF router. Here’s the output I got: Corp#
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Corp#
Here you can see that I pinged from the Corp router to the remote interface of the SF router. Now let’s ping the remote network on the LA router, and after that, we’ll test our DHCP server and see if that is working too! Corp#
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Corp#
And why not test my configuration of the DHCP server on the Corp router while we’re at it? I’m going to go to each host on the SF and LA routers and make them DHCP clients. By the way, I’m using an old router to represent “hosts,” which just happens to work great for studying purposes. Here’s how I did that:
SF_PC(config)# int e0 SF_PC(config-if)# ip address dhcp SF_PC(config-if)# no shut Interface Ethernet0 assigned DHCP address 192.168.10.8, mask 255.255.255.0 LA_PC(config)# int e0 LA_PC(config-if)# ip addr dhcp LA_PC(config-if)# no shut Interface Ethernet0 assigned DHCP address 192.168.20.4, mask 255.255.255.0 Nice! Don’t you love it when things just work the first time? Sadly, this just isn’t exactly a realistic expectation in the networking world, so we must be able to troubleshoot and verify our networks. Let’s verify our DHCP server with a few of the commands you learned back in Chapter 7: Corp#
sh ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type
Hardware address/ User name 192.168.10.8 0063.6973.636f.2d30. Sept 16 2013 10:34 AM Automatic 3035.302e.3062.6330. 2e30.3063.632d.4574. 30 192.168.20.4 0063.6973.636f.2d30. Sept 16 2013 10:46 AM Automatic 3030.322e.3137.3632. 2e64.3032.372d.4574. 30 We can see from earlier that our little DHCP server is working! Let’s try another couple of commands: Corp#
sh ip dhcp pool SF_LAN Pool SF_LAN : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 3 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 192.168.10.9 192.168.10.1 - 192.168.10.254 3
Corp# sh ip dhcp conflict IP address Detection method Detection time VRF The last command would tell us if we had two hosts with the same IP address, so it’s good news because there are no conflicts reported! Two detection methods are used to confirm this: A ping from the DHCP server to make sure no other host responds before handing out an address A gratuitous ARP from a host that receives a DHCP address from the server The DHCP client will send an ARP request with its new IP address looking to see if anyone responds, and if so, it will report the conflict to the server. Okay, since we can communicate from end to end and to each host without a problem while receiving DHCP addresses from our server, I’d say our static and default route configurations have been a success— cheers!
Dynamic Routing Dynamic routing is when protocols are used to find networks and update routing tables on routers. This is whole lot easier than using static or default routing, but it will cost you in terms of router CPU processing and bandwidth on network links. A routing protocol defines the set of rules used by a router when it communicates routing information between neighboring routers. The routing protocol I’m going to talk about in this chapter is Routing Information Protocol (RIP) versions 1 and 2. Two types of routing protocols are used in internetworks: interior gateway protocols (IGPs) and exterior gateway protocols (EGPs). IGPs are used to exchange routing information with routers in the same autonomous system (AS). An AS is either a single network or a collection of networks under a common administrative domain, which basically means that all routers sharing the same routing-table information are in the same AS. EGPs are used to communicate between ASs. An example of an EGP is Border Gateway Protocol (BGP), which we’re not going to bother with because it’s beyond the scope of this book. Since routing protocols are so essential to dynamic routing, I’m going to give you the basic information you need to know about them next. Later on in this chapter, we’ll focus on configuration.
There are some important things you should know about routing protocols before we get deeper into RIP routing. Being familiar with administrative distances and the three different kinds of routing protocols, for example. Let’s take a look.
The administrative distance (AD) is used to rate the trustworthiness of routing information received on a router from a neighbor router. An administrative distance is an integer from 0 to 255, where 0 is the most trusted and 255 means no traffic will be passed via this route. If a router receives two updates listing the same remote network, the first thing the router checks is the AD. If one of the advertised routes has a lower AD than the other, then the route with the lowest AD will be chosen and placed in the routing table. If both advertised routes to the same network have the same AD, then routing protocol metrics like hop count and/or the bandwidth of the lines will be used to find the best path to the remote network. The advertised route with the lowest metric will be placed in the routing table, but if both advertised routes have the same AD as well as the same metrics, then the routing protocol will load-balance to the remote network, meaning the protocol will send data down each link. Table 9.1 shows the default administrative distances that a Cisco router uses to decide which route to take to a remote network.
Default administrative distances Route Source Default AD Connected interface 0 Static route 1 External BGP 20 EIGRP
90 OSPF 110
RIP 120
External EIGRP 170
Internal BGP 200
Unknown 255 (This route will never be used.) If a network is directly connected, the router will always use the interface connected to the network. If you configure a static route, the router will then believe that route over any other ones it learns about. You can change the administrative distance of static routes, but by default, they have an AD of 1. In our previous static route configuration, the AD of each route is set at 150. This AD allows us to configure routing protocols without having to remove the static routes because it’s nice to have them there for backup in case the routing protocol experiences some kind of failure. If you have a static route, an RIP-advertised route, and an EIGRP- advertised route listing the same network, which route will the router go with? That’s right—by default, the router will always use the static route unless you change its AD—which we did!
There are three classes of routing protocols: Distance vector The distance-vector protocols in use today find the best path to a remote network by judging distance. In RIP routing, each instance where a packet goes through a router is called a hop, and the route with the least number of hops to the network will be chosen as the best one. The vector indicates the direction to the remote network. RIP is a distance-vector routing protocol and periodically sends out the entire routing table to directly connected neighbors.
protocols, the routers each create three separate tables. One of these tables keeps track of directly attached neighbors, one determines the topology of the entire internetwork, and one is used as the routing table. Link-state routers know more about the internetwork than any distance- vector routing protocol ever could. OSPF is an IP routing protocol that’s completely link-state. Link-state routing tables are not exchanged
periodically. Instead, triggered updates containing only specific link-state information are sent. Periodic keepalives that are small and efficient, in the form of hello messages, are exchanged between directly connected neighbors to establish and maintain neighbor relationships. Advanced distance vector Advanced distance-vector protocols use aspects of both distance-vector and link-state protocols, and EIGRP is a great example. EIGRP may act like a link-state routing protocol because it uses a Hello protocol to discover neighbors and form neighbor relationships and because only partial updates are sent when a change occurs. However, EIGRP is still based on the key distance-vector routing protocol principle that information about the rest of the network is learned from directly connected neighbors. There’s no set of rules to follow that dictate exactly how to broadly configure routing protocols for every situation. It’s a task that really must be undertaken on a case-by-case basis, with an eye on specific requirements of each one. If you understand how the different routing protocols work, you can make good, solid decisions that will solidly meet the individual needs of any business! Routing Information Protocol (RIP) Routing Information Protocol (RIP) is a true distance-vector routing protocol. RIP sends the complete routing table out of all active interfaces every 30 seconds. It relies on hop count to determine the best way to a remote network, but it has a maximum allowable hop count of 15 by default, so a destination of 16 would be considered unreachable. RIP works okay in very small networks, but it’s super inefficient on large networks with slow WAN links or on networks with a large number of routers installed and completely useless on networks that have links with variable bandwidths! RIP version 1 uses only classful routing, which means that all devices in the network must use the same subnet mask. This is because RIP version 1 doesn’t send updates with subnet mask information in tow. RIP version 2 provides something called prefix routing and does send subnet mask information with its route updates. This is called classless routing. So, with that let’s configure our current network with RIPv2, before we move onto the next chapter.
Configuring RIP Routing To configure RIP routing, just turn on the protocol with the router rip command and tell the RIP routing protocol the networks to advertise. Remember that with static routing, we always configured remote networks and never typed a route to our directly connected networks? Well, dynamic routing is carried out the complete opposite way. You would never type a remote network under your routing protocol—only enter your directly connected networks! Let’s configure our three-router internetwork, revisited in Figure 9.9 , with RIP routing. Corp RIP has an administrative distance of 120. Static routes have an administrative distance of 1 by default, and since we currently have static routes configured, the routing tables won’t be populated with RIP information by default. We’re still good though because I added the 150 to the end of each static route! You can add the RIP routing protocol by using the router rip command and the
network command. The network command tells the routing protocol which classful network to advertise. By doing this, you’re activating the RIP routing process on the interfaces whose addressing falls within the specified classful networks configured with the network
command under the RIP routing process. Look at the Corp router configuration to see how easy this is. Oh wait— first, I want to verify my directly connected networks so I know what to configure RIP with: Corp#
Interface IP-Address OK? Method Status Protocol FastEthernet0/0 10.10.10.1 YES manual up up Serial0/0 172.16.10.1 YES manual up up FastEthernet0/1 unassigned YES unset administratively down down Serial0/1 172.16.10.5 YES manual up up Corp#
config t Corp(config)# router rip Corp(config-router)# network 10.0.0.0 Corp(config-router)# network 172.16.0.0 Corp(config-router)# version 2 Corp(config-router)# no auto-summary That’s it—really! Typically just two or three commands and you’re done, which sure makes your job a lot easier than dealing with static routes, doesn’t it? Be sure to keep in mind the extra router CPU process and bandwidth that you’re consuming. Anyway, so what exactly did I do here? I enabled the RIP routing protocol, added my directly connected networks, made sure I was only running RIPv2, which is a classless routing protocol, and then I disabled auto-summary. We typically don’t want our routing protocols summarizing for us because it’s better to do that manually and both RIP and EIGRP (before 15.x code) auto-summarize by default. So a general rule of thumb is to disable auto-summary, which allows them to advertise subnets. Notice I didn’t type in subnets, only the classful network address, which is betrayed by the fact that all subnet bits and host bits are off! That’s because with dynamic routing, it’s not my job and it’s up to the routing protocol to find the subnets and populate the routing tables. And since we have no router buddies running RIP, we won’t see any RIP routes in the routing table yet. Remember that RIP uses the classful address when configuring the network address. To clarify this, refer to the example in our network with an address of 172.16.0.0/24 using subnets 172.16.10.0 and 172.16.20.0. You would only type in the classful network address of 172.16.0.0 and let RIP find the subnets and place them in the routing table. This doesn’t mean you are running a classful routing protocol; this is just the way that both RIP and EIGRP are configured.
Let’s configure our SF router now, which is connected to two networks. We need to configure both directly connected classful networks, not subnets:
|