Uncle John Stands Back, At Last.

The post Finally, a post-Chambers Cisco appeared first on EtherealMind.

One of the perks of my online courses is the lifetime access to course Slack team, and you’d amazed by the variety of questions asked there. Not so long ago I got one on BGP timers:

The BGP timers I’m using in my network are 5 and 15 seconds, and I am not sure if it's a good practice to reduce them even more.

You should always ask yourself this set of questions before tweaking a nerd knob:

Read more ...

Amanuensis is the process of copy pasta

The post Dictionary : amanuensis appeared first on EtherealMind.

You might have noticed the “upcoming webinars” blog widget is gone and I’ll write a blog post every two weeks or so to keep you updated on upcoming webinars and other events.

Here’s what’s coming in September and October 2017:

• Does Docker (and containers) make sense with Cumulus Networks on September 21st in Zurich;
• Docker workshop on September 21st in Zurich;
• DevOps and Security for Enterprise Environments on September 28th;
• Second part of Network Visibility with Flow Data webinar on October 5th;
• Network automation workshop in Rome on October 18th.

So you want to work for Google as Network Engineer? Check out one of the job ads here. I pasted the screenshot below just in case the ad is removed once the position is no longer available.

"You'll build software for distributed services, abstractions and the components of the system that operates and powers Google." OK, even this is not common in Network Engineer job description, it makes sense since Google is running one of the world's largest networks to connect its data centers that are scattered all around world. As minimum requirement, you must have experience in software development in one or more modern programming languages e.g. C++, Java, Python, Go, etc. And learn how to code using "Teach yourself Python in 24 hours" won't be enough since it is expected for you to have experience in data structures, complexity analysis and software design.

Is Google really looking for Network Engineer (NE), and not Software Engineer (SWE)? Yup, you still need to have expertise in networking protocols and technologies, including end-to-end packet flow, forwarding and routing. Google knows that a world class distributed computing infrastructure must run on world class networking infrastructure that is operated reliably and at scale. When network capacity in the company's data centers has grown so fast that conventional routers and switches can't keep up, Google could not buy, for any price, a data-center network that would meet the requirements of its distributed systems. So the engineers decided to build its own instead.

And someone like me who relies on 3 CCIEs and CCDE only won't be qualified to apply. Before you ask if it is still needed to pursue certification or not, let me say it again: you still need in-depth networking knowledge. You still need to know OSPF, ISIS, and BGP in details. And you may use that kind of certification to build the expertise. But don't turn into certification junkies just like a younger me once! Especially if your target is to only pass the exam, it won't get you to Google for sure. Once you understand network engineering, learn software engineering and how to design, analyze and troubleshoot large-scale distributed systems. In this company, and similar companies that build and maintain large-scale networking like Facebook, Amazon and others, Network Engineer is expected to write software and tools that interact with networking systems, to support Software Defined Networking, zero touch networking, to automate network operations, and to develop advanced monitoring systems.
  
Google is definitely looking for someone who is at minimum already in Phase 5 as per my Network Engineer evolution, that will progress to Phase 6 someday. And during my past 440 days in Google, I'm so lucky to be surrounded by these guys.

Getting bored sitting at San Jose airport waiting for Vagrant to update guest additions in my Ubuntu VM (first item on my to-do list: prepare final version of material for next week’s Docker workshop), so here are my very first impressions of Networking Field Day 16 presentations we’ve seen in the last three days.

As always, there were great presentations, good presentations, … and a few that are best forgotten. I won’t mention those.

Read more ...

We discussed LAG (Link Aggregation Group) and the ECMP (Equal Cost Multipath) on real network deployments with the Service Provider/Telco Engineer engineers on my slack group.   I thought it was good discussion so you can see what others are doing and the reasons of their deployments.    In this talk, three people involved. Myself […]

The post LAG vs. ECMP discussion on real network deployments appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

Long story short: I’m offering a few free seats in my Ansible for Networking Engineers online course to undergraduate or master’s students.

Interested? Check out the details, and apply before October 1^st.

Too old? Please spread the word ;)

You might have seen this Register article this week which summarized a Future:Net talk from Peyton Koran. In the article and the talk, Peyton talks about how the network vendor and reseller market has trapped organizations into a needless cycle of bad hardware and buggy software. He suggests that organizations should focus on their new “core competency” of software development and run whitebox or merchant hardware on top of open source networking stacks. He says that developers can use code that has a lot of community contributions and shares useful functionality. It’s a high and mighty goal. However, I think the open source part of the equation is going to cause some issues.

A Penny For Your Thoughts

The idea behind open source isn’t that hard to comprehend. Everything available to see and build. Anyone can contribute and give back to the project and make the world a better place. At least, that’s the theory. Reality is sometimes a bit different.

Many times, I’ve had off-the-record conversations with organizations that are consuming open source resources and projects as a starting point for building something that will end up containing many proprietary resources. When I ask them about contributing back to those projects or finding ways to advance things, the response are usually silence. Very rarely, I hear that the organization sees their proprietary developments as a “competitive advantage” that they are going to use to either beat a competitor or build a product that saves them a significant amount of money.

The analogy I like to use for open source is the “Take A Penny” dish that many businesses have next to their cash register. The idea is that people can contribute something small to help out others. If someone needs a penny or two to help make payment for a good or service, they can take one. If they have a few left over they can give back. It’s a way to give back a little now and then.

However, there are a couple of types of people that skew the trend for the penny dish. The first is the person that gives back much more than the norm. That person might put a quarter in the dish or put in four or five pennies at every dish they find. They contribute above the norm often and give a lot. The second type of person takes quite a few pennies from the dish and never gives back. They may see the dish as “free money” to be used to augment their own. They don’t care if all the pennies are gone when they finish just as long as they got what they needed out of it.

Extend this metaphor into the open source community. There are quite a few contributors that put in significant time and effort in their projects. They may have found a way to do it full time or may be paid by their company to participate in projects. These folks are dedicated to the cause.

On the other side of the metaphor are the people and organizations that take what they want from open source and never give back. They never contribute to the project, even if their enhancements are needed and welcome. They take a free or inexpensive starting point and use it to build a product that could be used internally to give the organization an advantage. The key here is that it’s something used internally. The GPL covers distribution of software that is based on GPL code, but it’s not really clear about what happens if that software is consumed internally. An enterprising developer may say to themselves, “As long as I don’t sell it, I don’t have to give my code back.”

Networking For Pocket Change

There are quite a few open source networking projects out there. Quagga, BiRD, and Open vSwitch are great examples of projects that have significant reach and are used by a lot of companies to build great products. However, imagine what would happen if no one gave back to these projects. Imagine what would happen if contributors decided to make their own BGP daemons or OVS-like program and use it without regard for helping others in the community.

Open source software needs developers willing to contribute back to the project. If networking is going to embrace open source projects as Peyton suggested in his talk, it’s going to take a lot more contribution than quiet consumption. Whether or not you agree with the premise that networking vendors are corrupt and evil you do have to concede that they’ve given us mostly stable protocols like BGP and OSPF. These same vendors have contributed ideas back to the standardization process to improve protocols like spanning tree and power over Ethernet. Their contributions helped shape what networking is today.

If the next generation of software based network developers wants to embrace and extend these contributions with open source, they’re going to need to be transparent and communicate with the project leads. They’re also going to need to push back when someone high up the food chain sees the development process as a way to gain an advantage and try and keep it all secretive. If developers aren’t going to give back to the community it negates the advantages of open source and instead takes us back to the days of networks being one-off creations that have no interoperability beyond a few protocols. Islands in a sea of home-grown lava.

---

Tom’s Take

As anyone that attended Future:Net within earshot of me can attest, I wasn’t overly thrilled with Peyton’s take on the future of networking. I have some deep seeded reservations about the “screw the vendors, build it all yourself” mentality that is pervading organizations today. Not everyone is a development shop. Law firms and schools don’t employ software engineers regularly. If you want to transform those types of users into open source adherents, you need to lead the pack by giving back and talking about what your doing with open source. If you’re not willing to lead the way, stop telling people to take the fork in the road.

In June 2017, we concluded the Building Next Generation Data Center online course with a roundtable discussion with Andrew Lerner, Research Vice President, Networking, and Simon Richard, Research Director, Data Center Networking @ Gartner.

During the first 45 minutes, we covered a lot of topics including:

Read more ...

PowerShell is a great scripting environment if your vendor provided PowerShell libraries to control their software or devices… but what if all you got is REST API (example: Nexus switches)?

We’ll conveniently ignore the challenges of managing devices that use 30-year-old non-scriptable CLI.

Read more ...

A month ago I told you how dr. Olivier Bonaventure starts his networking course with IPv6. But there’s more: the full textbook for the undergraduate course (Computer Networking: Principles, Protocols and Practice) is open-sourced and available (in source form) on GitHub.

You might wonder why I’m so enthusiastic, so let me tell you another story…

Read more ...

What does P router mean in MPLS ? It is used in MPLS VPN networks mostly but can be used with any MPLS application, use case.     This is very important node in MPLS, and crucial to understand MPLS.   MPLS is one of the most commonly used encapsulation mechanism in Service Provider networks […]

The post What does P router mean in MPLS ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

The featured webinar in September 2017 is the Ansible for Networking Engineers webinar, and in the featured videos you'll learn what Jinja2 is and how you can use it to generate network device configurations with Ansible.

If you already have an trial subscription, log into my.ipspace.net, select the Ansible webinar from the first page, and watch the videos marked with star. To start your trial subscription, register here.

Read more ...

Today’s enterprise is complex with digital operations and data located in the cloud, at headquarters and on remote sites. Coupled with business need for always-on working and application reliability and it’s not surprising that teams often struggle under the weight of their work.

4 Main, Key Design Principles of Mobile Networks – I will explain the 4 key design principles of cellular networks in plain English.   In fact I should have said, cell based systems as mobile networks may not be design based on cell based architecture.   Let me explain what would be the other deployment […]

The post 4 Main Design Principles of Mobile Networks appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

I got several questions along the lines of “why is Cisco pushing LISP instead of using EVPN in VXLAN-based Enterprise campus solutions?”

Honestly, I’m wondering that myself (and maybe I’ll get the answer in a few days @ NFD16). However, let’s start at the very beginning…

Read more ...

You might have noticed that my blog looks a bit different than it did a few hours ago thanks to fantastic work by Nils & Mathias from Strandrover.Agency (and a bit of homegrown blogger template hacking). We tested all functionality we could think of, if we missed something, please write a comment (they still work ;).

When reporting a problem, please tell me what browser (and browser version) you're using and whether you're using a web proxy (like Cisco Web Security Appliance).

I discussed the BGP Router Reflector design, Settlement Free Peering , Transit Operator choice, Internet Gateways and the Route Reflector connections, MPLS deployment option at the Internet Edge and many other things with the Operator from Maldives. Operator name is Dhiraagu. Autonomous System Number is 7642.   Engineer from the ISP Core team, who is […]

The post Discussion with Maldivian Operator Dhiraagu (AS7642) appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

One of the many takeaways I got from Future:Net last week was the desire for networks to do more. The presenters were talking about their hypothesized networks being able to make intelligent decisions based on intent and other factors. I say “hypothesized” because almost everyone admitted that we aren’t quite there. Yet. But the more I thought about it, the more I realized that perhaps the timeline for these mythical networks is a bit skewed in favor of refresh cycles that are shorter than we expect.

Software Eats The World

SDN has changed the way we look at things. Yes, it’s a lot of hype. Yes, it’s an overloaded term. But it’s also the promise of getting devices to do much more than we had ever dreamed. It’s about automation and programmability and, now, deriving intent from plain language. It’s everything we could ever want a simple box of ASICs to do for us and more.

But why are we asking so much? Why do we now believe that the network is capable of so much more than it was just five years ago? Is it because we’ve developed a revolutionary new method for making chips that are ten times smarter and a hundred times faster? No. In fact, the opposite is true. Chips are a little faster and a little cheaper, but they aren’t custom construction. Most companies are embracing merchant silicon from companies like Broadcom and Mellanox. So, where’s all this functionality coming from?

Its’ the “S” in SDN. We’re seeing software driving this development. Yes, it’s the same thing we’ve been saying for years now. But it’s something more now. Admins and engineers aren’t just excited that network devices are more software now. They’re expecting it. They’re looking to the software to drive the development. Gone are the days of CLI-only access. Now, the interfaces are practically built on API-driven capabilities. The Aruba 8400 seems like it was built for the API first, with the GUI being a superset of API functions. People getting into the networking world are focusing on things like Python first and CLI syntax second. Software is winning again.

It’s like the iPhone revolution. The hardware is completely divorced from the software. I can upgrade to the latest version of Apple’s iOS and get most of the functionality I want in the OS. Aside from some hardware specific things the majority of the functions work no matter what. Every year, I get new toys to play with. Every 12 months I can enable new functions and have new avenues available to me. If you think back to the first iterations of the iPhone ten years ago, you can see how far software development has driven this device.

Hardware For The Long Haul

However, for all the grandeur and amazement that iPhone (and Android for that matter) show, it’s also created a side effect that is causing even more problems in the mobile device world that is bleeding over into other electronics. That is the rapid replacement cycle. I mentioned above how awesome it is that you can get new functions every year in your mobile device. But I didn’t mention how people are already looking forward to the newest hardware even though they may have purchased a new phone just 10 months ago.

The desire to get faster by leaps and bounds every year is almost comical at this point. When the new device is delivered an it’s just a bit faster than the last, people are disappointed. Even I was guilty of this when I moved from a 2013 MacBook to a 2016 model. It was only 20% faster. Even with everything else I got in the new package, I found myself chasing performance over every other feature.

The desire to get better performance isn’t just limited to phones and tablets and laptops. When network designers look to increase network performance, they want to do so in a way that makes their users happy. Gone are the days when a simple gigabit network connection would keep someone pleased. We now have to develop gigabit wireless connections to the backbone network, where data is passed to servers connected by 25Gig connections to spines and super spines running at 100Gig (for now). In some cases, that data doesn’t even move any more, and instead short-lived containers are spun up next to it to make things run faster.

Networks aren’t designed like iPhones. They aren’t built to be ripped out every year and replaced with something a little faster and a little shinier. They’re designed more like cars in that regard. They are large purchases that should last for years upon years, with their performance profile dictated by the design at the time. We’ve gone through the phases of running 10Mbit hubs. We upgraded to FastEthernet. We’re now living in a cycle where Gigabit and 10/40 Gigabit switches are ruling the roost. Some of the more forward-thinking folks are adopting 25/50Gigabit and even looking to faster technologies like 400Gig connections for spines.

However, the longevity of hardware remains. Capital expenditure isn’t the easiest thing in the world to accomplish. You need to budget for new devices in the networking world. You need to justify cost savings or new applications. You can’t just buy a fast new switch or two every year and claim that it makes everything better without some kind of justification. Even if you move to the cloud with your strategy, you’re not changing the purchasing model. You’re just trading capital expenditure to operational expenditure. You’re leasing a car instead of buying it. Because if you leave the cloud, you’re back to your old switching model with nothing to show for it.

---

Tom’s Take

I was pretty hard on the Future:Net presenters because I felt that their talk of ditching money grubbing vendors for the purity of whitebox switching running open source software was a bit heavy handed. Most organizations are in the middle of a refresh cycle and can’t afford to rip everything out and replace it today. Moreover, the value in whitebox switching isn’t realized when you install new hardware. It’s realized when you turn your switch into an iPhone. Where software development rules the day and your hardware fades away in the background. We’re not there yet. We’re still buying hardware for the sake of hardware as the software is catching up. Networking equipment is still built and bought like a car and will be for a few years to come. Maybe we can revisit this topic in 3 years and see how far software will have driven us by then.

VMware started talking about VMware Cloud on AWS a while ago, and my first response was “yeah, it’s just vCloud Air but they wanted to get rid of CapEx, so it’s running on someone else’s servers”

Last week Frank Denneman published a technical overview of the solution and I was mostly correct.

Read more ...

Data is bucking the trend that suggests all things eventually become a simple commodity. We’ve all spent years just seeing data as ‘there’; whether it’s a spreadsheet, email or information on a website/social media – data just exists. However, with recent, and massive, growth in stored data its value throughout its lifetime has now changed.

 

What do I mean by this?

My little , sweet baby girl has just born. This is happiness and I feel totally different now. I am a father of two now 🙂 She says hello to all networking community and father’s friends 🙂  

The post What is happiness ? Let me show you ! appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

Wireless ISPs also known as WISP mostly use unlicensed frequency spectrum. Frequency spectrum is the most critical asset for the Mobile and Wireless networks and it is sold in auctions for 100s of millions of dollars.   Frequency spectrum is managed by the governments and governments in general, sell frequency spectrum in auctions.   And […]

The post Wireless ISPs Spectrum Problem appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

Plenty of new stuff was added to the Ansible for Networking Engineers online course and webinar since the last update.

Fun things first: I needed adjustable check mode behavior and change tracking in some playbooks, and documented these features in two new videos (online course and webinar).

Read more ...

The latest in all the networking buzz these days is Intent-Based Networking (IBN). There are varying definitions of what IBN is and is not. Does IBN mean you need to deploy networking solely from business policy, does IBN mean you must be streaming telemetry from every network device in real-time, is it a combination of both? Is it automation?

This article isn’t meant to define IBN, rather, it’s meant to provide a broader, yet more practical perspective on automation and intent.

Intent isn’t New

One could argue that intent-based systems have been around for years, especially when managing servers. Why not look at DevOps tools like CFEngine, Chef, and Puppet (being three of the first)? They focused on desired state–their goal was to get managed systems into a technical desired state.

If something is in its desired state, doesn’t that mean it’s in its intended state?

These tools did this eliminating the need to know the specific Linux server commands to configure the device–you simply defined your desired state with a declarative approach to systems management, e.g. ensure Bob is configured on the system without worrying about the command to add Bob. One major difference was those tools used the term “declarative” and not “intent-based” when it comes to industry terms and hype. That said, it’s actually quite a solid approach to systems management.

Using DevOps Tools for Networking

Using a declarative approach for systems management was solid enough that eventually these tools were extended to manage network devices. The only caveat was the companies that developed these tools never employed anyone focused on network integrations. Then along came Ansible–they were the same in that they employed no one that developed network integrations (circa 2014-15). There was a major difference between Puppet/Chef and Ansible though. It was that Ansible was dead simple and the network community drove the initial Ansible <–> network device integrations. Even vendors like Juniper and Arista wrote their own modules. Finally, Ansible made investments and continues to do so, and now has a full team dedicated to networking.

Since I mentioned all other popular “configuration management” tools, there is even the newest of these tools: Salt by SaltStack, that has a growing interest in the community to be used for network automation.

Intent-Based Network Automation with Ansible

Let’s get back to Ansible. Ansible is interesting because it’s often debated if it’s imperative or declarative. This partially goes back to defining something as intent-driven or not. More on this later though.

Major point: certain tools are not tools–they are mere platforms that you can build on. This is how I see Ansible. If you look at a single task (in Ansible terminology) today, you may in theory be using CLI commands or making specific API calls. What’s great about this is that you know 100% what is being sent to the device. What’s not so great about this? It may not be considered intent-based by industry pundits. However, platforms like Ansible have building blocks.

Within Ansible, there are modules, tasks, plays, and roles that allow you to build your own abstractions that perform how you need them to fit your environment. This means you can write an Ansible playbook to automate your network that enforces your precise intent. Of course, if you look inside the playbook, you may see some imperative tasks, but who cares? This is why there are platform architects (who build robust playbooks) and users of the system (who execute the playbooks).

You should be able to define your desired state according to your Enterprise standards.

Using CLI Commands to Drive Intent

All we do at Network to Code is network automation. If all we had was something that could be used for greenfield deployments or that only worked in the WAN, Campus, or DC, we wouldn’t exist as a services company. Our major selling point is that we make network automation consumable and something that can be adopted and deployed in a gradual, yet effective, fashion across a wide variety of network types. This means using CLI commands to even drive intent–let’s face it, it’s the world we live in.

If there is any solution categorized as Intent-Based Networking (open source of commercial), I guarantee you it’s using CLI commands if it’s managing devices such as Cisco Nexus, IOS, or Arista EOS. All this means is that the solution built more logic on top to enforce intent, perform real-time checks, and allows you to see and mange this with a slick UI.

Network Intent with NAPALM

This post wouldn’t be complete without mention of NAPALM. NAPALM at its core is a Python library that was built to offer a uniform way (in Python) to manage network device configurations. While this isn’t meant to be a primer on NAPALM, there is a way to declaratively manage full device configurations with NAPALM. This means if your desire is to have a particular running configuration on the device, you can use NAPALM to do so. The subtle, but major difference here to traditional automation, is you do not have to issue any “no” or “delete” commands to do this.

You literally focus on what your intent is with CLI commands, which in my opinion isn’t a bad thing because CLI devices is what’s mostly deployed today in production environments (forget about what transport is used - CLI over API or CLI over SSH…it’s still being used). Looking back, NAPALM was arguably the first networking library that offered intent (but uses declarative in their terminology just as the initial DevOps tools did). Again, the real value here is that NAPALM is a collection of device drivers, so why not build atop NAPALM. In fact, any commercial tool is using something equivalent like NAPALM to manage device configurations.

Using Ansible and NAPALM

Because Ansible was extensible, there were NAPALM modules written pretty early on, pre-dating any network module in core today. We could go onto say that Ansible has been doing IBN for over several years now! In either case, systems have building blocks. These days you can use native modules in Ansible core (much more of this coming with Ansible 2.4), or NAPALM modules with Ansible to write pretty robust playbooks–each playbook could do something like manage a configuration of device with intent in mind or something that makes adoption easier, managing each feature with intent in mind!

You shouldn’t have to change your Enterprise standards to adopt automation.

From Automating Configurations to Automating Intent

This brings me to another point and question not often talked about when it comes to automation, configuration drift, intent, and declarative configuration management.

If you’re managing network devices, what is the source of truth (SOT)? Where are the desired (or intended, if we want to use current terminology) configuration inputs held? Is it in a custom database? IPAM solution? YAML files? Any answer is better than, “it’s the network device and that’s the only thing we trust!” However, after you consider where the SOT is and where you want it to be, you have to ask yourself, what about “additional configurations” that are on the device after you’ve automated your desired configuration?

• What if you desire 5 BGP neighbors and those 5 exist, but there are also 2 others?
• What if you need 10 VLANs on each switch, but there is also an additional 2-3 on each switch?
• What about SNMP community strings? Do all of your SNMP tools work, but you still see the aging comm strings for the past 20 years that you’re afraid to delete?

We can ask these types of questions for every feature on a network device. This is why there is actually a major difference with what we refer to as basic network automation (ensure your desired configuration exists) and fully declarative intent-based management per feature or per device (ensure your intended and desired configuration exists and remove all other configurations not in your SOT).

Using Ansible as a Platform

If you treat Ansible as a platform, you get all of this today. It’s up to you to choose what level of abstraction is right for your organization and the users of the platform. For example, we at Network to Code have been hard at work deploying solutions like this leveraging Ansible as a platform. We’ve deployed Ansible Tower (self-service via Tower Surveys) on top of Ansible if that meets customer requirements, and we’ve developed custom integrations (including front-ends) that are more network centric that sit above Ansible (or Tower).

Note: the alternative is to use Ansible as a power tool and not as a platform, in which there is still great value, but it’s then just automating CLI commands faster than you.

Realize there is a difference using something as a platform or a tool.

Tabling Operational State

This post didn’t cover operational state as that’s a bit more complex to enforce and then you get into event-driven and auto-remediation systems, but in all of these tools and platforms, you have the ability to collect any information from the device (config or operational state), and then based on that data, work through your logic and intent-based deployment.

Let’s Meet at AnsibleFest SF 2017

A few of us from the NTC team are at AnsibleFest in SF tomorrow, September 7. If you’re interested in hearing more about our model-driven intent-based network automation services and solutions with Ansible, feel free to stop by our booth!

Network Automation with Python & Ansible Training

In the spirit of AnsibleFest, NTC is offering 50% off any of our public training courses until 9/15. Just email info@networktocode asking for your promo code.

Happy Automating!

-Jason (@jedelman8)

Security threats continue to increase exponentially in volume and in risk. According to a recent CBR article, cybercrime is expected to cost the world more than $2 trillion by 2019. Developers are creating more applications more frequently and many are migrating them between different clouds for business agility. But, the greater volume and dynamic nature of applications make businesses more vulnerable. In fact, Microsoft predicts that we will be writing 111 billion lines of new software code every year that will generate 50 times more data volume by 2020. This should give you an idea of the increased threat attack surface in a multi-cloud world. 

It all started with a realistic response I got to my automation and orchestration blog post (here’s a unicorn-driving-a-DeLorean one in case you missed it):

Maybe you could also add the "intent-based network" which is also not so far from orchestration?

It got me thinking. The way I understand intent-based whatever, it’s an approach where I tell a system what I want it to do, not how to do it.

Read more ...

Istanbul/Turkey Onsite CCDE Training will be held between October 30 – November 4.   Course will be in English as usual, everyday will be between 9am – 6pm, 9 hours.   I am going to extend my CCDE Materials for this course as there was new scenarios and the technologies after August 29, 2017 CCDE […]

The post Istanbul/Turkey Onsite CCDE Training – 50% OFF until Sep-15, 2017 appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

What is Blame Theater ?

The post Dictionary: Blame THeater appeared first on EtherealMind.

There are two reasonable ways of building a layer-2 leaf-and-spine fabric: use VXLAN (the direction almost everyone in the industry is taking at the moment), or routing-on-layer-2 technology like TRILL or SPB.

Read more ...

Maybe nothing ?

The post Response: What Drives Change in Enterprise IT – Jeremy Filliben appeared first on EtherealMind.

I’m at Future:NET this week and there’s a lot of talk about the future of what networking is going to look like from the perspective of vendors like Apstra, Veriflow, and Forward Networks. There’s also a great deal of discussion from customers and end users as well. One of the things that I think is being missed in all the talk about resources.

Time Is Not On Your Side

Many of the presenters, like Truman Boyes of Bloomberg and Peyton Maynard-Koran of EA, discussed the idea of building boxes from existing components instead of buying them from established networking vendors like Cisco and Arista. The argument does hold some valid ideas. If you can get your hardware from someone like EdgeCore or Accton and get your software from someone else like Pluribus Networks or Pica8 it looks like a slam dunk. You get 90% to 95% of a solution that you could get from Cisco with much less cost to you overall.

Companies like Facebook and Google have really pioneered this solution. Facebook’s OCP movement is really helping networking professionals understand the development that goes into building their own switches. Facebook’s commitment is also helping reduce the price of the components when an eager person wants to go build an OCP switch from parts they find at Radio Shack or from Amazon.

But, for Facebook, the development of a switch like this or the development of a platform is a sunk cost. Because the important resource to Facebook isn’t time. Facebook has teams of engineers sitting around developing things. For them, the time the least important resource. Time is something they have in abundance. Why is that? Because their development is entirely focused on their product. Google can afford to have 500 people working on a product with an IT focus like Google Reader or Google Wave because that’s what Google hires people to do.

Contrast that with the typical IT department at an enterprise. Even with thousands of users in Marketing, Management, and Finance there are usually only a handful of IT professionals. And those people have to cover storage, compute, networking, wireless, and software. The focus of the average law firm is not using IT resources to create a product. The focus of the business is leveraging IT to provide a service. A finance firm doesn’t have the time resources to commit to developing in-house solutions or creating IT hardware from components and freely available software.

Money, Money, Money.

Let’s look at the other side of the coin. Facebook and Google have oodles and oodles of time to build and develop things. They can get their developers to work together to build the hardware and software to integrate at a deep level. And because they understand it at that level, they can easily debug it instead of asking someone to solve their problem. What Facebook and Google don’t have is money.

To large firms like these, money is more important than time. When you have to purchase networking or storage equipment by the thousands or tens of thousands of units money becomes a huge issue. If you can save a few dollars per switch that can translate to huge savings in the long run. Even Facebook is doing this with OCP. By creating a demand for specific components for these devices, they can drive costs down across the board and save money for them. For Facebook, money is what is tracked for creating their infrastructure. The more that is saved, the more they can do with it.

In the enterprise, money isn’t quite as important as time. Money is important to businesses for sure. You don’t keep the lights on if you aren’t making money. But because IT supports the business and isn’t the entire business, money can be more easily allocated to projects from budgets. There are pools of money that can be used to purchase office furniture, catering services, or IT hardware. These resources can be reallocated efficiently like Facebook allocates time for projects. If the storage array needs to be upgraded or the wireless needs to be refreshed there can be discussions about how to accomplish it. Maybe the CEO doesn’t get a new desk this quarter. Or maybe there needs to be a few new sales discussions to create capital. But money isn’t as valuable as time. If you think I’m crazy try to get 10 minutes on a CEO’s calendar. Versus getting him to sign off on a purchase.

That’s the real value of cloud computing for IT professionals. They aren’t paying for scale or for availability. They’re really paying for time. They’re paying for a process that reduces the amount of time that they spend configuring low level tasks that are menial and time consuming. Building systems takes time. Automation reduces the time it takes. Process reduces it even further. So organizations looking to move to the cloud are essentially trading one resource, money, for a more important resource, time. Likewise, the large cloud providers that are building these systems are trading their resource, time, for a more valuable resource, money.

---

Tom’s Take

I don’t believe that smaller enterprises will ever truly embrace the idea of building their own OCP switches running custom Linux distros and custom built routing processes. Because to them, time is way too important. Time to focus on the business. Time to focus on supporting the way that the money is made. Time to do more. Likewise, I expect that large enterprises and providers like Facebook will continue to push the envelope of development and create new solutions. Because they have the time to play and test and build. And use those skills to make money. But I never see a world where those two places meet. Because resource contention is different between these two groups and it causes different outcomes. And the value of those resources are unlikely to change without massive disruption.

Over the course of the last few weeks, a botnet comprised mainly of Android mobile devices has been utilized to launch a high-impact DDoS extortion campaign against multiple organizations in the travel and hospitality sector. This botnet, dubbed ‘WireX’, is only the second mobile botnet […]

What are the changes in 2017 CCDE Practical/Lab exam ?    As you might know, CCDE Practical/Lab exam was cancelled on May 2017 due to some leakage. Some people tried to sell the scenarios, Cisco cancelled the exam and revoke the certifications of those who involved with that cheating. Some people among them can be […]

The post What are the changes in August 2017 CCDE Practical exam ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

My friend Christoph Jaggi published new versions of his Metro- and Carrier Ethernet Encryptor documents:

• Technology introduction, including an overview of encryption mechanisms, Carrier Ethernet connectivity models, typical deployments, and key management challenges.
• Market overview, including standards, control- and data plane considerations, key- and system management, and network integration.

Enjoy!

Dan Lyons talks about the dysfunctional side of working at a startup.

The post Startups have Screwed Up Work Culture appeared first on EtherealMind.

IS-IS Overload Bit – Why IS-IS Overload bit is used ? What are the use cases ?  In this post, I will explain the Overload bit which is an important feature of IS-IS routing protocol.   When a router which runs an IS-IS routing protocol have resource issue (CPU, Memory), device shouldn’t receive network traffic. […]

The post IS-IS Overload Bit – Why IS-IS Overload bit is used ? What are the use cases ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

A network engineer interested in attending the Building Network Automation Solutions online course sent me this question:

Does the course cover only Ansible, or does it also cover other automation tools like Python?

The course focuses on how you’d build a network automation solution. Selecting the best tool for the job is obviously one of the major challenges, and so one of the self-study modules describes various automation tools and where you could use them to build a full-blown solution.

Read more ...

What is attachment circuit in MPLS VPN ? Definitions are important in networking, if there are alternative usages of the definition, better to know them all for effective communication.   MPLS Layer 2 VPN Topology   In the above topology, I share, MPLS Layer 2 VPN Topology. There are many terminology but let’s focus on […]

The post What is Attachment Circuit in MPLS VPN ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.