<?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 Onbarding X435-8P via multiple VLANs/Subnets fails in ExtremeCloud IQ- Site Engine Management Center</title>
    <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/onbarding-x435-8p-via-multiple-vlans-subnets-fails/m-p/95555#M9826</link>
    <description>&lt;P&gt;We have multiple sites where site connectivity is provided over third party managed infrastructure providing multiple VRFs/VLANs and subnets over a single uplink.&lt;/P&gt;&lt;P&gt;Typically there is an internally facing VLAN and Subnet with access to internal DNS, DHCP and hence XIQ-SE plus an externally facing VLAN and subnet for public use with no access to internal DNS and no access to XIQ-SE. This has access to externally hosted DHCP and public DNS.&lt;/P&gt;&lt;P&gt;When onboarding X435-8P switches 'out of the box' they pick up addresses on both VLANs. We were under the impression that the switch should try each until a connection to XIQ-SE is established. However, traceroute from the switch shows that this is being restricted to just the public interface - hence not only can the address of our XIQ-SE server not be determined as there is no access to internal DNS but also the server itself is inaccessible anyway.&lt;BR /&gt;&lt;BR /&gt;Connecting to an intermediate device to filter out Public access gives us a workaround - but won't always be possible. Nor will disabling the Public DHCP be an option as that would interrupt access to vital public services.&lt;BR /&gt;&lt;BR /&gt;Switches come 'out of the box' with OS&amp;nbsp;31.7.1.4 patch1-77&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 19 Apr 2023 15:46:59 GMT</pubDate>
    <dc:creator>NCC</dc:creator>
    <dc:date>2023-04-19T15:46:59Z</dc:date>
    <item>
      <title>Onbarding X435-8P via multiple VLANs/Subnets fails</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/onbarding-x435-8p-via-multiple-vlans-subnets-fails/m-p/95555#M9826</link>
      <description>&lt;P&gt;We have multiple sites where site connectivity is provided over third party managed infrastructure providing multiple VRFs/VLANs and subnets over a single uplink.&lt;/P&gt;&lt;P&gt;Typically there is an internally facing VLAN and Subnet with access to internal DNS, DHCP and hence XIQ-SE plus an externally facing VLAN and subnet for public use with no access to internal DNS and no access to XIQ-SE. This has access to externally hosted DHCP and public DNS.&lt;/P&gt;&lt;P&gt;When onboarding X435-8P switches 'out of the box' they pick up addresses on both VLANs. We were under the impression that the switch should try each until a connection to XIQ-SE is established. However, traceroute from the switch shows that this is being restricted to just the public interface - hence not only can the address of our XIQ-SE server not be determined as there is no access to internal DNS but also the server itself is inaccessible anyway.&lt;BR /&gt;&lt;BR /&gt;Connecting to an intermediate device to filter out Public access gives us a workaround - but won't always be possible. Nor will disabling the Public DHCP be an option as that would interrupt access to vital public services.&lt;BR /&gt;&lt;BR /&gt;Switches come 'out of the box' with OS&amp;nbsp;31.7.1.4 patch1-77&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 19 Apr 2023 15:46:59 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/onbarding-x435-8p-via-multiple-vlans-subnets-fails/m-p/95555#M9826</guid>
      <dc:creator>NCC</dc:creator>
      <dc:date>2023-04-19T15:46:59Z</dc:date>
    </item>
  </channel>
</rss>

