DHCP Snooping

Scenerio:

As part of a modernization project of tech in a big campus and because of several problems caused by users (l) connect the routers on the network and causing DHCP issues, I'm looking to turn on DHCP snooping. During the tech switches access update will be updated first and then the kernel. The new access switches are 4510R + E/Sup7, running the latest IOS XE base license and just passing through. New carrots are 6509 Sup 720's configured as a cluster VSS, manage all routing for VIRTUAL local area networks and have the statements of support IP. The DHCP server which takes care of all the VLAN is a Windows 2008 server that is directly connected to the base.

I also read all the info I could find on DHCP snooping, but I'm still a little fuzzy on if it changes the way that the DHCP server handles requests.

Issues related to the:

  • Because the access switches pass only, they only need monitoring DHCP enabled (in the world and on VIRTUAL local area networks) and their uplinks to the core set as being approved, right? In particular, they only declarations of support IP or Layer-3 interfaces for all of their VIRTUAL local networks, right?
  • While I understand that DHCP snooping will be ineffective if it is not lit on the kernel, there is no reason I can't deploy it first to the access layer without touching the basic configurations to avoid large amounts of documents of change control, right? Then, when the kernel is put at level and DHCP snooping successfully activated that will work.
  • I got that on the layer to access the switches uplink to the core are approved, but I'm not 100% on the question of whether the same interfaces are approved on the carrots. I don't think but want to be sure. Carrots of course trust the real interface on that server DHCP is plugged
  • The most confusing part is all the stuff from the Option-82. As near as I can tell its option for the server to use the information from the Option-82. I think that if all I do is enable DHCP snooping on worldwide and on the right VIRTUAL LANs the DHCP relay between the core and the DHCP server will continue to work as it is today, is that correct?

Is there really this traps or in my case I really just need to turn it on in the world and by vlan, trust the uplinks on the access switches and the DHCP server on the kernel interface and call it a day?

Thank you

Nathan Spitzer

SR Network Communications analyst.

Lockheed Martin

Hello Nathan,.

Given that the access switches are only switching, they only need DHCP snooping turned on (both globally and on the VLANS) and their uplinks to the core set as trusted, right?

Fix.

In particular they dont need IP helper statements or layer-3 interfaces for all of their VLANS, right?

Fix. The statement of support ip address would only be necessary if switches performed routing inter - VLAN and the DHCP server is located in a VLAN different.

While I understand that DHCP snooping will only be marginally effective if it is not turned on on the core, there is no reason I cannot deploy it first at the access layer without touching the core configurations to avoid large amounts of change-control paperwork, right? Then when the core is upgraded and DHCP snooping properly enabled it will work.

To my knowledge, the opposite is true. DHCP Snooping is a service of access protection layer - is it not in the core of the network. It has nothing to protect in the kernel once DHCP messages have beein properly disinfected at the edge of the network. For some inexplicable reason, many people think that the DHCP Snooping should be enabled on the network. The fact is that the DHCP Snooping protects against

  • DHCP messages are sent to ineligible devices
  • Ineligible devices posing as DHCP servers

From this it naturally follows that it is the limit of the network, or the layer of access, where such protection is the most effective. So in your case, I believe that the activation of the DHCP Snooping only on the access layer is actually what you want to do.

I got that on the access layer switches the uplinks to the core are trusted, but I am not 100% on whether the same interfaces are trusted on the cores. I dont think so but want to be sure. Of cource the cores do trust the actual interface the DHCP server is plugged in on

If you enable the DHCP Snooping on the basic features and uplink between the access switches and core would have to be configured as confidence both on the basic switches and access. Otherwise, the base ports would pass DHCP messages received from customers because the access layer switches running DHCP Snooping insert DHCP Option 82 in the DHCP messages sanitized and ports untrustred delete all DHCP messages including 82 of the present Option.

2960 Configuration Guide to

http://www.Cisco.com/en/us/docs/switches/LAN/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1078853

The switch removes a DHCP packet when one of these situations occurs:

  • Comes from a packet to a DHCP server, for example a DHCPOFFER, DHCPACK, DHCPNAK or DHCPLEASEQUERY package, outside the network or firewall.

  • A packet is received on an interface that is not reliable, and do not match the source MAC address and hardware address of the DHCP client.

  • The switch receives a message DHCPRELEASE or DHCPDECLINE with a MAC address in the DHCP snooping database binding, but the information in the database of linking interface does not correspond to the interface on which the message was received.

  • A DHCP relay agent sends a DHCP packet that includes a relay agent IP address which is not 0.0.0.0 or relay agent transmits a packet that includes information of option-82 to an untrusted port.

    • As I have indicated, however, I personally discourage running DHCP Snooping on the basic devices - I see no reason for this. Please correct if I am wrong!

    The most confusing part is all the Option-82 stuff. As near as I can tell its optional for the server to use the Option-82 information. I believe that if all I do is turn DHCP snooping on globally and on the right VLANS the DHCP relaying between the core and the DHCP server will continue working just like it is today, is that correct?

    LOL, my favorite on the DHCP Snooping things is the Option 82 interesting how much this topic brings confusion...

    The Option 82 was created to provide DHCP relay agent the ability to identify itself and the customer who sent the original message from DHCP unmodified. The DHCP server can then use this information to perform certain policies of customer trust. The format of the Option 82 is not strictly specified, only its basic structure is fixed. You can read more on this and the whole reason to be in the RFC 3046. One of the key points to remember here, however, is that the DHCP server may or may not recognize the Option 82, but apart from that, to copy the value of the Option 82A received in the message to a DHCP client for all its replies sent to this client.

    DHCP Snooping uses the Option 82 differently. He didn't expect and doesn't require that the DHCP Server includes the Option of 82 or manages a special way. The Option 82 is inserted by switches access performing DHCP Snooping and it contains two important parts:

    • The Circuit ID that identifies the port to which the client is connected (VLAN and the location of the physical port in a switch)
    • The remote ID that identifies the access switch to which the client is connected (by the MAC address of the switch)

    See http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1105589

    Now, when an access switch performing DHCP Snooping receives a message from DHCP client on an untrusted port, this will happen:

    • The switch will insert the 82 Option in the message of the DHCP client. The Option 82 will identify the specific switch and the port to which the client is attached
    • The switch will forward the DHCP message according to its MAC address of destination (i.e. in a completely normal way)
    • The server receives the DHCP message containing the Option 82. It is not relevant for DHCP Snooping if the server takes into account the value of the Option 82. However, when the server replies, it will insert the original value of the Option of 82 to the answer.
    • Access switch will finally receive the DHCP response. Looking at the Option 82, he knows exactly in which port is the message transmitted to the customer - and only the customer - even if the answer was broadcast!

    Note that the Option 82 contributes enormously to identify exactly the access switch and its port where the client is attached. If other switches with DHCP Snooping has received this DHCP message (in reason of the flood or address broadcast requested by the client), they would pass this message because they understand once glancing at the 82 Option that the customer is attached elsewhere. The 82 Option allowing to ensure DHCP communication between a particular client and the DHCP server doesn't leak not to other customers.

    There is a hunt for witches, associated with the Option 82. A switch run DHCP Snooping inserts the Option 82 messages DHCP clients. However, each DHCP message contains a field named GIADDR where the IP address of the relay agent is registered, where the DHCP message was relayed. Clearly, when a DHCP message goes through a switch DHCP Snooping, it is not relayed (drawn from one VLAN and rerouted to another), so an access switch does not change the GIADDR that remains set to 0.0.0.0. However, at least the implementation of server DHCP Cisco IOS performs a validation on a test received DHCP messages and it drops DHCP messages containing the Option 82, but which the GIADDR field is set to 0.0.0.0 (i.e. unitialized). This can be seen in the output of the debug ip dhcp server packet :

    Router# debug ip dhcp server packet
    
