BRKIOT-2109 — Connecting Oil and Gas Pipelines

Presenters:

• Rick Irons-Mclean, Oil & Gas and Energy Architecture Lead
• Jason Greengrass, IoT Solution Architect

BRKEWN-2019 — 7 Ways to Fail as a Wireless Expert

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. ?

Random Notes From My Third CPOC

I was lucky enough (volunteering for very challenging work is luck, right? ) to finish my third tour through Cisco CPOC last week. CPOC is Cisco’s Customer Proof of Concept facility where customer’s can bring their network design, build it in Cisco’s lab, and beat the hell out of it. CPOC has tons of network and compute gear, all the right testing tools and processes, and excellent work areas that cater to collaborative work and information sharing. It’s also staffed by very senior and experienced engineers.

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 Continue reading

Random Notes From My Third CPOC

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.

Label Switched Multicast – Q&A

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!

How can the mapping between a (*,G) or (S,G) and a Multicast Distribution Tree be found?

If you have a (*,G) or an (S,G), the following commands will show you which MDT is being used through the MPLS core. I find the easiest place in the network to check the mapping between a (*,G) or (S,G) and an MDT is on the Ingress PE. Two tables hold the mapping:

1 – the MFIB:

PE1#show ip mfib vrf BLUE 239.3.3.3
[...]
VRF BLUE
 (*,239.3.3.3) Flags: C
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Tunnel0 Flags: A
   Lspvif0, LSM/2 Flags: F NS
     Pkts:  Continue reading

Label Switched Multicast — Q&A

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!

Getting Traffic to a Virtual Firepower Sensor

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.

1 – Validate vSwitch Settings

This is probably not a very real-world example since most environments will be running some form of distributed vSwitch (dvSwitch) and not the regular vSwitch, but all I’ve got in my lab is the vSwitch, so work with me. The same considerations apply when running a dvSwitch.

Ensure that the port-group where you’re attaching the NGIPSv allows promiscuous mode. The NGIPSv acts as sniffer and will attempt to put its NICs into promisc mode.

Set this either at Continue reading

Getting Traffic to a Virtual Firepower Sensor

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.

Label Switched Multicast – Packet Walk

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!

The Topology

I’m using the same sample network as the previous posts with three CEs all in the same VRF, three PEs and just a single P router. Each of the CEs and PEs is multicast enabled.

The scenario I’m going to be running here is CE1 sending an ICMP echo to the group 239.23.23.23. The receivers in this group are CE2 and CE3.

Between CE1 and PE1

I’m going to just gloss over the traffic exchanged between CE1 and PE1 since nothing changes here Continue reading

Label Switched Multicast — Packet Walk

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!

Label Switched Multicast – Configuration

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!

Configuring the Provider Network

In order to keep this post on point, I’m going to start on the basis that basic routing, LDP and MP-BGP are already configured and that unicast traffic is successfully flowing between all CEs.

The basic topology being used here is the same as the one in the introduction post:

Within the Continue reading

Label Switched Multicast — Configuration

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!

Label Switched Multicast – An Introduction

There are two common methods for transporting multicast packets within an MPLS-based Layer 3 VPN:

1. Generic Routing Encapsulation (GRE) with Protocol Independent Multicast (PIM) (also known as “draft-rosen”)
2. Label Switched Multicast (LSM)

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!

Draft-rosen

All in all, draft-rosen is not all that different from running PIM-Sparse Mode (SM) in a non-MPLS network.

Draft-rosen requires that the MPLS network — the P and PE routers — all be multicast enabled and all run PIM. Each PE that is participating in the draft-rosen multicast network will form a Continue reading

Label Switched Multicast — An Introduction

There are two common methods for transporting multicast packets within an MPLS-based Layer 3 VPN:

1. Generic Routing Encapsulation (GRE) with Protocol Independent Multicast (PIM) (also known as “draft-rosen”)
2. Label Switched Multicast (LSM)

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!

2015 End of Year Blog Statistics

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.

Here are the overall statistics comparing Jan 1 – Dec 30 2015 (first number) to Jan 1 – Dec 30 2014 (second number):

The number of sessions and number of unique users clipped the 100,000 mark for the first time. Session duration fell off, but I think that is a funny metric. I’ve not bothered to investigate how Google Analytics measures that nor do I understand conceptually how it’s even possible to measure how long someone stays on a web page, so I’ve never put much stock in that metric.

New vs returning visitors are basically unchanged from last year:

The top five browsers hitting the site is precisely the same as last year:

What’s interesting here is that out of the ~138,000 sessions that hit the site in 2015, Chrome was the only browser that was used for a bigger Continue reading

2015 End of Year Blog Statistics

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.

Avoiding an ISSUe on the Nexus 5000

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.

The two major ISSU conditions on the n5k are:

1. You must unconfigure all Layer 3 features
2. The n5k must not have any Spanning Tree (STP) ports in Designated state unless the port is an Edge port.

The first one is easy: the switch cannot be doing any routing. Even if the switch is Layer 2 only, this condition will still fail if any of the following are true:

• Any Layer 3 features are enabled Continue reading

Avoiding an ISSUe on the Nexus 5000

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.

OSPF vs EIGRP for DMVPN

In this post I’m going to look at the characteristics of OSPF and EIGRP when used in a Dynamic Multipoint VPN (DMVPN). I will do my best not to play favorites and instead stick to the facts (yes, I do have a preference :-). To that end I will back everything up with data from my lab. The focus areas of the comparison will be:

• Scalability of the hub router’s control plane
• Overall control plane stability
• Traffic engineering

This post won’t go into any background on how DMVPN works. If you’re not yet familiar with DMVPN, I recommend watching these introductory videos by Brian McGahan. This post also does not do a deep dive on OSPF or EIGRP. I’m making the assumption that you’re already familiar with the different LSA types in OSPF and general functions of EIGRP.

After reading this post you should be able to describe the pros and cons of OSPF and EIGRP in the three areas listed above and incorporate this knowlege into a DMVPN design.

Continue reading

OSPF vs EIGRP for DMVPN

In this post I'm going to look at the characteristics of OSPF and EIGRP when used in a Dynamic Multipoint VPN (DMVPN). I will do my best not to play favorites and instead stick to the facts (yes, I do have a preference :-). To that end I will back everything up with data from my lab. The focus areas of the comparison will be:

• Scalability of the hub router's control plane
• Overall control plane stability
• Traffic engineering

This post won't go into any background on how DMVPN works. If you're not yet familiar with DMVPN, I recommend watching these introductory videos by Brian McGahan. This post also does not do a deep dive on OSPF or EIGRP. I'm making the assumption that you're already familiar with the different LSA types in OSPF and general functions of EIGRP.

After reading this post you should be able to describe the pros and cons of OSPF and EIGRP in the three areas listed above and incorporate this knowlege into a DMVPN design.