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

Cucumber

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.

4_lom

You have been in the business for a decade but you do not know how to spell Dynamic Trunking Protocol? Also, Pandas are awesome!

Cucumber

lol well English is not my primary language, please excuse my grammar failures, not saying you are a grammar **** or anything. Entschuldigung mein Freund.

Monkerz

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.

SubnetZero

No thanks!

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

ColbyG

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?

SubnetZero

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

ColbyG

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.

Sett

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.

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

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!

Turgon

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.

ColbyG

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_GA

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.

ColbyG

Forsaken_GA wrote: »

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.

Turgon

Forsaken_GA wrote: »

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.

SubnetZero

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

Forsaken_GA

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)

vinbuck

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.

4_lom

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.

reloaded

I've found in our environment, dynamic desirable tends to be a result of laziness. This applies to trunks by themselves or etherchannel.

malcybood

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.

SubnetZero

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

malcybood

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!

ipSpace

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

ColbyG

ipSpace wrote: »

We had an issue with some users that had fast PCs that were booting up before the port was up.

portfast