Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

Vendor NewsFeed

More Vendor NewsFeed »

ON THE WIRE

A Blast From The Past: Revisiting The Big RIPoff

by Bill Alderson and J. Scott Haugdahl

Occasionally we receive a challenge we just cannot refuse. In a recent Letterto the Editor in the May 15 issue (" ImitationIs a Form of Flattery? ,"), the reader describes how he appliedone of our recent problem scenarios to an arbitrary network infrastructure,and consequently didn't care much for our suggested solution. As you mayrecall from our March 15 column ( "BigRIPoff: Do You Know Where Your Packets Are?," ), the net-work inquestion consisted of several Ethernet segments that were connected togethervia several NetWare servers that were also acting as routers. A number ofthe segments we re also connected directly to a router, for WAN access. Thebasic problem was unusually high traffic on some of the segments, and thereason for the problem was that traffic was passing through a router toa server when the traffic could have gone directly to the server. It turnsout that the server was physically attached to several segments-one of thembeing the same segment as the originating traffic.

Scott : Interesting that the reader who wrote the letter works forthe technical support group at the vendor that makes the protocol we discussed-NetWare'sRIP.

Bill : It's certainly not the first time we've seen the proverbialknee-jerk response to o ne of our columns. Since we're end-user advocates,perhaps we can help out a bit.

Scott : For example, the reader's letter states the following: "Icorresponded with them several times to straighten out problems with thatone." This statement actually refers to a technical support call duringwhich we uncovered a comple tely different problem at a different customersite and the vendor in question was, at the time, scrambling to recommenda temporary solution to the problem.

Bill : That particular problem was eventually written up as the infamous" Big Bad Watchdog Bites Network "column.

Scott : Regarding the RIP problem, we always try to treat a complexsubject as best we can in the space available to us. We want to alert ourreaders to problems in real networks, especially when equipment vendorshave different views of a standard or specification.

Bill : The hardware router to which we referred in our March 15 columnresponds to the station's "Get Nearest Route" to a server RIPpacket, despite applying a technique known as "split horizon"(that is, a router never advertises a network number back to the same physicalsegment from which the router learned it).

Scott : In our client's case, however, the router lear ns about theserver's internal IPX number on both sides of the router, and thus "crossadvertises" the IPX numbers.

Bill : The router sees the same IPX number being advertised on bothsides, since the server is advertising its internal IPX number to everyphysical segment to which it is attached.

Scott : It just so happens that these are the same segments to whichthe router is attached.

Bill : Novell's use of an internal IPX number inside a server is uniqueto NetWare (beginning with NetWare 3.x). In other networks that use theRIP protocol, such as IP networks, a router advertises the physical subnetto which it's attached, whereas in IPX ne tworks, NetWare servers advertisethat they can "route" to their internal IPX network.

Scott : We stated this clearly in our March 15 column as: "Scott:The server's internal segment was really connected to the two external physicalEthernet segments via the internal router, as shown in the figure . Therefore,the internal IPX number (700001) was advertised to both segments."

Bill : To which I had replied, "Since the router was also attachedto both segments, it advertised the IPX network 700001 it had heard fromthe server on segments away from where it was heard."

Scott : Now, with NetWare servers that are also physically routingin parallel between the two segments, this wouldn't normally be a problem,since the servers recognize this "multi-segment, same IPX number"phenomena. In theory, a fully IPX-compliant router should recognize thisas well.

Bill : Our interim solution (delayed RIP response from the hardwarerouter) only applies to this particular portion of the network. Again, togive a bit more detail, the majority of the users on the bottom segmentuse the server attached to that segment, as shown in the figure below. Thus,very little traffic actually went across the server, meaning there was no"terrible congestion" whats oever, as alluded to in our reader'sletter.

Scott : As a matter of fact, the only real IPX traffic routed offthis particular segment turned out to be occasional e-mail headed for anotherpost office server.

Bill : If for some reason, there were to be an application shift ormore users accessing remote servers, then we would recommend turning offphysical routing in the server (which can be done with NetWare 4.x, butrequires the IPXRTR.NLM in NetWare 3.x). The server would still RIP, advertisingonly its internal IPX network number, not any of the remote networks, sincethey are no longer reachable through the server.

Scott : There are other solutions available, s ome of which are vendordependent. For example, one router vendor allows you to perform a "SetPath" command that would solve the problem.

Bill : Also, we didn't talk about IP-the protocol used to access theoutside networks to which we allude. Thus, IP traffic always goes throughthe har dware router anyway, as the servers only carry IPX.

Scott : Meanwhile, we must continue to keep an eye on our IPX networksto make sure that we do not have this "route-about" routing problem.

Bill : Interestingly, this problem was discussed at the recent NovellDeveloper's Conference, Brainshare '96.

Scott : And, two weeks prior to writing this column, we encounteredthis problem again in another network.

Bill : The moral of the story is to never assume any protocol of anytype in any piece of equipment in any network is going to behave preciselythe way a specification or a standard is written.

Scott : Not only that, but there are often areas of ambiguity andthere may be different interpretations when it comes to actual implementation.

Bill : Overall, the RIP protocol is just fine in networks of low tomedium complexity. IP and IPX use it the same way to update routing tablesbetween routers. Both have their roots i n XNS, and IPX adds an additionaltick metric.

Scott : It's when a workstation uses RIP to find a route to an IPXnetwork that we need to keep a watchful eye on it.

Bill and Scott are principals of Pine Mountain Group. They can be reachedat otw@pmg.com. Portions of the actual trace files from selected columnsare available via Pine Mountain Group's Home Page ( http://www.pmg.com ).

Updated June 14, 1996

Research and Reports

Hypervisor Derby
August 2011
Network Computing: August 2011

Video


WATCH: Box.net CEO Aaron Levie Takes On Microsoft

WATCH: HP Chairman Ray Lane: Focus On Innovation

WATCH: How OpenFlow Changes Networking


View All Videos
Previous Page First Page Second Page Third Page Next Page

Most Popular

Stories Blogs

More Stories »

Featured Whitepapers

Featured Reports

BlogRoll

TechWeb Careers