packetmischief.ca Archives - Page 4 of 16

3 Ways to Fail at Logging with Flask

For the benefit of readers who haven't worked with Flask or don't know what Flask is, it's a so-called microframework for writing web-based applications in Python. Basically, the framework takes care of all the obvious tasks that are needed to run a web app. Things like talking HTTP to clients, routing incoming requests to the appropriate handler in the app, and formatting output to send back to the client in response to their request. When you use a framework like this, you as the developer can concentrate a lot more on the application logic and worry a lot less about hooking the app into the web.

As you may have guessed from the title of this post, one of the other tasks that Flask manages is logging within the application. For example, if you want to emit a log message when a user logs in or when they upload a new photo, Flask provides a simple interface to generate those log messages.

Flask has a large community of active users built around it and as a result, there's tons of best practice information out there on scaling, talking to a database, and even whole tutorials on how to Continue reading

Lifting the Hood on Cisco Software Defined Access

If you’re an IT professional and you have at least a minimal awareness of what Cisco is doing in the market and you don’t live under a rock, you would’ve heard about the major launch that took place in June: “The network. Intuitive.” The anchor solution to this launch is Cisco’s Software Defined Access (SDA) in which the campus network becomes automated, highly secure, and highly scalable.

The launch of SDA is what’s called a “Tier 1” launch where Cisco’s corporate marketing muscle is fully exercised in order to generate as much attention and interest as possible. As a result, there’s a lot of good high-level material floating around right now around SDA. What I’m going to do in this post is lift the hood on the solution and explain what makes the SDA network fabric actually work.

SDA’s (Technical) Benefits

Let’s examine the benefits of SDA through a technical lens (putting aside the business benefits we’ve been hearing about since the launch).

Eliminates STP (!!). How many years have we been hearing about this in the data center?? Now the same is true in the campus network as well. STP can finally be left in the Continue reading

Lifting the Hood on Cisco Software Defined Access

If you're an IT professional and you have at least a minimal awareness of what Cisco is doing in the market and you don't live under a rock, you would've heard about the major launch that took place in June: “The network. Intuitive.” The anchor solution to this launch is Cisco's Software Defined Access (SDA) in which the campus network becomes automated, highly secure, and highly scalable.

The launch of SDA is what's called a “Tier 1” launch where Cisco's corporate marketing muscle is fully exercised in order to generate as much attention and interest as possible. As a result, there's a lot of good high-level material floating around right now around SDA. What I'm going to do in this post is lift the hood on the solution and explain what makes the SDA network fabric actually work.

How I’ve Attempted to Blog More in 2017

This post has been sitting in the “drafts” folder for a while now. Clearly, since it’s August and is therefore a little late to be deciding on a plan that is supposed to carry through all 12 months of 2017. Regardless, I think it’s still worth sharing how I’ve attempted to increase the frequency of my blogging. My basic goal for 2017 is:

Create more content in 12 months than I ever have before in order to a) significantly build up the depth and breadth of knowledge on my blog, b) increase my skills as a writer, and c) continue to build this blog and the readership as a key part of my online persona and brand.

In order to achieve this goal, I’ve identified a couple of tactical objectives:

Reduce the friction between me and the keyboard; make it possible to “just write”.
Be able to “just write” anywhere. At home. On vacation. In a waiting room. On an airplane. I should also be able to start a post in one location and pick it up again in another. Indirectly this means I need to be able to write on any of my computers or mobile devices.

In order Continue reading

How I’ve Attempted to Blog More in 2017

This post has been sitting in the “drafts” folder for a while now. Clearly, since it's August and is therefore a little late to be deciding on a plan that is supposed to carry through all 12 months of 2017. Regardless, I think it's still worth sharing how I've attempted to increase the frequency of my blogging. My basic goal for 2017 is:

In order to achieve this goal, I've identified a couple of tactical objectives:

Reduce the friction between me and the keyboard; make it possible to “just write”.
Be able to “just write” anywhere. At home. On vacation. In a waiting room. On an airplane. I should also be able to start a post in one location and pick it up again in another. Indirectly this means I need to be able to write on any of my computers or mobile devices.

In order Continue reading

Troubleshooting Cisco Network Elements with the USE Method

I want to draw some attention to a new document I’ve written titled “Troubleshooting Cisco Network Elements with the USE Method“. In it, I explain how I’ve taken a model for troubleshooting a complex system–the USE Method, by Brendan Gregg–and applied it to Cisco network devices. By applying the USE Method, a network engineer can perform methodical troubleshooting of a network element in order to determine why the NE is not performing/acting/functioning as it should.

I ask that if you’re familiar with a given Cisco network platform (or platforms), that you please contribute commands that would also fit into the USE Method! My list is just a start and I welcome contributions from others in order to make it a stronger, more valuable reference.

