thr3ads.net - zfs discuss - [zfs-discuss] ISCI Network Hang

If this information is useful, please help other people find it:
Share via:

2009-Jan-11 23:36 UTC

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

I am sharing out ZFS ISCSI luns to my Mac. When copying large files, the network
will hang in the middle of the transfer and the LUN will become unavailable
until I plumb the NIC. This issue appears to only occur only when I am reading
files (ie..syncing an ipod) and not writing (I''m not 100% sure though).
When I snoop the interface I notice a bunch of ARP lookups. Any ideas? Thanks in
advanced.

Solaris Build:    OpenSolaris 2008.11 snv_101b_rc2 X86
           Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 19 November 2008


Below is the output from snoop. 10.0.1.200 is the Solaris server and 10.0.1.4 is
the Mac client.
  
10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072298406 Len=2352 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072300758 Len=4390 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072305148 Len=2920 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072308068 Len=1700 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072309768 Len=2920 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072312688 Len=5320 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072318008 Len=2920 Win=64240
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072195178 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072198098 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072203178 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072206098 Seq=405482834
Len=0 Win=65535
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072320928 Len=5320 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072326248 Len=2920 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072329168 Len=5080 Win=64240
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Push Ack=405482834
Seq=1072334248 Len=2920 Win=64240
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072209958 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072212878 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Ack=1072215278 Seq=405482834
Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
362)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 362)
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51699 Push Ack=133176904
Seq=1610109515 Len=48 Win=65535 Options=<nop,nop,tstamp 628354654 67148>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Ack=1610109563 Seq=133176952
Len=0 Win=65160 Options=<nop,nop,tstamp 67569 628354643>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Push Ack=1610109563
Seq=133176904 Len=48 Win=65160 Options=<nop,nop,tstamp 67582 628354643>
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Ack=405483698 Seq=1073633082
Len=1460 Win=64240
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
363)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 363)
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
364)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 364)
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51699 Push Ack=133176904
Seq=1610109515 Len=48 Win=65535 Options=<nop,nop,tstamp 628354670 67148>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Ack=1610109563 Seq=133176952
Len=0 Win=65160 Options=<nop,nop,tstamp 67729 628354643>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Push Ack=1610109563
Seq=133176904 Len=48 Win=65160 Options=<nop,nop,tstamp 67753 628354643>
  10.0.1.200 -> 10.0.1.1     DNS C 250.255.255.239.in-addr.arpa. Internet PTR
?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
365)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 365)
  10.0.1.200 -> 10.0.1.1     DNS C _nfsv4idmapdomain.nyc.rr.com. Internet TXT
?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
366)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 366)
  10.0.1.200 -> 10.0.1.4     TCP D=51683 S=3260 Ack=405483698 Seq=1073633082
Len=1460 Win=64240
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
367)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 367)
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51699 Push Ack=133176904
Seq=1610109515 Len=48 Win=65535 Options=<nop,nop,tstamp 628354702 67148>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Ack=1610109563 Seq=133176952
Len=0 Win=65160 Options=<nop,nop,tstamp 68050 628354643>
  10.0.1.200 -> 10.0.1.4     TCP D=51699 S=3260 Push Ack=1610109563
Seq=133176904 Len=48 Win=65160 Options=<nop,nop,tstamp 68094 628354643>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
368)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 368)
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
369)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 369)
  10.0.1.200 -> 10.0.1.1     DNS C 250.255.255.239.in-addr.arpa. Internet PTR
?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
370)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 370)
  10.0.1.200 -> 10.0.1.1     DNS C _nfsv4idmapdomain. Internet TXT ?
    10.0.1.4 -> 10.0.1.255   UDP D=631 S=631 LEN=140
  10.0.1.200 -> 10.0.1.1     DNS C 255.1.0.10.in-addr.arpa. Internet PTR ?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
371)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 371)
    10.0.1.4 -> 10.0.1.255   UDP D=631 S=631 LEN=175
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
372)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 372)
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
373)
  10.0.1.200 -> 10.0.1.4     ICMP Echo reply (ID: 40450 Sequence number: 373)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51699 Push Ack=133176904
Seq=1610109515 Len=48 Win=65535 Options=<nop,nop,tstamp 628354766 67148>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
374)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,nop,wscale 1,nop,nop,tstamp 628354778
0,sackOK,eol>
  10.0.1.200 -> 10.0.1.1     DNS C 250.255.255.239.in-addr.arpa. Internet PTR
?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
375)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
  10.0.1.200 -> 10.0.1.1     DNS C _nfsv4idmapdomain. Internet TXT ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,nop,wscale 1,nop,nop,tstamp 628354787
