Skip to content

LLDP, Priorities, and Vlan tagging

Deal with the oxford comma, I like them.

There’s been an issue at a customer’s site that’s really been bothering me. Not that there’s an issue, it’s not my fight nor have I been asked to troubleshoot it. But the scope of the problem sheds light on glaring holes in my understanding of LLDP (or link layer discover protocol for the uninitiated.) It’s just another subject I haven’t taken the time to sit down and dissect. That’s really all any of this takes, time. It’s not like you have to train to jump 10 feet, or run 10 miles. It’s taking the time to really understand a protocol and how it interacts with all the other protocols that the IEE have duct taped together. I tried to find examples on the web with packet captures or an in depth look under the hood but had very little luck, especially when looking specifically for a VoIP interaction. I want to take a pretty comprehensive look at at the LLDP interaction between a phone and a switch. I figured what better way to hold my understanding accountable than to talk about it here. In order to define my specific goals I have to give a little background.

The layout

I deal with a lot of VoIP. For most networks, we utilize vlans for our voice traffic. Now setting a port that you know a phone will be plugged into as the particular vlan that voice traffic will be on is one way of accomplishing this, but it’s less than ideal. That port becomes locked to the vlan for voice and if any users plug a PC into a port intended for phones, they now are on the wrong network and may lose access to needed resources. The solution we go for is pretty standard. We set all user facing ports to being a member of both the data and voice network vlans. The catch is that the data network is untagged, and the voice network is tagged. IP phones are able to tag themselves, while windows workstations are not. We can set the phones to tag themselves as the voice vlan and our job is done. All traffic will be on the correct subnet and no kittens are killed.

The proper way of saying this is that all user ports have a PVID which is the data vlan and are also a member of the voice vlan, whatever that is.

This works across the board with all switch manufacturers I’ve seen. The one exception is Cisco. Okay it does work, I worked out how to mimic the same functionality we see in our typical Netgear/Zyxel/Hp/ small business switches. But the issue at the customers site in question is that the engineer utilized a functionality of Cisco switches where a command specifically designates a voice vlan and relies on LLDP to dictate who uses that vlan. So there it is. That’s the issue and that’s what I’ve been working at. This method is assuming that the phone is not set to tag itself, it instead is intended that LLDP will work it’s magic and the phone will end up on the correct subnet.

  • Maybe the switch recognizes the phone as being a phone and manually places traffic from it’s MAC on the voice vlan,
  • or maybe the phone understands from the switch which vlan it should tag itself as and does this without us manually setting it.

That’s what we’re going to find out. There is a specific issue with the customer, but like I said, that’s not what this is about. The scenario however is that the Cisco dominated network is configured for a designated voice vlan while the phones themselves are tagging their vlan. I want to know any pitfalls to this or if it has any effect what-so-ever.

Cisco Primer

So to understand the whole Cisco thing. we have to go over two different way’s of working out vlans for voice traffic. The Cisco Preferred method is to utilize the defined “Voice Vlan” which relies on LLDP.

Traditional with LLDP
interface range switchport 0/1 - 24
switchport voice vlan #

This, assuming LLDP isn’t disabled will be all that’s needed on user facing ports to allow a phone also with LLDP enabled to negotiate the correct vlan. Again, we’re going to look at exactly how it does this.

The other option I worked out was to set the port as trunk and declare vlan access as well as a default vlan.

Manual with tagging.
interface range switchport 0/1 - 24
switchport mode trunk
switchport trunk allowed vlan none
switchport trunk allowed vlan # (data vlan)
switchport trunk allowed vlan # (voice vlan)
switchport trunk native vlan # (data vlan)

This will mimic what what referenced at the start of this post, the Netgear/hp small business switches. Where 1 vlan will be untagged while the other will be tagged and the phone should be configured ahead of time to tag it’s own traffic as the proper vlan. I’ve talked to a couple people about this and the fact that the port is set to “Trunk” seems to bother them. Doing what’s above will however restrict it to only those vlans specifically declared, so don’t let that bother you.

So both of the methods above are what I’m going to test. I’m going to perform packet captures to dissect what is really happening between the phone and the switch to better understand any benefits or faults over one method or the other. In order to get the answers I need though I need to be able to see VLAN tags in wireshark. Below you can see what the two configurations look like in a show run.

Screenshot from 2016-12-04 15-05-43 Screenshot from 2016-12-04 15-04-31

 

VLAN sniffing

