I guess we could spend hours doing packet captures and switch debugs to try to work out what is happening or you could just ignore the fact that it is happening on certain ports and set the network up correctly so that it doesn't happen anywhere under normal circumstances.   If you really want an answer as to why, get spanning-tree debug logs and packet captures from a working and non-working port.  Even better, implement DHCP snooping and debug that.  It will tell you exactly what is happening and how and why.  Happy to help with the diagnosis if you need it, but we are really flying blind with very little real information here.   ... View more

OK, so if I read you correctly, all ports on the Cisco exhibit the 30 seconds delay but only some ports on the HP switches do this.  I can't really comment on the HP switches but can say that if spanning-tree is not configured then you will definitely not see the issue and if spanning-tree is configured without some form of port-fast then you will very likely see this issue.   On the Cisco switches you will have to enable portfast to solve this, change timers (bad idea) or turn off spanning-tree (even worse idea); that is just the way they work. By design a port that is participating in spanning-tree will not forward traffic until it has passed through the blocking, listening and learning stages.  This, as you have found, takes about 30 seconds or so by default.  To test this turn on spanning-tree event debugging while you connect a PC and watch what happens.   The HP switches should work the same way but we would have to get into models, versions and configuration of those if you want to work out why some of those ports don't exhibit the same issue.  If I was to hazard a guess it would be that spanning-tree is not running on the ports that are responding quickly.         ... View more

  @djay_cdxi wrote: Thank you for your reply. Can you explain why other workstation/branches doesn't experience delay given that their access ports don't have a "portfast" configuration? I might be asked by our team lead prior to reconfiguration. Hi djay Without configs and more info I don't think anybody can.  At a bare minimum we need to see the running configs of your switch that has the problem and the other switch on which several ports do not exhibit the same behavior.  Along with this please share which ports on this switch have the issue and which don't. Then do show interface on one of each. show spanning-tree interface for one of each And we might even need some debug information yet. As a general guide, however, unless you have non-Cisco switches in your environment I think you will find that the best practice recommendation would be to implement RSTP+ or MST on all switches rather than relying upon the old STP protocol.   And enable port-fast (edge) on all interfaces except your network (inter-switch) interfaces.  ... View more

If you only have AC power available onsite (" But onsite there is only 120AV source available.") then you are going to need to get something to convert the AC from the 120AV source into DC for the switch. The PWR-IE50W-AC will do that for you. You need to look at your future expansion requirements (will you be using PoE?) to determine if you need the 50 or 65W versions. Or you need to procure/provide something else that will do the conversion or be a source of DC power. If you do get something else, make sure it complies with all the warnings & specifications detailed in the link that you posted. From what you have said, I think you will find that the Cisco AC power converter will be the most cost effective solution but do your own homework on that one and make sure it fits with future requirements. Finally, consider if you will need dual power sources for redundancy purpose. It may actually be a requirement in which case I think you will need at least one DC direct power option ... View more

Please do a double check that the 'other workstation/branches' don't have portfast default on as a global command or if they are maybe running Rapid PVST+ ... View more

