[cisco-voip] How Many Docs Does it Take to Prep for an Upgrade?
Brian V
bvanbens at gmail.com
Tue Oct 20 12:50:55 EDT 2015
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
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
>
> ------------------------------------------------------------------------
> *From: *"Ryan Huff" <ryanhuff at outlook.com>
> *To: *"Lelio Fulgenzi" <lelio at uoguelph.ca>
> *Cc: *"Kevin Przybylowski" <kevinp at advancedtsg.com>, "Anthony
> Holloway" <avholloway+cisco-voip at gmail.com>, "Cisco VoIP Group"
> <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
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151020/8b067020/attachment.html>
More information about the cisco-voip
mailing list