Main Nav

Hello Everyone,

Pacific’s network infrastructure (core, distribution and server farm layers) are due for refresh. Currently, the infrastructure consists of single vendor equipment (Cisco). This refresh gives us an opportunity to consider other vendors at the core and distribution. The access, etc. would still remain Cisco. I’m interested in any experiences others have had in diversifying their network infrastructure in this manner. Also, if anyone has an RFP they are willing to share related to a network equipment replacement, I would greatly appreciate being able to review.

Thanks, Faye

 

Faye Snowden, PMP

OIT-Director of Communications Infrastructure

University of the Pacific

Stockton, CA 95211

Office: 209 946-3968

Fax: 209 932-4003

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

We went the opposite direction as we stayed Cisco in the core and are migrating to Enterasys on the edge.  We run Cisco Callmanager as well and Cisco phones have worked flawlessly on their switches.  I looked at several vendors but Enterasys won in MTBF, higher operating temperature, as good or better lifetime warranty than the others, and most importantly on price.  The only features that we used on our edge that Enterasys didn’t have were QoS mark downs via policing and vlan specific port mirroring.  We can do the mark downs in the core and just be more strict on our QoS policy and security on the edge with Enterasys policies.  The cost savings were and will continue to be substantial.

 

We looked at HP, Enterasys, Juniper, and Enterasys mainly for the core.  It came down to Enterasys and Cisco.  The deal Cisco had at the time on their new 4500 with Sup7-Es was too good to pass up.  We are moving over from a 6509 Sup720 core.  The maintenance savings were significant compared to the 6500.  The only feature we sacrificed with this move was reflexive access lists.

 

-Brian

 

On 9/13/2012 7:20 PM, Faye Snowden wrote:

Pacific’s network infrastructure (core, distribution and server farm layers) are due for refresh. Currently, the infrastructure consists of single vendor equipment (Cisco). This refresh gives us an opportunity to consider other vendors at the core and distribution. The access, etc. would still remain Cisco.


On 9/13/2012 8:21 PM, Kellogg, Brian D. wrote:
>
> We went the opposite direction as we stayed Cisco in the core and are migrating to Enterasys on the edge. 

We too were formerly 100% Cisco, somewhat locked in by CiscoWorks (gave up the money chase / obsolescence race) and later Clean Access (same thing).  After switching over to Bradford (very vendor-agnostic) we entertained other access layer options.  We have done evaluations of some depth of HP Procurve, Brocade, Extreme, Enterasys, Avaya, and perhaps a couple others I've lost track.  We have some 10-15% Procurves out there, with a similar and growing percentage of Brocades, and a smattering of 3Com Intellijacks for those "just need another couple jacks" quick-fix solutions.  Procurves don't play well with default Cisco PVST spanning-tree.

We are still all Cisco at layer-3.  Our network is very VRF-dependent and the interoperability there with other vendors is lacking, difficult, and/or high-end with everyone else.  We have also adopted EIGRP for interior routing, as it is the only solution that does "load aware" routing over otherwise equal cost paths.  Shifting to another vendor would require an OSPF, ISIS, or similar conversion with the associated trade-offs in the load sharing.

The access layer compromises and trade-offs seem to be much easier to accomodate than the more dramatic layer-3 and/or core changes.

Jeff
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Hello,

 

At the University of New Hampshire we have used cisco for routing and collapse points over the years.  On the campus LAN we run Enterasys at the edge, WIFI and in in certain parts of the data centers.  Our NAC solution is Enterasys as well, which recently replaced the Southwestern Netreg (modified for our needs of course). We also use various other vendors for VPNs, load balancers and the WAN equipment.

 

We receive outstanding service as well as great response to change requests form Enterasys.  This has been a huge value for the growth of our network in WIFI and our effort to build a reliable IPv6 network.

 

As you can guess I recommend looking at Enterasys networking equipment and the value they can bring to your network.

 

-scott

 

What a useful thread!  We looked at Procurve and chose not to use them, because as Jeff noted: "Procurves don't play well with default Cisco PVST spanning-tree."  

Does Enterasys work with the default Cisco PVST+ spanning-tree?  We would be really uncomfortable trying to re-engineer the spanning tree protocol.  Based on things people have said on the list, we reached out once to enterasys, but they were only interested in selling us a full-out network replacement.  Have others experience this, or is it just us?

best,
Dennis Bohn
Manager of Network and Systems
Adelphi University
bohn@adelphi.edu
5168773327



********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

We currently run HP procurves 5400's for our access layer as well as for some layer 3 parts as well.  The comment about them not playing well with the cisco pvst is changing since they just introduced support for PVST in the latest firmware for some of their models.  It is not an issue for us though since we switched over to MSTP quite a while ago to be able to support multiple vendor networking environment.
 
Steve
South Dakota School of Mines and Technology 
 

Can you help me understand why you would need to load balance connections via EIGRP when 10 Gig has gotten so cheap?

Are you talking about WAN connections?

 

