So, I've never dealt with MPLS before, but there must be some set of points that can be polled (probably via SNMP) to show bandwidth utilization over time. There are a ton of apps that can do this, from MRTG to PRTG to Solar Winds and much more.
Set that up, correlate reports of slowness with it, make a report to management. Kurt On Wed, Jul 22, 2015 at 6:20 PM, J- P <[email protected]> wrote: > One of the reasons that they asked to test/monitor it is because remote > offices sometimes claim slow access , perhaps its when the links get > saturated? > > I would think that the carrier/provider would be aware & report their > findings to the client , after all it would be in the carriers best interest > to increase ($$$) the bandwidth. > > > > >> Date: Wed, 22 Jul 2015 15:43:58 -0700 >> Subject: Re: [NTSysADM] MPLS monitoring / testing >> From: [email protected] >> To: [email protected] >> >> Only if you expect all of the hub sites to saturate their links. >> >> Kurt >> >> On Wed, Jul 22, 2015 at 2:42 PM, J- P <[email protected]> wrote: >> > Looking at this again today, if the main location has 50mb, and the 9 >> > sites >> > combined total 93mb, >> > >> > shouldn't the main site's tunnel be equal to (93) or greater than the >> > sum of >> > the other site to get full throughput? >> > >> > >> > >> > >> > >> > >> > >> > ________________________________ >> > From: [email protected] >> > To: [email protected] >> > Subject: RE: [NTSysADM] MPLS monitoring / testing >> > Date: Wed, 22 Jul 2015 00:25:58 -0400 >> > >> > >> > wow, >> > >> > here;s the breakdown all in megs (site numbers then bandwidth i.e site >> > 1. >> > has a 50 meg) >> > >> > 1. HQ 50 >> > >> > 2. 9 >> > >> > 3. 10 >> > >> > 4. 30 >> > >> > 5. 10 >> > >> > 6. 10 >> > >> > 7. 10 >> > >> > 8. 4 >> > >> > 9. 10 >> > >> > >> > >> > >> > Jean-Paul Natola >> > >> > >> > >> >> From: [email protected] >> >> To: [email protected] >> >> Subject: RE: [NTSysADM] MPLS monitoring / testing >> >> Date: Wed, 22 Jul 2015 04:00:26 +0000 >> >> >> >> Confirm your routing to ensure the proper path is taken. >> >> >> >> MTR and PsPing have been tools I've used in the past to measure latency >> >> and conduct bandwidth tests. Use nping for more advanced features. >> >> >> >> Consider that the time, specific day and ISP provider hops between your >> >> networks will affect traffic flows. You can also call the provider to >> >> speak >> >> with a technician who can conduct tests between their gear. >> >> >> >> What is the bandwidth of the MPLS link that has been purchased? >> >> >> >> Hope this helps. >> >> >> >> -----Original Message----- >> >> From: [email protected] >> >> [mailto:[email protected]] On Behalf Of Kurt Buff >> >> Sent: Tuesday, July 21, 2015 10:46 PM >> >> To: ntsysadm >> >> Subject: Re: [NTSysADM] MPLS monitoring / testing >> >> >> >> For bandwidth validation, one very good tool is iperf/jperf. I believe >> >> it's hosted by Google, but I haven't used it in a while. >> >> >> >> There is a Windows port of it. >> >> >> >> Ah, this is the mothership, but no Windows port. >> >> https://code.google.com/p/iperf/ >> >> >> >> For a Windows port, try here: >> >> https://iperf.fr/ >> >> >> >> Kurt > >> >> >> >> On Tue, Jul 21, 2015 at 5:33 PM, J- P <[email protected]> wrote: >> >> > Hi all, >> >> > >> >> > Went to new site and one the tasks was to monitor the MPLS VPN >> >> > tunnels , truth be told I always thought this was done by the >> >> > carrier, >> >> > , furthermore I have never EVER been on a site that used MPLS, >> >> > >> >> > It seems what they are primarily asking is "are we getting the >> >> > throughput we are paying for" >> >> > >> >> > >> >> > So , does anyone know of any tools or tests that can be used for >> >> > this, >> >> > what it seems they are? >> >> > >> >> > OH, and just to clarify, the reason I accepted the project in the >> >> > first place was because initially it was to be an internal LAN >> >> > assessment, the MPLS stuff was added afterwards. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> IMPORTANT NOTICE: Without the use of secure encryption, the Internet is >> >> not a secure medium and privacy cannot be ensured. Internet e-mail is >> >> vulnerable to interception, misuse and forging. Equitable cannot ensure >> >> the >> >> privacy and authenticity of any information sent by way of the public >> >> Internet. Equitable will not be responsible for any damages you may >> >> incur if >> >> you communicate confidential and personal information to us over the >> >> Internet or if we communicate such information to you at your request. >> >> This >> >> e-mail and any attachments are confidential, may be covered by legal >> >> professional privilege or exempt from disclosure under applicable law, >> >> and >> >> are intended for the addressee only. If you are not the intended >> >> recipient, >> >> you are not authorized to and must not disclose, copy, distribute or >> >> retain >> >> any or part of this e-mail and any attachments without written >> >> permission of >> >> The Equitable Life Insurance Company of Canada. >> >>
