Você está na página 1de 122

Distance Vector Routing and RIP

Justinian Anatory

Overview

Describe how routing loops can occur in distance vector routing


Describe several methods used by distance vector routing protocols to ensure
that routing information is accurate
Configure RIP
Use the ip classless command
Troubleshoot RIP
Configure RIP for load balancing
Configure static routes for RIP
Verify RIP
Configure IGRP (Part II)
Verify IGRP operation (Part II)
Troubleshoot IGRP (Part II)

Department of Computer and systems Engineering

Distance Vector Routing Updates

Department of Computer and systems Engineering

Distance Vector Routing Updates

No! MTU is never


used as a routing
metric. Some
documentation is
incorrect on this
item.

RIP Hop Count


IGRP and EIGRP Bandwidth, Delay, Reliability, Load
Ciscos OSPF Bandwidth
IS-IS Cost
BGP Number of AS or policy

Department of Computer and systems Engineering

FAQs
FAQs Network Discovery
Q: How often does initial network discovery happen?
A: Only when the network comes first comes up.
Q: Do routers share routing table information after network discovery?
A: Yes, distance-vector routing protocols share their entire routing tables
periodically (with or without split horizon enabled). Distance vector routing
protocols on Cisco routers by default use split horizon with poison reverse
(discussed in the next section). Depending upon the distance-vector routing
protocol, the frequency of the updates will happen for RIP every 30 seconds,
IPX RIP every 60 seconds, and IGRP every 90 seconds.
Q: What happens when there is a change in the topology, link goes down, new
network is added, new router, is added, etc.?
A: Lets take a look.

Department of Computer and systems Engineering

Triggered Updates - Extra

Triggered Updates
Routers do not have to wait for the periodic update to hear about
changes in the network topology.
Improvements to the distance-vector algorithm is typically made in
distance-vector routing protocols, like RIP, to include triggered
updates.
Even with triggered updates, large distance vector networks can suffer
from long convergence times in some situations.
Department of Computer and systems Engineering

Triggered Updates

Triggered updates are sent whenever a router sees a topology change


or a change in routing information (from another router).
The router does not have to wait for the period timer, but can send
them immediately.
Triggered updates do not need to include the entire routing table but
only the modified route(s).
Triggered updates must still be sent to adjacent routers, from router to
router, like other routing updates.

Department of Computer and systems Engineering

Triggered Updates

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. (RIP: random 1 to 5 seconds)
Typically, triggered updates can be triggered by:
Interface transition to the up or down state
A route has entered or exited an unreachable (down) state (later)
A new route is installed in the routing table

Department of Computer and systems Engineering

Routing Loop Issues

Routing Loops
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.
Routing loops can cause major network problems, from packets getting lost (blackholed)
in your network, to bringing down your entire network.
Several remedies to have been added to distance-vector algorithms to help prevent
routing loops including:
Split horizon
Hold-down timers
Defining a maximum metric
Department of Computer and systems Engineering

Routing Loop Issues

What can cause routing loops?


Routing loops can occur when there are:
Incorrect or inconsistent routing updates due to slow convergence after a
topology change. (Example coming up next.)
Incorrect or incomplete routing information (see presentation on Discard
Routes)
Static routes incorrectly configured with an intermediate address which
does not become resolved in the routing table. (see presentation on Static
Routes Additional Information)
Department of Computer and systems Engineering

Routing Loop Issues

Routing Loop Example


Assume for the remainder of this example that Router Cs preferred path to
network 1 is by way of Router B.
Router Cs routing table has a distance of 3 to network 1 via Router B.

Department of Computer and systems Engineering

Routing Loop Issues

Network 1 Fails
Router E sends an update to Router A.
Router A stops routing packets to network 1.
But Routers B, C, and D continue to do so because they have not yet been
informed about the failure.
Router A sends out its update.
Routers B and D stop routing to network1, (via Router A).
However, Router C is still not updated.
To router C, network 1 is still reachable via router B.
Department of Computer and systems Engineering

Routing Loop Issues

Router C sends a periodic update to Router D


Router C sends a periodic update to Router D indicating a path to network 1
(by way) of via Router B. (4 hops).
Router Ds Routing Table information for Network 1
Current path to Network 1 = Unreachable (down)
Information from Router C: Network 1 : 4 hops by way of Router C
Normally, RouterD ignores this routing information because it usually has a
better route, 2 hops, via Router A, but this route is now down.
Router D changes its routing table to reflect this (good) better, but incorrect
information, Network 1 by way of Router C (4 hops)
Router D propagates the information to Router A.
Department of Computer and systems Engineering

Routing Loop Issues

Routers A changes its routing table


Router A adds new route to its routing table, get to Network 1 by way of Router
D (5 hops).
Propagates the information to Routers B and E.
Router B (and Router E) change their routing tables
Router B now believes it can get to Network 1 by way of Router A (6 hops).
Wow! I was about to tell Router C that Network 1 was down via Router B, but
now I have new information!
Propagates the incorrect information to Router C.
Department of Computer and systems Engineering

Routing Loop Issues

Router C changes its routing table


Router C still believes it can get to Network 1 by way of Router B (7 hops).
Of course now it believes it is 7 hops instead of 3.
Propagates the newer but still incorrect information to Router D.
Here we go again!
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.
As routing updates continue between the routers, the hop count gets greater
to infinity? (Not quite we will see in a moment.)
Department of Computer and systems Engineering

Defining a Maximum

Problem: Count to infinity


Solution: Defining a Maximum
Distance vector routing algorithms are self-correcting, but a routing loop
problem can require a count to infinity.
To avoid this prolonged problem, distance vector protocols define infinity as a
specific maximum number.
This number refers to a routing metric which may simply be the hop count.
When the metric value exceeds the maximum value, and as each router
receives this maximum metric, the network is then considered unreachable.
Department of Computer and systems Engineering

Why only a 15 hop count limit?


Question: Why does RIP use a hop count as the route metric, and why is its
maximum value limited to 15?
Answer: When RIP was designed and implemented, dynamic routing protocols
were not widely used. Instead, networks relied mostly on static routing. RIP,
even with its hop-count-metric which seems very poor to us today was
quite a big improvement. Counting intermediate routes is the simplest method
to measure the quality of routes. Setting the infinity value for the metric is
always a problem of choosing between wider networks and faster convergence
when the protocol starts counting. When RIP was invented, it seemed unlikely
to have a network with the maximum diameter more more than 15 routers, so
16 was chosen as the infinity value.

Department of Computer and systems Engineering

10

Split Horizon

The effect of split horizon is that a router will send out different routing
messages on different interfaces. In effect a router never sends out
information on an interface that it learned from that interface.

Department of Computer and systems Engineering

11

Split Horizon

Split-horizon attempts to avoid this situation. If a routing update about


Network 1 arrives from Router A, Router B or Router D cannot send
information about Network 1 back to Router A. Split-horizon thus
reduces incorrect routing information and reduces routing overhead.
Initially, this is true, but the loop is a result of Router C sending out the
updates, because it has not converged.

Department of Computer and systems Engineering

12

Simple Split Horizon


10.1.1.0/24
.1
e0

RTA

10.1.2.0/24
.1

.2

s0

s0

RTB

10.1.3.0/24
.1
e0

Routing Table

Routing Table

Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0

Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0

Initial
routing
tables

Split Horizon Rule Avoiding Routing Loops


Routers RTA and RTB have their initial routing tables and are ready to
exchange routing information via a distance-vector routing protocol
like RIP.
Split Horizon disabled
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.
Department of Computer and systems Engineering

13

10.1.1.0/24
.1

10.1.2.0/24

RTA
.1

.2

s0

s0

e0

RTB

10.1.3.0/24
.1
e0

Routing Table

Routing Table

Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0

Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1
10.1.2.0/24 1 10.1.1.1

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Routing Update
Next-hop
Net.
Hops Address
10.1.2.0/24 1 10.1.2.2
10.1.3.0/24 1 10.1.2.2

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