The intent of sniffing VLAN tags brought me to an issue that I had never noticed that when sniffing traffic on a windows PC. I don’t see vlan tags. A bit of confusion and googling landed me on an intel kbs page. It turns out that this is normal, but can luckily be addressed with a quick registry edit and a healthy reboot on most newer machines. I have an Intel NIC on my windows machine and they are dominant on most so I’m going to link the kbs article here and outline it.

http://www.intel.com/content/www/us/en/support/network-and-i-o/ethernet-products/000005498.html

Adapter Driver Registry Key
e1g, e1e, e1y MonitorModeEnabled
e1c, e1d, e1k, e1q, e1r, ixe, ixn, ixt MonitorMode

The link above has this table listed with no clear way of identifying which driver you have, so I’ll clue you into that first. Head over to device manager, find your physical NIC and select properties. As depicted below, head to the Driver tab and select Driver File Details. I highlighted a couple spots where I was able to find a correlation between the chart above and my device. The chart dictates our dword.

Capture

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00nn

Pull up regedit and head here. the last bit, 00nn (those are zeros) however requires discussion, Look through all the 00 entries you have and look for a field called description. You should find an entry with a description that matches the name you see in device manager, that’s the entry you want to add the dword in. So depending on your NIC, add either.

  • MonitorMode
  • MonitorModeEnabled

And that’s it. Reboot and we should now be able to see VLAN tags in our packet captures.

VLAN tagging

Since we have that working, lets take a look at some captures with tagging. To reiterate, the phone is set to tag all of it’s own traffic to the voice vlan and LLDP is not being used. In all examples we’re using vlan id:99 for voice. We’re only going to look at layer 2 here, as layer 3 doesn’t matter to us with what we’re doing.

From the phone
No. Time Source Destination Protocol Length Info
 2 2016-12-02 21:02:58.664594 192.168.99.2 10.17.17.36 DNS 86 Standard query 0x0002 A ###############

Frame 2: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0
 Interface id: 0 (\Device\NPF_{E5C15F12-50EF-4F53-BE64-91151B1D46C3})
 Encapsulation type: Ethernet (1)
 Arrival Time: Dec 2, 2016 21:02:58.664594000 EST
 [Time shift for this packet: 0.000000000 seconds]
 Epoch Time: 1480730578.664594000 seconds
 [Time delta from previous captured frame: 0.060120000 seconds]
 [Time delta from previous displayed frame: 0.060120000 seconds]
 [Time since reference or first frame: 0.060120000 seconds]
 Frame Number: 2
 Frame Length: 86 bytes (688 bits)
 Capture Length: 86 bytes (688 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:vlan:ethertype:ip:udp:dns]
 [Coloring Rule Name: UDP]
 [Coloring Rule String: udp]
Ethernet II, Src: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8), Dst: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Destination: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Address: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Source: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Address: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 99
 101. .... .... .... = Priority: Video, < 100ms latency and jitter (5)
 ...0 .... .... .... = CFI: Canonical (0)
 .... 0000 0110 0011 = ID: 99

So the first section isn’t too important here, but you can see that it’s a DNS query. The second section is our ethernet frame and in purple we have a new section that our NIC ignored prior to the reg edit above. We see a priority value (5) and the vlan ID, 99 also represented in binary 1100011. Both of these values are defined in the phone’s config file.

From the switch
No. Time Source Destination Protocol Length Info
 3 2016-12-02 21:02:58.666011 10.17.17.36 192.168.99.2 DNS 416 Standard query response 0x0002 A ############## A ############## NS m.root-servers.net NS g.root-servers.net NS k.root-servers.net NS c.root-servers.net NS i.root-servers.net NS a.root-servers.net NS f.root-servers.net NS d.root-servers.net NS e.root-servers.net NS j.root-servers.net NS l.root-servers.net NS h.root-servers.net NS b.root-servers.net AAAA 2001:500:84::b AAAA 2001:500:a8::e AAAA 2001:500:12::d0d

Frame 3: 416 bytes on wire (3328 bits), 416 bytes captured (3328 bits) on interface 0
 Interface id: 0 (\Device\NPF_{E5C15F12-50EF-4F53-BE64-91151B1D46C3})
 Encapsulation type: Ethernet (1)
 Arrival Time: Dec 2, 2016 21:02:58.666011000 EST
 [Time shift for this packet: 0.000000000 seconds]
 Epoch Time: 1480730578.666011000 seconds
 [Time delta from previous captured frame: 0.001417000 seconds]
 [Time delta from previous displayed frame: 0.001417000 seconds]
 [Time since reference or first frame: 0.061537000 seconds]
 Frame Number: 3
 Frame Length: 416 bytes (3328 bits)
 Capture Length: 416 bytes (3328 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:vlan:ethertype:ip:udp:dns]
 [Coloring Rule Name: UDP]
 [Coloring Rule String: udp]
Ethernet II, Src: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5), Dst: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Destination: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Address: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Source: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Address: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 99
 000. .... .... .... = Priority: Best Effort (default) (0)
 ...0 .... .... .... = CFI: Canonical (0)
 .... 0000 0110 0011 = ID: 99

Again a new section shows the switch tagging the traffic as vlan 99. Even though the switch is set to have vlan 99 as it’s specific voice vlan under the voice vlan command, it’s priority value is still 0. What I mean by this is that the switch is configured the Cisco way. The port is not set to trunk, it is set to access, with the voice vlan command declaring vlan 99 like we went over above. I’m actually surprised at the lack of a Priority value.

So just from this and knowing how the switch is configured we can deter that even when operating with LLDP the phone must be expecting it’s traffic to be tagged otherwise the phone wouldn’t work at all. I’m betting when vlan tagging isn’t defined on the phone and LLDP is enabled, it will still be tagging it’s traffic just like we see in the first capture. Before I test that I want to look at the LLDP traffic.

LLDP

So the truth is if you noticed from the captures above, I don’t have a Cisco switch. Infact the only Cisco gear I have is an ASA and an Aironet. But what I do have is a couple Adtran devices. They use whats called AOS which may be different in the binaries, but the syntax is 95% the same along with functionality as well. Any commands that work on Cisco gear has worked on this gear. The underlying protocols are the same as well. LLDP is defined by the IEE, we’re not using CDP (Cisco discovery protocol) here as it would only work between a cisco switch and a cisco phone.

Disclaimer aside, first enable LLDP

lldp run
interface <any interface you want LLDP enabled on>
lldp transmit
lldp recieve

You can see we have the flexibility to enable and disable LLDP send and receive specifically here.

sitandspinMrCisco#show lldp 
Global LLDP information:
Sending LLDP packets every 30 seconds
Sending TTL of 120 seconds

The above shows my timer settings as well.

If lldp transmit is enabled, we’re seeing this every 30 seconds on all enabled interfaces. This looks like a lot but that’s really wireshark doing it’s thing. If we look individually at the flagged bits and binary bytes, it’s not nearly as bad as it looks. What we’re looking at is an LLDPDU.

LLDP from the switch
 Type: 802.1 Link Layer Discovery Protocol (LLDP) (0x88cc)
