do folk use `netstat -s` to help diagnose on routers/switches? randy
On Thu, Jul 18, 2019 at 11:43 AM Chris Cariffe <ccariffe@gmail.com> wrote:
[netstat] -rn and -an fan here!
Rarely use them. "ip route show" and "lsof +c 15 -nP | grep TCP" are normally more useful. -- William Herrin bill@herrin.us https://bill.herrin.us/
I know I have a few times after seeing SNMP bumps of errors but mainly just so I could get up to the moment error rates or stats. Other than that though it’s a very minor usage IMO -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Jul 17, 2019, at 19:55, Randy Bush <randy@psg.com> wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
randy
Ideally folks should be subshells (unless you're on a strange system or legacy system). netstat is now mostly obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr. https://www.linux.com/learn/intro-to-linux/2017/7/introduction-ss-command r/s, Steven M. Miano (727)244-9990 http://stevenmiano.com 1811 C2CB 8219 4F52 On 7/17/19 20:54, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
randy
Ideally folks should be subshells (unless you're on a strange system or legacy system).
netstat is now mostly obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.
on some vendors. but could you answer my question? do you use it?
Why do you want to know? On Thu, Jul 18, 2019, 5:55 PM Randy Bush <randy@psg.com> wrote:
Ideally folks should be subshells (unless you're on a strange system or legacy system).
netstat is now mostly obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.
on some vendors. but could you answer my question? do you use it?
Ideally folks should be subshells (unless you're on a strange system or legacy system).
I have never thought of myself as subshell, even on a low carbohydrate system
netstat is now mostly obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.
Microsoft (Windows, that is) and Apple macOS have no knowledge of ss. That is why I use netstat often, but never netstat -s to diagnose routing. (Hi, Randy.) James R. Cutler James.cutler@consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net
On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
Sometimes - it depends on the problems and visibility/lack thereof provided by other methods. In the netstat family of flags, what I *really* miss is DEC's 'netstat -z', especially when having "application vs network" arguments for poorly instrucmented applications. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
I (mostly) use it on firewalls, but yes, it's something I turn to fairly often (along with other incantations of netstat, plus lsof and other tools). ---rsk
Personaly I think that circumstance weighs the benifits of the utilities used to diagnose a problem. Given any instance, you use the utilities available to you to see that problem through to completion of a proper result. The question in hand is very broad but particular to an instance that is trying to be solved. 1. Dev is trying to weight whether its worth while to consider diagnosing a problem that considers the use of netstat with an option that in its legacy use was quite considerable debug output. 2. Regardless of the system the old method is still supported but is the output still supported and enough to gain evidential knowledge of the current facts. 3. Will the rseult gathhered by this and the effort be well worth considering the target be gainful toward the final intended result. With that said, Randy I personally think that you already have the annswer that you were looking for given the minimal input ... maybe 3-4 actual interactions of the utility but given that, I think I would sum it up as people don't know the actual usefulness of netstat(1) these days and why it was originaly put out there and what they could gain by instances where they may be required to use it to set themselves on a path to correct the pronlem they are currently facing. On Fri, Jul 19, 2019 at 08:31:38AM -0400, Rich Kulawiec wrote:
On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
I (mostly) use it on firewalls, but yes, it's something I turn to fairly often (along with other incantations of netstat, plus lsof and other tools).
---rsk
-- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Jul 17, 2019, at 20:54, Randy Bush <randy@psg.com> wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
I have used netstat -s on hosts to look at error counters if a switch or router was suspect. But that was a while ago (anyone remember when NFS corrupted all your files if one of your routers or the NIC had a bit error outside the protection provided by the Ethernet CRC?). Today, I have the problem that netstat -s doesn’t seem to work right on macOS. Many counter values are nonsensical, or simply zero. I was guessing this was due to NIC offload, but I haven’t analyzed further. If anyone knows more about recent macOS netstat -s, I’d love to hear more details. (Oh, and if there are recent (< 2 years old) statistics of ECT penetration in real networks, I’d love to know, too.) Grüße, Carsten
:On Jul 17, 2019, at 20:54, Randy Bush <randy@psg.com> wrote: :> :> do folk use `netstat -s` to help diagnose on routers/switches? Yes, for sufficienly Unix-y routers/switches. :I have used netstat -s on hosts to look at error counters if a switch or router was suspect. :But that was a while ago (anyone remember when NFS corrupted all your files if one of your routers or the NIC had a bit error outside the protection provided by the Ethernet CRC?). : :Today, I have the problem that netstat -s doesn’t seem to work right on macOS. :Many counter values are nonsensical, or simply zero. :I was guessing this was due to NIC offload, but I haven’t analyzed further. :If anyone knows more about recent macOS netstat -s, I’d love to hear more details. "sudo netstat -s" is your friend. -Mike -- Michael J. O'Connor mjo@dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Puny god." -Hulk
On Thu, Jul 18, 2019, at 02:55, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
randy
Before today, I've never heard on anyone using it on routers/switches. Only on servers. `netstat -s` not very often. `netstat` (all options included) - less ans less often (due to updated tools and data collection methods). Personally, I still consider it a tools to know about.
On 7/17/19 17:54, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
I suspect there's an unstated question here of should metrics reported by netstat -s which includes metrics from the kernel should include metrics derived from from the asic counters. I do / have occasionally used netstat or the values exposed to it from the kernel which are generally also exposed via other metrics methods. I would find it a little odd for ip counters in netstat for example to include packets that do not hit the kernel control plane, though I could imagine someone wanting that.
randy
On Jul 20, 2019, at 6:14 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 7/17/19 17:54, Randy Bush wrote:
do folk use `netstat -s` to help diagnose on routers/switches?
I suspect there's an unstated question here of should metrics reported by netstat -s which includes metrics from the kernel should include metrics derived from from the asic counters.
I do / have occasionally used netstat or the values exposed to it from the kernel which are generally also exposed via other metrics methods.
I would find it a little odd for ip counters in netstat for example to include packets that do not hit the kernel control plane, though I could imagine someone wanting that.
Yeah, I avoided jumping in until now, I think the key thing is (and why some people like GUI routers/devices eg: UBNT has a decent http(s) U/I) is a device can have a lot of interfaces and traffic both in the control and data plane that don’t hit a common set of counters/interfaces. When I look at UBNT devices, I can get a sense quickly of traffic rates and information to understand how my network is working. When on a device with 60 or 160 interfaces, it’s much trickier. If I’m on a 16 or 32 port device, a terminal window can tell me decent info, after that I need a summarization system, and this is where streaming telemetry stuff can come into play. That is the aggregation layer for the information vs netstat -s, monitor interface, show | match rate, show | include bits or whatever other commands/data you want/need. XR/JunOS have curses interface monitoring commands that work well, but in most of my cases I really would prefer to have software watch vs a human. “monitor interface” on a Juniper for example doesn’t have separators or human readable elements. I don’t measure my interfaces in bits per seconds these days but in gigs as my base unit and it doesn’t give me common visuals or right justified numbers to delineate if i bumped out an order of magnitude. When I’ve used netstat -s or netstat -i the units often don’t make sense. Similar to other commands like vmstat or similar, what used to be a big number in context switches may not be relevant with 8 cpus each with 8 cores. - Jared
participants (15)
-
Brett Watson -
Carsten Bormann -
Chris Cariffe -
J. Hellenthal -
James R Cutler -
Jared Mauch -
Joe Provo -
Joel Jaeggli -
Mike O'Connor -
Radu-Adrian Feurdean -
Randy Bush -
Rich Kulawiec -
Ross Tajvar -
Steven M. Miano -
William Herrin