• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Switch

NetFlow-Lite on Catalyst 2960-X

04/19/2015 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Several months ago, sFlow became instrumental in figuring out the issue with HP switches that we inherited. Just to give you an idea of what the issue was, the HP switches would sporadically drop off the network but the user data traffic was still flowing. Good thing it was only the management traffic that was dropping and not user traffic. With the help of sFlow collector, I was able to correlate the timestamps of when several HP switches went down and I found out that MLD (Multicast Listener Discovery) was the culprit. Tried to search the web for some answers but no luck. I upgraded the code of the switches but still no luck. Finally, I decided to contact HP Tech Support since they offer a lifetime warranty on hardware and software. When the tech support asked for the config, he saw that igmp querier was turned on and when we turned it off the problem never came back. Since we’ve been replacing the HP switches with Cisco Catalyst switches, I wanted to replicate some level of the sFlow functionality. Luckily, the Catalyst 2960-X supports NetFlow-Lite.

What is NetFlow-Lite?

Cisco defines it as shown below. If you want to read more about NetFlow-Lite, please read this. To me, it’s a way for a network professional to see some visibility of what’s on the wire and gather statistics.

NetFlow-Lite collects packets randomly, classifies them into flows, and measures flow statistics as they pass through the switch. It is a true flow-based traffic-monitoring mechanism that conserves valuable forwarding bandwidth when exporting flow-based data for analysis and reporting.

Prior to sFlow and NetFlow-Lite, I was somewhat exposed with NetFlow but it was very limited implementation. That NetFlow implementation was good enough for what we used it for. Besides, the traffic generated by devices and/or computers on the network were very specific to the business applications and the computers were locked down tight so it was not needed at all. The places where we needed application visibility had protocol analyzers deployed so there was not a whole lot of push to deploy NetFlow.

NetFlow-Lite is not available in all Catalyst switches, I believe it was first supported on Catalyst 4948 platform and now being supported on newer Catalyst switches. The NetFlow-Lite requires the FPGA (Field-Programmable Gate Array) that contains the logic to implement NetFlow engine. Without it, then there won’t be support of NetFlow-Lite. Hence, no support on older platforms.

NetFlow-Lite Configuration

If you want to know what the commands do, please visit the configuration guide here.

flow record netflow
 match datalink mac source address input
 match datalink mac destination address input
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match ipv6 protocol
 match ipv6 source address
 match ipv6 destination address
 match transport source-port
 match transport destination-port
 collect transport tcp flags
 collect interface input
 collect flow sampler
 collect counter bytes long
 collect counter packets long
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!
flow exporter collector
 description To NetFlow Collector
 destination 192.168.1.100
 source Vlan100
 transport udp 9985
 template data timeout 60
 option interface-table
!
flow monitor netflow
 record netflow
 exporter collector
 cache timeout active 30
!
sampler netflow
 mode random 1 out-of 32
!
!
interface range Gi1/0/1 - 48
 ip flow monitor netflow sampler netflow input
!
interface range Te1/0/1, TeX/0/1
 ip flow monitor netflow sampler netflow input

NetFlow/sFlow Collector

There are many vendors out there that sell flow collector software. Vendors out there like inMon (sFlow creator), Plixer, ntop, SolarWinds, etc. Make sure that they support NetFlow v9 or IPFIX since that’s the format that NetFlow-Lite can export to. Most of these vendors have trial software that you could use to give you a demo of their product. I am sure they’ll be happy to do a webinar so that they could introduce you to their product before starting to play with their software.

Thoughts

While NetFlow-Lite gave us some visibility, I noticed that sFlow provided more information so it is still better than not having any visibility at all. If your switches are capable of doing NetFlow-Lite, I suggest you do some trial to see if it’s going to be helpful for your environment. For us, it’s definitely helpful to have visibility so it is still being used. Another pretty cool feature that I find it very convenient is the fact that it could tell you the switch and port number of the device you’re looking for. While it’s not quite of a big deal to just log in to routers and switches to trace the device you’re looking for, it’s rather inconvenient to do so, especially if you implement two-factor for your switch-based authentication.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Same Data and Voice VLAN

12/24/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Yes, it’s not the best practice to put both data and voice traffic in the same VLAN and subnet, but I’ve recently encountered it in production and caused us some head scratching scenario. While it was probably best to redesign the whole thing since it doesn’t follow best practices, it was not going to fly in this case.

Configuration

The stack’s configuration was copied from an existing Catalyst 3750-X production switch. For the most part, it’s a basic configuration that you will encounter in a lot of production switches. Some of the configurations are the following: AAA, BPDU Guard, PortFast, Storm Control, Access and Voice VLAN (same VLAN number), etc. The 3750-X stack’s configuration was not changed for more than two years. There were no issues or complaints from the clients so it was pretty much safe to copy the configuration to the new Catalyst 2960-X stack. This stack will be the new location of the same users of the 3750-X stack – just moving to a new location.

Issue

The desktop support guy started hooking up Avaya phones and desktops to the switch and noticed that all desktops and phones connected to switch 1 (two in a stack) were not communicating to the network. The desktops and phones weren’t getting IP addresses, but once he connects to switch 2 everything started to work. The interface configurations on both switches were configured the same but for whatever reason it wasn’t working. I rebooted switch 1 and all the desktops and phones connected to it started communicating to the network.

Several hours later, the desktop support guy said that everything connected to switch 2 stopped working. I decided to reboot the whole stack at this point. Before I rebooted the stack, I noticed that one of the switches was in EX4 and the other one was in EX5. Normally, there would be a version mismatch error when there are two different IOS installed and shouldn’t join the stack, but on this particular instance both switches were in the stack. I decided to upgrade the EX4 switch to EX5 since that is the latest code anyway and we’re making that as a standard IOS.

After upgrading and rebooting the stack, I still noticed that computers and phones on switch 2 were not communicating. At that point, our client was now panicking because they were not compliant with their contract to their client. That said, we decided to replace the whole stack with new switches. The switch replacement worked for a while but the issue came back which we kind of suspected anyway – we were not fully convinced that it would resolve the issue. Since we’ve been using the Catalyst 2960-X with EX5 code for several months now, we know it works just fine with our standard configuration. The only thing different with this stack and others was the same voice and data VLAN. While the switch is solid, we’ve hit bugs starting with EX1 all the way to EX4. That said, I begun to suspect that we might be hitting a bug in EX5, so I decided to open a TAC case while it was on the working state.

Troubleshooting

A Cisco TAC engineer contacted via e-mail me to troubleshoot the issue since it was working at the time I opened the case. As usual, the first thing I had to give them was show tech output. I still do not know why I do not include that by default when opening a case.  Anyway, as mentioned, the issue came back and I engaged the TAC engineer as soon as I was informed it stopped working.

The TAC engineer started checking some stuff up to try diagnose the issue. The first thing he mentioned is the voice and data VLAN being the same and it’s not a recommended practice. I agreed with him but I also reminded him that we have this deployed in two locations and were working fine using Catalyst 3750-X. He even asked me to connect to those switches so he could see it in his own eyes.

Upon issuing few show commands, we finally found some clue on what the problem was. There was no spanning tree instance on the interfaces where the phones and desktops were connected to. It acted as if there was nothing connected to the port even though the switch sees something connected to those ports. He decided to take out the switchport voice vlan vlan-id  and the desktop started pinging and spanning tree instance on the port showed forwarding.

While the configuration worked for desktops, I still needed the phones to work. Having only switchport access vlan vlan-id on the port won’t work with the phones even if I separated phones and desktop connections. That said, we needed a way to configure the port for the phones to also work. At the time, I only knew two ways of configuring a port with phones and data connected to the switch: configuring access vlan and voice vlan commands on the interface and configuring the interface as a trunk with native VLAN set for data. Essentially, they will act the same thing so we didn’t want to do that.

Upon him talking to his colleague(s) and probably done his research, he came back and said we’re going to try the switchport voice vlan dot1p command. That solved the issue! While he explained what the command did, I was not quite happy with his explanation because I felt it was incomplete, so I decided to read the configuration guide and was quite disappointed it didn’t have more information about it.

If you do a search, you will find plenty of information about the command, which I hoped the configuration guide would have. From what I’ve gathered both online and from the TAC engineer, if configured, the switch will instruct the phone to use VLAN 0 for its voice traffic and also mark its voice traffic with their proper CoS values, 5 or 3 depending on what traffic it is. Once the frame is received, the voice traffic with VLAN 0 will be accepted and drop the voice and data traffic in the same VLAN configured on the port – access vlan command.

Thoughts

While the dot1p configuration worked, I still would’ve preferred to have two different VLANs for both data and voice which is the standard configuration anyway in our environment. But, for whatever reason, they decided to design it this way and it’s going to stay that way. Maybe when it breaks that’s when they are going to decide to separate it, but at this point we had to choose the battle we were going to fight.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

VLAN Trunking Protocol (VTP)

02/09/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

VLAN Trunking Protocol is a Cisco proprietary protocol that allows the switch to propagate VLANs. Some may argue that it is poorly named protocol since the name implies that it has to do something with trunking VLANs. Maybe the name should’ve been VLAN Propagation Protocol (VPP)? I may have taken the name and the thought that the protocol is poorly named from Jeremy Cioara. It’s hard to tell now since I’ve watched a lot of videos and read a lot of books, blogs, and discussion forums.

As I was reading the CCNP SWITCH OCG book, a way for me to refresh my BCMSN knowledge, I was curious about what the book says regarding VTP v1 and v2 transparent mode.

In VTP version 1, a transparent mode switch does not even relay VTP information it receives to other switches unless its VTP domain names and VTP version numbers match those of the other switches. In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting.

On Cisco’s documentation page, it says something different than the book.

Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Although VTP version 2 supports only one domain, a VTP version 2 transparent switch forwards a message only when the domain name matches.

Since the book and the documentation page conflicts with each other, it’s time to put this to the test to end this confusion once and for all.

Switch Topology

Just a simple three-switch topology to test if VLANs will propagate when VTP Transparent mode is in the middle.

VTP

Configuration

Our first test is configured the same for all the necessary interfaces of the switches. The configuration is shown below for reference. Since we’re going to play with different VTP domain names, we’ll need to turn off the DTP as shown below.

interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate

Switches that are in factory default settings have NULL domain or a blank domain name and as soon as they hear the first VTP advertisement from another switch who has VTP configured then it will inherit that name and start updating its database.

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#vtp mode server
Device mode already VTP SERVER.
SW1(config)#vtp domain networkjutsu
Changing VTP domain name from NULL to networkjutsu
SW1(config)#vtp version 1
VTP mode already in V1.
SW1#sh vtp
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 0015.6264.3300
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
--------------
VTP Operating Mode                : Server
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0xBC 0xB8 0xA3 0xEE 0x7E 0xDE 0x5A 0xDE
                                    0xBE 0xB3 0xDC 0xCE 0xE8 0xB8 0x5A 0x82
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
--------------
VTP Operating Mode                : Server
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0xBC 0xB8 0xA3 0xEE 0x7E 0xDE 0x5A 0xDE
                                    0xBE 0xB3 0xDC 0xCE 0xE8 0xB8 0x5A 0x82
SW3#sh vtp statu
VTP Version                     : running VTP1 (VTP2 capable)
Configuration Revision          : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 5
VTP Operating Mode              : Server
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)

Once every switch are in the same VTP domain mode, we are now ready to test. Let’s create a VLAN on SW1 to verify that VTP is actually working. Before I issue the command below, I enabled the debugging of VTP on SW2 and SW3 by issuing debug sw-vlan vtp events.

