@@plaintextpackets I definitely felt as though the test was pretty gatekeepery. And I walked out with cert in hand wondering why they didn't teach us anything about voip.
I've been a cable guy for almost 20 years, and wish every customer had something running in their home to monitor their connection and keep detailed logs for guys like me to find a smoking 🔫 when I go to a trouble call for slow or intermittent internet. There are so many variables that even with all the tools the ISP gives us (actual tools and internal diagnostic sites) it's usually difficult to be sure the problem is fixed. Repeat truck rolls negatively affect our metrics, so anything to reduce those is a win for us AND the customer.
I totally get it. I’ve worked as a network analyst for a small company with a bunch of branch sites and had the same challenge. Now I work at the enterprise level but it’s the same problem just at a bigger scale.
Great video. Question: lets say that the src is a storage solution, of type PowerScale (so distributed file system accross multiple nodes etc..). Traffic is SMB. You isolate switches, routers, long network routes, to have both the clients + storage on the same subnet. Even removed the switch and tested with a direct 10Gb fiber client to 1 node of the storage connection. But you STILL see packet loss and retransmission. Can you 100% JUST the network? NIC on src or/and dst, or can it be see on the wire as retransmissions because the storage is not able to recompile the data requested fast nought in some fasion? Though, looking on the storage, we do NOT see any filesystem delays. The cluster is performing at 10% load. Thank you !
It could be buffers at the OS level. The packets are received by the receiving NIC, which passes them to the receive buffer at the OS layer, then to the applications. If the apps are slow at processing the data those buffers fill up. Could also be the app just slow to ACK packets and therefore they get retransmitted
Yeah. We looked at optimization on the client NIC side with various buffering options and settings. Things looked a bit better but we still see retrans on the wire. Single wire too ! So it can not be between point to point. The fiber cables were also swapped and the spf checked. But we are having to prove that the issue is not on the storage end. As we do not see issues with our NIC, non issues either with our OS restripping algorithm. Is there a way to see what is happening at the NIC level? Zoom in onto the device itself?
@itsdouetthierry it would depend on the device. I would ask chatgpt or Claude for steps to check all buffers for your given platform and follow through on commands
Thank you for the very informative video. I have used the technique you have discribed to analyze some packet captures i took using Cisco EPC. I have an extensive amount of packet loss from a client workstation to a server across an MPLS network. the packet loss is usually between 1.7 and 3.4%. We have compaints from our users connecting to that server that they drop their connection several times a day, which is why i started capturing the data. The main issue i am having is only seeing traffic in a unidirectional fashion. I always see the client workstation on the left and the server host on the right. i have manipulated the words on the EPC filter on the cisco switch from in , out, and both.. but it does not change anyting. Would you be able to comment 0n why i only see 1 way traffic in the trace file? Thank you!
Hi, thanks for the video. What if I want to know my packet loss for UDP protocol ? Is it possible to know many were lost/dropped during the transmission ?
It depends on the UDP protocol. Some protocols like RTP have sequence numbers shown in plaintext. So even though there aren’t retransmissions of packets you can find gaps in the numbers. Another method is for UDP streams that should have a constant bitrate (like a webcam stream). You can graph the I/o rate in wireshark to look for dips in the bitrate
SIP itself could be TCP or UDP, but then the audio stream will use a UDP protocol like RTP. This video focuses on TCP but there are other methods for spotting packet loss in UDP streams
12:01 1418 is the total packets sent between the client and server. The 1400 was just that number rounded down so it would be easier to get a rough estimate of the % packet loss. 113/1418 would still give about 8% (0.079)
So i have an packet loss in a game called valorant up to 45% looking at it with the game stats its mostly incoming up to 95% and outgoing up to 5% my internet company and the val support cant find what causing this
Are you on wifi or connected to your router via ethernet cable? If on wifi I would first test with an ethernet cable and see if it gets better (home wifi is notoriously bad). If it's still bad I would take a wide-open capture (ua-cam.com/video/wI2qfO61iFw/v-deo.html) and then look for packet loss. Feel free to join the discord to continue troubleshooting: discord.gg/4XE5jSGb
@@plaintextpackets Hello! That would be fantastic. Basically, I'm curious if there are rouge DHCP servers or LAN issues that can be fixed to provide better overall network performace and reliabilty. How long of a capture would you like? 1 min, 5 mins, ? I can upload the file to Google Drive.
Great video, thank you! Was looking for the next one for troubleshooting steps, hope its coming soon
don't know if it's sad or just telling that I learn more watching your videos that I did while preparing for CCNA and even well into the CCNP
That's more a comment on how bad Cisco certs and training have become lol, but thank you!
@@plaintextpackets I definitely felt as though the test was pretty gatekeepery. And I walked out with cert in hand wondering why they didn't teach us anything about voip.
@mtnsolutions that’s exactly it. It’s just obscurely difficult to make it hard but doesn’t really help you understand network better
I've been a cable guy for almost 20 years, and wish every customer had something running in their home to monitor their connection and keep detailed logs for guys like me to find a smoking 🔫 when I go to a trouble call for slow or intermittent internet. There are so many variables that even with all the tools the ISP gives us (actual tools and internal diagnostic sites) it's usually difficult to be sure the problem is fixed.
Repeat truck rolls negatively affect our metrics, so anything to reduce those is a win for us AND the customer.
I totally get it. I’ve worked as a network analyst for a small company with a bunch of branch sites and had the same challenge. Now I work at the enterprise level but it’s the same problem just at a bigger scale.
Good video. It is very useful to understand how to check the packet loss. good work keep it up !!!!
👏👏👏🙏
This is an AMAZING video - thank you!
You’re welcome!
Great video. Question: lets say that the src is a storage solution, of type PowerScale (so distributed file system accross multiple nodes etc..). Traffic is SMB. You isolate switches, routers, long network routes, to have both the clients + storage on the same subnet. Even removed the switch and tested with a direct 10Gb fiber client to 1 node of the storage connection. But you STILL see packet loss and retransmission.
Can you 100% JUST the network? NIC on src or/and dst, or can it be see on the wire as retransmissions because the storage is not able to recompile the data requested fast nought in some fasion? Though, looking on the storage, we do NOT see any filesystem delays. The cluster is performing at 10% load.
Thank you !
It could be buffers at the OS level. The packets are received by the receiving NIC, which passes them to the receive buffer at the OS layer, then to the applications. If the apps are slow at processing the data those buffers fill up. Could also be the app just slow to ACK packets and therefore they get retransmitted
Yeah. We looked at optimization on the client NIC side with various buffering options and settings. Things looked a bit better but we still see retrans on the wire. Single wire too ! So it can not be between point to point. The fiber cables were also swapped and the spf checked. But we are having to prove that the issue is not on the storage end. As we do not see issues with our NIC, non issues either with our OS restripping algorithm.
Is there a way to see what is happening at the NIC level? Zoom in onto the device itself?
@itsdouetthierry it would depend on the device. I would ask chatgpt or Claude for steps to check all buffers for your given platform and follow through on commands
Thank you for the very informative video. I have used the technique you have discribed to analyze some packet captures i took using Cisco EPC. I have an extensive amount of packet loss from a client workstation to a server across an MPLS network. the packet loss is usually between 1.7 and 3.4%. We have compaints from our users connecting to that server that they drop their connection several times a day, which is why i started capturing the data.
The main issue i am having is only seeing traffic in a unidirectional fashion. I always see the client workstation on the left and the server host on the right. i have manipulated the words on the EPC filter on the cisco switch from in , out, and both.. but it does not change anyting. Would you be able to comment 0n why i only see 1 way traffic in the trace file? Thank you!
If you can join the discord we can start a tread and share notes, would be happy to help
Another awesome video. Thank you !!
Glad you enjoyed it!
Hi, thanks for the video.
What if I want to know my packet loss for UDP protocol ?
Is it possible to know many were lost/dropped during the transmission ?
It depends on the UDP protocol. Some protocols like RTP have sequence numbers shown in plaintext. So even though there aren’t retransmissions of packets you can find gaps in the numbers. Another method is for UDP streams that should have a constant bitrate (like a webcam stream). You can graph the I/o rate in wireshark to look for dips in the bitrate
Hello, if this was a SIP call, what layer should I be looking? TCP or UDP? Thank you!
SIP itself could be TCP or UDP, but then the audio stream will use a UDP protocol like RTP. This video focuses on TCP but there are other methods for spotting packet loss in UDP streams
Just posted a video on this!
Thank you! Checking now
@@plaintextpackets
why divide the drop packets with 1400 ? is it the maximum segment size ?
What timestamp are you seeing 1400?
@@plaintextpackets ok got it.
12:01 1418 is the total packets sent between the client and server. The 1400 was just that number rounded down so it would be easier to get a rough estimate of the % packet loss.
113/1418 would still give about 8% (0.079)
So i have an packet loss in a game called valorant up to 45% looking at it with the game stats its mostly incoming up to 95% and outgoing up to 5% my internet company and the val support cant find what causing this
Are you on wifi or connected to your router via ethernet cable? If on wifi I would first test with an ethernet cable and see if it gets better (home wifi is notoriously bad). If it's still bad I would take a wide-open capture (ua-cam.com/video/wI2qfO61iFw/v-deo.html) and then look for packet loss.
Feel free to join the discord to continue troubleshooting: discord.gg/4XE5jSGb
HI, Can I hire you to take a look at my capture to troubleshoot LAN issues?
I wouldn’t mind looking at it pro bono, is it posted somewhere?
@@plaintextpackets Hello! That would be fantastic. Basically, I'm curious if there are rouge DHCP servers or LAN issues that can be fixed to provide better overall network performace and reliabilty. How long of a capture would you like? 1 min, 5 mins, ? I can upload the file to Google Drive.
5 mins would be good to start, you can email the link to plaintextpackets@gmail.com
@foxtrot1967 I just setup Dropbox as well if you'd like to submit that way
That's helpful, thanks a lot!
thank you
Exellent😊
At times, some of your conversation fades away. Some words sound like a murmur.
Lol, where? He's very clear IMO
Sorry you had that experience! I’ve only had time to record videos in batches using my work headset! Maybe someday I’ll invest in a better mic :-)