Link Layer Discovery Protocol
 Chassis Subtype = MAC address, Id: 00:a0:c8:75:1a:b5
 0000 001. .... .... = TLV Type: Chassis Id (1)
 .... ...0 0000 0111 = TLV Length: 7
 Chassis Id Subtype: MAC address (4)
 Chassis Id: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Port Subtype = Locally assigned, Id: swx 0/8
 0000 010. .... .... = TLV Type: Port Id (2)
 .... ...0 0000 1000 = TLV Length: 8
 Port Id Subtype: Locally assigned (7)
 Port Id: swx 0/8
 Time To Live = 120 sec
 0000 011. .... .... = TLV Type: Time to Live (3)
 .... ...0 0000 0010 = TLV Length: 2
 Seconds: 120
 Unknown - Unknown (3)
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0001 0001 = TLV Length: 17
 Organization Unique Code: Unknown (0x00a0c8)
 Unknown Subtype: 3
 Unknown Subtype Content: 4e657456616e74612033343438
 Port Description = swx 0/8: Fast Ethernet (BCM53xx)
 0000 100. .... .... = TLV Type: Port Description (4)
 .... ...0 0010 0000 = TLV Length: 32
 Port Description: swx 0/8: Fast Ethernet (BCM53xx)
 System Name = sitandspinMrCisco
 0000 101. .... .... = TLV Type: System Name (5)
 .... ...0 0001 0001 = TLV Length: 17
 System Name: sitandspinMrCisco
 System Description = NetVanta 3448, Version: R12.1.0, Date: Tue Jul 26 18:26:57 2016
 0000 110. .... .... = TLV Type: System Description (6)
 .... ...0 0011 1111 = TLV Length: 63
 System Description: NetVanta 3448, Version: R12.1.0, Date: Tue Jul 26 18:26:57 2016
 Capabilities
 0000 111. .... .... = TLV Type: System Capabilities (7)
 .... ...0 0000 0100 = TLV Length: 4
 Capabilities: 0x0014
 .... .... .... ...0 = Other: Not capable
 .... .... .... ..0. = Repeater: Not capable
 .... .... .... .1.. = Bridge: Capable
 .... .... .... 0... = WLAN access point: Not capable
 .... .... ...1 .... = Router: Capable
 .... .... ..0. .... = Telephone: Not capable
 .... .... .0.. .... = DOCSIS cable device: Not capable
 .... .... 0... .... = Station only: Not capable
 Enabled Capabilities: 0x0014
 .... .... .... ...0 = Other: Not capable
 .... .... .... ..0. = Repeater: Not capable
 .... .... .... .1.. = Bridge: Capable
 .... .... .... 0... = WLAN access point: Not capable
 .... .... ...1 .... = Router: Capable
 .... .... ..0. .... = Telephone: Not capable
 .... .... .0.. .... = DOCSIS cable device: Not capable
 .... .... 0... .... = Station only: Not capable
 Management Address
 0001 000. .... .... = TLV Type: Management Address (8)
 .... ...0 0011 1000 = TLV Length: 56
 Address String Length: 5
 Address Subtype: IPv4 (1)
 Management Address: 192.168.21.1
 Interface Subtype: ifIndex (2)
 Interface Number: 12
 OID String Length: 44
 Object Identifier: 0.0.0.0.1.0.0.0.3.0.0.0.6.0.0.0.1.0.0.0.2.0.0.0.1.0.0.0.2.0.0.0.2.0.0.0.1.0.0.0.1.0.0.0.12 (itu-t.0.0.0.1.0.0.0.3.0.0.0.6.0.0.0.1.0.0.0.2.0.0.0.1.0.0.0.2.0.0.0.2.0.0.0.1.0.0.0.1.0.0.0.12)
 IEEE 802.3 - MAC/PHY Configuration/Status
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1001 = TLV Length: 9
 Organization Unique Code: IEEE 802.3 (0x00120f)
 IEEE 802.3 Subtype: MAC/PHY Configuration/Status (0x01)
 Auto-Negotiation Support/Status: 0x03
 .... ...1 = Auto-Negotiation: Supported
 .... ..1. = Auto-Negotiation: Enabled
 PMD Auto-Negotiation Advertised Capability: 0x0036
 .... .... .... ...0 = 1000BASE-T (full duplex mode): Not capable
 .... .... .... ..1. = 1000BASE-T (half duplex mode): Capable
 .... .... .... .1.. = 1000BASE-X (-LX, -SX, -CX full duplex mode): Capable
 .... .... .... 0... = 1000BASE-X (-LX, -SX, -CX half duplex mode): Not capable
 .... .... ...1 .... = Asymmetric and Symmetric PAUSE (for full-duplex links): Capable
 .... .... ..1. .... = Symmetric PAUSE (for full-duplex links): Capable
 .... .... .0.. .... = Asymmetric PAUSE (for full-duplex links): Not capable
 .... .... 0... .... = PAUSE (for full-duplex links): Not capable
 .... ...0 .... .... = 100BASE-T2 (full duplex mode): Not capable
 .... ..0. .... .... = 100BASE-T2 (half duplex mode): Not capable
 .... .0.. .... .... = 100BASE-TX (full duplex mode): Not capable
 .... 0... .... .... = 100BASE-TX (half duplex mode): Not capable
 ...0 .... .... .... = 100BASE-T4: Not capable
 ..0. .... .... .... = 10BASE-T (full duplex mode): Not capable
 .0.. .... .... .... = 10BASE-T (half duplex mode): Not capable
 0... .... .... .... = Other or unknown: Not capable
 Same in inverse (wrong) bitorder
 0... .... .... .... = 1000BASE-T (full duplex mode): Not capable
 .0.. .... .... .... = 1000BASE-T (half duplex mode): Not capable
 ..0. .... .... .... = 1000BASE-X (-LX, -SX, -CX full duplex mode): Not capable
 ...0 .... .... .... = 1000BASE-X (-LX, -SX, -CX half duplex mode): Not capable
 .... 0... .... .... = Asymmetric and Symmetric PAUSE (for full-duplex links): Not capable
 .... .0.. .... .... = Symmetric PAUSE (for full-duplex links): Not capable
 .... ..0. .... .... = Asymmetric PAUSE (for full-duplex links): Not capable
 .... ...0 .... .... = PAUSE (for full-duplex links): Not capable
 .... .... 0... .... = 100BASE-T2 (full duplex mode): Not capable
 .... .... .0.. .... = 100BASE-T2 (half duplex mode): Not capable
 .... .... ..1. .... = 100BASE-TX (full duplex mode): Capable
 .... .... ...1 .... = 100BASE-TX (half duplex mode): Capable
 .... .... .... 0... = 100BASE-T4: Not capable
 .... .... .... .1.. = 10BASE-T (full duplex mode): Capable
 .... .... .... ..1. = 10BASE-T (half duplex mode): Capable
 .... .... .... ...0 = Other or unknown: Not capable
 Operational MAU Type: 100BaseTXFD - 2 pair category 5 UTP, full duplex mode (0x0010)
 Media (TIA TR-41 Committee) - Media Capabilities
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 0111 = TLV Length: 7
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Media Capabilities (0x01)
 Capabilities: 0x0003
 .... .... .... ...1 = LLDP-MED Capabilities: Capable
 .... .... .... ..1. = Network Policy: Capable
 .... .... .... .0.. = Location Identification: Not capable
 .... .... .... 0... = Extended Power via MDI-PSE: Not capable
 .... .... ...0 .... = Extended Power via MDI-PD: Not capable
 .... .... ..0. .... = Inventory: Not capable
 Class Type: Network Connectivity (4)
 Media (TIA TR-41 Committee) - Network Policy
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1000 = TLV Length: 8
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Network Policy (0x02)
 Application Type: Voice (1)
 0... .... .... .... .... .... = Policy: Defined
 .1.. .... .... .... .... .... = Tagged: Yes
 ...0 0000 1100 011. .... .... = VLAN Id: 99
 .... .... .... ...1 01.. .... = L2 Priority: 5
 .... .... .... .... ..10 1110 = DSCP Priority: 46
 End of LLDPDU
 0000 000. .... .... = TLV Type: End of LLDPDU (0)
 .... ...0 0000 0000 = TLV Length: 0

