thanks william but i have gone through this link before doing the testing on customer devices. All I need to know is if the LDAP Setting [Syntax] is same on all controllers and also if client is using the correct LDAP Syntax or not as shown in image. [he is using UID instead of CN in bind username] secondly why it shows successful LDAP binding on WLC GUI when i mention wrong credentials , it should show deauthenticate when the parameters are incorrect . check the attach image. Moreover ping is also successful for LDAP via WLC GUI even after wrong credentials. ... View more

Please refer to the link below, its seem bug on your release.    https://quickview.cloudapps.cisco.com/quickview/bug/CSCdp67403 ... View more

It depends on how your firewall HA setup works, most likely it will be something HSRP alike with a VIP shared between the two FWs? If so, then simply trunk the transport vlan between Nexus and the Fortinet FWs to all 4 devices and point the default route from Nexus upstream to the VIP of the FW cluster and vice versa the route to the DC vlans (summary route) towards the HSRP IP of the Nexus. You could definetly go for VPC in this case which provides better throughput and more resilience against a single link failure. The second option would be to run some dynamic routing protocol between Nexus and the firewall, this is normally done in an active/active setup, this means the links between Nexus and the FWs are individual L3 Links and failover or loadbalancing will rely on the routing protocol, this is usually not the way a firewall cluster is operated. Edit: if you plan to purchase those Nexus switches, be advised that you don't need the L3 Enterprise License for that setup. HSRP and static Routing is included in the LAN Base license. And depending on which Nexus3k switch you are planning, consider to use a Nexus 9k instead, they are the better switches and are just slightly more expensive. (talking about the newest generation like 93180YC-EX, not the old generations) ... View more

Also check these Error types ... View more

