home news blogs forums events research newsletter whitepapers careers


UBM Network Computing
TechWeb
Visit our SOA/Web Services Immersion Center

IMMERSE YOURSELF:

SOA

  |

Data Center

  |

802.11n

  |

Data Privacy

  |
APO  |

Virtualization

  |

NAC

  |

Security

  |

Network Mgmt

  |

Enterprise Apps

  |

Storage & Servers



WORKSHOPS

Should RIP Finally Rest In Peace?

by Chris Lewis

For many large TCP/IP-based networks, the routing protocol of choice has been version 1 of the Routing Information Protocol (RIP). The basic operation of this protocol is familiar to many network administrators, particularly those who have abackground in Unix systems administration. RIP version 1 was distributed free with BSD Unix and was designed for small networks, connected with links of identical characteristics--typically machines interconnected with Ethernet segments.

But as networks grow and utilize FDDI, 56-Kbps lines, dial-up links and Ethernet segments, RIP produces suboptimal routing. In most instances, it's time to stop using RIP just because it is familiar and easy. Other routing protocols are widely available and will create internetworks that are more reliable, scalable and easily maintained.

This article will provide network managers with a better understanding of how RIP works, so that its shortfalls are clear. In a later article, we'll discuss the operation of more modern routing protocols, such as the Interior Gateway Routing Protocol (IGRP), Enhanced IGRP and Open Shortest Path First (OSPF), and how a network manager can migrate from RIP to these protocols. Note that RIP version 2 and Integrated IS-IS are not considered as they are not widely deployed.

Basic Concepts By definition, a router seeks to route packets bet ween interfaces, which are associated with different network numbers. This has two immediate practical implications: A router (unlike a bridge or switch) will not forward broadcast packets unless specifically configured to do so; and a router cannot be configured with the same network number connecte d to more than one interface. However, most routers allow a secondary address to be associated with an interface.

For a host, such as a workstation PC, IP-routing decisions are simple. If the destination host is on the directly connected network, the packet is sent directly to the destination host. If the destination host is on a remote network (that is, the other side of one or more routers), the host refers to its TCP/IP configuration and forwards the packet to whatever is configured as the default router (some IP stacks refer to this as the default gateway). The terms "router" and "gateway" are interchangeable in most TCP/IP documentation.

But routers can face more complex routing decisions, at the heart of which is the routing table. If one understands the content of the routing table and how it gets updated, optimal configuration of routing protocols is relatively straightforward. In "Sample Internetwork Connections," on page 126, an internetwork with four router devices connects six networks. Using this sample internetwork, we can examine how routing protocols work in a simple environment. If Machine C is a Unix machine, one can view the routing table by issuing the netstat -nr command. This should show a table similar to "Output of netstat -nr Command On A Unix Machine," on page 126.

This routing table is a simple look-up table. When a router receives a packet, it examines the destination address and determines the network number for the destination. The router then looks up the destination network number and forwards the packet to the gateway IP address for that entry, then sends the packet via the interface associated with it.

Let's consider an example: Machine C receives a packet with destination address 162.8.1.1. As this is a class B network address with no subnet masks applied, the destination network number is determined to be 162.8.0.0. The router looks up its routing table and sees that to get to network 162.8.0.0, it must forward the packet to gateway (or router) 162.11.1.2, ou t of interface le0.

Machine C does not know the exact route to network 162.8.0.0, it just knows the next hop in the sequence. This is the basis of all routing protocols that are termed "distance vector" protocols.

If Machine B is a router, it will have a slightly different routing table. Issuing the command show ip route to a Cisco router will produce a display similar to "Output Of show ip route Command On A Cisco Router," on page 128.

Chris Lewis is a product support manager at ILX Systems in New York.

( Next Page )

ODBC Servers Simplify Database Management
Return To The Table Of Contents
Updated August 26, 1996





Ready to take that job and shove it?

Function:

Keyword(s):

State:
SPONSOR
RECENT JOB POSTINGS
CAREER NEWS
Go beyond Google and get vertical. These specialized search sites will help you find the business information you need -- fast.

Ari Balogh was named to the post of chief technology officer as the companys for a "realignment" of employees.










InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Purchase Today: $299
 
ROLLING RIGHT ALONG
Follow key Network Computing Reviews from conception to completion. This Week: Holistic APM.



Network Computing Reports Emerging Enterprise Podcast Series: Secrets to Success








TechSearch


Microsite of the Week


Powerful Information at Your Fingertips



App Infrastructure   |   Messaging & Collaboration   |   Network & Systems Mgmt   |   Network Infrastructure   |   Security  |   Storage & Servers   |   Wireless   |   Enterprise Apps
About Us  |  Contact Us  |  Site Map  |  Media Kit  |   Briefing Centers
Other Techweb Sites:   InformationWeek Reports  |  Intelligent Enterprise  |  Light Reading  |  InformationWeek
Techweb  |  Dark Reading  |  Network Computing Germany  |   Byte & Switch  |  bMighty  |  Small Biz Resource  |  InformationWeek Analytics
Copyright © 2008  United Business Media LLC  |  Privacy Statement  |  Terms of Service  |  Your California Privacy Rights