That’s a lot to digest, but really the important part is right here at the bottom in purple. We can see the switch is broadcasting to anyone listening that the voice vlan is 99 along with a COS value. Most of everything else there is ignored by the phone.

Notice that COS priority here though. We saw the phone transmitting before with a priority of 5 as well but LLDP wasn’t enabled on the phone at that time. This isn’t because it’s a universal value. When the phone was set to tag it’s vlan it was also set to declare it’s value as 5 as I mentioned before. Don’t let that matching value confuse you.

The interesting bit here though is that when the switch is sending to the phone there is no priority. I know the example above was a DNS resolv, but below we see an RTP packet with a voice payload again not using a defined Priority.

Screenshot from 2016-12-04 11-45-13

LLDP from the phone
No. Time Source Destination Protocol Length Info
 6897 2016-12-03 20:49:15.023177 ZultysTe_84:13:f8 LLDP_Multicast LLDP 225 TTL = 180 System Name = ZULTYS IP Phone System Description = ZULTYS IP Phone

Frame 6897: 225 bytes on wire (1800 bits), 225 bytes captured (1800 bits) on interface 0
 Interface id: 0 (\Device\NPF_{E5C15F12-50EF-4F53-BE64-91151B1D46C3})
 Encapsulation type: Ethernet (1)
 Arrival Time: Dec 3, 2016 20:49:15.023177000 EST
 [Time shift for this packet: 0.000000000 seconds]
 Epoch Time: 1480816155.023177000 seconds
 [Time delta from previous captured frame: 0.336598000 seconds]
 [Time delta from previous displayed frame: 1.039492000 seconds]
 [Time since reference or first frame: 90.978404000 seconds]
 Frame Number: 6897
 Frame Length: 225 bytes (1800 bits)
 Capture Length: 225 bytes (1800 bits)
 [Frame is marked: True]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:lldp]
 [Coloring Rule Name: Broadcast]
 [Coloring Rule String: eth[0] & 1]
Ethernet II, Src: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8), Dst: LLDP_Multicast (01:80:c2:00:00:0e)
 Destination: LLDP_Multicast (01:80:c2:00:00:0e)
 Address: LLDP_Multicast (01:80:c2:00:00:0e)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
 Source: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Address: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Type: 802.1 Link Layer Discovery Protocol (LLDP) (0x88cc)
