Introduction In this post we will take a look at IP FRR and Micro-loops. If the reader already doesn’t have some kind of basic familiarity with IP FRR and Micro-loops, then I would highly recommend the reader go through below post series by Russ as he introduces various concepts in a very clear way. This post […]
The post IP FRR and Micro-loops Part 1 appeared first on Packet Pushers Podcast and was written by Diptanshu Singh.
If you watched the Network Field Day videos, you might have noticed an interesting (somewhat one-sided) argument I had with Sunay Tripathi, CTO and co-founder of Pluribus Networks (start watching at around 32:00 to get the context). Let’s try to get the record straight.
Read more ...Original content from Roger's CCIE Blog Tracking the journey towards getting the ultimate Cisco Certification. The Routing & Switching Lab Exam
The spanning tree portfast command is a very simple feature but often mis-understood. In this short post I will explore how this feature behaves, how it works and how to configure it on a cisco switch. Portfast is a Cisco Propietary feature that was originally developed to overcome an issue when a PC was trying... [Read More]
Post taken from CCIE Blog
Original post Spanning Tree Portfast – The Definitive Guide
If you have ever worked with Ansible, it’s almost a guarantee that you have used their online docs to figure out what parameters a given module supports, how they should be used, or what their defaults are. Over the past few weeks, I’ve been working on a few custom modules and was trying to find a way to generate web docs for them, and have them locally accessible or easily posted to GitHub.
Ansible offers a way to “make webdocs,” but it generates the complete module inventory and truth be told, I didn’t get this work for my custom modules, so I figured I would explore a “simplified” way — a way that should be able to generate docs as needed for one or more modules on an as needed basis.
The outcome was the creation of an Ansible module and Jinja2 template that automatically generates a markdown file (that can then be viewed or posted anywhere).
The modules you’ve built or are local to your machine (even Ansible core modules) that you want to generate a web doc for must be documented according to Ansible standards. That’s the only major requirement.
From there, Continue reading
In a former post I pointed out that we need to think of obscurity as a tool in network security — that we shouldn’t try to apply rules that are perfectly logical in terms of algorithms to networks as a system. While I’m not normally one to repeat myself, this topic needs a little more […]
The post NAT, Security, and Repeating Myself appeared first on Packet Pushers Podcast and was written by Russ White.
Confession Time.
I am guilty of committing several sins. One that egregiously stands out is writing two IETF specs for BFD security (here and here) without considering the impact on the routers and switches implementing those specs. Bear in mind that Bi-directional Forwarding Detection (BFD) is a hard protocol to implement well. Its hard to get into a conversation with engineers working on BFD without a few of them shedding copious quantities of tears on what it took them to avoid those dreaded BFD flaps in scaled setups. They will tell you how they resorted to clever tricks (hacks, if you will) to process BFD packets as fast as they could (plucking them out of order from a shared queue, dedicated tasks picking up BFD packets in the ISR contexts, etc) . In a candid conversation, an ex-employee of a reputed vendor revealed how they stage managed their BFD during a demo to a major customer since they didnt want their BFD to flap while the show (completely scripted) was on. So, long story short — BFD is hard when you start scaling. It just becomes a LOT worse, when you add security on top of it.
The reason BFD is hard is because of Continue reading
Confession Time.
I am guilty of committing several sins. One that egregiously stands out is writing two IETF specs for BFD security (here and here) without considering the impact on the routers and switches implementing those specs. Bear in mind that Bi-directional Forwarding Detection (BFD) is a hard protocol to implement well. Its hard to get into a conversation with engineers working on BFD without a few of them shedding copious quantities of tears on what it took them to avoid those dreaded BFD flaps in scaled setups. They will tell you how they resorted to clever tricks (hacks, if you will) to process BFD packets as fast as they could (plucking them out of order from a shared queue, dedicated tasks picking up BFD packets in the ISR contexts, etc) . In a candid conversation, an ex-employee of a reputed vendor revealed how they stage managed their BFD during a demo to a major customer since they didnt want their BFD to flap while the show (completely scripted) was on. So, long story short — BFD is hard when you start scaling. It just becomes a LOT worse, when you add security on top of it.
The reason BFD is hard is because of Continue reading
There is another project out there in the ether that I have a hand in providing input for. One of the features that I felt was necessary for it is exporting NetFlow information from traffic the Linux machine handled, to a collector. This is dual-stack traffic, but I have the collector listening on IPv6.
Firstly, I needed something that would gather and export the data, so I found softflowd. My ubuntu server had it in the repo, so a quick apt install got it onto the machine easily enough. You need to edit /etc/default/softflowd and set what interface(s) you want it capturing & generating flow data from, and what options to feed to the daemon, like what server:port to export that data to:
INTERFACE="eth#"
OPTIONS="-v 9 -n [x:x:x:x::x]:9995"
Fill in the correct interface name you want to gather data from. The -v 9 option tells it to use Netflow v9, which has IPv6 support The -n option is used for specifying the collector machine’s IP and port, and fill in for the correct IPv6 address of that collector. Above is the format for specifying an IPv6 host running a collector, like nfcapd. Then you can fire up the softflowd daemon, Continue reading
Did you guess by the title who will be the celebrity keynote speaker for CLUS San Diego? It’s none other than Mike Rowe, also known as the dirtiest man on TV.
Mike is the man behind “Dirty Jobs” on the Discovery Channel. Little did he know when pitching the idea to Discovery that they would order 39 episodes of it. Mike traveled through 50 states and completed 300 different jobs going through swamps, sewers, oil derricks, lumberjack camps and what not.
Mike is also a narrator and can be heard in “American Chopper”, “American Hot Rod”, “Deadliest Catch”, “How the Universe Works” and other TV shows.
He is also a public speaker and often hired by Fortune 500 companies to tell their employees frightening stories of maggot farmers and sheep castrators.
Mike also believes in skilled trades and in working smart AND hard. He has written extensively on the country’s relationship with work and the skill gap.
I’m sure Mike’s speach will be very interesting…and maybe a bit gross…
The following two links take you to Cisco Live main page and the registration packages:
Cisco Live
Cisco Live registration packages
Having set up an Ubuntu Linux server running on a free micro-instance in Amazon’s Web Services EC2 service, I’d like to see how some of the open-source network simulation tools I’ve been using work in the cloud.
First, I will install the CORE Network Emulator on my Amazon AWS EC2 virtual private server. Please read the rest of this post to see how it works.
I expect that the CORE Network Emulator will install and run on an Amazon EC2 instance because it uses Linux Containers (LXC) as its virtualization technology. I have already observed that LXC containers work when run inside a virtual machine on my Laptop computer. It should work the same when running in a virtual machine in Amazon’s EC2 cloud computing service.
I’ve already described how to install the CORE network emulator in previous posts so I will list the installation steps below without any explanation. For details, please see my post on how to install the CORE Network Emulator from source code.
$ sudo apt-get update
$ sudo apt-get install bash bridge-utils ebtables
iproute libev-dev python tcl8.5 tk8.5 libtk-img
autoconf automake gcc libev-dev make python-dev
Continue readingI’m sitting in the San Francisco airport with nothing better to do than writing blog posts, so let’s see what we’ve seen and learned during the Networking Field Day 9.
Most videos recorded during the week are already online. You’ll find links to them in the Presentation Calendar section.
Read more ...