Author Archives: packetmischief.ca
Author Archives: packetmischief.ca
At Cisco's GSX conference at the start of FY17, the DevNet team made a programming scavenger hunt by posting daily challenges that required using things like containers, Cisco Shipped, Python, and RESTful APIs in Cisco software in order to solve puzzles. In order to submit an answer, the team created an API that contestants had to use (in effect creating another challenge that contestants had to solve).
This post contains the artifacts I created while solving some of the challenges.
I'm a big fan of Let's Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let's Encrypt doesn't have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let's Encrypt software client and the Let's Encrypt web service.
Since the protocols that Let's Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:
NSF and GR are two features in Layer 3 network elements (NEs) that allows two adjacent elements to work together when one of them undergoes a control plane switchover or control plane restart.
The benefit is that when a control plane switchover/restart occurs, the impact to network traffic is kept to a minimum and in most cases, to zero.
Presenter: Paul Lysander, Technical Marketing Engineer, Cisco
Presenter: Fred Niehaus, Technical Marketing Engineer, Cisco Wireless Networking Group
Presented by Muhammad A Imam, Sr Manager Technical Marketing Engineering
Presenters:
Presenters:
Presenter: Steven Heinsius, Product Manager, Enterprise Networking Group
I'm hoping the title of this session could also be “7 Ways to not be a TOTAL Wireless Noob” since that's more my level. ?
I know it's cliche and I know I'm biased because I have an @cisco.com email address, but I've truthfully never seen anything like CPOC before. And the customer's I've worked with at CPOC haven't either. It's extremely gratifying to take something you built “on paper” and prove that it works; to take it to the next level and work those final kinks out that the paper design just didn't account for.
If you want more information about CPOC, get in touch with me or leave a comment below. Or ask your Cisco SE (and if they don't know, have them get in touch with me).
Anyways, on to the point of this post. When I was building the topology for the customer, I kept notes about random things I ran into that I wanted to remember later or those “oh duh!” moments that I probably should've known the answer to but had forgotten or overlooked at the time. This post is just a tidy-up of those notes, in no particular order.
This post is the last one I'm planning in this series on Label Switched Multicast (LSM). The questions & answers below are meant to expand on topics from the previous posts or address topics that weren't mentioned in the previous posts at all.
If you're not familiar with LSM yet then this Q&A likely won't make much sense to you and I recommend you go back and read through the previous posts.
Please post a comment if one of the answers isn't clear or you have additional questions!
I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.
Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.
Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.
This post is going to follow a multicast packet as it moves through a sample MPLS network using Label Switched Multicast (LSM). I'll show how the packet moves through the network by looking at the forwarding tables on different routers and also by doing some packet captures.
This post is part of a series I'm writing on LSM and if you're not already familiar with LSM, I recommend you go back and read the previous posts.
After reading this post you will be able to precisely describe how LSM forwarding works in the data plane and will be able to do some basic troubleshooting.
Let's get into the lab!
In the previous post (Label Switched Multicast - An Introduction) in this series on Label Switched Multicast (LSM) I introduced the concepts behind LSM and draft-rosen, the two most poplar methods for transporting multicast traffic through MPLS Layer 3 VPNs.
In this article I will talk through the configuration of LSM on the PE and P routers and get to the point where two CEs are successfully passing multicast traffic via the MPLS network. All of the configuration examples will be relevant to Cisco IOS.
As was the case in the introduction article in the series, it's best if you already have a good understanding of multicast and MPLS before reading this article.
At the end of this article you'll be able to start configuring your own LSM environment using the configuration samples here as a template.
To the CLI!
There are two common methods for transporting multicast packets within an MPLS-based Layer 3 VPN:
There's also a third method which uses Resource Reservation Protocol-Traffic Engineering (RSVP-TE) but I'm not going to get into that one.
In this first post in a series on LSM, I'll describe how draft-rosen works, how LSM works, and then compare and contrast the two. Subsequent posts will focus solely on LSM.
At the end of this post, you will be able to describe conceptually how the control and data planes work with LSM and what the pros and cons are of LSM as compared to draft-rosen.
I will not be covering any theory on multicast or MPLS and will instead recommend that you be familiar with both topics before reading further.
Here we go!
Happy New Year! As is my tradition, here are the 2015 blog statistics as compared to 2014.
I'm pretty excited that once again readership and overall reach of this blog has increased by double digits. I'm looking forward to growing these numbers and creating challenging and interesting new content in 2016.
The idea for this post came from someone I was working with recently. Thanks Fan (and Carson, and Shree) :-)
In Service Software Upgrade (ISSU) is a method of upgrading software on a switch without interrupting the flow of traffic through the switch. The conditions for successfully completing an ISSU are usually pretty strict and if you don't comply, the hitless upgrade can all of a sudden become impacting.
The conditions for ISSU on the Nexus 5000 are pretty well documented (cisco.com link) however, there are a couple bits of knowledge that are not. This post is a reminder of the ISSU conditions you need to comply with and a call out to the bits of information that aren't so well documented.