Talk:Open Shortest Path First/Archive 1
 | This is an archive of past discussions about Open Shortest Path First. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 |
A good introduction article
I think this guy has done a good job on introducing the topic. Its a little Cisco oriented, but unlike the corporate literature, his writting style is human, or what Art Kleiner call "native" in his book The Age of Heretics.
One thing that I found confusing though, what is the explicit message behind this paragraph? Does he imply that OSPF can not scale? I am betting its communication problem as the guy seems to know his stuff really well
"The U.S. Post Office is putting in 38,000 Cisco routers. Note that if we use our rules of thumb, 38,000 divided by 100 routers says we'd need 380 areas. Alternatives include multiple OSPF AS's, and other protocols (like EIGRP). I'd very definitely want healthy route summarization in such a network. Note that since OSPF only allows us to summarize at ABR's, we can only have one level of summarization. With 38,000 routers, we might well want to summarize at the regional, state, and portion of state levels. That can't be done with pure OSPF." [1]
- I know Pete Welcher, the author of that link, and have discussed the project with him. Let me put in my own opinion. First, OSPF probably could not scale to 38,000 routers and probably at least times that in subnets. Within a single OSPF process, you only have one level of summarization. Do you create one area for each of the three-digit regional prefixes of ZIP codes? What is an administrative hierarchy that makes sense?
- For this sort of network, I'd establish a number of OSPF domains (i.e., an area 0.0.0.0 and some number of nonzero areas), and interconnect them with a backbone-of-backbones running BGP. That is about as scalable a technique as we know. Yes, OSPF is faster converging with a reasonable number of routers and subnets, but making the whole service one relatively flat domain makes you extremely vulnerable to anything going into oscillation.Hcberkowitz 21:07, 14 June 2007 (UTC)
I reverted my unvandalisation, removing the IPstack template, because it's the template which has been vandalised. I don't know how to remove the link to 'ANUS' from it.
MD5 to authenticate ?
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.
I dont know much about OSPF or Networking, but what I know is MD5 is used for verifying Integrity and not for authentication. May be the line " OSPF Protocol can operate (communicate with other routers about "best-path" routes to save in their LSDBs) securely, using MD5 to authenticate peers before forming adjacencies" shall be considered for correction.
--Empit 21:54, 13 April 2007 (UTC)
- OSPF routers can transmit MD5-hashed password in Hello packets to authenticate adjacent routers. MD5 hashing is a basic protection against sniffing the password.
- OSPF also supports plaintext passwords. I've had situations where we were not especially concerned with sniffing as a danger, but were in the process of combining OSPF networks of two merged companies. As we converted, we used one password for each of the old networks and another password for the merged network. This kept us from accidentally picking up routers that weren't converted to the new conventions. With our particular router vendor, there were easy-to-code but also easy-to-pick-up-garbage configuration options that could easily bring in things we didn't want in the merged system. If the passwords didn't match, that ended the possibility of a mixed environment.Hcberkowitz 21:11, 14 June 2007 (UTC)
Full Disclosure and All That
In the section I added on OSPF Applications, I did cite one of my peer-reviewed NANOG presentations, along with one by my esteemed colleague, Dave Katz. One of the reasons that most IS-IS implementations tend to work together is that Dave wrote most of them. There are assorted authors of OSPF implementations. Howard C. Berkowitz 23:28, 19 September 2007 (UTC)
Request for further information
I've just tidied up the article, trying to remove duplication and some citations that don't seem to work (not sure if this was a previous way of doing references?)
Anyway, the thing I don't get from reading the article is how OSPF actually works. It would be really helpful if someone who understands this (and I don't) could write a section on how routes are actually exchanged between routers, and how the optimum routes are actually calculated. Thanks in advance.--Phil Holmes 09:43, 3 October 2007 (UTC)
- Once I get some books out of storage, or maybe without (I've been moving), I can get down to that level in OSPF. Some feedback about how detailed an explanation is appropriate here would be useful, as this easily gets to be book-length if all is covered.
- Let make some brief comments, just to give a flavor. Some of these are already covered, to some extent, my question is how much more detail is appropriate. It's purely my opinion, but I tend to think packet functios, but not formats, are appropriate for an encyclopedia. OSPF has a standard header on packets it sends out, which should be understood do not use any transport protocol.
- When reliable delivery is important, OSPF does its own retransmission. Are the mechanics of that retransmission relevant, especially because it has fault-tolerance mechanisms to allow the Backup Designated Router to take over if the DR goes down?
- Standard header discussion?
- I should note that things are reasonably straightforward on broadcast (e.g., LAN) and point-to-point media. Things get significantly more complicated on nonbroadcast multiaccess (NBMA, such as Frame Relay) or demand (e.g., dialup).
There are a reasonably small number of packet types; the real complexity is in the Link State Announcements (LSA) that most of them carry:
- Hello
- Database Description packet
- The Link State Request packet
- Link State Update packet
- The Link State Acknowledgment packet
- All but the Hello packet carry one or more LSAs, either in summary or full form. There is what I'd call a basic set of LSAs, and then a newer group, typically used for optional capabilities such as traffic engineering, that need considerably more explanation. Here's the basic set, ignoring two obsolete types:
- Router
- Network
- Summary (two subtypes)
- External (two major subtypes, and subcategories of those)
- My question to you and all other people concerned: is this level of list, with narrative explanations, adequate for an encyclopedia? Obviously, I haven't gotten into things like how the initialization of new routers' databases takes place, how routes are added and deleted within an area, what packets go in or out of areas, how the basic intra-area computation works (with several versions, some vendor-dependent), how inter-area and externals work if the area type permits them. That's a start. Howard C. Berkowitz 11:09, 3 October 2007 (UTC)
- For me, I think I could summarise what I see as important by asking "how does the forwarding/routing table get populated?". So I think the details of packet headers, transmission mechanisms, transmission reliability, etc., are not needed for an encyclopedia article. But how the routers learn routes from each other - that seems to me to be the fundamental function of OSPF, and therefore the fundamental "how to" need.
- I hope that's helpful. --Phil Holmes 14:58, 3 October 2007 (UTC)
Initial Comments
TYPE 5 does equal AS External, HELLO???????? —Preceding unsigned comment added by 206.126.163.20 (talk) 16:32, 23 January 2008 (UTC)
type 5, eh??
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum 0.0.0.0 2.2.2.2 20 0x80000001 0x75C0 6.0.0.0 2.2.2.2 13 0x80000001 0x2709
—Preceding unsigned comment added by 206.126.163.20 (talk) 16:29, 23 January 2008 (UTC)
- The remark concerning Type 5 advertisements and Stub Areas is in fact correct. Type 5 carries AS-external routing information, and a Stub Area only has one connection towards the backbone, thereby eliminating the need for a detailled routing information. Stub Areas are usually only fed a default route and maybe the AS-internal routes (Type 1-4), but they don't need to know about the AS-external routes. Sigkill 02:06, 1 July 2006 (UTC)
"Intra-area routing goes via the backbone"
Is this really correct? It would seem more logical if inter-area routing was done via the backbone. --K. Sperling 10:33, July 20, 2005 (UTC)
- True, and is corrected meanwhile. Sigkill 02:06, 1 July 2006 (UTC)
"In contrast to RIP or BGP, OSPF does not use TCP or UDP but uses IP directly, using IP protocol 89."
This sounds incorrect Routers are layer 3 devices so how can they use Transport Layer, Layer 4, services?
- While some routing protocols use L4 transports (such as tcp/179 for BGP or udp/520 for RIP), others bring their own L4 protocol (such as (E)IGRP with L4-protcol number 88 or OSPF with L4-protocol number 89). You should distinguish between the actual routing task running on Layer 3, and the inter-router communication, which uses higher-level protocols. Sigkill 02:06, 1 July 2006 (UTC)
- I'd hesitate to call the protocol number layer 4. By protocol number, I refer to a field in the IP packet header, which identifies what the packet carries if not pure IP. It can be TCP or UDP, but also ICMP or OSPF or EIGRP. OSPF has its own reliable delivery mechanism with retransmissions and other features built into the protocol, but with lower overhead than TCP. Be careful before trying to force routing protocols into OSI layers, because (1) IP routing protocols were designed without OSI compliance as a goal, and (2) additional ISO documents, such as "OSI Routeing [sic] Framework", identify routing protocols as layer management protocols of the network layer. Layer management is defined in an annex to the basic OSI reference model. Hcberkowitz 21:15, 14 June 2007 (UTC)
Could a list of entry level Products which support OSPF be added, so others can learn by 'doing'?
- Added meanwhile. Sigkill 02:06, 1 July 2006 (UTC)
implementation -- why no mention of hardware/appliance vendors?
I appreciate that Wikipedia is open-source-centric and all, but really, in a discussion of the implementations of OSPF there should be something said about Cisco, HP, Nortel/Bay, Extreme, Juniper and the plethora of other mainstream hardware vendors whose devices implement OSPF. Of particular interest would be a chart that compares the support for OSPF v2 versus OSPF v3, vendor extensions and limitations and other information that might be of use to someone doing a vendor comparison, especially to help someone from not falling into the trap of buying a vendor-proprietary extension. —Preceding unsigned comment added by 129.97.15.226 (talk) 19:00, 21 August 2009 (UTC)
Stub area definition
I recently removed an incorrect statement in the paragraph on stub areas (the statement that a stub area can contain only one router). This was then erroneously reverted, the reason given being: "A stub area only has one exit route, thus it has only one router".
Firstly, the statement that a stub area has only one exit route is incorrect. While real-world stub areas will commonly only have a single exit point, this is not a requirement.
Secondly, it's entirely possible (and not uncommon) to have a number of OSPF-speaking routers in a stub area. The stipulations of a stub area are that external routes should not be advertised into the area, and that all routers in a stub area are aware that the area is a stub area. A default route would commonly be advertised into the area by the ABR, but even this is not a requirement.
Rather than simply reverting the reversion, only to be once more incorrectly reverted, maybe a discussion is warranted to clear up this misunderstanding. —Preceding unsigned comment added by 213.94.198.249 (talk) 18:03, 11 September 2009 (UTC)
- I think this is to some degree an issue of POV, as a stub area can have many levels of complexity internally. We shouldn't even be so specific in a general purpose article. However, the RFC seems specific that routing is based entirely on a default route which must be advertised into the area. The router awareness of the stub is a feature or enforcement of the protocol itself. I hope you can agree with my changes. Kbrose (talk) 17:10, 17 September 2009 (UTC)
Addition of OSPF Types and LSA Types
I've already added the OSPF Types (according to RFC 3540) and am interested in creating another section on LSA Types, but am lost as to how to proceed.
Should I break the LSAs into OSPFv2 and OSPFv3 or should I combine the two into a single section and make a note of which ones are supported only by OSPFv3?
Likewise, there are some IPv6 specific "Prefix Options" which are ONLY supported by IPv6 and again, I'm at a lost as to how/where to add mention of that. Perhaps a new section? But I don't want to muddy up the wiki page!
If anybody has any ideas on how I should go about breaking them up or combining them together, I'd like to hear those voices prior to me creating the material.
--wbenton (talk) 01:57, 2 March 2010 (UTC)
RFC history
I think that having a huge table of RFCs is not useful at all and the same goes for their graph, so I removed the section from the article. Because it may be useful, if someone wanted to rewrite that section in a better way, I copied the section's contents below. Svick (talk) 01:45, 25 June 2010 (UTC)
RFC history
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The following image gives a visual view of how the older OSPF related RFCs have transpired into their current state today.
|
ROSPF (Radio-OSPF)
a variant of Open Shortest Path First (OSPF) that is called Radio-OSPF (ROSPF). ROSPF does not use the OSPF hello protocol for link discovery, etc. Instead, OSPF adjacencies are created and destroyed as a function of MANET information that is distributed by the NTDR routers, both cluster heads and cluster members.
Read about this patent @ http://bbn.com/resources/pdf/6,977,937.pdf —Preceding unsigned comment added by 75.9.141.234 (talk) 02:25, 15 April 2011 (UTC)
Configuration corner
What do people think about the recently added Open Shortest Path First#OSPF Configuration Corner? I have suggested here that it is not suitable and we would like other comments. Johnuniq (talk) 08:19, 13 May 2012 (UTC)
- WP:NOTHOWTO certainly applies. No place for it here IMO. — Dgtsyb (talk) 13:21, 20 May 2012 (UTC)
External link clutter
The External Links section has become a morass of clutter with very few links that meet the requirements of WP:EL. I'm removing some of the most blatant commercial links now. Can we discuss links (especially new links) on the Talk page? — UncleBubba ( T @ C ) 03:56, 9 December 2011 (UTC)
Found an external link that is no longer working that is referenced under Stub Area... http://www.visualland.net/view.php?cid=760 I think that whole domain has gone away. Cpostier (talk) 15:38, 27 September 2012 (UTC)Christian
Stub area — edit to intro
I just wanted to explain edit 614012779 since it was reverted. This duplicates my comment on Johnuniq's Talk page.
The Not-so-stubby area was already introduced and is not a proprietary extension (it has an RFC). The two proprietary extensions discussed by the article are Totally stubby area and NSSA totally stubby area. I believe the sentence I edited intended to introduce these.
@Johnuniq: Indeed, NSSA is 'Not-so-stubby area', but both Stub area and NSSA have proprietary variants called Totally stubby area and NSSA totally stubby area. These are described in the sections just below. Trackpick (talk) 04:46, 23 June 2014 (UTC)
- OK. It's a while since I thought about this article or the topic. Happy editing! Johnuniq (talk) 06:09, 23 June 2014 (UTC)
Link Layer or Network Layer?
I want to point out that I believe this protocol is in the wrong OSI layer. The RFC, RFC #2328, specifies this runs over the network (IP) layer protocol.
From Section A.1 of the RFC:
A.1 Encapsulation of OSPF packets OSPF runs directly over the Internet Protocol's network layer. OSPF packets are therefore encapsulated solely by IP and local data-link headers.
I'm thinking this might classify OSPF as layer 3. Please let me know what you think.
LostTemplar (talk) 21:48, 27 March 2009 (UTC)
- I agree with you completely, LostTemplar. OSPF definately runs over IP. If you don't have IP running, you have no hope of getting OSPF running. So the link layer, and the IP layer must be up for OSPF to communicate between routers. Are you looking at how OSPF shows up in the link-layer section of the box in the upper right? —fudoreaper (talk) 07:47, 29 March 2009 (UTC)
- First of all, you cannot use the terms Link Layer and Network Layer (aka Layer 3) in the same statement for comparison. They are from different models, and the comparison becomes completely meaningless when dealing with the subtleties of protocol semantics. RFC 2328 is not the latest OSPF specification and is only valid for IPv4 implementations. In regards to encapsulation: of course IPv4 OSPF (version 2) runs in IP datagrams, that is not the question or puzzle here and is not the criterion TCP/IP uses for categorization. OSPFv2 was indeed considered to run at the IP subnet level, and with its strong ties to IPv4 there was perhaps some justification to place it into the Internet Layer (but not just because of its encapsulation sequence) but does that justify it? TCP/IP does not layer in terms of encapsulation. An IP subnet usually runs on a single link as well, and since OSPF v2 only operates on the link between routers, collecting link states, and is never routed across networks despite using IP datagrams, it really is a Link Layer protocol in the sense of the TCP/IP model as well. In terms of the OSI model, it surely is a Layer 3 protocol, by encapsulation rule as well as the concept that routing protocols in general are often assigned to a network managment category within Layer 3 (no matter what the encapsulation -- funny how the encapsulation requirement may all of a sudden be broken). OSPF for IPv6 has removed all IP address information from all LSAs, except the update payload LSAs, and the protocol has become network-protocol independent. Furthermore, the protocol operates on a 'per-link' basis, not 'per-subnet' anymore, and uses link-local addressing for inter-router communications. The specification explicitely defines the Link Layer operation of OSPF v3. So, the question in the end is how to document a general 'OSPF' protocol in a general audience article. Clearly the newest OSPF developments put it into the Link Layer, but they do not obsolete the IPv4 documents. So, in fact we have two OSPF protocols. One might split the designation and put a link to OSPFv2 into the Internet Layer and OSPFv3 into the Link Layer, or just put the overall term into the Link Layer (since v2 is really a Link Layer protocol). In terms of OSI, go and figure, but don't mix up that discussion and the terms with TCP/IP. OSPF development has been conducted entirely in terms of TCP/IP terminology. Kbrose (talk) 15:45, 29 March 2009 (UTC)
- Both OSPF and EIGRP use multicast packets encapsulated inside multicast layer 2 frames (let it be ethernet, frame-relay, ppp, hdlc). scope of these packets is just link local, this does not mean that ospf works at link layer or eigrp works at link layer. It just means the ttl is 1. the nature of ospf is link-state routing protocol should not mean its only operates at link layer. the highest layer used by ospf for control/management/data plane is internet layer, and not link layer. BGP uses path vector logic, that doesnt mean bgp doesnt fit in the application layer because its scope is between autonomous systems. however ISIS is link layer as clearly frames are involved in transporting in ISIS PDUs. A discussion on this can be found here...https://learningnetwork.cisco.com/thread/82389?tstart=0on Cisco learning network, specifically addressing the wikipedia mentioning ospf under link layer...[1]Pritishp333 (talk) 08:23, 12 March 2015 (UTC)
- First of all, you cannot use the terms Link Layer and Network Layer (aka Layer 3) in the same statement for comparison. They are from different models, and the comparison becomes completely meaningless when dealing with the subtleties of protocol semantics. RFC 2328 is not the latest OSPF specification and is only valid for IPv4 implementations. In regards to encapsulation: of course IPv4 OSPF (version 2) runs in IP datagrams, that is not the question or puzzle here and is not the criterion TCP/IP uses for categorization. OSPFv2 was indeed considered to run at the IP subnet level, and with its strong ties to IPv4 there was perhaps some justification to place it into the Internet Layer (but not just because of its encapsulation sequence) but does that justify it? TCP/IP does not layer in terms of encapsulation. An IP subnet usually runs on a single link as well, and since OSPF v2 only operates on the link between routers, collecting link states, and is never routed across networks despite using IP datagrams, it really is a Link Layer protocol in the sense of the TCP/IP model as well. In terms of the OSI model, it surely is a Layer 3 protocol, by encapsulation rule as well as the concept that routing protocols in general are often assigned to a network managment category within Layer 3 (no matter what the encapsulation -- funny how the encapsulation requirement may all of a sudden be broken). OSPF for IPv6 has removed all IP address information from all LSAs, except the update payload LSAs, and the protocol has become network-protocol independent. Furthermore, the protocol operates on a 'per-link' basis, not 'per-subnet' anymore, and uses link-local addressing for inter-router communications. The specification explicitely defines the Link Layer operation of OSPF v3. So, the question in the end is how to document a general 'OSPF' protocol in a general audience article. Clearly the newest OSPF developments put it into the Link Layer, but they do not obsolete the IPv4 documents. So, in fact we have two OSPF protocols. One might split the designation and put a link to OSPFv2 into the Internet Layer and OSPFv3 into the Link Layer, or just put the overall term into the Link Layer (since v2 is really a Link Layer protocol). In terms of OSI, go and figure, but don't mix up that discussion and the terms with TCP/IP. OSPF development has been conducted entirely in terms of TCP/IP terminology. Kbrose (talk) 15:45, 29 March 2009 (UTC)
fudoreaper and Kbrose, thank you for your feedback. fudoreaper, yes, you are right; I was referring to the placement of OSPF in the upper-right box.
I see your point about the IPv4 and IPv6 versions of OSP, Kbrose. Yes, you are right about the differences in TCP/IP, and OSI. I'm thinking this might be more of an issue of Wikipedia considering the entire protocol stack as part of TCP/IP. Correct me if I'm wrong, but I think a year or so earlier, the protocols were listed under the OSI stack rather than the TCP/IP. IMO, this makes it more easy to follow. Some vendors prefer to follow the OSI layer when implementing a particular protocol. I shall have a look around and get some references.
LostTemplar (talk) 04:15, 31 March 2009 (UTC)
- I don't really see any evidence that anyone is using OSI to design network protocols anymore. The few vendors that are actually designing new protocols, if they want to have any chance of wide-spread use, align themselves with an IETF work group usually and the IETF virtually never refers to OSI, and, for example, Microsoft as a proprietary developer usually, seems to use the TCP/IP model terminology as well, see for example, the description of LLTD, as a Link Layer protocol. OSPF was a TCP/IP centric protocol since start, and the v3 specs make this even clearer. The only significant use of OSI terms seems to be for descriptions by hardware designers in the hardware layers and data link layers, occasionally referring to L3 as well. But the new technologies developed today in the physical layer and L2 are often so complicated that they have their own detailed layering terminologies and even the OSI sublayers of L2 don't do them much good.
- As far as the WP past is concerned, it seems to me that it was more or less a vast disorder of interpretations without much reliance on the original, primary sources of these things. I think some of this resulted from the use of secondary sources, often foreign language text books, that loosely translate technical terms (and get loosely translated back to English) and mix in their own interpretations. Much of this still persists. Kbrose (talk) 14:56, 31 March 2009 (UTC)
- I have said it, I'll say it again OSPF is NOT a link layer Protocol. Need an explanation? read here what the Industry Experts (Specifically Cisco VIP Scott Morris-CCDE/4xCCIE/2xJNCIE) have to say https://learningnetwork.cisco.com/thread/82389?start=30&tstart=0 Pritishp333 (talk) 16:53, 19 May 2015 (UTC)
I find it really confusing to be saying that it is a link layer protocol. Yes, it cares about link state etc. and does not propagate further than the LAN. But you could say the same about games which implement multicast discovery for LAN support. They're however not link layer protocols in the sense that they don't provide link-layer services: they are obviously not physical link layers, but they are also *not* data link layers: they do not transfer data for higher protocols, they just happen to operate on the link layer for other layers to work better (IP for OSPF).
That's really confusing for any people trying to understand how networks protocols are basically organized, and have a look at wikipedia to get a clue. OSPF really belongs next to IP in that regard. Isn't that what matters in the end?