The use of RIPng

Benedikt Stockebrand me at benedikt-stockebrand.de
Tue Jun 1 19:07:40 CEST 2010


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.

> 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

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/



More information about the ipv6-ops mailing list