Ethernet packet drops

I'm losing close to 50% of my packets when hard wired. No issues with AirPort, and no packet loss when any other system plugs into any of the switches. It is an issue regardless of the switch being plugged into.

Check this thread regarding 802.1Q:
http://discussions.apple.com/thread.jspa?threadID=378673
PowerBook G4 17" 1.33 GHz 2GB/80GB Mac OS X (10.4.5)

Similar Messages

High packet drop over FCoE setup

We have nexus 5k switch connected to storage array through FCoE 10GB interface and with blade chasse support FCoE. We are facing a hug latency on the traffic flow between the server and the storage. Can some one help me to solve this issue? Also do we need to setup the jumbo frame and modify the MTU size?
Sent from Cisco Technical Support iPad App

Aymen,
MTU should not be an issue. No need to modify the MTU for regular ethernet traffic, unless you're using IP storage such as iSCSI.
Let's narrow down the problem first.
1. Do you see packet loss/performance issues on other servers connected to the same N5K(s)?
2. Are you seeing any packet drops on the N5K interfaces or GATOs ASIC?
show interface e1/20 counters errors
show interface e1/20 flowcontrol
show interface e1/20 priority-flow-control
show system internal ethpm errors | egrep Ethernet1/20
show hardware internal gatos port ethernet 1/20| egrep -i err
I would check these counters on both the host facing and arrary facing interfaces.
3. What is the exact array that is FCoE attached?
4. Do you have a topology diagram?
5. What are the server side adapters, firmware and driver versions being used (include the OS on the host).
Regads,
Robert

Input packet drops on uplink port-profile

Hi,
I'm using Nexus 1000v and vSphere 5.1;
I just migrated some physical servers to VM, and I have some weird reporting issues;
Just to make sure it wasn't a network issue they asked me to verify if anything was overlooked on the Nexus side of things;
Everything checked out, but I'm seeing a lot of input packet drops on the physical ports of the system uplink port-profile; I doubled checked the configs on the VSM and the Catalyst stack and all is configured properly;
should I be concerned about these Input packet drops that I'm seeing on the VSM on the physical interfaces of my uplink port-profile? If so, could it be the NICS in the ESX host that could be the issue?
Any feed back would be appreciated;
Thanks.

I have the same symptomps on 3 different Nexus 1000v. All 3 run the same version - 4.2(1)SV2(1.1) VMware is 5.0 sp1 and the hardware for ESXi hosts is more or less the same (At least server blade model and CNA).
We have tried to use vempkt to capture traffic but no traffic is captured if we filter on drops even though the counter on the port-channel and member Ethernet interfaces increase. On the hosts we tried vempkt we see about 20 drops per second. Here is some info. I have removed some irrellevant stuff.
NRK-VSM-001# show int po 14
port-channel14 is up
Members in this channel: Eth6/3, Eth6/4
6172 input packet drops <- Increases
NRK-VSM-001# show mod 6
Mod Sw                  Hw
6    4.2(1)SV2(1.1)      VMware ESXi 5.0.0 Releasebuild-1024429 (3.0)
Mod Server-IP        Server-UUID                           Server-Name
6    10.16.1.12       4c4c4544-0034-3010-8036-b4c04f33354a nrk-vi01-h07.nt.se
FROM The ESXi
~ # vemcmd show port
LTL   VSM Port Admin Link State PC-LTL SGID Vem Port Type
   19     Eth6/3     UP   UP    F/B*    305     0    vmnic2
   20     Eth6/4     UP   UP    F/B*    305     0    vmnic3
~ # vempkt show capture info
Stage : Drop
     LTL : 305
    VLAN : Unspecified
    Filter : Unspecified
Even if we let the capture run for several minutes we see no drops. I set it to capture 31 packets.
~ # vempkt show info
                 Enabled : Yes
    Total Packet Entries : 0       <- Never increases even if the capture is running filtered like above
Wrapped Packet Entries : 0
     Lost Packet Entries : 0
Skipped Packet Entries : 560145
Available Packet Entries : 14169
     Packet Capture Size : 88
     Packet Capture Mode : Un Reliable
