mvif switch to other mvif unexpectedly

[tatlee]

Hi,

IHAC setting up a second level VIF. One svif has 2 mvifs, each mvif has 3 physical interfaces. config as below: 

vif create lacp mvif0 -b ip e0a e0b e4d

vif create lacp mvif1 -b ip e4a e4b e4c

vif create single svif0 mvif0 mvif1 

When we physically disconnect one interface from the active mvif, it switched to other mvif unexpectedly. e.g when e0a was disconnected, mvif0 switched to mvif1; when e4a was disconnected, mvif1 switched to mvif0. This should not be the case as this is mvif, it should only switch to other mvif when all the physical interfaces are dead or physically disconnected. The console message as beow:

Sat Nov 13 10:44:12 HKT [FASHK02A: netif.linkDown:info]: Ethernet e4a: Link down, check cable.

Sat Nov 13 10:44:13 HKT [FASHK02A: pvif.switchLink:warning]: svif0: switching to mvif0

Sat Nov 13 10:44:34 HKT [FASHK02A: netif.linkUp:info]: Ethernet e4a: Link up.

Sat Nov 13 10:45:16 HKT [FASHK02A: netif.linkDown:info]: Ethernet e0a: Link down, check cable.

Sat Nov 13 10:45:17 HKT [FASHK02A: pvif.switchLink:warning]: svif0: switching to mvif1

Sat Nov 13 10:45:33 HKT [FASHK02A: netif.linkUp:info]: Ethernet e0a: Link up.

Any idea?

The network switch side setting :

interface port-channel20
  description Etherchannel to fashk02a
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on

interface port-channel21
  description Etherchannel to fashk02b
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on

interface Ethernet150/1/11
  description fashk02a-e0a
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 20 mode active

interface Ethernet150/1/12
  description fashk02a-e0b
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 20 mode active

interface Ethernet150/1/13
  description fashk02a-e4d
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 20 mode active

interface Ethernet150/1/14
  description fashk02b-e0a
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 21 mode active

interface Ethernet150/1/15
  description fashk02b-e0b
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 21 mode active

interface Ethernet150/1/16
  description fashk02b-e4d
  no cdp enable
  switchport access vlan 610
  spanning-tree guard root
  flowcontrol receive on
  no snmp trap link-status
  channel-group 21 mode active

Regards,

Terrence

[thomas_glodde]

Hi Terrence,

you could give the "vif favor" command a try:

vif create lacp mvif0 -b ip e0a e0b e4d

vif create lacp mvif1 -b ip e4a e4b e4c

vif create single svif0 mvif0 mvif1

vif favor mvif0

So the single vif favors the mvif0.

If this wont help, my guess would be sort of hidden option, how is this option set on your filer?

filer> priv set diag

filer*> registry walk options.vif
options.vif.failover.link_degraded=off

filer*> priv set

Regards

Thomas

[tatlee]

Hi Thomas,

Thanks for your advise. However, the customer is not requiring a vif favor. So, I don't think this is an option. Also, this isn't solve the problem.

The "options.vif.failover.link_degraded' is set to off, so it should not failover to the higher bandwidth mvif.

Regards,

Terrence

[thomas_glodde]

Hi,

you should get in contact with NGS then and have the pros check that matter out.

Kind regards

Thomas

[alexander_duske]

today i realized that i have the same problem.

has there been a resolution to this issue?

i would be highly interested!

Thanks in advance!

Edit: found this in the Network Administration Guide, maybe it applied to your environment:

"If you create a second-level vif over two

multimode vifs that are connected to two different switches, you should connect the two switches

with an inter-switch link (ISL)."

So i guess we cant go without an ISL. 😞

[alexander_duske]

we have now implemented an ISL between the two switches and everything works fine.

in question is the exact sense of having a redundant link, that switches when only one  link is down.

maybe this is just for load-balancing purposes??