Mike Bilow is rumoured to of said:
>
>
> Terry Dawson wrote in a message to Mike Bilow:
>
> TD> I use a manually defined default route as the catch all and
> TD> let rspf handle the exception. This seems to work fairly
> TD> well, though I can fairly easily imagine scenarios where
> TD> this might not work. You always have the option of starting
> TD> with no routes and just waiting for rspf to build them for
> TD> you. Isn't it true that when I am first detected as a new
> TD> adjacency my neighbours should perform a full routing
> TD> broadcast for me ? If not, I wonder if it shouldn't be, or
> TD> if some functional equivalent to an 'rspf query' could not
> TD> be implemented so that when I start, and find an adjacency I
> TD> can ask them to tell me what they know?
An rspf query for a set of routes for a particular router is a rspf routing
bulletin for that router with a sequence number of 0. 0 is guarranteed to
be the "lowest" number as we don't use cyclic sequence numbers (see rspf
spec IV.2.1.2), see below as to why a low number means an update.
Now IV.3.2 says that when a new adjacency is found a full routing update
should happen. This is a bit hard as you may not know what you have just
made an adjacency is a router (it could be just a host not running rspf).
I get around this by only sending a full bulletin to a Tentative adjacency
that I have just recieved a RRH from; guess it depends on your definition
of "acquired".
There is no way for you to tell a router to "send me everything", well there
is using an undocumented debug feature but this is via the 9006 port. It's
for impatient programmers like me. But there is none in the protocol.
> This was discussed at one point early in the development of RSPF, and it is a
> tempting thing to try. However, a little thinking about it leads to the
> realization that it would provide an opportunity for catastrophic failure where
> routers forcibly update each other and prevent useful traffic from passing over
> the channel hogged by routing updates. These sorts of things have actually
> happened in real networks, and they have been studied extensively. There are
> also security concerns, since a spoof could start a thrashing condition that
> would quickly bring down the whole network.
You may need to give some more details here, but I believe this sort of
thing has been worked out already.
Hmm, ok, a router A receives a route bulletin from B and router A decides it
has newer information, it will update B by sending A's version of that
routing bulletin. B will then update its counters so they are the same as A.
Now if that routing information was for B (ie it was of B's adjacencies)
then B will, in current versions, ignore those adjacencies but it will
increment and store the sequence number, so it has the current information
for itself (which makes sense).
Now this sort of thrash has happen with pre release versions of rspfd. I
cannot remember the exact reason but it was due to me getting confused with
the fact that a poll is for a *single* routing bulletin.
I think we're forgetting here is that what rspf was to be used for was to
break up a subnet into little paths of hopeful reachability. With the new
kernels, the ifconfig'ed routes should handle the general stuff, there may
be a default used and then rspf fills in the gaps. ie if I have an interface
with address/netmask of 44.136.8.0/24 then what I am usually saying is that
hosts 44.136.8.1 to 44.136.8.254 are *directly reachable* via that
interface. RSPF takes that best first effort and says "well except
44.136.8.5 which you have to use 44.136.8.220". (If you are reading this
Sam, it's a hint!). It's intra-subnet routing.
- Craig vk2xlz
-- / /\ | | Craig Small VK2XLZ <ufoai.bkshs@technophobia.co.uk> |==||==|=| Finger plam.cebjpicmz@metroflux.net for PGP key. \ \/ | | fingerprint = AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90