0
Ch. 7 – Distance Vector Routing Protocols Part 1 of 2: Distance Vector Routing and RIP Rick Graziani Cabrillo College
Overview <ul><li>Describe how routing loops can occur in distance vector routing   </li></ul><ul><li>Describe several meth...
Distance Vector Routing Updates <ul><li>Routing table updates occur periodically or when the topology in a distance vector...
Distance Vector Routing Metrics <ul><li>RIP  – Hop Count </li></ul><ul><li>IGRP and EIGRP  – Bandwidth, Delay, Reliability...
Triggered Updates <ul><li>Triggered updates are sent whenever a router sees a topology change or a change in routing infor...
Triggered Updates <ul><li>Most distance-vector routing protocols limit the frequency of triggered updates so that a flappi...
Routing Loop Issues <ul><li>Distance vector routing protocols are simple in their implementation and configuration, but th...
Routing Loop Issues <ul><li>What can cause routing loops? </li></ul><ul><li>Routing loops can occur when there are: </li><...
Routing Loop Issues <ul><li>Routing Loop Example </li></ul><ul><li>Assume for the remainder of this example that  Router C...
Routing Loop Issues <ul><li>Network 1 Fails </li></ul><ul><li>Router E sends an update to Router A.  </li></ul><ul><li>Rou...
Routing Loop Issues <ul><li>Router C sends a periodic update to Router D </li></ul><ul><li>Router C sends a periodic updat...
Routing Loop Issues <ul><li>Routers A changes its routing table </li></ul><ul><li>Router A adds new route to its routing t...
Routing Loop Issues <ul><li>Router C changes its routing table </li></ul><ul><li>Router C   still believes  it can get to ...
Defining a Maximum <ul><li>Problem :  Count to infinity </li></ul><ul><li>Solution :  Defining a Maximum </li></ul><ul><li...
Split Horizon <ul><li>A route pointing back to the router from which packets were received is called a  reverse route . </...
<ul><li>Split Horizon Rule – Avoiding Routing Loops </li></ul><ul><li>Routers RTA and RTB have their initial routing table...
<ul><li>Split Horizon Disabled </li></ul><ul><li>After the initial exchange of updates everything in the routing tables lo...
<ul><li>Split Horizon Disabled </li></ul><ul><li>After the next exchange of updates everything in the routing tables look ...
<ul><li>Split Horizon Disabled – 10.1.3.0/24 down </li></ul><ul><li>Routing tables are not sent at the exactly same time. ...
<ul><li>Split Horizon Disabled – 10.1.3.0/24 down </li></ul><ul><li>RTB notices that it has a route to 10.1.3.0/24 via RTA...
Previous routing tables New routing tables Split Horizon Enabled
<ul><li>Split Horizon  Enabled </li></ul><ul><li>As you can see, with split horizon enabled, RTA does not send RTB ( out s...
<ul><li>Split Horizon  Enabled  – 10.1.3.0/24 down </li></ul><ul><li>RTB notices 10.1.3.0/24 is down and puts this route i...
<ul><li>Split Horizon  Enabled  – 10.1.3.0/24 down </li></ul><ul><li>Notice that RTA never sends RTB a routing update for ...
<ul><li>Split Horizon with Poison Reverse </li></ul><ul><li>Many vendor implementations of distance vector routing protoco...
<ul><li>Split Horizon Enabled by Default </li></ul><ul><li>Split horizon with poison reverse is  enabled by default  for a...
Route poisoning <ul><li>When route poisoning is used with triggered updates it will speed up convergence time because neig...
Preventing routing loops with holddown timers <ul><li>The main function of  holddown timers  is to prevent the distance ve...
Preventing routing loops with holddown timers <ul><li>Curriculum </li></ul><ul><li>A count to infinity problem can be avoi...
Preventing routing loops with holddown timers <ul><li>Same Route from same neighbor:  Network is back up (Correct News) </...
Preventing routing loops with holddown timers <ul><li>Better Route from different neighbor (Correct News) </li></ul><ul><l...
Preventing routing loops with holddown timers <ul><li>Poorer Route from a different neighbor. (Incorrect News) </li></ul><...
Avoiding routing loops with triggered updates <ul><li>Triggered update is sent immediately in response to some change in t...
<ul><li>Let’s look at a related item in IP, the TTL field.  Taken from information added to Ch. 9 TCP/IP. </li></ul>IP’s T...
<ul><li>When a packet is first generated a value is entered into the TTL field. </li></ul><ul><li>Originally, the TTL fiel...
<ul><li>If the router decrements the TTL field to 0, it will then drop the packet (unless the packet is destined specifica...
<ul><li>The idea behind the TTL field is that IP packets can not travel around the Internet forever, from router to router...
RIP routing process <ul><li>Request for Comments (RFC) 1058  </li></ul><ul><li>RIP has evolved over the years from a Class...
Configuring RIP
Configuring RIP <ul><li>RIP and IGRP:  </li></ul><ul><li>Classful network statements only </li></ul><ul><li>IOS will take ...
Configuring RIP <ul><li>Rick’s Clarifications  (This is for IGPs only and not EGPs such as BGP): </li></ul><ul><li>The net...
Triggered Extensions <ul><li>Triggered Extensions to RIP </li></ul><ul><li>http://www.cisco.com/en/US/products/sw/iosswrel...
Triggered Extensions <ul><li>RFC 2091, Triggered Extensions to RIP to Support Demand Circuits. </li></ul><ul><li>When trig...
<ul><li>RIP Message </li></ul><ul><li>Data Link Frame </li></ul><ul><li>         MAC Source Address </li></ul><ul><li>  ...
<ul><li>Command :  1 signifying a Request or 2 signifying a Reply </li></ul><ul><li>Version : 1 for RIP v 1 or 2 for RIP v...
RIP v2 message format <ul><li>All the extensions to the original protocol are carried in the unused fields.  </li></ul><ul...
RIP v2 message format <ul><li>The  Route Tag  field provides a way to differentiate between internal and external routes. ...
Configuring RIP <ul><li>RIP must be enabled and the networks specified. The remaining tasks are optional. Among these opti...
ip classless  command <ul><li>IP classless only affects the operation of the forwarding processes in IOS. IP classless doe...
Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><u...
Lookup what? <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R  17...
Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><u...
Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0 /24  is subnetted, 3 subnets </li></ul>...
Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><u...
Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><u...
Classful Routing Behavior <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul>...
Classless Routing Behavior <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul...
Common RIP Configuration Issues <ul><li>Split Horizon </li></ul><ul><li>The following command is used to disable  split ho...
Common RIP Configuration Issues <ul><li>Holddown Timer </li></ul><ul><li>The ideal setting would be to set the timer just ...
Common RIP Configuration Issues <ul><li>Update Timer </li></ul><ul><li>The default RIP update interval in Cisco IOS is 30 ...
Common RIP Configuration Issues <ul><li>For RIP and IGRP, the  passive interface  command stops the router from sending up...
Common RIP Configuration Issues <ul><li>Because RIP is a broadcast protocol, the network administrator may have to configu...
Common RIP Configuration Issues <ul><li>By default, the Cisco IOS software receives RIP Version 1 and Version 2 packets, b...
Compatibility with RIP v1 <ul><li>NewYork </li></ul><ul><li>interface fastethernet0/0 </li></ul><ul><li>ip address 192.168...
Verifying RIP configuration
Verifying RIP configuration <ul><li>Also:  show running-config </li></ul>
Troubleshooting RIP update issues
Troubleshooting RIP update issues <ul><li>Other commands to troubleshoot RIP: </li></ul><ul><li>show ip rip database   </l...
Load balancing with RIP <ul><li>RIP is capable of load balancing over as many as six equal-cost paths, with four paths bei...
Fast Switching and Process Switching <ul><li>The following information is taken from Routing TCP/IP Volume I by Jeff Doyle...
Fast Switching  – Per Destination Load Balancing <ul><li>The default for most interfaces is Fast Switching. </li></ul><ul>...
Fast Switching  – Per Destination Load Balancing <ul><li>Fast Switching </li></ul><ul><li>Router switches first packet to ...
Process Switching  – Per Packet Load Balancing <ul><li>Process Switching </li></ul><ul><li>Given equal cost paths, per pac...
Which one?  <ul><li>Fast Switching or Process Switching </li></ul><ul><li>Process switching (per packet load balancing) ha...
Using debug ip packet with Fast Switching and Process Switching  <ul><li>debug ip packet  can be used to observe packets s...
Load balancing across multiple paths <ul><li>Note: The example used in this section of the online curriculum is really for...
RIP and Administrative Distance
RIP and Floating Static Routes <ul><li>Floating static routes are static routes which are used as backup routes. </li></ul...
RIPv1 Labs – 3 Scenarios (Optional) <ul><li>Read the following lab. </li></ul><ul><li>Review the configurations and the ou...
<ul><li>Objective </li></ul><ul><li>  In this lab, you will configure RIP routing in three different scenarios.  </li></ul...
<ul><li>Setup </li></ul><ul><li>Use the 8 Steps to Success to help you configure the routers. </li></ul><ul><li>Be sure yo...
<ul><li>Optional:  Keeping outputs from interrupting our inputs </li></ul><ul><li>  </li></ul><ul><li>Before we begin to c...
<ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.1...
<ul><li>Objective:  Running RIPv1 on classful networks </li></ul><ul><li>  </li></ul><ul><li>This scenario is the same one...
<ul><li>Here are the commands for each router: </li></ul><ul><li>  </li></ul><ul><li>SanJose2# configure terminal </li></u...
<ul><li>Step 2 – Understanding the network command </li></ul><ul><li>  </li></ul><ul><li>SENDING RIP MESSAGES  </li></ul><...
<ul><li>LISTENING FOR RIP MESSAGES </li></ul><ul><li>Routers will also listen for RIP messages on each interface belonging...
<ul><li>Step 3 – Viewing the debug ip rip output and the routing tables </li></ul><ul><li>  </li></ul><ul><li>Remember tha...
<ul><li>SanJose2   </li></ul><ul><li>01:30:45: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) </li>...
<ul><li>SanJose1   </li></ul><ul><li>01:33:05: RIP: received v1 update from 192.168.4.1 on Serial1 </li></ul><ul><li>01:33...
<ul><li>Baypointe   </li></ul><ul><li>01:34:53: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.5.1) </li...
<ul><li>NOTE:  At this point all routers should be able to ping all networks.  We will discuss RIP much more in the chapte...
<ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.3...
<ul><li>Objective:  Running RIPv1 on subnets and between classful networks </li></ul><ul><li>  </li></ul><ul><li>In this s...
<ul><li>Step 1 – Configuring RIP </li></ul><ul><li>  </li></ul><ul><li>Once again, lets enable RIP on each router.  </li><...
<ul><li>Here are the commands for each router: </li></ul><ul><li>  </li></ul><ul><li>SanJose2# configure terminal </li></u...
<ul><li>Question:  What would happen if you entered a network statement that was a subnet?  For example: </li></ul><ul><li...
<ul><li>Step 2 – Viewing the debug ip rip output and the routing tables   </li></ul><ul><li>SanJose2   </li></ul><ul><li>S...
<ul><li>Reflections </li></ul><ul><li>IMPORTANT INFORMATION :  RIPv1 is a  classful routing protocol .  Classful routing p...
<ul><li>SanJose1   </li></ul><ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><...
<ul><li>Reflections </li></ul><ul><li>The same subnet route information applies with routes sent from SanJose2 to SanJose1...
<ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>SanJose1# </li></ul><ul><l...
<ul><li>More Reflections </li></ul><ul><li>IMPORTANT INFORMATION :  Notice the RIP update being sent out Serial 1: </li></...
<ul><li>More Reflections (continued) </li></ul><ul><li>How is this an advantage?   Fewer updates sent and received, result...
<ul><li>Baypointe   </li></ul><ul><li>Baypointe# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul...
<ul><li>Reflections </li></ul><ul><li>Notice that Baypointe is only receiving the classful summary of the 172.30.0.0 subne...
<ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.3...
<ul><li>Objective:  Running RIPv1 on a stub network </li></ul><ul><li>  </li></ul><ul><li>In this scenario we will modify ...
<ul><li>Making changes between Scenario 2 and Scenario 3 </li></ul><ul><li>  </li></ul><ul><li>Be sure to change the IP ad...
<ul><li>Step 1 – Configuring RIP on SanJose1 and SanJose2 </li></ul><ul><li>  </li></ul><ul><li>Here are the commands for ...
<ul><li>Step 2 - Configuring the default static route on SanJose1 </li></ul><ul><li>  </li></ul><ul><li>On SanJose1, let’s...
<ul><li>Step 3 - Configuring the static route on Baypointe for the 172.30.0.0/16 network </li></ul><ul><li>  </li></ul><ul...
<ul><li>SanJose1 </li></ul><ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li...
<ul><li>Reflections </li></ul><ul><li>Notice that the static default route is being propagated by SanJose1 to other router...
<ul><li>SanJose2 </li></ul><ul><li>  SanJose2# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><...
<ul><li>Reflections </li></ul><ul><li>Notice that SanJose2 is receiving the default route from SanJose1. </li></ul><ul><li...
<ul><li>Baypointe </li></ul><ul><li>   </li></ul><ul><li>No RIP messages, as we are not running RIP. </li></ul><ul><li>  <...
<ul><li>show ip protocols command </li></ul><ul><li>   </li></ul><ul><li>SanJose2 router from Scenario 3. </li></ul><ul><l...
<ul><li>A Few Final Notes </li></ul><ul><li>  </li></ul><ul><li>  RIP uses broadcasts </li></ul><ul><li>Notice that RIPv1 ...
<ul><li>What is with the /30 network? </li></ul><ul><li>/30 or 255.255.255.252 subnet masks are quite common on serial lin...
<ul><li>How can I remove a single network from RIP? </li></ul><ul><li>  </li></ul><ul><li>Instead of using the following c...
End of Part I <ul><li>End of Part I </li></ul><ul><li>See Part II for IGRP </li></ul>
Upcoming SlideShare
Loading in...5
×