I have same issue on a 4431 router Cisco IOS XE Software, Version 03.13.06.S - Extended Support Release Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(3)S6, RELEASE SOFTWARE (fc1) #show interface Hardware is ISR4431-X-4x1GE, address is 00a2.eefa.bac1 (bia 00a2.eefa.bac1) Description: [Internet] ACET-FNN-803-087 Royal St (NextGen VS-VLL-002-593) Internet address is 167.30.38.26/30 MTU 1500 bytes, BW 256000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 19/255, rxload 76/255 Encapsulation ARPA, loopback not set Keepalive not supported Full Duplex, 1000Mbps, link type is auto, media type is LX output flow-control is off, input flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:11, output 00:04:09, output hang never Last clearing of "show interface" counters 28w3d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 370 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 76507000 bits/sec, 11041 packets/sec 30 second output rate 19666000 bits/sec, 6114 packets/sec 25914094732 packets input, 13278884432078 bytes, 0 no buffer Received 1449007 broadcasts (0 IP multicasts) 0 runts , 0 giants , 0 throttles 15301971 input errors , 0 CRC , 0 frame , 15301971 overrun , 0 ignored 0 watchdog , 322267 multicast, 0 pause input 15831928709 packets output, 9969484229200 bytes, 0 underruns 0 output errors, 0 collisions , 3 interface resets 1742512 unknown protocol drops 0 babbles , 0 late collision , 0 deferred 3 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out     We have 2x1Gb outward-facing interfaces, both of which are 100Mb managed services so we shouldn't be getting more than 200Mb (OK, maybe 400Mb if we are sending and receiving at full capacity). The throughput of the device should be 500Mb as per: #show platform hardware throughput level The current throughput level is 500000 kb/s   We do have a third (toward our network) interface running at a full 1Gbps.  Does the figures for this interface count in the throughput?  I wouldn't have thought so since it is essentially the same traffic as would be found on the other two outward-facing interfaces.   And, the errors are only occurring on one interface, never on the second.  If this was a performance licence issue, I would expect drops on both interfaces I think. It also doesn't appear to be load related as I have looked at the utilisation graphs and the drops can occur at any time, not necessarily when the interface is loaded. I have  never seen the CPU go much above about 30% but we are using outgoing NAT on both outward-facing interfaces.   Are there any other areas to explore? Thanks   ... View more

From the following documentation, VTP is only supported in transparent mode on the Nexus 9K and is disabled by default.  You will have to use another device as the VTP server and if the N9K is in the path between the server and other clients you will have to enable VTP Transparent. But in any case you will have to recreate the VLANs on the 9K   https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/layer2/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_0100.html   VTP Modes VTP is supported in these modes: Transparent—Allows you to relay all VTP protocol packets that it receives on a trunk port to all other trunk ports. When you create or modify a VLAN that is in VTP transparent mode, those VLAN changes affect only the local device. A VTP transparent network device does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. If VTP is in transparent mode, you can configure VLAN long names of up to 128 characters. ... View more

It appears from your description that there are two 2960 switches that are connected via a trunk interface. A device is connected to switch 1 and the you are seeing packets that match the QoS policy on that device's input interface.  Between Switch 1 and switch 2 there is a trunk interface.  On the incoming trunk interface on Switch 2, the same QoS policy shows no matches.   First of all I would not be rechecking and resetting the packets on Switch 2 as they enter from Switch 1 (maybe you are not doing that).   But you do need a command on both switches' trunk link that will trust the incoming DSCP value because, depending upon the IOS version I think, the default state is to reset the COS to 0.  In Ver 15, this is "mls qos trust dscp" Assuming you have a separate router at each site, this command should also be on the interface to the site router so that incoming packets are not reset.  You will also need to set this on the 3560 switch interface which connects to that site's router.   If the sites are directly connected via the switches (i.e. no router), put this command on the connection interface of both switches. If this doesn't help, post the configurations, a diagram and the results of the show policy-map interface commands           ... View more

Hi Kabeer The short answer is, you can't if the end user knows what they are doing.   You can make it harder to do by using a combination of the following configurations: Port Security - limit the MAC addresses on a single interface BPDU Guard - look for BPDU packets generated by switches Disable trunk negotiation (switchport access) Use Network Access Control (NAC) to only permit corporate devices.  This won't work if they do manage to get a switch or hub on. Use other features within your infrastructure which require corporate certificates on all devices to connect None of these methods are foolproof but they will stop the casual connection of a switch.  If you can limit the MAC address to 1 by port-security, even if a hub (or switch that isn't running spanning-tree) is connected, the switch port will only permit 1 device to transmit.  It gets harder if you need to permit IP phones because you need to support at least 2 MAC addresses. The only real way is to implement DHCP Snooping and ARP Inspection on your devices and manually create a DHCP reserved entry for every permitted device.  Don't allow any dynamic pool. Not nice! Or create a policy that says if anybody does it they will be fired immediately and without question and hope this does the trick.           ... View more

Any more takers? ... View more