[cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?

Tue Oct 20 23:56:11 EDT 2015

My preferred approach is to leverage a CSR1000v to do all the routing and then NAT that traffic out to the network. In the art of transparency, I am currently an architect for a Lab as a Service (LaaS) style service, and migrations is one of the primary use cases. Once the migration is done in the lab then the configs are restored back to the production servers. There are always issues and unexpected “features” during these upgrades, and it seems to get more complicated with every release.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]<https://twitter.com/CollabSensei>
[chat]<xmpp:dennis.heim at wwt.com>[Phone]<tel:+13142121814>[video]<sip:dennis.heim at wwt.com>
“There is a fine line between Wrong and Visionary. Unfortunately, you have to be a visionary to see it." – Sheldon Cooper
“The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it.” -- Michelangelo Buonarroti
“We should tansform the way we work” -- RowanTrollope

Click here to join me in my Collaboration Meeting Room<https://wwt.webex.com/meet/dennis.heim>

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Brian V
Sent: Tuesday, October 20, 2015 12:51 PM
To: Cisco VOIP <cisco-voip at puck.nether.net>; lelio at uoguelph.ca
Subject: Re: [cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?

I've found it useful to put your duplicate network behind  separate NAT router.

Create a L2 (only L2, no L3 interface) VLAN on your production network, call it "Isolated"
Pick a L2/L3 network that can be your NAT "outside"  This network should be fully reachable in the enterprise and have some free IP addresses on it (like 5-10 free addresses)

Find a separate physical router (like an old 28xx), Connect the outside interface to your switch on an access port that was selected for the NAT "outside"
Connect the inside interface of the router to your switch on a port mapped to the "isolated" L2-only network

On the NAT router inside interface create the duplicate IP network as your production UC network
(don't run any routing protocols, just use a static default on the NAT router to get back to the core network for mgmt)
On the NAT router outside, assign an IP to the interface for management. Then configure simple 1:1 NATs for each of your voice servers.  Trunk the "isolated", L2 only, VLAN into your VMware host and assign to the guest UC VMs

Since the duplicate IP interface only exists on the NAT router "inside" interface and you don't have any L3 IP address created on the isolated VLAN, your duplicate network is safely isolated yet reachable.

You'll be able to reach the voice servers via the NAT "outside" address
The voice servers will be able to "reach out" to the production network for NTP, LDAP. sFTP,  etc. but appear to come from the NAT address.

On 10/20/2015 9:40 AM, Lelio Fulgenzi wrote:

My major concern is IP address conflicts. Right now, with my offline network, it's completely isolated, with the UCS solution, unless I buy a UCS server(s) that is sized accordingly to hold the VMs sized for my production environment (which is unlikely), I'll have to consider feeding the UCS servers with the offline network which is a duplicate of the production network.

While technically possible, it would mean that the entire team be aware of this special configuration and not mess with anything that could bridge the configurations and cause IP address conflicts. I'm envisioning a separate network cable plugged into our offline switch/routers that would connect to the UCS server(s) in a separate VLAN. Unfortunately, I'm not up to speed with the intricacies of the UCS systems and VM, etc. and whether or not that would cause issues.

As with other organizations, we're under pressure to keep systems up and running 24 hours a day. We're improving our service availability design to hopefully help us going forward. For example, building an almost exact duplicate of our auto-attendant and call processing on Unity Express, so that we can do work on Connection while peoples business can continue at 3 in the morning while we do work.

We may revisit the offline upgrade in lieu of an inplace upgrade, but I'm not sure we're there yet.

Lelio

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519‐824‐4120 Ext 56354
lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs>
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

________________________________
From: "Ryan Huff" <ryanhuff at outlook.com><mailto:ryanhuff at outlook.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca><mailto:lelio at uoguelph.ca>
Cc: "Kevin Przybylowski" <kevinp at advancedtsg.com><mailto:kevinp at advancedtsg.com>, "Anthony Holloway" <avholloway+cisco-voip at gmail.com><mailto:avholloway+cisco-voip at gmail.com>, "Cisco VoIP Group" <cisco-voip at puck.nether.net><mailto:cisco-voip at puck.nether.net>
Sent: Sunday, October 18, 2015 7:04:42 PM
Subject: Re: [cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?

Lelio, what challenges are you facing in your next upgrade on UCS?

I don't think staging is so much 'the old way of doing it' as much as it is depending on the engagement and timeline, in my opinion.

If the target environment is only sized for the production VMs (and your coming from MCS) .... it might be difficult to do a bridge in the target environment. In that case, I would advocate pulling the DRS and upgrading offnet, unless the customer can spin-up an sftp server that you can use to shuffle DRS on. At that point though, I'd say it is going to take just as long, one way or the other.

Virtual to virtual with plenty of room in the datastores can certainly, and easily be done onnet. In place upgrades are another great case for onnet upgrades without staging.

As Anthony mentioned earlier, PCD is only valuable (IMO) in a rather limited set of circumstances and has enough nuances that I don't bother with it. PCD has a ways to go before I'd consider using it in practice; it's a good idea -just too early for me.

Some organizations have change-controls that mandate major upgrades be ran in tandem/staged, then switched once signed off on. In those cases, I'll usually advocate upgrading the device loads on the current version before the switch, so at least the phones move over quick.

Thanks,

Ryan

Sent from my iPad

On Oct 18, 2015, at 6:36 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:

We've built an offline network where we have staged the last couple of upgrades. It's worked out well. We basically test everything we can to ensure operability. The day of the cutover there's an overall downtime of about 90 minutes but some things come up sooner.

I'm hoping to come up with a similar approach to the next one. But it would be using ucs so I'm not sure how to make that work just yet.

Sent from my iPhone

On Oct 16, 2015, at 3:52 PM, Kevin Przybylowski <kevinp at advancedtsg.com<mailto:kevinp at advancedtsg.com>> wrote:

It is very time consuming to stage in the lab… Installs, DRS’s, Upgrades, etc…  I’ve only done them in the past if there was a large gap in versions.  It looks like PCD PCD is getting better so it looks like a valid option nowadays for bare metal to esx migration/upgrades.

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Friday, October 16, 2015 3:42 PM
To: Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>>
Cc: Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?

You sound more organized than I am.  I would like to see what you have, sure.  Thanks for the offer.

I've never staged an upgrade in my lab, though I have heard of plenty of people doing this.  Is it really something to consider or is that a thing of the past?  Like pulling a drive from the array?  Not too mention, I rarely have time to perform two upgrades on a project like this.  I barely get enough time to upgrade the system once.

On Fri, Oct 16, 2015 at 1:56 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
I use an excel spread sheet with a hyperlink to the base doc in one sheet with notes and details gathered in the sheet.Then I create additional worksheets of subordinate documentation and notes and then make references from the base sheet to the subordinate sheets. I also have a sheet for customer discovery (current dns, ip, device loads .... etc). It ends up looking a lot like a Gantt chart.

If you'd like, I can sanitize and send one to you, to compare notes and see if there is anything of use to you.

Also, If time permits, and it's feasible,  I like to stage a mock upgrade in my lab with customer data (drs ... etc) and do a dry run.

-------- Original message --------
From: Anthony Holloway
Date:10/16/2015 2:38 PM (GMT-05:00)
To: Cisco VoIP Group
Subject: [cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?
Does anyone else do this?  Gather all of the documentation ahead of time, because inevitably you're going to revisit a document more than once?  There are a lot of documents to gather!  Anything I could be doing better?  Tips?  Tricks?

I create a spreadsheet of all of the pertinent documents I need to review or reference, like in this screenshot.  There's over 90 documents in this list.  Granted, I don't read them all front to back, but some I do, and  for others I need to reference information within them nonetheless.  You never know when you might find a small font hidden note in there.

E.g., From the 8945 Release Notes

"Release 9.4(2)SR1 can only be upgraded from 9.3(4) and later. Releases prior to 9.3(4) have to be upgraded to 9.3(4) first."

Source: 8945 9.4(2)SR1 Release Notes<http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8941_8945/firmware/9_4_2SR1/english/release_notes/P415_BK_RB1FD4B7_00_release-notes-942sr1.html#P415_TK_IA5F5D63_00>

I actually missed this one recently, and unlike 7900 series phones, they phone will just brick itself and never register.  Causing you to walk to every phone and reset power to it, or walk the mac address tables of your layer 2 network and shut/no shut the ports.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________

cisco-voip mailing list

cisco-voip at puck.nether.net<mailto: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/20151021/253e17a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3876 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151021/253e17a1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1389 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151021/253e17a1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1292 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151021/253e17a1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1391 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151021/253e17a1/attachment-0003.png>