0,sackOK,eol>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
376)
  10.0.1.200 -> 10.0.1.1     DNS C 255.1.0.10.in-addr.arpa. Internet PTR ?
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,nop,wscale 1,nop,nop,tstamp 628354797
0,sackOK,eol>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
377)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,sackOK,eol>
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
378)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,sackOK,eol>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
379)
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,sackOK,eol>
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
  10.0.1.200 -> 10.0.1.1     DNS C 250.255.255.239.in-addr.arpa. Internet PTR
?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
380)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
381)
  10.0.1.200 -> 10.0.1.1     DNS C 255.1.0.10.in-addr.arpa. Internet PTR ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51683 Fin Ack=1073633082
Seq=405483698 Len=0 Win=65535
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
    10.0.1.4 -> 10.0.1.200   TCP D=3260 S=51734 Syn Seq=3476025541 Len=0
Win=65535 Options=<mss 1460,sackOK,eol>
    10.0.1.4 -> 10.0.1.200   ICMP Echo request (ID: 40450 Sequence number:
382)
  10.0.1.200 -> (broadcast)  ARP C Who is 10.0.1.4, 10.0.1.4 ?
-- 
This message posted from opensolaris.org

2009-Jan-13 02:57 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

Some additional info:

I''m using the default port 3260 and native iscsitgt (not Comstar). What
other details would you like? Im running OpenSolaris 2008.11 snv_101b_rc2 X86
Thinkpad T60p laptop with 3GB of memory, a 2.1Ghz core duo proc, with 2 500gb
mirriored USB drives. I did notice that when I do an ifconfig -a I see my NIC
twice.


 I actually came across these bugs 6638604 and 6680855 while doing my due
diligence before posting to the forums. I tried the workarounds but am still
seeing the issue. Once the network hang occurs and  I try an arp -a it just
hangs until I reset the interface. Not sure if there is something I''m
missing when setting the arp intervals and static arp entries.

Before issue:

root at opensolaris:~# ndd /dev/ip ip_ire_arp_interval

86400000

root at opensolaris:~# ndd /dev/arp arp_cleanup_interval

3600000

root at opensolaris:~# arp -a

Net to Media Table: IPv4

Device   IP Address               Mask      Flags      Phys Addr

------ -------------------- --------------- -------- ---------------

e1000g0 10.0.1.1             255.255.255.255 o        00:1f:f3:42:73:a0

e1000g0 10.0.1.4             255.255.255.255 o        00:1e:52:76:14:f2

e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f

e1000g0 BASE-ADDRESS.MCAST.NET 240.0.0.0       SM       01:00:5e:00:00:00

root at opensolaris:~# arp -s 10.0.1.1 00:1f:f3:42:73:a0

root at opensolaris:~# arp -s 10.0.1.4 00:1e:52:76:14:f2

root at opensolaris:~# arp -a

Net to Media Table: IPv4

Device   IP Address               Mask      Flags      Phys Addr

------ -------------------- --------------- -------- ---------------

e1000g0 10.0.1.1             255.255.255.255 S        00:1f:f3:42:73:a0

e1000g0 10.0.1.4             255.255.255.255 S        00:1e:52:76:14:f2

e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f

e1000g0 BASE-ADDRESS.MCAST.NET 240.0.0.0       SM       01:00:5e:00:00:00

root at opensolaris:~# 

After Issue:

root at opensolaris:~# arp -a

Net to Media Table: IPv4

Device   IP Address               Mask      Flags      Phys Addr

------ -------------------- --------------- -------- ---------------

^C

root at opensolaris:~# ndd /dev/arp arp_cleanup_interval

3600000

root at opensolaris:~# ndd /dev/ip ip_ire_arp_interval

86400000

root at opensolaris:~# 

root at opensolaris:~# ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1

    inet 127.0.0.1 netmask ff000000 

e1000g0: flags=201004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4,CoS> mtu
1500 index 12

    inet 10.0.1.200 netmask ffffff00 broadcast 10.0.1.255

    ether 0:15:58:2e:af:8f 

wpi0: flags=201000802<BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 13

    inet 0.0.0.0 netmask 0 

    ether 0:13:2:b9:86:27 

lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252
index 1

    inet6 ::1/128 

e1000g0: flags=202004841<UP,RUNNING,MULTICAST,DHCP,IPv6,CoS> mtu 1500
index 12

    inet6 fe80::215:58ff:fe2e:af8f/10 

    ether 0:15:58:2e:af:8f 

root at opensolaris:~# 

Rgds,

Marc
-- 
This message posted from opensolaris.org

