AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Brian.Stark@lsi.com>,<Richard.Hardiman@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	E1EC65251D4B3D46BBC0AAA3C0629222B007FC77@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 9 Dec 2009 16:36:03 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Stark, Brian" <Brian.Stark@lsi.com>
Cc: "Hardiman, Richard" <Richard.Hardiman@lsi.com>
Subject: Re: problem with new lab network switches
Message-ID: <20091209163603.5a49fa1f@ripper.onstor.net>
In-Reply-To: <E1EC65251D4B3D46BBC0AAA3C0629222B007FC77@cosmail02.lsi.com>
References: <20091209153523.3b815785@ripper.onstor.net>
	<E1EC65251D4B3D46BBC0AAA3C0629222B007FC77@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

One switch will link the lab to the rest of the network, the rest will
be lab-only.  That will be virtual 'one' since there might be a
redundant link.  However, that 'one' will probably be the backbone
switch for the lab, so that will be its major role.  Routing to the IT
network will be a minor role, and not something that has a lot of
volatility.  That link will essentially be a default route for that
switch, so no major overlap there.

On Wed, 9 Dec 2009 17:01:35 -0700 "Stark, Brian" <Brian.Stark@lsi.com>
wrote:

> Andy,
> 
> Just so I'm clear, will these switches be used to link Elab to the
> rest of the LSI network?  I think that's the case, but I'd like to
> confirm.
> 
> 
> Brian
> 
> 
> 
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Wednesday, December 09, 2009 3:35 PM
> To: Stark, Brian
> Cc: Hardiman, Richard
> Subject: problem with new lab network switches
> 
> Hi Brian,
> 
> I got an update from Rich H. today, and it seems that our cisco
> switches for the lab have been hijacked by LSI IT, best I can tell.
> 
> As far as I'm concerned, those switches belong to us, not IT, and no
> way in hell should they be holding them back and tying them to other
> programs they have going, like re-doing onstor's IP space.  Rich tells
> me that Rich Miller isn't letting us have them and they plan on owning
> those switches and not deploying them until they complete a plan
> for re-IPing our whole building, lab included, as well as a few other
> IT ventures they have going.
> 
> These various IT movements are completely separate from the elab
> switches and I'm just really surprised that IT is trying to tie them
> together.
> 
> We need those switches now-1 week.  We've already run into problems
> that we could have avoided if we had deployed these switches that are
> just sitting in a closet somewhere, if not actually installed in some
> other location, which is something I'm starting to suspect.
> 
> I'm also told that Karen is making unhappy noises that we have yet to
> install these switches that she went to great lengths to acquire for
> us, so I believe she's on our side in this.
> 
> I want to make it clear to these folks that, as far as I'm concerned,
> Rich H. is the "owner" of those switches and we won't be installing
> the tacacs client software on them which allows anyone in LSI IT to
> log into them and make lots of really helpful changes ... you get the
> idea.  Any switches outside the lab, that's different, but inside the
> lab, only Rich and people deemed worthy by Rich, etc., will be able to
> access those switches and make config changes.
> 
> Our schedules depend on that chain of responsibility.  They're already
> talking about not even having a plan to present to us until January,
> never mind a deployment date.
> 
> Thanks,
> 
> a
