CCIE SP version 4 has been announced

Cisco has been updating their certifications lately. The CCIE RS got bumped to version 5 and went all virtual. The CCNP RS was then also updated and now it’s time for the CCIE SP.

It seems that Cisco has done a better job lately of tying all the certifications together and providing a more unified exam format. At least this is the indications I’m getting for the CCIE track.

CCIE SP v4 will use the same exam format as the CCIE RS v5. This means that there will be a diagnostic (DIAG) and troubleshooting (TS) module at the CCIE SP lab. First let’s go over the exam domain.

SPv3vsv4

My impression from this is that the v4 blueprint is a bit more generic. This makes it easier to develop the exam content and I also get the feeling that it’s getting more important to have a high level understanding of the different technologies and architecture.

The exam is designed to be dual stack, so you can’t afford to be weak on v6, you must master the v6 topics at the same level as v4. If you get certified you may use the IPv6 Forum Gold logo.

The following topics have been Continue reading

Conformity as an inhibitor to strategy

Early in life, we are all made acutely aware of the power of peer pressure. Most of us probably attribute it to a deep need for belonging. But what if that deep sense of belonging is less about social acceptance and more about how we are psychologically wired? In fact, the pursuit of conformity goes beyond mere social dynamics; it is rooted in how our cognitive selves.

While this plays out in very obvious ways for individuals, the dynamics actually hold true for organizations. And for companies, the stakes might be even higher.

A guy named Solomon

In the 1950s, an American psychologist named Solomon Asch ran through a series of experiments to test the effects of conformity on individuals. His studies have been published several times, but one test in particular gives a fascinating look into how we operate.

Asch took a number of participants and asked them very simple cognitive questions. To conduct the study, Asch brought participants into a room that had seven other people. However, these seven people were actually part of the study. The eight individuals were shown a card with a line on it, followed by a card with three lines on it. The Continue reading

New Webinar: Scaling Overlay Virtual Networks

You can get an overlay virtual networking solution from almost every major hypervisor- and data center networking vendor. Do you ever wonder which one to choose for your large-scale environment? I’m positive you’d get all of them up and running in a one-rack environment, but what if you happen to be larger than that?

We’ll try to address scalability hiccups and roadblocks you might encounter on your growth path in Scaling Overlay Virtual Networks webinar (get your free ticket here).

Read more ...

Is November 12 D-Day for 512k prefixes?

Is November 12 D-Day for 512k prefixes?


by Brian Boyko, Technology Contributor - October 28, 2014

During his presentation on October 7th at NANOG on the trends for prefixes over the past half-decade, Jim Cowie, chief scientist at Dyn Research, found something interesting: We may be reaching “512K day” as soon as next month.

Back in 2009, a typical IPv4 routing table contained only 269k entries. Today, in 2014, it is around 471k, and it is projected to be 519k in 2015… if not sooner. See the chart below from Cowie’s presentation.



Many older but still-in-use Cisco routers can only handle 512k border gateway protocol (BGP) routing entries in their TCAM memory. Indeed, a major outage occurred on August 12th of this year, when an accidental de-aggregation of 20k prefixes pushed the consensus routing table size over that 512k limit.

Was this an aberration, or an industry wake-up call to the fact that we are rapidly approaching a persistent 512k number of BGP entries? The chart above certainly suggests that latter. Cowie predicts that as the consensus BGP routing table hits 512k organically, we'll have a much larger and longer outage as everyone works to upgrade or replace Continue reading

Junos – Wildcard Ranges, Interface Ranges and Configuration Groups

Until recently I have worked almost exclusively on Cisco ASA and IOS platforms. Within the last six months I’ve added Juniper’s Junos platform into my repertoire. The story for how this came to be is one for another post I hope to write soon. For those who aren’t familiar, Junos is a whole different ball […]

Author information

Christian Talsness

Christian Talsness

I've done stints at a start-up, in IT consulting, and most recently in corporate IT as a Network and Security Engineer. I'm a life long geek, and I love fixing broken things. When I have some spare time, I enjoy spending time with my wife and kids, reading and wood working.

The post Junos – Wildcard Ranges, Interface Ranges and Configuration Groups appeared first on Packet Pushers Podcast and was written by Christian Talsness.

Checking community interest for a new kind of networking site

A couple of days ago I got an idea for a new kind of networking site. The idea is to do something similar to dpreview.com but for network products.

I work a lot on network designs these days and part of the design is always what device to choose. Maybe I need a product that does NAT, IPSEC, 200 Mbit/s of throughput and has at least 4 ports. This is the kind of knowledge that you get from working on design and staying up to date with products from different vendors. There is not a community for people where they can find a broad range of products and get help choosing the right one based on different search criteria such as number of ports, features and the throughput.

What I would like to do as well is to have people write about the products. The product page said 200 Mbit/s but I got 500 Mbit/s with IMIX traffic. After enabling IPSEC I only got 80 Mbit/s. These kind of figures are very difficult to find. There could then be some kind of rating or voting system to rate if the post is helpful to sort out if people are Continue reading

Fire your mobile app programmer and build it yourself

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.

Everyone used to hire mobile app developers to build custom programs, but that often resulted in shoddy, insecure programs that sometimes didn’t even work. And even when the software suited the need, chances are it was a colossal waste of money.

Today you can program without programming. Even business people can define and build apps that suit their needs – in just hours or days, depending on the complexity. Or have them built for you for as a low as $500 from a provider harnessing the same automated software creation tools.

To read this article in full or to leave a comment, please click here

Using Scapple To Help Manage Complex Network Changes

I’ve blogged about Scapple in the past, describing how I’ve been using Scapple to do basic network diagrams. If you are willing to give up some of the fancy features you get with an advanced diagramming tool like Visio or Omnigraffle, Scapple can take you reasonably far. In preparation for a recent change […]

Learning NSX, Part 17: Adding External L2 Connectivity

This is part 17 of the Learning NSX blog series. In this post, I’ll show you how to add layer 2 (L2) connectivity to your NSX environment, and how to leverage that L2 connectivity in an NSX-powered OpenStack implementation. This will allow you, as an operator of an NSX-powered OpenStack cloud, to offer L2/bridged connectivity to your tenants as an additional option.

As you might expect, this post does build on content from previous posts in the series. Links to all the posts in the series are available on the Learning NVP/NSX page; in particular, this post will leverage content from part 6. Additionally, I’ll be discussing using NSX in the context of OpenStack, so reviewing part 11 and part 12 might also be helpful.

There are 4 basic steps to adding L2 connectivity to your NSX-powered OpenStack environment:

  1. Add at least one NSX gateway appliance to your NSX implementation. (Ideally, you would add two NSX gateway appliances for redundancy.)
  2. Create an NSX L2 gateway service.
  3. Configure OpenStack for L2 connectivity by configuring Neutron to use the L2 gateway service you just created.
  4. Add L2 connectivity to a Neutron logical network by attaching to the L2 gateway service.

Continue reading

5 Dev Tools for Network Engineers

This entry is part 1 of 1 in the series DevOps for Networking

I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code – this is less about programming, and more about the tools that software developers use every day to work more efficiently. I believe in this, there is a lot of potential benefit to network engineering and operations.

I’m of the opinion that “once you know what you don’t know, you’re halfway there”. After all, if you don’t know what you don’t know, then you can’t very well learn what you don’t know, can you? In that spirit, this article will introduce a few concepts briefly, and every single one will require a lot of hands-on practice and research to really understand thoroughly. However, it’s a good starting point, and I think if you can add even a few of these skills, your marketability as a network engineer will increase dramatically.

 

Proper Version Control

As a developer, version Continue reading

The Inner Ring

An avid reader of C.S. Lewis, I often find his thoughts and statements applicable far outside his original intent. For instance, in 1944 (at least a few years before I was born I feel safe to say), he gave an amazing lecture at the Memorial Lecture of King’s College, University of London. The entire speech can be found here, but to gain a sense of his statement, consider the following quote:

And the prophecy I make is this. To nine out of ten of you the choice which could lead to scoundrelism will come, when it does come, in no very dramatic colours. Obviously bad men, obviously threatening or bribing, will almost certainly not appear. Over a drink, or a cup of coffee, disguised as triviality and sandwiched between two jokes, from the lips of a man, or woman, whom you have recently been getting to know rather better and whom you hope to know better still—just at the moment when you are most anxious not to appear crude, or naïf or a prig—the hint will come. It will be the hint of something which the public, the ignorant, romantic public, would never understand: something which even the outsiders Continue reading

Networking’s atomic unit: Going small to scale up

The major IT trends are all being driven by what can probably best be summarized as more. Some of the stats are actually fairly eye-popping:

  • 40% of the world’s 7 billion people connected in 2014
  • 3 devices per person by 2018
  • Traffic will triple by 2018
  • 100 hours of Youtube video are uploaded every minute
  • Datacenter traffic alone will grow with a 25% CAGR

The point is not that things are growing, but that they are growing exceedingly fast. And trends like the Internet of Things and Big Data, along with the continued proliferation of media-heavy communications, are acting as further accelerant.

So how do we scale?

Taking a page out of the storage and compute play books

Storage and compute have gone through architectural changes to alleviate their initial limitations. While networking is not the same as storage or compute, there are interesting lessons to be learned. So what did they do?

The history lesson here is probably largely unnecessary, but the punch lines are fairly meaningful. From a storage perspective, the atomic unit shifted from the spinning disk down to a block. Ultimately, to scale up, what storage did was reduce the size of the useful atomic unit Continue reading

Learning NSX, Part 17: Adding External L2 Connectivity

This is part 17 of the Learning NSX blog series. In this post, I’ll show you how to add layer 2 (L2) connectivity to your NSX environment, and how to leverage that L2 connectivity in an NSX-powered OpenStack implementation. This will allow you, as an operator of an NSX-powered OpenStack cloud, to offer L2/bridged connectivity to your tenants as an additional option.

As you might expect, this post does build on content from previous posts in the series. Links to all the posts in the series are available on the Learning NVP/NSX page; in particular, this post will leverage content from part 6. Additionally, I’ll be discussing using NSX in the context of OpenStack, so reviewing part 11 and part 12 might also be helpful.

There are 4 basic steps to adding L2 connectivity to your NSX-powered OpenStack environment:

  1. Add at least one NSX gateway appliance to your NSX implementation. (Ideally, you would add two NSX gateway appliances for redundancy.)

  2. Create an NSX L2 gateway service.

  3. Configure OpenStack for L2 connectivity by configuring Neutron to use the L2 gateway service you just created.

  4. Add L2 connectivity to a Neutron logical network by attaching to the L2 gateway service.

Continue reading

HTIRW: Provider Peering and Revenue Streams (Part 1)

In the last post in this series, I described several types of providers — and even how those descriptions are no longer really “pure,” for the most part (although NTT, for instance, is a pure transit provider that only offers a few services throughout the world). For each piece of a provider’s business, then — […]

Author information

Russ White

Russ White
Principle Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. You want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area Continue reading

Stretching the friendship

It has been nine months now since I hung up the console cable and embarked on my PhD.  I seem to be unusual in the 21st-century IT world in that I have only had a couple of employers over the twenty or so years in the industry.  I left each of those jobs on (I […]

Author information

Matthew Mengel

Matthew was a Senior Network Engineer for a regional educational institution in Australia for over 15 years, working with Cisco equipment across many different product areas. However, in April 2011 he resigned, took seven months of long service leave to de-stress and re-boot before becoming a network engineer for a medium sized non-profit organisation. At the end of 2013, he left full-time networking behind after winning a scholarship to study for a PhD in astrophysics. He is on twitter infrequently as @mengelm.

The post Stretching the friendship appeared first on Packet Pushers Podcast and was written by Matthew Mengel.

5 Dev Tools for Network Engineers

I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code - this is less about programming, and more about the tools that software developers use every day to work more efficiently.