Network Monitoring....

vColevCole Member Posts: 1,574 ■■■■■■■□□□
We're having issues here lately with our network. It's mostly from the second half of it.

(we have two more switches half way across the building) & the network keeps hiccuping.

What should I look for & test?


Thanks
-Fade icon_thumright.gif

Comments

  • hypnotoadhypnotoad Banned Posts: 915
    Are they managed switches? If so, you should be able to log in and set up a syslog to see what it's doing (or view the log if it exists).
  • vColevCole Member Posts: 1,574 ■■■■■■■□□□
    hypnotoad wrote: »
    Are they managed switches? If so, you should be able to log in and set up a syslog to see what it's doing (or view the log if it exists).


    I believe they're unmanaged but I will check. Thanks :)

    edit: they are unmanaged
  • cisco_troopercisco_trooper Too many Member Posts: 1,443 ■■■■□□□□□□
    Jeeze. Why do people insist on unmanaged switches.....I feel for you.
  • seuss_ssuesseuss_ssues Member Posts: 629
    Jeeze. Why do people insist on unmanaged switches.....I feel for you.

    Either they purchase them because they are cheaper or his switch may be manageable but the option is not turned on.
  • vColevCole Member Posts: 1,574 ■■■■■■■□□□
    Either they purchase them because they are cheaper or his switch may be manageable but the option is not turned on.

    I believe they purchased them because they were cheaper. icon_sad.gif

    Anywho...

    I'm running a continually ping from one of the machines on the second rack to one of the IPs on rack 1. Also, running a continual ping from one machine to another one on the same switch.

    Hoping this will narrow it down if it's the fiber or the switch. icon_thumright.gif
  • vColevCole Member Posts: 1,574 ■■■■■■■□□□
    So the machine that is pinging rack 1 (that is on rack 2)

    Constantly gets:
    Reply from 192.168.20.8: bytes=32 time<10ms TTL=128

    but occasionally this:

    Reply from 192.168.20.8: bytes=32 time=1ms TTL=128

    anything to worry about?
  • mattrgeemattrgee Member Posts: 201
    Its unlikely to be anything to worry about.

    Have you tried running a packet trace to see what type of traffic is using the network? As others have said though you really need the switches to be of the manage type to get any useful information.
  • SlowhandSlowhand MCSE: Cloud Platform and Infrastructure, MCSA: Windows Server 2003/2012/2016, CCNA Routing & Switchi Bay Area, CaliforniaMod Posts: 5,163 Mod
    This might be a good time to start playing with Wireshark in order to not only figure out what could be giving you issues, but also learn about a shiny geek-toy. . . err. . . "useful networking tool". icon_lol.gif

    Free Microsoft Training: Microsoft Learn
    Free PowerShell Resources: Top PowerShell Blogs
    Free DevOps/Azure Resources: Visual Studio Dev Essentials

    Let it never be said that I didn't do the very least I could do.
  • vColevCole Member Posts: 1,574 ■■■■■■■□□□
    I downloaded it, but I'm unsure of what to look for that could be bad. icon_sad.gif
  • SlowhandSlowhand MCSE: Cloud Platform and Infrastructure, MCSA: Windows Server 2003/2012/2016, CCNA Routing & Switchi Bay Area, CaliforniaMod Posts: 5,163 Mod
    I've got a little bit of experience with Wireshark, but I've used it mainly for simple things like looking for specific traffic-patterns. My approach would be to do a few scans, then look for things like recurring errors or dropped packets. After that, start looking at the kind of traffic you're getting and look for packets that might be flooding your network. Once you know what's putting the biggest load on your wire, then start going through servers and other machines to figure out where the culprits are.

    Keep in mind, this might be a process that'll take weeks, even months, as you're learning and tweaking the network. Regardless, it'll be a great learning-experience and I'm sure you'll find all kinds of little quirks on your network you never knew were there.

    Free Microsoft Training: Microsoft Learn
    Free PowerShell Resources: Top PowerShell Blogs
    Free DevOps/Azure Resources: Visual Studio Dev Essentials

    Let it never be said that I didn't do the very least I could do.
  • arwesarwes Member Posts: 633 ■■■□□□□□□□
    We use The Dude for the most part. It helped me track down something that was packet flooding the network a while back (a D-Link print server of all things).
    [size=-2]Started WGU - BS IT:NDM on 1/1/13, finished 12/31/14
    Working on: Waiting on the mailman to bring me a diploma
    What's left: Graduation![/size]
  • malcyboodmalcybood Member Posts: 900 ■■■□□□□□□□
    What is the switch make/model and does the fiber connect into a GBIC connector?
    What exactly is the problem here when you say hicupping?
    Is it a particular application that is having issues?
    How many users are affected?
    How do you know it's the network that is the issue?
    Has this only just started recently or always been like this?

    Some points to note;

    - The switch not being managed can mean different things depending on who is asking the question. ISP's want everything to be managed by them, but if a local IT dept sets a switch up sometimes they don't setup mgmt addressing etc but that's easily solved.

    -Good response time from a ping doesn't always mean everything is OK saying that a 10ms response time over a campus LAN is OK although I would expect it to consistently be 1ms on the network that I work on. We have plenty of capacity etc though. You can get a "good" response time whilst the link is being choked or has errors on it.

    - People blame the network all the time, when it's not actually the root cause of the issue

    - If fiber gets dirts performance can be degraded. Clean the fiber with a fiber cleaning kit (if you don't have one wipe the end to ensure no dust or dirt on the end of the fiber)

    - You may need to test the fiber end to end as it may have breaks anywhere in the line

    If the switch is not managed as in not even configurable (although I doubt this if it has a fiber connectivity) then Wireshark is no use to you. If you can login to the switch via console, connect your laptop in by RJ45 and setup a port mirror the fiber GBIC port to the port your laptop is plugged into then Wireshark can help you out. Tell us the switch make/model as requested above and we can help you with port mirroring if the switch is capable.

    If you see lots of black packets coloured packets these are usually dropped TCP syn/acks in Wireshark or retransmissions when you use the default schema. If you see these then check the source / destination ip addresses to identify which devices they are on the network.

    Also if you can get logged into the switch and check under each interface for "FCS errors". These are usually caused by the port being "nailed up" to 100mbps full duplex as opposed to auto negotiate. The pcs try to autonegotiate but the switch doesn't let them as they're fixed. This causes slow network performance on the LAN!

    If you just plug a laptop into an unmanaged switch or a switch that doesn't have the port mirrored all you're doing is looking at the traffic from your own PC. In this scenario you want to find out if the trunk port is the issue or not by using port mirroring.

    Malc
Sign In or Register to comment.