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?
On 1 October 2010 12:19, Tim Franklin <tim@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.
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:hj1980@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 <tim@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).
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:hj1980@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 <tim@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).
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:tim@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?
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.
participants (5)
-
Guerra, Ruben -
Heath Jones -
Jonathon Exley -
Owen DeLong -
Tim Franklin