Talk:Routing table

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)

Multiple tables vs. single table

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

It would be good to have discussion of cache and other acceleration techniques here or in Routing or Router (computing). ~Kvng (talk) 15:37, 24 January 2022 (UTC)

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)

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)

I've done a diff and the only piece of these paragraphs that still exists in the current article is a routing table is a data file in ram that is used to store route information about directly connected and remote networks. ~Kvng (talk) 15:37, 24 January 2022 (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. — Preceding unsigned comment added by 70.231.128.66 (talk) 01:29, 4 November 2015 (UTC)