Does Netapp filer support RFC2131?

[steve_bui]

We have a mishap last friday when a server was mistakenly configured  with an ip address duplicate of a filer and caused other servers to not  being able to reach their volumes/luns and crashed. Our linux admins said if NetApp filers support RFC2131 then it should have detected the duplicate ips and sent back a bad code to the Linux server. The linux server would not let the admins use it. RFC2131 says “Duplicate address detection mode (DAD).  See RFC2131. 4.4.1  Returns 0 if DAD succeeded i.e. no replies are received.”.

Does Netapp filer support RFC2131?

[billshaffer]

RFC2131 is for DHCP.  DHCP has a mechanism to check if an IP is in use before handing it out, but I think it is only a ping.  If the linux box got a DHCP address that was already taken by the filer, that is an issue with the DHCP server config.

I have not heard of something that, on manual configuration of an IP address, will say "hey, that's already in use" and refuse to use it (though I'd be interested to hear of one!).

Bill

[steve_bui]

Hi Bill,

Our linux admin tested it out and said that linux does get back an error if the ip address is in use.

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

This happens whenever I do the VLAN testing.  The IP that was free before when I ran the test previously,  is now assigned to a guest VM.

This is on PROD POOL1 using an unassigned IP:

# cat ifcfg-eth0

DEVICE="eth0"

NM_CONTROLLED="no"

ONBOOT="yes"

IPADDR=129.219.113.210

##IPADDR=129.219.113.206

NETMASK=255.255.255.192

GATEWAY=129.219.113.193

# ping 129.219.16.157

PING 129.219.16.157 (129.219.16.157) 56(84) bytes of data.

64 bytes from 129.219.16.157: icmp_seq=1 ttl=122 time=2.52 ms

64 bytes from 129.219.16.157: icmp_seq=2 ttl=122 time=1.12 ms

^C

--- 129.219.16.157 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1538ms

rtt min/avg/max/mdev = 1.120/1.820/2.520/0.700 ms

Change the IP to one already in use:

# cat ifcfg-eth0

DEVICE="eth0"

NM_CONTROLLED="no"

ONBOOT="yes"

##IPADDR=129.219.113.210

IPADDR=129.219.113.206

NETMASK=255.255.255.192

GATEWAY=129.219.113.193

# service network restart

Shutting down interface eth0:  [  OK  ]

Shutting down loopback interface:  [  OK  ]

Bringing up loopback interface:  [  OK  ]

Bringing up interface eth0:  Error, some other host already uses address 129.219.113.206.

[FAILED]

# ping 129.219.16.157

connect: Network is unreachable

This is a ping from 129.219.113.206 , network is still up:

# ping 129.219.16.157

PING 129.219.16.157 (129.219.16.157) 56(84) bytes of data.

64 bytes from 129.219.16.157: icmp_seq=1 ttl=122 time=1.31 ms

--- 129.219.16.157 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 1.315/1.315/1.315/0.000 ms

---sB

[billshaffer]

Ah, okay - this is just functionality built into linux networking scripts:

ifup-eth:

...

         if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then

            net_log $"Error, some other host already uses address ${IPADDR}."

            exit 1

         fi

...

The man page for arping mentions RFC2131:4.4.1 for the -D switch, which detects duplicate addresses (as you said).

RFC2131:4.4.1 states (in part):

The client SHOULD perform a check on the suggested address to ensure that the address is not already in use.  For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

So your question shouldn't really be "is the filer RFC2131 compliant", since RFC2131 applies to DHCP, and 4.4.1 ONLY applies to DHCP client actions - plus, it only says the client SHOULD check the address, so even if a client doesn't do this, he is still RFC compliant.  Plus, arping will only really work on a flat network, unless ARP forwarding is set up.

The filer doesn't really have any option but to respond to an ARP request - otherwise it wouldn't get any traffic.  So your question should more likely be "why didn't the filer get the arping sent by the server," and that really needs to be directed to the network guys.

Of course, having the server guys be more careful when the configure IP addresses would be helpful too.  It doen't take too long to do a ping before configuration....

Hope that helps, and sorry, I don't mean to be preachy....

Bill