The use of RIPng

[Benedikt Stockebrand]

Nick Hilliard <nick at foobar.org> writes:

> On 01/06/2010 18:07, 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.
>
> lolwut?!??!

With the vast majority of network services available on common Unixes,
the default configuration listens on all interfaces, i.e. it does a
listen on 0.0.0.0 or ::.  In that case it doesn't really matter in
which sequence services get started, and for that reason the ordering
constraints for services are frequently somewhat incomplete.

Now if you configure a service to listen only on a specific address,
then the starting order *does* matter, because if the address from the
service configuration isn't configured on an interface when the
service attempts to start, the service won't come up.  This is
particularly painful if it happens to the sshd, which on the other
hand should be started as soon as possible to give an admin a chance
to fix problems remotely even if the boot sequence doesn't finish.

With parallel startup mechanisms like upstart or SMF the situation
gets even worse because the startup order becomes nondeterministic.

>>> 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
>
> lolwut^2?

If you wait for the move from RIP to OSPF until you reach the
limitations of RIP, most notably network diameter, then you have quite
likely reached a point where you have to use both RIP and OSPF
simultaneously for the migration phase.

Redistributing routes between different routing protocols in
real-world environments tends to be messy, especially if you have to
manipulate the metrics, and is one of those things you don't want to
do only occasionally.  Having little experience with OSPF yet doesn't
make things easier, either.

Doing multi-protocol routing is something you want to leave to people
who do very little else, so that's usually only an option if you are
either an ISP/NSP, a large data center or possibly a large enterprise.

>> hosts, 2--3 routers).  To them, RIP makes life easier while OSPF is an
>> undefused bomb.
>
> huh?

You send one or two of your generic system/network administrators to a
three to five day OSPF training.  Afterwards they manage to deploy
OSPF in your network.

Half a year later, and with absolutely no reason to fiddle around with
OSPF since the network works, something breaks.  Not having touched
any OSPF for months, they have forgotten much of what they've learned
and the only chance they have to find and fix the problem is to dig
out those old training manuscripts, trying to recall what the relevant
details of have learned.  All this under significant time pressure.

Since you are so keen on not having a 45s loss of service, this should
be a particularly alarming scenario to you.

Or maybe you can find out in 45s what a type 5 LSA with OSPFv3 means?

>> 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 have found that I don't need to understand the finer points of internal
> combustion mechanics, spark plug design and exhaust muffling technology in
> order to drive down to the shop to buy a loaf of bread.

If it is your job to keep that car working, and more importantly, to
fix it again if it breaks, then you *do* need to know about it.

Of course, if you are an end user, that's not a problem to you.

> Ok, let me spell it out.  If you're running a routing protocol on your
> end-user workstations, you're probably doing it wrong.  If you're running a
> routing protocol on your routers, then it goes like this:
>
> RIP configuration:
>
> router rip
>  version 2
>  redistribute connected
>  redistribute static
>  default-information originate
>  passive-interface FastEthernetX/Y
>
> or OSPF:
>
> router ospf 1
>  redistribute connected subnets
>  redistribute static subnets
>  default-information originate
>  network a.b.c.0 0.0.0.255 area 0
>  passive-interface FastEthernetX/Y
>
> The configuration parameters are similarly difficult for RIPng and OSPFv3,
> or if you use Quagga instead of IOS, or JunOS instead of Quagga.
>
> I'm at a loss to see why one is much more difficult than the other.  Can
> you explain?

On FreeBSD, enabling RIPng is a single line

    ipv6_router_enable=YES

in /etc/rc.conf, while on Solaris you run

    # routeadm -e ipv6-routing
    # routeadm -u

This *is* simpler than installing anything extra, sorting out
potential init script issues mentioned above or any such thing.  So
much about running OSPF on Unix.

Beyond that, your RIP configuration apparently works, but your OSPF
one doesn't---maybe in the future you could try them out first, before
publicly posting them.  I have taken the liberty to dump your
configuration into a toy 1812W, running 12.4(15)T1, just to make sure
that I didn't just imagine the obvious error.  But I got what I
expected when I actually checked things:

    Router#show ip ospf 1 
    %OSPF: Router process 1 is not running, please configure a router-id
    Router#

This is one of the very first things you should learn about OSPF: Be
extremely careful about properly setting unique router IDs---even more
so with OSPFv3, where an IP address can't be conveniently re-used as a
router ID.  

And in a more general context it's also one of the very first things
you should learn about any system or network administration in
general: Always check the results.  And, if possible, double and
triple check.

But that's still not the point.

The real point is that things happen.  Hardware breaks, software is
buggy and, most importantly, people make mistakes.  Maybe you have
never had to deal with a "mission critical" system, but I have (and
no, that TOP500 cluster wasn't the worst one).

Fixing a problem that costs anything from 10000 Euro (or USD,
whatever) per minute isn't fun, especially because very quickly you
tend to have a flash mob (aka. unscheduled meeting of the board)
breathing down your neck.  

What's worse, situations that you could cope with in a relaxed lab
environment tend to turn out much more difficult to handle when they
happen in production, because that's usually at 03:00 when you are dog
tired, the colleague you desperatley need at the other end of the line
5000 km (3000 sm) away is down with flu and you're so pumped with
adrenaline that most of whatever intelligence it leaves you can barely
keep the fight or flight reflex at bay.

If you are too optimistic about your skills when you set up things,
then you are likely to learn about your limits and those of your
colleagues and successors the hard way.

> This thread is becoming too bizarre for words, but for some reason, I can't
> seem to pull myself away from it.

Maybe for starters you could just try to stop posting broken
configurations and false statements about protocols you haven't tried
out and don't understand.

> Maybe don't explain after all.

I'm not so much explaining but trying to help people finding your
postings in search engines from getting into unnecessary trouble.


    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

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