Richard Elling

2009-Jan-13 03:45 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

M wrote:> Some additional info:
>
> I''m using the default port 3260 and native iscsitgt (not Comstar).
What other details would you like? Im running OpenSolaris 2008.11 snv_101b_rc2
X86 Thinkpad T60p laptop with 3GB of memory, a 2.1Ghz core duo proc, with 2
500gb mirriored USB drives. I did notice that when I do an ifconfig -a I see my
NIC twice.
>   
You have one IPv4 and one IPv6 address, which is why you see e1000g
twice.
>  I actually came across these bugs 6638604 and 6680855 while doing my due
diligence before posting to the forums. I tried the workarounds but am still
seeing the issue. Once the network hang occurs and  I try an arp -a it just
hangs until I reset the interface. Not sure if there is something I''m
missing when setting the arp intervals and static arp entries.
>   
That won''t fix it... whatever it is.  You''re losing the net
and you
need to solve that problem first.  I''d check /var/adm/messages file
and see if there is anything unusual, then fmdump -eV, looking for
clues.

> Before issue:
>
> root at opensolaris:~# ndd /dev/ip ip_ire_arp_interval
>
> 86400000
>
> root at opensolaris:~# ndd /dev/arp arp_cleanup_interval
>
> 3600000
>
> root at opensolaris:~# arp -a
>
> Net to Media Table: IPv4
>
> Device   IP Address               Mask      Flags      Phys Addr
>
> ------ -------------------- --------------- -------- ---------------
>
> e1000g0 10.0.1.1             255.255.255.255 o        00:1f:f3:42:73:a0
>
> e1000g0 10.0.1.4             255.255.255.255 o        00:1e:52:76:14:f2
>
> e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f
>
> e1000g0 BASE-ADDRESS.MCAST.NET 240.0.0.0       SM       01:00:5e:00:00:00
>
> root at opensolaris:~# arp -s 10.0.1.1 00:1f:f3:42:73:a0
>
> root at opensolaris:~# arp -s 10.0.1.4 00:1e:52:76:14:f2
>
> root at opensolaris:~# arp -a
>
> Net to Media Table: IPv4
>
> Device   IP Address               Mask      Flags      Phys Addr
>
> ------ -------------------- --------------- -------- ---------------
>
> e1000g0 10.0.1.1             255.255.255.255 S        00:1f:f3:42:73:a0
>
> e1000g0 10.0.1.4             255.255.255.255 S        00:1e:52:76:14:f2
>
> e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f
>
> e1000g0 BASE-ADDRESS.MCAST.NET 240.0.0.0       SM       01:00:5e:00:00:00
>
> root at opensolaris:~# 
>
> After Issue:
>
> root at opensolaris:~# arp -a
>
> Net to Media Table: IPv4
>
> Device   IP Address               Mask      Flags      Phys Addr
>
> ------ -------------------- --------------- -------- ---------------
>
> ^C
>   
By default, arp will try to resolve (reverse lookup) the IP addresses.
This is a bad thing, if you are not connected to the net, since it will
wait patiently for the reverse lookups to timeout.  When troubleshooting
nets, you should use the -n flag which disables reverse lookups: arp -an,
netstat -rn, etc.
 -- richard
> root at opensolaris:~# ndd /dev/arp arp_cleanup_interval
>
> 3600000
>
> root at opensolaris:~# ndd /dev/ip ip_ire_arp_interval
>
> 86400000
>
> root at opensolaris:~# 
>
> root at opensolaris:~# ifconfig -a
>
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
>
>     inet 127.0.0.1 netmask ff000000 
>
> e1000g0:
flags=201004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4,CoS> mtu 1500
index 12
>
>     inet 10.0.1.200 netmask ffffff00 broadcast 10.0.1.255
>
>     ether 0:15:58:2e:af:8f 
>
> wpi0: flags=201000802<BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 13
>
>     inet 0.0.0.0 netmask 0 
>
>     ether 0:13:2:b9:86:27 
>
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu
8252 index 1
>
>     inet6 ::1/128 
>
> e1000g0: flags=202004841<UP,RUNNING,MULTICAST,DHCP,IPv6,CoS> mtu 1500
index 12
>
>     inet6 fe80::215:58ff:fe2e:af8f/10 
>
>     ether 0:15:58:2e:af:8f 
>
> root at opensolaris:~# 
>
> Rgds,
>
> Marc
>

2009-Jan-13 04:29 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

Thanks for the response Richard.

<That won''t fix it... whatever it is. You''re losing the net
and you
need to solve that problem first. I''d check /var/adm/messages file
and see if there is anything unusual, then fmdump -eV, looking for
clues.
<
I don''t see anything in the messages file or fmdump when the issue
occurs.

