cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31251
Views
117
Helpful
14
Replies

EIGRP & OSPF Layer 3 or 4 ?

Umesh Shetty
Level 1
Level 1

Hi All,           

One question thats seems to get so many diferent and contradicting anwers , I am confused too , while if we were apply the OSI layer theory, that every layer uses the layer below it to be able to complete the end to end transmission. TCP ( Layer 4)  uses IP (Layer 3). When IP receives a TCP segment it marks the Protocol Number feild in the IP header as 6 which then helps the final receiver ( the destination IP in the IP Header)  of the IP packet to understand tht it needs to hand over the packet to TCP for further processing. The same thing happens with EIGRP ( Protocol number 88) and OSPF ( Protocol number 89) .

One of the refernces in the link below says

http://technet.microsoft.com/en-us/library/cc959827.aspx

"In an IP header, the Protocol field identifies the service in the next higher level in the protocol stack to which data is passed."

Theoretically if EIGRP & OSPF uses IP they are supposed to be at a layer above IP ie Layer 4.

I've often read OSPF and EIGRP being termed as Layer 3 and have had trouble finding out why?  I am hoping that I get some good lessons from all who know this better.

Thanks in Advance

Umesh

2 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Umesh, Nish, Jon,

Positioning of protocols to layers is often a point of contention, as Jon has very clearly stated.

First of all, trying to squeeze TCP/IP protocols into OSI terminology is bound to fail at some point because TCP/IP was not designed according to OSI model, never observed it, nor was trying to emulate or mimic it. Just because TCP/IP and OSI are similar does not mean you can cleanly do the mapping of protocols in TCP/IP into layers of OSI. Many misunderstandings about the protocol placement are rooted here.

Second, most approaches use a gross simplification: they believe that "if the messages of protocol ABC are placed into datagrams of Layer N, then the protocol ABC must be on Layer N+1". This premise is illustrative but it is not definitoric, and therefore not universally true. Layers are defined by services they provide , not by services they depend on. No offense intended but I really wish all those people who make very categorical and resolute statements about this protocol being in Layer X and that protocol being in Layer Y in fact read the OSI layer specifications to see how the layers are defined, and only then made their judgements. Anyone interested - please see http://www.itu.int/ITU-T/recommendations/index.aspx?ser=X and the X.200 series of recommendations. Good reading for long winter evenings (sorta... )

Third, the layering works well for data flows if each layer already somehow, automagically, knows all the necessary information required to complete its task. However, the control of individual layers, i.e. creating and communicating the information that directs the operation of each layer (routing table contents, MAC table contents, load sharing table contents, etc.) reaches beyond the layering model and often, it plainly violates it just in order to make it simple and work. For example, BGP delivers control information for the internetwork (or the OSI network) layer. But BGP runs over TCP. Is BGP an application layer protocol? No, it isn't - because it does not deliver/provide application-layer services! The fact it runs over TCP is irrelevant. BGP provides control information for the network layer, and should thus be considered a Layer3 control protocol. Or, think of the interrelation of TCP MSS and MTU. The MTU is the maximum payload size of a Layer2 frame. The MSS is the maximum payload size of the Layer4 segment. How would TCP, a Layer4 protocol, know about Layer2 payload size limitations if the strict layering was observed? Well, here, because the size of MTU and MSS constitutes a control information, the layering is not observed that strictly.

With respect to any routing protocol - my personal opinion is that a routing protocol creates and communicates the control information to allow the network layer do its job. The protocol may run over Layer2 frames such as IS-IS, it may run directly over IP just like OSPF or EIGRP, it may run over UDP or TCP as RIP or BGP do... that does not really matter. None of IS-IS, OSPF, EIGRP, RIP, BGP provide any other service or capability beyond populating routing tables, i.e. data structures defined for and within the network layer operation. Therefore, I personally consider all these routing protocols to sit at Layer3 because their target is the control of Layer3 operation.

My two cents...

Best regards,

Peter

View solution in original post

Joseph W. Doherty
Hall of Fame
Hall of Fame

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 whatsoever (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

And for another opinion . . . (laugh)

Routing protocols are not layer 3 or 4, as they support layer 3 but are not layer 3.  I recall (?) the ITU documents make this clear as routing protocols are documented separately from main OSI model which is about moving the bits/frames/packets, etc.

Consider static routing, what's that?  It's how you, a person, configure, or support layer 3 information, used by the router to make its forwarding/routing decision.  So are network engineers layer 3 too?

IP layer 3 accepts a packet, looks at its destination address, and then makes a routing decision for that packet.  That has nothing to do with how the routing protocol works or how it updates the routing information.  Similarly, the command line syntax for entering static routes, or how "efficiently" (process, optimal, fast, CEF, etc.) the routing lookup is accomplished, supports L3, but it is not L3.

Since routing protocols support L3, how they share their information recognizes they need to be careful how they use the network (inband), they're supporting.  For example, as routing protocols are trying to keep L3 informed of the current topology, they realize there will be times it's out of date, and so generally (logically) don't rely on the network to move routing information between routing peers depending on network L3.  (That's the reason why routing peers usually share physical media and depend on L2 broadcasts and/or multicast.)

