<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
I may look at post-sales deployments a little differently than some...
<div><br>
</div>
<div>I figure, if you’re coming to me to install, upgrade and/or repair or adjust this UC solution for you, it’s more than likely because you don’t have the capacity or depth to do it for yourself, or with your internal team.</div>
<div><br>
</div>
<div>To that end, I approach the deployment as if I’m likely to be the last person to touch the deployment, with specific depth-of-knowledge. So I want to leave the deployment as resilient and fault tolerant (to organic failure as well as human failure) as
possible in every way possible.</div>
<div><br>
</div>
<div>I assume that once I have the UC system up and running to agreed-upon specifications that no one else is really going to touch the solution outside of administrative MACD. At which point, I become less worried about the resilience of the solution itself
(I have that covered all day long) and more worried about the other actors in the environment who can impact the solution with their actions.</div>
<div><br>
</div>
<div>Now, if it’s a managed services scenario, that can be a horse of a different color because I can expect to be responsible for the entire solution’s operation on a day-to-day basis. I may recommend NIC teaming in that case, because I know I (or my team)
are likely to be the only ones in the environment making those sorts of network changes that would be impactful to load balancing mechanisms on VMware hypervisors.</div>
<div><br>
</div>
<div>It all comes down to risk and understanding, which I gauge through customer interaction. If the customer understands the caveats to teaming and accepts that, great. If they are more of the “it guy that just wants the phones to ring”, perhaps not.</div>
<div><br>
</div>
<div>-Ryan<br>
<div dir="ltr"><br>
<blockquote type="cite">On Nov 28, 2019, at 14:49, Ryan Huff <ryanhuff@outlook.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"> The issues I’ve experienced with it, admittedly, have nothing to do (generally) with VMware or Cisco UC specifically.
<div><br>
</div>
<div>The issues I’ve had to deal with (not many mind you) over the years have either been from an over enthusiastic network engineer who just wanted to standardize all LAG groups in the enterprise to LACP (and not do their due diligence beforehand) or a network
engineer who thought they should move a channel group member to another switch for physical redundancy and not respect LAG rule #1 (all bundled ports in one switch or switch stack, but not multiple switches trunked together).</div>
<div><br>
</div>
<div>So my preference in this regard, is really just a hedge against someone else doing something stupid rather than just because I think it works better one way over the other. Like driving a car, sometimes a good offense is a good defense ;).</div>
<div><br>
</div>
<div>I simply do it as a matter of making my deployment more tolerant to changes within the network, unless the customer or business goal has a requirement for nic teaming, then of course, by all means.</div>
<div><br>
<div dir="ltr">- Ryan</div>
<div dir="ltr"><br>
<blockquote type="cite">On Nov 28, 2019, at 14:17, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Interesting comment/experience. I have not had any issues attributed to loading balancing based on IP hash, and have been doing that on about 4-5 installs a year for the last 6 years. Not too mention the environments I'm in, where I was not
the deployment Engineer, but support the environment nonetheless. Either I'm just not seeing the issues with it, or the issues are not directly related to the setting.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2019 at 1:02 PM Jonathan Charles <<a href="mailto:jonvoip@gmail.com">jonvoip@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I have experienced unpleasantness in the past with IP Hash... it is not enough traffic to justify active/active on the trunks to risk the load balancing oddities that occur on the vSphere standard switch...
<div><br>
</div>
<div>I am going to suggest they change it back to originating port ID and break the channel group.</div>
<div><br>
</div>
<div><br>
</div>
<div>Jonathan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Nov 27, 2019 at 7:37 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Honestly, and this is just my preference based on my years of experience in post-sales engineering and my desire to not be on support calls at stupid-thirty AM...</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
For a typical Cisco UC on UCS "business edition" hypervisor setup, I would change the hypervisor's vSwitch load balancing mechanism to "Route based on originating port ID" and put the vNIC failover to active/standby (assuming just the two typical vmnic0/1),
then on the switch, unbundle the ports from the channel group and make the ports individual trunk / access ports (would depend on how you are handling 802.1Q tags).
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Active/Standby is usually a sufficient NIC failover strategy for most customers, in most scenarios. Unless teamed NICs on the chassis are a material requirement in your scenario for some reason, I'd consider un-teaming the NICs and just let them be active/standby.
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I've not experienced where the convergence time for failover between the NICs is so significant that it disrupts UC communications in a meaningful way, that can't also be tolerated and assessed to a brief "blip". Could it cause "in progress" calls to fail?
Probably. Could it cause calls terminated on CUCM (MTP) to fail? Possibly. Could it cause disruptions to Finesse agents (if UCCX is in play)? Possibly. However, the convergence is very quick and is usually tolerated in the same way that a "brief moment of
packet loss" is tolerated. <br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Again, evaluate whether nic teaming is a material requirement in your environment, but if it is not, I'd consider un-teaming and just going to active/standby.</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Thanks,</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Ryan<br>
</div>
<div id="gmail-m_2293898896802765719gmail-m_5723868957567015973Signature">
<div>
<div id="gmail-m_2293898896802765719gmail-m_5723868957567015973appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_2293898896802765719gmail-m_5723868957567015973divRplyFwdMsg" dir="ltr">
<font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Jonathan Charles <<a href="mailto:jonvoip@gmail.com" target="_blank">jonvoip@gmail.com</a>><br>
<b>Sent:</b> Wednesday, November 27, 2019 7:48 PM<br>
<b>To:</b> Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>><br>
<b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a> <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>><br>
<b>Subject:</b> Re: [cisco-voip] Preservation Mode, long time for call setups...</font>
<div> </div>
</div>
<div>
<div dir="ltr">Would you recommend changing it to Originating Port ID?
<div><br>
</div>
<div><br>
</div>
<div>Jonathan</div>
</div>
<br>
<div>
<div dir="ltr">On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">I would expect the same behavior from PAgP with ESXi.<br>
<br>
<div dir="ltr">-Ryan</div>
<div dir="ltr"><br>
<blockquote type="cite">On Nov 27, 2019, at 19:19, Jonathan Charles <<a href="mailto:jonvoip@gmail.com" target="_blank">jonvoip@gmail.com</a>> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">They are channel group ON... (so, no LACP) on the switch...
<div><br>
</div>
<div><br>
</div>
<div>Jonathan</div>
</div>
<br>
<div>
<div dir="ltr">On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">AFAIK, VMware has always required a distributed vSwitch for LACP, but the earliest reference I can find tonight is 5.1, though I believe it’s referenced the same way in the documentation of every version since then.
<div><br>
</div>
<div><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkb.vmware.com%2Fs%2Farticle%2F2034277&data=02%7C01%7C%7C003802b3ac5f46128ddf08d7743c02cf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637105673397641917&sdata=jsLjLUFJ%2BBT904TH5F6X%2F2MvXxG9P%2F5lHkNy3mmvZC0%3D&reserved=0" originalsrc="https://kb.vmware.com/s/article/2034277" shash="JakvBQH/NdkKL9wq2KpOGh4cqRzP6IoYBPd+54jmk8FQFMJJEUxW+kacThpTxfLMj1CB4OobxadjAMSG8Puu8N4QMYYFbRQGe61/GvhTxkmULxyN+2hJWVnQMS+Ye3yWs6577HoidasJF3F2Ae2KRXb6g4NYyPmKgiiKN5aZQQc=" target="_blank">https://kb.vmware.com/s/article/2034277</a><br>
<br>
<div dir="ltr">Sent from my iPhone</div>
<div dir="ltr"><br>
<blockquote type="cite">On Nov 27, 2019, at 19:11, Ryan Huff <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"><span>Route based on IP hash should be fine for 802.3ad, but technically, VMWare only supports it with a distributed vSwitch (would need an EA or Enterprise license for the hypervisor, not the “free” license) and not a standard vSwitch.</span><br>
<span>I’ve seen it work with a standard vSwitch, for long periods of time even, and then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), then all hell breaks loose and you can’t get teaming to work again.</span><br>
<span></span><br>
<span>If those c220s are business editions and/or have the “free” license (non enterprise), then that’s likely a problem. You’d likely see evidence of this in the switch syslog (Mac flaps, possibly err-disable... etc).</span><br>
<span></span><br>
<span>What is the reason for suspecting you need to change the NIC teaming to active/passive?</span><br>
<span></span><br>
<span>Phones going into SRST mode (may be displayed as preservation mode on phones) is an indication the phone’s IP lost network connectivity to all the call control servers listed in the phone’s configuration (xml) file.</span><br>
<span></span><br>
<span>The delayed call setup could be due to the call traversing an unexpected/unoptimized network path, due to disruption in it’s connection to its preferred call control server.</span><br>
<span></span><br>
<span>Thanks,</span><br>
<span></span><br>
<span>Ryan</span><br>
<span></span><br>
<blockquote type="cite"><span>On Nov 27, 2019, at 18:17, Jonathan Charles <<a href="mailto:jonvoip@gmail.com" target="_blank">jonvoip@gmail.com</a>> wrote:</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected to the same 4-stack 3850 (port channel, mode on)</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Customer is reporting Preservation Mode kicking in on the LAN and some calls taking a long time to setup.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Currently, VMware is set to Route based on IP Hash with PAgP channel groups.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>I think we need to change it to Route Based on Originating Virtual Port instead, but I cannot prove it before hand...</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>What could be causing the Preservation Mode on the LAN?</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Jonathan</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>_______________________________________________</span><br>
</blockquote>
<blockquote type="cite"><span>cisco-voip mailing list</span><br>
</blockquote>
<blockquote type="cite"><span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
</blockquote>
<blockquote type="cite"><span><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C003802b3ac5f46128ddf08d7743c02cf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637105673397641917&sdata=mXf%2F3PaD7l0g007j9XbIb1iJApHIz34HUCRE0Kh0JuE%3D&reserved=0" originalsrc="https://puck.nether.net/mailman/listinfo/cisco-voip" shash="aeDDKBC33D7qLLZaviAVXMT/jWSbKXBnIV6S5nPmQDXhtjBl+fa0sbNQohAABO8RIZt/YBZ1omJVL4Bg8Wnc0tfQGUeuG1xczR+wK1DrFippaCfoEymSQaA7tY5HVTcXarNQOsNnGpOA9Duxt+aThdUkQersuO8kEYIGhyHdIfw=" target="_blank">https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0</a></span><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C003802b3ac5f46128ddf08d7743c02cf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637105673397651922&sdata=f8iQdyJORmgnn%2FtxV7vRrJV8HzhJJTN4bNDpTj4PU%2BA%3D&reserved=0" originalsrc="https://puck.nether.net/mailman/listinfo/cisco-voip" shash="agMFpKlMEaE7qwQOrXVLm80AU5YQXwn/FZRZ2QvXmrwhBFRw0td6/m+yvBd50S1Q2nAsDtrzx4Mg3JYStPblOf3nvfTkYCHDRbbB8duvZ6jRDXHLwBmtY03J9AbBuNyBbGLtrHN/V/K5bUrw8+DrTznyqa7ENYGh/Uo2itlrO1s=" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span>cisco-voip@puck.nether.net</span><br>
<span>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C003802b3ac5f46128ddf08d7743c02cf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637105673397671937&sdata=lH2%2F8sRfH%2FtDFi9Qt%2BgGF9B2CZhtM%2FhHagk%2BaD7o0xM%3D&reserved=0</span><br>
</div>
</blockquote>
</div>
</body>
</html>