<By default, arp will try to resolve (reverse lookup) the IP addresses.
This is a bad thing, if you are not connected to the net, since it will
wait patiently for the reverse lookups to timeout. When troubleshooting
nets, you should use the -n flag which disables reverse lookups: arp -an,
netstat -rn, etc.
<

Looks like Im losing the arp data somehow....could it be something on the client
side (10.0.1.4)?
root at opensolaris:~# arp -an
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
e1000g0 10.0.1.1             255.255.255.255          00:1f:f3:42:73:a0
e1000g0 10.0.1.4             255.255.255.255 U        
e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f
e1000g0 224.0.0.0            240.0.0.0       SM       01:00:5e:00:00:00
root at opensolaris:~# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface 
-------------------- -------------------- ----- ----- ---------- --------- 
default              10.0.1.1             UG        1         92 e1000g0   
10.0.1.0             10.0.1.200           U         1        170 e1000g0   
127.0.0.1            127.0.0.1            UH        1         14 lo0       

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If   
--------------------------- --------------------------- ----- --- ------- ----- 
fe80::/10                   fe80::215:58ff:fe2e:af8f    U       1       0
e1000g0
::1                         ::1                         UH      1       0 lo0   
root at opensolaris:~# ping 10.0.1.1
no answer from 10.0.1.1

Message was edited by: mfish
-- 
This message posted from opensolaris.org

Richard Elling

2009-Jan-13 04:45 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

M wrote:> Thanks for the response Richard.
>
> <That won''t fix it... whatever it is. You''re losing
the net and you
> need to solve that problem first. I''d check /var/adm/messages file
> and see if there is anything unusual, then fmdump -eV, looking for
> clues.
> <
> I don''t see anything in the messages file or fmdump when the issue
occurs.
>
> <By default, arp will try to resolve (reverse lookup) the IP addresses.
> This is a bad thing, if you are not connected to the net, since it will
> wait patiently for the reverse lookups to timeout. When troubleshooting
> nets, you should use the -n flag which disables reverse lookups: arp -an,
> netstat -rn, etc.
> <
>
> Looks like Im losing the arp data somehow....could it be something on the
client side (10.0.1.4)?
>   
Yes, the client might be losing the net rather than the Thinkpad.
 -- richard
> root at opensolaris:~# arp -an
> Net to Media Table: IPv4
> Device   IP Address               Mask      Flags      Phys Addr
> ------ -------------------- --------------- -------- ---------------
> e1000g0 10.0.1.1             255.255.255.255          00:1f:f3:42:73:a0
> e1000g0 10.0.1.4             255.255.255.255 U        
> e1000g0 10.0.1.200           255.255.255.255 SPLA     00:15:58:2e:af:8f
> e1000g0 224.0.0.0            240.0.0.0       SM       01:00:5e:00:00:00
> root at opensolaris:~# netstat -rn
>
> Routing Table: IPv4
>   Destination           Gateway           Flags  Ref     Use     Interface 
> -------------------- -------------------- ----- ----- ---------- --------- 
> default              10.0.1.1             UG        1         92 e1000g0   
> 10.0.1.0             10.0.1.200           U         1        170 e1000g0   
> 127.0.0.1            127.0.0.1            UH        1         14 lo0       
>
> Routing Table: IPv6
>   Destination/Mask            Gateway                   Flags Ref   Use   
If
> --------------------------- --------------------------- ----- --- -------
-----
> fe80::/10                   fe80::215:58ff:fe2e:af8f    U       1       0
e1000g0
> ::1                         ::1                         UH      1       0
lo0
> root at opensolaris:~# ping 10.0.1.1
> no answer from 10.0.1.1
>
> Message was edited by: mfish
>

2009-Jan-13 17:56 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

The client isn''t losing the network. After the issue I am still able to
ping other systems and get to the web from the mac. On the other hand I cant
ping any hosts or get to the web from the server.
-- 
This message posted from opensolaris.org

2009-Jan-22 19:48 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

Here what fixed this:

Added

tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

to /kernel/drv/e1000g.conf
-- 
This message posted from opensolaris.org

2009-Jan-22 19:48 UTC

head link

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

Heres what fixed this:

Added

tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

to /kernel/drv/e1000g.conf
-- 
This message posted from opensolaris.org

Seemingly Similar Threads

Search for more maybe matching threads

zfs discuss - Jan 2009 - ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

[zfs-discuss] ISCI Network Hang - Lun becomes unavailable

Seemingly Similar Threads