Initial
routing
tables
10.1.2.0/24
network is
included because
split horizon has
been disabled

New
routing
tables

Split Horizon Disabled


After the initial exchange of updates everything in the routing tables
look fine.
Because split horizon disabled, the 10.1.2.0/24 network is sent by both
routers, but neither router includes the others 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.
Department of Computer and systems Engineering

14

10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1
10.1.2.0/24 1 10.1.1.1
10.1.3.0/24 2 10.1.1.1

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Previous
routing
tables
Networks in red
were included
because split
horizon has been
disabled

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 2
10.1.2.1
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Split Horizon Disabled 10.1.3.0/24 down


Note: Routing tables are not sent at the exactly same time. We will
learn about this in Routing Protocols, that this is done on purpose to
avoid collisions on broadcast networks like Ethernet.
Here, the 10.1.3.0/24 network fails, and before RTB sends out its
routing update, RTB receives a routing update from RTA.
Department of Computer and systems Engineering

15

10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1
10.1.2.0/24 1 10.1.1.1
10.1.3.0/24 2 10.1.1.1

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Previous
routing
tables
Networks in red
were included
because split
horizon has been
disabled

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 2
10.1.2.1
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Split Horizon Disabled 10.1.3.0/24 down


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.
RTB now forwards all packets destined for 10.1.3.0/24 to RTA at 10.1.2.1.
RTA receives these packets and forwards them to RTB at 10.1.2.2.
RTB forwards them back to RTA at 10.1.2.1.
Department
And so
on! The
packets
get blackholed in this routing loop.
of Computer
and systems
Engineering

16

10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 2
10.1.2.1
10.1.1.0/24 1
10.1.2.1

Routing Update
Next-hop
Net.
Hops Address
10.1.2.0/24 1 10.1.2.2
10.1.3.0/24 3 10.1.2.2
10.1.1.0/24 2 10.1.2.2

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 3
10.1.2.2

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 2
10.1.2.1
10.1.1.0/24 1
10.1.2.1

Previous
routing
tables
Networks in red
were included
because split
horizon has been
disabled

New
routing
tables

Split Horizon Disabled 10.1.3.0/24 down


Meanwhile, its RTBs turn to send its routing update.
RTB increments the hop count to 10.1.3.0/24 to 3 hops and sends it to
RTA.
When RTA sends out its next routing table it will increment the hop
count to 10.1.3.0/24 to 4 hops and sends it to RTB.
Department
Andofon
and on, until infinity which in RIP is 16 hops.
Computer and systems Engineering
17

Simple Split Horizon


10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 16 10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 16 10.1.2.1
10.1.1.0/24 1
10.1.2.1

Split Horizon Disabled


Once both routers have 16 hops for 10.1.3.0/24, they will both mark
this network as unreachable and discontinue forwarding, drop, packets
to this network.
This temporary routing loop can be easily avoided by enabling split
horizon on the serial 0 interfaces.
Split horizon rule states that router never sends out information on an
interface that it learned from that interface
Lets see!
Department of Computer and systems Engineering

18

10.1.1.0/24
.1

Split
Horizon
Enabled

10.1.2.0/24

RTA
.1

.2

s0

s0

e0

RTB

10.1.3.0/24
.1
e0

Routing Table

Routing Table

Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0

Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1

Department of Computer and systems Engineering

Previous
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1 10.1.2.2

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1 10.1.2.2

19

10.1.1.0/24
.1

RTA

10.1.2.0/24
.1

.2

s0

s0

e0

RTB

10.1.3.0/24
.1
e0

Routing Table

Routing Table

Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0

Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1 10.1.1.1

Previous
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1 10.1.2.2

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1 10.1.2.2

Split Horizon Enabled


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.
Department of Computer and systems Engineering

20

10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops
Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 (down) e0
10.1.1.0/24 1
10.1.2.1

Previous
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 16 10.1.2.2

Routing Table
Net.
Hops
Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 (down) 10.1.2.2

Routing Table
Net.
Hops
Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 (down) e0
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Split Horizon Enabled 10.1.3.0/24 down


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)
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.
RTA receives the triggered update and puts the route for 10.1.3.0/24 into
hold-down state.
Department of Computer and systems Engineering

21

10.1.1.0/24
.1

RTA

e0

10.1.2.0/24
.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

RTB

10.1.3.0/24
.1
e0

Routing Table
Net.
Hops
Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 (down) e0
10.1.1.0/24 1
10.1.2.1

Previous
routing
tables

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 16 10.1.2.2

Routing Table
Net.
Hops
Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 (down) 10.1.2.2

Routing Table
Net.
Hops
Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 (down) e0
10.1.1.0/24 1
10.1.2.1

New
routing
tables

Split Horizon Enabled 10.1.3.0/24 down


Notice that RTA never sends RTB a routing update for 10.1.3.0/24,
because split horizon is enabled on these interfaces.
Department of Computer and systems Engineering

22

Split Horizon with Poison Reverse


10.1.1.0/24
.1

RTA

e0

10.1.2.0/24

.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1
10.1.1.1
10.1.2.0/24 16 10.1.2.1
10.1.3.0/24 16 10.1.2.1

Split Horizon with Poison Reverse

RTB

10.1.3.0/24

.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1
10.1.2.2
10.1.2.0/24 16 10.1.2.2
10.1.1.0/24 16 10.1.2.2

Poisoned
routes in red.
Routing tables
remain the
same.

Many vendor implementations of distance vector routing protocols like Ciscos RIP and
IGRP apply a special kind of split horizon, called split horizon with poison reverse.
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)
One drawback is that routing update packet sizes will be increased when using Poison
Reverse, since they now include these routes.
Department of Computer and systems Engineering

23

Split Horizon with Poison Reverse


10.1.1.0/24
.1

RTA

e0

10.1.2.0/24

.1

.2

s0

s0

Routing Table
Net.
Hops Ex-Int
10.1.1.0/24 0
e0
10.1.2.0/24 0
s0
10.1.3.0/24 1
10.1.2.2

Routing Update
Next-hop
Net.
Hops Address
10.1.1.0/24 1
10.1.1.1
10.1.2.0/24 16 10.1.2.1
10.1.3.0/24 16 10.1.2.1

RTB

10.1.3.0/24

.1
e0

Routing Table
Net.
Hops Ex-Int
10.1.2.0/24 0
s0
10.1.3.0/24 0
e0
10.1.1.0/24 1
10.1.2.1

Routing Update
Next-hop
Net.
Hops Address
10.1.3.0/24 1
10.1.2.2
10.1.2.0/24 16 10.1.2.2
10.1.1.0/24 16 10.1.2.2

Poisoned
routes in red.

Split Horizon Enabled by Default


Split horizon with poison reverse is enabled by default for all interfaces except:
Physical interfaces or multipoint sub-interfaces using Frame Relay or SMDS
encapsulation
To disable split horizon on an interface:
Router(config-if)# no ip split-horizon
To enable split horizon on an interface:
Router(config-if)# ip split-horizon
Department of Computer and systems Engineering

24

Route poisoning

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.

Department of Computer and systems Engineering

25

Preventing routing loops with holddown


timers

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).
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)
The amount of time a router remains in this state is determined by the
holddown timer.

Department of Computer and systems Engineering

26

Preventing routing loops with holddown


timers

Curriculum
A count to infinity problem can be avoided by using holddown timers.
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.

Department of Computer and systems Engineering

27

Preventing routing loops with holddown


timers

Same Route from same neighbor: Network is back up (Correct News)

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 holddown timer.

Department of Computer and systems Engineering

28

Preventing routing loops with holddown


timers

Better Route from different neighbor (Correct News)

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.

Department of Computer and systems Engineering

29

Preventing routing loops with holddown


timers

Poorer Route from a different neighbor. (Incorrect News)

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.
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.

Department of Computer and systems Engineering

30

Preventing routing loops with holddown


timers

Additional Information on Holddown Timers