For the LAN, you can do all kinds of load balancing using standards based solutions. 802.3ad, RSTP, OSPF and VRRP can accomplish this very nicely, but I would argue that the HA it provides is even more important than the load balancing, given how cheap high speed LAN interfaces are these days.

 

As far as I know, RSTP, and later standards based enhancements, do everything Cisco’s proprietary PVST does only it is an IEEE standard which means it is very likely to be interoperable between vendors. In Cisco’s defense, I believe they came up with the proprietary versions to address weaknesses in the original version of STP. I believe the later standards were based upon Cisco’s original versions, even though they are not compatible. Cisco now supports the standards versions as well.

 

I think this is a great discussion topic, and it seems to be making the point that when you design networks based upon standards,  you at least have the option of using multiple vendors. That’s why an RFP for core or edge should include a detailed breakout of standards that make this possible.

 

Having said that, there is also a case to be made for the single vendor approach (for networking equipment), especially for a small shop that does not have a lot of network engineering support depth. Then you are relieved of grappling with some of these issues, and live with the one vendor, and hope they treat you well.

 

Pete Morrissey

 

I agree

 

We use RSTP without a problem between our differing vendor switches, but our network doesn’t change much and I police edge ports pretty strictly for BPDUs and such.  Still, we have a pretty simple treed network with one routing point that is also configured to be the spanning-tree root at all times.  I strive for simplicity when and where it doesn’t interfere with the budget or other more important goals of course.

 

We use link aggregation without issue between vendor equipment as well.

 

-Brian

 

 

We use spanning tree as follows:

 

     Core cisco: “rapid-pvst”

     Cisco core device is set as ROOT bridge

     Edge Enterasys: “rstp”

 

 

 

I believe this was put in place some years ago over a Christmas break around 3am.

It seems to work very well for us.

 

-scott k

University of New Hampshire

 

 

I would concur, open standards are a good thing.  We have worked to make sure that our infrastructure was operating on open standards so that we are not bound by an one vendor.  OSPF has worked very well for us.  We have been very pleased with our Juniper solution in the Data Center.  It is fast.  When looking at traffic on the SAN NFS mounts, I was able to find round trip times going from the SAN via a 10Gig to a 1Gig server at sub 10  and some sub 5 micro seconds.  This is just using their EX stuff and doing HA via LAGs across switches in a virtual chassis.  We implemented our solution before they introduced Q-Fabric.  I would love to hear if anyone has gone that route.

 

They have also proven to be very green even with redundant hot swappable power supplies in each member of the virtual chassis at a more reasonable cost then our previous solution.

 

If you are needing to separate routing tables, the way Junos (the OS) handles virtual routers is great to work with.  The part that is minor but I have found to be a great asset has been how Junos does commits.  In most every other implementation, the commands you set go into effect right away.  Since Juniper is essentially a BSD controlling computer that provides the settings and a small amount of CPU to a switch layer that is primarily running all the switching functions via compiled forwarding tables on ASICs, you can line up your configuration, compare with the running version, run a check and then do a commit.  Changes do not go into effect until you send (commit) your configuration where the changes get sent to the switch layer.  It also keeps multiple generations of past commits.  If you goof, ( I am probably the only one in the group that has ever done that) then a single command with a commit can immediately restore you back to your last configuration, even if it is multiple interfaces or many commands.  In my mind, that is really helpful.  Need to know how it was set 20 commits ago?  No problem, there is a compare option.

 

We have been very pleased.  For us they have been faster, greener, and more cost effective as a data center solution. 

Hope that helps.  That represents on person’s mileage anyway.

 

Will McCullen

Principal Analyst

Pima Community College

520-206-4873

 

I agree with the simplicity. I don’t’ think you can underestimate the importance of simplicity in network design.

Complexity often works against reliability.

Pete M.

 

The OP said that their network infrastructure was due for a refresh, which makes me curious what lifespan others are assigning to network infrastructure components.  For example, we have been operating on a five year replacement cycle for edge equipment, but the increased quality and therefore longer life expectancy of edge equipment has me considering pushing that out to eight years or more.  

The comment about features seems to be a key consideration:  What functionality do you need for which network component, and what is the competitive price for that functionality? Therefore, if you're not considering, or at least price shopping alternative vendors, you're probably overpaying.  Similarly, I agree with the comments about using open standards.  While proprietary standards are often borne out of innovation, what degree of innovation do most of us require in our networks? Sometimes there are benefits to those standards, but there's a certain amount of lock-in you face when adopting them.  In this day you should encounter very little resistance concerning vendor interoperability, if you're using open standards.  

Kris Sulzberger
Associate Director for Technical Services
Denison University

On 9/14/2012 3:48 PM, Kris Sulzberger wrote:
The OP said that their network infrastructure was due for a refresh, which makes me curious what lifespan others are assigning to network infrastructure components.  For example, we have been operating on a five year replacement cycle for edge equipment, but the increased quality and therefore longer life expectancy of edge equipment has me considering pushing that out to eight years or more. 

I wish :)