If the routing protocol are, themselves, not L3, what are they?  Well, since routing protocol are really dedicated applications, sharing data (which happens to be the L3 topology), I consider them like other services, L7 in OSI, or the application layer in IP.  Again, though, these special "applications" support the network's L3 layer, and might do so using various layers of the network.

Also consider a router's L3 being populated with statics, EIGRP and OSPF.  If these 3 sources all disagree about topology, how is the L3 topology determined?   It's determined by the L3 of the router, not the routing protocols themselves.  (I.e. something with "better" knowledge has to decide what to accept from the routing protocols.)

View solution in original post

14 Replies 14

Nish Vamadevan
Level 1
Level 1

Looks at it this way and see which layer a protocol gets transported by...

EIGRP - Layer 3

OSPF - Layer 3

RIP - Layer 4

BGP - An application transported at Layer 4

Have a look at the packet, especially using wireshark and you will be able to understand how it actually works...

Two wireshark captures here, one is a TCP segment transported by IP at Layer 3 other one an OSPF packet also uses IP at Layer 3. Should you call both OSPF and TCP as working at Layer 4 ?

TCP.jpg

OSPF.jpg

Regards

Umesh

They are transported by Layer 3 so I would personally go with Layer 3 than Layer 4.

Just look at the fields of IP layer you will find that no data could be delivered without any upper layer payload, but only information related to IP addresses within.

So if there is information interaction between two or more devices, why is it the layer 3 that carries things, such as OSPF? It should be layer 4 in my opinion.

Jon Marshall
Hall of Fame
Hall of Fame

Umesh

There are so many contradictory answers because put simply the TCP/IP model does not map very well to the OSI model and so depending on how you look at it you can come up with different answers.

So instead of going through all the arguments for and against let me ask you this.

If the defintion of whether it is L3 or higher is whether it uses IP as a transport then where would you place ICMP ?

I choose this specifically because most (if not all) people would place ICMP at L3. But ICMP also uses IP as a transport so based on the previous definiton you would end up saying it works at a higher level.

For me OSPF etc. are L3 because they do not rely on the transport layer ie. they encapsulate their packets directly into an IP packet. They have their own protocol numbers as opposed to a TCP/UDP port number

But again i would say the primary reason for all the contradictory answers is trying to map two different models to each other and there are people who would disagree with what i have said and i am by no means saying i am right.

Jon

Well said Jon and Thanks Nish for your inputs,

Jon , yes the case of icmp was another argument within the argument. I've heard so many theories on this and hence this tends to confuse me all the time. The best way would be to just know how the protocol funtions and interacts with other layers and not worry too much about the layer and you'll be fine isn't it.

Thanks again

Umesh

Umesh

To be honest you can argue it both ways.

I think you are spot on when you say it is better to just know how the protocols work and how they interact with the other layers rather than worrying about the exact layer.

For me at least, it is more of an academic issue rather than any specific practical one.

Jon

Peter Paluch
Cisco Employee
Cisco Employee

Umesh, Nish, Jon,

Positioning of protocols to layers is often a point of contention, as Jon has very clearly stated.

First of all, trying to squeeze TCP/IP protocols into OSI terminology is bound to fail at some point because TCP/IP was not designed according to OSI model, never observed it, nor was trying to emulate or mimic it. Just because TCP/IP and OSI are similar does not mean you can cleanly do the mapping of protocols in TCP/IP into layers of OSI. Many misunderstandings about the protocol placement are rooted here.

Second, most approaches use a gross simplification: they believe that "if the messages of protocol ABC are placed into datagrams of Layer N, then the protocol ABC must be on Layer N+1". This premise is illustrative but it is not definitoric, and therefore not universally true. Layers are defined by services they provide , not by services they depend on. No offense intended but I really wish all those people who make very categorical and resolute statements about this protocol being in Layer X and that protocol being in Layer Y in fact read the OSI layer specifications to see how the layers are defined, and only then made their judgements. Anyone interested - please see http://www.itu.int/ITU-T/recommendations/index.aspx?ser=X and the X.200 series of recommendations. Good reading for long winter evenings (sorta... )

Third, the layering works well for data flows if each layer already somehow, automagically, knows all the necessary information required to complete its task. However, the control of individual layers, i.e. creating and communicating the information that directs the operation of each layer (routing table contents, MAC table contents, load sharing table contents, etc.) reaches beyond the layering model and often, it plainly violates it just in order to make it simple and work. For example, BGP delivers control information for the internetwork (or the OSI network) layer. But BGP runs over TCP. Is BGP an application layer protocol? No, it isn't - because it does not deliver/provide application-layer services! The fact it runs over TCP is irrelevant. BGP provides control information for the network layer, and should thus be considered a Layer3 control protocol. Or, think of the interrelation of TCP MSS and MTU. The MTU is the maximum payload size of a Layer2 frame. The MSS is the maximum payload size of the Layer4 segment. How would TCP, a Layer4 protocol, know about Layer2 payload size limitations if the strict layering was observed? Well, here, because the size of MTU and MSS constitutes a control information, the layering is not observed that strictly.