Link Layer Discovery Protocol
 Chassis Subtype = Network address, Id: 0.0.0.0
 0000 001. .... .... = TLV Type: Chassis Id (1)
 .... ...0 0000 0110 = TLV Length: 6
 Chassis Id Subtype: Network address (5)
 Network Address family: IPv4 (1)
 Chassis Id: 0.0.0.0
 Port Subtype = MAC address, Id: 00:0b:ea:84:13:f8
 0000 010. .... .... = TLV Type: Port Id (2)
 .... ...0 0000 0111 = TLV Length: 7
 Port Id Subtype: MAC address (3)
 Port Id: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Time To Live = 180 sec
 0000 011. .... .... = TLV Type: Time to Live (3)
 .... ...0 0000 0010 = TLV Length: 2
 Seconds: 180
 System Name = ZULTYS IP Phone
 0000 101. .... .... = TLV Type: System Name (5)
 .... ...0 0000 1111 = TLV Length: 15
 System Name: ZULTYS IP Phone
 System Description = ZULTYS IP Phone
 0000 110. .... .... = TLV Type: System Description (6)
 .... ...0 0000 1111 = TLV Length: 15
 System Description: ZULTYS IP Phone
 Capabilities
 0000 111. .... .... = TLV Type: System Capabilities (7)
 .... ...0 0000 0100 = TLV Length: 4
 Capabilities: 0x0034
 .... .... .... ...0 = Other: Not capable
 .... .... .... ..0. = Repeater: Not capable
 .... .... .... .1.. = Bridge: Capable
 .... .... .... 0... = WLAN access point: Not capable
 .... .... ...1 .... = Router: Capable
 .... .... ..1. .... = Telephone: Capable
 .... .... .0.. .... = DOCSIS cable device: Not capable
 .... .... 0... .... = Station only: Not capable
 Enabled Capabilities: 0x0024
 .... .... .... ...0 = Other: Not capable
 .... .... .... ..0. = Repeater: Not capable
 .... .... .... .1.. = Bridge: Capable
 .... .... .... 0... = WLAN access point: Not capable
 .... .... ...0 .... = Router: Not capable
 .... .... ..1. .... = Telephone: Capable
 .... .... .0.. .... = DOCSIS cable device: Not capable
 .... .... 0... .... = Station only: Not capable
 Port Description = WAN PORT
 0000 100. .... .... = TLV Type: Port Description (4)
 .... ...0 0000 1000 = TLV Length: 8
 Port Description: WAN PORT
 IEEE 802.3 - MAC/PHY Configuration/Status
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1001 = TLV Length: 9
 Organization Unique Code: IEEE 802.3 (0x00120f)
 IEEE 802.3 Subtype: MAC/PHY Configuration/Status (0x01)
 Auto-Negotiation Support/Status: 0x03
 .... ...1 = Auto-Negotiation: Supported
 .... ..1. = Auto-Negotiation: Enabled
 PMD Auto-Negotiation Advertised Capability: 0x6c00
 .... .... .... ...0 = 1000BASE-T (full duplex mode): Not capable
 .... .... .... ..0. = 1000BASE-T (half duplex mode): Not capable
 .... .... .... .0.. = 1000BASE-X (-LX, -SX, -CX full duplex mode): Not capable
 .... .... .... 0... = 1000BASE-X (-LX, -SX, -CX half duplex mode): Not capable
 .... .... ...0 .... = Asymmetric and Symmetric PAUSE (for full-duplex links): Not capable
 .... .... ..0. .... = Symmetric PAUSE (for full-duplex links): Not capable
 .... .... .0.. .... = Asymmetric PAUSE (for full-duplex links): Not capable
 .... .... 0... .... = PAUSE (for full-duplex links): Not capable
 .... ...0 .... .... = 100BASE-T2 (full duplex mode): Not capable
 .... ..0. .... .... = 100BASE-T2 (half duplex mode): Not capable
 .... .1.. .... .... = 100BASE-TX (full duplex mode): Capable
 .... 1... .... .... = 100BASE-TX (half duplex mode): Capable
 ...0 .... .... .... = 100BASE-T4: Not capable
 ..1. .... .... .... = 10BASE-T (full duplex mode): Capable
 .1.. .... .... .... = 10BASE-T (half duplex mode): Capable
 0... .... .... .... = Other or unknown: Not capable
 Same in inverse (wrong) bitorder
 0... .... .... .... = 1000BASE-T (full duplex mode): Not capable
 .1.. .... .... .... = 1000BASE-T (half duplex mode): Capable
 ..1. .... .... .... = 1000BASE-X (-LX, -SX, -CX full duplex mode): Capable
 ...0 .... .... .... = 1000BASE-X (-LX, -SX, -CX half duplex mode): Not capable
 .... 1... .... .... = Asymmetric and Symmetric PAUSE (for full-duplex links): Capable
 .... .1.. .... .... = Symmetric PAUSE (for full-duplex links): Capable
 .... ..0. .... .... = Asymmetric PAUSE (for full-duplex links): Not capable
 .... ...0 .... .... = PAUSE (for full-duplex links): Not capable
 .... .... 0... .... = 100BASE-T2 (full duplex mode): Not capable
 .... .... .0.. .... = 100BASE-T2 (half duplex mode): Not capable
 .... .... ..0. .... = 100BASE-TX (full duplex mode): Not capable
 .... .... ...0 .... = 100BASE-TX (half duplex mode): Not capable
 .... .... .... 0... = 100BASE-T4: Not capable
 .... .... .... .0.. = 10BASE-T (full duplex mode): Not capable
 .... .... .... ..0. = 10BASE-T (half duplex mode): Not capable
 .... .... .... ...0 = Other or unknown: Not capable
 Operational MAU Type: 100BaseTXFD - 2 pair category 5 UTP, full duplex mode (0x0010)
 Media (TIA TR-41 Committee) - Media Capabilities
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 0111 = TLV Length: 7
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Media Capabilities (0x01)
 Capabilities: 0x0033
 .... .... .... ...1 = LLDP-MED Capabilities: Capable
 .... .... .... ..1. = Network Policy: Capable
 .... .... .... .0.. = Location Identification: Not capable
 .... .... .... 0... = Extended Power via MDI-PSE: Not capable
 .... .... ...1 .... = Extended Power via MDI-PD: Capable
 .... .... ..1. .... = Inventory: Capable
 Class Type: Endpoint Class III (3)
 Media (TIA TR-41 Committee) - Network Policy
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1000 = TLV Length: 8
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Network Policy (0x02)
 Application Type: Voice (1)
 1... .... .... .... .... .... = Policy: Unknown
 .0.. .... .... .... .... .... = Tagged: No
 ...0 0000 0000 000. .... .... = VLAN Id: 0
 .... .... .... ...0 00.. .... = L2 Priority: 0
 .... .... .... .... ..00 0000 = DSCP Priority: 0
 Media (TIA TR-41 Committee) - Extended Power-via-MDI
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 0111 = TLV Length: 7
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Extended Power-via-MDI (0x04)
 01.. .... = Power Type: PD Device (1)
 ..01 .... = Power Source: 1 PSE
 .... 0010 = Power Priority: High (2)
 Power Value: 2800 mW
 Media (TIA TR-41 Committee) - Inventory - Hardware Revision
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1100 = TLV Length: 12
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Hardware Revision (0x05)
 Hardware Revision: 11.0.0.5
 Media (TIA TR-41 Committee) - Inventory - Firmware Revision
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0001 0000 = TLV Length: 16
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Firmware Revision (0x06)
 Firmware Revision: 60.72.132.32
 Media (TIA TR-41 Committee) - Inventory - Software Revision
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0001 0000 = TLV Length: 16
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Software Revision (0x07)
 Software Revision: 60.72.132.32
 Media (TIA TR-41 Committee) - Inventory - Serial Number
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0001 0000 = TLV Length: 16
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Serial Number (0x08)
 Serial Number: 000bea8413f8
 Media (TIA TR-41 Committee) - Inventory - Manufacturer Name
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1010 = TLV Length: 10
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Manufacturer Name (0x09)
 Manufacturer Name: ZULTYS
 Media (TIA TR-41 Committee) - Inventory - Model Name
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 1011 = TLV Length: 11
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Model Name (0x0a)
 Model Name: ZIP 33i
 Media (TIA TR-41 Committee) - Inventory - Asset ID
 1111 111. .... .... = TLV Type: Organization Specific (127)
 .... ...0 0000 0100 = TLV Length: 4
 Organization Unique Code: Media (TIA TR-41 Committee) (0x0012bb)
 Media Subtype: Inventory - Asset ID (0x0b)
 End of LLDPDU
 0000 000. .... .... = TLV Type: End of LLDPDU (0)
 .... ...0 0000 0000 = TLV Length: 0

