ONTAP Discussions

SVM Management LIF

gmilazzoitag
20,364 Views

I was reading with interest the good TR-4182 Ethernet Storage Design Configuration by Mike Worthen. 

I think that there's some contradiction in e0M usage and the concept of SVM Management LIF or, possible, I do not understand 😉

 

At page 5 it states:

 

Beginning with clustered Data ONTAP 8.3 node-mgmt and cluster-mgmt LIFs can no longer be used by an SVM to make connections to outside resources such as AD or DNS.

 

While at page 26, about SVM Management LIF it states:

 

Beginning with clustered Data ONTAP 8.3 node management LIFs can no longer be used. Thus it will be typical in an 8.3 deployment to configure quite a few of these SVM
management LIFs - one per data SVM - on the e0M management port, for example, so that data SVM’s can access DNS and other services.

 

These concepts do not match one to the other. How is possible to depute the e0M as SVM Management LIF? e0M interface is the preferred node management interface and it belong to a default failover policy "local only", it does not migrate. How can be possible to use it as SVM management LIF to access to external common services such as AD, DNS, NTP and so on?

 

Regards

 

 

 

 

1 ACCEPTED SOLUTION

aborzenkov
20,189 Views
First, e0M does not support VLAN 🙂

But you again confuse port and LIF. VLAN cannot be *on* LIF. LIF is associated with failover group which containes ports; these ports can of course be VLANs, but LIF does not know or care.

View solution in original post

6 REPLIES 6

aborzenkov
20,218 Views

You confuse port and LIF. Nothing prevents having two LIFs on the same e0M port where one LIF is restricted to local node and another LIF can failover to another node. What TR tries to say, that if in the past physical node connectivity to management network was enough, now you may need to explicitly configure LIFs in this management network for each SVM.

gmilazzoitag
20,207 Views

Yes. Good point. Ten yrs of 7Mode caused the continous confusion 😉 between ports (physical and logical too such as VLAN and ifgrp!) and LIF.

So If I get you well I could create on port e0M the default node-mngmt LIF and at the same time another LIF for SVM management: this two LIF will belong to different failover group with the second one that could fail, if needed, from a node to another (SVM spread on more than one node).

 

What's about different VLAN on these two different LIFs? This will cause some issue to design and understand ip spaces and  broadcast domains, is it?

 

Regards,

bobshouseofcards
20,211 Views

Ironically, the same Technical Report also states on page 37 :

 

Do not use interface e0M (or any other port designated for node management) for any type of

protocol traffic other than node management. This interface should be exclusively for node

management and administrative access.

 

which would "seem" to negate mapping any general SVM LIFs onto any node's port e0M to access DNS and other services as described on page 26.

aborzenkov
20,190 Views
First, e0M does not support VLAN 🙂

But you again confuse port and LIF. VLAN cannot be *on* LIF. LIF is associated with failover group which containes ports; these ports can of course be VLANs, but LIF does not know or care.

gmilazzoitag
20,184 Views

And your last post cut any other consideration Smiley Happy

I think that author of that TR should correct this phrase:

 

Thus it will be typical in an 8.3 deployment to configure quite a few of these SVM management LIFs - one per data SVM - on the e0M management port

 

Regards,

d3n1s
8,198 Views

It's possible to use port e0M to host management lif of a SVM.

 

cluster::> network interface create -vserver SVM_name_nere -lif SVM_mgmt_LIF_name -role data  -data-protocol none -address x.x.x.x -netmask x.x.x.x -home-node node_a_or_b -home-port e0M  -status-admin up -failover-policy system-defined -firewall-policy mgmt -auto-revert false -failover-group Default      (-force-subnet-association true if you have defined a subnet with a IP rangas for management)

 

Regards.

Denis R.

 

 

Public