New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
In any case whoever is assigning this dictionary words as subdomains of enarmorednation.com might want to sanitize their wordlist.
Their NOC Technician will only ask me for my MTR records and I want to know how to analyze this issue through MTR records.I'm more interested in this and I won't give him the MTR record until he tells me.
MTR can/will show when something is wrong.. When everything is good, it shows very little..
MTR is an advanced traceroute, can show packetloss along the way.
If there is packet loss, those packets need to be resent, pushing your usage up.
A better way to explain this.. If you are using a mobile phone data in a poor signal area, you don't get all the packets because of poor signal, they need to be resent, except you are billed by the data that is sent to your phone, not by the amount of data your phone received.
I got it.Because the server bandwidth is sufficient, there is no serious packet loss at present, but it is constantly consuming traffic, so even if I am asked to provide MTR, the result will not be any different from the usual test results.
But i want to know how to analyze the broadcast storm through MTR records.He said he cannot analysis for the root cause of the problem without my MTR.
>
He can't analyze it with a MTR. He can stick it into his ass. Really.
He can just spin up a VM and or machine in the same VLAN/and or Same node even and find easily using traffic analyzers in Linux to find if that is just normal ARP traffic of a big shared vlan or if there are any problems in his network and where it comes from.
There also things they are called "sFlow/netFlow analyzers". He might have one in His Network. So.
They can help indicate better.
I dont want to call this a storm. We dont Know. But there are Things Like Storm Control, RSTP and bpdu guard etc etc to minimize such Risks.
There are other tools. Not your job to Provide him with a MTR. Makes less Sense.
Shared VLAN issue.
I also think that my MTR will not be of much help to him in solving this problem. After some operations, they decided that there was nothing wrong with their settings, and they didn't count my downstream traffic, so they didn't plan to deal with it anymore.
several MB/s of broadcast storm is not unusual, although 3MB/s is high, that'd be a misconfiguration or a huge improper designed layer 2 network. without counting you don't necessarily need to care but it's not pretty, at all.
Nah support used the wrong help desk script here. The proper reply here was 'we will look into it and come back to you'. For self educational purposes look into ARP and Layer 2
Here's the thing about MTR records – they can be helpful for diagnosing internet slowdowns or connection issues, but they might not be the best tool for figuring out where 100GB of data went. MTR records typically track data packets and ping times, which are more useful for identifying problems with the connection itself, not necessarily how much data is being used.
To check for broadcast traffic, try the next command: tcpdump -i INTERFACE -nn not arp and dst not YOUR_IP and src not YOUR_IP