Re: RIP Justification
The knowhow for BGP in that environment is all of about 30 minutes worth of training. They should find a way to get it, IMHO. Owen On Oct 4, 2010, at 10:56 PM, Jonathon Exley wrote: It also scales better from the SP point of view. If you have 1000 L3VPN services on your PE node using OSPF to the customer that would require a lot of memory for the multiple LSDBs and a lot of CPU for the SPF calculations. BGP is nicer but the reality is that many enterprises don't have the know-how. Jonathon -Original Message- From: Heath Jones [mailto:hj1...@gmail.com] Sent: Saturday, 2 October 2010 12:39 a.m. To: Tim Franklin Cc: nanog@nanog.org Subject: Re: RIP Justification On 1 October 2010 12:19, Tim Franklin t...@pelican.org wrote: Or BGP. Why not? Of course, technically you could use almost any routing protocol. OSPF and IS-IS would require more configuration and maintenance, BGP even more still. I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain. 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).
Re: RIP Justification
On Fri, Oct 01, 2010 at 04:28:30PM +, Tim Franklin wrote: Leaf-node BGP config is utterly trivial [...] The Enterprise guys really need to get out of the blanket BGP is scary mindset It's not just enterprise mindset. Over the years I've seen a lot of deployed gear that either didn't support BGP at all or for which it was a significant extra cost. At least in the past this applied to many firewalls and load-balancers, and until recently, even one of the major CMTS vendors didn't support BGP. I agree that edge-node BGP is simple, but finding gear that supports it isn't necessarily so. --Jeff
RE: RIP Justification
It also scales better from the SP point of view. If you have 1000 L3VPN services on your PE node using OSPF to the customer that would require a lot of memory for the multiple LSDBs and a lot of CPU for the SPF calculations. BGP is nicer but the reality is that many enterprises don't have the know-how. Jonathon -Original Message- From: Heath Jones [mailto:hj1...@gmail.com] Sent: Saturday, 2 October 2010 12:39 a.m. To: Tim Franklin Cc: nanog@nanog.org Subject: Re: RIP Justification On 1 October 2010 12:19, Tim Franklin t...@pelican.org wrote: Or BGP. Why not? Of course, technically you could use almost any routing protocol. OSPF and IS-IS would require more configuration and maintenance, BGP even more still. I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain. 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).
Re: RIP Justification
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
Re: RIP Justification
On Sep 30, 2010, at 3:47 PM, Heath Jones wrote: On 30 September 2010 22:11, Jack Carrozzo j...@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
Re: RIP Justification
Why would you run dynamic to simple CPE at all? Static route that stuff through DHCP or RADIUS and move on. If you need dynamic routing across administrative boundaries, that's not a good place for RIP, that's a good place for BGP. Owen On Sep 30, 2010, at 5:54 PM, Guerra, Ruben wrote: I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE peace -- Ruben Guerra - Sent from my Nokia N900 - Original message - 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 j...@crepinc.commailto:j...@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
Re: RIP Justification
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.
Re: RIP Justification
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. Or BGP. Why not?
Re: RIP Justification
On 1 October 2010 12:19, Tim Franklin t...@pelican.org wrote: Or BGP. Why not? Of course, technically you could use almost any routing protocol. OSPF and IS-IS would require more configuration and maintenance, BGP even more still. I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain.
Re: RIP Justification
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
RE: RIP Justification
Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest. Using BGP would be overkill for most. Many small commercial customers to not want the complexity of BGP or want to spend money on extra resources (routers that actually support it) Sure for someone that needs to announce their own space or wants multi-homed connection def use BGP. -Ruben -Original Message- From: Tim Franklin [mailto:t...@pelican.org] Sent: Friday, October 01, 2010 6:19 AM To: nanog@nanog.org Subject: Re: RIP Justification 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. Or BGP. Why not?
Re: RIP Justification
- Ruben Guerra ruben.gue...@arrisi.com wrote: Using BGP would be overkill for most. Many small commercial customers to not want the complexity of BGP This one keeps coming up. Leaf-node BGP config is utterly trivial, and is much easier for the SP to configure the necessary safety devices on their side to stop you from shooting yourself in the foot and blowing up your networks - or worse, *their* network. Plus, if / when in the future you need to do something clever, you've already got the routing protocol with all the advanced knobs in place, ready for you to tweak as needed. The Enterprise guys really need to get out of the blanket BGP is scary mindset - running BGP for an SP with multitudes of customers, peers, transits, aggregation, filters etc and getting it right needs expertise and experience. Announcing a /24 LAN and receiving a default on a single link, not so much. or want to spend money on extra resources (routers that actually support it) This has a bit more weight to it, if you're at the really low end (certainly the consumer end). But a BGP-capable Cisco 800-series is, what, £300? Regards, Tim.
Re: RIP Justification
Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest. Just to be perfectly clear with the scenario I was referring to (L3VPN with all remote sites hitting provider router) that Tim was responding to.. The kit is all managed - customer has no access to it. I should have mentioned that before, as it's a pretty key point to the example, perhaps it was thought the customer could touch it? What is needed is simply one step above statics so the provider does not have to maintain them. Loops or hop count are a non-issue, and the customer sites have no redundancy. It's not even a requirement to have fast convergence. All that is required is to have the CPE say 'here is 10.0.0/24', or at a later date, '10.0.1/24' without any work on any other equipment. Nice and easy. RIPv2. Arguing that BGP should be used over RIPv2 in this scenario becomes interesting, as BGP would offer no real advantages and requires further configuration in most cases for each site deployed. It also introduces more overhead for the carrier, the same with OSPF and IS-IS. In other scenarios - of course choose a different protocol - but for this one, I think its a good example for the OP as to why RIPv2 is still used.
Re: RIP Justification
On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin ch...@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 rek...@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 na...@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
Re: RIP Justification
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. +1 - for me, if I need a dynamic routing protocol between trust / administrative domains, it's BGP unless there's a good reason not to. I find it more straightforward to work with (albeit slightly more up-front to configure it and get it right) than anything else - the information available is a very clear who am I talking to? / what routes do I send them? / what routes do they send me?. Plus I can work through the route-selection process by hand from the information displayed, and have it make sense. Regards, Tim.
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [1]na...@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]na...@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:na...@studio442.com.au 2. mailto:na...@studio442.com.au
Re: RIP Justification
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
Re: RIP Justification
On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Thu, 30 Sep 2010 01:15:45 -0500 William McCall william.mcc...@gmail.com wrote: On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin ch...@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 rek...@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 na...@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
Re: RIP Justification
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins jlogginsc...@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
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 On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff j...@cymru.com wrote: On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins jlogginsc...@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
Re: RIP Justification
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
RE: RIP Justification
-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.
Re: RIP Justification
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 j...@cymru.com wrote: On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins jlogginsc...@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
Re: RIP Justification
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 t...@americafree.tvwrote: 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 j...@cymru.com wrote: On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins jlogginsc...@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
RE: RIP Justification
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... I was just curious - why would IS-IS be more die-hard than OSPF or iBGP? Best Regards, Nathan Eisenberg
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
On 30 September 2010 22:11, Jack Carrozzo j...@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.
Re: RIP Justification
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
Re: RIP Justification
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 j...@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
Re: RIP Justification
I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE peace -- Ruben Guerra - Sent from my Nokia N900 - Original message - 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 j...@crepinc.commailto:j...@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
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 (RS, Service Provider)
Re: RIP Justification
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
RE: RIP Justification
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:jlogginsc...@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 (RS, Service Provider)
Re: RIP Justification
IPVPN arrangement with multiple sites no redundancy for each small site. RIP to advertise networks from each site towards cloud, quick and easy.
Re: RIP Justification
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 patr...@ianai.netwrote: 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: w3y...@gmail.com
Re: RIP Justification
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 glad...@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:jlogginsc...@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 (RS, Service Provider)
RE: RIP Justification
-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.
Re: RIP Justification
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 (RS, Service Provider)
Re: RIP Justification
On Wed, 29 Sep 2010 16:20:48 -0400, Jesse Loggins jlogginsc...@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
Re: RIP Justification
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 K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: RIP Justification
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
Re: RIP Justification
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.
Re: RIP Justification
I am referring to RIPv2 On Wed, Sep 29, 2010 at 1:52 PM, Heath Jones hj1...@gmail.com wrote: 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. -- Jesse Loggins CCIE#14661 (RS, Service Provider)
RE: RIP Justification
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: e...@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
Re: RIP Justification
Thus spake Jesse Loggins (jlogginsc...@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
Re: RIP Justification
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
RE: RIP Justification
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:jlogginsc...@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 (RS, 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).
Re: RIP Justification
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 jlogginsc...@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 (RS, Service Provider)
Re: RIP Justification
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.
RE: RIP Justification
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: jgr...@ns.sol.net Subject: Re: RIP Justification To: patr...@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.
Re: RIP Justification
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.
Re: RIP Justification
On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin ch...@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 glad...@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:jlogginsc...@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 (RS, Service Provider)
Re: RIP Justification
On 9/29/2010 at 4:24 PM, Joe Greco jgr...@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.
Re: RIP Justification
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 (RS/Security) On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin ch...@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.
Re: RIP Justification
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.
Re: RIP Justification
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
Re: RIP Justification
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:jlogginsc...@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 (RS, 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).
Re: RIP Justification
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
Re: RIP Justification
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
Re: RIP Justification
On Wed, 29 Sep 2010 17:26:17 -0400 Craig cvulja...@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 jlogginsc...@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 (RS, Service Provider)
Re: RIP Justification
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 (RS/Security) On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin ch...@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.
Re: RIP Justification
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?
Re: RIP Justification
On Wed, 29 Sep 2010 19:31:26 -0500 Christopher Gatlin ch...@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.
Re: RIP Justification
On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin na...@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.
