Re: RTG

[Seth Mattinen]

On 10/30/19 10:10 PM, Seth Mattinen wrote:

On 10/30/19 6:13 AM, John Von Essen wrote:
I too love RTG, been using it forever, appears to handle interfaces 
all the way up 10G.





I still use RTG. Not for graphing or anything fancy, just for polling 
counters in a database to be queried by other things. It's still useful 
for raw numbers for billing.



Slight correction, I'm using rtg2:
https://code.google.com/archive/p/rtg2/downloads

Re: Best components for a full mvno core network?

[Andrew Paolucci via NANOG]

From my experience Project Clearwater is the most matured IMS Core solution.
http://www.projectclearwater.org/

Also has a commercial offering.
https://www.metaswitch.com/products/core-network/clearwater-ims-core

Good Luck!
Regards,
Andrew Paolucci

‐‐‐ Original Message ‐‐‐
On Tuesday, October 15, 2019 10:19 AM, Dario Renaud  
wrote:

> Hello,
>
> At my day job, we are considering going Full MVNO. Which means building a 
> mobile core network.
>
> I was wondering if some of you would have feedback or advices on the 
> solutions currently available?
>
> We would like to avoid the big providers (Ericsson & such).
> Ideally, something opensource, or, if proprietary, a company maybe willing to 
> license access to the code (one can dream).
>
> There seems to be a lot of bits and pieces available out there, with a mix of 
> full, fullish or partial solutions. This makes for quite the puzzle.
>
> Among the ones I found most interesting:
>
> nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc). It 
> looks like the more active open EPC implementation out there.
>
> And it seems that Yate people have a commercial product covering basically 
> everything needed 
> (https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/).
>
> What do you think?
>
> Regards
>
> Dario Renaud

Re: RTG

[Seth Mattinen]

On 10/30/19 6:13 AM, John Von Essen wrote:
I too love RTG, been using it forever, appears to handle interfaces all 
the way up 10G.





I still use RTG. Not for graphing or anything fancy, just for polling 
counters in a database to be queried by other things. It's still useful 
for raw numbers for billing.

Re: SFP oraganizers / storage recommendations

[Glen Turner]

Hi Matthew

There's a typical 10*SFP tray and less common 20* tray. Flexoptix,
Fiberstore and others retail these (as well as use them to protect
their transceivers in transit) or AliBaba gives lots of hits.  Use a
tray per transceiver part number and keep them vertical in an
appropriately-sized box. If you have a lot of transceivers then use
distinct boxes for SMF/MMF, 1G/10G/40G/100G, etc.  If you're careful in
your tray choice then the trays will also hold 4*XFP, 4*QSFP, etc.
Using a small post-it note *on the inside* of the transparent cover is
a convenient way to label the tray with the part number of the SFPs
inside.

Best wishes, glen

Re: Best components for a full mvno core network?

[Dovid Bender]

This was discussed in detail at commcon. Have a look at
https://www.youtube.com/watch?v=4HdGuCFQYMs=PLvNS4EBAxmJKz6E6PLCqBq0eB-KKB6HR0=21=0s



On Mon, Oct 21, 2019 at 12:51 PM Dario Renaud 
wrote:

> Hello Javier,
>
> Well, if we take a step back to goals, I would like first to point that
> going Full MVNO might not be the best solution for us (roaming alone seems
> like quite a hassle, not to mention handsets management).
>
> My focus here is narrower, as I am mostly trying here to assert what the
> possibilities for the core are, and if there are reasonable alternatives to
> the fully integrated solutions of the big providers.
>
> That being said, I am not sure how our specific goals here would impact
> much the architecture: aren’t there a lot of constraints due to the 3GPP
> requirements?  It seems to leave little room for creativity.
>
> To provide a bit of context and answer you:
>
> We are historically providing solutions on fixed networks, with a strong
> bend toward business end-users. We are also used to have a lot of control
> over our architecture, most of our services running over open-source and/or
> in-house solutions.
>
> Being able to provide our services on mobile accesses is now a necessity.
> For this we already are light MVNO, using two different MNOs. Thanks to
> forced routing, it mostly does the job regarding voice. Data could be
> managed also. SMS is proving trickier.
>
> But each MNO have their own products set: building offers that would work
> on both is tedious and necessitate compromises that tend to make our
> marketing people unhappy. Not to talk about supporting two provisioning
> chains, two SIMs supply chains, etc… These problems would only get worse if
> we add other MNOs to the mix.
>
> We are also stuck with the roadmap of the MNOs (VoLTE and VoWifi are but
> distant “maybe later” possibilities).
>
> So, in one word, this is about autonomy. And its cost.
>
> Regards,
>
> Dario Renaud
>
> Le ven. 18 oct. 2019 à 17:44, Javier J  a
> écrit :
>
>> This is interesting but so many variables to unpack to determin what the
>> right solution is. What are the main goals of your org? What exact pain
>> points are you trying to fix?
>>
>>
>>
>> On Wed, Oct 16, 2019, 8:28 AM Dario Renaud 
>> wrote:
>>
>>> Hello,
>>>
>>> At my day job, we are considering going Full MVNO. Which means building
>>> a mobile core network.
>>>
>>> I was wondering if some of you would have feedback or advices on the
>>> solutions currently available?
>>>
>>> We would like to avoid the big providers (Ericsson & such).
>>> Ideally, something opensource, or, if proprietary, a company maybe
>>> willing to license access to the code (one can dream).
>>>
>>> There seems to be a lot of bits and pieces available out there, with a
>>> mix of full, fullish or partial solutions. This makes for quite the puzzle.
>>>
>>> Among the ones I found most interesting:
>>>
>>> nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc).
>>> It looks like the more active open EPC implementation out there.
>>>
>>> And it seems that Yate people have a commercial product covering
>>> basically everything needed (
>>> https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/).
>>>
>>>
>>> What do you think?
>>>
>>> Regards
>>>
>>> Dario Renaud
>>>
>>

Looking for input -- OSS tooling

[Leslie Daigle]

I know that a number of people on this list use, and/or contribute to, 
open source software tools (e.g., *RTG).  As I outlined in my lightning 
talk at the NANOG meeting last June,  I’m collecting information about 
what operators find useful/off-putting in the use, contribution to, and 
support of open source software tools.


My plan, and why I hope this project will be interesting to you, is to 
share the results of the data collection publicly so that supporters of 
OSS projects will be able to better tune them to what works for you.  
People who fund open source are asking for answers, so your thoughts 
would be appreciated!


If you have 8 - 10 minutes to spare and would be willing to contribute 
your thoughts, you can get to the questionnaires here:


https://possie.techark.org/operators-and-open-source-software-survey/

Thing 1 — “Questionnaires” because there’s one for individual 
contributors, and one for decision makers.  You’re welcome to fill out 
both, if applicable.


Thing 2 — the questionnaire does not require you to provide your name 
or contact info — that’s optional, if you’d like to do some follow 
up.


Thanks for considering contributing your thoughts!

Leslie.

--

---
Leslie Daigle
Principal, ThinkingCat Enterprises
ldai...@thinkingcat.com
---

Google/GMail contact

[Eric Dugas]

Looking for a Google/GMail contact, off-list.

Eric

Re: D'oH III: In 3-D! Plot Twist from Google/Chrome, Vixie approves?

[Scott Morizot]

+1

On Wed, Oct 30, 2019 at 11:03 AM Todd Underwood  wrote:

> the relevant sentiment is:  thanks for whitelisting a fixed number of them
> so i can block them.
>

Re: SFP oraganizers / storage recommendations

[Denys Fedoryshchenko]

On 2019-10-30 15:35, Matthew Huff wrote:

Any recommendations to keep track of different SFP and keep them
organized? Any storage boxes / trays designed for SFPs?

3D printed some, but i have small amounts.
Like this one: https://www.thingiverse.com/thing:2855165
There is many more designs, for example whole tray for 50 pieces.

