A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider)
On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
RIP has one property no "modern" protocol has. It works on simplex links (e.g. high-speed satellite downlink with low-speed terrestrial uplink). Is that useful? I don't know, but it is still a fact. -- TTFN, patrick
Loss of using VLSM's is a big thing to give up. You can go to RIPv2 and get that however. Would work for small networks to stay under the hop-count limit as it is still distance-vector. On Wed, Sep 29, 2010 at 4:27 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
RIP has one property no "modern" protocol has. It works on simplex links (e.g. high-speed satellite downlink with low-speed terrestrial uplink).
Is that useful? I don't know, but it is still a fact.
-- TTFN, patrick
-- ===================================== Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3yni1@gmail.com
where the RIP protocol is useful? Please excuse me if this is the = incorrect forum for such questions.
RIP has one property no "modern" protocol has. It works on simplex = links (e.g. high-speed satellite downlink with low-speed terrestrial = uplink).
Is that useful? I don't know, but it is still a fact.
I once had cause to write a RIP broadcast daemon while on-site with a client; they had some specific brokenness with a Novell server and some other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 or 30 minutes of programming (mostly to remember the grimy specifics of UDP broadcast programming). I do not recall the specific routing issue, but being able to just inject a periodic "spoofed" packet was sufficient to repair them. While not the correct way to engineer a network, sometimes being able to bring a client's network back on-line in a crisis is more important than technical correctness. I feel reasonably certain that I would not have been able to cobble together a quick solution if they had been relying on OSPF, etc. A simple protocol can be a blessing. I concede it is more often a curse. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Thanks Joe! You just added a new term to my vocabulary! "Technical Correctness" I think I'm going to go out of my way now to use this in the office... =)
From: jgreco@ns.sol.net Subject: Re: RIP Justification To: patrick@ianai.net Date: Wed, 29 Sep 2010 18:24:59 -0500 CC: nanog@nanog.org
where the RIP protocol is useful? Please excuse me if this is the = incorrect forum for such questions.
RIP has one property no "modern" protocol has. It works on simplex = links (e.g. high-speed satellite downlink with low-speed terrestrial = uplink).
Is that useful? I don't know, but it is still a fact.
I once had cause to write a RIP broadcast daemon while on-site with a client; they had some specific brokenness with a Novell server and some other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 or 30 minutes of programming (mostly to remember the grimy specifics of UDP broadcast programming). I do not recall the specific routing issue, but being able to just inject a periodic "spoofed" packet was sufficient to repair them.
While not the correct way to engineer a network, sometimes being able to bring a client's network back on-line in a crisis is more important than technical correctness. I feel reasonably certain that I would not have been able to cobble together a quick solution if they had been relying on OSPF, etc. A simple protocol can be a blessing. I concede it is more often a curse.
.... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
This is why they need a 'like' button on nanog!! :)
I once had cause to write a RIP broadcast daemon while on-site with a client; they had some specific brokenness with a Novell server and some other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 or 30 minutes of programming (mostly to remember the grimy specifics of UDP broadcast programming). I do not recall the specific routing issue, but being able to just inject a periodic "spoofed" packet was sufficient to repair them.
On 9/29/2010 at 4:24 PM, Joe Greco <jgreco@ns.sol.net> wrote: where the RIP protocol is useful? Please excuse me if this is the = incorrect forum for such questions.
RIP has one property no "modern" protocol has. It works on simplex = links (e.g. high-speed satellite downlink with low-speed terrestrial = uplink).
Is that useful? I don't know, but it is still a fact.
I once had cause to write a RIP broadcast daemon while on-site with a client; they had some specific brokenness with a Novell server and some other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 or 30 minutes of programming (mostly to remember the grimy specifics of UDP broadcast programming). I do not recall the specific routing issue, but being able to just inject a periodic "spoofed" packet was sufficient to repair them.
I've got a RIPv2 daemon written in a few dozen lines of Perl to do something very similar. In other situations, RIPv2 has strong KISS appeal.
I would think it would depend on the complexity of the network and how the network advertises routes to peer networks. I'm always in favor the simpler the better but with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF. Gary -----Original Message----- From: Jesse Loggins [mailto:jlogginsccie@gmail.com] Sent: Wednesday, September 29, 2010 4:21 PM To: nanog@nanog.org Subject: RIP Justification A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider)
RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area. Chris On Wed, Sep 29, 2010 at 3:29 PM, Gary Gladney <gladney@stsci.edu> wrote:
I would think it would depend on the complexity of the network and how the network advertises routes to peer networks. I'm always in favor the simpler the better but with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF.
Gary
-----Original Message----- From: Jesse Loggins [mailto:jlogginsccie@gmail.com] Sent: Wednesday, September 29, 2010 4:21 PM To: nanog@nanog.org Subject: RIP Justification
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
-- Jesse Loggins CCIE#14661 (R&S, Service Provider)
On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin <chris@travelingtech.net> wrote:
RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area.
I think BGP is better for that job, ultimately because it was specifically designed for that job, but also because it's now available in commodity routers for commodity prices e.g. Cisco 800 series.
Chris
On Wed, Sep 29, 2010 at 3:29 PM, Gary Gladney <gladney@stsci.edu> wrote:
I would think it would depend on the complexity of the network and how the network advertises routes to peer networks. I'm always in favor the simpler the better but with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF.
Gary
-----Original Message----- From: Jesse Loggins [mailto:jlogginsccie@gmail.com] Sent: Wednesday, September 29, 2010 4:21 PM To: nanog@nanog.org Subject: RIP Justification
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
-- Jesse Loggins CCIE#14661 (R&S, Service Provider)
My point here is untrusted networks, such as business partners exchanging routes with each other. Not many hops and less than a 100 prefixes. Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance. I've seen RIPv2 very successfully deployed in modern networks in this fashion. I advocate using an appropriate tool for the job. Christopher Gatlin CCIE #15245 (R&S/Security) On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith < nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin <chris@travelingtech.net> wrote:
RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area.
I think BGP is better for that job, ultimately because it was specifically designed for that job, but also because it's now available in commodity routers for commodity prices e.g. Cisco 800 series.
On Sep 29, 2010, at 5:31 PM, Christopher Gatlin wrote:
My point here is untrusted networks, such as business partners exchanging routes with each other. Not many hops and less than a 100 prefixes.
Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance.
No, it's like using a wrench to tighten a nut. Using RIPv2 for the task is like using a pair of pliers.
I've seen RIPv2 very successfully deployed in modern networks in this fashion. I advocate using an appropriate tool for the job.
So do I. Use a wrench, not a pair of pliers, no matter how much it seems easier to reach the piers. Owen
Christopher Gatlin CCIE #15245 (R&S/Security)
On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith < nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin <chris@travelingtech.net> wrote:
RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area.
I think BGP is better for that job, ultimately because it was specifically designed for that job, but also because it's now available in commodity routers for commodity prices e.g. Cisco 800 series.
On Wed, 29 Sep 2010 19:31:26 -0500 Christopher Gatlin <chris@travelingtech.net> wrote:
My point here is untrusted networks, such as business partners exchanging routes with each other. Not many hops and less than a 100 prefixes.
Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance.
I've used BGP quite a fair bit, for both Internet scale and small scale routing scenarios such as the one I recommended. How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be? A shared RIP MD5 key between the routers doesn't validate the route information within the RIP update. All the routers within your business partner domain will blindly accept and trust the routing information in any and all of the RIP updates they receive. Do the businesses attached have a multilateral or bi-lateral routing relationship? If routing relationship is multilateral, which is likely because you're using RIP, are the business partners using IPsec to ensure that if the routing is subverted, their traffic isn't disclosed to partners it shouldn't be? The scenario you're describing sounds pretty much exactly like a internet/peering exchange is between ISPs. The routing security issues are similar if not the same. In either multilateral or bi-lateral routing scenarios, BGP will provide you with the mechanisms needed to provide more trustworthy routing in these peer exchange type scenarios.
I've seen RIPv2 very successfully deployed in modern networks in this fashion.
Popular doesn't always equal good. Britney Spear's music is a testament to that. The threshold of success isn't if something works. It's whether it continues to work in the face of adversity. I'd think your business partner customers would expect a highly available service that is resilient to predictable and preventable adverse events, with a fairly likely one to be accidental route injection.
I advocate using an appropriate tool for the job.
As do I, and therefore I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter. Regards, Mark.
-----Original Message----- From: Gary Gladney Sent: Wednesday, September 29, 2010 1:29 PM To: 'Jesse Loggins'; nanog@nanog.org Subject: RE: RIP Justification
with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF.
Gary
I would think most people using RIP with IPv4 would use RIPv2 which does allow CIDR.
IPVPN arrangement with multiple sites & no redundancy for each small site. RIP to advertise networks from each site towards cloud, quick and easy.
On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
I'd argue that in order to do anything useful (read: moderately sized) with RIP (aside from supporting legacy devices lacking anything else and as Patrick mentioned handling asymmetric links), you actually need to _add_ complexity in order to make it work –– if you can at all. The lack of path vectoring limits network diameter due to counting to infinity, redundancy requires the use of hold down timers (which are proportionate to the diameter of the network), etc. Antilock brakes are "complex" from an mechanical perspective. But the act of braking is the same. Turn on the protocol. Add the necessary interfaces. Subnet accordingly. Summarize where possible. Walk away. "Let the machines do the work." -Vijay Gill (most recently as I recall) C
-- Jesse Loggins CCIE#14661 (R&S, Service Provider)
On 29 Sep 2010 15:20, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
(I assume "RIP" above refers to RIPv2.) When the automobile was developed, plenty of folks thought horses were obsolete and would fall completely out of use. However, the reality is that there are still some things horses are better at, e.g. terrain that automobiles (even 4WD) simply can't navigate, places where automobiles are banned for safety, aesthetic and/or environmental reasons, etc. Newer isn't always better. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Wed, 29 Sep 2010 16:20:48 -0400, Jesse Loggins <jlogginsccie@gmail.com> wrote:
It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again".
That is the correct way to think about RIP. (RIPv1 specific) In 99% of the cases where I've seen RIP used (over 2 decades), they would've been better off with static routes. (or they needed something a lot more complex/robust... say, a power company running RIPv1 over their entire network.) The 1% where it was a necessary evil... dialup networking where the only routing protocol supported was RIP (v2) [netblazers] -- static IP clients had to be able to land anywhere -- but RIP only lived on the local segment, OSPF took over network-wide. (Later MaxTNT's were setup with OSPF stub areas so they didn't have to have a full route table.) BTW, ALL other routing protocols are more complex than RIP. One cannot get any simpler than RIP. --Ricky
On Sep 29, 2010, at 1:47 PM, Ricky Beam wrote:
The 1% where it was a necessary evil... dialup networking where the only routing protocol supported was RIP (v2) [netblazers] -- static IP clients had to be able to land anywhere -- but RIP only lived on the local segment, OSPF took over network-wide. (Later MaxTNT's were setup with OSPF
I remember RIP across chassis for the TotalControl bonded dialup stuff, and as you mention, static IPs, but I haven't seen it in serious use for a long time. Cheers, -j
I see nothing wrong with using RIPV2 for small networks as it is more dynamic and faster convergence. As for RIPv1, I think we can all say, RIP!! (no pun intended) Ok yes it was intended.... LOL... I think some engineers get lost in the "whatever is newer is better" and you don't need to use a complicated protocol for small simple networks. Now, you should think ahead if that's possible and if you do know it can get complicated, you can implement the right protocol from the start. I have not heard about RIPv3. I suppose I should start looking into it......
From: egon@egon.cc To: nanog@nanog.org Subject: Re: RIP Justification Date: Wed, 29 Sep 2010 13:53:40 -0700
On Sep 29, 2010, at 1:47 PM, Ricky Beam wrote:
The 1% where it was a necessary evil... dialup networking where the only routing protocol supported was RIP (v2) [netblazers] -- static IP clients had to be able to land anywhere -- but RIP only lived on the local segment, OSPF took over network-wide. (Later MaxTNT's were setup with OSPF
I remember RIP across chassis for the TotalControl bonded dialup stuff, and as you mention, static IPs, but I haven't seen it in serious use for a long time.
Cheers, -j
Jesse - just to clarify, are you talking about v1 or v2? There is also a proposal for v3.. In my previous post, I was assuming v2.
On Sep 29, 2010, at 1:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
For RIP, the attraction is simplicity, and the down-side is count-to-infinity. If you have a network in which count-to-infinity is a non-issue - often true of residential networks, for example - the simplicity of RIP can be very attractive. If you have anything resembling complexity in your network, protocols like OSPF are far more appropriate.
We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well.. I could discuss it more with you off-line if you like. On Sep 29, 2010, at 4:20 PM, Jesse Loggins <jlogginsccie@gmail.com> wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
-- Jesse Loggins CCIE#14661 (R&S, Service Provider)
On Wed, 29 Sep 2010 17:26:17 -0400 Craig <cvuljanic@gmail.com> wrote:
We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well..
I'm don't really buy the extra config argument. It's literally differences measured in seconds or minutes between the configuration effort, and in the context of the operational benefits over time of link state verses distance vector, I think they're worth spending. However, if you want a really simple OSPF config, the following two lines will make OSPF just work everywhere it can on a Cisco router router ospf 64512 network 0.0.0.0 255.255.255.255 area 0 One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent.
I could discuss it more with you off-line if you like.
On Sep 29, 2010, at 4:20 PM, Jesse Loggins <jlogginsccie@gmail.com> wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
-- Jesse Loggins CCIE#14661 (R&S, Service Provider)
On 30/09/10 13:42, Mark Smith wrote:
One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g.
int ethernet0 ip ospf network point-to-point
If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent.
Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask?
On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin <nanog@studio442.com.au> wrote:
On 30/09/10 13:42, Mark Smith wrote:
One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g.
int ethernet0 ip ospf network point-to-point
If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent.
Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask?
Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface <blah> The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark.
On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [1]<nanog@studio442.com.au> wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. Nope. Not Cisco anyway. NDC-R1-CustA(config)#int f0/0 NDC-R1-CustA(config-if)#ip addr 10.111.1.1 255.255.255.254 % Warning: use /31 mask on non point-to-point interface cautiously NDC-R1-CustA(config-if)# *Sep 30 15:18:22.710: %OSPF-5-ADJCHG: Process 1, Nbr 10.133.1.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached NDC-R1-CustA(config-if)# NDC-R1-CustA(config-if)#do sh ip o i f0/0 | i Type|Address Internet Address 10.111.1.1/31, Area 0 Process ID 1, Router ID 192.168.1.1, Network Type BROADCAST, Cost: 1 NDC-R1-CustA(config-if)# HTH, Scott On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [2]<nanog@studio442.com.au> wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface <blah> The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark. References 1. mailto:nanog@studio442.com.au 2. mailto:nanog@studio442.com.au
Thus spake Jesse Loggins (jlogginsccie@gmail.com) on Wed, Sep 29, 2010 at 01:20:48PM -0700:
This leads to my question. What are your views of when and where the RIP protocol is useful?
I most often see RIPv2 used simply to avoid paying vendor license fees to run more sophisticated things such as OSPF. Dale
On 29/09/2010 22:36, Dale W. Carder wrote:
I most often see RIPv2 used simply to avoid paying vendor license fees to run more sophisticated things such as OSPF.
The good thing about vendors who charge license fees to run more sophisticated things such as OSPF is that there are always other vendors out there who don't charge license fees for bread and butter protocols - such as OSPF. Nick
RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF. The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks. Jonathon -----Original Message----- From: Jesse Loggins [mailto:jlogginsccie@gmail.com] Sent: Thursday, 30 September 2010 9:21 a.m. To: nanog@nanog.org Subject: RIP Justification A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider) This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
I know of one large-ish provider that does it exactly like that - RIPv2 between POP edge routers and provider-managed CPE. In addition to the simplicity, it lets them filter routes at redistribution without having to fiddle with inter-area OSPF (or, ghod forbid, multiple OSPF processes redistributing between each other...) Where folks run into trouble is vendors that decide that RIP is so under-utilized they don't need to fully support or QA it anymore. Implementations tend to be a bit more..."quirky" than OSPF or BGP running on the same box. And occasionally you run into the odd vendor that doesn't care about things like being able to adjust hello/dead intervals... -C On Sep 29, 2010, at 2:50 PM, Jonathon Exley wrote:
RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF. The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks.
Jonathon
-----Original Message----- From: Jesse Loggins [mailto:jlogginsccie@gmail.com] Sent: Thursday, 30 September 2010 9:21 a.m. To: nanog@nanog.org Subject: RIP Justification
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
-- Jesse Loggins CCIE#14661 (R&S, Service Provider) This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin <chris@travelingtech.net> wrote:
Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance.
But on the flipside, arguing that we're providing this business parter service with no sort of broadcast mechanism, does the complexity actually increase between a proper implementation of BGP versus properly implementing RIP for the same scenario? Consider this example: 2 business partners terminating on the same device, we are advertising 1 prefix to both and receiving 1 prefix from each. Each has redundant connections to another router. Goals: 1) Prevent BP A from advertising routes owned by BP B and vice-versa 2) Advertise only the single prefix to the BPs 3) No broadcast medium, so we'll need neighbor statements 4) Prefix advertised to peers originates from IGP Mentally configuring this (in cisco terms), it seems about the same in terms of config complexity. Filtering the prefixes from each of the neighbors is required and the ACL to do this looks kind of nasty in RIP. Also, you'll need to redistribute from the IGP and add either an egress distribute list or a route map on the redistribution into RIP. Finally, redistribute back into the IGP for the received prefixes. BGP gives a slightly nicer-looking policy with a route map for each of the neighbors and policy building features that make scaling the solution slightly easier since route-maps can be reused and attached to the neighbor through whatever mechanism you want. And no funky-looking ACLs to describe how to accept prefixes and no need to redistribute from the IGP. Also, if choosing to run iBGP between redundant nodes, its quite a bit more simplified to set metrics to determine primary and redundant paths since this can be done on the same ingress policy. On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield <rekoil@semihuman.com> wrote:
(or, ghod forbid, multiple OSPF processes redistributing between each other...)
I think I have an anxiety disorder from this sort of "design".. On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be?
Ingress filtering for prefixes can be performed with RIP. It just looks really funky compared to route maps for neighbors in BGP.
[...] I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter.
True that BGP is generally better in most external routing instances. But there are other cost factors involved with doing BGP - fear and knowledge. A lot of less experienced folk out there are outright afraid of the concepts behind BGP and/or do not have the requisite skills to maintain it. That shouldn't justify bad design decisions, but it often does. Plus, it could be postulated that proper implementation of RIP in the same scenario would be hindered by the lack of knowledge still. Also, it should be pointed out that there are security products and others that don't support BGP. In those instances, it might make some sense to choose RIP. Other limiting factors can include resource and feature availablity on the terminating device(s) (as addressed by others). -- William McCall
On Thu, 30 Sep 2010 01:15:45 -0500 William McCall <william.mccall@gmail.com> wrote:
On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin <chris@travelingtech.net> wrote:
Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance.
But on the flipside, arguing that we're providing this business parter service with no sort of broadcast mechanism, does the complexity actually increase between a proper implementation of BGP versus properly implementing RIP for the same scenario?
Consider this example: 2 business partners terminating on the same device, we are advertising 1 prefix to both and receiving 1 prefix from each. Each has redundant connections to another router.
Goals: 1) Prevent BP A from advertising routes owned by BP B and vice-versa 2) Advertise only the single prefix to the BPs 3) No broadcast medium, so we'll need neighbor statements 4) Prefix advertised to peers originates from IGP
Mentally configuring this (in cisco terms), it seems about the same in terms of config complexity. Filtering the prefixes from each of the neighbors is required and the ACL to do this looks kind of nasty in RIP. Also, you'll need to redistribute from the IGP and add either an egress distribute list or a route map on the redistribution into RIP. Finally, redistribute back into the IGP for the received prefixes.
BGP gives a slightly nicer-looking policy with a route map for each of the neighbors and policy building features that make scaling the solution slightly easier since route-maps can be reused and attached to the neighbor through whatever mechanism you want. And no funky-looking ACLs to describe how to accept prefixes and no need to redistribute from the IGP. Also, if choosing to run iBGP between redundant nodes, its quite a bit more simplified to set metrics to determine primary and redundant paths since this can be done on the same ingress policy.
On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield <rekoil@semihuman.com> wrote:
(or, ghod forbid, multiple OSPF processes redistributing between each other...)
I think I have an anxiety disorder from this sort of "design"..
On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be?
Ingress filtering for prefixes can be performed with RIP. It just looks really funky compared to route maps for neighbors in BGP.
The best place to configure the prefix filtering would be on admission to the routing domain, rather than on exit. To achieve any sort of accurate route filtering in a RIP environment you'd have to maintain ingress route filters on all of the business partner routers. That'd be much harder to maintain accurately due to the number of business partner routers than a single per-business customer inbound route filter on a couple of BGP Route Reflectors/Servers. Those business customers may not trust you to operate their routers, so your routing accuracy is dependent on how well administered those business partner routers are maintained, which is likely to be very inconsistently. If you were operating the business peering exchange as a paid third party, and were providing SLAs for the service, then you wouldn't be in control of something that is essential to maintaining the quality and availability of the service.
[...] I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter.
True that BGP is generally better in most external routing instances. But there are other cost factors involved with doing BGP - fear and knowledge. A lot of less experienced folk out there are outright afraid of the concepts behind BGP and/or do not have the requisite skills to maintain it.
Then they're not the right people to be operating this network because they're not competent to. It sounds a bit like you're justifying people saying "I want to be paid to be an expert in this field, but I don't want to actually be an expert." I find this cop-out extremely irritating. You either know what you're doing or you don't, and if you don't, you shouldn't be selling yourself as somebody who does.
That shouldn't justify bad design decisions, but it often does. Plus, it could be postulated that proper implementation of RIP in the same scenario would be hindered by the lack of knowledge still.
Also, it should be pointed out that there are security products and others that don't support BGP. In those instances, it might make some sense to choose RIP. Other limiting factors can include resource and feature availablity on the terminating device(s) (as addressed by others).
Then you buy a cheap BGP speaking device e.g. a Cisco 800 to put in front of it. Regards, Mark.
On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Thu, 30 Sep 2010 01:15:45 -0500 William McCall <william.mccall@gmail.com> wrote:
On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin <chris@travelingtech.net> wrote:
Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance.
But on the flipside, arguing that we're providing this business parter service with no sort of broadcast mechanism, does the complexity actually increase between a proper implementation of BGP versus properly implementing RIP for the same scenario?
Consider this example: 2 business partners terminating on the same device, we are advertising 1 prefix to both and receiving 1 prefix from each. Each has redundant connections to another router.
Goals: 1) Prevent BP A from advertising routes owned by BP B and vice-versa 2) Advertise only the single prefix to the BPs 3) No broadcast medium, so we'll need neighbor statements 4) Prefix advertised to peers originates from IGP
Mentally configuring this (in cisco terms), it seems about the same in terms of config complexity. Filtering the prefixes from each of the neighbors is required and the ACL to do this looks kind of nasty in RIP. Also, you'll need to redistribute from the IGP and add either an egress distribute list or a route map on the redistribution into RIP. Finally, redistribute back into the IGP for the received prefixes.
BGP gives a slightly nicer-looking policy with a route map for each of the neighbors and policy building features that make scaling the solution slightly easier since route-maps can be reused and attached to the neighbor through whatever mechanism you want. And no funky-looking ACLs to describe how to accept prefixes and no need to redistribute from the IGP. Also, if choosing to run iBGP between redundant nodes, its quite a bit more simplified to set metrics to determine primary and redundant paths since this can be done on the same ingress policy.
On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield <rekoil@semihuman.com> wrote:
(or, ghod forbid, multiple OSPF processes redistributing between each other...)
I think I have an anxiety disorder from this sort of "design"..
On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be?
Ingress filtering for prefixes can be performed with RIP. It just looks really funky compared to route maps for neighbors in BGP.
The best place to configure the prefix filtering would be on admission to the routing domain, rather than on exit. To achieve any sort of accurate route filtering in a RIP environment you'd have to maintain ingress route filters on all of the business partner routers. That'd be much harder to maintain accurately due to the number of business partner routers than a single per-business customer inbound route filter on a couple of BGP Route Reflectors/Servers.
Those business customers may not trust you to operate their routers, so your routing accuracy is dependent on how well administered those business partner routers are maintained, which is likely to be very inconsistently. If you were operating the business peering exchange as a paid third party, and were providing SLAs for the service, then you wouldn't be in control of something that is essential to maintaining the quality and availability of the service.
Agreed, but rarely is this option presented. For this reason, the operator must still protect the network from other's misconfiguration, etc.
[...] I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter.
True that BGP is generally better in most external routing instances. But there are other cost factors involved with doing BGP - fear and knowledge. A lot of less experienced folk out there are outright afraid of the concepts behind BGP and/or do not have the requisite skills to maintain it.
Then they're not the right people to be operating this network because they're not competent to.
It sounds a bit like you're justifying people saying "I want to be paid to be an expert in this field, but I don't want to actually be an expert." I find this cop-out extremely irritating. You either know what you're doing or you don't, and if you don't, you shouldn't be selling yourself as somebody who does.
No no... True that it happens that "experts" are often not quite "experts", I am not a fan, but it is a reality of the business. Once upon a time, not long ago, I had a manager explain to me that our team must set up a business partner scenario with either: A) Static routes and IP SLA or B) RIP I told him BGP made more sense and he just said "It's too complicated, don't do it." Not like he had to support it (the senior engineers, who all knew BGP, had to support it regardless). Long story short, we did static routes and IP SLA because the BP would only do BGP or static routing. Anyway, as I indicated in the statement you quoted, I don't support bad design decisions and, as an extension, gross incompetence, but it is rife in most technical and professional fields. And still, even if that incompetent administrator attempted to implement RIP versus BGP for this scenario, they'd probably still screw it up. (As another recent example of professional incompetence outside of networks, consider a set of medical professionals attempting to give more morphine to a surgery patient when the patient had a heartbeat of around 40 BPM and telling said patient that they must be having a panic attack. Twice.)
That shouldn't justify bad design decisions, but it often does. Plus, it could be postulated that proper implementation of RIP in the same scenario would be hindered by the lack of knowledge still.
Also, it should be pointed out that there are security products and others that don't support BGP. In those instances, it might make some sense to choose RIP. Other limiting factors can include resource and feature availablity on the terminating device(s) (as addressed by others).
Then you buy a cheap BGP speaking device e.g. a Cisco 800 to put in front of it.
Again, I don't disagree. In the proposals I have designed, it is usually some sort of termination router for the tunnel or attachment circuit and then a security device behind that somewhere where it makes sense. Management is sort of responsible though for making that happen and often enough they'd rather not, usually to save the relatively few dollars here and there and get a slightly larger bonus at the end of the year. Or the other approach is where the "security" team (firewall jockey and/or fear mongering CSO) has dictated that they handle termination of all of these circuits, etc and they HAVE to handle the BP routing (so even the hack known as eBGP multihop is not an option). The reason? "Security."
Regards, Mark.
Often times, technical decisions are made into "business" decisions when they shouldn't be. Also, incompetence is common, if not promoted in a lot of these "business" decisions. If you haven't had to deal with this inside of your firm, then I really really want to ask you about a job with your firm. I'll relocate just about anywhere and I shower daily or more often as necessary. (This should not be construed as to say my current firm is run by incompetent folks, quite to the contrary is true). -- William McCall
I think you're right that everything has its' place. But you gotta know where that is and why you choose it! RIP(v2) is great in that there aren't neighbor relationships, so you can shoot routes around in a semi-sane-haphazard fashion if need be. Whatever your reality you exist in like satellite (or other one-way links from the hinterlands). But anything, ask why you are using it. To exchange routes, yes... but how many. Is sending those every 30 seconds good? Sure, tweak it. But are you gaining anything over static routes? Perhaps you are, and if so, it's a great choice in that situation. But I'd certainly think it would be considered to be the "edge" variety of your network and hopefully not planning to use it through your entire network! :) But yeah, I'd agree with the "time and place" argument for it. If you have a Cisco-only shop, ODR can be kinda cool in situations like that as well. Something to think about! My two cents. Scott On 9/29/10 4:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
On Sep 29, 2010, at 6:14 PM, Scott Morris wrote:
But anything, ask why you are using it. To exchange routes, yes... but how many. Is sending those every 30 seconds good? Sure, tweak it. But are you gaining anything over static routes?
For simple networks, RIP(v2, mind you) works fine. You're correct that the number of advertisements sent over the wire every 30 seconds won't scale, but with today's routers and bandwidths it takes quite a lot to start to cause issues. The real nail in RIP's coffin is that with most (if not all) routers out there today, it's no more work to turn on and configure OSPF than it is to do RIP, and OSPF will help you scale much better as you go without being too complex for the simpler setups as well. As such, it really doesn't make sense to go with RIP for mere nostalgia's sake. If you have a specific reason not to run OSPF, fine, but those reasons are few and far between. -C
One would assume you aren't doing this for nostalgic reasons. At least I would hope that! Like anything, if you decide to vary outside the 'accepted norms', then have a reason for it! Understand your technology, understand your topology (re: before about RIP not needing peered neighbors whereas OSPF does) and you may have your justification. If it's for nostalgia or "just because", then I'd say everyone agrees that RIP has passed its usefulness! Scott On 9/29/10 11:32 PM, Chris Woodfield wrote:
On Sep 29, 2010, at 6:14 PM, Scott Morris wrote:
But anything, ask why you are using it. To exchange routes, yes... but how many. Is sending those every 30 seconds good? Sure, tweak it. But are you gaining anything over static routes? For simple networks, RIP(v2, mind you) works fine. You're correct that the number of advertisements sent over the wire every 30 seconds won't scale, but with today's routers and bandwidths it takes quite a lot to start to cause issues.
The real nail in RIP's coffin is that with most (if not all) routers out there today, it's no more work to turn on and configure OSPF than it is to do RIP, and OSPF will help you scale much better as you go without being too complex for the simpler setups as well. As such, it really doesn't make sense to go with RIP for mere nostalgia's sake. If you have a specific reason not to run OSPF, fine, but those reasons are few and far between.
-C
hi, I summarize the discussion in my way. Please add or fix it. * RIP works okay in topologies without topological loops. I would like to elaborate the term "small networks" in "RIP works well in small networks". Specifically the term "small network" would mean: 1) the diameter of the network is less than 15 hops, 2) the network does not include topological loop, and 3) the #routes exchanged in it is small. One does not need to care about 1) unless he or she wants to use the path with more than 15 hops. 2) is important to care because it leads to counting-to-infinity. For 3), if the #routes is large, the routing message may seem to be really redundant or painfull (refer poisonous reverse discussion). I am wondering whether someone saying "working well in small networks" checks if the counting-to-infinity occurs on their networks. I guess Counting-to-infinity is really hard to catch. I think RIP works "okay" in a whatever-large network, if above 3 points are fine with us. But I would not like to call the case "works well". * Routing control message seems more redundant in RIP. Every 30 seconds may seem redundant. You may need to advertise the prefix that doesn't exist in some cases (poisonous reverse). * RIP have rooms to fix, tweak, or hack the routes. The algorithm works okay with rejecting and modifying the routes (filters) at an arbitrary point in the network. Link State routing protocols including OSPF and IS-IS basically do not support this. This is the pros in RIP. * RIP algorithm is simple, but debugging is really hard. You would never want to debug what is happening in RIP, when a problem occurs such as Counting-to-infinity. The state of the routes changes too quickly to catch, and you must track the logs of all the routers on the way. This is almost impossible. * OSPF algorithm (i.e. DB exchange) is complex, but debugging is simple. OSPF is easy to debug because one can point out the bad part easily by comparing DBs. If DBs are sync'ed, they are okay. If DBs are not sync'ed, the source of the problem lies in either (or both) of the routers. If the DB is sync'ed but routes are strange, then the problem lies in the Dijkstra code in the router. Most operators prefers this characteristic (feature). In all of the above case, you can simply replace the router to fix the problem. (Check if the router-id conflicts first, when DB changes so quickly.) Most people hates DB exchange in OSPF since it is hard to understand. So, some prefers IS-IS more, because the DB exchange algorithm is simpler. Complex algorithm in DB exchange may produce bugs, but may prevent (or at least alert) some problems that is hard to debug. * Complexities in configuring them are not much different. As someone stated, tasks necessary to configure, e.g., turn on protocol, include network I/F, ..., walk away, are equivalent for both. I support "everything has its place". In summary, if you can avoid topological loop in your network, I think RIP works okay even in a large network. regards, yasu
On Sep 29, 2010, at 1:20 PM, Jesse Loggins wrote:
A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a
I would rather say it should be thrown under a bus, squashed, then left on a set of very active railway tracks to be thoroughly mutilated, then discarded never to be seen again.
more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and
Here's my thinking... If your network is not complex enough to require a dynamic routing protocol, then, you don't need RIP. If it is, then, you have scaled beyond the point where RIP is more useful than harmful. Yes, OSPF is a more complex protocol. It is also quite a bit more robust and far less susceptible to bizarre looping behaviors when it misbehaves or encounters lost state packets. It has a much shorter fall-over time for dead links and provides a much more accurate and up to date picture of the state of the network. It's a more complex world now than when RIP was developed. Owen
On 9/29/2010 3:20 PM, Jesse Loggins wrote:
What are your views of when and where the RIP protocol is useful?
Home networks when dual NAT isn't being used. It's also the perfect protocol for v6 on home networks where multiple home routers might be connected in a variety of ways. Shocked I didn't even see v6 mentioned in the thread (though you did clarify v2, which isn't the v6 implementation). :( Jack
On Sep 30, 2010, at 6:27 AM, Jack Bates wrote:
On 9/29/2010 3:20 PM, Jesse Loggins wrote:
What are your views of when and where the RIP protocol is useful?
Home networks when dual NAT isn't being used. It's also the perfect protocol for v6 on home networks where multiple home routers might be connected in a variety of ways.
I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. I have multiple routers in my home network. They use a combination of BGP and OSPFv3.
Shocked I didn't even see v6 mentioned in the thread (though you did clarify v2, which isn't the v6 implementation). :(
If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP. Owen
On 9/30/2010 8:46 AM, Owen DeLong wrote:
I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario.
I have multiple routers in my home network. They use a combination of BGP and OSPFv3.
Except you must configure those things. The average home user cannot.
If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP.
While it is possible for a router to create static routes automatically based on DHCPv6 assignment information, this has no loop prevention and is suboptimal depending on the configuration that things get plugged in. I'm not talking good network design here. I'm talking, buy box, plug in wherever it fits. Things should work. Jack
On Sep 30, 2010, at 6:56 AM, Jack Bates wrote:
On 9/30/2010 8:46 AM, Owen DeLong wrote:
I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario.
I have multiple routers in my home network. They use a combination of BGP and OSPFv3.
Except you must configure those things. The average home user cannot.
The average home user cannot configure RIP. What is your point?
If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP.
While it is possible for a router to create static routes automatically based on DHCPv6 assignment information, this has no loop prevention and is suboptimal depending on the configuration that things get plugged in. I'm not talking good network design here. I'm talking, buy box, plug in wherever it fits. Things should work.
RIP has no loop prevention and is suboptimal depending on the configuration that things get plugged in. RIP breaks more often than DHCP in my experience. Owen
On 10/1/2010 4:21 AM, Owen DeLong wrote:
The average home user cannot configure RIP. What is your point?
Last linksys I looked at had a checkbox. All done.
RIP has no loop prevention and is suboptimal depending on the configuration that things get plugged in.
Damn. You mean the split horizon stuff doesn't prevent loops? Granted, it's not optimal, but it works better than nothing in small homeuser networks as we roll v6 out and will need plug and play routing inside of a house. It's also, as someone else pointed out, nice for l3vpn when customers don't support BGP (ie, the very small ones). Providers hate manually having to jack with routes when customers want to rework stuff in their private networks.
RIP breaks more often than DHCP in my experience.
I'm sure it does, but they are both useful for v6 in consumer grade routers where OSPF/IS-IS/BGP won't be found. These routers sometimes even get used in L3VPN. It's not the providers job to dictate what gear the customer wants to use. I rarely care about the stability of a customer network. I strictly care that my stuff works, it provides services to the customer, and the upkeep is as low as I can make it, especially for MPLS services. Jack
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins <jlogginsccie@gmail.com> wrote:
OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that
Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments.
every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
As an implementation of distance vector, its at least useful as a teaching tool about routing theory, history and implementations. John
Dynamic routing is hard, let's go shopping. Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die... My $0.02, -Jack On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff <jtk@cymru.com> wrote:
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins <jlogginsccie@gmail.com> wrote:
OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that
Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments.
every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
As an implementation of distance vector, its at least useful as a teaching tool about routing theory, history and implementations.
John
RIP cannot also be used for traffic engineering; so if you want MPLS then you MUST use either OSPF or ISIS. RIP, like any other distance vector protocol, converges extremely slowly - so if you want faster convergence then you have to use one of ISIS or OSPF. Glen
Maybe I WAY under-read the initial poster's question, but I was pretty sure he wasn't talking about running it as a CORE routing protocol or anything on the middle of their network where MPLS would be expected on top of it! If I missed it and he did intend that, then I'd certainly agree with you (among many other reasons why it would be a horrible idea)! ;) Scott On 9/30/10 12:59 PM, Glen Kent wrote:
RIP cannot also be used for traffic engineering; so if you want MPLS then you MUST use either OSPF or ISIS. RIP, like any other distance vector protocol, converges extremely slowly - so if you want faster convergence then you have to use one of ISIS or OSPF.
Glen
-----Original Message----- From: Jack Carrozzo Sent: Thursday, September 30, 2010 9:44 AM To: John Kristoff Cc: nanog@nanog.org Subject: Re: RIP Justification
Dynamic routing is hard, let's go shopping.
Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die...
My $0.02,
-Jack
The one and only place I have used RIPv2 and RIPng is for distributing igp information on links between BGP routers. Say I have a cluster of such routers with some /30 links (for IPv4) to transit, peers and each other. Basically I run RIP with "redistribute connected" on them and only running on the internal interfaces connecting the routers. All RIP is doing at that point is providing an igp path to the BGP next hop. There is really no need to run OSPF for that and frankly I don't WANT OSPF running there for other reasons.
On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote:
Dynamic routing is hard, let's go shopping.
Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die...
But what about all of those students even now working on getting their Lab RIP routing to work ? Surely such a huge crowd-sourcing will solve any remaining problems with the protocol by the end of the term! Regards Marshall
My $0.02,
-Jack
On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff <jtk@cymru.com> wrote:
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins <jlogginsccie@gmail.com> wrote:
OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that
Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments.
every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
As an implementation of distance vector, its at least useful as a teaching tool about routing theory, history and implementations.
John
Yes, clearly the next crowd of CCNAs will save the world. You know what they say about giving CCNAs enable... -Jack On Thu, Sep 30, 2010 at 2:37 PM, Marshall Eubanks <tme@americafree.tv>wrote:
On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote:
Dynamic routing is hard, let's go shopping.
Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die...
But what about all of those students even now working on getting their Lab RIP routing to work ? Surely such a huge crowd-sourcing will solve any remaining problems with the protocol by the end of the term!
Regards Marshall
My $0.02,
-Jack
On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff <jtk@cymru.com> wrote:
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins <jlogginsccie@gmail.com> wrote:
OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that
Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments.
every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
As an implementation of distance vector, its at least useful as a
teaching
tool about routing theory, history and implementations.
John
I was just curious - why would IS-IS be more die-hard than OSPF or iBGP?
It's like running apps on Solaris and Oracle these days instead of Linux and MySQL. Both options work if you know what you're doing, but it's way easier (and cheaper) to hire admins for the latter. When was the last time you ran into a younger neteng designing his topology who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less used. I know there are a lot of guys on here using IS-IS and I'm certainly not knocking it... </flamewarprotection> -Jack
On 9/30/2010 3:32 PM, Jack Carrozzo wrote:
When was the last time you ran into a younger neteng designing his topology who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less used.
Which makes no sense to me. I originally looked at both and thought OSPF to be inferior to IS-IS. That being said, OSPF is supported on more (and cheaper) hardware. IS-IS can have additional licensing with some hardware (where OSPF does not) and is often considered a "service provider" protocol by vendors. Jack
As it was explained to me, the main difference is that you can have $lots of prefixes in IS-IS without it falling over, whereas Dijkstra is far more resource-intensive and as such OSPF doesn't get too happy after $a_lot_less prefixes. Those numbers can be debated as you like, but I think if you were to redist bgp ospf on a lab machine you'd get the point. Disclaimer: I've never run IS-IS operationally, just in the lab. -Jack
Which makes no sense to me. I originally looked at both and thought OSPF to be inferior to IS-IS. That being said, OSPF is supported on more (and cheaper) hardware. IS-IS can have additional licensing with some hardware (where OSPF does not) and is often considered a "service provider" protocol by vendors.
Jack
On 30 September 2010 22:11, Jack Carrozzo <jack@crepinc.com> wrote:
As it was explained to me, the main difference is that you can have $lots of prefixes in IS-IS without it falling over, whereas Dijkstra is far more resource-intensive and as such OSPF doesn't get too happy after $a_lot_less prefixes. Those numbers can be debated as you like, but I think if you were to redist bgp ospf on a lab machine you'd get the point.
Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it.. RIPv2 is great for simple route injection. I'm talking really simple, just to avoid statics.
Haha It's all good :) You are right about IS-IS being less resource intensive than OSPF, and that it scales better! On 30 September 2010 23:50, Jack Carrozzo <jack@crepinc.com> wrote:
Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it..
Sorry, my mistake. I'll go sit in my corner now... -Jack
On Sep 30, 2010, at 3:47 PM, Heath Jones wrote:
On 30 September 2010 22:11, Jack Carrozzo <jack@crepinc.com> wrote:
As it was explained to me, the main difference is that you can have $lots of prefixes in IS-IS without it falling over, whereas Dijkstra is far more resource-intensive and as such OSPF doesn't get too happy after $a_lot_less prefixes. Those numbers can be debated as you like, but I think if you were to redist bgp ospf on a lab machine you'd get the point.
Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it..
RIPv2 is great for simple route injection. I'm talking really simple, just to avoid statics.
And there, my friend, is the crux of the matter. There's almost no place imagineable where injecting routes from RIPv2 is superior to statics. Owen
RIPv2 is great for simple route injection. I'm talking really simple, just to avoid statics.
And there, my friend, is the crux of the matter. There's almost no place imagineable where injecting routes from RIPv2 is superior to statics.
Well, let me stimulate your imagination.. IPVPN cloud provided by carrier. Head office is ethernet into cloud. Remote sites are DSL, so terminating on LNS within cloud, and have one or more prefixes behind CPE. Pretty simple stuff. Now, when traffic comes from head office destined for a site prefix, it hits the provider gear. That provider gear will need routing information to head to a particular site. If you wanted to use statics, you will need to fill out a form each time you add/remove a prefix for a site and the provider must manage that. Its called a 'pain in the arse'. Enter RIPv2.
participants (32)
-
Brandon Kim -
Charles Mills -
Chris Woodfield -
Christian Martin -
Christopher Gatlin -
Craig -
Crist Clark -
Dale W. Carder -
Fred Baker -
Gary Gladney -
George Bonser -
Glen Kent -
Heath Jones -
Jack Bates -
Jack Carrozzo -
James Downs -
Jesse Loggins -
Joe Greco -
John Kristoff -
Jonathon Exley -
Julien Goodwin -
Mark Smith -
Marshall Eubanks -
Nathan Eisenberg -
Nick Hilliard -
Owen DeLong -
Patrick W. Gilmore -
Ricky Beam -
Scott Morris -
Stephen Sprunk -
William McCall -
Yasuhiro Ohara