Tag Archives: RIP V2

Routing Part 4 – Another RIP Lab

So now we know all about configuring RIP we are going to play with it a little. In this lab we build on what we did in the last lab. We are using the frame relay network, with the loopbacks, but we are adding a few extra connections. We are going to demonstrate what happens when we change administrative distances, add floating static routes.route3

RIP V2 is running on all three routers, but RIP is NOT running (for what ever reason) on the route 210.1.1.0/24

So the plan here is to use the 210.1.1.0 connection, only in the event that the Frame Relay connections go down. If we try a to add a simple static route, here is what happens:

r2610xm#sh ip route rip
 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
R 172.12.23.0/27 [120/1] via 172.12.123.3, 00:00:05, Serial0/1
                 [120/1] via 172.12.123.2, 00:00:20, Serial0/1

Lets add our static route:

r2610xm(config)#ip route 127.12.23.0 255.255.255.224 210.1.1.3

… to get the 172.12.23.0 network, we will add the static route via the 210.1.1.0 link (.3 is the router 3 end).
So what happens to the routing table?

r2610xm#sh ip route rip
r2610xm#

So our RIP routes have gone and if we look at the routing table we have:

r2610xm#sh ip route 
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
S 172.12.23.0/27 [1/0] via 210.1.1.3
C 172.12.123.0/24 is directly connected, Serial0/1
  210.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 210.1.1.3/32 is directly connected, Serial0/0
C 210.1.1.0/24 is directly connected, Serial0/0
r2610xm#

And we can see from the routing table that the static route has displaced our RIP route. So what happened.?

It all comes down to administrative distance, and unintended consequences. When the router gets two routes to the same network, it looks at the administrative distance of both, and the lower admin distance gets loaded into the routing table. The Static route has a lower administrative distance, so it is the route that gets loaded.

What we need is for the RIP route to remain in the table until such time that route drops, then the static route takes over. This is known as a floating static route and is what this lab is all about.

 

Floating Static Routes

So how do we create a static route that will only be present when the RIP route has gone down? We do this by playing with the administrative distance. If we give the route an administrative distance greater than the RIP route (which has a default of 120) we can ‘fool’ the router in to using the rip route, but it will then fall back to the static route if the RIP route fails. We do this as follows:

r2610xm(config)#ip route 172.12.23.0 255.255.255.224 210.1.1.3 ? 
 <1-255>   Distance metric for this route
 name      Specify name of the next hop
 permanent permanent route
 tag       Set tag for this route
 track     Install route depending on tracked item
 <cr>
r2610xm(config)#ip route 172.12.23.0 255.255.255.224 210.1.1.3 125

So we use the same command syntax as we did with the ordinary static route, but we add the administrative distance for the route at the end. You can see from the above that there are a number of options available to us.

Now when we do a sh ip route rip, we still see the RIP route in place:

r2610xm#sh ip route rip  172.12.0.0/16 is variably subnetted, 2 subnets, 2 masksR 172.12.23.0/27 [120/1] via 172.12.123.3, 00:00:16, Serial0/1 [120/1] via 172.12.123.2, 00:00:21, Serial0/1

So lets test this theory! If we close the interface serial0/1 (the interface to the frame relay) we should see the new floating static route take effect.

r2610xm(config)#int ser0/1
r2610xm(config-if)#shut
r2610xm(config-if)#^Z
r2610xm#sh 
*Feb 13 12:11:49.213: %LINK-5-CHANGED: Interface Serial0/1, changed state to administratively down
*Feb 13 12:11:49.298: %SYS-5-CONFIG_I: Configured from console by console
*Feb 13 12:11:50.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
r2610xm#sh ip route rip
r2610xm#sh ip route
  172.12.0.0/27 is subnetted, 1 subnets
S 172.12.23.0 [125/0] via 210.1.1.3
  210.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 210.1.1.3/32 is directly connected, Serial0/0
C 210.1.1.0/24 is directly connected, Serial0/0

We can see the frame relay link go down, and the RIP routes have gone. We can also see our floating static route now in the routing table. If the link comes back up, the router automatically will put the the new RIP routes in the routing table, displacing the floating static route.

