<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: The vSwitch &#8220;Notify Switches&#8221; setting	</title>
	<atom:link href="https://rickardnobel.se/vswitch-notify-switches-setting/feed/" rel="self" type="application/rss+xml" />
	<link>https://rickardnobel.se/vswitch-notify-switches-setting/</link>
	<description>Specialists in IT infrastructure services</description>
	<lastBuildDate>Fri, 19 Dec 2025 09:27:01 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.8.6</generator>
	<item>
		<title>
		By: MarcL		</title>
		<link>https://rickardnobel.se/vswitch-notify-switches-setting/#comment-483342</link>

		<dc:creator><![CDATA[MarcL]]></dc:creator>
		<pubDate>Fri, 19 Dec 2025 09:27:01 +0000</pubDate>
		<guid isPermaLink="false">https://rickardnobel.se/?p=1358#comment-483342</guid>

					<description><![CDATA[Nice, I knew about &quot;Notify Switches&quot; for a long time, but never got around to see a packet dissection of the RARPs the ESX are sending. 

QUESTION:
Do you know if the vSwitch/dvSwitches on other ESXi hosts forward the RARPs to the VMs connected to the given port group? The RARPs sent from one ESXi host because a VM just moved in, are they ... 
a) on other ESX hosts, are they seen by the VMs in the same VLAN/Port Group? (in extenso: dvSwitch fwds them to the locally connected VMs, while also updating its own MAC address table)
b) ingested/discarded by the dvSwitch, only updating its own MAC address tables? 


INFO: 
To other commenters, about notifiy switches not (always) working.

This is just for the case where Notify Switches is expected to help when an ESX&#039;s uplink port is going down or especially when coming back up:  

Immediately when the ESX sees &quot;line protocol up&quot; on the given uplink interface, it will start sending out RARP bursts through that freshly-up uplink (pun intended!). 

The given switchport must go into fwd&#039;ing state just as quickly, so be sure to turn off (in Cisco speak): Dynamic Trunking Protocol (&quot;switchport nonegotiate&quot;) and Spanning-Tree (&quot;spanning-tree portfast [trunk]&quot; &#124; spanning-tree port type edge [trunk]&quot; --- pick the one that suits your switch hardware platform).   If these are missing, or equivalents thereof, a freshly-upped switchport remains a black hole for the RARPs until it eventually goes into fwd&#039;ing state, and that of course kills Notify Switches&#039;s attempts  to - well - notify the switches.]]></description>
			<content:encoded><![CDATA[<p>Nice, I knew about &#8220;Notify Switches&#8221; for a long time, but never got around to see a packet dissection of the RARPs the ESX are sending. </p>
<p>QUESTION:<br />
Do you know if the vSwitch/dvSwitches on other ESXi hosts forward the RARPs to the VMs connected to the given port group? The RARPs sent from one ESXi host because a VM just moved in, are they &#8230;<br />
a) on other ESX hosts, are they seen by the VMs in the same VLAN/Port Group? (in extenso: dvSwitch fwds them to the locally connected VMs, while also updating its own MAC address table)<br />
b) ingested/discarded by the dvSwitch, only updating its own MAC address tables? </p>
<p>INFO:<br />
To other commenters, about notifiy switches not (always) working.</p>
<p>This is just for the case where Notify Switches is expected to help when an ESX&#8217;s uplink port is going down or especially when coming back up:  </p>
<p>Immediately when the ESX sees &#8220;line protocol up&#8221; on the given uplink interface, it will start sending out RARP bursts through that freshly-up uplink (pun intended!). </p>
<p>The given switchport must go into fwd&#8217;ing state just as quickly, so be sure to turn off (in Cisco speak): Dynamic Trunking Protocol (&#8220;switchport nonegotiate&#8221;) and Spanning-Tree (&#8220;spanning-tree portfast [trunk]&#8221; | spanning-tree port type edge [trunk]&#8221; &#8212; pick the one that suits your switch hardware platform).   If these are missing, or equivalents thereof, a freshly-upped switchport remains a black hole for the RARPs until it eventually goes into fwd&#8217;ing state, and that of course kills Notify Switches&#8217;s attempts  to &#8211; well &#8211; notify the switches.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>

<!--
Page Caching using Disk: Enhanced 

Served from: rickardnobel.se @ 2026-07-21 04:31:22 by W3 Total Cache
-->