So looking at the LLDPDU from the phone we can see why the switch is sending frames to the phone with a default priority. The phone never told it to. Whether this can be adjusted is going to specific to each model of phone, but it looks like for this one the answer is no. We can also set a priority for a specific vlan on the switch side using qos and cos, but I don’t think I’m going to touch on that here as that would be long winded subject. The only bit I want to point to is the standards below so we know why we’re using Priority 5.

  • Classify all voice payload traffic that is used for business purposes as IP DSCP EF and CoS 5.
  • Classify all video conferencing and other interactive video for business purposes as IP DSCP AF41 and CoS 4.
  • Classify all business-critical data application traffic as IP DSCP AF21 and CoS 2.

Packets defined by LLDP

So lets get to it and see what differences we see now that LLDP is up. It’s been enabled on both the phone and the switch.

from the phone

Again we’re skipping Layer 3

No. Time Source Destination Protocol Length Info
 454 2016-12-02 20:54:25.229321 192.168.99.2 ############ RTP 78 PT=ITU-T G.729, SSRC=0x74B0DC51, Seq=23824, Time=23120

Frame 454: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0
 Interface id: 0 (\Device\NPF_{E5C15F12-50EF-4F53-BE64-91151B1D46C3})
 Encapsulation type: Ethernet (1)
 Arrival Time: Dec 2, 2016 20:54:25.229321000 EST
 [Time shift for this packet: 0.000000000 seconds]
 Epoch Time: 1480730065.229321000 seconds
 [Time delta from previous captured frame: 0.008896000 seconds]
 [Time delta from previous displayed frame: 0.008896000 seconds]
 [Time since reference or first frame: 7.756022000 seconds]
 Frame Number: 454
 Frame Length: 78 bytes (624 bits)
 Capture Length: 78 bytes (624 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:vlan:ethertype:ip:udp:rtp]
