+ Reply to Thread
Results 1 to 25 of 25
  1. Senior Member
    Join Date
    Mar 2007
    Posts
    192

    Certifications
    CCNP, CCNA
    #1

    Default DTP? Really, anyone using it in a production network?

    I was wondering, if anyone has used or is using this Dinamyc Trunk Protocol thing in a production network?

    And, if so, really? You think its safe to use, does it not contradict any basic idea of having an stable network? I would rather have my trunks on or off. Even cisco recommends having your trunks on to save some seconds when the switch is loading, and for other security reasons as well.

    Personally I have never seen it in action, I have been in the bussiness for a decade, but hey, I would like to know if anyone out there is using it.

    Just wondering.

    EDIT> By the way, the question arises since Im studying just now to recertify my CCNP.
    Last edited by Cucumber; 02-06-2012 at 01:43 AM.
    Reply With Quote Quote  


  2. Login/register to remove this advertisement.
  3. NOC Ninja 4_lom's Avatar
    Join Date
    Nov 2011
    Location
    Notre Dame, IN
    Posts
    432

    Certifications
    A+, N+, S+, CCENT, CCNA, MTA x3, MCITP: EDST & EDA, AAS in Computer Networking, Axcient ACE, 70-687
    #2
    You have been in the business for a decade but you do not know how to spell Dynamic Trunking Protocol? Also, Pandas are awesome!
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    Mar 2007
    Posts
    192

    Certifications
    CCNP, CCNA
    #3
    lol well English is not my primary language, please excuse my grammar failures, not saying you are a grammar **** or anything. Entschuldigung mein Freund.
    Reply With Quote Quote  

  5. Skilled Hamburglar Monkerz's Avatar
    Join Date
    Apr 2010
    Location
    State of Dementia
    Posts
    811

    Certifications
    A+, Net+, CCENT, CCNA:R&S, CCNP:R&S
    #4
    I wish I could speak german...

    I've seen a few instances where DTP was used in the network of my current employer, but I have since corrected all instances I have found.
    Reply With Quote Quote  

  6. Senior Member SubnetZero's Avatar
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    123

    Certifications
    CCIE #32840 (RS), CCNP, CCNA (RS/SEC), FNCNE, BCNE, MCSE, MCSA, MCTS, MCITP:SA, C|EH, CCA, A+, Network+ [working on CCIE SPv3]
    #5
    No thanks!

    We hardcode everything to either static access or trunk and turn DTP off with the "switchport nonegotiate" command

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced

    Reply With Quote Quote  

  7. Senior Member ColbyG's Avatar
    Join Date
    Jan 2009
    Location
    Orlando, FL
    Posts
    1,262

    Certifications
    CCNP DC, CCNP RS, CCDP, CCIP, CCNA DC, CCNA V, JNCIA-ER, ITILv3
    #6
    I'm a bit surprised that so many are against DTP. I don't use it too frequently, but I don't really see the issue with it.

    Do you guys statically configure your etherchannels too?
    Reply With Quote Quote  

  8. Senior Member SubnetZero's Avatar
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    123

    Certifications
    CCIE #32840 (RS), CCNP, CCNA (RS/SEC), FNCNE, BCNE, MCSE, MCSA, MCTS, MCITP:SA, C|EH, CCA, A+, Network+ [working on CCIE SPv3]
    #7
    By default DTP frames are transmitted every 30 seconds which creates extra overhead. Secondly DTP is a serious security risk and if it's not disabled could be used by an attacker to form a trunk with your switch.

    Either you're going to configure a trunk or you're not...

    For EtherChannels I usually use "mode on" but sometimes use PAgP or LACP depending upon the requirements. For example when running VSS between a pair of 6500's I typically use PAgP.

    Personally as part of my layer2 hardening I will disable as much of this dynamic stuff as I can...

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced

    Reply With Quote Quote  

  9. Senior Member ColbyG's Avatar
    Join Date
    Jan 2009
    Location
    Orlando, FL
    Posts
    1,262

    Certifications
    CCNP DC, CCNP RS, CCDP, CCIP, CCNA DC, CCNA V, JNCIA-ER, ITILv3
    #8
    When configuring user-facing ports, of course you would disable DTP. That's not at all what I'm talking about. It's not a security risk when used on a port which would normally be configured as a static trunk though. You could even argue that it increases security on a port intended to be a trunk. If a user somehow plugs into a port they shouldn't and that port is configured to use DTP instead of as a static trunk, you've actually created an extra layer of security. People seem to default to the security answer despite the fact that a static trunk is theoretically less secure (and obviously no sane person would argue that DTP on user ports is a good idea). The overhead thing is a joke. We may as well disable all management protocols (brb, turning off STP) with that logic.

    Using static channels is a very bad idea. This is a much different conversation that DTP or no DTP. I've seen campuses taken down by misconfigured channels (one side on, the other side unconfigured) numerous times. I use LACP whenever humanly possible. You should really rethink your own best practices.
    Reply With Quote Quote  

  10. Senior Member Sett's Avatar
    Join Date
    Feb 2009
    Posts
    174

    Certifications
    CC[NI]P; JNCIA:Junos; JNCIS-ENT
    #9
    For me personally the DTP doesn't make any sense. I hate that it's enabled by default. I haven't worked too much on LANs though.
    Reply With Quote Quote  

  11. Senior Member SubnetZero's Avatar
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    123

    Certifications
    CCIE #32840 (RS), CCNP, CCNA (RS/SEC), FNCNE, BCNE, MCSE, MCSA, MCTS, MCITP:SA, C|EH, CCA, A+, Network+ [working on CCIE SPv3]
    #10
    Yes you make valid points however this argument is similar to the never ending battle between hardcoding full/duplex or leaving it as auto...

    That being said please don't take my overhead comment out of context, because disabling Spanning Tree in a production network is a preposterous idea.

    I agree with you in that using aggregation protocols can prevent bridging loops from forming due to misconfiguration, however we haven't had any issues with it here so telling me to reconsider my own best practices is ludicrous. If fact, maybe you should reconsider your own best practices because changes like these should be made during your maintenance windows and not in the middle of the day Again, we use mode on and don't have an issue with it, however using LACP is fine too. So I see your point on this one and wont argue you on it...

    Back to DTP now...

    As long as you're disabling it on your non-trunking access ports your method is fine too, that's your preference. There's no added benefit for me to use DTP and I prefer to hardcode mine as trunks. However even security hardening documents from reputable sources like the the NSA tell you to disable it everywhere, other docs from Cisco and the INFOSEC Institute only tell you to disable it on untrusted ports (again, it's a preference).

    http://www.nsa.gov/ia/_files/switche...ersion1_01.pdf

    Disabling Dynamic Trunking Protocol (DTP) - Packet Life

    *InfoSec Institute – IT Training and Information Security Resources – VLAN Hacking

    In the NSA's Cisco IOS Switch Security Configuration Guide:

    Note: Newer Cisco switches default to dynamic auto as opposed to dynamic desirable!

    9.5 Trunk Auto-Negotiation

    9.5.1 Vulnerability

    A trunk is a point-to-point link between two ports, typically on different network systems, that aggregates packets from multiple VLANs. Cisco implements two types of trunks: IEEE 802.1q, which is an open standard; and ISL, which is a Cisco proprietary standard.

    A port may use the Dynamic Trunking Protocol (DTP) to automatically negotiate which trunking protocol it will use, and how the trunking protocol will operate. By default, a Cisco Ethernet port's default DTP mode is "dynamic desirable", which allows the port to actively attempt to convert the link into a trunk. Even worse, the member VLANs of the new trunk are all the available VLANs on the switch. If a neighboring port's DTP mode becomes "trunk", "dynamic auto", or "dynamic desirable", and if the two switches support a common trunking protocol, then the line will become a trunk automatically, giving each switch full access to all VLANs on the neighboring switch. An attacker who can exploit DTP may be able to obtain useful information from these VLANs.

    9.5.2 Countermeasures

    Do not use DTP if possible. Assign trunk interfaces to a native VLAN other than VLAN 1.

    Switch(config)# interface fastethernet 0/1
    Switch(config-if)# switchport mode trunk
    Switch(config-if)# switchport trunk native vlan 998

    Put non-trunking interfaces in permanent non-trunking mode without negotiation.

    Switch(config)# interface fastethernet 0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport nonegotiate

    Put trunking interfaces in permanent trunking mode, without negotiation.

    Switch(config)# interface fastethernet 0/1 Switch
    (config-if)# switchport mode trunk Switch
    (config-if)# switchport nonegotiate

    Cheers!

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced

    Reply With Quote Quote  

  12. Senior Member Turgon's Avatar
    Join Date
    Apr 2007
    Location
    Great Britain
    Posts
    6,250

    Certifications
    CCIE counter..993 Lab Hours.... 532 Reading.
    #11
    Disabling spanning tree on a production network is unwise. People do stupid things so even if the design is good for loop avoidance..better safe than sorry.

    I find DTP a headache to be honest but it will have applications somewhere. For aggregated links I prefer LACP.
    Reply With Quote Quote  

  13. Senior Member ColbyG's Avatar
    Join Date
    Jan 2009
    Location
    Orlando, FL
    Posts
    1,262

    Certifications
    CCNP DC, CCNP RS, CCDP, CCIP, CCNA DC, CCNA V, JNCIA-ER, ITILv3
    #12
    Quote Originally Posted by SubnetZero
    Yes you make valid points however this argument is similar to the never ending battle between hardcoding full/duplex or leaving it as auto...
    That being said please don't take my overhead comment out of context, because disabling Spanning Tree in a production network is a preposterous idea.
    I agree with you in that using aggregation protocols can prevent bridging loops from forming due to misconfiguration, however we haven't had any issues with it here so telling me to reconsider my own best practices is ludicrous. If fact, maybe you should reconsider your own best practices because changes like these should be made during your maintenance windows and not in the middle of the day Again, we use mode on and don't have an issue with it, however using LACP is fine too. So I see your point on this one and wont argue you on it...
    Your not having experienced issues with nailing up channels is a reason to stick with a bad practice? That doesn't make a lot of sense, IMO. I try to go with logically good practices as opposed to things I know could be an issue but haven't bitten me yet. To you it's ludicrous for one to point out that your current practice is potentially dangerous? That's a funny outlook you have. And yes, disabling STP is proposterous, but so is worrying about the overhead in management protocols, which was my point. Also, you're saying you don't mind a misconfigured channel taking down your network as long as it's during a maintenance window? Seriously? You also made a silly leap that I'm doing my changes outside of maintenance windows... not sure where you got that.


    Quote Originally Posted by SubnetZero
    Back to DTP now...

    As long as you're disabling it on your non-trunking access ports your method is fine too, that's your preference. There's no added benefit for me to use DTP and I prefer to hardcode mine as trunks. However even security hardening documents from reputable sources like the the NSA tell you to disable it everywhere, other docs from Cisco and the INFOSEC Institute only tell you to disable it on untrusted ports (again, it's a preference).
    http://www.nsa.gov/ia/_files/switche...ersion1_01.pdf

    ....
    What you've quoted is essentially the same logic I argued against earlier. Again, I'm definitely not advocating running DTP on user-facing ports. But, how can you argue that running DTP on a port you would normally statically trunk isn't another security/safety measure? I'm not following your reasoning for never using it other than because everyone thinks DTP is evil. For the record, as I said earlier, I typically nail up my trunks. I'm not saying everyone should use DTP, I'm just saying I don't get the hate and that people should step back and think about it and not blindly dismiss the practice.
    Last edited by ColbyG; 02-06-2012 at 08:08 PM.
    Reply With Quote Quote  

  14. Senior Member
    Join Date
    Aug 2008
    Posts
    3,954
    #13
    Quote Originally Posted by ColbyG View Post
    I'm a bit surprised that so many are against DTP. I don't use it too frequently, but I don't really see the issue with it.

    Do you guys statically configure your etherchannels too?
    Proprietary protocol = big no no in my book, especially when your environment is heterogeneous.

    Etherchannels, no, I always lean towards LACP, simply because it's what you *have* to use with some equipment, so it's easier to standardize that all port bundles are LACP, and not have to remember that some are pagp, some are statically set, etc. And some it's an open standard that practically every network vendor implements, it's safe.
    Reply With Quote Quote  

  15. Senior Member ColbyG's Avatar
    Join Date
    Jan 2009
    Location
    Orlando, FL
    Posts
    1,262

    Certifications
    CCNP DC, CCNP RS, CCDP, CCIP, CCNA DC, CCNA V, JNCIA-ER, ITILv3
    #14
    Quote Originally Posted by Forsaken_GA View Post
    Proprietary protocol = big no no in my book, especially when your environment is heterogeneous.
    That's the best argument I've seen so far and I agree with you. 99% of the networks I touch are Cisco-only and are running load of proprietary protocols, lol. It's something to consider either way though.
    Reply With Quote Quote  

  16. Senior Member Turgon's Avatar
    Join Date
    Apr 2007
    Location
    Great Britain
    Posts
    6,250

    Certifications
    CCIE counter..993 Lab Hours.... 532 Reading.
    #15
    Quote Originally Posted by Forsaken_GA View Post
    Proprietary protocol = big no no in my book, especially when your environment is heterogeneous.

    Etherchannels, no, I always lean towards LACP, simply because it's what you *have* to use with some equipment, so it's easier to standardize that all port bundles are LACP, and not have to remember that some are pagp, some are statically set, etc. And some it's an open standard that practically every network vendor implements, it's safe.
    Inclined to agree. For all the best management tools in the world, things change and they are often not checked. Your best hope is a standards based environment in a potentially mixed vendor solution at layer 2..aggregation, spanning-tree..everything really.
    Reply With Quote Quote  

  17. Senior Member SubnetZero's Avatar
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    123

    Certifications
    CCIE #32840 (RS), CCNP, CCNA (RS/SEC), FNCNE, BCNE, MCSE, MCSA, MCTS, MCITP:SA, C|EH, CCA, A+, Network+ [working on CCIE SPv3]
    #16
    Quote Originally Posted by ColbyG View Post
    Your not having experienced issues with nailing up channels is a reason to stick with a bad practice? That doesn't make a lot of sense, IMO. I try to go with logically good practices as opposed to things I know could be an issue but haven't bitten me yet.
    I'm not disagreeing with you on this point however there's a LOT of conflicting information out there regarding this.

    Quote Originally Posted by ColbyG View Post
    To you it's ludicrous for one to point out that your current practice is potentially dangerous? That's a funny outlook you have.
    The keyword is "potentially". Listen I'm not going to keep arguing on the EtherChannel front because I agree that channel protocols are protectors

    Quote Originally Posted by ColbyG View Post
    Also, you're saying you don't mind a misconfigured channel taking down your network as long as it's during a maintenance window? Seriously? You also made a silly leap that I'm doing my changes outside of maintenance windows... not sure where you got that.
    No, I'm simply telling you that it's never happened since I know how to configure an EtherChannel. Based on how you worded it I assumed it was an unplanned outage, since it took down an entire campus and all...

    Quote Originally Posted by ColbyG View Post
    What you've quoted is essentially the same logic I argued against earlier. Again, I'm definitely not advocating running DTP on user-facing ports.
    Good so we are in agreement on this one

    Quote Originally Posted by ColbyG View Post
    But, how can you argue that running DTP on a port you would normally statically trunk isn't another security/safety measure? I'm not following your reasoning for never using it other than because everyone thinks DTP is evil.
    You misunderstood me again. I never said that. What I meant was it's a security risk on non-trunk facing ports. For me I just don't see the need to run DTP and turn it off everywhere. So we agree on this one too.

    Quote Originally Posted by ColbyG View Post
    For the record, as I said earlier, I typically nail up my trunks. I'm not saying everyone should use DTP, I'm just saying I don't get the hate and that people should step back and think about it and not blindly dismiss the practice.
    So we both agree on statically configuring our trunks too. I don't really hate DTP, I just don't see the point.

    So let's move on from this nonsense...

    I agree with you on the EtherChannel (I break best practice) however I still have no use for or care about DTP for any of my switchports...

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced

    Reply With Quote Quote  

  18. Senior Member
    Join Date
    Aug 2008
    Posts
    3,954
    #17
    Quote Originally Posted by Turgon View Post
    Inclined to agree. For all the best management tools in the world, things change and they are often not checked. Your best hope is a standards based environment in a potentially mixed vendor solution at layer 2..aggregation, spanning-tree..everything really.
    Yeah, folks forget that port bonding isn't always between network gear. In most enterprises, there are going to be some end nodes that require port bundles, especially with the virtualization trend. I've run into plenty of appliances, blade chassis, and server gear that will only do port bundling through LACP to the point that I just consider it a de facto standard. Best thing an engineer can do is to simplify their network as much as possible to make it easier to find problems, and then fix them.

    Unless you're an anal bastard who's documentation is always 100% kept up to date, and everyone knows how to find it, the best thing you can do is to remove complexity whenever possible and limit the weird ****. There will always be exceptions to the rules, but the wise engineer makes damn sure those exceptions STAY exceptions instead of becoming the new rule (or worse, obliterating the rules entirely)
    Reply With Quote Quote  

  19. M&C: Far Side of the Net vinbuck's Avatar
    Join Date
    Jul 2008
    Location
    Jackson, MS
    Posts
    773

    Certifications
    CSA (Certified Sandwich Artist - Retired), MCP, CCNP, CCNA, MTCNA, MTCRE, MTCTCE, HE IPv6 Enthusiast
    #18
    I think it's also important to realize that we each work in different environments that have different needs. There are plenty of pieces of gear that I don't run spanning tree on because i'm in a provider network and I know that for certain access segments there is only one path to each end node and the end nodes are miles apart instead of right next to each other, so it's not like someone can just plug in a patch cable and complete the loop unless they have a 10 mile fiber patch handy. It all depends on design and application.
    Reply With Quote Quote  

  20. NOC Ninja 4_lom's Avatar
    Join Date
    Nov 2011
    Location
    Notre Dame, IN
    Posts
    432

    Certifications
    A+, N+, S+, CCENT, CCNA, MTA x3, MCITP: EDST & EDA, AAS in Computer Networking, Axcient ACE, 70-687
    #19
    Quote Originally Posted by Cucumber View Post
    lol well English is not my primary language, please excuse my grammar failures, not saying you are a grammar **** or anything. Entschuldigung mein Freund.

    It's all good man. (Thank you Google Translate heh). Didn't mean to sound like a grammar ****. Just one of my pet peeves I guess. Oh, and DTP has never really made sense to me. You're either going to trunk or not. And if you're trunking when you don't mean to... well, then you have a problem.
    Reply With Quote Quote  

  21. Senior Member
    Join Date
    Nov 2004
    Location
    Ashburn, VA
    Posts
    232

    Certifications
    A+, Net+, Sec+, CCNA, CCNP
    #20
    I've found in our environment, dynamic desirable tends to be a result of laziness. This applies to trunks by themselves or etherchannel.
    Reply With Quote Quote  

  22. Senior Member
    Join Date
    Apr 2005
    Posts
    867

    Certifications
    650-987 PSDCUCAM, 642-357 DCSNS, 642-991 DCUFD, 642-993 DCUCD, RCSA-W, CCDP, CCNP, CCNA, CCDA, NCTE, NCTS, MCP 70-270, ITIL Foundations, Network+
    #21
    Isn't a combination of CDP and DTP is used to put cisco IP phones on the voice vlan if you use the switchport voice vlan command?

    I've never actually done a debug or disabled it with the switchport nonegotiate command on an access port of this kind to see what happens.
    Reply With Quote Quote  

  23. Senior Member SubnetZero's Avatar
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    123

    Certifications
    CCIE #32840 (RS), CCNP, CCNA (RS/SEC), FNCNE, BCNE, MCSE, MCSA, MCTS, MCITP:SA, C|EH, CCA, A+, Network+ [working on CCIE SPv3]
    #22
    Quote Originally Posted by malcybood View Post
    Isn't a combination of CDP and DTP is used to put cisco IP phones on the voice vlan if you use the switchport voice vlan command?

    I've never actually done a debug or disabled it with the switchport nonegotiate command on an access port of this kind to see what happens.
    I have read conflicting information about DTP and IP Phones as well. Some material says DTP negotiates the trunk with the phone, other material say it does not.

    In the begining the "switchport voice vlan" was used exclusively with Cisco phones with CDP to pass down the VVID, however now we have the ability to use this with non-Cisco IP phones as well, so how could DTP or CDP be required?

    Thery're not...

    IP Phones don't do DTP. They pull information from a TFTP server or from CDP (LLDP on non-Cisco phones and newer switches).

    Where I work we have Avaya IP phones and use the "switchport voice vlan" & "switchport nonegotiate" religiously.

    In order to make this work we disable CDP/DTP at the port level, and then enable LLDP instead. So now have LLDP passing the voice VLAN ID from Cisco to Avaya as opposed to CDP... Here is an example:

    LLDP config
    Code:
    SW1(config)#lldp run
    SW1(config)#lldp timer 60     
    SW1(config)#lldp holdtime 180
    SW1(config)#lldp tlv-select port-vlan
    Switchport config
    Code:
    interface GigabitEthernet0/8
     switchport access vlan 100
     switchport mode access
     switchport nonegotiate
     switchport voice vlan 200
     no cdp enable
     no cdp tlv server-location 
     no cdp tlv app
     spanning-tree portfast
     spanning-tree bpduguard enable
     spanning-tree guard root
    LLDP neighbor verification
    Code:
    SW1#show lldp neigh gig0/8
    Capability codes:
        (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
        (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
    Device ID           Local Intf     Hold-time  Capability      Port ID
    AVXB99C65           Gi0/8          120        B               0007.3bb9.9c65
    Total entries displayed: 1
    Code:
    SW1#show lldp neigh gig0/8 de | i Man|Mod|VLAN 200
    Management Addresses:
        Manufacturer: Avaya
        Model: 4610
        Network Policy(Voice): VLAN 200, tagged, Layer-2 priority: 6, DSCP: 46
    Verification that the port is not trunking
    Code:
    SW1#show inter gig0/8 trunk
    
    Port        Mode             Encapsulation  Status        Native vlan
    Gi0/8       off              negotiate      not-trunking  1
    Port        Vlans allowed on trunk
    Gi0/8       100,200
    Port        Vlans allowed and active in management domain
    Gi0/8       100,200
    Port        Vlans in spanning tree forwarding state and not pruned
    Gi0/8       100,200
    And finally verification that the port is in static access mode while the begotiation of Trunking = Off
    Code:
    SW1#show inter gig0/8 switchport
    Name: Gi0/8
    Switchport: Enabled
    Administrative Mode: static access
    Operational Mode: static access
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: native
    Negotiation of Trunking: Off
    Access Mode VLAN: 100 (Regional)
    Trunking Native Mode VLAN: 1 (default)
    Administrative Native VLAN tagging: enabled
    Voice VLAN: 200 (VOiP)
    Administrative private-vlan host-association: none 
    Administrative private-vlan mapping: none 
    Administrative private-vlan trunk native VLAN: none
    Administrative private-vlan trunk Native VLAN tagging: enabled
    Administrative private-vlan trunk encapsulation: dot1q
    Administrative private-vlan trunk normal VLANs: none
    Administrative private-vlan trunk associations: none
    Administrative private-vlan trunk mappings: none
    Operational private-vlan: none
    Trunking VLANs Enabled: ALL
    Pruning VLANs Enabled: 2-1001
    Capture Mode Disabled
    Capture VLANs Allowed: ALL
    If this required DTP it wouldn't work since DTP is Cisco proprietary and we have Avaya IP phones. That being said DTP can't be used to negotiate this and the material that says otherwise is wrong...
    Last edited by SubnetZero; 02-09-2012 at 10:58 PM.

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced

    Reply With Quote Quote  

  24. Senior Member
    Join Date
    Apr 2005
    Posts
    867

    Certifications
    650-987 PSDCUCAM, 642-357 DCSNS, 642-991 DCUFD, 642-993 DCUCD, RCSA-W, CCDP, CCNP, CCNA, CCDA, NCTE, NCTS, MCP 70-270, ITIL Foundations, Network+
    #23
    Quote Originally Posted by SubnetZero View Post
    I have read conflicting information about DTP and IP Phones as well. Some material says DTP negotiates the trunk with the phone, other material say it does not.

    In the begining the "switchport voice vlan" was used exclusively with Cisco phones with CDP to pass down the VVID, however now we have the ability to use this with non-Cisco IP phones as well, so how could DTP or CDP be required?

    Thery're not...

    IP Phones don't do DTP. They pull information from a TFTP server or from CDP (LLDP on non-Cisco phones and newer switches).

    Where I work we have Avaya IP phones and use the "switchport voice vlan" & "switchport nonegotiate" religiously.

    In order to make this work we disable CDP/DTP at the port level, and then enable LLDP instead. So now have LLDP passing the voice VLAN ID from Cisco to Avaya as opposed to CDP... Here is an example:

    LLDP config
    Code:
    SW1(config)#lldp run
    SW1(config)#lldp timer 60     
    SW1(config)#lldp holdtime 180
    SW1(config)#lldp tlv-select port-vlan
    Switchport config
    Code:
    interface GigabitEthernet0/8
     switchport access vlan 100
     switchport mode access
     switchport nonegotiate
     switchport voice vlan 200
     no cdp enable
     no cdp tlv server-location 
     no cdp tlv app
     spanning-tree portfast
     spanning-tree bpduguard enable
     spanning-tree guard root
    LLDP neighbor verification
    Code:
    SW1#show lldp neigh gig0/8
    Capability codes:
        (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
        (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
    Device ID           Local Intf     Hold-time  Capability      Port ID
    AVXB99C65           Gi0/8          120        B               0007.3bb9.9c65
    Total entries displayed: 1
    Code:
    SW1#show lldp neigh gig0/8 de | i Man|Mod|VLAN 200
    Management Addresses:
        Manufacturer: Avaya
        Model: 4610
        Network Policy(Voice): VLAN 200, tagged, Layer-2 priority: 6, DSCP: 46
    Verification that the port is not trunking
    Code:
    SW1#show inter gig0/8 trunk
    
    Port        Mode             Encapsulation  Status        Native vlan
    Gi0/8       off              negotiate      not-trunking  1
    Port        Vlans allowed on trunk
    Gi0/8       100,200
    Port        Vlans allowed and active in management domain
    Gi0/8       100,200
    Port        Vlans in spanning tree forwarding state and not pruned
    Gi0/8       100,200
    And finally verification that the port is in static access mode while the begotiation of Trunking = Off
    Code:
    SW1#show inter gig0/8 switchport
    Name: Gi0/8
    Switchport: Enabled
    Administrative Mode: static access
    Operational Mode: static access
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: native
    Negotiation of Trunking: Off
    Access Mode VLAN: 100 (Regional)
    Trunking Native Mode VLAN: 1 (default)
    Administrative Native VLAN tagging: enabled
    Voice VLAN: 200 (VOiP)
    Administrative private-vlan host-association: none 
    Administrative private-vlan mapping: none 
    Administrative private-vlan trunk native VLAN: none
    Administrative private-vlan trunk Native VLAN tagging: enabled
    Administrative private-vlan trunk encapsulation: dot1q
    Administrative private-vlan trunk normal VLANs: none
    Administrative private-vlan trunk associations: none
    Administrative private-vlan trunk mappings: none
    Operational private-vlan: none
    Trunking VLANs Enabled: ALL
    Pruning VLANs Enabled: 2-1001
    Capture Mode Disabled
    Capture VLANs Allowed: ALL
    If this required DTP it wouldn't work since DTP is Cisco proprietary and we have Avaya IP phones. That being said DTP can't be used to negotiate this and the material that says otherwise is wrong...
    Yeah used LLDP for various IPT deployments for Avaya and NEC.

    Got a CCME lab running via GNS3 and a couple of phones so had to lab this up.

    Disabled DTP with switchport nonegotiate command, bounced the port the phone was connected to and it registered fine so that answers that question!

    Not sure if it's the way it's worded in the SWITCH book or if this is what they mean but the way I read it, looked like DTP is used in combination with CDP to negotiate a "special trunk" when using switch port voice vlan command.

    If that is what they mean ten it's wrong!
    Reply With Quote Quote  

  25. Senior Member ipSpace's Avatar
    Join Date
    Apr 2011
    Location
    Romania
    Posts
    145

    Certifications
    FCNSP, CCNP, CCIE Written - 157 Hours
    #24
    Well in my enovironment, i see a lot of stuff

    I see "switchport access vlan 10" with specifing the "switchport mode access". That can cause troubles, by sometimes my colleagues forget or are lazy

    A new thing that i see quite often is that they do not use rapid-pvst. They use plain PVST. We had an issue with some users that had fast PCs that were booting up before the port was up.

    So i see all kind of weird stuff
    Reply With Quote Quote  

  26. Senior Member ColbyG's Avatar
    Join Date
    Jan 2009
    Location
    Orlando, FL
    Posts
    1,262

    Certifications
    CCNP DC, CCNP RS, CCDP, CCIP, CCNA DC, CCNA V, JNCIA-ER, ITILv3
    #25
    Quote Originally Posted by ipSpace View Post
    We had an issue with some users that had fast PCs that were booting up before the port was up.
    portfast
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks