Network and Storage Protocols

NetApp-Controller-SR2 Unable to Access 10.20.4.12

CSTOCKDA
901 Views

Hello,

 

We have a system that has to be in takeover as users cannot access 10.20.4.12 on NetApp-Controller-SR2. The system needs to always be in takeover or access to this share does not work. I am looking at the ifconfig -a for each node but I cannot see anything:

 

NetApp-Controller-SR2

 

e0a: flags=0x2f0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:a4:92 (auto-1000t-fd-up) flowcontrol full
e0b: flags=0x2f0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:a4:93 (auto-1000t-fd-up) flowcontrol full
e2a: flags=0x89f0e867<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:a4:92 (auto-10g_sr-fd-up) flowcontrol full
trunked VIF1
e2b: flags=0x8970e867<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:a4:92 (auto-unknown-down) flowcontrol full
trunked VIF1
c0a: flags=0x170e866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:a4:94 (auto-unknown-enabling) flowcontrol full
c0b: flags=0x170e866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:a4:95 (auto-unknown-enabling) flowcontrol full
e0M: flags=0x2b0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,MGMT_PORT> mtu 1500
ether 00:a0:98:14:a4:96 (auto-100tx-fd-up) flowcontrol full
e0P: flags=0x2b4c867<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM,ACP_PORT> mtu 1500 PRIVATE
inet 192.168.0.117 netmask 0xfffffc00 broadcast 192.168.3.255 noddns vFiler ID: 0
ether 00:a0:98:14:a4:97 (auto-100tx-fd-up) flowcontrol full
lo: flags=0x1b48049<UP,LOOPBACK,RUNNING,MULTICAST,TCPCKSUM> mtu 9188
inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1 vFiler ID: 0
losk: flags=0x40a400c9<UP,LOOPBACK,RUNNING> mtu 9188
inet 127.0.20.1 netmask 0xff000000 broadcast 127.0.20.1 vFiler ID: 0
VIF1: flags=0xa2f0e862<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:a4:92 (Enabled interface groups)
VIF1-6: flags=0x2b4e863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 9000
inet 10.20.16.81 netmask 0xffffff00 broadcast 10.20.16.255 vFiler ID: 0
partner VIF1-6 (not in use)
ether 02:a0:98:14:a4:92 (vlan-on-ifgrp-up)
VIF1-1: flags=0x2b4e863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
inet 10.20.4.12 netmask 0xfffff000 broadcast 10.20.15.255 vFiler ID: 0
partner VIF1-1 (not in use)
ether 02:a0:98:14:a4:92 (vlan-on-ifgrp-up)

 

NetApp-Controller-SR1

 

e0a: flags=0x2f0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:9d:02 (auto-1000t-fd-up) flowcontrol full
e0b: flags=0x2f0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:9d:03 (auto-1000t-fd-up) flowcontrol full
e2a: flags=0x89f0e867<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:9d:02 (auto-10g_sr-fd-up) flowcontrol full
trunked VIF1
e2b: flags=0x8970e867<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:9d:02 (auto-unknown-down) flowcontrol full
trunked VIF1
c0a: flags=0x170e866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:9d:04 (auto-unknown-enabling) flowcontrol full
c0b: flags=0x170e866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
ether 00:a0:98:14:9d:05 (auto-unknown-enabling) flowcontrol full
e0M: flags=0x2b0c866<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,MGMT_PORT> mtu 1500
ether 00:a0:98:14:9d:06 (auto-100tx-fd-up) flowcontrol full
e0P: flags=0x2b4c867<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM,ACP_PORT> mtu 1500 PRIVATE
inet 192.168.2.158 netmask 0xfffffc00 broadcast 192.168.3.255 noddns vFiler ID: 0
ether 00:a0:98:14:9d:07 (auto-100tx-fd-up) flowcontrol full
lo: flags=0x1b48049<UP,LOOPBACK,RUNNING,MULTICAST,TCPCKSUM> mtu 9188
inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1 vFiler ID: 0
losk: flags=0x40a400c9<UP,LOOPBACK,RUNNING> mtu 9188
inet 127.0.20.1 netmask 0xff000000 broadcast 127.0.20.1 vFiler ID: 0
VIF1: flags=0xa2f0e862<BROADCAST,RUNNING,MULTICAST,TCPCKSUM,VLAN> mtu 9000
ether 02:a0:98:14:9d:02 (Enabled interface groups)
VIF1-6: flags=0x2b4e863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 9000
inet 10.20.16.80 netmask 0xffffff00 broadcast 10.20.16.255 vFiler ID: 0
partner VIF1-6 (not in use)
ether 02:a0:98:14:9d:02 (vlan-on-ifgrp-up)
VIF1-1: flags=0x2b4e863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
inet 10.20.4.11 netmask 0xfffff000 broadcast 10.20.15.255 vFiler ID: 0
partner VIF1-1 (not in use)
ether 02:a0:98:14:9d:02 (vlan-on-ifgrp-up)

 

