Results 1 to 6 of 6

Thread: Any Cisco CCNA engineer able to describe what "UDP error" is in CiscoWorks?

  1. #1
    Senior Member
    Join Date
    Jul 2003
    Location
    Reading, Berkshire
    Posts
    1,250
    Thanks
    64
    Thanked
    53 times in 34 posts
    • tfboy's system
      • Motherboard:
      • MSI X470 Gaming Plus
      • CPU:
      • AMD Ryzen 7 2700
      • Memory:
      • 2x8GB Corsair Vengeance LPX)
      • Storage:
      • Force MP600 1TB PCIe SSD
      • Graphics card(s):
      • 560 Ti
      • PSU:
      • Corsair RM 650W
      • Case:
      • CM Silencio 550
      • Operating System:
      • W10 Pro
      • Monitor(s):
      • HP LP2475w + Dell 2001FP
      • Internet:
      • VM 350Mb

    Any Cisco CCNA engineer able to describe what "UDP error" is in CiscoWorks?

    Just in case there are any Cisco certified engineers here...

    I'm trying to help debug a network issue:

    Running a Cisco Catalyst 6509 with IOS software. After a lot of hassle, finally managed to get CiscoView 6 installed and running (as part of Ciscoworks) in order to try and fault find an issue we have where a networked system stops functioning.

    Looking at the status of the Supervisor engine (it's a Sup720 ), I get a shed load of UDP errors, just about as many errors as UDP packets sent over the network

    I've set up a span monitoring port on the cisco and have ethereal running on a host PC capturing all network traffic, but as you can imagine, there's a fair few million packets whizzing around the place and I don't know where to start

    However, if someone was able to technically explain what is meant by a "UDP error", i.e. what does a UDP packet need to have / not have for it to be considered erroneous

    That way, it might help me narrow down and find the cause of the issue.

    TIA


  2. #2
    Member
    Join Date
    Aug 2003
    Location
    edinburgh
    Posts
    99
    Thanks
    0
    Thanked
    0 times in 0 posts
    A UDP Error is the same as a TCP error ... It's caused by an incorrect or malformed UDP packet.

    I guess you know the difference between UDP and TCP so I'll spare the stuff, but since UDP doesnt ask for an aknowledgement, the destination machine will never know if the packets have been successfully sent/receieved.

    Does a server re-send an unsuccessful UDP packet? I don't know, but my guess is that it does.

    A typical UDP error would be an incorrect DNS address since DNS uses the UDP protocol which is the most commonly used application that still uses UDP as far as I'm aware.

    I really hope this helps!
    Acer Travelmate 8104WMLi
    P-M 2.0 Ghz
    2Gb DDR533 Corsair RAM
    100Gb 7200rpm Seagtae HD
    128Mb ATi x700 Mobility

  3. #3
    HEXUS.social member Agent's Avatar
    Join Date
    Jul 2003
    Location
    Internet
    Posts
    19,168
    Thanks
    735
    Thanked
    1,607 times in 1,045 posts
    Quote Originally Posted by St3v3
    ADoes a server re-send an unsuccessful UDP packet? I don't know, but my guess is that it does.
    How would the server know that it wasnt sucessful, as it doesnt require acknowledgement ?
    Quote Originally Posted by Saracen View Post
    And by trying to force me to like small pants, they've alienated me.

  4. #4
    Member
    Join Date
    Aug 2003
    Location
    edinburgh
    Posts
    99
    Thanks
    0
    Thanked
    0 times in 0 posts
    Thats a good point. But I think is a packets destination is unreachable or if the TTL expires the UDP packet is still sent back. Unless somebody knows otherwise?
    Acer Travelmate 8104WMLi
    P-M 2.0 Ghz
    2Gb DDR533 Corsair RAM
    100Gb 7200rpm Seagtae HD
    128Mb ATi x700 Mobility

  5. #5
    HEXUS.social member Agent's Avatar
    Join Date
    Jul 2003
    Location
    Internet
    Posts
    19,168
    Thanks
    735
    Thanked
    1,607 times in 1,045 posts
    I was under the impression that its just sent from the server, and thats it.
    If it gets to the intended target, the TTL expires, it gets corrupted, or it just fancys a quick stroll around the block, the machine that sent it would never know.

    Its probably best to wait for some of the guys that do networking for a living to confirm that though, its been a while since i read up on a few things
    Quote Originally Posted by Saracen View Post
    And by trying to force me to like small pants, they've alienated me.

  6. #6
    Ex-MSFT Paul Adams's Avatar
    Join Date
    Jul 2003
    Location
    %systemroot%
    Posts
    1,926
    Thanks
    29
    Thanked
    77 times in 59 posts
    • Paul Adams's system
      • Motherboard:
      • Asus Maximus VIII
      • CPU:
      • Intel Core i7-6700K
      • Memory:
      • 16GB
      • Storage:
      • 2x250GB SSD / 500GB SSD / 2TB HDD
      • Graphics card(s):
      • nVidia GeForce GTX1080
      • Operating System:
      • Windows 10 x64 Pro
      • Monitor(s):
      • Philips 40" 4K
      • Internet:
      • 500Mbps fiber
    UDP is pretty much "fire and forget" - the sender has no way of knowing whether the recipient actually got the packets, and the nature of the data usually means packets that arrive out of sequence or get delayed in transit can be ignored anyway.

    e.g.
    If you are listening to an audio stream and a chunk of data is not received, it wouldn't make sense to play the data when it finally did turn up - ending up sounding Yoda like, could one.
    If you are playing a game and have a bunch of packets dropped, so long as the percentage and frequency of drops is not too high it should not matter - and it definitely would not be any use to have the packets retransmitted.

    As to what Cisco consider a "UDP error" is anyone's guess - it could be a general transmission error on a particular port and the traffic type happens to be primarily UDP, or it could be a client jabbering on the network with garbage (hence the high percentage of "errors").
    The UDP headers could be corrupt, the frame too short or long, the destination IP or MAC could be 0.0.0.0, multicast or something that can't be routed.

    I know Cisco switches can complain about a huge number of errors if the speed and duplex settings are not matched on a port, even though the network actually appears to function just fine.

    I would log a few megs of network traffic in Ethereal, filtered on UDP specifically, and view it to see if it thinks the data is sound - it should just take a few minutes and Ethereal's overview is usually pretty good at highlighting genuine packet errors.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •