The use of RIPng

[Ted Mittelstaedt]

On 6/1/2010 10:07 AM, Benedikt Stockebrand wrote:
> Hi Mark and list,
>
> Mark Tinka<mtinka at globaltransit.net>  writes:
>
>> On Tuesday 01 June 2010 11:01:16 pm Benedikt Stockebrand
>> wrote:
>>
>>> As far as deployment goes: If you use e.g. a BSD or
>>>   Solaris you get a lightweight RIP daemon as part of the
>>>   base system, so with these systems deployment is
>>>   actually a bit easier---you just turn it on.
>>
>> Then install Quagga/Zebra and run OSPF or IS-IS.
>
> that's a bit of a pain involved there.  Additionally, it is
> recommended not to run it on a machine that does anything else, mostly
> because the init scripts (or equivalent) and Quagga tend to interfere
> with each other.
>
>> I'm sorry, I just don't subscribe to the idea of teaching
>> folk to use RIP in today's networks, despite the size of
>> their business (I hold workshops myself, I know) - because
>> this stuff sticks.
>
> Valid point.  And I agree that moving from RIP to OSPF is a rather
> gory business, especially if you delay the move until RIP becomes a
> problem rather than a solution.
>
> However, there are businesses that rarely grow to the point that they
> have a full-time sysadmin around, and the choices there are either
> static routes (which are fascinatingly prone to typos) or RIP to
> maintain routing tables automatically.
>
> At least here in Germany we have lots of small but IT-heavy
> businesses, like accounting/tax advisor shops, engineering offices and
> such.  They usually have an external contractor to take care of
> everything related to computers, from buying the right type of toner
> cartridge to setting up and maintaining their networks (of 5--25
> hosts, 2--3 routers).  To them, RIP makes life easier while OSPF is an
> undefused bomb.
>

Why do you use 2-3 routers with a grand total of 25 hosts?!?

Ted

>> The most I tend to say about RIP - don't use it! In addition
>> to the "other way" we we tend to describe it.
>
> [Parse Error?]
>
>>> (And yes, I've seen people overextending themselves with
>>>   OSPF...)
>>
>> So tell them to ignore all those knobs the industry has
>> added to the spec. They don't need (m)any of them.
>
> My point is on troubleshooting, not configuring things.  You don't
> have to use areas (beyond backbone) or whatever, but it still takes
> quite some background to understand that the LSAs you see are wrong,
> figure out what they mean, why and how they mess up your routing, how
> to track down their source and how to get rid of them.
>
>> If you're having problems stuffing enough useful information
>> about link state routing protocols into your tutorials, I'd,
>> respectfully, look at working on that instead.
>
> Since I mostly do IPv6 tutorials I normally run into only one of two
> situations:
>
> - If I have participants who know about OSPFv2, then telling them about
>    the differences between v2 and v3 is no big deal; it's mostly
>    "router IDs are still 32 bits, so you can't just use an IPv6 address
>    there, the authentication mechanisms have gone in favour of IPsec"
>    and similar.
>
> - If I have participants who don't know about OSPFv2, usually because
>    they are less routing centric, then I won't spend time on teaching
>    elementary OSPF because there are plenty topics more relevant to them.
>
> Doing a three day course on OSPF alone is fine, but stuffing OSPF into
> a three day course on IPv6 is just running people into trouble.
>
>
> Cheers,
>
>      Benedikt
>