Flapping routes
Holddown timers not only help prevent routing loops during transient periods
but also help network stability by dampening unstable, flapping routes (routes
which continuously go up and down).
Holddown Time
As we will see with both RIP and IGRP, the amount of time the router remains
in the holddown state can be modified (with caution!), even set to 0.
Department
We will
look at this later in the presentations on RIP and IGRP.
of Computer and systems Engineering

31

Preventing routing loops with holddown


timers

Additional Information on Holddown Timers

Packet forwarding
Even though routing tables remain constant and routers do not accept
potentially bad updates, an interesting question is whether or not routers
should continue use the existing routes that are in holddown state for
forwarding packets?
In practice, routes in the holddown state are used for packet forwarding. In
the worst case, packets are forwarded toward the router that was previously
connected to the destination network, which drops them. In the best case, they
are forwarded along a potentially suboptimal but valid path. (Zinin, Cisco IP
Routing)
Department of Computer and systems Engineering

32

Avoiding routing loops with triggered


updates

Triggered update is sent immediately in response to some change in


the routing table.
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.
When a route fails, an update is sent immediately rather than waiting on
the update timer to expire.
Triggered updates, used in conjunction with route poisoning, ensure
that all routers know of failed routes before any holddown timers can
expire.
Department of Computer and systems Engineering
33

IPs TTL Time To Live field


IP Header
0
4-bit
Version

15 16
4-bit
Header
Length

8-bit Type Of
Service
(TOS)

16-bit Total Length (in bytes)


3-bit
Flags

16-bit Identification
8 bit Time To Live
TTL

31

8-bit Protocol

13-bit Fragment Offset


16-bit Header Checksum

32-bit Source IP Address


32-bit Destination IP Address
Options (if any)
Data

Lets look at a related item in IP, the TTL field.


Department of Computer and systems Engineering

IPs TTL Time To Live field


IP Header
0
4-bit
Version

15 16
4-bit
Header
Length

8-bit Type Of
Service
(TOS)

16-bit Total Length (in bytes)


3-bit
Flags

16-bit Identification
8 bit Time To Live
TTL

31

8-bit Protocol

13-bit Fragment Offset


16-bit Header Checksum

32-bit Source IP Address


32-bit Destination IP Address
Options (if any)
Data

When a packet is first generated a value is entered into the TTL field.
Originally, the TTL field was the number of seconds, but this was difficult to implement
and rarely supported.
Now, the TTL is now set to a specific value which is then decremented by each router.
Department of Computer and systems Engineering

IPs TTL Time To Live field


IP Header
0
4-bit
Version

15 16
4-bit
Header
Length

8-bit Type Of
Service
(TOS)

16-bit Total Length (in bytes)


3-bit
Flags

16-bit Identification
8 bit Time To Live
TTL

31

8-bit Protocol

13-bit Fragment Offset


16-bit Header Checksum

32-bit Source IP Address

Decrement by 1, if 0 drop the


packet.

32-bit Destination IP Address


Options (if any)

If the router decrements the TTL field to 0, it will then drop the packet (unless the packet
is destined specifically for the router,Data
I.e. ping, telnet, etc.).
Common operating system TTL values are:
UNIX: 255
Linux: 64 or 255 depending upon vendor and version
Microsoft Windows 95: 32
Other Microsoft Windows operating systems: 128

Department of Computer and systems Engineering

http://www.switch.ch/docs/ttl_default.html
TTL Overview - Disclaimer:
The following list is a best effort overview of some widely used TCP/IP stacks. The
information was provided by vendors and many helpful system administrators. We would
like to thank all these contributors for their precious help ! SWITCH cannot, however,
take any responsibility that the provided information is correct. Furthermore, SWITCH
cannot be made liable for any damage that may arise by the use of this information.
+--------------------+-------+---------+---------+
| OS Version
|"safe" | tcp_ttl | udp_ttl |
+--------------------+-------+---------+---------+
AIX
n
60
30
DEC Pathworks V5
n
30
30
FreeBSD 2.1R
y
64
64
HP/UX
9.0x
n
30
30
HP/UX
10.01
y
64
64
Irix 5.3
y
60
60
Irix 6.x
y
60
60
Linux
y
64
64
MacOS/MacTCP 2.0.x
y
60
60
OS/2 TCP/IP 3.0
y
64
64
OSF/1 V3.2A
n
60
30
Solaris 2.x
y
255
255
SunOS 4.1.3/4.1.4
y
60
60
Ultrix V4.1/V4.2A
n
60
30
VMS/Multinet
y
64
64
VMS/TCPware
y
60
64
VMS/Wollongong 1.1.1.1
n
128
30
VMS/UCX (latest rel.)
y
128
128
MS WfW
n
32
32
MS Windows 95
n
32
32
MS Windows NT 3.51
n
32
32
MS Windows NT 4.0
y
128
128
Department of Computer and systems Engineering

Assigned Numbers (RFC


1700, J. Reynolds, J.
Postel, October 1994):
IP TIME TO LIVE
PARAMETER
The current
recommended default
time to live (TTL)
for the Internet
Protocol (IP) is 64.

Safe: TCP and UDP


initial TTL values
should be set to a
"safe" value of at
least 60 today.
5

IPs TTL Time To Live field


IP Header
0
4-bit
Version

15 16
4-bit
Header
Length

8-bit Type Of
Service
(TOS)

16-bit Total Length (in bytes)


3-bit
Flags

16-bit Identification
8 bit Time To Live
TTL

31

8-bit Protocol

13-bit Fragment Offset


16-bit Header Checksum

32-bit Source IP Address

Decrement by 1, if 0 drop the


packet.

32-bit Destination IP Address


Options (if any)
Data

The idea behind the TTL field is that IP packets can not travel around the
Internet forever, from router to router.
Eventually, the packets TTL which reach 0 and be dropped by the router, even
if there is a routing loop somewhere in the network.

Department of Computer and systems Engineering

RIP routing process

Request for Comments (RFC) 1058


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:
Ability to carry additional packet routing information.
Authentication mechanism to secure table updates.
Supports variable length subnet masking (VLSM).

Department of Computer and systems Engineering

Configuring RIP

Department of Computer and systems Engineering

Configuring RIP

RIP and IGRP:


Classful network statements only
IOS will take subnetted networks but will translate it into
the classful network for the running-config.
Department of Computer and systems Engineering

Triggered Extensions

A router running RIP can be configured to send a triggered update


when the network topology changes using the ip rip triggered
command. This command is issued only on serial interfaces at the
router(config-if)# prompt. After updating its routing table due to
a configuration change, the router immediately begins transmitting
routing updates in order to inform other network routers of the change.
These updates, called triggered updates, are sent independently of the
regularly scheduled updates that RIP routers forward.

Department of Computer and systems Engineering

10

Triggered Extensions
interface serial 0
ip rip triggered

Triggered Extensions to RIP


There were two problems using RIP to connect to a WAN:
Periodic broadcasting by RIP generally prevented WAN circuits from being
closed.
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.
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.
Periodic update packets are suppressed over the interface on which this
feature is enabled.
Department of Computer and systems Engineering

11

Triggered Extensions
interface serial 0
ip rip triggered

RFC 2091, Triggered Extensions to RIP to Support Demand Circuits.


When triggered extensions to RIP are enabled, routing updates are transmitted
on the WAN only if one of the following occurs:
The router receives a specific request for a routing update. (Full database is
sent.)
Information from another interface modifies the routing database. (Only
latest changes are sent)
The interface comes up or goes down. (Partial database is sent.)
The router is first powered on, to ensure that at least one update is sent.
(Full database is sent.)
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.
Department of Computer and systems Engineering

12

The RIPv1 Protocol


Data Link
Frame
Header

IP Packet
Header

UDP
Segment
Header

RIP
Message

RIP Message
Data Link Frame

MAC Source Address

MAC Destination Address = Broadcast


IP Packet

IP Source Address