I see that this is part of Vif1 on controller 2 with a VLAN tag of 1

 

VIF1-1: flags=0x2b4e863<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM> mtu 1500
inet 10.20.4.12 netmask 0xfffff000 broadcast 10.20.15.255 vFiler ID: 0
partner VIF1-1 (not in use)
ether 02:a0:98:14:a4:92 (vlan-on-ifgrp-up)

 

===Vif details ====

 

default: transmit 'IP Load balancing', Ifgrp Type 'multi_mode', fail 'log'
VIF1: 1 link, transmit 'none', Ifgrp Type 'single_mode' fail 'default'
Ifgrp Status Up Addr_set
up:
e2a: state up, since 30Dec2022 09:22:56 (00:11:22)
mediatype: auto-10g_sr-fd-up
flags: enabled
input packets 34576, input bytes 2305844
output packets 496, output bytes 64549
output probe packets 0, input probe packets 0
strike count: 0 of 10
up indications 2, broken indications 1
drops (if) 0, drops (link) 0, drops (no active link) 0
indication: up at 30Dec2022 09:22:56
consecutive 682, transitions 3
broken:
e2b: state broken, since 30Dec2022 09:23:06 (00:11:12)
mediatype: auto-unknown-down
flags:
input packets 0, input bytes 0
output packets 0, output bytes 0
output probe packets 0, input probe packets 0
strike count: 0 of 10
up indications 0, broken indications 0
drops (if) 0, drops (link) 0, drops (no active link) 0
indication: broken at 30Dec2022 09:23:06
consecutive 0, transitions 1

 

======

 

Am I correct in thinking it is single mode so only 1 link can be active ?

I am sure it is config but i find it strange it works in takeover but not on its own.

 

Any advise would be appreciated

1 ACCEPTED SOLUTION

Ontapforrum
884 Views

I think wording of your question is bit confusing but hopefully we can sort that out.

 

You mentioned - "We have a system that has to be in takeover" ? By system I would take that as a 'Filer', if so then - Why is the Controller on take-over mode ? (Is their Hardware issue and is it out of support for Hardware/Software)

 

But after reading the full question, It appears that you are talking about 'ifgrp' single-mode, which means one of the interface of the ifgrp will be on a standby and ready to take over if the 'active interface fails'. So, there is no application of "controller take-over" here, here take-over simply means taking over the interface within the ifgrp(VIF1) on the given Node (NetApp-Controller-SR2).

 

You have created a single-mode ifgrp:
VIF1 [e2a & e2b]
e2a: auto-10g_sr-fd-up
e2b: Broken/auto-unknown-down <---Why is this down, is it known or needs troubleshooting ?

 

VLAN-ID:
VIF1-1 [10.20.4.12]

 

Is your question : Why is 10.20.4.12 only accessible from e2a ? (As the partner interface e2b is down)

 

Am I correct in thinking it is single mode so only 1 link can be active ?

Yes, in single-mode ifgrp "only one" interface is active at a time and the others are ready to take over if the active interface fails.


Designating a nonfavored interface in a single-mode interface group:
When you create a single-mode interface group, an interface is randomly selected to be the active interface. You can designate an interface as nonfavored so that it is not considered during the random selection of an active interface in a single-mode interface group

 

More on nonfavored interface here:
https://www.ibm.com/docs/en/nseriessoftware/com.ibm.nseries.software.doc/ga32104202.pdf

 

View solution in original post

1 REPLY 1

Ontapforrum
885 Views

I think wording of your question is bit confusing but hopefully we can sort that out.

 

You mentioned - "We have a system that has to be in takeover" ? By system I would take that as a 'Filer', if so then - Why is the Controller on take-over mode ? (Is their Hardware issue and is it out of support for Hardware/Software)

 

But after reading the full question, It appears that you are talking about 'ifgrp' single-mode, which means one of the interface of the ifgrp will be on a standby and ready to take over if the 'active interface fails'. So, there is no application of "controller take-over" here, here take-over simply means taking over the interface within the ifgrp(VIF1) on the given Node (NetApp-Controller-SR2).

 

You have created a single-mode ifgrp:
VIF1 [e2a & e2b]
e2a: auto-10g_sr-fd-up
e2b: Broken/auto-unknown-down <---Why is this down, is it known or needs troubleshooting ?

 

VLAN-ID:
VIF1-1 [10.20.4.12]

 

Is your question : Why is 10.20.4.12 only accessible from e2a ? (As the partner interface e2b is down)

 

Am I correct in thinking it is single mode so only 1 link can be active ?

Yes, in single-mode ifgrp "only one" interface is active at a time and the others are ready to take over if the active interface fails.


Designating a nonfavored interface in a single-mode interface group:
When you create a single-mode interface group, an interface is randomly selected to be the active interface. You can designate an interface as nonfavored so that it is not considered during the random selection of an active interface in a single-mode interface group

 

More on nonfavored interface here:
https://www.ibm.com/docs/en/nseriessoftware/com.ibm.nseries.software.doc/ga32104202.pdf

 

Public