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.
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.
I hate pandas
Comments
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.
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:
Do you guys statically configure your etherchannels too?
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:
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.
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
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:
I find DTP a headache to be honest but it will have applications somewhere. For aggregated links I prefer LACP.
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.
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.
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.
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.
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.
I'm not disagreeing with you on this point however there's a LOT of conflicting information out there regarding this.
The keyword is "potentially". Listen I'm not going to keep arguing on the EtherChannel front because I agree that channel protocols are protectors
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...
Good so we are in agreement on this one
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.
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:
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)
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.
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
Switchport config
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: 1SW1#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: 46Verification that the port is not trunking
And finally verification that the port is in static access mode while the begotiation of Trunking = Off
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:
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!
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.
portfast