Distance Vector Routing - RIP

2,771

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,771
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
187
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Distance Vector Routing - RIP"

  1. 1. Ch. 7 – Distance Vector Routing Protocols Part 1 of 2: Distance Vector Routing and RIP Rick Graziani Cabrillo College
  2. 2. Overview <ul><li>Describe how routing loops can occur in distance vector routing </li></ul><ul><li>Describe several methods used by distance vector routing protocols to ensure that routing information is accurate </li></ul><ul><li>Configure RIP </li></ul><ul><li>Use the ip classless command </li></ul><ul><li>Troubleshoot RIP </li></ul><ul><li>Configure RIP for load balancing </li></ul><ul><li>Configure static routes for RIP </li></ul><ul><li>Verify RIP </li></ul>
  3. 3. Distance Vector Routing Updates <ul><li>Routing table updates occur periodically or when the topology in a distance vector protocol network changes. </li></ul><ul><li>Topology change updates proceed systematically from router to router. </li></ul><ul><li>Distance vector algorithms call for each router to send its entire routing table to each of its adjacent neighbors. </li></ul><ul><li>The routing tables include information about the total path cost. This path cost is defined by the metric. </li></ul>
  4. 4. Distance Vector Routing Metrics <ul><li>RIP – Hop Count </li></ul><ul><li>IGRP and EIGRP – Bandwidth, Delay, Reliability, Load </li></ul><ul><li>Cisco’s OSPF – Bandwidth </li></ul><ul><li>IS-IS – Cost </li></ul><ul><li>BGP – Number of AS or policy </li></ul>No! MTU is never used as a routing metric. Some documentation is incorrect on this item.
  5. 5. Triggered Updates <ul><li>Triggered updates are sent whenever a router sees a topology change or a change in routing information (from another router). </li></ul><ul><li>The router does not have to wait for the period timer, but can send them immediately. </li></ul><ul><li>Triggered updates do not need to include the entire routing table but only the modified route(s). </li></ul><ul><li>Triggered updates must still be sent to adjacent routers, from router to router, like other routing updates. </li></ul>
  6. 6. Triggered Updates <ul><li>Most distance-vector routing protocols limit the frequency of triggered updates so that a flapping link does not put an unnecessary load on the network. </li></ul><ul><li>Typically, triggered updates can be “triggered” by: </li></ul><ul><ul><li>Interface transition to the up or down state </li></ul></ul><ul><ul><li>A route has entered or exited an unreachable (down) state </li></ul></ul><ul><ul><li>A new route is installed in the routing table </li></ul></ul>
  7. 7. Routing Loop Issues <ul><li>Distance vector routing protocols are simple in their implementation and configuration, but this comes at a price. Pure distance vector routing protocols suffer from possible routing loops. </li></ul><ul><li>Routing loops can cause major network problems, from packets getting lost (blackholed) in your network, to bringing down your entire network. </li></ul><ul><li>Several remedies have been added to distance-vector algorithms to help prevent routing loops including: </li></ul><ul><ul><li>Split horizon </li></ul></ul><ul><ul><li>Hold-down timers </li></ul></ul><ul><ul><li>Defining a maximum metric </li></ul></ul>
  8. 8. Routing Loop Issues <ul><li>What can cause routing loops? </li></ul><ul><li>Routing loops can occur when there are: </li></ul><ul><ul><li>Incorrect or inconsistent routing updates due to slow convergence after a topology change. </li></ul></ul><ul><ul><li>Incorrect or incomplete routing information </li></ul></ul><ul><ul><li>Static routes incorrectly configured with an intermediate address which does not become resolved in the routing table. </li></ul></ul>
  9. 9. Routing Loop Issues <ul><li>Routing Loop Example </li></ul><ul><li>Assume for the remainder of this example that Router C’s preferred path to network 1 is by way of Router B . </li></ul><ul><li>Router C’s routing table has a distance of 3 to network 1 via Router B. </li></ul>
  10. 10. Routing Loop Issues <ul><li>Network 1 Fails </li></ul><ul><li>Router E sends an update to Router A. </li></ul><ul><li>Router A stops routing packets to network 1. </li></ul><ul><li>But Routers B, C, and D continue to do so because they have not yet been informed about the failure. </li></ul><ul><li>Router A sends out its update. </li></ul><ul><li>Routers B and D stop routing to network1, (via Router A). </li></ul><ul><li>However, Router C is still not updated. </li></ul><ul><li>To router C, network 1 is still reachable via router B. </li></ul>
  11. 11. Routing Loop Issues <ul><li>Router C sends a periodic update to Router D </li></ul><ul><li>Router C sends a periodic update to Router D indicating a path to network 1 (by way) of via Router B. (4 hops). </li></ul><ul><li>Router D’s Routing Table information for Network 1 </li></ul><ul><li>Current path to Network 1 = Unreachable (down) </li></ul><ul><li>Information from Router C: Network 1 : 4 hops by way of Router C </li></ul><ul><li>Normally, Router D ignores this routing information because it usually has a better route, 2 hops, via Router A, but this route is now down. </li></ul><ul><li>Router D changes its routing table to reflect this (good) better , but incorrect information , Network 1 by way of Router C (4 hops) </li></ul><ul><li>Router D propagates the information to Router A. </li></ul>
  12. 12. Routing Loop Issues <ul><li>Routers A changes its routing table </li></ul><ul><li>Router A adds new route to its routing table, get to Network 1 by way of Router D (5 hops). </li></ul><ul><li>Propagates the information to Routers B and E. </li></ul><ul><li>Router B (and Router E) change their routing tables </li></ul><ul><li>Router B now believes it can get to Network 1 by way of Router A (6 hops). </li></ul><ul><li>Wow! I was about to tell Router C that Network 1 was down via Router B, but now I have new information! </li></ul><ul><li>Propagates the incorrect information to Router C. </li></ul>
  13. 13. Routing Loop Issues <ul><li>Router C changes its routing table </li></ul><ul><li>Router C still believes it can get to Network 1 by way of Router B (7 hops). </li></ul><ul><li>Of course now it believes it is 7 hops instead of 3. </li></ul><ul><li>Propagates the newer but still incorrect information to Router D. </li></ul><ul><li>Here we go again! </li></ul><ul><li>Data packets destined for Network 1 get caught in a routing loop, from Routers A to D to C to B to A to D etc. </li></ul><ul><li>As routing updates continue between the routers, the hop count gets greater – to infinity? (Not quite – we will see in a moment.) </li></ul>
  14. 14. Defining a Maximum <ul><li>Problem : Count to infinity </li></ul><ul><li>Solution : Defining a Maximum </li></ul><ul><li>Distance vector routing algorithms are self-correcting, but a routing loop problem can require a count to infinity. </li></ul><ul><li>To avoid this prolonged problem, distance vector protocols define infinity as a specific maximum number. </li></ul><ul><li>This number refers to a routing metric which may simply be the hop count. </li></ul><ul><li>When the metric value exceeds the maximum value, and as each router receives this maximum metric, the network is then considered unreachable . </li></ul>
  15. 15. Split Horizon <ul><li>A route pointing back to the router from which packets were received is called a reverse route . </li></ul><ul><li>Split horizon is a technique for preventing reverse routes between two routers. </li></ul><ul><li>The Split Horizon Rule: when sending updates out a particular interface, do not include networks that were learned from updates received on that interface. </li></ul>
  16. 16. <ul><li>Split Horizon Rule – Avoiding Routing Loops </li></ul><ul><li>Routers RTA and RTB have their initial routing tables and are ready to exchange routing information via a distance-vector routing protocol like RIP. </li></ul><ul><li>Split Horizon disabled </li></ul><ul><li>If split horizon were disabled the routing updates would include all of the networks in their routing tables including their directly connected networks and any networks learned from any interface. </li></ul>Simple Split Horizon Initial routing tables
  17. 17. <ul><li>Split Horizon Disabled </li></ul><ul><li>After the initial exchange of updates everything in the routing tables look fine. </li></ul><ul><li>Because split horizon is disabled, the 10.1.2.0/24 network is sent by both routers, but neither router includes the other’s route to 10.1.2.0/24 (1 hop) in the routing table, because it has a current route with a better metric of 0. </li></ul>Initial routing tables New routing tables 10.1.2.0/24 network is included because split horizon has been disabled
  18. 18. <ul><li>Split Horizon Disabled </li></ul><ul><li>After the next exchange of updates everything in the routing tables look fine and the routing tables are converged. </li></ul><ul><li>Because split horizon is disabled, besides the 10.1.2.0/24 network, the networks learned from the other router in the previous update is also sent by both routers. </li></ul><ul><li>However, neither router includes those networks, because it has a current route with a better metric of 0. </li></ul>Previous routing tables Networks in red were included because split horizon has been disabled New routing tables
  19. 19. <ul><li>Split Horizon Disabled – 10.1.3.0/24 down </li></ul><ul><li>Routing tables are not sent at the exactly same time. This is done on purpose to avoid collisions on broadcast networks like Ethernet. </li></ul><ul><li>Here, the 10.1.3.0/24 network fails, and before RTB sends out its routing update, RTB receives a routing update from RTA. </li></ul>Previous routing tables Networks in red were included because split horizon has been disabled New routing tables
  20. 20. <ul><li>Split Horizon Disabled – 10.1.3.0/24 down </li></ul><ul><li>RTB notices that it has a route to 10.1.3.0/24 via RTA. Even though it is 2 hops it is certainly better than its current situation of “unreachable” so it accepts this better, but incorrect information from RTA. </li></ul><ul><li>RTB now forwards all packets destined for 10.1.3.0/24 to RTA at 10.1.2.1. </li></ul><ul><li>RTA receives these packets and forwards them to RTB at 10.1.2.2. </li></ul><ul><li>RTB forwards them back to RTA at 10.1.2.1. </li></ul><ul><li>And so on! The packets get blackholed in this routing loop. </li></ul>Previous routing tables Networks in red were included because split horizon has been disabled New routing tables
  21. 21. Previous routing tables New routing tables Split Horizon Enabled
  22. 22. <ul><li>Split Horizon Enabled </li></ul><ul><li>As you can see, with split horizon enabled, RTA does not send RTB ( out s0 ) information about 10.1.3.0/24 because it learned it from RTB ( same s0 ), and RTB does not send RTA ( out s0 ) information about 10.1.1.0/24 to RTA because it learned it from RTA ( same s0 ). (This also includes the common network between them. </li></ul>Previous routing tables New routing tables
  23. 23. <ul><li>Split Horizon Enabled – 10.1.3.0/24 down </li></ul><ul><li>RTB notices 10.1.3.0/24 is down and puts this route into hold-down state in its routing table. (hold-down coming next) </li></ul><ul><li>RTB immediately sends out a triggered update for only this route (if there were others in the routing table) with a metric of infinity, 16. </li></ul><ul><li>RTA receives the triggered update and puts the route for 10.1.3.0/24 into hold-down state. </li></ul>Previous routing tables New routing tables
  24. 24. <ul><li>Split Horizon Enabled – 10.1.3.0/24 down </li></ul><ul><li>Notice that RTA never sends RTB a routing update for 10.1.3.0/24, because split horizon is enabled on these interfaces. </li></ul>Previous routing tables New routing tables
  25. 25. <ul><li>Split Horizon with Poison Reverse </li></ul><ul><li>Many vendor implementations of distance vector routing protocols like Cisco’s RIP and IGRP apply a special kind of split horizon, called split horizon with poison reverse . </li></ul><ul><li>“ Split horizon with poison reverse means that, instead of not advertising routes to the source, routes are advertised back to the source with a metric of 16, which will make the source router ignore the route. It is perceived that explicitly telling a router to ignore a route is better than not telling it about the route in the first place.” (Lewis, Cisco TCP/IP Routing) </li></ul><ul><li>One drawback is that routing update packet sizes will be increased when using Poison Reverse, since they now include these routes. </li></ul>Split Horizon with Poison Reverse “ Poisoned” routes in red. Routing tables remain the same.
  26. 26. <ul><li>Split Horizon Enabled by Default </li></ul><ul><li>Split horizon with poison reverse is enabled by default for all interfaces except : </li></ul><ul><li>Physical interfaces or multipoint sub-interfaces using Frame Relay or SMDS encapsulation (CCNA Semester 4 and CCNP) </li></ul><ul><li>To disable split horizon on an interface: </li></ul><ul><li>Router(config-if)# no ip split-horizon </li></ul><ul><li>To enable split horizon on an interface: </li></ul><ul><li>Router(config-if)# ip split-horizon </li></ul>“ Poisoned” routes in red. Split Horizon with Poison Reverse
  27. 27. Route poisoning <ul><li>When route poisoning is used with triggered updates it will speed up convergence time because neighboring routers do not have to wait 30 seconds before advertising the poisoned route. </li></ul>
  28. 28. Preventing routing loops with holddown timers <ul><li>The main function of holddown timers is to prevent the distance vector routing protocol from establishing routing loops during periods of network transition (topology changes). </li></ul><ul><li>“ The rule: Once a route is marked unreachable , it must stay in this state for a period of time assumed sufficient for all routers to receive new information about the unreachable network. In essence, we instruct the routers to let the rumors calm down and then to pick up the truth.” (Zinin, Cisco IP Routing) </li></ul><ul><li>The amount of time a router remains in “this state” is determined by the holddown timer . </li></ul>
  29. 29. Preventing routing loops with holddown timers <ul><li>Curriculum </li></ul><ul><li>A count to infinity problem can be avoided by using holddown timers. </li></ul><ul><li>When a router receives an update from a neighbor indicating that a previously accessible network is now inaccessible, the router marks the route as inaccessible and starts a hold-down timer. </li></ul>
  30. 30. Preventing routing loops with holddown timers <ul><li>Same Route from same neighbor: Network is back up (Correct News) </li></ul><ul><li>If at any time before the hold-down timer expires an update is received from the same neighbor indicating that the network is again accessible, the router marks the network as accessible and removes the hold-down timer. </li></ul>
  31. 31. Preventing routing loops with holddown timers <ul><li>Better Route from different neighbor (Correct News) </li></ul><ul><li>If at any time before the hold-down timer expires an update arrives from a different neighboring router with a better metric than originally recorded for the network, the router marks the network as accessible and removes the hold-down timer. </li></ul>
  32. 32. Preventing routing loops with holddown timers <ul><li>Poorer Route from a different neighbor. (Incorrect News) </li></ul><ul><li>If at any time before the hold-down timer expires an update arrives from a different neighboring router with a poorer metric than originally recorded for the network the update is ignored and the hold-down timer continues. </li></ul><ul><li>Ignoring an update with a poorer metric when a hold-down is in effect allows more time for the knowledge of a disruptive change to propagate through the entire network. </li></ul>
  33. 33. Avoiding routing loops with triggered updates <ul><li>Triggered update is sent immediately in response to some change in the routing table. </li></ul><ul><li>The router that detects a topology change immediately sends an update message to adjacent routers that, in turn, generate triggered updates notifying their adjacent neighbors of the change. </li></ul><ul><li>When a route fails, an update is sent immediately rather than waiting on the update timer to expire. </li></ul><ul><li>Triggered updates, used in conjunction with route poisoning, ensure that all routers know of failed routes before any holddown timers can expire. </li></ul>
  34. 34. <ul><li>Let’s look at a related item in IP, the TTL field. Taken from information added to Ch. 9 TCP/IP. </li></ul>IP’s TTL – Time To Live field
  35. 35. <ul><li>When a packet is first generated a value is entered into the TTL field. </li></ul><ul><li>Originally, the TTL field was the number of seconds, but this was difficult to implement and rarely supported. </li></ul><ul><li>Now, the TTL is now set to a specific value which is then decremented by each router. </li></ul>IP’s TTL – Time To Live field
  36. 36. <ul><li>If the router decrements the TTL field to 0, it will then drop the packet (unless the packet is destined specifically for the router, I.e. ping, telnet, etc.). </li></ul><ul><li>Common operating system TTL values are: </li></ul><ul><ul><li>UNIX: 255 </li></ul></ul><ul><ul><li>Linux: 64 or 255 depending upon vendor and version </li></ul></ul><ul><ul><li>Microsoft Windows 95: 32 </li></ul></ul><ul><ul><li>Other Microsoft Windows operating systems: 128 </li></ul></ul>Decrement by 1, if 0 drop the packet. IP’s TTL – Time To Live field
  37. 37. <ul><li>The idea behind the TTL field is that IP packets can not travel around the Internet forever, from router to router. </li></ul><ul><li>Eventually, the packet’s TTL which reach 0 and be dropped by the router, even if there is a routing loop somewhere in the network. </li></ul>Decrement by 1, if 0 drop the packet. IP’s TTL – Time To Live field
  38. 38. RIP routing process <ul><li>Request for Comments (RFC) 1058 </li></ul><ul><li>RIP has evolved over the years from a Classful Routing Protocol, RIP Version 1 (RIP v1), to a Classless Routing Protocol, RIP Version 2 (RIP v2). RIP v2 enhancements include: </li></ul><ul><ul><li>Ability to carry additional packet routing information. </li></ul></ul><ul><ul><li>Authentication mechanism to secure table updates. </li></ul></ul><ul><ul><li>Supports variable length subnet masking (VLSM). </li></ul></ul>
  39. 39. Configuring RIP
  40. 40. Configuring RIP <ul><li>RIP and IGRP: </li></ul><ul><li>Classful network statements only </li></ul><ul><li>IOS will take subnetted networks but will translate it into the classful network for the running-config. </li></ul>
  41. 41. Configuring RIP <ul><li>Rick’s Clarifications (This is for IGPs only and not EGPs such as BGP): </li></ul><ul><li>The network command does two things: </li></ul><ul><li>1. Determines which interfaces will participate in sending and receiving routing updates, as long as the interface IP address falls in the range of the network command. </li></ul><ul><li>2. Determines which networks this router will announce as being directly connected to in its routing updates to other routers. </li></ul><ul><li>The network numbers do not necessarily have to be based on the network class, as it depends on the routing protocol. Network numbers are based on the network class for RIP, IGRP, and usually EIGRP, but can be more specific for OSPF, EIGRP and IS-IS. </li></ul>
  42. 42. Triggered Extensions <ul><li>Triggered Extensions to RIP </li></ul><ul><li>http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a008008746f.html </li></ul><ul><li>There were two problems using RIP to connect to a WAN: </li></ul><ul><ul><li>Periodic broadcasting by RIP generally prevented WAN circuits from being closed. </li></ul></ul><ul><ul><li>Even on fixed, point-to-point links, the overhead of periodic RIP transmissions could seriously interrupt normal data transfer because of the quantity of information that hits the line every 30 seconds. </li></ul></ul><ul><li>To overcome these limitations, triggered extensions to RIP cause RIP to send information on the WAN only when there has been an update to the routing database. </li></ul><ul><li>Periodic update packets are suppressed over the interface on which this feature is enabled. </li></ul>interface serial 0  ip rip triggered
  43. 43. Triggered Extensions <ul><li>RFC 2091, Triggered Extensions to RIP to Support Demand Circuits. </li></ul><ul><li>When triggered extensions to RIP are enabled, routing updates are transmitted on the WAN only if one of the following occurs: </li></ul><ul><ul><li>The router receives a specific request for a routing update. (Full database is sent.) </li></ul></ul><ul><ul><li>Information from another interface modifies the routing database. (Only latest changes are sent) </li></ul></ul><ul><ul><li>The interface comes up or goes down. (Partial database is sent.) </li></ul></ul><ul><ul><li>The router is first powered on, to ensure that at least one update is sent. (Full database is sent.) </li></ul></ul><ul><li>You might want to enable this feature if you are using an on-demand circuit and you are charged for usage time. Fewer routing updates will incur lower usage costs. </li></ul>interface serial 0  ip rip triggered
  44. 44. <ul><li>RIP Message </li></ul><ul><li>Data Link Frame </li></ul><ul><li>        MAC Source Address </li></ul><ul><li>        MAC Destination Address = Broadcast </li></ul><ul><li>  </li></ul><ul><li>IP Packet </li></ul><ul><li>        IP Source Address </li></ul><ul><li>        IP Destination Address = Broadcast: 255.255.255.255 </li></ul><ul><li>        Protocol field = 17 for UDP </li></ul><ul><li>  </li></ul><ul><li>UDP Segment </li></ul><ul><li>        Source Port number field = 520 for RIP Message </li></ul><ul><li>  </li></ul><ul><li>RIP Message (Data portion of IP Packet): </li></ul><ul><li>        Routes: Network IP Address </li></ul><ul><li>        Hops (metric) </li></ul>The RIPv1 Protocol Data Link Frame Header IP Packet Header UDP Segment Header RIP Message
  45. 45. <ul><li>Command : 1 signifying a Request or 2 signifying a Reply </li></ul><ul><li>Version : 1 for RIP v 1 or 2 for RIP v 2 </li></ul><ul><li>Address Family Identifier : 2 signifying IP (only exception is for a Request for the Router’s full routing table, later Semester in RIP v 2) </li></ul><ul><li>IP Address : The address of the destination route, which may be a network address, a subnet address of a host address. </li></ul><ul><li>Metric : Hop count between 1 and 16. Note : With RIP the sending router increases the metric before sending out the RIP message. </li></ul><ul><li>Note: The routing table knows the next-hop-ip-address (via) from the source IP address of the packet. </li></ul>Data Link Frame Header IP Packet Header UDP Segment Header RIP Message
  46. 46. RIP v2 message format <ul><li>All the extensions to the original protocol are carried in the unused fields. </li></ul><ul><li>The Address Family Identifier (AFI) field is set to two for IP. The only exception is a request for a full routing table of a router or host, in which case it will be set to zero. </li></ul>
  47. 47. RIP v2 message format <ul><li>The Route Tag field provides a way to differentiate between internal and external routes. </li></ul><ul><li>External routes are those that have been redistributed into the RIP v2. </li></ul><ul><li>The Next Hop field contains the IP address of the next hop listed in the IP Address field. </li></ul><ul><li>Metric indicates how many internetwork hops, between 1 and 15 for a valid route, or 16 for an unreachable route. </li></ul>
  48. 48. Configuring RIP <ul><li>RIP must be enabled and the networks specified. The remaining tasks are optional. Among these optional tasks are: </li></ul><ul><li>Specifying a RIP version (RIPv1 or RIPv2) </li></ul><ul><li>Enabling RIP authentication </li></ul><ul><li>Configuring route summarization on an interface </li></ul><ul><li>Verifying IP route summarization </li></ul><ul><li>Disabling automatic route summarization (RIPv2) </li></ul><ul><li>Running IGRP and RIP concurrently </li></ul><ul><li>Disabling the validation of source IP addresses </li></ul><ul><li>Enabling or disabling split horizon </li></ul><ul><li>Connecting RIP to a WAN </li></ul>
  49. 49. ip classless command <ul><li>IP classless only affects the operation of the forwarding processes in IOS. IP classless does not affect the way the routing table is built. </li></ul><ul><li>This command concerns classless and classful routing behavior, which is not the same as classless and classful routing protocols (later). </li></ul>
  50. 50. Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>Parent Route </li></ul><ul><li>Created automatically whenever there is a route with a mask greater than the classful mask. </li></ul><ul><li>For non-VLSM routes, contains the mask of the child routes. </li></ul><ul><li>Child Routes </li></ul><ul><li>Routes with masks greater than the default classful mask. </li></ul>
  51. 51. Lookup what? <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>Routing Table process matches: </li></ul><ul><li>The routing table process compares the left-most bits in the packet’s destination IP address with the left-most bits in the route in the routing table, looking for a longest-bit-match. </li></ul><ul><li>The subnet mask of the route in the routing table specifies the minimum number of left-most bits that must match. </li></ul><ul><li>Before checking child routes, the classful mask of the parent route is used. </li></ul><ul><ul><li>For child routes the parent route’s mask is used. </li></ul></ul><ul><ul><li>For VLSM routes, the mask is contained with the child route. </li></ul></ul>
  52. 52. Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 192.168.1.10 </li></ul><ul><li>16 bits of 172.16.0.0 do not match, so child routes are not checked. </li></ul><ul><li>24 bits of 192.168.1.0/24 do match, so this route is used. </li></ul>
  53. 53. Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0 /24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 172.16.2.1 </li></ul><ul><li>16 bits of 172.16.0.0 do match, so child routes are checked. </li></ul><ul><li>24 bits of 172.16.1.0 do not match, so continue to next child route. </li></ul><ul><li>24 bits of 172.16.2.0 do match, so this route is used! </li></ul>
  54. 54. Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 32.1.1.10 </li></ul><ul><li>16 bits of 172.16.0.0 do not match, so child routes are not checked. </li></ul><ul><li>24 bits of 192.168.1.0/24 do not match, so this route is not used. </li></ul><ul><li>8 bits of 172.0.0.0/8 do not match, so this route is not used. </li></ul><ul><li>4 bits of 160.0.0.0/4 do not match, so this route is not used. </li></ul><ul><li>0 bits of 0.0.0.0/0 does match, so this route is used! </li></ul>
  55. 55. Parent and Child Routes <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 172.16.4.1 </li></ul><ul><li>16 bits of 172.16.0.0 do match, so child routes are checked. </li></ul><ul><li>24 bits of 172.16.1.0 do not match, so continue to next child route. </li></ul><ul><li>24 bits of 172.16.2.0 do not match, so continue to next child route. </li></ul><ul><li>24 bits of 172.16.3.0 do not match, no more child routes. </li></ul><ul><li>Now what??? It depends! </li></ul>
  56. 56. Classful Routing Behavior <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 172.16.4.1 </li></ul><ul><li>Router(config)# no ip classless </li></ul><ul><li>With classful routing behavior , if the child routes are checked but there are no matches, the routing lookup process ends and the Packet is dropped . (The packets get in, but they can’t get out!) </li></ul><ul><li>Supernet and default routes are not checked. </li></ul><ul><li>Default with IOS 11.2 and prior </li></ul>
  57. 57. Classless Routing Behavior <ul><li>RouterB#show ip route </li></ul><ul><li>172.16.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>R 172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0 </li></ul><ul><li>C 172.16.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.16.3.0 is directly connected, FastEthernet0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Serial1 </li></ul><ul><li>S 172.0.0.0/8 is directly connected, Serial1 </li></ul><ul><li>S 160.0.0.0/4 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul><ul><li>DA = 172.16.4.1 </li></ul><ul><li>Router(config)# ip classless </li></ul><ul><li>With classless routing behavior , if the child routes are checked but there are no matches, the routing lookup process continues with other routes in the routing table, including supernet and default routes. </li></ul><ul><li>8 bits of 172.0.0.0/8 do match, so this route is used! </li></ul><ul><li>Default with IOS 11.3 and later </li></ul>
  58. 58. Common RIP Configuration Issues <ul><li>Split Horizon </li></ul><ul><li>The following command is used to disable split horizon : </li></ul><ul><li>GAD(config-if)# no ip split-horizon </li></ul><ul><li>The following command is used to enable (default) split horizon : </li></ul><ul><li>GAD(config-if)# ip split-horizon </li></ul>
  59. 59. Common RIP Configuration Issues <ul><li>Holddown Timer </li></ul><ul><li>The ideal setting would be to set the timer just longer than the longest possible update time for the internetwork. </li></ul><ul><li>To change the holddown timer: </li></ul><ul><li>Router(config-router)# timers basic update invalid holddown flush [sleeptime] </li></ul>
  60. 60. Common RIP Configuration Issues <ul><li>Update Timer </li></ul><ul><li>The default RIP update interval in Cisco IOS is 30 seconds. This can be configured for longer intervals to conserve bandwidth, or for shorter intervals to decrease convergence time. </li></ul><ul><li>To change the update internal: </li></ul><ul><li>GAD(config-router)# update-timer seconds </li></ul>
  61. 61. Common RIP Configuration Issues <ul><li>For RIP and IGRP, the passive interface command stops the router from sending updates to a particular neighbor, but the router continues to listen and use routing updates from that neighbor. (More later.) </li></ul><ul><li>Also used when there are no routers on that interface, such as stub LANs. </li></ul><ul><li>Router(config-router)# passive-interface interface </li></ul>router rip passive-interface fastethernet 0/0 
  62. 62. Common RIP Configuration Issues <ul><li>Because RIP is a broadcast protocol, the network administrator may have to configure RIP to exchange routing information in a non-broadcast network such as Frame Relay. </li></ul><ul><li>In this type of network, RIP needs to be told of other neighboring RIP routers. </li></ul><ul><li>To do this use the router rip command: </li></ul><ul><li>Router(config-router)# neighbor ip address </li></ul>
  63. 63. Common RIP Configuration Issues <ul><li>By default, the Cisco IOS software receives RIP Version 1 and Version 2 packets, but sends only Version 1 packets. </li></ul><ul><li>The network administrator can configure the router to only receive and send Version 1 packets or the administrator can configure the router to send only Version 2 packets. </li></ul>
  64. 64. Compatibility with RIP v1 <ul><li>NewYork </li></ul><ul><li>interface fastethernet0/0 </li></ul><ul><li>ip address 192.168.50.129 255.255.255.192 </li></ul><ul><li>ip rip send version 1 </li></ul><ul><li>ip rip receive version 1 </li></ul><ul><li>interface fastethernet0/1 </li></ul><ul><li>ip address 172.25.150.193 255.255.255.240 </li></ul><ul><li>ip rip send version 1 2 </li></ul><ul><li>interface fastethernet0/2 </li></ul><ul><li>ip address 172.25.150.225 225.255.255.240 </li></ul><ul><li>router rip </li></ul><ul><li>version 2 </li></ul><ul><li>network 172.25.0.0 </li></ul><ul><li>network 192.168.50.0 </li></ul><ul><li>Interface FastEthernet0/0 is configured to send and receive RIP v1 updates. </li></ul><ul><li>FastEthernet0/1 is configured to send both version 1 and 2 updates. </li></ul><ul><li>FastEthernet0/2 has no special configuration and therefore sends and receives version 2 by default. </li></ul>RIPv2
  65. 65. Verifying RIP configuration
  66. 66. Verifying RIP configuration <ul><li>Also: show running-config </li></ul>
  67. 67. Troubleshooting RIP update issues
  68. 68. Troubleshooting RIP update issues <ul><li>Other commands to troubleshoot RIP: </li></ul><ul><li>show ip rip database </li></ul><ul><li>show ip protocols {summary} </li></ul><ul><li>show ip route </li></ul><ul><li>debug ip rip {events} </li></ul><ul><li>show ip interface brief </li></ul>
  69. 69. Load balancing with RIP <ul><li>RIP is capable of load balancing over as many as six equal-cost paths, with four paths being default. RIP performs what is referred to as “round robin” load balancing. </li></ul><ul><li>This means that RIP takes turns forwarding packets over the parallel paths. </li></ul><ul><li>This is only part of the story… </li></ul>
  70. 70. Fast Switching and Process Switching <ul><li>The following information is taken from Routing TCP/IP Volume I by Jeff Doyle. </li></ul><ul><li>Load sharing or Load balancing allows routers to take advantage of multiple paths to the same destination. </li></ul><ul><li>Equal-cost load balancing: </li></ul><ul><ul><li>Distributes packets equally among multiple paths with equal metrics </li></ul></ul><ul><ul><li>RIP, EIGRP, OSPF, IS-IS and BGP </li></ul></ul><ul><li>Unequal-cost load balancing: </li></ul><ul><ul><li>Distributes packets among multiple paths with different metrics, inversely proportional to the cost of the routes. </li></ul></ul><ul><ul><li>IGRP, EIGRP </li></ul></ul><ul><li>Load sharing can be either: </li></ul><ul><ul><li>Per Destination (Fast Switching) </li></ul></ul><ul><ul><li>Per Packet ( Process Switching) </li></ul></ul>
  71. 71. Fast Switching – Per Destination Load Balancing <ul><li>The default for most interfaces is Fast Switching. </li></ul><ul><li>Load balancing is distributed according to the destination IP address. </li></ul><ul><li>Given two paths to the same network, all packets for one destination IP address will travel over the first path, all packets for a second destination will travel over the second path, all packets for the third destination will again travel over the first path, and so on. </li></ul><ul><li>To enable fast switching: </li></ul><ul><li>Router(config-if)#  ip route-cache </li></ul><ul><li>To enable distributed or process switching: </li></ul><ul><li>Router(config-if)#  no ip route-cache </li></ul>ping 10.0.0.1 ping 10.0.0.2 Router(config-if)#  ip route-cache
  72. 72. Fast Switching – Per Destination Load Balancing <ul><li>Fast Switching </li></ul><ul><li>Router switches first packet to a particular destination, a routing table lookup is performed and an exit interface is selected. </li></ul><ul><li>The necessary data-link information to frame the packet for the selected interface is retrieved including any ARP cache information. </li></ul><ul><li>The route and data-link information is stored in fast switching cache. </li></ul><ul><li>The router uses the cache to look up subsequent packets. </li></ul><ul><li>All other packets to the same destination are immediately switched out the same interface without the router performing another routing table lookup, including any recursive lookups. (Also no ARP cache lookup). </li></ul>ping 10.0.0.1 ping 10.0.0.2 Router(config-if)#  ip route-cache
  73. 73. Process Switching – Per Packet Load Balancing <ul><li>Process Switching </li></ul><ul><li>Given equal cost paths, per packet load sharing means that one packet to a destination is sent over one link, the next packet to the same destination is sent over the next link, and so on. </li></ul><ul><li>If the paths are unequal cost, the load balancing may be one packet over the higher-cost link for every three packets over the lower-cost link, or similar ratio. </li></ul><ul><li>With process switching, for every packet, the router performs a route table lookup and selects an interface, and looks up the data-link information. </li></ul><ul><li>To enable distributed or process switching: </li></ul><ul><li>Router(config-if)#  no ip route-cache </li></ul>ping 10.0.0.1 ping 10.0.0.2 Router(config-if)# no   ip route-cache
  74. 74. Which one? <ul><li>Fast Switching or Process Switching </li></ul><ul><li>Process switching (per packet load balancing) has a price, load balancing may be distributed more evenly but the lower switching time and processor utilization of fast switching are lost. </li></ul>ping 10.0.0.1 ping 10.0.0.2 Router(config-if)# no   ip route-cache ping 10.0.0.1 ping 10.0.0.2 Router(config-if)#  ip route-cache Fast Switching Process Switching
  75. 75. Using debug ip packet with Fast Switching and Process Switching <ul><li>debug ip packet can be used to observe packets sent and received and the interfaces that are involved. </li></ul><ul><li>IMPORTANT: The debug ip packet command allows only process switched packets to be observed. Fast switch packets are not displayed (except for the first packet in the flow). </li></ul>Router# debug ip packet IP: s=192.168.3.2 (FastEthernet0), d=10.0.0.1 ( Serial0/0 ), g= 192.168.1.2 , forward IP: s=192.168.3.2 (FastEthernet0), d=10.0.0.1 ( Serial0/1 ), g= 192.168.2.2 , forward IP: s=192.168.3.2 (FastEthernet0), d=10.0.0.1 ( Serial0/0 ), g= 192.168.1.2 , forward IP: s=192.168.3.2 (FastEthernet0), d=10.0.0.1 ( Serial0/1 ), g= 192.168.2.2 , forward
  76. 76. Load balancing across multiple paths <ul><li>Note: The example used in this section of the online curriculum is really for IGRP/EIGRP and does not fit well in this section of RIP. </li></ul><ul><li>By default, most IP routing protocols install a maximum of four parallel routes in a routing table. </li></ul><ul><li>Static routes always install six routes. </li></ul><ul><li>The exception is BGP, which by default allows only one path to a destination. </li></ul><ul><li>The range of maximum paths is one to six paths. To change the maximum number of parallel paths allowed, use the following command in router configuration mode: </li></ul><ul><li>Router(config-router)# maximum-paths [ number ] </li></ul>
  77. 77. RIP and Administrative Distance
  78. 78. RIP and Floating Static Routes <ul><li>Floating static routes are static routes which are used as backup routes. </li></ul><ul><li>They are only injected into the routing table when a route with a lower administrative distance (dynamic or another static route) goes down. </li></ul><ul><li>Should the route with the lower administrative distance come back up then the floating static route is removed from the routing table. </li></ul>172.16.0.0/16 X router rip network 192.168.13.0 ip route 172.16.0.0 255.255.0.0 bri0/1 130
  79. 79. RIPv1 Labs – 3 Scenarios (Optional) <ul><li>Read the following lab. </li></ul><ul><li>Review the configurations and the outputs. </li></ul>
  80. 80. <ul><li>Objective </li></ul><ul><li>  In this lab, you will configure RIP routing in three different scenarios. </li></ul><ul><li>At the end of each scenario, all hosts and all routers should be able to reach (ping) each other. </li></ul><ul><li>  </li></ul><ul><li>Scenario </li></ul><ul><li>  There are five separate classful networks. After configuring RIP, we want to view the RIP update messages being sent and received by each router. </li></ul><ul><li>  </li></ul><ul><li>Scenario 1: Running RIPv1 on classful networks </li></ul><ul><li>Scenario 2: Running RIPv1 on subnets and between classful networks </li></ul><ul><li>Scenario 3: Running RIPv1 on a stub network </li></ul><ul><li>  </li></ul><ul><li>These three scenarios can be done in sequence or separately. </li></ul>RIPv1 Labs – 3 Scenarios
  81. 81. <ul><li>Setup </li></ul><ul><li>Use the 8 Steps to Success to help you configure the routers. </li></ul><ul><li>Be sure your cabling is correct, as this causes more troubleshooting issues than anything else. </li></ul><ul><li>If the routers have a startup-config already on them, erase it and reboot the routers. </li></ul><ul><li>Configure the routers to include hostnames and the proper interface commands including IP addresses, subnet masks, etc. </li></ul><ul><li>Each router should be able to ping the interface of the adjacent (neighboring) router and the host on its LAN (Ethernet) interface. </li></ul><ul><li>Test and troubleshoot as necessary. </li></ul><ul><li>Basic Configurations </li></ul><ul><li>There is a Basic Configuration included for each scenario, but it does not include clock rate, no shutdown and some other necessary commands. </li></ul><ul><li>Note: Even though some of the networks are in numerical order, obviously this does not need to be the case. We only did this to make it easier to remember where the networks originated from. </li></ul>RIPv1 Labs – 3 Scenarios
  82. 82. <ul><li>Optional: Keeping outputs from interrupting our inputs </li></ul><ul><li>  </li></ul><ul><li>Before we begin to configure RIP, lets configure the console 0 port to keep debug and other output messages from interrupting our input. Use the following command on each router to keep the debug out from interfering with you command-line input: </li></ul><ul><li>  </li></ul><ul><li>Router(config)# line console 0 </li></ul><ul><li>Router(config-line)# logging synchronous </li></ul><ul><li>  </li></ul><ul><li>Optional: Changing the default timeout </li></ul><ul><li>  </li></ul><ul><li>After 10 minutes, by default, if there is no input via the console, the user will be logged off. Although a good idea in production environment, in a lab environment this can be somewhat annoying. To turn-off the automatic timeout feature, we use the command: exec-timeout minutes [ seconds ] , setting both the minutes and seconds to 0. </li></ul><ul><li>  </li></ul><ul><li>Router(config)# line console 0 </li></ul><ul><li>Router(config-line)# exec-timeout 0 0 </li></ul>RIPv1 Labs – 3 Scenarios
  83. 83. <ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.168.1.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 192.168.2.1 255.255.255.0 </li></ul><ul><li>  </li></ul><ul><li>SanJose1 </li></ul><ul><li>hostname SanJose1 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.168.3.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 192.168.2.2 255.255.255.0 </li></ul><ul><li>interface serial 1 </li></ul><ul><li>ip add 192.168.4.2 255.255.255.0 </li></ul><ul><li>  </li></ul><ul><li>Baypointe </li></ul><ul><li>hostname Baypointe </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.168.5.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 192.168.4.1 255.255.255.0 </li></ul>Scenario 1: Running RIPv1 on classful networks
  84. 84. <ul><li>Objective: Running RIPv1 on classful networks </li></ul><ul><li>  </li></ul><ul><li>This scenario is the same one we used in the network discovery lab, with the same configurations and the same outputs. The concepts specific to this scenario will become more clear when we view the differences between this scenario and Scenario 2: Running RIPv1 on subnets and between classful networks. </li></ul><ul><li>  </li></ul><ul><li>Step 1 – Configuring RIP </li></ul><ul><li>  </li></ul><ul><li>First, lets enable RIP on each router. </li></ul><ul><li>  </li></ul><ul><li>From global configuration you will enter the command (the default is RIPv1): </li></ul><ul><li>Router(config)# router rip </li></ul><ul><li>  </li></ul><ul><li>Once you are in the Router RIP configuration sub-mode, all you need to do is enter the classful network address for each directly connected network, using the network command. </li></ul><ul><li>Router(config-router)# network directly-connected-classful-network-address </li></ul><ul><li>  </li></ul>Scenario 1: Running RIPv1 on classful networks
  85. 85. <ul><li>Here are the commands for each router: </li></ul><ul><li>  </li></ul><ul><li>SanJose2# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 192.168.1.0 </li></ul><ul><li>SanJose2(config-router)# network 192.168.2.0 </li></ul><ul><li>  </li></ul><ul><li>Baypointe# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>Baypointe(config)# router rip </li></ul><ul><li>Baypointe(config-router)# network 192.168.4.0 </li></ul><ul><li>Baypointe(config-router)# network 192.168.5.0 </li></ul><ul><li>  </li></ul><ul><li>SanJose1# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose1(config)# router rip </li></ul><ul><li>SanJose1(config-router)# network 192.168.2.0 </li></ul><ul><li>SanJose1(config-router)# network 192.168.3.0 </li></ul><ul><li>SanJose1(config-router)# network 192.168.4.0 </li></ul>Scenario 1: Running RIPv1 on classful networks
  86. 86. <ul><li>Step 2 – Understanding the network command </li></ul><ul><li>  </li></ul><ul><li>SENDING RIP MESSAGES </li></ul><ul><li>Each router will begin to send RIP update message out each interface belonging to one of the network statements. </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 192.168.1.0 </li></ul><ul><li>SanJose2(config-router)# network 192.168.2.0 </li></ul><ul><li>  </li></ul><ul><li>For example, SanJose2 to will send out RIP update messages on Ethernet 0 because that interface has an IP address that belong to the network 192.168.1.0, and on Serial 0 because that interface has an IP address that belongs to the network 192.168.2.0. </li></ul><ul><li>Just because a router has a directly connected network does not mean it will automatically include that network in its routing updates to neighboring routers. The network command also tells the RIP to include these networks in its updates to adjacent neighbors. </li></ul><ul><li>To view the RIP messages being sent and received use the debug ip rip command. </li></ul><ul><li>  </li></ul><ul><li>SanJose2# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>  </li></ul><ul><li>SanJose2 </li></ul><ul><li>01:03:27: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) </li></ul><ul><li>01:03:27: network 192.168.2.0, metric 1 </li></ul><ul><li>01:03:27: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.2.1) </li></ul><ul><li>01:03:27: network 192.168.1.0, metric 1 </li></ul>
  87. 87. <ul><li>LISTENING FOR RIP MESSAGES </li></ul><ul><li>Routers will also listen for RIP messages on each interface belonging to one of the network statements. </li></ul><ul><li>  </li></ul><ul><li>For example, SanJose2 to will listen for RIP update messages on Ethernet 0 because that interface has an IP address that belong to the network 192.168.1.0, and also listen for RIP update messages on Serial 0 because that interface has an IP address that belongs to the network 192.168.2.0. </li></ul><ul><li>As RIP messages are received router, will add those networks in the messages to their routing tables: </li></ul><ul><li>If the RIP message contains a network not currently in the routing table. </li></ul><ul><li>If the RIP message contains a network with a better metric (fewer hops) than an entry currently in the routing table. </li></ul><ul><li>  </li></ul><ul><li>SanJose2 </li></ul><ul><li>01:10:56: RIP: received v1 update from 192.168.2.2 on Serial0 </li></ul><ul><li>01:10:56: 192.168.4.0 in 1 hops </li></ul><ul><li>01:10:56: 192.168.3.0 in 1 hops </li></ul>Scenario 1: Running RIPv1 on classful networks
  88. 88. <ul><li>Step 3 – Viewing the debug ip rip output and the routing tables </li></ul><ul><li>  </li></ul><ul><li>Remember that SanJose1 will learn routes to networks from SanJose2. It will then send that information to Baypointe, telling Baypointe that it is the next hop to get to those networks, and incrementing the metric (hop count) by one. </li></ul><ul><li>  </li></ul><ul><li>After convergence, each router will continue to send its RIP update messages out the appropriate interfaces every 30 seconds. </li></ul><ul><li>  </li></ul><ul><li>Lets look at the debug messages and the routing table for each router: </li></ul>Scenario 1: Running RIPv1 on classful networks
  89. 89. <ul><li>SanJose2   </li></ul><ul><li>01:30:45: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) </li></ul><ul><li>01:30:45: network 192.168.4.0, metric 2 </li></ul><ul><li>01:30:45: network 192.168.5.0, metric 3 </li></ul><ul><li>01:30:45: network 192.168.2.0, metric 1 </li></ul><ul><li>01:30:45: network 192.168.3.0, metric 2 </li></ul><ul><li>01:30:45: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.2.1) </li></ul><ul><li>01:30:45: network 192.168.1.0, metric 1 </li></ul><ul><li>SanJose2# </li></ul><ul><li>01:30:50: RIP: received v1 update from 192.168.2.2 on Serial0 </li></ul><ul><li>01:30:50: 192.168.4.0 in 1 hops </li></ul><ul><li>01:30:50: 192.168.5.0 in 2 hops </li></ul><ul><li>01:30:50: 192.168.3.0 in 1 hops </li></ul><ul><li>SanJose2# </li></ul><ul><li>  </li></ul><ul><li>SanJose2#show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted> </li></ul><ul><li>i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default </li></ul><ul><li>U - per-user static route, o - ODR  </li></ul><ul><li>Gateway of last resort is not set </li></ul><ul><li>  </li></ul><ul><li>R 192.168.4.0/24 [120/1] via 192.168.2.2, 00:00:10, Serial0 </li></ul><ul><li>R 192.168.5.0/24 [120/2] via 192.168.2.2, 00:00:10, Serial0 </li></ul><ul><li>C 192.168.1.0/24 is directly connected, Ethernet0 </li></ul><ul><li>C 192.168.2.0/24 is directly connected, Serial0 </li></ul><ul><li>R 192.168.3.0/24 [120/1] via 192.168.2.2, 00:00:10, Serial0 </li></ul><ul><li>SanJose2# </li></ul>
  90. 90. <ul><li>SanJose1   </li></ul><ul><li>01:33:05: RIP: received v1 update from 192.168.4.1 on Serial1 </li></ul><ul><li>01:33:05: 192.168.5.0 in 1 hops </li></ul><ul><li>SanJose1# </li></ul><ul><li>01:33:07: RIP: received v1 update from 192.168.2.1 on Serial0 </li></ul><ul><li>01:33:07: 192.168.1.0 in 1 hops </li></ul><ul><li>01:33:08: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.3.1) </li></ul><ul><li>01:33:08: network 192.168.4.0, metric 1 </li></ul><ul><li>01:33:08: network 192.168.5.0, metric 2 </li></ul><ul><li>01:33:08: network 192.168.1.0, metric 2 </li></ul><ul><li>01:33:08: network 192.168.2.0, metric 1 </li></ul><ul><li>01:33:08: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.2.2) </li></ul><ul><li>01:33:08: network 192.168.4.0, metric 1 </li></ul><ul><li>01:33:08: network 192.168.5.0, metric 2 </li></ul><ul><li>01:33:08: network 192.168.3.0, metric 1 </li></ul><ul><li>01:33:08: RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.2) </li></ul><ul><li>01:33:08: network 192.168.1.0, metric 2 </li></ul><ul><li>01:33:08: network 192.168.2.0, metric 1 </li></ul><ul><li>01:33:08: network 192.168.3.0, metric 1 </li></ul><ul><li>  </li></ul><ul><li>SanJose1#show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted> </li></ul><ul><li>Gateway of last resort is not set  </li></ul><ul><li>C 192.168.4.0/24 is directly connected, Serial1 </li></ul><ul><li>R 192.168.5.0/24 [120/1] via 192.168.4.1, 00:00:12, Serial1 </li></ul><ul><li>R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:10, Serial0 </li></ul><ul><li>C 192.168.2.0/24 is directly connected, Serial0 </li></ul><ul><li>C 192.168.3.0/24 is directly connected, Ethernet0 </li></ul>
  91. 91. <ul><li>Baypointe   </li></ul><ul><li>01:34:53: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.5.1) </li></ul><ul><li>01:34:53: network 192.168.4.0, metric 1 </li></ul><ul><li>01:34:53: network 192.168.1.0, metric 3 </li></ul><ul><li>01:34:53: network 192.168.2.0, metric 2 </li></ul><ul><li>01:34:53: network 192.168.3.0, metric 2 </li></ul><ul><li>01:34:53: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.4.1) </li></ul><ul><li>01:34:53: network 192.168.5.0, metric 1 </li></ul><ul><li>Baypointe# </li></ul><ul><li>01:34:56: RIP: received v1 update from 192.168.4.2 on Serial0 </li></ul><ul><li>01:34:56: 192.168.1.0 in 2 hops </li></ul><ul><li>01:34:56: 192.168.2.0 in 1 hops </li></ul><ul><li>01:34:56: 192.168.3.0 in 1 hops </li></ul><ul><li>  </li></ul><ul><li>Baypointe#show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li>D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area </li></ul><ul><li>N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 </li></ul><ul><li>E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP </li></ul><ul><li>i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default </li></ul><ul><li>U - per-user static route, o - ODR  </li></ul><ul><li>Gateway of last resort is not set </li></ul><ul><li>  </li></ul><ul><li>C 192.168.4.0/24 is directly connected, Serial0 </li></ul><ul><li>C 192.168.5.0/24 is directly connected, Ethernet0 </li></ul><ul><li>R 192.168.1.0/24 [120/2] via 192.168.4.2, 00:00:23, Serial0 </li></ul><ul><li>R 192.168.2.0/24 [120/1] via 192.168.4.2, 00:00:23, Serial0 </li></ul><ul><li>R 192.168.3.0/24 [120/1] via 192.168.4.2, 00:00:23, Serial0 </li></ul>
  92. 92. <ul><li>NOTE: At this point all routers should be able to ping all networks. We will discuss RIP much more in the chapter on Routing Protocols (RIP). </li></ul><ul><li>  </li></ul><ul><li>Step 4 – Turning-off debug </li></ul><ul><li>  </li></ul><ul><li>Don’t forget to turn-off debug when you are done collecting the output. </li></ul><ul><li>  </li></ul><ul><li>Router# undebug all </li></ul><ul><li>or </li></ul><ul><li>Baypointe# undebug ip rip   </li></ul><ul><li>  </li></ul><ul><li>Step 5 – Reflections </li></ul><ul><li>For each router compare the RIP received messages with its routing table. Now you see how the information is entered into the routing table. </li></ul><ul><li>Cisco IOS uses split horizon with poison reverse, however this information is not displayed with debug ip rip command. </li></ul><ul><li>You will notice that the routers send RIP messages out their stub Ethernet interfaces, even though there are no routers out there to receive those messages. This does take up unnecessary bandwidth on the link; so later we will see how to keep those RIP messages from going out those interfaces. </li></ul>Scenario 1: Running RIPv1 on classful networks
  93. 93. <ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.30.1.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 172.30.2.1 255.255.255.0 </li></ul><ul><li>  </li></ul><ul><li>SanJose1 </li></ul><ul><li>hostname SanJose1 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.30.3.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 172.30.2.2 255.255.255.0 </li></ul><ul><li>interface serial 1 </li></ul><ul><li>ip add 192.168.4.9 255.255.255.252 </li></ul><ul><li>  </li></ul><ul><li>Baypointe </li></ul><ul><li>hostname Baypointe </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.168.5.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 192.168.4.10 255.255.255.252 </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks Note: This lab has some important information regarding RIP and boundary routers!
  94. 94. <ul><li>Objective: Running RIPv1 on subnets and between classful networks </li></ul><ul><li>  </li></ul><ul><li>In this scenario we will see how subnetted routes are distributed with the same classful network. We will also see how RIPv1 automatically summarizes between classful network boundaries. You will notice that SanJose1 and SanJose2 have subnets belonging to the 172.30.0.0 network, but Baypointe does not. </li></ul><ul><li>  </li></ul><ul><li>Making changes between Scenario 1 and Scenario 2 </li></ul><ul><li>  </li></ul><ul><li>Be sure to change the IP addressing as displayed in the diagram and Basic Configuration section for Scenario 2. Sometimes when changing the IP address on a serial interface, you may need to reset that interface by doing a shutdown , wait for the LINK-5-CHANGED message, then follow it with a no shutdown command. </li></ul><ul><li>  </li></ul><ul><li>If you have just completed Scenario 1, lets remove RIP by issuing the following command on each router : </li></ul><ul><li>  </li></ul><ul><li>Router(config)# no router rip </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  95. 95. <ul><li>Step 1 – Configuring RIP </li></ul><ul><li>  </li></ul><ul><li>Once again, lets enable RIP on each router. </li></ul><ul><li>  </li></ul><ul><li>Once you are in the Router RIP configuration sub-mode, all you need to do is enter the classful network address for each directly connected network, using the network command. If a router has multiple interfaces on the same classful network, you will only need to enter a single command enabling RIP on all interfaces for that network. </li></ul><ul><li>Router(config-router)# network directly-connected-classful-network-address </li></ul><ul><li>  </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  96. 96. <ul><li>Here are the commands for each router: </li></ul><ul><li>  </li></ul><ul><li>SanJose2# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 172.30.0.0 </li></ul><ul><li>  </li></ul><ul><li>Notice we only used a single network statement for SanJose2, which includes both interfaces, on different subnets, of the 172.30.0.0 major network. </li></ul><ul><li>  </li></ul><ul><li>SanJose1# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose1(config)# router rip </li></ul><ul><li>SanJose1(config-router)# network 172.30.0.0 </li></ul><ul><li>SanJose1(config-router)# network 192.168.4.0 </li></ul><ul><li>  </li></ul><ul><li>Again, notice that we only used a single network statement for SanJose1, which includes both interfaces, on different subnets, of the 172.30.0.0 major network. </li></ul><ul><li>  </li></ul><ul><li>Baypointe# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>Baypointe(config)# router rip </li></ul><ul><li>Baypointe(config-router)# network 192.168.4.0 </li></ul><ul><li>Baypointe(config-router)# network 192.168.5.0 </li></ul>
  97. 97. <ul><li>Question: What would happen if you entered a network statement that was a subnet? For example: </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 172.30.1.0 </li></ul><ul><li>  </li></ul><ul><li>Answer: The IOS would automatically convert it to a classful network statement: </li></ul><ul><li>SanJose2# show running-config </li></ul><ul><li>router rip </li></ul><ul><li>network 172.30.0.0 </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  98. 98. <ul><li>Step 2 – Viewing the debug ip rip output and the routing tables   </li></ul><ul><li>SanJose2   </li></ul><ul><li>SanJose2# debug ip rip </li></ul><ul><li>00:14:10: RIP: received v1 update from 172.30.2.2 on Serial0 </li></ul><ul><li>00:14:10: 172.30.3.0 in 1 hops </li></ul><ul><li>00:14:10: 192.168.4.0 in 1 hops </li></ul><ul><li>00:14:10: 192.168.5.0 in 2 hops </li></ul><ul><li>SanJose2# </li></ul><ul><li>00:14:29: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.1.1) </li></ul><ul><li>00:14:29: subnet 172.30.2.0, metric 1 </li></ul><ul><li>00:14:29: subnet 172.30.3.0, metric 2 </li></ul><ul><li>00:14:29: network 192.168.4.0, metric 2 </li></ul><ul><li>00:14:29: network 192.168.5.0, metric 3 </li></ul><ul><li>00:14:29: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.1) </li></ul><ul><li>00:14:29: subnet 172.30.1.0, metric 1 </li></ul><ul><li>SanJose2# </li></ul><ul><li>00:14:39: RIP: received v1 update from 172.30.2.2 on Serial0 </li></ul><ul><li>00:14:39: 172.30.3.0 in 1 hops </li></ul><ul><li>00:14:39: 192.168.4.0 in 1 hops </li></ul><ul><li>00:14:39: 192.168.5.0 in 2 hops </li></ul><ul><li>SanJose2# undebug all </li></ul><ul><li>  </li></ul><ul><li>SanJose2# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted>  </li></ul><ul><li>Gateway of last resort is not set  </li></ul><ul><li>172.30.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>C 172.30.2.0 is directly connected, Serial0 </li></ul><ul><li>R 172.30.3.0 [120/1] via 172.30.2.2, 00:00:08, Serial0 </li></ul><ul><li>C 172.30.1.0 is directly connected, Ethernet0 </li></ul><ul><li>R 192.168.4.0/24 [120/1] via 172.30.2.2, 00:00:08, Serial0 </li></ul><ul><li>R 192.168.5.0/24 [120/2] via 172.30.2.2, 00:00:08, Serial0 </li></ul>
  99. 99. <ul><li>Reflections </li></ul><ul><li>IMPORTANT INFORMATION : RIPv1 is a classful routing protocol . Classful routing protocols do not send the subnet mask with network in routing updates, ie. 172.30.1.0 is sent by SanJose1 to SanJose2 without any subnet mask information. </li></ul><ul><li>QUESTION : Notice that SanJose2 is receiving the subnet 172.30.3.0 from SanJose1, which is put in the routing table under the parent network (classful network) of 172.30.0.0 with the /24 subnet mask (172.30.0.0/24 is subnetted, 3 subnets). Also notice that the RIP message received from SanJose1 was “172.30.3.0 in 1 hops” but did not include a subnet mask for the subnet. How does SanJose2 know that this subnet has a /24 (255.255.255.0) subnet mask? </li></ul><ul><li>ANSWER : SanJose2 received this information on an interface belonging to the same classful network as the incoming 172.30.3.0 update. The IP address that SanJose1 received the “172.30.3.0 in 1 hops” message was on (Serial 0) with an IP address of 172.30.2.1 and a subnet mask of 255.255.255.0. SanJose2 uses its own subnet mask and applies it to this and all other 172.30.0.0 subnets it receives on this interface. The 172.30.3.0 network is placed with the other 172.30.0.0 /24 subnets in the routing table. </li></ul><ul><li>Routers running RIPv1 are limited to using the same subnet mask for all subnets with the same classful network. Classless routing protocols like RIPv2 allow the same major (classful) network to use different subnet masks on different subnets. This is known as VLSM (Variable Length Subnet Masks) and is discussed later (Cabrillo’s CCNA Sem 2 course and the CCNP Advanced Routing). </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  100. 100. <ul><li>SanJose1   </li></ul><ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.3.1) </li></ul><ul><li>00:17:52: subnet 172.30.2.0, metric 1 </li></ul><ul><li>00:17:52: subnet 172.30.1.0, metric 2 </li></ul><ul><li>00:17:52: network 192.168.4.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.5.0, metric 2 </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2) </li></ul><ul><li>00:17:52: subnet 172.30.3.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.4.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.5.0, metric 2 </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.9) </li></ul><ul><li>00:17:52: network 172.30.0.0, metric 1 </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:18:10: RIP: received v1 update from 172.30.2.1 on Serial0 </li></ul><ul><li>00:18:10: 172.30.1.0 in 1 hops </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:18:12: RIP: received v1 update from 192.168.4.10 on Serial1 </li></ul><ul><li>00:18:12: 192.168.5.0 in 1 hops </li></ul><ul><li>SanJose1# undebug all   </li></ul><ul><li>SanJose1# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted>  </li></ul><ul><li>Gateway of last resort is not set  </li></ul><ul><li>172.30.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>C 172.30.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.30.3.0 is directly connected, Ethernet0 </li></ul><ul><li>R 172.30.1.0 [120/1] via 172.30.2.1, 00:00:14, Serial0 </li></ul><ul><li>192.168.4.0/30 is subnetted, 1 subnets </li></ul><ul><li>C 192.168.4.8 is directly connected, Serial1 </li></ul><ul><li>R 192.168.5.0/24 [120/1] via 192.168.4.10, 00:00:10, Serial1 </li></ul><ul><li>  </li></ul>
  101. 101. <ul><li>Reflections </li></ul><ul><li>The same subnet route information applies with routes sent from SanJose2 to SanJose1 (see Reflections for SanJose2). </li></ul><ul><li>SanJose1 knows that the 172.30.1.0 update has a subnet mask of /24 because it received it on an interface with a /24 subnet mask (Serial 0, 172.30.3.2 255.255.255.0). </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  102. 102. <ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Ethernet0 ( 172.30.3.1 ) </li></ul><ul><li>00:17:52: subnet 172.30.2.0, metric 1 </li></ul><ul><li>00:17:52: subnet 172.30.1.0, metric 2 </li></ul><ul><li>00:17:52: network 192.168.4.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.5.0, metric 2 </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial0 ( 172.30.2.2 ) </li></ul><ul><li>00:17:52: subnet 172.30.3.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.4.0, metric 1 </li></ul><ul><li>00:17:52: network 192.168.5.0, metric 2 </li></ul><ul><li>00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial1 ( 192.168.4.9 ) </li></ul><ul><li>00:17:52: network 172.30.0.0, metric 1 </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:18:10: RIP: received v1 update from 172.30.2.1 on Serial0 </li></ul><ul><li>00:18:10: 172.30.1.0 in 1 hops </li></ul><ul><li>SanJose1# </li></ul><ul><li>00:18:12: RIP: received v1 update from 192.168.4.10 on Serial1 </li></ul><ul><li>00:18:12: 192.168.5.0 in 1 hops </li></ul><ul><li>SanJose1# undebug all </li></ul><ul><li>  </li></ul><ul><li>SanJose1# show ip route </li></ul><ul><li>Codes: <omitted>  </li></ul><ul><li>Gateway of last resort is not set  </li></ul><ul><li>172.30.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>C 172.30.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.30.3.0 is directly connected, Ethernet0 </li></ul><ul><li>R 172.30.1.0 [120/1] via 172.30.2.1, 00:00:14, Serial0 </li></ul><ul><li>192.168.4.0/30 is subnetted, 1 subnets </li></ul><ul><li>C 192.168.4.8 is directly connected, Serial1 </li></ul><ul><li>R 192.168.5.0/24 [120/1] via 192.168.4.10, 00:00:10, Serial1 </li></ul>
  103. 103. <ul><li>More Reflections </li></ul><ul><li>IMPORTANT INFORMATION : Notice the RIP update being sent out Serial 1: </li></ul><ul><li>RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.9) </li></ul><ul><li>network 172.30.0.0, metric 1 </li></ul><ul><li>Compare that to the same information for the 172.30.0.0 network being sent out Serial 0 & Ethernet 0: </li></ul><ul><li>RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2) </li></ul><ul><li>subnet 172.30.3.0, metric 1 </li></ul><ul><li>Notice that the 172.30.0.0 subnets are being summarized to their classful network address of 172.30.0.0 when sent out Serial 1 to Baypointe. </li></ul><ul><li>RIP automatically summarizes RIP updates between classful networks. Because the 172.30.0.0 update is being sent out an interface (Serial 1) on a different classful network (192.168.4.0), RIP sends out only a single update for the entire classful network instead of all of the different subnets. This is similar to what we did with summarizing several static routes into a single static route. </li></ul><ul><li>A router like SanJose1, which has an interface in more than one classful network is sometimes called a “boundary router” in RIP. Boundary routers automatically summarize RIP subnets from one classful network to the other. </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  104. 104. <ul><li>More Reflections (continued) </li></ul><ul><li>How is this an advantage? Fewer updates sent and received, resulting in less bandwidth used for routing updates between SanJose1 and Baypointe. Just as importantly, Baypointe will now only have a single route for the 172.30.0.0/16 network, no matter how many subnets there are or how it is subnetted. This will result in faster lookup process in the routing table for Baypointe. </li></ul><ul><li>What do you expect to see in Baypointe’s received RIP messages and its routing table? That’s right, only a single 172.30.0.0 network via SanJose1. </li></ul><ul><li>Are there any disadvantages? Yes, discontinguous networks. We will see this later, but the idea here is what if Baypointe had another connection via Serial 1 to another router, SantaCruz1 on 192.168.4.12/30 subnet, which also has other 172.30.0.0/24 subnets (172.30.4.0/24, 172.30.5.0/24, etc.). Baypointe would also receive the same 172.30.0.0 network from SantaCruz1 as well. Baypointe would not know how to reach the specific subnet, and mistakenly load-balance the packets between the two routers. We will see an example of this later this semester. </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  105. 105. <ul><li>Baypointe   </li></ul><ul><li>Baypointe# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>Baypointe# </li></ul><ul><li>00:20:09: RIP: received v1 update from 192.168.4.9 on Serial0 </li></ul><ul><li>00:20:09: 172.30.0.0 in 1 hops </li></ul><ul><li>Baypointe# </li></ul><ul><li>00:20:24: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.5.1) </li></ul><ul><li>00:20:24: network 172.30.0.0, metric 2 </li></ul><ul><li>00:20:24: network 192.168.4.0, metric 1 </li></ul><ul><li>00:20:24: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.4.10) </li></ul><ul><li>00:20:24: network 192.168.5.0, metric 1 </li></ul><ul><li>Baypointe# </li></ul><ul><li>Baypointe# undebug all   </li></ul><ul><li>Baypointe# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted> </li></ul><ul><li>Gateway of last resort is not set </li></ul><ul><li>  </li></ul><ul><li>R 172.30.0.0/16 [120/1] via 192.168.4.9, 00:00:11, Serial0 </li></ul><ul><li>192.168.4.0/30 is subnetted, 1 subnets </li></ul><ul><li>C 192.168.4.8 is directly connected, Serial0 </li></ul><ul><li>C 192.168.5.0/24 is directly connected, Ethernet0 </li></ul>
  106. 106. <ul><li>Reflections </li></ul><ul><li>Notice that Baypointe is only receiving the classful summary of the 172.30.0.0 subnets: </li></ul><ul><li>RIP: received v1 update from 192.168.4.9 on Serial0 </li></ul><ul><li>172.30.0.0 in 1 hops </li></ul><ul><li>SanJose1 automatically summarized the subnets into a single classful update. </li></ul><ul><li>This keeps Baypointe’s routing table smaller, resulting in faster routing table lookups. </li></ul><ul><li>This also isolates any changes in the 172.30.0.0 network on SanJose1 and SanJose2 from affecting Baypointe. In other words, SanJose1 and SanJose2 can add and delete 172.30.0.0/24 subnets without affecting Baypointe’s routing table, as Baypointe doesn’t care. Baypointe will send all packets destined for the 172.30.0.0/16 network to SanJose1. Baypointe’s routing table: </li></ul><ul><li>R 172.30.0.0/16 [120/1] via 192.168.4.9, 00:00:11, Serial0 </li></ul><ul><li>Also, the subnet mask scheme could be changed (i.e. to /27) on the 172.30.0.0 network without affecting Baypointe’s routing table or the RIP update sent to Baypointe by SanJose1. </li></ul>Scenario 2: Running RIPv1 on subnets and between classful networks
  107. 107. <ul><li>SanJose2 </li></ul><ul><li>hostname SanJose2 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.30.1.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 172.30.2.1 255.255.255.0 </li></ul><ul><li>  </li></ul><ul><li>SanJose1 </li></ul><ul><li>hostname SanJose1 </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 172.30.3.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 172.30.2.2 255.255.255.0 </li></ul><ul><li>interface serial 1 </li></ul><ul><li>ip add 192.168.4.9 255.255.255.252 </li></ul><ul><li>  </li></ul><ul><li>Baypointe </li></ul><ul><li>hostname Baypointe </li></ul><ul><li>interface ethernet 0 </li></ul><ul><li>ip add 192.168.5.1 255.255.255.0 </li></ul><ul><li>interface serial 0 </li></ul><ul><li>ip add 192.168.4.10 255.255.255.252 </li></ul>Scenario 3: Running RIPv1 on a stub network
  108. 108. <ul><li>Objective: Running RIPv1 on a stub network </li></ul><ul><li>  </li></ul><ul><li>In this scenario we will modify Scenario 2 to only run RIP between SanJose1 and SanJose2. Scenario 3 is a very common situation for many companies. It is very common that a company will want to run a dynamic routing protocol (RIPv1 in our case) within their own network, but find in unnecessary to run a dynamic routing protocol between their company and their ISP. </li></ul><ul><li>  </li></ul><ul><li>For Scenario 3 let us assume that Baypointe is the ISP for our Company XYZ, which consists of the SanJose1 and SanJose2 routers using the 172.30.0.0/16 major network, subnetted with a /24 mask. </li></ul><ul><li>  </li></ul><ul><li>Company XYZ is a stub network, meaning there is only one way in and out of the 172.30.0.0/16 network, in via SanJose1 (a.k.a. the entrance router) and out via Baypointe (the ISP). It is doesn’t make sense for SanJose1 to send Baypointe the RIP update of 172.30.0.0 every 30 seconds, because Baypointe has no other way to get there. RIP update message from SanJose1 to Baypointe, if RIP were configured: </li></ul><ul><li>RIP: received v1 update from 192.168.4.9 on Serial0 </li></ul><ul><li>172.30.0.0 in 1 hops   </li></ul><ul><li>Instead, it makes more sense for Baypointe to have a static route configured for the 172.30.0.0/16 network via SanJose1. </li></ul><ul><li>  </li></ul><ul><li>Well, how about traffic from Company XYZ towards the Internet? It makes no sense for Baypointe to send more than the 120,000 summarized Internet routes to SanJose1. All SanJose1 needs to know is that if it is not in the 172.30.0.0 network then send it to the ISP, Baypointe. This is the same for all other Company XYZ routers (only SanJose2 in our case), that they would send all traffic with destination IP addresses other than 172.30.0.0 to SanJose1 who would forward them on to Baypointe.  Let’s see how to configure this. </li></ul>
  109. 109. <ul><li>Making changes between Scenario 2 and Scenario 3 </li></ul><ul><li>  </li></ul><ul><li>Be sure to change the IP addressing as displayed in the diagram and Basic Configuration section for Scenario 3. Sometimes when changing the IP address on a serial interface, you may need to reset that interface by doing a shutdown , wait for the LINK-5-CHANGED message, then follow it with a no shutdown command. </li></ul><ul><li>  </li></ul><ul><li>If you have just completed Scenario 2, lets remove RIP by issuing the following command on each router : </li></ul><ul><li>  </li></ul><ul><li>Router(config)# no router rip </li></ul>
  110. 110. <ul><li>Step 1 – Configuring RIP on SanJose1 and SanJose2 </li></ul><ul><li>  </li></ul><ul><li>Here are the commands for each router: </li></ul><ul><li>  </li></ul><ul><li>SanJose2# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 172.30.0.0 </li></ul><ul><li>  </li></ul><ul><li>SanJose1# configure terminal </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose1(config)# router rip </li></ul><ul><li>SanJose1(config-router)# network 172.30.0.0 </li></ul><ul><li>  </li></ul><ul><li>Notice that we are only including the 172.30.0.0 interfaces, networks, for SanJose1. We will not be exchanging RIP updates with Baypointe via the 192.168.4.0/30 network. </li></ul>
  111. 111. <ul><li>Step 2 - Configuring the default static route on SanJose1 </li></ul><ul><li>  </li></ul><ul><li>On SanJose1, let’s configure a static default route, sending all default traffic, packets with destination IP addresses which do not match a specific route in the routing table, to Baypointe.  </li></ul><ul><li>SanJose1(config)# ip route 0.0.0.0 0.0.0.0 serial 1 </li></ul><ul><li>  </li></ul><ul><li>Notice, since the exit interface is a point-to-point serial interface we chose to use the exit-interface instead of a intermediate-address (next-hop-ip address), saving the router from having to do a recursive lookup. However, using an intermediate-address (next-hop-ip-address) would have worked also. </li></ul><ul><li>  </li></ul><ul><li>Previous to IOS version 12.1, SanJose1 would propagate, send, this default route automatically via RIP with its RIP updates to all other routers (in this case SanJose2). SanJose2 and all other routers will receive this default route via RIP and forward to all other routers in the RIP routing domain. </li></ul><ul><li>  </li></ul><ul><li>However, with IOS 12.1 and later, we need to enter the default-information originate command on Baypointe, the router with the static default route. This will tell SanJose1 to include the static default route with its RIP updates to SanJose2.  </li></ul><ul><li>SanJose1(config)# router rip </li></ul><ul><li>SanJose1(config-router)# default-information originate </li></ul>
  112. 112. <ul><li>Step 3 - Configuring the static route on Baypointe for the 172.30.0.0/16 network </li></ul><ul><li>  </li></ul><ul><li>Since Baypointe and SanJose1 are not exchanging RIP updates, we need to configure a static route on Baypointe for the 172.30.0.0/16 network. This will send all 172.30.0.0/16 traffic, packets with destination IP addresses of 172.30.x.x, to SanJose1. </li></ul><ul><li>  </li></ul><ul><li>Baypointe(config)# ip route 172.30.0.0 255.255.0.0 serial 0 </li></ul><ul><li>  </li></ul><ul><li>Once again, notice, since the exit interface is a point-to-point serial interface we chose to use the exit-interface instead of a intermediate-address (next-hop-ip address), saving the router from having to do a recursive lookup. However, using an intermediate-address (next-hop-ip-address) would have worked also. </li></ul>
  113. 113. <ul><li>SanJose1 </li></ul><ul><li>SanJose1# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>SanJose1# </li></ul><ul><li>02:09:10: RIP: received v1 update from 172.30.2.1 on Serial0 </li></ul><ul><li>02:09:10: 172.30.1.0 in 1 hops </li></ul><ul><li>SanJose1# </li></ul><ul><li>02:09:29: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.3.1) </li></ul><ul><li>02:09:29: subnet 172.30.2.0, metric 1 </li></ul><ul><li>02:09:29: subnet 172.30.1.0, metric 2 </li></ul><ul><li>02:09:29: default, metric 1 </li></ul><ul><li>02:09:29: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2) </li></ul><ul><li>02:09:29: subnet 172.30.3.0, metric 1 </li></ul><ul><li>02:09:29: default, metric 1 </li></ul><ul><li>SanJose1# </li></ul><ul><li>SanJose1# undebug all </li></ul><ul><li>  </li></ul><ul><li>SanJose1# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted>  </li></ul><ul><li>Gateway of last resort is 0.0.0.0 to network 0.0.0.0 </li></ul><ul><li>  </li></ul><ul><li>172.30.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>C 172.30.2.0 is directly connected, Serial0 </li></ul><ul><li>C 172.30.3.0 is directly connected, Ethernet0 </li></ul><ul><li>R 172.30.1.0 [120/1] via 172.30.2.1, 00:00:13, Serial0 </li></ul><ul><li>192.168.4.0/30 is subnetted, 1 subnets </li></ul><ul><li>C 192.168.4.8 is directly connected, Serial1 </li></ul><ul><li>S* 0.0.0.0/0 is directly connected, Serial1 </li></ul>
  114. 114. <ul><li>Reflections </li></ul><ul><li>Notice that the static default route is being propagated by SanJose1 to other routers (SanJose2) via RIP. </li></ul><ul><li>Notice the static route in the routing table and the “Gateway of last resort.” </li></ul>Scenario 3: Running RIPv1 on a stub network
  115. 115. <ul><li>SanJose2 </li></ul><ul><li>  SanJose2# debug ip rip </li></ul><ul><li>RIP protocol debugging is on </li></ul><ul><li>SanJose2# </li></ul><ul><li>02:07:06: RIP: received v1 update from 172.30.2.2 on Serial0 </li></ul><ul><li>02:07:06: 172.30.3.0 in 1 hops </li></ul><ul><li>02:07:07: 0.0.0.0 in 1 hops </li></ul><ul><li>SanJose2# </li></ul><ul><li>02:07:23: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.1.1) </li></ul><ul><li>02:07:23: subnet 172.30.2.0, metric 1 </li></ul><ul><li>02:07:23: subnet 172.30.3.0, metric 2 </li></ul><ul><li>02:07:23: default, metric 2 </li></ul><ul><li>02:07:23: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.1) </li></ul><ul><li>02:07:23: subnet 172.30.1.0, metric 1 </li></ul><ul><li>SanJose2# </li></ul><ul><li>SanJose2# undebug all </li></ul><ul><li>  </li></ul><ul><li>SanJose2# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li><omitted> </li></ul><ul><li>i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default </li></ul><ul><li>U - per-user static route, o - ODR </li></ul><ul><li>Gateway of last resort is 172.30.2.2 to network 0.0.0.0   </li></ul><ul><li>172.30.0.0/24 is subnetted, 3 subnets </li></ul><ul><li>C 172.30.2.0 is directly connected, Serial0 </li></ul><ul><li>R 172.30.3.0 [120/1] via 172.30.2.2, 00:00:22, Serial0 </li></ul><ul><li>C 172.30.1.0 is directly connected, Ethernet0 </li></ul><ul><li>R* 0.0.0.0/0 [120/1] via 172.30.2.2, 00:00:22, Serial0 </li></ul>
  116. 116. <ul><li>Reflections </li></ul><ul><li>Notice that SanJose2 is receiving the default route from SanJose1. </li></ul><ul><li>SanJose2 forwards that default route out Ethernet 0, a RIP enabled interface, although there are no other routers on that segment. </li></ul><ul><li>Notice the default route in the routing table and that it was learned via RIP. </li></ul><ul><li>Notice the “Gateway of last resort” </li></ul><ul><li>  </li></ul>Scenario 3: Running RIPv1 on a stub network
  117. 117. <ul><li>Baypointe </li></ul><ul><li>   </li></ul><ul><li>No RIP messages, as we are not running RIP. </li></ul><ul><li>  </li></ul><ul><li>Baypointe# show ip route </li></ul><ul><li>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP </li></ul><ul><li>D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area </li></ul><ul><li>N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 </li></ul><ul><li>E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP </li></ul><ul><li>i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default </li></ul><ul><li>U - per-user static route, o - ODR </li></ul><ul><li>  </li></ul><ul><li>Gateway of last resort is not set </li></ul><ul><li>  </li></ul><ul><li>S 172.30.0.0/16 is directly connected, Serial0 </li></ul><ul><li>192.168.4.0/30 is subnetted, 1 subnets </li></ul><ul><li>C 192.168.4.8 is directly connected, Serial0 </li></ul><ul><li>C 192.168.5.0/24 is directly connected, Ethernet0 </li></ul><ul><li>Reflections </li></ul><ul><li>Notice that RIP is not being used on Baypointe. The only routes that are not directly-connected is the static route. </li></ul>
  118. 118. <ul><li>show ip protocols command </li></ul><ul><li>   </li></ul><ul><li>SanJose2 router from Scenario 3. </li></ul><ul><li>  </li></ul><ul><li>SanJose2# show ip protocols </li></ul><ul><li>Routing Protocol is &quot; rip &quot; </li></ul><ul><li>Sending updates every 30 seconds , next due in 11 seconds </li></ul><ul><li>Invalid after 180 seconds, hold down 180, flushed after 240 </li></ul><ul><li>Outgoing update filter list for all interfaces is </li></ul><ul><li>Incoming update filter list for all interfaces is </li></ul><ul><li>Redistributing: rip </li></ul><ul><li>Default version control: send version 1 , receive any version </li></ul><ul><li>Interface Send Recv Key-chain </li></ul><ul><li>Ethernet0 1 1 2 </li></ul><ul><li>Serial0 1 1 2 </li></ul><ul><li>Routing for Networks: </li></ul><ul><li>172.30.0.0 </li></ul><ul><li>Routing Information Sources: </li></ul><ul><li>Gateway Distance Last Update </li></ul><ul><li>172.30.2.2 120 00:00:04 </li></ul><ul><li>Distance: (default is 120) </li></ul><ul><li>SanJose2# </li></ul><ul><li>   </li></ul><ul><li>Be sure to understand this command. We will examine it again when we take a closer look at RIPv1, RIPv2 and IGRP. Take a look at the items in bold and make sure you understand them. </li></ul>Scenario 3: Running RIPv1 on a stub network
  119. 119. <ul><li>A Few Final Notes </li></ul><ul><li>  </li></ul><ul><li>  RIP uses broadcasts </li></ul><ul><li>Notice that RIPv1 sends out its RIP updates via an IP broadcast. </li></ul><ul><li>02:07:23: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.1.1) </li></ul><ul><li>All devices on the segment will see these RIP updates. </li></ul><ul><li>   </li></ul><ul><li>The passive-interface command </li></ul><ul><li>How can you keep a RIP update from being sent out an interface which does not have any other routers? (i.e The Ethernet interfaces in our network.) </li></ul><ul><li>Because the network statement includes all interfaces which have an IP address on that classful network, by default RIP will send out updates out each one of those interfaces. </li></ul><ul><li>Do keep RIP from sending updates out an interface which does not have any other routers, you can use the passive-interface command. </li></ul><ul><li>The passive-interface command allows the interface to receive RIP updates on the interface, but does not send RIP updates out that interface. </li></ul><ul><li>For example, to keep SanJose2 from sending out RIP updates out Ethernet 0, you can do the following: </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 172.30.0.0 </li></ul><ul><li>SanJose2(config-router)# passive-interface Ethernet 0 </li></ul>
  120. 120. <ul><li>What is with the /30 network? </li></ul><ul><li>/30 or 255.255.255.252 subnet masks are quite common on serial links. </li></ul><ul><li>A /30 subnet mask helps maximize the hosts addresses, which is perfect for a point-to-point serial link, allowing the following for each subnet: </li></ul><ul><ul><li>1 network address </li></ul></ul><ul><ul><li>2 host addresses </li></ul></ul><ul><ul><li>1 broadcast address  </li></ul></ul><ul><li>IP Class: C IP Address: 192.168.4.0 </li></ul><ul><li>Mask Bits: 6 Subnet Mask: 255.255.255.252 </li></ul><ul><li>Subnets: 62+1 IP Major Net: 192.168.4.0 </li></ul><ul><li>Hosts/Subnet: 2 Major Net Bcast: 192.168.4.255  </li></ul><ul><li>Subnets for Fixed Length Subnet Masking </li></ul><ul><li>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . </li></ul><ul><li>No. Subnet Hosts Hosts Broadcast Address From To Address  </li></ul><ul><li>0 192.168.4.0 192.168.4.1 192.168.4.2 192.168.4.3 </li></ul><ul><li>1 192.168.4.4 192.168.4.5 192.168.4.6 192.168.4.7 </li></ul><ul><li>2 192.168.4.8 192.168.4.9 192.168.4.10 192.168.4.11 </li></ul><ul><li>3 192.168.4.12 192.168.4.13 192.168.4.14 192.168.4.15 </li></ul><ul><li>4 192.168.4.16 192.168.4.17 192.168.4.18 192.168.4.19 </li></ul><ul><li>5 192.168.4.20 192.168.4.21 192.168.4.22 192.168.4.23 </li></ul><ul><li>6 192.168.4.24 192.168.4.25 192.168.4.26 192.168.4.27 </li></ul><ul><li>7 192.168.4.28 192.168.4.29 192.168.4.30 192.168.4.31 </li></ul><ul><li>8 192.168.4.32 192.168.4.33 192.168.4.34 192.168.4.35 </li></ul><ul><li>9 192.168.4.36 192.168.4.37 192.168.4.38 192.168.4.39 </li></ul><ul><li><omitted> </li></ul><ul><li>61 192.168.4.244 192.168.4.245 192.168.4.246 192.168.4.247 </li></ul><ul><li>62 192.168.4.248 192.168.4.249 192.168.4.250 192.168.4.251 </li></ul><ul><li>63 192.168.4.252 192.168.4.253 192.168.4.254 192.168.4.255   </li></ul>
  121. 121. <ul><li>How can I remove a single network from RIP? </li></ul><ul><li>  </li></ul><ul><li>Instead of using the following command to remove all networks from RIP: </li></ul><ul><li>Router(config)# no router rip </li></ul><ul><li>  </li></ul><ul><li>You can specify just the network you wish to remove by using the no network command, for example: </li></ul><ul><li>Router(config)# router rip </li></ul><ul><li>Router(config-router)# no network 172.30.0.0 </li></ul><ul><li>   </li></ul><ul><li>Debug ip routing - FYI </li></ul><ul><li>  </li></ul><ul><li>         If you wish to see what is happening in the router’s routing table process, you can use the debug ip routing command:   </li></ul><ul><li>SanJose2# debug ip routing </li></ul><ul><li>IP routing debugging is on </li></ul><ul><li>SanJose2#conf t </li></ul><ul><li>Enter configuration commands, one per line. End with CNTL/Z. </li></ul><ul><li>SanJose2(config)# router rip </li></ul><ul><li>SanJose2(config-router)# network 172.30.0.0 </li></ul><ul><li>SanJose2(config-router)# </li></ul><ul><li>00:15:03: RT: add 172.30.3.0/24 via 172.30.2.2, rip metric [120/1] </li></ul><ul><li>00:15:03: RT: add 0.0.0.0/0 via 172.30.2.2, rip metric [120/1] </li></ul><ul><li>00:15:03: RT: default path is now 0.0.0.0 via 172.30.2.2 </li></ul><ul><li>00:15:03: RT: new default network 0.0.0.0 </li></ul>
  122. 122. End of Part I <ul><li>End of Part I </li></ul><ul><li>See Part II for IGRP </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×