OSPF, RIP (fwd)

MegaZone (megazone@livingston.com)
Sat, 31 May 1997 20:08:49 +1700 (PDT)

Once upon a time Stephen Fisher shaped the electrons to say...
>In order to get it to listen to the route I had to set gateway 0.0.0.0 and
>reboot the box (ugh!). Now it looks like this:

I think resetting routing might have worked there actually.

>Destination Mask Gateway Source Flag Met Interface
>----------------- ---- -------------------- ------- ---- --- ---------
>0.0.0.0 255 206.206.162.97 ospf/E2 ND 2 ether0
>
>It works fine but the mask shouldn't be /255! It should be /0 as seen in
>the Cisco it is behind:

That might be a cosmetic bug - it is behaving correctly, right?

>For some reason Livingston doesn't let you do OSPF on dial-in users,
>dial-out locations, sub-interfaces (?), basically anything except
>hardwired ports.

I think it does work on sub-interfaces actually. But that may have been
something in 3.5.1bx or something. I'm too involved in new things to
keep actually released code and beta code seperate in my mind sometimes.

But I just explained in another post why we don't:
1. Another RFC entirely.
2. Next to now demand - basically you are almost the *only* user who asks
for it. On the info forms, at trade shows, surveys, sakes calls, etc -
I have never heard anyone ask for it.

>So if Livingston won't support OSPF (I wish they would though) on things
>like dial-out locations I think they should at least support RIPv2. This
>seems very easy, especially since someone said Livingston already had the

Not likely. The code was mostly done. But then we added BGP and redid
most of the routing core - and that means RIPv2 would have to be redone
to work with the new code. AND lots of new work would have to be done
to handle route injection, the routing filters that are in the BGP rev,
etc. A lot more work.

In addition, as we've said, the older units are getting tight on FLASH.
The RIPv2 code is not small. In the same room it would eat, we could
do a slew of other features.

And, on top of it all, as I explained - no where near sufficient demand.

>code written?? The packet formats are identical as seen below (for the

That is the easy part. HANDLING the data is what is different. AND
RIPv2 is not backwards compatible with many RIPv1 boxes. That is why
you find units with 'compatibility' modes

>Since the packet formats are identical Livingston could just support RIPv2
>and when it talked to hosts that only supported RIPv1 it would just ignore
>the extra information. Or of course they could support both.

No, that is considered extremely rude in the networking would. You have
to support BOTH. You simply have to support RIPv1 - it is still the only
thing many products speak, period. RIPv2 on the other hand is no where
as nearly wide spread, and OSPF is far better any way. RIPv2 is used by
companies unwilling, or unable, to get OSPF out.

If we were to support any VLSM dialin/out active routing protocol it
would be OSPF.

But the bottom line is - insufficient demand at this time.

Honestly, it just might be that our products are not suited to your
requirements if this is something you must have. We can accept that.

-MZ

--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 4464 Willow Road, Pleasanton, CA 94588