[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Openbsd 3.0 stable routing problems



Hi all,

I recently upgraded from 2.9-stable to 3.0-stable, and have
run into a problem.  I've been running NAT on the OpenBSD
box between an internal network (196.168.200/24) and the
outside world.  As of the upgrade, however, the routing has
gone strange.

If I traceroute a box on the internal network using a name
defined in /etc/hosts, everything works:

 skuld:~$ traceroute urd                                        
 traceroute to urd.homeworld.net (192.168.200.32), 64 hops max, 40 byte packets
  1  urd.homeworld.net (192.168.200.32)  0.560 ms  0.536 ms  0.529 ms

However, if I use the IP address itself:
 skuld:~$ traceroute 196.168.200.32
 traceroute to 196.168.200.32 (196.168.200.32), 64 hops max, 40 byte packets
  1  Booth-RSM-184.caltech.edu (131.215.184.253)  174.559 ms  21.635 ms  54.419 ms
  2  Booth-border.ilan.caltech.edu (131.215.254.254)  20.35 ms  126.529 ms  14.776 ms
  3  nabisco.dmz.caltech.edu (192.12.19.3)  29.693 ms  23.689 ms  52.625 ms
  4  nabisco.dmz.caltech.edu (192.12.19.3)  24.477 ms !H

And so on.  For some reason, the request has been routed out
the external interface.  This will happen even trying to go
to the OpenBSD box itself:

 skuld:~$ traceroute 196.168.200.254
 traceroute to 196.168.200.254 (196.168.200.254), 64 hops max, 40 byte packets
  1  Booth-RSM-184.caltech.edu (131.215.184.253)  25.641 ms  142.153 ms  18.920 ms
  2  Booth-border.ilan.caltech.edu (131.215.254.254)  22.652 ms  24.152 ms  24.132 ms
  3  nabisco.dmz.caltech.edu (192.12.19.3)  137.619 ms  22.400 ms  16.330 ms

To my admittedly unexpert eyes, the routing tables seem
sane:

 skuld:~$ netstat -rn
 Routing tables

 Internet:
 Destination        Gateway            Flags     Refs     Use    Mtu  Interface
 default            131.215.184.254    UGS         4     4337   1500   dc0
 127/8              127.0.0.1          UGRS        0        0  33224   lo0
 127.0.0.1          127.0.0.1          UH          4       26  33224   lo0
 131.215.184/24     link#1             UC          0        0   1500   dc0
 131.215.184.254    0:0:c:7:ac:3       UHL         1        0   1500   dc0
 192.168.200/24     link#2             UC          0        0   1500   dc1
 192.168.200.32     0:50:da:6c:c9:92   UHL         0        9   1500   dc1
 192.168.200.254    127.0.0.1          UGHS        0        0  33224   lo0
 192.168.200.255    link#2             UHL         3       57   1500   dc1
 224/4              127.0.0.1          URS         0        0  33224   lo0

 [snipped the IPv6]

dc0 is the external interface, and dc1 is the internal
interface.  Both are Linksys LNE100TX cards:

 dc0 at pci0 dev 11 function 0 "ADMtek AN983" rev 0x11: irq 5 address 00:03:6d:13:1e:e7
 ukphy0 at dc0 phy 1: Generic IEEE 802.3u media interface
 ukphy0: OUI 0x000895, model 0x0001, rev. 0
 dc1 at pci0 dev 17 function 0 "ADMtek AN983" rev 0x11: irq 9 address 00:03:6d:13:1e:55
 ukphy1 at dc1 phy 1: Generic IEEE 802.3u media interface
 ukphy1: OUI 0x000895, model 0x0001, rev. 0

This is 3.0-stable, with a GENERIC kernel.  It is *not* a
result of NAT or IP forwarding; the above traceroutes were
obtained with both pf and net.inet.ip.fowarding disabled.

I'm sure that the problem is that I'm missing something
obvious, but I'm really at a loss.  Any suggestions would be
appreciated.

Thanks in advance,

Bjorn Christianson

-- 
bjorn@etho.caltech.edu        http://www.its.caltech.edu/~bjorn
Computation & Neural Systems, Caltech 216-76, Pasadena CA 91125