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

Thu Nov 28 14:01:10 EST 2019

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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191128/001e9252/attachment.htm>