In a throwback to the problems I dealt with using AirPlay across VLANs, I recently jumped through similar hoops for Sonos speakers. There are many forum and blog posts out there that describe (or attempt to describe) how to make this work, however all of the ones I read suffered from one or both of these problems:

1. Their instructions had errors (eg, reversing the upstream and downstream interfaces when talking about multicast).
2. They don't have a diagram of traffic flow! Every network engineer knows that a diagram is a must when trying to understand how two systems are talking to each other.

This post will dive deep on what's happening on the wire when a Sonos controller (eg, your mobile phone running the Sonos app) tries to talk with the players (the speakers) on the network. The focus will be how to make this process work when those two devices are in different VLANs.

What you read below works successfully with Sonos Beam, Sonos Sub, and Sonos Move using the Sonos S1 app.

This is a running list of unusual data found in the Domain Name System.

Typically, DNS stores name-to-IP (for example, foo.example.net -> 192.0.2.123) and IP-to-name mappings (i.e., the inverse). But, the DNS is arguably the biggest, most distributed key/value store on the planet, making it a great place to stash all kinds of simple data.

Consider for a moment that you have an application running on a server that needs to push some data out to multiple consumers and that every consumer needs the same copy of the data at the same time. The canonical example is live video. Live audio and stock market data are also common examples. At the re:Invent conference in 2019, AWS announced support for multicast routing in AWS Virtual Private Cloud (VPC). This blog post will provide a walkthrough of configuring and verifying multicast routing in a VPC.

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.

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 (@thatmattlove) 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).

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?

1. The router reboots
2. The network reboots
3. That's um-possible
4. None of the above

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.

Presented by: Russ White, LinkedIn

Presented by: David Prall, Communications Architect, Cisco

For reference, David is the "father of IWAN".

This session was not what I was expecting. I was expecting design and architecture, but it was all about features in IOS and IOS-XE (eg, FHRPs, talked about routing protocol timers, PfRv3, BFD). I guess I need to pay more attention to the session code (RST == routing; ARC == architecture).

Presenters:

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

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!

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:

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!

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.

Mohamed Anwar asked the following question on my post "4 Types of Port Channels and When They're Used".

"I need a clarification, where if a member link fails, what will happen to the traffic already sent over that link ? Is there any mechanism to notify the upper layer about the loss and ask it to resend ? How this link failure will be handled for data traffic and control traffic ?"

— Mohamed Anwar

I think his questions are really important because he hits on two really key aspects of a failure event: what happens in the data plane and what happens in the control plane.

A network designer needs to bear both of these aspects in mind as part of their design. Overlooking either aspect will almost always open the network up to additional risk.

I think it's well understood that port channels add resiliency in the data plane (I cover some of that in the previous article). What may not be well understood is that port channels also contribute to a stable control plane! I'll talk about that below. I'll also address Mohamed's question about what happens to traffic on the failed link.

As I've written about previously (The Importance of BGP NEXT_HOP in L3VPNs), the BGP NEXT_HOP attribute is key to ensuring end to end connectivity in an MPLS L3VPN. In the other article, I examine the different forwarding behavior of the network based on which of the egress PE's IP addresses is used as the NEXT_HOP. In this article I'll look at the subnet mask that's associated with the NEXT_HOP and the differences in forwarding behavior when the mask is configured to different values.

There is a lot of (mis-)information on the web stating that the PE's loopback address — which, as I explain in the previous article, should always be used as the NEXT_HOP — must have a /32 mask. This is not exactly true. I think this is an example of some information that has been passed around incorrectly, and without proper context, and is now taken as a rule. I'll explain more about this further on in the article.

In an MPLS network with L3VPNs, it's very easy for the NEXT_HOP attribute of a VPN route to look absolutely correct but be very wrong at the same time. In a vanilla IP network, the NEXT_HOP can point to any IP address that gets the packets moving in the right direction towards the ultimate destination. In an MPLS network, the NEXT_HOP must get the packets moving in the right direction but it must also point to the exact right address in order for traffic to successfully reach the destination.

Presenter: Arkadiy Shapiro, Manager Technical Marketing (Nexus 2000 - 7000) @ArkadiyShapiro

"You could say I'm obsessed with BFD" -Arkadiy

Fast failure detection is the key to fast convergence.

Presenters: Dave Zacks, Distinguished Engineer; Peter Zones, Principle Engineer

History has been: 10x performnce increase at 3x the cost. 40Gb broke that model -> 100Gb PHYs were very expensive; industry needed/wanted an intermediate step.

I like MPLS. And I don't necessarily mean as a solution to solve a problem, but as something to configure in the lab. It's fun to build things that do something when you're done. Setting up OSPF or EIGRP and being able to traceroute across routers is meh. But configuring MPLS with all the associated technologies — an IGP, LDP, MP-BGP, — and then getting all of them working in unison... when you get the traceroute working, it's rewarding.

Here's something to keep an eye out for when you're troubleshooting MPLS: An LFIB entry (that is, the Label Forwarding Information Base) that states "No Label" versus one that states "Pop Label". These mean very different things and can be the difference between a working Label Switched Path (LSP) and a non-working LSP.

Think about this for a minute: An MPLS network with a two Provider Edge (PE) routers and some Provider (P) routers. The P routers have no VRFs configured on them and therefore have no routes whatsoever for any of the customer networks. A customer then does a traceroute from one of their sites, across the MPLS cloud, and into one of their other sites. The traceroute output shows the P routers as hops along the path.

How is it possible for the P routers to reply to the traceroute if they don't have routes back to the customer network?

Let's take a look at EIGRP and the state a route can get into where EIGRP tells you "FD is Infinity".

