Talk:Routing table

Isn't the endless-looping problem avoided by the 'time to live' in the packet header?

Basics: Rewrite

Olo! The information in this section was okay (by me, anyhoo), but a lot of factors, including verbose repetition of phrasing, and ambiguity, left it rather unintelligible. Some of the points of concern for me were:

. Repetition of a few words, like "whenever."
. Too much parallelism in the sentence structure
. Using the word "data"  to mean different things in different contexts.
. The word "package" was introduced, without enough qualification.
. Random reference to a change in the architecture after first paragraph.

I rewrote the whole thing, mostly, which fixed the first two; I either eliminated all usage of "data," except in reference to the data that the original node needed to send; and, I defined the use of package a little better. As for the obscure reference, I didn't fix it, but I also didn't want to delete any useful (though extraneous) info; instead, I tacked it onto the second para, which does make much sense to me, any way: Should it be under Basics?

38.109.136.11 (talk) 11:39, 9 February 2010 (UTC)

Lacking in context?

Hi,

I added a new sentence to the start of the 1st paragraph to try and give context to the introduction of the article. Is this sufficient, or is more needed?

Kind regards Amigaholic 08:42, 28 December 2006 (UTC)

Endless Looping Problem

Hi,

The endless looping issue is not solved by the Time-To-Live (TTL) being set - this is simply a measure to prevent a build-up of endlessly-looping packets (a broadcast storm) - the recurring loop may still exist, but TTL prevents the packets accumulating in that loop.

Endless looping is circumvented using technologies such as route poisoning or split horizon with poison reverse.

Amigaholic 08:41, 28 December 2006 (UTC)

Multiple tables vs. single table

Current [1] version talks about several routinge tables on one host. As far as I know each host has only one table (perhaps single table for each user). Routing protocols (the protocols that upkeep network topology information) may have tables or likely other structures but these are not used for packet-forwarding directly - instead they build routing table. Therefore I propose to remove mentions to multiple tables. --Alvin-cs ✉ 21:03, 1 June 2007 (UTC)

Merge Routing Table with Router

What would you think about merging this entire article with Routing with a wiki link to the section? In other words the entire article would not be alone any more. The would save the trouble of creating an non-computerish beginning.

If we leave this as a stub, non-tech information will need to be added to the intro for a novice and the article will need to be expanded to fulfil the encyclopedic function that this article is to server. Let me know your thoughts.

Thanks! --akc9000 ^{(talk • contribs • count)} 15:54, 2 July 2007 (UTC)

Merging seems like a good move to me. The concept of a routing table is entirely dependent on routers --Nethgirb 21:42, 2 July 2007 (UTC)

Not necessarily. Route servers and other routing instrumentation that do not forward build routing tables but are not routers. Label switched routers need not have routing tables.

In the IETF FORCES architecture, there is a separation between control and forwarding elements. Consider, for example, how many routing tables are present in a Cisco 12000 8-slot chassis with redundant route processors in a stateful failover mode? HINT: there are multiple answers to this question, depending on the definition used of "routing table". It isn't as simple as it might look. Howard C. Berkowitz 21:49, 2 July 2007 (UTC)

Does not matter, Wiki is not a textbook or a manual. Tell me something that is not a router that builds a routing table. Please see: WP:NOT#TEXT about how to write an article. --akc9000 ^{(talk • contribs • count)} 11:25, 3 July 2007 (UTC)

I tagged this article: {{unencyclopedic}}

I actually do not want this article to be deleted. I would like to think there is a way for this article to survive, and I have sought advice from an admin so that this point can be made more clear to see if this article can stand alone. --akc9000 ^{(talk • contribs • count)} 12:33, 3 July 2007 (UTC)

I think that's unnecessarily harsh. Merge, yes; unencyclopedic and delete, no --Nethgirb 13:09, 3 July 2007 (UTC)

