Maximum Prefixes in RIPv2 on a Cisco Router

[jsbenami2008]

I work in a lab and we are developing/testing a server based system that dymamically calulates routes for certain types of encryptors:

That said part of the component involves redistribution from ISIS into RIP (yes the only prot avail) on these encryptors for now.

Q: What is the theoretical maximum number of prefixes or routes/hosts that a RIPv2 router can carry updates for in it's routing table router to router?

Q2 Not withstanding my encrytor's limitations - What is the max number before convergence time becomes crazy?

I have searched the web and read RFC 2453 but nothing even scratches this question.

FYI we are seeking operationally 10k prefixes, with testing for 40k prefixes. I've already loaded up iBGP speaking servers and routers a> 250k prefixes. I expect RIPv2 will fall a bit short of that

[paolo bevilacqua]

Q1. No theoretical limits.

Q2. Depends by the hardware used. A 3945E is much, much faster than a 851. You will have to experiment with your devices to find an answer.

[Mohamed Sobair]

Hi,

RIP version 2 can carry up to 25 routes in it routing update without authentication.

With RIP version 2 Authentication, the Protocl can carry up to 24 routes as a maximum routes in a routing update.

Source: Routing TCP/IP by Jeff Doyle,

Regards,

Mohamed

[paolo bevilacqua]

msobier123 wrote:
Hi,
RIP version 2 can carry up to 25 routes in it routing update without authentication.
With RIP version 2 Authentication, the Protocl can carry up to 24 routes as a maximum routes in a routing update.
Source: Routing TCP/IP by Jeff Doyle,

Regards,
Mohamed

Meaning: 24 or 25 routes in a single packet.

Then splitting the entire update over multiple packets, router can advertise as many routes is wanted. This is what IOS does since day 1.

[Mohamed Sobair]

Paolo,

I have never tested it, but the book states the routing update in rip which are carried every 30 seconds can carry UP TO 25 routes as maximum Without authentication.

So if you have an update of more than this limit , it cant be carried out in one RIP update.

Regards,

Mohamed

[paolo bevilacqua]

No, that is not what the book says or means, and you understanding is wrong.

Go ahead and test yourself, then you will understand how things work, and become entitled to participate in discussions.

[Mohamed Sobair]

This is the Second time I noticed you treat People with disrespect.

However, this time , I wouldnt care too much because from my point of view you are not the right person to evaluate me whether I am entitled or Not to participate in discussions.

BTW:

This what the book says, the reference is (Routing TCP/IP) Volume 1 - written by Jeff Doyle, I dont recall the page number but If You go and read the book Section RIP, you will find the correct answer.

Last Note, If you tested it and it doesnt provide the exact result, I should then report it to Cisco Press to determine the correct answer!! (AFTER I TEST IT My SELF).

Regards,

Mohamed

[paolo bevilacqua]

Again you are wrong.

You see disrespect while instead I'm showing you with patience, where exactly you are wrong, and why.

As long you keep insisting with your mistakes, I'm afraid you will meet a lot of "disrespect" in your life.

Anyway, go ahead and do your testing. You will only have to learn in the process.

Have a nice day, anyway.

[Peter Paluch]

Paolo, Mohamed,

Please, do not let the tempers run high. I have the feeling that you have both been saying the same thing, just using different names for the same thing. What you, Paolo, called a "packet", Mohamed called "an update". I agree that the term "packet" is more precise, and it is true that a single RIPv2 packet can contain up to 25 route entries. If there are more routes to advertise in RIPv2, multiple packets are sent every 30 seconds.

Best regards,

Peter

[marikakis]

Hi Mohamed and Paolo,

I believe this is just a misunderstanding. Some specific words sometimes make all the difference.
As I see it, the OP is interested in how many total route entries can be exchanged between the routers
and not how many route entries can be carried in a single RIP packet.

So, I guess Paolo is right that there is no theoretical limit

(or at least I can't think of a theoretical limiting factor right now either).
If you think about it, you wouldn't need to test that RIP routers

can send more than 25 route entries to each other incrementally
(even if such a total limit of route entries existed,

I guess it would support many more routes to make the protocol usable).

Mohamed posted correct information, but, as I see it, this information was not what the author was asking.
(FYI: Here is a reference for the information Mohamed posted:
http://www.wetdirt.com/cisco_tranning/data/itm/routing/rip/rgrirpk2.htm).

Author asks about theoretical maximum number of prefixes exchanged between the routers

and such a question typically asks about the end result and not how exactly the protocol accomplishes its task,

although it is interesting to know that as well.

Kind Regards,
Maria

[Peter Paluch]

Maria,

(or at least I can't think of a theoretical limiting factor right now either).

I can think of one but it is so improbable it is almost not worth mentioning

Obviously, there is no problem in conveying multiple routes in RIPv2 using multiple Response packets. Therefore, the only aspect left is the fact that there may be so many routes to announce that even with continous sending of updates, the same network cannot be announced again (i.e. refreshed) in the invalid_time timeframe. However, to imagine there are so many networks that you need at least 180 seconds of continous RIPv2 packet stream to send them all is just absurd

Best regards,

Peter

[marikakis]

Hi Peter,

You are right and it is worth mentioning. When I used the word "theoretical" I was referring to some protocol upper limit and the notion of time was classified as something "practical" in my mind at that time. Seems we like to play with the words in this thread.

But, the limitations that some delays bring into the picture of communications have been discussed in physics some time ago, so from a physics perspective we have at least one theoretical limit, even if that exists in a somewhat axiomatic form, and might even also be referred as a practical effect:

http://en.wikipedia.org/wiki/Speed_of_light#Practical_effects_of_finiteness
These things might seem obvious now, but it took hundreds of years of disagreements for some conclusions to be reached. I guess instantaneous communication looks so charming that is a difficult expectation for people to give up. It is even extended to science fiction about instant transfer of "more physical" objects such as people themselves to a remote galaxy and returning back young and beautiful while everybody else has been dead for years.

But again, you might hear a client expecting a delay of say 5ms between Athens and London, so that client can play an online game more effectively (my personal favorite clients of all time). So, the theory might not be widely known and it is worth mentioning, since it also has implications in other contexts. Besides, the author here wants to know some practical limits and these are also related to your introduction of the time dimension into the picture.

I guess if we have too many routes we won't be discussing about RIP and even not even OSPF or IS-IS either. I guess we go with better design and/or have BGP carry the burden somehow.

BTW: Why would these servers or encryptors need to have too many RIP routes? Or am I missing something in this case? If this is some type of service requirement and RIP is the only protocol available in the endpoints, can't issue be solved using some other way (e.g. using MPLS VPNs and some defaults) rather than stretching RIP to provide the service?

Kind Regards,
Maria