Date: Thu, 07 Aug 1997 10:56:49 -0700 From: John Milford <jwm@CSUA.Berkeley.EDU> To: hackers@freebsd.org Subject: Routing problems Message-ID: <199708071757.KAA24249@soda.CSUA.Berkeley.EDU>
next in thread | raw e-mail | index | archive | help
A new 2.2.2 machine has recently been droping off the net for some unknown reason. This can take from 15 min. to 24 hour to happen and the only way to bring it back is to reboot. At least that is the only way I have found. I have found that the routing table looks a little strange when this happens: # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 128.32.240.254 UGSc 8 28 fxp0 127.0.0.1 127.0.0.1 UH 0 5640 lo0 128.32.134/24 link#1 UC 0 0 128.32.134.5 8:0:5a:47:21:53 UHLW 1 209 vx0 465 128.32.134.17 0:20:af:d3:78:9a UHLW 1 26 lo0 128.32.134.240 0:0:f8:1:8e:e2 UHLW 0 7 vx0 779 128.32.134.254 0:0:93:10:6a:d8 UHLW 0 0 vx0 1116 128.32.240/24 link#2 UC 0 0 128.32.240.39 link#2 UHLW 0 3 128.32.240.190 0:a0:c9:6b:12:b1 UHLW 0 17276 lo0 128.32.240.231 link#2 UHLW 1 267 128.32.240.254 link#2 UHLW 8 0 Where "link #2" appears I would expect to see a MAC adress. I would also expect to see all 240 net routes associated with fpx0. I tried flushing the routing table: # route flush default inr-115-eecs-new-net done route: write to routing socket: No such process got only -1 for rlen # route -v flush Examining routing table from sysctl RTM_GET: Report Metrics: len 132, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STAT IC,PRCLONING> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY,NETMASK> default inr-115-eecs-new-net-1.Berkeley.EDU (255) ffff 0 100 RTM_DELETE: Delete Route: len 132, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,STA TIC,PRCLONING> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY,NETMASK> default inr-115-eecs-new-net-1.Beecs-new-net-1.Berkeley.EDU (255) ffff 0 100 RTM_GET: Report Metrics: len 124, pid: 0, seq 0, errno 0, flags:<UP,HOST,LOCAL> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> localhost localhost RTM_GET: Report Metrics: len 136, pid: 0, seq 0, errno 0, flags:<UP,CLONING> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY,NETMASK> 128.32.134.0 (255) ffff ffff ff RTM_GET: Report Metrics: len 128, pid: 0, seq 0, errno 0, flags:<UP,HOST,LLINFO, WASCLONED> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> godzilla 8.0.5a.47.21.53 RTM_GET: Report Metrics: len 128, pid: 0, seq 0, errno 0, flags:<UP,HOST,LLINFO, WASCLONED,LOCAL> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> fantasia 0.20.af.d3.78.9a RTM_GET: Report Metrics: len 128, pid: 0, seq 0, errno 0, flags:<UP,HOST,LLINFO, WASCLONED> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> saidin 0.0.f8.1.8e.e2 RTM_GET: Report Metrics: len Report Metrics: len 128, pid: 0, seq 0, errno 0, f lags:<UP,HOST,LLINFO,WASCLONED> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> inr-116-eecs.Berkeley.EDU 0.0.93.10.6a.d8 RTM_GET: Report Metrics: len 124, pid: 0, seq 0, errno 0, flags:<UP,GATEWAY,HOST ,WASCLONED,PROTO3> locks: inits: <pksent,sendpipe,recvpipe,expire> sockaddrs: <DST,GATEWAY> garnet.Berkeley.EDU inr-115-eecs-new-net-1.Berkeley.EDU route: write to routing socket: No such process got only -1 for rlen I have been looking at the source, but have not come up with anything. I have found that with just the 3c590 (vx0) that this does not occur, and in fact that when this problem occurs the machine can be acessed from the 134 net (vx0). Is it possible that the Intel card is causing the routing table to get munged like this? Any ideas on how to debug this will be graetly appreciated. --John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708071757.KAA24249>