A few final notes:

  • RIP will run in a multi vendor environment
  • Use show ip protocols and debug ip rip for debugging
  • most issues with RIP are going to be config issues
  • RIP uses the Bellman-ford algorithm
  • Hop counts are not a great metric for routing!
  • 224.0.0.9 is the RIPv2 multicast address
Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Routing Part 3 – RIP and RIPv2

Now we are going to take a look at RIP and RIPv2.route2

We will almost always be running RIPv2, but in most cases we have to tell our router that is the version we want to run. This discussion is another lab so we are going back to our frame relay topology again, but this time we have removed the static routes, and added more loopbacks.

What are the differences between RIP and RIPv2?

Well, glad you asked: Version 1 is limited in the sorts of addressing it can handle.

RIP:

  • Classful addresses
  • no VLSM
  • No manual route summarization

RIPv2:

  • Classless Addressing
  • VLSM supported
  • Manual route summarization supported.

How to run RIP

It is a simple command to fire up RIP; in global configuration mode we simply type router rip and add some configuration information, and away we go.

r2610xm(config)#router rip 
r2610xm(config-router)#no auto-summary 
r2610xm(config-router)#network 172.12.123.0
r2610xm(config-router)#network 1.0.0.0
  • There are no options when turning RIP on.
  • The no auto-summary is something we will come later, for right now we just need to have it there.
  • Then we tell RIP what networks to operate on.

So now what? Well if we do a couple of show commands, we can see RIP operating:

r2610xm>sh ip protocols
Routing Protocol is "rip"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Sending updates every 30 seconds, next due in 13 seconds
 Invalid after 180 seconds, hold down 180, flushed after 240
 Redistributing: rip
 Default version control: send version 1, receive any version
 Interface Send Recv Triggered RIP Key-chain
 Serial0/0  1   1 2 
 Loopback0  1   1 2 
 Automatic network summarization is not in effect
 Maximum path: 4
 Routing for Networks:
 1.0.0.0
 172.12.0.0
 Routing Information Sources:
 Gateway Distance Last Update
 Distance: (default is 120)

You can see both the networks we specified are in the network list, and at the top, we can see the statement ‘sending updates every 30 seconds’. This is quite often. We rely on routing protocols to dynamically adjust to network changes and on a LAN, 30 seconds might be useful, however on a WAN, this is way too much overhead, which is why RIP is almost never used on a WAN.

r2610xm>sh ip route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
 172.12.0.0/24 is subnetted, 1 subnets
C 172.12.123.0 is directly connected, Serial0/0

And here we can see the two connected networks.

Given the limitations of RIPv1, we would prefer to use v2. This is easy to select; in global config mode we simply type:

router rip
version 2
^z

… and we can verify that RIP is sending and receiving version 2 information by issuing another sh ip protocols command.

RIP Timers

In practice we will usually leave these timers at their defaults, but it is good to know what they do and how to change them. The timers are:

  • updates – how often RIP sends update packets (Default 30s)
  • invalid – If a router doesn’t see an existing route (in its routing table), how long before it marks it as unreachable (hop count 16) (Default 180s)
  • holddown – Routes will go into a holdown state when marked as unreachable. During this time the router will not accept updates indicating reachable. (Default 180s)
  • flush – This is the time it takes for a route to get flushed from the table. This time is the invalid time plus 60 seconds. (Default 180 + 60 – 240s)

Some notes about the time intervals:

  • invalid should be at least 3 x the update timer
  • holddown should be at least 3x the update also
  • Flush must be larger than both invalid and holddown

OK great, so how do i change the timer:

conf t
router rip
timers basic

… and use IOS help to look at the timers as you need to enter all four.

How to debug RIP

Once we have our three routers running RIP, lets take a look as see what we have. The commands we can use to have a good look at what is going on are:

  • sh ip protocols
  • sh router rip
  • sh ip route

Executing a sh ip protocols gets us this:

r2610xm#sh ip protocols
Routing Protocol is "rip"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Sending updates every 30 seconds, next due in 20 seconds
 Invalid after 180 seconds, hold down 180, flushed after 240
 Redistributing: rip
 Default version control: send version 2, receive version 2
 Interface Send Recv Triggered RIP Key-chain
 Serial0/0   2 2 
 Loopback0   2 2 
 Automatic network summarization is not in effect
 Maximum path: 4
 Routing for Networks:
 1.0.0.0
 172.12.0.0
 Routing Information Sources:
 Gateway       Distance Last Update
 172.12.123.3  120      00:00:19
 172.12.123.2  120      00:00:07
 Distance: (default is 120)

We can now see the routing info from router 2 and 3. When we check sh ip route

r2610xm#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:12, Serial0/0
 3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:27, Serial0/0
 172.12.0.0/24 is subnetted, 1 subnets
C 172.12.123.0 is directly connected, Serial0/0

… we can see the RIP routes in Router 1’s routing table.
Notice the [120/1] – 120 administrative distance, and 1 is the hop count.

Now I’ve popped over to router 3 and run an debug ip rip, and here is what I got:

r1721#debug ip rip
RIP protocol debugging is on
r1721#
Oct 11 23:46:04.199: RIP: received v2 update from 172.12.123.1 on Serial0
Oct 11 23:46:04.199: 1.1.1.1/32 via 0.0.0.0 in 1 hops
Oct 11 23:46:04.199: 2.2.2.2/32 via 172.12.123.2 in 2 hops
Oct 11 23:46:04.199: 172.12.123.0/24 via 0.0.0.0 in 1 hops
Oct 11 23:46:04.243: RIP: sending v2 update to 224.0.0.9 via Loopback0 (3.3.3.3)
Oct 11 23:46:04.243: RIP: build update entries
Oct 11 23:46:04.243: 1.1.1.1/32 via 0.0.0.0, metric 2, tag 0
Oct 11 23:46:04.243: 2.2.2.2/32 via 0.0.0.0, metric 3, tag 0
Oct 11 23:46:04.243: 172.12.123.0/24 via 0.0.0.0, metric 1, tag 0
Oct 11 23:46:04.243: RIP: sending v2 update to 224.0.0.9 via Serial0 (172.12.123.3)
r1721#
Oct 11 23:46:04.243: RIP: build update entries
Oct 11 23:46:04.243: 1.1.1.1/32 via 172.12.123.1, metric 2, tag 0
Oct 11 23:46:04.243: 2.2.2.2/32 via 172.12.123.2, metric 3, tag 0
Oct 11 23:46:04.247: 3.3.3.3/32 via 0.0.0.0, metric 1, tag 0
Oct 11 23:46:04.247: 172.12.123.0/24 via 0.0.0.0, metric 1, tag 0
Oct 11 23:46:04.247: RIP: ignored v2 packet from 3.3.3.3 (sourced from one of our addresses)
r1721#u all
  • Notice the multicast address of 224.0.0.9
  • Also the term Metric – this is the hop count
  • If we want to force an update rather than waiting 30 seconds, we can use the command clear ip route *

 

The downside of using RIP

There are a couple of downsides to using RIP and we have touched on them a little.

  • RIPv1 uses broadcast packets to communicate, and this is not a great idea. V2 improves this will multicast packets, but they are still sent every 30 seconds, so thats a lot of overhead.
  • When RIP sends out an update, it sends its entire routing table. This is a waste of bandwidth.
  • The only metric RIP has is hop count. This is an issue because it does not take into account bandwidth, and as we know from Layer 2 switching, bandwidth is important.
  • Also, RIP performs equal cost load balancing, which splits data across multiple links equally. This is great but again, bandwidth is not taken into account. It is quite feasible that RIP would equally share data across two links – one at 56k and the other at T1 and to RIP this is perfectly ok.

Final Note:

Just to illustrate how easy using RIP is, I went to router 3 and added some more loopbacks.

conf t
int loopback33
ip address 33.3.3.3 255.255.255.255
int loopback44
ip address 44.4.4.4 255.255.255.255
int loopback55
ip address 55.5.5.5 255.255.255.255
and then added the networks to RIP
router rip
network 33.0.0.0
network 44.0.0.0
network 55.0.0.0
^z

… and at router 1 (the hub) we can see the following if we issue a sh ip route rip :

