The use of RIPng
mtinka at globaltransit.net
Wed Jun 2 10:44:19 CEST 2010
On Wednesday 02 June 2010 01:07:40 am Benedikt Stockebrand
> 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
Can't say I've heard of such a recommendation, but I'd
likely spin more cycles making this do what I want than
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.
> 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
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
> > 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
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
But again, that's just me :-).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100602/8cd4c13d/attachment.bin
More information about the ipv6-ops