Mailing List Archive

Current state of ISISd
In spring of 2003 we (me, Cougar and one my coworker) looked at isisd
code and tried to find out how usable it is in current state. During
this we made some fixes which are now commited to the CVS.

What it can do at the moment:

1) It runs only in Linux and FreeBSD AFAIK.

2) Apart from IS-IS "internal" stuff (form adjacencies, elect DIS etc)
it can receive and receive LSP's. It sends LSP's with "must be" info
only - hostname, internal reachability info etc. No extrenal
reachability info - ie. it CAN'T redistribute any routes. While
receiving LSP's it parses extrenal reachability info as well and puts
routes into zebra RIB with fixed distance 110.

That's basically all. No any redistribution or filtering or ... So, it
isn't usable at all for any productions and I recommend to disable it
in packages.

This is unofficial "what's next" list (as much info as I remember).

1) ISISd can't be started with config file it writes. ISISd expects
"router isis XXXX" node commands entered before interface node
commands - ie. area should be defined before putting interface to the
area.

2) ISISd will be very confused when DIS changes. Don't remember
details.

3) There is at least one crash related to threads. We solved it with
hack in lib/thread.c [don't try to use unused threads]. Of course it
isn't correct solution and this needs to be tracked down.

4) Time used in spf doubles with every run if both ipv4 and ipv6 is
enabled in interface.

interface eth0
ip router isis DEAD
ipv6 router isis DEAD
!

...

I'm sure that there will be more ...

I looked briefly how to implement redistributing. It's not easy copy
and paste from other daemons, because IS-IS has areas, but these are
not like ospf areas. IS-IS doesn't send routes from one area to
another and areas might have different redsitribution rules.

router isis <area>
redstribute ...
!
router isis <area>
redistribute ...
!

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator