The use of RIPng

[Mark Tinka]

On Wednesday 02 June 2010 01:07:40 am Benedikt Stockebrand 
wrote:

> 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.

Can't say I've heard of such a recommendation, but I'd 
likely spin more cycles making this do what I want than 
running RIP.

But that's just me; it's a free world, you're welcome to run 
whatever you like :-).

> 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.

Aye.

> 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.

These might probably afford to employ someone like yourself 
to come in as-needed to fix problems with their link state 
routing protocol.

The workshops we do are generally formatted in a 'service 
provider' style, but we find all types of organizations 
attending and benefiting from them anyway, from enterprise 
to university, e.t.c.

The moral of the story is that you never know how/when your 
network will scale up. So rather than having to migrate to a 
more scalable deployment in the future, just do it now even 
if it may look like a waste of time. It doesn't cost you 
much more.

> > 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?]

Rest In Peace.

> 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.

We tackle this problem by having a Basic and Advanced set of 
sessions. We have found that it's easy to load a lot of fat 
on tutorials and make routing protocols seem more 
complicated than they actually are (or perhaps, should be), 
e.g., it probably is not very useful to go into Dijkstra 
Algorithm details, header format details, e.t.c.

Advanced sessions can then look at more detail of the 
protocol. Provided you lock down the basics in the Basic 
session and encourage good network design, interaction with 
the IGP will not be as often as you might think, if ever 
(the only time we touch our IS-IS setup is when we're 
deploying a new router or new interface). If you're spending 
too much debugging your IGP, your probably have a poor 
network design to start with.

> - 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.

I think routing protocols are as relevant to IP as IP, 
itself, is. Once your participants understand the IPv6 
protocol, they need to understand how to propagate those IP 
addresses within the network. At some point, you can't 
detach the two.

Whatever they take in now will stick for a very long time, 
and what we've seen with workshops is the hardest thing to 
teach participants is how to "unlearn" the bad stuff they've 
picked up from allover.

> 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.

I really can't tell you how to do your job. Only you know it 
best :-). But the fact about getting down the good 
principles in the start, remains, and personally, while you 
can't stop folk from doing what they want to do, RIP should 
really not be talked about in public, especially to virgin 
operators. 

But again, that's just me :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100602/8cd4c13d/attachment.bin