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

CucumberCucumber Member Posts: 192
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. :D
I hate pandas

Comments

  • 4_lom4_lom Member Posts: 485
    You have been in the business for a decade but you do not know how to spell Dynamic Trunking Protocol? Also, Pandas are awesome! :D
    Goals for 2018: MCSA: Cloud Platform, AWS Solutions Architect, MCSA : Server 2016, MCSE: Messaging

  • CucumberCucumber Member Posts: 192
    lol well English is not my primary language, please excuse my grammar failures, not saying you are a grammar **** or anything. Entschuldigung mein Freund.
    I hate pandas
  • MonkerzMonkerz Member Posts: 842
    I wish I could speak german... icon_sad.gif

    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.
  • SubnetZeroSubnetZero Member Posts: 124
    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
    :cool:
  • ColbyGColbyG Member Posts: 1,264
    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?
  • SubnetZeroSubnetZero Member Posts: 124
    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
    :cool:
  • ColbyGColbyG Member Posts: 1,264
    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.
  • SettSett Member Posts: 187
    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.
    Non-native English speaker
  • SubnetZeroSubnetZero Member Posts: 124
    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/switches/switch-guide-version1_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
    :cool:
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • ColbyGColbyG Member Posts: 1,264
    SubnetZero wrote:
    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.

    SubnetZero wrote:
    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.
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    ColbyG wrote: »
    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.
  • ColbyGColbyG Member Posts: 1,264
    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.
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • SubnetZeroSubnetZero Member Posts: 124
    ColbyG wrote: »
    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.
    ColbyG wrote: »
    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
    ColbyG wrote: »
    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...
    ColbyG wrote: »
    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
    ColbyG wrote: »
    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.
    ColbyG wrote: »
    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
    :cool:
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Turgon wrote: »
    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 **** 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)
  • vinbuckvinbuck Member Posts: 785
    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.
    Cisco was my first networking love, but my "other" router is a Mikrotik...
  • 4_lom4_lom Member Posts: 485
    Cucumber wrote: »
    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.:D (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.icon_wink.gif
    Goals for 2018: MCSA: Cloud Platform, AWS Solutions Architect, MCSA : Server 2016, MCSE: Messaging

  • reloadedreloaded Member Posts: 235
    I've found in our environment, dynamic desirable tends to be a result of laziness. This applies to trunks by themselves or etherchannel.
    Reloaded~4~Ever
  • malcyboodmalcybood Member Posts: 900 ■■■□□□□□□□
    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.
  • SubnetZeroSubnetZero Member Posts: 124
    malcybood wrote: »
    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
    SW1(config)#lldp run
    SW1(config)#lldp timer 60     
    SW1(config)#lldp holdtime 180
    SW1(config)#lldp tlv-select port-vlan
    

    Switchport config
    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
    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
    
    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
    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
    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...

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced
    :cool:
  • malcyboodmalcybood Member Posts: 900 ■■■□□□□□□□
    SubnetZero wrote: »
    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
    SW1(config)#lldp run
    SW1(config)#lldp timer 60     
    SW1(config)#lldp holdtime 180
    SW1(config)#lldp tlv-select port-vlan
    

    Switchport config
    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
    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
    
    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
    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
    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!
  • ipSpaceipSpace Member Posts: 147
    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 :)

    My Network & Security Blog with a focus on Fortigate. New post on how to create a fortigate ssl vpn.
  • ColbyGColbyG Member Posts: 1,264
    ipSpace wrote: »
    We had an issue with some users that had fast PCs that were booting up before the port was up.

    portfast
Sign In or Register to comment.