IP Destination Address = Broadcast: 255.255.255.255

Protocol field = 17 for UDP


UDP Segment

Source Port number field = 520 for RIP Message


RIP Message (Data portion of IP Packet):

Routes: Network IP Address

Hops (metric)
Department of Computer and systems Engineering

13

Data Link
Frame
Header

IP Packet
Header

UDP
Segment
Header

RIP
Message

0
7 8
15 16
23 24
Command = 1 or 2
Version = 1
Must be zero
Address family identifier (2 = IP)
Must be zero
IP Address (Network Address)
Must be zero
Must be zero
Metric (Hops)

31

Multiple Routes, up to a maximum of 25


Address family identifier (2 = IP)
Must be zero
IP Address (Network Address)
Must be zero
Must be zero
Metric (Hops)

Command: 1 signifying a Request or 2 signifying a Reply


Version: 1 for RIP v 1 or 2 for RIP v 2
Address Family Identifier: 2 signifying IP (only exception is for a Request for the Routers full routing
table, later Semester in RIP v 2)
IP Address: The address of the destination route, which may be a network address, a subnet address
of a host address.
Metric: Hop count between 1 and 16. Note: With RIP the sending router increases the metric before
sending out the RIP message.
Note: The routing table knows the next-hop-ip-address (via) from the source IP address of the packet.

Department of Computer and systems Engineering

14

RIP v2 message format

All the extensions to the original protocol are carried in the unused
fields.
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.

Department of Computer and systems Engineering

15

RIP v2 message format

The Route Tag field provides a way to differentiate between internal and
external routes.
External routes are those that have been redistributed into the RIP v2.
The Next Hop field contains the IP address of the next hop listed in the IP
Address field.
Metric indicates how many internetwork hops, between 1 and 15 for a valid
route, or 16 for an unreachable route.

Department of Computer and systems Engineering

16

Configuring RIP

RIP must be enabled and the networks specified. The remaining tasks are
optional. Among these optional tasks are:
Applying offsets to routing metrics (Not commonly used)
Adjusting timers
Specifying a RIP version (RIPv1 or RIPv2)
Enabling RIP authentication
Configuring route summarization on an interface
Verifying IP route summarization
Disabling automatic route summarization (RIPv2)
Running IGRP and RIP concurrently (Usually, redistributing, not concurrently.)
Disabling the validation of source IP addresses
Enabling or disabling split horizon
Connecting RIP to a WAN
Department of Computer and systems Engineering

17

ip classless command

IP classless only affects the operation of the forwarding


processes in IOS. IP classless does not affect the way the
routing table is built.

This command concerns classless and classful routing


behavior, which is not the same as classless and classful
routing protocols (later).

Department of Computer and systems Engineering

Parent and Child Routes


RouterB#show ip route

R
C
C
C
S
S
S*

172.16.0.0/24 is subnetted, 3 subnets


172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0
172.16.2.0 is directly connected, Serial0
172.16.3.0 is directly connected, FastEthernet0
192.168.1.0/24 is directly connected, Serial1
172.0.0.0/8 is directly connected, Serial1
160.0.0.0/4 is directly connected, Serial1
0.0.0.0/0 is directly connected, Serial1

Parent Route
Created automatically whenever there is a route with a mask greater
than the classful mask.
For non-VLSM routes, contains the mask of the child routes.
Child Routes
Routes with masks greater than the default classful mask.
Department of Computer and systems Engineering

Lookup what?
RouterB#show ip route

R
C
C
C
S
S
S*

172.16.0.0/24 is subnetted, 3 subnets


172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0
172.16.2.0 is directly connected, Serial0
172.16.3.0 is directly connected, FastEthernet0
192.168.1.0/24 is directly connected, Serial1
172.0.0.0/8 is directly connected, Serial1
160.0.0.0/4 is directly connected, Serial1
0.0.0.0/0 is directly connected, Serial1

Routing Table process matches:


The routing table process compares the left-most bits in the packets
destination IP address with the left-most bits in the route in the routing table,
looking for a longest-bit-match.
The subnet mask of the route in the routing table specifies the minimum
number of left-most bits that must match.
Before checking child routes, the classful mask of the parent route is used.
For child routes the parent routes mask is used.
For VLSM routes, the mask is contained with the child route.
Department of Computer and systems Engineering

Classful Routing Behavior


RouterB#show ip route

R
C
C
C
S
S
S*

172.16.0.0/24 is subnetted, 3 subnets


172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0
172.16.2.0 is directly connected, Serial0
172.16.3.0 is directly connected, FastEthernet0
192.168.1.0/24 is directly connected, Serial1
172.0.0.0/8 is directly connected, Serial1
160.0.0.0/4 is directly connected, Serial1
0.0.0.0/0 is directly connected, Serial1

DA = 172.16.4.1
Router(config)# no ip classless
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 cant get out!)
Supernet and default routes are not checked.
Default with IOS 11.2 and prior
Department of Computer and systems Engineering

Classless Routing Behavior


RouterB#show ip route

R
C
C
C
S
S
S*

172.16.0.0/24 is subnetted, 3 subnets


172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial0
172.16.2.0 is directly connected, Serial0
172.16.3.0 is directly connected, FastEthernet0
192.168.1.0/24 is directly connected, Serial1
172.0.0.0/8 is directly connected, Serial1
160.0.0.0/4 is directly connected, Serial1
0.0.0.0/0 is directly connected, Serial1

DA = 172.16.4.1
Router(config)# ip classless
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.
8 bits of 172.0.0.0/8 do match, so this route is used!
Default with IOS 11.3 and later
Department of Computer and systems Engineering

Common RIP Configuration Issues


Split Horizon
The following command is used to disable split horizon:
GAD(config-if)#no ip split-horizon

The following command is used to enable (default) split horizon:


GAD(config-if)#ip split-horizon

Department of Computer and systems Engineering

23

Common RIP Configuration Issues


Holddown Timer
The ideal setting would be to set the timer just longer that the longest
possible update time for the internetwork.
To change the holddown timer:
Router(config-router)#timers basic update invalid
holddown flush [sleeptime]

Department of Computer and systems Engineering

24

Common RIP Configuration Issues


Update Timer
The default RIP update interval in IOS is 30 seconds. This can be
configured for longer intervals to conserve bandwidth, or for shorter
intervals to decrease convergence time.
To change the update internal:
GAD(config-router)#update-timer seconds

Department of Computer and systems Engineering

25

Common RIP Configuration Issues


router rip
passive-interface fastethernet 0/0

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.
Also used when there are no routers on that interface, such as stub
LANs.
Router(config-router)# passive-interface interface

Department of Computer and systems Engineering

26

Common RIP Configuration Issues

Because RIP is a broadcast protocol, the network administrator may


have to configure RIP to exchange routing information in a nonbroadcast network such as Frame Relay.
In this type of network, RIP needs to be told of other neighboring RIP
routers.
To do this use the router rip command:
Router(config-router)# neighbor ip address

Department of Computer and systems Engineering

27

Common RIP Configuration Issues

By default, the IOS software receives RIP Version 1 and Version 2


packets, but sends only Version 1 packets.
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.

Department of Computer and systems Engineering

28

Compatibility with RIP v1


NewYork
interface fastethernet0/0
ip address 192.168.50.129 255.255.255.192
ip rip send version 1
ip rip receive version 1
RIPv2

interface fastethernet0/1
ip address 172.25.150.193 255.255.255.240
ip rip send version 1 2

Interface FastEthernet0/0 is
configured to send and receive
RIP v1 updates.
FastEthernet0/1 is configured
to send both version 1 and 2
updates.
FastEthernet0/2 has no special
configuration and therefore
sends and receives version 2
by default.

Department of Computer and systems Engineering

interface fastethernet0/2
ip address 172.25.150.225 225.255.255.240
router rip
version 2
network 172.25.0.0
network 192.168.50.0

29

Verifying RIP configuration

Department of Computer and systems Engineering

30