RE: fuzzy subnet aggregation

[Jakob Heitz (jheitz) via NANOG]

Another thing to consider is how long it takes to download into forwarding 
hardware.
Forwarding hardware is optimized for forwarding, not programming.
The programming has to wait for time slots when forwarding is not using the 
memory.

When you do smart aggregation, a single changed route could cause a massive
change in your aggregates. Then the resulting download could be both long
and cause glitches. Glitches, because you remove some aggregates while adding
others within a finite time. During this finite time, you may have incorrect
routing.

Regards,
Jakob.

RE: RTG

[Drew Weaver]

Hi Nick,

At the time MRTG was the thing that everyone was using and the way it handled 
numbers and how it stored those numbers made it challenging to use for our use 
case.

The things that we like about RTG are that it collects raw (non-smoothed) 
numbers (usage) and it stores those numbers in a well known RDBMS.

This has made it extremely easy to integrate that data in other applications 
and with other data sources such as sflow/netflow to do some interesting things.

 It is also very easy to include graphs generated by RTG in other applications.

The primary pain point is how it handles 'targets' for polling and the 
targetmaker script itself. 

I will check out Libre.
Thanks!
-Drew




-Original Message-
From: Nick Hilliard  
Sent: Wednesday, October 30, 2019 9:09 AM
To: Drew Weaver 
Cc: 'nanog@nanog.org' 
Subject: Re: RTG

Drew Weaver wrote on 30/10/2019 12:25:
> We've been using this product for years and years 
> http://rtg.sourceforge.net/ to collect and store SNMP statistics.
> 
> It has been working fine for us. I haven't really been able to find 
> much information about forks, new versions, and development happening on it.
> 
> A while back I heard that Yahoo created their own version of it but I 
> could never find it.

that would have been yrtg:

http://mu.org/~billf/yrtg/

> Does anyone know if there is a spiritual successor to RTG that pretty 
> much works the same way that is modernized?

It was ok at the time, in its own way, but there are lots of other options 
these days, ranging from librenms to graphite, prometheus and that end of 
things, depending on what you're looking for in a graphing package.  Things 
moved on a bit in the area.

Nick

Re: D'oH III: In 3-D! Plot Twist from Google/Chrome, Vixie approves?

[Todd Underwood]

the relevant sentiment is:  thanks for whitelisting a fixed number of them
so i can block them.

t

On Wed, Oct 30, 2019 at 11:42 AM Royce Williams 
wrote:

> The difference is that Chrome won't use resolvers other than the ones
> you've configured yourself, and will simply opportunistically upgrade to
> DoH if they detect that those resolvers support it.
>
> In other words, there is no usurpation of administrative intent.
>
> Royce
>
> On Wed, Oct 30, 2019 at 7:30 AM Jay R. Ashworth  wrote:
>
>> It's not clear to me whether Paul is expressing approval of the whole
>> shebang
>> at this point, or just the one change they've made, but, just on first
>> look,
>> I don't think that change addresses *my* distaste for DoH, as discussed in
>> last month's 100-poster.  :-)
>>
>>
>> https://www.zdnet.com/article/dns-over-https-google-hits-back-at-misinformation-and-confusion-over-its-plans/
>>
>> TL;DR: they (Chrome) won't enable DoH unless it's being run from an
>> internet
>> which they know supports it; there are apparently a list of 8-12 ISPs/etc
>> which are announcing such support.
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth  Baylink
>> j...@baylink.com
>> Designer The Things I Think   RFC
>> 2100
>> Ashworth & Associates   http://www.bcp38.info  2000 Land
>> Rover DII
>> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
>> 1274
>>
>

Re: D'oH III: In 3-D! Plot Twist from Google/Chrome, Vixie approves?

[Royce Williams]

The difference is that Chrome won't use resolvers other than the ones
you've configured yourself, and will simply opportunistically upgrade to
DoH if they detect that those resolvers support it.

In other words, there is no usurpation of administrative intent.

Royce

On Wed, Oct 30, 2019 at 7:30 AM Jay R. Ashworth  wrote:

> It's not clear to me whether Paul is expressing approval of the whole
> shebang
> at this point, or just the one change they've made, but, just on first
> look,
> I don't think that change addresses *my* distaste for DoH, as discussed in
> last month's 100-poster.  :-)
>
>
> https://www.zdnet.com/article/dns-over-https-google-hits-back-at-misinformation-and-confusion-over-its-plans/
>
> TL;DR: they (Chrome) won't enable DoH unless it's being run from an
> internet
> which they know supports it; there are apparently a list of 8-12 ISPs/etc
> which are announcing such support.
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

D'oH III: In 3-D! Plot Twist from Google/Chrome, Vixie approves?

[Jay R. Ashworth]

It's not clear to me whether Paul is expressing approval of the whole shebang
at this point, or just the one change they've made, but, just on first look,
I don't think that change addresses *my* distaste for DoH, as discussed in
last month's 100-poster.  :-)

https://www.zdnet.com/article/dns-over-https-google-hits-back-at-misinformation-and-confusion-over-its-plans/

TL;DR: they (Chrome) won't enable DoH unless it's being run from an internet 
which they know supports it; there are apparently a list of 8-12 ISPs/etc 
which are announcing such support.

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: SFP oraganizers / storage recommendations

[Josh Luthman]

I've been doing the nice plastic trays from fs.com as well as a sharpie on
the side (bidi, mm, sm, distance, etc)

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Wed, Oct 30, 2019 at 9:54 AM Warren Kumari  wrote:

> If you buy your SFPs from fs.com, they come in a nice organizer -- and
> if you buy less than a tray full, you still get a tray.
> I keep spares in the trays, labeled on the outside -- I then put the
> trays in a cheap toolbox / fishing tackle box, and list what's in each
> one in a Google spreadsheet.
>
> Whenever I'm actually at the cage / rack and have a few minutes I
> compare the spreadsheet to reality, and update accordingly (SFPs, and
> XFPs in particular evaporate over time...)
>
> W
>
> On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
> >
> > Any recommendations to keep track of different SFP and keep them
> organized? Any storage boxes / trays designed for SFPs?
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>

IXP Renumbering: Equinix Miami (formerly known as NOTA)

[Fredy Künzler]

It seems that many participants of the Equinix Miami Exchange (formerly
Nap of the Americas NOTA) are unaware of the required IP renumbering.
Init7 AS13030 sees at least 50% of the new BGP sessions still down.

While the usefulness of the replacement of the peering mesh /23 with
another /23 could be discussed, the process itself hasn't been
announced, at least we didn't became aware of it until recently, and
only because some peers asked for new sessions.

Equinix provided a website with the necessary information, but it seems
that they failed to announce it. Interestingly the schedule is already
overdue.

https://ix.equinix.com/home/ip-migration/mi/

I would propose that some IXP operators should write a BCOP to avoid
future renumbering pain.

-- 
Fredy Künzler

Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
https://www.init7.net/

Re: SFP oraganizers / storage recommendations

[Jason Lixfeld]

We have ones from FS with our own logo on them and don’t pay any more (or 
marginally so), so I’m sure it’d trivial for FS to make a label that included a 
bar code for the PN or whatever you wanted, really.