Here's the scenario: An enterprise network with an MPLS core and two branch locations connected to their own Provider Edge (PE) router. In addition to the MPLS link, the PEs are also connected via a DMVPN tunnel. The PEs are peering via iBGP (of course) and are also OSPF neighbors on the DMVPN. Both Customer Edge (CE) routers at the branch are OSPF neighbors with their local PE.

Task: Use the high speed MPLS network as the primary path between the CE routers and only use the DMVPN network if the MPLS network becomes unavailable.

Question: Is the solution as simple as adjusting the Admin Distance (AD) so that the iBGP routes are more preferred?

In Cisco IOS packets are forwarded through the router (or Layer 3 switch) by Cisco Express Forwarding (CEF). A data structure called the CEF table contains a list of known IP prefixes and the outgoing interface that packets should be put on in order to get them onwards to their destination. That's well and good. But how do the IP prefixes make it into the CEF table? To answer that question you have to work backwards and understand the order of operations that IOS goes through in order for a prefix to make it into the CEF table.

If you've ever done a traceroute from one IOS box to another, you've undoubtedly seen output like this:

R8# traceroute 192.168.100.7
Tracing the route to 192.168.100.7
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.0.1 4 msec 3 msec 4 msec
  2 192.168.100.7 4 msec *  0 msec

That msec * msec output. Why is the middle packet always lost?? And why only on the last hop??

This is a quick calculator I came up that I could use in the CCIE lab to translate between various IPv4 header QoS markings. As long as I could remember how to draw out the calculator, all I had to do was some basic math and I could translate between markings quite easily.

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.

I'm not sure why I've taken such an interest in mDNS, service discovery, and the Bonjour protocol, but I have. It probably has something to do with my not being able to use AirPlay at home for such a long time because, like any true network geek, I put my wireless devices on a separate VLAN from my home media devices. I mean, duh. So now I keep an eye out for different methods of enabling mDNS in the network in anticipation of my own experience in my home network becoming one of my customer's experience in their enterprise network.

As I've written about in the past (here), Apple's AirPlay technology relies on Bonjour which is Apple's implementation of "zero config" networking. One of the things that Bonjour enables is the automatic discovery of services on the network. For example, an Apple TV might advertise itself as being able to receive AirPlay streams. An iPad that is looking for AirPlay receivers would use Bonjour to discover the Apple TV and present it to the user as an AirPlay destination. Both the Apple TV and iPad do all this without any user intervention or configuration (hence the "zero config" part).

That's fine and dandy but what my earlier article focused on was how Bonjour broke down in a network where what I'll call the "server" and the "client" are not in the same Layer 2 domain/VLAN. This is because the service discovery aspect of Bonjour relies on link-local scope multicast. These packets will not cross Layer 3 boundaries in the network.

As a follow-up to my previous article on Port Channels titled "4 Types of Port Channels and When They're Used" I wanted to talk a bit about the long-standing rule that says you should always create your Etherchannel (EC) bundles with a number of links that works out to a power of two (ie, 2,4 or 8 links). That rule is less applicable today than it used to be.

The other day I was catching up on recorded content from Cisco Live! and I saw mention of yet another implementation of port channels (this time called Enhanced Virtual Port Channels). I thought it would make a good blog entry to describe the differences of each, where they are used, and what platforms each is supported on.

We're all hardcore network engineers here right? We all sling packets using nothing but the CLI on our gear? We've all got the "CLI OR DIE" bumper sticker? OK. We're all on the same page then. So, when you're configuring Cisco Identity Services Engine (ISE) and the documentation says it's mandatory to enable "ip http server" on your switches in order to do central web authentication (CWA) (ie, the captive portal for authenticating users on guest devices) that probably makes you uncomfortable right?

Fear not. It's not as bad as it sounds. I'll explain why.

The shared services area of the network is meant to provide common services — such as DNS, DHCP, and Internet access — to multiple logical networks/VRFs/customers. Cisco publishes a validated design for shared services that describes the use of multiple virtual firewalls and routers to provide connectivity between the shared services module and the VRFs in the network. I'm going to describe a method of collapsing the shared services firewalls and virtual routers into a single instance running on a single box using some of the features found in Juniper's Junos platform.

I attended the Cisco Plus Canada Roadshow in Calgary recently and sat in on a day of presentations related to Cisco's data center/cloud offerings. The sessions where quite good and I ended up taking quite a few notes. I thought I'd blog my notes in order to share what was presented.

The four sessions were:

• Journey to the Cloud
• Cisco UCS
• Data Center Networking
• Powering the Cloud

A great little "feature" of Cisco's Identity Services Engine is that out of the box, the administrator account expires after 45 days if the password is not changed during that time. The documentation says that if you have trouble logging in you should click the "Problem logging in?" link and use the default administrative user/pass. This is of course ridiculous and does not work.

Below are the steps for properly resetting an admin password and for changing the security policy so the lockout doesn't happen again.

This post is going to provide a very basic introduction to configuring VRFs on Cisco IOS and Juniper's Junos. There's so many configuration combinations and options for virtual routing that it would be impossible to go through everything in great detail. At the end of the post I'll provide links to documentation where you can get detail if you want it.

All network engineers should be familiar with the method for virtualizing the network at Layer 2: the VLAN. VLANs are used to virtualize the bridging table of Layer 2 switches and create virtual switching topologies that overlay the physical network. Traffic traveling in one topology (ie VLAN) cannot bleed through into another topology. In this way, traffic from one group of users or devices can be kept isolated from other users or devices.

VLANs work great in a Layer 2 switched network, but what happens when you need to maintain this traffic separation across a Layer 3 boundary such as a router or firewall?