Ethernet II, Src: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8), Dst: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Destination: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Address: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Source: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Address: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 99
 101. .... .... .... = Priority: Video, < 100ms latency and jitter (5)
 ...0 .... .... .... = CFI: Canonical (0)
 .... 0000 0110 0011 = ID: 99

So the phone is taking the information from the LLDP broadcast and tagging it’s own traffic as vlan 99.

From the switch

For good measure, here’s the frame from the other direction.

No. Time Source Destination Protocol Length Info
 453 2016-12-02 20:54:25.220425 ########## 192.168.99.2 RTP 78 PT=ITU-T G.729, SSRC=0x1C00B940, Seq=15, Time=2240

Frame 453: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0
 Interface id: 0 (\Device\NPF_{E5C15F12-50EF-4F53-BE64-91151B1D46C3})
 Encapsulation type: Ethernet (1)
 Arrival Time: Dec 2, 2016 20:54:25.220425000 EST
 [Time shift for this packet: 0.000000000 seconds]
 Epoch Time: 1480730065.220425000 seconds
 [Time delta from previous captured frame: 0.000002000 seconds]
 [Time delta from previous displayed frame: 0.000002000 seconds]
 [Time since reference or first frame: 7.747126000 seconds]
 Frame Number: 453
 Frame Length: 78 bytes (624 bits)
 Capture Length: 78 bytes (624 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:vlan:ethertype:ip:udp:rtp]
Ethernet II, Src: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5), Dst: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Destination: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 Address: ZultysTe_84:13:f8 (00:0b:ea:84:13:f8)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Source: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 Address: Adtran_75:1a:b5 (00:a0:c8:75:1a:b5)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 99
 000. .... .... .... = Priority: Best Effort (default) (0)
 ...0 .... .... .... = CFI: Canonical (0)
 .... 0000 0110 0011 = ID: 99

What it all means

So it looks like in short, it shouldn’t hurt a thing if the network is trying to use LLDP to designate voice traffic and the phones are manually declaring their voice vlan. From a functional side the vlan tag and it’s priority are exactly the same in either circumstance assuming the devices have been configured properly. In fact all packets look exactly the same. There’s no way to tell the difference between an LLDP defined phone compared to a statically defined VLAN phone just by watching the packets (minus actually seeing an LLDP packet). However this is more the bare bones, “does it work” approach. If we were to follow the rules, changes to how the phones associate with the network can be done right from the switch. Create a new voice vlan? change the switch config and it will inform all the phones. There would be no need to push config updates to the phones at all. Change in COS scheme? Same thing. The LLDP packets are pretty much there for nothing if the phones aren’t using them. But lets be honest, how many times are we going to be changing a subnet around. Once we stand an infrastructure up, there has to be pretty significant reasons to tear it down or move it.

All things considered, it was still a valuable look under the hood for me.