Linux-Hams archive - July 1997: confusion over routing with rspf

confusion over routing with rspf

Simon J Mudd (fybpr@ambra.ro)
Mon, 30 Jun 1997 22:43:01 +0200 (MET DST)


Craig, (if you're about, this might be best answered by you, I'm not sure)

I have a small problem which I am experiencing using rspf and linux.

device ax0 is configured as follows:

[ea4els@unicorn ea4els]$ /sbin/ifconfig ax0
ax0 Link encap:AMPR AX.25 HWaddr EA4ELS-5
inet addr:44.133.228.2 Bcast:44.133.228.63 Mask:255.255.255.192
UP BROADCAST RUNNING MTU:256 Metric:1
RX packets:23510 errors:0 dropped:0 overruns:0
TX packets:7717 errors:0 dropped:0 overruns:0

This is I think correct. Initially I have no specific routing information
to ax0 apart from the device configuration above, but this is sufficient
to route access to all hosts on the 44.133.228/26 network.

However another host on the same network, ea4rct, using rspf is
broadcasting a route to THIS network on the same frequency. Here I am
unclear whether this is correct, tolerated or not. The end result is my
rspf daemon notes this information and adds a dynamic route to
44.133.228.0/26 through ea4rct.

Having done so, any paquets, including broadcast paquetes are sent
directly to EA4RCT, and not to the specified host on the network,
without routing.

Should not the "metric" of the interface's configuration
take priority over a dynamic "learnt" metric, which has to pass through
the same interface, or is the problem that ea4rct should not be
broadcasting routes TO this network ON THIS NETWORK?

I've included the routing table below in both "symbolic", and numeric
forms, marking the lines which are causing me concern:

comments would be appreciated.

[ea4els@unicorn ea4els]$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
eb4euf.ampr.org ea4bqg.ampr.org 255.255.255.255 UGHD 127 0 4 ax0
phoenix.ea4els. * 255.255.255.255 UHD 0 0 1 eth0
unicorn.ea4els. * 255.255.255.255 UHD 0 0 0 eth0
vhf.ea4rct.ampr * 255.255.255.255 UHD 63 0 0 ax0
ea4bqg.ampr.org * 255.255.255.255 UHD 63 0 0 ax0
ea4yd.ampr.org * 255.255.255.255 UHD 63 0 0 ax0
ec4dfp.ampr.org * 255.255.255.255 UHD 63 0 0 ax0
pc.ea4bqg.ampr. ea4bqg.ampr.org 255.255.255.255 UGHD 64 0 0 ax0
linux.ea4rct.am vhf.ea4rct.ampr 255.255.255.255 UGHD 65 0 0 ax0
nos.ea4rct.ampr ea4yd.ampr.org 255.255.255.255 UGHD 71 0 0 ax0
ea4rca.ampr.org ea4yd.ampr.org 255.255.255.255 UGHD 71 0 0 ax0
default ea4yd.ampr.org 255.255.255.255 UGD 79 0 0 ax0
madrid-70cm-net vhf.ea4rct.ampr 255.255.255.224 UGD 71 0 0 ax0
madrid-2m-net!!!vhf.ea4rct.ampr!255.255.255.192!UGD!!!127!!!!0!!!!!!!!1!ax0
madridnet ea4bqg.ampr.org 255.255.255.0 UGD 127 0 0 ax0
eaamprnet ea4yd.ampr.org 255.255.0.0 UGD 71 0 0 ax0
loopback * 255.0.0.0 U 0 0 991 lo

[ea4els@unicorn ea4els]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
44.133.28.113 44.133.28.47 255.255.255.255 UGHD 127 0 4 ax0
44.133.28.118 0.0.0.0 255.255.255.255 UHD 0 0 1 eth0
44.133.28.96 0.0.0.0 255.255.255.255 UHD 0 0 0 eth0
44.133.228.1 0.0.0.0 255.255.255.255 UHD 63 0 0 ax0
44.133.28.47 0.0.0.0 255.255.255.255 UHD 63 0 0 ax0
44.133.28.9 0.0.0.0 255.255.255.255 UHD 63 0 0 ax0
44.133.28.89 44.133.28.47 255.255.255.255 UGHD 64 0 0 ax0
44.133.28.138 44.133.228.1 255.255.255.255 UGHD 65 0 0 ax0
44.133.28.76 44.133.28.9 255.255.255.255 UGHD 71 0 0 ax0
44.133.28.29 44.133.28.9 255.255.255.255 UGHD 71 0 0 ax0
0.0.0.0 44.133.28.9 255.255.255.255 UGD 79 0 0 ax0
44.133.228.64 44.133.228.1 255.255.255.224 UGD 71 0 0 ax0
44.133.228.0!!!!44.133.228.1!!!!255.255.255.192!UGD!!!127!!!!0!!!!!!!!0!ax0
44.133.28.0 44.133.28.47 255.255.255.0 UGD 127 0 0 ax0
44.133.0.0 44.133.28.9 255.255.0.0 UGD 71 0 0 ax0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 991 lo
[ea4els@unicorn ea4els]$

regards,

Simon J Mudd, Madrid SPAIN +34-1-559 2854 e-mail: terhi.victor@logonet.com
[short messages - from radio hams] ----> yae@linzu2-215-201.utaonline.at