SW1(config)#vlan 10
SW1(config-vlan)#end
SW1#

Once the command was issued in SW1, both SW2 and SW3 received the VTP advertisements – this is expected in VTP Server mode.

SW2# debug sw-vlan vtp events
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 1, followers = 1
VTP LOG RUNTIME: Summary packet rev 1 greater than domain networkjutsu rev 0
VTP LOG RUNTIME: Domain networkjutsu currently not in updating state
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 1, seq = 1, length = 165
VTP LOG RUNTIME: Transmit vtp summary, domain networkjutsu, rev 1, followers 1
   MD5 digest calculated = BF 22 27 B3 02 83 26 97 D2 70 B1 33 21 96 DA 12
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 1, followers = 1
VTP LOG RUNTIME: Summary packet rev 1 equal to domain networkjutsu rev 1
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 1, seq = 1, length = 165
SW2#sh vlan id 10
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   VLAN0010                         active    
SW3#sh vlan id 10
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   VLAN0010                         active

VTP v1 Transparent Mode

Now, let’s try changing the VTP mode on SW2 to see if the SWITCH OCG book is correct and create another VLAN on SW1.

SW2(config)#vtp mode trans
Setting device to VTP TRANSPARENT mode.
SW2# sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0xCF 0xCE 0x8A 0x4E 0x4F 0xFA 0x6E 0x4D
                                    0x4F 0xA4 0xA7 0xA2 0xE3 0xD9 0xB2 0x15
SW1(config)#vlan 20
SW1(config-vlan)#end
SW1#

Upon creating VLAN 20 on SW1, SW2 relayed the VTP advertisements and SW3 updated its database. As expected, switch on transparent mode would not update it’s database.

SW2#
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
SW2# sh vlan id 20
VLAN id 20 not found in current VLAN database
SW3#
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 2, followers = 1
VTP LOG RUNTIME: Summary packet rev 2 greater than domain networkjutsu rev 1
VTP LOG RUNTIME: Domain networkjutsu currently not in updating state
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 2, seq = 1, length = 185
VTP LOG RUNTIME: Transmit vtp summary, domain networkjutsu, rev 2, followers 1
   MD5 digest calculated = 1B 2E 5F 19 49 46 C4 E6 B7 D2 3C 7A DD 86 D6 42
SW3#sh vlan id 20
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
20   VLAN0020                         active

Different VTP Domain, VTP v1 Transparent

Now, how about we change the domain name. According to SWITCH OCG book, the switch with VTP1 Transparent mode will not forward VTP advertisements if it doesn’t match the domain name and version number.

SW2(config)#vtp domain NetworkJutsu
Changing VTP domain name from networkjutsu to NetworkJutsu
SW2(config)#end
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : NetworkJutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0x2A 0xE8 0x6D 0xF7 0x91 0x0A 0x62 0xC4
                                    0x03 0xD0 0x07 0x07 0x7C 0xE2 0x23 0xED
SW1(config)#vlan 30
SW1(config-vlan)#end
SW1#

Upon creating VLAN 30 on SW1, SW2 dropped the VTP advertisement and SW3 never received it.

SW2#
*Mar  1 00:42:56.963: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 00:42:56.963: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vl id 30
VLAN id 30 not found in current VLAN database

Different Domain, VTP v2 Transparent

Let’s change SW2’s VTP version and leave the VTP domain name unchanged.

SW2(config)#vtp ver 2
SW2(config)#end
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : NetworkJutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0x1B 0xF8 0xD3 0x9D 0xD2 0x06 0xC7 0xD7
                                    0x33 0x4B 0x66 0x50 0xC5 0x77 0xF5 0xE1

Now, let’s create another VLAN on SW1 and see if the SWITCH OCG book is correct.

SW1(config)#vlan 40
SW1(config-vlan)#end
SW1#
SW3#
VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
VTP LOG RUNTIME: Dropping packet received on trunk Fa0/2 - not in domain networkjutsu
SW3#sh vlan id 40
VLAN id 40 not found in current VLAN database

We now know that VTP v2 transparent mode does not relay traffic if the domain does not match. This means that the book is incorrect and the Cisco’s documentation page is spot on. Let’s prove it by changing the domain back to its previous name.

SW2(config)#vtp domain networkjutsu
Changing VTP domain name from NetworkJutsu to networkjutsu
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0xF1 0x29 0x4F 0xB3 0x73 0x0A 0x3A 0xE7
                                    0xF9 0x38 0x1B 0x1A 0xD1 0xAC 0xA6 0x19
SW2#
*Mar  1 01:10:35.944: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:35.953: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.532: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.532: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.574: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.574: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan id 40
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
40   VLAN0040                         active    Fa0/1

So far, the book did get the information correctly for the VTP Transparent mode version 1 but wrong for version 2.

All VTP version 2

Now, let’s try to change SW1 and SW3 to version 2 and see the effects. Let’s see if the book has more errors in its statement.

SW3(config)#vtp ver 2
SW3(config)#end
SW1(config)#vtp ver 2
SW1(config)#end
SW1(config)#vlan 50
SW1(config-vlan)#end
SW2#
*Mar 1 01:15:36.810: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.810: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.852: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.852: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan id 50
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
50   VLAN0050                         active    Fa0/1

As the book says, in version 2 transparent mode the VTP advertisements are forwarded out to the trunks. Great, the book is correct.

Different Domain, VTP v2 Transparent and Servers

Now, how about testing what the book says on the last sentence? The book says “this occurs regardless of the VTP domain name setting.”

SW2(config)#vtp domain NetworkJutsu
Changing VTP domain name from networkjutsu to NetworkJutsu
*Mar  1 01:17:27.196: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to NetworkJutsu.
SW2(config)#end
SW1(config)#vlan 60
SW1(config-vlan)#exit
SW1(config)#
SW2#
*Mar  1 01:18:08.057: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 01:18:08.057: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vlan id 60
VLAN id 60 not found in current VLAN database

It looks like the book got it wrong again. Let’s continue with our testing.

Different Domain, VTP v1 Transparent, VTP v2 Servers

For our penultimate test, let’s try to change SW2’s VTP version to 1 and domain name unchanged, and let SW1 and SW3 remain in version 2. According to the book, with VTP v1 Transparent the domain name and version must match. Let’s see if our gears agree with that.

SW1(config)#vlan 70
SW1(config-vlan)#exit
SW2#
*Mar  1 01:19:19.377: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 01:19:19.377: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vlan id 70
VLAN id 70 not found in current VLAN database

It looks like the book is wrong again.

Same Domain, VTP v1 Transparent, VTP v2 Servers

Now for our last test, let’s change it back to the original domain name and leave other settings unchanged.

SW2(config)#vtp domain networkjutsu
Changing VTP domain name from NetworkJutsu to networkjutsu
*Mar  1 01:20:26.500: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to networkjutsu.
SW1(config)#vlan 80
SW1(config-vlan)#exit
SW2
*Mar  1 01:20:26.645: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.645: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.687: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.687: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan |  i active
1    default                          active    Fa0/2, Fa0/3, Fa0/4, Fa0/5
10   VLAN0010                         active
20   VLAN0020                         active
30   VLAN0030                         active
40   VLAN0040                         active
50   VLAN0050                         active
60   VLAN0060                         active
70   VLAN0070                         active
80   VLAN0080                         active

Summary

In theory, theory and practice are the same. In practice, they are not. – Albert Einstein

We’ve just witnessed that it doesn’t matter what the switch’s VTP version is set to so long as the VTP domain name match then the advertisement will be forwarded. Please note that the behavior of VTP version 3 may not be the same as shown here. Unfortunately, I only have two switches capable of running VTP version 3 so it was not tested this time. Maybe when I get a hands on three switches capable of VTP version 3 then I will revisit this blog and update it.

Want to learn more about VTP or switching?