*Sep 9 01:59:40: DHCPD: inconsistent relay information.
    
*Sep 9 01:59:40: DHCPD: relay information option exists, but giaddr is zero

    Under normal circumstances, such a mental health check makes sense - how is it that a DHCP message contains the Option 82 (i.e. the Relay Agent Information Option DHCP) when there is no DHCP relay identified in the GIADDR? However, with DHCP Snooping on the access layer switches, DHCP messages are normal and expected. Therefore, it is essential to disable this check of mental health on the Cisco box that is running the DHCP server configuration using global ip dhcp relay confidence all information or only is selected routed (i.e. L3) interfaces with command level interface ip dhcp relay reliable information.

    To summarize:

    • The 82 Option is A Good Thing (TM) because it allows to deliver DHCP messages only to the client for which they are intended. Any suggestions to disable the insertion of the Option 82 on access DHCP Snooping Switches are useless 82 Option is inserted by DHCP Snooping Switches in DHCP messages by default - no additional configuration is necessary.
    • Through the easiest way - when you deploy DHCP Snooping, does not initially change anything about the Option 82. Make sure that your customers can receive their config IP via DHCP. If yes then there is nothing to resolve. If not, go further.
    • If you run a DHCP server on a Device IOS base (router, switch), you may need to use the command ip dhcp relay information confidence-everything (global config) or ip dhcp relay reliable information (level interface) to allow the DHCP messages with the Add Option 82 and unitialized field GIADDR to be accepted. These commands are required only on the device where the DHCP server is running, not on the access layer switches. You may want to first perform debugging as I suggested previously, and only if you see that packets are dropped, add these commands to the configuration.
    • I don't know if these commands should be added also to a DHCP relay function efficient switch - I can check that tomorrow in a laboratory.
    • If you are using another DHCP server you have to try experimentally whether happy with the DHCP messages with 82 Option present and unitialized GIADDR field

    Sorry for the long answer... I hope that I do not bore you to death. We invite you to ask for more! I'll try to be more concise next time

    Best regards

    Peter

    Tags: Cisco Network

    Similar Questions

    • DHCP snooping problem!

      Hello world

      I have a problem with dhcp snooping

      I have three switch, sw1 and sw2 to connect to a x 3750 as distribution switch

      My dhcp server is connect sw1 and clients connect to sw2

      I did trust the corresponding port and disable ip dhcp snooping information

      but when I configured dhcp snooping my client cannot get the ip address?

      I am grateful if someone could help me

      Did you trust ports to the DHCP server AND your circuits between switches?

    • DHCP Snooping without configured DHCP relay

      Hello

      We use DHCP Snooping with DHCP relay successfully configured... but I was wondering if the DHCP-Snooping function is also working on a (composed by different switches) L2 network where the DHCP server is on the same VLAN as the client?

      I know that server must be in a VLAN dedicated but segmentation VLAN server DHCP - client is scheduled in a second step...

      Thanks for your suggestions!

      Hi Omar,.

      The DHCP server can be on the same VLAN as the customers, no problem with that.

      You must configure the port on the DHCP server as being approved with the following commands:

      conf t

      IP dhcp snooping

      IP dhcp snooping vlan x

      interface fastethernet x / y

      IP dhcp snooping trust

      FastEthernet x / is the port where the DHCP server must be located.

      Cheers:

      István

    • DHCP SNOOPING TO THE SWITCH OF CISCO SMALL BUSINESS SF200-48

      Please help me. I need to know if the dhcp snooping is available in cisco firmware version 1.3.7.18.

      Hi Bonnie, as I know DHCP snooping is not on the SX200 switch. I am also unable to find documentation in Administrator's guide and release notes not stating that it is.

    • N4064F ip source guard without dhcp

      Hello!

      I'm having a problem with our new Dell switches.

      We are a small ISP and need to find a way to prevent users from assigning IP addresses to their equipment which do not belong to them. We hoped there was a feature similar to Cisco using static ip assignments ip source guard, but it seems that it requires the use of a DHCP server. None of our clients are in DHCP, all IP addresses are statically assigned. Is there another method or solution? Perhaps using an ACL?

      Thank you!

      I came across this post that goes beyond using source guard with static IP addresses on Cisco.

      http://bit.LY/1DsAM47

      The switches of the N series to offer the same commands with a slightly different syntax. This suggests to me that it should work the same.

      Console (config) # ip dhcp snooping
      Console (config) # interface item in gi1/0/1
      IP console(Config-if-Gi1/0/1) # check the source
      output console(Config-if-Gi1/0/1) #.
      IP console (config) # check the binding 00:11:22:33:44:55 vlan 1 1.2.3.4 interface gigabitethernet 0/1/1

      Page 521 for another look at these commands:
      http://Dell.to/1KxGn74

      An ACL would work too. You can apply an ACL entry to the physical interface that would allow only the traffic of the said IP address and then deny all other traffic.

    • PowerConnect 5448, how to restrict DHCP BOOTREPLY messages to a specific LAN port?

      In order to counter the effect of the DHCP server that is not allowed on my Ethernet network. I need to restrict DHCP BOOTREPLY messages on a specific LAN port on which the authorized DHCP server resides.

      I tried to read the section "Configuration DHCP Snooping" of the 54xx User Guide, but does not get a clear idea. This description in the user guide seems rough and intuitive for me to understand.

      'Trusted Interface Définition' help? I think I need feature 'port of trust '. I hope only trust ports 5448 can receive DHCP BOOTREPLY packages, while BOOTREPLY arriving in untrusted ports is rejected.

      Daniel finally understand the missing link after an exchange of emails with me.

      I have to add

      Console (config) # ip dhcp snooping vlan 1

      to finally make it work - even if I don't yet use the VLAN.

      See you soon.

    • function of guard of source IP and dhcp DHCP scope of exhaustion (customer parodies other customers)

      Hello world.

      A dhcp server assigns ip address based on the mac address by equipment of the customer field in the dhcp packets.

      A potential attack is when a crowd of thugs mimics different mac addresses and causes the dhcp server to assign ip addresses until no ip address is left for legitimate host.

      For example, a host with mac1 h1 is designated by the ip address of the dhcp server as:

      199.199.199.1 mac1

      DHCP server has this entry in its database.

      Using hacking tools such as Yersinia or Gobbler can create a DHCP discover messages every time that create another mac for material scope of the client to the dhcp server, thereby causing a dhcp server to assign ip addresses because they are of legitimate dhcp to dhcp server discover messages with matching each another Mac in hardware of client addresses.

      You could use dhcp snooping and it will avoid that (exhaustion of dhcp scope) and configure the switch to check if the CBC mac fits the hardware address of the client in the dhcp message. But when even we can creat spoofed discover messages where mac src in the ethernet header will match the client hardware address in dhcp discovery message. It did not always overcome the problem.

      You might say use IP source guard characteristic but it really will prevent this problem from happening?

      Let me illustrate:

      H1 - f1/1SW - DHCP server

      Let's say that we have configured dhcp snooping on sw1 and f1/1 is untrusted port.  Switch a suite dhcp binding

      199.199.199.1 mac1 vlan1 f1/1

      Then, we configure source ip guard in order to validate the mac src and src ip against the dhcp bindings. When you configure keep source ip first, it will allow dhcp only if a host can request ip address and dhcp binding can be built. After that IP keep source will validate ip or mac src src or both against the binding.depending dhcp on how configure us source ip guard.

      In our case, we have configured source ip guard in order to validate the mac src and src ip against the dhcp binding.

      A dhcp connection is already created as:

      199.199.199.1 mac1 vlan 1 f1/1

      Now, using hacking tools Yersinia or Gobbler on h1, we create our first spoofed dhcp discovery message where mac src = mac2 ethernet header and client harware address = mac2 in dhcp discovery message. As the switch is configured with the function of guard of source ip and therefore allows dhcp discover message to pass through. DHCP server after you receive the message dhcp assigns another IP from the pool. The dhcp server has now after the entries:

      199.199.199.1 mac1

      199.199.199.2 mac2.

      We continue to spoofed dhcp to craft discover messages as described above and are dhcp server keep ip address assignment until exhausts the entire pool.

      So my question is how ip source guard in conjunction with dhcp snooping doesn't stop this attack does not happen? (IE DHCP scope exhaustion)

      I really appreciate your comments.

      Thank you and have a week.

      Hi Sara,.

      Ask was quite interesting. As far as I know that whatever it is port snooping untrusted won't let your fake dhcp server.

      You can take this query in the Sub forum of experts mentioned that is specific for dhcp snooping and source of guard.

      https://supportforums.Cisco.com/message/3689811#3689811

      Please assess whether the information provided is useful.

      By

      Knockaert

    • DHCP NAK on wrong VLAN on SG500

      I have a 52 SG500 L3 mode with IPV4 addresses configured on 2 VLANS (1 & 2).

      DHCP server is running on the switch, and that only one pool is configured (for the subnet on the LAN VIRTUAL 2).

      When executing a capture of packets to test something with DHCP, I noticed that when a customer of the VLAN 1 sent a DHCP INFORM, the switch has responded his address IPV4 1 VLAN with a DHCP NAK.

      Curiously, it seems to only respond to only a single client with DHCP NAK. All other DHCP INFORM requests (several in the screenshot) seem to be ignored by the switch.

      Is there a reason why the switch would meet a DHCP INFORM on a subnet for which no DHCP pool is configured? Is there a way to stop this behavior?

      DHCP snooping * is * turned on the switch on the two VLAN 1 & 2.

      Thank you

      -Matt

      Looks like the same problem discussed in this thread of message:

      https://supportforums.Cisco.com/discussion/12196801/DHCP-scopes-SG500

    • Monitoring IP Dhcp and IP Source Guard

      Good day to all

      How to enable dhcp snooping and ip source guard, so that the user of the VLAN 60 (PC1) was not able to use other static addresses except 192.168.20.2 for the DHCP server, without affecting the other VLAN? The regime does not change and there is no other material.

      Something like a little:

      ip dhcp snooping vlan 60ip dhcp snooping