> On Oct 30, 2019, at 10:10 AM, Luke Guillory  wrote:
> 
> Barcodes on FS.com is the serial, so you'd need to receive them in or enter 
> them with PN and SN.
> 
> 
> 
> Ns
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jason Lixfeld
> Sent: Wednesday, October 30, 2019 9:03 AM
> To: Warren Kumari
> Cc: NANOG mailing list
> Subject: Re: SFP oraganizers / storage recommendations
> 
> I’m wondering if the barcodes on the SFPs would let you simplify things a bit 
> more vs. updating a spreadsheet.  IE:  Some sort of barcode scanner app for 
> your phone that could automagically add/remove from some sort of document or 
> database?
> 
>> On Oct 30, 2019, at 9:53 AM, Warren Kumari  wrote:
>> 
>> If you buy your SFPs from fs.com, they come in a nice organizer -- and
>> if you buy less than a tray full, you still get a tray.
>> I keep spares in the trays, labeled on the outside -- I then put the
>> trays in a cheap toolbox / fishing tackle box, and list what's in each
>> one in a Google spreadsheet.
>> 
>> Whenever I'm actually at the cage / rack and have a few minutes I
>> compare the spreadsheet to reality, and update accordingly (SFPs, and
>> XFPs in particular evaporate over time...)
>> 
>> W
>> 
>> On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
>>> 
>>> Any recommendations to keep track of different SFP and keep them organized? 
>>> Any storage boxes / trays designed for SFPs?
>> 
>> 
>> 
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>  ---maf
> 
> 

RE: SFP oraganizers / storage recommendations

[Luke Guillory]

We use a few of these.

https://www.amazon.com/gp/product/B000LDH3JC/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8=1


We label the fronts with address label's for each PN.

https://i.imgur.com/iDTNVJ9.jpg






Luke Guillory
Vice President – Technology and Innovation

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084

_

Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. .

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Warren Kumari
Sent: Wednesday, October 30, 2019 8:54 AM
To: Matthew Huff
Cc: NANOG mailing list
Subject: Re: SFP oraganizers / storage recommendations

If you buy your SFPs from fs.com, they come in a nice organizer -- and if you 
buy less than a tray full, you still get a tray.
I keep spares in the trays, labeled on the outside -- I then put the trays in a 
cheap toolbox / fishing tackle box, and list what's in each one in a Google 
spreadsheet.

Whenever I'm actually at the cage / rack and have a few minutes I compare the 
spreadsheet to reality, and update accordingly (SFPs, and XFPs in particular 
evaporate over time...)

W

On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
>
> Any recommendations to keep track of different SFP and keep them organized? 
> Any storage boxes / trays designed for SFPs?



--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf

Re: SFP oraganizers / storage recommendations