Verifying RIP configuration

Also: show running-config

Department of Computer and systems Engineering

31

Troubleshooting RIP update issues

Department of Computer and systems Engineering

32

Troubleshooting RIP update issues


Other commands to troubleshoot RIP:
show ip rip database
show ip protocols {summary}
show ip route
debug ip rip {events}
show ip interface brief

Department of Computer and systems Engineering

33

Load balancing with RIP

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.
This means that RIP takes turns forwarding packets over the parallel
paths.
This is only part of the story

Department of Computer and systems Engineering

34

Fast Switching and Process Switching


The following information is taken from Routing TCP/IP Volume I by Jeff Doyle.

Load sharing or Load balancing allows routers to take advantage of


multiple paths to the same destination.
Equal-cost load balancing:
Distributes packets equally among multiple paths with equal metrics
RIP, IGRP, EIGRP, OSPF, IS-IS and BGP
Unequal-cost load balancing:
Distributes packets among multiple paths with different metrics,
inversely proportional to the cost of the routes.
EIGRP
Load sharing can be either:
Per Destination (Fast Switching)
Per Packet ( Process Switching)

Department of Computer and systems Engineering

35

Fast Switching
Per Destination Load Balancing
Router(config-if)# ip route-cache
ping 10.0.0.2

ping 10.0.0.1

The default for most interfaces is Fast Switching.


Load balancing is distributed according to the destination IP address.
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.
To enable fast switching:
Router(config-if)# ip route-cache
To enable distributed or process switching:
Router(config-if)# no ip route-cache

Department of Computer and systems Engineering

36

Fast Switching
Per Destination Load Balancing
Router(config-if)# ip route-cache
ping 10.0.0.2

ping 10.0.0.1

Fast Switching
1. Router switches first packet to a particular destination, a routing table lookup
is performed and an exit interface is selected.
2. The necessary data-link information to frame the packet for the selected
interface is retrieved including any ARP cache information.
3. The route and data-link information is stored in fast switching cache.
4. The router uses the cache to look up subsequent packets.
5. 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).
Department of Computer and systems Engineering

37

Process Switching
Per Packet Load Balancing
Router(config-if)#no ip route-cache
ping 10.0.0.2

ping 10.0.0.1

Process Switching
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.
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.
With process switching, for every packet, the router performs a route table
lookup and selects an interface, and looks up the data-link information.
To enable distributed or process switching:
Router(config-if)# no ip route-cache
Department of Computer and systems Engineering

38

Which one?
Fast Switching

ping 10.0.0.2

ping 10.0.0.1

Router(config-if)# ip route-cache

Process Switching

ping 10.0.0.2

ping 10.0.0.1

Router(config-if)#no ip route-cache

Fast Switching or Process Switching


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.
Department of Computer and systems Engineering

39

Using debug ip packet with


Fast Switching and Process Switching
Router# debug ip packet
IP: s=192.168.3.2 (FastEthernet0),
g=192.168.1.2, forward
IP: s=192.168.3.2 (FastEthernet0),
g=192.168.2.2, forward
IP: s=192.168.3.2 (FastEthernet0),
g=192.168.1.2, forward
IP: s=192.168.3.2 (FastEthernet0),
g=192.168.2.2, forward

d=10.0.0.1 (Serial0/0),
d=10.0.0.1 (Serial0/1),
d=10.0.0.1 (Serial0/0),
d=10.0.0.1 (Serial0/1),

debug ip packet can be used to observe packets sent


and received and the interfaces that are involved.
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).

Department of Computer and systems Engineering

40

Load balancing across multiple paths

By default, most IP routing protocols install a maximum of four parallel


routes in a routing table.
Static routes always install six routes.
The exception is BGP, which by default allows only one path to a
destination.
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:
Router(config-router)#maximum-paths [number]

Department of Computer and systems Engineering

41

RIP and Administrative Distance

Department of Computer and systems Engineering

42

RIP and Floating Static Routes

172.16.0.0/16

router rip
network 192.168.14.0
ip route 172.16.0.0 255.255.0.0 bri0/1 130

Floating static routes are static routes which are used as backup
routes.
They are only injected into the routing table when a route with a lower
administrative distance (dynamic or another static route) goes down.
Should the route with the lower administrative distance come back up
then the floating static route is removed from the routing table.

Department of Computer and systems Engineering

43

Redistribute Static
172.16.0.0/16

RIP

RouterA
ip route 172.16.0.0 255.255.0.0 eth 0
Router rip
redistribute static
network .

Redistributes static routes into the dynamic routing domain.


172.16.0.0/16 will be seen by other RIP routers as a
dynamic route learned via RIP.
The default metric is 0, so B and D will have a hop count of
1, where C will have a hop count of 2.

Department of Computer and systems Engineering

44

Scenario 1: Running RIPv1 on classful networks


SanJose2
hostname SanJose2
interface ethernet 0
ip add 192.168.1.1 255.255.255.0
interface serial 0
ip add 192.168.2.1 255.255.255.0
SanJose1
hostname SanJose1
interface ethernet 0
ip add 192.168.3.1 255.255.255.0
interface serial 0
ip add 192.168.2.2 255.255.255.0
interface serial 1
ip add 192.168.4.2 255.255.255.0
Baypointe
hostname Baypointe
interface ethernet 0
ip add 192.168.5.1 255.255.255.0
interface serial 0
ip add 192.168.4.1 255.255.255.0

Department of Computer and systems Engineering

45

Scenario 1: Running RIPv1 on classful networks


Objective: Running RIPv1 on classful networks
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.
Step 1 Configuring RIP
First, lets enable RIP on each router.
From global configuration you will enter the command (the default is RIPv1):
Router(config)#router rip
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.
Router(config-router)#network directly-connected-classful-networkaddress

Department of Computer and systems Engineering

46

Scenario 1: Running RIPv1 on classful networks


Here are the commands for each router:
SanJose2#configure terminal
Enter configuration commands, one per line.
SanJose2(config)#router rip
SanJose2(config-router)#network 192.168.1.0
SanJose2(config-router)#network 192.168.2.0

End with CNTL/Z.

Baypointe#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Baypointe(config)#router rip
Baypointe(config-router)#network 192.168.4.0
Baypointe(config-router)#network 192.168.5.0
SanJose1#configure terminal
Enter configuration commands, one per line.
SanJose1(config)#router rip
SanJose1(config-router)#network 192.168.2.0
SanJose1(config-router)#network 192.168.3.0
SanJose1(config-router)#network 192.168.4.0
Department of Computer and systems Engineering

End with CNTL/Z.

47

Step 2 Understanding the network command


SENDING RIP MESSAGES
Each router will begin to send RIP update message out each interface belonging to one of the network
statements.
SanJose2(config)#router rip
SanJose2(config-router)#network 192.168.1.0
SanJose2(config-router)#network 192.168.2.0
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.
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.
To view the RIP messages being sent and received use the debug ip rip command.
SanJose2# debug ip rip
RIP protocol debugging is on
SanJose2
01:03:27: RIP: sending v1 update to
01:03:27:
network 192.168.2.0,
01:03:27: RIP: sending v1 update to
01:03:27:
network 192.168.1.0,

Department of Computer and systems Engineering

255.255.255.255 via Ethernet0 (192.168.1.1)


metric 1
255.255.255.255 via Serial0 (192.168.2.1)
metric 1

48

Scenario 1: Running RIPv1 on classful networks


LISTENING FOR RIP MESSAGES
Routers will also listen for RIP messages on each interface belonging to one of the
network statements.
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.
As RIP messages are received router, will add those networks in the messages to
their routing tables:
If the RIP message contains a network not currently in the routing table.
If the RIP message contains a network with a better metric (fewer hops) than an
entry currently in the routing table.
SanJose2
01:10:56: RIP: received v1 update from 192.168.2.2 on Serial0
01:10:56:
192.168.4.0 in 1 hops
01:10:56:
192.168.3.0 in 1 hops
Department of Computer and systems Engineering

49

Scenario 1: Running RIPv1 on classful networks


Step 3 Viewing the debug ip rip output and the routing tables
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.
After convergence, each router will continue to send its RIP update
messages out the appropriate interfaces every 30 seconds.
Lets look at the debug messages and the routing table for each router:

Department of Computer and systems Engineering

50

SanJose2
01:30:45: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1)
01:30:45:
network 192.168.4.0, metric 2
01:30:45:
network 192.168.5.0, metric 3
01:30:45:
network 192.168.2.0, metric 1
01:30:45:
network 192.168.3.0, metric 2
01:30:45: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.2.1)
01:30:45:
network 192.168.1.0, metric 1
SanJose2#
01:30:50: RIP: received v1 update from 192.168.2.2 on Serial0
01:30:50:
192.168.4.0 in 1 hops
01:30:50:
192.168.5.0 in 2 hops
01:30:50:
192.168.3.0 in 1 hops
SanJose2#
SanJose2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
R
192.168.4.0/24
R
192.168.5.0/24
C
192.168.1.0/24
C
192.168.2.0/24
R
192.168.3.0/24
SanJose2#

[120/1] via
[120/2] via
is directly
is directly
[120/1] via

192.168.2.2, 00:00:10, Serial0


192.168.2.2, 00:00:10, Serial0
connected, Ethernet0
connected, Serial0
192.168.2.2, 00:00:10, Serial0

Department of Computer and systems Engineering

51

SanJose1
01:33:05:
01:33:05:
SanJose1#
01:33:07:
01:33:07:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:
01:33:08:

RIP: received v1 update from 192.168.4.1 on Serial1


192.168.5.0 in 1 hops
RIP: received v1 update from 192.168.2.1 on Serial0
192.168.1.0 in 1 hops
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.3.1)
network 192.168.4.0, metric 1
network 192.168.5.0, metric 2
network 192.168.1.0, metric 2
network 192.168.2.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.2.2)
network 192.168.4.0, metric 1
network 192.168.5.0, metric 2
network 192.168.3.0, metric 1
RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.2)
network 192.168.1.0, metric 2
network 192.168.2.0, metric 1
network 192.168.3.0, metric 1

SanJose1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
Gateway of last resort is not set
C
192.168.4.0/24 is directly connected, Serial1
R
192.168.5.0/24 [120/1] via 192.168.4.1, 00:00:12, Serial1
R
192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:10, Serial0
C
192.168.2.0/24 is directly connected, Serial0
C
192.168.3.0/24 is directly connected, Ethernet0
Department of Computer and systems Engineering

52

Baypointe
01:34:53: RIP:
01:34:53:
01:34:53:
01:34:53:
01:34:53:
01:34:53: RIP:
01:34:53:
Baypointe#
01:34:56: RIP:
01:34:56:
01:34:56:
01:34:56:

sending
network
network
network
network
sending
network

v1 update to
192.168.4.0,
192.168.1.0,
192.168.2.0,
192.168.3.0,
v1 update to
192.168.5.0,

received v1
192.168.1.0
192.168.2.0
192.168.3.0

255.255.255.255 via Ethernet0 (192.168.5.1)


metric 1
metric 3
metric 2
metric 2
255.255.255.255 via Serial0 (192.168.4.1)
metric 1

update from 192.168.4.2 on Serial0


in 2 hops
in 1 hops
in 1 hops

Baypointe#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C
C
R
R
R

192.168.4.0/24
192.168.5.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24

is directly
is directly
[120/2] via
[120/1] via
[120/1] via

connected, Serial0
connected, Ethernet0
192.168.4.2, 00:00:23, Serial0
192.168.4.2, 00:00:23, Serial0
192.168.4.2, 00:00:23, Serial0

Department of Computer and systems Engineering

53

Scenario 1: Running RIPv1 on classful networks


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).
Step 4 Turning-off debug
Dont forget to turn-off debug when you are done collecting the output.
Router# undebug all
or
Baypointe# undebug ip rip
Step 5 Reflections
For each router compare the RIP received messages with its routing table. Now you see
how the information is entered into the routing table.
Cisco IOS uses split horizon with poison reverse, however this information is not
displayed with debug ip rip command.
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.
Department of Computer and systems Engineering

54

Scenario 2: Running RIPv1 on subnets and between


classful networks
SanJose2
hostname SanJose2
interface ethernet 0
ip add 172.30.1.1 255.255.255.0
interface serial 0
ip add 172.30.2.1 255.255.255.0

SanJose1
hostname SanJose1
interface ethernet 0
ip add 172.30.3.1 255.255.255.0
interface serial 0
ip add 172.30.2.2 255.255.255.0
interface serial 1
ip add 192.168.4.9 255.255.255.252
Baypointe
hostname Baypointe
interface ethernet 0
ip add 192.168.5.1 255.255.255.0
interface serial 0
ip add 192.168.4.10 255.255.255.252

Department of Computer and systems Engineering

55

Scenario 2: Running RIPv1 on subnets and between


classful networks
Objective: Running RIPv1 on subnets and between classful networks
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.
Making changes between Scenario 1 and Scenario 2
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.
If you have just completed Scenario 1, lets remove RIP by issuing the following command
on each router:
Router(config)# no router rip

Department of Computer and systems Engineering

56

Scenario 2: Running RIPv1 on subnets and between


classful networks
Step 1 Configuring RIP
Once again, lets enable RIP on each router.
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.
Router(config-router)#network directly-connectedclassful-network-address

Department of Computer and systems Engineering

57

Here are the commands for each router:


SanJose2#configure terminal
Enter configuration commands, one per line.
SanJose2(config)#router rip
SanJose2(config-router)#network 172.30.0.0

End with CNTL/Z.

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.
SanJose1#configure terminal
Enter configuration commands, one per line.
SanJose1(config)#router rip
SanJose1(config-router)#network 172.30.0.0
SanJose1(config-router)#network 192.168.4.0

End with CNTL/Z.

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.
Baypointe#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Baypointe(config)#router rip
Baypointe(config-router)#network 192.168.4.0
Baypointe(config-router)#network 192.168.5.0

Department of Computer and systems Engineering

58

Scenario 2: Running RIPv1 on subnets and between


classful networks
Question: What would happen if you entered a network statement that
was a subnet? For example:
SanJose2(config)#router rip
SanJose2(config-router)#network 172.30.1.0
Answer: The IOS would automatically convert it to a classful network
statement:
SanJose2#show running-config
router rip
network 172.30.0.0

Department of Computer and systems Engineering

59

Step 2 Viewing the debug ip rip output and the routing tables
SanJose2
SanJose2# debug ip rip
00:14:10: RIP: received v1 update from 172.30.2.2 on Serial0
00:14:10:
172.30.3.0 in 1 hops
00:14:10:
192.168.4.0 in 1 hops
00:14:10:
192.168.5.0 in 2 hops
SanJose2#
00:14:29: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.1.1)
00:14:29:
subnet 172.30.2.0, metric 1
00:14:29:
subnet 172.30.3.0, metric 2
00:14:29:
network 192.168.4.0, metric 2
00:14:29:
network 192.168.5.0, metric 3
00:14:29: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.1)
00:14:29:
subnet 172.30.1.0, metric 1
SanJose2#
00:14:39: RIP: received v1 update from 172.30.2.2 on Serial0
00:14:39:
172.30.3.0 in 1 hops
00:14:39:
192.168.4.0 in 1 hops
00:14:39:
192.168.5.0 in 2 hops
SanJose2# undebug all
SanJose2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
Gateway of last resort is not set
172.30.0.0/24 is subnetted, 3 subnets
C
172.30.2.0 is directly connected, Serial0
R
172.30.3.0 [120/1] via 172.30.2.2, 00:00:08, Serial0
C
172.30.1.0 is directly connected, Ethernet0
R
192.168.4.0/24 [120/1] via 172.30.2.2, 00:00:08, Serial0
R
192.168.5.0/24 [120/2] via 172.30.2.2, 00:00:08, Serial0
Department of Computer and systems Engineering