CRC error CRC error are mostly for faulty cable moreover check below for CRC error, farme error and few useful links to trouble shoot these type of problems   The CRC error rate is 1.75915% (greater than 1 in a million packets),   and the collision rate is less than 0.1%.   This can indicate excessive noise or transmission problems on the LAN or the LAN   bus itself. A high number of CRCs is usually the result of collisions or a station   transmitting bad data.   TRY THIS: Check cables to determine whether any are damaged. If 100BaseTX is being   used, ensure Category 5 cabling is being used and not another type, such as Category   3.   There have been 1599 'frame errors' reported.   This indicates the number of packets received incorrectly, having a CRC error   and a non-integer number of octets. On a LAN, this is usually the result of collisions   or a malfunctioning Ethernet device. TRY THIS: Monitor the level of frame errors over time. If they are increasing,   try swapping interfaces and or ports to identify the problem. http://www.cisco.com/en/US/customer/products/hw/modules/ps2033/products_tech_note09186a008009446d.shtml http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html ====================================== SPF errors 1.The port is placed in error-disabled state after SFP is inserted. Possible Cause: This problem is usually caused by bad or non-Cisco-approved SFP module(ie. the incompatible SFP). Resolution: Remove the SFP module from the switch and replace it with a Cisco-approved module. Use the irrdisable recovery cause GBIC-invalid global configuration command to verify the port status, and enter a time interval to recover from the error-disable state. The best advice is to use the Cisco original SFP or 100% Cisco compatible SFP (If you decide to use a third-party SFP, please ensure that your supplier is assured) that is adapted to the switch. 2.Device does not recognize the SFP module. Possible Cause: This problem is generally related to the SFP installation. Situations, such as SFP is installed upside dowm or does not snap into the slot can cause this problem. Resolution: Verify that the SFP module is not installed upside down. Remove the SFP module. Inspect for physical damage to the connector, the module, and the module slot. Replace the SFP module with a known good SFP module. 3.Excessive errors found in port statistics. Possible Cause: Bad adapter in attached device or STP checking for possible loops can cause this problem. Resolution: Run adapter card diagnostic utility and wait 30 seconds for the port LED to turn green. ===========   BFD timers(ospf) The BFD protocol is a simple hello mechanism that detects failures in a network. The BFD failure detection timers have shorter timer limits than the OSPF failure detection mechanisms, thereby providing faster detection. BFD is useful on interfaces that are unable to detect failure quickly, such as Ethernet interfaces http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005.html ============== Incremental error this could be 1 or 2 above or other reasons like faulty port , faulty software too. Also check this link for incremental error https://supportforums.cisco.com/document/14776/runts-and-crc-errors-increment-show-interface-command-output-cisco-ios-based-switch ================================= High bandwidth utilization Could be many reasons , too much devices a segment has ,too much traffic generally for the device to handle , you need to spec before you buy and make sure your traffic volume will not overload the network ========================================================= Route-flapping in OSPF Network A route is said to be flapping when it keeps saying “Now you see me, now you don’t, Now you see me, now you don’t”…many times over…. Its availability keeps going up and down, flapping as it were or fluctuating frequently. OSPF neighbours exchange hello messages to let each other know, “Hey, am still available, am still reachable, and still a participating member of the OSPF process”.  By default, hello messages are sent every 10 Seconds (i.e Hello Interval/Timer) on broadcast networks (e.g Ethernet) and every 40 seconds on Non-Broadcast networks. The Dead Interval will be four times the Hello Interval (40 or 120 seconds) again depending on the interface type. If a OSPF router doesn’t receive 4 hello packets (e.g in 40seconds) from its neighbour, it will safely assume that its neighbour is unreachable/down and subsequently purges all the routes from its routing table that were once reachable via this neighbour. (Hence the name dead Interval/Timer) Major causes of route flapping in OSPF are: • Unstable links within the network • Unstable neighbor(s) within the network • Duplicate router ID within the network Whenever there is a change in topology, (e.g. neighbour goes down, then up again) OSPF will run the SPF algorithm afresh to re-calculate the shortest path to all available destinations. To detect route flapping, the command “show ip ospf | include SPF algorithm executed” is useful. It will tell you how many times the SPF algorithm has run. When theres a route flap, you’ll see something like: Router#show ip ospf | include SPF algorithm executed SPF algorithm executed 15378 times That’s an insane number of SPF executions. Another way is by use of the good old  show ip route command. The output will be something like this below: R2#show ip route ospf O  1.1.1.1 [110/2] via 192.168.12.1, 00:00:43 , FastEthernet1/0 You will notice that all OSPF advertised routes are always less than a minute old. ( 00:00:43 seconds have passed since this route was installed in the Routing table ) Another useful command is   debug ip ospf monitor command is also very useful, because it pinpoints exactly where the problem is. Sample output is shown below: Router# debug ip ospf monitor OSPF: Schedule SPF in area 0.0.0.0 Change in LS ID 3.3.3.3 , LSA type R 3.3.3.3 is the duplicate router ID. This tells you that two routers in Area 0 must be having this same ID of 3.3.3.3 http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19167-bgp-rec-routing.html =============== Hope this will be helpful ... View more

shutdown the port and then issue the above mentioned command and also disable CDP and then bring interface up. let me know after doing this. ... View more

issue the following command on that specific port Switch(config)# interface {fastethernet | gigabitethernet} slot/port Switch(config-if)# power inline {auto [ max milli-watts] | never | static [ max milli-watts]} NOTE: In second command use "never" option to disable inline power for that port. ... View more

Check the following link for troubleshooting 4500 series http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4500-series-switches/24052-165.html ... View more

Thanks alot.   Please mention the command for adding static route and also shed light on "default network" and "default gateway" in L3 switch. ... View more

Thanks Jon , I check in LAB its not possible what i'am thinking as physcial port is indeed at the back end of etherchannel so we need SVI.   One thing more Jon I would like to know , In order to reach from PC2 to PC1 in diagram, Do I have to define RIP on both Switch? because IP routing on both switches can't let me reach that end (PC1).     ... View more

I get what you mentioned. Is there any way to bind SVI with Etherchannel ? So I don't have to configure extra interface/SVI.     ... View more