Please check out the guide: Troubleshooting Cisco Network Elements with the USE Method

Original article: Troubleshooting Cisco Network Elements with the USE Method

Troubleshooting Cisco Network Elements with the USE Method

I want to draw some attention to a new document I've written titled “Troubleshooting Cisco Network Elements with the USE Method". In it, I explain how I've taken a model for troubleshooting a complex system-the USE Method, by Brendan Gregg-and applied it to Cisco network devices. By applying the USE Method, a network engineer can perform methodical troubleshooting of a network element in order to determine why the NE is not performing/acting/functioning as it should.

Troubleshooting Cisco Network Elements with the USE Method

The USE Method is a model for troubleshooting a system that is in distress when you don't know exactly what the nature of the problem is. For example, if users within a specific part of your network are complaining of slowness, disconnects and poor application performance, you can probably isolate your troubleshooting to 2-3 switches or routers. However, since the problem description is so vague (we all love the “it's slow!

Tools for TE with EIGRP

In response to my article about what would cause a directly connected route to be overridden, Matt Love (@showflogi) made a good observation:

Good stuff – LPM rule can be a useful tool if you want to manipulate paths without mucking with metrics, esp if using multiple protocols

— Matt Love (@showflogi) July 13, 2017

What Matt is saying is that longest prefix match (LPM) is a mechanism that can be used to steer traffic around the network in order to meet a technical or business need. This type of traffic steering is called traffic engineering (TE).

LPM refers to how route lookups work on a Layer 3 device: the longest, most-specific match is always chosen. Like I explained in the prior post, if the routing table contains 10.10.10.0/24 and 10.10.10.64/26, the latter route will be used to forward traffic to 10.10.10.100 (as an example) because a /26 is longer (ie, has a longer prefix length) and is therefore more specific. We can use this behavior to direct traffic towards 10.10.10.100 over a specific interface or via a specific path (ie, a path with Continue reading

Tools for TE with EIGRP

In response to my article about what would cause a directly connected route to be overridden, Matt Love (@showflogi) made a good observation:

Good stuff - LPM rule can be a useful tool if you want to manipulate paths without mucking with metrics, esp if using multiple protocols
— Matt Love (@checktheroads) July 13, 2017

When is a Connected Route Not Used?

I ran into this situation on a recent project and thought it would make an excellent question on an exam. It could be worded something like this:

What is the behavior of a router or Layer 3 switch when a dynamic route is learned that partially overlaps with a directly connected network?

a. The router reboots
b. The network reboots
c. That’s um-possible
d. None of the above

The answer, of course, is “d” but the specifics of what does happen is what’s interesting. First, this is the scenario I’m trying to describe in the question above:

R12#show ip route
...
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
D        10.1.14.0/24 [90/1024640] via 123.1.1.14, 00:14:37, Ethernet0/1
C        10.10.10.0/24 is directly connected, Ethernet0/0
L        10.10.10.12/32 is directly connected, Ethernet0/0
D        10.10.10.64/26 [90/1024640] via 123.1.1.14, 00:14:05, Ethernet0/1

R12 has a directly connected network 10.10.10.0/24 on its e0/0 interface. It has also learned a route for 10.10.10.64/26 via an EIGRP neighbor on its e0/1 interface. We can see both networks Continue reading

When is a Connected Route Not Used?

I ran into this situation on a recent project and thought it would make an excellent question on an exam. It could be worded something like this:

What is the behavior of a router or Layer 3 switch when a dynamic route is learned that partially overlaps with a directly connected network?

The router reboots

The network reboots

That's um-possible

None of the above

Reflecting On My First Cisco Live! Presentation

Well, I got to tick a big item off my list of goals last week. I successfully delivered a presentation at Cisco Live! in front of a large group of people. It didn’t kill me and I didn’t trip over anything and embarrass myself so no matter what, I have those two points to feel good about :-)

All joking aside, it actually went a whole lot better than that.

I’ve recently realized that I really enjoy teaching. Not in the sense that I want to be a trainer full time or have a job in a classroom, more like I feel that’s a big part of what drives me to write this blog and is why I feel (relatively) comfortable talking in front of people. As long as the subject is something that I feel I can weave some teaching/learning into, I’m comfortable to deliver it. By contrast, I would feel far less comfortable delivering something like a keynote speech or a toast at a wedding.

So along those lines, that was a big goal I set for myself in delivering my Cisco Live! (CLUS) presentation: empower the audience by sharing targeted, high-value knowledge and Continue reading

Reflecting On My First Cisco Live! Presentation

Well, I got to tick a big item off my list of goals last week. I successfully delivered a presentation at Cisco Live! in front of a large group of people. It didn't kill me and I didn't trip over anything and embarrass myself so no matter what, I have those two points to feel good about :-)

