I need to understand why routing protocols like BGP use port 179 , and eigrp uses port 88 etc etc
But IGRP does not use port number and use IP directly on protocol number 9. Need to understand the functionality of the routing protocols w.r.t port numbers??
BGP uses TCP (port 179) to provide an additional layer of Reliability
BGP 4 protocol is not interested in communicating a full knowledge of every subnet within the
organization. It takes summarization to the extreme, communicating only that which is defined,
as necessary.The routing update carries a list of autonomous system numbers and aggregated
prefix addresses, as well as some policy routing information. The little information that it
carries is extremely important, so great efforts are made to ensure the reliability of the transport
carrying the updates and to ensure that the databases are synchronized. This is the pinnacle of
hierarchical routing design. Because of this fact, the transport medium for BGP is TCP, which
provides an additional layer of reliability.
Other routing Protocol (Layer 3)
EIGRP/IGRP packets are encapsulated directly in IP with the protocol field set to 88(for EIGRP) & set to 9 (for IGRP)
EIGRP packet delivery is handled using Reliable Transport Protocol (RTP) which ensures delivery in order using Reliable Multicast on the multicast address 126.96.36.199.
Hope this help:)
Okay, for each protocol....
-- EIGRP uses an IP protocol number to distinguish EIGRP packets from other IP packets on the wire. Note that the destination address (the multicast address) is stripped out of the packet before it hits the EIGRP process, so we can't tell what the destination IP addess of a packet is within EIGRP, AFAIK. EIGRP uses port numbers within this IP protocol number to differentiate process numbers, or autonomous systems. Hence, an EIGRP process with the number 88 would send packets to the EIGRP IP protocol, unicast or multicast on 188.8.131.52, with a port number of 88.
-- OSPF only uses the IP type, not a port number, the two multicast addresses (all dr routers, and all spf routers), and unicast addresses to send packets. OSPF doesn't use a port number, as far as I know, since there's no concept of an autonomous system.
-- IS-IS uses a different ethertype, since it doesn't ride on IP at all. If it ever did ride on IP, it would have an IP protocol type, and no port number.
-- BGP uses TCP on top of IP as its transport. So, a BGP packet would have an IP TCP protocol type, and then a TCP port number indicating the TCP session. One end of the session will use port 179, the other end an ephemeral port, as all TCP sessions to well known services do.
Just to add to Russ's list,
RIP uses udp port 520 and IGRP uses IP protocol number 9.
Hope this helps,
Want to know RIP being a layer 3 protocol why need a UDP port number which is layer 4 information as IGRP does not use any port number or layer 4 information.
That is a good question. They could have decided back then to go with an IP protocol number instead of a UDP port. I am unfortunately not aware of what was the reasoning behind going with a UDP port instead.
I'm going to add my 2 Euro-cent-worth, and risk being controversial.
From the architectural point of view, it has always seemed strange to me that any routing protocol that maintains a network-layer routing table should use IP (let alone TCP) as its transport. It's like picking yourself up by your own bootlaces.
After all, routing updates (and even LSAs) travel on single links, with each router in the path intervening in some way or other, even if only to propagate the flooding.
(Yes, I know there seem to be exceptions such as BGP and virtual links in OSPF, but I don't think that's what they had in mind when they picked on the transport for each routing protocol.)
In fact, using your network-layer to carry your network-layer-control can only work because either the control PDUs are valid for one link only, or there is another routing table control mechanism underpinning it. (For example, an OSPF virtual link works only if you have a route to the remote ABR, that is usually learned from the intra-area of the transit area, which is flooded from router to router. If that makes sense.)
You can pick yourself up by your own bootlaces, but only if you pass the bootlace over a pulley attached to the ceiling.
It seems to me that the only protocol that got the architecture right was IS-IS, which uses a link-layer protocol as transport, and should therefore be capable of setting up routes for any arbitrary network-layer protocol.
I know it's only academic now, but what does anyone else think?
This is a huge area of disgreement within the IETF community.... The primary advantage of using IP as your transport seems to be that you can support any media without a lot more work (without any more work). Other than this, IP takes care of fragmentation for you, in IPv4 (not in v6, of course).
The advantage to running directly over the L2 protocol is that you're less vulnerable to security issues, and you stay out of the common IP queue on most IP stack implementations.
It's hard to judge which of these two is better, where the best tradeoff lies....
Programs that implement routing protocols are normally processes running on a box.
The port numbers are usually intended to separate processes within the same box
(or discriminate between various points of attachment within a process).
Just because a routing protocol is associated with a port number and its
packets are encapsulated in IP datagrams, that doesn't make it a high level protocol.
According to the OSI jargon, a layer uses services offered by layers below,
and provides services to the layers above.
Layer 3 is supposed to provide the end-to-end delivery of packets service to the layers above it.
This means there is some encapsulation and a way to find out the path to the destination.
Routing protocols are an integral part of IP, although they might partly run as applications.
I do not think the IP specific routing protocol specifications had the goal to follow
the OSI reference model and failed.
I agree with Russ that ease of implementation must have been the main reason
for bare IP service re-use. (Or UDP/TCP code re-use.)
On the other hand, I am not surprised an ISO protocol such as IS-IS, which was intended
to support CLNP in the ISO CLNS environment "got the architecture right".
The OSI reference model was also defined by ISO,
so IS-IS would better got the architecture right!
Despite the code re-use reason, there had been made different design choices,
according to specific protocol's needs for reliability.
Some different design choices result in different capabilities and limitations for each protocol,
although fundamentally all accomplish the same task.
I think it's nice to have a broad collection of routing protocols to choose from,
according to needs and personal taste.
Thanks Russ and Maria for your thoughts on this subject.
The way I like to think of this ( ... read "the way I shoehorn this into my mindmap of the OSI model" ... ) is that the IETF routing protocols use IP or TCP as though it (IP or TCP) were a link-layer protocol.
I guess you could also view them as applications that happen control layer-3, in the same way that my Network Management Station application controls my campus LAN.
There is no concept of a virtual link in IS-IS, is there? Hmmm .... ;-)
No, no concept of virtual links in IS-IS.... This is probably a blessing in disguise, in some ways, too. :-) I would guess a large number of the bugs through code complexity in OSPF result from optimizing the virtual link concept, especically when you get to iSPF and other such really find optimizations....
There's always good and bad things in all these concepts....
I don't think it would have been in the ethos of IS-IS to ride over IP. In the late '80s I was working for Retix, which was very OSI based. The word was that this IP stuff was just a workaround to tide us over until OSI got on its feet - it would fade out eventually. So OSI certainly would not have used anything so ephemeral to carry their routing protocol.
Right ... and by the end of the 20th century the world's computing needs were be met by just 6 mainframes ... according to an IBM prediction in the late '60s
Thanks for the information. I understand with the explaination of MAYANK (msdesai) and yours for why BGP used port number.
But got little doubt with your explaination for EIGRP.
As you stated "EIGRP uses port numbers within this IP protocol number to differentiate process numbers, or autonomous systems. Hence, an EIGRP process with the number 88 would send packets to the EIGRP IP protocol, unicast or multicast on 184.108.40.206, with a port number of 88"
The port numbers which EIGRP uses in IP protocol number is this port numbers are layer 4 port numbers or just port numbers to differtiate the EIGRP process or autonomous number. Also are this port number really inside the IP protocol feild or encapulated the IP protocol like layer 4 ports number do. Also that means if we use EIGRP process 120 the port number will be 120 to differentiate the EIGRP process from other.
Will wait for some more light from your side on EIGRP.
Thanks again for all your help.
The number that follows the router eigrp is the Autonomous System number. This is carried in a field of the special EIGRP protocol (which BTW runs over IP protocol 88). You could consider the AS field as a sort of special port number. If two routers are in different AS numbers, they will not form adjacencies. Thus it is possible to have two different AS numbers on your network to create two EIGRP domains that pass like ships in the night.
Hope this answers the question.
EIGRP is IP protocol 88. Within the packets, there is a "port" or "socket" number, as we call it, which is based on the AS number (the number after the ip router eigrp statement, as Kevin says. So, to look at it another way:
-- IP Input (the process) pushes packets to TCP.
-- TCP pushes these packets to a "socket queue," based on the port number (socket number), which is assigned per process.
-- IP Input (the process) pushes all EIGRP packets at the EIGRP hello process.
-- The EIGRP hello process puts individual EIGRP packets on a socket queue, based on the EIGRP AS number.
It's not quite that way, but it's easiest to think of it that way, when you're considering the way EIGRP works. You can see the AS number in the packet as a field to differentiate between processes on a single router, or you can see it as a "socket number" whereby the inbound packet processing code figures out which process to send the packet to.
Either way, you're right--the result is the same. It's a matter of terminology, and how it's easiest for you to understand it....