I have a portmaster which I want to listen to the ospf default route
broadcast by my Internet router (a Cisco). This portmaster is at a pop
and behind a Cisco router which then connects to the main Internet router.
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:
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:
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 1, candidate default path
Tag 1, type extern 2, forward metric 1785
Redistributing via ospf 1
Last update from 206.206.152.1 on Serial0.16, 00:23:48 ago
Routing Descriptor Blocks:
* 206.206.152.1, from 206.206.152.17, 00:23:48 ago, via Serial0.16
Route metric is 1, traffic share count is 1
Even "show ospf links" on that PM has the correct mask:
External Links for All Areas
Link ID Advertising Router Sequence TOS Ext Age Mask
--------------- ------------------ ---------- --- --- ---- ----
0.0.0.0 206.206.152.17 0x80000531 No No 486 0
------------------------------------------------------------------------
RIPv1 vs. RIPv2
For some reason Livingston doesn't let you do OSPF on dial-in users,
dial-out locations, sub-interfaces (?), basically anything except
hardwired ports.
To get around this, one would use RIP (v1) which ComOS does support. You
can even tell the PM to redistribute routes learned through RIP into OSPF
which is nice. The problem is that RIPv1 is terrible for today's routing
requirements! It doesn't even support VLSM.
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
code written?? The packet formats are identical as seen below (for the
curious):
RIPv1:
0 7 15 31 <- Bits
+---------------+--------------+---------------------------------+ ---
| command (1-6) | version (1) | (must be zero) | |
+---------------+--------------+---------------------------------+ |
| Address family (2) | (must be zero) | |
+------------------------------+---------------------------------+ 20
| 32-bit ip address | bytes
+----------------------------------------------------------------+ |
| (must be zero) | |
+----------------------------------------------------------------+ |
| (must be zero) | |
+----------------------------------------------------------------+ |
| metric (1-16) | |
+----------------------------------------------------------------+ ---
| (up to 24 more routes with same |
| format as the previous 20 bytes) |
And RIPv2:
0 7 15 31 <- Bits
+---------------+--------------+---------------------------------+ ---
| command (1-6) | version (2) | routing domain | |
+---------------+--------------+---------------------------------+ |
| Address family (2) | route tag | |
+------------------------------+---------------------------------+ 20
| 32-bit ip address | bytes
+----------------------------------------------------------------+ |
| 32-bit subnet mask | |
+----------------------------------------------------------------+ |
| 32-bit next hop address | |
+----------------------------------------------------------------+ |
| metric (1-16) | |
+----------------------------------------------------------------+ ---
| (up to 24 more routes with same |
| format as the previous 20 bytes) |
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.
Give us something better, please!
- Steve
- Systems Manager
- Community Internet Access, Inc.
- Gallup and Grants, New Mexico