I agree. And I was also believed this only. But when I captured using Wireshark in a Layer 2 environment, I am able to see OSPF packets. That is what Wikipedia is trying to say. Then, is Wikipedia is right? or its a contradiction?

All OSPF packet's TTL is 1 whatever it is hello packet or LSA exchange packet. Hello packet use multicast address 225.0.0.5/6 to discovery neighbor and keep track of them. However LSA exchange use unicast IP to exchange LSA update.

OSPF working as routing protocol, its primary and only task is to build routing table independently. In other words, OSPF can generate routing table without any help of any other routing protocol. This means OSPF must work on the local link. If OSPF can traverse beyond the local link, OSPF need the routing table to help routing OSPF packet. This is totally not acceptable.

It is an interesting approach to say that since OSPF packets are not forwarded that OSPF is a link layer protocol. But I believe that this is fundamentally not the correct analysis of the layer for OSPF. Its function is to contribute to IP routing which is clearly a layer 3 function. And there is an IP protocol number allocated for OSPF. If it were a layer 2 protocol there would be no need for an IP protocol number.

I believe that there are valid arguments that OSPF operates at a layer higher than layer 3 and that it legitimately can be treated as an application layer process.

HTH

Rick

Thank Richard very much for the comments.

It is no doubt that OSPF works on top of IP layer as its IP protocol type 89. But all OSPF packets are limited to only local link as its TTL=1. When LSA update need flooding to the whole area, LSA update are advertised to directly connected neighbor. After the directly connected neighbors receive the LSA update, they extract the LSA and repacket the LSA, then advertised to their directly neighbors until all the OSPF routers in this area get this LSA update.

You seem to agree with my point that OSPF has an IP protocol number of 89 and therefore works on top of IP layer. Which means it is at least layer 3 or probably higher and not layer 2 as the original post asks. You then have a good explanation of the flooding process. But I am not clear what, if anything, that says about the layer that OSPF operates at.

HTH

Rick

Yes, I totally disagree with OSPF working on data link layer.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Please allow me to join.

No - stay away - shoo.  (Laugh)

Seriously, Peter, thanks for jumping in.

Your compilation of other support forum links on this subject - very nice!

I think at one time, in a similar subject thread, I posted the ISO reference document, that distinguished routing protocols from their model.  If I did once post such, I don't think it's in the set you've listed.  (Such might be another document, besides your ATM reference link, that makes clear routing protocols don't fall directly into the OSI model.)

This evening, returning from work, I thought of another interesting consideration.  Peter's posting got me to think of a couple more.

Let's consider a topology running both OSPF and EIGRP covering all the same links/networks.  I.e. effectively, both protocols have the same identical topology.

On Cisco platforms, by default, EIGRP has a better AD metric than EIGRP, so each L3 device's route table would be populated by EIGRP.  In such a case, OSPF wouldn't have any bearing on the network's actual L3 operation.  Yet, OSPF is still running on all the L3 devices, it "knows" the topology and will keep itself sync'ed with the current topology.

What I just described, isn't much different from Packet Design's Route Explorer, which taps into OSPF's LSAs.  We don't, or a least I don't, say Route Explorer is a L2, or L3 protocol.

Or, somewhat along the same line, we might run MTRG, monitoring every interface.  It uses SNMP to query different devices, but do we say that MTRG is a L2 or L3 protocol?

Everyone might agree Route Explorer and MTRG are network applications.  Routing protocols, like OSPF, to me, are also network applications, they, however, are applications that support L3, but they are not L3.

Consider NTP.  It's a network application that runs across the network, that works to insure the local system clock is accurate, but it's not the clock.

The reason I mentioned NTP because it dynamically keeps the clock accurate, but the clock continues to function, without it.  It can also be manually set.

Likewise, a routing protocol like OSPF can dynamically keep L3 information accurate, but routing can function without it.  Routing information can also be manually set.

Finally, consider Cisco's PfR.  It can share information from multiple routers, it dynamically injects and/or remove routes, it can make decisions based on link loading, latency, packet loss, QoS policies, etc.  Do we call this a network application or a L3 or L4 protocol?

I very, very seldom disagree with Peter, and when I do he often nicely shows me the error of my ways (and maybe he will here too - hehe), but I believe routing protocols are best understood as network applications that dynamically provide information to L3.  For communication, routing protocols use whatever other layers they believe they need, just as do other network applications, where one might chose UDP to communicate and another TCP.

Ah, Rolf referenced the thread where I posted links to the ISO documents I was referencing.

Thanks.