<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Patching new trunk LAG in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161598#M36913</link>
    <description>&lt;P&gt;Hi Folks,&lt;/P&gt;&lt;P&gt;We have a FAS 8200 cluster (9.5P9) that is currently using a single 2 port data interface group&amp;nbsp; (per node) on an isolated switch dedicated to VMware storage.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Our goal is to add another 2 port data interface group that is for general purpose data SVMs (NFS and CIFS) which may be on any of a number of VLANs.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;As such we need to physically patch 4 new 10Gbe connections to the FAS, 2 for each node, which will all become members of an interface group (or do we create 2 interface groups, one per node?), which will be part of a switch LACP LAG configured as trunk ports.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We'll then extend a number of vlan tags onto those 4 ports from the switch and create those vlans on the interface group.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Then we can move on to creation of SVMs.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Did I miss anything in the above steps?&amp;nbsp; This all seems like it'll be perfectly non-disruptive to our existing VMWare isolated storage network interface groups, right?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I did create a mock recipe for this if it helps explain what I'm attempting:&lt;/P&gt;&lt;P&gt;&lt;A href="https://gist.github.com/kfiresmith/79244a1c0254a471cabcfd5214846a67" target="_blank"&gt;https://gist.github.com/kfiresmith/79244a1c0254a471cabcfd5214846a67&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 04 Jun 2025 10:43:27 GMT</pubDate>
    <dc:creator>kodiak_f</dc:creator>
    <dc:date>2025-06-04T10:43:27Z</dc:date>
    <item>
      <title>Patching new trunk LAG</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161598#M36913</link>
      <description>&lt;P&gt;Hi Folks,&lt;/P&gt;&lt;P&gt;We have a FAS 8200 cluster (9.5P9) that is currently using a single 2 port data interface group&amp;nbsp; (per node) on an isolated switch dedicated to VMware storage.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Our goal is to add another 2 port data interface group that is for general purpose data SVMs (NFS and CIFS) which may be on any of a number of VLANs.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;As such we need to physically patch 4 new 10Gbe connections to the FAS, 2 for each node, which will all become members of an interface group (or do we create 2 interface groups, one per node?), which will be part of a switch LACP LAG configured as trunk ports.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We'll then extend a number of vlan tags onto those 4 ports from the switch and create those vlans on the interface group.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Then we can move on to creation of SVMs.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Did I miss anything in the above steps?&amp;nbsp; This all seems like it'll be perfectly non-disruptive to our existing VMWare isolated storage network interface groups, right?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I did create a mock recipe for this if it helps explain what I'm attempting:&lt;/P&gt;&lt;P&gt;&lt;A href="https://gist.github.com/kfiresmith/79244a1c0254a471cabcfd5214846a67" target="_blank"&gt;https://gist.github.com/kfiresmith/79244a1c0254a471cabcfd5214846a67&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 04 Jun 2025 10:43:27 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161598#M36913</guid>
      <dc:creator>kodiak_f</dc:creator>
      <dc:date>2025-06-04T10:43:27Z</dc:date>
    </item>
    <item>
      <title>Re: Patching new trunk LAG</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161601#M36914</link>
      <description>&lt;P&gt;Hi there!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Yes - it will be non-disruptive - assuming you're using different VLAN tags etc on each set of links.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;To answer your question - you create one ifgrp per controller, and likewise on the switch side, you create a channel group per controller for this new ifgrp.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Your github document is a good start - you probably already have an a0a on each node for the existing ifgrp - so you may use a0b for a new one. Personally I used to call node 1's ifgrps a1a, a1b, a1c etc, then node 2 would be a2a, a2b etc - but that's up to each admin. Once the ifgrp is created, and ports added to it, you then create broadcast domains, as per&amp;nbsp;&lt;A href="https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-nmg%2FGUID-92011B2B-B3EE-4860-B9B0-1868D2966A7F.html" target="_blank"&gt;https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-nmg%2FGUID-92011B2B-B3EE-4860-B9B0-1868D2966A7F.html&lt;/A&gt;&amp;nbsp;and then create LIFs for SVMs inside those broadcast domains.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope this helps!&lt;/P&gt;</description>
      <pubDate>Mon, 30 Nov 2020 06:10:37 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161601#M36914</guid>
      <dc:creator>AlexDawson</dc:creator>
      <dc:date>2020-11-30T06:10:37Z</dc:date>
    </item>
    <item>
      <title>Re: Patching new trunk LAG</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161605#M36917</link>
      <description>&lt;P&gt;Thanks AlexDawson,&lt;/P&gt;&lt;P&gt;I'll continue to work on my runbook for this task - will be taking it on tomorrow evening hopefully.&amp;nbsp; Appreciate it!&lt;/P&gt;</description>
      <pubDate>Mon, 30 Nov 2020 12:27:55 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Patching-new-trunk-LAG/m-p/161605#M36917</guid>
      <dc:creator>kodiak_f</dc:creator>
      <dc:date>2020-11-30T12:27:55Z</dc:date>
    </item>
  </channel>
</rss>

