CoPP policies on Nexus 3k/5k

Hi. Is there any documentation on defined tasks of certain CoPP policies. While most are guessable then there are some that I have no clue about.
For example class-map copp-s-selfIp ... if I had traffic matched by that policy exceeding the defined pps then I would have no clue what traffic is actually flooding the control plane.
Is there a source for that kind of information?
thanks!

Those are different things.
Policy type qos  --> Function: Define traffic classification rules -->attached under System qos and Ingress Interface
policy type queuing -->Function: Strict Priority queue & Deficit Weight Round Robin --> attached under: System qos  & Egress Interface & Ingress Interface*
network-qos -->Function: System class type(drop or no-drop) & MTU per class of service & Buffer size &Marking --> Attached under:System qos

Similar Messages

  • 10Gig Copper SFP for Nexus F Series module (N7K-F248XP-25E)

    Does Cisco have 10Gig Copper SFP which can be supported on Nexus platform in the F Series module (N7K-F248XP-25E)

    Leo,
    Thank you for the answer, you mentioned 10Gig Copper module in your reply (Part# N7K-F248XT-25E) but I already have Fiber Module (Part# N7K-F248XP-25E), I just need 2 10Gig copper ports for my storage and cant afford to buy a whole new Copper module. My question was if there is any 10Gig Copper SFP supported on F Series Fiber Module (Part# N7K-F248XP-25E), (not a twinax/DAC cable since my distance is longer and Twinax wont work)

  • Nexus N7k 10 slot ISSU failure

    Hi, 
    I am trying to ISSU upgrade our Nexus 7K 10 slot switch from 5.2.7 to 6.2.8a The ISSU has failed multiple times due to the Standby Supervisor failing to come back online  with the message
    Install has failed. Return code 0x4093001e (Standby failed to come online)
    Please identify the cause of the failure, and try 'install all' again.
    Start type: SRV_OPTION_RESTART_STATELESS (23)
    Death reason: SYSMGR_DEATH_REASON_NEED_COPYRS (19)
    Last heartbeat 0.00 secs ago
    System image name: n7000-s1-dk9.6.2.8a.bin
    System image version: 6.2(8a) S2
    Exit code: SYSMGR_EXITCODE_NEED_COPYRS (66)
    Has anyone else experienced this before and found a solution?, any suggestions are welcome at this stage. I've followed the ISSU guidelines to the core. Please help!!
    thanks, Sujohn

    Hi,
    Are you following these guide lines before attempting to upgrade?
    efore attempting to use ISSU to upgrade to any software image version, follow these guidelines:
    Scheduling Schedule the upgrade when your network is stable and steady. Ensure that everyone who has access to the device or the network is not configuring the device or the network during this time. You cannot configure a device during an upgrade.
    Space Verify that sufficient space is available in the location where you are copying the images. This location includes the active and standby supervisor module bootflash: (internal to the device). Internal bootflash: has approximately 250 MB of free space available.
    Hardware Avoid power interruption during any install procedure, which can corrupt the software image.
    Connectivity to remote servers
    Configure the IPv4 address or IPv6 address for the 10/100/1000 BASE-T Ethernet port connection (interface mgmt0).
    Ensure that the device has a route to the remote server. The device and the remote server must be in the same subnetwork if you do not have a router to route traffic between subnets.
    Software images
    Ensure that the specified system and kickstart images are compatible with each other.
    If the kickstart image is not specified, the device uses the current running kickstart image.
    If you specify a different system image, ensure that it is compatible with the running kickstart image.
    Retrieve the images in one of two ways:
    Locally
    Images are locally available on the switch.
    Remotely
    Images are in a remote location and you specify the destination using the remote server parameters and the filename to be used locally.
    Before an upgrade from Cisco NX-OS Release 6.1(x) to Release 6.2, apply either "limit-resource module-type f1" or "limit-resource module-type f2" to the storage VDC, and check that the following storage VDC configurations are removed:
    Shared F2(F1) interfaces with a storage VDC that supports only F1(F2)
    F1 and F2 interfaces in the same storage VDC
    The default Control Plane Policing (CoPP) policy does not change when you upgrade the Cisco NX-OS software.
    CoPP MAC policies are supported beginning with Cisco NX-OS Release 5.1, and default policies are installed upon execution of the initial setup script. However, if you use ISSU to upgrade to Cisco NX-OS Release 6.0(1), the default CoPP policies for the following features must be manually configured: FabricPath, OTV, L2PT, LLDP, DHCP, and DOT1X. For more information on the default CoPP policies, see the Cisco Nexus 7000 Series NX-OS Security Configuration Guide.
    When you upgrade to Cisco NX-OS Release 6.0(1), the policy attached to the control plane is treated as a user-configured policy. Check the CoPP profile using the show copp profile command and make any required changes.
    The upgrade to Cisco NX-OS Release 6.0(1) in an OTV network is disruptive. You must upgrade all edge devices in the site and configure the site identifier on all edge devices in the site before traffic is restored. You can prepare OTV for ISSU to Cisco NX-OS Release 6.0(1) in a dual-homed site to minimize this disruption. See the Cisco Nexus 7000 Series NX-OS OTV Configuration Guide for information on how to prepare OTV for ISSU to Cisco NX-OS Release 6.0(1) in a dual-homed site. An edge device with an older Cisco NX-OS release in the same site can cause traffic loops. You should upgrade all edge devices in the site during the same upgrade window. You do not need to upgrade edge devices in other sites as OTV interoperates between sites with different Cisco NX-OS versions.
    The upgrade from Cisco NX-OS Release 5.2(1) or from Release 6.0(1) to Release 6.1(1) in an OTV network is non-disruptive.
    VPC peers can only operate dissimilar versions of the Cisco NX-OS software during the upgrade or downgrade process. Operating VPC peers with dissimilar versions, after the upgrade or downgrade process is complete, is not supported.
    Starting with Cisco NX-OS Release 6.1(1), Supervisor 2 is supported. Therefore, there is no upgrade of Supervisor 2 from a previous Cisco NX-OS release.
    Link:
    http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/upgrade/guide/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide_Release_6-x.html#con_317522
    HTH

  • CoPP for PPPOE in 10008

    Hi folks.
    I have an issue with a 10008 acting as BRAS PPPOE server.
    when there is an outage somewhere between the 10008 and clients, all clients have to reconnect to the 10008, and this has a major impact on CPU of the 10008, hitting 100% and then having problem of handling about 12 000 reconnections attemps by customers. After painfully reaching 8000 connections OK, it does loose and get back connections for a while, and painfully reaches 12 000 connections back after a few hours.
    SSS manager process is about 20%
    ROUTER#sh proc cpu sorted
    CPU utilization for five seconds: 99%/19%; one minute: 99%; five minutes: 99%
    PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
    170      966348    109491       8825 22.54% 21.08% 20.83%   0 SSS Manager
    317      479292    238020       2013  9.59%  9.29%  9.41%   0 PPP Events
    333      209572     55311       3788  8.95%  5.50%  4.70%   0 VTEMPLATE Backgr
    310      336336     70939       4741  7.35%  7.60%  7.42%   0 PPPoE Discovery
    242      158484      3727      42523  5.19%  4.69%  4.61%   0 c10k_periodic_st
    181      232316     70878       3277  4.71%  4.94%  4.82%   0 SSM connection m
    243       73280       668     109700  4.23%  2.22%  2.10%   0 STATS DMA Daemon
      32      176984     40482       4371  3.43%  5.40%  6.14%   0 ARP Input
    328      146300     73268       1996  3.35%  3.17%  3.50%   0 RADIUS
    166       94528     71505       1321  2.15%  1.99%  2.04%   0 PPPoE Background
    324       27116     82403        329  1.43%  1.21%  1.10%   0 SNMP ENGINE
    150       57944     87227        664  0.95%  1.21%  1.30%   0 AAA Server
    169       28804     10270       2804  0.87%  0.20%  0.40%   0 PPP IP Route
    238       19464      3451       5640  0.79%  0.66%  0.60%   0 CEF: IPv4 proces
    161       18168    102918        176  0.63%  0.44%  0.41%   0 IP Input
    208       30860     70705        436  0.47%  0.74%  0.69%   0 IP Background
      49       31924     43991        725  0.47%  0.37%  0.42%   0 Net Background
      61        4304     42723        100  0.39%  0.17%  0.12%   0 IF-MGR control p
    278       30340     44381        683  0.31%  0.60%  0.64%   0 AAA SEND STOP EV
    172        8620     62002        139  0.31%  0.23%  0.20%   0 SSS Feature Mana
      94        3988      3186       1251  0.23%  0.16%  0.11%   4 Virtual Exec
    209        8048     10252        785  0.23%  0.08%  0.10%   0 IP RIB Update
    322        3616     12275        294  0.15%  0.15%  0.12%   0 IP SNMP
    330        1080     14005         77  0.07%  0.01%  0.00%   0 IPHC Admin
    143        3360     40211         83  0.07%  0.05%  0.05%   0 CCM
      77         400      8559         46  0.07%  0.00%  0.00%   0 C10K OIR process
    279        3440      1483       2319  0.07%  0.36%  0.29%   3 Virtual Exec
    152         928     82385         11  0.07%  0.01%  0.00%   0 ACCT Periodic Pr
    214        2732     64087         42  0.07%  0.07%  0.07%   0 static  
    I do think that I need to use CoPP for rate limiting pppoe packets to CPU and did try the following :
    class-map match-all COPP
      match protocol pppoe
    policy-map COPP
      class COPP
        police rate 500 pps burst 1000 packets peak-burst 0 packets conform-action transmit exceed-action drop violate-action drop
    control-plane
    service-policy input COPP
    However it looks like this is not working as no packet are matched :
    ROUTER#sh policy-map  control-plane
    Control Plane
      Service-policy input: COPP
        Class-map: COPP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol pppoe
          Police:
            rate 500 pps, 1000 limit, 0 extended limit
            conformed 0 packets, 0 bytes; action:
            transmit
            exceeded 0 packets, 0 bytes; action:
            drop
            violated 0 packets, 0 bytes; action:
            drop
        Class-map: class-default (match-any)
          150989 packets, 17708701 bytes
          5 minute offered rate 130000 bps, drop rate 0 bps
          Match: any                                     
    Any idea on what i'm doing wrong?
    I would like just to rate limit enough to be able not to hit 100 %CPU, and have a quick and steady recovery. Any other commands could help?
    thanks

    Hi Olivier,
    Indeed, I was also looking at some documentation in Cisco.com but couldn't find any document describing properly. I had some links stored in my bookmarks but they doesn't seem to be available anymore in the website.
    In any case, to explain the configuration of CAC, this is basically what you need to know (when using call admission new-model):
    - The call rejection is based on either, cpu-limit or charge limit, whichever is exceeded first.
    - The “limit” command specifies the total session charge the system will accept before incoming calls will be rejected.
    - You need to define the charge for each session. For example, “call admission pppoe 10 1” specifies the charge for a single PPPoE session:
    10 = session charge, 1 = session lifetime
    - Approximate CPS = (Limit) / (Session Charge * (Session Lifetime + 1))
    - cpu-limit of X means CAC will drop incoming calls when the measured 5-second CPU utilization is X% or higher
    You mentioned that you would like to have 12000 sessions to establish in 30 minutes. This would be a rate of aprox. 6.6 sessions per second (let's say 7). Based on the above, you would need to configure:
    call admission new-model
    call admission pppoe 10 1
    call admission limit 140
    call admission cpu-limit 60
    The above will allow 7 CPS (will drop new calls above that limit) and will drop new calls if the CPU load is above 60.
    I think 7 CPS is a reasonable rate for C10K (I do not have any official information to support that, though).
    Perhaps you can start exploring this with a config similar to the above.
    Best regards.

  • N5000 & ICMP Rate Limit

    All,
    Does the N5000 run an ICMP rate limiter by default ?
    I just connected a N5000 up to a C6500 chassis. When i ping the N5000 (inline ! on a SVI interface) from the C6500, he drops everytime the 95th ping request :-)
    TESTC6500#   ping 10.102.78.66 df-bit size 1500 repeat 100
    Type escape sequence to abort.
    Sending 100, 1500-byte ICMP Echos to 10.102.78.66, timeout is 2 seconds:
    Packet sent with the DF bit set
    Success rate is 99 percent (99/100), round-trip min/avg/max = 1/1/4 ms
    TESTC6500#   ping 10.102.78.66 df-bit size 1500 repeat 100
    Type escape sequence to abort.
    Sending 100, 1500-byte ICMP Echos to 10.102.78.66, timeout is 2 seconds:
    Packet sent with the DF bit set
    Success rate is 99 percent (99/100), round-trip min/avg/max = 1/1/4 ms
    TESTC6500#   ping 10.102.78.66 df-bit size 1500 repeat 100
    Type escape sequence to abort.
    Sending 100, 1500-byte ICMP Echos to 10.102.78.66, timeout is 2 seconds:
    Packet sent with the DF bit set
    Success rate is 99 percent (99/100), round-trip min/avg/max = 1/1/4 ms
    TESTC6500#   ping 10.102.78.66 df-bit size 1500 repeat 100
    Type escape sequence to abort.
    Sending 100, 1500-byte ICMP Echos to 10.102.78.66, timeout is 2 seconds:
    Packet sent with the DF bit set
    Success rate is 99 percent (99/100), round-trip min/avg/max = 1/1/4 ms
    TESTC6500#

    There is no (configurable) rate-limiter function in the N5k.  I think what you are seeing is a result of process/scheduler timing, but I would have to look up some tests to back that up.
    I can do the same operation and I see the packet mising is either 95, 96, none, 97... it varies.  With a true rate-limiter, you will typically see a much more defined pattern.
    The Nexus 7000 has hardware and software control-plane policing (CoPP), but the Nexus 5000 does not.  I think it's possible you will see software CoPP in the Nexus 5000 in the future, but time will tell.
    Regards,
    John Gill

  • Is Cisco Nexus 5596UP support vlan base Policing and traffic shaping on code NX OS version: 5.1(3)N1(1)

    Is Cisco Nexus 5596UP support vlan base Policing and traffic shaping on code NX OS version: 5.1(3)N1(1)
    where i couldn't see any police command under the policy map 

    I have tested this issue on another 5548UP with L3 running the same NX-OS version and get the same problem. Show CDP from the switch is not discovering devices, but the neightbors can see the 5K in question. Reboot sometimes will fix it, but not always. I suspect a problem with the software since that doesn't happen in NX-OS 5.2. The one I am using is
    Software
      BIOS:      version 3.6.0
      loader:    version N/A
      kickstart: version 5.1(3)N2(1)
      system:    version 5.1(3)N2(1)

  • Control Plane Policing (CoPP) for Data Center

    Hi All,
    I am planning to apply CoPP on different routers and switches of Data Center. This Data Center comprises of Cisco 6513 (VSS), Catalyst 3750, Cisco 3845 and Cisco 2811.
    My question are:
    1. Do we have to apply CoPP on Catalyst 3750, as these are DMZ switches only?
    2. How to find the packet processing rate from router and switches?
    3. Any best practices CoPP template for routers running OSPF and BGP?
    Thanks and Regards,
    Ahmed.

    1. You would need to apply CoPP to all routers/switches that are 
    manageable from untrusted sites. So even if you have non-DMZ switches 
    that will be able to be telneted to from the outside for example, 
    CoPPing them would be helpful for you.Do we not need to apply
    CoPP on switches and routers that are not telneted from outside?
    Control plan traffic is traffic that goes to the control plane of the router like management traffic, snmp etc. If there is a firewall securing you from the outside I would feel my switches are more secure and it is not easy to bring them to their knees with an attacker doing too much from the outside. Control plane policing applies to all control plane traffic, but it is mostly against outsiders that someone would try to protect himself.
    2. "sh proc
    cpu" would give you some  insight for processes like ssh or telnet and
    how much the take. Not  control packet rate processing though.I
    want to know the maximum packet processing rate of a router or switch?
    I don't think you will be able to pull that number.
    3. Depends
    on how powerful the  router is, how many commands you are running, how
    much route processing  is going on.Best practice for a router
    running OSPF with 200 routes?
    Don't know of any.
    PK

  • Nexus 7010 ARP and COPP

    Hellow Nexus Gurus,
    I have had numerous instances where Broadcom NICs on Dell servers have started storming the LAN with directed ARP requests (unicast) for addresses off the subnet of the station sending the request.  I've had stations send 2GB of ARP requests to the 7K in under a minute in some cases.  Oddly this has not completely taken out the data center.  It has only caused weird temporary outages to some servers throughout various subnets.  I have no idea why the EDC wasnt taken out but I assume that many servers were saved due to the preconfigured COPP configuration.
    class-map type control-plane match-any copp-system-class-redirect
      match redirect arp-inspect
    Can anyone explain the behavior above as well as what that class-map does?
    Does anyone have a solution to prevent these unicast ARP storms in the future?
    Any insight would be much appreciated.
    /r
    Rob

    We are seeing issues with our Broadcom NIC, Dell, Hyper V servers with NIC teaming to seperate Nexus 2248's where random virtual servers will stop responding, sometimes the eventually start responding again sometimes we move them to a different chassis.  Is that the kind of "weird temporary outages" you were experiencing?  And how did you find the ARP storms?
    Thanks

  • Nexus 7000 - 1-rate, 2-color policer

    Hi All
    We have M224 module in N7K where we have a WAN circuit. This circuit takes all traffic , including replication. Now  - there is too much of activity on replication and we wanted to police replication traffic. I was interested in 1-rate, 2-color policer: ,  which will police replication traffic to 2 GB (say)....
    I already have a service policy type queueing on the interface, and ill apply service policy qos on the same interface. Hope its fine ?
    Will this work ?
    1) define ACL for replication traffic
    2) Create class map type qos, and apply the acl (should we also have class map default ?)
    3) create policy map similar to one below:
    policy-map type qos replication
    class type qos one_rate_2_color_policer
     police cir 2048000000 confirm transmit violate drop
    Can someone please help with this policing configuraiton ?
    Raj

    anyone ?

  • Nexus COPP troubleshooting question

    We are seeing a ton of violated bytes in one of our copp class-maps. I was wondering if some of you could give me some advice into chasing these down to see what they are and where they are coming from.

    yes, it does
    From the doc:
    Algo Boost technology is a set of hardware  functions that provide an ultra-low latency as low as 190 nanoseconds  (ns), even with features such as Network Address Translation (NAT) in  hardware.
    more info
    http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/ps12581/white_paper_c11-715262.html
    HTH

  • Nexus ping drops

    Hi,
    We have a nexus 5k acting as core in one of our sites.
    Problem:- When a user connects himself to nexus 2k port, the connectivity suddenly drops & ping message are gone with either destination host uncreachable or ping failure messages.
    This has been observer on many users.
    class-map type qos class-fcoe
    class-map type queuing class-fcoe
      match qos-group 1
    class-map type queuing class-all-flood
      match qos-group 2
    class-map type queuing class-ip-multicast
      match qos-group 2
    class-map type network-qos class-fcoe
      match qos-group 1
    class-map type network-qos class-all-flood
      match qos-group 2
    class-map type network-qos class-ip-multicast
      match qos-group 2
    We saw these configurations on the switch. will these cauese any problems?
    Appreciate if some suggestions come up!
    Appreciate all help!

    Hi,
    Depending upon which Nexus platform and which NX-OS version you're running, it's quite possibly the Control Plane Policing (CoPP) feature, introduced in NX-OS 5.1(3)N1(1), that's causing the drops.
    You can see if that's the case using the show policy-map interface control-plane and look for incrementing violations in the class that matches ICMP. There's a fair amount of information in the output so I find the quickest way to spot this is using the show policy-map interface control-plane | in "class|violate" command and look for a non zero value. Assuming the default configuration, on the Nexus 5000 this will be the copp-system-class-icmp-echo
    You can find further information about CoPP in the Configuring Control Plane Policing section of the Nexus 5000 Security Configuration Guide.
    Regards

  • Nexus monitoring, device recource metrics

    Hello
    I'm looking for Nagios/Nexus Plugins and lesson learned is, that there seams to be currently (2011/10/20) nothing at all.
    So I want to start with this and want to ask the experts about the basics of Nexus monitoring.
    What is the best practice to monitor Nexus device recource metrics? NetConfig, SNMP, SSH with preshared key?
    For Netconfig are there any documentation how to can use it with Perl?
    If SNMP should be still the best, are this OIDs known or what should be the best method to get them out?
    Are there SNMPv3 issues e.g. with views?
    How to find out the Nexus OID's for its IOS-equivalents, e.g.
    "Voltage" => ".1.3.6.1.4.1.9.9.13.1.2",
    "Temperature" => ".1.3.6.1.4.1.9.9.13.1.3",
    "Fan" => ".1.3.6.1.4.1.9.9.13.1.4",
    "PSU" => ".1.3.6.1.4.1.9.9.13.1.5"
    ModuleState ?
    How to find out OIDs for special CLI commands, e.g. traffic class violations:
    sh policy-map interface control-plane | egrep "class-map|violated"
        class-map copp-system-class-normal (match-any)
            violated 5394687638 bytes; action: drop
    If Netconfig is to complicated and finding Nexus SNMP-OIDs is an unresolveable neightmare, can SSH with preshared key could be an oportunity for permanent monitoring?
    many thx in advance for your hints and ideas,
    Steffen

    Though Nexus 7004 is supported from LMS 4.2.2 onwards, but it is in a restricted support :
    The following features are supported:
    Fault Management
    Network Topology Layer 2 Services
    The following features are not supported:
    Inventory Collection , User Tracking, VLAN Management, VRF Lite, LANE Management
    Configuration Deploy Protocols: HTTPS, SCP, RCP, TELNET, TFTP, SSH
    Configuration Fetch Protocols: HTTPS, SCP, RCP, TELNET, TFTP, SSH
    Software Distribution by: Advanced flow, Image, Remote Staging
    Software Repository Synchronization
    CiscoView
    Software Image Types for Distribution: System Software, Bootloader
    Software Images Import from: Cisco.com, Device, File System, Network, URL
    Upgrade Analysis from: Cisco.com, Repository
    Software Image Import Connection Protocols: SNMP
    Software Image Import Transfer Protocols: TFTP,  TELNET
    Software Image Distribution Transfer Protocols: TFTP, TELNET
    Software Image Distribution Connection Protocols: SNMP
    If this is not working, it is only that the essential device package seems to be missing. please do the following :
    1. Download all device packages available for LMS server :
         Step 1: Open command prompt on server.
         Step 2: Run following cli command :
    psucli -p rme,cmf,dfm,cvw,upm,cm -download -dst C:\test_download -all
    **Created test_download dir or name some existing.
         Step 2: Check the downloaded files, if they are in diffrent folders inside download dir, copy all of them to a common folder and run this command :
    psucli -p rme,cmf,dfm,cvw,upm,cm -install -src D:\test_download -all
    **use directory you downloaded packages to
         Step 4: Check the device if it shows nexus 7004 information or not.
    Share results.
    -Thanks
    Vinod
    **Rating Encourages contributors, and its really free. **

  • DCBX Between Linux and Nexus QOS

    Hi Guys
    i have a server with 2 physical links only.
    over this link im passing 2 vlans in trunk ( can be Portchannel to VPC or bond active passive , doesnt matter to me ) .
    vlan 302 is for data
    vlan 303 is for backup
    server on vlan 303 is pushing traffic on that link and would take as much
    bandwidth as we would give it , and would therefore cause communication issues to vlan 302 . ( congestion ) .
    I would like to talk about my options here , to avoid congestions .
    thought about enabling dcbx on clients ( linux ) and pfc ( priority flow
    control ) to be able to negotiate qos and bw allocation according to COS IEEE 802.1p .
    the idea is to have either the traffic prioritized/limit/shaped before/when its ingressing the nexus port .
    the dcbx looks very cool like i said , it's kind of like what the nexus has with the CNA Card .
    when it can send the linux nic through dcbx the qos parameters to apply ! ( ah ok , i see now its exactly the same )
    ps linux dcbx link : http://manpages.ubuntu.com/manpages/precise/man8/dcbtool.8.html
    Ingress Queuing Policies
    You can associate an ingress policy map with an Ethernet interface to guarantee bandwidth for the specified traffic class or to specify a priority queue.
    The ingress policy is applied in the adapter to all outgoing traffic that matches the specified CoS value.
    When you configure an ingress policy for an interface, the switch sends the configuration data to the adapter. If the adapter does not support the DCBX protocol or the ingress policy type-length-value (TLV), the ingress policy configuration is ignored.
    did anyone here tried it or implemented dcbx before ?
    anyway id be happy to hear your wise and helpfull suggestions please
    Thanks Thanks !!!

    Found the answer.
    Anatomy of RX packet counters on a Cisco Nexus 5548:
    Nexus5548# show int eth1/29 
      RX      
        6387682660 unicast packets  1495485 multicast packets  164 broadcast packets 
        6389178309 input packets  589693485138 bytes
        5146969 jumbo packets  0 storm suppression bytes
      * "input" = unicast + multicast + broadcast (all non-jumbo)
      * "jumbo" = frames sized 1519 bytes to the MTU bytes defined on the interface
      * "jumbo" frames are counted separately from non-jumbo ("input")
      * (unicast, multicast and broadcast "jumbo" frames appear to be rolled into the 
            one "jumbo" counter)
    This can be seen another way with the 'count detail' command, correlated to "show int" output:
    Nexus5548# show int eth1/29 count detailed
    Ethernet1/29
      Rx Packets:                                  6389178309 <-- input
      Rx Unicast Packets:                          6387682660 <-- unicast
      Rx Multicast Packets:                           1495485 <-- multicast
      Rx Broadcast Packets:                               164 <-- broadcast
      Rx Jumbo Packets:                               5146969 <-- jumbo
      Rx Bytes:                                  589693485138
      Rx Packets from 0 to 64 bytes:                  1059418 <-- non-jumbo start
      Rx Packets from 65 to 127 bytes:             6072007478       +
      Rx Packets from 128 to 255 bytes:              11055520       +
      Rx Packets from 256 to 511 bytes:             287107435       +
      Rx Packets from 512 to 1023 bytes:             12801466       +
      Rx Packets from 1024 to 1518 bytes:                  23 <-- non-jumbo end
      Rx Trunk Packets:                            6387682823 <-- unicast + broadcast
    fyi.

  • Nexus 7K VPC

    Hi,
    We have two Nexus 7K in our data centre with N7K-M132XP-12(10G) module and N7K-M148GT-11(1G) module
    Also both 7K has two supervisor module in active/standby mode
    vpc keep alive and vpc peer link( on port channel) is setup on 10G module between both 7K's
    Im currently planning for an NX-OS upgrade and i wanted to keep the vpc keepalive/vpc peer link active during the process
    my questions:
    1. Is it a must to use 10 gig ports otherwise the peer link and keepalive will not form
    2. can i configure vpc keep alive and peerlink on the 1G N7K-M148GT-11 copper module
    3.can i form two sets of vpc keepalive and peerlink in two different vpc domain, so during the upgrade when one slot reboots, the other slot will keep the vpckeepalive and peerlink active
    4. can i use the management modules on the supervisor modules to configure vpc keep alive
    apart from the above question, could u just provide the best practice for my situation

    Hi Oleksandr,
    ISSU which upgrades only the control plane. Would this be considered to be a complete OS upgrade
    I have seen ur other discussion about control and data plane fucntionality..
    When only the control plane gets updated, i understand all routing and other fucntionality gets updated but would it be applied to the physical hardware like supervisor modules and other line cards ?
    since u mentioned that data plance will not upgraded(traffic is not interupted). what happens when only control plane is upgraded and not the data plance ?
    would the supervisor modules and line cards not be able to make use of the new fucntionality since the data plane is not upgraded ?

  • My list of Nexus problems:

    First Android phone, bought-out AT&T contract to switch to Verizon ... for the network. :-/
    1. Reception
    Phone will periodically lose signal altogether as I move around inside my house. Never had ANYthing but 4-5 bars with my iPhones (switched b/c of signal on AT&T where I work, in another town). At best my Nexus gets MAYBE two bars, and only when I'm literally next to the window.
    Last night my extended battery drained completely, phone was dead when I woke up. Once it charged enough to turn on I saw it went from about 60% to 0% in three hours or so where it was apparently searching for a network signal ('network connection' bar was red, as opposed to its' normal orange). Even using the phone in the middle of the LTE service area I bought it for I only get a spotty connection.
    2. Battery
    See issue number 1., also the fact that this thing eats battery for lunch, even when it's doing NOTHING. I have the extended battery. Maybe I am spoiled by the iPhone, but I used to go days at a time without charging that thing. Even when I have the Nexus PLUGGED-IN to my car charger, it will often use charge faster than it can replace it. I mean...wow. 
    3. Random Rebooting
    Was in the middle of listening to a song on headphones the other day when all of a sudden the screen goes black and I hear a painfully loud 'crack!' in my headphones while the phone apparently resets. 
    I should say that I really love this phone - well, I love the OS - and if it functioned acceptably I would certainly prefer it to the iPhone. I figured all the talk amongst the Apple faithful about Android's failings were exaggerated, and perhaps they are, but I want to see these problems fixed SOON or I will be returning the phone and switching back to AT&T early next week. Not to mention getting a lot of "I told you so"s that I'm not ready to deal with. Really this phone should not have been released in the first place with all these issues, but I don't know who to pin them on. I guess that's what happens when one 'experience' is made by three (or more) companies, one of whom at least have serious control issues (I'm looking at you Red).
    Feeling duped.

    malikona wrote:
    First Android phone, bought-out AT&T contract to switch to Verizon ... for the network. :-/
    1. Reception
    Phone will periodically lose signal altogether as I move around inside my house. Never had ANYthing but 4-5 bars with my iPhones (switched b/c of signal on AT&T where I work, in another town). At best my Nexus gets MAYBE two bars, and only when I'm literally next to the window.
    Don't go by the bars on the phone. Check the signal level out with any one of the apps that will show you the actual signal level, not just bars. The bars are not exaggerated like they are on most phones. I used Open Signal Maps that show me the actual signal strength, not the interpretation into 'bars' Bars can be faked by the OS (re Apple) and can show more 'bars' than the signal strength would suggest.
    Last night my extended battery drained completely, phone was dead when I woke up. Once it charged enough to turn on I saw it went from about 60% to 0% in three hours or so where it was apparently searching for a network signal ('network connection' bar was red, as opposed to its' normal orange). Even using the phone in the middle of the LTE service area I bought it for I only get a spotty connection.
    2. Battery
    See issue number 1., also the fact that this thing eats battery for lunch, even when it's doing NOTHING. I have the extended battery. Maybe I am spoiled by the iPhone, but I used to go days at a time without charging that thing. Even when I have the Nexus PLUGGED-IN to my car charger, it will often use charge faster than it can replace it. I mean...wow. 
    I doubt the phone is doing NOTHING..... check out Settings-Data usage, and you will see what your phone is doing behind the scenes..... there is a LOT of stuff happening involving the radio most of the time.....
    But with that said, yes, this battery seems to drain a little quicker than my Droid X.... but lets look at the difference between the phones...... Nexus has a dual core, X has a single core, Nexus as a 4g radio, X has only a 3g radio..... Nexus screen 4.65, X 4.3...
    Yep.. the Nexus will eat the battery a little more quickly.... remember, does your laptop last all day running? If not, you really cannot expect a smart phone (which is a small POWERFUL computer) to last like that..... but that is my opinion
    3. Random Rebooting
    Was in the middle of listening to a song on headphones the other day when all of a sudden the screen goes black and I hear a painfully loud 'crack!' in my headphones while the phone apparently resets. 
    My Nexus rebooted on its own once.... and I have not been able to recreate it... That was after I made a mistake dialing and shut the call off as soon as I could. Did this happen only once? If it happens more than once, does it happen on the same song everytime it reboots? Too many questions to say that it is randomly rebooting.. there might be a
    I should say that I really love this phone - well, I love the OS - and if it functioned acceptably I would certainly prefer it to the iPhone. I figured all the talk amongst the Apple faithful about Android's failings were exaggerated, and perhaps they are, but I want to see these problems fixed SOON or I will be returning the phone and switching back to AT&T early next week. Not to mention getting a lot of "I told you so"s that I'm not ready to deal with. Really this phone should not have been released in the first place with all these issues, but I don't know who to pin them on. I guess that's what happens when one 'experience' is made by three (or more) companies, one of whom at least have serious control issues (I'm looking at you Red).
    Feeling duped.
    Why are you feeling duped? Most of what you said are not problems with the phone, you expectations are a little high. I am not trying to be mean or flame throwing, or insult you in any way. But a lot of perceived problems are not really problems at all. Remember that Android apps are not always up to our standards for apps, and sometimes they cause more problems. Apple does have an edge there because they police the way apps interact with the phone. But that closed system is also a curse. There are many good app developers out there that will not do iPhone apps because of the control that Apple puts on their developers.
    Today is not a good day to try to troubleshoot the network. Verizon has a whole set of problems with 3g/4g today and if affects more than the Nexus phone, its affecting the whole network.

Maybe you are looking for