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.

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!

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.

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

I got an interesting email from Ying Lu who had read my posts on LSM: I am curious about the Ethernet DA and codepoint used for multicast MPLS. Previously, I understand that: Ethernet DA is unicast MAC of nexthop of each replication leg. codepoint is 0x8847 However, looking at RFC5332, I am not so sure... Quote: "Ethernet is an example of a multipoint-to-multipoint data link. Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.

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.