[cisco-voip] Preservation Mode, long time for call setups...

Thu Nov 28 14:17:22 EST 2019

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.

On Thu, Nov 28, 2019 at 1:02 PM Jonathan Charles <jonvoip at gmail.com> wrote:

> 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...
>
> I am going to suggest they change it back to originating port ID and break
> the channel group.
>
>
> Jonathan
>
> On Wed, Nov 27, 2019 at 7:37 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> 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...
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Thanks,
>>
>> Ryan
>>
>> ------------------------------
>> *From:* Jonathan Charles <jonvoip at gmail.com>
>> *Sent:* Wednesday, November 27, 2019 7:48 PM
>> *To:* Ryan Huff <ryanhuff at outlook.com>
>> *Cc:* cisco-voip at puck.nether.net <cisco-voip at puck.nether.net>
>> *Subject:* Re: [cisco-voip] Preservation Mode, long time for call
>> setups...
>>
>> Would you recommend changing it to Originating Port ID?
>>
>>
>> Jonathan
>>
>> On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> I would expect the same behavior from PAgP with ESXi.
>>
>> -Ryan
>>
>> On Nov 27, 2019, at 19:19, Jonathan Charles <jonvoip at gmail.com> wrote:
>>
>> 
>> They are channel group ON... (so, no LACP) on the switch...
>>
>>
>> Jonathan
>>
>> On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> 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.
>>
>> https://kb.vmware.com/s/article/2034277
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkb.vmware.com%2Fs%2Farticle%2F2034277&data=02%7C01%7C%7Ca802058aed07451c4a6e08d7739cbbe1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637104989304335769&sdata=s%2FLBSv5M9CRT8ofriXEX8%2FguNjuLklCQ1NVFA9qwcuI%3D&reserved=0>
>>
>> Sent from my iPhone
>>
>> On Nov 27, 2019, at 19:11, Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> 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.
>> 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.
>>
>> 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).
>>
>> What is the reason for suspecting you need to change the NIC teaming to
>> active/passive?
>>
>> 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.
>>
>> 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.
>>
>> Thanks,
>>
>> Ryan
>>
>> On Nov 27, 2019, at 18:17, Jonathan Charles <jonvoip at gmail.com> wrote:
>>
>>
>> 
>>
>> 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)
>>
>>
>> Customer is reporting Preservation Mode kicking in on the LAN and some
>> calls taking a long time to setup.
>>
>>
>> Currently, VMware is set to Route based on IP Hash with PAgP channel
>> groups.
>>
>>
>> I think we need to change it to  Route Based on Originating Virtual Port
>> instead, but I cannot prove it before hand...
>>
>>
>> What could be causing the Preservation Mode on the LAN?
>>
>>
>>
>> Jonathan
>>
>>
>>
>> _______________________________________________
>>
>> cisco-voip mailing list
>>
>> cisco-voip at puck.nether.net
>>
>>
>> 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
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Ca802058aed07451c4a6e08d7739cbbe1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637104989304345792&sdata=jLrZEk560DqydbB6OMBgFYUmUPLNmFJ%2FQk7HXktIDZA%3D&reserved=0>
>>
>> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191128/1e5e06df/attachment.htm>