Most of our infrastructure has been funded out of one-time or CapEx funds, with significant ignorance of operating (maintenance) or replacement budget.  We had some 15-year-old gear out there (Cisco Catalyst XL series) until this past summer, and did some of that "refresh" (if you want to call it that) involved getting some "refurbished" 2950s (still obsolete, but not so extreme).

We have tried to push maintenance (at least) on core-to-border gear, but access/edge layer remains largely ignored.

Jeff
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

I would echo Jeff's comments almost verbatim. We have no specific refresh cycle for network equipment. We replace core/border equipment when it goes EOS by the vendor. Access/edge switching equipment pretty much remains ignored. We just keep spares on hand. We are more aggressive replacing wireless gear, but funding still comes from special project proposals rather than a replacement program. 

Thanks,
Chris


From: Jeff Kell <jeff-kell@UTC.EDU>
Reply-To: The EDUCAUSE Network Management Constituent Group Listserv <NETMAN@LISTSERV.EDUCAUSE.EDU>
Date: Friday, September 14, 2012 3:14 PM
To: "NETMAN@LISTSERV.EDUCAUSE.EDU" <NETMAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [NETMAN] Network Refresh: RFPs and Ideas on Vendor Diversity

On 9/14/2012 3:48 PM, Kris Sulzberger wrote:
The OP said that their network infrastructure was due for a refresh, which makes me curious what lifespan others are assigning to network infrastructure components.  For example, we have been operating on a five year replacement cycle for edge equipment, but the increased quality and therefore longer life expectancy of edge equipment has me considering pushing that out to eight years or more. 

I wish :)

Most of our infrastructure has been funded out of one-time or CapEx funds, with significant ignorance of operating (maintenance) or replacement budget.  We had some 15-year-old gear out there (Cisco Catalyst XL series) until this past summer, and did some of that "refresh" (if you want to call it that) involved getting some "refurbished" 2950s (still obsolete, but not so extreme).

We have tried to push maintenance (at least) on core-to-border gear, but access/edge layer remains largely ignored.

Jeff
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

 

 

How did VoIP perform with per packet load balancing?

 

Regards,

Adrian

 

 

 

From: Jeff Kell [mailto:jeff-kell@UTC.EDU]
Sent: Friday, September 14, 2012 6:10 PM
Subject: Re: Network Refresh: RFPs and Ideas on Vendor Diversity

 

On 9/14/2012 9:36 AM, Peter P Morrissey wrote:

Can you help me understand why you would need to load balance connections via EIGRP when 10 Gig has gotten so cheap?

Are you talking about WAN connections?


If I had the budget and hardware for 10G, I'd already be there and not sweating it :)  As it stands, we have toyed with link aggregation from all aspects:  simple port-channels (varying degrees of hardware support for hashing connections), and multiple layer-3 links.  We've evolved from RIP to OSPSF and finally to EIGRP; the latter has better load balancing and seemingly better convergence on failures.  We even tried per-packet load balancing where it was supported, but that doesn't extend to lower end Catalysts which we typically use in building CE routers.


For the LAN, you can do all kinds of load balancing using standards based solutions. 802.3ad, RSTP, OSPF and VRRP can accomplish this very nicely, but I would argue that the HA it provides is even more important than the load balancing, given how cheap high speed LAN interfaces are these days.


We're trying to go with stacked layer-3 (VSS in the future, stacked 3750s for now) to avoid the soft redundancy of HSRP/VRRP.  Not there yet other than a few prototypes, but preferable to the soft options.


As far as I know, RSTP, and later standards based enhancements, do everything Cisco’s proprietary PVST does only it is an IEEE standard which means it is very likely to be interoperable between vendors. In Cisco’s defense, I believe they came up with the proprietary versions to address weaknesses in the original version of STP. I believe the later standards were based upon Cisco’s original versions, even though they are not compatible. Cisco now supports the standards versions as well. 


Yes.  But the conversion is daunting to say the least, and certainly disruptive.  Brocade seems to play well with PVST, and I need to investigate the earlier comments that latest Procurve firmware may do the same.  To keep things balanced, the downside of Brocade is lack of mac-address-notifications which our NAC prefers, while latest Procurve firmware does provide this.  Brocades can only do link-up/link-down.


I think this is a great discussion topic, and it seems to be making the point that when you design networks based upon standards,  you at least have the option of using multiple vendors. That’s why an RFP for core or edge should include a detailed breakout of standards that make this possible.


Yes, whatever works for you.  Enterasys has some "excellent" features and coverage, all the way to NAC, access controls, QoS, and traffic shaping; but like some other vendors, they imply an end-to-end (or very near it) implementation of their hardware/software.  There are some relatively open solutions out there that are more vendor agnostic, you just have to hunt them down and interpret their limitations with respect to your environment.


Having said that, there is also a case to be made for the single vendor approach (for networking equipment), especially for a small shop that does not have a lot of network engineering support depth. Then you are relieved of grappling with some of these issues, and live with the one vendor, and hope they treat you well.


Been there, done that, got the T-Shirt, and they typically broke the bank in the long haul.  Especially Cisco software/management, which seems to compete with itself in the race to obsolescence and replacement.

Jeff

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.