perfsonar-user - Re: [perfsonar-user] Testing network integrity
Subject: perfSONAR User Q&A and Other Discussion
List archive
- From: Mark Feit <>
- To: Patrick Grahvendy <>, "" <>
- Subject: Re: [perfsonar-user] Testing network integrity
- Date: Tue, 9 Apr 2024 20:44:01 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=internet2.edu; dmarc=pass action=none header.from=internet2.edu; dkim=pass header.d=internet2.edu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NGqeTgzKxHvPd32utacpm2O1pPhh9pj1I3XxLuMNLsk=; b=kkGcmPH9RGgwVyNZL97toXq0qQ3Ij6MYRj5YTf1tdRX3iA7DzoeH/vo5WSdCAqyEo7/SmwjYXKbPS0h5RfF+mw2dpYxejoC+GPJpyoHuNnswA/5ZQzgNhj6XxqySVY3p3ZcGx6S7NGQo+LBZsFz45Om/Qhhjc6hXHCvZYZSI294yPGSqBw/P29rqbiD555c1yfZG03QMi3d+tbTRq0pwEfvTHiGNZjXWJDAYvYJlSSzpb/AFJbBDRuDLZNim6/TJjqzXtuQOmJo286fAzEhle/K33dQTF6ZJ1YIhdtRfLw6WR5ATVi0AfY+xGFdXro5psAEZ71PC3QWIrymcUndJzg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aTm3gUaypDqOq+/3ChfdOwFq1bifzGHKM/A0YUkYKD2zMgWUwG+10Dm7UXl9hMv/Vj34/HAUZ3oIWb16yfVMJwh5MQ5z2HnntU49hmPZ5Bzy7lDyRSrVXPNqCrVYVmsDqzysWXuyfv/kKVFCk5kNjPiu+f7l3A3x+/axI0uZBrZkeU/5atviT+hkkgLwmUWleDCAQc41my7yz2pmXP2NnOgAGkX6gGP5Jmjv1qL3j7aR5Wd8+TMuTsADk8hOs5ISpcwSAFgpQnfQFYZ6/RjxYIMart0EGv58KMjQTA3V9b7wXYb3XVlNo6n29pGDZp0dOz4qmtOxHHlduQmU+ns0eQ==
Patrick Grahvendy writes:
… The issue I’m having is lost packet data intermittently causing this shutdown
Yes, absolutely. Identifying connectivity and performance problems is perfSONAR’s raison d’être. (And sorry for the late reply; I saw your note last week but was on travel.)
To replicate what it sounds like you’re doing now, a single perfSONAR toolkit node installed alongside your main control unit running round-trip time measurements (ping, essentially) to the IP of every device on your network would get the job done. It’s a bit ham-fisted in that if the link between the switch the perfSONAR node is plugged into and the rest of the network goes bad, everything else will show bad as well. You can get around that by using process-of-elimination to figure out where the fault lies and getting all of the faults out of the network will be a repetitive process. perfSONAR offers a tool called pSConfig that uses a single JSON file to do most of the grunt work of getting multiple repeating measurements configured and running. (It’s also handy if you have multiple perfSONAR nodes on your network because they can all be configured centrally, but that’s another discussion.)
All of this will need to be installed on a separate system; perfSONAR runs on Linux. Your application won’t require a lot of horsepower, so pretty much anything you’ve got around with 8-16 GB of RAM and four cores will work fine. If you’re stuck with Windows, the price of commercial products like PingPlotter and EMCO Ping Monitor would probably be money well spent compared to the costs of having your machinery be down. They may also be easier to configure; perfSONAR is something of an expert-level tool and, while it will work for this application, it may be overkill.
Also worth mentioning: You’ve caught us at a point where we’re about to put a new release into beta that will completely change the way data in the system is visualized. Installing the current release will work, of course, but you can expect major changes if the system is upgraded after the next release. This will be just visualization, all of the measurement functions will remain the same.
Hope that helps.
--Mark
|
- [perfsonar-user] Testing network integrity, Patrick Grahvendy, 04/05/2024
- Re: [perfsonar-user] Testing network integrity, Mark Feit, 04/09/2024
Archive powered by MHonArc 2.6.24.