Howard wrote: "Route servers and other routing instrumentation that do not forward build routing tables but are not routers. Label switched routers need not have routing tables." I agree that you can have a router that doesn't have a routing table, and a routing table that exists outside of a router. However this does not contradict my statement that the concept of a routing table is entirely dependent on routers. In your example of a route server intended for instrumentation, the concept is tied to routers, because the instrumentation mechanism's purpose is to mimic what's going on inside the router (right?). The following is not very precise, but... my impression is that wherever there is a routing table, a router is not far away. I'm curious if you have examples where that is not the case. (and also I didn't get the point of your Cisco 12000 example) --Nethgirb 12:57, 3 July 2007 (UTC)

For the record, I am by nature an inclusionist. But I do not want the article structure to get out of control here, making Wiki a textbook. To quote: Wikipedia is an encyclopedic reference, not a textbook. The purpose of Wikipedia is to present facts, not to teach subject matter. It is not appropriate to create or edit articles which read as textbooks, with leading questions and step-by-step problem solutions as examples. These belong on our sister projects Wikibooks and Wikisource.

Also, I do not want any editor to do great work, only to have their article deleted. The issue would not have arose but Howard has written a number of new articles concerning this issue, combined they could be considered a reference. I think everything he has written is excellent. The problem is, we need to follow the rules here. I want to make absolutely 100% sure what is being done is going to be ok with the community in general. By posing the question in advance, we are able to prevent afds and other unpl. issues from happening. I hope you can see that I am trying to help and not be harsh but to make sure there is not future issue. For example, another editor tagged the photos of the routers I included to try to have them deleted. I personally think they are needed in the router article. But anyone can come along and try to have something deleted. To avoid this from happening, we have to cover the bases so to speak to make sure we stay focused and on target. --akc9000 ^{(talk • contribs • count)} 16:15, 3 July 2007 (UTC)

I understand the concern that we need to work out the organization of these articles and I agree with you. However for content organization like this I don't think we're in danger of a smackdown from an admin --Nethgirb 20:36, 3 July 2007 (UTC)

Even little bitty routers...

Even in low-end home routers, there still will be more than one table associated with routing. Older Cisco routers, for example, had the main routing table, which was sometimes used to look up forwarding information, as in certain kinds of load balancing (per-packet, if anyone cares). That table, since it was optimized for update by routing protocols, was the slowest lookup for forwarding.

For most purposes, the older routers used a "fast cache" in main memory for routine lookup, and it indeed was faster. It also had to be invalidated and rebuilt when the router learned a new destination. Now, the default forwarding mode is Cisco Express Forwarding (CEF) even in small routers. CEF has the feature of having a forwarding-optimized table in one-to-one correspondence with the routing table, so there is never a "cache miss" conditioning forcing recomputation of the forwarding table.

Non-forwarding "routers"

One historic but reasonably clear example would be the route servers that were once heavily used at Internet Exchange Points (IXP). Assume the exchange point has routers from 10 ISPs. There is a fairly significant overhead to each BGP session. Further assuming that all the ISPs interconnect, that is a minimum of 9 BGP sessions per router. If an ISP puts in a backup router, there needs to be a session between the two routers, and potentially backup sessions to all the other ISPs if the routers load-share.

Route servers were *NIX general purpose computers with lots and lots of memory. Most commonly, they ran the Rsd routing daemon, which could maintain BGP sessions and the associated tables, but had no capability to forward packets (i.e., "route" them). Typically, there were two servers, each running on a different platform to avoid bug-related problems (e.g., Sun and DEC Alpha processors).

With route servers, each ISP router only needed to maintain sessions with the route server(s) and, if present, the ISP backup router. The route server also collected information about routes, but not traffic, that were critical in routing research.

Non-routing table "routers"

Virtually any high-performance router distributes the forwarding part of routing to its line cards. Those line cards (e.g., Cisco's VIP on the 7500 series) has a table with a copy of every active route in the main control processor's routing table, but this forwarding information base is organized differently than the "routing table", being optimized for fast lookup rather than fast updating.

It is perfectly reasonable and common to take commercial routers, inside an ISP, and use them only as MPLS forwarders, which is defined as a Label Switched Router (LSR). LSRs do not participate in routing protocols, but only have enough information to do next-hop label swapping and forwarding. Their MPLS tables are populated by the Label Edge Routers, which do participate in routing protocols and build the label swapping tables. The labels are inside a data link frame but preceding the IP packet header, so the forwarding decision is indeed being made at the network layer, where routers operate. For interprovider MPLS, additional labels can be pushed into the header and popped off when the packet leaves one routing domain, and the last label is stripped off in the destination ISP, where

My proposal

Would you mind commenting on my proposal, not to delete routing table, but to make it subordinate to control plane, which, along with forwarding plane, would be subordinate to router? Each of these planes have logically subordinate functions, one of which would be the routing table, which, along with other tables, is under the control plane. I'm speaking this way as one who has designed router products, as well as designing routed networks that had from one to tens of thousands (or more) routers.

Response to Proposal

I needed to get consultation before commenting. Please see the comments I have left you on your talk page. Please remember that:

1. Wiki always needs a intro that anyone that can understand.
2. cannot be written as a manual or a how to.
3. cannot explain how to set something up.
4. cannot go off topic. See example of what is wrong with control plane and forwarding plane from an admin.

If you can write the article that it stays encyclopedic and does not read like a manual. You can write the articles as they are. They cannot go into overtly complex detail or they will be considered to read like a manual, and be flagged for deletion. Not by me but by someone else, Remember I am an inclusionist. (But even I see the limits and you need to too.)

Also you can post information to the Talk page of the networking groups talk page when it has to do with something on its to do list. Remember to add the networking group's talk page to your watch list.

If you do not understand please ask me on my talk page; Talk to akc9000 I respond to my talk page requests first. Then others. So if you need an answer, please feel free to ask there. As you will see on that page, I am dealing with other editors trying to delete things from the networking articles that I believe should be there. So believe me when I tell you I write to you to tell you how to do things right so your articles do not get deleted and we make Wiki the best it can be according to the style guidelines.

I am removing the merge tag. It is up to us to make sure we do not go off track with this articles. Stay on topic. Use wiki links to refernce other data. Do not repeat data, do not write a manual on a topic.

Remember, I exist on Wiki to help editors not to hurt them. But I still have to point out mistakes and take action.

--akc9000 ^{(talk • contribs • count)} 02:08, 4 July 2007 (UTC)

A Cisco 12000 example: a partial look at the tables of a high-performance router

To take the Cisco 12000 example, depending on how you define "routing table", in a configuration that has 8 line (forwarding) cards and a redundant control processor with stateful failover, different definitions could lead a reasonable person to say that the device has 1, 2, 16, or 18 routing tables, or even more.

• One routing information base in the active control processor. This is closest to the intuitive definition, although not necessarily technically accurate. This is the primary place that information from dynamic routing, static configuration, and hardware status store their information about potentially reachable destinations.
• One hot standby copy in the backup control processor.
• In each of the line cards, a forwarding information base that is in one-to-one correspondence with the entries in the routing information base, but stored in a different structure, hardware-assisted, and with additional tables that are used in "routing" (e.g., the adjacency table used in uRPF and other functions) but are not directly updated by routing protocols.

In addition, assume this router is running OSPF (connected to three areas), BGP (to four other BGP-speakers). I'll leave multicast and traffic-engineered routing out of the discussion for now. The OSPF process has three tables of route-related information, one per area. The BGP process, for each neighbor, has three conceptual tables that, depending on implementation, may be separate memory structures or combined: the Adj-RIB-In, the Loc-RIB, and the Adj-RIB-Out.

Are these routing tables? More to the point, does an "encyclopedic" view of a real-world router explain the various tables used in routing, as opposed to "the routing table"? Even a much smaller router still has multiple tables associated with routing. Howard C. Berkowitz 18:36, 3 July 2007 (UTC)

Hi howard, thanks so much for your detailed reply.

RE your last question, I would assume that yes, the router article would explain the various tables used in routing (at least, the important ones).

RE your proposal, what do you mean by subordinate? I thought you meant "merge" before, but I guess you mean to organize wikilinks between them so readers are clear on how the concepts from the different articles all fit together? If the articles in question are too big to put into one article, then yes, this sounds fine.

RE your examples: You seem to be arguing against the position that "every router has exactly one routing table, and every routing table is in exactly one router". But that is not my position. I'm saying that the concept of a routing table is entirely dependent on routers. So, looking at your new example of route servers: yes they do not forward. But the only reason they have routing tables is to redistribute those tables to actual routers. So this example doesn't demonstrate the independence of the concept of "routing table" from "router". Maybe we just have some confusion in our communication here because you seem to agree with me when you say "routing table" is subordinate to "control plane" which is subordinate to "router" --Nethgirb 20:36, 3 July 2007 (UTC)

Thank you; I think we are progressing. I wasn't suggesting merging, as my sense is that a thorough treatment of several of these points would best be done in several linked articles. The level of these articles, however, would not be as detailed as an engineering textbook on the subject.

One of the problems I'm having, I suspect, has to do with keeping both "router" and "routing" as separate articles. A lot of our disagreement, I think, comes from that separation, which I find confusing. How would you feel about merging them, with appropriate links to whatever is merged into the surviving article? Let me try to illustrate what I consider the subordination:

1. Router/routing
   1. Control Plane
      1. Routing table(s)
      2. Dynamic Routing Protocols
         1. Unicast
            1. RIP
            2. OSPF
            3. ISIS
            4. BGP (and variants such as multiprotocol BGP)
         2. Constraint-based
         3. Multicast
         4. MPLS path setup
         5. RSVP
   2. Forwarding Plane
      1. Forwarding Information Bases
      2. Distributed (IP) forwarding
      3. MPLS forwarding (maybe make this GMPLS)

There are assorted other articles, such as Virtual Private Network, which need work, but would link into this hierarchy. For example, the two major types of provider-provisioned VPNs either combine BGP (which carries VPN-tagged information to store into Virtual Routing & Forwarding tables, and MPLS, or create virtual routers (each with one or more routing tables). I'm looking at VPN and thinking how their routing-based setup could be clarified better if there were a decent set of routing articles. —Preceding unsigned comment added by Hcberkowitz (talk • contribs)

The state of Routing might be messy at the moment... but, the way I envision these articles is:

• Router would describe a local view: the structure of a router, generally a physical box that operates at layer 3. It would discuss hardware design, internal data structures, etc. Your outline above seems like a good one for router and its subordinate articles.
• Routing would cover a global, high-level view of path selection. The issues covered would generally deal with algorithmic issues and fundamental limits involved in global properties of the network. Such as: the difference between an identifier and an address; the tradeoff between minimizing state in routers and finding shortest paths; algorithms for distributing network topology information. It can also deal with routing more generally than layer 3 devices (e.g., ad-hoc routing or routing in overlay networks) and where appropriate, routing in non-computer networks (e.g., routing in social networks, such as in Milgram's small world experiment). Much of that doesn't at all involve routers in the sense of physical L3 boxes.

What do you think? --Nethgirb 23:09, 3 July 2007 (UTC)

We seem to be on a very interesting journey, without really knowing what to call the path or the destination. As a L3 routing person, I sometimes say I just worry about paving and building the interchanges on the Information Superhighway, and am less concerned with the destination. Less charitably, some of my friends suggest I have to clean up the roadkill on said highway.

One issue is whether "routing" is sufficiently different than "router" to avoid ambiguity. While I'm not convinced it is the right term, let me offer one from what was mostly a dead end, called the OSI Routeing [sic] Framework, defined in ISO/TR 9575:1989. Unfortunately, which was one of the things that doomed OSI protocols, the defining documents are not available free online, as are the IETF RFCs. This document, in combination with ISO/TR 10000 on functional (i.e., stack) protocols, had a general concept of "relay" between two protocol entities.

Your point about Milgram is well taken. Do you think the PGP web of trust/distributed trust model fits here? If you've looked at the LinkedIn.com social networking tool, which I use extensively, it's distributed trust for a maximum of 3 degrees of separation.

For these non-L3 boxes, do we not still have the separate concepts of control (drawing the map, establishing express lanes, etc.) as well as forwarding (moving traffic along it, and, perhaps, QoS and filtering being the highway police pulling offenders off the road?). Adding filtering/access lists to both the control (pattern definition) and forwarding (pattern matching and action), or perhaps the distributed trust idea of countersigning/vouching, may well deal with the trusted social network idea.

While I understand Wikipedia frowns on original research in general, there is, I believe, originality in the way you propose generalizing the idea. I'd like to see it mature, and, perhaps the WikiPowersThatBe permit creative ways of organizing, as opposed to creating, information. Howard C. Berkowitz 01:06, 4 July 2007 (UTC)

original research cannot go into wikipedia. It always needs to come from a secondary source. If you write an RFC that is published by the IETF and you cite it. You need a different secodary source to back it up or you will have a conflict of interest. You could also ask another to post the information for you to prevent the conflict or affirm the post so there is no problem. You would post this type of info into wikisources or wikibooks. --akc9000 ^{(talk • contribs • count)} 02:22, 4 July 2007 (UTC)

Hi Howard: I agree there could be a bit of confusion between "routing" (as I define it) and "routing" (in its more narrow definition typically used in the context of Internet engineering) and "router". There was some discussion about this over at Talk:Routing#Definition of routing a few days ago. What I would suggest is to use the more general definition and also state the more narrow definition to avoid confusion.

I would not suggest to use "relay". I've heard this term used before too, but I think only in Internet contexts. I suspect the term arose because "routing" took on too specific a meaning, and then some other term became necessary for the more general idea of path selection. But in the world at large, "routing" seems to be the common term. Here are some usage examples:

• Vehicle routing: selecting paths for vehicles in a transportation network. Studied in Operations research
• Routing in the PSTN: it's path selection again, but was around long before the OSI model
• Kleinberg uses the term "routing" to refer to finding paths in a paper about small world models, which are often used to model social networks and computer networks (and, according to that paper, there's some sort of routing that goes on in neuroanatomy...)
• McGraw Hill Sci-Tech Dictionary: "The assignment of a path by which a message will travel to its destination."

I think these examples also demonstrate that using the term "routing" in the way I'm suggesting is not original research.

I'm not sufficiently familiar with web of trust to know whether there is a notion of path selection that goes on there. But, it's a nice idea that we could look into. Also, I'm not sure how much concepts like the control / forwarding separation transfer to these other settings that also involve routing. More connections are better, but I'm not going to try to shoehorn in weak analogies. Also, I do expect the article will end up being mostly about routing in computer networks, given the expertise of the editors around here... --Nethgirb 02:57, 4 July 2007 (UTC)

Information that is placed in articles

From my converstation with an admin... Looking at your specific articles, I think they could be kept. Forwarding Plane does read like a manual in some parts. Phrases like "the next step" give it an almost how-to feel and should be rewritten or completely removed. The article is actually quite large for such a specific item, and tends to go off into the history of routers/processing. If you cut it down to just the specifics of the forwarding plane, it will probably have a more encyclopedic tone. If it's still not reading very well, maybe redirect it to Router (or whatever appropriate article) and include a section.

Control Plane seems to have the same problem; much of the article focuses on the use/installation/background noise, rather than the actual subject. It's also overly technical. I don't have a clue what "Routers, obviously, have local physical interfaces, and possibly logical subinterfaces, that have addresses in particular IP subnets." means...it's not so obvious. I think you're right that they aren't on a whole encyclopedic, and read like a text-book, but there might be enough information to make a proper article

So please remember that Wiki is not a manual or how to guide. It is not to go into great detail, that is what the cites do.

--akc9000 ^{(talk • contribs • count)} 01:40, 4 July 2007 (UTC)

May I ask you (and the other contributors to this discussion) to take a look at something that may be analogous to the question of the level of detail in Forwarding Plane? As you point out, the forwarding plane article does show history and alternatives, as high-performance routers became more and more highly parallel, as in Parallel Computing. There is a fair analogy, I believe, between the various classification schemes given for parallel computing. The various memory and bus models there have direct relevance to the way that routers have evolved to distributed/parallel processors.

In your opinion, is the Parallel Computing article also too detailed? This is not meant as a challenge, but an attempt to understand the Wikipedia style, and perhaps have both sections benefit. The Talk section for parallel computing also suggests that people are, to varying extents, unhappy. The subjects of parallel computing and distributed forwarding are sufficiently similar that, I suspect, getting them at the same level of history and detail will solve many of the concerns.

The Parellel Computing article is written wrong. It may be deleted at any time. It is already flagged for not having cites. It does not have the proper intro. It is a mess. Things I hope to avoid in our group. It cannot be classified as overtly complex it is to short, but it is too complex for a laymen. A different problem. So please do not use this article as an example.

Actually, it's useful to have an example of what you consider bad. Do you have some examples, in computing or other areas, where you think the level is right? I'm really not sure how I could make parallel computing much simpler other than to say "if the problem lends itself to being split into many smaller pieces, you can improve the performance by splitting the workload over many computational elements." Having recently written some textbook material on parallelism, to go much beyond that, I'm not sure you can avoid being fairly technical. It is not trivial to think of multiple instruction streams, or avoiding interference by multiple processors accessing the same memory.

There are a substantial number of cites in Forwarding Plane, so that isn't the problem. Do you see it adequate simply to say that speedup, given physical limits of the speed of individual hardware components, requires spreading the load over multiple components and leaving it at that? Do you think, for example, that it's useful (I do) to mention that simply adding forwarders gets you a certain distance, but then bottlenecks at an improved performance level due to contention for the shared bus or memory? Howard C. Berkowitz 02:24, 4 July 2007 (UTC)

There is a fundamental issue, that runs throughout Wikipedia, of when something is "too technical". For example, I've found useful articles on pharmacology, but, when I refer a friend who doesn't have much exposure to organic chemistry or molecular pharmacology, the articles might as well have been written in Old Sumerian. With some articles in mathematics, I follow them thoroughly, but I only see the broad outlines in others, and yet others are incomprehensible -- and I know a good deal more math than the average person. The fundamental issue is that some topics are inherently technical, and, to go into the details at all, there may be no way to avoid being technical.

I'm not being facetious when I ask if I stated the problem that Internet speeds are growing ever faster, and routers have to go faster and faster, is it appropriate to say that big fast routers need to be highly parallel, but not how the parallelism works? Is there a level at which I can say, about speeding routers so they can have 40 Gbps interfaces, "Need go fast. Gods say go fast need many processors working in harmony. Much magic. Tell secrets to wrong person and him turn into toad." Howard C. Berkowitz 02:00, 4 July 2007 (UTC)

You can get very technical but the infomation must be presented in such a way that it is not a reference for people who already know the topic. It need an intro for a laymen so anyone can grasp the concept first. Then it can get technical but from the intro, anyone must be able to understand what you are talking about.

also remember that what was true that is not true now must be preserved. So, when we talk about the Internet core and the Core router article that explains what a core router is on the Internet, just because the core no longer exists does not mean that the article gets revised. What happens is what I did. There is a pointer to the subject concerning the core and then another pointer to your reference in Router to what a core router is. Wiki has to keep and preserve what was along with what is.

A great example of this that I love is, the article on the battery size b. Whens the last time you saw a b battery? But the article remains. I need to go update that. In any event I hope you see my point. --akc9000 ^{(talk • contribs • count)} 02:31, 4 July 2007 (UTC)

Removed Merge Tag added Function section

Routing tables are stored and used as well as created in end copmputers. This would mean there is a much broader scope that just in a phys. router. Although one could argue that the network card in a pc is a router, the laymen will not see this. Therefore this article can stand on its own. Furthermore I have expanded this article with the Function part and added a few term so we could place redirects to the proper section. --akc9000 ^{(talk • contribs • count)} 17:33, 4 July 2007 (UTC)

Possible Plagiarism

Paragraphs 4 through 7 of the "Basics" section are a direct copy/paste from the "Routing and Switching Companion Guide" by Cisco Networking Academy. In my hard copy of the text, the passage is from page 202. I was thinking this should be added to the references, or changed so that it is not a word for word copy. Pmmeyourghosts (talk) 10:33, 30 January 2015 (UTC)

Section For OS specific details appropriate?

Hi. I understand that OS specific details are not appropriate for a top level concept page like this one "routing tables". However, after reading this article and the Forward Information Base article, the FreeBSD implementation of routing tables does not seem to follow these articles' nomenclature.

For example, from what I understand, in FreeBSD, the kernel routing tables are called FIB, and the routing daemon routing tables are called RIB. I am assuming that the FIB is a compiled version of the RIB, based on the Forward Information Base Wikipedia article. Also, the FreeBSD kernel compile option ROUTETABLES=n adjusts the number of FIB, and the kernel boot option net.fibs=n adjust the number of FIB at boot. There is no run time adjustment. Some software has switch -F n to select the FIB to use, other software requires setfib(1).

Irregardless of whether or not the above paragraph is true, is there any way to get a brief section detailing the language of each major kernel (Linux, FreeBSD, OpenBSD, NetBSD, etc.), and how they differ or how they are similar. The idea is that a person reading the concept article could then read the kernel specific section to get a better understanding and a clear path to more detailed exploration for that specific kernel.