interface Gigabit a/b/c  description DHCP Server  ip dhcp snooping trust

interface Gigabit a/b/d  description Interface facing client  ip verify source vlan dhcp-snooping

    • Cannot collect dhcp information using device-sensor for profiling.

      Hello

      I try authentication dot1x/MAB (there is no issue here), but I want to collect information dhcp devices requesting the IP address of the dhcp server to the profiling using the sensor in the camera (cdp collects on - no problem) but when I check for all device-sensor of the show # dhcp cache, there is no single entry for dhcp data.

      The dhcp server is on the switch where these devices attempt to access the network since then and this should be the case. However, I noticed the following I don't know if it is bound (from device-sensor #debug error)-same error appear with different X value.

      DSensor: NULL input physical interface, throw packetRejecting IVR Interface VlanX package

      I am more concerned about collection attributes now rather than send... !

      Dip-switch IOS: Version 15.0 (2) SE9

      any suggestions?

      A couple more questions:

      1. do you have active monitoring dhcp ?

      2. do you see links in the dhcp snooping database?

      Thank you for evaluating useful messages!

    • Re: No DHCP for physical clients

      @abeggled

      No, it should not be a router it. More in the video below...

      http://www.bilder-space.de/show.php?file=04.081zx1woqTCQA7uzL.jpg

      Visio network (must be correct)

      http://www.Bilder-space.de/show.php?file=04.08AGPMCjdKIqeKjF1.jpg

      The ESXi Network Setup

      If you need more information, just ask

      The new server is just a replacement for the old, is - this can be a problem outside the virtualization?

      Have you checked your switch on DHCP Snooping or IP/MAC based ACL settings?

      Daniel

      ---

      If you find this or any other answer useful please consider awarding points marking the answer correct or useful

    • High utilization of the processor on Powerconnect 8024F

      Hello world

      We have a few Powerconnect 8024F using more than 60% of its CPU time on 'snoopTask '.

      State bytes
      ------ ----------
      674521408 free
      Alloc 327563488

      CPU usage:

      PID name 5 seconds 60 dry dry 300
      -----------------------------------------------------------------
      4ad0a00 tTffsPTask 0.00% 0.02% 0.00%
      4aede50 tNet0 0.21% 0.08% 0.05%
      4 d 19990 ipnetd 0.21% 0.03% 0.00%
      4d780d0 envMonTask 0.00% 0.13% 1.18%
      4d818a0 osapiTimer 0.00% 0.11% 0.14%
      4f93200 bcmL2X.0 3.17% 3.44% 3.34%
      4fb9ac0 bcmCNTR.0 0.84% 0.87% 0.84%
      500dde0 bcmTX 2.33% 1.96% 1.76%
      56cbd50 bcmRX 4.87% 4,45% 4.40%
      5cbdc90 MAC send task 2.75% 3.12 3.19%
      5cc7190 MAC age task 1.90% 0.63% 0.67%
      6aa3310 bcmLINK.0 1.27% 0.84% 0.68%
      91fa040 tL7Timer0 0.00% 0.00% 0.01%
      921f950 osapiMonTask 0.00% 0.06% 0.07%
      9224e70 serialInput 0.00% 0.01% 0.01%
      a4fb110 portMonTask 0.00% 0.00% 0.01%
      a5254b0 simPts_task 0.00% 0.03% 0.05%
      ac294e0 emWeb 0.00% 0.00% 0.01%
      ac3c400 dtlTask 4.44% 4.31% 4.18%
      ac456d0 dtlAddrTask 0.00% 0.00% 0.01%
      ac8ebd0 hapiRxTask 2.33% 1.55% 1.47%
      ba8b380 DHCP snoop 0.00% 0.00% 0.02%
      ceea3a0 dot1s_timer_task 0.84% 0.35% 0.28%
      da20f40 unitMgrTask 0.00% 0.01% 0.00%
      dc03030 snoopTask 66,73 68,60% 67,56%
      ed219b0 dhcpsPingTask 0.00% 0.03% 0.03%
      eeb1d30 ipMapForwardingTask 1.27% 1.21% 1.22%
      156-8780 ip6MapLocalDataTask 0.21% 0.31% 0.34% d
      15 d 09730 0.21% 0,16% 0,16% lldpTask
      15fad980 tCptvPrtl 0.00% 0.05% 0.03%
      164cba80 isdpTask 0.00% 0.05% 0.49%
      16 d 41400 RMONTask 0.21% 0.16% 0.19%
      16d531f0 boxes Req 0.00% 0.00% 0.01%
      -----------------------------------------------------------------
      Total CPU Utilization 93,85% 92.74% 92.57%

      These switches are usually connect to a dozen of 5548 s and rstp between, purely layer 2 running, they are all on the firmware 5.1.0.1.  We are quite surprised to see the little problem of performance, given the strong support.

      We are witnessing a firmware bug or something far more sinister? What is 'snoopTask' and how such problems help out me?

      Please let me know if any additional info is needed, thank you very much.

      Will be

      The task is linked to the treatment of IGMP/MLD Snooping packages. Multicast is configured on the network? The new firmware has a few improvements that can help. If you can schedule some time to do the update of the firmware, it would be worth.

      http://Dell.to/1uXNDaJ

      If the network is flooded then firmware cannot help.

    • The support of SG300 - 10 TEAR?

      Hello!

      In the documentation for the CLI of the SG 300 series, it shows sh ip rip road as a command. I installed the latest firmware and this command is no longer available. Support of the SG300 series TEAR?

      Thank you!

      Richard S.

      Hello Richard,.

      My name is David Aguilar, and I am an engineer with Cisco Small Business Center. Thanks for writing.

      The SG300 series can't RIP. Only static routes (up to 32) are supported. However, models of SG500X support the dynamic routing RIP version 2 Protocol.

      Regarding the new firmware Sx300, he added a number of security features impressive including inspection IP ARP, DHCP snooping and encryption of SSD.

      All the best,

      -David Aguilar

      Cisco Small Business Support Center

    • Option 82 and ip-helper

      I use ip assistance to forward the DHCP broadcasts of all of my VLAN to the 2012 Microsoft dhcp server. In my switch CCNP training, recently, I came across option 82 and wishes to state his destination. Is option 82 and assistance the same ip? I understand that 82 is the inclusion of additional information in the context of broadcast DHCP what ip-helper does as well. I implement DHCP snooping and cisco best practices wrote to pair it with option 82.

      Hello Phil,

      A major point option 82 is to pass additional information to the DHCP server by saying the latter where exactly is the client DHCP, that is which port that he Switch is connected to.

      With option 82, special ip address may be linked to the specific switch port. Also it has many extra fileds as the mac address, the port identifier but most important is giaddr (gateway aandle lists).

      This is the area given by device acting as relay dhcp (with support address).

      It could be that useful...

      -GI

      Rate if this can help

    • Cisco 4506 high CPU usage

      Hello

      Yesterday afternoon, one of our 4506 switch has climbed to 96% CPU usage. I did not the configuration changes. Here is the process with high CPU usage

      40 36630921841089949084 3360% 8.63% 10.56% 11,29% 0 Cat4k Mgmt HiPri

      41 30929587802851505705 1084 36,61 36,53% 36.18% 0 Cat4k Mgmt LoPri

      76 72485492 270422107 268 entry IP 7.91% 7.72% 7,68% 0

      113 35661224 40030007 890 21.91 28.13 29,84% 0 DHCPD receive

      After having HS health platform, what are those high:

      S2w-JobEventSchedule 10.00 7.54 10 8 100 500 9 9 7 36703:06

      Stub-JobEventSchedul 10.00 12.23 10 48 100 500 12 12 9 51004:51

      K2CpuMan review 30,00 29,44 30 99 100 500 33 32 25 37067:58

      K2AccelPacketMan: Tx 10.00 12,15 20 1 100 500 12 12 10 11871:22

      And finally sh platform cpu packet statistics gives me this

      Packets dropped in hardware by CPU Subport (txQueueNotAvail)

      UC Subport TxQueue 0 TxQueue 1 TxQueue 2 TxQueue 3

      ------------ --------------- --------------- --------------- ---------------

      0 11045 14031 149981 188579662

      1               0               0               0         5919279

      2               0          115638               0               0

      RkiosSysPacketMan:

      Falures allowance package: 0

      Package (common software) buffer allocation falures: 0

      Package Buffer (software ESMP) allocation falures: 0

      Package Buffer (software EOBC) allocation falures: 0

      Falures IOS Packet Wrapper buffer allocation: 0

      Packets dropped in the overall treatment

      Total 5 s 1 min, 5 min 1 hour avg avg avg avg

      -------------------- --------- --------- --------- ----------

      146521131 0 0 0 0

      Packets dropped in treatment by event CPU

      AVG s Total 5 1 min, 5 min avg avg avg 1 hour event

      ----------------- -------------------- --------- --------- --------- ----------

      Input Acl 146002289 0 0 0 0

      SA Miss                             27         0         0         0          0

      Packets dropped in the treatment of priority

      AVG s Total 5 priority 1 min, 5 min avg avg avg 1 hour

      ----------------- -------------------- --------- --------- --------- ----------

      Normal 46723179 0 0 0 0

      Medium 518884 0 0 0 0

      High 99797883 0 0 0 0

      Packets dropped in the treatment of the reason

      AVG s Total 5 reason 1 min, 5 min avg avg avg 1 hour

      ------------------ -------------------- --------- --------- --------- ----------

      SrcAddrTableFilt 24 0 0 0 0

      L2DstDrop                             7         0         0         0          0

      L2DstDropInAcl 46 0 0 0 0

      NoDstPorts                           32         0         0         0          0

      NoFloodPorts 146521022 0 0 0 0

      The package 16 total queues

      Packets received from the packet queue

      Total 5 s 1 min, 5 min 1 hour avg avg avg avg queue

      ---------------------- --------------- --------- --------- --------- ----------

      6279742115 238 247 203 193 ESMP

      L2/L3Control 1320811357 57 48 43 41

      Host of learning 24933459 1 0 0 0

      L3 Fwd Medium 5813 0 0 0 0

      L3 Fwd Low 72923122 0 0 0 0

      L2 Fwd high 11130 0 0 0 0

      L2 Fwd Medium 164016 0 0 0 0

      L2 Fwd 242645408 227 237 193 185 Low

      L3 Rx High                           9         0         0         0          0

      L3 Rx 89296999 439 461 378 364 Low

      Failure of the RPF 129420 0 0 0 0

      Packets dropped packet queue

      Total 5 s 1 min, 5 min 1 hour avg avg avg avg queue

      ---------------------- --------------- --------- --------- --------- ----------

      L2/L3Control 18470371 0 0 0 0

      Host of learning 5825831 0 0 0 0

      L2 Fwd Low 405210 0 0 0 0

      L3 Rx Low                         9863         0         0         0          0

      I will be restarting the night switch to see if it helps.

      Thank you.

      Salman

      Hello Salman,

      If DHCP requests are taken over by clients, you will probably want to focus on the limiting of requests DHCP using DHCP snooping.

      ip dhcp snooping limit rate rate

      http://www.Cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/65591-Cat4500-high-CPU.html#high_cpu

      http://www.Cisco.com/c/en/us/TD/docs/switches/LAN/catalyst4500/12-2/25ew/configuration/guide/conf/DHCP.html#wp1073418

      -Ginette

    Maybe you are looking for

    • iPhone 7 - can't reload everything while listening to music?

      I listen to music through my headphones all day to work on my iPhone 6 s. For this I need to have my iPhone supported otherwise it won't last all day. As far as I can see, the iPhone 7 allow me not to that! Looking at the ear pods included lightning

    • Best option to install Windows on a laptop with only of the BIOS

      I have a laptop that is preinstalled with Vista. The hard drive crashed so I had to completely restore, even the recovery partition. How can I LEGALLY install Windows again at the lowest possible cost? The computer has enough features to run Windows

    • Express Card USB + 1394 Combo Express card problem device.

      I have a Sony Vaio laptop and try installing this card in the Express slot to join sony Video 8 digital recorder to my laptop. Device will not load driver correctly. There was no disc or another driver with the device. The foregoing describes the pro

    • 8 scan and Capture app windows doesn't work is not for HP B210a Photosmart

      The printer mentioned in the subject appears in the application of control of the printer but when I try the Scan / Capture enforcement, it displays "Invalid data" (see table) Win8 x 64 update Pro - this happens when I click on the document capture p

    • I got the Tablet Todier

      Hello Today, I had the desire to Tablet W700. I've had a few hours now the? is that I don't is where can I find what BIos I have and where I would have been too if I neeed two I. the W700 verson i 3 of the Tablet and I want too much at the mercy of B