From colin at interisle.net Sun Apr 2 16:38:07 2017 From: colin at interisle.net (Colin Strutt) Date: Sun, 2 Apr 2017 10:38:07 -0400 Subject: [atlas] Problems trying to add a probe to a measurement Message-ID: <00d701d2abbe$bf030db0$3d092910$@interisle.net> I'm trying to add a probe, by probe number, to an existing, running measurement, using curl, following the example and description on page 84 of the "RIPE Atlas API v2 manual". However, I'm getting an error message that does not clearly point me to the problem, and thus allow me to correct my error. Here's what I'm entering (with the <.> as placeholders, explained below) curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{"probes":[{"action":"add","requested":1,"type":"probes","value":"

"}]}' https://atlas.ripe.net/api/v2/measurements//participation-requests/?key=< a> where:

is the number of the probe I'm trying to add, and I can access it at https://atlas.ripe.net/probes/

is the measurement to which I'm trying to add it - it's a running measurement, and I can access it at https://atlas.ripe.net/measurements/ is the API key, which is enabled and has "Update an existing measurement" granted The error I get back is: {"error":{"status":400,"code":104,"detail":"JSON parse error - No JSON object could be decoded","title":"Bad Request"}} In case it's relevant, I'm running curl 7.53.1 on Windows 10. Thanks in advance for any suggestions. colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Mon Apr 3 08:35:43 2017 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 3 Apr 2017 08:35:43 +0200 Subject: [atlas] Problems trying to add a probe to a measurement In-Reply-To: <00d701d2abbe$bf030db0$3d092910$@interisle.net> References: <00d701d2abbe$bf030db0$3d092910$@interisle.net> Message-ID: <95319182-fa09-11e3-2ea6-8d3aa4670c4f@ripe.net> Hi Colin, Try to submit it just either as object or list of objects (not including the outer "probes":). Like: {"action":"add","requested":1,"type":"probes","value":"

"} or [{"action":"add","requested":1,"type":"probes","value":"

"}, {"action":"add"....} ] wbr /vty On 4/2/17 4:38 PM, Colin Strutt wrote: > > I?m trying to add a probe, by probe number, to an existing, running > measurement, using curl, following the example and description on page > 84 of the ?RIPE Atlas API v2 manual?. However, I?m getting an error > message that does not clearly point me to the problem, and thus allow > me to correct my error. > > Here?s what I?m entering (with the as placeholders, explained below) > > curl -H "Content-Type: application/json" -H "Accept: application/json" > -X POST -d > '{"probes":[{"action":"add","requested":1,"type":"probes","value":"

"}]}' > https://atlas.ripe.net/api/v2/measurements//participation-requests/?key= > > where: > >

is the number of the probe I?m trying to add, and I can access it > at https://atlas.ripe.net/probes/

> > is the measurement to which I?m trying to add it ? it?s a running > measurement, and I can access it at > https://atlas.ripe.net/measurements/ > > is the API key, which is enabled and has ?Update an existing > measurement? granted > > The error I get back is: > > {"error":{"status":400,"code":104,"detail":"JSON parse error - No JSON > object could be decoded","title":"Bad Request"}} > > In case it?s relevant, I?m running curl 7.53.1 on Windows 10. > > Thanks in advance for any suggestions. > > colin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Thu Apr 6 13:59:05 2017 From: camin at ripe.net (Chris Amin) Date: Thu, 6 Apr 2017 13:59:05 +0200 Subject: [atlas] Behind the scenes changes to measurement creation Message-ID: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net> Dear colleagues, Today we deployed behind-the-scenes changes to the measurement creation process, both when using the website and the REST API. These changes should not have any visible effects, with the exception of improvements to the measurement API reference[1] to make it easier to see which options belong to which measurement type. Although we've tested these changes extensively, they are significant so I am sending this mail to ask you to please let us know if you notice any problems or changes when creating measurements. Kind regards, Chris Amin RIPE NCC [1] https://atlas.ripe.net/docs/api/v2/reference/#!/api/Measurement_List_GET -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From camin at ripe.net Fri Apr 7 12:55:34 2017 From: camin at ripe.net (Chris Amin) Date: Fri, 7 Apr 2017 12:55:34 +0200 Subject: [atlas] Behind the scenes changes to measurement creation In-Reply-To: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net> References: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net> Message-ID: <58816364-61d7-8f9f-9145-ada4f4b118fb@ripe.net> Dear all, There were several problems with these changes that have now been fixed: * When creating groups of measurements at the same time, only the first one would have probes scheduled, meaning that the other measurements would not receive results. This happened for 26 measurement creation requests before being fixed. * Measurements were scheduled more slowly so you may have seen delays before getting results. * Some measurements created using the API would display an error when viewing their details on the UI; these measurements have been fixed, and the problem no longer exists for new measurements. * The API became temporarily more strict in accepting certain values, which caused the command-line tools to stop working for some measurement types. The API has reverted to being more liberal in these cases, although this may be deprecated in the future -- any changes will be communicated clearly. Apologies for any inconvenience that these issues may have caused. Please do let us know if you notice anything else unusual when scheduling and using RIPE Atlas measurements. Kind regards, Chris Amin RIPE NCC On 06/04/2017 13:59, Chris Amin wrote: > Today we deployed behind-the-scenes changes to the measurement creation > process, both when using the website and the REST API. These changes > should not have any visible effects, with the exception of improvements > to the measurement API reference[1] to make it easier to see which > options belong to which measurement type. > > Although we've tested these changes extensively, they are significant so > I am sending this mail to ask you to please let us know if you notice > any problems or changes when creating measurements. > > Kind regards, > Chris Amin > RIPE NCC > > [1] https://atlas.ripe.net/docs/api/v2/reference/#!/api/Measurement_List_GET > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From colin at interisle.net Fri Apr 7 20:42:06 2017 From: colin at interisle.net (Colin Strutt) Date: Fri, 7 Apr 2017 14:42:06 -0400 Subject: [atlas] Problems trying to add a probe to a measurement In-Reply-To: <00d701d2abbe$bf030db0$3d092910$@interisle.net> References: <00d701d2abbe$bf030db0$3d092910$@interisle.net> Message-ID: <058c01d2afce$a863c400$f92b4c00$@interisle.net> As a result of some debugging with significant help from Viktor Naumov, we've been able to solve the problem. In fact there are two problems: 1. The example in the ripe_atlas_api_V2_manual.pdf is wrong 2. The example shows using curl under UNIX; Windows requires a completely different approach to make the curl command word. The example in the manual (page 84) shows JSON that it not accepted by atlas.ripe.net - the outer "layer" of JSON needs to be removed. So rather than '{"probes":[{"action":"add","requested":1,"type":"country","value":"NL"}]}' you need to use '{"action":"add","requested":1,"type":"country","value":"NL"}' And, while the example works on UNIX, it does not work, as shown, on Windows. It took a while to work out why. It appears that, in UNIX the single quote is used to escape the contents in between, so what gets sent to the HTTP server is just {"action":"add","requested":1,"type":"country","value":"NL"} But this "convention" does not work on Windows. Instead, the single quotes should be removed, and then *every* double-quote has to be escaped, with a backslash character, in order for the correct JSON to be sent to the HTTP server. This is the corrected version of the example in the API manual for a UNIX-based system: ~$ curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{"action":"add","requested":1,"type":"country","value":"NL"}' https://atlas.ripe.net/api/v2/measurements/100076/participation-requests/?ke y=YOUR_API_KEY And this is the version that needs to be used for a Windows system: C:\> curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d {\"action\":\"add\",\"requested\":1,\"type\":\"country\",\"value\":\"NL\"} https://atlas.ripe.net/api/v2/measurements/100076/participation-requests/?ke y=YOUR_API_KEY Apologies for the poor line-breaking in the above two examples in this email message. colin From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Colin Strutt Sent: Sunday, April 2, 2017 10:38 AM To: ripe-atlas at ripe.net Subject: [atlas] Problems trying to add a probe to a measurement I'm trying to add a probe, by probe number, to an existing, running measurement, using curl, following the example and description on page 84 of the "RIPE Atlas API v2 manual". However, I'm getting an error message that does not clearly point me to the problem, and thus allow me to correct my error. Here's what I'm entering (with the <.> as placeholders, explained below) curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{"probes":[{"action":"add","requested":1,"type":"probes","value":"

"}]}' https://atlas.ripe.net/api/v2/measurements//participation-requests/?key=< a> where:

is the number of the probe I'm trying to add, and I can access it at https://atlas.ripe.net/probes/

is the measurement to which I'm trying to add it - it's a running measurement, and I can access it at https://atlas.ripe.net/measurements/ is the API key, which is enabled and has "Update an existing measurement" granted The error I get back is: {"error":{"status":400,"code":104,"detail":"JSON parse error - No JSON object could be decoded","title":"Bad Request"}} In case it's relevant, I'm running curl 7.53.1 on Windows 10. Thanks in advance for any suggestions. colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Mon Apr 10 14:38:46 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 10 Apr 2017 14:38:46 +0200 Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy In-Reply-To: References: Message-ID: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> Dear colleagues, TraceMON is a client-side tool for visualising network topology generated by traceroutes reaching one or more targets in a network. It provides a one-click access to a set of information useful during day to day operations. Please find more details on RIPE Labs: https://labs.ripe.net/Members/massimo_candela/tracemon-traceroute-visualisation-network-debugging-tool Kind regards, Mirjam Kuhne RIPE NCC From randy at psg.com Tue Apr 11 04:45:38 2017 From: randy at psg.com (Randy Bush) Date: Mon, 10 Apr 2017 19:45:38 -0700 Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy In-Reply-To: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> References: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> Message-ID: ok, it is pretty cool. many creds. is there an api to which, for example, nlring folk could hook ring-trace? randy, always making trouble From mcandela at ripe.net Tue Apr 11 10:02:26 2017 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 11 Apr 2017 10:02:26 +0200 Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy In-Reply-To: References: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> Message-ID: <165B6A2A-22ED-4607-B0B3-A384D9FFFA4A@ripe.net> Not yet, but it?s matter of time. The idea is to create an open-source tool able to support whatever traceroute collection. The first release is RIPE Atlas centric, but as soon as I have time I will make it generic. Of course, the code is open, help on GitHub is welcome Ciao, Massimo > On 11 Apr 2017, at 04:45, Randy Bush wrote: > > ok, it is pretty cool. many creds. > > is there an api to which, for example, nlring folk could hook > ring-trace? > > randy, always making trouble From mcandela at ripe.net Tue Apr 11 11:04:54 2017 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 11 Apr 2017 11:04:54 +0200 Subject: [atlas] New on RIPE Labs: TraceMON - Network Debugging Made Easy In-Reply-To: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> References: <52847800-1fd1-ba11-3d70-357e627ca294@ripe.net> Message-ID: I received some questions about the exact location of TraceMON in Atlas. The tool is embedded by default on the detail page of each of the traceroute measurements in RIPE Atlas. Any RIPE Atlas user can access it by selecting a traceroute measurement in the measurements listing page [1] and clicking on the TraceMON tab. If you instead want just a quick demo: https://massimo.ripe.net/tracemon/widget/ I will try to collect some interesting cases on the link above. Ciao, Massimo [1] https://atlas.ripe.net/measurements/?search=&status=&af=&kind=2%2C4&age=#!tab-public > On 10 Apr 2017, at 14:38, Mirjam Kuehne wrote: > > > > Dear colleagues, > > TraceMON is a client-side tool for visualising network topology > generated by traceroutes reaching one or more targets in a network. It > provides a one-click access to a set of information useful during day to > day operations. Please find more details on RIPE Labs: > > https://labs.ripe.net/Members/massimo_candela/tracemon-traceroute-visualisation-network-debugging-tool > > Kind regards, > Mirjam Kuhne > RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg.kahest at internet.ee Thu Apr 13 11:08:02 2017 From: georg.kahest at internet.ee (Georg Kahest) Date: Thu, 13 Apr 2017 12:08:02 +0300 Subject: [atlas] status-check misbehaving Message-ID: Hello, Am I misunderstanding something or the status-checks are kind of broken: Yesterday i made new measurement: https://atlas.ripe.net/measurements/8038852/ I noticed some probes werent reaching my ipv6 host, so decided to remove them like you can see from the Probe specifications section. Now when i goto https://atlas.ripe.net/api/v2/measurements/8038852/status-check/ I can still see the removed probes in status-check page (which contains 17 errors ) in reality if i'm lookin at measurement probe page i should have only two errors. So it seems that status-check isnt updated once probes are removed from a measurement. -- Georg Kahest System Administrator / S?steemiadministraator Eesti Interneti SA Paldiski mnt 80, 10617 Tallinn Tel 727 1016 www.internet.ee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bryan at digitalocean.com Thu Apr 13 19:40:05 2017 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 13 Apr 2017 13:40:05 -0400 Subject: [atlas] Are there plans for faster than 1G anchors? Message-ID: We're finding it harder and harder to support the 1G nic interface on the anchors. We'd love to add more but would need a 10g port at minimum (25G or 40G would also work). Are there any plans to update them for networks that can't easily support a 1G nic? Bryan Socha Network Engineer DigitalOcean -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandb at ripe.net Tue Apr 18 11:18:47 2017 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 18 Apr 2017 11:18:47 +0200 Subject: [atlas] RIPE Atlas Maintenance Today Message-ID: <28f52c5533d37c347d17d68a73fce651@ripe.net> Dear colleagues, Today, between 11:15 and 16:00 (UTC+2) we will be performing maintenance on the RIPE Atlas infrastructure. Some probes may disconnect briefly during this time. Kind regards Anand Buddhdev Senior Engineer From alexmil at ics.forth.gr Tue Apr 18 14:04:00 2017 From: alexmil at ics.forth.gr (Alexandros Milolidakis) Date: Tue, 18 Apr 2017 14:04:00 +0200 Subject: [atlas] Behind the scenes changes to measurement creation In-Reply-To: <4c0921f1-fc4a-c3b1-5d77-37abbb322ff2@ripe.net> Message-ID: Hi Chris , It seems that stop_time , start_time etc don't work anymore. For example picking all trace route measurements which stopped before yesterday yields no results. https://atlas.ripe.net:443/api/v2/measurements/?stop_time__lt=1492469625&type=traceroute Could you take look? Thanks Alex Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From camin at ripe.net Tue Apr 18 15:26:41 2017 From: camin at ripe.net (Chris Amin) Date: Tue, 18 Apr 2017 15:26:41 +0200 Subject: [atlas] Behind the scenes changes to measurement creation In-Reply-To: References: Message-ID: <68c9539b-bb68-1a13-b031-c407a4f43f87@ripe.net> Dear Alex, Apologies, thank you for picking up on this. The stop_time and start_time lt, lte, gt and gte fields were incorrectly working like their exact match counterpart. This has now been fixed and these filters should work as expected. Kind regards, Chris On 18/04/2017 14:04, Alexandros Milolidakis wrote: > Hi Chris , > It seems that stop_time , start_time etc don't work anymore. > For example picking all trace route measurements which stopped before yesterday yields no results. > https://atlas.ripe.net:443/api/v2/measurements/?stop_time__lt=1492469625&type=traceroute > Could you take look? > Thanks > Alex > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From camin at ripe.net Wed Apr 19 12:08:01 2017 From: camin at ripe.net (Chris Amin) Date: Wed, 19 Apr 2017 12:08:01 +0200 Subject: [atlas] status-check misbehaving In-Reply-To: References: Message-ID: <179f6e82-711d-93ce-d919-e3c5c3f4d236@ripe.net> Dear Georg, The current behaviour is for all probes that have returned results in the past three days to be included in the status-check report. That's why removing the probes from the measurement did not immediately remove them from the status-check. We will review this behaviour because I can see how it is desirable to be able to immediately remove probes from the status check, and users will generally not care about results from probes that they have explicitly removed. For now your status-check does not include the old probes since they were removed more than three days ago -- if you have to remove more probes just keep in mind that the effect is not currently immediate. Kind regards, Chris Amin RIPE NCC On 13/04/2017 11:08, Georg Kahest wrote: > Hello, > > Am I misunderstanding something or the status-checks are kind of broken: > > Yesterday i made new measurement: > > https://atlas.ripe.net/measurements/8038852/ > > I noticed some probes werent reaching my ipv6 host, so decided to remove > them like you can see from the Probe specifications section. > > Now when i goto > https://atlas.ripe.net/api/v2/measurements/8038852/status-check/ > > I can still see the removed probes in status-check page (which contains > 17 errors ) in reality if i'm lookin at measurement probe page i should > have only two errors. > > So it seems that status-check isnt updated once probes are removed from > a measurement. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From romeo.zwart at ripe.net Thu Apr 20 16:10:39 2017 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Thu, 20 Apr 2017 16:10:39 +0200 Subject: [atlas] Are there plans for faster than 1G anchors? In-Reply-To: References: Message-ID: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net> Hi Bryan, On 17/04/13 19:40 , Bryan Socha wrote: > We're finding it harder and harder to support the 1G nic interface on > the anchors. We'd love to add more but would need a 10g port at > minimum (25G or 40G would also work). > > Are there any plans to update them for networks that can't easily > support a 1G nic? Interesting question. :) I can see the logic of this from the perspective of some operators. However, we are not considering adding 10GE or higher port speeds to the RIPE Atlas anchors. The reasons for this are manyfold: - Though this would possibly be technically feasible with some Soekris models that have PCI Express capabilities, there would be a non-trivial and as yet undefined amount of engineering work involved for us to make this an operationally supported option. - By expanding hardware support options we increase the burden on our limited-resourced operational team. - The current GE port speed already is a significant overkill for a measurement network that is not designed to do capacity/throughput tests. As a side note: we also have a strong requirement from many of our anchor hosts in other regions of the world to keep the actual bandwidth requirements for the anchors in the order of kilobits per second or less. - Our assessment is that most of our anchor hosts (current and prospective) will be able to support 1G somewhere in their networks for at least the next 3-5 years. I hope this clarifies our reasoning and addresses your question. Kind regards, Romeo > Bryan Socha > Network Engineer > DigitalOcean > From colinj at mx5.org.uk Thu Apr 20 16:26:11 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 20 Apr 2017 15:26:11 +0100 Subject: [atlas] Are there plans for faster than 1G anchors? In-Reply-To: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net> References: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net> Message-ID: vm virtual image would be great though so that underlying network would be transparent to the application. Colin > On 20 Apr 2017, at 15:10, Romeo Zwart wrote: > > Hi Bryan, > > On 17/04/13 19:40 , Bryan Socha wrote: >> We're finding it harder and harder to support the 1G nic interface on >> the anchors. We'd love to add more but would need a 10g port at >> minimum (25G or 40G would also work). >> >> Are there any plans to update them for networks that can't easily >> support a 1G nic? > > Interesting question. :) I can see the logic of this from the > perspective of some operators. However, we are not considering adding > 10GE or higher port speeds to the RIPE Atlas anchors. The reasons for > this are manyfold: > > - Though this would possibly be technically feasible with some Soekris > models that have PCI Express capabilities, there would be a non-trivial > and as yet undefined amount of engineering work involved for us to make > this an operationally supported option. > - By expanding hardware support options we increase the burden on our > limited-resourced operational team. > - The current GE port speed already is a significant overkill for a > measurement network that is not designed to do capacity/throughput > tests. As a side note: we also have a strong requirement from many of > our anchor hosts in other regions of the world to keep the actual > bandwidth requirements for the anchors in the order of kilobits per > second or less. > - Our assessment is that most of our anchor hosts (current and > prospective) will be able to support 1G somewhere in their networks for > at least the next 3-5 years. > > I hope this clarifies our reasoning and addresses your question. > > Kind regards, > Romeo > > > > >> Bryan Socha >> Network Engineer >> DigitalOcean >> > > From bryan at digitalocean.com Thu Apr 20 17:35:37 2017 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 20 Apr 2017 11:35:37 -0400 Subject: [atlas] Are there plans for faster than 1G anchors? In-Reply-To: References: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net> Message-ID: VM image or maybe follow what nlnog's the ring did and automate with an anchor sponsor giving you a base install you can control. That's even easier for me to support then dealing with specific hardware. But this is something to think about for future proofing and not requiring sponsors to find a spot and put it in more ideal locations. Depending on cost, maybe something like moving up to 10g ports that would support 1G with sfp-t adapters. We looked into that for our hardware and turned out we just can't do 1G on most of the hardware we are using these days. Food for thought on what the future anchor design should be as for us it's not about needing 10g bandwidth, it's having a 1G port to plug it into that has become a challenge. Bryan Socha Network Engineer DigitalOcean On Thu, Apr 20, 2017 at 10:26 AM, Colin Johnston wrote: > vm virtual image would be great though so that underlying network would be > transparent to the application. > > Colin > > > On 20 Apr 2017, at 15:10, Romeo Zwart wrote: > > > > Hi Bryan, > > > > On 17/04/13 19:40 , Bryan Socha wrote: > >> We're finding it harder and harder to support the 1G nic interface on > >> the anchors. We'd love to add more but would need a 10g port at > >> minimum (25G or 40G would also work). > >> > >> Are there any plans to update them for networks that can't easily > >> support a 1G nic? > > > > Interesting question. :) I can see the logic of this from the > > perspective of some operators. However, we are not considering adding > > 10GE or higher port speeds to the RIPE Atlas anchors. The reasons for > > this are manyfold: > > > > - Though this would possibly be technically feasible with some Soekris > > models that have PCI Express capabilities, there would be a non-trivial > > and as yet undefined amount of engineering work involved for us to make > > this an operationally supported option. > > - By expanding hardware support options we increase the burden on our > > limited-resourced operational team. > > - The current GE port speed already is a significant overkill for a > > measurement network that is not designed to do capacity/throughput > > tests. As a side note: we also have a strong requirement from many of > > our anchor hosts in other regions of the world to keep the actual > > bandwidth requirements for the anchors in the order of kilobits per > > second or less. > > - Our assessment is that most of our anchor hosts (current and > > prospective) will be able to support 1G somewhere in their networks for > > at least the next 3-5 years. > > > > I hope this clarifies our reasoning and addresses your question. > > > > Kind regards, > > Romeo > > > > > > > > > >> Bryan Socha > >> Network Engineer > >> DigitalOcean > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Apr 20 17:48:21 2017 From: gert at space.net (Gert Doering) Date: Thu, 20 Apr 2017 17:48:21 +0200 Subject: [atlas] Are there plans for faster than 1G anchors? In-Reply-To: References: <48720e29-eb5a-4cd9-5080-e59b4fb0bae5@ripe.net> Message-ID: <20170420154821.GB25069@Space.Net> Hi, On Thu, Apr 20, 2017 at 03:26:11PM +0100, Colin Johnston wrote: > vm virtual image would be great though so that underlying network would be transparent to the application. Welcome back, we've missed your contributions. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: