August 18, 2017

The Networking Nerd

Automating Documentation

Tedium is the enemy of productivity. The fastest way for a task to not be done is to make it long, boring, and somewhat complicated. People who feel that something is tedious or repetitive are the ones more likely to marginalize a task. And I think I speak for the entire industry when I say that there is no task more tedious and boring than documentation. So how can we fix it?

Tell Me What You Did

I’m not a huge fan of documentation. When I decide on a plan of action, I rarely write it down step-by-step unless I’m trying to train someone. Even then, it looks more like notes with keywords instead of a narrative to follow. It’s a habit that has been borne out of years of firefighting in networks and calls to “do it faster”. The essential items of a task are refined and reduced until all that remains is the work and none of the ancillary items, like documentation.

Based on my previous life as a network engineer, I can honestly say that I’m not alone in this either. My old company made lots of money doing network discovery engagements. Sometimes these came because the previous admins walked out the door with no documentation. Other times, it was simply because the network had changed so much since the last person made any notes that what was going on didn’t resemble anything like what they thought it was supposed to look like.

This happens everywhere. It doesn’t take many instances of an network or systems professional telling themselves, “Oh, I’ll write it down later…” for later to never come. Devices get added, settings get changed, and not one word is ever written down. That’s the kind of chaos that causes disorganization at best and outages at worst. And I doubt there’s any networking pro out there that hasn’t been affected by bad documentation at one time or another.

So, how do we fix documentation? It’s tedious for sure. Requiring it as part of the process just invites people to find ways around it. And good documentation takes time. Is there a way to combine the lack of time, lack of requirement, and repetition and make documentation something that is done again? I think there is. And it requires a little help from process.

Not Too Late To Automate

Automation is a big thing right now. SDN is driving it. Network complexity is practically requiring it. Yet networking professionals are having a hard time embracing it. Why?

In part, networking pros don’t like to spend hours solving a problem that can be done in minutes. If you don’t believe me, watch one of the old SNL Nick Burns sketches. Nick is more likely to tell you to move than tell you how to fix your problem. Likewise, if a network pro is spending four hours writing an automation script that is supposed to execute a change that can be made in 20 minutes, they’re not going to want to do it. It’s just the nature of the job and the desire of the network professional to make every minute count.

So, how can we drive adoption of automation? As it turns out, automating documentation can be a huge driver. Automation of tedious tasks is exactly the thing that scripting and automation was designed to solve. Instead of focusing on the automation of the task, like adding VLANs to a set of switches, focus on the ability of the system to create documentation on the fly from the change.

Let’s walk through an example. In order for documentation to matter, it has to answer the 5 Ws. How can we automate that?

Let’s start with Who. Automation can create documentation saying user Hollingsworth made a change through an automated process. That helps the accounting side of the house figure out the person making changes in the network. If that person is actually a script, the Who can be changed to reflect that it was an automated process called by a person related to a change ticket. That gives everyone the ability to track the changes back to a given problem. And it can all be pulled in without user intervention.

What is also an easy automation task. List the configuration being applied. At first, the system can simply list the configuration to be programmed. But for menial and repetitive tasks like VLAN additions you can program the system with a real description like “Adding VLANs to $Switch to support $ticket”. Those variables can be autopopulated based on the work to be done. Again, we reference a ticket number in order to prove that these changes are coming from somewhere.

When is also critical. Are these changes happening in a maintenance window? Or did someone check them in in the middle of the day because they won’t cause any problems? (SPOILER ALERT: They will) By required a timestamp for changes, you can track which professionals are being cavalier with their change management. You can also find out if someone is getting into the system after hours to cause problems or attempt to compromise things. Even if the cause of the change is “immediately” due to downtime or emergency, knowing why it had to be checked in right away is a clue to finding problems that recur in the network.

Where is a two-pronged reason. It’s important to check where the changes are going to be applied. Is it going to be done to all switches in the organization? Or just a set in a remote office. Sanity checking via documentation will keep you from bricking your entire organization in one fell swoop. Likewise, knowing where the change is being checked in from is important. Is a remote office trying to change config on HQ switches? Is a remote engineer dialed in making changes related to an open support case? Is someone from a foreign nation making changes via VPN at 4:30am local time? In every case, you’d really want to know what’s going on before those changes get made.

Why is the one that will trip up everything. If you don’t believe me, I’d like to give you the top two reasons why Windows Server 2003 is shut down and rebooted with the shutdown justification dialog box:

  1. a;lkdjfalkdflasdfkjadlf;kja;d
  2. JUST ****ing SHUT DOWN!!!!!

People don’t like justifying their decisions. Even when I worked for Gateway 2000 on their national help desk, our required call documentation was a bit spotty when it came to justification for changes. Why did you decide to FDISK and reload? Why are you going into the registry to fix the icon colors? Change justification is half of documentation. It gives people something to audit. It gives people a way to look at things and figure out why you started down the path of a particular reasoning for problem solving. It also provides context for you after the fact when you can’t figure out why you did it the way you did.

Tom’s Take

Automation isn’t going to take away your job. Automation is going to do the jobs you hate doing. It’s going to make your life easier to concentrate on the tasks that need to be done by freeing you from the tasks that should be done and aren’t. If we can make automation document our networks for just six months, I think you’ll find the value in programming things to work this way. I also think you’ll be happier with the level of detail on your network. And once you can prove the value of automating just one task to your teams, I’m sure they’ll see the value of increasing automation all around.

by networkingnerd at August 18, 2017 02:38 PM

Network Design and Architecture

Network Interconnections Video by Orhan Ergun

Network Interconnections is one of the most important topics for the operator network as it directly related with the cost of the sending traffic out from their networks.   I published a network interconnection video on my Facebook page. I explain the peering types, settlement free peering , paid peering , remote peering , IP […]

The post Network Interconnections Video by Orhan Ergun appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 18, 2017 01:00 PM Blog (Ivan Pepelnjak)

Feedback: Network Automation 101

Some networking practitioners start their network automation journey with the Python or Ansible dilemma. Engineers and architects usually want to understand the bigger picture first, and figure out the potential showstoppers and roadblocks. One of them left this feedback on the Network Automation 101 webinar:

A must-have overview of fundamental Network Automation concepts. I wouldn't face an automation project without understanding these concepts first.

by Ivan Pepelnjak ( at August 18, 2017 06:21 AM

XKCD Comics

August 17, 2017

My Etherealmind
Network Design and Architecture

BGP Route Reflector routing loop problem !

BGP Route reflector routing loop arise in IP networks. In this post, I will illustrate the topology which will loop the IP packets between the routers and I will describe multiple possible solution and share a best practice to design BGP Route Reflector in an IP network.       BGP Route Reflector Routing loop […]

The post BGP Route Reflector routing loop problem ! appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 17, 2017 01:00 PM

August 16, 2017

Network Design and Architecture

IS-IS Case Study – Ausnet

This is a case study which provides a detailed design steps for IGP protocol on hypothetical Internet Service Provider, called Ausnet. You can download the Case Study from the below link directly. Also, please know that you can watch 10+ hours Service Provider Design Videos from here.      

The post IS-IS Case Study – Ausnet appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by alaaissa at August 16, 2017 08:01 PM

Router Jockey

PCAP PCAP PCAP – Changes to RJ Store

I made a couple changes to the RouterJockey store this week and I wanted to make sure I got the word out. Previously the store worked in sprints that I tried to open up 2-3x a year. Instead of trying to manage these sprints, and keep the products updated, I’ve now made the store available year round. It still operates in sprints, but instead of being 2-3 weeks long, they’re only 3-4 days each.

On top of being more available, the store now has a few new products, nothing too exciting, but we do have a RJ phone case, a PCAP mug, and a couple stickers for sale. Teespring has recently added these products and as I get requests for other products I will be sure to add them. As usual, if you have any questions, hit me up on twitter or use the contact form.

Click here, or use the store item in the menu bar to visit my new storefront.

The post PCAP PCAP PCAP – Changes to RJ Store appeared first on Router Jockey.

by Tony Mattke at August 16, 2017 06:55 PM

Network Design and Architecture

MPLS Traffic Engineering Fast Reroute Link Protection

MPLS Traffic Engineering Fast Reroute Link Protection – I will explain it in plain English and the most important point of MPLS TE FRR Link Protection among other Fast Reroute mechanisms.   Sometimes I am surprised that we have a very long technology names in networking 🙂   Okay, let me explain briefly what is […]

The post MPLS Traffic Engineering Fast Reroute Link Protection appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 16, 2017 01:00 PM Blog (Ivan Pepelnjak)

Teach IPv6 First and Automate the Deployment

In mid-July dr. Olivier Bonaventure (one of the unsung networking heroes who’s always trying to address real-life problems instead of inventing unicorn solutions in search of a problem) sent an email to v6ops mailing list describing how they teach networking.

Short summary for differently-attentive:

Read more ...

by Ivan Pepelnjak ( at August 16, 2017 08:22 AM

XKCD Comics

August 15, 2017

My Etherealmind
Network Design and Architecture

What is GLBP and where GLBP should be used ?

GLBP stands for Gateway Load Balancing Protocol. In this article, I will explain where GLBP is used , where it shouldn’t be used with the topologies. GLBP is a Cisco preparatory protocol. In most networks, design requirements might be to use only standard based protocols. If that is the case, GLBP is not a standard […]

The post What is GLBP and where GLBP should be used ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 15, 2017 01:00 PM

August 14, 2017

My Etherealmind
Network Design and Architecture

Is Inter-AS MPLS VPNs commonly deployed ?

Is Inter-AS MPLS VPNs commonly deployed ? In real-life deployment which Inter-AS MPLS VPN Option is most common ? What are the use cases of Inter-AS MPLS VPNs ? This is not a theory post , I will share practical information with you.   For those who want to learn the details of Inter-AS MPLS […]

The post Is Inter-AS MPLS VPNs commonly deployed ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 14, 2017 01:00 PM

New design of

I used to receive many queries on design of website and we did few changes. Changes especially on the homepage. Previously the blog posts were in the and we moved them to homepage. So they are now accessible directly from the homepage which is Also, added an announcement section to homepage where you will […]

The post New design of appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 14, 2017 08:13 AM

XKCD Comics

August 12, 2017

Network Design and Architecture

Very important update on CCDE Practical Exam Result !

As you might know May 2017 exam was cancelled due to leakage and I shared a post on it on May.   It was very important step taken by Cisco to secure the exam.   Now, it seems another important step is taken by Cisco.   Below message sent by Pearson to the CCDE Practical […]

The post Very important update on CCDE Practical Exam Result ! appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 12, 2017 07:18 PM

August 11, 2017

The Networking Nerd

Virtual Reality and Skeuomorphism

Remember skeuomorphism? It’s the idea that the user interface of a program needs to resemble a physical a physical device to help people understand how to use it. Skeuomorphism is not just a software thing, however. Things like faux wooden panels on cars and molded clay rivets on pottery are great examples of physical skeuomorphism. However, most people will recall the way that Apple used skeuomorphism in the iOS when they hear the term.

Scott Forrestal was the genius behind the skeuomorphism in iOS for many years. Things like adding a fake leather header to the Contacts app, the wooden shelves in the iBooks library, and the green felt background in the Game Center app are the examples that stand out the most. Forrestal used skeuomorphism to help users understand how to use apps on the new platform. Users needed to be “trained” to touch the right tap targets or to feel more familiar with an app on sight.

Skeuomorphism worked quite well in iOS for many years. However, when Jonny Ive took over as the lead iOS developer, he started phasing out skeuomorphism starting in iOS 7. With the advent of flat design, people didn’t want fake leather and felt any longer. They wanted vibrant colors and integrated designs. As Apple (and others) felt that users had been “trained” well enough, the decision was made to overhaul the interface. However, skeuomorphism is poised to make a huge comeback.

Virtual Fake Reality

The place where skeuomorphism is about to become huge again is in the world of virtual reality (VR) and augmented reality (AR). VR apps aren’t just limited to games. As companies start experimenting with AR and VR, we’re starting to see things emerge that are changing the way we think about the use of these technologies. Whether it be something as simple as using the camera on your phone combined with AR to measure the length of a rug or using VR combined with a machinery diagram to teach someone how to replace a broken part without the need to send an expensive technician.

Look again at the video above of the AR measuring app. It’s very simple, but it also displays a use of skeuomorphism. Instead of making the virtual measuring tape a simple arrow with a counter to keep track of the distance, it’s a yellow box with numbers printed every inch. Just like the physical tape measure that it is displayed beside. It’s a training method used to help people become acclimated to a new idea by referencing a familiar object. Even though a counter with tenths of an inch would be more accurate, the developer chose to help the user with the visualization.

Let’s move this idea along further. Think of a more robust VR app that uses a combination of eye tracking and hand motions to give access to various apps. We can easily point to what we want with hand tracking or some kind of pointing device in our dominant hand. But what if we want to type? The system can be programmed to respond if the user places their hands palms down 4 inches apart. That’s easy to code. But how to do tell the user that they’re ready to type? The best way is to paint a virtual keyboard on the screen, complete with the user’s preferred key layout and language. It triggers the user to know that they can type in this area.

How about adjusting something like a volume level? Perhaps the app is coded to increase and reduce volume if the hand is held with fingers extended and the wrist rotated left or right. How would the system indicate this to the user? With a circular knob that can be grasped and manipulated. The ideas behind these applications for VR training are only limited by the designers.

Tom’s Take

VR is going to lean heavily on skeuomorphism for many years to come. It’s one thing to make a 2D user interface resemble an amplifier or a game table. But when it comes to recreating constructs in 3D space, you’re going to need to train users heavily to help them understand the concepts in use. Creating lookalike objects to allow users to interact in familiar ways will go a long way to helping them understand how VR works as well as helping the programmers behind the system build a user experience that eases VR adoption. Perhaps my kids or my grandkids will have VR and AR systems that are less skeuomorphic, but until then I’m more than happy to fiddle with virtual knobs if it means that VR adoption will grow more quickly.

by networkingnerd at August 11, 2017 07:35 PM

Network Design and Architecture

BFD is not a Fast Convergence mechanism !

BFD is not a fast convergence mechanism. BFD stands for Bidirectional Forwarding Detection. It is an important tool for the IP layer but there is a confusion in the network community about it.   BFD is a failure detection mechanism. Link and  node failures can be detected with it.   Without BFD, detection can be done at Layer […]

The post BFD is not a Fast Convergence mechanism ! appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 11, 2017 01:00 PM Blog (Ivan Pepelnjak)

Feedback: Open Networking for Large-Scale Networks

Got this feedback from a network architect attending the Open Networking for Large-Scale Networks webinar:

I used the webinar when preparing for a meeting/discussion with a NOS SW-vendor. In the meeting, my knowledge was completely up-to-speed & I was on the level with the vendor in the discussion! :-)

Obviously, Russ White and Shawn Zandi did a great job based on their real-life hands-on experience (they use whitebox switches @ LinkedIn).

by Ivan Pepelnjak ( at August 11, 2017 07:24 AM

XKCD Comics

August 10, 2017

My Etherealmind
Network Design and Architecture

OSPF Prefix Suppression helps company to use 200 routers

OSPF Prefix Suppression helps to company to use 200 routers in their network without any problem. You can think that, some companies use more than 200 routers in their OSPF network, why this post is special? You will understand why in 10 minutes.   Yes that is true but those companies have either multi-area OSPF […]

The post OSPF Prefix Suppression helps company to use 200 routers appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 10, 2017 01:00 PM Blog (Ivan Pepelnjak)

Interview with Daniel Dib

Daniel Dib is setting up a networking career (from a down-to-earth engineer’s perspective) web site, and started populating it with numerous interviews with fellow networking engineers and architects (all of them well worth reading).

Here are my answers to his questions.

by Ivan Pepelnjak ( at August 10, 2017 07:13 AM

August 09, 2017

Network Design and Architecture
My Etherealmind
Network Design and Architecture

Check these 5 things when you add new technologies on your network

Networks can be really simple but we insist on making it complex !   If you are adding new technologies onto an existing network, these sorts of questions should be kept in mind:   1. What can be broken?   You need to make sure, when you add new protocols or technologies on to an […]

The post Check these 5 things when you add new technologies on your network appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 09, 2017 01:00 PM

Inevitable (Himawan's blog)

Building Intent Based Networking System

I've been unhappy with my creation-to-consumption ratio lately, which is the amount of time spent creating compared to amount of time spent consuming. Yes I spend time creating design documents, business proposals, system architecture, slides for both technical and non-technical content, product requirement documents, blog posts, and occasionally write simple codes, but much of my free time is spent consuming for Netflix, newspapers, Twitter, televised sports, Facebook, blogs, Medium, TV series, online courses and others.

You may say we need consumption as an input prior to creating. And I agree, consuming is fine if it is part of learning or research in order to create something. But creation must come first. So if I commit to create something, let's say a system design or even this blog post, I must start by starting the work first and whenever I feel some information is needed to add or validate the work only then I will consume new inputs to mix with the old ones and fuel creativity.

Tonight I'm sitting in front of my macbook, in an attempt to increase my creation-to-consumption ratio, by writing about building Intent-Based Networking System (IBNS). Let's start with problem definition.

The end customer is a Small-to-Medium Business (SMB) owner who wishes to expand his business to multiple offices. Some of the owner's requirements are below:

"I will have three different size of offices: small for max 20 employees, medium for max 50 employees, and large or main branch with max 200 employees."
"In every office all employees who work in back office must use company-provided wired PC, while employees who work in sales may use company-provided wireless laptop or their personal computing device."
"Anyone can use company's internal collaboration application to chat anytime, however the use of video conference application must be using scheduling system."
"Those who work in sales can access our customer data using web portal, however only those who work in back office can access the database to update the entry."

As you can see, all the above are described using high-level human language, driven by business requirements, policy based, and focus to the applications. These are business intents, and usually in normal network operation we will need an architect or engineer to translate such requirements into technical specification all the way until the method to do the implementation. In the near future, this problem will be solved with no human interaction using Intent-Based Networking.

According to Andrew Lerner from Gartner, Intent-Based Networking is a piece of networking software that helps to plan, design and implement/operate networks that can improve network availability and agility. IBNS incorporates four key things:
  • Translation and Validation– Converts higher-level business policy (what) as input from end users and converts it to the necessary network configuration (how) 
  • Automated Implementation – Uses network automation and/or network orchestration to configure the appropriate network changes (how) across existing network infrastructure 
  • Awareness of Network State – Ingests real-time network status for systems under its administrative control, and is protocol- and transport-agnostic 
  • Assurance and Dynamic Optimization/Remediation– Continuously validates in real time that the original business intent is being met, and can take corrective actions when it is not met 
So company executives or managers define a high-level business policy they want to be enforced in the network. The IBNS verifies that the policy can be executed, then manipulates network resources to create the desired state and enforce policies using fully automated operations. IBNS is gathering data to constantly monitor the state of the network, to ensure the desired state of the network is maintained, and can take automated corrective action to maintain state.

Wait. Is this Intent-Based Networking just another name for network automation and orchestration?

Based on comparison chart created by Big Switch above, Intent defines what is the goal (declarative) while automation or orchestration provides explicit method of how to do the implementation (imperative). This creates layer of abstraction since the input now is more high level to describe business needs, and not implementation specific. And since the Intent is declarative, it requires validation of the Intent to ensure it can be translated by the system into series of tasks that need to be done. Automation and orchestration do not deal with telemetry or monitoring of network state. Real-time network state monitoring is one key element since the system needs to validate in real time that the original business intent is being met. When it is not met, the system can take dynamic actions to correct it.

Where is SDN here? SDN is an architecture for networks with original idea to separate the control plane in SDN controller, from data plane in networking device. This separation makes abstraction between application developer and network device: anyone who wants to create new application related to networking now does not have to understand how specific network device works, instead she can make her application to communicate to SDN controller using northbound API. And if there is any changes required to be done on the device, the controller will do so using southbound API. IBNS can work in both SDN-based and non-SDN based network infrastructure.

A while ago I built the five levels of Autonomous Network, mimicking the levels in Autonomous Vehicle:

Level 0 means no automation at all, and engineer configures network device manually using CLI. As pointed out by Gartner, even if in 2016 there are still 85% operations teams using CLI as their primary interface, the number will go down to 30% in 2020. So some form of automation will surely happen. In Level 1, which is the task specific automation, engineer can write code to communicate to network devices using various APIs to execute certain task e.g. reconfigure BGP configuration, get network state information from the device, redirect the traffic by shutting down certain interfaces or doing routing protocol manipulation, and so on.

Level 2 is when we want to execute series of task to complete one workflow, let's say to deploy the configuration to all network devices for one new medium-size office based on the requirements above. If we assume all required hardware are already in place, the system will start by pulling out the definition of medium-size office: how many devices, what are the types, what kind of configuration needs to be done, and perhaps the current device configuration so the system can make decision if the new config will only be appended to the current one, or will add/replace the full config completely. Then a sequence of tasks following a playbook or recipe, using either an open-source or purposely build software, will be executed to automate the end-to-end workflow to complete the deployment.

Orchestration is needed in Level 3 when there are more components involved in the process. To address some of the business requirements in this exercise will need to orchestrate the work between different controllers or managers for networks (both physical and virtual), servers, storage, security policy as well as management system. For example, we need to make sure the new office will be added into the inventory database. The device configuration and security policy like user segmentation will be enforced by network controller. Then perhaps new virtual machines need to be started on physical servers to host the applications or virtualized network functions. All information, device config, network state until application data must be stored in the storage somewhere, that needs to be orchestrated too. 

Thing gets more interesting from Level 4. If we have already used SDN-based network, we can just use the northbound API to inform the controller what we want it to change from the network. But with non SDN-based infrastructure, it means we still can connect directly to each network device to push the configuration changes. Even if we use automation platform or orchestrator to connects to the network device using API like Netconf and REST, and no longer through manual CLI or SNMP, this approach is called stove pipe as explained in diagram from Tail-F above. The main disadvantage of this approach other than scalability issue, is the communication between the platform to each device (or Managed Object as per Tail-F) is implementation specific depending on the device vendor. This means if we change the device vendor we may have to change the method of implementation from our platform to the new vendor's devices.

Introducing Model Driven networking. Instead of the platform to connect directly to each network device, we can build a model to represent the device and the device config, so now any automation and orchestration happens on the model first. Model based networking provides abstraction since even the network devices are changed to different vendor, the model will remain the same. Another benefit is: any planned changes to the network can be simulated and validated in the model first, and only gets implemented in the real device when the changes are considered safe.

And finally, Level 5 is the target for network intelligence for any infrastructure. We specify business intent, we define the policy between users or components in the network, we provide declarative requirements, and the system will execute without any human interaction. Zero human touch networking. This is the level for Intent-Based Networking System.

Now we know the definition and characteristic of IBNS, how to build one?

I'm using bottom up approach here even though top down will work too and I would argue it is a better approach:

First, start by building the infrastructure. No kidding, we still need the network. Some vendors may call it Network Fabric, and it may consist both physical and virtual networks. We still need physical cables to connect between physical network devices or at least the servers running network functions. In later case we can use overlay protocols to connect between different network functions.

Second, automate and orchestrate the infrastructure. As mentioned earlier, if it's SDN-based infrastructure we will have a controller to deal with network control plane then push the desired state to the device. And in non-SDN infrastructure we still can use a controller to automate any configuration changes to network device (or the model of network device). We need to use an orchestrator to combine this controller with another physical or virtual infrastructure managers that manages the servers, storages and virtual machines.

Third, build the telemetry and monitoring system. At minimum we need a mechanism to measure the state of the network from the status of the service, topology view, both previous and latest configurations, logs for any state change, and error checking mechanism for any failed changes.

Forth, create a mean to translate business intent. This could be in the simple web portal or mobile app that provides service catalogue offering packages for user to select from, with some degree of possible customization. Some day this may turn into a form of virtual assistant that will listen to our voice command, and will translate the captured information into a series of workflows need to be executed by the system.

Obviously the building exercise I write here is a very simple one that should work in principle, event though the devil is always in the details.

Let's see how Google does it, as taken from their public presentation.

Google has been using abstraction with model-driven approach to provide network topology view, configuration data structure and content, and telemetry data structure and attributes. Imagine a vendor-agnostic network topology. The information we need from such topology is a representation of all network devices as nodes, and link to connect the nodes to each other. It can have both node and link attributes such as node identification, port information (e.g. Node A's first port is connected to Node B, second port to Node C and so on) and link speed. We can also have the information to map the node to the current actual network device, for example Node A is currently representing Cisco hardware type X with specific hardware and port configuration, that obviously can be changed when needed. Such information is required for the system to know how to map the model to the actual network device e.g. Node A's first port means interface Gi0/1 on Cisco type X.

Configuration and monitoring information must be described in vendor-agnostic way so it is not bound to specific configuration line or monitoring attribute from the vendor. Any network device configuration will be described as models of interfaces, routing protocols, routing table, routing policy, ACL etc. Each configuration model such as BGP protocol later can be mapped into specific implementation for different vendor's device configuration. And the state of the network like routing table information can be retrieved from the device and populated into the model as well.

Google implements telemetry system using publish–subscribe messaging pattern where senders of messages (publishers) categorize published messages into classes without knowledge of specific receivers (subscribers), and subscribers express interest in one or more classes and only receive messages that are of interest. Using gRPC protocol, it is possible to have a continuous time-series data stream from the device with incremental updates. And the device can provide asynchronous event-driven reporting that does not require to get any response from the servers/collectors (think about device logging or SNMP trap). Obviously it is possible for the collectors to run ad-hoc request to collect data from the devices, that could be a synchronous RPC call.

Once we have all the components in place, what we need now is to connect all pieces together to get the system up and running. The users, or operators, of the system use application to describe configuration intent. An example of this is a web portal to provide the operators to select the option of one use case: "drain the traffic from link X" let's say because we want to do maintenance of the link or migrate it to another link. The instruction is sent using declarative API to both configuration and topology model. Once the requirement is translated into changes to the model, the system will analyze the current configuration to understand what changes are needed to generate required configuration instance. This configuration will be mapped into specific vendor configuration line that will be pushed to the device using different option of southbound protocols depending on which device. Telemetry data is used to monitor configuration changes and the system will provide feedback to the operators when the intent has been implemented successfully.

As closing remark, Intent-Based Networking is considered as "one of the most significant breakthroughs in enterprise networking". Cisco CEO claims Intent Based Networking will redefine the network for the next 30 years. Gartner made prediction that 10% of enterprises will use intent-driven network design and operation tools, reducing their network outages by 65%, by 2020.

And after reading this post, I believe you will agree with such statements because it makes sense. It makes sense not because of the amount of technologies involved in the system, but because the system can provide the answers to the requirements from the business. And that is just what needed from any innovation in this space: to solve real business problem.

Disclaimer: This post represents my own personal view. All the sources of information are available online and accessible to public. No confidential information belong to my current employer is disclosed in this post

by Himawan Nugroho ( at August 09, 2017 06:26 AM

XKCD Comics

August 08, 2017 Blog (Ivan Pepelnjak)

RFC 8212: Bringing Sane Defaults to EBGP

It’s amazing how long it can take to get some sanity into networking technologies. RFC 8212 specifies that a BGP router should not announce prefixes over EBGP until its routing policy has been explicitly configured. It took us only 22 years to get there…

For more technical details, read this email by Job Snijders.

by Ivan Pepelnjak ( at August 08, 2017 03:06 PM

Network Design and Architecture

Are you an Intelligent fool ?

Most fundamental network design attribute should be simplicity.   When you have a simple network, you can have secure, flexible , scalable, understandable , in fact all important design requirements can be achieved.   But having simplicity is easy to say, hard to achieve.   On the other hand, some amount of complexity is required, as […]

The post Are you an Intelligent fool ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 08, 2017 01:00 PM

August 07, 2017

Ethan Banks on Technology

Beware Bait & Switch

Over the weekend, I ordered an Apple Airport Extreme wireless router from The price was great, and their site stated they had 90 in stock. This afternoon, I received from them via e-mail one of the oldest sales tricks there is–the bait and switch.

With the bait and switch technique, the victim is lured by a low price on a desirable product (the bait). The vendor of the low-priced product claims to be out of the bait, offering a different product at a higher price (the switch). N1Wireless suggested that instead of what I had ordered, I spend $50 more on an Apple Time Capsule product.

I applaud for their bold ethical choices, but respectfully decline the opportunity to spend more money on a product I don’t want.

The lesson is not a new one. If something is too good to be true, then it probably is. Really, I should know better. I had a similar experience with a different vendor several months back selling a TV at a surprisingly low price. After two weeks of waiting for the order to ship, I had to call support to find out that the TV was on backorder, but perhaps I was interested in something else?


by Ethan Banks at August 07, 2017 07:53 PM

My Etherealmind
Network Design and Architecture

What is KISS Principle ? Keep it Simple and Stupid ?

What is KISS Principle ? Okay it stands for Keep it Simple and Stupid but what does really it mean in networking ? Can we really make things simpler ?. Probably yes but should we ?   Let’s remember What Einstein said about simplicity.   ” Everything should be made as simple as possible, but no […]

The post What is KISS Principle ? Keep it Simple and Stupid ? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 07, 2017 01:00 PM

Did you see my Interview?

I recently made an interview with  I talked with Daniel many things on networking, brief overview of my story , predictions for the future of networking, recommended community platforms for the network engineers and many other things ! This is a new website which provides many good interviews on networking.   There are many good […]

The post Did you see my Interview? appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 07, 2017 09:52 AM

XKCD Comics

August 04, 2017

My Etherealmind

Opinion on Cisco VIRL Aug 2017

Plenty of reasons to not use it, basically.

The post Opinion on Cisco VIRL Aug 2017 appeared first on EtherealMind.

by Greg Ferro at August 04, 2017 02:03 PM

Network Design and Architecture

Settlement-Free Peering Requirements

Settlement-Free Peering Requirements.   I explained the Peering , Types of Peering basics in one of the previous posts. When we talk about peering, we generally mean settlement-free peering. But what are the common requirements for companies to peer with each other ?   Settlement-free peering is called as Internet Peering as well.   So, companies setup […]

The post Settlement-Free Peering Requirements appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 04, 2017 01:00 PM

XKCD Comics

August 03, 2017

The Networking Nerd

It’s Probably Not The Wi-Fi

After finishing up Mobility Field Day last week, I got a chance to reflect on a lot of the information that was shared with the delegates. Much of the work in wireless now is focused on analytics. Companies like Cape Networks and Nyansa are trying to provide a holistic look at every part of the network infrastructure to help professionals figure out why their might be issues occurring for users. And over and over again, the resound cry that I heard was “It’s Not The Wi-Fi”

Building A Better Access Layer

Most of wireless is focused on the design of the physical layer. If you talk to any professional and ask them to show your their tool kit, they will likely pull out a whole array of mobile testing devices, USB network adapters, and diagramming software that would make AutoCAD jealous. All of these tools focus on the most important part of the equation for wireless professionals – the air. When the physical radio spectrum isn’t working users will complain about it. Wireless pros leap into action with their tools to figure out where the fault is. Either that, or they are very focused on providing the right design from the beginning with the tools validating that access point placement is correct and coverage overlap provides redundancy without interference.

These aren’t easy problems to solve. That’s why wireless folks get paid the big bucks to build it right or fix it after it was built wrong. Wired networkers don’t need to worry about microwave ovens or water pipes. Aside from the errant fluorescent light or overly aggressive pair of cable pliers, wired networks are generally free from the kinds of problems that can plague a wire-free access layer.

However, the better question that should be asked is how the users know it’s the wireless network that’s behind the faults? To the users, the system is in one of three states: perfect, horribly broken, or slow. I think we can all agree that the first state of perfection almost never actually exists in reality. It might exist shortly after installation when user load is low and actual application use is negligible. However, users are usually living in one of the latter states. Either the wireless is “slow” or it’s horribly broken. Why?

No-Service Station

As it turns out, thanks to some of the reporting from companies like Cape and Nyansa, it turns out that a large majority of the so-called wireless issues are in fact not wireless related at all. Those designs that wireless pros spend so much time fretting over are removed from the equation. Instead, the issues are with services.

Yes, those pesky network services. The ones like DNS or DHCP that seem invisible until they break. Or those services that we pay hefty sums to every month like Amazon or Microsoft Azure. The same issues that plague wired networking exist in the wireless world as well and seem to escape blame.

DNS is invisible to the majority of users. I’ve tried to explain it many times with middling to poor results. The idea that computers on the internet don’t understand words and must rely on services to translate them to numbers never seems to click. And when you add in the reliance on this system and how it can be knocked out with DDoS attacks or hijacking, it always comes back to being about the wireless.

It’s not hard to imagine why. The wireless is the first thing users see when they start having issues. It’s the new firewall. Or the new virus. Or the new popup. It’s a thing they can point to as the single source of problems. And if there is an issue at any point along the way, it must be the fault of the wireless. It can’t possibly be DNS or routing issues or a DDoS on AWS. Instead, the wireless is down.

And so wireless pros find themselves defending their designs and configurations without knowing that there is an issue somewhere else down the line. That’s why the analytics platforms of the future are so important. By giving wireless pros visibility into systems beyond the spectrum, they can reliably state that the wireless isn’t at fault. They can also engage other teams to find out why the DNS servers are down or why the default gateway for the branch office has been changed or is offline. That’s the kind of info that can turn a user away from blaming the wireless for all the problems and finding out what’s actually wrong.

Tom’s Take

If I had a nickel for every problem that was blamed on the wireless network or the firewall or some errant virus when that actually wasn’t the case, I could retire and buy my own evil overlord island next to Larry Ellison. Alas, these are issues that are never going to go away. Instead, the only real hope that we have is speeding the time to diagnose and resolve them by involving professionals that manage the systems that are actually down. And perhaps having some pictures of the monitoring systems goes a long way to tell users that they should make sure that the issue is indeed the wireless before proclaiming that it is. Because, to be honest, it probably isn’t the Wi-Fi.

by networkingnerd at August 03, 2017 08:24 PM

Dyn Research (Was Renesys Blog)

.NE Body Out There?

Protecting end users starts with understanding their use and integration of services. For authoritative DNS, this includes human error when copying and pasting information between interfaces. After purchasing a new domain, such as “,” the end user configures authoritative nameservers. Delegation is a “set it and forget it” operation; it is often made outside of scope of continuous integration pipelines and automated deployment systems. To quantify this risk and reconcile it with reality, we started to look at the existence of nameserver record typos in the .COM zone file.

There are typos in nameserver records for a number of authoritative DNS providers made across a number of zones, making it clear that end users make delegation typos. The existence of the typo is one thing, it’s another when the typo has been registered and another provider is serving responses. One of the typos of interest was, which was registered some time in February of 2016. At that time, it was delegated to a pair of authoritative nameservers operated by, a name related to a Chinese hosting provider. Sometime around January 2017, the authoritative nameservers changed over to Yandex, the Russian internet services provider, and the domain began resolving to Using the IP address as a pivot point, we were able to identify thousands of domain names, all of which shared the IP.

internet monitoring

After verifying that the domain name had been registered, we wanted to understand how it was being used. One way to do this is to review passive DNS, a collection of timestamped observations of a domain name and its value at that given point in time. The initial results were troubling, passive DNS showed that in January of 2017 typos of a number of business critical domains were resolving to IP space ( ) of a VPS provider, The typo domains being resolved included our authoritative nameservers, for example: and domains used as part of our email platform, additionally, There were a number of observations of these resolutions in the passive DNS results, which seemed to indicate that someone or something was requesting resolution of these typos consistently.

Things looked suspicious. The domain was resolving to one provider and business critical sub-domains were resolving to another. This initiated some active examination of the infrastructure supporting the domain. The first set of testing showed that the owner of the domain had configured a wildcard to match any requested subdomain of A wildcard will return the same resource records for any permutation that matches *, making any and all subdomains valid requests. An end user requesting will get the same response as someone requesting Finding the wildcard helped clarify why we were seeing so many resolutions in passive DNS. Whenever an end user requested a domain with a nameserver delegation typo, the nameserver would return the wildcard for what was requested, generating observations of the typo with its business critical subdomain.

If you visit with a web browser, you will see the webpage above served from, an IP owned by Team Internet AG. Their website,, explains that they are “a leading provider of services in the direct navigation search market.” The Team Internet entity is tied to an advertising marketplace, Tonic, and domain monetization business, ParkingCrew. After reading through the details of the various business functions on and, it appeared that the nameserver typo domains were being used in a way which matched the “Domain Traffic” ad type. Explained on the Tonic page ( as:

“Domain traffic is also referred to as zero-click traffic, redirect traffic or direct navigation traffic. It all means the same: A user types in a domain name that is parked with a domain parking company like and instead of PPC ads (usually from Google or Yahoo) the user gets instantly redirectet [sic] to the advertiser landing page. You can see an example of this by typing in your browser bar. You will get redirected to one of our advertisers, who is interested in bodybuilding traffic. This adtype brings the best conversions for advertisers.”

Our next step was to reach out to the operators of .NE, the ccTLD of Niger, to get details on their domain usage policies. One issue that came up immediately was trying to contact the ccTLD, as was returning a PHP version page and didn’t resolve correctly. The next stop was to go to IANA and look at the WhoIS contacts. This provided two contacts with email addresses. We drafted up some details about the number of authoritative nameserver typos involved and sent over a note. Then a few days later:

Final-Recipient: rfc822; <redacted>
Action: failed
Status: 4.4.1
Diagnostic-Code: smtp; The recipient server did not accept our requests to connect. [ timed out]

internet monitoring image

Meanwhile, since March 11, 2017, subdomains have started to resolve to an IP belonging to Intergenia (, a different infrastructure provider, part of Host Europe since acquisition in December of 2014. Thanks to some help from the tightly knit DNS Operator & ICANN community, we were able to find updated contact information for the .NE ccTLD. It appears they switched namespace and now operate using email addresses in the rather than We are currently waiting to hear back from them to see if .ne is willing to follow the ICANN Uniform Domain-Name Dispute-Resolution Policy (UDRP).

Domain traffic monetization has been a staple internet ad business for years. Those who have been in the DNS/internet operator game for a while will most likely remember in August of 2006 when Cameroon (.cm) wildcarded their ccTLD for advertizing purposes. There are a couple lessons to be learned from this exercise. When configuring authoritative nameservers, always check twice for typos. When researching use of domain names with passive DNS, it’s important to keep things in context. When you’re done reading maybe go take a look at Oman (.om) and Ethiopia (.et) to make sure your bases are covered.

by Chris Baker at August 03, 2017 01:17 PM

Network Design and Architecture

GRE Tunnels – Generic Routing Encapsulation – Use Cases

GRE Tunnels  GRE tunnels are by far most common tunnelling technology. Very easy to setup, troubleshoot and operate. But in large scale deployment, configuring GRE tunnels become cumbersome, because GRE tunnel is a point to point tunnel.   GRE Tunnel Characteristics    • GRE tunnels are manual point to point tunnels. Tunnel end points are not automatically […]

The post GRE Tunnels – Generic Routing Encapsulation – Use Cases appeared first on Cisco Network Design and Architecture | CCDE Bootcamp |

by Orhan Ergun at August 03, 2017 01:00 PM

Networking Now (Juniper Blog)

Cyber-Threat: Is your team up to the challenge?




Our people are our greatest asset; this is the universal mantra amongst organizations who value their staff and reputation, and never has this been truer than in the fight against cyber-crime. If any team has ever been asked to up its game and be one step ahead of an ingenious and cunning enemy, it’s the network and IT security team tasked with overcoming cyber-criminals.



At the same time we also know that there are simply not enough cyber-security experts to fill all the jobs available, and this is a huge issue. A recent article from Harvard Business Review highlights this challenge – stating that there will be more than 1.5 million unfilled positions globally by 2020!


This represents the largest single shortfall in human resource. Quite simply there are not enough people in cyber-security today, and even with the new-hires currently graduating university and college globally the gap is not going to shrink any time soon.


Security teams already suffer from ‘alert fatigue’ and that can lead them to become ambivalent, ultimately introducing risk as they may miss the single critical alert hidden inside thousands of other purely informational alerts.


To meet the challenge we need to think differently, invest differently and adopt new technology, but what does this mean? We hear buzz words like virtualization, machine learning, artificial intelligence. But are they really just buzz words, or can they actually help you to be better prepared for the cyber-threat challenge?


On August 24th at 14:00 BST we are running the next in Juniper Networks’ series of  security webinars. If you are interested to hear and discuss this challenge then please join myself and Lee Fisher to hear our thoughts, recommendations and ideas. You can register here.

by lpitt at August 03, 2017 10:45 AM

Could Smart-City malware be spread via motorways and highways?



 In recent years we have seen news reports of wildflowers and weeds being 'spread' by the wind-tunnel effect of cars on our motorways and highways, is there a potential for malware to spread between smart cities in the same way?


If you enjoyed reading this blog and would like to read related security blogs please visit here

by lpitt at August 03, 2017 10:38 AM

The first connected car could be taken for ransom




 In my last blog, I discussed how a supply chain attack could affect the business – and brand –of a global company. This week, we’re going to take this a level down and consider something else which I believe could be a threat - the intelligence that is being built into our cars.


If you enjoyed reading this blog and would like to read related security blogs please visit here

by lpitt at August 03, 2017 10:37 AM

Security Prediction #5: Potential major takedown of an IoT manufacturers services or devices



 In my last blog I discussed the risks associated with IoT. If we look at information technology progress in the last 25 years, it seems that malware or data-theft quickly follows major technology milestones. As much as we like to see technology innovation, hackers are are also finding new business opportunities.


If you enjoyed reading this blog and would like to read related security blogs please visit here

by lpitt at August 03, 2017 10:37 AM Blog (Ivan Pepelnjak)

Net Neutrality (Again and Again and Again)

Net neutrality is one of those topics that should never have existed, but of course it inevitably erupts every so often, so here we go…

Not so long ago Robert Graham published his anti-net-neutrality arguments which are (no surprise) not much different from what I wrote when I still cared about this argument (here, here, here and here). While I agree with his overall perspective, I completely disagree with his view of Comcast’s initial response to network congestion.

Read more ...

by Ivan Pepelnjak ( at August 03, 2017 05:33 AM