Topic
  • 3 replies
  • Latest Post - ‏2012-10-03T17:05:40Z by el_esceptico
el_esceptico
el_esceptico
4 Posts

Pinned topic V7000 Unified

‏2012-10-02T16:03:59Z |
Hello,

I am new in this forum. I have problems with V7000 Unified. I have been working fine with the unified with the following IPs:

-Management Unified IP: 172.22.64.185
-Node File 1: 172.22.64.183
-Node File 2: 172.22.64.184

I have created a public netnork through gui. This public network has the following settings:

-Subnet: 172.22.0.0/16
-IP addresses: 172.22.64.183, 172.22.64.184

When I have configured it I have lost access to the Unified. I don't have access to any file module(172.22.64.183, 172.22.64.184) and to the management IP Unified(172.22.64.185). I have restarted the file modules aand at first I can ping to file modules, but when the management Unified IP is going to active all the IPs are lost.

I think that the problem would resolved if I can delete the public network(172.22.0.0/16). The only way to connect is through direct console to file module.

Thank you.
Updated on 2012-10-03T17:05:40Z at 2012-10-03T17:05:40Z by el_esceptico
  • chriscanto
    chriscanto
    292 Posts

    Re: V7000 Unified

    ‏2012-10-02T20:15:43Z  
    It sounds like you might have configured duplicate IP addresses for NAS services on the 10GbE interfaces to those which you already had configured for management access on the 1GbE interfaces.

    Your plan of removing and replacing the public network config using a console connection sounds sensible. I think the relevant CLI commands are lsnw, rmnw, chnw (or use the GUI), etc and attachnw, detachnw etc.
  • SystemAdmin
    SystemAdmin
    4779 Posts

    Re: V7000 Unified

    ‏2012-10-03T14:38:06Z  
    The public network you define should not reuse any addresses assigned to either the file module or V7000 for manangement (cluster or service addresses). Defining them in both will likely cause the loss of access you've seen.

    There are at least two possibilities for why you may have also lost access to the cluster management addresses with the configuration you describe above.
    1) You have, as suggested by Chris, added the network to your 10G interface when the management addresses are bound to the 1G
    2) You have defined a different gateway for the network

    Both of these could lead to bad routing causing loss of access due to the overlap of subnets used by the data and management addresses.

    In either of these cases connecting to the console as you suggest should allow you to remove the network you defined in using the GUI.

    ---

    You can list the currently defined networks using lsnw:

    http://kd52y0g.ibm$ lsnw
    Network VLAN ID Network Groups IP-Addresses Routes
    172.22.0.0/16 DEFAULT 172.22.64.183,172.22.64.184
    EFSSG1000I The command completed successfully.

    In your case these IPs conflict with your file module service IPs

    You can see the actual IP allocations using lsnwinterface

    http://kd52y0g.ibm$ lsnwinterface
    Node Interface MAC Master/Subordinate Bonding mode Transmit hash policy Up/Down Speed IP-Addresses MTU
    mgmt001st001 ethX0 e4:1f:13:d6:06:64 MASTER active-backup (1) UP 1000 172.22.64.184 1500
    mgmt001st001 ethX1 00:00:c9:bb:af:2a MASTER active-backup (1) UP 10000 1500
    mgmt002st001 ethX0 e4:1f:13:d6:05:64 MASTER active-backup (1) UP 1000 172.22.64.183 1500
    mgmt002st001 ethX1 00:00:c9:bb:af:66 MASTER active-backup (1) UP 10000 1500
    EFSSG1000I The command completed successfully.

    In the above example the network has been attached to the 1G interface (ethX0)

    You can detach the IPs using the detachnw command (using the interface found with the lsnwinterface command as above):

    http://kd52y0g.ibm$ detachnw ethX0 172.22.0.0/16
    EFSS1GG0015I Refreshing data.
    EFSSG1000I The command completed successfully.

    Would now give:

    http://kd52y0g.ibm$ lsnwinterface
    Node Interface MAC Master/Subordinate Bonding mode Transmit hash policy Up/Down Speed IP-Addresses MTU
    mgmt001st001 ethX0 e4:1f:13:d6:06:64 MASTER active-backup (1) UP 1000 1500
    mgmt001st001 ethX1 00:00:c9:bb:af:2a MASTER active-backup (1) UP 10000 1500
    mgmt002st001 ethX0 e4:1f:13:d6:05:64 MASTER active-backup (1) UP 1000 1500
    mgmt002st001 ethX1 00:00:c9:bb:af:66 MASTER active-backup (1) UP 10000 1500
    EFSSG1000I The command completed successfully.

    At this point your access to the file module service IPs should be restored, however, if you had a gateway defined on that network the route may have been removed. In this case you may need to reboot the file modules before access is restored.

    If you want to go back to the GUI and edit the configuration, you should now be able to do so. Make sure to change the IP addresses so they do not conflict with any management/service addresses associated with the file module or V7000.

    If you want to remove the now unattached network on the command line (instead of editing it), you can use rmnw:

    http://kd52y0g.ibm$ rmnw 172.22.0.0/16
    EFSSG1000I The command completed successfully.

    Hope this helps.
  • el_esceptico
    el_esceptico
    4 Posts

    Re: V7000 Unified

    ‏2012-10-03T17:05:40Z  
    The public network you define should not reuse any addresses assigned to either the file module or V7000 for manangement (cluster or service addresses). Defining them in both will likely cause the loss of access you've seen.

    There are at least two possibilities for why you may have also lost access to the cluster management addresses with the configuration you describe above.
    1) You have, as suggested by Chris, added the network to your 10G interface when the management addresses are bound to the 1G
    2) You have defined a different gateway for the network

    Both of these could lead to bad routing causing loss of access due to the overlap of subnets used by the data and management addresses.

    In either of these cases connecting to the console as you suggest should allow you to remove the network you defined in using the GUI.

    ---

    You can list the currently defined networks using lsnw:

    http://kd52y0g.ibm$ lsnw
    Network VLAN ID Network Groups IP-Addresses Routes
    172.22.0.0/16 DEFAULT 172.22.64.183,172.22.64.184
    EFSSG1000I The command completed successfully.

    In your case these IPs conflict with your file module service IPs

    You can see the actual IP allocations using lsnwinterface

    http://kd52y0g.ibm$ lsnwinterface
    Node Interface MAC Master/Subordinate Bonding mode Transmit hash policy Up/Down Speed IP-Addresses MTU
    mgmt001st001 ethX0 e4:1f:13:d6:06:64 MASTER active-backup (1) UP 1000 172.22.64.184 1500
    mgmt001st001 ethX1 00:00:c9:bb:af:2a MASTER active-backup (1) UP 10000 1500
    mgmt002st001 ethX0 e4:1f:13:d6:05:64 MASTER active-backup (1) UP 1000 172.22.64.183 1500
    mgmt002st001 ethX1 00:00:c9:bb:af:66 MASTER active-backup (1) UP 10000 1500
    EFSSG1000I The command completed successfully.

    In the above example the network has been attached to the 1G interface (ethX0)

    You can detach the IPs using the detachnw command (using the interface found with the lsnwinterface command as above):

    http://kd52y0g.ibm$ detachnw ethX0 172.22.0.0/16
    EFSS1GG0015I Refreshing data.
    EFSSG1000I The command completed successfully.

    Would now give:

    http://kd52y0g.ibm$ lsnwinterface
    Node Interface MAC Master/Subordinate Bonding mode Transmit hash policy Up/Down Speed IP-Addresses MTU
    mgmt001st001 ethX0 e4:1f:13:d6:06:64 MASTER active-backup (1) UP 1000 1500
    mgmt001st001 ethX1 00:00:c9:bb:af:2a MASTER active-backup (1) UP 10000 1500
    mgmt002st001 ethX0 e4:1f:13:d6:05:64 MASTER active-backup (1) UP 1000 1500
    mgmt002st001 ethX1 00:00:c9:bb:af:66 MASTER active-backup (1) UP 10000 1500
    EFSSG1000I The command completed successfully.

    At this point your access to the file module service IPs should be restored, however, if you had a gateway defined on that network the route may have been removed. In this case you may need to reboot the file modules before access is restored.

    If you want to go back to the GUI and edit the configuration, you should now be able to do so. Make sure to change the IP addresses so they do not conflict with any management/service addresses associated with the file module or V7000.

    If you want to remove the now unattached network on the command line (instead of editing it), you can use rmnw:

    http://kd52y0g.ibm$ rmnw 172.22.0.0/16
    EFSSG1000I The command completed successfully.

    Hope this helps.
    Thank you for your help. I resolved the problem with your help. I done a lsnw and I detached both ips, 172.22.64.183 and 172.22.64.184 and in that moment the ping reply.

    But I have another problem. I don't know if I have to open other post or I can use this one.

    I explain the problem and if I have to open other post I will open. My problem is with CIFS. I have added the V7000 Unified to Active Directory. I have created a new file system, in this file system I have created a CIFS share. The settings of this share are:

    -Path: <Name of file system>
    -Name: CIFS
    -Owner: <User of AD>
    -Advanced:
    -User/Group(AD) -- Allow -- Full

    When I access to this share since windows client, I only read and write with the owner of this share, but with the user that I have added in Advanced I can't write in it. It seems that the users that I put in Advanced it doesn't add to this share.

    How can I add users and groups of AD to this CIFS share for read and write?

    Thank you.