r2610xm#sh ip route rip
 2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:15, Serial0/0
 33.0.0.0/32 is subnetted, 1 subnets
R 33.3.3.3 [120/1] via 172.12.123.3, 00:00:13, Serial0/0
 3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:13, Serial0/0
 55.0.0.0/32 is subnetted, 1 subnets
R 55.5.5.5 [120/1] via 172.12.123.3, 00:00:13, Serial0/0
 44.0.0.0/32 is subnetted, 1 subnets
R 44.4.4.4 [120/1] via 172.12.123.3, 00:00:13, Serial0/0
Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Routing Part 2 – Routing Protocols Basics

In this post we are going to start looking at routing protocols. We had a brief discussion of routing protocols in the CCENT post on routing, here.

routing-protocol1

For the CCNA we are only going to focus on:

  • RIP (versions 1 & 2),
  • EIGRP (IGRP is no longer supported), and
  • OSPF.

BGP and IS-IS are covered with later studies.

There are a few concepts we need to get down before we go too deep into this:

  • Distance vector routing
  • Administrative distance
  • Split Horizon
  • Route Poisoning

Distance Vector Routing

RIP and EIGRP are distance vector protocols. I searched for a definition of DVP, and I found this on wikipedia:

A distance-vector routing protocol requires that a router informs its neighbours of topology changes periodically. Compared to link-state protocols, which require a router to inform all the nodes in a network of topology changes, distance-vector routing protocols have less computational complexity and message overhead.

OK, makes sense to me and as far as I can tell, that is as far as we need to go in terms of understanding it, now we need to know how to use it.

Administrative Distance

Administrative distance is the measurement of the routing sources believability, on a scale of 0 to 255, 0 being most believable. Usually a score of 0 indicates a directly connected route.

Split Horizon

Split Horizon is a distance vector protocol behavior so you won’t see this on a Link State protocol. We have discussed this before in the frame relay and router on a stick labs. Split Horizon prevents routing loops by preventing routes being advertised out of the same interface they were initially advertised on.

Route Poisoning

Route poisoning is also a distance vector behavior. If a router decides that a particular route is no longer there, rather than just delete the route, it advertises the route as being unreachable (hop count of 16 for RIP). There is a good reason for this – if it just deletes the route, other routers may still have this route and will keep sending packets to the original router. By advertising the route as unreachable, it lets the other routers on the network know that the route no longer exists. Then it can be deleted from the routing table.

 

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Routing Protocols Overview

We need to understand how routing works. Once we have mastered the static route, we realise that while static routes are ok for very small networks, we need dynamic routing for medium and large networks, and there are a number of protocols we need to study.

 

routing-protocol1

RIP

The first protocol is RIP (Routing information protocol). Rip is an old protocol, based on distance vectors. It is easy to configure, and comes in two flavors, version 1 and version 2. We need to be aware of both, but will only ever deploy version 2.  RIP Version 1 does not understand VLSM (Variable Length Subnet Masks) and will treat each IP address as its class (A, B or C)

RIP version 2 moves away from that and enables the use of classless IP addresses and in modern networks is by far the preferred version. There is one drawback with RIP however and that is the speed at which it can update routes. In smaller network, if a route changes, that change needs to be communicated quickly and RIP can take 30 seconds or more to communicate change.

IGRP, OSPF, ISIS, EIGRP

These protocols are covered in the second part of the course, for now we just have to know that they exist.

BGP

A quick note about BGP (Border Gateway Protocol). RIP, IGRP, OSPF and ISIS are interior routing protocols. This means they are targeted at working within small to large networks, but BGP is targeted at working within the internet itself, and is an exterior (or Border) routing protocol. It is very much like RIP in that it is distance vector based, and slow to react to changes in routing, however this slowness is in this case a good thing. BGP can get quite involved, and happily, we don’t need to know anything about BGP for the CCENT.

 

Routing and the Ethernet frame.

A quick note about the Ethernet frame itself – while this is not an exact representation of the Ethernet frame, what I am trying to convey here is that the MAC addresses change on each hop, but the connection information, ie; port and IP address do not.

Ethernet

 

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone