Five Functional Facts about OTV
Following on from my previous “triple-F” article (Five Functional Facts about FabricPath), I thought I would apply the same concept to the topic of Overlay Transport Virtualization (OTV). This post will not describe much of the foundational concepts of OTV, but will dive right into how it actually functions in practice. A reasonable introduction to OTV can be found in my series on Data Center Interconnects.
So without any more preamble, here are five functional facts about OTV.
Understanding CME Overlays with Dual-Line DNs
Normally I talk about overlays in the context of data center/SDN/cloud but today I’m going out into left field and am going to talk about voice! :-)
I freely admit that I’m a noob when it comes to Cisco voice so I’m not sure if the behavior I’m about to describe is obvious or not. It wasn’t obvious to me and I only figured it out after running into the issue for real and troubleshooting it to resolution.
The issue stems from my misunderstanding about how dual-line ephone-dns function when used in an overlay.
The Desired Behavior
Here’s the scenario: Cisco Communications Manager Express (CME) with a handful of IP phones registered to it. There’s no Communications Manager (UCM); the dial plan lives entirely within CME. PSTN connectivity is via (4) POTS lines terminated on FXO ports on the router running CME.
The desired behavior is to have incoming calls from the PSTN ring on all the IP phones simultaneously. If a second call comes in, it should ring on all the remaining phones, and so on.
The Original CME Config
Here’s what the original CME config looked like. At least, the parts of the config relevant to this blog Continue reading
Understanding CME Overlays with Dual-Line DNs
Normally I talk about overlays in the context of data center/SDN/cloud but today I'm going out into left field and am going to talk about voice! :-)
I freely admit that I'm a noob when it comes to Cisco voice so I'm not sure if the behavior I'm about to describe is obvious or not. It wasn't obvious to me and I only figured it out after running into the issue for real and troubleshooting it to resolution.
The issue stems from my misunderstanding about how dual-line ephone-dns function when used in an overlay.
Plumbing OpenBSD Software with gdb(1)
This post is about finding and fixing a memory leak I discovered in the SNMP daemon, snmpd(8), in OpenBSD. This sort of analysis is foreign territory for me; I’m not a software hacker by day. However, using instructions written by Otto Moerbeek as my Rosetta stone and Google to fill in the blanks when it came to usage of the GNU debugger, gdb(1), I was able to find and fix the memory leak.
I’m documenting the steps I used for my future self and for others.
The Problem
When walking the pfTblAddrTable in the OPENBSD-PF-MIB, the unprivileged snmpd process would grow in terms of SIZE and RES. Querying other parts of PF-MIB or other MIBS altogether resulted in no memory usage increase.
Since I knew roughly which code path must have the leak, I first examined it manually. I could not see where memory wasn’t being given back. I needed to instrument the process as it was running in order to find the leak.
Before Starting
This set of instructions from Otto Moerbeek was my guide. As per his guide, you have to rebuild libc with MALLOC_STATS enabled. This enables statistics collection that is used later on.
Edit /usr/src/lib/libc/stdlib/malloc. Continue reading
Plumbing OpenBSD Software with gdb(1)
This post is about finding and fixing a memory leak I discovered in the SNMP daemon, snmpd(8), in OpenBSD. This sort of analysis is foreign territory for me; I'm not a software hacker by day. However, using instructions written by Otto Moerbeek as my Rosetta stone and Google to fill in the blanks when it came to usage of the GNU debugger, gdb(1), I was able to find and fix the memory leak.
I'm documenting the steps I used for my future self and for others.
DCI with LISP for Cold Migrations
Let’s step back for a minute. So far in this series of blog posts on DCI, I’ve been focusing on extending the Layer 2 domain between data centers with the goal of supporting hot migrations — ie, moving a virtual machine between sites while it’s online and servicing users.
Is that the only objective with DCI?
Well if it was, there wouldn’t be a need for this blog post :-) Cold migrations have valid use cases too. Cold migrations occur when the virtual machine is shut down in one site and then booted in a new site. As part of that operation, typically an orchestration layer (such as VMware’s Site Recovery Manager) will poke and prod the VM to make it ready for operation in the new site. Most notably, it takes care of changing the VM’s IP address and default gateway.
Cold migrations do not have a requirement for the same IP subnet in both sites. This is because there’s no need to maintain active user sessions during the migration. Different IP subnets in the sites means no stretched Layer 2 which means no risk of combining failure domains!
What if that orchestration layer didn’t have to poke Continue reading
DCI with LISP for Cold Migrations
Let's step back for a minute. So far in this series of blog posts on DCI, I've been focusing on extending the Layer 2 domain between data centers with the goal of supporting hot migrations — ie, moving a virtual machine between sites while it's online and servicing users.
Is that the only objective with DCI?
Cisco onePK Screencast
As a follow-on to my previous article on onePK – Cisco onePK: Now I Get It – I recorded a screencast in which I talk about what a onePK-enabled network is capable of. I also demonstrate two applications which make use of onePK to gather telemetry from the network and also program the network.
- MTU Checker – Verifies that when the MTU of an interface is changed on the CLI, that the adjoining interface MTU matches
- Routing For Dollars – Programs the forwarding table of the routers in the network based on the cost – in terms of dollars – of the various links in the network
Please leave a comment below with any questions or feedback.
Copyright Joel Knight. All Rights Reserved.
www.packetmischief.ca
Cisco onePK Screencast
As a follow-on to my previous article on onePK — Cisco onePK: Now I Get It — I recorded a screencast in which I talk about what a onePK-enabled network is capable of. I also demonstrate two applications which make use of onePK to gather telemetry from the network and also program the network. MTU Checker - Verifies that when the MTU of an interface is changed on the CLI, that the adjoining interface MTU matches Routing For Dollars - Programs the forwarding table of the routers in the network based on the cost — in terms of dollars — of the various links in the network Please leave a comment below with any questions or feedback.Cisco onePK: Now I Get It
I had an opportunity recently to sit in a Cisco onePK lab and it opened my eyes to exactly what Cisco is doing with onePK, why it’s going to be so important as Software Defined Networking (SDN) continues to gain traction, and why onePK is different than what anyone else is doing in the industry.
onePK is a key element within Cisco’s announced Open Network Environment SDN strategy. onePK is an easy-to-use toolkit for development, automation, rapid service creation and more. It enables you to access the valuable data inside your network via easy-to-use APIs.
Source: www.cisco.com/go/onepk
Since having my own eyes opened, I’ve been pondering how to explain my new found understanding in a way that others will grasp. In particular to business decision makers (BDMs) and technical decision makers (TDMs). I’m really, really, struggling to come up with a good analogy for BDMs. I’m still working on that one. Surprisingly, I’m also struggling to come up with a sound analogy that will work with the majority of TDMs that I know. Maybe I shouldn’t be so surprised at that since all the TDMs I deal with are on the infrastructure side of things (networks, storage, Continue reading
Cisco onePK: Now I Get It
I had an opportunity recently to sit in a Cisco onePK lab and it opened my eyes to exactly what Cisco is doing with onePK, why it's going to be so important as Software Defined Networking (SDN) continues to gain traction, and why onePK is different than what anyone else is doing in the industry.
onePK is a key element within Cisco's announced Open Network Environment SDN strategy. onePK is an easy-to-use toolkit for development, automation, rapid service creation and more. It enables you to access the valuable data inside your network via easy-to-use APIs.
Source: www.cisco.com/go/onepk
Since having my own eyes opened, I've been pondering how to explain my new found understanding in a way that others will grasp. In particular to business decision makers (BDMs) and technical decision makers (TDMs). I'm really, really, struggling to come up with a good analogy for BDMs. I'm still working on that one. Surprisingly, I'm also struggling to come up with a sound analogy that will work with the majority of TDMs that I know. Maybe I shouldn't be so surprised at that since all the TDMs I deal with are on the infrastructure side of things (networks, storage, Continue reading
An Introduction to the Nexus 7700
We're halfway through 2013 and we have our second new member of the Nexus family of switches for the year: the Nexus 7700. Here are the highlights:
- Modular, chassis-based system
- 18 slot (16 IO modules) and 10 slot (8 IO modules)
- True front-to-back airflow
- New fabric modules
- (6) fabric modules (maximum) per chassis
- 220G per slot per fabric module
- 1.32Tbps per IO module slot
- Supports F2E and newly announced F3 IO modules
DCI: Using FabricPath for Interconnecting Data Centers
Here's a topic that comes up more and more now that FabricPath is getting more exposure and people are getting more familiar with the technology: Can FabricPath be used to interconnecting data centers?
For a primer on FabricPath, see my pervious article Five Functional Facts about FabricPath
.
FabricPath has some characteristics that make it appealing for DCI. Namely, it extends Layer 2 domains while maintaining Layer 3 — ie, routing — semantics. End host MAC addresses are learned via a control plane, FP frames contain a Time To Live (TTL) field which purge looping packets from the network, and there are no such thing as blocked links — all links are forwarding and Equal Cost Multi-Pathing (ECMP) is used within the fabric. In addition, since FabricPath does not mandate a particular physical network topology, it can be used in spine/leaf architectures within the data center or point-to-point connections between data centers.
Sounds great. Now what are the caveats?
How I Replace a Failed/Failing HDD in a ZFS Storage Pool
I've had enough real life experience with replacing drives in the ZFS pool in my home NAS that I feel comfortable sharing this information with the community.
Nexus 7000 IO Module SKU Cheat Sheet
Wow the title of this post is a mouthful.
Similar to my previous post on the Nexus 2000 (Nexus 2000 Model Number Cheat Sheet), this post will explain what the letters and numbers mean in the Nexus 7000 IO module part numbers. This will allow you to quickly identify the characteristics of the card just by looking at the part number which in turn should help you out as you're building BOMs and picking the right card for the job.
Update July 2, 2013: Updated to reflect release of the Nexus 7700 and F3 modules.
DCI Series: Overlay Transport Virtualization
This is the third article in my series on Data Center Interconnection (DCI). In the first (Why is there a “Wrong Way” to Interconnect Data Centers?) I wrote about the risks associated with DCI when the method chosen is to stretch Layer 2 domains between the data centers. In the second article (DCI: Why is Stretched Layer 2 Needed?) I wrote about why the need exists for stretching Layer 2 domains between sites and also touched on why it's such a common element in many DCI strategies.DCI: The Need for Stretched Layer 2
In the previous article in this DCI series (Why is there a “Wrong Way” to Interconnect Datacenters?) I explained the business case for having multiple data centers and then closed by warning that extending Layer 2 domains was a path to disaster and undermined the resiliency of having two data centers.
Why then is stretching Layer 2 a) needed and b) a go-to maneuver for DCI.
Let's look at it from two points of view: technology and business.
Why is there a “Wrong Way” to Interconnect Datacenters?
There's certainly a lot of focus on data center interconnection (DCI) right now. And understandably so since there are many trends in the industry that are making IT organizations look at data center redundancy. Among these trends are:
- The business is saying to IT that they require their IT services to be available at all times. In effect the business is saying that they want to be shielded from technology issues, maintenance windows, and unplanned downtime because the IT services they consume (not all of them mind you, but certainly some of them) are so critical to running the business that they cannot be without them (or, they cannot be without them for whatever period of time it would take IT to recover the service).
- The technical ability to move workloads between sites thanks to the near ubiquity of features like vMotion and Live Migration. The ability to pick up an application and swing it over to another location makes item #1 above far less daunting to IT shops and lowers the barrier to adoption.
In this post I'm going to talk about how IT can address item #1 above — the business need — in a manner Continue reading
My Tools for Studying
Anyway, I thought it would be neat to document the tools I'm using today. It'll be interesting to read this in a couple of years to see how things have changed again and maybe it'll give a fellow cert-chaser some ideas for today.
Creating a CCNA Voice Lab
I've been working on something that at this point in my career I never thought I'd be doing: another Cisco Certified Network Associate (CCNA) certification. The CCNA Voice, to be exact. Now that I'm in a job role where I'm expected to be somewhat of a jack-of-all-trades, I can no longer avoid learning voice :-) For a long time I've focused on just the underlying network bits and left the voice “stuff” to others. Since I now need to talk intelligently about Cisco voice solutions, products, and architectures, I decided to go through the CCNA Voice curriculum as a way to establish some foundational knowledge.
This post is about the tools and methods I used to build a small lab to support my studies.