Does EIGRP use AS number/process number as it's PORT NUMBER between routers in the same AS/group?

Question

Does EIGRP use AS number/process number as it's PORT NUMBER between routers in the same AS/group?

I know that EIGRP does NOT use TCP/UDP; I know that that EIGRP uses RTP as a mechanism to establish a layer-4-like function to keep EIGRP packets ordered and sequenced. I also know that there is an AS number in the payload. So please don't state the obvious, and just talk straight to the point.

In this post on the Cisco Support Forums there is an answer which seems a little weird. The question is about the EIGRP port number, and someone answers that "The port number is the EIGRP AS."

I Googled all over the internet, but could not find a single clue about that statement! Is that really true, I mean DOES EIGRP USE THE AS NUMBER as it's PORT NUMBER?

(By the way, there's a link under the mentioned post, but it doesn't load.)

How EIGRP neighbors know not to form a neighbor relationship with adjacent routers that aren't in their AS? The routers get the packets, disassemble it and check the payload to see that the AS# is not matched and then drop it? Or something else is going on?

Sorry to ask this kind of question, but the guy’s name, who has posted this stuff is Russ White, CCIE No. 2635. With all due respect to him, I couldn’t find a single clue to back up his theory of EIGRP using AS# number as port number. Or to back up his statement, “That's how EIGRP neighbors know not to form a neighbor relationship with adjacent routers that aren't in their AS--they won't even receive the packets sent by a router in another AS!”

Answer 1

I emailed Russ White (ex-Cisco employee / EIGRP specialist from the routing protocols deployment team), and this was his answer:

If you think about the way a TCP stack works, you have some sort of switching process that accepts packets, and stuffs them onto a "forme" queue. That queue is processed by IP -- but how does IP know what process to hand the packet to? That would be the protocol number. IP sticks a protocol number into the right argument in a function call, and out pops a pointer to a function to pass the packet to for that process (or more likely a pointer to a work queue that process monitors).

In the case of EIGRP, it's a work queue, and the process that monitors it is the EIGRP transport process (you should see a separate process for EIGRP and EIGRP transport in the processes running on a cisco box). Once this transport process is handed a slice of CPU, and it pulls a packet off the work queue. If there are several EIGRP processes running on the box, which one does it hand the packet to?

It treats the AS number in the packet as a selector, just like TCP treats the socket as a selector among the various processes consuming packets (HTTP/80, ident, FTP, etc). So, from an IOS perspective, the AS number in EIGRP provides the same information as a TCP socket does -- hence it's a "socket." Each EIGRP process "listens" to a "socket" or "port" equal to the AS number.

From the design and process perspective, each EIGRP AS looks like a different database/best path set/etc. From the protocol perspective, the AS number looks like a process selector, or a "port number," or a "socket," depending on your point of view.