[Ethan O'Toole]

I’m wondering if the barcodes on the SFPs would let you simplify things 
a bit more vs. updating a spreadsheet.  IE:  Some sort of barcode 
scanner app for your phone that could automagically add/remove from some 
sort of document or database?


Barcode is likely to just be the serial #, not model #?

- Ethan O'Toole

RE: SFP oraganizers / storage recommendations

[Luke Guillory]

Barcodes on FS.com is the serial, so you'd need to receive them in or enter 
them with PN and SN.



Ns






-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jason Lixfeld
Sent: Wednesday, October 30, 2019 9:03 AM
To: Warren Kumari
Cc: NANOG mailing list
Subject: Re: SFP oraganizers / storage recommendations

I’m wondering if the barcodes on the SFPs would let you simplify things a bit 
more vs. updating a spreadsheet.  IE:  Some sort of barcode scanner app for 
your phone that could automagically add/remove from some sort of document or 
database?

> On Oct 30, 2019, at 9:53 AM, Warren Kumari  wrote:
>
> If you buy your SFPs from fs.com, they come in a nice organizer -- and
> if you buy less than a tray full, you still get a tray.
> I keep spares in the trays, labeled on the outside -- I then put the
> trays in a cheap toolbox / fishing tackle box, and list what's in each
> one in a Google spreadsheet.
>
> Whenever I'm actually at the cage / rack and have a few minutes I
> compare the spreadsheet to reality, and update accordingly (SFPs, and
> XFPs in particular evaporate over time...)
>
> W
>
> On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
>>
>> Any recommendations to keep track of different SFP and keep them organized? 
>> Any storage boxes / trays designed for SFPs?
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf

Re: SFP oraganizers / storage recommendations

[Jason Lixfeld]

I’m wondering if the barcodes on the SFPs would let you simplify things a bit 
more vs. updating a spreadsheet.  IE:  Some sort of barcode scanner app for 
your phone that could automagically add/remove from some sort of document or 
database?

> On Oct 30, 2019, at 9:53 AM, Warren Kumari  wrote:
> 
> If you buy your SFPs from fs.com, they come in a nice organizer -- and
> if you buy less than a tray full, you still get a tray.
> I keep spares in the trays, labeled on the outside -- I then put the
> trays in a cheap toolbox / fishing tackle box, and list what's in each
> one in a Google spreadsheet.
> 
> Whenever I'm actually at the cage / rack and have a few minutes I
> compare the spreadsheet to reality, and update accordingly (SFPs, and
> XFPs in particular evaporate over time...)
> 
> W
> 
> On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
>> 
>> Any recommendations to keep track of different SFP and keep them organized? 
>> Any storage boxes / trays designed for SFPs?
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf

Re: SFP oraganizers / storage recommendations

[Warren Kumari]

If you buy your SFPs from fs.com, they come in a nice organizer -- and
if you buy less than a tray full, you still get a tray.
I keep spares in the trays, labeled on the outside -- I then put the
trays in a cheap toolbox / fishing tackle box, and list what's in each
one in a Google spreadsheet.

Whenever I'm actually at the cage / rack and have a few minutes I
compare the spreadsheet to reality, and update accordingly (SFPs, and
XFPs in particular evaporate over time...)

W

On Wed, Oct 30, 2019 at 9:36 AM Matthew Huff  wrote:
>
> Any recommendations to keep track of different SFP and keep them organized? 
> Any storage boxes / trays designed for SFPs?



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

SFP oraganizers / storage recommendations

[Matthew Huff]

Any recommendations to keep track of different SFP and keep them organized? Any 
storage boxes / trays designed for SFPs?

Re: RTG

[John Von Essen]

I too love RTG, been using it forever, appears to handle interfaces all the way 
up 10G.

Out of curiosity, are you hitting an issue that requires updating?

I get it, there are many options now, but back in the day, RTG was so simple 
and so useful, its a testament to the original product. Its a great light 
weight traffic monitor, at my old datacenter I monitored over 2000 interfaces 
(with up to 2 years of retention) from a very basic low-end single CPU box.

-John

> On Oct 30, 2019, at 8:25 AM, Drew Weaver  wrote:
> 
> Hello,
>  
> We’ve been using this product for years and years http://rtg.sourceforge.net/ 
>  to collect and store SNMP statistics.
>  
> It has been working fine for us. I haven’t really been able to find much 
> information about forks, new versions, and development happening on it.
>  
> A while back I heard that Yahoo created their own version of it but I could 
> never find it.
>  
> Does anyone know if there is a spiritual successor to RTG that pretty much 
> works the same way that is modernized?
>  
> Thanks! 
> -Drew

Re: RTG

[Nick Hilliard]

Drew Weaver wrote on 30/10/2019 12:25:
We’ve been using this product for years and years 
http://rtg.sourceforge.net/ to collect and store SNMP statistics.


It has been working fine for us. I haven’t really been able to find much 
information about forks, new versions, and development happening on it.


A while back I heard that Yahoo created their own version of it but I 
could never find it.


that would have been yrtg:

http://mu.org/~billf/yrtg/

Does anyone know if there is a spiritual successor to RTG that pretty 
much works the same way that is modernized?


It was ok at the time, in its own way, but there are lots of other 
options these days, ranging from librenms to graphite, prometheus and 
that end of things, depending on what you're looking for in a graphing 
package.  Things moved on a bit in the area.


Nick

RTG

[Drew Weaver]

Hello,

We've been using this product for years and years http://rtg.sourceforge.net/ 
to collect and store SNMP statistics.

It has been working fine for us. I haven't really been able to find much 
information about forks, new versions, and development happening on it.

A while back I heard that Yahoo created their own version of it but I could 
never find it.

Does anyone know if there is a spiritual successor to RTG that pretty much 
works the same way that is modernized?

Thanks!
-Drew