With respect to any routing protocol - my personal opinion is that a routing protocol creates and communicates the control information to allow the network layer do its job. The protocol may run over Layer2 frames such as IS-IS, it may run directly over IP just like OSPF or EIGRP, it may run over UDP or TCP as RIP or BGP do... that does not really matter. None of IS-IS, OSPF, EIGRP, RIP, BGP provide any other service or capability beyond populating routing tables, i.e. data structures defined for and within the network layer operation. Therefore, I personally consider all these routing protocols to sit at Layer3 because their target is the control of Layer3 operation.

My two cents...

Best regards,

Peter

Good discussion, but I got one Q, since BGP is tcp based and actually goes through the motions of a proper TCP connection, would you not classify this as layer 4? It is essentially becomes that, right or wrong?

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

Bilal

I think as this discussion has highlighted it is all just people's opinions. Certainly that was what i was trying to say in my original response.

I don't go as far as Peter or rather i see no contradicton between saying BGP is sits in the application layer but it's function is concerned with the network layer.

As Peter notes the rules are not always followed and i personally see the BGP protocol as being implemented to utilse the advantages of the upper layers even though it doesn't actually provide application layer services as such.

If you take the application layer to only be providing application layer services then strictly speaking BGP cannot reside there but as this and many other threads show, "strictly speaking" is a somewhat debatable term when talking about the TCP/IP model.

Again just my opinions.

Jon

Jon,

I don't go as far as Peter or rather i see no contradicton between  saying BGP is sits in the application layer but it's function is  concerned with the network layer. 

Perhaps this is the subtle but important difference - one thing is what layer a protocol "sits in" in terms of encapsulation, and another thing is what services does the protocol provide and which other layer uses them.

Best regards,

Peter

Peter

Agreed and that's where i think the TCP/IP model is somewhat ambiguous in it's terminology.

I'm certainly not saying you are wrong and i am right and i'm pretty sure you know that.

i think we both agree that the BGP function is concerned with the network layer. After that it seems to me to be a contradiction that is really just down to interpretation or, in other words, personal opinion.

The contradiction obviously being that BGP does not directly provide services for upper layers to utilise (or if it does then that puts all routing protocols in the same bracket which clearly isn't the case) but it itself does utilise the upper layers to carry out it's function so technically it sits in the application layer.

I'm just happy to accept the ambiguity because to me the whole TCP/IP model has exceptions in it.

I should also say that, as you know, i have no certifications but i did once hold CCNA. And i specifically remember that the only section i dropped any points on was the network models so i am perhaps not the best person to be answering questions on this

Jon

Joseph W. Doherty
Hall of Fame
Hall of Fame

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 whatsoever (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

And for another opinion . . . (laugh)

Routing protocols are not layer 3 or 4, as they support layer 3 but are not layer 3.  I recall (?) the ITU documents make this clear as routing protocols are documented separately from main OSI model which is about moving the bits/frames/packets, etc.

Consider static routing, what's that?  It's how you, a person, configure, or support layer 3 information, used by the router to make its forwarding/routing decision.  So are network engineers layer 3 too?

IP layer 3 accepts a packet, looks at its destination address, and then makes a routing decision for that packet.  That has nothing to do with how the routing protocol works or how it updates the routing information.  Similarly, the command line syntax for entering static routes, or how "efficiently" (process, optimal, fast, CEF, etc.) the routing lookup is accomplished, supports L3, but it is not L3.

Since routing protocols support L3, how they share their information recognizes they need to be careful how they use the network (inband), they're supporting.  For example, as routing protocols are trying to keep L3 informed of the current topology, they realize there will be times it's out of date, and so generally (logically) don't rely on the network to move routing information between routing peers depending on network L3.  (That's the reason why routing peers usually share physical media and depend on L2 broadcasts and/or multicast.)

If the routing protocol are, themselves, not L3, what are they?  Well, since routing protocol are really dedicated applications, sharing data (which happens to be the L3 topology), I consider them like other services, L7 in OSI, or the application layer in IP.  Again, though, these special "applications" support the network's L3 layer, and might do so using various layers of the network.

Also consider a router's L3 being populated with statics, EIGRP and OSPF.  If these 3 sources all disagree about topology, how is the L3 topology determined?   It's determined by the L3 of the router, not the routing protocols themselves.  (I.e. something with "better" knowledge has to decide what to accept from the routing protocols.)

CiscoLadder
Level 1
Level 1

...and then...which model is one trying to fit a protocol in ? The OSI model or the TCP model...? Just sayin’...

Yea, my profile is ‘beginner’...but I thoroughly enjoyed reading through this post

756259E5-A481-4683-8147-379B149E4921.png

Review Cisco Networking for a $25 gift card