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

Jonathan Charles jonvoip at gmail.com
Wed Nov 27 19:48:37 EST 2019


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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkb.vmware.com%2Fs%2Farticle%2F2034277&data=02%7C01%7C%7C68933632a9034cb6982808d77398b185%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637104971952651559&sdata=hpirlhOhpUibcfreuD26bRnR3D2w5NtTGqjxz3f0uIU%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C68933632a9034cb6982808d77398b185%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637104971952661564&sdata=fJcqdFCeqj8ntcObGdrIHjmbBT4mfc%2BULyoJSxFHjy4%3D&reserved=0>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191127/2a7ee6b0/attachment.htm>


More information about the cisco-voip mailing list