Just to come back on this, after some testing and discussion with Aaron, here's where we are with CDP:
1) Access ports (no matter the device) - sent untagged and therefore received on whatever VLAN the access port is associated with 2) Trunk ports (except for WLCs and 4.2 APs) - sent on VLAN 1, whether or not this is the native VLAN and whether or not it is in a spanning-tree forwarding state 3) WLC and 4.2 based APs - sent untagged, and thus are associated with the native VLAN, whatever that may be Cisco has done work on the APs since 4.2 which resulted in the change for lightweight APs (apparently it was causing issues for PoE, particularly with the 1250s.) The WLCs (as of 7.0.116.0) are the only devices in the mix that are using the native VLAN for CDP. Thanks Aaron for your help and clarification on this! Jason Boyers - CCIE #26024 (Wireless) Technical Instructor - IPexpert, Inc. Mailto: [email protected] -----Original Message----- From: Aaron Leonard [mailto:[email protected]] Sent: Wednesday, September 21, 2011 10:31 PM To: Jason Boyers Cc: [email protected]; [email protected] Subject: Re: [OSL | CCIE_Wireless] CCIE_Wireless Digest, Vol 30, Issue 16 Inline: On 9/21/2011 2:58 PM, [email protected] (Jason Boyers) wrote: > Thank you for the clarification. In looking at various documents, > there is a lot of confusion. From what you are stating: > > Access Port - sent on the VLAN for which interface is configured Well, if it's an access port (untagged), then there *is* no VLAN (not from the perspective of the AP at any rate.) So the AP just sends the CDP packet out untagged (as it sends *all* packets), in that case. A *switch* has a notion of what VLAN if any is configured on an access port, but an *AP* does not. > Trunk Port - sent on VLAN 1, whether or not VLAN 1 is tagged and > whether or not VLAN 1 is allowed and in a spanning-tree forwarding > state for that port Well, an AP doesn't have the notion of "allowed" VLANs. The VLANs (i.e. subinterfaces of the LAN interface) are either configured or not. But so anyway - the AP *always* sends CDP in VLAN1, *if* its LAN port is configured for VLANs. (Here I am not sure about what if VLAN1 is in a spanning-tree blocked state - I would assume then that we would *not* send CDP, but would not wager cash on that point.) > Is that another way of putting it? That is different than my > understanding has been (where CDP is sent untagged on an access or > trunk port - period.) Yep, the notion that CDP is always sent untagged is quite incorrect. (A notion that is widely held within Cisco as well, in fact by many developers :) I would like here to post a reference to the CDP spec but unfortunately it is confidential. As I reread it for the n'th time, I can now see that there are two alternate possible interpretations: One is that, for an 802.1q encapsulated link, it should always be sent with tagged in VLAN 1, and the other is that, for a link that has both tagged and untagged frames, it should be sent untagged. Unfortunately, different implementations have adopted different interpretations. The AP's interpretation is the VLAN 1 one. > I just did a packet capture on an interface connected to a WLC. That > interface only allows specified VLANs (which don't include VLAN 1) and > a separate native VLAN (which is 999 in this case, which doesn't even > exist as a VLAN on the switch.) In the packet capture, CDP was tagged > with VLAN 999 when coming from the WLC. Everything else was tagged > with the Management VLAN (no clients currently on the WLC.) Well, I was speaking specifically about (WNBU) IOS, *not* about the WLC. With the WLC, all bets are off. I don't quite get your scenario here. You say that your native VLAN is 999, and that you see CDP tagged with VLAN 999 coming from the WLC. Now, on the WLC, you configure a "native" (i.e. *untagged*) VLAN as 0 ... so you're saying that you have some interface configured on the WLC as tagged VLAN 999? Some interface other than the management interface? I'm skeptical of this ... its sounds more like maybe the WLC just transmits CDP as untagged. > I appreciate your help in working through this, both for understanding > as well as for proper documentation on Cisco's site. It sounds like what I *really* need to do is to drive some consensus at Cisco on this point ... although higher priority (of course) is to study for my imminent CCIE lab ... Cheers, Aaron _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