Stop After Packet Entry : 31
In our case, could the input drops depend on that we allow vlans from the upstream hardware switch to the VEM that do not exist on the N1000v and that this is the reason we can not capture the dropped packets?
Any ideas?
PS: We see drops on uplinks on all VEMs

Network packets dropped

Hi,
I have a sun server X3-2, 3x 1Gb Nic, 1x 10Gb Nic. I installed OVM Server 3.2.1.
I'm seeing network packets dropped at OVM Server and also virtual machines. I need some help to trousbleshoot this problem. Below is ifconfig from OVM Server,
101cdcd51d Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E9
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2583993 errors:0 dropped:159 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:131036673 (124.9 MiB) TX bytes:0 (0.0 b)
104dd3b9b6 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:EA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2971119 errors:0 dropped:308152 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:173808870 (165.7 MiB) TX bytes:0 (0.0 b)
10812417eb Link encap:Ethernet HWaddr 00:10:E0:0F:4E:EB
inet addr:172.18.20.21 Bcast:172.18.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:79785265 errors:0 dropped:308147 overruns:0 frame:0
TX packets:59666982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5272272043 (4.9 GiB) TX bytes:213770574164 (199.0 GiB)
ac120a00 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E8
inet addr:172.18.10.14 Bcast:172.18.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37411282 errors:0 dropped:27211 overruns:0 frame:0
TX packets:26454994 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26791781952 (24.9 GiB) TX bytes:66747028706 (62.1 GiB)
ac120a00:0 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E8
inet addr:172.18.10.21 Bcast:172.18.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
bond0 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E8
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:25398774 errors:0 dropped:149288 overruns:0 frame:0
TX packets:53556134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:13158783040 (12.2 GiB) TX bytes:58483952392 (54.4 GiB)
eth0 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E8
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:25398774 errors:0 dropped:0 overruns:0 frame:0
TX packets:53556134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13158783040 (12.2 GiB) TX bytes:58483952392 (54.4 GiB)
eth1 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:E9
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60907850 errors:0 dropped:149288 overruns:0 frame:0
TX packets:46274656 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:55810386302 (51.9 GiB) TX bytes:9002478487 (8.3 GiB)
eth2 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:EA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5385839 errors:0 dropped:149288 overruns:0 frame:0
TX packets:1980840 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:597573454 (569.8 MiB) TX bytes:1870009913 (1.7 GiB)
eth3 Link encap:Ethernet HWaddr 00:10:E0:0F:4E:EB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3083698952 errors:0 dropped:149288 overruns:0 frame:0
TX packets:2206053130 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3204785408535 (2.9 TiB) TX bytes:2844843875054 (2.5 TiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:289418 errors:0 dropped:0 overruns:0 frame:0
TX packets:289418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:575239287 (548.5 MiB) TX bytes:575239287 (548.5 MiB)
tap2.0 Link encap:Ethernet HWaddr 86:01:23:DD:30:45
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:46239049 errors:0 dropped:0 overruns:0 frame:0
TX packets:60793985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:9000848211 (8.3 GiB) TX bytes:55803051642 (51.9 GiB)
tap2.1 Link encap:Ethernet HWaddr BA:AA:64:41:45:C9
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40433024 errors:0 dropped:0 overruns:0 frame:0
TX packets:33831126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:44233509682 (41.1 GiB) TX bytes:9093090370 (8.4 GiB)
tap2.2 Link encap:Ethernet HWaddr 62:65:11:65:D6:D1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19737692 errors:0 dropped:0 overruns:0 frame:0
TX packets:19458130 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:16177172226 (15.0 GiB) TX bytes:5121148316 (4.7 GiB)
vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vif2.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vif2.2 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vif7.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4214308 errors:0 dropped:0 overruns:0 frame:0
TX packets:8060734 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:7340812076 (6.8 GiB) TX bytes:6143519413 (5.7 GiB)
vif15.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26718295 errors:0 dropped:0 overruns:0 frame:0
TX packets:27375858 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:30597536250 (28.4 GiB) TX bytes:23460283180 (21.8 GiB)
vif24.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8920840 errors:0 dropped:0 overruns:0 frame:0
TX packets:10589487 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:77502033529 (72.1 GiB) TX bytes:9979589042 (9.2 GiB)
vif35.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:179700 errors:0 dropped:0 overruns:0 frame:0
TX packets:171511 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:60900250 (58.0 MiB) TX bytes:1544469271 (1.4 GiB)
vif35.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:67196487 errors:0 dropped:0 overruns:0 frame:0
TX packets:71343770 errors:0 dropped:75 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:135310654804 (126.0 GiB) TX bytes:272303511292 (253.6 GiB)
Thanks for your help.
Regards
Dean
Edited by: user9256256 on May 11, 2013 8:25 PM

Looks you've tried to setup a bond between various members on bond0. It doesn't appear your bond is working correctly.

Customer packet drops issue

Hi,
Our customer took 30Mbps metro link from us. Even at 17Mbps link utilization they are facing packet drops. Our side policer is implemented for 30Mbps. There are no errors on customer or our interfaces. But I can see exceed packets under 'show policy-map interface' . Used maximum Bc. Does customer required to implement shaping his end with same CIR and Bc.
Regards
Siva K

Hi Siva,
It is not a mandatory rule that Customer should also have the same CIR configured with shaping.
When Customer have 30 Mbps circuit SLA with Service Provider, he may be able to pump ta line rate from CE side. But on PE side, it will be policied and excess traffic will be dropped.
To avoid Customer's traffic getting dropped at PE, It is advisible to configure shaping at CE side so that the traffic SLA will be maintained without or with less number of packet loss.
Can you post your config and show policy-map interface output with traffic?.
Regards,
Nagendra

Packet drop when clients moving from one Access point to another

HI All ,
I am new to wireless . I am using WS-SVC-WISM-1-K9 wism module and using 5 Access points . When my clients are moving from one access point to another we are getting packet drops .
Kindly anyone suggest me what all configuration i need to verify on the controller for Proper client roaming so that i can resolve my issues..
Please let me know in case of any explanations requiered .
Thanks in Advance !!!
Regards
Angus

For radius authenticated SSIDs, you need WPA2-aes or wpa1-tkip-CCKM. It depends on what the client supports.
For pre-shared key, any WPA should be decent enough for roaming speed.
If you're on WEP ... no comment.
If you covered the above point, check if it's not a coverage problem. If the 2 APs coverage zone are not overlapping there will be a hole where you don't have signal and logically will have packet drops.

Wireless AP 1262 getting packet drops whille buffering videos for 18 users.

Hi Team,
Please help for this issue
We are having 1262 Access point model and we are getting packet drops when 20 users are connected and users do Video streaming and buffering online.
Even our AD IP address also getting packet drops during the users are connected and using youtube or someother video sites.
Please help on this issue.
Best regards,
Arun

Well if you have 802.11n enabled and also have 802.11n capable devices, then you would have max of 144mbps on the 2.4ghz and up to 300mbps on the 5ghz with 40 MHz channels. If you are using 20mhz on the 5ghz you will have the same as the 2.4ghz which is again 144mbps.
So if you have clients working fine on the 5ghz and its set to 20mhz, then I would look at interference on the 2.4ghz. See if your SNR is low as that will identify a poor 2.4ghz spectrum.
Sent from Cisco Technical Support iPhone App

N7000 : details of packets dropped by COPP policy (class-default) ?

Hi,
On one of our N7K, we have some packets dropped by the COPP policy in the class-default class-map. :
Partial results of "show policy-map interface control-plane" not so long after clearing the counters :
class-map class-default (match-any)
      set cos 0
      police cir 100 kbps , bc 250 ms
      module 1 :
        conformed 12210790 bytes; action: transmit
        violated 201870 bytes; action: drop
      module 2 :
        conformed 8399646 bytes; action: transmit
        violated 0 bytes; action: drop
      module 3 :
        conformed 34518233 bytes; action: transmit
        violated 6186895 bytes; action: drop
What would be the best way to figure out what traffic is dropped by the policy ? Is there any logging possible ?
Thanks,
Laurent

There is still no logging possible.
What can be done is piping the class-default-traffic to some port and then analyze it with wireshark or some similar tool. But as far as I know, this still cannot be done by default - at least with NX-OS 4.2(4) we had to reprogram the module with assistance from TAC. I suggest you contact your support partner in this matter.

EEM -automatic shut down or switch over of WAN link in OSPF when packet drop increase

Hi,
Need help..
can any one help me how can EEM help for automatic shut down or switch over of WAN link in OSPF when packet drop increase a predefined level.
I have a set up different branches connected together...OSPF is the routing protocol and need to communicate with two branches via hub locations.
need to shut or switch some percent of traffic from primary to back up when packet drop in the link.

I am not sure EEM can do what you want.
Another option could be to use SLA tacking/monitoring. But you will fall back to the new route when you lose some percentage of pings, you can't switch only part of the traffic.
I hope it helps.
PK

Signature 1330 causes packet drops

Hello Members,
i see in my IPS-NME module a hign number of packet drops because of the following signatures:
1330-17: TCP segment out of state order
1330-12: TCP segment is out of order.
the targets and the attacers are internal hosts.
are these signatures triggered because of not propper configured policies or is this an indicator for problems in the internal network.
thanks for your inputs.
regards
alex

Hello Sid,
thanks for your answer. I learned that most of packets where the Signature 1330 triggers are packets from the IPS module to the IPS Express Manager. I added wireshark dump to the case.
That's really odd, i ran a traceroute from the IPS Manager to the IPS Module and vice versa and the flow look ok to me.
Trace from the IPS module to the IPS Manager
# trace 10.0.128.5
traceroute to 10.0.128.5 (10.0.128.5), 4 hops max, 40 byte packets
1 172.16.1.9 (172.16.1.9) 1.479 ms 1.327 ms 1.275 ms
2 172.16.1.1 (172.16.1.1) 3.616 ms 2.952 ms 1.907 ms
3 10.89.27.10 (10.89.27.10) 2.288 ms 2.044 ms 2.136 ms
4 10.89.27.21 (10.89.27.21) 8.106 ms 9.148 ms 8.266 ms
return path
C:\Users\Administrator.NOS-POC>tracert 172.16.1.11
Tracing route to 172.16.1.11 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms 10.0.128.1
2     2 ms     3 ms     2 ms 172.16.2.1
3     1 ms     1 ms     1 ms 10.89.27.22
4     9 ms     9 ms     9 ms 10.89.27.9
5     8 ms     8 ms     8 ms 172.16.1.6
6     8 ms     8 ms     8 ms 172.16.1.11
Trace complete.
trace from the IPS module's gateway
#traceroute vrf CENTRAL 10.0.128.5 source 172.16.1.9
Type escape sequence to abort.
Tracing the route to 10.0.128.5
1 172.16.1.1 0 msec 0 msec 0 msec
2 10.89.27.10 0 msec 0 msec 4 msec
3 10.89.27.21 8 msec 8 msec 8 msec
4 172.16.2.6 8 msec 8 msec 4 msec
5 10.0.128.5 4 msec 4 msec 4 msec
what make me wonder is that the IPS module doesn't show hops further than 4 hops.
regards
alex

Specialized ethernet packet type receipt?

Greetings,
I'm writing a specialized module which requires that I be able to tell the OS, "Give all ethernet packets of type X to me." In linux this is achieved with a little understanding of the sk_buff, packet_type structures and a call to dev_add_pack(struct packet_type *).
Since I can no longer get the Solaris source, can someone please enlighten me as to what I might do to accomplish this?
Cheers,
Sam
[email protected]

Sam,
The Sys V Unix way is to write a protocol handler that's written to talk to a DLPI provider (i.e. the network interface device driver). You specify the Ethernet type by putting it in the dl_sap field of a DL_BIND_REQ mesage.
While OS source can make these things quite a bit easier, DLPI is a published, open specification and has been for nearly two decades.
GCOM has implemented DLPI (and STREAMS) on Linux. You can read about DLPI and STREAMS from a Linux perspective at
http://www.gcom.com/home/linux/streams.html
You'll want to look at their ip_strms module to help you grok DLPI from a protocol handler perspective. You can find the source code at http://www.gcom.com/home/linux/lis/drvrs.html.
Regards,
Richard Masoner
http://www.masoner.net/

How to get ethernet packet directly from adaper in labview6.1

I want to get the ethernet packet directly from adaper directly. Which control or function should I use?

If you really need to work with raw ethernet frames, I think you'll want to turn to something outside of built-in LabVIEW functionality.
One approach would be to purchase or download dedicated packet-capture (aka packet sniffer, network monitor) software that provides a developer API (e.g. a DLL with various packet access/filtering/analysis functions), then access that API from LabVIEW (e.g. by using the Call Library Function Node).
Here's one such piece of software, called WinPCap:
http://winpcap.polito.it/
You didn't give many details about your application.
So, I'm going to get up on my soapbox for a moment and urge you to reconsider whether you really need to go this low-level. I'd suggest carefully defining your goal and making sure you can't a
chieve it with higher-level functions like TCP Read and TCP Write in LabVIEW.
Best Regards,
John Lum
National Instruments

How do I create, send and receive ethernet packets to UUT

I need to create and send ethernet packets to control and communicate with an RF board. I would also like to receive ethernet packets back which would be parsed and interpreted.

There you are!
I was wondering how this project was going.
As I said before, we need to know what protocol is being used.
Let me eaxplain. (Please refer to the diagrams and tutorial on pages 752-755 of 2002 NI catalog.)
802.3 is the spec for ethernet. It defines how packets will be transmitted on the wire.
Real Life analogy:
US Mail service.
It moves messages from one place to another. It defines that messages should be in an envelope. The Envelope must have a address so they know where it should be delivered to. You should also have a return address (but this is not enforced). Inside the envelope, you can put any kind of message you want as long as the person recieving it knows how to read it. The
reciever can look at the message and say "oh, this is english, I will read it in english".
Ethernet is similar. Ethernet (ignoring the electrical specs) defines a packet as consisting of
Source address (return address in US mail)
Destination address (delivery address)
Protocol (pretend there was a mark on the envelope that said this letter is in French).
Data (the letter itself)
Checksum (letter pages number as 1 of 4, 2 of 4, etc).
So what you have told me so far is that you want to send a letter!
You have been asking me how to comunicate with the other person but you have not told me what language they speak!
There are many different languages (i.e. protocol's) possible with 802.3.
Examples are
TCP/IP ( say this is English)
UDP (French)
etc....
LV has built in VI's to take a message and convert it to the protocol (lanuage) you want and send it on it's way.
So my question to you once more is;
What protocol are you using?
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Monitoring dscp ef packet drops

Looking for some guidance please.
I have been tasked by our network team to find a solution to monitor voice traffic specifically for packet drops in dscp ef traffic.
Thinking of using my cacti box as my first port of call but need to know exactly which OIDs i need to be pulling in. I have looked at the various mib sets related to qos cos etc.... but to be honest, they are bit daunting for someone who is not familiar in this area.
Any other options for this would be greatly appreciated - could rmon fulfill this task?
cheers

You can troubleshoot the output drops occuring with priority queuing be following the sugesstions made in http://www.cisco.com/en/US/tech/tk39/tk51/technologies_tech_note09186a0080103e8a.shtml

Packet drops on v490 production server..help us

Hello...
We have v490 server with ce0 interface configured.. It gets down frequently & after some packet drops it makes itself up...
Can anybody tell me what could be the reason behind this problem...
I have checked switch & router by changing interface cables, still problem persists...no message on /var/adm/messages.
Thanks in advance
gmraj

try a "snoop -d ce0" and verify messages
also, perhaps the NIC is broken
also, perhaps the duplex/speed of the NIC isn't set correctly (autoneg, forced, fullduplex, halfduplex etc.) and you have to define it with a "ndd -set "

Ethernet packet drops

Similar Messages

Maybe you are looking for