60

Scenario 2: Running RIPv1 on subnets and between


classful networks
Reflections
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.
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?
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.
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.
Department of Computer and systems Engineering

61

SanJose1
SanJose1#debug ip rip
RIP protocol debugging is on
SanJose1#
00:17:52: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.3.1)
00:17:52:
subnet 172.30.2.0, metric 1
00:17:52:
subnet 172.30.1.0, metric 2
00:17:52:
network 192.168.4.0, metric 1
00:17:52:
network 192.168.5.0, metric 2
00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2)
00:17:52:
subnet 172.30.3.0, metric 1
00:17:52:
network 192.168.4.0, metric 1
00:17:52:
network 192.168.5.0, metric 2
00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.9)
00:17:52:
network 172.30.0.0, metric 1
SanJose1#
00:18:10: RIP: received v1 update from 172.30.2.1 on Serial0
00:18:10:
172.30.1.0 in 1 hops
SanJose1#
00:18:12: RIP: received v1 update from 192.168.4.10 on Serial1
00:18:12:
192.168.5.0 in 1 hops
SanJose1# undebug all
SanJose1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
Gateway of last resort is not set
172.30.0.0/24 is subnetted, 3 subnets
C
172.30.2.0 is directly connected, Serial0
C
172.30.3.0 is directly connected, Ethernet0
R
172.30.1.0 [120/1] via 172.30.2.1, 00:00:14, Serial0
192.168.4.0/30 is subnetted, 1 subnets
C
192.168.4.8 is directly connected, Serial1
R
192.168.5.0/24 [120/1] via 192.168.4.10, 00:00:10, Serial1
Department of Computer and systems Engineering

62

Scenario 2: Running RIPv1 on subnets and between


classful networks
Reflections
The same subnet route information applies with routes sent from
SanJose2 to SanJose1 (see Reflections for SanJose2).
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).

Department of Computer and systems Engineering

63

SanJose1#debug ip rip
RIP protocol debugging is on
SanJose1#
00:17:52: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.3.1)
00:17:52:
subnet 172.30.2.0, metric 1
00:17:52:
subnet 172.30.1.0, metric 2
00:17:52:
network 192.168.4.0, metric 1
00:17:52:
network 192.168.5.0, metric 2
00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2)
00:17:52:
subnet 172.30.3.0, metric 1
00:17:52:
network 192.168.4.0, metric 1
00:17:52:
network 192.168.5.0, metric 2
00:17:52: RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.9)
00:17:52:
network 172.30.0.0, metric 1
SanJose1#
00:18:10: RIP: received v1 update from 172.30.2.1 on Serial0
00:18:10:
172.30.1.0 in 1 hops
SanJose1#
00:18:12: RIP: received v1 update from 192.168.4.10 on Serial1
00:18:12:
192.168.5.0 in 1 hops
SanJose1# undebug all
SanJose1#show ip route
Codes: <omitted>
Gateway of last resort is not set
172.30.0.0/24 is subnetted, 3 subnets
C
172.30.2.0 is directly connected, Serial0
C
172.30.3.0 is directly connected, Ethernet0
R
172.30.1.0 [120/1] via 172.30.2.1, 00:00:14, Serial0
192.168.4.0/30 is subnetted, 1 subnets
C
192.168.4.8 is directly connected, Serial1
R
192.168.5.0/24 [120/1] via 192.168.4.10, 00:00:10, Serial1
Department of Computer and systems Engineering

64

Scenario 2: Running RIPv1 on subnets and between


classful networks
More Reflections
IMPORTANT INFORMATION: Notice the RIP update being sent out Serial 1:
RIP: sending v1 update to 255.255.255.255 via Serial1 (192.168.4.9)
network 172.30.0.0, metric 1

Compare that to the same information for the 172.30.0.0 network being sent out
Serial 0 & Ethernet 0:

RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2)


subnet 172.30.3.0, metric 1

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.
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.
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.

Department of Computer and systems Engineering

65

Scenario 2: Running RIPv1 on subnets and between


classful networks
More Reflections (continued)
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.
What do you expect to see in Baypointes received RIP messages and its
routing table? Thats right, only a single 172.30.0.0 network via SanJose1.
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.

Department of Computer and systems Engineering

66

Baypointe
Baypointe#debug ip rip
RIP protocol debugging is on
Baypointe#
00:20:09: RIP: received v1 update from 192.168.4.9 on Serial0
00:20:09:
172.30.0.0 in 1 hops
Baypointe#
00:20:24: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.5.1)
00:20:24:
network 172.30.0.0, metric 2
00:20:24:
network 192.168.4.0, metric 1
00:20:24: RIP: sending v1 update to 255.255.255.255 via Serial0 (192.168.4.10)
00:20:24:
network 192.168.5.0, metric 1
Baypointe#
Baypointe#undebug all
Baypointe#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
Gateway of last resort is not set
R
C
C

172.30.0.0/16 [120/1] via 192.168.4.9, 00:00:11, Serial0


192.168.4.0/30 is subnetted, 1 subnets
192.168.4.8 is directly connected, Serial0
192.168.5.0/24 is directly connected, Ethernet0

Department of Computer and systems Engineering

67

Scenario 2: Running RIPv1 on subnets and between


classful networks
Reflections
Notice that Baypointe is only receiving the classful summary of the 172.30.0.0
subnets:
RIP: received v1 update from 192.168.4.9 on Serial0
172.30.0.0 in 1 hops

SanJose1 automatically summarized the subnets into a single classful update.


This keeps Baypointes routing table smaller, resulting in faster routing table
lookups.
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 Baypointes routing
table, as Baypointe doesnt care. Baypointe will send all packets destined for
the 172.30.0.0/16 network to SanJose1. Baypointes routing table:
172.30.0.0/16 [120/1] via 192.168.4.9, 00:00:11, Serial0

Also, the subnet mask scheme could be changed (i.e. to /27) on the 172.30.0.0
network without affecting Baypointes routing table or the RIP update sent to
Baypointe by SanJose1.
Department of Computer and systems Engineering

68

Scenario 3: Running RIPv1 on a stub network


SanJose2
hostname SanJose2
interface ethernet 0
ip add 172.30.1.1 255.255.255.0
interface serial 0
ip add 172.30.2.1 255.255.255.0
SanJose1
hostname SanJose1
interface ethernet 0
ip add 172.30.3.1 255.255.255.0
interface serial 0
ip add 172.30.2.2 255.255.255.0
interface serial 1
ip add 192.168.4.9 255.255.255.252
Baypointe
hostname Baypointe
interface ethernet 0
ip add 192.168.5.1 255.255.255.0
interface serial 0
ip add 192.168.4.10 255.255.255.252

Department of Computer and systems Engineering

69

Objective: Running RIPv1 on a stub network


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.
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.
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 doesnt 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:
RIP: received v1 update from 192.168.4.9 on Serial0
172.30.0.0 in 1 hops
Instead, it makes more sense for Baypointe to have a static route configured for the 172.30.0.0/16 network via
SanJose1.
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. Lets see how
to configure this.

Department of Computer and systems Engineering

70

Making changes between Scenario 2 and Scenario 3


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.
If you have just completed Scenario 2, lets remove RIP by issuing the following
command on each router:
Router(config)# no router rip

Department of Computer and systems Engineering

71

Step 1 Configuring RIP on SanJose1 and SanJose2


Here are the commands for each router:
SanJose2#configure terminal
Enter configuration commands, one per line.
SanJose2(config)#router rip
SanJose2(config-router)#network 172.30.0.0
SanJose1#configure terminal
Enter configuration commands, one per line.
SanJose1(config)#router rip
SanJose1(config-router)#network 172.30.0.0

End with CNTL/Z.

End with CNTL/Z.

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.

Department of Computer and systems Engineering

72