CCNP SWITCH 642-813 Official Certification Guide (Official Cert Guide)
CCNP Routing and Switching SWITCH 300-115 Official Cert Guide
CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1 (5th Edition)

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Dynamic Trunking Protocol (DTP)

02/08/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Dynamic Trunking Protocol (DTP) is the second generation of Dynamic Inter-Switch Link (DISL) which allow switches to negotiate trunking state of the link between two switches. Both DISL and DTP are Cisco proprietary protocol that are designed to learn whether the device on the other end wants to perform trunking or not.

DTP was covered in BCMSN exam and continues to be covered in SWITCH and even in the CCIE R&S v4.0 book – though not as detailed as the SWITCH/BCMSN books. In Cisco Press’ SWITCH Foundation Learning Guide (FLG in short), there’s table in chapter two that shows combination of DTP modes between two switches. While it’s a great table for DTP reference, it’s incomplete. The table is shown below.

DTP

One might ask, what’s missing? Well, DTP on this table shows that it is still on – except for the access. One mode that is missing is the DTP off mode which one would get if the switchport nonegotiate command was issued on a port. The table that the authors should’ve used is something like shown below.

DTP complete

While having DTP turned on can save some time in forming trunks between two switches (assuming that proper modes match up), it is in my opinion that it is not good to leave this feature turned on. Why? Imagine an access port left with default configuration and a malicious user connects to the port and successfully negotiated as a trunk and at the same time decided to attack the STP topology by assigning his computer to be the root bridge for all VLANs. Another example would be an attacker successfully negotiated as a trunk and decided to send traffic to hosts on all VLANs allowed in a trunk. Leaving the DTP on can leave a security hole in an organization’s network so turning it off is a good practice.

While there are ways to mitigate the attacks that I’ve described above, there are other ways one can be convinced to turn DTP off. As a network engineer, do you want ports to automatically negotiate as a trunk even though you didn’t want these ports to be trunk in the first place? A poorly design network is full of unintended scenarios such as this. Why would a network engineer let a finance employee who brought a switch and decided to plug it in to one of the data drops and able to negotiate as a trunk be allowed? Another reason to turn it off is to do increase the speed of convergence. While DTP negotiation is not time consuming, if your uptime is measured in milliseconds then shaving some milliseconds off the DTP negotiation is a good reason, in my opinion.

One final reason that I can think of right now not to rely on DTP, is when you use VTP with multiple domains in your network. If you try to link two switches with different VTP domains, the DTP will not negotiate even if it matches the modes in the table. An example is shown below.

The link between Switch 1 and Switch 2 is Fa0/1. Switch 2’s Fa0/1 is administratively down.

