Hey guys,
Looking to lean on a few more experienced DC guys here. We are contemplating purchasing 9504 chassis, with the new FEX's, however there is the possibility of needing DCI. Would you rather go with arista/nexus?
pros/cons of each?
The Cisco Nexus 9Ks are pretty much the only DC switch I would still recommend if Cisco is your choice.
You have not touched really on any features and requirements needed outside of possibly needing DCI, so its kinda hard to nail down a solid choice. But I dont mind throwing my opinion in the mix. :D
Right now I would deploy Arista in almost all scenarios unless I was forced into Cisco or had solid reasons. They have a solid product line and dealing with code upgrades, versioning is much easier than the mess Cisco Nexus is. I like their VxLAN option for both internal fabric and DCI. CloudVision is a great tool if leveraged properly and really simplifies management. Cisco well... they can sell you ACI! or Prime :|
From what I have been playing with Arista is also way ahead in modernizing their EOS platform. From a solid single API to YANG and NetConf across the board. This helps a TON when talking automation or pulling structured data out of your device instead of the old CLI way. Cisco is still a steaming pill of shit IMO.
Telemetry and real time analytics. They are both getting there. Arista though its just gonna be a code bump and module install. Where Cisco it looks like hardware refresh to get gear supporting this stuff. I could be wrong though.
As for DCI depending on how complex you are looking to go with it, Arista has a number of options all from the same hardware. Unlike Cisco if you decide to go with advanced ISP technology ( C/DWDM, MPLS, Segment Routing) you are not gonna get much out of the Nexus from last I checked. Would have to go ASRs for DCI. But then again, Aristas Service provider technology is still pretty new and that makes me somewhat nervous. Id want some serious lab time to bake it in or give it another year or so to iron out bugs.
If you are adventures my second recommendation would be to check out whitebox and go Cumulus+Apstra or Arista+Apstra for DC fabric. But this would only be feasible in a mostly greenfield deployment with how Apstra does intent driven networking. Also this is a pretty big shift into automation and newer technologies, so there would need to be a shift in how the team runs their day to day. But damn it would be cool!
Quote from: that1guy15 on April 20, 2017, 05:05:00 PM
You have not touched really on any features and requirements needed outside of possibly needing DCI, so its kinda hard to nail down a solid choice. But I dont mind throwing my opinion in the mix. :D
Right now I would deploy Arista in almost all scenarios unless I was forced into Cisco or had solid reasons.
Agree except with caveat that there is presently no EVPN story (lacks loads of features that are a given in Juniper/Cisco), so right now, you have to be content with the 'traditional' CVX solution for a control plane.
In fact Juniper are clearly the technology leader in the EVPN space (right now). ESI blows the crap out of vPC or MLAG, their silicon has the highest numbers (outside of the latest gen of Arista software-tweaked Jericho (I think?) merchant silicon e.g. the FiB compression algos etc.), above all, JunOS stack re: automation API > everything else, they've been doing it for the longest and at service provider scale. But going to the J team is a big obstacle for most Cisco shops, whereas the Arista syntax makes it really easy to switch. And Arista do have excellent API. Not a fan of how they went eos_template with Ansible, but I digress....
Cloudvision runs RINGS around DCMN if you want a turn-key (well nothing in this SD space is really turn-key... but I digress again) automation platform.
But yes circle back to requirements, requirements and more requirements.
BTW Would you trust Apstra? We've had the dog and pony show, looks nice but very beta... only 1 use-case (leaf/spine) 1 topology.... have you run proper evaluation vs DCMN/VTS and Network Director and Cloudvision?
Actually, there is a broad EVPN type 2 through type 5 play right now and it works flawlessly.
http://www.eantc.de/fileadmin/eantc/downloads/events/2011-2015/MPLSSDNNFV_2017/EANTC-MPLSSDNNFV2017-WhitePaper-Final_v2.pdf
^^ If you have the time this is an excellent read where they are not biased towards any real hardware vendor.
Nothing wrong with the Juniper automation if you have the time to go through 100000 lines of documentation and want to work with netconf if you feel that is the real future of automation. Arista is highly embracing openconfig for newer ways of automation. If you want to use the api its really simple and uses CLI as the transport so it makes it real for most network people.
As for eos_template its actually depricated. You need to use eos_config :D .. I am assuming you are referring to jinja2 templates. Jinja is great.
As far as your last question goes I would just wait for open config to mature.
I'm well aware of Type-1 through to Type-5, I meant Arista's EVPN implementation. @ my last meeting with your guys down under, they advised me that they still hadn't gotten ARP suppression nor symmetrical-IRB (inter-VXLAN IRB via Type-5) nor IGMP snooping + a whole bunch of other caveats on how the underlay/overlay needs to be setup (e.g. only BGP allowed, can't have say OSPF underlay). Are you saying that this info is wrong? Coz I was shown a slide saying its not possible with the Arista logo on it, + roadmap for when stuff would get knocked off... NDA and all that, but I'm sure you've got the same slides. I can PM you the SEs involved if you think some wires are crossed or loop into an email chain?
Then again reading your attached doco I note specifically the Type-5 symmetric IRB working so I am going to prod your colleagues a bit... I won't mention where I got this from ;) or maybe this was on unreleased software (likely scenario I suppose).
Not meaning to vendor bash on you guys specifically, but as EVPN is a hot topic, I must admit I was taken a bit aback by the above info. Nothing wrong with CVX if that fits your requirements, I know a lot of people use it.
Yep I meant eos_config (the jinja2 stuff) - as much as jinja2 works great, I'm a bit sad that its at the end of the day still focusing on getting a show run, complete with having to care about indents etc. (though you could level that argument back @ YAML I guess). I must admit I haven't looked at specifically how JunOS interacts with ansible.
re: Juniper automation, I get what you mean, though have you tried pzEZ? A router/switch as a python class. Magnificent. (basically what Cisco wanted to do with onePK except dropped it like its hot). I'm also pretty sure their RESTAPI is feature complete.
At least we can all agree Cisco is #3 when it comes to automation LOL
I'm well aware of Type-1 through to Type-5, I meant Arista's EVPN implementation. @ my last meeting with your guys down under, they advised me that they still hadn't gotten ARP suppression nor symmetrical-IRB (inter-VXLAN IRB via Type-5) nor IGMP snooping + a whole bunch of other caveats on how the underlay/overlay needs to be setup (e.g. only BGP allowed, can't have say OSPF underlay). Are you saying that this info is wrong? Coz I was shown a slide saying its not possible with the Arista logo on it, + roadmap for when stuff would get knocked off... NDA and all that, but I'm sure you've got the same slides. I can PM you the SEs involved if you think some wires are crossed or loop into an email chain?
I dont feel like quoting because its all messed up so response in bold.
Check that link out both connected and non connected IRB and ARP suppression are both within there.
BGP is the only underlay allowed. You should only BGP all the things no idea why you would want to OSPF stuff.
Keep in mind this is only on a few model switches.
Not meaning to vendor bash on you guys specifically, but as EVPN is a hot topic, I must admit I was taken a bit aback by the above info. Nothing wrong with CVX if that fits your requirements, I know a lot of people use it.
Yep, Im all on board with EVPN. If you do not need a type 5 of vrf isolation then go cvx. But looking at that NFV conference nobodies stuff right now is compatable with anyone elses!
Yep I meant eos_config (the jinja2 stuff) - as much as jinja2 works great, I'm a bit sad that its at the end of the day still focusing on getting a show run, complete with having to care about indents etc. (though you could level that argument back @ YAML I guess). I must admit I haven't looked at specifically how JunOS interacts with ansible.
You can run any CLI command against the switch with the eos_cli command and then you can pretty print it or even ask for certain parts of the configuration.
At least we can all agree Cisco is #3 when it comes to automation LOL
lololololol
I know where we do good and I know where we dont. We were late to the evpn game. But once everyone see's that fit as the DC fabric of the future and everyone can kind of talk to everyone elses stuff including type 3 IRB its going to be awesome. Use openconfig to orchestrate everything and you will have a pretty cool automated fabric data center.
We are still early in this project, but we are possibly looking to extend out datacenter to a new building with dark fiber from a carrier inbetween. We have had discussions on whether these datacenters are going to be autonomous (L3), or L2 extensions. We do not want to make this ridiculously difficult if we do not have to. I have heard some significant horror stories about OTV, which is also making me look to other competitors. Price is also another big reason, I know the 9504's are cheap, but if arista offers the best option, for the best price, I find it hard pressed to go cisco.
As for juniper, I have little to no experience. We purchased a 3300 for testing, but other than that I have no experience. I cannot stand their CLI, and I do not know if I am comfortable implementing a first time vendor into our core when I have no experience.
The biggest reason I see a need for DCI would be virtualization, and vmotion. I can see a need to move vms between data centers. I am trying my best to push L3 separation, but I am not sure if our proprietary connections will allow for that.
I am also interested in arista because they have full routing features/functionality on their 7500R platform. This makes it easier to push a product knowing we will not have to purchase anything additional when we can do our internet edge/routing all on one machine.
Quote from: LynK on April 21, 2017, 07:38:44 AM
The biggest reason I see a need for DCI would be virtualization, and vmotion. I can see a need to move vms between data centers. I am trying my best to push L3 separation, but I am not sure if our proprietary connections will allow for that.
All the DBAs and sysadmins say in unison:
PLZ LAYYER 2 ADDJASENSEE ERRYWHERE N THA DATASENTIR PLZ KTHXBAI:oracle: :mssql:
Quote from: deanwebb on April 21, 2017, 08:20:40 AM
Quote from: LynK on April 21, 2017, 07:38:44 AM
The biggest reason I see a need for DCI would be virtualization, and vmotion. I can see a need to move vms between data centers. I am trying my best to push L3 separation, but I am not sure if our proprietary connections will allow for that.
All the DBAs and sysadmins say in unison:
PLZ LAYYER 2 ADDJASENSEE ERRYWHERE N THA DATASENTIR PLZ KTHXBAI
:oracle: :mssql:
Do not roll out OTV. You will pretty much lock yourself into a platform and technology for life.
I am sort of biased because I do work for Arista. 7500R platform is fantastic. Both for buffers, speeds feeds and the typical Arista automation. The chip itself its extremely similar to the chip in the 7500E in many ways. So the reliability is still there. Its practically a swiss army knife in all the features it supports.
But as Wintermute and I have said EVPN has been amazing. Like if you replace anything at this point EVPN and VXLAN are the technologies you would want to go with. Typically MPLS has been pretty expensive although we have some boxes now and other vendors have some cheep boxes but everything supports VXLAN/VXLAN routing wether its single pass or not its 100% the way to go imho.
Quote from: LynK on April 21, 2017, 07:38:44 AM
We are still early in this project, but we are possibly looking to extend out datacenter to a new building with dark fiber from a carrier inbetween. We have had discussions on whether these datacenters are going to be autonomous (L3), or L2 extensions. We do not want to make this ridiculously difficult if we do not have to. I have heard some significant horror stories about OTV, which is also making me look to other competitors. Price is also another big reason, I know the 9504's are cheap, but if arista offers the best option, for the best price, I find it hard pressed to go cisco.
As for juniper, I have little to no experience. We purchased a 3300 for testing, but other than that I have no experience. I cannot stand their CLI, and I do not know if I am comfortable implementing a first time vendor into our core when I have no experience.
The biggest reason I see a need for DCI would be virtualization, and vmotion. I can see a need to move vms between data centers. I am trying my best to push L3 separation, but I am not sure if our proprietary connections will allow for that.
I am also interested in arista because they have full routing features/functionality on their 7500R platform. This makes it easier to push a product knowing we will not have to purchase anything additional when we can do our internet edge/routing all on one machine.
Sounds stock standard. There's very little besides inertia/politics/documentation (publicly available white papers, design guides, you know the score) to recommend Cisco except for EVPN maturity although burnyd has given his refutation (and I personally am going to hit up some official channels to get some clarity, anything not NDA happy to share).
re: DCI and OTV etc., the horror stories are from people who don't design their routing properly and don't properly think through the implications and traffic flows (FOR ALL SCENARIOS) for stretched L2, especially stateful devices in path, or trying to avoid that problem via stretching FW clusters etc (run away!). You don't sound like you have enormous scale, Arista VXLAN is rock solid and will tunnel anything including EIGRP peerings (have seen this live... not recommend, but the point is that its a great solution), flood and learn isn't as big a deal as it sounds until scaling is a problem.
However, with Anycast GW topologies (esp. again EVPN....) and VXLAN IRB the ballgame changes, you might want to stop thinking re: traditional DCI as in L2 tunnels point to point. It also starts to get vendor/HW specific (e.g. the old Trident2 can't IRB on same pass caveat).
burynd/aspiring, I think it would be of benefit if you were able to share the old Arista VXLAN Bridging and routing slides (CHI-NOG 05, Darrin Machay) as an intro? Centralised vs Direct vs Indirect vs Underlay routing etc... As for EVPN, this book seems good (reading it now) - Building Data Centers with VXLAN BGP EVPN: A Cisco NXOS Perspective - it is biased though (as you'd expect) but a good summary so far
In all honesty the Juniper MPLS in the SDN era is probably the best reference for EVPN it has both MPLS and VXLAN for EVPN.
The world according to burnyd next year will be EVPN / Openconfig for intent based network configuration. However, that is just me.
IRB with VXLAN and EVPN is the real deal for sure!
All those things that Darren did on the slides were all a result of that previous nfv link I sent. Pretty much everything is there.
Hehe - this thread is funny.
Just got a list price quote from arista. VERY EXPENSIVE. We are going to be looking at their other options (were looking at their 7504R platform). It was going to be like ~400K list. lol.
you said it yourself - list - what's the real price?
note I have seen this before i.e. Cisco winning on pants-drop pricing. That, and CIO level conversations. lawsuits don't help.
out of curiosity why are you looking @ a 6RU chassis switch? Can the 1-2RU options in leaf-spine not handle your requirements? I know the Jericho switches are the new hotness but can a 'traditional' 1/2RU fixed leaf-spine scale-out topology handle your requirements.
burnyd, that MPLS in the SDN era book is possibly the greatest technical textbook I ever read. Really wish I had the time (and real-life XP and opportunities) to go into the SP space but alas I'll never get the required prod time on core SP infra to fully get into it. MPLS is fascinating
Yep they will in your words do pants dropping prices just to compete.
That Juniper book is amazing. Even at a company like Arista you would be really shocked at some of the large SP's what they are doing now a days. Things like small pockets of segment routing, UCMP just really whacky neato stuff.
But anyways, thats list price!
Quote from: LynK on April 25, 2017, 07:29:40 AM
Just got a list price quote from arista. VERY EXPENSIVE. We are going to be looking at their other options (were looking at their 7504R platform). It was going to be like ~400K list. lol.
That's list price, and for the best platform the company has to offer - which blows away the 9500. Instead of just looking at price tags, evaluate on technical merit. There are reasons why Cisco hates Arista, reasons why they drop pants on pricing when they can't compete technically, reasons why they continue to lose market share in the DC space, etc. - take all of that into consideration. Do you understand the capabilities of the 7500 or did you just throw up when you saw the price? Have your rep discuss the technical competitive points versus the 9500, and if you still don't like it, Arista has other platforms as well.
Evaluate on technical merit first - THEN shift if you have to due to budget.
I prefer the Facebook wedge as it has all those different color blinky LEDs on the front.
Does anyone else have cool blinky lights? uh huh...
:D
I am not going to sit here and say I know everything about the product line, but I do know that the 7500 series does have significantly more functionality than the 9504 systems.
At the end of the day, however, accounting is architecture. If you want to justify actually spending money on hardware vs. free hardware, you've got a lot of homework ahead of you. Cisco knows this, which is why they cut way back on their purchase prices, hoping to make the money back in licensing renewals and professional services engagements. In accounting-speak, this is all part of TCO, total cost of ownership.
If you can put numbers on *all* the costs and show that vendor A is going to be cheaper than vendor C, J, or even B, then you'll have numbers the accountants can understand. Any savings on personnel costs, maintenance, licensing, and the like will be important to identify and include.
Think of it this way: if we spend $400K on gear I can configure myself, that's ultimately cheaper than free gear that requires a $500K 6-month pro serv engagement with the vendor in order to get up and running. If you estimate more vendor staff would be required, say an actual on-site, year-round technical resource, that can easily hit a million, depending upon the vendor. That million may include all-hours tech support and a case manager, but that's still way more than the gear that has a higher cost that you can set up on your own with a minimum of tech calls.
remember my Credo (LoL) one of my old companies stood by this,
buy the cheapest POC you can, and spare no expense implementing it...
If it costs 10K up front and 50K to make it run, that's much better than 50K up front and 10K to make it run.
Take this advice with a grain of salt. it's probably better to do the opposite.
But the original take makes the bottom line look better upfront.
Look honestly, it sounds like you're going shopping before you've ironed out your requirements and design. This is a big no-no in my book. The book (ok, the consulting book, but it works) says: requirements then analyse options then design then FINALLY a BoM that derives from the design.
Do you really you have requirements that are unlikely to be met by any old Tomahawk based (or that equivalent performance e.g. Cisco 9200/9300s) fixed 10/40/100G merchant silicon? I would love to see your requirements and environment if 1 and 2RU pizzabox switches that can handle 48x10G and 4x40G uplinks nonblocking (raw or VXLAN encap) are too slow and you have > 16k MAC addresses per fabric. And off the top of my head I believe that's Trident2 figures i.e. 2014 merchant silicon, not 2017.
In other news, Cisco has finally gotten their ESI (Type-1 and Type-4 EVPN advertisements i.e. active-active multi-homing to the same LAN segment with EVPN without MLAG/vPC) working, and that despite all the white papers and the April 2017 textbook saying no, that EVPN DCI is now available (so EVPN multi-fabric with a EVPN DCI segment in the middle... sounds funny until you read the old 'solution' which was OTV, ugh). Expect formal public announcements in the near future.
Listen Guys,
I know how the proposal process goes. This is still very early in the project phase. I am looking to get numbers/prices for a project, to see what the cost would be so when presented to ownership I can give them a budgetary number, and answers to our solution. This is where I am now. The purpose of this post was not for your assistance with this project, but rather in your professional experience what are your thoughts on Arista's platform. How does it meet XYZ functionality, how is their support, pros/cons of their hardware/features.
Nothing more nothing less.
As far as our infrastructure currently. We are 99% physical server infrastructure, with a collapsed 6509 core (yes... non E). The idea is to provide the owners with an attractive upgrade to infrastructure that is current, and supported. My idea is to do this as cost effectively as possible. I do not want to drop a 400K deployment, and say here ya go. For example, I have requested a quote for a refurbished 9504 chassis with 23XX FIs. This I can get for around 120-140K list, and ~ around 80k, which is a very attractive price.
I am also investigating non chassis based deployments as well.
How many of those servers are on port channels so they can pool multiple NICs?
Quote from: wintermute000 on April 25, 2017, 05:31:44 PM
In other news, Cisco has finally gotten their ESI (Type-1 and Type-4 EVPN advertisements i.e. active-active multi-homing to the same LAN segment with EVPN without MLAG/vPC) working, and that despite all the white papers and the April 2017 textbook saying no, that EVPN DCI is now available (so EVPN multi-fabric with a EVPN DCI segment in the middle... sounds funny until you read the old 'solution' which was OTV, ugh). Expect formal public announcements in the near future.
Read that non biased non fake news link I posted.
Quote from: LynK on April 26, 2017, 09:07:38 AM
Listen Guys,
I know how the proposal process goes. This is still very early in the project phase. I am looking to get numbers/prices for a project, to see what the cost would be so when presented to ownership I can give them a budgetary number, and answers to our solution. This is where I am now. The purpose of this post was not for your assistance with this project, but rather in your professional experience what are your thoughts on Arista's platform. How does it meet XYZ functionality, how is their support, pros/cons of their hardware/features.
Nothing more nothing less.
As far as our infrastructure currently. We are 99% physical server infrastructure, with a collapsed 6509 core (yes... non E). The idea is to provide the owners with an attractive upgrade to infrastructure that is current, and supported. My idea is to do this as cost effectively as possible. I do not want to drop a 400K deployment, and say here ya go. For example, I have requested a quote for a refurbished 9504 chassis with 23XX FIs. This I can get for around 120-140K list, and ~ around 80k, which is a very attractive price.
I am also investigating non chassis based deployments as well.
You 100% do not need chassis now a days. Vendors have priced themselves out of chassis with the merchant silicon lanes. So since we are talking about Tomahawk in its first can handle 132 ports of 10GB links in its second generation that will be out will handle a lot more. Keep in mind this is a cost effective box thats in 1RU form factor. Breakout cables are not pretty but they are great for the price.
Hi burnyd - yes I read it - its great but if I go on vendor doco and current design guides etc and they say no go I can't very well assume its all great, esp as the testing may well have been on pre-release HW/SW revisions that I either can't get hold of or are not yet supported. I'm getting clarifications from various vendor SEs now and that's the gist of it - expect release second half FY17 and all the guides to be updated etc.
re: Lynk - point noted so I'll back off on the design / process questions and merely address your points directly. re: 9500 with FEX, two things
- what's wrong with a 9300 + FEX if you want to save money? Not to mention the new 9300Ex is now out. Does FEX. Faster and newer. Again I doubt you'll run into any capacity issues with 48x10/25 + 6x40Gb nonblocking.... if you're fine with a 6500 right now....
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/datasheet-c78-736651.html (http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/datasheet-c78-736651.html)
- you are aware that FEX's don't locally switch, even port to port on the same FEX has to hairpin through the uplink? (ristau mentioned something re: local switching coming in for F3 modules in 7.x for 7K but I'm not sure of the status on 9K).
- If you still want to do FEX, for the love of god do not go enhanced VPC. Its marketing designed to make your life miserable during upgrades. KISS
https://rednectar.net/2012/08/30/why-i-wouldnt-bother-with-enhanced-vpc/ (https://rednectar.net/2012/08/30/why-i-wouldnt-bother-with-enhanced-vpc/)
I have seen customers go down the 9K + FEX route simply due to price + inertia (CBF with leaf-spine and doing new things, just drop in newer faster iron, happy days).
RE: Arista in general, read Arista Warrior, marvel in what you can do, and remember that book is what 4-5 years old now. If you're not heavily into linux/scripting it may not blow you away. NX-OS has caught up a lot though a lot of where it falls down is at a qualitative level, not a tickbox e.g. yes it has RESTAPI but its flakier than Arista (how to quantify that though without a formal test regime where you go through every feature you could conceivably want to manipulate, I dunno). MLAG has less gotchas/caveats than vPC e.g. can peer routing through it.
The second point re: Arista I'd make is that Cloudvision (esp now that telemetry is out) is amazing. Its by far the slickest turn-key vendor automation solution on the market for DC fabrics. The telemetry is mind blowing - rewing the exact state of the network XYZ seconds ago and check the exact CAM or BGP tables at that state in time.... rollback config network wide.... the list goes on, buyrnd/aspiring can probably give you an even better pitch. If you don't believe me, go bake it off against say DCMN and come back with your findings...
We will look into the 9300 series, thank you for that recommendation. I know all about the enhanced VPC garbage. Trust me KISS is my motto. I am aware that they do not switch locally. They are EXTENSIONS of the fabric.
The primary reason we are looking into a chassis is because we are most likely going to only implement one core in each of our buildings. This allows the FEX design to be much simpler, but also getting the features of a chassis (modular, and easy hardware upgrades) , and also supervisor features (ISSU/etc.)
Well unfortunately the 9300EXs are all 1RU not modular.
If you want one monolithic thing with ISSU/dual sup then you're back to the big bad chassis switches.
I can't see though why you can't just have two 9300EXs with single homed FEXs offering vPC in lieu of a big 9500 with dual sup. One is more survivable (and cheaper) than the other?
ISSU is the lols
Quote from: burnyd on April 28, 2017, 08:24:18 AM
ISSU is the lols
ISSU with single processor devices
:rofl: :challenge-considered: :developers:
Haha just ISSU in general. Buy small rack unit switches run them a as spine switches and scale out your blast radius.
+100
I still have nightmares about my last multi stage (3 step) ISSU project for 7ks.
Quote from: ristau5741 on April 28, 2017, 09:08:28 AM
Quote from: burnyd on April 28, 2017, 08:24:18 AM
ISSU is the lols
ISSU with single processor devices
:rofl: :challenge-considered: :developers:
SSU Leaf - challenge accepted.
And in regards to ISSU, I did recently sit on a 2am to 5 am change control window where three MLAG ISSU upgrades were performed - went off without a hitch - I was pleasantly shocked. ;)
Quote from: deanwebb on April 25, 2017, 12:58:54 PM
At the end of the day, however, accounting is architecture. If you want to justify actually spending money on hardware vs. free hardware, you've got a lot of homework ahead of you. Cisco knows this, which is why they cut way back on their purchase prices, hoping to make the money back in licensing renewals and professional services engagements. In accounting-speak, this is all part of TCO, total cost of ownership.
If you can put numbers on *all* the costs and show that vendor A is going to be cheaper than vendor C, J, or even B, then you'll have numbers the accountants can understand. Any savings on personnel costs, maintenance, licensing, and the like will be important to identify and include.
Think of it this way: if we spend $400K on gear I can configure myself, that's ultimately cheaper than free gear that requires a $500K 6-month pro serv engagement with the vendor in order to get up and running. If you estimate more vendor staff would be required, say an actual on-site, year-round technical resource, that can easily hit a million, depending upon the vendor. That million may include all-hours tech support and a case manager, but that's still way more than the gear that has a higher cost that you can set up on your own with a minimum of tech calls.
I have a hard time swallowing this pill, but I haven't worked a day in an operational role. For me, I'm very much the type of person to go against the grain and be like, "Look - this is the best solution for XYZ reasons." (I also am completely capable of being able to tell when a solution is overkill as well, so when I say "best", I mean it's the best fit - cost is a secondary concern for me). I come at it from a no-nonsense, simple approach. If they can't stomach the price tag, I simply ask what that price needs to be, then I go back to the vendor. If they can't do it, I find the next best solution. If I start approaching a deadline, that's not my fault - I did my job. I presented the best solution possible, and you chose not to accept it and have me find another.
I'd probably be fired within a year.
Quote from: AspiringNetworker on May 02, 2017, 10:14:19 AM
I'd probably be fired within a year.
Probably, yes. :lol:
But what you're saying about "next best solution"... these guys will go for a totally unworkable solution, if the price is right and the vendor does enough of a C-level end-run and character assassination of an engineer to discount what's being said against their product.
I can say that A and B work great, C is abomination - use it and die.
C can then drop its pants on pricing, show a bunch of Gartner slides to the managers, and snow the higher-ups to where they ignore my recommendation and go with C because they *have* to have a vendor for this solution and, besides, nobody ever got fired for buying C, right?
Not only do I know of guys who got fired for buying C, I also know people that left companies after they bought C because they knew what was coming next.
The big C is introducing software-ISSU - containers LOL - other vendors doing similar. Though in this day and age, plan for failure, ECMP leaf-spine, just take it out gracefully, upgrade and bring it back into routing, done.
yeah but how gracefully can you take out a spine switch running L3, and have it be stateful? There is no way, even with BFD which makes it faster, but not stateful.
Thoughts?
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-735628.html#_Toc427398694
Also graceful bgp shutdown is a thing but haven't checked 9k support. Just normal routing things...
If theres a way to do it with standard routing, it's the answer.
So yeah, there is most definitely a way, and people do it all the time. OSPF max-metric is an old ISP trick for OSPF/iBGP MPLS designs for example, tweaking metrics is foolproof and yeah hitless - you may have some reordered packets but TCP should handle it
Thanks for the article. I was aware of graceful BGP, but not of the others.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_011010.html (http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_011010.html)
Quote from: LynK on May 03, 2017, 09:25:30 AM
yeah but how gracefully can you take out a spine switch running L3, and have it be stateful? There is no way, even with BFD which makes it faster, but not stateful.
Thoughts?
Poison metrics, or:
BGP Maintenance Mode:
https://eos.arista.com/maintenance-mode-lab-example-of-bgp-on-spine/
Quote from: deanwebb on May 02, 2017, 11:28:29 AM
Quote from: AspiringNetworker on May 02, 2017, 10:14:19 AM
I'd probably be fired within a year.
Probably, yes. :lol:
But what you're saying about "next best solution"... these guys will go for a totally unworkable solution, if the price is right and the vendor does enough of a C-level end-run and character assassination of an engineer to discount what's being said against their product.
I can say that A and B work great, C is abomination - use it and die.
C can then drop its pants on pricing, show a bunch of Gartner slides to the managers, and snow the higher-ups to where they ignore my recommendation and go with C because they *have* to have a vendor for this solution and, besides, nobody ever got fired for buying C, right?
Not only do I know of guys who got fired for buying C, I also know people that left companies after they bought C because they knew what was coming next.
Yep - I'd be fired or quit and find a job elsewhere. Frankly, I don't put up with that crap and am completely confident I can find employment elsewhere that values me as an employee.
EDIT - Isn't this easily addressed though by requesting/demanding to be part of any conversations that involve infrastructure, since you're the one in charge/has to maintain/is the throat that gets choked when it breaks? I mean, that's completely reasonable, right? That way when they try to sling FUD you can address it right on the spot?
Quote from: AspiringNetworker on May 04, 2017, 10:54:13 AM
Isn't this easily addressed though by requesting/demanding to be part of any conversations that involve infrastructure, since you're the one in charge/has to maintain/is the throat that gets choked when it breaks? I mean, that's completely reasonable, right? That way when they try to sling FUD you can address it right on the spot?
Your thoughts are completely reasonable. The problem in a lot of orgs (both private and public) is that business culture and politics drive a lot of these big "we choose vendor X" decisions, and unless you are willing to drive culture and play politics you could be left out of the decision. It's a lot to take on for sr. engineers that might want to avoid such things. It's also a great way to get a potentially unwanted promotion into leadership/management, haha. Throw in public sector RFP requirements and it's a whole other can of worms. That said, I would venture that the relationship between the sr. engineers and their manager/CTO/CIO is the crux of the matter. If there is trust and respect there, then it's probably a non-issue, but if there is no trust...
@ AspiringNetworker
Oh the number of times I have faced any of the following or similar.
- CEO sat next to another CEO in 1st one trip. Determined we will now deploy $new_hotness from $vendor. "Signing contract today"
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
- Submitted network design/BOM/PO rejected. Leadership and procurement rejected due to "$crappySwitchCo undercut bit" and this is what was purchased. "Can you have it deployed in 2 weeks?"
Its sad but I see more times project design goes as far as what switches to purchase before cutting a PO. Rest can be figured out after we get them in.
I'm still waiting for maintenance to be activated on some gear we bought almost 3 years ago so that I can use it before the 3 year maintenance contract is up.
We had to do a complete re-architecture of one project because of the haggling between our purchasing guys and the vendors. They liked how virtual stuff, being software, came under the OPEX budget instead of CAPEX and that we could get deeper discounts on software than hardware. Out went the physical, distributed solution and in came the virtual, centralized solution.
Just a few weeks ago, we had an architecture review and the manager worked up a recommendation to start getting some physical devices to push out into our sites that don't have a big virtual presence. I'll be happy to go back to the physical, distributed solution, but I'm not going to hold my breath.
Quote from: that1guy15 on May 04, 2017, 12:37:53 PM
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
Oh yeah, these "surprises" are always fun. We have had vendors just show up in IT/data center with network appliances or equipment asking where to rack and stack. I have also seen departments or project teams completely bid out entire network solutions including all switching without ever even thinking of talking to IT ops. "Just make it work - contract is already signed". This is usually due to a lack of org governance or leadership/turf wars.
Quote from: that1guy15 on May 04, 2017, 12:37:53 PM
@ AspiringNetworker
Oh the number of times I have faced any of the following or similar.
- CEO sat next to another CEO in 1st one trip. Determined we will now deploy $new_hotness from $vendor. "Signing contract today"
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
- Submitted network design/BOM/PO rejected. Leadership and procurement rejected due to "$crappySwitchCo undercut bit" and this is what was purchased. "Can you have it deployed in 2 weeks?"
Its sad but I see more times project design goes as far as what switches to purchase before cutting a PO. Rest can be figured out after we get them in.
So honest question - do you ever push back with justification? Again - I don't think I'd last in that world. Better I stay on this side of the fence. xD
Push back with justification? If I'm lucky, this will be the higher-up's reaction:
:haha1:
Meanwhile, my fellow engineers are all like
:kramer:
DON'T DO IT MAN, THINK OF THE CHILDREN!!!
***
Back to the physical that went almost 100% virtual... the position was clear. If I wanted vendor $$$ over vendor Cheapo, then the ONLY way we'd get vendor $$$ in would be if we got their deep discounts on virtual gear, full stop, end of story. If I dug my heels in on the physical solution, it would be goodbye vendor $$$ and hello vendor Cheapo and a serious career decision for me, because I did NOT want to work with vendor Cheapo's stuff at all. I had tested it and it was a failure. We needed the $$$ stuff, but no way would our accountants pay for the hardware when the virtual stuff was so much less.
That's about the time I put "Accounting is architecture, remember that!" in my sig, I believe. Because we re-did everything in the middle of those negotiations. We got vendor $$$, but only just.
There's still talk about ripping out vendor $$$ and going with Cheapo... I did push back on insisting on $$$, but got pushed right back from above to make a big change to get that vendor over Cheapo.
I believe part of it has to be a stand we have to take so that we don't get a rep as a firm that just cuts a check for expensive stuff without a second thought. We've got a Wal-Mart type of attitude, where we know we'll drive down the purchase cost, but the vendor will make up for it on volume.
But accounting is architecture, remember that!
Quote from: AspiringNetworker on May 04, 2017, 04:01:20 PM
Quote from: that1guy15 on May 04, 2017, 12:37:53 PM
@ AspiringNetworker
Oh the number of times I have faced any of the following or similar.
- CEO sat next to another CEO in 1st one trip. Determined we will now deploy $new_hotness from $vendor. "Signing contract today"
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
- Submitted network design/BOM/PO rejected. Leadership and procurement rejected due to "$crappySwitchCo undercut bit" and this is what was purchased. "Can you have it deployed in 2 weeks?"
Its sad but I see more times project design goes as far as what switches to purchase before cutting a PO. Rest can be figured out after we get them in.
So honest question - do you ever push back with justification? Again - I don't think I'd last in that world. Better I stay on this side of the fence. xD
Yes, Ive always been sure to let those directly above me know when crap like this is not OK. Now whether they listen or not is something else.
With crap like this happening these jobs were quite easy to quit and sure as hell stuff like this gets brought up in exit interviews. Stuff like this is how you run off your talent. But then again Im sure they dont care.
Sometimes though you just have to play the game and focus on what you can control. You getting to do exactly what you want in your job is not always the only deciding factor in staying or leaving. There are many others that could come into play for anybody.
yeah just don't play the game at all. #consultantlyfe
I'm external as well so if the client insists on doing the wrong thing, go right ahead, we're gonna caveat our position then bill you anyway, and at the end of it we walk away whilst you're the ones who have to live with the consequences. Doesn't tend to happen as we position ourselves to come in right at the start so we can usually stop anything too outlandish via simply pointing to the requirements (that we drag the customer into going over for this very reason). But that's a luxury sometimes, esp. when people want to do it proposal/RFP style instead of consulting style, and esp. when mega-corps and mega-vendors are involved with their implicit nudge nudge wink wink pre-determined outcomes.
Quote from: that1guy15 on May 04, 2017, 12:37:53 PM
@ AspiringNetworker
Oh the number of times I have faced any of the following or similar.
- CEO sat next to another CEO in 1st one trip. Determined we will now deploy $new_hotness from $vendor. "Signing contract today"
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
- Submitted network design/BOM/PO rejected. Leadership and procurement rejected due to "$crappySwitchCo undercut bit" and this is what was purchased. "Can you have it deployed in 2 weeks?"
Its sad but I see more times project design goes as far as what switches to purchase before cutting a PO. Rest can be figured out after we get them in.
C:-) C:-) C:-) C:-) C:-) C:-) C:-) C:-)
Quote from: wintermute000 on May 04, 2017, 11:54:33 PM
yeah just don't play the game at all. #consultantlyfe
I'm external as well so if the client insists on doing the wrong thing, go right ahead, we're gonna caveat our position then bill you anyway, and at the end of it we walk away whilst you're the ones who have to live with the consequences. Doesn't tend to happen as we position ourselves to come in right at the start so we can usually stop anything too outlandish via simply pointing to the requirements (that we drag the customer into going over for this very reason). But that's a luxury sometimes, esp. when people want to do it proposal/RFP style instead of consulting style, and esp. when mega-corps and mega-vendors are involved with their implicit nudge nudge wink wink pre-determined outcomes.
Ugh - yes! That comment about proposal/RFP instead of consulting... man! "Give me what your solution is lined up against this Vendor XYZ BoM and no other info - I wanna see pricing." - this drives me INSANE.
That proposal/RFP method is primarily asking for the other party to act as a staffing agency, not as a value-adding consultant. Basically, it's, "We need 15 level 1 guys, 9 level 2 guys, 3 level 3, one level 4, and two service managers. Level 1-2 guys should all be CCNAs familiar with Riverbed and the 3/4 guys need to be certified by the vendor. Also CCIEs. How much will that cost us and how soon will you have them delivered?"
I hate, really hate, stuff like that. Either hire real consultants to do the job or real people to work for your firm. Don't go through some staffing solution crap to fill personnel reqs while keeping payroll low.
Hmmm - think I misunderstood what was said here.
Quote from: that1guy15 on May 04, 2017, 10:18:26 PM
Quote from: AspiringNetworker on May 04, 2017, 04:01:20 PM
Quote from: that1guy15 on May 04, 2017, 12:37:53 PM
@ AspiringNetworker
Oh the number of times I have faced any of the following or similar.
- CEO sat next to another CEO in 1st one trip. Determined we will now deploy $new_hotness from $vendor. "Signing contract today"
- Apps team with large project budget purchases network with consultants to deploy EVERYTHING. Its next week. "Hey That1guy you got a couple min to talk through how this will connect?"
- Submitted network design/BOM/PO rejected. Leadership and procurement rejected due to "$crappySwitchCo undercut bit" and this is what was purchased. "Can you have it deployed in 2 weeks?"
Its sad but I see more times project design goes as far as what switches to purchase before cutting a PO. Rest can be figured out after we get them in.
So honest question - do you ever push back with justification? Again - I don't think I'd last in that world. Better I stay on this side of the fence. xD
Yes, Ive always been sure to let those directly above me know when crap like this is not OK. Now whether they listen or not is something else.
With crap like this happening these jobs were quite easy to quit and sure as hell stuff like this gets brought up in exit interviews. Stuff like this is how you run off your talent. But then again Im sure they dont care.
Sometimes though you just have to play the game and focus on what you can control. You getting to do exactly what you want in your job is not always the only deciding factor in staying or leaving. There are many others that could come into play for anybody.
Fair.
Quote from: deanwebb on May 04, 2017, 06:55:17 PM
Push back with justification? If I'm lucky, this will be the higher-up's reaction:
:haha1:
Meanwhile, my fellow engineers are all like
:kramer:
DON'T DO IT MAN, THINK OF THE CHILDREN!!!
***
Back to the physical that went almost 100% virtual... the position was clear. If I wanted vendor $$$ over vendor Cheapo, then the ONLY way we'd get vendor $$$ in would be if we got their deep discounts on virtual gear, full stop, end of story. If I dug my heels in on the physical solution, it would be goodbye vendor $$$ and hello vendor Cheapo and a serious career decision for me, because I did NOT want to work with vendor Cheapo's stuff at all. I had tested it and it was a failure. We needed the $$$ stuff, but no way would our accountants pay for the hardware when the virtual stuff was so much less.
That's about the time I put "Accounting is architecture, remember that!" in my sig, I believe. Because we re-did everything in the middle of those negotiations. We got vendor $$$, but only just.
There's still talk about ripping out vendor $$$ and going with Cheapo... I did push back on insisting on $$$, but got pushed right back from above to make a big change to get that vendor over Cheapo.
I believe part of it has to be a stand we have to take so that we don't get a rep as a firm that just cuts a check for expensive stuff without a second thought. We've got a Wal-Mart type of attitude, where we know we'll drive down the purchase cost, but the vendor will make up for it on volume.
But accounting is architecture, remember that!
Haha just revisited this thread and saw this - made me chuckle
Quote from: AspiringNetworker on May 15, 2017, 12:50:37 PM
Haha just revisited this thread and saw this - made me chuckle
Mission accomplished.
:smug: