Simple IOS-XE mDNS configuration for AppleTV

This post is a small “tech note” about how to configure mDNS in IOS-XE to support AppleTV. In this example the AppleTV is located in VLAN 101 and the client in VLAN 107.

First enable mDNS and configure the switch to query for AirPlay and AirTunes services (AirTunes is necessary for AppleTV to work as well).
service-list mdns-sd MDNS-QUERY query
service-type _airplay._tcp.local
service-type _raop._tcp.local
service-routing mdns-sd
service-policy-query MDNS-QUERY 60

Configure service lists so that only AirPlay and AirTunes announcements will be accepted on the VLAN101 interfaces.
service-list mdns-sd MDNS-VLAN101-IN permit 10
match message-type announcement
match service-type _airplay._tcp.local
service-list mdns-sd MDNS-VLAN101-IN permit 20
match message-type announcement
match service-type _raop._tcp.local
service-list mdns-sd MDNS-VLAN101-IN deny 30

From the client side we only process AirPlay and AirTunes queries.
service-list mdns-sd MDNS-VLAN107-IN permit 10
match message-type query
match service-type _airplay._tcp.local
service-list mdns-sd MDNS-VLAN107-IN permit 20
match message-type query
match service-type _raop._tcp.local
service-list mdns-sd MDNS-VLAN107-IN deny 30

Because we apply the filtering on the inbound side, outbound filtering is not required.
service-list mdns-sd MDNS-VLAN101-OUT permit 10
service-list mdns-sd MDNS-VLAN107-OUT permit 10

Apply the service lists on the interfaces.
interface Vlan101
service-routing mdns-sd
service-policy MDNS-VLAN101-IN IN
service-policy MDNS-VLAN101-OUT OUT
interface Vlan107
service-routing mdns-sd
service-policy MDNS-VLAN107-IN IN
service-policy MDNS-VLAN107-OUT OUT

Validate that records are visible.
CAT3650# show mdns cache
_airplay._tcp.local PTR IN 4500/4496 0 Vl101 a431.3514.b907
_raop._tcp.local PTR IN 4500/4496 1 Vl101 a431.3514.b907
AppleTV._airplay._tcp.local SRV IN 4500/4496 1 Vl101 a431.3514.b907

Cisco IOS / IOS-XE and DHCPv6 option 52 (RFC 5417)

First post in the year 2016! Will this be “the” year for IPv6? Who knows, but at least this post will be about IPv6 which is a start right? 🙂

If you have 3500’s or newer type of access-points with AirOS 8.x software on your WLC’s you can use native IPv6 as protocol for the CAPWAP traffic. The way that AP’s initially try to discover WLC’s with IPv6 is not that different comparing with IPv4:
1. DHCPv6 Option 52
2. Multicast Discovery (L2)
3. DNS
4. Static AP priming

More than once I have used Cisco’s native DHCP server in IOS/IOS-XE to supply AP’s with information about the WLC’s (with DHCPv4 this is option 43). I wanted the same with IPv6 so I configured the following:

ipv6 dhcp pool IPV6-DHCP-VLAN106
address prefix 2002:1234:CC1E:106::/64
vendor-specific 52
suboption 1 address 2002:1234:CC1E:105::11

On the AP side something strange was happening. Instead of showing “CAPWAP Access controller: <IPv6 address> ” it showed the following output:

AP#show ipv6 dhcp interface
Vendor-specific Information options:
Enterprise-ID: 52

After more than one hour of fiddling with the configuration and troubleshooting I reached out to TAC. It turns out that the current DHCPv6 implementation on IOS and IOS-XE simply don’t support DHCPv6 option 52 (RFC 5417). Because of this TAC filled the feature enhancement CSCux73480. More information about DHCPv6 option 52 configuration for other DHCPv6 servers can be found in this document.