The use of RIPng
ted.m at ipinc.net
Tue Jun 1 19:14:09 CEST 2010
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
>>> 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?!?
>> 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
>> 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
> - 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.
More information about the ipv6-ops