SW1#sh vtp statu
VTP Version : 3 (capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : CISCO
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0xD3 0x78 0x41 0xC8 0x35 0x56 0x89 0x97
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
VTP version running : 1
SW1#sh int f0/1 sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: isl
Operational Dot1q Ethertype: 0x8100
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
SW2#sh vtp statu
VTP Version : 3 (capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : SYSTEMS
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x9E 0x9B 0x51 0x32 0x00 0xB3 0xDC 0x5D
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
VTP version running : 1
SW2#sh int f0/1 sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Upon bringing up the interface on Switch 2, DTP event on Switch 1 shows that it failed to trunk due to VTP domain mismatch.

SW2(config)#int f0/1 
SW2(config-if)#no shut 
SW2(config-if)#end 
SW2# *Feb 9 03:00:32.847: %SYS-5-CONFIG_I: Configured from console by console 
SW2# *Feb 9 03:00:34.075: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up *Feb 9 03:00:35.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up 
SW1#debug DTP events DTP events debugging is on 
SW1# *Feb 9 03:00:32.715: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/1 because of VTP domain mismatch.

To verify this, one can issue show interface trunk.

SW1#sh int trunk
SW1#
SW2#sh int trunk
SW2#

As already mentioned above, the command to turn DTP off is by issuing switchport nonegotiate command. But issuing it on an interface without specifying the trunk will give you an error message as shown below.

SW1(config)#int f0/1
Switch(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.

To properly turn DTP off, you need to specify what kind of trunk you want to use as shown below.

SW1(config)#int f0/1
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
SW1(config-if)#switchport nonegotiate

To verify that DTP is turned off, you can issue the command below.

SW1#sh int f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: All
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

This command can also be issued on an access port. If the port was not configured with static access, then the error shown earlier will appear as well. That said, change the port to mode access then issue the nonegotiate command.

I believe that this should be a standard configuration in any network for all trunk ports and also the switchport host command on user ports. While not having the nonegotiate command on access ports yield to the same results, it might be a good idea to consider turning it off. If default configuration present more risks than it can offer are then I’d rather issue more commands than be sorry in the future. As what Jeremy Cioara would say, auto is ought not to use it.

Want to learn more about DTP or switching?

CCNP SWITCH 642-813 Official Certification Guide (Official Cert Guide)

CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1 (5th Edition)

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Stacking 2960-S and 2960-X

11/15/2013 By Andrew Roderos 18 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

At the time of writing, Cisco released the Catalyst 2960X not too long ago. It is the new version of the Cisco Catalyst 2960S, which allows stacking of up to eight switches. It provides up to 80 Gbps bandwidth using the optional FlexStack+ module. For more information about the specifications of the switch, head over to Cisco’s site.

I was not really a fan of the 2960S because of the four switches in a stack limitation. With the introduction of 2960X, network professionals can now pick it over 3750 or 3850 in certain scenarios and also save money. Speaking of money, since Cisco designed 2960X to be backward compatible, companies can take advantage of deploying the switch to join existing 2960S stacks. Therefore, provides their customer’s investment protection.

Mixed Stack

The 2960X allows stacking of up to eight switches and can provide up to 80 Gbps bandwidth with FlexStack+. Since 2960S can only stack up to four and provides up to 40 Gbps bandwidth, both switches are architecturally different and one would think that it shouldn’t stack – but, it does. Since both switches are architecturally different, there have to be some restrictions with mixed stack configuration. If you agreed, then you are correct that there are restrictions with mixed stack and are listed below:

  • Stacking is not supported on switches running the LAN Lite image. All switches in the stack must be running the LAN Base image.
  • In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, the number of supported stack members is reduced from eight to four.
  • In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, full stack bandwidth is reduced from 80 Gbps to 40 Gbps.
  • In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, stack convergence time is increased from milliseconds to 1 to 2 seconds.

Preparation

As with the stacking of 2960S or 3750, network professionals do not need to configure the switches. The stacking is done automatically by the switch by connecting the FlexStack or StackWise cables. However, there will be some work for the network professional to get the mixed stack configuration working properly.

In this scenario, the existing stack is 2960S with 12.2 IOS image and 2960X with 15.0 IOS image. As with the stacking of 2960S and 3750, the IOS needs to match first before the switch can join the stack properly. That said, the 2960S needs to be upgraded to the same software train as the 2960X.

The output shown here is a familiar log message and show switch output that informs the user that there is a software version mismatch.

*Mar  1 00:16:39.041: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 2 Switch 2 has changed to state UP
*Mar  1 00:16:55.168: %STACKMGR-4-SWITCH_ADDED_VM: Switch 1 has been ADDED to the stack (VERSION_MISMATCH)
*Mar  1 00:20:55.182: %IMAGEMGR-6-AUTO_COPY_SW_INITIATED: Auto-copy-software process initiated for switch number(s) 1
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: Searching for stack member to act
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: as software donor...
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: Software was not copied
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_ADVISE_SW_INITIATED: Auto-advise-software process initiated for switch number(s) 1
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: Systems with incompatible software have
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: been added to the stack.  The storage
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: devices on all of the stack members have
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: been scanned, and the software required
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: to make all stack members compatible with
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: each other was not found. The "archive
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: download-sw" command can be used to
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: install software off of the network from
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: a tar file.
Switch#sho sw
Switch/Stack Mac Address : f4ea.67ad.7580
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State 
----------------------------------------------------------
 1       Member 64e9.50f1.8100     1      2       Version Mismatch    
*2       Master f4ea.67ad.7580     1      1       Ready

The 2960X are designed to work with the 15.0 code. That said, we need to make sure the 2960S is upgraded to the same software train as the 2960X in order for it to form the stack. While the 2960S is being upgraded, we need to prepare the 2960X to ensure it forms the stack. Preparing 2960X to join the stack is as simple as issuing only one command. However, my recommendation is to issue another command for the preparation, which will be covered in a bit.

The switch stack port-speed 10 is the command we need to ensure the switch forms the stack. As the command implies, it sets the port speed of the stack port to 10 Gbps since the default of 2960X is 20 Gbps. Without this command, the 2960S will not recognize anything connected to the stack ports. As a result, the stack will not form. The sample output of the command is shown below. As always, make sure to save the configuration before reload.

Switch(config)#switch stack port-speed 10
WARNING: Changing the stack speed may result in a
stack speed mismatch .
Do you want to continue?[confirm]
New stack speed will be effective after next reload

Optional

The second command that I recommend ensures that both switches are running on the same SDM preference. By default, at least in my testing, the 2960S is set to default as the SDM preference. Make sure to check the SDM preference of the 2960S before changing the 2960X.

In addition, the second command helps with the booting process. Without it, the booting will take a little bit of time since the 2960X will attempt to match the existing stack’s SDM preference. By matching the SDM preference ahead of time, we are bypassing another process that the stack goes through for boot up sequence. A snippet of the boot up output is shown below.

Election Complete
Switch 2 booting as Member, Switch 1 elected Master
HCOMP: Compatibility check PASSED 
Waiting for feature sync....
Waiting for Port download...Complete
Stack Master is ready
 !!!!!!! SDM MISMATCH !!!!!!!
 Master Template is default & Local Template is lanbase-default
Reloading because of sdm template mismatch

SDM Preference

In the previous section, the output displays that the SDM preference of the switches do not match. The output below shows the default SDM preference of the switches.

2960X#show sdm prefer
 The current template is "lanbase-default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 0 routed interfaces and 1024 VLANs. 
2960S#sho sdm prefer
 The current template is "default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 0 routed interfaces and 255 VLANs.

To change the SDM preference on the 2960X, please issue the command below. Don’t forget to save the configuration before reloading. Once the configurations are done, the 2960X is ready to join the 2960S stack.

Switch(config)#sdm prefer ?  
  default          Default bias
  lanbase-default  Enhanced support for both IPv4 and IPv6 Routing
  lanbase-routing  Supports both IPv4 and IPv6 Routing
Switch(config)#sdm prefer default
Changes to the running SDM preferences have been stored, but cannot take effect 
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.

Verification

Just as any other Cisco stack, to verify if the switch(es) join the stack properly is to issue the command show switch, as shown below.

Switch#sh sw
Switch Ports Model              SW Version            SW Image                 
------ ----- -----              ----------            ----------               
     1 52    WS-C2960X-48FPD-L  15.0(2)EX3            C2960X-UNIVERSALK9-M     
*    2 52    WS-C2960S-48FPS-L  15.0(2)EX3            C2960S-UNIVERSALK9-M

Thoughts

It is a good thing that Cisco is providing investment protection for their customers. It is also good that Cisco released a new version of 2960 platform that supports more than four switches in a stack. The limitation of the 2960S platform that allows only up to four switches in a stack has always been my complaint with it. That said, I don’t normally deploy them in a stack. As a standalone switch, it is a good platform and cheaper than 3750. Having said that, I’ve always liked the 3750 platform for scenarios where I need to have stacking capability since it can go up to nine switches. But with this new 2960 platform, it has earned a place with me.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to Next Page »

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use