RE: OT - Small DNS "appliances" for remote offices.
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds. <div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates. Yeah, it would be awesome if they'd been able to get a SoC that included ethernet. -Pete On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me. Geoff On 02/18/2015 04:44 PM, Peter Loron wrote:
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
You also have to watch out for issues with the Pi corrupting SD cards. On 19 Feb 2015 01:04, "Geoff Mulligan" <nanog08@mulligan.org> wrote:
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me.
Geoff
On 02/18/2015 04:44 PM, Peter Loron wrote:
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
The BeagleBone Black uses flash memory to hold the system image which allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it seems stable. Geoff *-- Presidential Innovation Fellow | The White House* On 02/18/2015 05:20 PM, Bacon Zombie wrote:
You also have to watch out for issues with the Pi corrupting SD cards. On 19 Feb 2015 01:04, "Geoff Mulligan" <nanog08@mulligan.org> wrote:
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me.
Geoff
On 02/18/2015 04:44 PM, Peter Loron wrote:
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is "hardware" mac. Another hardware MAC on inexpensive board it is Odroid-C1. But stability of all this boards in heavy networking use is under question, i didn't tested them yet intensively for same purpose. On 2015-02-19 02:27, Geoff Mulligan wrote:
The BeagleBone Black uses flash memory to hold the system image which allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it seems stable.
Geoff
*-- Presidential Innovation Fellow | The White House*
On 02/18/2015 05:20 PM, Bacon Zombie wrote:
You also have to watch out for issues with the Pi corrupting SD cards. On 19 Feb 2015 01:04, "Geoff Mulligan" <nanog08@mulligan.org> wrote:
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me.
Geoff
On 02/18/2015 04:44 PM, Peter Loron wrote:
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
--- Best regards, Denys
Denys Fedoryshchenko <denys@visp.net.lb> writes:
Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is "hardware" mac.
The Beaglebone Black rev C BOM calls out the ethernet phy chip as LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC is built into the SoC and according to the datasheet the AM3358B is 10/100/1000.
Another hardware MAC on inexpensive board it is Odroid-C1.
Difficulty: hardware MAC tells you nothing about how it's connected, either on the board or internally in the SoC. Ethernet on Multibus and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both "hardware MAC" yet the bus-constrained bandwidths will differ by several orders of magnitude. -r
Denys Fedoryshchenko <denys@visp.net.lb> writes:
Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is "hardware" mac.
The Beaglebone Black rev C BOM calls out the ethernet phy chip as LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC is built into the SoC and according to the datasheet the AM3358B is 10/100/1000.
Another hardware MAC on inexpensive board it is Odroid-C1.
Difficulty: hardware MAC tells you nothing about how it's connected, either on the board or internally in the SoC. Ethernet on Multibus and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both "hardware MAC" yet the bus-constrained bandwidths will differ by several orders of magnitude.
-r Well, i guess for DNS it wont matter much(400Mbit or full capacity). But stability of driverand archievable pps rate on it, due poor code - can be a question. And mostly this products are "Network enabled", but networking are very "lightly" used, not as it is used on appliances, 24/7 traffic, sometimes malicious. About Beaglebone, probably reason is this errata: "While the AM335x GP EVM has a Gb Ethernet PHY, AR8031A, on the base board,
On 2015-02-19 15:13, Rob Seastrom wrote: the PCB was designed to use internal clock delay mode of the RGMII interface and the AM335x does not support the internal clock delay mode. Therefore, if operating the Ethernet in Gb mode, there may be problems with the performance/function due to this. The AR8031A PHY supports internal delay mode. This can be enabled by software to guarantee Gb operation. However, this cannot be done to enable internal delay mode for Ethernet booting of course. " Or maybe they just put 100Mbit PHY to make BOM cost less. As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. --- Best regards, Denys
On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko <denys@visp.net.lb> wrote:
As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now.
On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko <denys@visp.net.lb> wrote:
As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now.
AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems. Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations. I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. d.
People, processor of this hardware will be killed before the 100M ethernet be the problem. -- Eduardo Schoedler 2015-02-19 12:52 GMT-02:00 David Reader <david.reader@zeninternet.co.uk>:
On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko <denys@visp.net.lb> wrote:
As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now.
On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko <denys@visp.net.lb> wrote:
As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now.
AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems.
Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations.
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location.
d.
-- Eduardo Schoedler
On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said:
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location.
I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet.
On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu wrote:
On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said:
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location.
I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely.
Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications.
--- Best regards, Denys
If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu wrote:
On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said:
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications.
--- Best regards, Denys
older apple tv will work as well :) Colin
On 19 Feb 2015, at 19:47, Mel Beckman <mel@beckman.org> wrote:
If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS.
I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding.
Total time from unboxing to working DNS: 20 minutes.
The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients.
You get Apple's warranty and full support. Any Apple store can do testing and repair.
And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests.
Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions.
-mel
On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu wrote:
On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said:
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications.
--- Best regards, Denys
If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality or likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote:
If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS.
I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding.
Total time from unboxing to working DNS: 20 minutes.
The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients.
You get Apple's warranty and full support. Any Apple store can do testing and repair.
And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests.
Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions.
-mel
On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu wrote:
On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said:
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications.
--- Best regards, Denys
Keenan, Red. Herrings. You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely. Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part. BGP speaker? Come on, you're gilding the lily. Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source "road map" has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend. You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap. As a famous scientist one said: "The absence of data is not data." :-) -mel beckman On Feb 19, 2015, at 12:43 PM, "Keenan Tims" <ktims@stargate.ca<mailto:ktims@stargate.ca>> wrote: If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality org likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko <denys@visp.net.lb<mailto:denys@visp.net.lb>> wrote: On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote: On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys
here here, apple kits rocks for low end server work, sun kit rocks for high end server work. Colin
On 19 Feb 2015, at 20:55, Mel Beckman <mel@beckman.org> wrote:
Keenan,
Red. Herrings.
You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely.
Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part.
BGP speaker? Come on, you're gilding the lily.
Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source "road map" has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend.
You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap.
As a famous scientist one said: "The absence of data is not data." :-)
-mel beckman
On Feb 19, 2015, at 12:43 PM, "Keenan Tims" <ktims@stargate.ca<mailto:ktims@stargate.ca>> wrote:
If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate?
Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality org likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market.
Keenan
On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS.
I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding.
Total time from unboxing to working DNS: 20 minutes.
The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients.
You get Apple's warranty and full support. Any Apple store can do testing and repair.
And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests.
Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions.
-mel
On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko <denys@visp.net.lb<mailto:denys@visp.net.lb>> wrote:
On 2015-02-19 18:26, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote: On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications.
--- Best regards, Denys
The BeagleBone's ethernet is directly connected to the SoC, so you would get a higher throughput ceiling than the rpi. On Wed, Feb 18, 2015, 19:03 Geoff Mulligan <nanog08@mulligan.org> wrote:
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me.
Geoff
On 02/18/2015 04:44 PM, Peter Loron wrote:
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
On 2015-02-18 15:08, Robert Webb wrote:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div> </div>
On Wed, Feb 18, 2015 at 7:24 PM, Domenick Petrella <domenick.petrella@gmail.com> wrote:
The BeagleBone's ethernet is directly connected to the SoC, so you would get a higher throughput ceiling than the rpi.
sounds super important... question though, what's the expected average/normal/budgeted rate for the remote office connection to the intertubes? + or 1 10mbps ?
"Robert Webb" <rwebb@ropeguru.com> writes:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.Â
Pretty much all of the ARM boards have their ethernet ports on HSIC channels (480mbit/sec, no-transceiver-phy USB for on-board use - maximum length is 10cm). The Pi-B shares the single HSIC channel with the USB hub for the keyboard and mice. It seems from looking at block diagrams and lsusb output that the ODROID U3 has an SoC with multiple HSIC channels and dedicate one to to the ethernet (though the "bus" vs "port" distinction is suspect). pi@raspi-b ~ $ lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M pi@raspi-b ~ $ root@odroid:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M root@odroid:~# But 480 is greater than 100, and none of the Pis have ethernet faster than 10/100. The long pole in the tent is definitely not the USB, and single stream tcp throughput is fine. pi@raspi-b ~ $ curl -o /dev/null http://172.30.250.101/bigfile % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 989M 100 989M 0 0 11.1M 0 0:01:28 0:01:28 --:--:-- 11.1M pi@raspi-b ~ $ -r
On Wed, Feb 18, 2015 at 08:23:37PM -0500, Rob Seastrom wrote:
"Robert Webb" <rwebb@ropeguru.com> writes:
What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.??
Pretty much all of the ARM boards have their ethernet ports on HSIC channels (480mbit/sec, no-transceiver-phy USB for on-board use - maximum length is 10cm).
Agreed the long pole at a small site for DNS won't be the USB bus. Might I recommend the following: odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well. The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf. -- Bryan G. Seitz
Bryan Seitz <seitz@bsd-unix.net> writes:
odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well.
I haven't looked into the details of the clock, so "wouldn't be bad" is probably true, "notably good", well, that would be a task for someone with experience doing clock benchmarking and who can describe MAVAR without looking it up.
The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf.
The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so that's not a limit of the host on the other end of the benchmark. I call shenanigans on the 940 Mbps iperf number though. The HSIC bus is only 480 Mbit/sec. Two pints of beer in a one pint glass would be some trick. -r
On Thu, Feb 19, 2015 at 06:18:43AM -0500, Rob Seastrom wrote:
Bryan Seitz <seitz@bsd-unix.net> writes:
odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well.
I haven't looked into the details of the clock, so "wouldn't be bad" is probably true, "notably good", well, that would be a task for someone with experience doing clock benchmarking and who can describe MAVAR without looking it up.
The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf.
The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so that's not a limit of the host on the other end of the benchmark.
I call shenanigans on the 940 Mbps iperf number though. The HSIC bus is only 480 Mbit/sec. Two pints of beer in a one pint glass would be some trick.
http://dn.odroid.com/homebackup/201411241452444193.jpg I don't think it lives on the 480Mbit/sec limited bus here. [ 3] local 192.168.1.4 port 53391 connected with 192.168.1.21 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 488 MBytes 409 Mbits/sec [ 4] local 192.168.1.4 port 5001 connected with 192.168.1.21 port 34581 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec -- Bryan G. Seitz
participants (15)
-
Bacon Zombie -
Bryan Seitz -
Christopher Morrow -
Colin Johnston -
David Reader -
Denys Fedoryshchenko -
Domenick Petrella -
Eduardo Schoedler -
Geoff Mulligan -
Keenan Tims -
Mel Beckman -
Peter Loron -
Rob Seastrom -
Robert Webb -
Valdis.Kletnieks＠vt.edu