All joking aside, it actually went a whole lot better than that.

OpenVPN 2.3.17 on OpenBSD 6.0

OpenBSD 6.0–which was released Sep 1 2016 and is still receiving security updates to the base system as per OpenBSD’s policy–shipped with a package for OpenVPN 2.3.11. Below you will find a patch and instructions for using the ports system to upgrade to version 2.3.11. Note that if you’re running OpenBSD 6.1, the ports tree has been updated to 2.4.3 so all you need to do is “cvs up” and “make install”.

Instructions:

Follow the OpenBSD FAQ for instructions on how to download, verify, and extract the ports tree on your machine.
Then:

% cd ports/net/openvpn
% patch < ~/openvpn-2.3.17p0.diff
% make install

Original article: OpenVPN 2.3.17 on OpenBSD 6.0

OpenVPN 2.3.17 on OpenBSD 6.0

On Jun 21, the OpenVPN team released an update for the 2.3.x and 2.4.x branches that resolved some newly discovered security vulnerabilities. The OpenVPN team recommends that users “upgrade to OpenVPN 2.4.3 or 2.3.17 as soon as possible". OpenBSD 6.0-which was released Sep 1 2016 and is still receiving security updates to the base system as per OpenBSD's policy-shipped with a package for OpenVPN 2.3.11. Below you will find a patch and instructions for using the ports system to upgrade to version 2.

I Will Be Presenting For the First Time at CLUS 2017!

Well, it looks like another major item will get struck from my bucket list this year. I’ve been accepted to present at Cisco Live in Las Vegas this summer!

This session is designed to walk through an enterprise network and look at how EIGRP can be engineered with purpose to best suit the needs of the different areas of the network. I will focus a lot on stability and scaling EIGRP and will show the audience how, where, and when to leverage common EIGRP features such as summarization, fast timers, BFD, and wide metrics. Before getting into the nuts and bolts, I will be doing a bit of a level-set on certain EIGRP features such as queries, going active, summarization, and support for flexible network hierarchies. I will round out the session by talking about how EIGRP has been optimized for use in Cisco’s Intelligent WAN (IWAN) solution and even touch on a not-so-commonly seen application of EIGRP: EIGRP Over-The-Top. The full session agenda looks like this:

I’m actually inheriting this session from a fellow CPOC engineer, Steve Moore who, un-coincidentally, is the same S. Moore whose name is on the EIGRP RFC. Steve will be presenting a sister session Continue reading

I Will Be Presenting For the First Time at CLUS 2017!

Well, it looks like another major item will get struck from my bucket list this year. I've been accepted to present at Cisco Live in Las Vegas this summer! ? This session is designed to walk through an enterprise network and look at how EIGRP can be engineered with purpose to best suit the needs of the different areas of the network. I will focus a lot on stability and scaling EIGRP and will show the audience how, where, and when to leverage common EIGRP features such as summarization, fast timers, BFD, and wide metrics.

Five Functional Facts About OSPF

It’s funny, in my exerperience, OSPF is the most widely used interior gateway protocol because it “just works” and it’s an IETF standard which means it interops between different vendors and platforms. However, if you really start to look at how OSPF works, you realize it’s actually a highly complex protocol. So on the one hand you get a protocol that likely works across your whole environment, regardless of vendor/platform, but on the other you’re implementing a lot of complexity in your control plane which may not be intuitive to troubleshoot.

This post isn’t a judgement about OSPF or link-state protocols in general. Instead it will detail five functional aspects of OSPF in order to reveal–at least in part–how this protocol works, and indirectly, some of the complexity lying under the hood.

1. OSPF Has Its Own Best Path Decision Process

Ever looked closely at OSPF routes in the show ip route output? You’ll notice flags such as O or O IA beside the route.

O     10.1.14.0 255.255.255.0
        [110/21] via 123.1.0.18, 00:00:07, Ethernet0/0
O IA  11.11.11.0 [110/20] via 123.1.0.18, 00:00:07, Ethernet0/0
O IA  123.1. Continue reading

Five Functional Facts About OSPF

It's funny, in my experience, OSPF is the most widely used interior gateway protocol because it “just works” and it's an IETF standard which means it inter-ops between different vendors and platforms. However, if you really start to look at how OSPF works, you realize it's actually a highly complex protocol. So on the one hand you get a protocol that likely works across your whole environment, regardless of vendor/platform, but on the other you're implementing a lot of complexity in your control plane which may not be intuitive to troubleshoot.

This post isn't a judgement about OSPF or link-state protocols in general. Instead it will detail five functional aspects of OSPF in order to reveal-at least in part-how this protocol works, and indirectly, some of the complexity lying under the hood.

« Previous 1 2 3 4 5 6 … 16 Next »