Step 2 - Configuring the default static route on SanJose1


On SanJose1, lets 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.
SanJose1(config)# ip route 0.0.0.0 0.0.0.0 serial 1
Notice, since the exit interface is a point-to-point serial interface we chose to use the exitinterface 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-ipaddress) would have worked also.
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.
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.
SanJose1(config)#router rip
SanJose1(config-router)#default-information originate

Department of Computer and systems Engineering

73

Step 3 - Configuring the static route on Baypointe for the 172.30.0.0/16 network
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.
Baypointe(config)# ip route 172.30.0.0 255.255.0.0 serial 0
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.

Department of Computer and systems Engineering

74

SanJose1
SanJose1#debug ip rip
RIP protocol debugging is on
SanJose1#
02:09:10: RIP: received v1 update from 172.30.2.1 on Serial0
02:09:10:
172.30.1.0 in 1 hops
SanJose1#
02:09:29: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.3.1)
02:09:29:
subnet 172.30.2.0, metric 1
02:09:29:
subnet 172.30.1.0, metric 2
02:09:29:
default, metric 1
02:09:29: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.2)
02:09:29:
subnet 172.30.3.0, metric 1
02:09:29:
default, metric 1
SanJose1#
SanJose1#undebug all
SanJose1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C
C
R
C
S*

172.30.0.0/24 is subnetted, 3 subnets


172.30.2.0 is directly connected, Serial0
172.30.3.0 is directly connected, Ethernet0
172.30.1.0 [120/1] via 172.30.2.1, 00:00:13, Serial0
192.168.4.0/30 is subnetted, 1 subnets
192.168.4.8 is directly connected, Serial1
0.0.0.0/0 is directly connected, Serial1
Department of Computer and systems Engineering

75

Scenario 3: Running RIPv1 on a stub network


Reflections
Notice that the static default route is being propagated by SanJose1 to
other routers (SanJose2) via RIP.
Notice the static route in the routing table and the Gateway of last
resort.

Department of Computer and systems Engineering

76

SanJose2
SanJose2#debug ip rip
RIP protocol debugging is on
SanJose2#
02:07:06: RIP: received v1 update from 172.30.2.2 on Serial0
02:07:06:
172.30.3.0 in 1 hops
02:07:07:
0.0.0.0 in 1 hops
SanJose2#
02:07:23: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.30.1.1)
02:07:23:
subnet 172.30.2.0, metric 1
02:07:23:
subnet 172.30.3.0, metric 2
02:07:23:
default, metric 2
02:07:23: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.30.2.1)
02:07:23:
subnet 172.30.1.0, metric 1
SanJose2#
SanJose2#undebug all
SanJose2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
<omitted>
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is 172.30.2.2 to network 0.0.0.0
172.30.0.0/24 is subnetted, 3 subnets
C
172.30.2.0 is directly connected, Serial0
R
172.30.3.0 [120/1] via 172.30.2.2, 00:00:22, Serial0
C
172.30.1.0 is directly connected, Ethernet0
R*
0.0.0.0/0 [120/1] via 172.30.2.2, 00:00:22, Serial0

Department of Computer and systems Engineering

77

Scenario 3: Running RIPv1 on a stub network


Reflections
Notice that SanJose2 is receiving the default route from SanJose1.
SanJose2 forwards that default route out Ethernet 0, a RIP enabled
interface, although there are no other routers on that segment.
Notice the default route in the routing table and that it was learned via
RIP.
Notice the Gateway of last resort

Department of Computer and systems Engineering

78

Baypointe
No RIP messages, as we are not running RIP.
Baypointe#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
S
C
C

172.30.0.0/16 is directly connected, Serial0


192.168.4.0/30 is subnetted, 1 subnets
192.168.4.8 is directly connected, Serial0
192.168.5.0/24 is directly connected, Ethernet0

Reflections
Notice that RIP is not being used on Baypointe. The only routes that are
not directly-connected is the static route.

Department of Computer and systems Engineering

79

Scenario 3: Running RIPv1 on a stub network


show ip protocols command
SanJose2 router from Scenario 3.
SanJose2#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 11 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface
Send Recv
Key-chain
Ethernet0
1
1 2
Serial0
1
1 2
Routing for Networks:
172.30.0.0
Routing Information Sources:
Gateway
Distance
Last Update
172.30.2.2
120
00:00:04
Distance: (default is 120)
SanJose2#

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.
Department of Computer and systems Engineering

80

A Few Final Notes


RIP uses broadcasts
Notice that RIPv1 sends out its RIP updates via an IP broadcast.
02:07:23: RIP: sending v1 update to 255.255.255.255 via Ethernet0
(172.30.1.1)
All devices on the segment will see these RIP updates.
The passive-interface command
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.)
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.
Do keep RIP from sending updates out an interface which does not have any other routers,
you can use the passive-interface command.
The passive-interface command allows the interface to receive RIP updates on the
interface, but does not send RIP updates out that interface.
For example, to keep SanJose2 from sending out RIP updates out Ethernet 0, you can do
the following:
SanJose2(config)#router rip
SanJose2(config-router)#network 172.30.0.0
SanJose2(config-router)#passive-interface Ethernet 0
Department of Computer and systems Engineering

81

What is with the /30 network?


/30 or 255.255.255.252 subnet masks are quite common on serial links.
A /30 subnet mask helps maximize the hosts addresses, which is perfect for a point-topoint serial link, allowing the following for each subnet:
1 network address
2 host addresses
1 broadcast address
IP Class:
C
IP Address:
192.168.4.0
Mask Bits:
6
Subnet Mask:
255.255.255.252
Subnets:
62+1
IP Major Net:
192.168.4.0
Hosts/Subnet:
2
Major Net Bcast: 192.168.4.255
Subnets for Fixed Length Subnet Masking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
No.
Subnet
Hosts
Hosts
Broadcast
Address
To
Address
0 192.168.4.0
192.168.4.1
192.168.4.2
192.168.4.3
1 192.168.4.4
192.168.4.5
192.168.4.6
192.168.4.7
2 192.168.4.8
192.168.4.9
192.168.4.10
192.168.4.11
3 192.168.4.12
192.168.4.13
192.168.4.14
192.168.4.15
4 192.168.4.16
192.168.4.17
192.168.4.18
192.168.4.19
5 192.168.4.20
192.168.4.21
192.168.4.22
192.168.4.23
6 192.168.4.24
192.168.4.25
192.168.4.26
192.168.4.27
7 192.168.4.28
192.168.4.29
192.168.4.30
192.168.4.31
8 192.168.4.32
192.168.4.33
192.168.4.34
192.168.4.35
9 192.168.4.36
192.168.4.37
192.168.4.38
192.168.4.39
<omitted>
61 192.168.4.244
192.168.4.245
192.168.4.246
192.168.4.247
62 192.168.4.248
192.168.4.249
192.168.4.250
192.168.4.251
63 192.168.4.252
192.168.4.253
192.168.4.254
192.168.4.255

Department of Computer and systems Engineering

From

82

How can I remove a single network from RIP?


Instead of using the following command to remove all networks from RIP:
Router(config)# no router rip
You can specify just the network you wish to remove by using the no network command, for
example:
Router(config)#router rip
Router(config-router)#no network 172.30.0.0
Debug ip routing - FYI

If you wish to see what is happening in the routers routing table process, you can use
the debug ip routing command:

SanJose2#debug ip routing
IP routing debugging is on
SanJose2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SanJose2(config)#router rip
SanJose2(config-router)#network 172.30.0.0
SanJose2(config-router)#
00:15:03: RT: add 172.30.3.0/24 via 172.30.2.2, rip metric [120/1]
00:15:03: RT: add 0.0.0.0/0 via 172.30.2.2, rip metric [120/1]
00:15:03: RT: default path is now 0.0.0.0 via 172.30.2.2
00:15:03: RT: new default network 0.0.0.0
Department of Computer and systems Engineering

83

Você também pode gostar