From randy at psg.com Sun May 1 00:25:32 2016 From: randy at psg.com (Randy Bush) Date: Sun, 01 May 2016 09:25:32 +0900 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: <7ed30fbc28fb4c34be602e197a37c48f@XCH-ALN-014.cisco.com> References: <008a01d1a317$56e33080$04a99180$@gmail.com> <7ed30fbc28fb4c34be602e197a37c48f@XCH-ALN-014.cisco.com> Message-ID: > If B does not send the /24 to F, > then F will send all the traffic to C, > even if A wanted a load balance. > > Maybe I could ask the community: > Why do you advertise longer prefixes with the > same nexthop as the shoter prefix? > Is it this use case, or something else? it is a common TE use case. but folk watching the water rise are starting to ask why the whole world should pay for A's TE. randy From randy at psg.com Sun May 1 02:43:01 2016 From: randy at psg.com (Randy Bush) Date: Sun, 01 May 2016 11:43:01 +0900 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: <008a01d1a317$56e33080$04a99180$@gmail.com> References: <008a01d1a317$56e33080$04a99180$@gmail.com> Message-ID: >> F >> / \ >> D E >> | | >> B C >> \ / >> A >> >> Suppose A is a customer of B and C. > > This is possible, but only remotely probable. In the real world, D and > E are likely peered, as are B and C. "likely?" with what probability? any measurement cite please. nothing exact; something rough would be fine. randy From rdobbins at arbor.net Sun May 1 03:56:32 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 01 May 2016 10:56:32 +0700 Subject: BGP FlowSpec In-Reply-To: <5724AB64.5050109@userid.org> References: <5724AB64.5050109@userid.org> Message-ID: On 30 Apr 2016, at 19:56, Pierre Lamy wrote: > to null out the destination rather than the source. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Sun May 1 08:46:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 1 May 2016 10:46:36 +0200 Subject: Standards for last mile performance In-Reply-To: References: <5724DC90.3000109@vaxination.ca> Message-ID: <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> On 30/Apr/16 20:36, Josh Reynolds wrote: > For us (FTTH) we had/have enough aggressive foresight to do smaller > splits.. 1x16. Some are doing 1x2's or 1x4's at the corner somewhere into > 1x16's or 1x8's, so at the point where you start to hit decent saturation > you can just shrink the upstream split and fuse onto a new upstream strand > / optic. Once that gets overused, thankfully you can overlay NG-PON2. If you're being this aggressive, and then having to re-invest in the next PON standard, isn't the case for Active-E being made more and more? Mark. From josh at kyneticwifi.com Sun May 1 08:55:33 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 1 May 2016 03:55:33 -0500 Subject: Standards for last mile performance In-Reply-To: <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> References: <5724DC90.3000109@vaxination.ca> <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> Message-ID: No. Active has higher initial and ongoing plant costs (cabinet power, cabinet wear and tear, more battery banks, chargers, etc). You also end up using far, far less fiber strands. On May 1, 2016 3:46 AM, "Mark Tinka" wrote: > > > On 30/Apr/16 20:36, Josh Reynolds wrote: > > > For us (FTTH) we had/have enough aggressive foresight to do smaller > > splits.. 1x16. Some are doing 1x2's or 1x4's at the corner somewhere into > > 1x16's or 1x8's, so at the point where you start to hit decent saturation > > you can just shrink the upstream split and fuse onto a new upstream > strand > > / optic. Once that gets overused, thankfully you can overlay NG-PON2. > > If you're being this aggressive, and then having to re-invest in the > next PON standard, isn't the case for Active-E being made more and more? > > Mark. > From josh at kyneticwifi.com Sun May 1 08:56:26 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 1 May 2016 03:56:26 -0500 Subject: Standards for last mile performance In-Reply-To: <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> References: <5724DC90.3000109@vaxination.ca> <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> Message-ID: In addition, the upgrade path uses the same strands simultaneously. On May 1, 2016 3:46 AM, "Mark Tinka" wrote: > > > On 30/Apr/16 20:36, Josh Reynolds wrote: > > > For us (FTTH) we had/have enough aggressive foresight to do smaller > > splits.. 1x16. Some are doing 1x2's or 1x4's at the corner somewhere into > > 1x16's or 1x8's, so at the point where you start to hit decent saturation > > you can just shrink the upstream split and fuse onto a new upstream > strand > > / optic. Once that gets overused, thankfully you can overlay NG-PON2. > > If you're being this aggressive, and then having to re-invest in the > next PON standard, isn't the case for Active-E being made more and more? > > Mark. > From mark.tinka at seacom.mu Sun May 1 08:58:24 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 1 May 2016 10:58:24 +0200 Subject: Standards for last mile performance In-Reply-To: References: <5724DC90.3000109@vaxination.ca> <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> Message-ID: On 1/May/16 10:55, Josh Reynolds wrote: > No. Active has higher initial and ongoing plant costs (cabinet power, > cabinet wear and tear, more battery banks, chargers, etc). You also > end up using far, far less fiber strands. > I tend to disagree, but this is one of those debates that could go on forever... Lord knows I've been having it since 2008. Mark. From 7riw77 at gmail.com Sun May 1 12:49:12 2016 From: 7riw77 at gmail.com (Russ White) Date: Sun, 1 May 2016 08:49:12 -0400 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: References: <008a01d1a317$56e33080$04a99180$@gmail.com> Message-ID: <00ac01d1a3a7$dd3837d0$97a8a770$@gmail.com> > >> F > >> / \ > >> D E > >> | | > >> B C > >> \ / > >> A > >> > >> Suppose A is a customer of B and C. > > > > This is possible, but only remotely probable. In the real world, D and > > E are likely peered, as are B and C. > > "likely?" with what probability? any measurement cite please. nothing > exact; something rough would be fine. Well, the average AS Path length is something like 4, and according to the charts Geoff has presented here and there, the graph is becoming more dense, as most people interconnect. The odds of finding an end-to-end path (4 hops) on the global 'net where no-one is peered in the middle seems pretty unlikely to me. It's not impossible, but it does seem unlikely, just given the average AS Path length and the density of the graph. For example, I suppose you could make A/B/C part of the same network which is intentionally not peered, or B/C two regional providers who are not peered with one another. You could then make D/E IXPs who have no transit connectivity between them, and then make F a tier 1 provider... But this really seems unlikely to me. How would you string together 4 AS' in a row that have no connectivity to any transit AS, even regional, like this? Two hops I can see, four I have a hard time seeing. > it is a common TE use case. but folk watching the water rise are starting to ask why the whole world should pay for A's TE. Precisely. Tragedy of the commons. To put it in other terms, removing information reduces optimization -- but if I can get optimization by making someone else pay for the information, then, well, why not? :-) Russ From randy at psg.com Sun May 1 13:22:35 2016 From: randy at psg.com (Randy Bush) Date: Sun, 01 May 2016 22:22:35 +0900 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: <00ac01d1a3a7$dd3837d0$97a8a770$@gmail.com> References: <008a01d1a317$56e33080$04a99180$@gmail.com> <00ac01d1a3a7$dd3837d0$97a8a770$@gmail.com> Message-ID: >>>> F >>>> / \ >>>> D E >>>> | | >>>> B C >>>> \ / >>>> A >>>> >>>> Suppose A is a customer of B and C. >>> >>> This is possible, but only remotely probable. In the real world, D and >>> E are likely peered, as are B and C. >> >> "likely?" with what probability? any measurement cite please. nothing >> exact; something rough would be fine. > > Well, the average AS Path length is something like 4, and according to > the charts Geoff has presented here and there, the graph is becoming > more dense, as most people interconnect. The odds of finding an > end-to-end path (4 hops) on the global 'net where no-one is peered in > the middle seems pretty unlikely to me. It's not impossible, but it > does seem unlikely, just given the average AS Path length and the > density of the graph. For example, I suppose you could make A/B/C part > of the same network which is intentionally not peered, or B/C two > regional providers who are not peered with one another. You could then > make D/E IXPs who have no transit connectivity between them, and then > make F a tier 1 provider... But this really seems unlikely to me. How > would you string together 4 AS' in a row that have no connectivity to > any transit AS, even regional, like this? Two hops I can see, four I > have a hard time seeing. i was hoping for measurements, not seems unlikely. as you know, i am sceptical about our internet topology intuitions and modeling given how good bgp is at hiding information and how poor our vantage points are. ripe atlas, caida, etc. give us some view, but views with inconsistencies and contradictions. we could write a paper on the hazards of as topology. oh, we did. :) randy From josh at kyneticwifi.com Sun May 1 15:02:01 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 1 May 2016 10:02:01 -0500 Subject: Standards for last mile performance In-Reply-To: References: <5724DC90.3000109@vaxination.ca> <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> Message-ID: Disagreeing is okay. It wouldn't make you any less wrong though :P On May 1, 2016 3:58 AM, "Mark Tinka" wrote: > > > On 1/May/16 10:55, Josh Reynolds wrote: > > > No. Active has higher initial and ongoing plant costs (cabinet power, > > cabinet wear and tear, more battery banks, chargers, etc). You also > > end up using far, far less fiber strands. > > > > I tend to disagree, but this is one of those debates that could go on > forever... > > Lord knows I've been having it since 2008. > > Mark. > From Valdis.Kletnieks at vt.edu Sun May 1 17:06:16 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 01 May 2016 13:06:16 -0400 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: References: Message-ID: <26273.1462122376@turing-police.cc.vt.edu> On Sat, 30 Apr 2016 19:10:44 -0000, "Jakob Heitz (jheitz)" said: > A use case for a longer prefix with the same nexthop: > > F > / \ > D E > | | > B C > \ / > A Am I the only one thinking "RFC4264" here? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From danny at tcb.net Mon May 2 12:30:14 2016 From: danny at tcb.net (Danny McPherson) Date: Mon, 02 May 2016 08:30:14 -0400 Subject: BGP FlowSpec In-Reply-To: <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> Message-ID: <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> On 2016-04-28 02:31 AM, Martin Bacher wrote: >> >> Literally the only people who were interested in it at the time was >> one >> of the spec's co-authors. :-) > That?s how it usually starts. ;) Given that I may be the guilty one here, I thought it might be worth chiming in. Inter-AS FlowSpec largely met the same fate as inter-AS source-based RTBH, where upstreams would only want to permit you to block sources destined for your address blocks (i.e.,. not others, so you would have to specify extended drop rule sets -- at least source and destination). As a result, with inter-AS FlowSpec, to appropriately scope things ingress policy specification is more complicated and hardware support was pretty limited at the time as well. Additionally, there was also only one vendor implementation at the time but now there are many and the IETF's IDR working group is continuing to enhance the capabilities and options available with FlowSpec. There are a large number of intra-AS and multi-AS single administrative domains that use FlowSpec today (my $dayjob included, for an array of things, not just DDoS mitigation). And as you point out Martin, it's simply another option available in the toolkit. One of the nicest things about it is that unlike destination-based RTBH, where you effectively completed the attack, if you can identify the primitives, namely at the network and transport layer, you can squelch a large number of attack vectors in an automated manner with minimal action required by the operator. We use it effectively in a layered model where "Principle of Minimal Intervention" applies, allowing attack mitigation and traffic diversion in the most optimal place (e.g., at network ingress), and only scrubbing or diverting traffic when necessary. Just like destination and source-based RTBH, FlowSpec is simply another evolution of automating forwarding path configuration, where NFV/SDN are the newest incarnation and can allows badness such as DDoS to be dropped implicitly rather than explicitly, even... -danny From outsider at scarynet.org Mon May 2 13:03:43 2016 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 2 May 2016 15:03:43 +0200 Subject: BGP FlowSpec In-Reply-To: <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> Message-ID: <85604b28716869b3fb41f233482f9b36.squirrel@mail.scarynet.org> On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote: > We use it effectively in a layered model where "Principle of Minimal > Intervention" applies, allowing attack mitigation and traffic diversion > in the most optimal place (e.g., at network ingress), and only scrubbing > or diverting traffic when necessary. Sorry to say, but the most optimal place for ddos mitigation is at network egress of origin. What comes in mind regarding that is the ability for target ASN telling source ASN to stop sending packets from a specific (let's say /29) in the case of a DDoS (with appropiate security measures in place off course). Because, let's face it, why would a target of a ddos need to nullroute itself? From ti14m028 at technikum-wien.at Mon May 2 13:16:44 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Mon, 2 May 2016 15:16:44 +0200 Subject: BGP FlowSpec In-Reply-To: <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> Message-ID: <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> > Am 02.05.2016 um 14:30 schrieb Danny McPherson : > > > > On 2016-04-28 02:31 AM, Martin Bacher wrote: > >>> Literally the only people who were interested in it at the time was one >>> of the spec's co-authors. :-) >> That?s how it usually starts. ;) > > > Given that I may be the guilty one here, I thought it might be worth chiming in. > > Inter-AS FlowSpec largely met the same fate as inter-AS source-based RTBH, where upstreams would only want to permit you to block sources destined for your address blocks (i.e.,. not others, so you would have to specify extended drop rule sets -- at least source and destination). I mainly agree on that. However, I have not found evidence of inter-AS S-RTBH deployments as of now. This would really require, at least in my understanding, a lot of hacks in order to implement it properly and avoid blackholing of the wrong traffic. BGP-FS is clearly doing a better job in that area. However, Tier 1s and most probably also some of the Tier 2s may not want to offer it to customers because they are loosing money if less traffic is sent downstream on IP-Transit links. What I would expect to see more often is iBGP deployments in order to protect the own infrastructure by remarking suspicious traffic to worst than best effort automatically. That?s again an example why BGP-FS in inter-AS setups may not be deployed on a large scale and things may stay worse for the Internet edge (and I still hope that I am wrong with that assumption). > As a result, with inter-AS FlowSpec, to appropriately scope things ingress policy specification is more complicated and hardware support was pretty limited at the time as well. Additionally, there was also only one vendor implementation at the time but now there are many and the IETF's IDR working group is continuing to enhance the capabilities and options available with FlowSpec. Yes, I have also noticed that. And the hardware support and inter-AS verification options are much better compared to the very beginning. > > There are a large number of intra-AS and multi-AS single administrative domains that use FlowSpec today (my $dayjob included, for an array of things, not just DDoS mitigation). And as you point out Martin, it's simply another option available in the toolkit. I personally think that it will really become standard for single administrative domains in the future as it is with L2VPNs and L3VPNs. Most of the AS will just deploy it and use it for DDoS mitigation and other applications. You just mentioned that you also used for other things. May I ask you about your use-cases? > > One of the nicest things about it is that unlike destination-based RTBH, where you effectively completed the attack, if you can identify the primitives, namely at the network and transport layer, you can squelch a large number of attack vectors in an automated manner with minimal action required by the operator. Could not agree more. > > We use it effectively in a layered model where "Principle of Minimal Intervention" applies, allowing attack mitigation and traffic diversion in the most optimal place (e.g., at network ingress), and only scrubbing or diverting traffic when necessary. Just like destination and source-based RTBH, FlowSpec is simply another evolution of automating forwarding path configuration, where NFV/SDN are the newest incarnation and can allows badness such as DDoS to be dropped implicitly rather than explicitly, even? Great. Thanks for sharing that. One must just make sure that the tools are used properly. High volume attacks can easily mitigated in many cases with BGP-FS while while other attacks like low bandwidth TCP attacks will have to be mitigated by scrubbing centers. @SDN/NFV: I am not so sure if this will really help or make things just more complicated. I have just been told that people are working on netconf/yang solutions for ACL deployments, which may again only work for intra-AS deployments. But your comment is going, at least in my understand, beyond ACL deployments, right? Could you please elaborate a bit further on that. Many thanks. Martin > > > -danny > From mattlists at rivervalleyinternet.net Mon May 2 11:47:05 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 2 May 2016 07:47:05 -0400 Subject: Frontier Internet Outage Message-ID: <57273E39.5010901@rivervalleyinternet.net> Is anyone else seeing major routing issues across the Frontier IP network this morning? I have been unable to get ahold of anyone at Frontier as of yet. From shane at short.id.au Sun May 1 10:27:20 2016 From: shane at short.id.au (Shane Short) Date: Sun, 1 May 2016 18:27:20 +0800 Subject: BGP FlowSpec In-Reply-To: References: <5724AB64.5050109@userid.org> Message-ID: <6DD5DBEC-F395-4398-96D5-3D8F88BD33B2@short.id.au> +1 I use this to block all kinds of unwanted traffic (with prejudice, of course). > On 1 May 2016, at 11:56 AM, Roland Dobbins wrote: > >> On 30 Apr 2016, at 19:56, Pierre Lamy wrote: >> >> to null out the destination rather than the source. > > > > ----------------------------------- > Roland Dobbins From jeff.richmond at gmail.com Mon May 2 13:46:41 2016 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Mon, 2 May 2016 06:46:41 -0700 Subject: Frontier Internet Outage In-Reply-To: <57273E39.5010901@rivervalleyinternet.net> References: <57273E39.5010901@rivervalleyinternet.net> Message-ID: <9E605BF8-9152-4AC1-9EC8-E132E27E8EA8@gmail.com> Matt, I will ping you direct, but for the public audience, we had a hardware issue this morning that was triggered during a config change on the peering routers. Should be resolved here very shortly. Thanks, -Jeff > On May 2, 2016, at 4:47 AM, Matt Hoppes wrote: > > Is anyone else seeing major routing issues across the Frontier IP network this morning? > > I have been unable to get ahold of anyone at Frontier as of yet. From ti14m028 at technikum-wien.at Mon May 2 13:48:37 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Mon, 2 May 2016 15:48:37 +0200 Subject: BGP FlowSpec In-Reply-To: <85604b28716869b3fb41f233482f9b36.squirrel@mail.scarynet.org> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <85604b28716869b3fb41f233482f9b36.squirrel@mail.scarynet.org> Message-ID: <108D89EF-9A19-4E77-A7F3-356C44411D89@technikum-wien.at> > Am 02.05.2016 um 15:03 schrieb Alexander Maassen : > > On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote: >> We use it effectively in a layered model where "Principle of Minimal >> Intervention" applies, allowing attack mitigation and traffic diversion >> in the most optimal place (e.g., at network ingress), and only scrubbing >> or diverting traffic when necessary. > > Sorry to say, but the most optimal place for ddos mitigation is at network > egress of origin. What comes in mind regarding that is the ability for > target ASN telling source ASN to stop sending packets from a specific > (let's say /29) in the case of a DDoS (with appropiate security measures > in place off course). > > Because, let's face it, why would a target of a ddos need to nullroute > itself? Well, I think ingress filtering at the Internet edge (see BCP38 and BCP84) would be the best approach. But we as Internet community are clearly failing in that area. And origin ASes of amplification and reflection attacks are most probably not able to detect DNS ANY queries or NTP monlist queries at a low rate without DPI. The networks used for reflection and amplification may be able to detect an ongoing attack and they will then hopefully fix their implementations and not deploy egress filters. So the question is how to get rid of source IP address spoofing at all? I don?t see any chance by now to push ASes, which are not filtering properly, to implement ingress filtering. What could help is to add session handling to UDP based protocols as proposed by Christian Rossow and implemented by Google in Quic. But that?s again just a workaround and may create new problems because of backwards compatibility issues. So filtering as precise as possible and as close as possible to the attack source is maybe the best option we have at the moment. > > From josh at imaginenetworksllc.com Mon May 2 13:50:55 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 2 May 2016 09:50:55 -0400 Subject: Frontier Internet Outage In-Reply-To: <57273E39.5010901@rivervalleyinternet.net> References: <57273E39.5010901@rivervalleyinternet.net> Message-ID: Traffic looks normal to me from Troy OH. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, May 2, 2016 at 7:47 AM, Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Is anyone else seeing major routing issues across the Frontier IP network > this morning? > > I have been unable to get ahold of anyone at Frontier as of yet. > From danny at tcb.net Mon May 2 13:54:12 2016 From: danny at tcb.net (Danny McPherson) Date: Mon, 02 May 2016 09:54:12 -0400 Subject: BGP FlowSpec In-Reply-To: <108D89EF-9A19-4E77-A7F3-356C44411D89@technikum-wien.at> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <85604b28716869b3fb41f233482f9b36.squirrel@mail.scarynet.org> <108D89EF-9A19-4E77-A7F3-356C44411D89@technikum-wien.at> Message-ID: On 2016-05-02 09:48 AM, Martin Bacher wrote: > > So filtering as precise as possible and as close as possible to the > attack source is maybe the best option we have at the moment. That was precisely my point! If an upstream isn't filtering at their ingress (or their egress) the optimal place for me to filter is at my ingress. Of course I'd rather have something akin to inter-domain pushback or FlowSpec, etc.. But you can't control how, or assume others will act on that. -danny From mel at beckman.org Mon May 2 13:56:20 2016 From: mel at beckman.org (Mel Beckman) Date: Mon, 2 May 2016 13:56:20 +0000 Subject: Frontier Internet Outage In-Reply-To: <9E605BF8-9152-4AC1-9EC8-E132E27E8EA8@gmail.com> References: <57273E39.5010901@rivervalleyinternet.net>, <9E605BF8-9152-4AC1-9EC8-E132E27E8EA8@gmail.com> Message-ID: <82ED50AE-9A20-4C3D-84FB-976BBFA9B8C0@beckman.org> We are seeing high latency to destinations within Frontier, but not to other locations outside Frontier: traceroute 71.102.212.201 traceroute to 71.102.212.201 (71.102.212.201), 64 hops max, 52 byte packets 1 98.112.74.1 (98.112.74.1) 4.349 ms 4.264 ms 4.855 ms 2 172.102.105.108 (172.102.105.108) 9.970 ms 12.494 ms 10.134 ms 3 ae8---0.scr02.lsan.ca.frontiernet.net (74.40.3.49) 9.833 ms 9.653 ms 10.081 ms 4 be10---0.lcr22.snlo.ca.frontiernet.net (74.40.3.54) 22.614 ms 24.705 ms 25.338 ms 5 172.102.96.195 (172.102.96.195) 24.824 ms 24.521 ms 25.280 ms 6 71.102.212.201 (71.102.212.201) 114.610 ms 134.279 ms 140.006 ms ping -s 1400 71.102.212.201 PING 71.102.212.201 (71.102.212.201): 1400 data bytes Request timeout for icmp_seq 0 1408 bytes from 71.102.212.201: icmp_seq=0 ttl=59 time=1313.874 ms 1408 bytes from 71.102.212.201: icmp_seq=1 ttl=59 time=749.040 ms 1408 bytes from 71.102.212.201: icmp_seq=2 ttl=59 time=200.203 ms 1408 bytes from 71.102.212.201: icmp_seq=3 ttl=59 time=209.519 ms 1408 bytes from 71.102.212.201: icmp_seq=4 ttl=59 time=286.727 ms 1408 bytes from 71.102.212.201: icmp_seq=5 ttl=59 time=338.709 ms 1408 bytes from 71.102.212.201: icmp_seq=6 ttl=59 time=1588.306 ms 1408 bytes from 71.102.212.201: icmp_seq=7 ttl=59 time=1627.653 ms 1408 bytes from 71.102.212.201: icmp_seq=8 ttl=59 time=1380.360 ms 1408 bytes from 71.102.212.201: icmp_seq=9 ttl=59 time=424.260 ms 1408 bytes from 71.102.212.201: icmp_seq=10 ttl=59 time=361.577 ms 1408 bytes from 71.102.212.201: icmp_seq=11 ttl=59 time=283.573 ms 1408 bytes from 71.102.212.201: icmp_seq=12 ttl=59 time=921.086 ms 1408 bytes from 71.102.212.201: icmp_seq=13 ttl=59 time=1037.984 ms 1408 bytes from 71.102.212.201: icmp_seq=14 ttl=59 time=902.649 ms traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets 1 98.112.74.1 (98.112.74.1) 6.391 ms 4.006 ms 5.330 ms 2 172.102.103.6 (172.102.103.6) 9.884 ms 6.952 ms 7.421 ms 3 ae8---0.scr01.lsan.ca.frontiernet.net (74.40.3.37) 7.531 ms 7.040 ms 10.007 ms 4 ae0---0.cbr01.lsan.ca.frontiernet.net (74.40.3.198) 7.441 ms 17.652 ms 7.147 ms 5 74.40.26.254 (74.40.26.254) 7.475 ms 6.983 ms 7.490 ms 6 216.239.59.205 (216.239.59.205) 7.468 ms 209.85.245.99 (209.85.245.99) 9.587 ms 64.233.174.37 (64.233.174.37) 7.364 ms 7 216.58.215.237 (216.58.215.237) 6.996 ms 209.85.249.221 (209.85.249.221) 7.648 ms 216.239.62.103 (216.239.62.103) 7.194 ms 8 google-public-dns-a.google.com (8.8.8.8) 7.275 ms 7.730 ms 7.039 ms ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=6.596 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=5.773 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=5.534 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=7.839 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=7.851 ms -mel beckman > On May 2, 2016, at 6:50 AM, Jeff Richmond wrote: > > Matt, I will ping you direct, but for the public audience, we had a hardware issue this morning that was triggered during a config change on the peering routers. Should be resolved here very shortly. > > Thanks, > -Jeff > >> On May 2, 2016, at 4:47 AM, Matt Hoppes wrote: >> >> Is anyone else seeing major routing issues across the Frontier IP network this morning? >> >> I have been unable to get ahold of anyone at Frontier as of yet. > From josh at kyneticwifi.com Mon May 2 13:58:23 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 2 May 2016 08:58:23 -0500 Subject: Frontier Internet Outage In-Reply-To: <57275C2B.6020201@rivervalleyinternet.net> References: <57273E39.5010901@rivervalleyinternet.net> <57275C2B.6020201@rivervalleyinternet.net> Message-ID: Something else you may want to look for in the future is an email report from the puck.nether.net outages list. On May 2, 2016 8:54 AM, "Matt Hoppes" wrote: > Yes yes yes, Josh :) Jeff got me the info I was looking for. > > On 5/2/16 9:47 AM, Josh Reynolds wrote: > >> From where? To what? Have you checked any carrier's looking glass? >> >> On May 2, 2016 8:45 AM, "Matt Hoppes" > > wrote: >> >> Is anyone else seeing major routing issues across the Frontier IP >> network this morning? >> >> I have been unable to get ahold of anyone at Frontier as of yet. >> >> From danny at tcb.net Mon May 2 16:25:34 2016 From: danny at tcb.net (Danny McPherson) Date: Mon, 02 May 2016 12:25:34 -0400 Subject: BGP FlowSpec In-Reply-To: <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> Message-ID: On 2016-05-02 09:16 AM, Martin Bacher wrote: > I mainly agree on that. However, I have not found evidence of inter-AS > S-RTBH deployments as of now. This would really require, at least in > my understanding, a lot of hacks in order to implement it properly and > avoid blackholing of the wrong traffic. BGP-FS is clearly doing a > better job in that area. However, Tier 1s and most probably also some > of the Tier 2s may not want to offer it to customers because they are > loosing money if less traffic is sent downstream on IP-Transit links. While possibly true in an small number of circumstance, I think that's a fairly naive view of the issue. That said, preventing collateral damage on the trajectory towards network egress was one of the primary drivers for destination-based RTBH (sacrifice the target to save the lot). > Great. Thanks for sharing that. One must just make sure that the tools > are used properly. High volume attacks can easily mitigated in many > cases with BGP-FS while while other attacks like low bandwidth TCP > attacks will have to be mitigated by scrubbing centers. Even some of those can be mitigated with network and transport layer controls, but certainly, there are places where you need application layer "scrubbing". > @SDN/NFV: I am not so sure if this will really help or make things > just more complicated. I have just been told that people are working > on netconf/yang solutions for ACL deployments, which may again only > work for intra-AS deployments. But your comment is going, at least in > my understand, beyond ACL deployments, right? Could you please > elaborate a bit further on that. All these techniques (from ACLs to BGP* to SDN) are all effectively about programming the forwarding path, albeit with more and more granularity, it's just a matter of where and what the management/control plane is. I agree with your intra-AS comment. -danny From vwittkop at nanog.org Mon May 2 17:33:16 2016 From: vwittkop at nanog.org (Valerie Wittkop) Date: Mon, 2 May 2016 13:33:16 -0400 Subject: [NANOG-announce] NANOG On The Road Comes to Denver! Message-ID: <04389A25-7980-44B7-8131-E996F6088451@nanog.org> We are very excited to be holding the next NOTR event in Denver on May 10, 2016, and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road Denver event is perfect for you! Date: May 10, 2016 Time: Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM Location: Denver Marriott Westminster - 7000 Church Ranch Boulevard, Westminster, CO 80021 The FREE to attend event is open for registration. Register Now! Agenda Topics are posted, which include: - Life After IPv4 - DNSSEC & RPKI - Traceroute Tutorial - IPv6 Tutorial - BGP Tutorial If you are, or will be, in the Denver area, we invite you to attend. And don?t forget to share the invitation with your colleagues or others you feel may benefit from attending. Make NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. Learn more about On The Road events here . Feel free to contact us at nanog-support at nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mike-nanog at tiedyenetworks.com Mon May 2 19:07:00 2016 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 2 May 2016 12:07:00 -0700 Subject: BGP peering strategies for smaller routers Message-ID: <5727A554.1090202@tiedyenetworks.com> Hello, I have an ASR1000 router with 4gb of ram. The specs say I can get '1 million routes' on it, but as far as I have been advised, a full table of internet routes numbers more than 530k by itself, so taking 2 full tables seems to be out of the question (?). I am looking to connect to a second ip transit provider and I'm looking for any advice or strategies that would allow me to take advantage and make good forwarding decisions while not breaking the bank on bgp memory consumption. I simply don't understand how this would likely play out and what memory consumption mitigation steps may be necessary here. Im open to ideas... a pair of route reflectors? selective bgp download? static route filter maps? Thank you. Mike- From jmilko at gmail.com Mon May 2 20:05:53 2016 From: jmilko at gmail.com (James Milko) Date: Mon, 2 May 2016 16:05:53 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: On Mon, May 2, 2016 at 3:07 PM, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so taking 2 full tables > seems to be out of the question (?). > > I am looking to connect to a second ip transit provider and I'm > looking for any advice or strategies that would allow me to take advantage > and make good forwarding decisions while not breaking the bank on bgp > memory consumption. I simply don't understand how this would likely play > out and what memory consumption mitigation steps may be necessary here. Im > open to ideas... a pair of route reflectors? selective bgp download? static > route filter maps? > > Thank you. > > Mike- > > You have to keep in mind there are two pools of memory on the router. The RIB and the FIB. The RIB contains all the routes that the router could possibly load. This includes all your BGP routes, even the ones not selected as best, and all your IGP routes. Whereas the FIB would only have the best routes that the router is actively using to forward traffic. FIB = 'sh ip route 4.2.2.2' RIB = 'sh ip bgp 4.2.2.2' (or OSPF, or IS-IS, or RIP, etc, etc) Generally FIB capacity is given as a number of routes and RIB capacity is given as a memory amount. Since the router manufacturer doesn't know what protocols you'll be running or how many attributes you'll be storing they don't really have a good idea of how many routes you'll get in the memory the router has. Now that you have a full table on the router, you won't see much growth on the FIB. For the most part every route you'll learn is already learned. You'll have some growth because not every transit provider will advertise the exact same table. My router with 3 transits has 580k routes for instance. In short, you're fine. Read up on RIB and FIB though so you have a good handle on when you're about to start running into problems. JM From mark.tinka at seacom.mu Mon May 2 20:18:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 May 2016 22:18:28 +0200 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <3fff94af-92b3-f1a9-dd3c-84eb889e76c5@seacom.mu> On 2/May/16 21:07, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get > '1 million routes' on it, but as far as I have been advised, a full > table of internet routes numbers more than 530k by itself, so taking 2 > full tables seems to be out of the question (?). Sounds like you have enough router resources to do your peering and take 2 full feeds. Mark. From ltd at interlink.com.au Mon May 2 20:27:40 2016 From: ltd at interlink.com.au (lincoln dale) Date: Mon, 2 May 2016 13:27:40 -0700 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: > > You have to keep in mind there are two pools of memory on the router. There's actually three. 1. Prefix (path) via BGP: "show ip bgp ". BGP will select the 'best' BGP path (can be multiple if ECMP) and send that through to the RIB. 2. RIB. "show ip route ". routing table will show the path chosen - and if there are backup paths etc, but may be recursive, e.g. prefix a.b.c.d points at e.f.g.h which in turn points at i.j.k.l etc. 3. FIB. basically fully resolved prefixes. What you otherwise say is correct - you could have N transit providers at (1) providing lotsOfPaths x N providers which ultimately resolve to lotsOfRoutes with up to N next-hops. Much design effort goes into the routing stack to efficiently store lotsOfPaths. Can't speak for what an ASR1K does but suggest the OP talk to Cisco. cheers, lincoln. From gustav.ulander at telecomputing.se Mon May 2 20:30:16 2016 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Mon, 2 May 2016 20:30:16 +0000 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: Hello. When we was in a similar situation we opted for one transit provider to provide a default to us then we filtered on AS-HOPS so prefixes that was more than 3 hops away was denied. This way we got the ones that where closest to us and that where more likely to matter. Prefixes that?s more than 3 hops away on both links could probably just as well go on a default insteed. However it?s a rather crude way of fixing the issue. We just did it to have the router up while we got extra memory from it. (we had memory shortage after an update that we needed to apply to correct some bug I think. We couldn?t just rollback the update if my memory serves me correct.) //Gustav -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Sent: den 2 maj 2016 21:07 To: NANOG list Subject: BGP peering strategies for smaller routers Hello, I have an ASR1000 router with 4gb of ram. The specs say I can get '1 million routes' on it, but as far as I have been advised, a full table of internet routes numbers more than 530k by itself, so taking 2 full tables seems to be out of the question (?). I am looking to connect to a second ip transit provider and I'm looking for any advice or strategies that would allow me to take advantage and make good forwarding decisions while not breaking the bank on bgp memory consumption. I simply don't understand how this would likely play out and what memory consumption mitigation steps may be necessary here. Im open to ideas... a pair of route reflectors? selective bgp download? static route filter maps? Thank you. Mike- From blake at ispn.net Mon May 2 20:34:26 2016 From: blake at ispn.net (Blake Hudson) Date: Mon, 2 May 2016 15:34:26 -0500 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <5727B9D2.2030000@ispn.net> Mike, the ASR1k series has several ESP options (ESP5, 10, 20, 40, 100, 200). Each ESP comes with a fixed amount of forwarding tcam which holds the forwarding information base (FIB). The ESP5 has 5MB of tcam can hold ~500k routes. The ESP10 has 10MB of tcam, so theoretically should hold roughly double (1 million routes). The ESP20 and ESP40 have 40MB of tam; Cisco quotes these as 4 million routes. http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/datasheet-c78-731640.html There are two route processor (RP) options for the ASR1k series. The RP1 and RP2. If you have 4GB, then you have an upgraded RP1. Which Cisco quotes at 1,000,000 IP4 routes *OR* 500k IP6 routes. Not to get too nitty gritty, but I would simplify these to say that there are 1,000,000 route slots; each IP4 route takes 1 slot and each IP6 route takes 2. http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-441072.html As others have noted, the best routes from the BGP table and other routing tables are condensed into the overall routing information base (RIB) and stored in DRAM. The RIB is then condensed into the FIB and stored as TCAM. Adding additional BGP peers will take minimal amounts of FIB if you're receiving the same full feed from both. The effect on the RIB and overall router memory is usually not that great either (I think on the ASR1k platform it's maybe ~100MB per peer). If you have an ESP10+, you're fine for two or more full feeds. If you have an ESP5, you really don't have the hardware to hold a single full feed. --Blake Mike wrote on 5/2/2016 2:07 PM: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get > '1 million routes' on it, but as far as I have been advised, a full > table of internet routes numbers more than 530k by itself, so taking 2 > full tables seems to be out of the question (?). > > I am looking to connect to a second ip transit provider and I'm > looking for any advice or strategies that would allow me to take > advantage and make good forwarding decisions while not breaking the > bank on bgp memory consumption. I simply don't understand how this > would likely play out and what memory consumption mitigation steps may > be necessary here. Im open to ideas... a pair of route reflectors? > selective bgp download? static route filter maps? > > Thank you. > > Mike- > From tony at wicks.co.nz Mon May 2 21:03:18 2016 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 3 May 2016 09:03:18 +1200 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <001301d1a4b6$0dcf2f20$296d8d60$@wicks.co.nz> I have used variations Gustav's solution below to good effect as well, this also works with two smaller routers providing basic fail over and load balancing. I found its best to take Full + default from one provider and just default from the other. Set a higher local-pref on the default only provider than the full+default one, then filter the full+default routes by AS-path as desired. Incoming control via the normal prepending of outgoing advertisements. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gustav Ulander Sent: Tuesday, 3 May 2016 8:30 AM To: Mike ; NANOG list Subject: RE: BGP peering strategies for smaller routers Hello. When we was in a similar situation we opted for one transit provider to provide a default to us then we filtered on AS-HOPS so prefixes that was more than 3 hops away was denied. This way we got the ones that where closest to us and that where more likely to matter. Prefixes that?s more than 3 hops away on both links could probably just as well go on a default insteed. However it?s a rather crude way of fixing the issue. We just did it to have the router up while we got extra memory from it. (we had memory shortage after an update that we needed to apply to correct some bug I think. We couldn?t just rollback the update if my memory serves me correct.) //Gustav -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Sent: den 2 maj 2016 21:07 To: NANOG list Subject: BGP peering strategies for smaller routers Hello, I have an ASR1000 router with 4gb of ram. The specs say I can get '1 million routes' on it, but as far as I have been advised, a full table of internet routes numbers more than 530k by itself, so taking 2 full tables seems to be out of the question (?). I am looking to connect to a second ip transit provider and I'm looking for any advice or strategies that would allow me to take advantage and make good forwarding decisions while not breaking the bank on bgp memory consumption. I simply don't understand how this would likely play out and what memory consumption mitigation steps may be necessary here. Im open to ideas... a pair of route reflectors? selective bgp download? static route filter maps? Thank you. Mike- From bob at FiberInternetCenter.com Mon May 2 21:03:52 2016 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 2 May 2016 14:03:52 -0700 Subject: BGP peering strategies for smaller routers In-Reply-To: <3fff94af-92b3-f1a9-dd3c-84eb889e76c5@seacom.mu> References: <5727A554.1090202@tiedyenetworks.com> <3fff94af-92b3-f1a9-dd3c-84eb889e76c5@seacom.mu> Message-ID: Rib or Fib for the million - thats the question - but in any event the following will most likely work for you. BTW, full table is now over 600K in size. 1) Choose one Transit and take their full table. (pick whatever reasons cost savings, bigger pipe, coin flip, etc.) 2) With the second transit use a filter to drop all everything /22 or smaller. Now check your tables , see if you have enough room. 3) Next add your peers - no filtering and lpref those routes about the transits. 4) Ask both transits to send you a default route. If this doesn't fit, use some more policy filtering and while this is up and running begin the search for a router with larger tables to replace it...as the tables will soon grow larger. Thank You Bob Evans CTO > > > On 2/May/16 21:07, Mike wrote: > >> Hello, >> >> I have an ASR1000 router with 4gb of ram. The specs say I can get >> '1 million routes' on it, but as far as I have been advised, a full >> table of internet routes numbers more than 530k by itself, so taking 2 >> full tables seems to be out of the question (?). > > Sounds like you have enough router resources to do your peering and take > 2 full feeds. > > Mark. > From rdobbins at arbor.net Mon May 2 21:38:46 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 03 May 2016 04:38:46 +0700 Subject: BGP FlowSpec In-Reply-To: <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> Message-ID: <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> On 2 May 2016, at 20:16, Martin Bacher wrote: > However, Tier 1s and most probably also some of the Tier 2s may not > want to offer it to customers because they are loosing money if less > traffic is sent downstream on IP-Transit links. I will go a step further than Danny's comments and state that this is categorically and demonstrably untrue. Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology) operators on this list offer commercial DDoS mitigation services making use of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand. They need these capabilities in order to defend their own properties and assets, and they are also offering them to end-customers who want and need them. In point of fact, it's becoming difficult to find one which *doesn't* offer this type of service. There were a couple of situations in the first half of the first decade of this millennium where operators took this attitude. But they changed their tunes pretty rapidly once they themselves were impacted, and once they started losing customers because they couldn't and wouldn't protect them. And as Danny notes, these technologies are all tools in the toolbox. NFV and 'SDN' have tremendous potential to make it a lot easier to bring mitigation resources to bear in a dynamic and optimal fashion within single spans of administrative control; and there are standards-based efforts underway to provide for a higher degree of automation, increased rapidity of response, and interoperability in both inter- and intra-network DDoS mitigation scenarios. ----------------------------------- Roland Dobbins From deleskie at gmail.com Mon May 2 21:51:06 2016 From: deleskie at gmail.com (jim deleskie) Date: Mon, 2 May 2016 18:51:06 -0300 Subject: BGP FlowSpec In-Reply-To: <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> Message-ID: I was going to avoid this thread because I've never been a huge fan of Flowspec for my own reasons. However having work on /been responsible for several "Tier 1 and 2" networks and DDoS mitigation services over the last 20 years, I can say I, nor any of my peers ( in any sense of that word) that I have known, have wanted to keep "bad " traffic on our networks so we can bill for it. Designing and running a large network is hard enough with planed growth, without having to manage unplanned spikes on links that can be orders of magnitude larger then traffic that "normally" flows across it. On top of that any given DDoS attack seldom last long enough to materially impact 95%ile billing, so carriers don't make anything from it, but have to do all the work of moving it around. -jim On Mon, May 2, 2016 at 6:38 PM, Roland Dobbins wrote: > On 2 May 2016, at 20:16, Martin Bacher wrote: > > However, Tier 1s and most probably also some of the Tier 2s may not want >> to offer it to customers because they are loosing money if less traffic is >> sent downstream on IP-Transit links. >> > > I will go a step further than Danny's comments and state that this is > categorically and demonstrably untrue. > > Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology) > operators on this list offer commercial DDoS mitigation services making use > of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand. > They need these capabilities in order to defend their own properties and > assets, and they are also offering them to end-customers who want and need > them. > > In point of fact, it's becoming difficult to find one which *doesn't* > offer this type of service. > > There were a couple of situations in the first half of the first decade of > this millennium where operators took this attitude. But they changed their > tunes pretty rapidly once they themselves were impacted, and once they > started losing customers because they couldn't and wouldn't protect them. > > And as Danny notes, these technologies are all tools in the toolbox. NFV > and 'SDN' have tremendous potential to make it a lot easier to bring > mitigation resources to bear in a dynamic and optimal fashion within single > spans of administrative control; and there are standards-based efforts > underway to provide for a higher degree of automation, increased rapidity > of response, and interoperability in both inter- and intra-network DDoS > mitigation scenarios. > > ----------------------------------- > Roland Dobbins > From rdobbins at arbor.net Mon May 2 22:06:39 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 03 May 2016 05:06:39 +0700 Subject: BGP FlowSpec In-Reply-To: References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> Message-ID: <39E3196C-F921-4237-B4C2-CF392AA90F86@arbor.net> On 3 May 2016, at 4:51, jim deleskie wrote: > I was going to avoid this thread because I've never been a huge fan of > Flowspec for my own reasons. Flowspec is an extremely useful tool, IMHO - not only for direct, layer-4-granular mitigation leveraging linecard ASICs, but for more granular and selective diversion into mitigation centers, as well. And its value is growing with increased platform support. It isn't perfect (nothing is), and operators must be aware of its performance/scalability envelope on a given platform, but it's a great tool to have in the toolbox. > I can say I, nor any of my peers ( in any sense of that word) that I > have known, have wanted to keep "bad " traffic on our networks so we > can bill for it. +1! I ran into this situation precisely twice early in the 'oughts ("Let the packets come!" was the quote which stood out in my mind); those espousing it pretty quickly changed their tunes once their networks had been knocked flat a couple of times. ;> ----------------------------------- Roland Dobbins From rtmcquillen at gmail.com Mon May 2 14:42:35 2016 From: rtmcquillen at gmail.com (Rob van de Logt) Date: Mon, 2 May 2016 09:42:35 -0500 Subject: Arista Routing Solutions In-Reply-To: <6D526C4EE4FA2745AD0D768DC25211F008FE543B6A95@MBOX-CLUSTER.hosted.vorboss.net> References: <571BB662.8000804@ninjabadger.net> <6D526C4EE4FA2745AD0D768DC25211F008FE543B6A95@MBOX-CLUSTER.hosted.vorboss.net> Message-ID: On Thu, Apr 28, 2016 at 2:22 PM, Timothy Creswick wrote: > Not in response to any point specifically, but the major issue which stopped us buying Arista a few months ago was the rather out-dated attitude to 3rd party transceiver support. > > I'm sure there are plenty of people running Arista on 3rd party optics, but all the noises that were being made by the sales and technical guys suggested that we could find ourselves abandoned by their support or a policy change in the future. We're going to be getting some Arista gear soon and this issue came up. They made the same noises and vague overtures of "well, you *might* have problems with TAC if you go with 3rd party optics"... until I said "Oh really- well, that's a deal breaker, we can't really even consider that". And then they backpedaled at light speed and reassured me that 3rd party optics would be fine, they just "had to have the conversation". Also talked to a local Arista customer, much bigger than us and using a lot more of their gear. They have 0 Arista optics and 0 problems with 3rd party for a few years now. IMHO the whole thing was just sales guy FUD to try to squeeze a few extra bucks out. From richard.hicks at gmail.com Mon May 2 20:32:14 2016 From: richard.hicks at gmail.com (Richard Hicks) Date: Mon, 2 May 2016 13:32:14 -0700 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: Careful with the ASR1000 and full tables at 4GB. http://www.gossamer-threads.com/lists/cisco/nsp/180710 I recommend adding some third party RAM to get 16GB. On Mon, May 2, 2016 at 12:07 PM, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so taking 2 full tables > seems to be out of the question (?). > > I am looking to connect to a second ip transit provider and I'm > looking for any advice or strategies that would allow me to take advantage > and make good forwarding decisions while not breaking the bank on bgp > memory consumption. I simply don't understand how this would likely play > out and what memory consumption mitigation steps may be necessary here. Im > open to ideas... a pair of route reflectors? selective bgp download? static > route filter maps? > > Thank you. > > Mike- > > From ti14m028 at technikum-wien.at Mon May 2 22:13:19 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Tue, 3 May 2016 00:13:19 +0200 Subject: BGP FlowSpec In-Reply-To: <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> Message-ID: > Am 02.05.2016 um 23:38 schrieb Roland Dobbins : > > On 2 May 2016, at 20:16, Martin Bacher wrote: > >> However, Tier 1s and most probably also some of the Tier 2s may not want to offer it to customers because they are loosing money if less traffic is sent downstream on IP-Transit links. > > I will go a step further than Danny's comments and state that this is categorically and demonstrably untrue. > > Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology) operators on this list offer commercial DDoS mitigation services making use of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand. They need these capabilities in order to defend their own properties and assets, and they are also offering them to end-customers who want and need them. > > In point of fact, it's becoming difficult to find one which *doesn't* offer this type of service. It was not meant to be a general statement that they are not offering anti DDoS services in whatever flavor. But you usually just get what you pay for. Furthermore, my statement was related to inter-AS BGP-FS and that providers may not offer it to customers but use in instead for traffic remarking to something like worse than best effort and still forwarding it to a customer under attack if he is not paying extra fees for DDoS mitigation. That does not mean that the ISP does not help on request or deploys countermeasures if its own infrastructure or other customers are suffering from that attack. But he may not perform any mitigation (except for the own protection) by default. > > There were a couple of situations in the first half of the first decade of this millennium where operators took this attitude. But they changed their tunes pretty rapidly once they themselves were impacted, and once they started losing customers because they couldn't and wouldn't protect them. > > And as Danny notes, these technologies are all tools in the toolbox. NFV and 'SDN' have tremendous potential to make it a lot easier to bring mitigation resources to bear in a dynamic and optimal fashion within single spans of administrative control; and there are standards-based efforts underway to provide for a higher degree of automation, increased rapidity of response, and interoperability in both inter- and intra-network DDoS mitigation scenarios. Sounds nice. Looking forward to see that implemented on a large scale in inter-AS setups. But I am not sure if this will really happen. > > ----------------------------------- > Roland Dobbins From ti14m028 at technikum-wien.at Mon May 2 22:21:56 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Tue, 3 May 2016 00:21:56 +0200 Subject: BGP FlowSpec In-Reply-To: References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> Message-ID: > Am 02.05.2016 um 23:51 schrieb jim deleskie : > > I was going to avoid this thread because I've never been a huge fan of > Flowspec for my own reasons. However having work on /been responsible for > several "Tier 1 and 2" networks and DDoS mitigation services over the last > 20 years, I can say I, nor any of my peers ( in any sense of that word) > that I have known, have wanted to keep "bad " traffic on our networks so > we can bill for it. Designing and running a large network is hard enough > with planed growth, without having to manage unplanned spikes on links that > can be orders of magnitude larger then traffic that "normally" flows > across it. I was for sure not precise enough in my statement and should have left out the money part. Sorry for that. An ISP would of course protect its own infrastructure and other customers if the attack is large enough and always tries to keep the general impact as low as possible. But auto mitigation is usually only provided for customers which are paying for it. BGP-FS offers an easy way for automatic deployment of traffic remarking of attack traffic in order to keep the overall impact for the own network and other customers at a very low level. > On top of that any given DDoS attack seldom last long enough to materially > impact 95%ile billing, so carriers don't make anything from it, but have to > do all the work of moving it around. > > -jim > > On Mon, May 2, 2016 at 6:38 PM, Roland Dobbins wrote: > >> On 2 May 2016, at 20:16, Martin Bacher wrote: >> >> However, Tier 1s and most probably also some of the Tier 2s may not want >>> to offer it to customers because they are loosing money if less traffic is >>> sent downstream on IP-Transit links. >>> >> >> I will go a step further than Danny's comments and state that this is >> categorically and demonstrably untrue. >> >> Many of the quite large 'Tier-1' and 'Tier-2' (using the old terminology) >> operators on this list offer commercial DDoS mitigation services making use >> of technologies like D/RTBH, S/RTBH, IDMS, et. al. due to customer demand. >> They need these capabilities in order to defend their own properties and >> assets, and they are also offering them to end-customers who want and need >> them. >> >> In point of fact, it's becoming difficult to find one which *doesn't* >> offer this type of service. >> >> There were a couple of situations in the first half of the first decade of >> this millennium where operators took this attitude. But they changed their >> tunes pretty rapidly once they themselves were impacted, and once they >> started losing customers because they couldn't and wouldn't protect them. >> >> And as Danny notes, these technologies are all tools in the toolbox. NFV >> and 'SDN' have tremendous potential to make it a lot easier to bring >> mitigation resources to bear in a dynamic and optimal fashion within single >> spans of administrative control; and there are standards-based efforts >> underway to provide for a higher degree of automation, increased rapidity >> of response, and interoperability in both inter- and intra-network DDoS >> mitigation scenarios. >> >> ----------------------------------- >> Roland Dobbins >> From ti14m028 at technikum-wien.at Mon May 2 22:38:53 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Tue, 3 May 2016 00:38:53 +0200 Subject: BGP FlowSpec In-Reply-To: <39E3196C-F921-4237-B4C2-CF392AA90F86@arbor.net> References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> <39E3196C-F921-4237-B4C2-CF392AA90F86@arbor.net> Message-ID: > Am 03.05.2016 um 00:06 schrieb Roland Dobbins : > > On 3 May 2016, at 4:51, jim deleskie wrote: > >> I was going to avoid this thread because I've never been a huge fan of Flowspec for my own reasons. > > Flowspec is an extremely useful tool, IMHO - not only for direct, layer-4-granular mitigation leveraging linecard ASICs, but for more granular and selective diversion into mitigation centers, as well. And its value is growing with increased platform support. It isn't perfect (nothing is), and operators must be aware of its performance/scalability envelope on a given platform, but it's a great tool to have in the toolbox. +1 > >> I can say I, nor any of my peers ( in any sense of that word) that I have known, have wanted to keep "bad " traffic on our networks so we can bill for it. > > +1! > > I ran into this situation precisely twice early in the 'oughts ("Let the packets come!" was the quote which stood out in my mind); those espousing it pretty quickly changed their tunes once their networks had been knocked flat a couple of times. Let the packets come is not the message. But an upstream ISP can either drop the traffic to reduce the impact on the own network and the customers which are not attacked directly or remark and/or rate-limit the particular flows with nearly, of course not for the customer under attack, the same result. And please don?t get me wrong. I am not a fan of implementing it that way. I also want to add something to keeping bad traffic: Well, nobody wants to keep bad traffic. But that does not imply that all upstream ISPs are filtering out attacks by default for customers which are not paying for that. This is at least my interpretation from reading the various available DDoS reports and research papers. > > ;> > > ----------------------------------- > Roland Dobbins From eric.kuhnke at gmail.com Mon May 2 23:09:12 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 2 May 2016 16:09:12 -0700 Subject: Standards for last mile performance In-Reply-To: References: <5724DC90.3000109@vaxination.ca> <0f0b468a-5382-efa4-1652-66f18e8c0572@seacom.mu> Message-ID: It hugely depends on the physical layout of the homes/area for economics of active-E vs GPON... The scale of the outside plant aerial fiber is very different in certain scenarios. A green field modern housing development with everything underground might be very different than a semi-rural chain shaped topology of GPON along a road of houses on 1 acre plots. Or an urban townhouse development. Or a 35 floor condo tower. On Sun, May 1, 2016 at 1:58 AM, Mark Tinka wrote: > > > On 1/May/16 10:55, Josh Reynolds wrote: > > > No. Active has higher initial and ongoing plant costs (cabinet power, > > cabinet wear and tear, more battery banks, chargers, etc). You also > > end up using far, far less fiber strands. > > > > I tend to disagree, but this is one of those debates that could go on > forever... > > Lord knows I've been having it since 2008. > > Mark. > From rdobbins at arbor.net Tue May 3 00:03:28 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 03 May 2016 07:03:28 +0700 Subject: BGP FlowSpec In-Reply-To: References: <20160427105823.12639135@localhost> <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> <4548ef76bafd6f33e098c93f90a46c7c@tcb.net> <3F0D338C-6AF6-411C-B2F9-957A006F9928@technikum-wien.at> <27975276-515D-4DBE-98BA-96BAD63E25B7@arbor.net> <39E3196C-F921-4237-B4C2-CF392AA90F86@arbor.net> Message-ID: On 3 May 2016, at 5:38, Martin Bacher wrote: > Let the packets come is not the message. That was *precisely* the message which was spoken to me directly by a large regional CONUS ISP in mid-2003 or thereabouts. I know this; I was there. And it was the wrong message, as that particular ISP found out a couple of weeks later when their network was knocked flat and they lost customers because of it. A bit of schadenfreude might not have been out of place, for the less-charitably inclined. > or remark and/or rate-limit the particular flows with nearly, of > course not for the customer under attack, the same result. This is almost always a Bad Idea, because the programmatically-generated attack traffic ends up 'crowding out' the legitimate traffic. For some attacks which are obviously out-of-profile with regards to the attack targets, this isn't as much of a concern; some large network operators are doing this with regards to common UDP reflection/amplification traffic (but they're being careful about it). And that still doesn't address the issue of high-volume traffic choking peering/transit links, of course. > But that does not imply that all upstream ISPs are filtering out > attacks by default for customers which are not paying for that. Nobody here has said that. But some beneficiary collateral effects of this nature do show up, from time to time. > This is at least my interpretation from reading the various available > DDoS reports and research papers. You should probably be aware that you are likely conversing directly with the authors of/contributors to some of those very reports and research papers in this thread (depending on which reports and papers you mean), and that the people with whom you are interacting routinely mitigate DDoS attacks on the public Internet as part of their normal work routine - and have done so for many years. For many of us, this is not a theoretical discussion; and it would probably be a good idea to keep in mind that our contributions to this thread aren't based upon reading various reports and research papers, but rather upon our actions which generate the data and experiential observations upon which such reports and research papers are based. ----------------------------------- Roland Dobbins From randy at psg.com Tue May 3 02:26:11 2016 From: randy at psg.com (Randy Bush) Date: Tue, 03 May 2016 11:26:11 +0900 Subject: Fwd: hotel References: Message-ID: excuse puking on list but the path to nanog admin action seems dead Date: Sun, 01 May 2016 13:48:10 +0900 From: Randy Bush To: action Subject: hotel hi, sorry to bother, but fairmont chicago block supposedly good to 22 may. tried to book just now, arriving 11th leaving 16th. got told "No lodging matches your search criteria. Please change your search options at right and try again." thanks randy From mike-nanog at tiedyenetworks.com Tue May 3 02:43:50 2016 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 2 May 2016 19:43:50 -0700 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <57281066.1010506@tiedyenetworks.com> On 05/02/2016 07:35 PM, Eric Sabotta wrote: > Mike, > > I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I got the real Cisco stuff for ~ $500). Before the router would crash when loading the tables. > > Right now, I have full tables from two providers: > > router1#show ip bgp summary > BGP router identifier 192.55.82.2, local AS number 4505 > BGP table version is 11150622, main routing table version 11150622 > 582461 network entries using 144450328 bytes of memory > 911730 path entries using 109407600 bytes of memory > 148924/93298 BGP path/bestpath attribute entries using 36933152 bytes of memory > 132977 BGP AS-PATH entries using 6043938 bytes of memory > 0 BGP route-map cache entries using 0 bytes of memory > 0 BGP filter-list cache entries using 0 bytes of memory > BGP using 296835018 total bytes of memory > BGP activity 962568/380103 prefixes, 5155645/4243915 paths, scan interval 60 secs > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd > 192.55.82.3 4 4505 2532914 1634867 11150622 0 0 3w0d 330377 > 192.55.82.4 4 4505 672950 1634865 11150622 0 0 3w0d 1 > 209.117.103.33 4 2828 1837130 48052 11150557 0 0 2w1d 581351 > > router1#show ip cef summary > IPv4 CEF is enabled for distributed and running > VRF Default > 582527 prefixes (582527/0 fwd/non-fwd) > Table id 0x0 > Database epoch: 2 (582527 entries at this epoch) > > -Eric > But if I'm reading the above right, it looks like bgp is eating ~300mb on your box. BGP using 296835018 total bytes of memory You would seem to have plenty of free ram. In my case, the ASR1002 doesn't have upgradable memory anyways so I'm stuck. Mike- From sf at lists.esoteric.ca Tue May 3 04:07:57 2016 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Tue, 3 May 2016 00:07:57 -0400 Subject: Fwd: hotel In-Reply-To: References: Message-ID: <15027fc0-853c-723a-4e99-e47c699d2414@lists.esoteric.ca> I tried booking earlier today, had the same issue and called in. I was told they were now full, and only non-block rooms were available (@ > $500/night). -- Stephen On 2016-05-02 10:26 PM, Randy Bush wrote: > excuse puking on list but the path to nanog admin action seems dead > > Date: Sun, 01 May 2016 13:48:10 +0900 > From: Randy Bush > To: action > Subject: hotel > > hi, > > sorry to bother, but > > fairmont chicago block supposedly good to 22 may. tried to book just > now, arriving 11th leaving 16th. got told "No lodging matches your > search criteria. Please change your search options at right and try > again." > > thanks > > randy > From randy at psg.com Tue May 3 04:09:35 2016 From: randy at psg.com (Randy Bush) Date: Tue, 03 May 2016 13:09:35 +0900 Subject: Fwd: hotel In-Reply-To: References: Message-ID: > To: action clue: this address is inactive sincs AMSL left the building ( thanks michael ) randy From randy at psg.com Tue May 3 05:22:52 2016 From: randy at psg.com (Randy Bush) Date: Tue, 03 May 2016 14:22:52 +0900 Subject: Fwd: hotel In-Reply-To: <15027fc0-853c-723a-4e99-e47c699d2414@lists.esoteric.ca> References: <15027fc0-853c-723a-4e99-e47c699d2414@lists.esoteric.ca> Message-ID: > I tried booking earlier today, had the same issue and called in. I was > told they were now full, and only non-block rooms were available (@ > > $500/night). find a non-exhorbitant fall-back? randy From mark.tinka at seacom.mu Tue May 3 05:37:31 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 3 May 2016 07:37:31 +0200 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <97b2ec1c-3ac3-7de8-0071-ec11f2351055@seacom.mu> On 2/May/16 22:32, Richard Hicks wrote: > Careful with the ASR1000 and full tables at 4GB. > > http://www.gossamer-threads.com/lists/cisco/nsp/180710 > > I recommend adding some third party RAM to get 16GB. It will be fine with 4GB of RAM provided the OP does not enable software redundancy. Mark. From dwessels at verisign.com Tue May 3 06:17:07 2016 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 3 May 2016 06:17:07 +0000 Subject: CFP: DNS Track at NANOG 67 Message-ID: Greetings, For our upcoming meeting in Chicago I'm looking for folks willing to give brief presentations during a proposed DNS Track. Possible topics include: - Operational experiences - New & interesting software features - Protocol advancements - Research results - Performance & compliance testing - Insights into DNS-related attacks I'm expecting to have about 90 minutes to fill with presentations of about 15 minutes or less. If you're interested in presenting please respond to me directly. Duane W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blake at ispn.net Tue May 3 13:20:16 2016 From: blake at ispn.net (Blake Hudson) Date: Tue, 3 May 2016 08:20:16 -0500 Subject: BGP peering strategies for smaller routers In-Reply-To: <57281066.1010506@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> <57281066.1010506@tiedyenetworks.com> Message-ID: <5728A590.4030301@ispn.net> Mike wrote on 5/2/2016 9:43 PM: > On 05/02/2016 07:35 PM, Eric Sabotta wrote: >> Mike, >> >> I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I >> got the real Cisco stuff for ~ $500). Before the router would crash >> when loading the tables. >> >> Right now, I have full tables from two providers: >> >> router1#show ip bgp summary >> BGP router identifier 192.55.82.2, local AS number 4505 >> BGP table version is 11150622, main routing table version 11150622 >> 582461 network entries using 144450328 bytes of memory >> 911730 path entries using 109407600 bytes of memory >> 148924/93298 BGP path/bestpath attribute entries using 36933152 bytes >> of memory >> 132977 BGP AS-PATH entries using 6043938 bytes of memory >> 0 BGP route-map cache entries using 0 bytes of memory >> 0 BGP filter-list cache entries using 0 bytes of memory >> BGP using 296835018 total bytes of memory >> BGP activity 962568/380103 prefixes, 5155645/4243915 paths, scan >> interval 60 secs >> >> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ >> Up/Down State/PfxRcd >> 192.55.82.3 4 4505 2532914 1634867 11150622 0 0 >> 3w0d 330377 >> 192.55.82.4 4 4505 672950 1634865 11150622 0 0 >> 3w0d 1 >> 209.117.103.33 4 2828 1837130 48052 11150557 0 0 >> 2w1d 581351 >> >> router1#show ip cef summary >> IPv4 CEF is enabled for distributed and running >> VRF Default >> 582527 prefixes (582527/0 fwd/non-fwd) >> Table id 0x0 >> Database epoch: 2 (582527 entries at this epoch) >> >> -Eric >> > > But if I'm reading the above right, it looks like bgp is eating ~300mb > on your box. > > BGP using 296835018 total bytes of memory > > You would seem to have plenty of free ram. In my case, the ASR1002 > doesn't have upgradable memory anyways so I'm stuck. > > Mike- > > Mike, I have a customer that has not had any operational issues taking two full IP4 feeds on an ASR1002 with RP1 @ 4GB of RAM. Again, I'd recommend an ESP10 to ensure you have enough TCAM to hold the FIB and to track netflow or other data that relies on the ESP. I can't comment on the RP2's memory usage or stability as I don't think I've ran into them. Here's the output to show you what to expect: #sh processes memory | inc BGP|Total:|PID Processor Pool Total: 1725514176 Used: 918478524 Free: 807035652 lsmpi_io Pool Total: 6295088 Used: 6294116 Free: 972 PID TTY Allocated Freed Holding Getbufs Retbufs Process 114 0 252 0 23264 4 4 BGP Scheduler 282 0 165948 327892 189212 0 0 BGP Task 294 0 0 0 17264 0 0 BGP HA SSO 317 0 610260780 0 220080 3387715 3387715 BGP I/O 355 0 0 17841472 23264 0 0 BGP Scanner 405 0 0 0 23316 0 0 BGP Consistency 422 0 0 0 23264 0 0 BGP Event 528 0 560439808 646907016 498109200 51 51 BGP Router 533 0 0 0 17264 0 0 BGP VA #sh bgp su BGP router identifier 1.2.3.4, local AS number ccccc BGP table version is 66249122, main routing table version 66249122 598594 network entries using 86197536 bytes of memory 1177526 path entries using 94202080 bytes of memory 208207/100401 BGP path/bestpath attribute entries using 28316152 bytes of memory 179429 BGP AS-PATH entries using 7090834 bytes of memory 4342 BGP community entries using 230370 bytes of memory 1 BGP extended community entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 216036996 total bytes of memory BGP activity 2943907/2345309 prefixes, 10963622/9786096 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd a.a.a.a 4 aaa 5523968 51273 66249070 0 0 4w4d 578933 b.b.b.b 4 bbbbb 3731440 101400 66249070 0 0 4w4d 598586 #sh cef fib 599851 allocated IPv4 entries, 0 failed allocations 1 allocated IPv6 entry, 0 failed allocations #sh ip route summary IP routing table name is default (0x0) IP routing table maximum-paths is 32 Route Source Networks Subnets Replicates Overhead Memory (bytes) connected 0 60 0 3600 10800 static 20 79 0 6060 17820 bgp ccccc 180614 417599 0 35892780 107678340 External: 598213 Internal: 0 Local: 0 internal 6552 23993840 Total 187186 417738 0 35902440 131700800 From math at sizone.org Tue May 3 14:06:39 2016 From: math at sizone.org (Ken Chase) Date: Tue, 3 May 2016 10:06:39 -0400 Subject: BGP peering strategies for smaller routers Message-ID: <20160503140639.GG6546@sizone.org> got a quagga router in my life where bgpd+zebra takes up 1gig for 4.5 full tables. Rest of the OS easily lives in 1 gig (could probably be much less.) big-vendor solutions always seem much bloatier - same deal on power usage. just a data point. /kc -- Ken Chase - math at sizone.org Toronto From Timothy.Creswick at vorboss.com Tue May 3 14:11:22 2016 From: Timothy.Creswick at vorboss.com (Timothy Creswick) Date: Tue, 3 May 2016 15:11:22 +0100 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> <6D526C4EE4FA2745AD0D768DC25211F008FE543B6A95@MBOX-CLUSTER.hosted.vorboss.net> Message-ID: <6D526C4EE4FA2745AD0D768DC25211F008FE546E4DEC@MBOX-CLUSTER.hosted.vorboss.net> > We're going to be getting some Arista gear soon and this issue came > up. They made the same noises and vague overtures of "well, you > *might* have problems with TAC if you go with 3rd party optics"... > until I said "Oh really- well, that's a deal breaker, we can't really > even consider that". And then they backpedaled at light speed and > reassured me that 3rd party optics would be fine, they just "had to > have the conversation". Similar experience here, but the conversation went on far too long and ultimately lost Arista the deal. There was a ridiculous amount of insistence that we would have to carry a "stock of Arista optics", but every attempt to clarify exactly what that meant (how many, what they would cost etc) failed to get a straight answer. It's 2016 and stupid conversations about vendor optics waste time and destroy deals. The slight difference here is that pretty much the first thing we said to Arista was that transceivers were out of the question unless they could price them reasonably** (they chose not to). On this particular deal we were probably only talking about 500 SR 10G transceivers. We've had similar conversations with Extreme, Brocade, Solarflare and Juniper, all of whom are quite happy with us running our own parts. Solarflare even certified our parts and put them on their website (http://solarflare.com/transceivers-and-cables). > Also talked to a local Arista customer, much bigger than us and using > a lot more of their gear. They have 0 Arista optics and 0 problems > with 3rd party for a few years now. IMHO the whole thing was just > sales guy FUD to try to squeeze a few extra bucks out. Doesn't surprise me, and I'm sure if we'd pushed for another week we could have got to this position. Unfortunately for Arista, there was another vendor quite happy to get the deal done faster and without all the BS so we voted with our feet. Clearly, mileage will vary on this one. T ** in this context, "reasonably" means no more than _double_ what I currently buy at. From bill at herrin.us Tue May 3 14:31:15 2016 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2016 10:31:15 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: On Mon, May 2, 2016 at 3:07 PM, Mike wrote: > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so taking 2 full tables > seems to be out of the question (?). Hi Mike, There is no "routing table." Instead: Routing Information Bases (RIB) Forwarding Information Base (FIB) RIB = the routing data from your neighbors. Each protocol (e.g. BGP, OSPF, static, connected) has a RIB. If you have virtual routers (VRF) then each VRF has its own RIBs. For the BGP RIB, each prefix (route) from each neighbor will need its own slot in the RIB. FIB = the next hop table. Only the best next hop for each prefix is stored in the FIB. One FIB per protocol (IPv4, IPv6), unless you run VRFs, then one FIB each per VRF. All routers have both a FIB and RIBs. All routers keep the RIBs in DRAM. Big Iron like yours typically store the FIB in special hardware called Ternary Content Addressable Memory (TCAM). You're looking at two physically different kinds of memory in your router to store the RIB and the FIB. No matter how much DRAM you have, you only have so much TCAM in that routing engine. The TCAM is not upgradable. In fact, it's buried under a big heat sink. All the RIBs are processed down to a single FIB for each protocol/VRF. The best next hop is selected from all the possibilities in the RIBs and only that one gets stored in the FIB. The FIB in the TCAM is consulted every single time a packet is routed. The RIBs are only consulted when new information is received from a neighbor of when the FIB table needs to be rebuilt. The RIB is not consulted to route individual packets. Your "million routes" is a reflection of the TCAM on your routing engine. The FIB table size. 4G DRAM is enough for 10-15 million routes in the various RIBs. If you're running a single VRF, you have enough FIB headroom for the next two or three years, until the v4 and v6 BGP tables add up to around 900M prefixes. You already have too little FIB headroom to run two BGP-speaking VRFs. My piddly little 2811 carries a full IPv4 table, 580k routes. Its BGP RIB consumes all of 154 megabytes of DRAM. Unlike your router, the 2811 does not have a "hardware fast path." No TCAM. It stores the FIB in a radix tree in DRAM instead. As a result, it can only handle low data rates, in the 10s of megabits per second. I'm leaving out lots of details, but these are the most important with respect to your question. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jerome at fleury.net Tue May 3 02:46:22 2016 From: jerome at fleury.net (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Mon, 2 May 2016 19:46:22 -0700 Subject: hotel In-Reply-To: References: Message-ID: Same here - only availability is from Monday 13th to Thursday 16th On Mon, May 2, 2016 at 7:26 PM, Randy Bush wrote: > excuse puking on list but the path to nanog admin action seems dead > > Date: Sun, 01 May 2016 13:48:10 +0900 > From: Randy Bush > To: action > Subject: hotel > > hi, > > sorry to bother, but > > fairmont chicago block supposedly good to 22 may. tried to book just > now, arriving 11th leaving 16th. got told "No lodging matches your > search criteria. Please change your search options at right and try > again." > > thanks > > randy > From esabotta at whdh.com Tue May 3 02:35:30 2016 From: esabotta at whdh.com (Eric Sabotta) Date: Tue, 3 May 2016 02:35:30 +0000 Subject: BGP peering strategies for smaller routers In-Reply-To: <5727A554.1090202@tiedyenetworks.com> References: <5727A554.1090202@tiedyenetworks.com> Message-ID: Mike, I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I got the real Cisco stuff for ~ $500). Before the router would crash when loading the tables. Right now, I have full tables from two providers: router1#show ip bgp summary BGP router identifier 192.55.82.2, local AS number 4505 BGP table version is 11150622, main routing table version 11150622 582461 network entries using 144450328 bytes of memory 911730 path entries using 109407600 bytes of memory 148924/93298 BGP path/bestpath attribute entries using 36933152 bytes of memory 132977 BGP AS-PATH entries using 6043938 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 296835018 total bytes of memory BGP activity 962568/380103 prefixes, 5155645/4243915 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.55.82.3 4 4505 2532914 1634867 11150622 0 0 3w0d 330377 192.55.82.4 4 4505 672950 1634865 11150622 0 0 3w0d 1 209.117.103.33 4 2828 1837130 48052 11150557 0 0 2w1d 581351 router1#show ip cef summary IPv4 CEF is enabled for distributed and running VRF Default 582527 prefixes (582527/0 fwd/non-fwd) Table id 0x0 Database epoch: 2 (582527 entries at this epoch) -Eric -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Sent: Monday, May 2, 2016 3:07 PM To: NANOG list Subject: BGP peering strategies for smaller routers Hello, I have an ASR1000 router with 4gb of ram. The specs say I can get '1 million routes' on it, but as far as I have been advised, a full table of internet routes numbers more than 530k by itself, so taking 2 full tables seems to be out of the question (?). I am looking to connect to a second ip transit provider and I'm looking for any advice or strategies that would allow me to take advantage and make good forwarding decisions while not breaking the bank on bgp memory consumption. I simply don't understand how this would likely play out and what memory consumption mitigation steps may be necessary here. Im open to ideas... a pair of route reflectors? selective bgp download? static route filter maps? Thank you. Mike- From bill at herrin.us Tue May 3 16:12:42 2016 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2016 12:12:42 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: On Mon, May 2, 2016 at 10:35 PM, Eric Sabotta wrote: > I just did this with a ASR1001. I had to upgrade it to 8gb of ram > (I got the real Cisco stuff for ~ $500). Before the router would > crash when loading the tables. Hi Eric, Something very fishy there because: > router1#show ip bgp summary > BGP using 296,835,018 total bytes of memory Commas added for clarity. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cgrundemann at gmail.com Tue May 3 16:16:47 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 3 May 2016 12:16:47 -0400 Subject: Fwd: hotel In-Reply-To: References: <15027fc0-853c-723a-4e99-e47c699d2414@lists.esoteric.ca> Message-ID: On Tue, May 3, 2016 at 1:22 AM, Randy Bush wrote: > > I tried booking earlier today, had the same issue and called in. I was > > told they were now full, and only non-block rooms were available (@ > > > $500/night). > > find a non-exhorbitant fall-back? The Sheraton Grand Chicago is close and appears to have not-quite-exorbitant rates (~$400). From betty at nanog.org Tue May 3 16:50:57 2016 From: betty at nanog.org (Betty Burke ) Date: Tue, 3 May 2016 12:50:57 -0400 Subject: [NANOG-announce] NANOG 67 Announcements Message-ID: NANOGers, We are beginning our final preparations in support of NANOG 67 taking place June 13-15, 2016 in Chicago, IL. The meeting will be held at the Fairmont Chicago Millennium Park. In addition, prior to the start of NANOG 67, The NANOG Program Committee is pleased to announce the first NANOG one-day Hackathon, Sunday, June 12, 2016 , at the Fairmont Chicago Millennium Park. The event will feature new ideas and hacks for automating production Internet networks. The NANOG event is planned in partnership with FaceBook and will require a separate registration process. For those considering the NANOG Hackation, attendance is free, however you must register here . The NANOG Program Committee continues in its dedication to present NANOG 67 attendees with quality presentations, track discussions, and tutorials. The agenda topics are confirmed and posted on the NANOG Highlights page. The draft agenda is expected on or near May 16, 2016. For those considering the NANOG 67 Conference, please be aware the registration fee will increase soon! Also, take a moment to join NANOG or renew your existing Membership . As a member, you receive a discounted registration rate, a dedicated line at the registration desk, and the ability to participate in annual elections and discussions about NANOG. ? Standard Registration now thru May 22, 2016 (member $500, non-member $525, student $100) ? Late Registration starting May 23, 2016 (member $575, non-member $600, student $100) ? On-Site Registration starting June 12, 2016 (member $650, non-member $675, student $100) The conference hotel is sold out on Sunday night. However, an additional NANOG Room block remains available at the Hard Rock Hotel. Both room blocks are set to expire very soon. Be sure to get your reservation made ASAP. We continue to seek and secure additional room nights, and will post the information on the NANOG 67 hotel meeting page. Should you have any questions regarding the Hackaton or NANOG 67, please direct them to nanog-support at nanog.org. If you are interested in sponsorship opportunities, please email sponsor-support at naong.org. I look forward to an exciting set of events in Chicago, and hope to see you there! Sincerely, Betty Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From marco at paesani.it Tue May 3 18:05:15 2016 From: marco at paesani.it (Marco Paesani) Date: Tue, 3 May 2016 20:05:15 +0200 Subject: NOC AS1836 green.ch AG Message-ID: Hi, I need direct contact with NOC of AS1836. Can you help me ? Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From marco at paesani.it Tue May 3 19:23:37 2016 From: marco at paesani.it (Marco Paesani) Date: Tue, 3 May 2016 21:23:37 +0200 Subject: NOC AS1836 green.ch AG In-Reply-To: <5728F0CA.3030102@nipper.de> References: <5728F0CA.3030102@nipper.de> Message-ID: Hi Arnold, nobody answer at 'peering at green.ch' for this reason I write here on NANOG. Ciao, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it 2016-05-03 20:41 GMT+02:00 Arnold Nipper : > On 03.05.2016 20:05, Marco Paesani wrote: > > > I need direct contact with NOC of AS1836. > > Can you help me ? > > Have a look at PeeringDB [0], Marco! > > > Ciao, Arnold > [0] https://peeringdb.com/net/232 > -- > Arnold Nipper > email: arnold at nipper.de phone: +49 6224 5593407 2 > mobile: +49 172 2650958 fax: +49 6224 5593407 9 > > From gustav.ulander at telecomputing.se Tue May 3 19:50:29 2016 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Tue, 3 May 2016 19:50:29 +0000 Subject: SV: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: Hello all. Yes I can confirm that we also had the issue with the asr1001s. For us the router was fine until we upgraded it. When we rebooted it after the upgrade it ran out of memory when populating 2 full feeds. When we contacted TAC they confirmed that indeed it was a memory problem and that we would need to add more memory to the box. Perhaps 1002 isnt as thirsty? //Gustav -----Ursprungligt meddelande----- Fr?n: NANOG [mailto:nanog-bounces at nanog.org] F?r William Herrin Skickat: den 3 maj 2016 18:13 Till: Eric Sabotta Kopia: NANOG list ?mne: Re: BGP peering strategies for smaller routers On Mon, May 2, 2016 at 10:35 PM, Eric Sabotta wrote: > I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I > got the real Cisco stuff for ~ $500). Before the router would crash > when loading the tables. Hi Eric, Something very fishy there because: > router1#show ip bgp summary > BGP using 296,835,018 total bytes of memory Commas added for clarity. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From baldur.norddahl at gmail.com Tue May 3 19:55:13 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 3 May 2016 21:55:13 +0200 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <5723C32A.1010008@foobar.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> <572361E4.2060608@foobar.org> <5723C32A.1010008@foobar.org> Message-ID: On 29 April 2016 at 22:25, Nick Hilliard wrote: > Baldur Norddahl wrote: > > With two uplinks that is highly unlikely to the point of being > impossible. > > There is no topology change upstream that can cause a situation where it > is > > not possible to do a high degree of aggregation of the full default free > > routing table before loading it in the FIB. > > which is why I qualified this in a previous posting: > > > The more paths you receive from different sources, the more likely it > > is that this list of 120k "superfluous" prefixes will converge > > towards zero. > > Agreed that small numbers of paths are most unlikely to create the > conditions for this problem to occur. > I agree that a larger number of peers makes the situation more complicated. It might warrant more studies. Your thesis is that there might be a problem, but mine is there likely is not. Let me argue why. We can consider networks of various sizes: 1) the dual homed network with full tables 2) the lightly peered ISP with more than two full tables 3) the well peered ISP 4) tier 1 backbone provider Each of those might experience different gain from the proposal and indeed it is likely that the backbone provider would not be interested in the solution no matter what. Even so the proposal could help deliver considerable cheaper hardware solutions to say #1 and #2 class providers. We already agree that the #1 class provider will not see an external event that can explode the number of needed FIB entries after compression. The #2 class provider is not much different. The number of routes he takes in as peering routes as opposed to transit are few. If he runs his network with proper max routes on every BGP session, there is nothing a free peer can do to wreck havok. Any entity with say max routes 50 can only break up a max of 50 of your optimized FIB entries and while that can cascade such a /16 breaks into a series of /17, /18, /19, ..., /24 that will never add up to anything that is a problem. In any case the real problem here will be a rogue peer injecting fake routes into your network. Can the more than two transit providers with full tables become a problem? No not really. These guys are all sending mostly the same routes to you and anything large happening will be reflected on all your transits. There is also the point about the weekly routing report: BGP routing table entries examined: 593320 Prefixes after maximum aggregation (per Origin AS): 217357 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290159 Now can you really say any one entity has the power to magically make all that aggregation disappear just so he can crash your network? I will put that in the "impossible" and "the net already crashed long before that" categories. There is a trend that some network are deaggregating their prefixes. Why not use software to aggregate that right back to what it ought to be before loading the routes into FIB? According to the above stat, that would save at least half the FIB memory and make some routers able to handle full tables for very much longer (possible forever). Regards, Baldur From hugge at nordu.net Tue May 3 20:18:00 2016 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 3 May 2016 22:18:00 +0200 Subject: NOC AS1836 green.ch AG In-Reply-To: References: <5728F0CA.3030102@nipper.de> Message-ID: <57290778.9080000@nordu.net> On 03/05/16 21:23, Marco Paesani wrote: > Hi Arnold, > nobody answer at 'peering at green.ch' for this reason I write here on NANOG. > Ciao, > > > Marco Paesani > > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it > Marco. As I've told you when you hunted me down the last time through backside channels.. :) When you don't get an answer on peering@ addresses its not because they don't read the emails. Instead of declining a peering-request formally people tend to just use the silent treatment and have that represent a "No". If you don't hear back - you probably don't fulfill the requirements to be eligible to peer with a network and for a big network with selective or restrictive policy, answering "no" to emails all day long isn't productive for anyone. This is one of MANY unwritten rules in the peering-world which can be hard to grasp at first. To understand the nomenclature and the "rules", going on a field trip to conferences such as NANOG, RIPE, EPF, GPF and the such is a great way to understand the game, so one can act accordingly to how the playfield looks like. -- hugge @ AS2603 From nick at foobar.org Tue May 3 20:31:42 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 03 May 2016 21:31:42 +0100 Subject: NOC AS1836 green.ch AG In-Reply-To: <57290778.9080000@nordu.net> References: <5728F0CA.3030102@nipper.de> <57290778.9080000@nordu.net> Message-ID: <57290AAE.9060804@foobar.org> Fredrik Korsb?ck wrote: > As I've told you when you hunted me down the last time through backside channels.. I can only hope you meant "back channels". Nick From bill at herrin.us Tue May 3 20:31:53 2016 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2016 16:31:53 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander wrote: > Yes I can confirm that we also had the issue with the asr1001s. > For us the router was fine until we upgraded it. When > we rebooted it after the upgrade it ran out of memory > when populating 2 full feeds. > When we contacted TAC they confirmed that indeed > it was a memory problem and that we would need to > add more memory to the box. Hi Gustav, IMO, you should not accept that answer from the TAC. An IOS release that crashes with two 600k BGP feeds in 4 gigs of RAM is badly defective. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nick at foobar.org Tue May 3 21:10:31 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 03 May 2016 22:10:31 +0100 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <572913C7.5070609@foobar.org> William Herrin wrote: > IMO, you should not accept that answer from the TAC. An IOS release > that crashes with two 600k BGP feeds in 4 gigs of RAM is badly > defective. I suspect the time the OP would spend raging down the phone would be better spent sourcing a third party memory upgrade to 8G or 16G. The upgrade would certainly be the cheaper option of the two, in addition to being the only option with a useful outcome. Nick From lukasz at bromirski.net Tue May 3 21:13:11 2016 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Tue, 3 May 2016 23:13:11 +0200 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> > On 03 May 2016, at 22:31, William Herrin wrote: > > On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander > wrote: >> Yes I can confirm that we also had the issue with the asr1001s. >> For us the router was fine until we upgraded it. When >> we rebooted it after the upgrade it ran out of memory >> when populating 2 full feeds. >> When we contacted TAC they confirmed that indeed >> it was a memory problem and that we would need to >> add more memory to the box. > > Hi Gustav, > > IMO, you should not accept that answer from the TAC. An IOS release > that crashes with two 600k BGP feeds in 4 gigs of RAM is badly > defective. Not necessarily. In essence, your physical memory gets halved in two after router boots up, then it may be further halved if you?re using features like SSO. So, with 4GB RAM config and with SSO running, you may be left with around 600-650MB free after boot and with IOS-XE loaded, and then all the features kick in. Including your BGP feeds that need around 300MB of memory just to store the tables, then there?s CEF RAM representation, and so on. Here?s a good WP w/r to memory usage & architecture on ASR 1k: http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html It actually contains the same recommendation given by TAC - with recent/current code if you want to run full tables with BGP, get 8GB of RAM on ASR 1k. In the 3.10-3.12S era I believe it was still possible to fit (without the SSO) full tables in RAM and be fine. As Nick just responded, it?s faster to source the RAM or modify the config to cut down on number of BGP prefixes rather than ping back and forth here discussing all the possibilities. -- ?ukasz Bromirski CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A From bill at herrin.us Tue May 3 21:53:37 2016 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2016 17:53:37 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> Message-ID: On Tue, May 3, 2016 at 5:13 PM, ?ukasz Bromirski wrote: > On 03 May 2016, at 22:31, William Herrin wrote: >> IMO, you should not accept that answer from the TAC. An IOS release >> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly >> defective. > > Not necessarily. > > In essence, your physical memory gets halved in two after > router boots up, then it may be further halved if you?re > using features like SSO. So, with 4GB RAM config and with > SSO running, you may be left with around 600-650MB free after > boot and with IOS-XE loaded, and then all the features kick > in. Including your BGP feeds that need around 300MB of memory > just to store the tables, then there?s CEF RAM representation, > and so on. > > Here?s a good WP w/r to memory usage & architecture on ASR 1k: > http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html Hi ?ukasz, You make some great points and that's an excellent document. > As Nick just responded, it?s faster to source the RAM or modify > the config to cut down on number of BGP prefixes rather than > ping back and forth here discussing all the possibilities. I respectfully disagree. Sourcing more ram won't fix the next bit of sloppiness with the software. Or the one after that. Once the manager of that team starts to accept poor code quality, the only thing with a chance of fixing it is strong customer push-back. And it is poor code quality. Even slicing and dicing the ram in odd ways, there's just no excuse for an order-of-magnitude increase in ram required to run the same algorithms on the same data. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nick at foobar.org Tue May 3 22:18:23 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 03 May 2016 23:18:23 +0100 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> Message-ID: <572923AF.8030303@foobar.org> William Herrin wrote: > I respectfully disagree. Sourcing more ram won't fix the next bit of > sloppiness with the software. Or the one after that. Once the manager > of that team starts to accept poor code quality, the only thing with a > chance of fixing it is strong customer push-back. You could feasibly argue that the box was shipped with too little RAM when it was released in 2008/2009. Alternatively, you could argue that 4G was fine way back then and that it's hardly surprising that it's too little now because the DFZ has grown from 220k prefixes to 620k. Anyway, this is all completely academic because the box is end-of-life and the chances of getting this problem fixed are zero. So there is simply no point in berating some poor TAC representative about this problem, end of story. The replacement box (ASR1001-X) has 8G ram. That's fine for today. In 8 years, it probably won't be fine. > And it is poor code quality. Even slicing and dicing the ram in odd > ways, there's just no excuse for an order-of-magnitude increase in ram > required to run the same algorithms on the same data. If RAM were expensive, your argument would make sense, but RAM is not expensive. I don't really think it's any more viable to complain about an 8yo end-of-life box being ill equipped to handle today's Internet than it is to complain about the fact that you can't run a desktop operating system on a computer with 8 megs of ram, like you used to be able to. Truth is, 8 megs of RAM then was more expensive than 8 gigs of RAM these days. Can we move on now? Nick From blake at ispn.net Tue May 3 22:23:42 2016 From: blake at ispn.net (Blake Hudson) Date: Tue, 3 May 2016 17:23:42 -0500 Subject: BGP peering strategies for smaller routers In-Reply-To: <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> Message-ID: <572924EE.2020606@ispn.net> ?ukasz Bromirski wrote on 5/3/2016 4:13 PM: >> On 03 May 2016, at 22:31, William Herrin wrote: >> >> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander >> wrote: >>> Yes I can confirm that we also had the issue with the asr1001s. >>> For us the router was fine until we upgraded it. When >>> we rebooted it after the upgrade it ran out of memory >>> when populating 2 full feeds. >>> When we contacted TAC they confirmed that indeed >>> it was a memory problem and that we would need to >>> add more memory to the box. >> Hi Gustav, >> >> IMO, you should not accept that answer from the TAC. An IOS release >> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly >> defective. > Not necessarily. > > In essence, your physical memory gets halved in two after > router boots up, then it may be further halved if you?re > using features like SSO. So, with 4GB RAM config and with > SSO running, you may be left with around 600-650MB free after > boot and with IOS-XE loaded, and then all the features kick > in. Including your BGP feeds that need around 300MB of memory > just to store the tables, then there?s CEF RAM representation, > and so on. > > Here?s a good WP w/r to memory usage & architecture on ASR 1k: > http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html > > It actually contains the same recommendation given by TAC - > with recent/current code if you want to run full tables with > BGP, get 8GB of RAM on ASR 1k. In the 3.10-3.12S era I believe > it was still possible to fit (without the SSO) full tables > in RAM and be fine. > > As Nick just responded, it?s faster to source the RAM or modify > the config to cut down on number of BGP prefixes rather than > ping back and forth here discussing all the possibilities. > I feel like you're trying to fit some other (possible, but far fetched) scenario from where we started. Mike, the op, said he has a 1002 which has an RP1 configured with 4GB of RAM. First, this is not a 1001. Second, SSO is off by default and is unlikely to be configured on an ASR1002 (the op certainly never stated he had enabled it). I just checked a few ASR 1k RP1s I have access to and the 3.10 IOS image has similar memory usage to the 3.13 (the latest MD release for this platform). On the RP1 platform, with a default only BGP feed, the systems have ~ 1.3GB of proc mem available. With a single full IP4 BGP feed, the free proc mem goes down to ~850MB. With two full feeds, the proc mem goes down to ~ 800MB. RP memory goes from ~1.8GB used (default only), ~2.7GB used (1x full), ~2.8GB used (2x full). This still leaves over 1GB of free RP memory with two full BGP feeds. The amount of FIB is dependent on the ESP installed by the OP; Mike hasn't yet stated what ESP he has installed. So yes, the 1002 can, and will continue to, work with two full BGP feeds when fitted with an ESP10. From carlos at race.com Tue May 3 23:02:05 2016 From: carlos at race.com (Carlos Alcantar) Date: Tue, 3 May 2016 23:02:05 +0000 Subject: BGP peering strategies for smaller routers In-Reply-To: <572924EE.2020606@ispn.net> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net>, <572924EE.2020606@ispn.net> Message-ID: I know this thread has been primarily about memory to hold the routing tables, but how well does it do with the BGP convergence time?? which could be the other killer with multiple full route tables. ? Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com ________________________________________ From: NANOG on behalf of Blake Hudson Sent: Tuesday, May 3, 2016 3:23:42 PM To: nanog at nanog.org Subject: Re: BGP peering strategies for smaller routers ?ukasz Bromirski wrote on 5/3/2016 4:13 PM: >> On 03 May 2016, at 22:31, William Herrin wrote: >> >> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander >> wrote: >>> Yes I can confirm that we also had the issue with the asr1001s. >>> For us the router was fine until we upgraded it. When >>> we rebooted it after the upgrade it ran out of memory >>> when populating 2 full feeds. >>> When we contacted TAC they confirmed that indeed >>> it was a memory problem and that we would need to >>> add more memory to the box. >> Hi Gustav, >> >> IMO, you should not accept that answer from the TAC. An IOS release >> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly >> defective. > Not necessarily. > > In essence, your physical memory gets halved in two after > router boots up, then it may be further halved if you?re > using features like SSO. So, with 4GB RAM config and with > SSO running, you may be left with around 600-650MB free after > boot and with IOS-XE loaded, and then all the features kick > in. Including your BGP feeds that need around 300MB of memory > just to store the tables, then there?s CEF RAM representation, > and so on. > > Here?s a good WP w/r to memory usage & architecture on ASR 1k: > http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html > > It actually contains the same recommendation given by TAC - > with recent/current code if you want to run full tables with > BGP, get 8GB of RAM on ASR 1k. In the 3.10-3.12S era I believe > it was still possible to fit (without the SSO) full tables > in RAM and be fine. > > As Nick just responded, it?s faster to source the RAM or modify > the config to cut down on number of BGP prefixes rather than > ping back and forth here discussing all the possibilities. > I feel like you're trying to fit some other (possible, but far fetched) scenario from where we started. Mike, the op, said he has a 1002 which has an RP1 configured with 4GB of RAM. First, this is not a 1001. Second, SSO is off by default and is unlikely to be configured on an ASR1002 (the op certainly never stated he had enabled it). I just checked a few ASR 1k RP1s I have access to and the 3.10 IOS image has similar memory usage to the 3.13 (the latest MD release for this platform). On the RP1 platform, with a default only BGP feed, the systems have ~ 1.3GB of proc mem available. With a single full IP4 BGP feed, the free proc mem goes down to ~850MB. With two full feeds, the proc mem goes down to ~ 800MB. RP memory goes from ~1.8GB used (default only), ~2.7GB used (1x full), ~2.8GB used (2x full). This still leaves over 1GB of free RP memory with two full BGP feeds. The amount of FIB is dependent on the ESP installed by the OP; Mike hasn't yet stated what ESP he has installed. So yes, the 1002 can, and will continue to, work with two full BGP feeds when fitted with an ESP10. From lukasz at bromirski.net Tue May 3 23:08:20 2016 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Wed, 4 May 2016 01:08:20 +0200 Subject: BGP peering strategies for smaller routers In-Reply-To: <572924EE.2020606@ispn.net> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> <572924EE.2020606@ispn.net> Message-ID: Blake, > On 04 May 2016, at 00:23, Blake Hudson wrote: > > ?ukasz Bromirski wrote on 5/3/2016 4:13 PM: >>> On 03 May 2016, at 22:31, William Herrin wrote: >>> >>> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander >>> wrote: >>>> Yes I can confirm that we also had the issue with the asr1001s. [...] > I feel like you're trying to fit some other (possible, but far fetched) scenario from where we started. Yeah, sorry for that - saw 1001 in quote and kept that as original platform. For 1002 with SSO off you may be fine, sure. BTW, the versions you're quoting as working were also quoted by me as the ones that could have been OK even on the 1001 (I know, I know). -- ?ukasz Bromirski CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A From bill at herrin.us Tue May 3 23:18:35 2016 From: bill at herrin.us (William Herrin) Date: Tue, 3 May 2016 19:18:35 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: <572923AF.8030303@foobar.org> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> <572923AF.8030303@foobar.org> Message-ID: On Tue, May 3, 2016 at 6:18 PM, Nick Hilliard wrote: > William Herrin wrote: >> And it is poor code quality. Even slicing and dicing the ram in odd >> ways, there's just no excuse for an order-of-magnitude increase in ram >> required to run the same algorithms on the same data. > > If RAM were expensive, your argument would make sense, but RAM is not > expensive. Hi Nick, You missed the point. Sloppy memory management is a "canary in a coal mine." It's a user-visible symptom that reflects poor code quality underneath. Programmers who don't care how much ram they're consuming are the same fools who catch and then ignore exceptions, don't bother evaluating the big-oh running time of their algorithms (often have no idea what that is) and engage in a variety of other bad practices that you as the customer suffer for but never directly see. It's not the cost of the ram, it's the attitude that ram is cheap so I won't care. It's a bad attitude, a dangerous attitude when found in a computer programmer. One which consistently leads to failure. If you challenge poor code quality when you spot it, your vendor might correct course. If you let it slide then by the time the code base is damaged enough for the pointy-hairs to understand there's a problem on their own, your only real choice will be to switch to a different product or vendor. > Can we move on now? Sure, why not. I've proselytized enough for one day. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From arnold at nipper.de Tue May 3 18:41:14 2016 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 3 May 2016 20:41:14 +0200 Subject: NOC AS1836 green.ch AG In-Reply-To: References: Message-ID: <5728F0CA.3030102@nipper.de> On 03.05.2016 20:05, Marco Paesani wrote: > I need direct contact with NOC of AS1836. > Can you help me ? Have a look at PeeringDB [0], Marco! Ciao, Arnold [0] https://peeringdb.com/net/232 -- Arnold Nipper email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From blake at ispn.net Wed May 4 01:57:07 2016 From: blake at ispn.net (Blake Hudson) Date: Tue, 3 May 2016 20:57:07 -0500 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> <572924EE.2020606@ispn.net> Message-ID: <58903185-1FD0-47AB-B9A0-406D0240C663@ispn.net> I turned up a full ip4 feed on an RP1 today. Took approximately 5 minutes to fill the rib and probably another 5 minutes to push to the fib. The CLI responsiveness was noticeably slowed during this process, but the router didn't drop traffic. I'm guessing a second feed would involve fewer rib and fib changes and would converge faster. > On May 3, 2016, at 6:02 PM, Carlos Alcantar wrote: > > I know this thread has been primarily about memory to hold the routing tables, but how well does it do with the BGP convergence time?? which could be the other killer with multiple full route tables. > From gustav.ulander at telecomputing.se Wed May 4 05:47:21 2016 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Wed, 4 May 2016 05:47:21 +0000 Subject: SV: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> Message-ID: Hello. Yea its a bit strange that we would need to add memory to the platform just because we upgraded the image. But since we were in kind of a tight spot we opted to upgrade it and then move away from the platform in that role. //Gustav -----Ursprungligt meddelande----- Fr?n: William Herrin [mailto:bill at herrin.us] Skickat: den 3 maj 2016 22:32 Till: Gustav Ulander Kopia: Eric Sabotta ; NANOG list ?mne: Re: BGP peering strategies for smaller routers On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander wrote: > Yes I can confirm that we also had the issue with the asr1001s. > For us the router was fine until we upgraded it. When we rebooted it > after the upgrade it ran out of memory when populating 2 full feeds. > When we contacted TAC they confirmed that indeed it was a memory > problem and that we would need to add more memory to the box. Hi Gustav, IMO, you should not accept that answer from the TAC. An IOS release that crashes with two 600k BGP feeds in 4 gigs of RAM is badly defective. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From chuckchurch at gmail.com Wed May 4 17:14:30 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 4 May 2016 13:14:30 -0400 Subject: BGP peering strategies for smaller routers In-Reply-To: References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> <572923AF.8030303@foobar.org> Message-ID: <010b01d1a628$6ed01b90$4c7052b0$@gmail.com> ---------------------------------------------------------------------------------------------------------------------- Hi Nick, >You missed the point. Sloppy memory management is a "canary in a coal mine." It's a user-visible symptom that reflects poor code quality underneath. Programmers who >don't care how much ram they're consuming are the same fools who catch and then ignore exceptions, don't bother evaluating the big-oh running time of their algorithms >(often have no idea what that is) and engage in a variety of other bad practices that you as the customer suffer for but never directly see. That Cisco URL covering ASR1K memory details did mention that due to 64 bit, everything does use more memory. http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html My biggest beef is that right off the bat, IOSd process only gets half the physical RAM. I'm not sure of that reasoning. Maybe to support ISSU with SW redundancy? Would be nice to be able to disable or tune that. I'm not sure what else that memory would be reserved for. It doesn't seem right that 2 full feeds works fine on an ISR with 768MB RAM, yet doesn't work on a 1K with 4 gigs of RAM. Chuck From javier at advancedmachines.us Wed May 4 20:37:23 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 4 May 2016 16:37:23 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. Message-ID: Anyone know what is going on, nothing in the English speaking media (not surprised) but reports are that a million + people on ATT in the metro area are without service for 8+ hours now. Only reports I have seen are on local media and social media. Any information is appreciated. If there is a better mailing list please let me know. - Javier From woody at pch.net Wed May 4 20:57:02 2016 From: woody at pch.net (Bill Woodcock) Date: Wed, 4 May 2016 16:57:02 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: Message-ID: > On May 4, 2016, at 4:37 PM, Javier J wrote: > > If there is a better mailing list please let me know. outages at outages.org -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From javier at advancedmachines.us Wed May 4 21:03:43 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 4 May 2016 17:03:43 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: Message-ID: Submitted. Here is the only news story I found in English: http://cb.pr/att-network-down-in-puerto-rico/ On Wed, May 4, 2016 at 4:57 PM, Bill Woodcock wrote: > > > On May 4, 2016, at 4:37 PM, Javier J wrote: > > > > If there is a better mailing list please let me know. > > outages at outages.org > > -Bill > > > > > From applebaumt at ochin.org Wed May 4 21:22:00 2016 From: applebaumt at ochin.org (Tyler Applebaum) Date: Wed, 4 May 2016 21:22:00 +0000 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: Message-ID: <25440C4BF31A8E44872003195DEB57BE054E6FA0@omail1.community-health.org> Maybe they didn't pay their bill! (kidding...) http://money.cnn.com/2016/05/02/investing/puerto-rico-default-may-1/ -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J Sent: Wednesday, May 4, 2016 1:37 PM To: nanog at nanog.org Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. Anyone know what is going on, nothing in the English speaking media (not surprised) but reports are that a million + people on ATT in the metro area are without service for 8+ hours now. Only reports I have seen are on local media and social media. Any information is appreciated. If there is a better mailing list please let me know. - Javier Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compliance at ochin.org, delete this email and destroy all copies. From blake at ispn.net Wed May 4 21:29:17 2016 From: blake at ispn.net (Blake Hudson) Date: Wed, 4 May 2016 16:29:17 -0500 Subject: BGP peering strategies for smaller routers In-Reply-To: <010b01d1a628$6ed01b90$4c7052b0$@gmail.com> References: <5727A554.1090202@tiedyenetworks.com> <8A90115C-7B89-443D-9E80-9E49AA6DEF3D@bromirski.net> <572923AF.8030303@foobar.org> <010b01d1a628$6ed01b90$4c7052b0$@gmail.com> Message-ID: <572A69AD.7070108@ispn.net> Chuck Church wrote on 5/4/2016 12:14 PM: > ---------------------------------------------------------------------------------------------------------------------- > Hi Nick, > >> You missed the point. Sloppy memory management is a "canary in a coal mine." It's a user-visible symptom that reflects poor code quality underneath. Programmers who >don't care how much ram they're consuming are the same fools who catch and then ignore exceptions, don't bother evaluating the big-oh running time of their algorithms >(often have no idea what that is) and engage in a variety of other bad practices that you as the customer suffer for but never directly see. > > That Cisco URL covering ASR1K memory details did mention that due to 64 bit, everything does use more memory. > http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html > My biggest beef is that right off the bat, IOSd process only gets half the physical RAM. I'm not sure of that reasoning. Maybe to support ISSU with SW redundancy? Would be nice to be able to disable or tune that. I'm not sure what else that memory would be reserved for. It doesn't seem right that 2 full feeds works fine on an ISR with 768MB RAM, yet doesn't work on a 1K with 4 gigs of RAM. > > Chuck > Given that the IOSd process runs under 32bit Linux (on the RP1), the 2GB allocation is probably a reflection of the max that Cisco could allocate to a single process in user space. The other 2GB (in a 4GB system) gets used, just not by the IOSd process. On the 8GB and 16GB versions of the RP2, I'm not sure why you'd maintain the 50/50 split. Perhaps it's not quite as simple as the document lets on. From javier at advancedmachines.us Wed May 4 21:44:16 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 4 May 2016 17:44:16 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: <25440C4BF31A8E44872003195DEB57BE054E6FA0@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BE054E6FA0@omail1.community-health.org> Message-ID: Haha, wouldn't be surprised if it had something to do with some government owned infrastructure crashing on a fiber. Just got my first call of the day from someone there. Looks like it's starting to come back. I'm still curious what exactly died. I saw hardware mentioned, but you could get a plane from Miami there in 2 hours if it was a matter of just swapping out a piece of network gear. On May 4, 2016 5:22 PM, "Tyler Applebaum" wrote: > Maybe they didn't pay their bill! (kidding...) > > http://money.cnn.com/2016/05/02/investing/puerto-rico-default-may-1/ > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J > Sent: Wednesday, May 4, 2016 1:37 PM > To: nanog at nanog.org > Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. > > Anyone know what is going on, nothing in the English speaking media (not > surprised) > > but reports are that a million + people on ATT in the metro area are > without service for 8+ hours now. > > > Only reports I have seen are on local media and social media. > > > Any information is appreciated. If there is a better mailing list please > let me know. > > - Javier > Attention: Information contained in this message and or attachments is > intended only for the recipient(s) named above and may contain confidential > and or privileged material that is protected under State or Federal law. If > you are not the intended recipient, any disclosure, copying, distribution > or action taken on it is prohibited. If you believe you have received this > email in error, please contact the sender with a copy to > compliance at ochin.org, delete this email and destroy all copies. > From toddunder at gmail.com Wed May 4 22:29:35 2016 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 4 May 2016 18:29:35 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: <25440C4BF31A8E44872003195DEB57BE054E6FA0@omail1.community-health.org> Message-ID: http://www.univision.com/noticias/comunicacion/cerca-de-un-millon-de-abonados-de-at-t-sin-servicio-en-el-pais-debido-a-averia for spanish speakers. they say it's a "hardware" issue that caused the fault. the story has almost no other facts in it about the RFO. there. i just read it for you. :-) t On Wed, May 4, 2016 at 5:44 PM, Javier J wrote: > Haha, wouldn't be surprised if it had something to do with some government > owned infrastructure crashing on a fiber. > > Just got my first call of the day from someone there. Looks like it's > starting to come back. > > I'm still curious what exactly died. > > I saw hardware mentioned, but you could get a plane from Miami there in 2 > hours if it was a matter of just swapping out a piece of network gear. > On May 4, 2016 5:22 PM, "Tyler Applebaum" wrote: > >> Maybe they didn't pay their bill! (kidding...) >> >> http://money.cnn.com/2016/05/02/investing/puerto-rico-default-may-1/ >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J >> Sent: Wednesday, May 4, 2016 1:37 PM >> To: nanog at nanog.org >> Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. >> >> Anyone know what is going on, nothing in the English speaking media (not >> surprised) >> >> but reports are that a million + people on ATT in the metro area are >> without service for 8+ hours now. >> >> >> Only reports I have seen are on local media and social media. >> >> >> Any information is appreciated. If there is a better mailing list please >> let me know. >> >> - Javier >> Attention: Information contained in this message and or attachments is >> intended only for the recipient(s) named above and may contain confidential >> and or privileged material that is protected under State or Federal law. If >> you are not the intended recipient, any disclosure, copying, distribution >> or action taken on it is prohibited. If you believe you have received this >> email in error, please contact the sender with a copy to >> compliance at ochin.org, delete this email and destroy all copies. >> From javier at advancedmachines.us Wed May 4 23:45:30 2016 From: javier at advancedmachines.us (Javier J) Date: Wed, 4 May 2016 19:45:30 -0400 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: <25440C4BF31A8E44872003195DEB57BE054E6FA0@omail1.community-health.org> Message-ID: Thanks Todd, I got only the "hardware" info as well. I would assume it was something more serious than just a simple "hardware" issue. On Wed, May 4, 2016 at 6:29 PM, Todd Underwood wrote: > > http://www.univision.com/noticias/comunicacion/cerca-de-un-millon-de-abonados-de-at-t-sin-servicio-en-el-pais-debido-a-averia > > for spanish speakers. > > they say it's a "hardware" issue that caused the fault. the story has > almost no other facts in it about the RFO. there. i just read it for > you. > > :-) > > t > > On Wed, May 4, 2016 at 5:44 PM, Javier J > wrote: > > Haha, wouldn't be surprised if it had something to do with some > government > > owned infrastructure crashing on a fiber. > > > > Just got my first call of the day from someone there. Looks like it's > > starting to come back. > > > > I'm still curious what exactly died. > > > > I saw hardware mentioned, but you could get a plane from Miami there in 2 > > hours if it was a matter of just swapping out a piece of network gear. > > On May 4, 2016 5:22 PM, "Tyler Applebaum" wrote: > > > >> Maybe they didn't pay their bill! (kidding...) > >> > >> http://money.cnn.com/2016/05/02/investing/puerto-rico-default-may-1/ > >> > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J > >> Sent: Wednesday, May 4, 2016 1:37 PM > >> To: nanog at nanog.org > >> Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. > >> > >> Anyone know what is going on, nothing in the English speaking media (not > >> surprised) > >> > >> but reports are that a million + people on ATT in the metro area are > >> without service for 8+ hours now. > >> > >> > >> Only reports I have seen are on local media and social media. > >> > >> > >> Any information is appreciated. If there is a better mailing list > please > >> let me know. > >> > >> - Javier > >> Attention: Information contained in this message and or attachments is > >> intended only for the recipient(s) named above and may contain > confidential > >> and or privileged material that is protected under State or Federal > law. If > >> you are not the intended recipient, any disclosure, copying, > distribution > >> or action taken on it is prohibited. If you believe you have received > this > >> email in error, please contact the sender with a copy to > >> compliance at ochin.org, delete this email and destroy all copies. > >> > From cb.list6 at gmail.com Thu May 5 13:05:59 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 5 May 2016 06:05:59 -0700 Subject: Netnod RD announcing misoriginate routes Message-ID: I have contacted noc@ and peering contacts for Netnod and Mainloop AS43893 24 hours ago, but no response or remediation If you have a contact, please ask tell to stop originating and announcing space 172.32.x.x space that belongs to 21928 It would also be good if they responded to me yesterday or had bgp filters Thanks! From cb.list6 at gmail.com Thu May 5 13:58:28 2016 From: cb.list6 at gmail.com (Ca By) Date: Thu, 5 May 2016 06:58:28 -0700 Subject: Netnod RD announcing misoriginate routes In-Reply-To: References: Message-ID: On Thursday, May 5, 2016, Ca By wrote: > I have contacted noc@ and peering contacts for Netnod and Mainloop > AS43893 24 hours ago, but no response or remediation > > If you have a contact, please ask tell to stop originating and announcing > space 172.32.x.x space that belongs to 21928 > > It would also be good if they responded to me yesterday or had bgp filters > > Thanks! > All fixed, thanks Internet! But, really should have bgp filters, it's dangerous out there From bedard.phil at gmail.com Thu May 5 14:28:55 2016 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 05 May 2016 10:28:55 -0400 Subject: Patch panel solutions for 4x10GE breakout Message-ID: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE breakouts to deliver 10G. We are not wiring these up to things in the same rack, they will be going to patch panels and then elsewhere in a facility. It could potentially get messy with the panels we have today so we are looking at other solutions. These are all SM LR connections using LC. There are a lot of SM MTP to LC options since that?s the way most panels are wired, but they typically have 6 duplex LC connectors per MTP and not 4 which isn?t very efficient in this use case. I?ve seen others just use an intermediate LC to LC panel and just wire the breakouts to those and then jumper the other side elsewhere. Anything else others have used? The point of the solution is to keep the wiring mess in front of or near the device to a minimum. Thanks, Phil From jared at puck.nether.net Thu May 5 14:45:58 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 5 May 2016 10:45:58 -0400 Subject: Patch panel solutions for 4x10GE breakout In-Reply-To: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> References: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> Message-ID: <12672D4F-3AC1-4D89-A2A1-19AFD7D924F3@puck.nether.net> There is a nice Corning panel our facilities team is using now. I can find the link and send it to the list when not at my phone. Jared Mauch > On May 5, 2016, at 10:28 AM, Phil Bedard wrote: > > So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE breakouts to deliver 10G. We are not wiring these up to things in the same rack, they will be going to patch panels and then elsewhere in a facility. It could potentially get messy with the panels we have today so we are looking at other solutions. These are all SM LR connections using LC. There are a lot of SM MTP to LC options since that?s the way most panels are wired, but they typically have 6 duplex LC connectors per MTP and not 4 which isn?t very efficient in this use case. I?ve seen others just use an intermediate LC to LC panel and just wire the breakouts to those and then jumper the other side elsewhere. > > Anything else others have used? The point of the solution is to keep the wiring mess in front of or near the device to a minimum. > > Thanks, > > Phil > From Daniel.Jameson at tdstelecom.com Thu May 5 15:17:31 2016 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 5 May 2016 15:17:31 +0000 Subject: Patch panel solutions for 4x10GE breakout In-Reply-To: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> References: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> Message-ID: Might be worth having a look at the Corning centrix modules. Very high densities. 72 terminations per u. Front side mpo/mtp connections. Have some great slack storage and management options. ________________________________ From: NANOG on behalf of Phil Bedard Sent: Thursday, May 05, 2016 9:28:55 AM To: nanog at nanog.org Subject: Patch panel solutions for 4x10GE breakout So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE breakouts to deliver 10G. We are not wiring these up to things in the same rack, they will be going to patch panels and then elsewhere in a facility. It could potentially get messy with the panels we have today so we are looking at other solutions. These are all SM LR connections using LC. There are a lot of SM MTP to LC options since that?s the way most panels are wired, but they typically have 6 duplex LC connectors per MTP and not 4 which isn?t very efficient in this use case. I?ve seen others just use an intermediate LC to LC panel and just wire the breakouts to those and then jumper the other side elsewhere. Anything else others have used? The point of the solution is to keep the wiring mess in front of or near the device to a minimum. Thanks, Phil From math at sizone.org Thu May 5 17:53:48 2016 From: math at sizone.org (Ken Chase) Date: Thu, 5 May 2016 13:53:48 -0400 Subject: sub $500-750 CPE firewall for voip-centric application Message-ID: <20160505175348.GU19521@sizone.org> Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). We'd like a bit of diagnostic capability (say tcpdump or the like, via shell preferred) - I realize a PFsense unit would be great, but might not have enough brand name recognition to make the master client happy plopping down as a CPE at end client sites. (I know, "there's only one brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get irritating for end customers.) /kc -- Ken Chase - Guelph Canada From nanog-amuse at foofus.com Thu May 5 18:11:54 2016 From: nanog-amuse at foofus.com (amuse) Date: Thu, 5 May 2016 11:11:54 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: What PFSense currently lacks in brand name recognition, they can make up with by the fact that they offer paid support at very affordable levels. I'd go with https://store.pfsense.org/SG-2440/ ($499 each) and a quote for professional services ( https://store.pfsense.org/Professional-Services.aspx ) to back that up. On Thu, May 5, 2016 at 10:53 AM, Ken Chase wrote: > Looking around at different SMB firewalls to standardize on so we can start > training up our level 2/3 techs instead of dealing with a mess of > different vendors > at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, > wondering > what your experiences are. Need something cheap enough (certainly <$1k, > <$500-750 better) > that we are comfortable telling endpoints to toss current gear/buy > additional gear. > > Basic firewalling of course is covered, but also need port range forwarding > (not available until later ASA versions for eg was an issue), QoS > (port/flow > based as well as possibly actually talking some real QoS protocols) and VPN > capabilities (not sure if many do without #seats licensing schemes which > get > irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > shell > preferred) - I realize a PFsense unit would be great, but might not have > enough brand name recognition to make the master client happy plopping > down as > a CPE at end client sites. (I know, "there's only one brand, Cisco." > ASA5506x is a > bit $$ and licensing acrobatics get irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada > From ray at orsiniit.com Thu May 5 18:16:27 2016 From: ray at orsiniit.com (Ray Orsini) Date: Thu, 5 May 2016 14:16:27 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: We deploy SonicWALL TZ300 or SOHO using Dell's Security as a Service. That way our monthly cost per customer is under $50 and includes all security services plus GMS centralized management. Works great with our VOIP service. Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: Thursday, May 5, 2016 1:54 PM To: nanog at nanog.org Subject: sub $500-750 CPE firewall for voip-centric application Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). We'd like a bit of diagnostic capability (say tcpdump or the like, via shell preferred) - I realize a PFsense unit would be great, but might not have enough brand name recognition to make the master client happy plopping down as a CPE at end client sites. (I know, "there's only one brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get irritating for end customers.) /kc -- Ken Chase - Guelph Canada From nellermann at broadaspect.com Thu May 5 18:39:30 2016 From: nellermann at broadaspect.com (Nick Ellermann) Date: Thu, 5 May 2016 18:39:30 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: We have a lot of luck for smaller VOIP customers having all of their services run through a FortiGate 60D, or higher models. 60D is our go to solution for small enterprise. However, if we are the network carrier for a particular customer and they have a voip deployment of more than about 15 phones, then we deploy a dedicated voice edge gateway, which is more about voice support and handset management than anything. You do need to disable a couple of things on the FortiGate such as SIP Session Helper and ALG. We never have voice termination, origination or call quality issues because of the firewall. FortiGate has a lot of advanced features as well as fine tuning and adjustment capabilities for the network engineering type and is still easy enough for our entry level techs to support. Most of our customers have heavy VPN requirements and FortiGates have great IPsec performance. We leverage a lot of the network security features and have built a successful managed firewall service with good monitoring and analytics using a third-party monitoring platform and Fortinet's FortiAnaylzer platform. Worth looking at, if you haven't already. If you want to private message me, happy to give more info. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect ? E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 ? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: Thursday, May 05, 2016 1:54 PM To: nanog at nanog.org Subject: sub $500-750 CPE firewall for voip-centric application Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). We'd like a bit of diagnostic capability (say tcpdump or the like, via shell preferred) - I realize a PFsense unit would be great, but might not have enough brand name recognition to make the master client happy plopping down as a CPE at end client sites. (I know, "there's only one brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get irritating for end customers.) /kc -- Ken Chase - Guelph Canada From mel at beckman.org Thu May 5 18:48:40 2016 From: mel at beckman.org (Mel Beckman) Date: Thu, 5 May 2016 18:48:40 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> Message-ID: <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto firewalls. The best SMB devices are definitely SonicWall and Fortigate. SonicWalls are easier to configure, but have fewer features. Fortigate has many knobs and dials and a very powerful virtual router facility that can do amazing things. The two vendors have equivalent support in my opinion, although Fortigate tends to be more personal (Dell is big and you get random techs). Cisco ASA is overpriced and under-featured. Cisco-only shops like them, but mostly I think because they?re Cisco-only. PaloAlto is expensive for what you get. Functionally they are on the same level as Fortigate, with a slightly more elegant GUI. But Fortigate can be configured via a USB cable, which is a huge advantage in the field. Legacy RS-232 serial ports are error-prone and slow. -mel > On May 5, 2016, at 11:39 AM, Nick Ellermann wrote: > > We have a lot of luck for smaller VOIP customers having all of their services run through a FortiGate 60D, or higher models. 60D is our go to solution for small enterprise. However, if we are the network carrier for a particular customer and they have a voip deployment of more than about 15 phones, then we deploy a dedicated voice edge gateway, which is more about voice support and handset management than anything. You do need to disable a couple of things on the FortiGate such as SIP Session Helper and ALG. We never have voice termination, origination or call quality issues because of the firewall. > FortiGate has a lot of advanced features as well as fine tuning and adjustment capabilities for the network engineering type and is still easy enough for our entry level techs to support. Most of our customers have heavy VPN requirements and FortiGates have great IPsec performance. We leverage a lot of the network security features and have built a successful managed firewall service with good monitoring and analytics using a third-party monitoring platform and Fortinet's FortiAnaylzer platform. > > Worth looking at, if you haven't already. If you want to private message me, happy to give more info. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services > BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: Thursday, May 05, 2016 1:54 PM > To: nanog at nanog.org > Subject: sub $500-750 CPE firewall for voip-centric application > > Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. > > Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via shell > preferred) - I realize a PFsense unit would be great, but might not have enough brand name recognition to make the master client happy plopping down as a CPE at end client sites. (I know, "there's only one brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada From nellermann at broadaspect.com Thu May 5 18:51:08 2016 From: nellermann at broadaspect.com (Nick Ellermann) Date: Thu, 5 May 2016 18:51:08 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> References: <20160505175348.GU19521@sizone.org> <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> Message-ID: <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> Your exactly right, Mel. Dell has really turned the Sonicwall platform around in the past few year. We dropped it a year or two before Dell took them over. Back then Sonicwall was full of issues and lacked important features that our enterprise customers required. If you have budget, Palo Alto is something to look at as well, but don't overlook Sonicwall and FortiGate. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect ? E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 ? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: Mel Beckman [mailto:mel at beckman.org] Sent: Thursday, May 05, 2016 2:49 PM To: Nick Ellermann Cc: Ken Chase ; nanog at nanog.org Subject: Re: sub $500-750 CPE firewall for voip-centric application I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto firewalls. The best SMB devices are definitely SonicWall and Fortigate. SonicWalls are easier to configure, but have fewer features. Fortigate has many knobs and dials and a very powerful virtual router facility that can do amazing things. The two vendors have equivalent support in my opinion, although Fortigate tends to be more personal (Dell is big and you get random techs). Cisco ASA is overpriced and under-featured. Cisco-only shops like them, but mostly I think because they're Cisco-only. PaloAlto is expensive for what you get. Functionally they are on the same level as Fortigate, with a slightly more elegant GUI. But Fortigate can be configured via a USB cable, which is a huge advantage in the field. Legacy RS-232 serial ports are error-prone and slow. -mel > On May 5, 2016, at 11:39 AM, Nick Ellermann wrote: > > We have a lot of luck for smaller VOIP customers having all of their services run through a FortiGate 60D, or higher models. 60D is our go to solution for small enterprise. However, if we are the network carrier for a particular customer and they have a voip deployment of more than about 15 phones, then we deploy a dedicated voice edge gateway, which is more about voice support and handset management than anything. You do need to disable a couple of things on the FortiGate such as SIP Session Helper and ALG. We never have voice termination, origination or call quality issues because of the firewall. > FortiGate has a lot of advanced features as well as fine tuning and adjustment capabilities for the network engineering type and is still easy enough for our entry level techs to support. Most of our customers have heavy VPN requirements and FortiGates have great IPsec performance. We leverage a lot of the network security features and have built a successful managed firewall service with good monitoring and analytics using a third-party monitoring platform and Fortinet's FortiAnaylzer platform. > > Worth looking at, if you haven't already. If you want to private message me, happy to give more info. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: Thursday, May 05, 2016 1:54 PM > To: nanog at nanog.org > Subject: sub $500-750 CPE firewall for voip-centric application > > Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. > > Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > shell > preferred) - I realize a PFsense unit would be great, but might not > have enough brand name recognition to make the master client happy > plopping down as a CPE at end client sites. (I know, "there's only one > brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get > irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada From mlfreita at mtu.edu Thu May 5 19:09:43 2016 From: mlfreita at mtu.edu (Matt Freitag) Date: Thu, 5 May 2016 15:09:43 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> References: <20160505175348.GU19521@sizone.org> <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> Message-ID: <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> I'm a huge fan of Juniper's SRX line. I use all the features you point out at home on my SRX210, although that product is end-of-life. A refurbished SRX220 lists on Amazon for about $375, and a new one for $700. Naturally support is extra, but I'm not sure how much. I haven't used it myself but I have seen the packet capture in action. It'll save any traffic you want right out to a pcap file too. I also like "show security flow session" - shows you the source, destination, ports, how long a session has been going, and number of packets and number of bytes transferred. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 http://www.mtu.edu/ http://www.it.mtu.edu/ -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Ellermann Sent: Thursday, May 5, 2016 2:51 PM To: Mel Beckman Cc: nanog at nanog.org Subject: RE: sub $500-750 CPE firewall for voip-centric application Your exactly right, Mel. Dell has really turned the Sonicwall platform around in the past few year. We dropped it a year or two before Dell took them over. Back then Sonicwall was full of issues and lacked important features that our enterprise customers required. If you have budget, Palo Alto is something to look at as well, but don't overlook Sonicwall and FortiGate. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: Mel Beckman [mailto:mel at beckman.org] Sent: Thursday, May 05, 2016 2:49 PM To: Nick Ellermann Cc: Ken Chase ; nanog at nanog.org Subject: Re: sub $500-750 CPE firewall for voip-centric application I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto firewalls. The best SMB devices are definitely SonicWall and Fortigate. SonicWalls are easier to configure, but have fewer features. Fortigate has many knobs and dials and a very powerful virtual router facility that can do amazing things. The two vendors have equivalent support in my opinion, although Fortigate tends to be more personal (Dell is big and you get random techs). Cisco ASA is overpriced and under-featured. Cisco-only shops like them, but mostly I think because they're Cisco-only. PaloAlto is expensive for what you get. Functionally they are on the same level as Fortigate, with a slightly more elegant GUI. But Fortigate can be configured via a USB cable, which is a huge advantage in the field. Legacy RS-232 serial ports are error-prone and slow. -mel > On May 5, 2016, at 11:39 AM, Nick Ellermann wrote: > > We have a lot of luck for smaller VOIP customers having all of their services run through a FortiGate 60D, or higher models. 60D is our go to solution for small enterprise. However, if we are the network carrier for a particular customer and they have a voip deployment of more than about 15 phones, then we deploy a dedicated voice edge gateway, which is more about voice support and handset management than anything. You do need to disable a couple of things on the FortiGate such as SIP Session Helper and ALG. We never have voice termination, origination or call quality issues because of the firewall. > FortiGate has a lot of advanced features as well as fine tuning and adjustment capabilities for the network engineering type and is still easy enough for our entry level techs to support. Most of our customers have heavy VPN requirements and FortiGates have great IPsec performance. We leverage a lot of the network security features and have built a successful managed firewall service with good monitoring and analytics using a third-party monitoring platform and Fortinet's FortiAnaylzer platform. > > Worth looking at, if you haven't already. If you want to private message me, happy to give more info. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: Thursday, May 05, 2016 1:54 PM > To: nanog at nanog.org > Subject: sub $500-750 CPE firewall for voip-centric application > > Looking around at different SMB firewalls to standardize on so we can start training up our level 2/3 techs instead of dealing with a mess of different vendors at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, wondering what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) that we are comfortable telling endpoints to toss current gear/buy additional gear. > > Basic firewalling of course is covered, but also need port range forwarding (not available until later ASA versions for eg was an issue), QoS (port/flow based as well as possibly actually talking some real QoS protocols) and VPN capabilities (not sure if many do without #seats licensing schemes which get irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > shell > preferred) - I realize a PFsense unit would be great, but might not > have enough brand name recognition to make the master client happy > plopping down as a CPE at end client sites. (I know, "there's only one > brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get > irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada From mel at beckman.org Thu May 5 19:29:00 2016 From: mel at beckman.org (Mel Beckman) Date: Thu, 5 May 2016 19:29:00 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> References: <20160505175348.GU19521@sizone.org> <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> Message-ID: <4A88C6C0-9AC6-4197-8785-05CF5FCAB8DE@beckman.org> I should mention that both SonicWall and Fortigate have superb packet capture engines. Not only can you do capture view and first-level decode right in the web GUI, you can save captures in PCAP format or pipe the capture stream to an available Ethernet port. Both have extensive filtering for both capture and viewing within capture, and decent-sized capture buffers. -mel > On May 5, 2016, at 12:09 PM, Matt Freitag wrote: > > I'm a huge fan of Juniper's SRX line. I use all the features you point out > at home on my SRX210, although that product is end-of-life. A refurbished > SRX220 lists on Amazon for about $375, and a new one for $700. Naturally > support is extra, but I'm not sure how much. > > I haven't used it myself but I have seen the packet capture in action. > It'll save any traffic you want right out to a pcap file too. I also like > "show security flow session" - shows you the source, destination, ports, > how long a session has been going, and number of packets and number of > bytes transferred. > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 > http://www.mtu.edu/ > http://www.it.mtu.edu/ > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Ellermann > Sent: Thursday, May 5, 2016 2:51 PM > To: Mel Beckman > Cc: nanog at nanog.org > Subject: RE: sub $500-750 CPE firewall for voip-centric application > > Your exactly right, Mel. Dell has really turned the Sonicwall platform > around in the past few year. We dropped it a year or two before Dell took > them over. Back then Sonicwall was full of issues and lacked important > features that our enterprise customers required. If you have budget, Palo > Alto is something to look at as well, but don't overlook Sonicwall and > FortiGate. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > > -----Original Message----- > From: Mel Beckman [mailto:mel at beckman.org] > Sent: Thursday, May 05, 2016 2:49 PM > To: Nick Ellermann > Cc: Ken Chase ; nanog at nanog.org > Subject: Re: sub $500-750 CPE firewall for voip-centric application > > I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto > firewalls. The best SMB devices are definitely SonicWall and Fortigate. > SonicWalls are easier to configure, but have fewer features. Fortigate has > many knobs and dials and a very powerful virtual router facility that can > do amazing things. The two vendors have equivalent support in my opinion, > although Fortigate tends to be more personal (Dell is big and you get > random techs). > > Cisco ASA is overpriced and under-featured. Cisco-only shops like them, > but mostly I think because they're Cisco-only. PaloAlto is expensive for > what you get. Functionally they are on the same level as Fortigate, with a > slightly more elegant GUI. But Fortigate can be configured via a USB > cable, which is a huge advantage in the field. Legacy RS-232 serial ports > are error-prone and slow. > > -mel > >> On May 5, 2016, at 11:39 AM, Nick Ellermann > wrote: >> >> We have a lot of luck for smaller VOIP customers having all of their > services run through a FortiGate 60D, or higher models. 60D is our go to > solution for small enterprise. However, if we are the network carrier for > a particular customer and they have a voip deployment of more than about > 15 phones, then we deploy a dedicated voice edge gateway, which is more > about voice support and handset management than anything. You do need to > disable a couple of things on the FortiGate such as SIP Session Helper and > ALG. We never have voice termination, origination or call quality issues > because of the firewall. >> FortiGate has a lot of advanced features as well as fine tuning and > adjustment capabilities for the network engineering type and is still easy > enough for our entry level techs to support. Most of our customers have > heavy VPN requirements and FortiGates have great IPsec performance. We > leverage a lot of the network security features and have built a > successful managed firewall service with good monitoring and analytics > using a third-party monitoring platform and Fortinet's FortiAnaylzer > platform. >> >> Worth looking at, if you haven't already. If you want to private message > me, happy to give more info. >> >> >> Sincerely, >> Nick Ellermann - CTO & VP Cloud Services BroadAspect >> >> E: nellermann at broadaspect.com >> P: 703-297-4639 >> F: 703-996-4443 >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase >> Sent: Thursday, May 05, 2016 1:54 PM >> To: nanog at nanog.org >> Subject: sub $500-750 CPE firewall for voip-centric application >> >> Looking around at different SMB firewalls to standardize on so we can > start training up our level 2/3 techs instead of dealing with a mess of > different vendors at cust premises. >> >> I've run into a few firewalls that were not sip or 323 friendly however, > wondering what your experiences are. Need something cheap enough > (certainly <$1k, <$500-750 better) that we are comfortable telling > endpoints to toss current gear/buy additional gear. >> >> Basic firewalling of course is covered, but also need port range > forwarding (not available until later ASA versions for eg was an issue), > QoS (port/flow based as well as possibly actually talking some real QoS > protocols) and VPN capabilities (not sure if many do without #seats > licensing schemes which get irritating to clients). >> >> We'd like a bit of diagnostic capability (say tcpdump or the like, via >> shell >> preferred) - I realize a PFsense unit would be great, but might not >> have enough brand name recognition to make the master client happy >> plopping down as a CPE at end client sites. (I know, "there's only one >> brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get >> irritating for end customers.) >> >> /kc >> -- >> Ken Chase - Guelph Canada From trelane at trelane.net Thu May 5 19:37:23 2016 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 5 May 2016 15:37:23 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> References: <20160505175348.GU19521@sizone.org> <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> Message-ID: Both the Juniper SRX, and the Mikrotik will work. The problem isn't firewalling, it's NAT. NAT is evil. Perhaps having enough IP Addresses would be a better solution? https://www.youtube.com/watch?v=v26BAlfWBm8 On Thu, May 5, 2016 at 3:09 PM, Matt Freitag wrote: > I'm a huge fan of Juniper's SRX line. I use all the features you point out > at home on my SRX210, although that product is end-of-life. A refurbished > SRX220 lists on Amazon for about $375, and a new one for $700. Naturally > support is extra, but I'm not sure how much. > > I haven't used it myself but I have seen the packet capture in action. > It'll save any traffic you want right out to a pcap file too. I also like > "show security flow session" - shows you the source, destination, ports, > how long a session has been going, and number of packets and number of > bytes transferred. > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 > http://www.mtu.edu/ > http://www.it.mtu.edu/ > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Ellermann > Sent: Thursday, May 5, 2016 2:51 PM > To: Mel Beckman > Cc: nanog at nanog.org > Subject: RE: sub $500-750 CPE firewall for voip-centric application > > Your exactly right, Mel. Dell has really turned the Sonicwall platform > around in the past few year. We dropped it a year or two before Dell took > them over. Back then Sonicwall was full of issues and lacked important > features that our enterprise customers required. If you have budget, Palo > Alto is something to look at as well, but don't overlook Sonicwall and > FortiGate. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > > -----Original Message----- > From: Mel Beckman [mailto:mel at beckman.org] > Sent: Thursday, May 05, 2016 2:49 PM > To: Nick Ellermann > Cc: Ken Chase ; nanog at nanog.org > Subject: Re: sub $500-750 CPE firewall for voip-centric application > > I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto > firewalls. The best SMB devices are definitely SonicWall and Fortigate. > SonicWalls are easier to configure, but have fewer features. Fortigate has > many knobs and dials and a very powerful virtual router facility that can > do amazing things. The two vendors have equivalent support in my opinion, > although Fortigate tends to be more personal (Dell is big and you get > random techs). > > Cisco ASA is overpriced and under-featured. Cisco-only shops like them, > but mostly I think because they're Cisco-only. PaloAlto is expensive for > what you get. Functionally they are on the same level as Fortigate, with a > slightly more elegant GUI. But Fortigate can be configured via a USB > cable, which is a huge advantage in the field. Legacy RS-232 serial ports > are error-prone and slow. > > -mel > > > On May 5, 2016, at 11:39 AM, Nick Ellermann > wrote: > > > > We have a lot of luck for smaller VOIP customers having all of their > services run through a FortiGate 60D, or higher models. 60D is our go to > solution for small enterprise. However, if we are the network carrier for > a particular customer and they have a voip deployment of more than about > 15 phones, then we deploy a dedicated voice edge gateway, which is more > about voice support and handset management than anything. You do need to > disable a couple of things on the FortiGate such as SIP Session Helper and > ALG. We never have voice termination, origination or call quality issues > because of the firewall. > > FortiGate has a lot of advanced features as well as fine tuning and > adjustment capabilities for the network engineering type and is still easy > enough for our entry level techs to support. Most of our customers have > heavy VPN requirements and FortiGates have great IPsec performance. We > leverage a lot of the network security features and have built a > successful managed firewall service with good monitoring and analytics > using a third-party monitoring platform and Fortinet's FortiAnaylzer > platform. > > > > Worth looking at, if you haven't already. If you want to private message > me, happy to give more info. > > > > > > Sincerely, > > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > > > E: nellermann at broadaspect.com > > P: 703-297-4639 > > F: 703-996-4443 > > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > > Sent: Thursday, May 05, 2016 1:54 PM > > To: nanog at nanog.org > > Subject: sub $500-750 CPE firewall for voip-centric application > > > > Looking around at different SMB firewalls to standardize on so we can > start training up our level 2/3 techs instead of dealing with a mess of > different vendors at cust premises. > > > > I've run into a few firewalls that were not sip or 323 friendly however, > wondering what your experiences are. Need something cheap enough > (certainly <$1k, <$500-750 better) that we are comfortable telling > endpoints to toss current gear/buy additional gear. > > > > Basic firewalling of course is covered, but also need port range > forwarding (not available until later ASA versions for eg was an issue), > QoS (port/flow based as well as possibly actually talking some real QoS > protocols) and VPN capabilities (not sure if many do without #seats > licensing schemes which get irritating to clients). > > > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > > shell > > preferred) - I realize a PFsense unit would be great, but might not > > have enough brand name recognition to make the master client happy > > plopping down as a CPE at end client sites. (I know, "there's only one > > brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get > > irritating for end customers.) > > > > /kc > > -- > > Ken Chase - Guelph Canada > From javier at advancedmachines.us Thu May 5 20:52:26 2016 From: javier at advancedmachines.us (Javier J) Date: Thu, 5 May 2016 16:52:26 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: I'm a fan of the EdgeRouterLite3 I don't manage many small businesses networks anymore because we now do only 100% cloud and remote work but I started deploying them to all my old clients I still have on retainer. It is a wonderful solid set it, and forget it device and you can manage it with ssh (it is basically running a fork of Vyatta under the hood on Cavium hardware which is nice because it does lots of hardware offload like any other enterprise device.) I won't use pfsense anymore because it's project was taken over by a-holes, but that is just my personal experience. - Javier On Thu, May 5, 2016 at 1:53 PM, Ken Chase wrote: > Looking around at different SMB firewalls to standardize on so we can start > training up our level 2/3 techs instead of dealing with a mess of > different vendors > at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, > wondering > what your experiences are. Need something cheap enough (certainly <$1k, > <$500-750 better) > that we are comfortable telling endpoints to toss current gear/buy > additional gear. > > Basic firewalling of course is covered, but also need port range forwarding > (not available until later ASA versions for eg was an issue), QoS > (port/flow > based as well as possibly actually talking some real QoS protocols) and VPN > capabilities (not sure if many do without #seats licensing schemes which > get > irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > shell > preferred) - I realize a PFsense unit would be great, but might not have > enough brand name recognition to make the master client happy plopping > down as > a CPE at end client sites. (I know, "there's only one brand, Cisco." > ASA5506x is a > bit $$ and licensing acrobatics get irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada > From shawn at smorris.com Thu May 5 14:59:34 2016 From: shawn at smorris.com (Shawn Morris) Date: Thu, 5 May 2016 09:59:34 -0500 Subject: Patch panel solutions for 4x10GE breakout In-Reply-To: <12672D4F-3AC1-4D89-A2A1-19AFD7D924F3@puck.nether.net> References: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> <12672D4F-3AC1-4D89-A2A1-19AFD7D924F3@puck.nether.net> Message-ID: It's the Corning Edge8 line [ https://www.corning.com/worldwide/en/products/communication-networks/applications/data-center/edge8.html ] On Thu, May 5, 2016 at 9:45 AM, Jared Mauch wrote: > There is a nice Corning panel our facilities team is using now. I can find > the link and send it to the list when not at my phone. > > Jared Mauch > > > On May 5, 2016, at 10:28 AM, Phil Bedard wrote: > > > > So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE > breakouts to deliver 10G. We are not wiring these up to things in the same > rack, they will be going to patch panels and then elsewhere in a facility. > It could potentially get messy with the panels we have today so we are > looking at other solutions. These are all SM LR connections using LC. > There are a lot of SM MTP to LC options since that?s the way most panels > are wired, but they typically have 6 duplex LC connectors per MTP and not 4 > which isn?t very efficient in this use case. I?ve seen others just use an > intermediate LC to LC panel and just wire the breakouts to those and then > jumper the other side elsewhere. > > > > Anything else others have used? The point of the solution is to keep > the wiring mess in front of or near the device to a minimum. > > > > Thanks, > > > > Phil > > > > From sryan at arbor.net Thu May 5 15:19:55 2016 From: sryan at arbor.net (Spencer Ryan) Date: Thu, 5 May 2016 11:19:55 -0400 Subject: Patch panel solutions for 4x10GE breakout In-Reply-To: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> References: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> Message-ID: We generally run a MTP/MPO12 cable to a breakout cassette a few racks down, and that's where we split out all of the LC pairs. It keeps the mess away from the routers/traffic generators. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Thu, May 5, 2016 at 10:28 AM, Phil Bedard wrote: > So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE > breakouts to deliver 10G. We are not wiring these up to things in the same > rack, they will be going to patch panels and then elsewhere in a facility. > It could potentially get messy with the panels we have today so we are > looking at other solutions. These are all SM LR connections using LC. > There are a lot of SM MTP to LC options since that?s the way most panels > are wired, but they typically have 6 duplex LC connectors per MTP and not 4 > which isn?t very efficient in this use case. I?ve seen others just use an > intermediate LC to LC panel and just wire the breakouts to those and then > jumper the other side elsewhere. > > Anything else others have used? The point of the solution is to keep the > wiring mess in front of or near the device to a minimum. > > Thanks, > > Phil > > > From afmug at zirkel.us Thu May 5 18:34:11 2016 From: afmug at zirkel.us (Sean Heskett) Date: Thu, 5 May 2016 11:34:11 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: We use Calix gigacenter 844E. It will do everything you listed (and a whole lot more) except the VPN part. -Sean On Thursday, May 5, 2016, Ken Chase wrote: > Looking around at different SMB firewalls to standardize on so we can start > training up our level 2/3 techs instead of dealing with a mess of > different vendors > at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, > wondering > what your experiences are. Need something cheap enough (certainly <$1k, > <$500-750 better) > that we are comfortable telling endpoints to toss current gear/buy > additional gear. > > Basic firewalling of course is covered, but also need port range forwarding > (not available until later ASA versions for eg was an issue), QoS > (port/flow > based as well as possibly actually talking some real QoS protocols) and VPN > capabilities (not sure if many do without #seats licensing schemes which > get > irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via > shell > preferred) - I realize a PFsense unit would be great, but might not have > enough brand name recognition to make the master client happy plopping > down as > a CPE at end client sites. (I know, "there's only one brand, Cisco." > ASA5506x is a > bit $$ and licensing acrobatics get irritating for end customers.) > > /kc > -- > Ken Chase - Guelph Canada > From nathan at schrenk.org Wed May 4 21:32:20 2016 From: nathan at schrenk.org (Nathan Schrenk) Date: Wed, 4 May 2016 16:32:20 -0500 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: Message-ID: It looks like www.outages.org stopped being updated with outage data in January 2013? Nathan On Wed, May 4, 2016 at 3:57 PM, Bill Woodcock wrote: > > > On May 4, 2016, at 4:37 PM, Javier J wrote: > > > > If there is a better mailing list please let me know. > > outages at outages.org > > -Bill > > > > > From g at 1337.io Fri May 6 00:18:20 2016 From: g at 1337.io (g at 1337.io) Date: Thu, 5 May 2016 17:18:20 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> Message-ID: <572BE2CC.5090401@1337.io> If you are considering pfSense, I would urge you to look at OPNsense instead. The pfSense code is horrible! On 5/5/16 11:11 AM, amuse wrote: > What PFSense currently lacks in brand name recognition, they can make up > with by the fact that they offer paid support at very affordable levels. > > I'd go with https://store.pfsense.org/SG-2440/ ($499 each) and a quote for > professional services ( > https://store.pfsense.org/Professional-Services.aspx ) to back that up. > > On Thu, May 5, 2016 at 10:53 AM, Ken Chase wrote: > >> Looking around at different SMB firewalls to standardize on so we can start >> training up our level 2/3 techs instead of dealing with a mess of >> different vendors >> at cust premises. >> >> I've run into a few firewalls that were not sip or 323 friendly however, >> wondering >> what your experiences are. Need something cheap enough (certainly <$1k, >> <$500-750 better) >> that we are comfortable telling endpoints to toss current gear/buy >> additional gear. >> >> Basic firewalling of course is covered, but also need port range forwarding >> (not available until later ASA versions for eg was an issue), QoS >> (port/flow >> based as well as possibly actually talking some real QoS protocols) and VPN >> capabilities (not sure if many do without #seats licensing schemes which >> get >> irritating to clients). >> >> We'd like a bit of diagnostic capability (say tcpdump or the like, via >> shell >> preferred) - I realize a PFsense unit would be great, but might not have >> enough brand name recognition to make the master client happy plopping >> down as >> a CPE at end client sites. (I know, "there's only one brand, Cisco." >> ASA5506x is a >> bit $$ and licensing acrobatics get irritating for end customers.) >> >> /kc >> -- >> Ken Chase - Guelph Canada >> From jared at puck.nether.net Fri May 6 00:27:31 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 5 May 2016 20:27:31 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> Message-ID: <8A0B1704-F3F8-4F2B-B0DE-9A35B0B3C9C0@puck.nether.net> > On May 5, 2016, at 4:52 PM, Javier J wrote: > > I'm a fan of the EdgeRouterLite3 > > > I don't manage many small businesses networks anymore because we now do > only 100% cloud and remote work but I started deploying them to all my old > clients I still have on retainer. > > > It is a wonderful solid set it, and forget it device and you can manage it > with ssh (it is basically running a fork of Vyatta under the hood on Cavium > hardware which is nice because it does lots of hardware offload like any > other enterprise device.) I?ll +1 the Edgerouter series. They are cheap and hit the right price performance ratio for most homes. You can do site-to-site IPSEC VPN stuff and easily SSH + tcpdump if necessary. If you are looking for more complex blocking rules and services, you need to be looking at something like the Deteque DNS service or the Cisco/OpenDNS services instead to nuke outbound malware connections and such. - Jared From lists at mtin.net Fri May 6 00:43:17 2016 From: lists at mtin.net (Justin Wilson) Date: Thu, 5 May 2016 20:43:17 -0400 Subject: CALEA Message-ID: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Does anyone have some up-to-date information on CALEA? https://askcalea.fbi.gov/ has a fair amount of broken links. The servicer provider registration is broken. The web-site has not been updated. Searches on FBI.gov and the FCC site just point back to askcalea. Are any of you still seeing CALEA requests on the voice or the data sides? What is the community hearing about CALEA? Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric From raphael.timothy at gmail.com Fri May 6 01:04:47 2016 From: raphael.timothy at gmail.com (Tim Raphael) Date: Fri, 6 May 2016 09:04:47 +0800 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <2ED2394E-4C15-4F65-BA4F-97EEF8C60B09@beckman.org> <863d27e5488441f48086e1af2e4b1afc@exchange.broadaspect.local> <4d83fa8037902325570f3f0498a52df0@mail.gmail.com> Message-ID: <5417AAE1-94BE-4747-A4AC-A375D7BEF0D5@gmail.com> The SIP ALG in the Juniper SRXs is definitely one of the best I?ve come across. I defaulted to turning it off based on my previous experiences with SIP ALGs and NAT however it became apparent that it actually worked really well and I ended up defaulting it to on. - Tim > On 6 May 2016, at 3:37 AM, Andrew Kirch wrote: > > Both the Juniper SRX, and the Mikrotik will work. > > The problem isn't firewalling, it's NAT. NAT is evil. > > Perhaps having enough IP Addresses would be a better solution? > https://www.youtube.com/watch?v=v26BAlfWBm8 > > On Thu, May 5, 2016 at 3:09 PM, Matt Freitag wrote: > >> I'm a huge fan of Juniper's SRX line. I use all the features you point out >> at home on my SRX210, although that product is end-of-life. A refurbished >> SRX220 lists on Amazon for about $375, and a new one for $700. Naturally >> support is extra, but I'm not sure how much. >> >> I haven't used it myself but I have seen the packet capture in action. >> It'll save any traffic you want right out to a pcap file too. I also like >> "show security flow session" - shows you the source, destination, ports, >> how long a session has been going, and number of packets and number of >> bytes transferred. >> >> Matt Freitag >> Network Engineer I >> Information Technology >> Michigan Technological University >> (906) 487-3696 >> http://www.mtu.edu/ >> http://www.it.mtu.edu/ >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Ellermann >> Sent: Thursday, May 5, 2016 2:51 PM >> To: Mel Beckman >> Cc: nanog at nanog.org >> Subject: RE: sub $500-750 CPE firewall for voip-centric application >> >> Your exactly right, Mel. Dell has really turned the Sonicwall platform >> around in the past few year. We dropped it a year or two before Dell took >> them over. Back then Sonicwall was full of issues and lacked important >> features that our enterprise customers required. If you have budget, Palo >> Alto is something to look at as well, but don't overlook Sonicwall and >> FortiGate. >> >> >> Sincerely, >> Nick Ellermann - CTO & VP Cloud Services BroadAspect >> >> E: nellermann at broadaspect.com >> P: 703-297-4639 >> F: 703-996-4443 >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail >> and its attachments from all computers. >> >> >> -----Original Message----- >> From: Mel Beckman [mailto:mel at beckman.org] >> Sent: Thursday, May 05, 2016 2:49 PM >> To: Nick Ellermann >> Cc: Ken Chase ; nanog at nanog.org >> Subject: Re: sub $500-750 CPE firewall for voip-centric application >> >> I install and support Cisco ASA, Dell SonicWall, Fortigate, and PaloAlto >> firewalls. The best SMB devices are definitely SonicWall and Fortigate. >> SonicWalls are easier to configure, but have fewer features. Fortigate has >> many knobs and dials and a very powerful virtual router facility that can >> do amazing things. The two vendors have equivalent support in my opinion, >> although Fortigate tends to be more personal (Dell is big and you get >> random techs). >> >> Cisco ASA is overpriced and under-featured. Cisco-only shops like them, >> but mostly I think because they're Cisco-only. PaloAlto is expensive for >> what you get. Functionally they are on the same level as Fortigate, with a >> slightly more elegant GUI. But Fortigate can be configured via a USB >> cable, which is a huge advantage in the field. Legacy RS-232 serial ports >> are error-prone and slow. >> >> -mel >> >>> On May 5, 2016, at 11:39 AM, Nick Ellermann >> wrote: >>> >>> We have a lot of luck for smaller VOIP customers having all of their >> services run through a FortiGate 60D, or higher models. 60D is our go to >> solution for small enterprise. However, if we are the network carrier for >> a particular customer and they have a voip deployment of more than about >> 15 phones, then we deploy a dedicated voice edge gateway, which is more >> about voice support and handset management than anything. You do need to >> disable a couple of things on the FortiGate such as SIP Session Helper and >> ALG. We never have voice termination, origination or call quality issues >> because of the firewall. >>> FortiGate has a lot of advanced features as well as fine tuning and >> adjustment capabilities for the network engineering type and is still easy >> enough for our entry level techs to support. Most of our customers have >> heavy VPN requirements and FortiGates have great IPsec performance. We >> leverage a lot of the network security features and have built a >> successful managed firewall service with good monitoring and analytics >> using a third-party monitoring platform and Fortinet's FortiAnaylzer >> platform. >>> >>> Worth looking at, if you haven't already. If you want to private message >> me, happy to give more info. >>> >>> >>> Sincerely, >>> Nick Ellermann - CTO & VP Cloud Services BroadAspect >>> >>> E: nellermann at broadaspect.com >>> P: 703-297-4639 >>> F: 703-996-4443 >>> >>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail >> and its attachments from all computers. >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase >>> Sent: Thursday, May 05, 2016 1:54 PM >>> To: nanog at nanog.org >>> Subject: sub $500-750 CPE firewall for voip-centric application >>> >>> Looking around at different SMB firewalls to standardize on so we can >> start training up our level 2/3 techs instead of dealing with a mess of >> different vendors at cust premises. >>> >>> I've run into a few firewalls that were not sip or 323 friendly however, >> wondering what your experiences are. Need something cheap enough >> (certainly <$1k, <$500-750 better) that we are comfortable telling >> endpoints to toss current gear/buy additional gear. >>> >>> Basic firewalling of course is covered, but also need port range >> forwarding (not available until later ASA versions for eg was an issue), >> QoS (port/flow based as well as possibly actually talking some real QoS >> protocols) and VPN capabilities (not sure if many do without #seats >> licensing schemes which get irritating to clients). >>> >>> We'd like a bit of diagnostic capability (say tcpdump or the like, via >>> shell >>> preferred) - I realize a PFsense unit would be great, but might not >>> have enough brand name recognition to make the master client happy >>> plopping down as a CPE at end client sites. (I know, "there's only one >>> brand, Cisco." ASA5506x is a bit $$ and licensing acrobatics get >>> irritating for end customers.) >>> >>> /kc >>> -- >>> Ken Chase - Guelph Canada >> From morrowc.lists at gmail.com Fri May 6 02:12:33 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 May 2016 22:12:33 -0400 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <8A0B1704-F3F8-4F2B-B0DE-9A35B0B3C9C0@puck.nether.net> References: <20160505175348.GU19521@sizone.org> <8A0B1704-F3F8-4F2B-B0DE-9A35B0B3C9C0@puck.nether.net> Message-ID: On Thu, May 5, 2016 at 8:27 PM, Jared Mauch wrote: > > > On May 5, 2016, at 4:52 PM, Javier J wrote: > > > > I'm a fan of the EdgeRouterLite3 > > > > > > I don't manage many small businesses networks anymore because we now do > > only 100% cloud and remote work but I started deploying them to all my > old > > clients I still have on retainer. > > > > > > It is a wonderful solid set it, and forget it device and you can manage > it > > with ssh (it is basically running a fork of Vyatta under the hood on > Cavium > > hardware which is nice because it does lots of hardware offload like any > > other enterprise device.) > > I?ll +1 the Edgerouter series. They are cheap and hit the right price > performance ratio for most homes. > > ?came here to say this, also they do v6, PD and all that jazz.? > You can do site-to-site IPSEC VPN stuff and easily SSH + tcpdump if > necessary. > > If you are looking for more complex blocking rules and services, you need > to be > looking at something like the Deteque DNS service or the Cisco/OpenDNS > services > instead to nuke outbound malware connections and such. > > ?also agree whole-heartedly with this sentiment.y? From warren at kumari.net Fri May 6 02:47:17 2016 From: warren at kumari.net (Warren Kumari) Date: Fri, 06 May 2016 02:47:17 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <8A0B1704-F3F8-4F2B-B0DE-9A35B0B3C9C0@puck.nether.net> References: <20160505175348.GU19521@sizone.org> <8A0B1704-F3F8-4F2B-B0DE-9A35B0B3C9C0@puck.nether.net> Message-ID: Yeah, the EdgeRouter series do not suck. Fast, stable, easy to manage (although the broken tab completion drives me nuts ('sho ip route' should just work, I'm too old to retrain my fingers...) - other than that they are great... W On Thu, May 5, 2016 at 8:28 PM Jared Mauch wrote: > > > On May 5, 2016, at 4:52 PM, Javier J wrote: > > > > I'm a fan of the EdgeRouterLite3 > > > > > > I don't manage many small businesses networks anymore because we now do > > only 100% cloud and remote work but I started deploying them to all my > old > > clients I still have on retainer. > > > > > > It is a wonderful solid set it, and forget it device and you can manage > it > > with ssh (it is basically running a fork of Vyatta under the hood on > Cavium > > hardware which is nice because it does lots of hardware offload like any > > other enterprise device.) > > I?ll +1 the Edgerouter series. They are cheap and hit the right price > performance ratio for most homes. > > You can do site-to-site IPSEC VPN stuff and easily SSH + tcpdump if > necessary. > > If you are looking for more complex blocking rules and services, you need > to be > looking at something like the Deteque DNS service or the Cisco/OpenDNS > services > instead to nuke outbound malware connections and such. > > - Jared > > From mark.tinka at seacom.mu Fri May 6 06:59:22 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 08:59:22 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160505175348.GU19521@sizone.org> References: <20160505175348.GU19521@sizone.org> Message-ID: On 5/May/16 19:53, Ken Chase wrote: > Looking around at different SMB firewalls to standardize on so we can start > training up our level 2/3 techs instead of dealing with a mess of different vendors > at cust premises. > > I've run into a few firewalls that were not sip or 323 friendly however, wondering > what your experiences are. Need something cheap enough (certainly <$1k, <$500-750 better) > that we are comfortable telling endpoints to toss current gear/buy additional gear. > > Basic firewalling of course is covered, but also need port range forwarding > (not available until later ASA versions for eg was an issue), QoS (port/flow > based as well as possibly actually talking some real QoS protocols) and VPN > capabilities (not sure if many do without #seats licensing schemes which get > irritating to clients). > > We'd like a bit of diagnostic capability (say tcpdump or the like, via shell > preferred) - I realize a PFsense unit would be great, but might not have > enough brand name recognition to make the master client happy plopping down as > a CPE at end client sites. (I know, "there's only one brand, Cisco." ASA5506x is a > bit $$ and licensing acrobatics get irritating for end customers.) pfSense. Mark. From mark.tinka at seacom.mu Fri May 6 07:01:26 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 09:01:26 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572BE2CC.5090401@1337.io> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> Message-ID: <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> On 6/May/16 02:18, g at 1337.io wrote: > If you are considering pfSense, I would urge you to look at OPNsense > instead. The pfSense code is horrible! Can you explain? We've been reasonably happy with it, running it since 2012 on dozens of boxes for our corporate network and as OpenVPN servers. Mark. From a.harrowell at gmail.com Fri May 6 10:42:25 2016 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 6 May 2016 11:42:25 +0100 Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out. In-Reply-To: References: Message-ID: you mean there's an outages.org outage? [sorry] On Wed, May 4, 2016 at 10:32 PM, Nathan Schrenk wrote: > It looks like www.outages.org stopped being updated with outage data in > January 2013? > > Nathan > > On Wed, May 4, 2016 at 3:57 PM, Bill Woodcock wrote: > > > > > > On May 4, 2016, at 4:37 PM, Javier J > wrote: > > > > > > If there is a better mailing list please let me know. > > > > outages at outages.org > > > > -Bill > > > > > > > > > > > From nanog-amuse at foofus.com Fri May 6 15:44:10 2016 From: nanog-amuse at foofus.com (amuse) Date: Fri, 6 May 2016 08:44:10 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> Message-ID: +1 to a "Can you substantiate that claim please?" sentiment here. I've used it for years and found it to be reliable, flexible, feature-filled. And having the BSD CLI fully available has been a godsend. On Fri, May 6, 2016 at 12:01 AM, Mark Tinka wrote: > > > On 6/May/16 02:18, g at 1337.io wrote: > > > If you are considering pfSense, I would urge you to look at OPNsense > > instead. The pfSense code is horrible! > > Can you explain? > > We've been reasonably happy with it, running it since 2012 on dozens of > boxes for our corporate network and as OpenVPN servers. > > Mark. > From nick at foobar.org Fri May 6 16:24:10 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 06 May 2016 17:24:10 +0100 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> Message-ID: <572CC52A.9090905@foobar.org> amuse wrote: > +1 to a "Can you substantiate that claim please?" sentiment here. I've > used it for years and found it to be reliable, flexible, feature-filled. > And having the BSD CLI fully available has been a godsend. The code quality is terrible in a 1990s sort of way. I.e. no separation of code, html, logic, data structure or anything else. Everything is jumbled in together using coding methodologies which don't scale and which make it almost impossible to audit in a meaningful way. Specific problems: 1. the installation image ships with static dh params files, e.g. > https://github.com/pfsense/pfsense/blob/master/src/etc/dh-parameters.1024 This is a really bad idea and someone should issue a CVE for it. The reasons are clearly explained at: > https://weakdh.org/ > https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html 2. http params validation: a cursory glance at the output of "grep -r _GET pfsense/src" show that the authors did not use any http parameters validation. In addition, the output of $_GET is used unsafely in multiple locations. 3. the output of "grep -wr exec pfsense/src | grep 'rm -rf'" shows what looks like exploitable problems due to poor shell escaping. This isn't an audit or anything, btw. It's the result of a couple of minutes glancing over the code. I'm sure an audit would produce a lot more. Nick From mel at beckman.org Fri May 6 16:39:30 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 6 May 2016 16:39:30 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CC52A.9090905@foobar.org> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> Message-ID: I, too, was not impressed with PFSense?s code. I?ve had to dig into it a couple of times to troubleshoot weird failure modes. I finally gave up. My time is too valuable, and the price of modern firewalls is fair for the value you get in serious regression testing and support. Also, I would not characterize PFSense as ?reliable?. My PFsense boxes still require periodic reboots due to memory leaks, and sometimes just lock up. Yes, that happens with commercial boxen, but those events are far more rare. -mel > On May 6, 2016, at 9:24 AM, Nick Hilliard wrote: > > amuse wrote: >> +1 to a "Can you substantiate that claim please?" sentiment here. I've >> used it for years and found it to be reliable, flexible, feature-filled. >> And having the BSD CLI fully available has been a godsend. > > The code quality is terrible in a 1990s sort of way. I.e. no separation > of code, html, logic, data structure or anything else. Everything is > jumbled in together using coding methodologies which don't scale and > which make it almost impossible to audit in a meaningful way. > > Specific problems: > > 1. the installation image ships with static dh params files, e.g. > >> https://github.com/pfsense/pfsense/blob/master/src/etc/dh-parameters.1024 > > This is a really bad idea and someone should issue a CVE for it. The > reasons are clearly explained at: > >> https://weakdh.org/ > >> https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html > > 2. http params validation: a cursory glance at the output of "grep -r > _GET pfsense/src" show that the authors did not use any http parameters > validation. In addition, the output of $_GET is used unsafely in > multiple locations. > > 3. the output of "grep -wr exec pfsense/src | grep 'rm -rf'" shows what > looks like exploitable problems due to poor shell escaping. > > This isn't an audit or anything, btw. It's the result of a couple of > minutes glancing over the code. I'm sure an audit would produce a lot more. > > Nick From nanog-amuse at foofus.com Fri May 6 16:59:54 2016 From: nanog-amuse at foofus.com (amuse) Date: Fri, 6 May 2016 09:59:54 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> Message-ID: One question I have is: Is there any reason to believe that the source code for Sonicwall, Cisco, etc are any better than the PFSense code? Or are we just able to see the PFSense code and make unfounded assumptions that the commercial code is in better shape? On Fri, May 6, 2016 at 9:39 AM, Mel Beckman wrote: > I, too, was not impressed with PFSense?s code. I?ve had to dig into it a > couple of times to troubleshoot weird failure modes. I finally gave up. My > time is too valuable, and the price of modern firewalls is fair for the > value you get in serious regression testing and support. > > Also, I would not characterize PFSense as ?reliable?. My PFsense boxes > still require periodic reboots due to memory leaks, and sometimes just lock > up. Yes, that happens with commercial boxen, but those events are far more > rare. > > -mel > > > > On May 6, 2016, at 9:24 AM, Nick Hilliard wrote: > > > > amuse wrote: > >> +1 to a "Can you substantiate that claim please?" sentiment here. I've > >> used it for years and found it to be reliable, flexible, feature-filled. > >> And having the BSD CLI fully available has been a godsend. > > > > The code quality is terrible in a 1990s sort of way. I.e. no separation > > of code, html, logic, data structure or anything else. Everything is > > jumbled in together using coding methodologies which don't scale and > > which make it almost impossible to audit in a meaningful way. > > > > Specific problems: > > > > 1. the installation image ships with static dh params files, e.g. > > > >> > https://github.com/pfsense/pfsense/blob/master/src/etc/dh-parameters.1024 > > > > This is a really bad idea and someone should issue a CVE for it. The > > reasons are clearly explained at: > > > >> https://weakdh.org/ > > > >> https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html > > > > 2. http params validation: a cursory glance at the output of "grep -r > > _GET pfsense/src" show that the authors did not use any http parameters > > validation. In addition, the output of $_GET is used unsafely in > > multiple locations. > > > > 3. the output of "grep -wr exec pfsense/src | grep 'rm -rf'" shows what > > looks like exploitable problems due to poor shell escaping. > > > > This isn't an audit or anything, btw. It's the result of a couple of > > minutes glancing over the code. I'm sure an audit would produce a lot > more. > > > > Nick > > From mark.tinka at seacom.mu Fri May 6 18:02:18 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 20:02:18 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> Message-ID: <3cf71332-f1a1-1694-26f8-61a881299df2@seacom.mu> On 6/May/16 18:59, amuse wrote: > One question I have is: Is there any reason to believe that the source > code for Sonicwall, Cisco, etc are any better than the PFSense code? Or > are we just able to see the PFSense code and make unfounded assumptions > that the commercial code is in better shape? A fair question. And I suppose one could say that if you are unhappy with the code, make a contribution to make it better. We have ran them for years, and while no system is without problems, for the amount of value you receive, I can't really complain. Mark. From effulgence at gmail.com Fri May 6 18:05:34 2016 From: effulgence at gmail.com (Aris Lambrianidis) Date: Fri, 06 May 2016 20:05:34 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> Message-ID: <572CDCEE.8010301@gmail.com> amuse wrote: > One question I have is: Is there any reason to believe that the source > code for Sonicwall, Cisco, etc are any better than the PFSense code? Or > are we just able to see the PFSense code and make unfounded assumptions > that the commercial code is in better shape? Perhaps not. In fact, probably not, judging by the apparent lack of audit processes for say, OpenSSL libraries re-used in commercial products. It still doesn't detract from the value of what people are aware of, in this case, pfSense code quality. Aris From cscora at apnic.net Fri May 6 18:10:18 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 May 2016 04:10:18 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201605061810.u46IAI2P009029@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 May, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 593234 Prefixes after maximum aggregation (per Origin AS): 217584 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290983 Total ASes present in the Internet Routing Table: 53672 Prefixes per ASN: 11.05 Origin-only ASes present in the Internet Routing Table: 36588 Origin ASes announcing only one prefix: 15696 Transit ASes present in the Internet Routing Table: 6446 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 1002 Unregistered ASNs in the Routing Table: 362 Number of 32-bit ASNs allocated by the RIRs: 13757 Number of 32-bit ASNs visible in the Routing Table: 10638 Prefixes from 32-bit ASNs in the Routing Table: 41921 Number of bogon 32-bit ASNs visible in the Routing Table: 3 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 373 Number of addresses announced to Internet: 2811765860 Equivalent to 167 /8s, 152 /16s and 36 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193871 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151595 Total APNIC prefixes after maximum aggregation: 42244 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 162397 Unique aggregates announced from the APNIC address blocks: 66463 APNIC Region origin ASes present in the Internet Routing Table: 5168 APNIC Prefixes per ASN: 31.42 APNIC Region origin ASes announcing only one prefix: 1183 APNIC Region transit ASes present in the Internet Routing Table: 917 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2052 Number of APNIC addresses announced to Internet: 754555972 Equivalent to 44 /8s, 249 /16s and 156 /24s Percentage of available APNIC address space announced: 88.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 180885 Total ARIN prefixes after maximum aggregation: 89452 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 186163 Unique aggregates announced from the ARIN address blocks: 88526 ARIN Region origin ASes present in the Internet Routing Table: 16367 ARIN Prefixes per ASN: 11.37 ARIN Region origin ASes announcing only one prefix: 5849 ARIN Region transit ASes present in the Internet Routing Table: 1714 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1182 Number of ARIN addresses announced to Internet: 1102188096 Equivalent to 65 /8s, 178 /16s and 14 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 142748 Total RIPE prefixes after maximum aggregation: 70381 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 151841 Unique aggregates announced from the RIPE address blocks: 93607 RIPE Region origin ASes present in the Internet Routing Table: 18079 RIPE Prefixes per ASN: 8.40 RIPE Region origin ASes announcing only one prefix: 7907 RIPE Region transit ASes present in the Internet Routing Table: 3018 Average RIPE Region AS path length visible: 4.2 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4724 Number of RIPE addresses announced to Internet: 704921216 Equivalent to 42 /8s, 4 /16s and 62 /24s Percentage of available RIPE address space announced: 102.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61745 Total LACNIC prefixes after maximum aggregation: 12272 LACNIC Deaggregation factor: 5.03 Prefixes being announced from the LACNIC address blocks: 76254 Unique aggregates announced from the LACNIC address blocks: 36232 LACNIC Region origin ASes present in the Internet Routing Table: 2481 LACNIC Prefixes per ASN: 30.74 LACNIC Region origin ASes announcing only one prefix: 576 LACNIC Region transit ASes present in the Internet Routing Table: 559 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2468 Number of LACNIC addresses announced to Internet: 171276128 Equivalent to 10 /8s, 53 /16s and 119 /24s Percentage of available LACNIC address space announced: 102.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 14245 Total AfriNIC prefixes after maximum aggregation: 3197 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 16206 Unique aggregates announced from the AfriNIC address blocks: 5817 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 21.96 AfriNIC Region origin ASes announcing only one prefix: 181 AfriNIC Region transit ASes present in the Internet Routing Table: 166 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 212 Number of AfriNIC addresses announced to Internet: 78466816 Equivalent to 4 /8s, 173 /16s and 79 /24s Percentage of available AfriNIC address space announced: 77.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5559 4192 76 China Education and Research 7545 3304 354 215 TPG Telecom Limited 4766 3168 11144 1124 Korea Telecom 17974 2927 914 96 PT Telekomunikasi Indonesia 9829 2498 1466 469 National Internet Backbone 4755 2090 432 240 TATA Communications formerly 9808 1893 8717 30 Guangdong Mobile Communicatio 4808 1660 2300 545 CNCGROUP IP network China169 9583 1512 122 562 Sify Limited 38197 1511 93 218 Sun Network (Hong Kong) Limit Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3248 2947 137 Cox Communications Inc. 6389 2322 3671 41 BellSouth.net Inc. 18566 2204 394 275 MegaPath Corporation 20115 1922 1937 404 Charter Communications 30036 1716 341 362 Mediacom Communications Corp 6983 1689 849 232 EarthLink, Inc. 209 1584 4671 1251 Qwest Communications Company, 4323 1528 985 380 tw telecom holdings, inc. 11492 1300 240 598 CABLE ONE, INC. 701 1298 10718 706 MCI Communications Services, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2508 958 1817 Akamai International B.V. 34984 1967 323 417 TELLCOM ILETISIM HIZMETLERI A 8551 1256 376 55 Bezeq International-Ltd 12479 1190 995 93 France Telecom Espana SA 6849 1148 355 21 JSC "Ukrtelecom" 13188 1078 98 65 TOV "Bank-Inform" 8402 1028 544 15 OJSC "Vimpelcom" 31148 1025 47 45 Freenet Ltd. 9198 969 352 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3477 542 135 Telmex Colombia S.A. 8151 2240 3399 570 Uninet S.A. de C.V. 7303 1516 941 238 Telecom Argentina S.A. 11830 1483 368 53 Instituto Costarricense de El 6503 1437 437 56 Axtel, S.A.B. de C.V. 6147 1057 377 27 Telefonica del Peru S.A.A. 26615 1017 2325 34 Tim Celular S.A. 3816 997 478 187 COLOMBIA TELECOMUNICACIONES S 7738 994 1882 40 Telemar Norte Leste S.A. 11172 870 125 77 Alestra, S. de R.L. de C.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1255 402 40 Link Egypt (Link.NET) 37611 644 48 2 Afrihost-Brevis Computer Serv 36903 617 310 105 Office National des Postes et 8452 538 1472 15 TE-AS 36992 511 1357 26 ETISALAT MISR 37492 395 234 68 Orange Tunisie 24835 329 402 15 Vodafone Data 29571 301 37 13 Cote d'Ivoire Telecom 2018 257 327 74 TENET (The UNINET Project) 36947 243 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5559 4192 76 China Education and Research 10620 3477 542 135 Telmex Colombia S.A. 7545 3304 354 215 TPG Telecom Limited 22773 3248 2947 137 Cox Communications Inc. 4766 3168 11144 1124 Korea Telecom 17974 2927 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2508 958 1817 Akamai International B.V. 9829 2498 1466 469 National Internet Backbone 6389 2322 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3477 3342 Telmex Colombia S.A. 22773 3248 3111 Cox Communications Inc. 7545 3304 3089 TPG Telecom Limited 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2927 2831 PT Telekomunikasi Indonesia 6389 2322 2281 BellSouth.net Inc. 4766 3168 2044 Korea Telecom 9829 2498 2029 National Internet Backbone 18566 2204 1929 MegaPath Corporation 9808 1893 1863 Guangdong Mobile Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:267 /13:509 /14:1037 /15:1764 /16:13018 /17:7621 /18:12763 /19:25962 /20:38096 /21:39797 /22:65501 /23:57186 /24:327849 /25:558 /26:595 /27:422 /28:45 /29:31 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2478 3248 Cox Communications Inc. 18566 2106 2204 MegaPath Corporation 30036 1530 1716 Mediacom Communications Corp 6389 1487 2322 BellSouth.net Inc. 10620 1368 3477 Telmex Colombia S.A. 6983 1338 1689 EarthLink, Inc. 34984 1251 1967 TELLCOM ILETISIM HIZMETLERI A 11492 1205 1300 CABLE ONE, INC. 6849 968 1148 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1574 2:735 4:21 5:2067 6:28 8:954 12:1781 13:39 14:1683 15:45 16:2 17:83 18:89 20:48 23:1536 24:1773 27:2267 31:1767 32:59 33:2 34:2 35:5 36:294 37:2277 38:1211 39:27 40:90 41:2881 42:396 43:1747 44:42 45:1811 46:2509 47:78 49:1160 50:868 51:32 52:178 54:328 55:4 56:6 57:42 58:1538 59:863 60:345 61:1810 62:1491 63:1921 64:4478 65:2146 66:4247 67:2165 68:1087 69:3245 70:1101 71:466 72:1990 74:2543 75:343 76:346 77:1382 78:1257 79:844 80:1274 81:1378 82:931 83:695 84:814 85:1578 86:474 87:1053 88:560 89:1991 90:169 91:6074 92:899 93:2340 94:2339 95:2310 96:502 97:359 98:934 99:46 100:74 101:1052 103:10614 104:2419 105:124 106:396 107:1165 108:667 109:2185 110:1251 111:1650 112:972 113:1144 114:1045 115:1549 116:1576 117:1430 118:2055 119:1623 120:931 121:1172 122:2182 123:2012 124:1567 125:1723 128:682 129:396 130:406 131:1343 132:635 133:174 134:454 135:126 136:374 137:345 138:1743 139:255 140:541 141:458 142:641 143:950 144:668 145:156 146:869 147:651 148:1466 149:503 150:645 151:882 152:618 153:280 154:613 155:946 156:495 157:430 158:358 159:1113 160:478 161:741 162:2320 163:560 164:900 165:1053 166:317 167:1155 168:1767 169:652 170:1574 171:264 172:546 173:1633 174:738 175:734 176:1720 177:3983 178:2207 179:1147 180:2059 181:1753 182:1892 183:938 184:803 185:6405 186:3135 187:2136 188:2133 189:1736 190:7755 191:1248 192:8941 193:5725 194:4374 195:3765 196:1701 197:1057 198:5540 199:5702 200:6951 201:3714 202:10117 203:9625 204:4518 205:2713 206:2974 207:3097 208:4042 209:3819 210:3913 211:2049 212:2705 213:2241 214:847 215:72 216:5791 217:1920 218:792 219:578 220:1676 221:870 222:658 223:1217 End of report From mark.tinka at seacom.mu Fri May 6 18:14:53 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 20:14:53 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CDCEE.8010301@gmail.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> Message-ID: <05781bd5-d6c0-964b-ece3-cd00989d2f23@seacom.mu> On 6/May/16 20:05, Aris Lambrianidis wrote: > It still doesn't detract from the value of what people are aware of, in > this case, > pfSense code quality. But the beauty is that with pfSense, you can do something about it, as someone knowledgeable in coding. Preferring a close source option because you can't see how potentially bad their code is is not a necessarily better position to be in. Mark. From mark.tinka at seacom.mu Fri May 6 18:15:12 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 20:15:12 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CDCEE.8010301@gmail.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> Message-ID: <3906855d-59ef-4bf8-ad53-026c8f0a5ba5@seacom.mu> On 6/May/16 20:05, Aris Lambrianidis wrote: > It still doesn't detract from the value of what people are aware of, in > this case, > pfSense code quality. But the beauty is that with pfSense, you can do something about it, as someone knowledgeable in coding. Preferring a closed source option because you can't see how potentially bad their code is is not a necessarily better position to be in. Mark. From mel at beckman.org Fri May 6 18:29:31 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 6 May 2016 18:29:31 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CDCEE.8010301@gmail.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> Message-ID: The question of code quality is always a difficult one, since in FOSS it?s public and often found lacking, but in private source you may never know. In these cases I rely on the vendor?s public statements about their development processes and certifications (e.g., ICSA). Commercial products often disclose their development processes and even run in-house security threat research groups that publish to the community. There are also outside certifications. For example, www.icsalabs.com lists certifications by vendor for those that have passed their test regimen, and both Dell SonicWall and Fortinet Fortigate are shown to be current. PFSense isn?t listed, and although it is theoretically vetted by many users, there is no guarantee of recency or thoroughness of the test regimen. This brings up the question of whether PFSense can meet regulatory requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory organizations don?t require specific overall firewall certifications, they do require various specific standards, such as encryption strength, logging, VPN timeouts, etc. I don?t know if PFsense meets these requirements, as they don?t say so on their site. Companies like Dell publish white papers on their compliance with each regulatory organization. -mel On May 6, 2016, at 11:05 AM, Aris Lambrianidis > wrote: amuse wrote: One question I have is: Is there any reason to believe that the source code for Sonicwall, Cisco, etc are any better than the PFSense code? Or are we just able to see the PFSense code and make unfounded assumptions that the commercial code is in better shape? Perhaps not. In fact, probably not, judging by the apparent lack of audit processes for say, OpenSSL libraries re-used in commercial products. It still doesn't detract from the value of what people are aware of, in this case, pfSense code quality. Aris From keiths at neilltech.com Fri May 6 18:41:40 2016 From: keiths at neilltech.com (Keith Stokes) Date: Fri, 6 May 2016 18:41:40 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com>, Message-ID: <010AD2B9-179E-4296-9FBF-12E5E2B61E91@neilltech.com> I've been told by various PCI auditors that a noncommercial/FOSS firewall could pass as long as you have implemented the necessary controls such as encryption/logging/management and passing actual testing. -- Keith Stokes > On May 6, 2016, at 1:31 PM, Mel Beckman wrote: > > The question of code quality is always a difficult one, since in FOSS it?s public and often found lacking, but in private source you may never know. In these cases I rely on the vendor?s public statements about their development processes and certifications (e.g., ICSA). Commercial products often disclose their development processes and even run in-house security threat research groups that publish to the community. > > There are also outside certifications. For example, www.icsalabs.com lists certifications by vendor for those that have passed their test regimen, and both Dell SonicWall and Fortinet Fortigate are shown to be current. PFSense isn?t listed, and although it is theoretically vetted by many users, there is no guarantee of recency or thoroughness of the test regimen. > > This brings up the question of whether PFSense can meet regulatory requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory organizations don?t require specific overall firewall certifications, they do require various specific standards, such as encryption strength, logging, VPN timeouts, etc. I don?t know if PFsense meets these requirements, as they don?t say so on their site. Companies like Dell publish white papers on their compliance with each regulatory organization. > > -mel > > > On May 6, 2016, at 11:05 AM, Aris Lambrianidis > wrote: > > amuse wrote: > One question I have is: Is there any reason to believe that the source > code for Sonicwall, Cisco, etc are any better than the PFSense code? Or > are we just able to see the PFSense code and make unfounded assumptions > that the commercial code is in better shape? > Perhaps not. In fact, probably not, judging by the apparent lack of > audit processes for say, > OpenSSL libraries re-used in commercial products. > > It still doesn't detract from the value of what people are aware of, in > this case, > pfSense code quality. > > Aris > From nanog-amuse at foofus.com Fri May 6 18:45:36 2016 From: nanog-amuse at foofus.com (amuse) Date: Fri, 6 May 2016 11:45:36 -0700 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <010AD2B9-179E-4296-9FBF-12E5E2B61E91@neilltech.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <010AD2B9-179E-4296-9FBF-12E5E2B61E91@neilltech.com> Message-ID: Don't forget ponying up the fees and charges for paying the auditors - which is why most OSS projects don't end up going through them. On Fri, May 6, 2016 at 11:41 AM, Keith Stokes wrote: > I've been told by various PCI auditors that a noncommercial/FOSS firewall > could pass as long as you have implemented the necessary controls such as > encryption/logging/management and passing actual testing. > > -- > > Keith Stokes > > > On May 6, 2016, at 1:31 PM, Mel Beckman wrote: > > > > The question of code quality is always a difficult one, since in FOSS > it?s public and often found lacking, but in private source you may never > know. In these cases I rely on the vendor?s public statements about their > development processes and certifications (e.g., ICSA). Commercial products > often disclose their development processes and even run in-house security > threat research groups that publish to the community. > > > > There are also outside certifications. For example, www.icsalabs.com< > http://www.icsalabs.com> lists certifications by vendor for those that > have passed their test regimen, and both Dell SonicWall and Fortinet > Fortigate are shown to be current. PFSense isn?t listed, and although it is > theoretically vetted by many users, there is no guarantee of recency or > thoroughness of the test regimen. > > > > This brings up the question of whether PFSense can meet regulatory > requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory > organizations don?t require specific overall firewall certifications, they > do require various specific standards, such as encryption strength, > logging, VPN timeouts, etc. I don?t know if PFsense meets these > requirements, as they don?t say so on their site. Companies like Dell > publish white papers on their compliance with each regulatory organization. > > > > -mel > > > > > > On May 6, 2016, at 11:05 AM, Aris Lambrianidis > wrote: > > > > amuse wrote: > > One question I have is: Is there any reason to believe that the source > > code for Sonicwall, Cisco, etc are any better than the PFSense code? Or > > are we just able to see the PFSense code and make unfounded assumptions > > that the commercial code is in better shape? > > Perhaps not. In fact, probably not, judging by the apparent lack of > > audit processes for say, > > OpenSSL libraries re-used in commercial products. > > > > It still doesn't detract from the value of what people are aware of, in > > this case, > > pfSense code quality. > > > > Aris > > > From effulgence at gmail.com Fri May 6 18:50:36 2016 From: effulgence at gmail.com (Aris Lambrianidis) Date: Fri, 06 May 2016 20:50:36 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> Message-ID: <572CE77C.2050905@gmail.com> Mel Beckman wrote: > The question of code quality is always a difficult one, since in FOSS > it?s public and often found lacking, but in private source you may > never know. In these cases I rely on the vendor?s public statements > about their development processes and certifications (e.g., ICSA). > Commercial products often disclose their development processes and > even run in-house security threat research groups that publish to the > community. > > There are also outside certifications. For example, www.icsalabs.com > lists certifications by vendor for those > that have passed their test regimen, and both Dell SonicWall and > Fortinet Fortigate are shown to be current. PFSense isn?t listed, and > although it is theoretically vetted by many users, there is no > guarantee of recency or thoroughness of the test regimen. > > This brings up the question of whether PFSense can meet regulatory > requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory > organizations don?t require specific overall firewall certifications, > they do require various specific standards, such as encryption > strength, logging, VPN timeouts, etc. I don?t know if PFsense meets > these requirements, as they don?t say so on their site. Companies like > Dell publish white papers on their compliance with each regulatory > organization. It seems those certifications are not offering the assurance at least *some* people would expect from them, unless of course we're talking about feeding the paper pushing beast. This is a mere observation on my part, principally I'm not against them, but I seriously doubt bad coding practices happen only on non certified/audited code, so I find the question of value difficult to answer in a satisfactory manner. Random germane example: http://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips Aris From mel at beckman.org Fri May 6 19:20:02 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 6 May 2016 19:20:02 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CE77C.2050905@gmail.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> Message-ID: But bug reports and response can be measured, at least by those with support contracts for the commercial products. I found PFSense less reliable by a quite large margin than commercial offerings. Plus when I have a problem, I can open a case and somebody else is working on it (because I paid them to), and they usually solve the problem without a lot more involvement on my part. I tried PFSense Premium Support once when it first launched, and they simply didn?t have their act together. Also, the cheapest PFSense support contract cost nearly as much as an entire commercial firewall including hardware and a year support! Maybe they?ve improved. I don?t have time to research it though, as the commercial products are quite reasonably priced and generally superior in features. I?ve also looked at the PFSense appliances for sale, and they are not remarkable (either in price or features). I think what store.pfsense.org demonstrates is that the commercial offerings are justified in what they charge, since it?s about equal to what PFSense hardware costs. Then there is the available skills problem. It?s much easier to find a Cisco, Dell, Juniper, or whatever-conversant tech than it is to find someone facile in PFSense. It?s a valiant effort, but to me the value differential just isn?t making sense for PFSense. -mel On May 6, 2016, at 11:50 AM, Aris Lambrianidis > wrote: Mel Beckman wrote: The question of code quality is always a difficult one, since in FOSS it?s public and often found lacking, but in private source you may never know. In these cases I rely on the vendor?s public statements about their development processes and certifications (e.g., ICSA). Commercial products often disclose their development processes and even run in-house security threat research groups that publish to the community. There are also outside certifications. For example, www.icsalabs.com lists certifications by vendor for those that have passed their test regimen, and both Dell SonicWall and Fortinet Fortigate are shown to be current. PFSense isn?t listed, and although it is theoretically vetted by many users, there is no guarantee of recency or thoroughness of the test regimen. This brings up the question of whether PFSense can meet regulatory requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory organizations don?t require specific overall firewall certifications, they do require various specific standards, such as encryption strength, logging, VPN timeouts, etc. I don?t know if PFsense meets these requirements, as they don?t say so on their site. Companies like Dell publish white papers on their compliance with each regulatory organization. It seems those certifications are not offering the assurance at least *some* people would expect from them, unless of course we're talking about feeding the paper pushing beast. This is a mere observation on my part, principally I'm not against them, but I seriously doubt bad coding practices happen only on non certified/audited code, so I find the question of value difficult to answer in a satisfactory manner. Random germane example: http://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips Aris From effulgence at gmail.com Fri May 6 19:34:10 2016 From: effulgence at gmail.com (Aris Lambrianidis) Date: Fri, 06 May 2016 21:34:10 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> Message-ID: <572CF1B2.4060204@gmail.com> Mel Beckman wrote: > But bug reports and response can be measured, at least by those with > support contracts for the commercial products. I found PFSense less > reliable by a quite large margin than commercial offerings. Plus when > I have a problem, I can open a case and somebody else is working on it > (because I paid them to), and they usually solve the problem without a > lot more involvement on my part. Valid points, my intention was to share my thoughts on certification and audit processes in general, and I guess in the process derail the thread a bit. Back to pfSense, arguably the point you raise is even stronger than the "bad coding practices" one. I might even say I personally don't care much about coding practices as I care about support services being prompt and effective. The latter *may* actually lead to good coding practices, but not the other way around. Aris From josh at kyneticwifi.com Fri May 6 19:40:07 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 6 May 2016 14:40:07 -0500 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <572CF1B2.4060204@gmail.com> References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> <572CF1B2.4060204@gmail.com> Message-ID: I've been very happy with the 2.3 release. Modularizing everything and the new bootstrap GUI is very nice. Updated BSD code base is a godsend. On May 6, 2016 2:36 PM, "Aris Lambrianidis" wrote: > Mel Beckman wrote: > >> But bug reports and response can be measured, at least by those with >> support contracts for the commercial products. I found PFSense less >> reliable by a quite large margin than commercial offerings. Plus when I >> have a problem, I can open a case and somebody else is working on it >> (because I paid them to), and they usually solve the problem without a lot >> more involvement on my part. >> > Valid points, my intention was to share my thoughts on certification and > audit processes in general, and I guess in the process derail the thread a > bit. > > Back to pfSense, arguably the point you raise is even stronger than the > "bad coding practices" one. I might even say I personally don't care much > about coding practices as I care about support services being prompt and > effective. The latter > *may* actually lead to good coding practices, but not the other way around. > > Aris > From mark.tinka at seacom.mu Fri May 6 19:51:15 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 6 May 2016 21:51:15 +0200 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> <572CF1B2.4060204@gmail.com> Message-ID: On 6/May/16 21:40, Josh Reynolds wrote: > I've been very happy with the 2.3 release. Modularizing everything and the > new bootstrap GUI is very nice. Updated BSD code base is a godsend. I was just about to ask the experienced coders whether the new GUI in 2.3 fixes a lot of problems of the past... And yes, 2.3 is running FreeBSD 10.3. Mark. From keiths at neilltech.com Fri May 6 21:53:52 2016 From: keiths at neilltech.com (Keith Stokes) Date: Fri, 6 May 2016 21:53:52 +0000 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <20160505175348.GU19521@sizone.org> <572BE2CC.5090401@1337.io> <0da23fa4-f5e1-983e-ca4c-91234b7e2b64@seacom.mu> <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <010AD2B9-179E-4296-9FBF-12E5E2B61E91@neilltech.com> Message-ID: PCI certification at the business level isn?t about whether your firewall vendor has gone through an audit and paid someone. You can build your own firewall if you wish and it must meet all of the necessary requirements. So will a commercial firewall, because it?s certainly possible to configure anyone?s firewall in an insecure manner. In fact, my name brand expensive firewall automatically fails the regular security scans because it answers ISAKMP. When asked, and it took awhile to get the truth, the answer was ?We automatically flag because ISAMKP can be configured insecurely, so we automatically flag.? Showing my config wasn?t insecure got me a green light. On May 6, 2016, at 1:45 PM, amuse > wrote: Don't forget ponying up the fees and charges for paying the auditors - which is why most OSS projects don't end up going through them. On Fri, May 6, 2016 at 11:41 AM, Keith Stokes > wrote: I've been told by various PCI auditors that a noncommercial/FOSS firewall could pass as long as you have implemented the necessary controls such as encryption/logging/management and passing actual testing. -- Keith Stokes > On May 6, 2016, at 1:31 PM, Mel Beckman > wrote: > > The question of code quality is always a difficult one, since in FOSS it?s public and often found lacking, but in private source you may never know. In these cases I rely on the vendor?s public statements about their development processes and certifications (e.g., ICSA). Commercial products often disclose their development processes and even run in-house security threat research groups that publish to the community. > > There are also outside certifications. For example, www.icsalabs.com> lists certifications by vendor for those that have passed their test regimen, and both Dell SonicWall and Fortinet Fortigate are shown to be current. PFSense isn?t listed, and although it is theoretically vetted by many users, there is no guarantee of recency or thoroughness of the test regimen. > > This brings up the question of whether PFSense can meet regulatory requirements such as PCI, HIPAA, GLBA and SOX. While these regulatory organizations don?t require specific overall firewall certifications, they do require various specific standards, such as encryption strength, logging, VPN timeouts, etc. I don?t know if PFsense meets these requirements, as they don?t say so on their site. Companies like Dell publish white papers on their compliance with each regulatory organization. > > -mel > > > On May 6, 2016, at 11:05 AM, Aris Lambrianidis >> wrote: > > amuse wrote: > One question I have is: Is there any reason to believe that the source > code for Sonicwall, Cisco, etc are any better than the PFSense code? Or > are we just able to see the PFSense code and make unfounded assumptions > that the commercial code is in better shape? > Perhaps not. In fact, probably not, judging by the apparent lack of > audit processes for say, > OpenSSL libraries re-used in commercial products. > > It still doesn't detract from the value of what people are aware of, in > this case, > pfSense code quality. > > Aris > --- Keith Stokes From dwhite at olp.net Fri May 6 21:54:52 2016 From: dwhite at olp.net (Dan White) Date: Fri, 6 May 2016 16:54:52 -0500 Subject: HBO Go Contact Message-ID: <20160506215452.GD4295@dan.olp.net> Please contact me off list regarding a geolocation error. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From rea+nanog at grid.kiae.ru Sun May 8 16:41:23 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Sun, 8 May 2016 19:41:23 +0300 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: References: <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> <572CF1B2.4060204@gmail.com> Message-ID: <20160508164123.GD5015light.codelabs.ru@light.codelabs.ru> Fri, May 06, 2016 at 09:51:15PM +0200, Mark Tinka wrote: > On 6/May/16 21:40, Josh Reynolds wrote: > > I've been very happy with the 2.3 release. Modularizing everything and the > > new bootstrap GUI is very nice. Updated BSD code base is a godsend. > > I was just about to ask the experienced coders whether the new GUI in > 2.3 fixes a lot of problems of the past... > > And yes, 2.3 is running FreeBSD 10.3. Just use FreeBSD without pfSense stuff -- it is easier ;)) Modulo the absence of the network-based installation for FreeBSD via PXE [1] out of the box (well, it is doable, but I'd prefer to have an easier way and Linuxen have that), so large-scale stuff is a bit tough. Was discussed several times in FBSD lists, big players have their own homegrown stuff from the early days of the universe, others are either not doing that or relying on the existing recipes. And there are not sufficient others of the big $SCALE :( [1] Something I'm trying to find the time for the past 5-6 years, should finally do that. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From greg at gregsowell.com Mon May 9 14:52:28 2016 From: greg at gregsowell.com (Greg Sowell) Date: Mon, 9 May 2016 09:52:28 -0500 Subject: sub $500-750 CPE firewall for voip-centric application In-Reply-To: <20160508164123.GD5015light.codelabs.ru@light.codelabs.ru> References: <572CC52A.9090905@foobar.org> <572CDCEE.8010301@gmail.com> <572CE77C.2050905@gmail.com> <572CF1B2.4060204@gmail.com> <20160508164123.GD5015light.codelabs.ru@light.codelabs.ru> Message-ID: +1 for mikrotik, been solid cpe for ages. I know a lot of msps using fortigates also. On May 8, 2016 11:43 AM, "Eygene Ryabinkin" wrote: > Fri, May 06, 2016 at 09:51:15PM +0200, Mark Tinka wrote: > > On 6/May/16 21:40, Josh Reynolds wrote: > > > I've been very happy with the 2.3 release. Modularizing everything and > the > > > new bootstrap GUI is very nice. Updated BSD code base is a godsend. > > > > I was just about to ask the experienced coders whether the new GUI in > > 2.3 fixes a lot of problems of the past... > > > > And yes, 2.3 is running FreeBSD 10.3. > > Just use FreeBSD without pfSense stuff -- it is easier ;)) Modulo the > absence of the network-based installation for FreeBSD via PXE [1] out > of the box (well, it is doable, but I'd prefer to have an easier way > and Linuxen have that), so large-scale stuff is a bit tough. Was > discussed several times in FBSD lists, big players have their own > homegrown stuff from the early days of the universe, others are either > not doing that or relying on the existing recipes. And there are not > sufficient others of the big $SCALE :( > > > [1] Something I'm trying to find the time for the past 5-6 years, > should finally do that. > > -- > Eygene Ryabinkin, National Research Centre "Kurchatov Institute" > > Always code as if the guy who ends up maintaining your code will be > a violent psychopath who knows where you live. > From jhaustin at gmail.com Mon May 9 20:00:10 2016 From: jhaustin at gmail.com (Jeremy Austin) Date: Mon, 9 May 2016 12:00:10 -0800 Subject: CALEA In-Reply-To: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Message-ID: On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: > What is the community hearing about CALEA? > Crickets? -- Jeremy Austin (907) 895-2311 (907) 803-5422 jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon From freetexwatson at gmail.com Tue May 10 03:01:23 2016 From: freetexwatson at gmail.com (b f) Date: Mon, 9 May 2016 23:01:23 -0400 Subject: NIST NTP servers Message-ID: Hello List, In search of stable, disparate stratum 1 NTP sources. Looking for anyone?s advice/experiences (good/bad/ugly/weird) using NIST?s NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi We tried using ?time.nist.gov? which returns varying round-robin addresses (as the link says), but Cisco IOS resolved the FQDN and embedded the numeric address in the ?ntp server? config statement. After letting the new server config go through a few days of update cycles, the drift, offset and reachability stats are not anywhere as good as what the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. I would greatly appreciate and feedback / advice, etc. Thanks!!! Ed From mel at beckman.org Tue May 10 03:08:16 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 10 May 2016 03:08:16 +0000 Subject: NIST NTP servers In-Reply-To: References: Message-ID: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> NTP has vulnerabilities that make it generally unsuitable for provider networks. I strongly recommend getting a GPS-based time server. These are as cheap as $300. Here is one I use quite a bit: http://www.amazon.com/TM1000A-GPS-Network-Time-Server/dp/B002RC3Q4Q You?ll have a stratum 1 clock on site. Hard to beat. -mel On May 9, 2016, at 8:01 PM, b f > wrote: Hello List, In search of stable, disparate stratum 1 NTP sources. Looking for anyone?s advice/experiences (good/bad/ugly/weird) using NIST?s NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi We tried using ?time.nist.gov? which returns varying round-robin addresses (as the link says), but Cisco IOS resolved the FQDN and embedded the numeric address in the ?ntp server? config statement. After letting the new server config go through a few days of update cycles, the drift, offset and reachability stats are not anywhere as good as what the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. I would greatly appreciate and feedback / advice, etc. Thanks!!! Ed From krux702 at gmail.com Mon May 9 19:49:20 2016 From: krux702 at gmail.com (krux) Date: Mon, 9 May 2016 12:49:20 -0700 Subject: Patch panel solutions for 4x10GE breakout In-Reply-To: References: <6CD354CF-6553-4F6C-82B7-BD951FD66B87@gmail.com> <12672D4F-3AC1-4D89-A2A1-19AFD7D924F3@puck.nether.net> Message-ID: The Corning Edge stuff is nice. Very modular, so you can customize it for your needs. And from my experience, it's proven to be designed well. Makes it easy to slide individual trays out to work on. And the built in shutters on the LC connectors instead of the dust caps are a nice touch, since no one remembers to put the dust caps back. On Thu, May 5, 2016 at 7:59 AM, Shawn Morris wrote: > It's the Corning Edge8 line [ > > https://www.corning.com/worldwide/en/products/communication-networks/applications/data-center/edge8.html > ] > > On Thu, May 5, 2016 at 9:45 AM, Jared Mauch wrote: > > > There is a nice Corning panel our facilities team is using now. I can > find > > the link and send it to the list when not at my phone. > > > > Jared Mauch > > > > > On May 5, 2016, at 10:28 AM, Phil Bedard > wrote: > > > > > > So the newer equipment we are looking at uses QSFP+/MTP with 4x10GE > > breakouts to deliver 10G. We are not wiring these up to things in the > same > > rack, they will be going to patch panels and then elsewhere in a > facility. > > It could potentially get messy with the panels we have today so we are > > looking at other solutions. These are all SM LR connections using LC. > > There are a lot of SM MTP to LC options since that?s the way most panels > > are wired, but they typically have 6 duplex LC connectors per MTP and > not 4 > > which isn?t very efficient in this use case. I?ve seen others just use > an > > intermediate LC to LC panel and just wire the breakouts to those and then > > jumper the other side elsewhere. > > > > > > Anything else others have used? The point of the solution is to keep > > the wiring mess in front of or near the device to a minimum. > > > > > > Thanks, > > > > > > Phil > > > > > > > > -- perl -e 's++=END;++y(;-P)}\n?k++=;<+xru}?print:??;' From greg at gregsowell.com Mon May 9 20:10:30 2016 From: greg at gregsowell.com (Greg Sowell) Date: Mon, 9 May 2016 15:10:30 -0500 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Message-ID: I haven't had a request in ages...back then all of the links worked. On May 9, 2016 3:02 PM, "Jeremy Austin" wrote: > On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: > > > What is the community hearing about CALEA? > > > > Crickets? > > > -- > Jeremy Austin > > (907) 895-2311 > (907) 803-5422 > jhaustin at gmail.com > > Heritage NetWorks > Whitestone Power & Communications > Vertical Broadband, LLC > > Schedule a meeting: http://doodle.com/jermudgeon > From sryan at arbor.net Tue May 10 03:09:33 2016 From: sryan at arbor.net (Spencer Ryan) Date: Mon, 9 May 2016 23:09:33 -0400 Subject: NIST NTP servers In-Reply-To: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> Message-ID: I would second the idea of using your own GPS appliance if possible. On May 9, 2016 11:08 PM, "Mel Beckman" wrote: > NTP has vulnerabilities that make it generally unsuitable for provider > networks. I strongly recommend getting a GPS-based time server. These are > as cheap as $300. Here is one I use quite a bit: > > http://www.amazon.com/TM1000A-GPS-Network-Time-Server/dp/B002RC3Q4Q > > You?ll have a stratum 1 clock on site. Hard to beat. > > -mel > > On May 9, 2016, at 8:01 PM, b f freetexwatson at gmail.com>> wrote: > > Hello List, > > > In search of stable, disparate stratum 1 NTP sources. > > Looking for anyone?s advice/experiences (good/bad/ugly/weird) using NIST?s > NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi > > We tried using ?time.nist.gov? which returns > varying round-robin addresses > (as the link says), but Cisco IOS resolved the FQDN and embedded the > numeric address in the ?ntp server? config statement. > > > > After letting the new server config go through a few days of update cycles, > the drift, offset and reachability stats are not anywhere as good as what > the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. > > > I would greatly appreciate and feedback / advice, etc. > > > Thanks!!! > > > Ed > > From msa at latt.net Tue May 10 03:12:22 2016 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 9 May 2016 23:12:22 -0400 Subject: NIST NTP servers In-Reply-To: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> Message-ID: <20160510031222.GA6790@puck.nether.net> On Tue, May 10, 2016 at 03:08:16AM +0000, Mel Beckman wrote: > NTP has vulnerabilities that make it generally unsuitable for > provider networks. I strongly recommend getting a GPS-based > time server. These are as cheap as $300. Here is one I use quite a bit: So how does this stop from distributing time to their customers via NTP? GPS doesn't save the protocol, in particular where the S1 clocks involved are embedded devices with rather coarse clocks and timestamping. --msa From ag4ve.us at gmail.com Tue May 10 04:02:07 2016 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 10 May 2016 00:02:07 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Message-ID: The OP is also asking someone to register a throwaway email, subscribe, and respond "yes" so that the owner can't be tracked to their employer. That's kind of a steep ask for something that's almost moot. On May 9, 2016 23:16, "Greg Sowell" wrote: I haven't had a request in ages...back then all of the links worked. On May 9, 2016 3:02 PM, "Jeremy Austin" wrote: > On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: > > > What is the community hearing about CALEA? > > > > Crickets? > > > -- > Jeremy Austin > > (907) 895-2311 > (907) 803-5422 > jhaustin at gmail.com > > Heritage NetWorks > Whitestone Power & Communications > Vertical Broadband, LLC > > Schedule a meeting: http://doodle.com/jermudgeon > From josh at kyneticwifi.com Tue May 10 04:34:48 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 9 May 2016 23:34:48 -0500 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Message-ID: Hrm? On May 9, 2016 11:04 PM, "shawn wilson" wrote: > The OP is also asking someone to register a throwaway email, subscribe, and > respond "yes" so that the owner can't be tracked to their employer. That's > kind of a steep ask for something that's almost moot. > On May 9, 2016 23:16, "Greg Sowell" wrote: > > I haven't had a request in ages...back then all of the links worked. > On May 9, 2016 3:02 PM, "Jeremy Austin" wrote: > > > On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: > > > > > What is the community hearing about CALEA? > > > > > > > Crickets? > > > > > > -- > > Jeremy Austin > > > > (907) 895-2311 > > (907) 803-5422 > > jhaustin at gmail.com > > > > Heritage NetWorks > > Whitestone Power & Communications > > Vertical Broadband, LLC > > > > Schedule a meeting: http://doodle.com/jermudgeon > > > From mianosm at gmail.com Tue May 10 10:48:52 2016 From: mianosm at gmail.com (Steven Miano) Date: Tue, 10 May 2016 06:48:52 -0400 Subject: NIST NTP servers In-Reply-To: <20160510031222.GA6790@puck.nether.net> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> Message-ID: NTP has vulnerabilities, so using an external source opens your networks and infrastructure to disruptions. Going with an internal GPS/GLONASS/RADIO based S1 allows you to restrict incoming traffic and not rely on volunteers or external entities (which may undergo maintenance or budget issues). My preference is more so something akin to the GLN180PEX (I am not affiliated or paid to endorse this product). It allows you to use commodity hardware (like a decommissioned 1U or several preferably) and creation of ones own reliable internal time source(s). Introducing black boxes into a production (revenue generation or expected services by paying customers) environment is undesirable. >From there setting up NTPd, Chronyd, and PTPd is up to you. Relying on satellites may seem like just another external reliance, but the next life is proposing a design life of 12 years..... On Mon, May 9, 2016 at 11:12 PM, Majdi S. Abbas wrote: > On Tue, May 10, 2016 at 03:08:16AM +0000, Mel Beckman wrote: > > NTP has vulnerabilities that make it generally unsuitable for > > provider networks. I strongly recommend getting a GPS-based > > time server. These are as cheap as $300. Here is one I use quite a bit: > > So how does this stop from distributing time to their > customers via NTP? > > GPS doesn't save the protocol, in particular where the S1 > clocks involved are embedded devices with rather coarse clocks and > timestamping. > > --msa > -- Miano, Steven M. http://stevenmiano.com From chuckchurch at gmail.com Tue May 10 14:29:35 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 10 May 2016 10:29:35 -0400 Subject: NIST NTP servers In-Reply-To: <20160510031222.GA6790@puck.nether.net> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> Message-ID: <04a201d1aac8$6320f360$2962da20$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Majdi S. Abbas > So how does this stop from distributing time to their customers via NTP? > GPS doesn't save the protocol, in particular where the S1 clocks involved are embedded devices with rather coarse clocks and timestamping. > --msa It doesn't really. Granted there are a lot of CVEs coming out for NTP the last year or so. But I just don't think there are that many attacks on it. It's just not worth the effort. Changing time on devices is more an annoyance than anything, and doesn't necessarily get you into a device. Sure you can hide your tracks a little by altering time in logs and altering it back, but that's more of an in-depth nation-state kind of attack, not going to be a script kiddie kind of thing. Just follow the best practices for verifying packet sources and NTP security itself, and you should be ok. Chuck From bortzmeyer at nic.fr Tue May 10 14:39:54 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 May 2016 16:39:54 +0200 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> Message-ID: <20160510143954.GA27288@nic.fr> On Tue, May 10, 2016 at 06:48:52AM -0400, Steven Miano wrote a message of 41 lines which said: > Going with an internal GPS/GLONASS/RADIO based S1 allows you to > restrict incoming traffic and not rely on volunteers or external > entities (which may undergo maintenance or budget issues). You mean the GPS network is not managed by an external entity? With budget issues? http://www.schriever.af.mil/GPS From Valdis.Kletnieks at vt.edu Tue May 10 14:52:28 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 May 2016 10:52:28 -0400 Subject: NIST NTP servers In-Reply-To: <20160510143954.GA27288@nic.fr> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> Message-ID: <7376.1462891948@turing-police.cc.vt.edu> On Tue, 10 May 2016 16:39:54 +0200, Stephane Bortzmeyer said: > You mean the GPS network is not managed by an external entity? With > budget issues? > > http://www.schriever.af.mil/GPS Note that they *do* have motivation to keep it working, simply because so much of their *own* gear (from gear for individual soldiers all the way to strategic bombers and aircraft carriers) wants a working GPS signal... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dhubbard at dino.hostasaurus.com Tue May 10 14:55:42 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 10 May 2016 14:55:42 +0000 Subject: NIST NTP servers In-Reply-To: References: Message-ID: <1A0F313B-0ED7-4E50-9631-6114F6C21761@dino.hostasaurus.com> Ed, and anyone else reading this thread, I?m curious if you?ve looked at their authenticated NTP offering which uses different servers: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm We?re considering that but haven?t tried yet. David On 5/9/16, 11:01 PM, "NANOG on behalf of b f" wrote: >Hello List, > > >In search of stable, disparate stratum 1 NTP sources. > >Looking for anyone?s advice/experiences (good/bad/ugly/weird) using NIST?s >NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi > >We tried using ?time.nist.gov? which returns varying round-robin addresses >(as the link says), but Cisco IOS resolved the FQDN and embedded the >numeric address in the ?ntp server? config statement. > > > >After letting the new server config go through a few days of update cycles, >the drift, offset and reachability stats are not anywhere as good as what >the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. > > >I would greatly appreciate and feedback / advice, etc. > > >Thanks!!! > > >Ed From chuckchurch at gmail.com Tue May 10 14:57:27 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 10 May 2016 10:57:27 -0400 Subject: NIST NTP servers In-Reply-To: <20160510144024.64E96E05D1@smtp.hushmail.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510144024.64E96E05D1@smtp.hushmail.com> Message-ID: <04b501d1aacc$466046a0$d320d3e0$@gmail.com> True, but I did mention verifying packet sources. That needs to happen everywhere, and it's not hard to do. Just getting everyone to do it is tough. Chuck -----Original Message----- From: Allan Liska [mailto:allan at allan.org] Sent: Tuesday, May 10, 2016 10:40 AM To: Chuck Church ; 'Majdi S. Abbas' ; nanog at nanog.org Subject: RE: NIST NTP servers On 5/10/2016 at 10:30 AM, "Chuck Church" wrote: > >It doesn't really. Granted there are a lot of CVEs coming out for NTP >the last year or so. But I just don't think there are that many >attacks on it. >It's just not worth the effort. Changing time on devices is more an >annoyance than anything, and doesn't necessarily get you into a device. >Sure you can hide your tracks a little by altering time in logs and >altering it back, but that's more of an in-depth nation-state kind of >attack, not going to be a script kiddie kind of thing. Just follow the >best practices for verifying packet sources and NTP security itself, >and you should be ok. > >Chuck I would argue that the fact the NTP can, and has been, be used in DDoS amplification attacks is a serious concern for using protocol going forward. allan From bortzmeyer at nic.fr Tue May 10 14:59:02 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 May 2016 16:59:02 +0200 Subject: NIST NTP servers In-Reply-To: <7376.1462891948@turing-police.cc.vt.edu> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> Message-ID: <20160510145902.GA29833@nic.fr> On Tue, May 10, 2016 at 10:52:28AM -0400, Valdis.Kletnieks at vt.edu wrote a message of 37 lines which said: > Note that they *do* have motivation to keep it working, simply > because so much of their *own* gear (from gear for individual > soldiers all the way to strategic bombers and aircraft carriers) > wants a working GPS signal... Yes, but they may switch it off for civilian use (by going encrypted, for instance) at any time, if it is better for *their* operations. From bicknell at ufp.org Tue May 10 15:22:19 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 May 2016 08:22:19 -0700 Subject: NIST NTP servers In-Reply-To: References: Message-ID: <20160510152219.GA32797@ussenterprise.ufp.org> In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: > In search of stable, disparate stratum 1 NTP sources. http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm > We tried using ?time.nist.gov? which returns varying round-robin addresses > (as the link says), but Cisco IOS resolved the FQDN and embedded the > numeric address in the ?ntp server? config statement. Depending on your hardware platform your Cisco Router is likely not a great NTP server. IOS is not designed for hyper-accuracy. > After letting the new server config go through a few days of update cycles, > the drift, offset and reachability stats are not anywhere as good as what > the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. The correct answer here is to run multiple NTP servers in your network. And by servers I mean real servers, with good quality oscellators on the motherboard. Then configure them to talk to _many_ sources. You need 4 sources of time minimum to redundantly detect false tickers. If you're serious about it then find ~10 Stratum 1 sources (ideally authenticated and from trusted entities), one of which could be GPS as several have suggested. You'll then have high quality false ticker rejection. Configure all of your devices to get NTP from the servers you run using authentication. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From josh at kyneticwifi.com Tue May 10 15:23:03 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 10 May 2016 10:23:03 -0500 Subject: NIST NTP servers In-Reply-To: <20160510145902.GA29833@nic.fr> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> <20160510145902.GA29833@nic.fr> Message-ID: That would be a very poor idea, since a lot of the circuits the DoD still uses to communicate with are ATM lines :) On Tue, May 10, 2016 at 9:59 AM, Stephane Bortzmeyer wrote: > On Tue, May 10, 2016 at 10:52:28AM -0400, > Valdis.Kletnieks at vt.edu wrote > a message of 37 lines which said: > >> Note that they *do* have motivation to keep it working, simply >> because so much of their *own* gear (from gear for individual >> soldiers all the way to strategic bombers and aircraft carriers) >> wants a working GPS signal... > > Yes, but they may switch it off for civilian use (by going encrypted, > for instance) at any time, if it is better for *their* operations. > > From Valdis.Kletnieks at vt.edu Tue May 10 15:23:56 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 May 2016 11:23:56 -0400 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> <20160510145902.GA29833@nic.fr> Message-ID: <9767.1462893836@turing-police.cc.vt.edu> On Tue, 10 May 2016 08:07:15 -0700, Brandon Vincent said: > On May 10, 2016 7:59 AM, "Stephane Bortzmeyer" wrote: > > Yes, but they may switch it off for civilian use (by going encrypted, > > for instance) at any time, if it is better for *their* operations. > > I think you are referring to selective availability which degraded the > positional accuracy for civilians. I seem to recall that the positional accuracy is degraded to "on the order of 200 meters" when selective availability is enabled (and yes, they *can* do it by geographic area by careful turning on/off on each orbit of each satellite - devices are told the signal is degraded and can downvote that signal. So unless you're in the war zone, you'll just notice your device reporting a lock on 2-3 fewer signals). The upshot is that Grace Hopper told us about electricity moving a foot per nanosecond - which means that the time-domain jitter introduced is all of 600 nanoseconds or so. In other words, anybody using it to feed an NTP server will hardly notice on the millisecond level. If you're trying to use NTP to get microsecond stability, you'll notice - but you have enough *other* things to do correctly to do this that it shouldn't be an actual issue... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From the.lists at mgm51.com Tue May 10 15:36:47 2016 From: the.lists at mgm51.com (Mike) Date: Tue, 10 May 2016 11:36:47 -0400 Subject: NIST NTP servers In-Reply-To: <20160510152219.GA32797@ussenterprise.ufp.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> Message-ID: <9916a49a-474b-9f35-5e76-2174702b04a1@mgm51.com> On 5/10/2016 11:22 AM, Leo Bicknell wrote: > In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: >> In search of stable, disparate stratum 1 NTP sources. > > http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm > >> We tried using ?time.nist.gov? which returns varying round-robin addresses >> (as the link says), but Cisco IOS resolved the FQDN and embedded the >> numeric address in the ?ntp server? config statement. > > Depending on your hardware platform your Cisco Router is likely not > a great NTP server. IOS is not designed for hyper-accuracy. > >> After letting the new server config go through a few days of update cycles, >> the drift, offset and reachability stats are not anywhere as good as what >> the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. > > The correct answer here is to run multiple NTP servers in your > network. ... >[snip] I think the correct answer here starts with a question --- what level of time accuracy is required for the local NTP server(s)? Which then begs the question, what level of accuracy is needed for the clients? A shop with a client need for nanosecond accuracy begs for an entirely different solution set than a shop where a millisecond of accuracy is needed on the clients, and still a different solution set that a shop where "a few milliseconds either way" is quite OK. From laszlo at heliacal.net Tue May 10 16:08:57 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 10 May 2016 16:08:57 +0000 Subject: NIST NTP servers In-Reply-To: <9916a49a-474b-9f35-5e76-2174702b04a1@mgm51.com> References: <20160510152219.GA32797@ussenterprise.ufp.org> <9916a49a-474b-9f35-5e76-2174702b04a1@mgm51.com> Message-ID: On 2016-05-10 15:36, Mike wrote: > On 5/10/2016 11:22 AM, Leo Bicknell wrote: >> In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: >>> In search of stable, disparate stratum 1 NTP sources. >> http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm >> >>> We tried using ?time.nist.gov? which returns varying round-robin addresses >>> (as the link says), but Cisco IOS resolved the FQDN and embedded the >>> numeric address in the ?ntp server? config statement. >> Depending on your hardware platform your Cisco Router is likely not >> a great NTP server. IOS is not designed for hyper-accuracy. >> >>> After letting the new server config go through a few days of update cycles, >>> the drift, offset and reachability stats are not anywhere as good as what >>> the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. >> The correct answer here is to run multiple NTP servers in your >> network. ... >> [snip] > > I think the correct answer here starts with a question --- what level of > time accuracy is required for the local NTP server(s)? Which then begs > the question, what level of accuracy is needed for the clients? > > A shop with a client need for nanosecond accuracy begs for an entirely > different solution set than a shop where a millisecond of accuracy is > needed on the clients, and still a different solution set that a shop > where "a few milliseconds either way" is quite OK. > > > > You can get pretty nutty with this, and it's fun to do, but regular NTP over the internet is good enough for millisecond accuracy. A default install with pool servers is pretty good. A custom config with a local NTP server (with less, possibly more symmetric network latency) is a little better, but for common sysadmin needs like cron jobs and log correlation, you likely won't notice a difference. I would worry more about having that config distributed correctly and monitoring all your servers to make sure their NTP is healthy, rather than worrying about the source of your NTP sync. The pool servers are fine, and NTP is good at deciding when they're acting up. The computer running NTP doesn't have to be anything special, but beware of VMs - depending on the virtualization type and the guest OS, you may not even be able to get NTP to engage because of the clock instability. Chrony might work better for VMs. For a linux NTP server, I prefer modern Intel CPUs with invariant tsc - linux will use it as a clocksource (cat /sys/devices/system/clocksource/clocksource0/current_clocksource ) . A Raspberry Pi or something in between also works equally well if you're going to be syncing this over a jittery shared network anyway. I would suggest having more than one server, in different locations if you can, and if you're able to supplement with pool servers, add those too. The most likely failure mode you're going to have is that it doesn't work at all because it's not running, it can't correct the local clock because of excess instability, or you lost all network connections. Worrying about whether you have 4 or 8 servers is kind of moot in any of those (much more likely) faults. -Laszlo From hvgeekwtrvl at gmail.com Tue May 10 18:33:31 2016 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 10 May 2016 11:33:31 -0700 Subject: TeamNANOG youtube video seeding Message-ID: First I am thrilled to see older Nanog meetings making it to youtube. Having said that can the people putting up the files put the Nanog meeting number in the title of the videos to make it easier to search and determine relevance? Thanks, james From mattlists at rivervalleyinternet.net Tue May 10 19:50:04 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 10 May 2016 15:50:04 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> Message-ID: <57323B6C.6060703@rivervalleyinternet.net> Perhaps the silence is an indication no one is doing CALEA or knows anything about it? Personally, I can't say I've heard anything about CALEA, seen people trying to sell CALEA appliances, or received a CALEA request in maybe 8 years? On 5/10/16 12:34 AM, Josh Reynolds wrote: > Hrm? > On May 9, 2016 11:04 PM, "shawn wilson" wrote: > >> The OP is also asking someone to register a throwaway email, subscribe, and >> respond "yes" so that the owner can't be tracked to their employer. That's >> kind of a steep ask for something that's almost moot. >> On May 9, 2016 23:16, "Greg Sowell" wrote: >> >> I haven't had a request in ages...back then all of the links worked. >> On May 9, 2016 3:02 PM, "Jeremy Austin" wrote: >> >>> On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: >>> >>>> What is the community hearing about CALEA? >>>> >>> >>> Crickets? >>> >>> >>> -- >>> Jeremy Austin >>> >>> (907) 895-2311 >>> (907) 803-5422 >>> jhaustin at gmail.com >>> >>> Heritage NetWorks >>> Whitestone Power & Communications >>> Vertical Broadband, LLC >>> >>> Schedule a meeting: http://doodle.com/jermudgeon >>> >> From gem at rellim.com Tue May 10 19:58:06 2016 From: gem at rellim.com (Gary E. Miller) Date: Tue, 10 May 2016 12:58:06 -0700 Subject: NIST NTP servers In-Reply-To: <04a201d1aac8$6320f360$2962da20$@gmail.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> Message-ID: <20160510125806.17324e29@spidey.rellim.com> Yo Chuck! On Tue, 10 May 2016 10:29:35 -0400 "Chuck Church" wrote: > Changing time on > devices is more an annoyance than anything, and doesn't necessarily > get you into a device. So, you are not worried about getting DoS'ed? How about you set the time on your server ahead by 5 years. Got any idea what would happen? Most of your passwords would expire. All your SSL certs would expire. All your TOTPs, like Google Authenticator would fail. All your IPSEC tunnels would drop, and refuse to restart. Many of your cron jobs would got nuts, possibly deleting all your logs. Much of your DNSSEC would expire. Many of your backups would be deleted since they 'expired'. Until recently, setting your iPhone to 1 Jan 1970 would brick it. I'm sure there are many more examples, but likely you can no longer log in, via SSH or HTTPS, and your iPhone is dead. I think any of those would qualify as more than an annoyance. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From josh at kyneticwifi.com Tue May 10 20:00:59 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 10 May 2016 15:00:59 -0500 Subject: CALEA In-Reply-To: <57323B6C.6060703@rivervalleyinternet.net> References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: This is a large list that includes many Tier 1 network operators, government agencies, and Fortune 500 network operators. The silence should be telling. On May 10, 2016 2:52 PM, "Matt Hoppes" wrote: > Perhaps the silence is an indication no one is doing CALEA or knows > anything about it? > > Personally, I can't say I've heard anything about CALEA, seen people > trying to sell CALEA appliances, or received a CALEA request in maybe 8 > years? > > On 5/10/16 12:34 AM, Josh Reynolds wrote: > >> Hrm? >> On May 9, 2016 11:04 PM, "shawn wilson" wrote: >> >> The OP is also asking someone to register a throwaway email, subscribe, >>> and >>> respond "yes" so that the owner can't be tracked to their employer. >>> That's >>> kind of a steep ask for something that's almost moot. >>> On May 9, 2016 23:16, "Greg Sowell" wrote: >>> >>> I haven't had a request in ages...back then all of the links worked. >>> On May 9, 2016 3:02 PM, "Jeremy Austin" wrote: >>> >>> On Thu, May 5, 2016 at 4:43 PM, Justin Wilson wrote: >>>> >>>> What is the community hearing about CALEA? >>>>> >>>>> >>>> Crickets? >>>> >>>> >>>> -- >>>> Jeremy Austin >>>> >>>> (907) 895-2311 >>>> (907) 803-5422 >>>> jhaustin at gmail.com >>>> >>>> Heritage NetWorks >>>> Whitestone Power & Communications >>>> Vertical Broadband, LLC >>>> >>>> Schedule a meeting: http://doodle.com/jermudgeon >>>> >>>> >>> From morrowc.lists at gmail.com Tue May 10 20:04:23 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 10 May 2016 16:04:23 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: On Tue, May 10, 2016 at 4:00 PM, Josh Reynolds wrote: > This is a large list that includes many Tier 1 network operators, > government agencies, and Fortune 500 network operators > ?no one gets calea requests because prism gets all requests?? From josh at kyneticwifi.com Tue May 10 20:11:27 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 10 May 2016 15:11:27 -0500 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: The first rule of prism is... *silence* :) On Tue, May 10, 2016 at 3:04 PM, Christopher Morrow wrote: > > > On Tue, May 10, 2016 at 4:00 PM, Josh Reynolds wrote: >> >> This is a large list that includes many Tier 1 network operators, >> government agencies, and Fortune 500 network operators > > > no one gets calea requests because prism gets all requests? > From jared at puck.nether.net Tue May 10 20:18:01 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 May 2016 16:18:01 -0400 Subject: NIST NTP servers In-Reply-To: <20160510125806.17324e29@spidey.rellim.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> Message-ID: <866BF641-92B6-4070-9013-2F70651F57B4@puck.nether.net> > On May 10, 2016, at 3:58 PM, Gary E. Miller wrote: > > I'm sure there are many more examples, but likely you can no longer log > in, via SSH or HTTPS, and your iPhone is dead. I think any of those > would qualify as more than an annoyance. An unnamed vendor has code where if the clock on their router is not set SSH won?t work as the crypto package signature says the package isn?t valid. Many of the not-before and not-after certificate systems have some fairly serious issues. https://www.cs.bu.edu/~goldbe/pub-index.html#NTP is one place to start when it comes to on-path and off-path NTP attacks that can skew clocks. - jared From chuckchurch at gmail.com Tue May 10 20:18:41 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 10 May 2016 16:18:41 -0400 Subject: NIST NTP servers In-Reply-To: <20160510125806.17324e29@spidey.rellim.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> Message-ID: <053e01d1aaf9$26f69d50$74e3d7f0$@gmail.com> -----Original Message----- From: Gary E. Miller [mailto:gem at rellim.com] Sent: Tuesday, May 10, 2016 3:58 PM To: Chuck Church Cc: 'Majdi S. Abbas' ; nanog at nanog.org Subject: Re: NIST NTP servers Yo Chuck! On Tue, 10 May 2016 10:29:35 -0400 "Chuck Church" wrote: > Changing time on > devices is more an annoyance than anything, and doesn't necessarily > get you into a device. So, you are not worried about getting DoS'ed? How about you set the time on your server ahead by 5 years. Got any idea what would happen? Most of your passwords would expire. All your SSL certs would expire. All your TOTPs, like Google Authenticator would fail. All your IPSEC tunnels would drop, and refuse to restart. Many of your cron jobs would got nuts, possibly deleting all your logs. Much of your DNSSEC would expire. Many of your backups would be deleted since they 'expired'. Until recently, setting your iPhone to 1 Jan 1970 would brick it. I'm sure there are many more examples, but likely you can no longer log in, via SSH or HTTPS, and your iPhone is dead. I think any of those would qualify as more than an annoyance. RGDS GARY ---------------------------------------------------------------------------- ---------------------------------------------------------------- Ok, annoyance might have been a little light on the severity wording. Still, modifying all your incoming NTP packets from all your sources to actually get your NTP servers to agree on a bad time is tricky. That is assuming you've got multiple links, multiple sources from multiple organizations (more than 4), they're all authenticated, etc. Even if a criminal was to do all that damage you listed, it still probably doesn't result in obtaining sensitive data or money that would be the main motivators for such extreme hacking. If I had an iPhone, perhaps I'd worry about that as well. But fortunately, not an issue ;) Chuck From stenn at ntp.org Tue May 10 20:21:20 2016 From: stenn at ntp.org (Harlan Stenn) Date: Tue, 10 May 2016 20:21:20 +0000 Subject: NIST NTP servers In-Reply-To: <20160510152219.GA32797@ussenterprise.ufp.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> Message-ID: Leo Bicknell writes: > ... > > The correct answer here is to run multiple NTP servers in your > network. And by servers I mean real servers, with good quality > oscellators on the motherboard. Then configure them to talk to > _many_ sources. You need 4 sources of time minimum to redundantly > detect false tickers. If you're serious about it then find ~10 > Stratum 1 sources (ideally authenticated and from trusted entities), Byzantine General's problem. With 3 sources you can detect *1* false ticker. But if one of those becomes unreachable you only have 2 time sources. Dilemma. With 4 sources you run the risk of 2 going one way, and 2 going another way. This happened to several folks recently, when some sites put NTP servers on the 'net that offered leap-smeared time. That's really a different problem where one of the effects is that it causes "time islands". > one of which could be GPS as several have suggested. You'll then > have high quality false ticker rejection. For extra points, use GPS receivers from different manufacturers, using whatever "variety" you can get for all of the components involved. Are you mounting each GPS receiver inside a coffee can to prevent drive-by jamming? Are the cables properly grounded? Using gas discharge tubes? Periodically tested/inspected? How much fun do you want to have thinking about all of these cases? > Configure all of your devices to get NTP from the servers you run > using authentication. Yes, and properly monitor your ntpd instances. -- Harlan Stenn http://networktimefoundation.org - be a member! From mel at beckman.org Tue May 10 20:23:04 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 10 May 2016 20:23:04 +0000 Subject: NIST NTP servers In-Reply-To: <20160510125806.17324e29@spidey.rellim.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> Message-ID: <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> Accurate time to the millisecond is pretty much essential for any network troubleshooting. Say you want to diagnose a SIP problem. You collect transaction logs from both phones, the VoIP gateway, and the PBX. Now you try to merge them to derive the sequence of events. You NEED millisecond accuracy. But more importantly, Gary is right about the risks. I?ve had several customers receive major NTP DoS attacks using forged source addresses. In today?s Internet, there is very little source address verification (despite several mechanisms being proposed). Everyone relies on the originating network preventing spoofing, but thousands of ISPs ? particularly overseas ? do not do spoof checks. And the issues of NTP pollution are even more dangerous. As Gary notes, changing dates is a risk. A big enough change (say 30 days) would be catastrophic to most accounting systems. A big leap ? a year or more ? could expire software license and disable all kinds of encryption. We haven?t even discussed multi-stage attacks, where NTP is used to disrupt systems at multiple points, and then the attacker storms in and takes over unnoticed during the confusion. All because of misplaced trust in a tiny UDP packet that can worm its way into your network from anywhere on the Internet. I say you?re crazy if you don?t run a GPS-based NTP server, especially given that they cost as little as $300 for very solid gear. Heck, get two or three! -mel > On May 10, 2016, at 12:58 PM, Gary E. Miller wrote: > > Yo Chuck! > > On Tue, 10 May 2016 10:29:35 -0400 > "Chuck Church" wrote: > >> Changing time on >> devices is more an annoyance than anything, and doesn't necessarily >> get you into a device. > > So, you are not worried about getting DoS'ed? > > How about you set the time on your server ahead by 5 years. Got any > idea what would happen? > > Most of your passwords would expire. > > All your SSL certs would expire. > > All your TOTPs, like Google Authenticator would fail. > > All your IPSEC tunnels would drop, and refuse to restart. > > Many of your cron jobs would got nuts, possibly deleting all your logs. > > Much of your DNSSEC would expire. > > Many of your backups would be deleted since they 'expired'. > > Until recently, setting your iPhone to 1 Jan 1970 would brick it. > > I'm sure there are many more examples, but likely you can no longer log > in, via SSH or HTTPS, and your iPhone is dead. I think any of those > would qualify as more than an annoyance. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 From gem at rellim.com Tue May 10 20:24:24 2016 From: gem at rellim.com (Gary E. Miller) Date: Tue, 10 May 2016 13:24:24 -0700 Subject: NIST NTP servers In-Reply-To: <053e01d1aaf9$26f69d50$74e3d7f0$@gmail.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <053e01d1aaf9$26f69d50$74e3d7f0$@gmail.com> Message-ID: <20160510132424.3494a1bf@spidey.rellim.com> Yo Chuck! On Tue, 10 May 2016 16:18:41 -0400 "Chuck Church" wrote: > Ok, annoyance might have been a little light on the severity wording. Yup. > Still, modifying all your incoming NTP packets from all your sources > to actually get your NTP servers to agree on a bad time is tricky. > That is assuming you've got multiple links, multiple sources from > multiple organizations (more than 4), they're all authenticated, > etc. NTP Authentication (autokey) has been broken, and no one used it anyway. If I have a copy of your ntp.conf I can spoof all your chimers. Not hard at all. This is UDP after all. > Even if a criminal was to do all that damage you listed, it > still probably doesn't result in obtaining sensitive data or money > that would be the main motivators for such extreme hacking. Correct, it would just get me fired due to the extended downtime. Or maybe my company just decided to pay the ransom to get un-DoS'ed. I still get fired. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Tue May 10 20:29:26 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 May 2016 16:29:26 -0400 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> Message-ID: <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> > On May 10, 2016, at 4:21 PM, Harlan Stenn wrote: > >> Configure all of your devices to get NTP from the servers you run >> using authentication. > > Yes, and properly monitor your ntpd instances. And upgrade them. Some software distributors don?t ship modern software. if you are using a distribution packaged ntpd it?s likely old and difficult to determine its lineage due to how it?s packaged. If you?re using Redhat based systems consider using chrony instead, even the new beta fedora 24 uses 4.2.6 derived code vs 4.2.8 - Jared From gem at rellim.com Tue May 10 20:40:40 2016 From: gem at rellim.com (Gary E. Miller) Date: Tue, 10 May 2016 13:40:40 -0700 Subject: NIST NTP servers In-Reply-To: <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> Message-ID: <20160510134040.60c35755@spidey.rellim.com> Yo Jared! On Tue, 10 May 2016 16:29:26 -0400 Jared Mauch wrote: > If you?re using Redhat based systems consider using chrony > instead, even the new beta fedora 24 uses 4.2.6 derived code > vs 4.2.8 Or, new but under heavy development: NTPsec : https://www.ntpsec.org/ It is a fork of classic NTPD, but was not vulnerable to most of the recent NTPD CVEs. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Tue May 10 20:51:25 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 May 2016 16:51:25 -0400 Subject: NIST NTP servers In-Reply-To: <20160510134040.60c35755@spidey.rellim.com> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> Message-ID: <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> > On May 10, 2016, at 4:40 PM, Gary E. Miller wrote: > > Yo Jared! > Yo, Gary! > On Tue, 10 May 2016 16:29:26 -0400 > Jared Mauch wrote: > >> If you?re using Redhat based systems consider using chrony >> instead, even the new beta fedora 24 uses 4.2.6 derived code >> vs 4.2.8 > > Or, new but under heavy development: NTPsec : https://www.ntpsec.org/ > > It is a fork of classic NTPD, but was not vulnerable to most of the > recent NTPD CVEs. Yeah, there are some issues here in how the NTP community has implemented solutions without discussing with each other through the community splits. The NTPWG at IETF has been in a bit of stasis for years now because the various aspects of how it works, and those who present sometimes don?t output in the most organized fashion requiring a lot of effort on the receiver. There?s also a very narrow universe of people who actually care about the implementations and details, with people like Majdi, Harlan and Miroslav understanding the needs more than I?ve seen anyone from the ntpsec/cisco funded side grasp the nuances of. As a general statement, we are well served by having diverse and robust implementations, but as we?ve seen in the (mostly) router space that NANOG community cares about.. there are far more BGP implementations than NTP. This isn?t good if the community wants to move to a model of certificate based routing and the dependent infrastructure is weak. I would suggest moving parts of this discussion to either the NTP Pool or the NTPWG mailing lists. - jared From mel at beckman.org Tue May 10 21:14:26 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 10 May 2016 21:14:26 +0000 Subject: NIST NTP servers In-Reply-To: <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> Message-ID: <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? IT guy: He changed our clocks. Boss: How did he do that? IT guy: We have an opening in our firewall that permits time clock packets to come from anywhere in the world, under certain conditions. Boss: Why didn?t you block that? IT guy: Well, we filtered to only accept clock settings from a trusted source, but the hacker lied and pretended to be that protected source. Boss: I thought encryption was supposed to prevent that. IT guy: Time clock packets aren?t encrypted. There is no standard for that. Boss: Not even a password? IT guy: Yes, there is a sophisticated authentication mechanism, but it doesn?t work. Boss: So how could we have prevented this? IT guy: We could have purchased our own time server synchronized to the U.S. Department of Standards atomic clock via Global Positioning System satellites using a special antenna. Then we wouldn?t need time from the Internet. Boss: That sounds expensive. How much are we talking? IT guy: $300 Boss: You?re fired. On May 10, 2016, at 1:51 PM, Jared Mauch > wrote: On May 10, 2016, at 4:40 PM, Gary E. Miller > wrote: Yo Jared! Yo, Gary! On Tue, 10 May 2016 16:29:26 -0400 Jared Mauch > wrote: If you?re using Redhat based systems consider using chrony instead, even the new beta fedora 24 uses 4.2.6 derived code vs 4.2.8 Or, new but under heavy development: NTPsec : https://www.ntpsec.org/ It is a fork of classic NTPD, but was not vulnerable to most of the recent NTPD CVEs. Yeah, there are some issues here in how the NTP community has implemented solutions without discussing with each other through the community splits. The NTPWG at IETF has been in a bit of stasis for years now because the various aspects of how it works, and those who present sometimes don?t output in the most organized fashion requiring a lot of effort on the receiver. There?s also a very narrow universe of people who actually care about the implementations and details, with people like Majdi, Harlan and Miroslav understanding the needs more than I?ve seen anyone from the ntpsec/cisco funded side grasp the nuances of. As a general statement, we are well served by having diverse and robust implementations, but as we?ve seen in the (mostly) router space that NANOG community cares about.. there are far more BGP implementations than NTP. This isn?t good if the community wants to move to a model of certificate based routing and the dependent infrastructure is weak. I would suggest moving parts of this discussion to either the NTP Pool or the NTPWG mailing lists. - jared From cma at cmadams.net Wed May 11 00:17:50 2016 From: cma at cmadams.net (Chris Adams) Date: Tue, 10 May 2016 19:17:50 -0500 Subject: NIST NTP servers In-Reply-To: <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> Message-ID: <20160511001750.GA6228@cmadams.net> Once upon a time, Mel Beckman said: > Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? > > IT guy: He changed our clocks. So, this has been repeated several times (with how bad things will go if your clocks get changed by years). It isn't that easy. First, out of the box, if you use the public pool servers (default config), you'll typically get 4 random (more or less) servers from the pool. There are a bunch, so Joe Random Hacker isn't going to have a high chance of guessing the servers your system is using. Second, he'd have to guess at least three to "win". Third, at best, he'd only be able to change your clocks a little; the common software won't step the clock more than IIRC 15 minutes. Yes, that can cause problems, but not the catastrophes of years in the future or Jan 1, 1970 mentioned in this thread. Is it possible to cause problems? Yes. Is it a practical attack? I'm not so sure, and I haven't seen proof to the contrary. -- Chris Adams From mel at beckman.org Wed May 11 01:59:55 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 01:59:55 +0000 Subject: NIST NTP servers In-Reply-To: <20160511001750.GA6228@cmadams.net> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org>, <20160511001750.GA6228@cmadams.net> Message-ID: <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> I don't pretend to know all the ways a hacker can find out what nap servers a company uses, but I can envision a virus that could do that once behind a firewall. Every ntp response lists the current reference ntp server in the next higher stratum. There are many ways that process could harvest all ntp servers over time, and then pass the public IP back to a mother ship controller. It could be going on right now. My point is, when the fix is so cheap, why put up with this risk at all? -mel beckman > On May 10, 2016, at 5:18 PM, Chris Adams wrote: > > Once upon a time, Mel Beckman said: >> Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? >> >> IT guy: He changed our clocks. > > So, this has been repeated several times (with how bad things will go if > your clocks get changed by years). It isn't that easy. > > First, out of the box, if you use the public pool servers (default > config), you'll typically get 4 random (more or less) servers from the > pool. There are a bunch, so Joe Random Hacker isn't going to have a > high chance of guessing the servers your system is using. > > Second, he'd have to guess at least three to "win". > > Third, at best, he'd only be able to change your clocks a little; the > common software won't step the clock more than IIRC 15 minutes. Yes, > that can cause problems, but not the catastrophes of years in the future > or Jan 1, 1970 mentioned in this thread. > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > not so sure, and I haven't seen proof to the contrary. > -- > Chris Adams From rdobbins at arbor.net Wed May 11 03:47:27 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 11 May 2016 10:47:27 +0700 Subject: NIST NTP servers In-Reply-To: <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: <185EEE6E-A4CD-4E36-B8CA-56D112CCA556@arbor.net> On 11 May 2016, at 8:59, Mel Beckman wrote: > My point is, when the fix is so cheap, why put up with this risk at > all? Time and Position Spoofing With Open Source Projects. [.pdf link] Just keep in mind, *nothing* is perfect. ----------------------------------- Roland Dobbins From jsklein at gmail.com Wed May 11 04:05:31 2016 From: jsklein at gmail.com (Joe Klein) Date: Wed, 11 May 2016 00:05:31 -0400 Subject: NIST NTP servers In-Reply-To: <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems, certificates, encryption, Kerberos, logging and any tightly coupled transaction systems were impacted. So I began doing 'security research' on the topic (don't confuse me with joe hacker), and discovered both interesting and terrifying issues, which I will not disclose on an open forum. Needless to say, my suggestions are: 1. Configure a trusted time source and good time stratum architecture for your organization. 2. When identifying your source of time, the majority of the technologies can be DDOS'ed, spoofed or MITM, so consider using redundant sources and authentication. 3. For distribution of time information inside your organization, ensure your critical systems (Encryption, PKI, transactions, etc) are using your redundant sources and authentication. 4. Operating systems, programming languages, libraries, and applications are sensitive to time changes and can fail in unexpected ways. Test them before it's too late. 5. Disallow internal system to seek NTP from other sources beyond your edge routers. 6. All core time systems should be monitored by your security team or SOC. One question, is this a topic anyone would find interested at a future NANOG? Something like "Hacking and Defending time?". Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, May 10, 2016 at 9:59 PM, Mel Beckman wrote: > I don't pretend to know all the ways a hacker can find out what nap > servers a company uses, but I can envision a virus that could do that once > behind a firewall. Every ntp response lists the current reference ntp > server in the next higher stratum. There are many ways that process could > harvest all ntp servers over time, and then pass the public IP back to a > mother ship controller. It could be going on right now. > > My point is, when the fix is so cheap, why put up with this risk at all? > > -mel beckman > > > On May 10, 2016, at 5:18 PM, Chris Adams wrote: > > > > Once upon a time, Mel Beckman said: > >> Boss: So how did a hacker get in and crash our accounting server, break > our VPNs, and kill our network performance? > >> > >> IT guy: He changed our clocks. > > > > So, this has been repeated several times (with how bad things will go if > > your clocks get changed by years). It isn't that easy. > > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > > > Second, he'd have to guess at least three to "win". > > > > Third, at best, he'd only be able to change your clocks a little; the > > common software won't step the clock more than IIRC 15 minutes. Yes, > > that can cause problems, but not the catastrophes of years in the future > > or Jan 1, 1970 mentioned in this thread. > > > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > > not so sure, and I haven't seen proof to the contrary. > > -- > > Chris Adams > From eric.kuhnke at gmail.com Wed May 11 04:18:34 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 10 May 2016 21:18:34 -0700 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly wrong the ntpd will ignore it. If people have routers/networking equipment inside their network that only supports retrieving ntp from one IP address (or hostname) and have manually configured it to request time from a single external source, not their own internal ntpd that is <10ms away, bad things could definitely happen. It is worthwhile to have both polling from external sources via IP as well as GPS sync. Many locations in a network have no hope of getting a GPS signal or putting an antenna with a clear view to the sky, but may be on a network segment that is <4ms away from many other nodes where you can colocate a 1U box and GPS antenna. On Tue, May 10, 2016 at 9:05 PM, Joe Klein wrote: > Is this group aware of the incident with tock.usno.navy.mil & > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 > years for the period of one hour, then return? > > The reasons were not fully explained, but the impact was global. Routers, > switches, power grids, phone systems, certificates, encryption, Kerberos, > logging and any tightly coupled transaction systems were impacted. > > So I began doing 'security research' on the topic (don't confuse me with > joe hacker), and discovered both interesting and terrifying issues, which I > will not disclose on an open forum. > > Needless to say, my suggestions are: > 1. Configure a trusted time source and good time stratum architecture for > your organization. > 2. When identifying your source of time, the majority of the technologies > can be DDOS'ed, spoofed or MITM, so consider using redundant sources and > authentication. > 3. For distribution of time information inside your organization, ensure > your critical systems (Encryption, PKI, transactions, etc) are using your > redundant sources and authentication. > 4. Operating systems, programming languages, libraries, and applications > are sensitive to time changes and can fail in unexpected ways. Test them > before it's too late. > 5. Disallow internal system to seek NTP from other sources beyond your edge > routers. > 6. All core time systems should be monitored by your security team or SOC. > > One question, is this a topic anyone would find interested at a future > NANOG? Something like "Hacking and Defending time?". > > > Joe Klein > "Inveniam viam aut faciam" > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Tue, May 10, 2016 at 9:59 PM, Mel Beckman wrote: > > > I don't pretend to know all the ways a hacker can find out what nap > > servers a company uses, but I can envision a virus that could do that > once > > behind a firewall. Every ntp response lists the current reference ntp > > server in the next higher stratum. There are many ways that process could > > harvest all ntp servers over time, and then pass the public IP back to a > > mother ship controller. It could be going on right now. > > > > My point is, when the fix is so cheap, why put up with this risk at all? > > > > -mel beckman > > > > > On May 10, 2016, at 5:18 PM, Chris Adams wrote: > > > > > > Once upon a time, Mel Beckman said: > > >> Boss: So how did a hacker get in and crash our accounting server, > break > > our VPNs, and kill our network performance? > > >> > > >> IT guy: He changed our clocks. > > > > > > So, this has been repeated several times (with how bad things will go > if > > > your clocks get changed by years). It isn't that easy. > > > > > > First, out of the box, if you use the public pool servers (default > > > config), you'll typically get 4 random (more or less) servers from the > > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > > high chance of guessing the servers your system is using. > > > > > > Second, he'd have to guess at least three to "win". > > > > > > Third, at best, he'd only be able to change your clocks a little; the > > > common software won't step the clock more than IIRC 15 minutes. Yes, > > > that can cause problems, but not the catastrophes of years in the > future > > > or Jan 1, 1970 mentioned in this thread. > > > > > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > > > not so sure, and I haven't seen proof to the contrary. > > > -- > > > Chris Adams > > > From mel at beckman.org Wed May 11 07:24:05 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 07:24:05 +0000 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> Regarding Roland?s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim?s antenna in order to succeed with this attack. That?s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :) Eric, I agree that sometimes a site can?t get a GPS signal, but in my experience designing data centers, that?s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE. There?s always CDMA, GSM, and even WWV for a less-accurate plan B time source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated yet: http://www.beaglesoft.com/celsynhowworks.htm And their $400 WWV-based Stratum 1 time server: http://www.beaglesoft.com/radsynreceiver.htm So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it. -mel On May 10, 2016, at 9:18 PM, Eric Kuhnke > wrote: For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly wrong the ntpd will ignore it. If people have routers/networking equipment inside their network that only supports retrieving ntp from one IP address (or hostname) and have manually configured it to request time from a single external source, not their own internal ntpd that is <10ms away, bad things could definitely happen. It is worthwhile to have both polling from external sources via IP as well as GPS sync. Many locations in a network have no hope of getting a GPS signal or putting an antenna with a clear view to the sky, but may be on a network segment that is <4ms away from many other nodes where you can colocate a 1U box and GPS antenna. On Tue, May 10, 2016 at 9:05 PM, Joe Klein > wrote: Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems, certificates, encryption, Kerberos, logging and any tightly coupled transaction systems were impacted. So I began doing 'security research' on the topic (don't confuse me with joe hacker), and discovered both interesting and terrifying issues, which I will not disclose on an open forum. Needless to say, my suggestions are: 1. Configure a trusted time source and good time stratum architecture for your organization. 2. When identifying your source of time, the majority of the technologies can be DDOS'ed, spoofed or MITM, so consider using redundant sources and authentication. 3. For distribution of time information inside your organization, ensure your critical systems (Encryption, PKI, transactions, etc) are using your redundant sources and authentication. 4. Operating systems, programming languages, libraries, and applications are sensitive to time changes and can fail in unexpected ways. Test them before it's too late. 5. Disallow internal system to seek NTP from other sources beyond your edge routers. 6. All core time systems should be monitored by your security team or SOC. One question, is this a topic anyone would find interested at a future NANOG? Something like "Hacking and Defending time?". Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > wrote: I don't pretend to know all the ways a hacker can find out what nap servers a company uses, but I can envision a virus that could do that once behind a firewall. Every ntp response lists the current reference ntp server in the next higher stratum. There are many ways that process could harvest all ntp servers over time, and then pass the public IP back to a mother ship controller. It could be going on right now. My point is, when the fix is so cheap, why put up with this risk at all? -mel beckman On May 10, 2016, at 5:18 PM, Chris Adams > wrote: Once upon a time, Mel Beckman > said: Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? IT guy: He changed our clocks. So, this has been repeated several times (with how bad things will go if your clocks get changed by years). It isn't that easy. First, out of the box, if you use the public pool servers (default config), you'll typically get 4 random (more or less) servers from the pool. There are a bunch, so Joe Random Hacker isn't going to have a high chance of guessing the servers your system is using. Second, he'd have to guess at least three to "win". Third, at best, he'd only be able to change your clocks a little; the common software won't step the clock more than IIRC 15 minutes. Yes, that can cause problems, but not the catastrophes of years in the future or Jan 1, 1970 mentioned in this thread. Is it possible to cause problems? Yes. Is it a practical attack? I'm not so sure, and I haven't seen proof to the contrary. -- Chris Adams > From mel at beckman.org Wed May 11 07:24:43 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 07:24:43 +0000 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: <514B4E7A-56A0-4D6A-A0BA-76AAB3E35041@beckman.org> Regarding Roland?s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim?s antenna in order to succeed with this attack. That?s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :) Eric, I agree that sometimes a site can?t get a GPS signal, but in my experience designing data centers, that?s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE. There?s always CDMA, GSM, and even WWV for a less-accurate plan B time source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated yet: http://www.beaglesoft.com/celsynhowworks.htm And their $400 WWV-based Stratum 1 time server: http://www.beaglesoft.com/radsynreceiver.htm So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it. -mel On May 10, 2016, at 9:18 PM, Eric Kuhnke > wrote: For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly wrong the ntpd will ignore it. If people have routers/networking equipment inside their network that only supports retrieving ntp from one IP address (or hostname) and have manually configured it to request time from a single external source, not their own internal ntpd that is <10ms away, bad things could definitely happen. It is worthwhile to have both polling from external sources via IP as well as GPS sync. Many locations in a network have no hope of getting a GPS signal or putting an antenna with a clear view to the sky, but may be on a network segment that is <4ms away from many other nodes where you can colocate a 1U box and GPS antenna. On Tue, May 10, 2016 at 9:05 PM, Joe Klein > wrote: Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems, certificates, encryption, Kerberos, logging and any tightly coupled transaction systems were impacted. So I began doing 'security research' on the topic (don't confuse me with joe hacker), and discovered both interesting and terrifying issues, which I will not disclose on an open forum. Needless to say, my suggestions are: 1. Configure a trusted time source and good time stratum architecture for your organization. 2. When identifying your source of time, the majority of the technologies can be DDOS'ed, spoofed or MITM, so consider using redundant sources and authentication. 3. For distribution of time information inside your organization, ensure your critical systems (Encryption, PKI, transactions, etc) are using your redundant sources and authentication. 4. Operating systems, programming languages, libraries, and applications are sensitive to time changes and can fail in unexpected ways. Test them before it's too late. 5. Disallow internal system to seek NTP from other sources beyond your edge routers. 6. All core time systems should be monitored by your security team or SOC. One question, is this a topic anyone would find interested at a future NANOG? Something like "Hacking and Defending time?". Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > wrote: I don't pretend to know all the ways a hacker can find out what nap servers a company uses, but I can envision a virus that could do that once behind a firewall. Every ntp response lists the current reference ntp server in the next higher stratum. There are many ways that process could harvest all ntp servers over time, and then pass the public IP back to a mother ship controller. It could be going on right now. My point is, when the fix is so cheap, why put up with this risk at all? -mel beckman On May 10, 2016, at 5:18 PM, Chris Adams > wrote: Once upon a time, Mel Beckman > said: Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? IT guy: He changed our clocks. So, this has been repeated several times (with how bad things will go if your clocks get changed by years). It isn't that easy. First, out of the box, if you use the public pool servers (default config), you'll typically get 4 random (more or less) servers from the pool. There are a bunch, so Joe Random Hacker isn't going to have a high chance of guessing the servers your system is using. Second, he'd have to guess at least three to "win". Third, at best, he'd only be able to change your clocks a little; the common software won't step the clock more than IIRC 15 minutes. Yes, that can cause problems, but not the catastrophes of years in the future or Jan 1, 1970 mentioned in this thread. Is it possible to cause problems? Yes. Is it a practical attack? I'm not so sure, and I haven't seen proof to the contrary. -- Chris Adams > From mel at beckman.org Wed May 11 07:24:45 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 07:24:45 +0000 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: Regarding Roland?s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim?s antenna in order to succeed with this attack. That?s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :) Eric, I agree that sometimes a site can?t get a GPS signal, but in my experience designing data centers, that?s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE. There?s always CDMA, GSM, and even WWV for a less-accurate plan B time source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated yet: http://www.beaglesoft.com/celsynhowworks.htm And their $400 WWV-based Stratum 1 time server: http://www.beaglesoft.com/radsynreceiver.htm So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it. -mel On May 10, 2016, at 9:18 PM, Eric Kuhnke > wrote: For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly wrong the ntpd will ignore it. If people have routers/networking equipment inside their network that only supports retrieving ntp from one IP address (or hostname) and have manually configured it to request time from a single external source, not their own internal ntpd that is <10ms away, bad things could definitely happen. It is worthwhile to have both polling from external sources via IP as well as GPS sync. Many locations in a network have no hope of getting a GPS signal or putting an antenna with a clear view to the sky, but may be on a network segment that is <4ms away from many other nodes where you can colocate a 1U box and GPS antenna. On Tue, May 10, 2016 at 9:05 PM, Joe Klein > wrote: Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems, certificates, encryption, Kerberos, logging and any tightly coupled transaction systems were impacted. So I began doing 'security research' on the topic (don't confuse me with joe hacker), and discovered both interesting and terrifying issues, which I will not disclose on an open forum. Needless to say, my suggestions are: 1. Configure a trusted time source and good time stratum architecture for your organization. 2. When identifying your source of time, the majority of the technologies can be DDOS'ed, spoofed or MITM, so consider using redundant sources and authentication. 3. For distribution of time information inside your organization, ensure your critical systems (Encryption, PKI, transactions, etc) are using your redundant sources and authentication. 4. Operating systems, programming languages, libraries, and applications are sensitive to time changes and can fail in unexpected ways. Test them before it's too late. 5. Disallow internal system to seek NTP from other sources beyond your edge routers. 6. All core time systems should be monitored by your security team or SOC. One question, is this a topic anyone would find interested at a future NANOG? Something like "Hacking and Defending time?". Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > wrote: I don't pretend to know all the ways a hacker can find out what nap servers a company uses, but I can envision a virus that could do that once behind a firewall. Every ntp response lists the current reference ntp server in the next higher stratum. There are many ways that process could harvest all ntp servers over time, and then pass the public IP back to a mother ship controller. It could be going on right now. My point is, when the fix is so cheap, why put up with this risk at all? -mel beckman On May 10, 2016, at 5:18 PM, Chris Adams > wrote: Once upon a time, Mel Beckman > said: Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? IT guy: He changed our clocks. So, this has been repeated several times (with how bad things will go if your clocks get changed by years). It isn't that easy. First, out of the box, if you use the public pool servers (default config), you'll typically get 4 random (more or less) servers from the pool. There are a bunch, so Joe Random Hacker isn't going to have a high chance of guessing the servers your system is using. Second, he'd have to guess at least three to "win". Third, at best, he'd only be able to change your clocks a little; the common software won't step the clock more than IIRC 15 minutes. Yes, that can cause problems, but not the catastrophes of years in the future or Jan 1, 1970 mentioned in this thread. Is it possible to cause problems? Yes. Is it a practical attack? I'm not so sure, and I haven't seen proof to the contrary. -- Chris Adams > From dovid at telecurve.com Wed May 11 10:47:20 2016 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 11 May 2016 06:47:20 -0400 Subject: NIST NTP servers In-Reply-To: <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> Message-ID: What about something like this? http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Has anyone used a Pi to create their own server? On Wed, May 11, 2016 at 3:24 AM, Mel Beckman wrote: > Regarding Roland?s reference to time and position spoofing via a hacked > GPS signal, the hacker has to get physical line of sight to the victim?s > antenna in order to succeed with this attack. That?s likely within a few > blocks, if not within a few feet. And a rooftop antenna might require a > drone attack. And how does the drone get guidance without a reliable GPS > signal? :) > > Eric, I agree that sometimes a site can?t get a GPS signal, but in my > experience designing data centers, that?s still pretty rare. Many NTP > systems use an active GPS antenna that can be hundreds of feet away. But > you can always put the $300 NTP server in an outdoor enclosure and power it > with PoE. > > There?s always CDMA, GSM, and even WWV for a less-accurate plan B time > source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated > yet: > > http://www.beaglesoft.com/celsynhowworks.htm > > And their $400 WWV-based Stratum 1 time server: > > http://www.beaglesoft.com/radsynreceiver.htm > > So if you want non-Internet clock diversity, you can have clock diversity. > You just have to pay for it. > > -mel > > On May 10, 2016, at 9:18 PM, Eric Kuhnke eric.kuhnke at gmail.com>> wrote: > > For quite some time, in debian the default configuration for the ntpd.conf > that ships with the package for the ntpd is to poll from four different, > semi-randomly assigned DNS pool based sources. I believe the same is true > for redhat/centos. > > In the event that one out of four sources is wildly wrong the ntpd will > ignore it. > > If people have routers/networking equipment inside their network that only > supports retrieving ntp from one IP address (or hostname) and have manually > configured it to request time from a single external source, not their own > internal ntpd that is <10ms away, bad things could definitely happen. > > It is worthwhile to have both polling from external sources via IP as well > as GPS sync. Many locations in a network have no hope of getting a GPS > signal or putting an antenna with a clear view to the sky, but may be on a > network segment that is <4ms away from many other nodes where you can > colocate a 1U box and GPS antenna. > > On Tue, May 10, 2016 at 9:05 PM, Joe Klein jsklein at gmail.com>> wrote: > > Is this group aware of the incident with tock.usno.navy.mil & > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 > years for the period of one hour, then return? > > The reasons were not fully explained, but the impact was global. Routers, > switches, power grids, phone systems, certificates, encryption, Kerberos, > logging and any tightly coupled transaction systems were impacted. > > So I began doing 'security research' on the topic (don't confuse me with > joe hacker), and discovered both interesting and terrifying issues, which I > will not disclose on an open forum. > > Needless to say, my suggestions are: > 1. Configure a trusted time source and good time stratum architecture for > your organization. > 2. When identifying your source of time, the majority of the technologies > can be DDOS'ed, spoofed or MITM, so consider using redundant sources and > authentication. > 3. For distribution of time information inside your organization, ensure > your critical systems (Encryption, PKI, transactions, etc) are using your > redundant sources and authentication. > 4. Operating systems, programming languages, libraries, and applications > are sensitive to time changes and can fail in unexpected ways. Test them > before it's too late. > 5. Disallow internal system to seek NTP from other sources beyond your edge > routers. > 6. All core time systems should be monitored by your security team or SOC. > > One question, is this a topic anyone would find interested at a future > NANOG? Something like "Hacking and Defending time?". > > > Joe Klein > "Inveniam viam aut faciam" > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Tue, May 10, 2016 at 9:59 PM, Mel Beckman mel at beckman.org>> wrote: > > I don't pretend to know all the ways a hacker can find out what nap > servers a company uses, but I can envision a virus that could do that > once > behind a firewall. Every ntp response lists the current reference ntp > server in the next higher stratum. There are many ways that process could > harvest all ntp servers over time, and then pass the public IP back to a > mother ship controller. It could be going on right now. > > My point is, when the fix is so cheap, why put up with this risk at all? > > -mel beckman > > On May 10, 2016, at 5:18 PM, Chris Adams cma at cmadams.net>> wrote: > > Once upon a time, Mel Beckman > > said: > Boss: So how did a hacker get in and crash our accounting server, > break > our VPNs, and kill our network performance? > > IT guy: He changed our clocks. > > So, this has been repeated several times (with how bad things will go > if > your clocks get changed by years). It isn't that easy. > > First, out of the box, if you use the public pool servers (default > config), you'll typically get 4 random (more or less) servers from the > pool. There are a bunch, so Joe Random Hacker isn't going to have a > high chance of guessing the servers your system is using. > > Second, he'd have to guess at least three to "win". > > Third, at best, he'd only be able to change your clocks a little; the > common software won't step the clock more than IIRC 15 minutes. Yes, > that can cause problems, but not the catastrophes of years in the > future > or Jan 1, 1970 mentioned in this thread. > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > not so sure, and I haven't seen proof to the contrary. > -- > Chris Adams > > > > > From mianosm at gmail.com Wed May 11 11:24:43 2016 From: mianosm at gmail.com (Steven Miano) Date: Wed, 11 May 2016 07:24:43 -0400 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> Message-ID: Building a S1 system with RaspberryPis would not fly in most of the corporate/enterprise environments I've worked in (random 'appliances', non-uniformity, and lack of support are all glaring issues). Get a PCIe card with a BNC connector and dual power supplies for life in a data center. For home/hobby use a Garmin 18x LVC and any spare compute is a great project: http://www.catb.org/gpsd/gpsd-time-service-howto.html On Wed, May 11, 2016 at 6:47 AM, Dovid Bender wrote: > What about something like this? > http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html > Has anyone used a Pi to create their own server? > > > On Wed, May 11, 2016 at 3:24 AM, Mel Beckman wrote: > > > Regarding Roland?s reference to time and position spoofing via a hacked > > GPS signal, the hacker has to get physical line of sight to the victim?s > > antenna in order to succeed with this attack. That?s likely within a few > > blocks, if not within a few feet. And a rooftop antenna might require a > > drone attack. And how does the drone get guidance without a reliable GPS > > signal? :) > > > > Eric, I agree that sometimes a site can?t get a GPS signal, but in my > > experience designing data centers, that?s still pretty rare. Many NTP > > systems use an active GPS antenna that can be hundreds of feet away. But > > you can always put the $300 NTP server in an outdoor enclosure and power > it > > with PoE. > > > > There?s always CDMA, GSM, and even WWV for a less-accurate plan B time > > source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t > investigated > > yet: > > > > http://www.beaglesoft.com/celsynhowworks.htm > > > > And their $400 WWV-based Stratum 1 time server: > > > > http://www.beaglesoft.com/radsynreceiver.htm > > > > So if you want non-Internet clock diversity, you can have clock > diversity. > > You just have to pay for it. > > > > -mel > > > > On May 10, 2016, at 9:18 PM, Eric Kuhnke > eric.kuhnke at gmail.com>> wrote: > > > > For quite some time, in debian the default configuration for the > ntpd.conf > > that ships with the package for the ntpd is to poll from four different, > > semi-randomly assigned DNS pool based sources. I believe the same is true > > for redhat/centos. > > > > In the event that one out of four sources is wildly wrong the ntpd will > > ignore it. > > > > If people have routers/networking equipment inside their network that > only > > supports retrieving ntp from one IP address (or hostname) and have > manually > > configured it to request time from a single external source, not their > own > > internal ntpd that is <10ms away, bad things could definitely happen. > > > > It is worthwhile to have both polling from external sources via IP as > well > > as GPS sync. Many locations in a network have no hope of getting a GPS > > signal or putting an antenna with a clear view to the sky, but may be on > a > > network segment that is <4ms away from many other nodes where you can > > colocate a 1U box and GPS antenna. > > > > On Tue, May 10, 2016 at 9:05 PM, Joe Klein > jsklein at gmail.com>> wrote: > > > > Is this group aware of the incident with tock.usno.navy.mil & > > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost > 12 > > years for the period of one hour, then return? > > > > The reasons were not fully explained, but the impact was global. Routers, > > switches, power grids, phone systems, certificates, encryption, Kerberos, > > logging and any tightly coupled transaction systems were impacted. > > > > So I began doing 'security research' on the topic (don't confuse me with > > joe hacker), and discovered both interesting and terrifying issues, > which I > > will not disclose on an open forum. > > > > Needless to say, my suggestions are: > > 1. Configure a trusted time source and good time stratum architecture for > > your organization. > > 2. When identifying your source of time, the majority of the technologies > > can be DDOS'ed, spoofed or MITM, so consider using redundant sources and > > authentication. > > 3. For distribution of time information inside your organization, ensure > > your critical systems (Encryption, PKI, transactions, etc) are using your > > redundant sources and authentication. > > 4. Operating systems, programming languages, libraries, and applications > > are sensitive to time changes and can fail in unexpected ways. Test them > > before it's too late. > > 5. Disallow internal system to seek NTP from other sources beyond your > edge > > routers. > > 6. All core time systems should be monitored by your security team or > SOC. > > > > One question, is this a topic anyone would find interested at a future > > NANOG? Something like "Hacking and Defending time?". > > > > > > Joe Klein > > "Inveniam viam aut faciam" > > > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > > > On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > mel at beckman.org>> wrote: > > > > I don't pretend to know all the ways a hacker can find out what nap > > servers a company uses, but I can envision a virus that could do that > > once > > behind a firewall. Every ntp response lists the current reference ntp > > server in the next higher stratum. There are many ways that process could > > harvest all ntp servers over time, and then pass the public IP back to a > > mother ship controller. It could be going on right now. > > > > My point is, when the fix is so cheap, why put up with this risk at all? > > > > -mel beckman > > > > On May 10, 2016, at 5:18 PM, Chris Adams > cma at cmadams.net>> wrote: > > > > Once upon a time, Mel Beckman > > > said: > > Boss: So how did a hacker get in and crash our accounting server, > > break > > our VPNs, and kill our network performance? > > > > IT guy: He changed our clocks. > > > > So, this has been repeated several times (with how bad things will go > > if > > your clocks get changed by years). It isn't that easy. > > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > > > Second, he'd have to guess at least three to "win". > > > > Third, at best, he'd only be able to change your clocks a little; the > > common software won't step the clock more than IIRC 15 minutes. Yes, > > that can cause problems, but not the catastrophes of years in the > > future > > or Jan 1, 1970 mentioned in this thread. > > > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > > not so sure, and I haven't seen proof to the contrary. > > -- > > Chris Adams > > > > > > > > > > -- Miano, Steven M. http://stevenmiano.com From baldur.norddahl at gmail.com Wed May 11 11:46:51 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 11 May 2016 13:46:51 +0200 Subject: NIST NTP servers In-Reply-To: <514B4E7A-56A0-4D6A-A0BA-76AAB3E35041@beckman.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> <514B4E7A-56A0-4D6A-A0BA-76AAB3E35041@beckman.org> Message-ID: <57331BAB.4060307@gmail.com> But would you not need to actually spend three times $300 to get a good redundant solution? While we are there, why not go all the way and get a rubidium standard with GPS sync? Anyone know of a (relatively) cheap solution with NTP output? https://en.wikipedia.org/wiki/Rubidium_standard Regards, Baldur On 2016-05-11 09:24, Mel Beckman wrote: > Regarding Roland?s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim?s antenna in order to succeed with this attack. That?s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :) > > Eric, I agree that sometimes a site can?t get a GPS signal, but in my experience designing data centers, that?s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE. > > There?s always CDMA, GSM, and even WWV for a less-accurate plan B time source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated yet: > > http://www.beaglesoft.com/celsynhowworks.htm > > And their $400 WWV-based Stratum 1 time server: > > http://www.beaglesoft.com/radsynreceiver.htm > > So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it. > > -mel > > On May 10, 2016, at 9:18 PM, Eric Kuhnke > wrote: > > For quite some time, in debian the default configuration for the ntpd.conf > that ships with the package for the ntpd is to poll from four different, > semi-randomly assigned DNS pool based sources. I believe the same is true > for redhat/centos. > > In the event that one out of four sources is wildly wrong the ntpd will > ignore it. > > If people have routers/networking equipment inside their network that only > supports retrieving ntp from one IP address (or hostname) and have manually > configured it to request time from a single external source, not their own > internal ntpd that is <10ms away, bad things could definitely happen. > > It is worthwhile to have both polling from external sources via IP as well > as GPS sync. Many locations in a network have no hope of getting a GPS > signal or putting an antenna with a clear view to the sky, but may be on a > network segment that is <4ms away from many other nodes where you can > colocate a 1U box and GPS antenna. > > On Tue, May 10, 2016 at 9:05 PM, Joe Klein > wrote: > > Is this group aware of the incident with tock.usno.navy.mil & > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 > years for the period of one hour, then return? > > The reasons were not fully explained, but the impact was global. Routers, > switches, power grids, phone systems, certificates, encryption, Kerberos, > logging and any tightly coupled transaction systems were impacted. > > So I began doing 'security research' on the topic (don't confuse me with > joe hacker), and discovered both interesting and terrifying issues, which I > will not disclose on an open forum. > > Needless to say, my suggestions are: > 1. Configure a trusted time source and good time stratum architecture for > your organization. > 2. When identifying your source of time, the majority of the technologies > can be DDOS'ed, spoofed or MITM, so consider using redundant sources and > authentication. > 3. For distribution of time information inside your organization, ensure > your critical systems (Encryption, PKI, transactions, etc) are using your > redundant sources and authentication. > 4. Operating systems, programming languages, libraries, and applications > are sensitive to time changes and can fail in unexpected ways. Test them > before it's too late. > 5. Disallow internal system to seek NTP from other sources beyond your edge > routers. > 6. All core time systems should be monitored by your security team or SOC. > > One question, is this a topic anyone would find interested at a future > NANOG? Something like "Hacking and Defending time?". > > > Joe Klein > "Inveniam viam aut faciam" > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > wrote: > > I don't pretend to know all the ways a hacker can find out what nap > servers a company uses, but I can envision a virus that could do that > once > behind a firewall. Every ntp response lists the current reference ntp > server in the next higher stratum. There are many ways that process could > harvest all ntp servers over time, and then pass the public IP back to a > mother ship controller. It could be going on right now. > > My point is, when the fix is so cheap, why put up with this risk at all? > > -mel beckman > > On May 10, 2016, at 5:18 PM, Chris Adams > wrote: > > Once upon a time, Mel Beckman > said: > Boss: So how did a hacker get in and crash our accounting server, > break > our VPNs, and kill our network performance? > > IT guy: He changed our clocks. > > So, this has been repeated several times (with how bad things will go > if > your clocks get changed by years). It isn't that easy. > > First, out of the box, if you use the public pool servers (default > config), you'll typically get 4 random (more or less) servers from the > pool. There are a bunch, so Joe Random Hacker isn't going to have a > high chance of guessing the servers your system is using. > > Second, he'd have to guess at least three to "win". > > Third, at best, he'd only be able to change your clocks a little; the > common software won't step the clock more than IIRC 15 minutes. Yes, > that can cause problems, but not the catastrophes of years in the > future > or Jan 1, 1970 mentioned in this thread. > > Is it possible to cause problems? Yes. Is it a practical attack? I'm > not so sure, and I haven't seen proof to the contrary. > -- > Chris Adams > > > > From rea+nanog at grid.kiae.ru Wed May 11 11:53:33 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Wed, 11 May 2016 14:53:33 +0300 Subject: NIST NTP servers In-Reply-To: <20160510145902.GA29833@nic.fr> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> <20160510145902.GA29833@nic.fr> Message-ID: <20160511115333.GH1159void.codelabs.ru@void.codelabs.ru> Tue, May 10, 2016 at 04:59:02PM +0200, Stephane Bortzmeyer wrote: > On Tue, May 10, 2016 at 10:52:28AM -0400, > Valdis.Kletnieks at vt.edu wrote > a message of 37 lines which said: > > > Note that they *do* have motivation to keep it working, simply > > because so much of their *own* gear (from gear for individual > > soldiers all the way to strategic bombers and aircraft carriers) > > wants a working GPS signal... > > Yes, but they may switch it off for civilian use (by going encrypted, > for instance) at any time, if it is better for *their* operations. Civilian signals are already degraded in terms of accuracy (without assisted GPS) and military ones are encrypted (but see [1]). The primary reason for encryption is, by the way, to address spoofing issues for the mil people themselves, but it is also good not to arm the potential enemy with the precise coordinates or to be able to do spoofing for them. And since many civilian, but nonetheless, vital orgs are using civilian parts, it could be hard to shut it off without affecting some parts of the infrastructure. Not that nobody wants that, but it will give an unneeded resonance and could lead to the terrible mess. [1] http://www.gps.gov/technical/codeless/ -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From bicknell at ufp.org Wed May 11 13:31:27 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2016 06:31:27 -0700 Subject: NIST NTP servers In-Reply-To: <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> Message-ID: <20160511133127.GA75456@ussenterprise.ufp.org> In a message written on Tue, May 10, 2016 at 08:23:04PM +0000, Mel Beckman wrote: > All because of misplaced trust in a tiny UDP packet that can worm its way into your network from anywhere on the Internet. > > I say you?re crazy if you don?t run a GPS-based NTP server, especially given that they cost as little as $300 for very solid gear. Heck, get two or three! You're replacing one single point of failure with another. Personally, my network gets NTP from 14 stratum 1 sources right now. You, and the hacker, do not know which ones. You have to guess at least 8 to get me to move to your "hacked" time. Good luck. Redundancy is the solution, not a new single point of failure. GPS can be part of the redundancy, not a sole solution. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From simon.goodwin at verizon.com Tue May 10 13:14:40 2016 From: simon.goodwin at verizon.com (Goodwin, Simon T) Date: Tue, 10 May 2016 09:14:40 -0400 Subject: VirginMedia AS5089 Message-ID: Can somebody contact me offline from VirginMedia UK regarding a BGP advertisement for 192.34.50.0/24 originating from AS1849 please Thanks Simon From hardenrm at uchicago.edu Tue May 10 13:28:14 2016 From: hardenrm at uchicago.edu (Ryan Harden) Date: Tue, 10 May 2016 13:28:14 +0000 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> Message-ID: <4B4DBED3-FF71-4BA5-A5BF-5C10A68E80B8@uchicago.edu> _Everything_ has vulnerabilities and using _any_ external source opens your network and infrastructure to disruptions. NTP has been used for DDoS amplification attacks recently, but so has DNS and other well known/heavily used protocols. With the right protections, syncing with an external NTP source is perfectly acceptable and safe. Further, it?s generally a good idea to ?peer? (not just sync) your NTP servers with a few external sources. This removes the dependence on a single source and helps ensure that your time source agrees with the rest of the world. Peering requires interaction with the owners of the remote site, which establishes a basic level of trust that they?ll provide an accurate and stable service. I?ve attached a diagram (sanitized) of what our NTP service will look like after an upcoming refresh. All external sources are trusted and will be peered. All time devices peer with four other sources to ensure there is always a live source to sync/peer with. A DNS record with round-robin is used for local clients to connect to the local Stratum 2 devices. The Stratum 1 GPS will not be directly accessible by users. /Ryan [cid:5676FF89-CBC8-42F7-84CE-69F431C23E48 at int.ancker.net] Ryan Harden Research and Advanced Networking Architect University of Chicago - ASN160 P: 773.834.5441 On May 10, 2016, at 5:48 AM, Steven Miano > wrote: NTP has vulnerabilities, so using an external source opens your networks and infrastructure to disruptions. Going with an internal GPS/GLONASS/RADIO based S1 allows you to restrict incoming traffic and not rely on volunteers or external entities (which may undergo maintenance or budget issues). My preference is more so something akin to the GLN180PEX (I am not affiliated or paid to endorse this product). It allows you to use commodity hardware (like a decommissioned 1U or several preferably) and creation of ones own reliable internal time source(s). Introducing black boxes into a production (revenue generation or expected services by paying customers) environment is undesirable. From there setting up NTPd, Chronyd, and PTPd is up to you. Relying on satellites may seem like just another external reliance, but the next life is proposing a design life of 12 years..... On Mon, May 9, 2016 at 11:12 PM, Majdi S. Abbas > wrote: On Tue, May 10, 2016 at 03:08:16AM +0000, Mel Beckman wrote: NTP has vulnerabilities that make it generally unsuitable for provider networks. I strongly recommend getting a GPS-based time server. These are as cheap as $300. Here is one I use quite a bit: So how does this stop from distributing time to their customers via NTP? GPS doesn't save the protocol, in particular where the S1 clocks involved are embedded devices with rather coarse clocks and timestamping. --msa -- Miano, Steven M. http://stevenmiano.com From allan at allan.org Tue May 10 14:40:23 2016 From: allan at allan.org (Allan Liska) Date: Tue, 10 May 2016 10:40:23 -0400 Subject: NIST NTP servers In-Reply-To: <04a201d1aac8$6320f360$2962da20$@gmail.com> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> Message-ID: <20160510144024.64E96E05D1@smtp.hushmail.com> On 5/10/2016 at 10:30 AM, "Chuck Church" wrote: > >It doesn't really. Granted there are a lot of CVEs coming out for >NTP the >last year or so. But I just don't think there are that many >attacks on it. >It's just not worth the effort. Changing time on devices is more >an >annoyance than anything, and doesn't necessarily get you into a >device. >Sure you can hide your tracks a little by altering time in logs >and altering >it back, but that's more of an in-depth nation-state kind of >attack, not >going to be a script kiddie kind of thing. Just follow the best >practices >for verifying packet sources and NTP security itself, and you >should be ok. > >Chuck I would argue that the fact the NTP can, and has been, be used in DDoS amplification attacks is a serious concern for using protocol going forward. allan From fkittred at gwi.net Tue May 10 19:29:22 2016 From: fkittred at gwi.net (Fletcher Kittredge) Date: Tue, 10 May 2016 15:29:22 -0400 Subject: third party single pole administrator regimes Message-ID: This is outside plant related. Ignore if all you do is configure routers (not that there is anything wrong with that.) I would be interested in any network provider's experiences with third party single pole administrator regulatory regimes, such as Connecticut's. Please respond privately and I will summarize if there is any interest. thanks -- Fletcher Kittredge GWI www.gwi.net From bmengel at gmail.com Tue May 10 21:00:54 2016 From: bmengel at gmail.com (Brian Mengel) Date: Tue, 10 May 2016 17:00:54 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: AFAIK being able to do a lawful intercept on a specific, named, individual's service has been a requirement for providers since 2007. I have never heard of a provider, big or small, being called out for being unable to provide this service when requested. I would be surprised if a national broadband ISP with millions of subs did not have this ability and did not perform intercepts routinely. I would be surprised if a small town providing it's own Internet access or small WISP serving a few hundred customers went through the trouble and expense of being able to provide this service. The mediation server needed to "mediate" between your customer aggregation box and the LEA is not inexpensive. I believe there was talk about "trusted third parties" providing mediation-as-a-service but I do not know if any such entities exist. The logistics of running a mediation server in the cloud and being able to signal from the cloud to the aggregation box to begin a mediation and ensuring that the data exported from the ISP to the cloud to the LEA remained private would seem to be significant but not insurmountable. On Tue, May 10, 2016 at 4:11 PM, Josh Reynolds wrote: > The first rule of prism is... > > > *silence* > > > :) > > On Tue, May 10, 2016 at 3:04 PM, Christopher Morrow > wrote: > > > > > > On Tue, May 10, 2016 at 4:00 PM, Josh Reynolds > wrote: > >> > >> This is a large list that includes many Tier 1 network operators, > >> government agencies, and Fortune 500 network operators > > > > > > no one gets calea requests because prism gets all requests? > > > From andreas at naund.org Tue May 10 22:46:05 2016 From: andreas at naund.org (Andreas Ott) Date: Tue, 10 May 2016 15:46:05 -0700 Subject: NIST NTP servers In-Reply-To: <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org>; from mel@beckman.org on Tue, May 10, 2016 at 09:14:26PM +0000 References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> Message-ID: <20160510154605.W1074@naund.org> Hi, > Boss: That sounds expensive. How much are we talking? > IT guy: $300 Beware! Over the past year we made engineering samples to deploy to datacenters. The goal was to use GPS and PPS to discipline ntpd appliances and serve as stratum 1 to other NTP distribution servers without the $5k price tag of commercial NTP 1RU gear. We also deliberately not pursued the path of running antenna coax from the roof to a receiver, as that is not an option in all the datacenters where we need to deploy. These appliances were built for lesss than $150 as (a) Raspberry-Pi with GPS receiver board (b) Garmin 18(x) LVC with DB-9 to an "older whitebox server" In my experience, most locations inside datacenters where you have good power and network connectivity have not "good enough" GPS signal reception due to servers emitting lots of RF noise in the range 1-2 GHz on the L-band. A brand new suite in the datacenter had OK GPS quality, but once we added 20+ racks with 40 servers each, GPS reception was pretty much gone. This hardware was an active antenna with less than 6 feet of cabling routed to the top of the network cabling rack. Most smartphones can run an app to show you the GPS signal on the phone, just walk around your datacenter and compare the signal. The only workable solution was to move the GPS clock to a location where it had good GPS signal but neither redundant network nor conditioned power (aka. "on my desk near a south facing window"). It also works pretty well "in my garage". In places where GPS reception is good, you can achieve 10E-06 seconds accuracy over time even with cheap hardware. If you chose to run the DB-9 NMEA0183 and GPS as "serial port passthrough" to a VM on a Hypervisor you can still get better than 10E-03 seconds accuracy. -andreas -- Andreas Ott (Time-Nut) K6OTT +1.408.431.8727 andreas at naund.org From josh at kyneticwifi.com Wed May 11 14:00:54 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 11 May 2016 09:00:54 -0500 Subject: NIST NTP servers In-Reply-To: <20160511133127.GA75456@ussenterprise.ufp.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: I hope your receivers aren't all from a single source. I was in Iraq when this ( http://dailycaller.com/2010/06/01/glitch-shows-how-much-us-military-relies-on-gps/ ) happened, which meant I had no GPS guided indirect fire assets for 2 weeks. On Wed, May 11, 2016 at 8:31 AM, Leo Bicknell wrote: > In a message written on Tue, May 10, 2016 at 08:23:04PM +0000, Mel Beckman wrote: >> All because of misplaced trust in a tiny UDP packet that can worm its way into your network from anywhere on the Internet. >> >> I say you?re crazy if you don?t run a GPS-based NTP server, especially given that they cost as little as $300 for very solid gear. Heck, get two or three! > > You're replacing one single point of failure with another. > > Personally, my network gets NTP from 14 stratum 1 sources right now. > You, and the hacker, do not know which ones. You have to guess at least > 8 to get me to move to your "hacked" time. Good luck. > > Redundancy is the solution, not a new single point of failure. GPS > can be part of the redundancy, not a sole solution. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ From mel at beckman.org Wed May 11 14:27:47 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 14:27:47 +0000 Subject: NIST NTP servers In-Reply-To: <20160510154605.W1074@naund.org> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org>, <20160510154605.W1074@naund.org> Message-ID: <104F84B7-22F2-4EAF-A625-FA2A50A8C525@beckman.org> Andreas, Most data centers will require a remotely positioned NTP server, which is actually easier and cheaper than a remotely located active GPS antenna. I have placed the $300 commercial NTP servers in an environmental box on the roof, powering t by PoE, without problems. You don't need a redundant network either, nor redundant power. Just plunk down two of these gizmos, or as I suggested elsewhere, deploy one or more CDMA, GSM, or WWV-based clocks, for as much local infrastructure and signal source diversity as you like (I sourced some of these units earlier in the thread, all well less than $1K each. You pay more for diversity, but you get more too. In response to the several DIYers on this thread: Anyone who thinks they're building a raspberry pi-based GPS NTP server for just $150 is kidding themselves. They forgot to include their labor, which is worth far more than the $300 for a commercial unit. The same goes for people who complain about even the minimal $300 price, forgetting that a commercial product has to pay for marketing, support, and make a profit. External NTP has two kinds of vulnerabilities: the ones we know, and the ones we don't. The ones we know are serious enough the pat the ones we don't should be considered with respect. Maybe diversity in Internet sources is a cure, maybe it isn't. But diverse RF sources is demonstrably more secure than the Internet. My point stands: secure external RF NTP sources are so plentiful that relying on Internet NTP is just plain crazy. -mel beckman > On May 11, 2016, at 7:12 AM, Andreas Ott wrote: > > Hi, > >> Boss: That sounds expensive. How much are we talking? >> IT guy: $300 > > Beware! > > Over the past year we made engineering samples to deploy to datacenters. > The goal was to use GPS and PPS to discipline ntpd appliances and serve > as stratum 1 to other NTP distribution servers without the $5k price tag > of commercial NTP 1RU gear. We also deliberately not pursued the path of > running antenna coax from the roof to a receiver, as that is not an > option in all the datacenters where we need to deploy. > > These appliances were built for lesss than $150 as > > (a) Raspberry-Pi with GPS receiver board > > (b) Garmin 18(x) LVC with DB-9 to an "older whitebox server" > > In my experience, most locations inside datacenters where you have good > power and network connectivity have not "good enough" GPS signal reception > due to servers emitting lots of RF noise in the range 1-2 GHz on the > L-band. A brand new suite in the datacenter had OK GPS quality, but > once we added 20+ racks with 40 servers each, GPS reception was pretty > much gone. This hardware was an active antenna with less than 6 feet of > cabling routed to the top of the network cabling rack. Most smartphones > can run an app to show you the GPS signal on the phone, just walk around > your datacenter and compare the signal. > > The only workable solution was to move the GPS clock to a location > where it had good GPS signal but neither redundant network nor conditioned > power (aka. "on my desk near a south facing window"). It also works pretty > well "in my garage". > > In places where GPS reception is good, you can achieve 10E-06 seconds > accuracy over time even with cheap hardware. If you chose to run the DB-9 > NMEA0183 and GPS as "serial port passthrough" to a VM on a Hypervisor > you can still get better than 10E-03 seconds accuracy. > > > -andreas > -- > Andreas Ott (Time-Nut) K6OTT +1.408.431.8727 andreas at naund.org From mel at beckman.org Wed May 11 14:30:12 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 14:30:12 +0000 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org>, Message-ID: Josh, Read deeper into the thread and you'll find where I sourced inexpensive RF-based NTP servers using CDMA, GSM, and even WWV. All radically different technologies that are unlikely to have common failure modes. But yes, buying different brands can't hurt either. -mel beckman > On May 11, 2016, at 7:15 AM, Josh Reynolds wrote: > > I hope your receivers aren't all from a single source. > > I was in Iraq when this ( > http://dailycaller.com/2010/06/01/glitch-shows-how-much-us-military-relies-on-gps/ > ) happened, which meant I had no GPS guided indirect fire assets for 2 > weeks. > >> On Wed, May 11, 2016 at 8:31 AM, Leo Bicknell wrote: >> In a message written on Tue, May 10, 2016 at 08:23:04PM +0000, Mel Beckman wrote: >>> All because of misplaced trust in a tiny UDP packet that can worm its way into your network from anywhere on the Internet. >>> >>> I say you?re crazy if you don?t run a GPS-based NTP server, especially given that they cost as little as $300 for very solid gear. Heck, get two or three! >> >> You're replacing one single point of failure with another. >> >> Personally, my network gets NTP from 14 stratum 1 sources right now. >> You, and the hacker, do not know which ones. You have to guess at least >> 8 to get me to move to your "hacked" time. Good luck. >> >> Redundancy is the solution, not a new single point of failure. GPS >> can be part of the redundancy, not a sole solution. >> >> -- >> Leo Bicknell - bicknell at ufp.org >> PGP keys at http://www.ufp.org/~bicknell/ From bicknell at ufp.org Wed May 11 14:49:07 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2016 07:49:07 -0700 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: <20160511144907.GB75456@ussenterprise.ufp.org> In a message written on Tue, May 10, 2016 at 03:00:59PM -0500, Josh Reynolds wrote: > This is a large list that includes many Tier 1 network operators, > government agencies, and Fortune 500 network operators. > > The silence should be telling. NANOG has a strong self-selection for people who run core routing devices and do things like BGP and peering negotiations with other providers. By contrast, CALEA requirements are generally all met by features deployed at the customer-edge. These groups are often a separate silo from the backbone folks at the largest providers. This is likely the wrong list for asking such questions, and the few who do answer is likely to be smaller providers where people wear multiple hats. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From bicknell at ufp.org Wed May 11 14:53:33 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2016 07:53:33 -0700 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: <20160511145333.GC75456@ussenterprise.ufp.org> In a message written on Wed, May 11, 2016 at 09:00:54AM -0500, Josh Reynolds wrote: > I hope your receivers aren't all from a single source. I have 4 each ACTS, GPS, and CDMA in my list, agumented with a pair of PTP. Amazingly right now all but 3 are within 2 microsconds of each other, and those three outliers are 10 and 35 microseconds off. That's pretty impressive! I didn't have to buy any of them, because various trustable entities run those infrastructures. Some of the trustable entites are the same ones that send the time up to the GPS satellites. :) -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Brandon.Vincent at asu.edu Wed May 11 15:08:00 2016 From: Brandon.Vincent at asu.edu (Brandon Vincent) Date: Wed, 11 May 2016 08:08:00 -0700 Subject: NIST NTP servers In-Reply-To: <20160511145333.GC75456@ussenterprise.ufp.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> Message-ID: GPS + a cesium or rubidium frequency standard is all you need. Too expensive? Then time isn't important to your organization. From chuckchurch at gmail.com Wed May 11 15:18:29 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 11 May 2016 11:18:29 -0400 Subject: NIST NTP servers In-Reply-To: <20160511133127.GA75456@ussenterprise.ufp.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: <005e01d1ab98$60f961f0$22ec25d0$@gmail.com> -----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Leo Bicknell >Sent: Wednesday, May 11, 2016 9:31 AM >To: nanog at nanog.org >Subject: Re: NIST NTP servers >Personally, my network gets NTP from 14 stratum 1 sources right now. >You, and the hacker, do not know which ones. You have to guess at least >8 to get me to move to your "hacked" time. Good luck. >Redundancy is the solution, not a new single point of failure. GPS can be part of the redundancy, not a sole solution. This seems like the most reasonable advise. If this truly becomes a concern, I would think IPS vendors could implement signatures to look for bad time. Lots of ways to do this - look for a difference between the IPS realtime and NTP status versus the incoming packets. - look for duplicate NTP responses, or responses that weren't requested - duplicate responses, but with differing TTLs, which might hint at one being spoofed. Chuck From swhyte at gmail.com Wed May 11 15:24:28 2016 From: swhyte at gmail.com (Scott Whyte) Date: Wed, 11 May 2016 08:24:28 -0700 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> Message-ID: On 5/10/16 21:05, Joe Klein wrote: > Is this group aware of the incident with tock.usno.navy.mil & > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 > years for the period of one hour, then return? > > The reasons were not fully explained, but the impact was global. Routers, > switches, power grids, phone systems, certificates, encryption, Kerberos, > logging and any tightly coupled transaction systems were impacted. > > So I began doing 'security research' on the topic (don't confuse me with > joe hacker), and discovered both interesting and terrifying issues, which I > will not disclose on an open forum. > > Needless to say, my suggestions are: > 1. Configure a trusted time source and good time stratum architecture for > your organization. > 2. When identifying your source of time, the majority of the technologies > can be DDOS'ed, spoofed or MITM, so consider using redundant sources and > authentication. > 3. For distribution of time information inside your organization, ensure > your critical systems (Encryption, PKI, transactions, etc) are using your > redundant sources and authentication. > 4. Operating systems, programming languages, libraries, and applications > are sensitive to time changes and can fail in unexpected ways. Test them > before it's too late. > 5. Disallow internal system to seek NTP from other sources beyond your edge > routers. I believe this will become a stronger need over time, and apply to more than NTP: http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > 6. All core time systems should be monitored by your security team or SOC. > > One question, is this a topic anyone would find interested at a future > NANOG? Something like "Hacking and Defending time?". > > > Joe Klein > "Inveniam viam aut faciam" > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Tue, May 10, 2016 at 9:59 PM, Mel Beckman wrote: > >> I don't pretend to know all the ways a hacker can find out what nap >> servers a company uses, but I can envision a virus that could do that once >> behind a firewall. Every ntp response lists the current reference ntp >> server in the next higher stratum. There are many ways that process could >> harvest all ntp servers over time, and then pass the public IP back to a >> mother ship controller. It could be going on right now. >> >> My point is, when the fix is so cheap, why put up with this risk at all? >> >> -mel beckman >> >>> On May 10, 2016, at 5:18 PM, Chris Adams wrote: >>> >>> Once upon a time, Mel Beckman said: >>>> Boss: So how did a hacker get in and crash our accounting server, break >> our VPNs, and kill our network performance? >>>> IT guy: He changed our clocks. >>> So, this has been repeated several times (with how bad things will go if >>> your clocks get changed by years). It isn't that easy. >>> >>> First, out of the box, if you use the public pool servers (default >>> config), you'll typically get 4 random (more or less) servers from the >>> pool. There are a bunch, so Joe Random Hacker isn't going to have a >>> high chance of guessing the servers your system is using. >>> >>> Second, he'd have to guess at least three to "win". >>> >>> Third, at best, he'd only be able to change your clocks a little; the >>> common software won't step the clock more than IIRC 15 minutes. Yes, >>> that can cause problems, but not the catastrophes of years in the future >>> or Jan 1, 1970 mentioned in this thread. >>> >>> Is it possible to cause problems? Yes. Is it a practical attack? I'm >>> not so sure, and I haven't seen proof to the contrary. >>> -- >>> Chris Adams From jra at baylink.com Wed May 11 15:24:43 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 11 May 2016 15:24:43 +0000 (UTC) Subject: NIST NTP servers In-Reply-To: <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> Message-ID: <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Jared Mauch" >> Yes, and properly monitor your ntpd instances. > > And upgrade them. > > Some software distributors don?t ship modern software. if you > are using a distribution packaged ntpd it?s likely old and > difficult to determine its lineage due to how it?s packaged. > > If you?re using Redhat based systems consider using chrony > instead, even the new beta fedora 24 uses 4.2.6 derived code > vs 4.2.8 We're all aware this project is underway, right? https://www.ntpsec.org/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Wed May 11 15:36:34 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 11 May 2016 15:36:34 +0000 (UTC) Subject: NIST NTP servers In-Reply-To: References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: <1506067283.128804.1462980994495.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Mel Beckman" > Read deeper into the thread and you'll find where I sourced inexpensive RF-based > NTP servers using CDMA, GSM, and even WWV. All radically different technologies > that are unlikely to have common failure modes. But yes, buying different > brands can't hurt either. CDMA and GSM are false diversity: both network types nodes *get their time* from GPS, so far as I know. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From msa at latt.net Wed May 11 17:42:54 2016 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 11 May 2016 13:42:54 -0400 Subject: NIST NTP servers In-Reply-To: <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> Message-ID: <20160511174254.GB19142@puck.nether.net> On Wed, May 11, 2016 at 03:24:43PM +0000, Jay R. Ashworth wrote: > We're all aware this project is underway, right? > > https://www.ntpsec.org/ Despite the name, I'm not aware of any significant protocol changes. It's just a recent fork of the reference implementation minus the refclocks, which isn't particularly helpful if you /don't/ trust network time sources. Long term, be looking at NTS: https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/ In the meanwhile, I'd recommend something along the following lines: - Several nearby upstream servers configured per time server, per site (As diversely as possible.) - Diverse reference clocks (I run everything from WWV to GPS here.) providing authenticated time to your servers. - That all your time servers in all sites be configured in an authenticated full mesh of symmetric peers, allowing the other sites to provide time to a site that has lost its upstream servers or for whatever reason does not trust them at the moment. And of course, ensure any hosts whose clocks you care about are talking to at least a few of these, and preferably several. I know the common case configuration is either default/ntp-pool, or "we have two time servers in this site and everything just chimes from them," but neither is that great of a configuration. --msa From Valdis.Kletnieks at vt.edu Wed May 11 17:54:25 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 May 2016 13:54:25 -0400 Subject: NIST NTP servers In-Reply-To: <1506067283.128804.1462980994495.JavaMail.zimbra@baylink.com> References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <1506067283.128804.1462980994495.JavaMail.zimbra@baylink.com> Message-ID: <129051.1462989265@turing-police.cc.vt.edu> On Wed, 11 May 2016 15:36:34 -0000, "Jay R. Ashworth" said: > CDMA and GSM are false diversity: both network types nodes *get their time* > from GPS, so far as I know. I'll make the fairly reasonable assumption that most readers of this list have networks that span multiple buildings. If somebody is managing to figure out that you have a GPS in Building 37, and a GPS-based CDMA up on the corner of Building 3, and the *other* 4 clocks at other locations and getting close enough to all of them at the same time to conduct a successful spoofing attack, all just to move your time source a few seconds off.... ... then the fact that GPS is spoofable is probably *NOT* your biggest security problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From lowen at pari.edu Wed May 11 18:23:59 2016 From: lowen at pari.edu (Lamar Owen) Date: Wed, 11 May 2016 14:23:59 -0400 Subject: NIST NTP servers In-Reply-To: References: Message-ID: <573378BF.3030503@pari.edu> On 05/11/2016 12:05 AM, Joe Klein wrote: > Is this group aware of the incident with tock.usno.navy.mil & > tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 > years for the period of one hour, then return? > ... I remember it like it was only four years ago.... oh, wait.... We have multiple sync sources ourselves, with a Symmetricom (formerly Datum) SSU2000 setup with a cesium PRS, a rubidium secondary, and an ovenized quartz for tertiary oscillators. SSU2000 architecture is separate control and data planes, with time-sync on a different interface from the LAN-facing NTP NIC. And the control plane is firewalled off from the main LAN. An Agilent (now Symmetricom) Z3816 is secondary. PC and SBC (RasPi, etc) oscillators are just not accurate enough for Stratum 1 standards; at best stratum 3 or 4, even when directly GPS-disciplined (stratum is NOT just a synonym for 'level' as a particular stratum really has stability, precision, and accuracy requirements). WWV plus GPS; GPS as you may or may not be aware, is spoofable and is not as accurate as one might want. Neither is WWV. Good reference for time-nuts is, well, the 'time-nuts at febo.com' mailing list. (We're a radio astronomy observatory; accurate time and frequency standards are a must here, especially as position accuracy of radio telescopes approach tens of arcseconds). From lowen at pari.edu Wed May 11 18:28:47 2016 From: lowen at pari.edu (Lamar Owen) Date: Wed, 11 May 2016 14:28:47 -0400 Subject: NIST NTP servers In-Reply-To: <57331BAB.4060307@gmail.com> References: Message-ID: <573379DF.1070407@pari.edu> On 05/11/2016 07:46 AM, Baldur Norddahl wrote: > But would you not need to actually spend three times $300 to get a > good redundant solution? > > While we are there, why not go all the way and get a rubidium standard > with GPS sync? Anyone know of a (relatively) cheap solution with NTP > output? > Ebay has several Symmetricom, Microsemi, Datum, Spectracom, and even Agilent solutions for prices from a few hundred US$ to a couple of thousand US$. Even something like the Agilent Z3801, Z3805, or Z3816 can be found for a few hundred US$. New, these things are in the $10,000+ territory. About the same range as mid-range ethernet gear. I like our SSU2000, personally. From jfbeam at gmail.com Wed May 11 18:58:30 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 11 May 2016 14:58:30 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel wrote: > AFAIK being able to do a lawful intercept on a specific, named, > individual's service has been a requirement for providers since 2007. It's been required for longer than that. The telco I worked for over a decade ago didn't build the infrastructure until the FCC said they were going to stop funding upgrades. That really got 'em movin'. (suddenly "data services" people -- i.e. ME -- weren't redheaded stepchildren.) > have never heard of a provider, big or small, being called out for being > unable to provide this service when requested. Where existing infrastructure is not already in place (read: T1/BRI/etc.), the telco can take up to 60 days to get that setup. I know more than one telco that used that grace period to actually setup CALEA in the first place. > did not perform intercepts routinely. The historic published figures (i've not looked in years) suggest CALEA requests are statistically rare. The NC based telco I worked for had never received an order in the then ~40yr life of the company. > The mediation server needed to "mediate" between your customer > aggregation box and the LEA is not inexpensive. And also is not the telco's problem. Mediation is done by the LEA or 3rd party under contract to any number of agencies. For example, a telco tap order would mirror the control and voice traffic of a POTS line (T1/PRI channel, etc.) into a BRI or specific T1 channel. (dialup was later added, but wasn't required in my era, so we didn't support it.) We used to test that by tapping a tech's phone. Not having any mediation software, all I could do is "yeap, it's sending data" and listen to the voice channels on a t-berd. --Ricky From fw at deneb.enyo.de Wed May 11 19:07:21 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 May 2016 21:07:21 +0200 Subject: NIST NTP servers In-Reply-To: <20160511001750.GA6228@cmadams.net> (Chris Adams's message of "Tue, 10 May 2016 19:17:50 -0500") References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> Message-ID: <87eg989zx2.fsf@mid.deneb.enyo.de> * Chris Adams: > First, out of the box, if you use the public pool servers (default > config), you'll typically get 4 random (more or less) servers from the > pool. There are a bunch, so Joe Random Hacker isn't going to have a > high chance of guessing the servers your system is using. A determined attacker will just run servers in the official pool. From mel at beckman.org Wed May 11 19:10:57 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 May 2016 19:10:57 +0000 Subject: NIST NTP servers In-Reply-To: <129051.1462989265@turing-police.cc.vt.edu> References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <1506067283.128804.1462980994495.JavaMail.zimbra@baylink.com> <129051.1462989265@turing-police.cc.vt.edu> Message-ID: No, many cell carriers run their own completely independent timing networks. I support some head-ends where they have rubidium clocks and a T1-delivered time source. They do reference GPS, and many cell sites have GPS as a backup clock (you can see their conical antennas on the very top of the tower). But most cellular providers are very protective of their time sources. They?re also typically clocking SONET networks too, which requires BITS. -mel JAshworth said: > CDMA and GSM are false diversity: both network types nodes *get their time* > from GPS, so far as I know. > On May 11, 2016, at 10:54 AM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 11 May 2016 15:36:34 -0000, "Jay R. Ashworth" said: > >> CDMA and GSM are false diversity: both network types nodes *get their time* >> from GPS, so far as I know. > > I'll make the fairly reasonable assumption that most readers of this list have > networks that span multiple buildings. > > If somebody is managing to figure out that you have a GPS in Building 37, and a > GPS-based CDMA up on the corner of Building 3, and the *other* 4 clocks at > other locations and getting close enough to all of them at the same time to > conduct a successful spoofing attack, all just to move your time source a > few seconds off.... > > ... then the fact that GPS is spoofable is probably *NOT* your biggest > security problem. > From swmike at swm.pp.se Wed May 11 19:21:52 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 11 May 2016 21:21:52 +0200 (CEST) Subject: TeamNANOG youtube video seeding In-Reply-To: References: Message-ID: On Tue, 10 May 2016, james machado wrote: > First I am thrilled to see older Nanog meetings making it to youtube. > > Having said that can the people putting up the files put the Nanog > meeting number in the title of the videos to make it easier to search > and determine relevance? +1 from me. I also sent a message to the TeamNANOG youtube account with the same request. -- Mikael Abrahamsson email: swmike at swm.pp.se From eric.kuhnke at gmail.com Wed May 11 20:15:48 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 11 May 2016 13:15:48 -0700 Subject: NIST NTP servers In-Reply-To: References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <1506067283.128804.1462980994495.JavaMail.zimbra@baylink.com> <129051.1462989265@turing-police.cc.vt.edu> Message-ID: Cellular carriers also use GPS timing for many reasons that are not readily apparent at the layer 3 router/IP/BGP network level. One big need is RF related, back-to-back sector antenna frequency re-use with GPS synced timing on the remote radio heads, such as an ABAB configuration on a tower or rooftop site. The same with some much less costly near consumer grade WISP radio platforms and PTP radio systems nowadays. In such a configuration the GPS timing signal from the local GPS receiver (small cone shaped or puck antennas at the site) is actually the primary, and whatever NTP-based GPS signal the network node might have access to is secondary. On Wed, May 11, 2016 at 12:10 PM, Mel Beckman wrote: > No, many cell carriers run their own completely independent timing > networks. I support some head-ends where they have rubidium clocks and a > T1-delivered time source. They do reference GPS, and many cell sites have > GPS as a backup clock (you can see their conical antennas on the very top > of the tower). But most cellular providers are very protective of their > time sources. They?re also typically clocking SONET networks too, which > requires BITS. > > -mel > > > JAshworth said: > > CDMA and GSM are false diversity: both network types nodes *get their > time* > > from GPS, so far as I know. > > > > On May 11, 2016, at 10:54 AM, Valdis.Kletnieks at vt.edu wrote: > > > > On Wed, 11 May 2016 15:36:34 -0000, "Jay R. Ashworth" said: > > > >> CDMA and GSM are false diversity: both network types nodes *get their > time* > >> from GPS, so far as I know. > > > > I'll make the fairly reasonable assumption that most readers of this > list have > > networks that span multiple buildings. > > > > If somebody is managing to figure out that you have a GPS in Building > 37, and a > > GPS-based CDMA up on the corner of Building 3, and the *other* 4 clocks > at > > other locations and getting close enough to all of them at the same time > to > > conduct a successful spoofing attack, all just to move your time source a > > few seconds off.... > > > > ... then the fact that GPS is spoofable is probably *NOT* your biggest > > security problem. > > > > From Valdis.Kletnieks at vt.edu Thu May 12 00:08:32 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 May 2016 20:08:32 -0400 Subject: NIST NTP servers In-Reply-To: <87eg989zx2.fsf@mid.deneb.enyo.de> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> Message-ID: <155332.1463011712@turing-police.cc.vt.edu> On Wed, 11 May 2016 21:07:21 +0200, Florian Weimer said: > * Chris Adams: > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > A determined attacker will just run servers in the official pool. Such attacks have allegedly been attempted against Tor by certain very well funded adversaries. Thus my statement that if you're seeing that scale attack on your time sources, the fact that your time source is being attacked is the *least* of your problems... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From surfer at mauigateway.com Thu May 12 00:20:28 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 11 May 2016 17:20:28 -0700 Subject: NIST NTP servers Message-ID: <20160511172028.A228E336@m0087796.ppops.net> --- mel at beckman.org wrote: From: Mel Beckman Accurate time to the millisecond is pretty much essential for any network troubleshooting. Say you want to diagnose a SIP problem. You collect transaction logs from both phones, the VoIP gateway, and the PBX. Now you try to merge them to derive the sequence of events. You NEED millisecond accuracy. ---------------------------------------- If all logs are sent to a unix server that does syslogd the log entries would go into the file in order no matter what timestamp is on them. scott From eric.kuhnke at gmail.com Thu May 12 00:23:31 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 11 May 2016 17:23:31 -0700 Subject: NIST NTP servers In-Reply-To: <155332.1463011712@turing-police.cc.vt.edu> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> <155332.1463011712@turing-police.cc.vt.edu> Message-ID: Compared to the scale of the budget of small research projects run by national intelligence agency sized organizations, you wouldn't have to be very well funded to run a sizeable proportion of all tor exit nodes with some degree of plausible deniability... 500 credit cards 500 unique bililng names/addresses and sets of contact info spread 500 1U servers around the world in as many geographically unique locations as you can find, with every dedicated hosting/colo company... average of $150/mo x 500 = $75,000 On Wed, May 11, 2016 at 5:08 PM, wrote: > On Wed, 11 May 2016 21:07:21 +0200, Florian Weimer said: > > * Chris Adams: > > > > > First, out of the box, if you use the public pool servers (default > > > config), you'll typically get 4 random (more or less) servers from the > > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > > high chance of guessing the servers your system is using. > > > > A determined attacker will just run servers in the official pool. > > Such attacks have allegedly been attempted against Tor by certain > very well funded adversaries. > > Thus my statement that if you're seeing that scale attack on your time > sources, the fact that your time source is being attacked is the *least* > of your problems... > From gem at rellim.com Thu May 12 00:28:01 2016 From: gem at rellim.com (Gary E. Miller) Date: Wed, 11 May 2016 17:28:01 -0700 Subject: NIST NTP servers In-Reply-To: <20160511172028.A228E336@m0087796.ppops.net> References: <20160511172028.A228E336@m0087796.ppops.net> Message-ID: <20160511172801.32d5dfff@spidey.rellim.com> Yo Scott! On Wed, 11 May 2016 17:20:28 -0700 "Scott Weeks" wrote: > If all logs are sent to a unix server that does > syslogd the log entries would go into the file > in order no matter what timestamp is on them. syslogd can have quite large buffers. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From surfer at mauigateway.com Thu May 12 00:42:34 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 11 May 2016 17:42:34 -0700 Subject: NIST NTP servers Message-ID: <20160511174234.A228E3F7@m0087796.ppops.net> --- gem at rellim.com wrote: From: "Gary E. Miller" Yo Scott! On Wed, 11 May 2016 17:20:28 -0700 "Scott Weeks" wrote: > If all logs are sent to a unix server that does > syslogd the log entries would go into the file > in order no matter what timestamp is on them. syslogd can have quite large buffers. --------------------------------------- Wouldn't the buffers empty in a FIFO manner? scott From gem at rellim.com Thu May 12 00:56:51 2016 From: gem at rellim.com (Gary E. Miller) Date: Wed, 11 May 2016 17:56:51 -0700 Subject: NIST NTP servers In-Reply-To: <20160511174234.A228E3F7@m0087796.ppops.net> References: <20160511174234.A228E3F7@m0087796.ppops.net> Message-ID: <20160511175651.1cd53dc9@spidey.rellim.com> Yo Scott! On Wed, 11 May 2016 17:42:34 -0700 "Scott Weeks" wrote: > > If all logs are sent to a unix server that does > > syslogd the log entries would go into the file > > in order no matter what timestamp is on them. > > syslogd can have quite large buffers. > --------------------------------------- > > > Wouldn't the buffers empty in a FIFO manner? Nope, each local syslog waits until its local buffer is full, or timed out, then sends to the main syslog server. The default flush_timeout() for syslog-ng is 10 seconds. That is a long time when debugging SIP. http://www.syslog.org/syslog-ng/v2/ RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lyndon at orthanc.ca Thu May 12 01:12:03 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 11 May 2016 18:12:03 -0700 Subject: NIST NTP servers In-Reply-To: <20160511174234.A228E3F7@m0087796.ppops.net> References: <20160511174234.A228E3F7@m0087796.ppops.net> Message-ID: <91728C6A-0165-44AE-A5BB-0ADE7789EF2B@orthanc.ca> > On May 11, 2016, at 5:42 PM, Scott Weeks wrote: > > Wouldn't the buffers empty in a FIFO manner? They will empty in whatever order the implementation decides to write them. But what's more important is the order in which the incoming packets are presented to the syslogd process. If you're listening on TCP connections, the receive order is very much determined by the strategy the syslogd implementation uses to read from FDs with available data. I.e. elevator scan, lowest/highest first, circular queue, ... In a threaded implementation, your reader workers, buffer writers, etc., are all at the mercy of the threading implementation; it's difficult to control thread dispatch ordering at that level of granularity. --lyndon From goldbe at cs.bu.edu Wed May 11 19:15:37 2016 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Wed, 11 May 2016 15:15:37 -0400 Subject: NIST NTP servers In-Reply-To: <87eg989zx2.fsf@mid.deneb.enyo.de> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> Message-ID: Well, if you really want to learn about the NTP servers a target is using you can always just sent them a regular NTP timing query (mode 3) and just read off the IP address in the reference ID field of the response (mode 4). Reference ID reveals the target that the client is sync'd to. If you do this over and over as the client changes the servers it sync's to, you learn all the servers. Or if you are really keen you can use our "kiss-of-death" attack to learn all the servers a client is willing to take time from. See sections V.B-V.C of our paper. https://eprint.iacr.org/2015/1020.pdf Sharon On Wed, May 11, 2016 at 3:07 PM, Florian Weimer wrote: > * Chris Adams: > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > A determined attacker will just run servers in the official pool. > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From goldbe at cs.bu.edu Wed May 11 19:17:51 2016 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Wed, 11 May 2016 15:17:51 -0400 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> Message-ID: With the caveat that if some of the servers are inside your own private network then learning who the servers are might be less useful. But this could be an issue for targets who use servers that are exclusively on the public internet. On Wed, May 11, 2016 at 3:15 PM, Sharon Goldberg wrote: > Well, if you really want to learn about the NTP servers a target is using > you can always just sent them a regular NTP timing query (mode 3) and just > read off the IP address in the reference ID field of the response (mode 4). > > > Reference ID reveals the target that the client is sync'd to. > > If you do this over and over as the client changes the servers it sync's > to, you learn all the servers. > > Or if you are really keen you can use our "kiss-of-death" attack to learn > all the servers a client is willing to take time from. See sections V.B-V.C > of our paper. > > https://eprint.iacr.org/2015/1020.pdf > > Sharon > > > > On Wed, May 11, 2016 at 3:07 PM, Florian Weimer wrote: > >> * Chris Adams: >> >> > First, out of the box, if you use the public pool servers (default >> > config), you'll typically get 4 random (more or less) servers from the >> > pool. There are a bunch, so Joe Random Hacker isn't going to have a >> > high chance of guessing the servers your system is using. >> >> A determined attacker will just run servers in the official pool. >> >> > > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From meekjt at gmail.com Wed May 11 15:40:03 2016 From: meekjt at gmail.com (Jon Meek) Date: Wed, 11 May 2016 11:40:03 -0400 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> Message-ID: A note on using a Raspberry Pi as a NTP server. In my limited home lab testing the RPi server had enough instability that Internet time sources were always preferred by my workstation after ntpd had been running for a while. Presumably this was due to the RPi's clock frequency drifting. At some point I will look at it again. If you do want to build your own Stratum 1 server you might want to glance at: https://github.com/meekj/ntp/blob/master/jon_meek_ntp_poster2009a.pdf and the references there. I had hoped to use the very low cost RPi Stratum 1 servers at $DAY_JOB, but the test device was clearly not up to the job. At some point I hope to revisit this and do some more testing like I did for that poster. I'll add in a CDMA server and a dedicated WWVB receiver. Jon From josh at kyneticwifi.com Thu May 12 01:46:18 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 11 May 2016 20:46:18 -0500 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> Message-ID: maybe try with an odroid? On May 11, 2016 8:45 PM, "Jon Meek" wrote: > A note on using a Raspberry Pi as a NTP server. In my limited home lab > testing the RPi server had enough instability that Internet time sources > were always preferred by my workstation after ntpd had been running for a > while. Presumably this was due to the RPi's clock frequency drifting. At > some point I will look at it again. > > If you do want to build your own Stratum 1 server you might want to glance > at: > > https://github.com/meekj/ntp/blob/master/jon_meek_ntp_poster2009a.pdf > > and the references there. > > I had hoped to use the very low cost RPi Stratum 1 servers at $DAY_JOB, but > the test device was clearly not up to the job. At some point I hope to > revisit this and do some more testing like I did for that poster. I'll add > in a CDMA server and a dedicated WWVB receiver. > > Jon > From rea+nanog at grid.kiae.ru Thu May 12 02:23:55 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Thu, 12 May 2016 05:23:55 +0300 Subject: NIST NTP servers In-Reply-To: <20160511172028.A228E336@m0087796.ppops.net> References: <20160511172028.A228E336@m0087796.ppops.net> Message-ID: <20160512022355.GZ3291light.codelabs.ru@light.codelabs.ru> Wed, May 11, 2016 at 05:20:28PM -0700, Scott Weeks wrote: > --- mel at beckman.org wrote: >> From: Mel Beckman >> >> Accurate time to the millisecond is pretty much >> essential for any network troubleshooting. Say >> you want to diagnose a SIP problem. You collect >> transaction logs from both phones, the VoIP >> gateway, and the PBX. Now you try to merge them >> to derive the sequence of events. You NEED >> millisecond accuracy. >> ---------------------------------------- > > If all logs are sent to a unix server that does > syslogd the log entries would go into the file > in order no matter what timestamp is on them. Modulo latencies and jitter from different machines to the log server. Millisecond precision can be harmed by this, easily. Especially by jitter and order of millisecond here isn't something non-existent in a long-distant networks. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From Valdis.Kletnieks at vt.edu Thu May 12 02:38:56 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 May 2016 22:38:56 -0400 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> <155332.1463011712@turing-police.cc.vt.edu> Message-ID: <164721.1463020736@turing-police.cc.vt.edu> On Wed, 11 May 2016 17:23:31 -0700, Eric Kuhnke said: > average of $150/mo x 500 = $75,000 Id worry more about the fact that somebody is willing to spend $75K/mo to attack me than the fact that it might be possible to wiggle my time base a bit. At that point, you *really* have to worry about other, more productive attacks, such as social engineering (including spear phishing and bribery), or obtaining a 0-day against something in your network. Remember that the FBI has basically admitted that the most effective means of uncloaking a Tor user has been browser 0-days, even though decloaking by pwning a majority of the servers is possible.... (Seriously - if *you* had $75K/mo to attack somebody, what would *you* spend it on?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From stenn at ntp.org Thu May 12 03:04:07 2016 From: stenn at ntp.org (Harlan Stenn) Date: Thu, 12 May 2016 03:04:07 +0000 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> Message-ID: Sharon Goldberg writes: > Well, if you really want to learn about the NTP servers a target is using > you can always just sent them a regular NTP timing query (mode 3) and just > read off the IP address in the reference ID field of the response (mode 4). Unless the server is an IPv6 server. This trick only works for IPv4. And we have a fix for all of this that will be out soon. -- Harlan Stenn http://networktimefoundation.org - be a member! From stenn at ntp.org Thu May 12 03:13:46 2016 From: stenn at ntp.org (Harlan Stenn) Date: Thu, 12 May 2016 03:13:46 +0000 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <87eg989zx2.fsf@mid.deneb.enyo.de> Message-ID: Harlan Stenn writes: > Sharon Goldberg writes: > > Well, if you really want to learn about the NTP servers a target is using > > you can always just sent them a regular NTP timing query (mode 3) and just > > read off the IP address in the reference ID field of the response (mode 4). > > Unless the server is an IPv6 server. This trick only works for IPv4. > > And we have a fix for all of this that will be out soon. Also, the attacker will need to know the correct origin timestamp for the brief window where that attack will work, and even if this happens either the client or the server will see syslog entries alerting to the abuse (if folks are running new enough versions of ntpd). H From rjoensen at synack.fo Thu May 12 11:21:59 2016 From: rjoensen at synack.fo (Ragnar =?utf-8?Q?Sigur=C3=B0sson?= Joensen) Date: Thu, 12 May 2016 13:21:59 +0200 (CEST) Subject: DDoS protection: Corero Message-ID: <1876792290.1228327.1463052119034.JavaMail.zimbra@synack.fo> Hello, Quick question. Is there anyone on this list using Corero for DDoS protection? If so I'd much appreciate an off-list review of it. Thanks in advance. Thanks, Ragnar Sigur?sson Joensen, rjoensen at synack.fo Operations, +40799694635 Sp/f Synack | synack at synack.fo | +298 201111 From the.lists at mgm51.com Thu May 12 14:16:40 2016 From: the.lists at mgm51.com (Mike) Date: Thu, 12 May 2016 10:16:40 -0400 Subject: NIST NTP servers In-Reply-To: <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> Message-ID: On 5/11/2016 11:24 AM, Jay R. Ashworth wrote: > ----- Original Message ----- >> From: "Jared Mauch" > >>> Yes, and properly monitor your ntpd instances. >> >> And upgrade them. >> >> Some software distributors don?t ship modern software. if you >> are using a distribution packaged ntpd it?s likely old and >> difficult to determine its lineage due to how it?s packaged. >> >> If you?re using Redhat based systems consider using chrony >> instead, even the new beta fedora 24 uses 4.2.6 derived code >> vs 4.2.8 > > We're all aware this project is underway, right? > > https://www.ntpsec.org/ > Speaking of nascent time projects http://nwtime.org/projects/ntimed/ So far, I like the overall architecture of the client/slave/master task differentiation. I've played around with the client in a test environment and ~it seems to work OK~, but it looks like the project is still a bit in the future. From jared at puck.nether.net Thu May 12 14:34:31 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 12 May 2016 10:34:31 -0400 Subject: NIST NTP servers In-Reply-To: <20160511174254.GB19142@puck.nether.net> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <1438308332.128734.1462980283871.JavaMail.zimbra@baylink.com> <20160511174254.GB19142@puck.nether.net> Message-ID: <1A7A1780-C55D-4598-A84F-45BFBFE32742@puck.nether.net> > On May 11, 2016, at 1:42 PM, Majdi S. Abbas wrote: > > On Wed, May 11, 2016 at 03:24:43PM +0000, Jay R. Ashworth wrote: >> We're all aware this project is underway, right? >> >> https://www.ntpsec.org/ > > Despite the name, I'm not aware of any significant protocol > changes. It's just a recent fork of the reference implementation > minus the refclocks, which isn't particularly helpful if you /don't/ > trust network time sources. I?ll also say that if you?re running NTP with -g beware. "This option allows the time to be set to any value without restriction? Game over if someone decided to go after you, you will never sync. Make sure systemd won?t just restart your daemon, if you get ?invalid? time the process dies and then you?re off. Game over, press redo or back. (yay ti99/4a references) - Jared From nanogml at Mail.DDoS-Mitigator.net Thu May 12 15:44:18 2016 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Thu, 12 May 2016 08:44:18 -0700 Subject: DDoS protection: Corero In-Reply-To: <1876792290.1228327.1463052119034.JavaMail.zimbra@synack.fo> References: <1876792290.1228327.1463052119034.JavaMail.zimbra@synack.fo> Message-ID: <20160512154418.GA7296@Mail.DDoS-Mitigator.net> hi On 05/12/16 at 01:21pm, Ragnar Sigur?sson Joensen wrote: > Quick question. Is there anyone on this list using Corero for DDoS protection? If so I'd much appreciate an off-list review of it. Thanks in advance. hummm ... just some generic comments when comparing "DDoS protection" one DDoS solution is NOT necessarily a cost-effective mitigation against all the various types of DDoS attacks various types of attacks: - tcp-based DDoS attacks on any port are best mitigated with iptables + tarpits ( in-house appliance could handle up to 100gig/sec ) the attacking zombie bots should crash long before they can affect your servers ( 100,000 ddos packet/sec * 2Kbyte/packet * 120sec tcp timeouts ) - udp-based DDoS attacks are best mitigated by confirming that your DNS server/app, NTP server/app, SNMP server/app, NFS, X11, etc, etc properly patched and hardened your ISP will most likely have to be involved to mitigate incoming UDP and ICMP based attacks using various methods like flow analysis/collection/mediation, rtbh, bgp, etc # # if you like the idea of just 'drop the packet" or "limit it", # then, it's too late as you have already received the DDoS packets # and the damage is done ... # - volumetric attacks ( say over 10gigbit/s ) probably will require various data-centers spread across the oceans or use the cloud ... - you will need a security policy ( infrastructure policy ) to define "legitimate traffic" and possibly incomign DDoS attacks simple minded rule: web servers should only run "apache/etc", all packets to the 65,534 ports are attacks mail servers should only run "sendmail/etc", all packets to the other 65,534 ports are attacks - DDoS attacks consisting of silly spam, virii, worms should be non-issues and imho, is easily mitigated w/ dozens of different foss tools and "company/computer/infrastructure policy" magic pixie dust alvin # # http://DDoS-Mitigator.net ..... http://DDoS-Simulator.net .... # From bmengel at gmail.com Thu May 12 15:28:42 2016 From: bmengel at gmail.com (Brian Mengel) Date: Thu, 12 May 2016 11:28:42 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: My comments were strictly limited to my understanding of CALEA as it applied to ISPs, not telcos. A request for a lawful intercept can entail mirroring a real time stream of all data sent to/from a customer's Internet connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this requires mediation before being sent to the LEA and it is the mediation server itself that initiates the intercept when so configured by the ISP. Perhaps some LEAs have undertaken the mediation function so as to facilitate these intercepts where the neither the ISP nor a third party can do so. If that were the case then very little would be needed on the part of the ISP in order to comply with a request for lawful intercept. I can say with certainty that these types of requests are being made of broadband ISPs though I agree that they are very rare. On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel > wrote: > > AFAIK being able to do a lawful intercept on a specific, named, >> individual's service has been a requirement for providers since 2007. >> > > It's been required for longer than that. The telco I worked for over a > decade ago didn't build the infrastructure until the FCC said they were > going to stop funding upgrades. That really got 'em movin'. (suddenly "data > services" people -- i.e. ME -- weren't redheaded stepchildren.) > > have never heard of a provider, big or small, being called out for being >> unable to provide this service when requested. >> > > Where existing infrastructure is not already in place (read: T1/BRI/etc.), > the telco can take up to 60 days to get that setup. I know more than one > telco that used that grace period to actually setup CALEA in the first > place. > > did not perform intercepts routinely. >> > > The historic published figures (i've not looked in years) suggest CALEA > requests are statistically rare. The NC based telco I worked for had never > received an order in the then ~40yr life of the company. > > The mediation server needed to "mediate" between your customer aggregation >> box and the LEA is not inexpensive. >> > > And also is not the telco's problem. Mediation is done by the LEA or 3rd > party under contract to any number of agencies. For example, a telco tap > order would mirror the control and voice traffic of a POTS line (T1/PRI > channel, etc.) into a BRI or specific T1 channel. (dialup was later added, > but wasn't required in my era, so we didn't support it.) We used to test > that by tapping a tech's phone. Not having any mediation software, all I > could do is "yeap, it's sending data" and listen to the voice channels on a > t-berd. > > --Ricky > From jfmezei_nanog at vaxination.ca Thu May 12 17:06:35 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 12 May 2016 13:06:35 -0400 Subject: NIST NTP servers In-Reply-To: <20160510145902.GA29833@nic.fr> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> <20160510145902.GA29833@nic.fr> Message-ID: <5734B81B.1020704@vaxination.ca> On 2016-05-10 10:59, Stephane Bortzmeyer wrote: > Yes, but they may switch it off for civilian use (by going encrypted, > for instance) at any time, if it is better for *their* operations. In the days of selected availability (GPS precision reduced on purpose), the time signal was still very accurate from the point of view of using it as a time source for computers. When Clinton lifted SA, the military reserved the right to re-instate it, and stated that it reserves the right to kill the civilian signal outside the USA. The EU considered launching their own constellation to counter the US possibiliy of a shutdown. Russia launched Glonass and eliminated the need for EU to launch their own. With Glonass now fairly common in GPS receivers, the USA can't unilaterally shut it down anymore. A satellite that is visible from Syria couldn't shutdown its signal without affecting a WHOLE lot of other areas. It is more likely that the USA would just jam the frequencies from a plane over Syria or some other means to geographically block those frequencies. Today, if someone were to jam the GPS signal in an areas in USA, you'd likely hear about large number of car accidents in the news before noticing your systems canMt get time from the GPS-NTP and went to a backup ip address (nist etc). From jfmezei_nanog at vaxination.ca Thu May 12 17:19:39 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 12 May 2016 13:19:39 -0400 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: <5734BB2B.6030307@vaxination.ca> On 2016-05-11 10:30, Mel Beckman wrote: > Read deeper into the thread and you'll find where I sourced inexpensive RF-based NTP servers using CDMA, GSM, and even WWV. For shortwave, you would need to calculate propagation delay between transmitter and receiver. (does signal reach via line of sight, bounce against ionosphere ?). Since CDMA is dead outside the USA and drying in USA, I wouldn't rely on that. If GSM towers rely on a GPS receiver on the tower and those towers are near enough to your location (< 30km), then chances are that blocked GPS signals at your location would also jam the signals at the GSM antenna. And if you are setup to be totally autonomous in case of power failures, you need to know whether the GSM antenna you are relying on is also on permanent power backup or only has autonomy of a few hours. From mel at beckman.org Thu May 12 18:09:52 2016 From: mel at beckman.org (Mel Beckman) Date: Thu, 12 May 2016 18:09:52 +0000 Subject: NIST NTP servers In-Reply-To: <5734BB2B.6030307@vaxination.ca> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <5734BB2B.6030307@vaxination.ca> Message-ID: <8EEEF42A-C04E-4482-853F-047DC9A45779@beckman.org> The WWV signal is still accurate within a few milliseconds. Light is fast. Really fast. -mel > On May 12, 2016, at 10:19 AM, Jean-Francois Mezei wrote: > > On 2016-05-11 10:30, Mel Beckman wrote: > >> Read deeper into the thread and you'll find where I sourced inexpensive RF-based NTP servers using CDMA, GSM, and even WWV. > > For shortwave, you would need to calculate propagation delay between > transmitter and receiver. (does signal reach via line of sight, bounce > against ionosphere ?). > > Since CDMA is dead outside the USA and drying in USA, I wouldn't rely on > that. If GSM towers rely on a GPS receiver on the tower and those > towers are near enough to your location (< 30km), then chances are that > blocked GPS signals at your location would also jam the signals at the > GSM antenna. > > And if you are setup to be totally autonomous in case of power failures, > you need to know whether the GSM antenna you are relying on is also on > permanent power backup or only has autonomy of a few hours. From admin at coldnorthadmin.com Thu May 12 20:07:03 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Thu, 12 May 2016 16:07:03 -0400 Subject: NIST NTP servers In-Reply-To: References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> Message-ID: <5734E267.9060703@coldnorthadmin.com> I did and it works! But as other mentioned, using a passive antenna means that you are very limited in where you can actually use the NTP server. The device failed to acquire a GPS lock with it was 2-3 feet away from a window. But when it did acquire a signal, it happily worked as a Stratum 1 device servicing what felt like all the CPE devices around Montreal. It's definitely not something that can be massively deployed to data centers where the physical layout can change a lot. It might be worth looking into an active antenna but I would also have doubts over running anything business critical on a RP2. https://coldnorthadmin.com/raspberry-pi-2-ntp-server-stratum-1/ Cheers, Laurent On 5/11/2016 6:47 AM, Dovid Bender wrote: > What about something like this? > http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html > Has anyone used a Pi to create their own server? > > > On Wed, May 11, 2016 at 3:24 AM, Mel Beckman wrote: > >> Regarding Roland?s reference to time and position spoofing via a hacked >> GPS signal, the hacker has to get physical line of sight to the victim?s >> antenna in order to succeed with this attack. That?s likely within a few >> blocks, if not within a few feet. And a rooftop antenna might require a >> drone attack. And how does the drone get guidance without a reliable GPS >> signal? :) >> >> Eric, I agree that sometimes a site can?t get a GPS signal, but in my >> experience designing data centers, that?s still pretty rare. Many NTP >> systems use an active GPS antenna that can be hundreds of feet away. But >> you can always put the $300 NTP server in an outdoor enclosure and power it >> with PoE. >> >> There?s always CDMA, GSM, and even WWV for a less-accurate plan B time >> source. Here?s a somewhat pricey ($700) CDMA gizmo I haven?t investigated >> yet: >> >> http://www.beaglesoft.com/celsynhowworks.htm >> >> And their $400 WWV-based Stratum 1 time server: >> >> http://www.beaglesoft.com/radsynreceiver.htm >> >> So if you want non-Internet clock diversity, you can have clock diversity. >> You just have to pay for it. >> >> -mel >> >> On May 10, 2016, at 9:18 PM, Eric Kuhnke > eric.kuhnke at gmail.com>> wrote: >> >> For quite some time, in debian the default configuration for the ntpd.conf >> that ships with the package for the ntpd is to poll from four different, >> semi-randomly assigned DNS pool based sources. I believe the same is true >> for redhat/centos. >> >> In the event that one out of four sources is wildly wrong the ntpd will >> ignore it. >> >> If people have routers/networking equipment inside their network that only >> supports retrieving ntp from one IP address (or hostname) and have manually >> configured it to request time from a single external source, not their own >> internal ntpd that is <10ms away, bad things could definitely happen. >> >> It is worthwhile to have both polling from external sources via IP as well >> as GPS sync. Many locations in a network have no hope of getting a GPS >> signal or putting an antenna with a clear view to the sky, but may be on a >> network segment that is <4ms away from many other nodes where you can >> colocate a 1U box and GPS antenna. >> >> On Tue, May 10, 2016 at 9:05 PM, Joe Klein > jsklein at gmail.com>> wrote: >> >> Is this group aware of the incident with tock.usno.navy.mil & >> tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 >> years for the period of one hour, then return? >> >> The reasons were not fully explained, but the impact was global. Routers, >> switches, power grids, phone systems, certificates, encryption, Kerberos, >> logging and any tightly coupled transaction systems were impacted. >> >> So I began doing 'security research' on the topic (don't confuse me with >> joe hacker), and discovered both interesting and terrifying issues, which I >> will not disclose on an open forum. >> >> Needless to say, my suggestions are: >> 1. Configure a trusted time source and good time stratum architecture for >> your organization. >> 2. When identifying your source of time, the majority of the technologies >> can be DDOS'ed, spoofed or MITM, so consider using redundant sources and >> authentication. >> 3. For distribution of time information inside your organization, ensure >> your critical systems (Encryption, PKI, transactions, etc) are using your >> redundant sources and authentication. >> 4. Operating systems, programming languages, libraries, and applications >> are sensitive to time changes and can fail in unexpected ways. Test them >> before it's too late. >> 5. Disallow internal system to seek NTP from other sources beyond your edge >> routers. >> 6. All core time systems should be monitored by your security team or SOC. >> >> One question, is this a topic anyone would find interested at a future >> NANOG? Something like "Hacking and Defending time?". >> >> >> Joe Klein >> "Inveniam viam aut faciam" >> >> PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 >> >> On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > mel at beckman.org>> wrote: >> >> I don't pretend to know all the ways a hacker can find out what nap >> servers a company uses, but I can envision a virus that could do that >> once >> behind a firewall. Every ntp response lists the current reference ntp >> server in the next higher stratum. There are many ways that process could >> harvest all ntp servers over time, and then pass the public IP back to a >> mother ship controller. It could be going on right now. >> >> My point is, when the fix is so cheap, why put up with this risk at all? >> >> -mel beckman >> >> On May 10, 2016, at 5:18 PM, Chris Adams > cma at cmadams.net>> wrote: >> >> Once upon a time, Mel Beckman > >> said: >> Boss: So how did a hacker get in and crash our accounting server, >> break >> our VPNs, and kill our network performance? >> >> IT guy: He changed our clocks. >> >> So, this has been repeated several times (with how bad things will go >> if >> your clocks get changed by years). It isn't that easy. >> >> First, out of the box, if you use the public pool servers (default >> config), you'll typically get 4 random (more or less) servers from the >> pool. There are a bunch, so Joe Random Hacker isn't going to have a >> high chance of guessing the servers your system is using. >> >> Second, he'd have to guess at least three to "win". >> >> Third, at best, he'd only be able to change your clocks a little; the >> common software won't step the clock more than IIRC 15 minutes. Yes, >> that can cause problems, but not the catastrophes of years in the >> future >> or Jan 1, 1970 mentioned in this thread. >> >> Is it possible to cause problems? Yes. Is it a practical attack? I'm >> not so sure, and I haven't seen proof to the contrary. >> -- >> Chris Adams > >> >> >> >> From lyndon at orthanc.ca Thu May 12 20:23:32 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 12 May 2016 13:23:32 -0700 (PDT) Subject: NIST NTP servers In-Reply-To: <5734E267.9060703@coldnorthadmin.com> References: <20160510152219.GA32797@ussenterprise.ufp.org> <791FF3E9-AB7B-4EE2-A093-94C1F7C3BCF4@puck.nether.net> <20160510134040.60c35755@spidey.rellim.com> <8DDF00BD-5823-40A3-9A1F-7F98396BCDF7@puck.nether.net> <6C6CBDEB-C95E-41CA-8642-FC6F5662B57F@beckman.org> <20160511001750.GA6228@cmadams.net> <7CF92DB7-0D9D-4CAC-B1C6-B338A540E3FD@beckman.org> <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org> <5734E267.9060703@coldnorthadmin.com> Message-ID: > [...] but I would also have doubts over running anything business > critical on a RP2. We use them as reverse terminal servers, for dhcp/tftp bootstrapping other machines, and soon, NTP. They are absolutely rock solid. There's something to be said for "no moving parts inside." --lyndon From sathish.kumar.ippani at gmail.com Thu May 12 13:21:52 2016 From: sathish.kumar.ippani at gmail.com (sathish kumar Ippani) Date: Thu, 12 May 2016 18:51:52 +0530 Subject: Internet DATA Center IP base utilization/Bandwidth Billing Message-ID: Hello All, We are looking for software/hardware which can monitor bandwidth usage of each IP address that enters Data center/Leave data center. Based on Bandwidth usage it will draw a graph or calculate Billing. We are running Datacenter and having 2000 and more clients. they are hosted their Network devices. -- With Regards, Sathish Ippani 9177166040 From dwing at cisco.com Thu May 12 15:24:59 2016 From: dwing at cisco.com (=?utf-8?Q?=F0=9F=94=93Dan_Wing?=) Date: Thu, 12 May 2016 08:24:59 -0700 Subject: AT&T postmaster Message-ID: <2FD24CA1-0EBE-4007-9012-2C9EB0A7523C@cisco.com> I help run a community machine (not for my employer) and we've been trying unsuccessfully for a month to get off AT&T's email blacklist; their automated systems claim we're off, but mail is still being blocked. Can an AT&T postmaster drop me an email to help work through this? Thanks. -d From john at souvestre.com Thu May 12 18:39:11 2016 From: john at souvestre.com (John Souvestre) Date: Thu, 12 May 2016 13:39:11 -0500 Subject: NIST NTP servers In-Reply-To: References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> Message-ID: <008801d1ac7d$93c07c50$bb4174f0$@Souvestre.com> > ... a dedicated WWVB receiver. The Enhanced WWVB signal has better range and more accuracy, but I don't know if any receivers are available yet. John John Souvestre - New Orleans LA -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Meek Sent: 2016 May 11, Wed 10:40 To: nanog at nanog.org list Subject: Re: NIST NTP servers A note on using a Raspberry Pi as a NTP server. In my limited home lab testing the RPi server had enough instability that Internet time sources were always preferred by my workstation after ntpd had been running for a while. Presumably this was due to the RPi's clock frequency drifting. At some point I will look at it again. If you do want to build your own Stratum 1 server you might want to glance at: https://github.com/meekj/ntp/blob/master/jon_meek_ntp_poster2009a.pdf and the references there. I had hoped to use the very low cost RPi Stratum 1 servers at $DAY_JOB, but the test device was clearly not up to the job. At some point I hope to revisit this and do some more testing like I did for that poster. I'll add in a CDMA server and a dedicated WWVB receiver. Jon From cma at cmadams.net Fri May 13 02:20:42 2016 From: cma at cmadams.net (Chris Adams) Date: Thu, 12 May 2016 21:20:42 -0500 Subject: NIST NTP servers In-Reply-To: <008801d1ac7d$93c07c50$bb4174f0$@Souvestre.com> References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> <008801d1ac7d$93c07c50$bb4174f0$@Souvestre.com> Message-ID: <20160513022042.GA24092@cmadams.net> Once upon a time, John Souvestre said: > The Enhanced WWVB signal has better range and more accuracy, but I don't know if any receivers are available yet. I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). At one point, they were going to put a second transmitter closer to the east coast, and it was going to be at the Army's Redstone Arsenal, next to Huntsville, AL, where I live; I probably could have put a receiver in a steel box and still had good signal! NASA vetoed it though. -- Chris Adams From john at souvestre.com Fri May 13 03:17:40 2016 From: john at souvestre.com (John Souvestre) Date: Thu, 12 May 2016 22:17:40 -0500 Subject: NIST NTP servers In-Reply-To: <20160513022042.GA24092@cmadams.net> References: <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> <20160511145333.GC75456@ussenterprise.ufp.org> <008801d1ac7d$93c07c50$bb4174f0$@Souvestre.com> <20160513022042.GA24092@cmadams.net> Message-ID: <00da01d1acc6$022caf40$06860dc0$@Souvestre.com> >>> I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). You are correct, but the what I read from NIST is that the Enhanced (PM) format " will allow faster and more accurate synchronization, as well as further address reception at particularly low SNIR." So perhaps I should have said better "resolution" rather than "accuracy". :) John ??? John Souvestre - New Orleans LA -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Adams Sent: 2016 May 12, Thu 21:21 To: nanog at nanog.org Subject: Re: NIST NTP servers Once upon a time, John Souvestre said: > The Enhanced WWVB signal has better range and more accuracy, but I don't know if any receivers are available yet. I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). At one point, they were going to put a second transmitter closer to the east coast, and it was going to be at the Army's Redstone Arsenal, next to Huntsville, AL, where I live; I probably could have put a receiver in a steel box and still had good signal! NASA vetoed it though. -- Chris Adams From george.herbert at gmail.com Fri May 13 04:38:16 2016 From: george.herbert at gmail.com (George Herbert) Date: Thu, 12 May 2016 21:38:16 -0700 Subject: NIST NTP servers In-Reply-To: <20160511133127.GA75456@ussenterprise.ufp.org> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <04a201d1aac8$6320f360$2962da20$@gmail.com> <20160510125806.17324e29@spidey.rellim.com> <7D10E910-339D-4E59-881E-DF977E41CF11@beckman.org> <20160511133127.GA75456@ussenterprise.ufp.org> Message-ID: > On May 11, 2016, at 6:31 AM, Leo Bicknell wrote: > ... > You're replacing one single point of failure with another. > > Personally, my network gets NTP from 14 stratum 1 sources right now. > You, and the hacker, do not know which ones. You have to guess at least > 8 to get me to move to your "hacked" time. Good luck. ...except for people who think that N internet only servers is enough redundancy. Pretty much anything with unfiltered outbound could put out enough forged UDP to effectively jam ALL the Stratum 1 servers for a given endpoint. George William Herbert Sent from my iPhone From dot at dotat.at Fri May 13 10:08:36 2016 From: dot at dotat.at (Tony Finch) Date: Fri, 13 May 2016 11:08:36 +0100 Subject: NIST NTP servers In-Reply-To: <5734B81B.1020704@vaxination.ca> References: <0E81961D-CCEB-4CA9-9D6B-327B3E253F52@beckman.org> <20160510031222.GA6790@puck.nether.net> <20160510143954.GA27288@nic.fr> <7376.1462891948@turing-police.cc.vt.edu> <20160510145902.GA29833@nic.fr> <5734B81B.1020704@vaxination.ca> Message-ID: Jean-Francois Mezei wrote: > > Today, if someone were to jam the GPS signal in an areas in USA, you'd > likely hear about large number of car accidents in the news before > noticing your systems canMt get time from the GPS-NTP and went to a > backup ip address (nist etc). The USA and the UK governments regularly perform GPS jamming tests, but they do so in remote areas. See http://www.navcen.uscg.gov/?pageName=gpsServiceInterruptions http://stakeholders.ofcom.org.uk/spectrum/gps-jamming-exercises/ (Dunno if other governments have similar exercises.) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea, South Shannon: Northerly or northeasterly 4 or 5, occasionally 6 except in south Shannon. Slight or moderate. Mainly fair. Good, occasionally poor at first in south Lundy. From dwhite at olp.net Fri May 13 13:33:15 2016 From: dwhite at olp.net (Dan White) Date: Fri, 13 May 2016 08:33:15 -0500 Subject: Internet DATA Center IP base utilization/Bandwidth Billing In-Reply-To: References: Message-ID: <20160513133315.GQ2168@dan.olp.net> We use Calix Flow Analyze. On 05/12/16?18:51?+0530, sathish kumar Ippani wrote: >Hello All, > >We are looking for software/hardware which can monitor bandwidth usage of >each IP address that enters Data center/Leave data center. > >Based on Bandwidth usage it will draw a graph or calculate Billing. > > >We are running Datacenter and having 2000 and more clients. they are hosted >their Network devices. > >-- >With Regards, > >Sathish Ippani >9177166040 -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From esr at thyrsus.com Fri May 13 04:20:02 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 13 May 2016 00:20:02 -0400 (EDT) Subject: A briefing on NTPsec Message-ID: <20160513042002.5C20913A098B@snark.thyrsus.com> Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From esr at thyrsus.com Fri May 13 11:31:28 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 13 May 2016 07:31:28 -0400 (EDT) Subject: A briefing on NTPsec Message-ID: <20160513113129.0062013A0994@snark.thyrsus.com> Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- Eric S. Raymond From harisir18 at gmail.com Fri May 13 02:11:53 2016 From: harisir18 at gmail.com (Hari Haran) Date: Fri, 13 May 2016 07:41:53 +0530 Subject: Internet DATA Center IP base utilization/Bandwidth Billing In-Reply-To: References: Message-ID: Hi Software name ntop On Thursday 12 May 2016, sathish kumar Ippani < sathish.kumar.ippani at gmail.com> wrote: > Hello All, > > We are looking for software/hardware which can monitor bandwidth usage of > each IP address that enters Data center/Leave data center. > > Based on Bandwidth usage it will draw a graph or calculate Billing. > > > We are running Datacenter and having 2000 and more clients. they are hosted > their Network devices. > > -- > With Regards, > > Sathish Ippani > 9177166040 > -- *Thanks & Regards* *Hari Haran * *IT Manager* *Seven Star Dot Com Pvt Ltd*Mhada Bldg No.8, Flat No.001, Blue Bell Co-Op Hsg Soc, Near Tarapore Towers, New Link Road,Oshiwara, Andheri (W), Mumbai - 400 053 Tel: +91-22 2632 1214/15 , 2636 4003/7 Cell No.+91-9819046500 E-Mail : harry at 7starnetwork.com / harry at balajiinternet.com Website : www.7starnetwork.com / www.balajiinternet.com From lowen at pari.edu Fri May 13 14:12:49 2016 From: lowen at pari.edu (Lamar Owen) Date: Fri, 13 May 2016 10:12:49 -0400 Subject: NIST NTP servers In-Reply-To: References: Message-ID: <5735E0E1.6010807@pari.edu> On 05/11/2016 09:46 PM, Josh Reynolds wrote: > maybe try [setting up an NTP server] with an odroid? > ... I have several ODroid C2's, and the first thing to note about them is that there is no RTC at all. Also, the oscillator is just a garden-variety non-temperature-compensated quartz crystal, and not necessarily a very precise one, either (precise quartz oscillators can cost more than the whole ODroid board costs). The XU4 and other ODroid devices make nice single-board ARM computers, but have pretty ratty oscillator precision. You really have to have at least a temperature compensated quartz crystal oscillator (TCXO) to even begin to think about an NTP server, for anything but the most rudimentary of timing. Ovenized quartz oscillators (OCXO) and rubidium standards are the next step up, and most reasonably good GPS-disciplined clocks have at least an ovenized quartz oscillator module (the Agilent Z3816 and kin are of this type). From mel at beckman.org Fri May 13 14:38:58 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 May 2016 14:38:58 +0000 Subject: NIST NTP servers In-Reply-To: <5735E0E1.6010807@pari.edu> References: , <5735E0E1.6010807@pari.edu> Message-ID: <983135C8-1A27-4F9C-B2ED-BE360865C479@beckman.org> Lamar, You make it sound like TXCOs are rare, but they're actually quite common in most single board computers. True, you're probably not gonna find them in the $35 cellular-based SBCs, but since these temperature compensated oscillators cost less than a dollar each in quantity, they're quite common in most industrial species for well under $100. An Ovenized XCO is absolutely not required for IT-grade NTP servers. If you need sub-microsecond low-jitter leading-edge clocks, for BITS timing of SONET or radio networks for example, then an OXCO is helpful. But NTP itself is not that accurate. NTP can usually maintain time to only within tens of milliseconds over the public Internet, and can only achieve better than one millisecond accuracy in local area networks under ideal conditions. -mel > On May 13, 2016, at 7:13 AM, Lamar Owen wrote: > >> On 05/11/2016 09:46 PM, Josh Reynolds wrote: >> maybe try [setting up an NTP server] with an odroid? >> > ... > > I have several ODroid C2's, and the first thing to note about them is that there is no RTC at all. Also, the oscillator is just a garden-variety non-temperature-compensated quartz crystal, and not necessarily a very precise one, either (precise quartz oscillators can cost more than the whole ODroid board costs). The XU4 and other ODroid devices make nice single-board ARM computers, but have pretty ratty oscillator precision. > > You really have to have at least a temperature compensated quartz crystal oscillator (TCXO) to even begin to think about an NTP server, for anything but the most rudimentary of timing. Ovenized quartz oscillators (OCXO) and rubidium standards are the next step up, and most reasonably good GPS-disciplined clocks have at least an ovenized quartz oscillator module (the Agilent Z3816 and kin are of this type). > From laszlo at heliacal.net Fri May 13 14:40:10 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 13 May 2016 14:40:10 +0000 Subject: NIST NTP servers In-Reply-To: <5735E0E1.6010807@pari.edu> References: <5735E0E1.6010807@pari.edu> Message-ID: <810d7497-38b2-a255-cbb5-fbb928550a8c@heliacal.net> On 2016-05-13 14:12, Lamar Owen wrote: > On 05/11/2016 09:46 PM, Josh Reynolds wrote: >> maybe try [setting up an NTP server] with an odroid? >> > ... > > > You really have to have at least a temperature compensated quartz > crystal oscillator (TCXO) to even begin to think about an NTP server, > for anything but the most rudimentary of timing. > There are WWVB clocks that try to sync nightly. Many of them don't even have a second indicator, but they give reliable time to the minute. NTP is a lot better than this as it continuously disciplines the clock instead of just lining it up once a day, but we're talking about doing this over the internet where we measure latency in milliseconds. If you're working down at the picosecond level you will probably not be using NTP to distribute your clock signal. Running an NTP client against pool servers is a lot better than not running it at all, but running it against a fancy local server with a GPSDO hooked up to it is only marginally better than the pool servers. It all depends on what you want to do but a cheap ARM or Intel Atom computer works well for an NTP server (remember millisecond level accuracy). If you can afford to build a secure bunker with armed guards and redundant everything for your time server that's good, but a few RPi style computers with GPS hats are almost as good, and you can buy a lot of them for very little money.. -Laszlo From cra at WPI.EDU Fri May 13 14:46:02 2016 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 13 May 2016 10:46:02 -0400 Subject: NIST NTP servers In-Reply-To: <5735E0E1.6010807@pari.edu> References: <5735E0E1.6010807@pari.edu> Message-ID: <20160513144601.GK32297@angus.ind.wpi.edu> On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote: > On 05/11/2016 09:46 PM, Josh Reynolds wrote: > >maybe try [setting up an NTP server] with an odroid? > > > ... > > I have several ODroid C2's, and the first thing to note about them > is that there is no RTC at all. Also, the oscillator is just a > garden-variety non-temperature-compensated quartz crystal, and not > necessarily a very precise one, either (precise quartz oscillators > can cost more than the whole ODroid board costs). The XU4 and other > ODroid devices make nice single-board ARM computers, but have pretty > ratty oscillator precision. > > You really have to have at least a temperature compensated quartz > crystal oscillator (TCXO) to even begin to think about an NTP > server, for anything but the most rudimentary of timing. Ovenized > quartz oscillators (OCXO) and rubidium standards are the next step > up, and most reasonably good GPS-disciplined clocks have at least an > ovenized quartz oscillator module (the Agilent Z3816 and kin are of > this type). Does anyone know of any COTS NTP servers that are based on non-ancient Linux kernel versions? In 2012 we bought new GPS/CDMA NTP servers with OCXO that are based on Linux 2.4, but they are fiddly as you can imagine with such an ancient software stack. What would people recommend for NTP server hardware/software? From goldbe at cs.bu.edu Fri May 13 14:52:14 2016 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Fri, 13 May 2016 10:52:14 -0400 Subject: NIST NTP servers In-Reply-To: <20160513144601.GK32297@angus.ind.wpi.edu> References: <5735E0E1.6010807@pari.edu> <20160513144601.GK32297@angus.ind.wpi.edu> Message-ID: Since we are on the subject, I would strongly recommend that you don't run NTP on Linux 2.2.13, since its especially vulnerable to our IPv4 fragmentation attack. "SunOS" also seems vulnerable, but I am not 100% sure what systems that say they are "SunOS" actually are. These OS will fragment packets to 64 bytes, and are vulnerable to frag attacks using "tiny" fragments. See Section VI of our paper: https://eprint.iacr.org/2015/1020.pdf You can also test your OS here (scroll to the bottom). http://www.cs.bu.edu/~goldbe/NTPattack.html On Fri, May 13, 2016 at 10:46 AM, Chuck Anderson wrote: > On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote: > > On 05/11/2016 09:46 PM, Josh Reynolds wrote: > > >maybe try [setting up an NTP server] with an odroid? > > > > > ... > > > > I have several ODroid C2's, and the first thing to note about them > > is that there is no RTC at all. Also, the oscillator is just a > > garden-variety non-temperature-compensated quartz crystal, and not > > necessarily a very precise one, either (precise quartz oscillators > > can cost more than the whole ODroid board costs). The XU4 and other > > ODroid devices make nice single-board ARM computers, but have pretty > > ratty oscillator precision. > > > > You really have to have at least a temperature compensated quartz > > crystal oscillator (TCXO) to even begin to think about an NTP > > server, for anything but the most rudimentary of timing. Ovenized > > quartz oscillators (OCXO) and rubidium standards are the next step > > up, and most reasonably good GPS-disciplined clocks have at least an > > ovenized quartz oscillator module (the Agilent Z3816 and kin are of > > this type). > > Does anyone know of any COTS NTP servers that are based on non-ancient > Linux kernel versions? In 2012 we bought new GPS/CDMA NTP servers > with OCXO that are based on Linux 2.4, but they are fiddly as you can > imagine with such an ancient software stack. > > What would people recommend for NTP server hardware/software? > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From mel at beckman.org Fri May 13 15:02:19 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 May 2016 15:02:19 +0000 Subject: A briefing on NTPsec In-Reply-To: <20160513113129.0062013A0994@snark.thyrsus.com> References: <20160513113129.0062013A0994@snark.thyrsus.com> Message-ID: <4545B8C2-8B6A-4BCF-831F-C36CC34959D5@beckman.org> Eric, Thanks for this really helpful insider look into NTPsec. Does your project have anything like a portable regression test suite that the rest of us could use for NTP product evaluations? And what I be correct in guessing that all of your work is foss? When you say that nothing has been done to add security mechanisms to NTP, are you saying that all the work so far has been code hardening exclusively? Finally, do you want to weigh in on the necessity for highly accurate local RT clocks in NTP servers? That seems to be the big bugaboo in cost limiting right now. -mel beckman > On May 13, 2016, at 6:40 AM, Eric S. Raymond wrote: > > Jay Ashworth informs me that NTP security and risks has recently been > a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've > written a bit of a background briefing on the project, which follows. > > The NTPsec project was initially funded in late 2014 by NSF when > authorities there became concerned about frequent incidents of DDoS > amplification involving ntpd. I was hired in as tech lead early on (in > part because of my work on GPSD, a technically similar project) and > retained that position when the Linux Foundation picked up funding > the project. It's now managed by Mark Atwood, who some of you may know > from HPE and OpenStack. > > I'm going to pass over the politics around the fork from what our team > now calls "NTP Classic" because it wasn't my decision or desire, merely > observing that I reluctantly acknowledged the necessity and wish > things could have been otherwise. > > The goal of NTPsec is to achieve high security and high assurance > through systematic application of modern best practices. Though not > yet at release 1.0, our progress can be judged by the fact that when > the last batch of 11 CVEs against NTP was released, we were not > vulnerable to 8 of them because we had previously removed or successfully > hardened the code they exploited. > > This was no fluke. Over the last 11 months, we have compiled a > significantly - I think it's fair to say "dramatically" - better > security record than Classic. We've earned some trust in the infosec > research community, working effectively with (among others) Sharon > Goldberg's group at BU. We were the first to develop a verified fix > for the now infamous off-path KOD bug (CVE-2015-7979). > > You can read more about our code-hardening practices here: > > http://esr.ibiblio.org/?p=6881 > > In brief, we've thrown out a lot of cruft and archaisms. The code has > been lifted to C99/POSIX-2001 conformance; other than a few warts near > Mac OS X and some unused Windows code probably destined for removal > itself, the port shims that used to infest the codebase are nearly > gone. Mode 7 has been removed, as has Autokey; these were nests of > bugs too risky to leave in. > > We've also done a lot of code auditing using tools like Coverity and > cppcheck, and worked hard on improving our test coverage (that part has > been more difficult than any of the code changes, actually, and is > still very much a work in progress). > > Here's a figure that should tell you a lot: we removed 57% of the > original codebase in the process of cleaning it up. No, that's not > a typo; the NTPsec codebase is *less than half* the size of NTP > Classic. And much, much easier to read. That's even without > counting the huge simplification win from ditching autotools. > > Nevertheless, sysdamins will find it very familiar. The largest > speedbump you will encounter in normal operation is that we've > changed the names of some auxiliary tools so everything has an "ntp" > prefix. The only thing I expect to actually surprise you is the > documentation, which has been greatly improved, specifically by > removing duplications and inconsistencies and distracting references > to equipment that has been dead since the Late Cretaceous. > > So far this is a deliberately conservative fork. We haven't yet tried > to add protocol features for security because there is plenty of > useful work to be done before tackling that very hard problem. We're > actively cooperating with the IETF NTP WG (we've committed to > supplying second interop for some upcoming draft RFCs) and we're > watching the work on NTS closely. It is likely, though not yet > certain, that we'll be second interop on that. > > Finally, I note some criticism that NTPsec is short on people who > understand all the subtleties of time service in the field. This is > partly justified. The tech lead admits to being something of a newbie; > though I know a lot about some adjacent technical areas from ten years > of leading GPSD, I was not a time-service expert before being engaged > for this project and am still coming up to speed. > > The team does already include one time-service old hand and a really > good crypto/infosec specialist. NANOG listmember Gary E. Miller was > an early team member who remains a friend of the project. We would > certainly welcome more engagement and advice fom time-service experts, > and the sort of experienced sysadmins who frequent NANOG. > > In a future post I may have a bit to say about Stratum 1s based on the > RPi and other hackerboards. I've been working in that area as well. > > I'll be happy to answer technical and procedural questions about NTPsec. > Any questions about politics and policy should go to Mark Atwood. > > See www.ntpsec.org for more information. > -- > Eric S. Raymond From lowen at pari.edu Fri May 13 16:29:54 2016 From: lowen at pari.edu (Lamar Owen) Date: Fri, 13 May 2016 12:29:54 -0400 Subject: NIST NTP servers In-Reply-To: <983135C8-1A27-4F9C-B2ED-BE360865C479@beckman.org> References: Message-ID: <57360102.9060809@pari.edu> On 05/13/2016 10:38 AM, Mel Beckman wrote: > You make it sound like TXCOs are rare, but they're actually quite common in most single board computers. True, you're probably not gonna find them in the $35 cellular-based SBCs, but since these temperature compensated oscillators cost less than a dollar each in quantity, they're quite common in most industrial species for well under $100. Correct, they're not rare in the industrial line (for that matter you can get TCXO-equipped RTL-SDR dongles, but that's not NTP-related). Something like a Transko TFC or TX-P or similar is enough for reasonable timing for basic purposes, and they're not expensive. They're also not a stock item on the consumer-level SBC's either. I looked at one of our half-dozen ODroid C2's, and the main processor clock, X3, is under the heatsink, so I can't see what part is being used. X1 and X2 are outside, and it doesn't appear that they are TCXO modules, although I didn't use a magnifier to check the part number and might have made an error. The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost choice at $12 (need to have an RPi, ODroid, or similar on which to mount it). It's not that TCXO's are rare or expensive, it's that they're not often considered to be important to accuracy in many circles. > An Ovenized XCO is absolutely not required for IT-grade NTP servers. No, but it is for my purposes here. But, as I said in my post: > You really have to have at least a temperature compensated quartz crystal oscillator (TCXO) to even begin to think about an NTP server, for anything but the most rudimentary of timing. Ovenized quartz oscillators (OCXO) and rubidium standards are the next step up, ... I was just saying that OCXO and Rb are just the next step up if you would like more stability, that's all. For 'within a second' on a GPS-disciplined clock (even without the 1PPS signal) you wouldn't necessarily need TXCO. But that's what I meant by 'anything but the most rudimentary of timing.' Rudimentary is down to the millisecond in my environment. PTP takes you to the next level, and beyond that you don't use network timing but put a dedicated time distribution network running IRIG-B or similar. But that is beyond the scope of a typical IT NTP server's needs..... From esr at thyrsus.com Fri May 13 17:46:42 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 13 May 2016 13:46:42 -0400 Subject: A briefing on NTPsec In-Reply-To: <4545B8C2-8B6A-4BCF-831F-C36CC34959D5@beckman.org> References: <20160513113129.0062013A0994@snark.thyrsus.com> <4545B8C2-8B6A-4BCF-831F-C36CC34959D5@beckman.org> Message-ID: <20160513174642.GA6599@thyrsus.com> Mel Beckman : > Does your project have anything like a portable regression test > suite that the rest of us could use for NTP product evaluations? We do not, yet. Testing NTP at above the level of unit tests for individual functions is *quite* difficult - I say that as the person who successfully implemented a very rigorous regression-test suite in GPSD. The NTP version of this problem is, unfortunately, much less tractable. We have some ideas and a partial implementation, but this is the technical area in which we have had the least success so far. We will persevere. We're going to need good end-to-end testing to maintain provable functional stability through some of the large changes I have in mind. I cannot, however, promise that our test framework will be applicable to other implementations. >And what I be correct in guessing that all of your work is foss? Yes. NTP and 2-clause BSD licenses. > When you say that nothing has been done to add security mechanisms > to NTP, are you saying that all the work so far has been code > hardening exclusively? Yes. There remains a considerable amount of this to be done. We have our eyes on several risky and only marginally useful features that should probably be excised. The recently-acquired ability of Windows to run many Linux binaries probably means all the Windows port shims can be thrown out. And so forth. The official motto of our project, front and center on www.ntpsec.org, is the Saint-Exupery quote: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." I must say that the effectiveness of ruthlessly cutting away bloat as a security-hardening strategy has actually exceeded our initial expectations. We were hoping for "successful" and seem to have achieved "wildly successful" - I think dodging 8 of 11 CVEs in the last batch counts as that. > Finally, do you want to weigh in on the necessity for highly > accurate local RT clocks in NTP servers? That seems to be the big > bugaboo in cost limiting right now. I'll reply to this starting a separate thread. -- Eric S. Raymond From cscora at apnic.net Fri May 13 18:09:01 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 May 2016 04:09:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201605131809.u4DI91Aa027770@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 May, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 593720 Prefixes after maximum aggregation (per Origin AS): 217775 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290742 Total ASes present in the Internet Routing Table: 53727 Prefixes per ASN: 11.05 Origin-only ASes present in the Internet Routing Table: 36600 Origin ASes announcing only one prefix: 15688 Transit ASes present in the Internet Routing Table: 6437 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 33 Prefixes from unregistered ASNs in the Routing Table: 1414 Unregistered ASNs in the Routing Table: 444 Number of 32-bit ASNs allocated by the RIRs: 13845 Number of 32-bit ASNs visible in the Routing Table: 10690 Prefixes from 32-bit ASNs in the Routing Table: 42050 Number of bogon 32-bit ASNs visible in the Routing Table: 3 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 386 Number of addresses announced to Internet: 2811463492 Equivalent to 167 /8s, 147 /16s and 135 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193775 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151912 Total APNIC prefixes after maximum aggregation: 42356 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 162829 Unique aggregates announced from the APNIC address blocks: 66401 APNIC Region origin ASes present in the Internet Routing Table: 5177 APNIC Prefixes per ASN: 31.45 APNIC Region origin ASes announcing only one prefix: 1181 APNIC Region transit ASes present in the Internet Routing Table: 913 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2070 Number of APNIC addresses announced to Internet: 755234628 Equivalent to 45 /8s, 3 /16s and 247 /24s Percentage of available APNIC address space announced: 88.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 181169 Total ARIN prefixes after maximum aggregation: 89627 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 186526 Unique aggregates announced from the ARIN address blocks: 88714 ARIN Region origin ASes present in the Internet Routing Table: 16363 ARIN Prefixes per ASN: 11.40 ARIN Region origin ASes announcing only one prefix: 5835 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 36 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1199 Number of ARIN addresses announced to Internet: 1101775680 Equivalent to 65 /8s, 171 /16s and 195 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 142528 Total RIPE prefixes after maximum aggregation: 70293 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 151781 Unique aggregates announced from the RIPE address blocks: 93519 RIPE Region origin ASes present in the Internet Routing Table: 18087 RIPE Prefixes per ASN: 8.39 RIPE Region origin ASes announcing only one prefix: 7914 RIPE Region transit ASes present in the Internet Routing Table: 3016 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4740 Number of RIPE addresses announced to Internet: 704636544 Equivalent to 41 /8s, 255 /16s and 230 /24s Percentage of available RIPE address space announced: 102.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61743 Total LACNIC prefixes after maximum aggregation: 12246 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 76062 Unique aggregates announced from the LACNIC address blocks: 35972 LACNIC Region origin ASes present in the Internet Routing Table: 2475 LACNIC Prefixes per ASN: 30.73 LACNIC Region origin ASes announcing only one prefix: 576 LACNIC Region transit ASes present in the Internet Routing Table: 558 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2469 Number of LACNIC addresses announced to Internet: 170943808 Equivalent to 10 /8s, 48 /16s and 101 /24s Percentage of available LACNIC address space announced: 101.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 14214 Total AfriNIC prefixes after maximum aggregation: 3215 AfriNIC Deaggregation factor: 4.42 Prefixes being announced from the AfriNIC address blocks: 16136 Unique aggregates announced from the AfriNIC address blocks: 5791 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 21.86 AfriNIC Region origin ASes announcing only one prefix: 182 AfriNIC Region transit ASes present in the Internet Routing Table: 168 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 212 Number of AfriNIC addresses announced to Internet: 78489600 Equivalent to 4 /8s, 173 /16s and 168 /24s Percentage of available AfriNIC address space announced: 78.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5558 4192 76 China Education and Research 7545 3307 354 213 TPG Telecom Limited 4766 3167 11145 1123 Korea Telecom 17974 2937 914 96 PT Telekomunikasi Indonesia 9829 2469 1467 464 National Internet Backbone 4755 2095 432 243 TATA Communications formerly 9808 1928 8717 30 Guangdong Mobile Communicatio 4808 1659 2299 551 CNCGROUP IP network China169 9583 1512 122 562 Sify Limited 38197 1501 93 215 Sun Network (Hong Kong) Limit Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3250 2947 137 Cox Communications Inc. 6389 2301 3671 41 BellSouth.net Inc. 18566 2204 394 275 MegaPath Corporation 20115 1920 1937 403 Charter Communications 30036 1722 342 356 Mediacom Communications Corp 6983 1689 849 232 EarthLink, Inc. 209 1613 4680 1267 Qwest Communications Company, 4323 1519 985 376 tw telecom holdings, inc. 16625 1314 484 694 Akamai Technologies, Inc. 701 1296 10718 704 MCI Communications Services, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2544 981 1835 Akamai International B.V. 34984 1964 326 357 TELLCOM ILETISIM HIZMETLERI A 8551 1228 376 55 Bezeq International-Ltd 12479 1202 996 88 France Telecom Espana SA 6849 1148 355 21 JSC "Ukrtelecom" 13188 1078 98 65 TOV "Bank-Inform" 8402 1028 544 15 OJSC "Vimpelcom" 31148 1026 47 45 Freenet Ltd. 9198 939 352 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3479 542 134 Telmex Colombia S.A. 8151 2243 3406 563 Uninet S.A. de C.V. 7303 1511 940 234 Telecom Argentina S.A. 11830 1481 368 52 Instituto Costarricense de El 6503 1475 437 55 Axtel, S.A.B. de C.V. 6147 1158 377 27 Telefonica del Peru S.A.A. 26615 1016 2325 34 Tim Celular S.A. 3816 997 478 186 COLOMBIA TELECOMUNICACIONES S 7738 994 1882 40 Telemar Norte Leste S.A. 11172 905 125 77 Alestra, S. de R.L. de C.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1261 402 45 Link Egypt (Link.NET) 37611 648 48 2 Afrihost-Brevis Computer Serv 36903 625 314 106 Office National des Postes et 36992 511 1357 26 ETISALAT MISR 8452 505 1471 15 TE-AS 37492 395 234 68 Orange Tunisie 24835 329 402 15 Vodafone Data 29571 301 37 13 Cote d'Ivoire Telecom 2018 257 327 74 TENET (The UNINET Project) 36947 240 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5558 4192 76 China Education and Research 10620 3479 542 134 Telmex Colombia S.A. 7545 3307 354 213 TPG Telecom Limited 22773 3250 2947 137 Cox Communications Inc. 4766 3167 11145 1123 Korea Telecom 17974 2937 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2544 981 1835 Akamai International B.V. 9829 2469 1467 464 National Internet Backbone 6389 2301 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3479 3345 Telmex Colombia S.A. 22773 3250 3113 Cox Communications Inc. 7545 3307 3094 TPG Telecom Limited 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2937 2841 PT Telekomunikasi Indonesia 6389 2301 2260 BellSouth.net Inc. 4766 3167 2044 Korea Telecom 9829 2469 2005 National Internet Backbone 18566 2204 1929 MegaPath Corporation 9808 1928 1898 Guangdong Mobile Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.190.0.0/24 63393 BOOM NET 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:267 /13:509 /14:1037 /15:1761 /16:13022 /17:7635 /18:12747 /19:25946 /20:37976 /21:39776 /22:65656 /23:57370 /24:328155 /25:554 /26:597 /27:421 /28:46 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2478 3250 Cox Communications Inc. 18566 2106 2204 MegaPath Corporation 30036 1536 1722 Mediacom Communications Corp 6389 1477 2301 BellSouth.net Inc. 10620 1370 3479 Telmex Colombia S.A. 6983 1338 1689 EarthLink, Inc. 34984 1248 1964 TELLCOM ILETISIM HIZMETLERI A 11492 1193 1289 CABLE ONE, INC. 6849 968 1148 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:728 4:21 5:2070 6:28 8:955 12:1776 13:39 14:1684 15:45 16:2 17:84 18:89 20:48 23:1593 24:1772 27:2273 31:1765 32:59 33:2 34:2 35:5 36:303 37:2297 38:1217 39:28 40:91 41:2849 42:395 43:1757 44:42 45:1843 46:2518 47:79 49:1166 50:872 51:34 52:181 54:329 55:6 56:6 57:42 58:1541 59:866 60:347 61:1822 62:1477 63:1919 64:4441 65:2155 66:4246 67:2153 68:1088 69:3284 70:1101 71:469 72:1990 74:2543 75:344 76:348 77:1369 78:1264 79:839 80:1267 81:1348 82:952 83:697 84:815 85:1581 86:474 87:1052 88:561 89:1995 90:174 91:6063 92:899 93:2334 94:2338 95:2313 96:518 97:358 98:935 99:46 100:74 101:1046 103:10738 104:2466 105:123 106:398 107:1166 108:669 109:2187 110:1249 111:1654 112:989 113:1143 114:1046 115:1576 116:1579 117:1428 118:2050 119:1617 120:932 121:1176 122:2160 123:2008 124:1568 125:1717 128:690 129:402 130:407 131:1327 132:636 133:176 134:453 135:126 136:374 137:352 138:1716 139:261 140:543 141:458 142:641 143:923 144:694 145:157 146:867 147:637 148:1473 149:505 150:647 151:877 152:579 153:281 154:624 155:944 156:493 157:415 158:355 159:1120 160:480 161:708 162:2332 163:560 164:900 165:1056 166:318 167:1148 168:1804 169:660 170:1569 171:263 172:553 173:1645 174:742 175:737 176:1738 177:3971 178:2209 179:1157 180:2055 181:1776 182:1894 183:949 184:808 185:6373 186:2996 187:2134 188:2127 189:1723 190:7731 191:1249 192:8947 193:5736 194:4377 195:3767 196:1695 197:1038 198:5558 199:5713 200:6967 201:3725 202:10118 203:9635 204:4519 205:2727 206:2978 207:3122 208:4053 209:3840 210:3912 211:2053 212:2695 213:2232 214:852 215:71 216:5787 217:1941 218:792 219:593 220:1680 221:870 222:664 223:1222 End of report From vwittkop at nanog.org Fri May 13 18:11:15 2016 From: vwittkop at nanog.org (Valerie Wittkop) Date: Fri, 13 May 2016 14:11:15 -0400 Subject: [NANOG-announce] NOTR - Thank you Denver, CO and Announcing NYC Message-ID: <26F6172A-EEC3-45EA-8875-BC6635963245@nanog.org> We extend a very big Thank You to Denver, CO for such a successful NOTR event on Tuesday. Great presentations and a large crowd made the day great for everyone! We are very excited to be holding the next NOTR event in New York City NOTR event in N ew York City on July 21, 2016, in partnership with NYNOG , and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road NYC event is perfect for you! Date: July 21, 2016 Time: Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM Location: New York Marriott Marquis N ew York Marriott Marquis - 1535 Broadway, New York, NY 10036 The FREE to attend event is open for registration. Register Now! Agenda Topics are posted, which include: - Life After IPv4 - Traceroute Tutorial - IPv6 Tutorial - BGP Tutorial If you are, or will be, in the New York City area, we invite you to attend. And don?t forget to attend NYNOG?s Meetup #1 on May 25, 2016. Click here for more information about their event. Learn more about On The Road events here . Feel free to contact us at nanog-support at nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From esr at thyrsus.com Fri May 13 19:39:27 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 13 May 2016 15:39:27 -0400 (EDT) Subject: Cost-effectivenesss of highly-accurate clocks for NTP Message-ID: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Mel Beckman : >Finally, do you want to weigh in on the necessity for highly accurate local RT >clocks in NTP servers? That seems to be the big bugaboo in cost limiting right >now. Yes, this is a topic on which I have some well-developed judgments due to having collected (and, where practical, tested) a pretty comprehensive set of figures on components of the NTP error budget. I've even invented some hardware that simplifies the problem. The background to my findings is laid out in my "Introduction to Time Service" HOWTO: http://www.catb.org/gpsd/time-service-intro.html I find that an effective way to learn my way into a new application domain is to first do knowledge capture on the assumptions its experts are using and then document those. "Introduction to Time Service" was written to do that and as a white paper for my project management. Criticism and corrections are, of course, welcome. In order to discuss the value of accurate clocks intelligently, we need to split apart two issues: accuracy and availability. Of course we want the most accurate time our networks can deliver; we also want to hedge against sporadic or systemic failure of single time sources. The most important simplification of either issue is that clock accuracy worth paying for is bounded both by user expectations and the noise floor defined by our network jitter. According to RFC 5095 expected accuracy of NTP time is "several tens of milliseconds." User expectations seem to evolved to on the close order of 10ms. I think it's not by coincidence this is pretty close to the jitter in ping times I see when I bounce ICMP off a well-provisioned site like (say) google.com through my Verizon FIOS connection. It's good rule-of-thumb engineering that if you want to be metrologically accurate you should pay for precision an order of magnitude below your feature size *and not more than that*. Thus, with a feature size of 10ms the economic sweet spot is a clock with accuracy about 1ms. One reason discussions of how to budget for WAN timeservice clocks has tended to become heated in the past is that nothing inexpensive hit this sweet spot. The world was largely divided between cheap time sources with too much jitter (e.g. GPS in-band data with a wander of 100ms or worse) and expensive high-precision clocks designed for PTP over Ethernet that deliver three or more orders of magnitude than WAN time service can actually use. However...also use the 1PPS signal your GPS engine ships (top of UTC second accurate to about 50ns) and the picture changes completely. With that over RS232 your delivered accuracy rises to single-digit numbers of microseconds, which is two orders of magnitude below what you need for your 1ms goal. Now we have a historical problem, though: RS232 and the handshake lines you could use to signal 1PPS are dying, being replaced by USB. which doesn't normally bring 1PPS out to where the timeserver OS can see it. In 2012, nearly three years before being recruited for NTPsec, I solved this problem as part of my work on GPSD. The key to this solution is an obscure feature of USB, and a one-wire patch to the bog-standard design for generic USB that exploits it. Technical details on request, but what it comes down to is that with this one weird trick(!) you can mass-produce primary time sources with a jitter bounded by the USB polling interval for about $20 a pop. The USB 1 polling interval is 1ms. Bingo. We're done. If we're only weighting accuracy and not availability, a USB GPS is as much clock as you need for WAN timeservice *provided it exposes 1PPS*. These devices exist, because I designed them and found a shop in Shenzhen to build them. They're called the Navisys GR-601W, GR-701W, and GR-801W. (A viable, only skightly more expensive alternative is to mate a GPS daughterboard to a hackerboard like the Raspberry Pi and run NTP service on that. I'll have much, much more to say about that in a future post.) Of course, now we have to talk about availability. GPS sometimes loses lock. There are sporadic and systemic availability risks due to jamming and system failures like the 2012 hiccup, and extreme scenarios like a giant meteorite hitting GPSS ground control in Colorado. What you should be willing to pay for a hedge against this is proportional to your 95% confidence estimate of the maximum outage interval. At the low end, this is simple; put your antenna on a mast that guarantees unobstructed skyview. At the high end it's effectively impossible, in that anything that takes down GNSS and Galileo permanently (giant meteor impact, war in space, collapse of the U.S. and Europe) is likely to be in the you-have-much-bigger- problems than-inaccurate-time department. Traditionally dedicated time-source hardware like rubidium-oscillator GPSDOs is sold on accuracy, but for WAN time service their real draw is long holdover time with lower frequency drift that you get from the cheap, non-temperature-compensated quartz crystals in your PC. There is room for debate about how much holdover you should pay for, but you'll at least be thinking more clearly about the problem if you recognize that you *should not* buy expensive hardware for accuracy. For WAN time service, in that price range, you're wither buying holdover and knowing you're doing so or wasting your money. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From mel at beckman.org Fri May 13 20:38:41 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 May 2016 20:38:41 +0000 Subject: NIST NTP servers In-Reply-To: <57360102.9060809@pari.edu> References: <983135C8-1A27-4F9C-B2ED-BE360865C479@beckman.org>, <57360102.9060809@pari.edu> Message-ID: Lamar, Because you need microsecond-level time accuracy (which is beyond NTP's capabilities) you'll requires an adjunct protocol, such as PPS, to get that. For continued NTP delivery despite periodic GPS signal loss, then you need an OCXO internal clock. But anyone satisfied with NTP's millisecond time accuracy at worst needs a $1 temperature-compensated internal clock. Either method needs the specs for a Stratum 1 time source on a local network. As you point out, the hobbyist SBCs can't deliver even basic clock accuracy. But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. But I see that the price premium for an OCXO clock is only $100 to $200 on low-cost (I.e., ~$500) commercial NTP servers. So buyers need only make a minor cost adjustment to have very good, and inexpensive, COTS NTP performance and reliability. -mel beckman > On May 13, 2016, at 9:30 AM, Lamar Owen wrote: > >> On 05/13/2016 10:38 AM, Mel Beckman wrote: >> You make it sound like TXCOs are rare, but they're actually quite common in most single board computers. True, you're probably not gonna find them in the $35 cellular-based SBCs, but since these temperature compensated oscillators cost less than a dollar each in quantity, they're quite common in most industrial species for well under $100. > > Correct, they're not rare in the industrial line (for that matter you can get TCXO-equipped RTL-SDR dongles, but that's not NTP-related). Something like a Transko TFC or TX-P or similar is enough for reasonable timing for basic purposes, and they're not expensive. They're also not a stock item on the consumer-level SBC's either. I looked at one of our half-dozen ODroid C2's, and the main processor clock, X3, is under the heatsink, so I can't see what part is being used. X1 and X2 are outside, and it doesn't appear that they are TCXO modules, although I didn't use a magnifier to check the part number and might have made an error. > > The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost choice at $12 (need to have an RPi, ODroid, or similar on which to mount it). It's not that TCXO's are rare or expensive, it's that they're not often considered to be important to accuracy in many circles. > >> An Ovenized XCO is absolutely not required for IT-grade NTP servers. > > No, but it is for my purposes here. But, as I said in my post: > > >> You really have to have at least a temperature compensated quartz crystal oscillator (TCXO) to even begin to think about an NTP server, for anything but the most rudimentary of timing. Ovenized quartz oscillators (OCXO) and rubidium standards are the next step up, ... > > I was just saying that OCXO and Rb are just the next step up if you would like more stability, that's all. For 'within a second' on a GPS-disciplined clock (even without the 1PPS signal) you wouldn't necessarily need TXCO. But that's what I meant by 'anything but the most rudimentary of timing.' Rudimentary is down to the millisecond in my environment. PTP takes you to the next level, and beyond that you don't use network timing but put a dedicated time distribution network running IRIG-B or similar. But that is beyond the scope of a typical IT NTP server's needs..... > From baldur.norddahl at gmail.com Fri May 13 21:01:21 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 13 May 2016 23:01:21 +0200 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160513193927.BCB8F13A098B@snark.thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: Den 13. maj 2016 21.40 skrev "Eric S. Raymond" : > Traditionally dedicated time-source hardware like rubidium-oscillator > GPSDOs is sold on accuracy, but for WAN time service their real draw > is long holdover time with lower frequency drift that you get from the > cheap, non-temperature-compensated quartz crystals in your PC. > > There is room for debate about how much holdover you should pay for, > but you'll at least be thinking more clearly about the problem if > you recognize that you *should not* buy expensive hardware for > accuracy. For WAN time service, in that price range, you're wither > buying holdover and knowing you're doing so or wasting your money. Ok how many hours or days of holdover can you expect from quartz, temperature compensated quartz or Rubidium? Should we calculate holdover as time until drift is more than 1 millisecond, 10 ms or more for NTP applications? I am thinking that many available datacenter locations will have poor GPS signal so we can expect signal loss to be common. Some weather patterns might even cause extended GPS signal loss. Regards Baldur From mel at beckman.org Fri May 13 22:12:31 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 May 2016 22:12:31 +0000 Subject: NIST NTP servers In-Reply-To: References: <983135C8-1A27-4F9C-B2ED-BE360865C479@beckman.org>, <57360102.9060809@pari.edu>, Message-ID: <1F26B4E0-F420-462D-B40E-C2DB61164D4B@beckman.org> "Either method needs the specs" should read "Either method meets the specs." -mel beckman > On May 13, 2016, at 1:39 PM, Mel Beckman wrote: > > Lamar, > > Because you need microsecond-level time accuracy (which is beyond NTP's capabilities) you'll requires an adjunct protocol, such as PPS, to get that. For continued NTP delivery despite periodic GPS signal loss, then you need an OCXO internal clock. > > But anyone satisfied with NTP's millisecond time accuracy at worst needs a $1 temperature-compensated internal clock. Either method needs the specs for a Stratum 1 time source on a local network. > > As you point out, the hobbyist SBCs can't deliver even basic clock accuracy. > > But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. > > But I see that the price premium for an OCXO clock is only $100 to $200 on low-cost (I.e., ~$500) commercial NTP servers. So buyers need only make a minor cost adjustment to have very good, and inexpensive, COTS NTP performance and reliability. > > -mel beckman > >>> On May 13, 2016, at 9:30 AM, Lamar Owen wrote: >>> >>> On 05/13/2016 10:38 AM, Mel Beckman wrote: >>> You make it sound like TXCOs are rare, but they're actually quite common in most single board computers. True, you're probably not gonna find them in the $35 cellular-based SBCs, but since these temperature compensated oscillators cost less than a dollar each in quantity, they're quite common in most industrial species for well under $100. >> >> Correct, they're not rare in the industrial line (for that matter you can get TCXO-equipped RTL-SDR dongles, but that's not NTP-related). Something like a Transko TFC or TX-P or similar is enough for reasonable timing for basic purposes, and they're not expensive. They're also not a stock item on the consumer-level SBC's either. I looked at one of our half-dozen ODroid C2's, and the main processor clock, X3, is under the heatsink, so I can't see what part is being used. X1 and X2 are outside, and it doesn't appear that they are TCXO modules, although I didn't use a magnifier to check the part number and might have made an error. >> >> The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost choice at $12 (need to have an RPi, ODroid, or similar on which to mount it). It's not that TCXO's are rare or expensive, it's that they're not often considered to be important to accuracy in many circles. >> >>> An Ovenized XCO is absolutely not required for IT-grade NTP servers. >> >> No, but it is for my purposes here. But, as I said in my post: >> >> >>> You really have to have at least a temperature compensated quartz crystal oscillator (TCXO) to even begin to think about an NTP server, for anything but the most rudimentary of timing. Ovenized quartz oscillators (OCXO) and rubidium standards are the next step up, ... >> >> I was just saying that OCXO and Rb are just the next step up if you would like more stability, that's all. For 'within a second' on a GPS-disciplined clock (even without the 1PPS signal) you wouldn't necessarily need TXCO. But that's what I meant by 'anything but the most rudimentary of timing.' Rudimentary is down to the millisecond in my environment. PTP takes you to the next level, and beyond that you don't use network timing but put a dedicated time distribution network running IRIG-B or similar. But that is beyond the scope of a typical IT NTP server's needs..... >> From jared at puck.nether.net Fri May 13 23:05:55 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 13 May 2016 19:05:55 -0400 Subject: B5-Lite Message-ID: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. Thanks, - Jared From faisal at snappytelecom.net Sat May 14 01:30:19 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 14 May 2016 01:30:19 +0000 (GMT) Subject: B5-Lite In-Reply-To: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> Message-ID: <1506068650.192047.1463189419737.JavaMail.zimbra@snappytelecom.net> Best place to ask this question would be the WISPA list (public one or Member's list). Plus you can ask ask this question on Facebook, WISPA Pictures or Mimosa Group ! Lots of good info there. Like all fixed wireless, in unlicensed freq...there are if's and's or but's.... Depending on your particular link, and what problem you are trying to solve, the Mimosa's would be a logical and good upgrade path from Ubiquiti M5 radios.... Weather you use B5-lite or B5's would depend on a few factors. :) Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Jared Mauch" > To: "nanog list" > Sent: Friday, May 13, 2016 7:05:55 PM > Subject: B5-Lite > Anyone deployed this radio in production in the US? I?m curious to hear from > people who are using it, looking at replacing some UBNT hardware with it on > some PTP links, going from the M-series class devices to something more modern. > > Thanks, > > - Jared From eric at ericheather.com Sat May 14 05:43:10 2016 From: eric at ericheather.com (Eric C. Miller) Date: Sat, 14 May 2016 05:43:10 +0000 Subject: B5-Lite In-Reply-To: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> Message-ID: B5c is the only product that I've had much success with from Mimosa. The B5Lite is a cheap plastic shell and, and it performs like it too. If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. Eric Miller, CCNP Network Engineering Consultant -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Friday, May 13, 2016 7:06 PM To: North American Network Operators' Group Subject: B5-Lite Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. Thanks, - Jared From mattlists at rivervalleyinternet.net Sat May 14 10:07:37 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 14 May 2016 06:07:37 -0400 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> Message-ID: <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? > On May 14, 2016, at 01:43, Eric C. Miller wrote: > > B5c is the only product that I've had much success with from Mimosa. > > The B5Lite is a cheap plastic shell and, and it performs like it too. > > If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. > > > Eric Miller, CCNP > Network Engineering Consultant > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > Sent: Friday, May 13, 2016 7:06 PM > To: North American Network Operators' Group > Subject: B5-Lite > > Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. > > Thanks, > > - Jared From hal at buzcom.net Sat May 14 12:31:10 2016 From: hal at buzcom.net (Hal Ponton) Date: Sat, 14 May 2016 13:31:10 +0100 Subject: B5-Lite In-Reply-To: <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Message-ID: We've deployed 2 B5 links into production, the newer firmware seems to have fixed the issues we saw in the links when we first tested them. We have a very rural customer where two hops are needed around the site. We're lucky in that we had two 80MHz channels free. We see around 350Mbps both ways actual throughput on both links. However, these links are short est. 200mtrs when we had tested these on longer links their performance was awful, on a 40MHz channel we saw 20Mbps. For our longer links that need a bit more throughput than a Rocket M5 we either use Licensed radios or the AF5X which works very well. Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi > On 14 May 2016, at 11:07, Matt Hoppes wrote: > > Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? > >> On May 14, 2016, at 01:43, Eric C. Miller wrote: >> >> B5c is the only product that I've had much success with from Mimosa. >> >> The B5Lite is a cheap plastic shell and, and it performs like it too. >> >> If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. >> >> >> Eric Miller, CCNP >> Network Engineering Consultant >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch >> Sent: Friday, May 13, 2016 7:06 PM >> To: North American Network Operators' Group >> Subject: B5-Lite >> >> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. >> >> Thanks, >> >> - Jared From jared at puck.nether.net Sat May 14 13:28:07 2016 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 14 May 2016 09:28:07 -0400 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Message-ID: <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if your effective range won't support a "short" 3-4km link. Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe AF5X instead I guess. Thanks! Jared Mauch > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > We've deployed 2 B5 links into production, the newer firmware seems to have fixed the issues we saw in the links when we first tested them. > > We have a very rural customer where two hops are needed around the site. We're lucky in that we had two 80MHz channels free. We see around 350Mbps both ways actual throughput on both links. > > However, these links are short est. 200mtrs when we had tested these on longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > For our longer links that need a bit more throughput than a Rocket M5 we either use Licensed radios or the AF5X which works very well. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > >> On 14 May 2016, at 11:07, Matt Hoppes wrote: >> >> Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? >> >>> On May 14, 2016, at 01:43, Eric C. Miller wrote: >>> >>> B5c is the only product that I've had much success with from Mimosa. >>> >>> The B5Lite is a cheap plastic shell and, and it performs like it too. >>> >>> If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. >>> >>> >>> Eric Miller, CCNP >>> Network Engineering Consultant >>> >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch >>> Sent: Friday, May 13, 2016 7:06 PM >>> To: North American Network Operators' Group >>> Subject: B5-Lite >>> >>> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. >>> >>> Thanks, >>> >>> - Jared From josh at imaginenetworksllc.com Sat May 14 13:30:46 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 14 May 2016 09:30:46 -0400 Subject: B5-Lite In-Reply-To: <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: AF5X is hard to beat and cheaper... Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On May 14, 2016 9:29 AM, "Jared Mauch" wrote: > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if your > effective range won't support a "short" 3-4km link. > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > AF5X instead I guess. > > Thanks! > > Jared Mauch > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > We've deployed 2 B5 links into production, the newer firmware seems to > have fixed the issues we saw in the links when we first tested them. > > > > We have a very rural customer where two hops are needed around the site. > We're lucky in that we had two 80MHz channels free. We see around 350Mbps > both ways actual throughput on both links. > > > > However, these links are short est. 200mtrs when we had tested these on > longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > > > For our longer links that need a bit more throughput than a Rocket M5 we > either use Licensed radios or the AF5X which works very well. > > > > Regards, > > > > Hal Ponton > > > > Senior Network Engineer > > > > Buzcom / FibreWiFi > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> > >> Jared - why not go to Ubiquiti AC gear if you need some more speed and > something more modern? > >> > >>> On May 14, 2016, at 01:43, Eric C. Miller > wrote: > >>> > >>> B5c is the only product that I've had much success with from Mimosa. > >>> > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > >>> > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > strongly recommend that you stear away from the lite and go with the B5c. > We use them with rocket dishes. You just need the RP-SMA to N cables. > >>> > >>> > >>> Eric Miller, CCNP > >>> Network Engineering Consultant > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > >>> Sent: Friday, May 13, 2016 7:06 PM > >>> To: North American Network Operators' Group > >>> Subject: B5-Lite > >>> > >>> Anyone deployed this radio in production in the US? I?m curious to > hear from people who are using it, looking at replacing some UBNT hardware > with it on some PTP links, going from the M-series class devices to > something more modern. > >>> > >>> Thanks, > >>> > >>> - Jared > > From josh at kyneticwifi.com Sat May 14 13:44:43 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 14 May 2016 08:44:43 -0500 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: WHAT HAVE YOU DONE WITH THE REAL JOSH LUTHMAN?! On May 14, 2016 8:33 AM, "Josh Luthman" wrote: > AF5X is hard to beat and cheaper... > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On May 14, 2016 9:29 AM, "Jared Mauch" wrote: > > > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if your > > effective range won't support a "short" 3-4km link. > > > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > > AF5X instead I guess. > > > > Thanks! > > > > Jared Mauch > > > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > > > We've deployed 2 B5 links into production, the newer firmware seems to > > have fixed the issues we saw in the links when we first tested them. > > > > > > We have a very rural customer where two hops are needed around the > site. > > We're lucky in that we had two 80MHz channels free. We see around 350Mbps > > both ways actual throughput on both links. > > > > > > However, these links are short est. 200mtrs when we had tested these on > > longer links their performance was awful, on a 40MHz channel we saw > 20Mbps. > > > > > > For our longer links that need a bit more throughput than a Rocket M5 > we > > either use Licensed radios or the AF5X which works very well. > > > > > > Regards, > > > > > > Hal Ponton > > > > > > Senior Network Engineer > > > > > > Buzcom / FibreWiFi > > > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > > mattlists at rivervalleyinternet.net> wrote: > > >> > > >> Jared - why not go to Ubiquiti AC gear if you need some more speed and > > something more modern? > > >> > > >>> On May 14, 2016, at 01:43, Eric C. Miller > > wrote: > > >>> > > >>> B5c is the only product that I've had much success with from Mimosa. > > >>> > > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > > >>> > > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > > strongly recommend that you stear away from the lite and go with the B5c. > > We use them with rocket dishes. You just need the RP-SMA to N cables. > > >>> > > >>> > > >>> Eric Miller, CCNP > > >>> Network Engineering Consultant > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared > Mauch > > >>> Sent: Friday, May 13, 2016 7:06 PM > > >>> To: North American Network Operators' Group > > >>> Subject: B5-Lite > > >>> > > >>> Anyone deployed this radio in production in the US? I?m curious to > > hear from people who are using it, looking at replacing some UBNT > hardware > > with it on some PTP links, going from the M-series class devices to > > something more modern. > > >>> > > >>> Thanks, > > >>> > > >>> - Jared > > > > > From sryan at arbor.net Sat May 14 13:46:10 2016 From: sryan at arbor.net (Spencer Ryan) Date: Sat, 14 May 2016 09:46:10 -0400 Subject: B5-Lite In-Reply-To: <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: I didn't think the AF5 was much cheaper than an AF24 and I'd much rather be up in the 24GHz band and out of any contention in 5GHz. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Sat, May 14, 2016 at 9:28 AM, Jared Mauch wrote: > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if your > effective range won't support a "short" 3-4km link. > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > AF5X instead I guess. > > Thanks! > > Jared Mauch > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > We've deployed 2 B5 links into production, the newer firmware seems to > have fixed the issues we saw in the links when we first tested them. > > > > We have a very rural customer where two hops are needed around the site. > We're lucky in that we had two 80MHz channels free. We see around 350Mbps > both ways actual throughput on both links. > > > > However, these links are short est. 200mtrs when we had tested these on > longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > > > For our longer links that need a bit more throughput than a Rocket M5 we > either use Licensed radios or the AF5X which works very well. > > > > Regards, > > > > Hal Ponton > > > > Senior Network Engineer > > > > Buzcom / FibreWiFi > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> > >> Jared - why not go to Ubiquiti AC gear if you need some more speed and > something more modern? > >> > >>> On May 14, 2016, at 01:43, Eric C. Miller > wrote: > >>> > >>> B5c is the only product that I've had much success with from Mimosa. > >>> > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > >>> > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > strongly recommend that you stear away from the lite and go with the B5c. > We use them with rocket dishes. You just need the RP-SMA to N cables. > >>> > >>> > >>> Eric Miller, CCNP > >>> Network Engineering Consultant > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch > >>> Sent: Friday, May 13, 2016 7:06 PM > >>> To: North American Network Operators' Group > >>> Subject: B5-Lite > >>> > >>> Anyone deployed this radio in production in the US? I?m curious to > hear from people who are using it, looking at replacing some UBNT hardware > with it on some PTP links, going from the M-series class devices to > something more modern. > >>> > >>> Thanks, > >>> > >>> - Jared > > From josh at imaginenetworksllc.com Sat May 14 13:52:05 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 14 May 2016 09:52:05 -0400 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: AF5X. The AF5 is not all that good (integrated small dishes for fdx, yuck). The real Josh is still waiting on UbntChuck to do a ptmp sync product. At least we're 2/3 of the way there :) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On May 14, 2016 9:49 AM, "Spencer Ryan" wrote: > I didn't think the AF5 was much cheaper than an AF24 and I'd much rather be > up in the 24GHz band and out of any contention in 5GHz. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Sat, May 14, 2016 at 9:28 AM, Jared Mauch > wrote: > > > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if your > > effective range won't support a "short" 3-4km link. > > > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > > AF5X instead I guess. > > > > Thanks! > > > > Jared Mauch > > > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > > > We've deployed 2 B5 links into production, the newer firmware seems to > > have fixed the issues we saw in the links when we first tested them. > > > > > > We have a very rural customer where two hops are needed around the > site. > > We're lucky in that we had two 80MHz channels free. We see around 350Mbps > > both ways actual throughput on both links. > > > > > > However, these links are short est. 200mtrs when we had tested these on > > longer links their performance was awful, on a 40MHz channel we saw > 20Mbps. > > > > > > For our longer links that need a bit more throughput than a Rocket M5 > we > > either use Licensed radios or the AF5X which works very well. > > > > > > Regards, > > > > > > Hal Ponton > > > > > > Senior Network Engineer > > > > > > Buzcom / FibreWiFi > > > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > > mattlists at rivervalleyinternet.net> wrote: > > >> > > >> Jared - why not go to Ubiquiti AC gear if you need some more speed and > > something more modern? > > >> > > >>> On May 14, 2016, at 01:43, Eric C. Miller > > wrote: > > >>> > > >>> B5c is the only product that I've had much success with from Mimosa. > > >>> > > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > > >>> > > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > > strongly recommend that you stear away from the lite and go with the B5c. > > We use them with rocket dishes. You just need the RP-SMA to N cables. > > >>> > > >>> > > >>> Eric Miller, CCNP > > >>> Network Engineering Consultant > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared > Mauch > > >>> Sent: Friday, May 13, 2016 7:06 PM > > >>> To: North American Network Operators' Group > > >>> Subject: B5-Lite > > >>> > > >>> Anyone deployed this radio in production in the US? I?m curious to > > hear from people who are using it, looking at replacing some UBNT > hardware > > with it on some PTP links, going from the M-series class devices to > > something more modern. > > >>> > > >>> Thanks, > > >>> > > >>> - Jared > > > > > From lowen at pari.edu Sat May 14 14:27:41 2016 From: lowen at pari.edu (Lamar Owen) Date: Sat, 14 May 2016 10:27:41 -0400 Subject: NIST NTP servers In-Reply-To: References: <983135C8-1A27-4F9C-B2ED-BE360865C479@beckman.org> Message-ID: <573735DD.1040809@pari.edu> On 05/13/2016 04:38 PM, Mel Beckman wrote: > But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. While this is drifting a bit off-topic for NANOG (and drifting into the topic range for time-nuts at febo.com), I'll just add one more thing to this. The Hold time (when the oscillator is free-running) is a very important consideration, especially, as you say, when terrain is an issue. For us it is even more important, as the 10MHz output from the timing rack is used as a site-wide frequency standard. Of course, you never discipline a cesium PRS, but the rubidium secondary is disciplined by circuitry in the SSU2000. Back in the days of common backbone delivery over SONET discussion of cesium standards would have been on-topic, as some SONET gear (Nortel Optera for instance) needs a master clock; especially if you were delivering channelized circuits or interfacing with customers and telcos with DS3 or even DS1 circuits or DS0 fractions within them. Ethernet is far more forgiving. From lowen at pari.edu Sat May 14 14:50:41 2016 From: lowen at pari.edu (Lamar Owen) Date: Sat, 14 May 2016 10:50:41 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160513193927.BCB8F13A098B@snark.thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <57373B41.8000404@pari.edu> On 05/13/2016 03:39 PM, Eric S. Raymond wrote: > Traditionally dedicated time-source hardware like rubidium-oscillator > GPSDOs is sold on accuracy, but for WAN time service their real draw > is long holdover time with lower frequency drift that you get from the > cheap, non-temperature-compensated quartz crystals in your PC. There > is room for debate about how much holdover you should pay for, but > you'll at least be thinking more clearly about the problem if you > recognize that you *should not* buy expensive hardware for accuracy. > For WAN time service, in that price range, you're wither buying > holdover and knowing you're doing so or wasting your money. Eric, Thanks for the pointers; nice information. A cheap way to get a WAN frequency standard is to use a WAN that is delivered over something derived from the telco's synchronous network; a POS on an OC3 with the clock set to network has an exceptionally stable frequency standard available. Less expensive, get a voice T1 trunk delivered (robbed-bit signaled will typically be less expensive than PRI) and grab clock from that; tarriffs for RBS T1/fractional T1 around here at least are less than an analog POTS line). Very stable. The plesiochronous digital hierarchy on copper or synchronous digital hierarchy/SONET on fiber have cesium clocks behind them, and you can get that stability by doing clock recovery on those WAN circuits. Back when this was the most common WAN technology frequency standards were there for the taking; Ethernet, on the other hand, not so much. But a nice catch on using the isochronous nature of USB. Cheap webcams also take advantage of the isochronous transfer mode. Do note that isochronous is often not supported in USB-passthrough for virtualization, though. But you shouldn't use a VM to do timing, either. :-) Now I'm looking for myself one of those Navisys devices you mentioned..... do any of them have external antenna inputs, say on an SMA connector (MCX is in my experience just too fragile) with a bias tee to drive phantom to an active antenna? The quick search I did seemed to indicate that the three you mentioned are self-contained with their own smart antenna. External antenna input would be required here, where we use timing-grade GPS antennas to feed our Z3816's. But for straight 1PPS and GPS timecode, dealing with the Z3816's complexity is overkill. Thanks again for the info; looking forward to seeing how NTPsec develops. From ecrogers at precisionds.com Sat May 14 17:14:46 2016 From: ecrogers at precisionds.com (Eric Rogers) Date: Sat, 14 May 2016 13:14:46 -0400 Subject: B5-Lite References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: If it is 3-4KM, I would definitely use the AF24 (24GHz) because it gives you 750M/750M Full duplex. For longer, or a backup link, I would use the AF5X (not AF5) instead of the B5. That way you have 750M full duplex during most days with the AF24, and on a strong rain if you use OSPF, the AF5X (5GHz) can at least carry 100Mish across until the rain stops. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan Sent: Saturday, May 14, 2016 9:46 AM To: Jared Mauch Cc: North American Network Operators' Group Subject: Re: B5-Lite I didn't think the AF5 was much cheaper than an AF24 and I'd much rather be up in the 24GHz band and out of any contention in 5GHz. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Sat, May 14, 2016 at 9:28 AM, Jared Mauch wrote: > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if > your effective range won't support a "short" 3-4km link. > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > AF5X instead I guess. > > Thanks! > > Jared Mauch > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > We've deployed 2 B5 links into production, the newer firmware seems > > to > have fixed the issues we saw in the links when we first tested them. > > > > We have a very rural customer where two hops are needed around the site. > We're lucky in that we had two 80MHz channels free. We see around > 350Mbps both ways actual throughput on both links. > > > > However, these links are short est. 200mtrs when we had tested these > > on > longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > > > For our longer links that need a bit more throughput than a Rocket > > M5 we > either use Licensed radios or the AF5X which works very well. > > > > Regards, > > > > Hal Ponton > > > > Senior Network Engineer > > > > Buzcom / FibreWiFi > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> > >> Jared - why not go to Ubiquiti AC gear if you need some more speed > >> and > something more modern? > >> > >>> On May 14, 2016, at 01:43, Eric C. Miller > wrote: > >>> > >>> B5c is the only product that I've had much success with from Mimosa. > >>> > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > >>> > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > strongly recommend that you stear away from the lite and go with the B5c. > We use them with rocket dishes. You just need the RP-SMA to N cables. > >>> > >>> > >>> Eric Miller, CCNP > >>> Network Engineering Consultant > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared > >>> Mauch > >>> Sent: Friday, May 13, 2016 7:06 PM > >>> To: North American Network Operators' Group > >>> Subject: B5-Lite > >>> > >>> Anyone deployed this radio in production in the US? I?m curious > >>> to > hear from people who are using it, looking at replacing some UBNT > hardware with it on some PTP links, going from the M-series class > devices to something more modern. > >>> > >>> Thanks, > >>> > >>> - Jared > > From josh at kyneticwifi.com Sat May 14 17:28:11 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 14 May 2016 12:28:11 -0500 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <86EDFEBA-A39E-42B2-948E-2D0FE59E0D6E@puck.nether.net> Message-ID: AF24HD can do full duplex 1Gbps On May 14, 2016 12:17 PM, "Eric Rogers" wrote: > If it is 3-4KM, I would definitely use the AF24 (24GHz) because it gives > you 750M/750M Full duplex. For longer, or a backup link, I would use the > AF5X (not AF5) instead of the B5. That way you have 750M full duplex > during most days with the AF24, and on a strong rain if you use OSPF, the > AF5X (5GHz) can at least carry 100Mish across until the rain stops. > > Eric Rogers > PDS Connect > www.pdsconnect.me > (317) 831-3000 x200 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan > Sent: Saturday, May 14, 2016 9:46 AM > To: Jared Mauch > Cc: North American Network Operators' Group > Subject: Re: B5-Lite > > I didn't think the AF5 was much cheaper than an AF24 and I'd much rather > be up in the 24GHz band and out of any contention in 5GHz. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor > Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Sat, May 14, 2016 at 9:28 AM, Jared Mauch > wrote: > > > Ouch. Was also looking at b5 but $1400 for a pair is a bit steep if > > your effective range won't support a "short" 3-4km link. > > > > Trying to bridge the gap, and UBNT has their pluses and minuses. Maybe > > AF5X instead I guess. > > > > Thanks! > > > > Jared Mauch > > > > > On May 14, 2016, at 8:31 AM, Hal Ponton wrote: > > > > > > We've deployed 2 B5 links into production, the newer firmware seems > > > to > > have fixed the issues we saw in the links when we first tested them. > > > > > > We have a very rural customer where two hops are needed around the > site. > > We're lucky in that we had two 80MHz channels free. We see around > > 350Mbps both ways actual throughput on both links. > > > > > > However, these links are short est. 200mtrs when we had tested these > > > on > > longer links their performance was awful, on a 40MHz channel we saw > 20Mbps. > > > > > > For our longer links that need a bit more throughput than a Rocket > > > M5 we > > either use Licensed radios or the AF5X which works very well. > > > > > > Regards, > > > > > > Hal Ponton > > > > > > Senior Network Engineer > > > > > > Buzcom / FibreWiFi > > > > > >> On 14 May 2016, at 11:07, Matt Hoppes < > > mattlists at rivervalleyinternet.net> wrote: > > >> > > >> Jared - why not go to Ubiquiti AC gear if you need some more speed > > >> and > > something more modern? > > >> > > >>> On May 14, 2016, at 01:43, Eric C. Miller > > wrote: > > >>> > > >>> B5c is the only product that I've had much success with from Mimosa. > > >>> > > >>> The B5Lite is a cheap plastic shell and, and it performs like it too. > > >>> > > >>> If you have UBNT gear now, Mimosa is a good next step, but I'd > > strongly recommend that you stear away from the lite and go with the B5c. > > We use them with rocket dishes. You just need the RP-SMA to N cables. > > >>> > > >>> > > >>> Eric Miller, CCNP > > >>> Network Engineering Consultant > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared > > >>> Mauch > > >>> Sent: Friday, May 13, 2016 7:06 PM > > >>> To: North American Network Operators' Group > > >>> Subject: B5-Lite > > >>> > > >>> Anyone deployed this radio in production in the US? I?m curious > > >>> to > > hear from people who are using it, looking at replacing some UBNT > > hardware with it on some PTP links, going from the M-series class > > devices to something more modern. > > >>> > > >>> Thanks, > > >>> > > >>> - Jared > > > > > From jared at puck.nether.net Sat May 14 17:43:04 2016 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 14 May 2016 13:43:04 -0400 Subject: B5-Lite In-Reply-To: <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Message-ID: > On May 14, 2016, at 6:07 AM, Matt Hoppes wrote: > > Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? Concern is with the UBNT AC 500mm dish and wind loading on the tower even with radome. b5 is ~450mm and b5-lite is 260mm. The link is 4.88km (3mi) so keeping bandwidth and link up are key. - Jared From hal at buzcom.net Sat May 14 17:53:16 2016 From: hal at buzcom.net (Hal Ponton) Date: Sat, 14 May 2016 18:53:16 +0100 Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Message-ID: For that distance link you could use to 300m 45 degree slant AF5x antenna Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi > On 14 May 2016, at 18:43, Jared Mauch wrote: > > >> On May 14, 2016, at 6:07 AM, Matt Hoppes wrote: >> >> Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? > > Concern is with the UBNT AC 500mm dish and wind loading on the tower even with radome. > > b5 is ~450mm and b5-lite is 260mm. > > The link is 4.88km (3mi) so keeping bandwidth and link up are key. > > - Jared From baldur.norddahl at gmail.com Sat May 14 19:39:29 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 14 May 2016 21:39:29 +0200 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: On 13 May 2016 at 23:01, Baldur Norddahl wrote: > Ok how many hours or days of holdover can you expect from quartz, > temperature compensated quartz or Rubidium? Should we calculate holdover as > time until drift is more than 1 millisecond, 10 ms or more for NTP > applications? > > I am thinking that many available datacenter locations will have poor GPS > signal so we can expect signal loss to be common. Some weather patterns > might even cause extended GPS signal loss. > > > I found some data points here: https://en.wikipedia.org/wiki/Crystal_oven Assuming that acceptable drift is 10 milliseconds due that being the expected accuracy from NTP. The common crystal oscillator can be as bad as 1E-4 => holdover time is 2 minutes. TCXO is listed as 1E-6 => holdover time is 3 hours. OCXO is listed as multiple values, I will use 1E-7 => holdover time is 1 day. Rubidium is listed as 1E-9 => 3 months Caesium is listed as 1E-11 => 30 years Hydrogen Maser 1E-15 => 300 millennia I clearly need three of those maser things for my network. Regards, Baldur From mel at beckman.org Sat May 14 19:42:13 2016 From: mel at beckman.org (Mel Beckman) Date: Sat, 14 May 2016 19:42:13 +0000 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> , Message-ID: <21BC0A36-520B-4700-BA32-D0490BD07DCF@beckman.org> > I clearly need three of those maser things for my network. Gives new meaning to the phrase "Set and forget". :) -mel beckman > On May 14, 2016, at 12:40 PM, Baldur Norddahl wrote: > >> On 13 May 2016 at 23:01, Baldur Norddahl wrote: >> >> Ok how many hours or days of holdover can you expect from quartz, >> temperature compensated quartz or Rubidium? Should we calculate holdover as >> time until drift is more than 1 millisecond, 10 ms or more for NTP >> applications? >> >> I am thinking that many available datacenter locations will have poor GPS >> signal so we can expect signal loss to be common. Some weather patterns >> might even cause extended GPS signal loss. >> >> >> > I found some data points here: https://en.wikipedia.org/wiki/Crystal_oven > > Assuming that acceptable drift is 10 milliseconds due that being the > expected accuracy from NTP. > > The common crystal oscillator can be as bad as 1E-4 => holdover time is 2 > minutes. > TCXO is listed as 1E-6 => holdover time is 3 hours. > OCXO is listed as multiple values, I will use 1E-7 => holdover time is 1 > day. > Rubidium is listed as 1E-9 => 3 months > Caesium is listed as 1E-11 => 30 years > Hydrogen Maser 1E-15 => 300 millennia > > I clearly need three of those maser things for my network. > > Regards, > > Baldur From bms at fastmail.net Sun May 15 07:21:05 2016 From: bms at fastmail.net (Bruce Simpson) Date: Sun, 15 May 2016 08:21:05 +0100 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160513193927.BCB8F13A098B@snark.thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <57382361.8050705@fastmail.net> On 13/05/16 20:39, Eric S. Raymond wrote: > In 2012, nearly three years before being recruited for NTPsec, I > solved this problem as part of my work on GPSD. The key to this > solution is an obscure feature of USB, and a one-wire > patch to the bog-standard design for generic USB that exploits > it. Technical details on request, but what it comes down to is > that with this one weird trick(!) you can mass-produce primary time > sources with a jitter bounded by the USB polling interval for > about $20 a pop. > > The USB 1 polling interval is 1ms. What about USB 3.1 (assuming the device is not intended to be backwards compatible with the polling model) ? I should point out Intel intend to retire EHCI/UHCI and implement only xHCI. From esr at thyrsus.com Sun May 15 10:21:33 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 15 May 2016 06:21:33 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <20160515102133.GA18517@thyrsus.com> Baldur Norddahl : > Ok how many hours or days of holdover can you expect from quartz, > temperature compensated quartz or Rubidium? Sorry, I don't have those drift figures handy. I'm a programmer, not a large-site sysadmin - I've never had purchase authority with a budget large enough to buy a rubidium-oscillator GPSDO or any other device with holdover. Better to ask Mel Beckman or someone else with field experience. > Should we calculate holdover as > time until drift is more than 1 millisecond, 10 ms or more for NTP > applications? If you want to go super-accurate, 1ms. If you want to go cheap, on sampling-theory grounds I'd say you want to vary your drift threshold from 1 to 5ms (half the expected precision of WAN time, think of it as the Nyquist rate) and look for a knee in the cost curve. > I am thinking that many available datacenter locations will have poor GPS > signal so we can expect signal loss to be common. Some weather patterns > might even cause extended GPS signal loss. Weather won't do it, usually. Rain and fog and clouds are transparent to GPS frequencies. Standing water directly on an antenna can cause some attenuation, but with any serious GPS engine made more recently than 5 years ago I would be extremely surprised if that lost it lock. The newer ones handle down to 30 feet in ocean water on robot submarines. -- Eric S. Raymond From esr at thyrsus.com Sun May 15 10:25:15 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 15 May 2016 06:25:15 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <57382361.8050705@fastmail.net> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <57382361.8050705@fastmail.net> Message-ID: <20160515102515.GB18517@thyrsus.com> Bruce Simpson : > On 13/05/16 20:39, Eric S. Raymond wrote: > >In 2012, nearly three years before being recruited for NTPsec, I > >solved this problem as part of my work on GPSD. The key to this > >solution is an obscure feature of USB, and a one-wire > >patch to the bog-standard design for generic USB that exploits > >it. Technical details on request, but what it comes down to is > >that with this one weird trick(!) you can mass-produce primary time > >sources with a jitter bounded by the USB polling interval for > >about $20 a pop. > > > >The USB 1 polling interval is 1ms. > > What about USB 3.1 (assuming the device is not intended to be backwards > compatible with the polling model) ? I should point out Intel intend to > retire EHCI/UHCI and implement only xHCI. Nobody makes GPSes with even USB 2 or 3 yet, and it is unlikely to happen for a long time. Cost reasons - USB GPSes are cheap consumer-grade hardware and the manufacturers care about fractions of a cent on the BOM. -- Eric S. Raymond From mel at beckman.org Sun May 15 15:21:02 2016 From: mel at beckman.org (Mel Beckman) Date: Sun, 15 May 2016 15:21:02 +0000 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160515102133.GA18517@thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> , <20160515102133.GA18517@thyrsus.com> Message-ID: <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> I have deployed rubidium-disciplined clocks at cellular carriers, where money is no object (look at your cellphone bill), typically for $20K-$100K for redundant clocks. The holdover time on these is supposed to be days, but we've never tested that. I think I'd better. But a more critical deployment of rubidium clocks is in cash-strapped public safety institutions, such as local police dispatch centers. Timing is crucial for the squad car communication systems, which these days are all digital, based on wireless T1/T3 trunks to remote repeaters. The clocking on these trunks can't drift much before voice communication fails due to repeater outages. The telecom gear has OXCO clocks that can provide a few hours holdover. A rubidium clock onsite provides coverage for longer outages. In these installations I have tested GPS outages of up to a week without enough clock drift to knock out the Tx links. I've never gone longer than that though, so I don't know the actual breaking point. But if you lose that rubidium clock, things go south in a less than a day. The cash-strapping comes into play when municipal bean counters eyeball the rubidium clock(s) and start thinking they can get by with a cheaper substitute. The upshot is that there are many real-world situations where expensive clock discipline is needed. But IT isn't, I don't think, one of them, with the exception of private SONET networks (fast disappearing in the face of metro Ethernet). -mel beckman > On May 15, 2016, at 3:22 AM, Eric S. Raymond wrote: > > Baldur Norddahl : >> Ok how many hours or days of holdover can you expect from quartz, >> temperature compensated quartz or Rubidium? > > Sorry, I don't have those drift figures handy. I'm a programmer, not > a large-site sysadmin - I've never had purchase authority with a > budget large enough to buy a rubidium-oscillator GPSDO or any other > device with holdover. Better to ask Mel Beckman or someone else > with field experience. > >> Should we calculate holdover as >> time until drift is more than 1 millisecond, 10 ms or more for NTP >> applications? > > If you want to go super-accurate, 1ms. If you want to go cheap, on > sampling-theory grounds I'd say you want to vary your drift threshold > from 1 to 5ms (half the expected precision of WAN time, think of it as > the Nyquist rate) and look for a knee in the cost curve. > >> I am thinking that many available datacenter locations will have poor GPS >> signal so we can expect signal loss to be common. Some weather patterns >> might even cause extended GPS signal loss. > > Weather won't do it, usually. Rain and fog and clouds are transparent > to GPS frequencies. Standing water directly on an antenna can cause > some attenuation, but with any serious GPS engine made more recently > than 5 years ago I would be extremely surprised if that lost it > lock. The newer ones handle down to 30 feet in ocean water on robot > submarines. > -- > Eric S. Raymond From esr at thyrsus.com Sun May 15 17:05:34 2016 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 15 May 2016 13:05:34 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160515102133.GA18517@thyrsus.com> <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> Message-ID: <20160515170534.GA20808@thyrsus.com> Mel Beckman : > The upshot is that there are many real-world situations where > expensive clock discipline is needed. But IT isn't, I don't think, > one of them, with the exception of private SONET networks (fast > disappearing in the face of metro Ethernet). Thank you, that was very interesting information. I'm not used to thinking of IT as a relatively low-challenge environment! You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP provisioning less dependent on accurate time synch. Do you think that's true? -- Eric S. Raymond From Valdis.Kletnieks at vt.edu Sun May 15 17:58:14 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 May 2016 13:58:14 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> , <20160515102133.GA18517@thyrsus.com> <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> Message-ID: <87104.1463335094@turing-police.cc.vt.edu> On Sun, 15 May 2016 15:21:02 -0000, Mel Beckman said: > But a more critical deployment of rubidium clocks is in cash-strapped public > safety institutions, such as local police dispatch centers. Timing is crucial > for the squad car communication systems, which these days are all digital, > based on wireless T1/T3 trunks to remote repeaters. The clocking on these > trunks can't drift much before voice communication fails due to repeater > outages. The telecom gear has OXCO clocks that can provide a few hours > holdover. A rubidium clock onsite provides coverage for longer outages. That may be the scariest entry on "Things I was not aware of" for quite some time.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mansaxel at besserwisser.org Sun May 15 19:16:26 2016 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 15 May 2016 21:16:26 +0200 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160515102133.GA18517@thyrsus.com> <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> Message-ID: <20160515191626.GE15061@besserwisser.org> Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP Date: Sun, May 15, 2016 at 03:21:02PM +0000 Quoting Mel Beckman (mel at beckman.org): > The upshot is that there are many real-world situations where expensive clock discipline is needed. But IT isn't, I don't think, one of them, with the exception of private SONET networks (fast disappearing in the face of metro Ethernet). Pro audio is moving to Ethernet (they talk about it, Ethernet, as either "RJ45" or "Internet"...) and sometimes even to IP in a fairly rapid pace. If you think the IP implementations in IoT devices are na?ve, wait until you've seen what passes for broadcast quality network engineering. Shoving digital audio samples in raw Ethernet frames is at least 20 years old, but the last perhaps 5 years has seen some progress in actually using IP to carry audio streams. (this is close-to-realtime audio, not file transfers, btw.) A lot of audio is sent using codecs like Opus, with SIP as signalling. That works quite nicely. We've got a smartphone app to do that, for instance. But, this is all mostly floating in terms of absolute sampling frequency. Digital audio needs a clock to work. In the simple home stereo case, this is taken care of by listening to the pace samples arrive at, and using that. But as soon as you are mixing two sources, they need to be in tune. Something needs to decide what to use as master. In the smartphone case, we simply buffer some 20-100ms of audio and start playing back, using our own clock. Then we hope the interview is over before the buffer is overflowing or drained. Which mostly works. Inside facilities, when we use the SIP-signalled streams, we usually can rely on a separate clock distribution. In our specific case, we've bought country-wide clock distribution that gives us the same sample clock in all facilities. (Digital TV is mostly built as single frequency networks, which requires syntonous (at least) transmitters. Thus, it today is quite easy to find providers of frequency in the broadcast business.) Now, the Audio Engineering Society has published AES67 which in essence is multichannel, multicast RTP audio (L48 mediatype, ie. linear 48KHz 24-bit) synchronized by PTP, also multicast. Now, bear in mind that I wrote _synchronized_, not _syntonized_. Up to now, the only thing that mattered to keep track of was frequency. Since one of the big reasons for AES67 is distributing sound to several different loudspeakers that can be heard by one listener simultaneously, the prime example being a stereo pair of active loudspeakers with one network jack on each, _phase_ matters, as well as absolute time. (Mostly, telco synchronization mentions absolute time as phase.) This application requires absolute time, since a mono sound in our stereo example needs to play back _at the same time_ from both speakers. Or it ceases to be a mono sound, instead becoming a sound that is offset in the soundstage by delaying it. Most classical stereo recordings are mono in terms of level, but not in terms of the time domain; since they derive all spatial info from time, not gain. Like we humans do. The usual test case is to buy a PTP-aware switch, a PTP Grand Master, steered by and build a small LAN, test that Vendor A and Vendor B can send audio between themselves via this simple network and call it a day. That is a nice lab setup. Also very far from what needs to be built in order to solve the actual production cases. But, to try to return to "relevant for NANOG", there are actual products requiring microsecond precision being sold. And used. And we've found that those products don't have a very good holdover. On ranty days I usually accuse them of having hotglued an Ethernet adapter onto the old TDM-based audio devices and sent them out to customers with a prayer and instructions to build an overengineered network to make certain that PTP always is delivered with zero IPDV. A lot of strange things are getting network connectors these days. Not all of them are content with a http connection to some cloud provider. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From joelja at bogus.com Mon May 16 00:28:35 2016 From: joelja at bogus.com (joel jaeggli) Date: Sun, 15 May 2016 17:28:35 -0700 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160515170534.GA20808@thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160515102133.GA18517@thyrsus.com> <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> <20160515170534.GA20808@thyrsus.com> Message-ID: <72866b4c-a0eb-8fa3-8a28-5520e1b24ef4@bogus.com> On 5/15/16 10:05 AM, Eric S. Raymond wrote: > Mel Beckman : >> The upshot is that there are many real-world situations where >> expensive clock discipline is needed. But IT isn't, I don't think, >> one of them, with the exception of private SONET networks (fast >> disappearing in the face of metro Ethernet). > > Thank you, that was very interesting information. I'm not used to thinking > of IT as a relatively low-challenge environment! > > You're implicitly suggesting there might be a technical case for > replacing these T1/T3 trunks with some kind of VOIP provisioning less > dependent on accurate time synch. Do you think that's true? APCO and TETRA trunked radio are mature systems, they do carry data, but are somewhat lower bandwidth. Being TDM they are dependent on accurate clocks. LTE systems are used or envisioned being used for high bandwidth applications. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From mel at beckman.org Mon May 16 03:12:51 2016 From: mel at beckman.org (Mel Beckman) Date: Mon, 16 May 2016 03:12:51 +0000 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <72866b4c-a0eb-8fa3-8a28-5520e1b24ef4@bogus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160515102133.GA18517@thyrsus.com> <46639B27-FC4E-4111-9BE7-6A2580EAB517@beckman.org> <20160515170534.GA20808@thyrsus.com>, <72866b4c-a0eb-8fa3-8a28-5520e1b24ef4@bogus.com> Message-ID: Joe and Eric, It's frustrating how far public safety technology lags behind what Industry can actually deliver. It's the same in aviation. Institutions are slow to adopt new tech due to fears about reliability, and and unwillingness to take any risk at all. So PS and aviation capabilities lag horribly. This is why commercial pilots, tired of waiting on the FAA, are buying their own tablets and running non-certified navigation tools. And police officers use cellular data connection with VPN to query wants and warrants databases. -mel beckman >> On May 15, 2016, at 5:28 PM, joel jaeggli wrote: >> >>> On 5/15/16 10:05 AM, Eric S. Raymond wrote: >>> Mel Beckman : >>> The upshot is that there are many real-world situations where >>> expensive clock discipline is needed. But IT isn't, I don't think, >>> one of them, with the exception of private SONET networks (fast >>> disappearing in the face of metro Ethernet). >> >> Thank you, that was very interesting information. I'm not used to thinking >> of IT as a relatively low-challenge environment! >> >> You're implicitly suggesting there might be a technical case for >> replacing these T1/T3 trunks with some kind of VOIP provisioning less >> dependent on accurate time synch. Do you think that's true? > > APCO and TETRA trunked radio are mature systems, they do carry data, > but are somewhat lower bandwidth. Being TDM they are dependent on > accurate clocks. > > LTE systems are used or envisioned being used for high bandwidth > applications. > > > From bicknell at ufp.org Mon May 16 14:27:50 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 16 May 2016 07:27:50 -0700 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160513193927.BCB8F13A098B@snark.thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <20160516142750.GA3992@ussenterprise.ufp.org> In a message written on Fri, May 13, 2016 at 03:39:27PM -0400, Eric S. Raymond wrote: > According to RFC 5095 expected accuracy of NTP time is "several tens > of milliseconds." User expectations seem to evolved to on the close > order of 10ms. I think it's not by coincidence this is pretty close > to the jitter in ping times I see when I bounce ICMP off a > well-provisioned site like (say) google.com through my Verizon FIOS > connection. For a typical site, there are two distinct desires from the same NTP process. First, syncronization with the rest of the world, which is generally over the WAN and the topic that was well discussed in your post. I agree completely that the largest factor is WAN jitter. The other is local syncronization, insuring multiple servers have the same time for log analysis purposes and such. This typically takes place across a lightly loaded ethernet fabric, perhaps with small latency (across a compus). Jitter here is much, much smaller. Does the limitation of accuracy remain jitter in the low jitter LAN/Campus enviornment, or does that expose other issues like the quality of oscellators, OS scheduling, etc? Or perhaps another way, is it possible to get say 10's or 100's of nanosecond accuracy in the lan/campus? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From chuckchurch at gmail.com Mon May 16 14:50:29 2016 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 16 May 2016 10:50:29 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160516142750.GA3992@ussenterprise.ufp.org> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160516142750.GA3992@ussenterprise.ufp.org> Message-ID: <01f101d1af82$4bdc67c0$e3953740$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Leo Bicknell Sent: Monday, May 16, 2016 10:28 AM To: nanog at nanog.org Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP >For a typical site, there are two distinct desires from the same NTP process. >First, synchronization with the rest of the world, which is generally over the WAN and the topic that was well discussed in your post. >I agree completely that the largest factor is WAN jitter. >Leo Bicknell - bicknell at ufp.org >PGP keys at http://www.ufp.org/~bicknell/ I was just thing about this WAN jitter issue myself. I'm wondering how many folks put NTP traffic in priority queues? At least for devices in your managed IP ranges. Seems like that would improve jitter. Would like to hear about others doing this successfully prior to suggesting it for our network. Chuck From sthaug at nethelp.no Mon May 16 14:56:37 2016 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 16 May 2016 16:56:37 +0200 (CEST) Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <01f101d1af82$4bdc67c0$e3953740$@gmail.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> <20160516142750.GA3992@ussenterprise.ufp.org> <01f101d1af82$4bdc67c0$e3953740$@gmail.com> Message-ID: <20160516.165637.74700344.sthaug@nethelp.no> > I was just thing about this WAN jitter issue myself. I'm wondering how many > folks put NTP traffic in priority queues? At least for devices in your > managed IP ranges. Seems like that would improve jitter. Would like to > hear about others doing this successfully prior to suggesting it for our > network. NTP, no. Not worth it. PTP, synched to a suitably accurate source, absolutely. Steinar Haug, AS2116 From lowen at pari.edu Mon May 16 16:02:04 2016 From: lowen at pari.edu (Lamar Owen) Date: Mon, 16 May 2016 12:02:04 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160515170534.GA20808@thyrsus.com> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <5739EEFC.8020603@pari.edu> On 05/15/2016 01:05 PM, Eric S. Raymond wrote: > I'm not used to thinking of IT as a relatively low-challenge environment! I actually changed careers from broadcast engineering to IT to lower my stress level and 'personal bandwidth challenge.' And, yes, it worked. In my case, I'm doing IT for radio and optical astronomy, and at least the timing aspect is higher-challenge that most IT environments. > You're implicitly suggesting there might be a technical case for > replacing these T1/T3 trunks with some kind of VOIP provisioning less > dependent on accurate time synch. Do you think that's true? While I know the question was directed at Mel specifically, I'll just say from the point of view of a T1 voice trunk customer that I hope to never see it go to a VoIP solution. VoIP codecs can have some serious latency issues; I already notice the round-trip delay if I try to carry on a conversation between our internal VoIP system and someone on a cell phone. And this is before codec artifacting (and cascaded codec scrambling) is counted. Can we please keep straight ?-law (A-law if relevant) lossless DS0 PCM timeslices for trunklines so we get at least one less lossy codec cascade? Or have you never experimented with what happens when you cascade G.722 with G.729 with G.726 and then G.711 and back? Calls become mangled gibberish. I would find it interesting to see how many carriers are still doing large amounts of SONET, as that is the biggest use-case for high-stability timing. From lowen at pari.edu Mon May 16 16:16:13 2016 From: lowen at pari.edu (Lamar Owen) Date: Mon, 16 May 2016 12:16:13 -0400 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <20160515191626.GE15061@besserwisser.org> References: <20160513193927.BCB8F13A098B@snark.thyrsus.com> Message-ID: <5739F24D.70703@pari.edu> On 05/15/2016 03:16 PM, M?ns Nilsson wrote: > ...If you think the IP implementations in IoT devices are na?ve, wait > until you've seen what passes for broadcast quality network > engineering. Shoving digital audio samples in raw Ethernet frames is > at least 20 years old, but the last perhaps 5 years has seen some > progress in actually using IP to carry audio streams. (this is > close-to-realtime audio, not file transfers, btw.) Close to realtime is a true statement. Using an IP STL (studio-transmitter link) has enough latency that the announcer can no longer use the air signal as a monitor. And the security side of things is a pretty serious issue; just ask a major IP STL appliance vendor about the recent hijacking of some of their customers' IP STL devices.... yeah, a random intruder on the internet hijacked several radio stations' IP STL's and began broadcasting their content over the radio. Not pretty. I advise any of my remaining broadcast clients that if they are going to an IP STL that they put in a dedicated point to point IP link without publicly routable IP addresses. Digital audio for broadcast STL's is old tech; we were doing G.722/G.723 over switched-56 in the early 90's. But using a public-facing internet connection with no firewalling for an IP STL appliance like the Barix boxes and the Tieline boxes and similar? That borders on networking malpractice. > ... But, to try to return to "relevant for NANOG", there are actual > products requiring microsecond precision being sold. And used. And > we've found that those products don't have a very good holdover. ... Television broadcast is another excellent example of timing needs; thanks. Valdis mentioned the scariest thing.... the scariest thing I've seen recently? Windows NT 3.5 being used for a transmitter control system, within the past five years. I will agree with Valdis on the scary aspects of the public safety communications Mel mentioned. Thanks, Mel, for the educational post. From mel at beckman.org Mon May 16 16:26:35 2016 From: mel at beckman.org (Mel Beckman) Date: Mon, 16 May 2016 16:26:35 +0000 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <5739EEFC.8020603@pari.edu> References: <20160515170534.GA20808@thyrsus.com> <5739EEFC.8020603@pari.edu> Message-ID: <7A1312FA-366A-4EEB-99A7-223E42528215@beckman.org> Lamar, Although VoIP has different technical challenges than TDM, they are all surmountable. Usually VoIP problems result from poor network design (e.g., mixed traffic with no QoS, Internet transport with no guarantees, etc). Public safety networks are generally well designed, don?t use the Internet, and support a single type of traffic: audio streams. I?ve done demonstrations of VoIP that works well in this environment, and you get the advantages of IP routing for redundancy, as opposed to clunky T1 failover mechanisms usually based on hardware switches. But public safety customers are not swayed. TDM works, and it?s the gold standard. They don?t want to change, and you can?t make them. They only see risk, no reward. BTW, in the TDM model, remote data and audio are usually two different systems, which is probably a good idea for redundancy: you might lose audio or data, but rarely both. In any event, I?m only proposing that public safety upgrade their audio systems to VoIP (or cellular-style private GSM, which is in essence VoIP). But nobody is willing. -mel > On May 16, 2016, at 9:02 AM, Lamar Owen wrote: > > On 05/15/2016 01:05 PM, Eric S. Raymond wrote: >> I'm not used to thinking of IT as a relatively low-challenge environment! > > I actually changed careers from broadcast engineering to IT to lower my stress level and 'personal bandwidth challenge.' And, yes, it worked. In my case, I'm doing IT for radio and optical astronomy, and at least the timing aspect is higher-challenge that most IT environments. > >> You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP provisioning less dependent on accurate time synch. Do you think that's true? > > While I know the question was directed at Mel specifically, I'll just say from the point of view of a T1 voice trunk customer that I hope to never see it go to a VoIP solution. VoIP codecs can have some serious latency issues; I already notice the round-trip delay if I try to carry on a conversation between our internal VoIP system and someone on a cell phone. And this is before codec artifacting (and cascaded codec scrambling) is counted. Can we please keep straight ?-law (A-law if relevant) lossless DS0 PCM timeslices for trunklines so we get at least one less lossy codec cascade? Or have you never experimented with what happens when you cascade G.722 with G.729 with G.726 and then G.711 and back? Calls become mangled gibberish. > > I would find it interesting to see how many carriers are still doing large amounts of SONET, as that is the biggest use-case for high-stability timing. > From rwebb at ropeguru.com Mon May 16 16:35:16 2016 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Mon, 16 May 2016 12:35:16 -0400 Subject: Comcast DNS Contact Message-ID: Can one of the Comcast DNS guru's contact me reference an issue with a .gov resolution? Robert From motamedi at cs.uoregon.edu Mon May 16 17:46:20 2016 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Mon, 16 May 2016 10:46:20 -0700 Subject: Question on peering strategies Message-ID: Dear Nanogers, I have a question about common/best network interconnection practices. Assume that two networks (let's refer to them as AS-a and AS-b) are present in a colocation facility say Equinix LA. As many of you know, Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct 1) using private cross-connect 2) through the public IXP's switching fabric. Is it a common/good practice for the two networks to establish connections both through the IXP and also using a private cross-connect? I was thinking considering the cost of cross-connects (my understanding is that the colocation provider charges the customers for each cross-connect in addition to the rent of the rack or cage or whatever), it would not be economically reasonable to have both. Although, if the cross-connect is the primary method of interconnection, and the IXP provides a router-server the public-peering over IXP would essentially be free. So it might makes sense to assume that for the private cross-connect, there exists a back-up connection though the IXP. Anyway, I guess some discussion may give more insight about which one is more reasonable to assume and do. Now my last question is that if the two connections exist (one private cross-connect and another back-up through the IXP), what are the chances that periodically launched traceroutes that pass the inter-AS connection in that colo see both types of connection in a week. I guess what I'm asking is how often back-up routes are taken? Can the networks do load balancing on the two connection and essentially use them as primary routes? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon From nellermann at broadaspect.com Mon May 16 18:10:34 2016 From: nellermann at broadaspect.com (Nick Ellermann) Date: Mon, 16 May 2016 18:10:34 +0000 Subject: Question on peering strategies In-Reply-To: References: Message-ID: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> Reza, You maybe overthinking this one a bit. The economics are something to consider, however all public exchanges have different economics. With Equinix you pay pretty much a flat rate for a single 1Gbps/10Gbps link that includes the cost of facility cross-connect and public exchange access. It is a nice one to many connection for all those various network and content networks your end users would appreciate direct connectivity. Depending on the public exchange you either have a single BGP session or a BGP session per network you are peering. Really after that, it's just BGP routing and route management. You do need to be careful about not being too overly dependent on a single public switch link, in some cases like at Equinix you may want multiple connections to redundant public exchange switches at that site. There is a balance you want to seek of number of paid upstream network transit providers you are connected to versus how many direct peering arrangements you have setup. It's not usually practical for a smaller network to have loads of BGP peers. There are lots of good articles online about this fine balance and some good advice from experienced network operators. To your later questions. For your simple example, if AS-a and AS-b were both already on the public IX, and the link wasn't too overly critical then using the public IX switch maybe a good first step. However as that relationship matures, they most likely in a real world example may look to split the cost of the private cross-connect. If it was mutually beneficial. There is much more to public peering and transit than the technical conversation. Most of the larger networks on the public switches won't peer privately with anyone or only with extremely larger networks. To get a provider such as this to peer both privately and on the public exchange is not a technical issue, it's more of a business overhead and management issue. If you have a couple of quality upstream transit providers, they will be excellent failovers to a public switch outage. Plan for the public switch to have as many problems as any upstream provider. Sincerely, Nick Ellermann ? CTO & VP Cloud Services BroadAspect ? E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 ? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org] On Behalf Of Reza Motamedi Sent: Monday, May 16, 2016 1:46 PM To: nanog at nanog.org Subject: Question on peering strategies Dear Nanogers, I have a question about common/best network interconnection practices. Assume that two networks (let's refer to them as AS-a and AS-b) are present in a colocation facility say Equinix LA. As many of you know, Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct 1) using private cross-connect 2) through the public IXP's switching fabric. Is it a common/good practice for the two networks to establish connections both through the IXP and also using a private cross-connect? I was thinking considering the cost of cross-connects (my understanding is that the colocation provider charges the customers for each cross-connect in addition to the rent of the rack or cage or whatever), it would not be economically reasonable to have both. Although, if the cross-connect is the primary method of interconnection, and the IXP provides a router-server the public-peering over IXP would essentially be free. So it might makes sense to assume that for the private cross-connect, there exists a back-up connection though the IXP. Anyway, I guess some discussion may give more insight about which one is more reasonable to assume and do. Now my last question is that if the two connections exist (one private cross-connect and another back-up through the IXP), what are the chances that periodically launched traceroutes that pass the inter-AS connection in that colo see both types of connection in a week. I guess what I'm asking is how often back-up routes are taken? Can the networks do load balancing on the two connection and essentially use them as primary routes? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon From dhubbard at dino.hostasaurus.com Mon May 16 19:49:11 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 16 May 2016 19:49:11 +0000 Subject: Level 3 issues? Message-ID: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Anyone seeing issues with Level 3 networking right now? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3. Comcast for example: 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] 4 * 33 ms 106 ms 162.151.48.173 5 214 ms 54 ms 41 ms 162.151.21.229 6 561 ms 764 ms 459 ms 4.68.71.133 Thanks, David From Daniel.Jameson at tdstelecom.com Mon May 16 19:53:38 2016 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Mon, 16 May 2016 19:53:38 +0000 Subject: Cost-effectivenesss of highly-accurate clocks for NTP In-Reply-To: <7A1312FA-366A-4EEB-99A7-223E42528215@beckman.org> References: <20160515170534.GA20808@thyrsus.com> <5739EEFC.8020603@pari.edu> <7A1312FA-366A-4EEB-99A7-223E42528215@beckman.org> Message-ID: Give this guy a look, 1RMU form factor, GPS with Rubidium holdover (7 days) if you need it very inexpensive, http://www.fibrolan.com/FibroLAN/SendFile.asp?DBID=1&LNGID=1&GID=3979 or http://www.fibrolan.com/FibroLAN/SendFile.asp?DBID=1&LNGID=1&GID=3978 if you have a SYC-E source or If you just need highly accurate NTP without the holdover, you can do it with FBSD, and a GPS device. http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm http://www.brandywinecomm.com/46-products/bus-level-plug-in-boards/212-pcie-1588-universal-timing-card -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman Sent: Monday, May 16, 2016 11:27 AM To: Lamar Owen Cc: nanog at nanog.org Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP Lamar, Although VoIP has different technical challenges than TDM, they are all surmountable. Usually VoIP problems result from poor network design (e.g., mixed traffic with no QoS, Internet transport with no guarantees, etc). Public safety networks are generally well designed, don?t use the Internet, and support a single type of traffic: audio streams. I?ve done demonstrations of VoIP that works well in this environment, and you get the advantages of IP routing for redundancy, as opposed to clunky T1 failover mechanisms usually based on hardware switches. But public safety customers are not swayed. TDM works, and it?s the gold standard. They don?t want to change, and you can?t make them. They only see risk, no reward. BTW, in the TDM model, remote data and audio are usually two different systems, which is probably a good idea for redundancy: you might lose audio or data, but rarely both. In any event, I?m only proposing that public safety upgrade their audio systems to VoIP (or cellular-style private GSM, which is in essence VoIP). But nobody is willing. -mel > On May 16, 2016, at 9:02 AM, Lamar Owen wrote: > > On 05/15/2016 01:05 PM, Eric S. Raymond wrote: >> I'm not used to thinking of IT as a relatively low-challenge environment! > > I actually changed careers from broadcast engineering to IT to lower my stress level and 'personal bandwidth challenge.' And, yes, it worked. In my case, I'm doing IT for radio and optical astronomy, and at least the timing aspect is higher-challenge that most IT environments. > >> You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP provisioning less dependent on accurate time synch. Do you think that's true? > > While I know the question was directed at Mel specifically, I'll just say from the point of view of a T1 voice trunk customer that I hope to never see it go to a VoIP solution. VoIP codecs can have some serious latency issues; I already notice the round-trip delay if I try to carry on a conversation between our internal VoIP system and someone on a cell phone. And this is before codec artifacting (and cascaded codec scrambling) is counted. Can we please keep straight ?-law (A-law if relevant) lossless DS0 PCM timeslices for trunklines so we get at least one less lossy codec cascade? Or have you never experimented with what happens when you cascade G.722 with G.729 with G.726 and then G.711 and back? Calls become mangled gibberish. > > I would find it interesting to see how many carriers are still doing large amounts of SONET, as that is the biggest use-case for high-stability timing. > From motamedi at cs.uoregon.edu Mon May 16 20:06:16 2016 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Mon, 16 May 2016 13:06:16 -0700 Subject: Question on peering strategies In-Reply-To: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> Message-ID: Hi Nick, Thanks for the reply. Let me clarify another issue first, since I thought the colo's business model is different at least in the US. So if AS-a puts its router in Equinix, it should pay the same amount in the following two scenario (only considering the interconnection cost and not the rent for racks and remote hands and ....)? 1) AS-a only connects to the IX and establishes all inter-AS connections through the IX. 2) AS-a connects to the IX, in addition to privately connecting to bunch of other colo customers (these private connections can be either transit or settlement-free peerings). My understanding was that colos in the US charge per cross connect, so the more you connect privately, the more you pay. This article may be old, but I don't think much has changed: https://www.telegeography.com/press/press-releases/2015/02/26/colocation-cross-connect-price-disparities-remain-between-u-s-europe/index.html With respect to my second question, I was asking if is practical/reasonable to keep both the connection types to same network (say AS-b) at the same time, i.e., connect privately over a cross-connect and keep the public connection over the IX. Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Mon, May 16, 2016 at 11:10 AM, Nick Ellermann wrote: > Reza, > You maybe overthinking this one a bit. The economics are something to > consider, however all public exchanges have different economics. With > Equinix you pay pretty much a flat rate for a single 1Gbps/10Gbps link that > includes the cost of facility cross-connect and public exchange access. It > is a nice one to many connection for all those various network and content > networks your end users would appreciate direct connectivity. Depending on > the public exchange you either have a single BGP session or a BGP session > per network you are peering. Really after that, it's just BGP routing and > route management. You do need to be careful about not being too overly > dependent on a single public switch link, in some cases like at Equinix you > may want multiple connections to redundant public exchange switches at that > site. There is a balance you want to seek of number of paid upstream > network transit providers you are connected to versus how many direct > peering arrangements you have setup. It's not usually practical for a > smaller network to have loads of BGP peers. There are lots of good > articles online about this fine balance and some good advice from > experienced network operators. > > To your later questions. For your simple example, if AS-a and AS-b were > both already on the public IX, and the link wasn't too overly critical then > using the public IX switch maybe a good first step. However as that > relationship matures, they most likely in a real world example may look to > split the cost of the private cross-connect. If it was mutually beneficial. > There is much more to public peering and transit than the technical > conversation. Most of the larger networks on the public switches won't peer > privately with anyone or only with extremely larger networks. To get a > provider such as this to peer both privately and on the public exchange is > not a technical issue, it's more of a business overhead and management > issue. > If you have a couple of quality upstream transit providers, they will be > excellent failovers to a public switch outage. Plan for the public switch > to have as many problems as any upstream provider. > > > Sincerely, > Nick Ellermann ? CTO & VP Cloud Services > BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org] > On Behalf Of Reza Motamedi > Sent: Monday, May 16, 2016 1:46 PM > To: nanog at nanog.org > Subject: Question on peering strategies > > Dear Nanogers, > > I have a question about common/best network interconnection practices. > Assume that two networks (let's refer to them as AS-a and AS-b) are > present in a colocation facility say Equinix LA. As many of you know, > Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct > 1) using private cross-connect > 2) through the public IXP's switching fabric. > Is it a common/good practice for the two networks to establish connections > both through the IXP and also using a private cross-connect? > > I was thinking considering the cost of cross-connects (my understanding is > that the colocation provider charges the customers for each cross-connect > in addition to the rent of the rack or cage or whatever), it would not be > economically reasonable to have both. Although, if the cross-connect is the > primary method of interconnection, and the IXP provides a router-server the > public-peering over IXP would essentially be free. So it might makes sense > to assume that for the private cross-connect, there exists a back-up > connection though the IXP. Anyway, I guess some discussion may give more > insight about which one is more reasonable to assume and do. > > Now my last question is that if the two connections exist (one private > cross-connect and another back-up through the IXP), what are the chances > that periodically launched traceroutes that pass the inter-AS connection in > that colo see both types of connection in a week. I guess what I'm asking > is how often back-up routes are taken? Can the networks do load balancing > on the two connection and essentially use them as primary routes? > > Best Regards > Reza Motamedi (R.M) > Graduate Research Fellow > Oregon Network Research Group > Computer and Information Science > University of Oregon > From ray at orsiniit.com Mon May 16 20:07:16 2016 From: ray at orsiniit.com (Ray Orsini) Date: Mon, 16 May 2016 16:07:16 -0400 Subject: Level 3 issues? In-Reply-To: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: <8cf7233636b9eb83f7fb140ba5f3af0f@mail.gmail.com> I'm having trouble reaching my Birch connection from Verizon and another Birch site. But no issues from FPL Fibernet which passes through Level3. Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Monday, May 16, 2016 3:49 PM To: nanog at nanog.org Subject: Level 3 issues? Anyone seeing issues with Level 3 networking right now? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3. Comcast for example: 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] 4 * 33 ms 106 ms 162.151.48.173 5 214 ms 54 ms 41 ms 162.151.21.229 6 561 ms 764 ms 459 ms 4.68.71.133 Thanks, David From jordan-medlen at bisk.com Mon May 16 20:10:48 2016 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Mon, 16 May 2016 20:10:48 +0000 Subject: Level 3 issues? In-Reply-To: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: Have been seeing issues since just after 3P. Had to swing my traffic over to another provider. Level3 says issues seen from Costa Rica on up to WDC. Thank you, Jordan Medlen Enterprise Communications Manager Bisk Education (813) 612-6207 On 5/16/16, 3:49 PM, "NANOG on behalf of David Hubbard" wrote: >Anyone seeing issues with Level 3 networking right now? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3. Comcast for example: > > 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] > 4 * 33 ms 106 ms 162.151.48.173 > 5 214 ms 54 ms 41 ms 162.151.21.229 > 6 561 ms 764 ms 459 ms 4.68.71.133 > >Thanks, > >David From dhubbard at dino.hostasaurus.com Mon May 16 20:12:47 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 16 May 2016 20:12:47 +0000 Subject: Level 3 issues? In-Reply-To: References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: I just heard from someone there is suspicion that a fiber cut occurred in FL, possibly Miami area, and it has revealed a capacity issue on the L3 network. Haven?t received official word on that yet, but I know our legacy TWTC connection is nearly as useless as our L3 connection thanks to the network merging activities. David On 5/16/16, 4:10 PM, "Jordan Medlen" wrote: >Have been seeing issues since just after 3P. Had to swing my traffic over to another provider. Level3 says issues seen from Costa Rica on up to WDC. > > >Thank you, > >Jordan Medlen >Enterprise Communications Manager >Bisk Education >(813) 612-6207 > > > >On 5/16/16, 3:49 PM, "NANOG on behalf of David Hubbard" wrote: > >>Anyone seeing issues with Level 3 networking right now? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3. Comcast for example: >> >> 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] >> 4 * 33 ms 106 ms 162.151.48.173 >> 5 214 ms 54 ms 41 ms 162.151.21.229 >> 6 561 ms 764 ms 459 ms 4.68.71.133 >> >>Thanks, >> >>David > From baldur.norddahl at gmail.com Mon May 16 20:29:24 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 16 May 2016 22:29:24 +0200 Subject: Question on peering strategies In-Reply-To: References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> Message-ID: On 16 May 2016 at 22:06, Reza Motamedi wrote: > With respect to my second question, I was asking if is practical/reasonable > to keep both the connection types to same network (say AS-b) at the same > time, i.e., connect privately over a cross-connect and keep the public > connection over the IX. > Router ports are expensive, so even if cross connects were free, you would still use the public switch fabric until you reach a traffic level that justifies a direct connection. The point of having a IX switch is that you can connect to many others with just one single router port. When you have the direct cross connect, you would not usually use the IX switch in parallel for that AS. With the cross connect you have dedicated bandwidth to the AS and you would want to reserve the IX switch port for traffic to the remaining networks that you do not yet have a cross connect to. The cross connect is not a very good redundancy setup with regard to the IX switch. Both usually go to the same router and share the same single point of failure (your router is a single point of failure and the peer router is a single point of failure). A cross connect is usual very reliable. You would plan for your router to be down or the peer router to be down, and have a backup path through some entirely geographic separate location. In many cases your generic IP transit service is good enough backup. Your direct peering is an optimization and if that is down, you go back to the transit service. Of course everyone are playing their own game and you might see anything happening in the real world despite the above. Regards, Baldur From nick at flhsi.com Mon May 16 21:06:02 2016 From: nick at flhsi.com (Nick Olsen) Date: Mon, 16 May 2016 17:06:02 -0400 Subject: Level 3 issues? In-Reply-To: References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: Saw the same here. Legacy TW (AS4323) connection didn't take quite the hit that our Level3 (AS3356) did. But they were both seeing similar issues. Had to push traffic some specific routes toward cogent *shudder*. Nick Olsen Sr. Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Hubbard" Sent: Monday, May 16, 2016 4:18 PM To: "nanog at nanog.org" Subject: Re: Level 3 issues? I just heard from someone there is suspicion that a fiber cut occurred in FL, possibly Miami area, and it has revealed a capacity issue on the L3 network. Haven't received official word on that yet, but I know our legacy TWTC connection is nearly as useless as our L3 connection thanks to the network merging activities. David On 5/16/16, 4:10 PM, "Jordan Medlen" wrote: >Have been seeing issues since just after 3P. Had to swing my traffic over to another provider. Level3 says issues seen from Costa Rica on up to WDC. > > >Thank you, > >Jordan Medlen >Enterprise Communications Manager >Bisk Education >(813) 612-6207 > > > >On 5/16/16, 3:49 PM, "NANOG on behalf of David Hubbard" wrote: > >>Anyone seeing issues with Level 3 networking right now? We're seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP's and Level 3. Comcast for example: >> >> 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] >> 4 * 33 ms 106 ms 162.151.48.173 >> 5 214 ms 54 ms 41 ms 162.151.21.229 >> 6 561 ms 764 ms 459 ms 4.68.71.133 >> >>Thanks, >> >>David > -------------- next part -------------- A non-text attachment was scrubbed... Name: Attachment 1 Type: application/octet-stream Size: 1355 bytes Desc: not available URL: From george.herbert at gmail.com Mon May 16 21:19:56 2016 From: george.herbert at gmail.com (George Herbert) Date: Mon, 16 May 2016 14:19:56 -0700 Subject: Level 3 issues? In-Reply-To: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: Yes; you should subscribe to outages at outages.org for better reports. (Short summary - yes, no root cause/TTR yet). George William Herbert Sent from my iPhone > On May 16, 2016, at 12:49 PM, David Hubbard wrote: > > Anyone seeing issues with Level 3 networking right now? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3. Comcast for example: > > 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] > 4 * 33 ms 106 ms 162.151.48.173 > 5 214 ms 54 ms 41 ms 162.151.21.229 > 6 561 ms 764 ms 459 ms 4.68.71.133 > > Thanks, > > David From jason+nanog at lixfeld.ca Tue May 17 00:09:53 2016 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Mon, 16 May 2016 20:09:53 -0400 Subject: Perspectives about customer M/A/C in triple play environments Message-ID: Hello, I think it?s fair to say that most broadband/FTTx customers don?t have to think very much or need to have a very high degree of understanding if they want to move their wired Internet device from one room or another in their house. Maybe to keep things simple, let?s assume that we?re talking about a relatively modern MDU unit where a customer has some sort of provider CPE in their in-suite telecom demark closet/box/what have you with some number of switched 'LAN? ports on it, and each of those LAN ports would be wired to a wall jack somewhere. Mr. or Ms. User can move their Internet device anywhere there is a wall jack and Bob?s your uncle. My question is around how this landscape changes in triple play environments. As I understand it, most triple play deployments separate (in some cases VoIP,) TV and Internet traffic onto VLANs (Internet would be presented to the customer untagged). The CPE would then allow the ISP to switch the video traffic onto a coax port, or maybe onto the CPE?s embedded switch, or maybe both. For the sake of argument, let?s assume the provider is supplying an Ethernet based set-top-box, so customer should be able to connect the STB to any wall jack and it should just work. And they should be able to connect their provider supplied ATA to any wall jack, and it should just work. And they should be able to connect their Internet device to any wall jack and it should just work. Or should it? Are most CPEs that are provided by ISPs sophisticated enough to be able to put all service tags on all ports, and have those same ports act as untagged LAN ports as well? If not, how do providers deal with this? Do they dedicate one port for an IPTV STB? One port for an ATA (assuming no built-in POTS on the CPE)? And the rest of the ports for untagged Internet? What if the customer has 2+ TVs? Do they need to call in and have the provider remote in and provision another port for TV at the expense of some other service that might be running on that port already? Do they need to install a switch that does IGMP snooping? I feel like this all has the potential to become very complicated for the customer, and maybe the provider and their installers. To me, the customer should continue to be dumb and unassuming. They should be able to put whatever they want wherever they want and have it just work. Is that how things actually are in the real world or are customers and providers making silent sacrifices for the sake of all this new fangled technology? From jared at puck.nether.net Tue May 17 00:16:26 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 May 2016 20:16:26 -0400 Subject: Perspectives about customer M/A/C in triple play environments In-Reply-To: References: Message-ID: <0294A079-DCD0-44DA-B1D6-278656BA96DB@puck.nether.net> Honestly if I'm paying for a TV service I should be able to plug in the device anywhere I have network. Look at what cell carriers have done with wifi calling. Have Internet? Have SMS, voice etc. If I'm consuming with a STB or a phone or VLC to ASCII plugin as long as I pass the authentication I should have access. Segmenting is just asking for trouble. Jared Mauch > On May 16, 2016, at 8:09 PM, Jason Lixfeld wrote: > > They should be able to put whatever they want wherever they want and have it just work. Is that how things actually are in the real world or are customers and providers making silent sacrifices for the sake of all this new fangled technology? From jna at retina.net Tue May 17 00:18:11 2016 From: jna at retina.net (John Adams) Date: Mon, 16 May 2016 17:18:11 -0700 Subject: Perspectives about customer M/A/C in triple play environments In-Reply-To: References: Message-ID: I have never seen this level of segmentation in any customer premises I have worked on. Even in "triple-play" environments the handoff is nearly always untagged ethernet and the downstream devices just work. -j On Mon, May 16, 2016 at 5:09 PM, Jason Lixfeld wrote: > Hello, > > I think it?s fair to say that most broadband/FTTx customers don?t have to > think very much or need to have a very high degree of understanding if they > want to move their wired Internet device from one room or another in their > house. > > Maybe to keep things simple, let?s assume that we?re talking about a > relatively modern MDU unit where a customer has some sort of provider CPE > in their in-suite telecom demark closet/box/what have you with some number > of switched 'LAN? ports on it, and each of those LAN ports would be wired > to a wall jack somewhere. Mr. or Ms. User can move their Internet device > anywhere there is a wall jack and Bob?s your uncle. > > My question is around how this landscape changes in triple play > environments. As I understand it, most triple play deployments separate > (in some cases VoIP,) TV and Internet traffic onto VLANs (Internet would be > presented to the customer untagged). The CPE would then allow the ISP to > switch the video traffic onto a coax port, or maybe onto the CPE?s embedded > switch, or maybe both. For the sake of argument, let?s assume the provider > is supplying an Ethernet based set-top-box, so customer should be able to > connect the STB to any wall jack and it should just work. And they should > be able to connect their provider supplied ATA to any wall jack, and it > should just work. And they should be able to connect their Internet device > to any wall jack and it should just work. > > Or should it? > > Are most CPEs that are provided by ISPs sophisticated enough to be able to > put all service tags on all ports, and have those same ports act as > untagged LAN ports as well? If not, how do providers deal with this? Do > they dedicate one port for an IPTV STB? One port for an ATA (assuming no > built-in POTS on the CPE)? And the rest of the ports for untagged > Internet? What if the customer has 2+ TVs? Do they need to call in and > have the provider remote in and provision another port for TV at the > expense of some other service that might be running on that port already? > Do they need to install a switch that does IGMP snooping? > > I feel like this all has the potential to become very complicated for the > customer, and maybe the provider and their installers. To me, the customer > should continue to be dumb and unassuming. They should be able to put > whatever they want wherever they want and have it just work. Is that how > things actually are in the real world or are customers and providers making > silent sacrifices for the sake of all this new fangled technology? > From sryan at arbor.net Tue May 17 00:21:30 2016 From: sryan at arbor.net (Spencer Ryan) Date: Mon, 16 May 2016 20:21:30 -0400 Subject: Perspectives about customer M/A/C in triple play environments In-Reply-To: References: Message-ID: While it's possible I've never seen a mainstream ISP offering tripleplay services (or even doubleplay) where the ATA isn't embedded in the CPE (eMTA for DOCSIS) As far as IPTV, at least the way UVerse does it the video traffic is all untagged on the customer side, the gateway may try to do some QoS but this allows you to plug a UVerse box in anywhere Ethernet works, along with MoCA. This is simple, and kind of just works. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Mon, May 16, 2016 at 8:09 PM, Jason Lixfeld wrote: > Hello, > > I think it?s fair to say that most broadband/FTTx customers don?t have to > think very much or need to have a very high degree of understanding if they > want to move their wired Internet device from one room or another in their > house. > > Maybe to keep things simple, let?s assume that we?re talking about a > relatively modern MDU unit where a customer has some sort of provider CPE > in their in-suite telecom demark closet/box/what have you with some number > of switched 'LAN? ports on it, and each of those LAN ports would be wired > to a wall jack somewhere. Mr. or Ms. User can move their Internet device > anywhere there is a wall jack and Bob?s your uncle. > > My question is around how this landscape changes in triple play > environments. As I understand it, most triple play deployments separate > (in some cases VoIP,) TV and Internet traffic onto VLANs (Internet would be > presented to the customer untagged). The CPE would then allow the ISP to > switch the video traffic onto a coax port, or maybe onto the CPE?s embedded > switch, or maybe both. For the sake of argument, let?s assume the provider > is supplying an Ethernet based set-top-box, so customer should be able to > connect the STB to any wall jack and it should just work. And they should > be able to connect their provider supplied ATA to any wall jack, and it > should just work. And they should be able to connect their Internet device > to any wall jack and it should just work. > > Or should it? > > Are most CPEs that are provided by ISPs sophisticated enough to be able to > put all service tags on all ports, and have those same ports act as > untagged LAN ports as well? If not, how do providers deal with this? Do > they dedicate one port for an IPTV STB? One port for an ATA (assuming no > built-in POTS on the CPE)? And the rest of the ports for untagged > Internet? What if the customer has 2+ TVs? Do they need to call in and > have the provider remote in and provision another port for TV at the > expense of some other service that might be running on that port already? > Do they need to install a switch that does IGMP snooping? > > I feel like this all has the potential to become very complicated for the > customer, and maybe the provider and their installers. To me, the customer > should continue to be dumb and unassuming. They should be able to put > whatever they want wherever they want and have it just work. Is that how > things actually are in the real world or are customers and providers making > silent sacrifices for the sake of all this new fangled technology? > From jlewis at lewis.org Tue May 17 01:44:24 2016 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 16 May 2016 21:44:24 -0400 (EDT) Subject: Question on peering strategies In-Reply-To: References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> Message-ID: On Mon, 16 May 2016, Reza Motamedi wrote: > Hi Nick, > > Thanks for the reply. > > Let me clarify another issue first, since I thought the colo's business > model is different at least in the US. So if AS-a puts its router in > Equinix, it should pay the same amount in the following two scenario (only > considering the interconnection cost and not the rent for racks and remote > hands and ....)? > 1) AS-a only connects to the IX and establishes all inter-AS connections > through the IX. > 2) AS-a connects to the IX, in addition to privately connecting to bunch of > other colo customers (these private connections can be either transit or > settlement-free peerings). > My understanding was that colos in the US charge per cross connect, so the > more you connect privately, the more you pay. This article may be old, but Ports on the colo's IX, Equinix for example, will likely cost more than just a cross connect. If you have peers with which you exchange enough traffic, it can make sense to remove that traffic from the IX and put it on PNI (cross connect) peering, leaving the IX port(s) for use primarily for peering with lots of "smaller peers" (in the amount of traffic exchanged). Typically, if a peer is big enough to justify PNI, you won't want to fail-over to the IX as a backup, because doing so is likely to congest your or their IX links. Of course, there are exceptions. A PNI peer might not have enough ports to dedicate to PNI peering and might want to spread peering traffic over both PNI and IX evenly. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Tue May 17 03:16:34 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 16 May 2016 23:16:34 -0400 Subject: Comcast DNS Contact In-Reply-To: References: Message-ID: On Mon, May 16, 2016 at 12:35 PM, wrote: > > Can one of the Comcast DNS guru's contact me reference an issue with a .gov resolution? > > Robert ?out of curiosity, is the .gov problem related to dnssec perhaps?? From rwebb at ropeguru.com Tue May 17 11:55:45 2016 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 May 2016 07:55:45 -0400 Subject: Comcast DNS Contact In-Reply-To: References: Message-ID: Yes, it was... On Mon, 16 May 2016 23:16:34 -0400 Christopher Morrow wrote: > On Mon, May 16, 2016 at 12:35 PM, wrote: >> >> Can one of the Comcast DNS guru's contact me reference an issue with a > .gov resolution? >> >> Robert > > out of curiosity, is the .gov problem related to dnssec perhaps? From rwebb at ropeguru.com Tue May 17 14:23:04 2016 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 17 May 2016 10:23:04 -0400 Subject: Comcast DNS Contact In-Reply-To: References: Message-ID: Thanks to everyone who helped me offlist. This was resolved quickly. Robert On Mon, 16 May 2016 12:35:16 -0400 rwebb at ropeguru.com wrote: > Can one of the Comcast DNS guru's contact me reference an issue with a .gov resolution? > > Robert From nanog at ics-il.net Tue May 17 15:06:43 2016 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 May 2016 10:06:43 -0500 (CDT) Subject: B5-Lite In-Reply-To: References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> Message-ID: <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> I think there is some information missing on your longer link. Did you still have appropriate signal? Was there noise? I have a B5 link that's about 2 miles that's rocking full data rate and a B5c one that's going about 4 miles at full data rate. My 8 mile B5c link is less than full data rate due to interference. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Hal Ponton" To: "Matt Hoppes" Cc: "North American Network Operators' Group" Sent: Saturday, May 14, 2016 7:31:10 AM Subject: Re: B5-Lite We've deployed 2 B5 links into production, the newer firmware seems to have fixed the issues we saw in the links when we first tested them. We have a very rural customer where two hops are needed around the site. We're lucky in that we had two 80MHz channels free. We see around 350Mbps both ways actual throughput on both links. However, these links are short est. 200mtrs when we had tested these on longer links their performance was awful, on a 40MHz channel we saw 20Mbps. For our longer links that need a bit more throughput than a Rocket M5 we either use Licensed radios or the AF5X which works very well. Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi > On 14 May 2016, at 11:07, Matt Hoppes wrote: > > Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? > >> On May 14, 2016, at 01:43, Eric C. Miller wrote: >> >> B5c is the only product that I've had much success with from Mimosa. >> >> The B5Lite is a cheap plastic shell and, and it performs like it too. >> >> If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. >> >> >> Eric Miller, CCNP >> Network Engineering Consultant >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch >> Sent: Friday, May 13, 2016 7:06 PM >> To: North American Network Operators' Group >> Subject: B5-Lite >> >> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. >> >> Thanks, >> >> - Jared From jared at puck.nether.net Tue May 17 15:29:57 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 May 2016 11:29:57 -0400 Subject: B5-Lite In-Reply-To: <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> Message-ID: <59F38A72-9CA6-4A8C-81DF-400439D1E040@puck.nether.net> I?m seeing -61 (63/67 V/H) with floor at -101 right now with the XW PowerBeam 400 w/ 40mhz. The speeds are ?Ok? but getting beyond 60Mb/s is hard as the CPU maxes in a bridged setup. Doesn?t seem to have any issues with the wireless rate during load, so perhaps it?s not doing offload to the chipset right? The goal is to improve capacity in the interim while some strategic fiber is deployed for some areas. A pair of B5s or AF5X would likely work out but would rather spend that on fiber. - Jared > On May 17, 2016, at 11:06 AM, Mike Hammett wrote: > > I think there is some information missing on your longer link. Did you still have appropriate signal? Was there noise? > > I have a B5 link that's about 2 miles that's rocking full data rate and a B5c one that's going about 4 miles at full data rate. My 8 mile B5c link is less than full data rate due to interference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Hal Ponton" > To: "Matt Hoppes" > Cc: "North American Network Operators' Group" > Sent: Saturday, May 14, 2016 7:31:10 AM > Subject: Re: B5-Lite > > We've deployed 2 B5 links into production, the newer firmware seems to have fixed the issues we saw in the links when we first tested them. > > We have a very rural customer where two hops are needed around the site. We're lucky in that we had two 80MHz channels free. We see around 350Mbps both ways actual throughput on both links. > > However, these links are short est. 200mtrs when we had tested these on longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > For our longer links that need a bit more throughput than a Rocket M5 we either use Licensed radios or the AF5X which works very well. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > >> On 14 May 2016, at 11:07, Matt Hoppes wrote: >> >> Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? >> >>> On May 14, 2016, at 01:43, Eric C. Miller wrote: >>> >>> B5c is the only product that I've had much success with from Mimosa. >>> >>> The B5Lite is a cheap plastic shell and, and it performs like it too. >>> >>> If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. >>> >>> >>> Eric Miller, CCNP >>> Network Engineering Consultant >>> >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch >>> Sent: Friday, May 13, 2016 7:06 PM >>> To: North American Network Operators' Group >>> Subject: B5-Lite >>> >>> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. >>> >>> Thanks, >>> >>> - Jared > From nanog at ics-il.net Tue May 17 15:37:47 2016 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 May 2016 10:37:47 -0500 (CDT) Subject: B5-Lite In-Reply-To: <59F38A72-9CA6-4A8C-81DF-400439D1E040@puck.nether.net> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> <59F38A72-9CA6-4A8C-81DF-400439D1E040@puck.nether.net> Message-ID: <1857352884.369464.1463499462977.JavaMail.mhammett@ThunderFuck> I know it'll result in the air interface coming down on the M series, but verify your noise with the AirView tool. I've grown to not trust the noise floor measurement. 40 MHz at that supposed amount of SNR should be rocking almost double what you're getting. With the V and H chains that far apart, alignment might be off. What are your CCQ, AMC and AMQ numbers? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Tuesday, May 17, 2016 10:29:57 AM Subject: Re: B5-Lite I?m seeing -61 (63/67 V/H) with floor at -101 right now with the XW PowerBeam 400 w/ 40mhz. The speeds are ?Ok? but getting beyond 60Mb/s is hard as the CPU maxes in a bridged setup. Doesn?t seem to have any issues with the wireless rate during load, so perhaps it?s not doing offload to the chipset right? The goal is to improve capacity in the interim while some strategic fiber is deployed for some areas. A pair of B5s or AF5X would likely work out but would rather spend that on fiber. - Jared > On May 17, 2016, at 11:06 AM, Mike Hammett wrote: > > I think there is some information missing on your longer link. Did you still have appropriate signal? Was there noise? > > I have a B5 link that's about 2 miles that's rocking full data rate and a B5c one that's going about 4 miles at full data rate. My 8 mile B5c link is less than full data rate due to interference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Hal Ponton" > To: "Matt Hoppes" > Cc: "North American Network Operators' Group" > Sent: Saturday, May 14, 2016 7:31:10 AM > Subject: Re: B5-Lite > > We've deployed 2 B5 links into production, the newer firmware seems to have fixed the issues we saw in the links when we first tested them. > > We have a very rural customer where two hops are needed around the site. We're lucky in that we had two 80MHz channels free. We see around 350Mbps both ways actual throughput on both links. > > However, these links are short est. 200mtrs when we had tested these on longer links their performance was awful, on a 40MHz channel we saw 20Mbps. > > For our longer links that need a bit more throughput than a Rocket M5 we either use Licensed radios or the AF5X which works very well. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > >> On 14 May 2016, at 11:07, Matt Hoppes wrote: >> >> Jared - why not go to Ubiquiti AC gear if you need some more speed and something more modern? >> >>> On May 14, 2016, at 01:43, Eric C. Miller wrote: >>> >>> B5c is the only product that I've had much success with from Mimosa. >>> >>> The B5Lite is a cheap plastic shell and, and it performs like it too. >>> >>> If you have UBNT gear now, Mimosa is a good next step, but I'd strongly recommend that you stear away from the lite and go with the B5c. We use them with rocket dishes. You just need the RP-SMA to N cables. >>> >>> >>> Eric Miller, CCNP >>> Network Engineering Consultant >>> >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch >>> Sent: Friday, May 13, 2016 7:06 PM >>> To: North American Network Operators' Group >>> Subject: B5-Lite >>> >>> Anyone deployed this radio in production in the US? I?m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. >>> >>> Thanks, >>> >>> - Jared > From mark.tinka at seacom.mu Mon May 16 14:04:38 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 16 May 2016 16:04:38 +0200 Subject: SAFNOG-3: Call for Papers! Message-ID: <86fb8b3a-a978-c29d-cb12-3f373761b525@seacom.mu> Hello all. This is just to remind you that the Call for Papers (CfP) for SAFNOG-3 is open. If you are interested in participating in SAFNOG-3 as a speaker or panelist in Windhoek, Namibia, kindly review the details of the CfP and submit your talk at the link below: http://www.safnog.org/#callforpapers We look forward to receiving your submission, and working with you to develop it into a topic that the community will find interesting and informative. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From beecher at yahoo-inc.com Mon May 16 20:03:52 2016 From: beecher at yahoo-inc.com (Tom Beecher) Date: Mon, 16 May 2016 20:03:52 +0000 (UTC) Subject: Level 3 issues? In-Reply-To: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> References: <443BEA4A-3E0C-4852-A3F3-4733BF2C6985@dino.hostasaurus.com> Message-ID: <424548197.2962173.1463429032932.JavaMail.yahoo@mail.yahoo.com> Was looking at an internal report not long ago. L3 NYC to Miami looked to be in really rough shape. As I was watching, things flipped inside L3 to go NYC->Boston, then handed off to Cogent.? Didn't dig further than that, but methinks they have something going on, yes.??Thanks, Beecher On Monday, May 16, 2016 3:51 PM, David Hubbard wrote: Anyone seeing issues with Level 3 networking right now?? We?re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP?s and Level 3.? Comcast for example: ? 3? ? 33 ms? ? 21 ms? ? 70 ms? te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] ? 4? ? *? ? ? 33 ms? 106 ms? 162.151.48.173 ? 5? 214 ms? ? 54 ms? ? 41 ms? 162.151.21.229 ? 6? 561 ms? 764 ms? 459 ms? 4.68.71.133 Thanks, David From hal at buzcom.net Tue May 17 18:19:53 2016 From: hal at buzcom.net (Hal Ponton) Date: Tue, 17 May 2016 19:19:53 +0100 Subject: B5-Lite In-Reply-To: <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> References: <2BB9CBB5-0B04-447C-BBF0-963ABA52ED98@puck.nether.net> <6F4489FE-B3E7-4794-834B-45B7A4FC0AEC@rivervalleyinternet.net> <1579626430.368062.1463497602871.JavaMail.mhammett@ThunderFuck> Message-ID: <573B60C9.6020302@buzcom.net> Hi Mike, We had the target signal as per the B5's GUI indicated we should have, there is a fair bit of noise in the area, however, the UBNT PowerBridge that was doing the link at 30MHz channel bandwidth was passing 70-80Mbps. Our engineers spent as much time possible aligning the link, we had a team at each end assisting in this. We reviewed with Mimosa and our Distributor, but there's only so much time we could spend on this link. Once the newer firmware was released (I think v1.2.0) we tested again and got better performance so this may have been an early problem that has been ironed out now, but for me I would only use them on smaller distance links. YMMV -- -- Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi > Mike Hammett > 17 May 2016 at 16:06 > I think there is some information missing on your longer link. Did you > still have appropriate signal? Was there noise? > > I have a B5 link that's about 2 miles that's rocking full data rate > and a B5c one that's going about 4 miles at full data rate. My 8 mile > B5c link is less than full data rate due to interference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Hal Ponton" > To: "Matt Hoppes" > Cc: "North American Network Operators' Group" > Sent: Saturday, May 14, 2016 7:31:10 AM > Subject: Re: B5-Lite > > We've deployed 2 B5 links into production, the newer firmware seems to > have fixed the issues we saw in the links when we first tested them. > > We have a very rural customer where two hops are needed around the > site. We're lucky in that we had two 80MHz channels free. We see > around 350Mbps both ways actual throughput on both links. > > However, these links are short est. 200mtrs when we had tested these > on longer links their performance was awful, on a 40MHz channel we saw > 20Mbps. > > For our longer links that need a bit more throughput than a Rocket M5 > we either use Licensed radios or the AF5X which works very well. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > > > > Hal Ponton > 14 May 2016 at 13:31 > We've deployed 2 B5 links into production, the newer firmware seems to > have fixed the issues we saw in the links when we first tested them. > > We have a very rural customer where two hops are needed around the > site. We're lucky in that we had two 80MHz channels free. We see > around 350Mbps both ways actual throughput on both links. > > However, these links are short est. 200mtrs when we had tested these > on longer links their performance was awful, on a 40MHz channel we saw > 20Mbps. > > For our longer links that need a bit more throughput than a Rocket M5 > we either use Licensed radios or the AF5X which works very well. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > From Mathias.Zimmermann at netcetera.com Wed May 18 05:23:12 2016 From: Mathias.Zimmermann at netcetera.com (Mathias Zimmermann) Date: Wed, 18 May 2016 05:23:12 +0000 Subject: mail delivery delayed to gmail/gmail hosted domains Message-ID: <97c52aeee1ba4e0fae6d6781389baff2@exchange01.one.nca> Dear Nanog'er, Since about 4 weeks or more we experience a mail delivery delay (always between 03:09 and 03:10) to gmail.com and gmail hosted domains. We already filled out the "delivery problem report" but never heard something from them. Are there any specs from google which explains when they delay mail acceptance? We are not listed in any blocklists and the SPF, PTR record is correctly set. Any ideas? Regards, Mathias From copraphage at gmail.com Thu May 19 17:44:37 2016 From: copraphage at gmail.com (Chris McDonald) Date: Thu, 19 May 2016 11:44:37 -0600 Subject: Frontier Rep Message-ID: Could a frontier rep hit me up offlist for an on-net check? thanks chris From arthurliew80 at gmail.com Fri May 20 13:57:03 2016 From: arthurliew80 at gmail.com (Arthur Liew) Date: Fri, 20 May 2016 21:57:03 +0800 Subject: NANOG Digest, Vol 100, Issue 19 In-Reply-To: References: Message-ID: Hi Guys, Just wondering if anyone knows equivalent of bgp.he.net for GRX/IPX world? Any good mailing list around targeting GRX/IPX? Thanks ! Rgds Arthur From mhuff at ox.com Fri May 20 15:31:48 2016 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 May 2016 15:31:48 +0000 Subject: Need BGP route check Message-ID: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> One of our upstreams is apparently having problems, although they don't appear to know about it. I've seen an alert at BGPmon.net about our prefixes being withdrawn, and I can't locate our prefixes through that provider on any routeviews. Can someone check to see what ASPATHS you are seeing for our prefixes? 129.77.0.0/16 2620:0:2810::/48 We should be advertised via AS6128 and AS46887 ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 From JJaritsch at anexia-it.com Fri May 20 15:39:47 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 20 May 2016 15:39:47 +0000 Subject: AW: Need BGP route check In-Reply-To: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> References: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> Message-ID: <1a4507efc0d84363a71b03d87a956111@anx-i-dag02.anx.local> Hi Matt, NYC: > show route 129.77.0.0/16 AS path: 6939 46887 14607 14607 I, validation-state: unverified AS path: 1299 6939 6939 46887 14607 14607 I, validation-state: unverified > show route 2620:0:2810::/48 AS path: 6939 6128 14607 I, validation-state: unverified AS path: 1299 3356 6128 14607 I, validation-state: unverified LAX: #sh ip bgp 129.77.0.0/16 6939 46887 14607 14607 1299 6939 6939 46887 14607 14607 #sh ip bgp ipv6 uni 2620:0:2810::/48 6939 6128 14607 1299 3356 6128 14607 Hong Kong: #sh ip bgp 129.77.0.0/16 10026 6939 46887 14607 14607 3491 6128 14607 #sh ip bgp ipv6 uni 2620:0:2810::/48 3491 6128 14607 Frankfurt: > show route 129.77.0.0/16 AS path: 6939 46887 14607 14607 I, validation-state: unverified AS path: 3356 6128 14607 I, validation-state: unverified AS path: 3320 3356 6128 14607 I, validation-state: unverified AS path: 1299 6939 6939 46887 14607 14607 I, validation-state: unverified > show route 2620:0:2810::/48 AS path: 6939 6128 14607 I, validation-state: unverified AS path: 3356 6128 14607 I, validation-state: unverified AS path: 1299 6939 6128 14607 I, validation-state: unverified AS path: 3320 6939 6128 14607 I, validation-state: unverified best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Matthew Huff Gesendet: Freitag, 20. Mai 2016 17:32 An: nanog at nanog.org Betreff: Need BGP route check One of our upstreams is apparently having problems, although they don't appear to know about it. I've seen an alert at BGPmon.net about our prefixes being withdrawn, and I can't locate our prefixes through that provider on any routeviews. Can someone check to see what ASPATHS you are seeing for our prefixes? 129.77.0.0/16 2620:0:2810::/48 We should be advertised via AS6128 and AS46887 ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 From bob at FiberInternetCenter.com Fri May 20 15:44:39 2016 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 20 May 2016 08:44:39 -0700 Subject: Need BGP route check In-Reply-To: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> References: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> Message-ID: Hello, here ya go. Routes: Destination Peer Next-Hop LPref Weight MED AS-Path ---------------------------------------------------------------------------------------- i 129.77.0.0/16 64.118.161.8 64.118.161.8 722 20000 0 6939 46887 14607 14607 *>i 129.77.0.0/16 64.118.161.13 64.118.161.13 725 25555 0 6939 46887 14607 14607 i 129.77.0.0/16 69.22.143.161 69.22.143.161 355 20000 10 4436 46887 14607 14607 i 129.77.0.0/16 216.129.125.5 216.129.125.5 355 20000 301 8121 6939 46887 14607 14607 Routes: Destination LPref Weight MED Peer Next-Hop AS-Path ------------------------------------------------------------------------- i 2620:0:2810::/48 100 1 73060 2001:550:2:58::d:1 2001:550:2:58::d:1 174 46887 14607 14607 *>i 2620:0:2810::/48 100 1 10 2001:590::4516:8fa1 2001:590::4516:8fa1 4436 46887 14607 14607 Thank You Bob Evans CTO > One of our upstreams is apparently having problems, although they don't > appear to know about it. I've seen an alert at BGPmon.net about our > prefixes being withdrawn, and I can't locate our prefixes through that > provider on any routeviews. Can someone check to see what ASPATHS you are > seeing for our prefixes? > > 129.77.0.0/16 > 2620:0:2810::/48 > > We should be advertised via AS6128 and AS46887 > > ---- > Matthew Huff???????????? | 1 Manhattanville Rd > Director of Operations???| Purchase, NY 10577 > OTA Management LLC?????? | Phone: 914-460-4039 > aim: matthewbhuff??????? | Fax:?? 914-694-5669 > > > From mhuff at ox.com Fri May 20 15:46:32 2016 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 May 2016 15:46:32 +0000 Subject: Need BGP route check In-Reply-To: <20160520153832.GL22527@sizone.org> References: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> <20160520153832.GL22527@sizone.org> Message-ID: <7c3ad76ac9d342e8a70e807aa75d80e2@pur-vm-exch13n2.ox.com> Thanks, but I had checked a number of public looking glasses and only one had the 46887 path (HE.net), wanted a more global check. A number of responses are seeing only one or the other paths. The 14607 pre-pend is due to depref'ing 46887 earlier today when we had the instability. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: Ken Chase [mailto:ken at sizone.org] > Sent: Friday, May 20, 2016 11:39 AM > To: Matthew Huff > Cc: nanog at nanog.org > Subject: Re: Need BGP route check > > $ telnet route-views.oregon-ix.net > Username: rviews > > $ show ip bgp paths 14607 > > might help > > /kc > > > On Fri, May 20, 2016 at 03:31:48PM +0000, Matthew Huff said: > >One of our upstreams is apparently having problems, although they > don't appear to know about it. I've seen an alert at BGPmon.net about > our prefixes being withdrawn, and I can't locate our prefixes through > that provider on any routeviews. Can someone check to see what ASPATHS > you are seeing for our prefixes? > > > >129.77.0.0/16 > >2620:0:2810::/48 > > > >We should be advertised via AS6128 and AS46887 > > > >---- > >Matthew Huff???????????? | 1 Manhattanville Rd > >Director of Operations???| Purchase, NY 10577 > >OTA Management LLC?????? | Phone: 914-460-4039 > >aim: matthewbhuff??????? | Fax:?? 914-694-5669 > > > > > > -- > Ken Chase - ken at sizone.org Guelph Canada From mhuff at ox.com Fri May 20 16:11:02 2016 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 May 2016 16:11:02 +0000 Subject: Need BGP route check (UPDATE) Message-ID: <5d6652b5044f4cf0bfa204df95b726db@pur-vm-exch13n2.ox.com> >From responses I received, I have gotten a number of different answers. Some are seeing our routes from 6128, some from 46887 and a few from both. The response from Eric though was typical. Showing the IPv4 prefix only from AS6128, but the IPv6 from both 6128 & 46887. I am guessing that 46887 might be set with a community to not export our IPv4 prefixes except to direct peers? Anyone directly peered with 46887 that could see the community for 129.77.0.0/16 and verify? ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: Eric Tykwinski [mailto:eric-list at truenet.com] > Sent: Friday, May 20, 2016 11:48 AM > To: Matthew Huff > Subject: RE: Need BGP route check > > Matt, > > show ip bgp 129.77.0.0/16 > BGP routing table entry for 129.77.0.0/16, version 161696687 > Paths: (2 available, best #2, table Default-IP-Routing-Table) > Advertised to update-groups: > 1 > 3356 6128 14607 > 4.59.140.65 from 4.59.140.65 (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external > 174 6128 14607 > 38.104.114.73 from 38.104.114.73 (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external, best > Community: 174:21000 174:22013 > > show bgp ipv6 unicast 2620:0:2810::/48 > BGP routing table entry for 2620:0:2810::/48, version 18004880 > Paths: (2 available, best #1, table Global-IPv6-Table) > Advertised to update-groups: > 2 > 3356 6128 14607 > 2001:1900:2100::A2D (FE80::219:7FF:FEDD:2800) from > 2001:1900:2100::A2D > (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external, best > Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2039 > 6128:3000 6128:3091 6128:4000 6128:5003 6128:5046 64600:4000 > 64600:65002 > 174 46887 14607 14607 > 2001:550:2:4::B:1 (FE80::D66D:50FF:FE5E:1D3) from 2001:550:2:4::B:1 > (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external > Community: 174:21001 174:22013 > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Huff > Sent: Friday, May 20, 2016 11:32 AM > To: nanog at nanog.org > Subject: Need BGP route check > > One of our upstreams is apparently having problems, although they don't > appear to know about it. I've seen an alert at BGPmon.net about our > prefixes > being withdrawn, and I can't locate our prefixes through that provider > on > any routeviews. Can someone check to see what ASPATHS you are seeing > for our > prefixes? > > 129.77.0.0/16 > 2620:0:2810::/48 > > We should be advertised via AS6128 and AS46887 > > ---- > Matthew Huff???????????? | 1 Manhattanville Rd Director of > Operations???| > Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 > aim: matthewbhuff??????? | Fax:?? 914-694-5669 > > > From JJaritsch at anexia-it.com Fri May 20 16:17:01 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 20 May 2016 16:17:01 +0000 Subject: AW: Need BGP route check (UPDATE) In-Reply-To: <5d6652b5044f4cf0bfa204df95b726db@pur-vm-exch13n2.ox.com> References: <5d6652b5044f4cf0bfa204df95b726db@pur-vm-exch13n2.ox.com> Message-ID: <6a0f2122dd4645568ba8a3f46895845c@anx-i-dag02.anx.local> Hi Matt, output from lg.he.net: core1.fmt2.he.net> show ip bgp routes detail 129.77.0.0/16 Number of BGP Routes matching display condition : 2 S:SUPPRESSED F:FILTERED s:STALE 1 Prefix: 129.77.0.0/16, Status: BI, Age: 1h0m28s NEXT_HOP: 216.66.50.106, Metric: 680, Learned from Peer: 216.218.252.148 (6939) LOCAL_PREF: 140, MED: 1, ORIGIN: igp, Weight: 0 AS_PATH: 46887 14607 14607 COMMUNITIES: 6939:1000 6939:1001 6939:1111 2 Prefix: 129.77.0.0/16, Status: I, Age: 1h0m28s NEXT_HOP: 216.66.32.6, Metric: 725, Learned from Peer: 216.218.252.212 (6939) LOCAL_PREF: 140, MED: 1, ORIGIN: igp, Weight: 0 AS_PATH: 46887 14607 14607 COMMUNITIES: 6939:1000 6939:1001 6939:1111 Last update to IP routing table: 1h0m28s, 1 path(s) installed: # Entry cached for another 59 seconds. At least at this stage no special communities are visible but I don't know if HE removes existing communities. best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Matthew Huff Gesendet: Freitag, 20. Mai 2016 18:11 An: Eric Tykwinski Cc: nanog at nanog.org Betreff: RE: Need BGP route check (UPDATE) >From responses I received, I have gotten a number of different answers. Some are seeing our routes from 6128, some from 46887 and a few from both. The response from Eric though was typical. Showing the IPv4 prefix only from AS6128, but the IPv6 from both 6128 & 46887. I am guessing that 46887 might be set with a community to not export our IPv4 prefixes except to direct peers? Anyone directly peered with 46887 that could see the community for 129.77.0.0/16 and verify? ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: Eric Tykwinski [mailto:eric-list at truenet.com] > Sent: Friday, May 20, 2016 11:48 AM > To: Matthew Huff > Subject: RE: Need BGP route check > > Matt, > > show ip bgp 129.77.0.0/16 > BGP routing table entry for 129.77.0.0/16, version 161696687 > Paths: (2 available, best #2, table Default-IP-Routing-Table) > Advertised to update-groups: > 1 > 3356 6128 14607 > 4.59.140.65 from 4.59.140.65 (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external > 174 6128 14607 > 38.104.114.73 from 38.104.114.73 (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external, best > Community: 174:21000 174:22013 > > show bgp ipv6 unicast 2620:0:2810::/48 > BGP routing table entry for 2620:0:2810::/48, version 18004880 > Paths: (2 available, best #1, table Global-IPv6-Table) > Advertised to update-groups: > 2 > 3356 6128 14607 > 2001:1900:2100::A2D (FE80::219:7FF:FEDD:2800) from > 2001:1900:2100::A2D > (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external, best > Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2039 > 6128:3000 6128:3091 6128:4000 6128:5003 6128:5046 64600:4000 > 64600:65002 > 174 46887 14607 14607 > 2001:550:2:4::B:1 (FE80::D66D:50FF:FE5E:1D3) from 2001:550:2:4::B:1 > (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external > Community: 174:21001 174:22013 > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Huff > Sent: Friday, May 20, 2016 11:32 AM > To: nanog at nanog.org > Subject: Need BGP route check > > One of our upstreams is apparently having problems, although they don't > appear to know about it. I've seen an alert at BGPmon.net about our > prefixes > being withdrawn, and I can't locate our prefixes through that provider > on > any routeviews. Can someone check to see what ASPATHS you are seeing > for our > prefixes? > > 129.77.0.0/16 > 2620:0:2810::/48 > > We should be advertised via AS6128 and AS46887 > > ---- > Matthew Huff???????????? | 1 Manhattanville Rd Director of > Operations???| > Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 > aim: matthewbhuff??????? | Fax:?? 914-694-5669 > > > From cscora at apnic.net Fri May 20 18:10:43 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 May 2016 04:10:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201605201810.u4KIAhCR026635@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 May, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 593812 Prefixes after maximum aggregation (per Origin AS): 217438 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 291167 Total ASes present in the Internet Routing Table: 53819 Prefixes per ASN: 11.03 Origin-only ASes present in the Internet Routing Table: 36588 Origin ASes announcing only one prefix: 15681 Transit ASes present in the Internet Routing Table: 6448 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 960 Unregistered ASNs in the Routing Table: 360 Number of 32-bit ASNs allocated by the RIRs: 13944 Number of 32-bit ASNs visible in the Routing Table: 10783 Prefixes from 32-bit ASNs in the Routing Table: 42394 Number of bogon 32-bit ASNs visible in the Routing Table: 28 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 383 Number of addresses announced to Internet: 2810367044 Equivalent to 167 /8s, 130 /16s and 204 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193857 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151956 Total APNIC prefixes after maximum aggregation: 42399 APNIC Deaggregation factor: 3.58 Prefixes being announced from the APNIC address blocks: 163075 Unique aggregates announced from the APNIC address blocks: 66721 APNIC Region origin ASes present in the Internet Routing Table: 5180 APNIC Prefixes per ASN: 31.48 APNIC Region origin ASes announcing only one prefix: 1179 APNIC Region transit ASes present in the Internet Routing Table: 916 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2087 Number of APNIC addresses announced to Internet: 754229060 Equivalent to 44 /8s, 244 /16s and 159 /24s Percentage of available APNIC address space announced: 88.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 180969 Total ARIN prefixes after maximum aggregation: 89100 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 186372 Unique aggregates announced from the ARIN address blocks: 88141 ARIN Region origin ASes present in the Internet Routing Table: 16361 ARIN Prefixes per ASN: 11.39 ARIN Region origin ASes announcing only one prefix: 5842 ARIN Region transit ASes present in the Internet Routing Table: 1716 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1221 Number of ARIN addresses announced to Internet: 1101448512 Equivalent to 65 /8s, 166 /16s and 197 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 142433 Total RIPE prefixes after maximum aggregation: 70409 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 151690 Unique aggregates announced from the RIPE address blocks: 94010 RIPE Region origin ASes present in the Internet Routing Table: 18083 RIPE Prefixes per ASN: 8.39 RIPE Region origin ASes announcing only one prefix: 7903 RIPE Region transit ASes present in the Internet Routing Table: 3012 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4773 Number of RIPE addresses announced to Internet: 704402560 Equivalent to 41 /8s, 252 /16s and 84 /24s Percentage of available RIPE address space announced: 102.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61841 Total LACNIC prefixes after maximum aggregation: 12235 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 76253 Unique aggregates announced from the LACNIC address blocks: 36154 LACNIC Region origin ASes present in the Internet Routing Table: 2482 LACNIC Prefixes per ASN: 30.72 LACNIC Region origin ASes announcing only one prefix: 577 LACNIC Region transit ASes present in the Internet Routing Table: 570 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2493 Number of LACNIC addresses announced to Internet: 171197760 Equivalent to 10 /8s, 52 /16s and 69 /24s Percentage of available LACNIC address space announced: 102.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 14112 Total AfriNIC prefixes after maximum aggregation: 3258 AfriNIC Deaggregation factor: 4.33 Prefixes being announced from the AfriNIC address blocks: 16039 Unique aggregates announced from the AfriNIC address blocks: 5798 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 21.76 AfriNIC Region origin ASes announcing only one prefix: 180 AfriNIC Region transit ASes present in the Internet Routing Table: 169 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 209 Number of AfriNIC addresses announced to Internet: 78707968 Equivalent to 4 /8s, 176 /16s and 253 /24s Percentage of available AfriNIC address space announced: 78.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5556 4192 76 China Education and Research 7545 3334 356 220 TPG Telecom Limited 4766 3170 11144 1123 Korea Telecom 17974 2946 914 96 PT Telekomunikasi Indonesia 9829 2459 1467 464 National Internet Backbone 4755 2096 432 243 TATA Communications formerly 9808 1940 8717 30 Guangdong Mobile Communicatio 4808 1659 2299 549 CNCGROUP IP network China169 9583 1513 122 558 Sify Limited 38197 1497 93 215 Sun Network (Hong Kong) Limit Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3242 2947 138 Cox Communications Inc. 6389 2299 3671 41 BellSouth.net Inc. 18566 2195 394 275 MegaPath Corporation 20115 1921 1937 404 Charter Communications 30036 1696 337 401 Mediacom Communications Corp 6983 1689 849 232 EarthLink, Inc. 209 1669 4968 770 Qwest Communications Company, 4323 1517 985 376 tw telecom holdings, inc. 701 1296 10718 704 MCI Communications Services, 11492 1290 236 586 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2557 985 1837 Akamai International B.V. 34984 1965 326 358 TELLCOM ILETISIM HIZMETLERI A 12479 1221 997 83 France Telecom Espana SA 8551 1203 376 55 Bezeq International-Ltd 6849 1148 355 21 JSC "Ukrtelecom" 13188 1078 98 65 TOV "Bank-Inform" 8402 1065 544 15 OJSC "Vimpelcom" 31148 1027 47 45 Freenet Ltd. 6830 890 2719 463 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3477 541 152 Telmex Colombia S.A. 8151 2259 3411 563 Uninet S.A. de C.V. 7303 1510 940 234 Telecom Argentina S.A. 6503 1477 437 55 Axtel, S.A.B. de C.V. 11830 1477 368 52 Instituto Costarricense de El 6147 1160 377 27 Telefonica del Peru S.A.A. 26615 1005 2325 34 Tim Celular S.A. 3816 999 478 186 COLOMBIA TELECOMUNICACIONES S 7738 994 1882 40 Telemar Norte Leste S.A. 11172 907 125 77 Alestra, S. de R.L. de C.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1082 402 44 Link Egypt (Link.NET) 37611 650 48 2 Afrihost-Brevis Computer Serv 36903 626 315 103 Office National des Postes et 36992 509 1359 27 ETISALAT MISR 8452 490 1472 15 TE-AS 37492 395 234 68 Orange Tunisie 29571 301 37 13 Cote d'Ivoire Telecom 24835 294 466 14 Vodafone Data 15399 284 35 10 Wananchi Group (Kenya) Limite 2018 257 327 74 TENET (The UNINET Project) Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5556 4192 76 China Education and Research 10620 3477 541 152 Telmex Colombia S.A. 7545 3334 356 220 TPG Telecom Limited 22773 3242 2947 138 Cox Communications Inc. 4766 3170 11144 1123 Korea Telecom 17974 2946 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2557 985 1837 Akamai International B.V. 9829 2459 1467 464 National Internet Backbone 6389 2299 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3477 3325 Telmex Colombia S.A. 7545 3334 3114 TPG Telecom Limited 22773 3242 3104 Cox Communications Inc. 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2946 2850 PT Telekomunikasi Indonesia 6389 2299 2258 BellSouth.net Inc. 4766 3170 2047 Korea Telecom 9829 2459 1995 National Internet Backbone 18566 2195 1920 MegaPath Corporation 9808 1940 1910 Guangdong Mobile Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:266 /13:511 /14:1035 /15:1761 /16:13039 /17:7614 /18:12699 /19:25925 /20:37931 /21:39674 /22:65485 /23:57409 /24:328597 /25:556 /26:598 /27:420 /28:46 /29:33 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2471 3242 Cox Communications Inc. 18566 2097 2195 MegaPath Corporation 30036 1511 1696 Mediacom Communications Corp 6389 1477 2299 BellSouth.net Inc. 10620 1373 3477 Telmex Colombia S.A. 6983 1338 1689 EarthLink, Inc. 34984 1249 1965 TELLCOM ILETISIM HIZMETLERI A 11492 1193 1290 CABLE ONE, INC. 6849 968 1148 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1584 2:746 4:20 5:2066 6:31 8:958 12:1781 13:39 14:1695 15:45 16:2 17:84 18:90 20:48 22:1 23:1495 24:1775 27:2278 31:1771 32:59 33:2 34:2 35:5 36:287 37:2305 38:1219 39:25 40:91 41:2867 42:395 43:1738 44:43 45:1896 46:2494 47:77 49:1174 50:868 51:33 52:188 54:329 55:5 56:7 57:42 58:1538 59:874 60:343 61:1825 62:1509 63:1922 64:4452 65:2164 66:4248 67:2153 68:1089 69:3291 70:1103 71:476 72:1989 74:2547 75:344 76:345 77:1382 78:1248 79:820 80:1276 81:1338 82:945 83:700 84:824 85:1611 86:473 87:1086 88:561 89:1993 90:174 91:6047 92:896 93:2331 94:2332 95:2309 96:486 97:359 98:935 99:46 100:75 101:1047 103:10824 104:2415 105:124 106:400 107:1175 108:671 109:2191 110:1256 111:1651 112:1006 113:1143 114:1052 115:1615 116:1578 117:1429 118:2054 119:1624 120:934 121:1178 122:2177 123:2009 124:1569 125:1726 128:719 129:419 130:412 131:1326 132:622 133:176 134:454 135:127 136:374 137:353 138:1709 139:277 140:543 141:458 142:638 143:939 144:688 145:160 146:873 147:608 148:1481 149:508 150:649 151:882 152:618 153:281 154:623 155:938 156:499 157:432 158:337 159:1119 160:484 161:709 162:2322 163:546 164:900 165:1047 166:320 167:1148 168:1849 169:660 170:1578 171:263 172:561 173:1638 174:743 175:723 176:1740 177:3986 178:2208 179:1137 180:2060 181:1789 182:1850 183:951 184:800 185:6434 186:2990 187:2119 188:2125 189:1708 190:7749 191:1238 192:8937 193:5740 194:4389 195:3770 196:1710 197:1073 198:5549 199:5699 200:7010 201:3766 202:10115 203:9645 204:4511 205:2732 206:2981 207:3120 208:4049 209:3861 210:3877 211:2053 212:2696 213:2232 214:856 215:70 216:5782 217:1947 218:797 219:607 220:1683 221:869 222:665 223:1222 End of report From nathana at fsr.com Fri May 20 23:43:07 2016 From: nathana at fsr.com (Nathan Anderson) Date: Fri, 20 May 2016 16:43:07 -0700 Subject: SNMP "bridging"/proxy? Message-ID: 'lo all, Is anybody out there aware of a piece of software that can take data from an arbitrary source and then present it, using a MIB or set of OIDs of your choosing, as an SNMP-interrogatable device? We have some CPE that supports SNMP, but considers it to be a mutually-exclusive "remote management" protocol such that if you use another supported method for deployment and provisioning (e.g., TR-069), you cannot have both that AND SNMP enabled simultaneously. It's one or the other. We currently monitor and graph some device stats for these CPE with Cacti, but we want to be able to provision using a TR-069 ACS. The ACS can collect some of the same data we are graphing right now, but cannot present it in a fashion that is nearly as useful as the way Cacti/RRDtool does (not to mention the staff is already used to navigating Cacti). We know what SQL database table the stats are being stored in by the ACS, though, so my thought was that there must be some way that we can have a host respond to SNMP gets and then have it turn around and collect the value to be returned from a database. Basically, an ODBC -> SNMP proxy. We'd then point Cacti at that IP instead of the individual CPEs. But I can't seem to find anything like this. Thanks, -- Nathan From eric.kuhnke at gmail.com Sat May 21 00:09:22 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 20 May 2016 17:09:22 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: References: Message-ID: It is fairly easy to extend the snmpd on a Linux host to retrieve data from non-SNMP sources... For example: http://www.adventuresinoss.com/2009/09/30/the-many-uses-of-net-snmp/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-System_Monitoring_Tools-Net-SNMP-Extending.html Anything you can retrieve with a shell script can be turned into a 1-minute-interval cron job that outputs a text file with a number in it, then the SNMP 'extend' parameter in the snmpd.conf can be used to 'cat' the file. For example something from a solar charge controller that only speaks RS485 over an RS485-to-RS232 (or USB) bridge. Or data retrieved via curl and sed. I use this to graph WSDOT traffic driving times patterns and flows and feed them into a charting system. For smaller setups you can have all the shell scripts for data acquisition on the same host that runs the snmpd. On Fri, May 20, 2016 at 4:43 PM, Nathan Anderson wrote: > 'lo all, > > Is anybody out there aware of a piece of software that can take data from > an arbitrary source and then present it, using a MIB or set of OIDs of your > choosing, as an SNMP-interrogatable device? > > We have some CPE that supports SNMP, but considers it to be a > mutually-exclusive "remote management" protocol such that if you use > another supported method for deployment and provisioning (e.g., TR-069), > you cannot have both that AND SNMP enabled simultaneously. It's one or the > other. > > We currently monitor and graph some device stats for these CPE with Cacti, > but we want to be able to provision using a TR-069 ACS. The ACS can > collect some of the same data we are graphing right now, but cannot present > it in a fashion that is nearly as useful as the way Cacti/RRDtool does (not > to mention the staff is already used to navigating Cacti). We know what > SQL database table the stats are being stored in by the ACS, though, so my > thought was that there must be some way that we can have a host respond to > SNMP gets and then have it turn around and collect the value to be returned > from a database. Basically, an ODBC -> SNMP proxy. We'd then point Cacti > at that IP instead of the individual CPEs. But I can't seem to find > anything like this. > > Thanks, > > -- Nathan > From mpalmer at hezmatt.org Sat May 21 01:53:53 2016 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 21 May 2016 11:53:53 +1000 Subject: SNMP "bridging"/proxy? In-Reply-To: References: Message-ID: <20160521015353.GI5275@hezmatt.org> On Fri, May 20, 2016 at 04:43:07PM -0700, Nathan Anderson wrote: > Is anybody out there aware of a piece of software that can take data from > an arbitrary source and then present it, using a MIB or set of OIDs of > your choosing, as an SNMP-interrogatable device? Many, many years ago, I wrote a fairly minimal SNMP agent in Ruby (http://theshed.hezmatt.org/rubysnmpd/index.html), which was explicitly designed to be easily extensible (it didn't do anything useful by itself). If your team's into Ruby, that might be a possibility. Otherwise, net-snmp does come with some fairly decent extensibility capabilities these days. It has a variety of mechanisms by which you can feed extra data into it, and in general I'd recommend going down that route. - Matt From rdrake at direcpath.com Sat May 21 04:45:18 2016 From: rdrake at direcpath.com (Robert Drake) Date: Sat, 21 May 2016 00:45:18 -0400 Subject: SNMP "bridging"/proxy? In-Reply-To: References: Message-ID: <9b2826c1-2948-31ff-ac4d-ebd8779eb393@direcpath.com> On 5/20/2016 7:43 PM, Nathan Anderson wrote: > 'lo all, > > Is anybody out there aware of a piece of software that can take data from an arbitrary source and then present it, using a MIB or set of OIDs of your choosing, as an SNMP-interrogatable device? > > We have some CPE that supports SNMP, but considers it to be a mutually-exclusive "remote management" protocol such that if you use another supported method for deployment and provisioning (e.g., TR-069), you cannot have both that AND SNMP enabled simultaneously. It's one or the other. > > We currently monitor and graph some device stats for these CPE with Cacti, but we want to be able to provision using a TR-069 ACS. The ACS can collect some of the same data we are graphing right now, but cannot present it in a fashion that is nearly as useful as the way Cacti/RRDtool does (not to mention the staff is already used to navigating Cacti). We know what SQL database table the stats are being stored in by the ACS, though, so my thought was that there must be some way that we can have a host respond to SNMP gets and then have it turn around and collect the value to be returned from a database. Basically, an ODBC -> SNMP proxy. We'd then point Cacti at that IP instead of the individual CPEs. But I can't seem to find anything like this. I would move away from this CPE vendor. Your solution has merit in the short term, but monitoring through the ACS is pointlessly putting more load on a server that already has it's own responsibilities. You can't scale out with this. Well, not without deploying more ACS servers.. which are a bit more heavyweight than SNMP pollers. As mentioned already, net-snmp can do this easily enough. The biggest problem you'll face is figuring out how you want to name OIDs to match up to each CPE and the elements you're graphing. .... you might be better off pulling the data out of the database via SQL queries to a remote host and proxying the data there. Or possibly have cacti run the SQL query directly. It looks like they have many general (non SNMP) templates that you could use to base it on. http://docs.cacti.net/templates http://forums.cacti.net/viewtopic.php?f=12&t=15067 > Thanks, > > -- Nathan > Thanks, Robert From nathana at fsr.com Sat May 21 06:11:37 2016 From: nathana at fsr.com (Nathan Anderson) Date: Fri, 20 May 2016 23:11:37 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: References: Message-ID: Hey, thanks guys! I had never really looked that deeply into Net-SNMP and had only ever installed it either to use as a client (snmpget/snmpwalk) or a basic agent w/ standard MIBs for the host it's running on, so I was unaware of its extensibility. And it even looks like it ships with a Perl module. That sounds like a perfect solution; thanks for pointing me in the right direction. -- Nathan From nathana at fsr.com Sat May 21 06:18:21 2016 From: nathana at fsr.com (Nathan Anderson) Date: Fri, 20 May 2016 23:18:21 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: <9b2826c1-2948-31ff-ac4d-ebd8779eb393@direcpath.com> References: , <9b2826c1-2948-31ff-ac4d-ebd8779eb393@direcpath.com> Message-ID: On Friday May 20, 2016 @ 21:45, Robert Drake wrote: > I would move away from this CPE vendor. I'm not thrilled with it either, but at this moment in time, this is easier said than done for many unfortunately good and unavoidable reasons. We will see how the future plays out, though. > [...] Or possibly have cacti run the > SQL query directly. It looks like they have many general (non SNMP) > templates that you could use to base it on. Another interesting suggestion & possibility. Thanks. -- Nathan From jcurran at arin.net Sun May 22 04:32:11 2016 From: jcurran at arin.net (John Curran) Date: Sun, 22 May 2016 04:32:11 +0000 Subject: IPv6 Residential Deployment Survey References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> Message-ID: <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> NANOGers - If you are providing residential Internet service with IPv6 (or are a customer of same), please take a moment to complete Jordi?s survey - this will help provide insight into the actual technical practices being used in residential IPv6 deployment. More details in attached email - Thanks! /John Begin forwarded message: From: John Curran > Subject: [arin-ppml] IPv6 Residential Deployment Survey Date: May 22, 2016 at 6:24:17 AM GMT+2 To: ARIN PPML > Folks - Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 deployment in residential Internet service. Having insight into the various practices that are in use may help to inform IPv6 number resource policy development, and thus I ask that you take a moment to complete the survey if you are providing such services (whether production or trial basis.) Jordi notes - "The results will be published and updated every month or so - No personal data will be published. (If you know your network, it takes less than 2 minutes to complete it) The survey can be responded even if is not yet a commercial service, and customers can also respond, not just the ISP. However, to avoid duplicate data, make sure to include the country and ISP name.? The IPv6 Residential Deployment Survey may be found here - Thanks! /John John Curran President and CEO ARIN From msa at latt.net Sun May 22 07:04:14 2016 From: msa at latt.net (Majdi S. Abbas) Date: Sun, 22 May 2016 03:04:14 -0400 Subject: IPv6 Residential Deployment Survey In-Reply-To: <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> Message-ID: <20160522070414.GA14908@puck.nether.net> On Sun, May 22, 2016 at 04:32:11AM +0000, John Curran wrote: > NANOGers - > > If you are providing residential Internet service with IPv6 (or > are a customer of same), please take a moment to complete > Jordi?s survey - this will help provide insight into the actual > technical practices being used in residential IPv6 deployment. John, Allow me to suggest an additional survey: If you're a customer of a provider that currently provides IPv6, and are not using it, please tell us why. In my case, on my consumer connection at home, I cannot utilize IPv6 because my provider does not wish to provide more than a /64 to a subscriber, and my equipment vendor (Juniper) does not support DHCPv6 PD delegation hints, so I'll always get a /64 that does not scale well to the >1 subnet I have internally. (4: Managment, Media, Guest, & Internal.) --msa From jcurran at arin.net Sun May 22 07:11:32 2016 From: jcurran at arin.net (John Curran) Date: Sun, 22 May 2016 07:11:32 +0000 Subject: IPv6 Residential Deployment Survey In-Reply-To: <20160522070414.GA14908@puck.nether.net> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <20160522070414.GA14908@puck.nether.net> Message-ID: <77DC793E-479F-4809-B31E-1D91142ED257@arin.net> > On May 22, 2016, at 9:04 AM, Majdi S. Abbas wrote: > > On Sun, May 22, 2016 at 04:32:11AM +0000, John Curran wrote: >> NANOGers - >> >> If you are providing residential Internet service with IPv6 (or >> are a customer of same), please take a moment to complete >> Jordi?s survey - this will help provide insight into the actual >> technical practices being used in residential IPv6 deployment. > > John, > > Allow me to suggest an additional survey: > > If you're a customer of a provider that currently provides > IPv6, and are not using it, please tell us why. > > In my case, on my consumer connection at home, I cannot utilize > IPv6 because my provider does not wish to provide more than a /64 to > a subscriber, and my equipment vendor (Juniper) does not support DHCPv6 > PD delegation hints, so I'll always get a /64 that does not scale well > to the >1 subnet I have internally. (4: Managment, Media, Guest, & > Internal.) Majdi - You should definitely complete the survey accordingly? that?s the kind of technical feedback that I believe Jordi is trying to collect! /John From aaron at heyaaron.com Sun May 22 18:15:46 2016 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 22 May 2016 11:15:46 -0700 Subject: IPv6 Residential Deployment Survey In-Reply-To: <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> Message-ID: The 'Next' button just keeps refreshing the initial page for me (Chrome, Linux). I was hoping there was an option in the survey for "I contacted my local monopoly^H^H^H^H^H provider, talked with their 'network guy' and asked about IPv6. He said he'd heard about it, but they probably won't going to even investigate it for 'a couple of years'". -A On Sat, May 21, 2016 at 9:32 PM, John Curran wrote: > NANOGers - > > If you are providing residential Internet service with IPv6 (or > are a customer of same), please take a moment to complete > Jordi?s survey - this will help provide insight into the actual > technical practices being used in residential IPv6 deployment. > > More details in attached email - Thanks! > /John > > > Begin forwarded message: > > From: John Curran > > Subject: [arin-ppml] IPv6 Residential Deployment Survey > Date: May 22, 2016 at 6:24:17 AM GMT+2 > To: ARIN PPML > > > Folks - > > Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 > deployment > in residential Internet service. Having insight into the various > practices that > are in use may help to inform IPv6 number resource policy development, > and > thus I ask that you take a moment to complete the survey if you are > providing > such services (whether production or trial basis.) > > Jordi notes - > > "The results will be published and updated every month or so - > No personal data will be published. > > (If you know your network, it takes less than 2 minutes to > complete it) > The survey can be responded even if is not yet a commercial > service, > and customers can also respond, not just the ISP. However, to > avoid > duplicate data, make sure to include the country and ISP name.? > > The IPv6 Residential Deployment Survey may be found here - > > > > Thanks! > /John > > John Curran > President and CEO > ARIN > From gwardell at gwsystems.co.il Sun May 22 18:31:00 2016 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sun, 22 May 2016 14:31:00 -0400 Subject: IPv6 Residential Deployment Survey In-Reply-To: <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> Message-ID: <00a501d1b458$17290120$457b0360$@gwsystems.co.il> Hi, My business provider (Shentel) doesn't even offer IPv6. I have asked repeatedly. Gary > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Curran > Sent: Sunday, May 22, 2016 12:32 AM > To: NANOG > Subject: IPv6 Residential Deployment Survey > > NANOGers - > > If you are providing residential Internet service with IPv6 (or > are a customer of same), please take a moment to complete > Jordi?s survey - this will help provide insight into the actual > technical practices being used in residential IPv6 deployment. > > More details in attached email - Thanks! > /John > > > Begin forwarded message: > > From: John Curran > > Subject: [arin-ppml] IPv6 Residential Deployment Survey > Date: May 22, 2016 at 6:24:17 AM GMT+2 > To: ARIN PPML > > > Folks - > > Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 deployment > in residential Internet service. Having insight into the various practices that > are in use may help to inform IPv6 number resource policy development, > and > thus I ask that you take a moment to complete the survey if you are > providing > such services (whether production or trial basis.) > > Jordi notes - > > "The results will be published and updated every month or so - > No personal data will be published. > > (If you know your network, it takes less than 2 minutes to complete it) > The survey can be responded even if is not yet a commercial service, > and customers can also respond, not just the ISP. However, to avoid > duplicate data, make sure to include the country and ISP name.? > > The IPv6 Residential Deployment Survey may be found here - > > > > Thanks! > /John > > John Curran > President and CEO > ARIN From aaron at heyaaron.com Sun May 22 20:11:42 2016 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 22 May 2016 13:11:42 -0700 Subject: IPv6 Residential Deployment Survey In-Reply-To: <6B4F2DF5-0373-4C08-AF2D-BEC25377EFA2@consulintel.es> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <6B4F2DF5-0373-4C08-AF2D-BEC25377EFA2@consulintel.es> Message-ID: Did some digging, it's was being caused by a plugin. Thanks, -A On Sun, May 22, 2016 at 11:37 AM, JORDI PALET MARTINEZ < jordi.palet at consulintel.es> wrote: > Hi Aaron, > > Sorry to heard that. Is the first report I got about this problem (253 > responses already and many using Chrome), so may be specific to > Chrome+Linux, not sure if you have been able to try with another browser or > OS. > > Regards, > Jordi > > > -----Mensaje original----- > De: NANOG en nombre de "Aaron C. de Bruyn" < > aaron at heyaaron.com> > Responder a: > Fecha: domingo, 22 de mayo de 2016, 20:15 > Para: John Curran > CC: NANOG > Asunto: Re: IPv6 Residential Deployment Survey > > >The 'Next' button just keeps refreshing the initial page for me (Chrome, > >Linux). > > > >I was hoping there was an option in the survey for "I contacted my local > >monopoly^H^H^H^H^H provider, talked with their 'network guy' and asked > >about IPv6. He said he'd heard about it, but they probably won't going to > >even investigate it for 'a couple of years'". > > > >-A > > > >On Sat, May 21, 2016 at 9:32 PM, John Curran wrote: > > > >> NANOGers - > >> > >> If you are providing residential Internet service with IPv6 (or > >> are a customer of same), please take a moment to complete > >> Jordi?s survey - this will help provide insight into the actual > >> technical practices being used in residential IPv6 deployment. > >> > >> More details in attached email - Thanks! > >> /John > >> > >> > >> Begin forwarded message: > >> > >> From: John Curran > > >> Subject: [arin-ppml] IPv6 Residential Deployment Survey > >> Date: May 22, 2016 at 6:24:17 AM GMT+2 > >> To: ARIN PPML > > >> > >> Folks - > >> > >> Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 > >> deployment > >> in residential Internet service. Having insight into the various > >> practices that > >> are in use may help to inform IPv6 number resource policy > development, > >> and > >> thus I ask that you take a moment to complete the survey if you are > >> providing > >> such services (whether production or trial basis.) > >> > >> Jordi notes - > >> > >> "The results will be published and updated every month or so - > >> No personal data will be published. > >> > >> (If you know your network, it takes less than 2 minutes to > >> complete it) > >> The survey can be responded even if is not yet a commercial > >> service, > >> and customers can also respond, not just the ISP. However, to > >> avoid > >> duplicate data, make sure to include the country and ISP > name.? > >> > >> The IPv6 Residential Deployment Survey may be found here - > >> > >> > >> > >> Thanks! > >> /John > >> > >> John Curran > >> President and CEO > >> ARIN > >> > > > > > > From maxtul at netassist.ua Sun May 22 06:33:38 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 22 May 2016 09:33:38 +0300 Subject: Question on peering strategies In-Reply-To: References: Message-ID: <574152C2.4050209@netassist.ua> Hi All, I wonder why a "VLAN exchange" does not exists. Or I do not know any? In my understanding it should be a switch, and people connected can easily order a private VLAN between each other (or to private group) through some kind of web interface. That should be a more easy and much less expensive way for private interconnects than direct wires. On 16.05.16 20:46, Reza Motamedi wrote: > Dear Nanogers, > > I have a question about common/best network interconnection practices. > Assume that two networks (let's refer to them as AS-a and AS-b) are present > in a colocation facility say Equinix LA. As many of you know, Equininx runs > an IXP in LA as well. So AS-as and AS-b can interconnct > 1) using private cross-connect > 2) through the public IXP's switching fabric. > Is it a common/good practice for the two networks to establish connections > both through the IXP and also using a private cross-connect? > > I was thinking considering the cost of cross-connects (my understanding is > that the colocation provider charges the customers for each cross-connect > in addition to the rent of the rack or cage or whatever), it would not be > economically reasonable to have both. Although, if the cross-connect is the > primary method of interconnection, and the IXP provides a router-server the > public-peering over IXP would essentially be free. So it might makes sense > to assume that for the private cross-connect, there exists a back-up > connection though the IXP. Anyway, I guess some discussion may give more > insight about which one is more reasonable to assume and do. > > Now my last question is that if the two connections exist (one private > cross-connect and another back-up through the IXP), what are the chances > that periodically launched traceroutes that pass the inter-AS connection in > that colo see both types of connection in a week. I guess what I'm asking > is how often back-up routes are taken? Can the networks do load balancing > on the two connection and essentially use them as primary routes? > > Best Regards > Reza Motamedi (R.M) > Graduate Research Fellow > Oregon Network Research Group > Computer and Information Science > University of Oregon > From marty at cloudflare.com Mon May 23 08:59:16 2016 From: marty at cloudflare.com (Marty Strong) Date: Mon, 23 May 2016 09:59:16 +0100 Subject: Question on peering strategies In-Reply-To: <574152C2.4050209@netassist.ua> References: <574152C2.4050209@netassist.ua> Message-ID: <9EFD2812-E741-4C52-B041-3099C678118F@cloudflare.com> This does exist, often called an elastic fabric, e.g. Megaport Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 22 May 2016, at 07:33, Max Tulyev wrote: > > Hi All, > > I wonder why a "VLAN exchange" does not exists. Or I do not know any? > > In my understanding it should be a switch, and people connected can > easily order a private VLAN between each other (or to private group) > through some kind of web interface. > > That should be a more easy and much less expensive way for private > interconnects than direct wires. > > On 16.05.16 20:46, Reza Motamedi wrote: >> Dear Nanogers, >> >> I have a question about common/best network interconnection practices. >> Assume that two networks (let's refer to them as AS-a and AS-b) are present >> in a colocation facility say Equinix LA. As many of you know, Equininx runs >> an IXP in LA as well. So AS-as and AS-b can interconnct >> 1) using private cross-connect >> 2) through the public IXP's switching fabric. >> Is it a common/good practice for the two networks to establish connections >> both through the IXP and also using a private cross-connect? >> >> I was thinking considering the cost of cross-connects (my understanding is >> that the colocation provider charges the customers for each cross-connect >> in addition to the rent of the rack or cage or whatever), it would not be >> economically reasonable to have both. Although, if the cross-connect is the >> primary method of interconnection, and the IXP provides a router-server the >> public-peering over IXP would essentially be free. So it might makes sense >> to assume that for the private cross-connect, there exists a back-up >> connection though the IXP. Anyway, I guess some discussion may give more >> insight about which one is more reasonable to assume and do. >> >> Now my last question is that if the two connections exist (one private >> cross-connect and another back-up through the IXP), what are the chances >> that periodically launched traceroutes that pass the inter-AS connection in >> that colo see both types of connection in a week. I guess what I'm asking >> is how often back-up routes are taken? Can the networks do load balancing >> on the two connection and essentially use them as primary routes? >> >> Best Regards >> Reza Motamedi (R.M) >> Graduate Research Fellow >> Oregon Network Research Group >> Computer and Information Science >> University of Oregon >> > From Jac.Kloots at surfnet.nl Mon May 23 09:00:57 2016 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Mon, 23 May 2016 11:00:57 +0200 (CEST) Subject: Question on peering strategies In-Reply-To: <574152C2.4050209@netassist.ua> References: <574152C2.4050209@netassist.ua> Message-ID: Hi Max, These do exist, at least in the NREN part of the internet. Have a look at netherlight (www.netherlight.net) and the bigger picture GLIF (www.glif.is) and where you read 'lightpath' replace that with ethernet p2p. Regards, Jac On Sun, 22 May 2016, Max Tulyev wrote: > Hi All, > > I wonder why a "VLAN exchange" does not exists. Or I do not know any? > > In my understanding it should be a switch, and people connected can > easily order a private VLAN between each other (or to private group) > through some kind of web interface. > > That should be a more easy and much less expensive way for private > interconnects than direct wires. > > On 16.05.16 20:46, Reza Motamedi wrote: >> Dear Nanogers, >> >> I have a question about common/best network interconnection practices. >> Assume that two networks (let's refer to them as AS-a and AS-b) are present >> in a colocation facility say Equinix LA. As many of you know, Equininx runs >> an IXP in LA as well. So AS-as and AS-b can interconnct >> 1) using private cross-connect >> 2) through the public IXP's switching fabric. >> Is it a common/good practice for the two networks to establish connections >> both through the IXP and also using a private cross-connect? >> >> I was thinking considering the cost of cross-connects (my understanding is >> that the colocation provider charges the customers for each cross-connect >> in addition to the rent of the rack or cage or whatever), it would not be >> economically reasonable to have both. Although, if the cross-connect is the >> primary method of interconnection, and the IXP provides a router-server the >> public-peering over IXP would essentially be free. So it might makes sense >> to assume that for the private cross-connect, there exists a back-up >> connection though the IXP. Anyway, I guess some discussion may give more >> insight about which one is more reasonable to assume and do. >> >> Now my last question is that if the two connections exist (one private >> cross-connect and another back-up through the IXP), what are the chances >> that periodically launched traceroutes that pass the inter-AS connection in >> that colo see both types of connection in a week. I guess what I'm asking >> is how often back-up routes are taken? Can the networks do load balancing >> on the two connection and essentially use them as primary routes? >> >> Best Regards >> Reza Motamedi (R.M) >> Graduate Research Fellow >> Oregon Network Research Group >> Computer and Information Science >> University of Oregon >> > > -- Jac Kloots Network Services SURFnet bv From jwbensley at gmail.com Mon May 23 09:03:58 2016 From: jwbensley at gmail.com (James Bensley) Date: Mon, 23 May 2016 10:03:58 +0100 Subject: Question on peering strategies In-Reply-To: <9EFD2812-E741-4C52-B041-3099C678118F@cloudflare.com> References: <574152C2.4050209@netassist.ua> <9EFD2812-E741-4C52-B041-3099C678118F@cloudflare.com> Message-ID: >> On 22 May 2016, at 07:33, Max Tulyev wrote: >> >> Hi All, >> >> I wonder why a "VLAN exchange" does not exists. Or I do not know any? >> >> In my understanding it should be a switch, and people connected can >> easily order a private VLAN between each other (or to private group) >> through some kind of web interface. >> >> That should be a more easy and much less expensive way for private >> interconnects than direct wires. On 23 May 2016 at 09:59, Marty Strong via NANOG wrote: > This does exist, often called an elastic fabric, e.g. Megaport > > Regards, > Marty Strong > -------------------------------------- > CloudFlare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > http://www.peeringdb.com/view.php?asn=13335 As Marty said, it does exist. AN example from LONAP in the UK: https://www.lonap.net/fees.php Private VLANs between members = FREE Another option is using a provider like IXReach (now "Console"), take a peering to them, and then down multiple VLANs they can through you peerings to different IXs from around the world and to other networks: http://www.ixreach.com/ Cheers, James. From bicknell at ufp.org Mon May 23 12:56:01 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 May 2016 05:56:01 -0700 Subject: Question on peering strategies In-Reply-To: <574152C2.4050209@netassist.ua> References: <574152C2.4050209@netassist.ua> Message-ID: <20160523125601.GA28488@ussenterprise.ufp.org> In a message written on Sun, May 22, 2016 at 09:33:38AM +0300, Max Tulyev wrote: > That should be a more easy and much less expensive way for private > interconnects than direct wires. The problem is peering is not an even distribution by traffic level. When BigCDNCo connects to BigCableCo, they need 50x100GE. It's actually cheaper to run the fiber between them at 10 locations for 5x100GE each than it is to run fiber from both of them to a switch, and have the switch providing vendor engineer the switch to that capacity. (Hint, running to the switch is 2x the fiber, plus switch ports.) On the other end of the spectrum, the guy who has 5Gbps of traffic can buy a 10GE into the switched exchange, have lots of headroom and connect to everyone with the same port. The truth of the matter is there are 40 players in the big pile, 15,000 providers in the small pile, and perhaps only 100 oddballs between the two. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From bjorn at mork.no Mon May 23 13:34:55 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 23 May 2016 15:34:55 +0200 Subject: IPv6 Residential Deployment Survey In-Reply-To: <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> (John Curran's message of "Sun, 22 May 2016 04:32:11 +0000") References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> Message-ID: <877feksxs0.fsf@nemi.mork.no> Got as far as the second page, where I was met by the question "What technology is used for the customer link ? Choose one of the following answers " Come on... One technology per ISP? In what world is that? Bj?rn John Curran writes: > NANOGers - > > If you are providing residential Internet service with IPv6 (or > are a customer of same), please take a moment to complete > Jordi?s survey - this will help provide insight into the actual > technical practices being used in residential IPv6 deployment. > > More details in attached email - Thanks! > /John > > > Begin forwarded message: > > From: John Curran > > Subject: [arin-ppml] IPv6 Residential Deployment Survey > Date: May 22, 2016 at 6:24:17 AM GMT+2 > To: ARIN PPML > > > Folks - > > Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 deployment > in residential Internet service. Having insight into the various practices that > are in use may help to inform IPv6 number resource policy development, and > thus I ask that you take a moment to complete the survey if you are providing > such services (whether production or trial basis.) > > Jordi notes - > > "The results will be published and updated every month or so - > No personal data will be published. > > (If you know your network, it takes less than 2 minutes to complete it) > The survey can be responded even if is not yet a commercial service, > and customers can also respond, not just the ISP. However, to avoid > duplicate data, make sure to include the country and ISP name.? > > The IPv6 Residential Deployment Survey may be found here - > > > > Thanks! > /John > > John Curran > President and CEO > ARIN From eric at emj.se Sat May 21 13:03:41 2016 From: eric at emj.se (=?UTF-8?Q?Eric_Lindsj=c3=b6?=) Date: Sat, 21 May 2016 15:03:41 +0200 Subject: SNMP "bridging"/proxy? In-Reply-To: References: Message-ID: <57405CAD.4070104@emj.se> Hi Nathan, You should probably write a cacti script to ingest the data instead of this SNMP proxy thing. Writing scripts to ingest data into cacti is simple, you just need to output the values you want in key: value format and then do some clicking in cacti. There are good docs for how to do this. -- emj On 05/21/2016 08:11 AM, Nathan Anderson wrote: > Hey, thanks guys! I had never really looked that deeply into Net-SNMP and had only ever installed it either to use as a client (snmpget/snmpwalk) or a basic agent w/ standard MIBs for the host it's running on, so I was unaware of its extensibility. And it even looks like it ships with a Perl module. That sounds like a perfect solution; thanks for pointing me in the right direction. > > -- Nathan From jordi.palet at consulintel.es Sun May 22 12:36:25 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 22 May 2016 14:36:25 +0200 Subject: IPv6 Residential Deployment Survey Message-ID: Definitively, please respond to the survey. The point here is to be able to tell the ISPs, ?hey why are you using /64 instead of /48 (or /56). You know that with /64, your customers can?t have different subnets in their network, for example an /64 in the SSID for guest, or different /64 for the home office and the kids ? You know that homenet will not work if you provide something smaller than /56 ? You know that only x% of ISP are using /64?, etc. ? Ideally the survey should be responded by the ISPs, but we know that many of them (even if they don?t need to provide personal data) will not do it, so customers are able to respond as well. We will then manually try to avoid duplicate data from the same ISP, to avoid having a distorsion in the stats, or clarify the data if there are inconsistencies, etc. At the moment we got 225 responses (57 complete), most of them right now from RIPE NCC. Some people is not filling the ?complete? survey, they can come back later to complete it and click ?submit?, otherwise, we will manually ?close? the incomplete surveys and account only for the fields that have been submitted. Hopefully this community can help to increase the responses from ARIN members ! Thanks a lot ! Regards, Jordi > On May 22, 2016, at 9:04 AM, Majdi S. Abbas wrote: > > On Sun, May 22, 2016 at 04:32:11AM +0000, John Curran wrote: >> NANOGers - >> >> If you are providing residential Internet service with IPv6 (or >> are a customer of same), please take a moment to complete >> Jordi?s survey - this will help provide insight into the actual >> technical practices being used in residential IPv6 deployment. > > John, > > Allow me to suggest an additional survey: > > If you're a customer of a provider that currently provides > IPv6, and are not using it, please tell us why. > > In my case, on my consumer connection at home, I cannot utilize > IPv6 because my provider does not wish to provide more than a /64 to > a subscriber, and my equipment vendor (Juniper) does not support DHCPv6 > PD delegation hints, so I'll always get a /64 that does not scale well > to the >1 subnet I have internally. (4: Managment, Media, Guest, & > Internal.) Majdi - You should definitely complete the survey accordingly? that?s the kind of technical feedback that I believe Jordi is trying to collect! /John From jordi.palet at consulintel.es Sun May 22 18:37:44 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 22 May 2016 20:37:44 +0200 Subject: IPv6 Residential Deployment Survey In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> Message-ID: <6B4F2DF5-0373-4C08-AF2D-BEC25377EFA2@consulintel.es> Hi Aaron, Sorry to heard that. Is the first report I got about this problem (253 responses already and many using Chrome), so may be specific to Chrome+Linux, not sure if you have been able to try with another browser or OS. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de "Aaron C. de Bruyn" Responder a: Fecha: domingo, 22 de mayo de 2016, 20:15 Para: John Curran CC: NANOG Asunto: Re: IPv6 Residential Deployment Survey >The 'Next' button just keeps refreshing the initial page for me (Chrome, >Linux). > >I was hoping there was an option in the survey for "I contacted my local >monopoly^H^H^H^H^H provider, talked with their 'network guy' and asked >about IPv6. He said he'd heard about it, but they probably won't going to >even investigate it for 'a couple of years'". > >-A > >On Sat, May 21, 2016 at 9:32 PM, John Curran wrote: > >> NANOGers - >> >> If you are providing residential Internet service with IPv6 (or >> are a customer of same), please take a moment to complete >> Jordi?s survey - this will help provide insight into the actual >> technical practices being used in residential IPv6 deployment. >> >> More details in attached email - Thanks! >> /John >> >> >> Begin forwarded message: >> >> From: John Curran > >> Subject: [arin-ppml] IPv6 Residential Deployment Survey >> Date: May 22, 2016 at 6:24:17 AM GMT+2 >> To: ARIN PPML > >> >> Folks - >> >> Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 >> deployment >> in residential Internet service. Having insight into the various >> practices that >> are in use may help to inform IPv6 number resource policy development, >> and >> thus I ask that you take a moment to complete the survey if you are >> providing >> such services (whether production or trial basis.) >> >> Jordi notes - >> >> "The results will be published and updated every month or so - >> No personal data will be published. >> >> (If you know your network, it takes less than 2 minutes to >> complete it) >> The survey can be responded even if is not yet a commercial >> service, >> and customers can also respond, not just the ISP. However, to >> avoid >> duplicate data, make sure to include the country and ISP name.? >> >> The IPv6 Residential Deployment Survey may be found here - >> >> >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> > From jordi.palet at consulintel.es Sun May 22 20:41:47 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 22 May 2016 22:41:47 +0200 Subject: IPv6 Residential Deployment Survey In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <6B4F2DF5-0373-4C08-AF2D-BEC25377EFA2@consulintel.es> Message-ID: <8A8CB8F6-B64C-42D5-B266-4C25DAE60450@consulintel.es> Thanks a lot ? Saludos, Jordi -----Mensaje original----- De: "Aaron C. de Bruyn" Responder a: Fecha: domingo, 22 de mayo de 2016, 22:11 Para: Jordi Palet Martinez CC: John Curran , NANOG Asunto: Re: IPv6 Residential Deployment Survey >Did some digging, it's was being caused by a plugin. >Thanks, > >-A > > > >On Sun, May 22, 2016 at 11:37 AM, JORDI PALET MARTINEZ wrote: > >Hi Aaron, > >Sorry to heard that. Is the first report I got about this problem (253 responses already and many using Chrome), so may be specific to Chrome+Linux, not sure if you have been able to try with another browser or OS. > >Regards, >Jordi > > >-----Mensaje original----- >De: NANOG en nombre de "Aaron C. de Bruyn" >Responder a: >Fecha: domingo, 22 de mayo de 2016, 20:15 >Para: John Curran >CC: NANOG >Asunto: Re: IPv6 Residential Deployment Survey > >>The 'Next' button just keeps refreshing the initial page for me (Chrome, >>Linux). >> >>I was hoping there was an option in the survey for "I contacted my local >>monopoly^H^H^H^H^H provider, talked with their 'network guy' and asked >>about IPv6. He said he'd heard about it, but they probably won't going to >>even investigate it for 'a couple of years'". >> >>-A >> >>On Sat, May 21, 2016 at 9:32 PM, John Curran wrote: >> >>> NANOGers - >>> >>> If you are providing residential Internet service with IPv6 (or >>> are a customer of same), please take a moment to complete >>> Jordi?s survey - this will help provide insight into the actual >>> technical practices being used in residential IPv6 deployment. >>> >>> More details in attached email - Thanks! >>> /John >>> >>> >>> Begin forwarded message: >>> >>> From: John Curran > >>> Subject: [arin-ppml] IPv6 Residential Deployment Survey >>> Date: May 22, 2016 at 6:24:17 AM GMT+2 >>> To: ARIN PPML > >>> >>> Folks - >>> >>> Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 >>> deployment >>> in residential Internet service. Having insight into the various >>> practices that >>> are in use may help to inform IPv6 number resource policy development, >>> and >>> thus I ask that you take a moment to complete the survey if you are >>> providing >>> such services (whether production or trial basis.) >>> >>> Jordi notes - >>> >>> "The results will be published and updated every month or so - >>> No personal data will be published. >>> >>> (If you know your network, it takes less than 2 minutes to >>> complete it) >>> The survey can be responded even if is not yet a commercial >>> service, >>> and customers can also respond, not just the ISP. However, to >>> avoid >>> duplicate data, make sure to include the country and ISP name.? >>> >>> The IPv6 Residential Deployment Survey may be found here - >>> >>> >>> >>> Thanks! >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >> > > > > > > > > > > From jordi.palet at consulintel.es Mon May 23 13:50:14 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 23 May 2016 15:50:14 +0200 Subject: IPv6 Residential Deployment Survey In-Reply-To: <877feksxs0.fsf@nemi.mork.no> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <877feksxs0.fsf@nemi.mork.no> Message-ID: <0929CF70-1F42-4474-8283-F5150470844B@consulintel.es> Hi, The intend is to make the survey simple, so in that case, you have two choices: 1) The same IPv6 services by means of DSL and FTTH (example), then you can use ?other? and indicate that. 2) Different IPv6 services with different access technology, then you better fill one survey for each technology. After initial responses in a ?smaller? survey via simple email, it was considered that case 2 is most common, so I didn't considered, to simplify stats, to be able to choose simultaneously several technologies. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Bj?rn Mork Organizaci?n: m Responder a: Fecha: lunes, 23 de mayo de 2016, 15:34 Para: John Curran CC: NANOG Asunto: Re: IPv6 Residential Deployment Survey >Got as far as the second page, where I was met by the question > > "What technology is used for the customer link ? > Choose one of the following answers " > >Come on... One technology per ISP? In what world is that? > > > >Bj?rn > > > > >John Curran writes: > >> NANOGers - >> >> If you are providing residential Internet service with IPv6 (or >> are a customer of same), please take a moment to complete >> Jordi?s survey - this will help provide insight into the actual >> technical practices being used in residential IPv6 deployment. >> >> More details in attached email - Thanks! >> /John >> >> >> Begin forwarded message: >> >> From: John Curran > >> Subject: [arin-ppml] IPv6 Residential Deployment Survey >> Date: May 22, 2016 at 6:24:17 AM GMT+2 >> To: ARIN PPML > >> >> Folks - >> >> Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 deployment >> in residential Internet service. Having insight into the various practices that >> are in use may help to inform IPv6 number resource policy development, and >> thus I ask that you take a moment to complete the survey if you are providing >> such services (whether production or trial basis.) >> >> Jordi notes - >> >> "The results will be published and updated every month or so - >> No personal data will be published. >> >> (If you know your network, it takes less than 2 minutes to complete it) >> The survey can be responded even if is not yet a commercial service, >> and customers can also respond, not just the ISP. However, to avoid >> duplicate data, make sure to include the country and ISP name.? >> >> The IPv6 Residential Deployment Survey may be found here - >> >> >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN > From morrowc.lists at gmail.com Mon May 23 14:14:13 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 May 2016 10:14:13 -0400 Subject: IPv6 Residential Deployment Survey In-Reply-To: <877feksxs0.fsf@nemi.mork.no> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <877feksxs0.fsf@nemi.mork.no> Message-ID: On Mon, May 23, 2016 at 9:34 AM, Bj?rn Mork wrote: > Got as far as the second page, where I was met by the question > > "What technology is used for the customer link ? > Choose one of the following answers " > > Come on... One technology per ISP? In what world is that? > > ?isn't this one answer stream per individual? so YOUR link at YOUR home is X-type. YOUR link at YOUR office/coffee-shop could be Y-type. you just need to answer the survey a few times...? From spano at datacast.it Fri May 20 15:41:33 2016 From: spano at datacast.it (=?utf-8?Q?Giuseppe_Span=C3=B2_-_Datacast_Srl?=) Date: Fri, 20 May 2016 17:41:33 +0200 Subject: Need BGP route check In-Reply-To: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> References: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> Message-ID: Here you are with our point of view (Italy - AS200873) BGP routing table entry for 129.77.0.0/16, version 147288840 Paths: (1 available, best #1, table default) Advertised to update-groups: 3 28716 6939 46887 14607 14607, (received & used) as you can see we receive it as generated by AS14607 with prepend. BR G. Spano' Giuseppe Span? Datacast S.r.l. - Consulenze e servizi tecnici V.le Brigate Partigiane 12/15 16129 Genova T. +39 346 6693932 spano at datacast.it > Il giorno 20 mag 2016, alle ore 17:31, Matthew Huff ha scritto: > > One of our upstreams is apparently having problems, although they don't appear to know about it. I've seen an alert at BGPmon.net about our prefixes being withdrawn, and I can't locate our prefixes through that provider on any routeviews. Can someone check to see what ASPATHS you are seeing for our prefixes? > > 129.77.0.0/16 > 2620:0:2810::/48 > > We should be advertised via AS6128 and AS46887 > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > From nevin at yahoo-inc.com Sun May 22 19:55:31 2016 From: nevin at yahoo-inc.com (Nevin Gonsalves) Date: Sun, 22 May 2016 19:55:31 +0000 (UTC) Subject: LACP Frames / Level3 Transport References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Hi Nanog-ers, Hoping someone may have come across a similar issue. Has anyone ever seen a situation where maybe like a Level3 transport system could be possibly dropping LACP frames..? End point A -? tx and rx counts incrementing for LACP ?LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-0/0/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:6d:2a:c0 ? ? ? 127 ? ? ?56 ? ?16? ? ? et-0/0/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? 127 ? ? ?56 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx??? ? et-0/0/0.0 ? ? ? ? ? ? ?6925 ? ? ? ? ? ? ?6922 ? ? ? ? ? ?0 ? ? ? ? ? ?0 End Point B - no RX, partner macs are 0s.. ? LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-9/1/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:77:d6:c4 ? ? ? 127 ? ? ?68 ? ?16? ? ? et-9/1/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? ? 1 ? ? ?68 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx?? ? ? et-9/1/0.0 ? ? ? ? ? ? ? ? 0 ? ? ? ?6752 ? ? ? ? ? ?0 ? ? ? ? ? ?0? Link works fine otherwise outside the aggregate and w/o LACP. Any inputs will be greatly appreciated. thanks, -nevin From morrowc.lists at gmail.com Mon May 23 14:15:54 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 May 2016 10:15:54 -0400 Subject: IPv6 Residential Deployment Survey In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <877feksxs0.fsf@nemi.mork.no> Message-ID: On Mon, May 23, 2016 at 10:14 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > > > On Mon, May 23, 2016 at 9:34 AM, Bj?rn Mork wrote: > >> Got as far as the second page, where I was met by the question >> >> "What technology is used for the customer link ? >> Choose one of the following answers " >> >> Come on... One technology per ISP? In what world is that? >> >> > ?isn't this one answer stream per individual? so YOUR link at YOUR home is > X-type. > YOUR link at YOUR office/coffee-shop could be Y-type. > > you just need to answer the survey a few times...? > > ?ha! sorry... question 3: ?Pre-commercial/Commercial Service Is IPv6 already part of your commercial service ? "no" and question 4 is: "What ipv6 configuraiton for your WAN link?" err.. I said no to the previous question... From jordi.palet at consulintel.es Mon May 23 14:47:31 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 23 May 2016 16:47:31 +0200 Subject: IPv6 Residential Deployment Survey In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <877feksxs0.fsf@nemi.mork.no> Message-ID: This is done so if you are part of a trial can keep answering. Otherwise, no sense to keep going, I guess ? In other words, if you don?t offer IPv6 you must not answer to the survey ? Saludos, Jordi -----Mensaje original----- De: NANOG en nombre de Christopher Morrow Responder a: Fecha: lunes, 23 de mayo de 2016, 16:15 Para: Bj?rn Mork CC: John Curran , NANOG Asunto: Re: IPv6 Residential Deployment Survey >On Mon, May 23, 2016 at 10:14 AM, Christopher Morrow < >morrowc.lists at gmail.com> wrote: > >> >> >> On Mon, May 23, 2016 at 9:34 AM, Bj?rn Mork wrote: >> >>> Got as far as the second page, where I was met by the question >>> >>> "What technology is used for the customer link ? >>> Choose one of the following answers " >>> >>> Come on... One technology per ISP? In what world is that? >>> >>> >> ?isn't this one answer stream per individual? so YOUR link at YOUR home is >> X-type. >> YOUR link at YOUR office/coffee-shop could be Y-type. >> >> you just need to answer the survey a few times...? >> >> > >?ha! sorry... question 3: >?Pre-commercial/Commercial Service >Is IPv6 already part of your commercial service ? > >"no" > >and question 4 is: "What ipv6 configuraiton for your WAN link?" > >err.. I said no to the previous question... > From morrowc.lists at gmail.com Mon May 23 14:57:26 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 May 2016 10:57:26 -0400 Subject: IPv6 Residential Deployment Survey In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <877feksxs0.fsf@nemi.mork.no> Message-ID: On Mon, May 23, 2016 at 10:47 AM, JORDI PALET MARTINEZ < jordi.palet at consulintel.es> wrote: > This is done so if you are part of a trial can keep answering. Otherwise, > no sense to keep going, I guess ? > > In other words, if you don?t offer IPv6 you must not answer to the survey ? > > ?'don't offer' from the perspective of a client is really: "Did not get" i filled in the survey as a client of the ISP.? > Saludos, > Jordi > > > -----Mensaje original----- > De: NANOG en nombre de Christopher Morrow < > morrowc.lists at gmail.com> > Responder a: > Fecha: lunes, 23 de mayo de 2016, 16:15 > Para: Bj?rn Mork > CC: John Curran , NANOG > Asunto: Re: IPv6 Residential Deployment Survey > > >On Mon, May 23, 2016 at 10:14 AM, Christopher Morrow < > >morrowc.lists at gmail.com> wrote: > > > >> > >> > >> On Mon, May 23, 2016 at 9:34 AM, Bj?rn Mork wrote: > >> > >>> Got as far as the second page, where I was met by the question > >>> > >>> "What technology is used for the customer link ? > >>> Choose one of the following answers " > >>> > >>> Come on... One technology per ISP? In what world is that? > >>> > >>> > >> ?isn't this one answer stream per individual? so YOUR link at YOUR home > is > >> X-type. > >> YOUR link at YOUR office/coffee-shop could be Y-type. > >> > >> you just need to answer the survey a few times...? > >> > >> > > > >?ha! sorry... question 3: > >?Pre-commercial/Commercial Service > >Is IPv6 already part of your commercial service ? > > > >"no" > > > >and question 4 is: "What ipv6 configuraiton for your WAN link?" > > > >err.. I said no to the previous question... > > > > > > From owen at delong.com Mon May 23 16:50:34 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2016 09:50:34 -0700 Subject: Question on peering strategies In-Reply-To: <574152C2.4050209@netassist.ua> References: <574152C2.4050209@netassist.ua> Message-ID: As mentioned by others, they do exist, but usually not for exactly the reason you state. In most cases, peers go to PNI instead of peering via the exchange when it does not make sense to grow laterally at the exchange for significant bilateral traffic. It?s much less expensive to get a cross-connect from my router to your router than for both of us to add a cross-connect to the exchange and each pay for an additional exchange port. Example: If I have 12.5 gigs of traffic to the exchange and 8 gigs of that is to autonomous system X while the remaining 4.5 G goes to random other peers, then it makes much more sense for both X and I to connect directly (PNI) than for each of us to order an additional exchange port to support that traffic. Owen > On May 21, 2016, at 23:33 , Max Tulyev wrote: > > Hi All, > > I wonder why a "VLAN exchange" does not exists. Or I do not know any? > > In my understanding it should be a switch, and people connected can > easily order a private VLAN between each other (or to private group) > through some kind of web interface. > > That should be a more easy and much less expensive way for private > interconnects than direct wires. > > On 16.05.16 20:46, Reza Motamedi wrote: >> Dear Nanogers, >> >> I have a question about common/best network interconnection practices. >> Assume that two networks (let's refer to them as AS-a and AS-b) are present >> in a colocation facility say Equinix LA. As many of you know, Equininx runs >> an IXP in LA as well. So AS-as and AS-b can interconnct >> 1) using private cross-connect >> 2) through the public IXP's switching fabric. >> Is it a common/good practice for the two networks to establish connections >> both through the IXP and also using a private cross-connect? >> >> I was thinking considering the cost of cross-connects (my understanding is >> that the colocation provider charges the customers for each cross-connect >> in addition to the rent of the rack or cage or whatever), it would not be >> economically reasonable to have both. Although, if the cross-connect is the >> primary method of interconnection, and the IXP provides a router-server the >> public-peering over IXP would essentially be free. So it might makes sense >> to assume that for the private cross-connect, there exists a back-up >> connection though the IXP. Anyway, I guess some discussion may give more >> insight about which one is more reasonable to assume and do. >> >> Now my last question is that if the two connections exist (one private >> cross-connect and another back-up through the IXP), what are the chances >> that periodically launched traceroutes that pass the inter-AS connection in >> that colo see both types of connection in a week. I guess what I'm asking >> is how often back-up routes are taken? Can the networks do load balancing >> on the two connection and essentially use them as primary routes? >> >> Best Regards >> Reza Motamedi (R.M) >> Graduate Research Fellow >> Oregon Network Research Group >> Computer and Information Science >> University of Oregon >> From motamedi at cs.uoregon.edu Mon May 23 17:53:58 2016 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Mon, 23 May 2016 10:53:58 -0700 Subject: Question on peering strategies In-Reply-To: References: <574152C2.4050209@netassist.ua> Message-ID: I'm glad we are having this discussion. I want to clarify something, since I'm not sure I'm following the terminology. What Max referred to as "VLAN exchange" is what Equinix markets as "*private VLAN"*, right? I just copy-pasted a portion of Equinix's IX brochure that covers the services that they offer [ http://www.equinix.com/resources/data-sheets/equinix-internet-exchange/] Standard Equinix Internet Exchange Features ? Public VLAN ? offers access to all peering participants ? Supports industry standard IEEE 802.1Q trunking encapsulation ? Redundant MLPE route servers at each IX Point enabling efficient open peering ? *Private VLAN* (Required: Unicast Peering VLAN enabled) ? create a private broadcast domain over the public switched infrastructure that can be used for direct bi-lateral peering or to create a community of interest My question is what is the point of having such an option for peering? I understand the argument that Owen and Leo have, which is to move the bigger portion of traffic away from the IX fabric and keep the IX for smaller flows. but why would a pair of networks want a private point-to-point connection on a shared switching fabric. Is this just because that shared fabric has geographical reach, as in the case of IXReach? I also see that links provided in this discussion show Europe based networks that are using this peering type more often. Is this widely accepted that US market is totally different from Europe? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Mon, May 23, 2016 at 9:50 AM, Owen DeLong wrote: > As mentioned by others, they do exist, but usually not for exactly the > reason you state. > > In most cases, peers go to PNI instead of peering via the exchange when it > does not make > sense to grow laterally at the exchange for significant bilateral traffic. > It?s much > less expensive to get a cross-connect from my router to your router than > for both of > us to add a cross-connect to the exchange and each pay for an additional > exchange port. > > Example: If I have 12.5 gigs of traffic to the exchange and 8 gigs of that > is to > autonomous system X while the remaining 4.5 G goes to random other peers, > then it > makes much more sense for both X and I to connect directly (PNI) than for > each of > us to order an additional exchange port to support that traffic. > > Owen > > > On May 21, 2016, at 23:33 , Max Tulyev wrote: > > > > Hi All, > > > > I wonder why a "VLAN exchange" does not exists. Or I do not know any? > > > > In my understanding it should be a switch, and people connected can > > easily order a private VLAN between each other (or to private group) > > through some kind of web interface. > > > > That should be a more easy and much less expensive way for private > > interconnects than direct wires. > > > > On 16.05.16 20:46, Reza Motamedi wrote: > >> Dear Nanogers, > >> > >> I have a question about common/best network interconnection practices. > >> Assume that two networks (let's refer to them as AS-a and AS-b) are > present > >> in a colocation facility say Equinix LA. As many of you know, Equininx > runs > >> an IXP in LA as well. So AS-as and AS-b can interconnct > >> 1) using private cross-connect > >> 2) through the public IXP's switching fabric. > >> Is it a common/good practice for the two networks to establish > connections > >> both through the IXP and also using a private cross-connect? > >> > >> I was thinking considering the cost of cross-connects (my understanding > is > >> that the colocation provider charges the customers for each > cross-connect > >> in addition to the rent of the rack or cage or whatever), it would not > be > >> economically reasonable to have both. Although, if the cross-connect is > the > >> primary method of interconnection, and the IXP provides a router-server > the > >> public-peering over IXP would essentially be free. So it might makes > sense > >> to assume that for the private cross-connect, there exists a back-up > >> connection though the IXP. Anyway, I guess some discussion may give more > >> insight about which one is more reasonable to assume and do. > >> > >> Now my last question is that if the two connections exist (one private > >> cross-connect and another back-up through the IXP), what are the chances > >> that periodically launched traceroutes that pass the inter-AS > connection in > >> that colo see both types of connection in a week. I guess what I'm > asking > >> is how often back-up routes are taken? Can the networks do load > balancing > >> on the two connection and essentially use them as primary routes? > >> > >> Best Regards > >> Reza Motamedi (R.M) > >> Graduate Research Fellow > >> Oregon Network Research Group > >> Computer and Information Science > >> University of Oregon > >> > > From sotnickd-nanog at ddv.com Mon May 23 17:59:27 2016 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Mon, 23 May 2016 10:59:27 -0700 Subject: Need Comcast IPv6 routing assistance please Message-ID: Hello NANOG, Could someone from Comcast IPv6 routing team please contact me directly? I am both a business and residential comcast customer and my employer is a Level(3) HSIP customer at multiple sites. I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services in Northern CA and Pixar (Level 3 customer) also in Northern CA. I have ticket open with Level (3) but the problem appears to be on Comcast's network. Sample trace: My traceroute [v0.85] ipv6testhost.ddv.com (::) Mon May 23 10:56:05 2016 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2601:647:280:23::1 0.0% 464 0.6 0.4 0.3 8.7 0.4 2. 2001:558:4000:3d::1 0.2% 463 13.0 10.3 8.2 27.4 2.1 3. te-0-7-0-5-sur03.sanrafael.ca.sfba.comcast.net 10.2% 463 9.6 10.7 8.5 34.8 2.4 4. be-207-rar01.rohnertpr.ca.sfba.comcast.net 44.7% 463 10.6 11.7 9.4 25.9 2.1 5. he-0-18-0-0-ar01.santaclara.ca.sfba.comcast.net 51.6% 463 15.2 14.1 12.0 26.2 1.9 6. 2001:1900:4:3::439 46.0% 463 13.3 14.4 11.8 50.2 3.6 7. vl-80.edge1.SanJose1.Level3.net 44.9% 463 12.1 13.9 11.7 28.5 2.3 8. vl-4045.edge5.LosAngeles.Level3.net 45.4% 463 21.2 21.5 19.2 39.4 2.6 9. vl-4044.bar1.LasVegas1.Level3.net 46.4% 463 24.9 27.7 24.4 88.3 6.8 10. vl-5.car1.LasVegas1.Level3.net 46.2% 463 104.3 46.3 24.5 318.2 48.0 11. PIXAR-ANIMA.car1.LasVegas1.Level3.net 44.9% 463 27.6 27.4 25.0 37.7 2.1 12. 2620:79:0:b04d::249 45.1% 463 46.4 48.9 46.0 114.2 4.9 And pings back from Pixar: Type escape sequence to abort.Sending 500, 100-byte ICMP Echos to 2601:647:0:1900:242:DEA1:FEC9:FFAE, timeout is 2 seconds: Packet sent with a source address of 2620:79:0:B04D::249%internet.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!..!.!!!!!!!!!!!!..!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!..!!!!!.!!!!!!!!!!!!!!!!!!!!!!!..!.!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!..!!.!!!!..!!!!!!!!!...!!!!!!!!!!!!!....!!!!!!!!..!!!!!!!!!....!!!!!..!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!Success rate is 90 percent (452/500), round-trip min/avg/max = 12/30/68 ms Any help really appreciated as you can imagine how painful remote access for our employees with Comcast connections into Pixar over IPv6 is right now. Many Thanks, David From marty at cloudflare.com Mon May 23 18:19:03 2016 From: marty at cloudflare.com (Marty Strong) Date: Mon, 23 May 2016 19:19:03 +0100 Subject: Question on peering strategies In-Reply-To: References: <574152C2.4050209@netassist.ua> Message-ID: The usefulness of an elastic fabric as far as I can see it are: - Can give you a private VLAN to some *cloud* providers that provide direct access to them in some other fashion than peering (assumedly for enterprises) - Is spread across multiple buildings across a metro area - Is elastic so can be divided between different services for different time periods In a traditional peering sense it doesn?t really offer much value. Just my two pence. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 23 May 2016, at 18:53, Reza Motamedi wrote: > > I'm glad we are having this discussion. > > I want to clarify something, since I'm not sure I'm following the > terminology. What Max referred to as "VLAN exchange" is what Equinix > markets as "*private VLAN"*, right? > I just copy-pasted a portion of Equinix's IX brochure that covers the > services that they offer [ > http://www.equinix.com/resources/data-sheets/equinix-internet-exchange/] > Standard Equinix Internet Exchange Features > ? Public VLAN ? offers access to all peering participants > ? Supports industry standard IEEE 802.1Q trunking encapsulation > ? Redundant MLPE route servers at each IX Point enabling efficient open > peering > ? *Private VLAN* (Required: Unicast Peering VLAN enabled) ? create a > private broadcast domain over the public switched infrastructure that can > be used for direct bi-lateral peering or to create a community of interest > > My question is what is the point of having such an option for peering? I > understand the argument that Owen and Leo have, which is to move the bigger > portion of traffic away from the IX fabric and keep the IX for smaller > flows. but why would a pair of networks want a private point-to-point > connection on a shared switching fabric. Is this just because that shared > fabric has geographical reach, as in the case of IXReach? > > I also see that links provided in this discussion show Europe based > networks that are using this peering type more often. Is this widely > accepted that US market is totally different from Europe? > > > Best Regards > Reza Motamedi (R.M) > Graduate Research Fellow > Oregon Network Research Group > Computer and Information Science > University of Oregon > > On Mon, May 23, 2016 at 9:50 AM, Owen DeLong wrote: > >> As mentioned by others, they do exist, but usually not for exactly the >> reason you state. >> >> In most cases, peers go to PNI instead of peering via the exchange when it >> does not make >> sense to grow laterally at the exchange for significant bilateral traffic. >> It?s much >> less expensive to get a cross-connect from my router to your router than >> for both of >> us to add a cross-connect to the exchange and each pay for an additional >> exchange port. >> >> Example: If I have 12.5 gigs of traffic to the exchange and 8 gigs of that >> is to >> autonomous system X while the remaining 4.5 G goes to random other peers, >> then it >> makes much more sense for both X and I to connect directly (PNI) than for >> each of >> us to order an additional exchange port to support that traffic. >> >> Owen >> >>> On May 21, 2016, at 23:33 , Max Tulyev wrote: >>> >>> Hi All, >>> >>> I wonder why a "VLAN exchange" does not exists. Or I do not know any? >>> >>> In my understanding it should be a switch, and people connected can >>> easily order a private VLAN between each other (or to private group) >>> through some kind of web interface. >>> >>> That should be a more easy and much less expensive way for private >>> interconnects than direct wires. >>> >>> On 16.05.16 20:46, Reza Motamedi wrote: >>>> Dear Nanogers, >>>> >>>> I have a question about common/best network interconnection practices. >>>> Assume that two networks (let's refer to them as AS-a and AS-b) are >> present >>>> in a colocation facility say Equinix LA. As many of you know, Equininx >> runs >>>> an IXP in LA as well. So AS-as and AS-b can interconnct >>>> 1) using private cross-connect >>>> 2) through the public IXP's switching fabric. >>>> Is it a common/good practice for the two networks to establish >> connections >>>> both through the IXP and also using a private cross-connect? >>>> >>>> I was thinking considering the cost of cross-connects (my understanding >> is >>>> that the colocation provider charges the customers for each >> cross-connect >>>> in addition to the rent of the rack or cage or whatever), it would not >> be >>>> economically reasonable to have both. Although, if the cross-connect is >> the >>>> primary method of interconnection, and the IXP provides a router-server >> the >>>> public-peering over IXP would essentially be free. So it might makes >> sense >>>> to assume that for the private cross-connect, there exists a back-up >>>> connection though the IXP. Anyway, I guess some discussion may give more >>>> insight about which one is more reasonable to assume and do. >>>> >>>> Now my last question is that if the two connections exist (one private >>>> cross-connect and another back-up through the IXP), what are the chances >>>> that periodically launched traceroutes that pass the inter-AS >> connection in >>>> that colo see both types of connection in a week. I guess what I'm >> asking >>>> is how often back-up routes are taken? Can the networks do load >> balancing >>>> on the two connection and essentially use them as primary routes? >>>> >>>> Best Regards >>>> Reza Motamedi (R.M) >>>> Graduate Research Fellow >>>> Oregon Network Research Group >>>> Computer and Information Science >>>> University of Oregon >>>> >> >> From nick at foobar.org Mon May 23 18:50:01 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 May 2016 19:50:01 +0100 Subject: Need Comcast IPv6 routing assistance please In-Reply-To: References: Message-ID: <574350D9.3080404@foobar.org> David Sotnick wrote: > I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services > in Northern CA and Pixar (Level 3 customer) also in Northern CA. I have > ticket open with Level (3) but the problem appears to be on Comcast's > network. 5/12 = 41.6% Someone's got a 12-way LAG / ECMP path with either 5 links broken or else with a hashing algorithm which is dumping your packets into one or more broken paths 5/12 of the time. Nick From nick at foobar.org Mon May 23 18:53:21 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 May 2016 19:53:21 +0100 Subject: Need Comcast IPv6 routing assistance please In-Reply-To: <574350D9.3080404@foobar.org> References: <574350D9.3080404@foobar.org> Message-ID: <574351A1.9040306@foobar.org> Nick Hilliard wrote: > David Sotnick wrote: >> I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services > > 5/12 = 41.6% and 5/12 != 46.1%, so scratch that. Anyway, the mtr output shows the likely position of where the problem is. Nick From jhellenthal at dataix.net Mon May 23 18:59:20 2016 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 23 May 2016 13:59:20 -0500 Subject: [Cox Communications] RFC1918 On WAN Interfaces Message-ID: <26B39710-A871-4799-B397-A5068725614A@dataix.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Could a clueful network operator from Cox contact me off list when they get a chance. Pertaining to RFC1918 appearing on our business WAN interfaces. Thanks - -- Jason Hellenthal JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXQ1MIAAoJEDLu+wRc4KcIAOoH/A+HtiKIACE2ec07feb6RWRJ ed0tzLjW8ahljw+NGHYtSR4MZ0UtylUL8/QFplu9fxjVl6A4hFlpXY0Jjvkyq5T1 3R9Ec5V8hvKdW3r0yzpV/QghBWFPeV49C44SmQgnMPmlMksurBCH91yuPytTW5fz JKIJtjjhaDn4Zyg6eSSsMp0ueyOk8N8nLouCkjF/bj3EHS6bkRWwQDR6KNCLjKdB yXAV7ZnrtyrcqZBzW+covFGmGA6yrFwTNe7FaMCYT4jsm8HhEC1afW639iBhcZ23 +XaJKTPZF97X1x8/6VtMoooDoN7cW7OMRzGhF16kycv6gWSIbsoNQuKuqoJxQj0= =31hc -----END PGP SIGNATURE----- From kemp at network-services.uoregon.edu Mon May 23 19:01:18 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 23 May 2016 12:01:18 -0700 Subject: Need BGP route check In-Reply-To: <7c3ad76ac9d342e8a70e807aa75d80e2@pur-vm-exch13n2.ox.com> References: <0965853c1cd849fc9a53d35c6300d7bd@pur-vm-exch13n2.ox.com> <20160520153832.GL22527@sizone.org> <7c3ad76ac9d342e8a70e807aa75d80e2@pur-vm-exch13n2.ox.com> Message-ID: <5743537E.2080109@network-services.uoregon.edu> Just to note, the route-views4 collector has a pretty diverse set of global multi-hop views. telnet://route-views4.routeviews.org/ http://www.routeviews.org/peers/peering-status.html http://www.routeviews.org/peers/route-views4.routeviews.org.txt John Kemp On 5/20/16 8:46 AM, Matthew Huff wrote: > Thanks, but I had checked a number of public looking glasses and only one had the 46887 path (HE.net), wanted a more global check. A number of responses are seeing only one or the other paths. The 14607 pre-pend is due to depref'ing 46887 earlier today when we had the instability. > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > >> -----Original Message----- >> From: Ken Chase [mailto:ken at sizone.org] >> Sent: Friday, May 20, 2016 11:39 AM >> To: Matthew Huff >> Cc: nanog at nanog.org >> Subject: Re: Need BGP route check >> >> $ telnet route-views.oregon-ix.net >> Username: rviews >> >> $ show ip bgp paths 14607 >> >> might help >> >> /kc >> >> >> On Fri, May 20, 2016 at 03:31:48PM +0000, Matthew Huff said: >> >One of our upstreams is apparently having problems, although they >> don't appear to know about it. I've seen an alert at BGPmon.net about >> our prefixes being withdrawn, and I can't locate our prefixes through >> that provider on any routeviews. Can someone check to see what ASPATHS >> you are seeing for our prefixes? >> > >> >129.77.0.0/16 >> >2620:0:2810::/48 >> > >> >We should be advertised via AS6128 and AS46887 >> > >> >---- >> >Matthew Huff???????????? | 1 Manhattanville Rd >> >Director of Operations???| Purchase, NY 10577 >> >OTA Management LLC?????? | Phone: 914-460-4039 >> >aim: matthewbhuff??????? | Fax:?? 914-694-5669 >> > >> > >> >> -- >> Ken Chase - ken at sizone.org Guelph Canada From eric.kuhnke at gmail.com Mon May 23 21:44:16 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 23 May 2016 14:44:16 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: <0lh9dojx56.fsf@wjh.hardakers.net> References: <0lh9dojx56.fsf@wjh.hardakers.net> Message-ID: Thinking of the recent conversation on ntp daemon precision and reliability here on nanog, reminded me of: https://www.pitt-pladdy.com/blog/_20140826-094101_0100_NTP_Monitoring_on_Cacti_over_SNMP/ There's a tiny shell script linked there on github which does nothing more than run "ntpq -p" on your ntpd and parse the results of the 9th and 10th columns (jitter an offset) into milliseconds. On a typical debian system you'll need to install the 'bc' package for command line calculations. Of course no need to use Cacti, though the XML template is ready to use. You can use the newly exposed OIDs via SNMP with opennms or some other charting/graphing system, or even something totally non RRA/RRDtool based such as collectd and a time series database for long term storage of data on a 60-second poller interval. Another thing you can do with 'extend' is monitor an openvpn daemon. There's no built in SNMP support in openvpn but it can be configured to listen for a management CLI on localhost. Run tiny shell, perl or python scripts that do something as simple as parse the openvpn-status.log, spit out the list of currently active clients, pipe that into a one line script with sed and "wc -l", feed the integer into a SNMP charting/monitoring system. On Mon, May 23, 2016 at 2:13 PM, Wes Hardaker wrote: > Eric Kuhnke writes: > > > http://www.adventuresinoss.com/2009/09/30/the-many-uses-of-net-snmp/ > > Ha! I've never seen that article, thanks for pointing it out. > > Note that the performance of Net-SNMP's extensibility mechanisms should > way into the decision. The fastest backend needs to be written in C, > and embedded perl is an easy second. Beyond that, pass_persist is > somewhere in the middle and pass/extend/other execs are the slowest > because of the need to exec a command for every incoming request which > is expensive. Great for bootstrapping and testing, but in the long run > look to the better coding solutions. > > Tutorials for most of these exist: > > http://www.net-snmp.org/wiki/index.php/Tutorials#Coding_Tutorials > > > [as a point of history: Net-SNMP has always been very extensible since > it was started based on my need to add extensibility to an agent way > back in 1995-ish in order to monitor some special cases on a map with HP > OV (as it was known back then)] > -- > Wes Hardaker > My Pictures: http://capturedonearth.com/ > My Thoughts: http://blog.capturedonearth.com/ > From eric.kuhnke at gmail.com Mon May 23 21:51:28 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 23 May 2016 14:51:28 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: <57405CAD.4070104@emj.se> References: <57405CAD.4070104@emj.se> Message-ID: This doesn't scale on a large cacti installation with hundreds of hosts and 60-second poller intervals. Cacti data input method scripts spawn a new php worker for each data acquisition target (they do NOT use the 'spine' SNMP poller). Exposing the data via SNMP on the host to be monitored distributes the CPU load individually onto each host (example: an 'extend' script in the snmpd.conf which runs "curl http://localhost/server-status" for apache2 status and parses the results) rather than centralizing it on the cacti host. This allows cacti or opennms or anything else to poll the hosts to be monitored via something that scales better than php script workers, using the 'spine' SNMP data acquisition method and the equivalent in other snmp polling platforms. On Sat, May 21, 2016 at 6:03 AM, Eric Lindsj? wrote: > Hi Nathan, > > You should probably write a cacti script to ingest the data instead of > this SNMP proxy thing. Writing scripts to ingest data into cacti is simple, > you just need to output the values you want in key: value format and then > do some clicking in cacti. There are good docs for how to do this. > > -- emj > > > On 05/21/2016 08:11 AM, Nathan Anderson wrote: > >> Hey, thanks guys! I had never really looked that deeply into Net-SNMP >> and had only ever installed it either to use as a client (snmpget/snmpwalk) >> or a basic agent w/ standard MIBs for the host it's running on, so I was >> unaware of its extensibility. And it even looks like it ships with a Perl >> module. That sounds like a perfect solution; thanks for pointing me in the >> right direction. >> >> -- Nathan >> > > From josh at kyneticwifi.com Mon May 23 21:58:25 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 23 May 2016 16:58:25 -0500 Subject: SNMP "bridging"/proxy? In-Reply-To: References: <57405CAD.4070104@emj.se> Message-ID: +1 On May 23, 2016 4:53 PM, "Eric Kuhnke" wrote: > This doesn't scale on a large cacti installation with hundreds of hosts and > 60-second poller intervals. Cacti data input method scripts spawn a new php > worker for each data acquisition target (they do NOT use the 'spine' SNMP > poller). > > Exposing the data via SNMP on the host to be monitored distributes the CPU > load individually onto each host (example: an 'extend' script in the > snmpd.conf which runs "curl http://localhost/server-status" for apache2 > status and parses the results) rather than centralizing it on the cacti > host. > > This allows cacti or opennms or anything else to poll the hosts to be > monitored via something that scales better than php script workers, using > the 'spine' SNMP data acquisition method and the equivalent in other snmp > polling platforms. > > > On Sat, May 21, 2016 at 6:03 AM, Eric Lindsj? wrote: > > > Hi Nathan, > > > > You should probably write a cacti script to ingest the data instead of > > this SNMP proxy thing. Writing scripts to ingest data into cacti is > simple, > > you just need to output the values you want in key: value format and then > > do some clicking in cacti. There are good docs for how to do this. > > > > -- emj > > > > > > On 05/21/2016 08:11 AM, Nathan Anderson wrote: > > > >> Hey, thanks guys! I had never really looked that deeply into Net-SNMP > >> and had only ever installed it either to use as a client > (snmpget/snmpwalk) > >> or a basic agent w/ standard MIBs for the host it's running on, so I was > >> unaware of its extensibility. And it even looks like it ships with a > Perl > >> module. That sounds like a perfect solution; thanks for pointing me in > the > >> right direction. > >> > >> -- Nathan > >> > > > > > From math at sizone.org Mon May 23 22:24:13 2016 From: math at sizone.org (Ken Chase) Date: Mon, 23 May 2016 18:24:13 -0400 Subject: Question on peering strategies In-Reply-To: References: <574152C2.4050209@netassist.ua> Message-ID: <20160523222413.GB30870@sizone.org> And what benefit is there to this 'public' vlan service? A shared vlan between all participants (with some well organized numbering/indexing scheme)? TorIX (Toronto) is about to have an AGM here and this VLAN thing which has been in the air for 3 years will certainly be brought up again. /kc On Mon, May 23, 2016 at 07:19:03PM +0100, Marty Strong via NANOG said: >The usefulness of an elastic fabric as far as I can see it are: > >- Can give you a private VLAN to some *cloud* providers that provide direct access to them in some other fashion than peering (assumedly for enterprises) >- Is spread across multiple buildings across a metro area >- Is elastic so can be divided between different services for different time periods > >In a traditional peering sense it doesn???t really offer much value. > >Just my two pence. > >Regards, >Marty Strong -- Ken Chase - Guelph Canada From jeffg at opennms.org Mon May 23 22:29:52 2016 From: jeffg at opennms.org (Jeff Gehlbach) Date: Mon, 23 May 2016 18:29:52 -0400 Subject: SNMP "bridging"/proxy? In-Reply-To: References: <57405CAD.4070104@emj.se> Message-ID: <787bc981-a25a-d67b-d2ec-0fab51cf1eca@opennms.org> On 05/23/2016 05:51 PM, Eric Kuhnke wrote: > Exposing the data via SNMP on the host to be monitored distributes the CPU > load individually onto each host So much this. Most importantly, it removes the fork/exec overhead from the monitoring server. > This allows cacti or opennms or anything else to poll the hosts to be > monitored via something that scales better than php script workers, using > the 'spine' SNMP data acquisition method and the equivalent in other snmp > polling platforms. Point of fact for OpenNMS users: all our collectors are in-process, so in cases where SNMP is impractical you can use the XML/JSON or JDBC or WS-Management collector and still achieve great scale with a single server. But SNMP still scales and interoperates like nothing else. -jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From colton.conor at gmail.com Tue May 24 04:06:40 2016 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 23 May 2016 23:06:40 -0500 Subject: LACP Frames / Level3 Transport In-Reply-To: <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Message-ID: What is performing the LACP? The Level3 transport system for the most part is purley optical, so I don't think it touches LACP. Did you check the hash values? On Sun, May 22, 2016 at 2:55 PM, Nevin Gonsalves via NANOG wrote: > Hi Nanog-ers, > Hoping someone may have come across a similar issue. Has anyone ever seen > a situation where maybe like a Level3 transport system could be possibly > dropping LACP frames..? > End point A - tx and rx counts incrementing for LACP > LACP info: Role System System Port Port > Port priority identifier priority > number key et-0/0/0.0 Actor 127 5c:45:27:6d:2a:c0 > 127 56 16 et-0/0/0.0 Partner 1 00:00:00:00:00:00 > 127 56 16 LACP Statistics: LACP Rx LACP Tx > Unknown Rx Illegal Rx et-0/0/0.0 6925 6922 > 0 0 > End Point B - no RX, partner macs are 0s.. > LACP info: Role System System Port Port > Port priority identifier priority > number key et-9/1/0.0 Actor 127 5c:45:27:77:d6:c4 > 127 68 16 et-9/1/0.0 Partner 1 00:00:00:00:00:00 > 1 68 16 LACP Statistics: LACP Rx LACP Tx > Unknown Rx Illegal Rx et-9/1/0.0 0 6752 > 0 0 > Link works fine otherwise outside the aggregate and w/o LACP. Any inputs > will be greatly appreciated. > thanks, > -nevin > From jared at puck.nether.net Tue May 24 06:51:00 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 May 2016 02:51:00 -0400 Subject: LACP Frames / Level3 Transport In-Reply-To: References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Message-ID: <77885102-DE54-45AF-9760-C6EA8DBD93D3@puck.nether.net> > On May 24, 2016, at 12:06 AM, Colton Conor wrote: > > What is performing the LACP? The Level3 transport system for the most part > is purley optical, so I don't think it touches LACP. Did you check the hash > values? I?ve seen optical transport gear be non-transparent in a few situations when using OTU2 vs OTU2e, but they turned out to be a bug. If a L2 platform is being used to front-end a router, you could be seeing slow protocols like CDP/LLDP/LACP being consumed by that switch. If you configure LLDP does it pass end-to-end? - Jared From mark.tinka at seacom.mu Tue May 24 06:58:13 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 24 May 2016 08:58:13 +0200 Subject: LACP Frames / Level3 Transport In-Reply-To: <77885102-DE54-45AF-9760-C6EA8DBD93D3@puck.nether.net> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> <77885102-DE54-45AF-9760-C6EA8DBD93D3@puck.nether.net> Message-ID: On 24/May/16 08:51, Jared Mauch wrote: > I?ve seen optical transport gear be non-transparent in a few situations when > using OTU2 vs OTU2e, but they turned out to be a bug. I've seen this as well, including in an SDH transport, where OSPF packets were being eaten (something Multicast-related). > If a L2 platform is > being used to front-end a router, you could be seeing slow protocols like > CDP/LLDP/LACP being consumed by that switch. If you configure LLDP does it > pass end-to-end? That's what I was thinking at first when I read the OP's post. If the circuit is being transported over MPLS or being fronted by an Ethernet switch, Level(3) would have to tunnel Layer 2 protocols in order to support your LACP frames across the pw. Mark. From marty at cloudflare.com Tue May 24 07:39:21 2016 From: marty at cloudflare.com (Marty Strong) Date: Tue, 24 May 2016 08:39:21 +0100 Subject: Question on peering strategies In-Reply-To: <20160523222413.GB30870@sizone.org> References: <574152C2.4050209@netassist.ua> <20160523222413.GB30870@sizone.org> Message-ID: Typically you would use a private VLAN between you and another participant in order to connect to them separately from the public peering VLAN. You would do this instead of a PNI in a situation where you?re in a different building from the other participant making a direct fibre more expensive than the value it would bring. A public VLAN is essentially the peering VLAN anyway, so an all participants VLAN would be a little pointless. Perhaps a VLAN shared between a couple of members *may* be useful depending on those members? use cases, although I can?t think of one off the top of my head. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 23 May 2016, at 23:24, Ken Chase wrote: > > And what benefit is there to this 'public' vlan service? A shared vlan between > all participants (with some well organized numbering/indexing scheme)? > > TorIX (Toronto) is about to have an AGM here and this VLAN thing which has > been in the air for 3 years will certainly be brought up again. > > /kc > > > On Mon, May 23, 2016 at 07:19:03PM +0100, Marty Strong via NANOG said: >> The usefulness of an elastic fabric as far as I can see it are: >> >> - Can give you a private VLAN to some *cloud* providers that provide direct access to them in some other fashion than peering (assumedly for enterprises) >> - Is spread across multiple buildings across a metro area >> - Is elastic so can be divided between different services for different time periods >> >> In a traditional peering sense it doesn???t really offer much value. >> >> Just my two pence. >> >> Regards, >> Marty Strong > > -- > Ken Chase - Guelph Canada From jared at puck.nether.net Tue May 24 08:03:02 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 May 2016 04:03:02 -0400 Subject: Question on peering strategies In-Reply-To: References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> Message-ID: <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> > On May 16, 2016, at 4:29 PM, Baldur Norddahl wrote: > > Router ports are expensive, so even if cross connects were free, you would > still use the public switch fabric until you reach a traffic level that > justifies a direct connection. The point of having a IX switch is that you > can connect to many others with just one single router port. > The cost of an IX can be quite expensive actually. If you look at the RIPE presentations from this week, there are stealth routing hijacks that come from promiscuous peering as well as just the flat economics of connecting with a 10GE or 100GE interface and the cost per gigabit you assign to the IX port. These are flat rate ports, unlike transit that may offer you a price and commit rates that allow you to reach everyone vs those just at the IX. I?m hoping I don?t get in trouble for sharing this, but this collaboration exists for europe on peering costs which are normalized in euro cents per megabit. https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 - Jared From rea+nanog at grid.kiae.ru Tue May 24 09:48:28 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Tue, 24 May 2016 12:48:28 +0300 Subject: LACP Frames / Level3 Transport In-Reply-To: <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160524094828.GC14947void.CODELABS.ru@void.CODELABS.ru> Nevin, good day. Sun, May 22, 2016 at 07:55:31PM +0000, Nevin Gonsalves via NANOG wrote: > Hoping someone may have come across a similar issue. Has anyone ever > seen a situation where maybe like a Level3 transport system could be > possibly dropping LACP frames..? > End point A -? tx and rx counts incrementing for LACP > ?LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-0/0/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:6d:2a:c0 ? ? ? 127 ? ? ?56 ? ?16? ? ? et-0/0/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? 127 ? ? ?56 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx??? ? et-0/0/0.0 ? ? ? ? ? ? ?6925 ? ? ? ? ? ? ?6922 ? ? ? ? ? ?0 ? ? ? ? ? ?0 > End Point B - no RX, partner macs are 0s.. > ? LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-9/1/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:77:d6:c4 ? ? ? 127 ? ? ?68 ? ?16? ? ? et-9/1/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? ? 1 ? ? ?68 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx?? ? ? et-9/1/0.0 ? ? ? ? ? ? ? ? 0 ? ? ? ?6752 ? ? ? ? ? ?0 ? ? ? ? ? ?0? > Link works fine otherwise outside the aggregate and w/o LACP. Any > inputs will be greatly appreciated. Cisco Q-in-Q implementation in some configurations (details are blurry, since our provider turned to X-connect quite fast). Also VPLS implementation in (older) EXOS releases (Extreme Networks), https://gtacknowledge.extremenetworks.com/articles/Solution/Layer-2-Control-packets-like-STP-LACP-EDP-etc-are-not-passing-through-VPLS -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From maxtul at netassist.ua Tue May 24 10:11:46 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 24 May 2016 13:11:46 +0300 Subject: Question on peering strategies In-Reply-To: <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> Message-ID: <574428E2.2060405@netassist.ua> If you dig into hijacking topic more, you will see that hijacks through Tier1 is same or even more popular than through IXes. And if someone want to make me a transit offer for the price of DE-CIX (I do not even ask the price of DTEL-IX peering ;) ) - please, contact me off-list, I will be really happy. On 24.05.16 11:03, Jared Mauch wrote: > >> On May 16, 2016, at 4:29 PM, Baldur Norddahl wrote: >> >> Router ports are expensive, so even if cross connects were free, you would >> still use the public switch fabric until you reach a traffic level that >> justifies a direct connection. The point of having a IX switch is that you >> can connect to many others with just one single router port. >> > > > The cost of an IX can be quite expensive actually. If you look at the RIPE > presentations from this week, there are stealth routing hijacks that come from > promiscuous peering as well as just the flat economics of connecting with a 10GE > or 100GE interface and the cost per gigabit you assign to the IX port. These > are flat rate ports, unlike transit that may offer you a price and commit rates > that allow you to reach everyone vs those just at the IX. > > I?m hoping I don?t get in trouble for sharing this, but this collaboration exists > for europe on peering costs which are normalized in euro cents per megabit. > > https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0 > > - Jared > From marco at paesani.it Tue May 24 10:13:18 2016 From: marco at paesani.it (Marco Paesani) Date: Tue, 24 May 2016 12:13:18 +0200 Subject: PeeringDB ? Message-ID: Whats happened totady at PeeringDB web site ? Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From jared at puck.nether.net Tue May 24 10:19:23 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 May 2016 06:19:23 -0400 Subject: Question on peering strategies In-Reply-To: <574428E2.2060405@netassist.ua> References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> <574428E2.2060405@netassist.ua> Message-ID: > On May 24, 2016, at 6:11 AM, Max Tulyev wrote: > > If you dig into hijacking topic more, you will see that hijacks through > Tier1 is same or even more popular than through IXes. You may not have a view into that you?re being hijacked and used to send SPAM for example: https://ripe72.ripe.net/presentations/45-Invisible_Hijacking.pdf Their space was hijacked and announced facing Yahoo. I?m hoping that Yahoo is now feeding public route views services as a method to help with detection. Same goes for Microsoft and Google and other e-mail providers. Some sunlight here would help avoid similar localized hijacks. > And if someone want to make me a transit offer for the price of DE-CIX > (I do not even ask the price of DTEL-IX peering ;) ) - please, contact > me off-list, I will be really happy. Pricing obviously varies based on location and a few other criteria, but you should be shopping if this is a major part of your business. - Jared From marty at cloudflare.com Tue May 24 10:21:03 2016 From: marty at cloudflare.com (Marty Strong) Date: Tue, 24 May 2016 11:21:03 +0100 Subject: PeeringDB ? In-Reply-To: References: Message-ID: https://twitter.com/PeeringDB/status/735026726053531649 Not sure it?s known yet :D Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 24 May 2016, at 11:13, Marco Paesani wrote: > > Whats happened totady at PeeringDB web site ? > Kind regards, > > Marco Paesani > > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it From job at instituut.net Tue May 24 10:22:41 2016 From: job at instituut.net (Job Snijders) Date: Tue, 24 May 2016 12:22:41 +0200 Subject: PeeringDB ? In-Reply-To: References: Message-ID: <20160524102241.GJ81971@Vurt.local> Hi Marco, On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: > Whats happened totady at PeeringDB web site ? We ran out of peerings, but as we speak our service provider is printing new ones ;-) In all seriousness: our SP has issues with a storage array. The staff is aware and they are hard working to restore services as soon as possible. We'll post updates as they become available to the pdb-tech at lists.peeringdb.com list. Kind regards, Job From John_Brzozowski at Cable.Comcast.com Tue May 24 10:23:44 2016 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Tue, 24 May 2016 10:23:44 +0000 Subject: Need Comcast IPv6 routing assistance please Message-ID: Regarding the thread: http://mailman.nanog.org/pipermail/nanog/2016-May/085878.html David, I looked around CA and it looks like some customers are provisioned with two delegated IPv6 prefixes. We had an issue a week or so back that we believe was corrected. If you wish contact me off list. Before we look to see if there are larger routing issue we should make sure you have one and only one active delegated IPv6 prefix. From my end it looks like you may have two. Thanks, John +1-484-962-0060 From maxtul at netassist.ua Tue May 24 10:29:28 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 24 May 2016 13:29:28 +0300 Subject: Question on peering strategies In-Reply-To: References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> <574428E2.2060405@netassist.ua> Message-ID: <57442D08.1040506@netassist.ua> I'm right here at RIPE 72 now, so I saw it of course ;) The problem is not peering itself, but more general problem of filtering nets, and it was told in the presentation. On 24.05.16 13:19, Jared Mauch wrote: > >> On May 24, 2016, at 6:11 AM, Max Tulyev wrote: >> >> If you dig into hijacking topic more, you will see that hijacks through >> Tier1 is same or even more popular than through IXes. > > You may not have a view into that you?re being hijacked and used to send > SPAM for example: > > https://ripe72.ripe.net/presentations/45-Invisible_Hijacking.pdf > > Their space was hijacked and announced facing Yahoo. I?m hoping that > Yahoo is now feeding public route views services as a method to help > with detection. Same goes for Microsoft and Google and other e-mail > providers. Some sunlight here would help avoid similar localized hijacks. > >> And if someone want to make me a transit offer for the price of DE-CIX >> (I do not even ask the price of DTEL-IX peering ;) ) - please, contact >> me off-list, I will be really happy. > > Pricing obviously varies based on location and a few other criteria, but > you should be shopping if this is a major part of your business. > > - Jared > From marco at paesani.it Tue May 24 10:29:41 2016 From: marco at paesani.it (Marco Paesani) Date: Tue, 24 May 2016 12:29:41 +0200 Subject: PeeringDB ? In-Reply-To: <20160524102241.GJ81971@Vurt.local> References: <20160524102241.GJ81971@Vurt.local> Message-ID: Hi Job, thanks for prompt replay and info. Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it 2016-05-24 12:22 GMT+02:00 Job Snijders : > Hi Marco, > > On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: > > Whats happened totady at PeeringDB web site ? > > We ran out of peerings, but as we speak our service provider is printing > new ones ;-) > > In all seriousness: our SP has issues with a storage array. The staff is > aware and they are hard working to restore services as soon as possible. > We'll post updates as they become available to the > pdb-tech at lists.peeringdb.com list. > > Kind regards, > > Job > From contact at winterei.se Tue May 24 10:51:36 2016 From: contact at winterei.se (Paul S.) Date: Tue, 24 May 2016 19:51:36 +0900 Subject: Looking for a Singtel rep Message-ID: <144dc275-33a3-8811-7791-9ff1681c97aa@winterei.se> Hi guys, We're after a good Singapore Telecom (AS7473) sales rep. After some IP transit in the Singapore and Hong Kong markets. Anyone have details that you wouldn't mind passing along? Much appreciated! From jared at puck.nether.net Tue May 24 11:08:09 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 May 2016 13:08:09 +0200 Subject: Question on peering strategies In-Reply-To: <57442D08.1040506@netassist.ua> References: <74d0ce9924644bf3bd746019a6678e7a@exchange.broadaspect.local> <3F27E66E-6A0C-490D-A44F-AE99315F623C@puck.nether.net> <574428E2.2060405@netassist.ua> <57442D08.1040506@netassist.ua> Message-ID: <5A197FBD-9952-4ED9-9DC1-35681C216214@puck.nether.net> I disagree somewhat, without a view of how you are being hijacked there often can be no remediation. Yahoo for example provides no cloud services so you can't purchase a view of their routing by getting a VM. Jared Mauch > On May 24, 2016, at 12:29 PM, Max Tulyev wrote: > > I'm right here at RIPE 72 now, so I saw it of course ;) > > The problem is not peering itself, but more general problem of filtering > nets, and it was told in the presentation. > >> On 24.05.16 13:19, Jared Mauch wrote: >> >>> On May 24, 2016, at 6:11 AM, Max Tulyev wrote: >>> >>> If you dig into hijacking topic more, you will see that hijacks through >>> Tier1 is same or even more popular than through IXes. >> >> You may not have a view into that you?re being hijacked and used to send >> SPAM for example: >> >> https://ripe72.ripe.net/presentations/45-Invisible_Hijacking.pdf >> >> Their space was hijacked and announced facing Yahoo. I?m hoping that >> Yahoo is now feeding public route views services as a method to help >> with detection. Same goes for Microsoft and Google and other e-mail >> providers. Some sunlight here would help avoid similar localized hijacks. >> >>> And if someone want to make me a transit offer for the price of DE-CIX >>> (I do not even ask the price of DTEL-IX peering ;) ) - please, contact >>> me off-list, I will be really happy. >> >> Pricing obviously varies based on location and a few other criteria, but >> you should be shopping if this is a major part of your business. >> >> - Jared >> From job at instituut.net Tue May 24 11:43:42 2016 From: job at instituut.net (Job Snijders) Date: Tue, 24 May 2016 13:43:42 +0200 Subject: PeeringDB ? In-Reply-To: References: Message-ID: <20160524114342.GP81971@Vurt.local> On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: > Whats happened today at PeeringDB web site ? And PeeringDB is back in business! http://instituut.net/~job/screenshots/2f255c17a8aa9cb99121b448.png A post-mortem will be shared on the pdb-tech@ list later today. Kind regards, Job From nevin at yahoo-inc.com Tue May 24 12:39:03 2016 From: nevin at yahoo-inc.com (Nevin Gonsalves) Date: Tue, 24 May 2016 12:39:03 +0000 (UTC) Subject: LACP Frames / Level3 Transport In-Reply-To: <20160524094828.GC14947void.CODELABS.ru@void.CODELABS.ru> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> <20160524094828.GC14947void.CODELABS.ru@void.CODELABS.ru> Message-ID: <35834213.1429317.1464093543784.JavaMail.yahoo@mail.yahoo.com> Thanks all..! I just had to sit and trace all the cables to make sure the tx/rx lined up for the right circuits as well as hitting the right patch panel ports. Once all that got aligned nicely things started working magically.??thanks,-nevin On Tuesday, May 24, 2016 2:49 AM, Eygene Ryabinkin wrote: Nevin, good day. Sun, May 22, 2016 at 07:55:31PM +0000, Nevin Gonsalves via NANOG wrote: > Hoping someone may have come across a similar issue. Has anyone ever > seen a situation where maybe like a Level3 transport system could be > possibly dropping LACP frames..? > End point A -? tx and rx counts incrementing for LACP > ?LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-0/0/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:6d:2a:c0 ? ? ? 127 ? ? ?56 ? ?16? ? ? et-0/0/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? 127 ? ? ?56 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx??? ? et-0/0/0.0 ? ? ? ? ? ? ?6925 ? ? ? ? ? ? ?6922 ? ? ? ? ? ?0 ? ? ? ? ? ?0 > End Point B - no RX, partner macs are 0s.. > ? LACP info: ? ? ? ?Role ? ? System ? ? ? ? ? ? System ? ? ?Port ? ?Port ?Port?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?priority ? ? ? ? ?identifier ?priority ?number ? key?? ? ? et-9/1/0.0 ? ? Actor ? ? ? ?127 ?5c:45:27:77:d6:c4 ? ? ? 127 ? ? ?68 ? ?16? ? ? et-9/1/0.0 ? Partner ? ? ? ? ?1 ?00:00:00:00:00:00 ? ? ? ? 1 ? ? ?68 ? ?16? ? LACP Statistics: ? ? ? LACP Rx ? ? LACP Tx ? Unknown Rx ? Illegal Rx?? ? ? et-9/1/0.0 ? ? ? ? ? ? ? ? 0 ? ? ? ?6752 ? ? ? ? ? ?0 ? ? ? ? ? ?0? > Link works fine otherwise outside the aggregate and w/o LACP. Any > inputs will be greatly appreciated. Cisco Q-in-Q implementation in some configurations (details are blurry, since our provider turned to X-connect quite fast).? Also VPLS implementation in (older) EXOS releases (Extreme Networks), ? https://gtacknowledge.extremenetworks.com/articles/Solution/Layer-2-Control-packets-like-STP-LACP-EDP-etc-are-not-passing-through-VPLS -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From sotnickd-nanog at ddv.com Tue May 24 15:18:02 2016 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Tue, 24 May 2016 08:18:02 -0700 Subject: Need Comcast IPv6 routing assistance please In-Reply-To: References: Message-ID: Hi John, I have been working with Courtney Smith and a fix has been implemented. Apparently a bunch of new Level(3) peering circuits were turned up on 5/15 and that's when the chronic packet loss problem started for our users. I have not been informed of the details as to what was causing such packet loss (but I would love to know), but for now the problem is resolved. FWIW, this problem doesn't appear limited to the Northern CA region, as we have users in Seattle, WA (who VPN down to Northern CA), and their packet loss issues have also been resolved. I don't see two delegated prefixes and besides wouldn't that particular issue need to be present on all our users' Comcast connections in order for them *all* to have experienced the same packet loss? I think perhaps that's a red-herring. Cheers, David On Tue, May 24, 2016 at 3:23 AM, Brzozowski, John < John_Brzozowski at cable.comcast.com> wrote: > Regarding the thread: > > http://mailman.nanog.org/pipermail/nanog/2016-May/085878.html > > David, > > I looked around CA and it looks like some customers are provisioned with > two delegated IPv6 prefixes. We had an issue a week or so back that we > believe was corrected. If you wish contact me off list. > > Before we look to see if there are larger routing issue we should make > sure you have one and only one active delegated IPv6 prefix. From my end > it looks like you may have two. > > Thanks, > > John > +1-484-962-0060 > > > From Courtney_Smith at Cable.Comcast.com Mon May 23 18:56:37 2016 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Mon, 23 May 2016 18:56:37 +0000 Subject: Need Comcast IPv6 routing assistance please In-Reply-To: References: Message-ID: <6912FE40-942E-4839-A499-3EFA855A47D2@Cable.Comcast.com> Will get appropriate folks engaged. Thanks. -----Original Message----- From: NANOG on behalf of David Sotnick Date: Monday, May 23, 2016 at 1:59 PM To: "nanog at nanog.org" Subject: Need Comcast IPv6 routing assistance please Hello NANOG, Could someone from Comcast IPv6 routing team please contact me directly? I am both a business and residential comcast customer and my employer is a Level(3) HSIP customer at multiple sites. I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services in Northern CA and Pixar (Level 3 customer) also in Northern CA. I have ticket open with Level (3) but the problem appears to be on Comcast's network. Sample trace: My traceroute [v0.85] ipv6testhost.ddv.com (::) Mon May 23 10:56:05 2016 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2601:647:280:23::1 0.0% 464 0.6 0.4 0.3 8.7 0.4 2. 2001:558:4000:3d::1 0.2% 463 13.0 10.3 8.2 27.4 2.1 3. te-0-7-0-5-sur03.sanrafael.ca.sfba.comcast.net 10.2% 463 9.6 10.7 8.5 34.8 2.4 4. be-207-rar01.rohnertpr.ca.sfba.comcast.net 44.7% 463 10.6 11.7 9.4 25.9 2.1 5. he-0-18-0-0-ar01.santaclara.ca.sfba.comcast.net 51.6% 463 15.2 14.1 12.0 26.2 1.9 6. 2001:1900:4:3::439 46.0% 463 13.3 14.4 11.8 50.2 3.6 7. vl-80.edge1.SanJose1.Level3.net 44.9% 463 12.1 13.9 11.7 28.5 2.3 8. vl-4045.edge5.LosAngeles.Level3.net 45.4% 463 21.2 21.5 19.2 39.4 2.6 9. vl-4044.bar1.LasVegas1.Level3.net 46.4% 463 24.9 27.7 24.4 88.3 6.8 10. vl-5.car1.LasVegas1.Level3.net 46.2% 463 104.3 46.3 24.5 318.2 48.0 11. PIXAR-ANIMA.car1.LasVegas1.Level3.net 44.9% 463 27.6 27.4 25.0 37.7 2.1 12. 2620:79:0:b04d::249 45.1% 463 46.4 48.9 46.0 114.2 4.9 And pings back from Pixar: Type escape sequence to abort.Sending 500, 100-byte ICMP Echos to 2601:647:0:1900:242:DEA1:FEC9:FFAE, timeout is 2 seconds: Packet sent with a source address of 2620:79:0:B04D::249%internet.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!..!.!!!!!!!!!!!!..!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!..!!!!!.!!!!!!!!!!!!!!!!!!!!!!!..!.!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!..!!.!!!!..!!!!!!!!!...!!!!!!!!!!!!!....!!!!!!!!..!!!!!!!!!....!!!!!..!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!Success rate is 90 percent (452/500), round-trip min/avg/max = 12/30/68 ms Any help really appreciated as you can imagine how painful remote access for our employees with Comcast connections into Pixar over IPv6 is right now. Many Thanks, David From wjhns61 at hardakers.net Mon May 23 21:50:02 2016 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 23 May 2016 14:50:02 -0700 Subject: SNMP "bridging"/proxy? In-Reply-To: (Eric Kuhnke's message of "Fri, 20 May 2016 17:09:22 -0700") References: Message-ID: <0l4m9ojvg5.fsf@wjh.hardakers.net> Eric Kuhnke writes: > http://www.adventuresinoss.com/2009/09/30/the-many-uses-of-net-snmp/ Ha! I've never seen that article, thanks for pointing it out. Note that the performance of Net-SNMP's extensibility mechanisms should way into the decision. The fastest backend needs to be written in C, and embedded perl is an easy second. Beyond that, pass_persist is somewhere in the middle and pass/extend/other execs are the slowest because of the need to exec a command for every incoming request which is expensive. Great for bootstrapping and testing, but in the long run look to the better coding solutions. Tutorials for most of these exist: http://www.net-snmp.org/wiki/index.php/Tutorials#Coding_Tutorials [as a point of history: Net-SNMP has always been very extensible since it was started based on my need to add extensibility to an agent way back in 1995-ish in order to monitor some special cases on a map with HP OV (as it was known back then)] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ From laidlaw at consecro.com Tue May 24 04:29:52 2016 From: laidlaw at consecro.com (Rob Laidlaw) Date: Tue, 24 May 2016 04:29:52 +0000 Subject: LACP Frames / Level3 Transport In-Reply-To: References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Message-ID: Yes. Many vendors are using l2vpn/pseudo-wire services of one sort or another to provide circuits and most do not transport LACP by default. LACP uses slow-protocols address: https://wiki.wireshark.org/LinkAggregationControlProtocol If they are using ALU gear, they can enable this using the port command: configure port ethernet lacp-tunnel On Tue, May 24, 2016 at 12:08 AM Colton Conor wrote: > What is performing the LACP? The Level3 transport system for the most part > is purley optical, so I don't think it touches LACP. Did you check the hash > values? > > On Sun, May 22, 2016 at 2:55 PM, Nevin Gonsalves via NANOG < > nanog at nanog.org> > wrote: > > > Hi Nanog-ers, > > Hoping someone may have come across a similar issue. Has anyone ever seen > > a situation where maybe like a Level3 transport system could be possibly > > dropping LACP frames..? > > End point A - tx and rx counts incrementing for LACP > > LACP info: Role System System Port Port > > Port priority identifier priority > > number key et-0/0/0.0 Actor 127 5c:45:27:6d:2a:c0 > > 127 56 16 et-0/0/0.0 Partner 1 > 00:00:00:00:00:00 > > 127 56 16 LACP Statistics: LACP Rx LACP Tx > > Unknown Rx Illegal Rx et-0/0/0.0 6925 > 6922 > > 0 0 > > End Point B - no RX, partner macs are 0s.. > > LACP info: Role System System Port Port > > Port priority identifier priority > > number key et-9/1/0.0 Actor 127 5c:45:27:77:d6:c4 > > 127 68 16 et-9/1/0.0 Partner 1 > 00:00:00:00:00:00 > > 1 68 16 LACP Statistics: LACP Rx LACP Tx > > Unknown Rx Illegal Rx et-9/1/0.0 0 6752 > > 0 0 > > Link works fine otherwise outside the aggregate and w/o LACP. Any inputs > > will be greatly appreciated. > > thanks, > > -nevin > > > From mitchell at dash-networks.com Tue May 24 12:17:39 2016 From: mitchell at dash-networks.com (Mitchell Lewis) Date: Tue, 24 May 2016 08:17:39 -0400 Subject: Network traffic simulator Message-ID: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. I am interested in any input as to brands to look at, build one myself etc. Thanks,Mitchell? From sryan at arbor.net Tue May 24 20:04:23 2016 From: sryan at arbor.net (Spencer Ryan) Date: Tue, 24 May 2016 16:04:23 -0400 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: We are heavily invested in Ixia, they are very expensive, but if you need the kind of precision they provide they work very well. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Tue, May 24, 2016 at 8:17 AM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell From josh at imaginenetworksllc.com Tue May 24 20:04:52 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 24 May 2016 16:04:52 -0400 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: IXIA would be the only company I know of. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, May 24, 2016 at 8:17 AM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell From ray at orsiniit.com Tue May 24 20:14:17 2016 From: ray at orsiniit.com (Ray Orsini) Date: Tue, 24 May 2016 16:14:17 -0400 Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: Siama also does this. I don't own any. But I've used them with some of my customers. http://siamasystems.com/?page_id=2280 Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Tuesday, May 24, 2016 4:05 PM To: Mitchell Lewis Cc: NANOG Subject: Re: Network traffic simulator IXIA would be the only company I know of. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, May 24, 2016 at 8:17 AM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I > am looking for a network traffic simulator which can simulate 40 gbps > of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself > etc. > Thanks,Mitchell From jason+nanog at lixfeld.ca Tue May 24 20:31:11 2016 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 24 May 2016 16:31:11 -0400 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: <0BAB157E-EA5E-48EA-A408-D68272235783@lixfeld.ca> I?m in the process of building a box using MoonGen [1] and a supported Intel 82599 6 port SFP+ NIC [2] that is coming in at just under US$3800 all-in. Supposed to be able to drive at least the entire card at line rate for that price and have enough CPU and memory slots free to fill the box up with as many of these NICs as it will take if need be. [1] https://github.com/emmericp/MoonGen [2] http://www.interfacemasters.com/index.php?option=com_content&view=article&id=153&Itemid=103 > On May 24, 2016, at 8:17 AM, Mitchell Lewis wrote: > > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell From mark.tinka at seacom.mu Tue May 24 21:38:48 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 24 May 2016 23:38:48 +0200 Subject: LACP Frames / Level3 Transport In-Reply-To: References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> Message-ID: <98aac474-eab5-3a17-7a02-6c559a2d76dc@seacom.mu> On 24/May/16 06:29, Rob Laidlaw wrote: > Yes. Many vendors are using l2vpn/pseudo-wire services of one sort or > another to provide circuits and most do not transport LACP by default. To the OP's case, commercially, I'd find it interesting to transport a 100Gbps circuit as EoMPLS rather than EoDWDM, considering the amount of bandwidth one would need to throw at an IP/MPLS network to transport 100Gbps effectively... Mark. From me at geordish.org Tue May 24 21:55:46 2016 From: me at geordish.org (Dave Bell) Date: Tue, 24 May 2016 22:55:46 +0100 Subject: Network traffic simulator In-Reply-To: <0BAB157E-EA5E-48EA-A408-D68272235783@lixfeld.ca> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> <0BAB157E-EA5E-48EA-A408-D68272235783@lixfeld.ca> Message-ID: I've used Spirent in the past. They do a hardware option, as well as a VM. Lots of things supported like BGP, and PPP. Regards, Dave On 24 May 2016 at 21:31, Jason Lixfeld wrote: > I?m in the process of building a box using MoonGen [1] and a supported > Intel 82599 6 port SFP+ NIC [2] that is coming in at just under US$3800 > all-in. Supposed to be able to drive at least the entire card at line rate > for that price and have enough CPU and memory slots free to fill the box up > with as many of these NICs as it will take if need be. > > [1] https://github.com/emmericp/MoonGen > [2] > http://www.interfacemasters.com/index.php?option=com_content&view=article&id=153&Itemid=103 > > > On May 24, 2016, at 8:17 AM, Mitchell Lewis > wrote: > > > > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > > I am interested in any input as to brands to look at, build one myself > etc. > > Thanks,Mitchell > > From eric.kuhnke at gmail.com Tue May 24 22:14:22 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 24 May 2016 15:14:22 -0700 Subject: LACP Frames / Level3 Transport In-Reply-To: <98aac474-eab5-3a17-7a02-6c559a2d76dc@seacom.mu> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> <98aac474-eab5-3a17-7a02-6c559a2d76dc@seacom.mu> Message-ID: Or a very reckless oversubscription ratio and misjudgment of the customer, example, if a provider had 2 x 100GbE capacity between two locations and sold a customer a 100GbE EoMPLS transport circuit from A to Z, based on the mistaken idea of "Well these guys probably aren't going to peak more than 35Gbps of traffic at any time in the near future....". Frightening. On Tue, May 24, 2016 at 2:38 PM, Mark Tinka wrote: > > > On 24/May/16 06:29, Rob Laidlaw wrote: > > > Yes. Many vendors are using l2vpn/pseudo-wire services of one sort or > > another to provide circuits and most do not transport LACP by default. > > To the OP's case, commercially, I'd find it interesting to transport a > 100Gbps circuit as EoMPLS rather than EoDWDM, considering the amount of > bandwidth one would need to throw at an IP/MPLS network to transport > 100Gbps effectively... > > Mark. > From jwbensley at gmail.com Tue May 24 22:25:57 2016 From: jwbensley at gmail.com (James Bensley) Date: Tue, 24 May 2016 23:25:57 +0100 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: On 24 May 2016 at 13:17, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell COTS hardware is cheap enough, TRex should do what you want: http://trex-tgn.cisco.com/ Cheers, James. From chip.gwyn at gmail.com Tue May 24 23:50:32 2016 From: chip.gwyn at gmail.com (chip) Date: Tue, 24 May 2016 19:50:32 -0400 Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: If this is a one time thing, you're probably better off renting an Ixia or Spirent device. If you find yourself doing this a few times a year, might be worth investing in one. Not only for just throughput testing but spamming packets for testing DoS, testing convergence times of routing protocols, generating complex topology routing updates, etc. On Tue, May 24, 2016 at 6:25 PM, James Bensley wrote: > On 24 May 2016 at 13:17, Mitchell Lewis > wrote: > > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > > I am interested in any input as to brands to look at, build one myself > etc. > > Thanks,Mitchell > > COTS hardware is cheap enough, TRex should do what you want: > > http://trex-tgn.cisco.com/ > > Cheers, > James. > -- Just my $.02, your mileage may vary, batteries not included, etc.... From swhyte at gmail.com Wed May 25 00:45:21 2016 From: swhyte at gmail.com (Scott Whyte) Date: Tue, 24 May 2016 17:45:21 -0700 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: <56475a4b-4a96-fda6-214d-9c8f3ab2713f@gmail.com> On 5/24/16 05:17, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. If you want DYI check out http://osnt.org/ > Thanks,Mitchell From mark.tinka at seacom.mu Wed May 25 05:42:45 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 25 May 2016 07:42:45 +0200 Subject: LACP Frames / Level3 Transport In-Reply-To: References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> <98aac474-eab5-3a17-7a02-6c559a2d76dc@seacom.mu> Message-ID: On 25/May/16 00:14, Eric Kuhnke wrote: > Or a very reckless oversubscription ratio and misjudgment of the customer, > example, if a provider had 2 x 100GbE capacity between two locations and > sold a customer a 100GbE EoMPLS transport circuit from A to Z, based on the > mistaken idea of "Well these guys probably aren't going to peak more than > 35Gbps of traffic at any time in the near future....". Frightening. Yeah, I wouldn't do that. Easier and cheaper to deliver the circuit over EoDWDM if you can't reserve enough capacity in the backbone. You could get away with it by doing an N x 100Gbps LAG, but EoMPLS traffic may or may not load balance well, depending on platform and payload. Mark. From rea+nanog at grid.kiae.ru Wed May 25 06:55:33 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Wed, 25 May 2016 09:55:33 +0300 Subject: LACP Frames / Level3 Transport In-Reply-To: <35834213.1429317.1464093543784.JavaMail.yahoo@mail.yahoo.com> References: <286815851.538144.1463946931350.JavaMail.yahoo.ref@mail.yahoo.com> <286815851.538144.1463946931350.JavaMail.yahoo@mail.yahoo.com> <20160524094828.GC14947void.CODELABS.ru@void.CODELABS.ru> <35834213.1429317.1464093543784.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160525065533.GS80548void.CODELABS.ru@void.CODELABS.ru> Tue, May 24, 2016 at 12:39:03PM +0000, Nevin Gonsalves wrote: > I just had to sit and trace all the cables to make sure the tx/rx > lined up for the right circuits as well as hitting the right patch > panel ports. Once all that got aligned nicely things started working > magically. Yep, ports in an "up" state, but LACP not working is the sign of bad cabling: had been hit by this overnight once when I was preparing to leave the facilities next day for conference, but ought to make 10G for the new servers working. Took around 1/2 hour to sense what happened at that time (tx was going to, say, port A and rx -- to port B, but overall all ports were receiving tx and rx) and 3 hours for rewiring and swearing: probably I am more skilled in the former than in the latter ;) Thought that you had checked this in the first place; my bad. Thanks for sharing! -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From saku at ytti.fi Wed May 25 07:08:32 2016 From: saku at ytti.fi (Saku Ytti) Date: Wed, 25 May 2016 10:08:32 +0300 Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: On 24 May 2016 at 23:04, Spencer Ryan wrote: Hey, > We are heavily invested in Ixia, they are very expensive, but if you need > the kind of precision they provide they work very well. I've used all big three, Agilent (back in packets and protocols), IXIA and Spirent. And several smaller/cheaper like Anritsu, EXFO, etc. I think Agilent was the best product for SP's. But you no longer can purchase it. I was recently responsible for evaluating and purchasing product for one company and shortlisted both IXIA and Spirent. Neither one really was fully satisfactory after Agilent experience, but we needed a solution so we purchased Spirent. For that company QoS testing was one of the key use-cases and you really can't do that in IXIA at all, as you cannot make it burst for any significant time (i.e. not for even significant microseconds). Testing QoS with precisely paced packets is not going to be useful. Spirent can do this nicely, so we chose Spirent. I'm not being nasty or funny, but I think best thing that ever happened to Spirent was IXIA buying Agilent. Both Spirent and IXIA has much poorer graphing capabilities than Agilent had. In IXIA I mostly rely on exporting data and graphing with GNUPlot instead. For example you cannot graph packet loss as percentage in the tool itself. Which is huge annoyance to me, after coming from Agilent. Many times in QoS testing you'd have EF, AF, BE traffic, and you have expectation how many percentage in given situation should given class drop, doing this in Agilent is a chore. Agilent probably has best in the breed network with emulation capabilities. And focus generally seems to be in protocol testing/development where network emulation is tremendously useful. As the platforms are very expensive, not many SPs are using them, so they're not getting input from SPs what the boxes should be doing. This market is very poorly tapped, there is large demand in the market for proper testing equipment but it's just priced out of reach. I believe Spirent and Agilent should sell the hardware at-cost, then sell timed licenses, where maybe 1000h license would be today's full cost. Large segment of this market might not use box at all in some year and would generally only require modest hours from it. Bit harder to justify the cost with low use, compared to vendors who run them automated 24/7. -- ++ytti From saku at ytti.fi Wed May 25 07:14:05 2016 From: saku at ytti.fi (Saku Ytti) Date: Wed, 25 May 2016 10:14:05 +0300 Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: Ugh. In all cases below, where it says Agilent it should say IXIA. > Many times in QoS testing you'd have EF, AF, BE > traffic, and you have expectation how many percentage in given > situation should given class drop, doing this in Agilent is a chore. > > Agilent probably has best in the breed network with emulation > capabilities. And focus generally seems to be in protocol > testing/development where network emulation is tremendously useful. > > As the platforms are very expensive, not many SPs are using them, so > they're not getting input from SPs what the boxes should be doing. > This market is very poorly tapped, there is large demand in the market > for proper testing equipment but it's just priced out of reach. I > believe Spirent and Agilent should sell the hardware at-cost, then > sell timed licenses, where maybe 1000h license would be today's full > cost. Large segment of this market might not use box at all in some > year and would generally only require modest hours from it. > Bit harder to justify the cost with low use, compared to vendors who > run them automated 24/7. -- ++ytti From sryan at arbor.net Wed May 25 07:19:28 2016 From: sryan at arbor.net (Spencer Ryan) Date: Wed, 25 May 2016 03:19:28 -0400 Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: Yeah. We run all of our IXIA gear 24/7 in automated feature/regression testing. We are looking into high density layer 1 packet switches so we can automate physical topology changes as well. On May 25, 2016 3:14 AM, "Saku Ytti" wrote: Ugh. In all cases below, where it says Agilent it should say IXIA. > Many times in QoS testing you'd have EF, AF, BE > traffic, and you have expectation how many percentage in given > situation should given class drop, doing this in Agilent is a chore. > > Agilent probably has best in the breed network with emulation > capabilities. And focus generally seems to be in protocol > testing/development where network emulation is tremendously useful. > > As the platforms are very expensive, not many SPs are using them, so > they're not getting input from SPs what the boxes should be doing. > This market is very poorly tapped, there is large demand in the market > for proper testing equipment but it's just priced out of reach. I > believe Spirent and Agilent should sell the hardware at-cost, then > sell timed licenses, where maybe 1000h license would be today's full > cost. Large segment of this market might not use box at all in some > year and would generally only require modest hours from it. > Bit harder to justify the cost with low use, compared to vendors who > run them automated 24/7. -- ++ytti From sabri at cluecentral.net Wed May 25 20:34:39 2016 From: sabri at cluecentral.net (Sabri Berisha) Date: Wed, 25 May 2016 13:34:39 -0700 (PDT) Subject: Network traffic simulator In-Reply-To: References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: <1557596034.107538.1464208479799.JavaMail.zimbra@cluecentral.net> Hi, This depends very much on which Ixia product you're using. In IxExplorer and IxNetwork require a lot of manual labor when setting up a test. IxLoad has a little less, but still. It is important to realize that most of the tests can be automated using TCL scripts. The company I'm currently with has an entire team doing nothing but test automation using Ixia TCL. Before the N2X acquisition by Ixia, I used both when I was still at Redback Networks. For access related test cases I found both of them to be equally suitable, with a slight preference towards IxNetwork because of their more intuitive gui. And pricing... yes, test gear is very expensive. But I guess that's because the market is pretty much dominated by Ixia and Spirent these days. Thanks, Sabri ----- Original Message ----- > From: "Saku Ytti" > To: "Spencer Ryan" > Cc: "NANOG" , "Mitchell Lewis" > Sent: Wednesday, May 25, 2016 12:14:05 AM > Subject: Re: Network traffic simulator > Ugh. In all cases below, where it says Agilent it should say IXIA. > >> Many times in QoS testing you'd have EF, AF, BE >> traffic, and you have expectation how many percentage in given >> situation should given class drop, doing this in Agilent is a chore. >> >> Agilent probably has best in the breed network with emulation >> capabilities. And focus generally seems to be in protocol >> testing/development where network emulation is tremendously useful. >> >> As the platforms are very expensive, not many SPs are using them, so >> they're not getting input from SPs what the boxes should be doing. >> This market is very poorly tapped, there is large demand in the market >> for proper testing equipment but it's just priced out of reach. I >> believe Spirent and Agilent should sell the hardware at-cost, then >> sell timed licenses, where maybe 1000h license would be today's full >> cost. Large segment of this market might not use box at all in some >> year and would generally only require modest hours from it. >> Bit harder to justify the cost with low use, compared to vendors who >> run them automated 24/7. > > > > > -- > ++ytti From saku at ytti.fi Wed May 25 20:44:09 2016 From: saku at ytti.fi (Saku Ytti) Date: Wed, 25 May 2016 23:44:09 +0300 Subject: Network traffic simulator In-Reply-To: <1557596034.107538.1464208479799.JavaMail.zimbra@cluecentral.net> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> <1557596034.107538.1464208479799.JavaMail.zimbra@cluecentral.net> Message-ID: On 25 May 2016 at 23:34, Sabri Berisha wrote: > This depends very much on which Ixia product you're using. In IxExplorer and IxNetwork require a lot of manual labor when setting up a test. IxLoad has a little less, but still. It is important to realize that most of the tests can be automated using TCL scripts. The company I'm currently with has an entire team doing nothing but test automation using Ixia TCL. I think the problems I pointed out are not fixable by TCL. The hardware itself simply cannot burst for any reasonable period, it only paces. You could create multiple streams and have TCL turn the burst on occasionally, but how to synchronise this in nanosecond level with the main stream, and at least in tens of microseconds resolution in duration? You can't do that, it takes easily 10s to command it to do something on TCL. Lot can be done, but for device costing that much, and virtually no QoS testing can be done, I'm not happy camper. QoS by nature is not paced. And QoS configuration which looks perfect in IXIA may not work in real-life. And in my case conversely, real-life problem we had, we could not replicate in lab with IXIA. I know two other companies who experienced same, and IXIA SE was unable to solve it. It is very clear development of software is being dominated by hardware vendors, not by SPs. -- ++ytti From joly at punkcast.com Wed May 25 23:13:07 2016 From: joly at punkcast.com (Joly MacFie) Date: Wed, 25 May 2016 19:13:07 -0400 Subject: NYNOG Inaugural meet livestream Message-ID: http://isoc-ny.org/p2/8521 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From mattlists at rivervalleyinternet.net Thu May 26 12:22:18 2016 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Thu, 26 May 2016 08:22:18 -0400 Subject: Frontier routing issue? Message-ID: <40AD53F9-BEB3-4930-9603-381DE1901B14@rivervalleyinternet.net> Is anyone else in the north east seeing routing issues on frontier right now? Unable to get to many websites. Trace route seems to complete fine but you can't bring up any content. From johnstong at westmancom.com Thu May 26 13:11:35 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Thu, 26 May 2016 13:11:35 +0000 Subject: AS 714/6185 IX Peering Message-ID: <82C0CE81789FE64D8F4D152631918297B149B4@MSG6.westman.int> Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try and get traffic from your network to come to me via your Equinix IX connection instead of a transit connections. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From freedman at freedman.net Thu May 26 14:47:15 2016 From: freedman at freedman.net (Avi Freedman) Date: Thu, 26 May 2016 10:47:15 -0400 (EDT) Subject: LLDP via SNMP Message-ID: <20160526144715.AA0D655006E16@freedman.net> Have had the question come up a few times, so I wanted to poll the community to see... For those who are monitoring LLDP, how have you found the SNMP MIB support support for it on Juniper, Cisco, Brocade, Arista, and others? Wondering if you've needed to resort to CLI scraping or APIs to get the data? Thanks, Avi Freedman CEO, Kentik From sryan at arbor.net Thu May 26 14:51:03 2016 From: sryan at arbor.net (Spencer Ryan) Date: Thu, 26 May 2016 10:51:03 -0400 Subject: LLDP via SNMP In-Reply-To: <20160526144715.AA0D655006E16@freedman.net> References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: We use Observium for most of our SNMP monitoring, and it correctly pulls LLDP and CDP data from all of our Cisco and Arista gear. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Thu, May 26, 2016 at 10:47 AM, Avi Freedman wrote: > > Have had the question come up a few times, so I wanted to poll the > community to see... > > For those who are monitoring LLDP, how have you found the SNMP MIB support > support for it on Juniper, Cisco, Brocade, Arista, and others? > > Wondering if you've needed to resort to CLI scraping or APIs to get the > data? > > Thanks, > > Avi Freedman > CEO, Kentik > > From michael.hare at wisc.edu Thu May 26 15:53:53 2016 From: michael.hare at wisc.edu (Michael Hare) Date: Thu, 26 May 2016 15:53:53 +0000 Subject: LLDP via SNMP In-Reply-To: References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: My experience with Juniper has been mixed, experience with 12.X and 13.X made me wonder if I had a poor understanding of how to do a proper decode or if Juniper's implementation itself had issues as I would often get incomplete results. We've now grab over XML and have been pleased with that choice to the point I no longer see it as a "resort" but the most efficient way for us to move forward. I used to open JTAC cases on each SNMP problem I'd come across [ CoS, mac-accounting ] and it generally wasn't a good use of our time. -Michael -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan Sent: Thursday, May 26, 2016 9:51 AM To: avi at kentik.com Cc: North American Network Operators' Group Subject: Re: LLDP via SNMP We use Observium for most of our SNMP monitoring, and it correctly pulls LLDP and CDP data from all of our Cisco and Arista gear. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Thu, May 26, 2016 at 10:47 AM, Avi Freedman wrote: > > Have had the question come up a few times, so I wanted to poll the > community to see... > > For those who are monitoring LLDP, how have you found the SNMP MIB support > support for it on Juniper, Cisco, Brocade, Arista, and others? > > Wondering if you've needed to resort to CLI scraping or APIs to get the > data? > > Thanks, > > Avi Freedman > CEO, Kentik > > From jeffg at opennms.org Thu May 26 18:53:19 2016 From: jeffg at opennms.org (Jeff Gehlbach) Date: Thu, 26 May 2016 14:53:19 -0400 Subject: LLDP via SNMP In-Reply-To: <20160526144715.AA0D655006E16@freedman.net> References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: <34b0b707-79be-b1c7-d89c-d18690aea6d1@opennms.org> On 05/26/2016 10:47 AM, Avi Freedman wrote: > For those who are monitoring LLDP, how have you found the SNMP MIB > support support for it on Juniper, Cisco, Brocade, Arista, and > others? I can't speak to Brocade (just haven't been to a customer recently who has their kit and wants topology), but I've found support from Juniper, Cisco, and Arista to be very good. As long as the device software load is reasonably modern and LLDP is lit up everywhere, topology usually just works. We added LLDP support a couple years ago to OpenNMS' L2/L3 link-discovery service daemon (on top of CDP, IS-IS, and OSPF). Everything is done via SNMP, for now anyway. If you read Java, you can profit from our experience by sifting through the various LLDP-related classes in our code here: https://github.com/OpenNMS/opennms/ Tangentially, we've also been working on integration with OpenDaylight, which pretty much demands going ReSTful to gather underlay and overlay topology data. -jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Thu May 26 19:16:21 2016 From: saku at ytti.fi (Saku Ytti) Date: Thu, 26 May 2016 22:16:21 +0300 Subject: LLDP via SNMP In-Reply-To: <20160526144715.AA0D655006E16@freedman.net> References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: On 26 May 2016 at 17:47, Avi Freedman wrote: > For those who are monitoring LLDP, how have you found the SNMP MIB support support for it on Juniper, Cisco, Brocade, Arista, and others? I've written this to crawl network with CDP+LLDP+SNMP and produce JSON or dotty output of topology. https://github.com/ytti/netcrawl CDP MIB is obviously enterprise but LLDP is standard. LLDP standard itself is in my non-humble opinion broken. There are no guarantees that standard compliant LLDP will produce useful data. Standard should allow multiple TLV's to describe port and device. Standard should mandate that if device implements IP and SNMP, one of the port TLVs SHOULD be 'ifIndex' and one of the device TLVs SHOULD be MGMT IP address. -- ++ytti From opendak at shaw.ca Tue May 24 20:14:04 2016 From: opendak at shaw.ca (David) Date: Tue, 24 May 2016 14:14:04 -0600 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: <5744B60C.9090809@shaw.ca> On 2016-05-24 6:17 AM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell > SPIRENT offers such products (along with Ixia already mentioned). From greenejk.ctr at afrl.hpc.mil Tue May 24 20:48:46 2016 From: greenejk.ctr at afrl.hpc.mil (Jim Greene) Date: Tue, 24 May 2016 16:48:46 -0400 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: <36d82b0945e0ea62cb98fa4c900ffa6e@afrl.hpc.mil> Spirent can do this, Have worked with them at 100G. On 2016-05-24 08:17, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell -- Jim Greene Lockheed Martin AFRL/RCM 2435 Fifth St WPAFB, OH. 45433 937-656-5692 greenejk.ctr at afrl.hpc.mil From tom.smyth at wirelessconnect.eu Tue May 24 22:42:23 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Tue, 24 May 2016 23:42:23 +0100 Subject: Network traffic simulator In-Reply-To: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> References: <97fec43ycia1a2k80bj7xtm8.1464092259234@email.android.com> Message-ID: Hi Michell, the CCR series from MT is probably is as cost effictive a 10G+ Capable system that you can use to generate and measure the packet troughput of a core router under test... check out traffic generator http://wiki.mikrotik.com/wiki/Manual:Tools/Traffic_Generator you can generate small packets / large packets ... simulate TCP throughput and play wireshark pcap files.. .. it is prety comprehensive... somre of the configuration syntax is not that intutive ... but its worakable... any system that I have tested with traffic generator vs an expensive calibrated tests the results were always corelating between MT traffic generator and the expensive testers with an error margin of 1-2 % I hope that helps... Peace out On Tue, May 24, 2016 at 1:17 PM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. From michaelolusegunrufai at gmail.com Wed May 25 07:10:59 2016 From: michaelolusegunrufai at gmail.com (segs) Date: Wed, 25 May 2016 08:10:59 +0100 Subject: VOIP Monitoring Solution Message-ID: Hi All, I Am on the lookout for a solution that can monitor IP phones in use on the network. The solution should have -- a very intuitive GUI -- detailed reporting mechanism. --- send basic commands like restart to the phones ---- monitor number of active calls on the call manager ---- monitor status of trunks > --- can show visual details of two ip phones in an active call --- show details of call quality. The environment in question is using Cisco Call manager BE7k and cisco Ip phones. Thanks in advance. Segun Rufai From ngambill at sjcisd.org Thu May 26 13:55:22 2016 From: ngambill at sjcisd.org (Gambill, Nate) Date: Thu, 26 May 2016 09:55:22 -0400 Subject: Frontier routing issue? In-Reply-To: <40AD53F9-BEB3-4930-9603-381DE1901B14@rivervalleyinternet.net> References: <40AD53F9-BEB3-4930-9603-381DE1901B14@rivervalleyinternet.net> Message-ID: Matt, Some of our sites in Michigan are experiencing similar outages. I understand that they are actively working to correct the issues. Later, -- Nate Gambill *STM* Network Engineer Information Services St. Joseph County Schools 62445 Shimmel Road Centreville, MI 49032-9527 269.467.5315 -- CONFIDENTIALITY NOTICE: This message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups. From qosys.net at gmail.com Thu May 26 15:28:34 2016 From: qosys.net at gmail.com (Fedor Sumkin) Date: Thu, 26 May 2016 18:28:34 +0300 Subject: LLDP via SNMP In-Reply-To: References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: Most of the vendors support standard LLDP-MIB::lldpMIB mib(i.e. Cisco, Huawei, Juniper, Arista, EdgeCore..). Only few of them have vendor-specific Mibs(Alcatel, a3com-huawei, Motorola WiNG). On Thu, May 26, 2016 at 5:51 PM, Spencer Ryan wrote: > We use Observium for most of our SNMP monitoring, and it correctly pulls > LLDP and CDP data from all of our Cisco and Arista gear. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Thu, May 26, 2016 at 10:47 AM, Avi Freedman > wrote: > > > > > Have had the question come up a few times, so I wanted to poll the > > community to see... > > > > For those who are monitoring LLDP, how have you found the SNMP MIB > support > > support for it on Juniper, Cisco, Brocade, Arista, and others? > > > > Wondering if you've needed to resort to CLI scraping or APIs to get the > > data? > > > > Thanks, > > > > Avi Freedman > > CEO, Kentik > > > > > From regezos at gmail.com Fri May 27 08:28:17 2016 From: regezos at gmail.com (Rukka Pal) Date: Fri, 27 May 2016 10:28:17 +0200 Subject: GRE on ASR9001 Message-ID: Anyone here running GRE tunnels between ASR9001series? I am planning to connect some special-purpose remote sites to my core infra using unencrypted GRE tunnels and OSPF routing. The estimated bandwidth requirements are between 500Mbps and several Gbps. I am not planning to use MPAs, instead the fixed 10G ports I believe this should present no significant problems to the ASR9001, just wanted to get a confirmation. Thanks! From saku at ytti.fi Fri May 27 09:40:25 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 27 May 2016 12:40:25 +0300 Subject: GRE on ASR9001 In-Reply-To: References: Message-ID: On 27 May 2016 at 11:28, Rukka Pal wrote: > I believe this should present no significant problems to the ASR9001, just > wanted to get a confirmation. Thanks! Performance will be about 15Mpps per NPU. -- ++ytti From regezos at gmail.com Fri May 27 11:04:54 2016 From: regezos at gmail.com (Rukka Pal) Date: Fri, 27 May 2016 13:04:54 +0200 Subject: GRE on ASR9001 In-Reply-To: References: Message-ID: Thanks! May I know where you found this information? Did you calculate this using "BRKSPG-2904" or is this a result of your own testing? On Fri, May 27, 2016 at 11:40 AM, Saku Ytti wrote: > On 27 May 2016 at 11:28, Rukka Pal wrote: > > > I believe this should present no significant problems to the ASR9001, > just > > wanted to get a confirmation. Thanks! > > Performance will be about 15Mpps per NPU. > > -- > ++ytti > From saku at ytti.fi Fri May 27 11:38:05 2016 From: saku at ytti.fi (Saku Ytti) Date: Fri, 27 May 2016 14:38:05 +0300 Subject: GRE on ASR9001 In-Reply-To: References: Message-ID: Original work. But I lied, I read my notes and performance was capped at 12Mpps, after which counters which indicate NPU starvation start to increase. On 27 May 2016 at 14:04, Rukka Pal wrote: > Thanks! May I know where you found this information? Did you calculate this > using "BRKSPG-2904" or is this a result of your own testing? > > On Fri, May 27, 2016 at 11:40 AM, Saku Ytti wrote: >> >> On 27 May 2016 at 11:28, Rukka Pal wrote: >> >> > I believe this should present no significant problems to the ASR9001, >> > just >> > wanted to get a confirmation. Thanks! >> >> Performance will be about 15Mpps per NPU. >> >> -- >> ++ytti > > -- ++ytti From ren.provo at gmail.com Fri May 27 10:06:45 2016 From: ren.provo at gmail.com (Ren Provo) Date: Fri, 27 May 2016 12:06:45 +0200 Subject: AS 714/6185 IX Peering In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297B149B4@MSG6.westman.int> Message-ID: <330BEA67-890C-4078-8E08-CDD7EA23B126@gmail.com> Third time should be the charm? (Thanks Job!) Cheers! -Ren Sent from my iPhone 6S Plus > On May 27, 2016, at 11:36 AM, Ren Provo wrote: > > Several folks have written to ensure I spotted this during RIPE. Indeed, the reminder to engage contacts posted at http://as714.peeringdb.com - namely peering-NOC at apple.com - was sent. Y'all didn't see it because it was sent from an email that is not registered on this list. Spotted the rejection later. Hence take two today and a confirmation Graham's concern has been noted within Apple. > > Cheers! -Ren > Sent from my iPhone 6S Plus > >> On May 26, 2016, at 3:11 PM, Graham Johnston wrote: >> >> Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try and get traffic from your network to come to me via your Equinix IX connection instead of a transit connections. >> >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> P think green; don't print this email. >> From mark at rapid-communications.com Fri May 27 12:46:08 2016 From: mark at rapid-communications.com (mark at rapid-communications.com) Date: Fri, 27 May 2016 12:46:08 +0000 (UTC) Subject: NANOG Digest, Vol 100, Issue 26 In-Reply-To: References: Message-ID: X rj45 3m ? 4 Tks mark On Fri, May 27, 2016 at 5:00 AM -0700, wrote: Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Frontier routing issue? (Matt Hoppes) 2. AS 714/6185 IX Peering (Graham Johnston) 3. LLDP via SNMP (Avi Freedman) 4. Re: LLDP via SNMP (Spencer Ryan) 5. RE: LLDP via SNMP (Michael Hare) 6. Re: LLDP via SNMP (Jeff Gehlbach) 7. Re: LLDP via SNMP (Saku Ytti) 8. Re: Network traffic simulator (David) 9. Re: Network traffic simulator (Jim Greene) 10. Re: Network traffic simulator (Tom Smyth) 11. VOIP Monitoring Solution (segs) 12. Re: Frontier routing issue? (Gambill, Nate) 13. Re: LLDP via SNMP (Fedor Sumkin) 14. GRE on ASR9001 (Rukka Pal) 15. Re: GRE on ASR9001 (Saku Ytti) 16. Re: GRE on ASR9001 (Rukka Pal) 17. Re: GRE on ASR9001 (Saku Ytti) ---------------------------------------------------------------------- Message: 1 Date: Thu, 26 May 2016 08:22:18 -0400 From: Matt Hoppes To: nanog at nanog.org Subject: Frontier routing issue? Message-ID: <40AD53F9-BEB3-4930-9603-381DE1901B14 at rivervalleyinternet.net> Content-Type: text/plain; charset=us-ascii Is anyone else in the north east seeing routing issues on frontier right now? Unable to get to many websites. Trace route seems to complete fine but you can't bring up any content. ------------------------------ Message: 2 Date: Thu, 26 May 2016 13:11:35 +0000 From: Graham Johnston To: NANOG Subject: AS 714/6185 IX Peering Message-ID: <82C0CE81789FE64D8F4D152631918297B149B4 at MSG6.westman.int> Content-Type: text/plain; charset="us-ascii" Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try and get traffic from your network to come to me via your Equinix IX connection instead of a transit connections. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. ------------------------------ Message: 3 Date: Thu, 26 May 2016 10:47:15 -0400 (EDT) From: freedman at freedman.net (Avi Freedman) To: nanog at nanog.org Subject: LLDP via SNMP Message-ID: <20160526144715.AA0D655006E16 at freedman.net> Content-Type: text/plain; charset="US-ASCII" Have had the question come up a few times, so I wanted to poll the community to see... For those who are monitoring LLDP, how have you found the SNMP MIB support support for it on Juniper, Cisco, Brocade, Arista, and others? Wondering if you've needed to resort to CLI scraping or APIs to get the data? Thanks, Avi Freedman CEO, Kentik ------------------------------ Message: 4 Date: Thu, 26 May 2016 10:51:03 -0400 From: Spencer Ryan To: avi at kentik.com Cc: "North American Network Operators' Group" Subject: Re: LLDP via SNMP Message-ID: Content-Type: text/plain; charset=UTF-8 We use Observium for most of our SNMP monitoring, and it correctly pulls LLDP and CDP data from all of our Cisco and Arista gear. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Thu, May 26, 2016 at 10:47 AM, Avi Freedman wrote: > > Have had the question come up a few times, so I wanted to poll the > community to see... > > For those who are monitoring LLDP, how have you found the SNMP MIB support > support for it on Juniper, Cisco, Brocade, Arista, and others? > > Wondering if you've needed to resort to CLI scraping or APIs to get the > data? > > Thanks, > > Avi Freedman > CEO, Kentik > > ------------------------------ Message: 5 Date: Thu, 26 May 2016 15:53:53 +0000 From: Michael Hare To: Spencer Ryan , "avi at kentik.com" Cc: North American Network Operators' Group Subject: RE: LLDP via SNMP Message-ID: Content-Type: text/plain; CHARSET=US-ASCII My experience with Juniper has been mixed, experience with 12.X and 13.X made me wonder if I had a poor understanding of how to do a proper decode or if Juniper's implementation itself had issues as I would often get incomplete results. We've now grab over XML and have been pleased with that choice to the point I no longer see it as a "resort" but the most efficient way for us to move forward. I used to open JTAC cases on each SNMP problem I'd come across [ CoS, mac-accounting ] and it generally wasn't a good use of our time. -Michael -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spencer Ryan Sent: Thursday, May 26, 2016 9:51 AM To: avi at kentik.com Cc: North American Network Operators' Group Subject: Re: LLDP via SNMP We use Observium for most of our SNMP monitoring, and it correctly pulls LLDP and CDP data from all of our Cisco and Arista gear. *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com On Thu, May 26, 2016 at 10:47 AM, Avi Freedman wrote: > > Have had the question come up a few times, so I wanted to poll the > community to see... > > For those who are monitoring LLDP, how have you found the SNMP MIB support > support for it on Juniper, Cisco, Brocade, Arista, and others? > > Wondering if you've needed to resort to CLI scraping or APIs to get the > data? > > Thanks, > > Avi Freedman > CEO, Kentik > > ------------------------------ Message: 6 Date: Thu, 26 May 2016 14:53:19 -0400 From: Jeff Gehlbach To: "nanog at nanog.org" Subject: Re: LLDP via SNMP Message-ID: <34b0b707-79be-b1c7-d89c-d18690aea6d1 at opennms.org> Content-Type: text/plain; charset="windows-1252" On 05/26/2016 10:47 AM, Avi Freedman wrote: > For those who are monitoring LLDP, how have you found the SNMP MIB > support support for it on Juniper, Cisco, Brocade, Arista, and > others? I can't speak to Brocade (just haven't been to a customer recently who has their kit and wants topology), but I've found support from Juniper, Cisco, and Arista to be very good. As long as the device software load is reasonably modern and LLDP is lit up everywhere, topology usually just works. We added LLDP support a couple years ago to OpenNMS' L2/L3 link-discovery service daemon (on top of CDP, IS-IS, and OSPF). Everything is done via SNMP, for now anyway. If you read Java, you can profit from our experience by sifting through the various LLDP-related classes in our code here: https://github.com/OpenNMS/opennms/ Tangentially, we've also been working on integration with OpenDaylight, which pretty much demands going ReSTful to gather underlay and overlay topology data. -jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 7 Date: Thu, 26 May 2016 22:16:21 +0300 From: Saku Ytti To: avi at kentik.com Cc: nanog list Subject: Re: LLDP via SNMP Message-ID: Content-Type: text/plain; charset=UTF-8 On 26 May 2016 at 17:47, Avi Freedman wrote: > For those who are monitoring LLDP, how have you found the SNMP MIB support support for it on Juniper, Cisco, Brocade, Arista, and others? I've written this to crawl network with CDP+LLDP+SNMP and produce JSON or dotty output of topology. https://github.com/ytti/netcrawl CDP MIB is obviously enterprise but LLDP is standard. LLDP standard itself is in my non-humble opinion broken. There are no guarantees that standard compliant LLDP will produce useful data. Standard should allow multiple TLV's to describe port and device. Standard should mandate that if device implements IP and SNMP, one of the port TLVs SHOULD be 'ifIndex' and one of the device TLVs SHOULD be MGMT IP address. -- ++ytti ------------------------------ Message: 8 Date: Tue, 24 May 2016 14:14:04 -0600 From: David To: nanog at nanog.org Subject: Re: Network traffic simulator Message-ID: <5744B60C.9090809 at shaw.ca> Content-Type: text/plain; charset=utf-8; format=flowed On 2016-05-24 6:17 AM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell > SPIRENT offers such products (along with Ixia already mentioned). ------------------------------ Message: 9 Date: Tue, 24 May 2016 16:48:46 -0400 From: Jim Greene To: NANOG Subject: Re: Network traffic simulator Message-ID: <36d82b0945e0ea62cb98fa4c900ffa6e at afrl.hpc.mil> Content-Type: text/plain; charset=US-ASCII Spirent can do this, Have worked with them at 100G. On 2016-05-24 08:17, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am looking for a network traffic simulator which can simulate 40 gbps of traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell -- Jim Greene Lockheed Martin AFRL/RCM 2435 Fifth St WPAFB, OH. 45433 937-656-5692 greenejk.ctr at afrl.hpc.mil ------------------------------ Message: 10 Date: Tue, 24 May 2016 23:42:23 +0100 From: Tom Smyth To: Mitchell Lewis Cc: NANOG Subject: Re: Network traffic simulator Message-ID: Content-Type: text/plain; charset=UTF-8 Hi Michell, the CCR series from MT is probably is as cost effictive a 10G+ Capable system that you can use to generate and measure the packet troughput of a core router under test... check out traffic generator http://wiki.mikrotik.com/wiki/Manual:Tools/Traffic_Generator you can generate small packets / large packets ... simulate TCP throughput and play wireshark pcap files.. .. it is prety comprehensive... somre of the configuration syntax is not that intutive ... but its worakable... any system that I have tested with traffic generator vs an expensive calibrated tests the results were always corelating between MT traffic generator and the expensive testers with an error margin of 1-2 % I hope that helps... Peace out On Tue, May 24, 2016 at 1:17 PM, Mitchell Lewis wrote: > Hi,I am looking to validate the performance specs of a core router. I am > looking for a network traffic simulator which can simulate 40 gbps of > traffic. I am looking for a simulator with sfp+ ports. > I am interested in any input as to brands to look at, build one myself etc. > Thanks,Mitchell -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. ------------------------------ Message: 11 Date: Wed, 25 May 2016 08:10:59 +0100 From: segs To: nanog at nanog.org Subject: VOIP Monitoring Solution Message-ID: Content-Type: text/plain; charset=UTF-8 Hi All, I Am on the lookout for a solution that can monitor IP phones in use on the network. The solution should have -- a very intuitive GUI -- detailed reporting mechanism. --- send basic commands like restart to the phones ---- monitor number of active calls on the call manager ---- monitor status of trunks > --- can show visual details of two ip phones in an active call --- show details of call quality. The environment in question is using Cisco Call manager BE7k and cisco Ip phones. Thanks in advance. Segun Rufai ------------------------------ Message: 12 Date: Thu, 26 May 2016 09:55:22 -0400 From: "Gambill, Nate" To: Matt Hoppes Cc: nanog at nanog.org Subject: Re: Frontier routing issue? Message-ID: Content-Type: text/plain; charset=UTF-8 Matt, Some of our sites in Michigan are experiencing similar outages. I understand that they are actively working to correct the issues. Later, -- Nate Gambill *STM* Network Engineer Information Services St. Joseph County Schools 62445 Shimmel Road Centreville, MI 49032-9527 269.467.5315 -- CONFIDENTIALITY NOTICE: This message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups. ------------------------------ Message: 13 Date: Thu, 26 May 2016 18:28:34 +0300 From: Fedor Sumkin To: Spencer Ryan Cc: avi at kentik.com, "North American Network Operators' Group" Subject: Re: LLDP via SNMP Message-ID: Content-Type: text/plain; charset=UTF-8 Most of the vendors support standard LLDP-MIB::lldpMIB mib(i.e. Cisco, Huawei, Juniper, Arista, EdgeCore..). Only few of them have vendor-specific Mibs(Alcatel, a3com-huawei, Motorola WiNG). On Thu, May 26, 2016 at 5:51 PM, Spencer Ryan wrote: > We use Observium for most of our SNMP monitoring, and it correctly pulls > LLDP and CDP data from all of our Cisco and Arista gear. > > > *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net > *Arbor Networks* > +1.734.794.5033 (d) | +1.734.846.2053 (m) > www.arbornetworks.com > > On Thu, May 26, 2016 at 10:47 AM, Avi Freedman > wrote: > > > > > Have had the question come up a few times, so I wanted to poll the > > community to see... > > > > For those who are monitoring LLDP, how have you found the SNMP MIB > support > > support for it on Juniper, Cisco, Brocade, Arista, and others? > > > > Wondering if you've needed to resort to CLI scraping or APIs to get the > > data? > > > > Thanks, > > > > Avi Freedman > > CEO, Kentik > > > > > ------------------------------ Message: 14 Date: Fri, 27 May 2016 10:28:17 +0200 From: Rukka Pal To: NANOG Subject: GRE on ASR9001 Message-ID: Content-Type: text/plain; charset=UTF-8 Anyone here running GRE tunnels between ASR9001series? I am planning to connect some special-purpose remote sites to my core infra using unencrypted GRE tunnels and OSPF routing. The estimated bandwidth requirements are between 500Mbps and several Gbps. I am not planning to use MPAs, instead the fixed 10G ports I believe this should present no significant problems to the ASR9001, just wanted to get a confirmation. Thanks! ------------------------------ Message: 15 Date: Fri, 27 May 2016 12:40:25 +0300 From: Saku Ytti To: Rukka Pal Cc: NANOG Subject: Re: GRE on ASR9001 Message-ID: Content-Type: text/plain; charset=UTF-8 On 27 May 2016 at 11:28, Rukka Pal wrote: > I believe this should present no significant problems to the ASR9001, just > wanted to get a confirmation. Thanks! Performance will be about 15Mpps per NPU. -- ++ytti ------------------------------ Message: 16 Date: Fri, 27 May 2016 13:04:54 +0200 From: Rukka Pal To: Saku Ytti Cc: NANOG Subject: Re: GRE on ASR9001 Message-ID: Content-Type: text/plain; charset=UTF-8 Thanks! May I know where you found this information? Did you calculate this using "BRKSPG-2904" or is this a result of your own testing? On Fri, May 27, 2016 at 11:40 AM, Saku Ytti wrote: > On 27 May 2016 at 11:28, Rukka Pal wrote: > > > I believe this should present no significant problems to the ASR9001, > just > > wanted to get a confirmation. Thanks! > > Performance will be about 15Mpps per NPU. > > -- > ++ytti > ------------------------------ Message: 17 Date: Fri, 27 May 2016 14:38:05 +0300 From: Saku Ytti To: Rukka Pal Cc: NANOG Subject: Re: GRE on ASR9001 Message-ID: Content-Type: text/plain; charset=UTF-8 Original work. But I lied, I read my notes and performance was capped at 12Mpps, after which counters which indicate NPU starvation start to increase. On 27 May 2016 at 14:04, Rukka Pal wrote: > Thanks! May I know where you found this information? Did you calculate this > using "BRKSPG-2904" or is this a result of your own testing? > > On Fri, May 27, 2016 at 11:40 AM, Saku Ytti wrote: >> >> On 27 May 2016 at 11:28, Rukka Pal wrote: >> >> > I believe this should present no significant problems to the ASR9001, >> > just >> > wanted to get a confirmation. Thanks! >> >> Performance will be about 15Mpps per NPU. >> >> -- >> ++ytti > > -- ++ytti End of NANOG Digest, Vol 100, Issue 26 ************************************** From mkamal at noor.net Fri May 27 13:19:21 2016 From: mkamal at noor.net (Mohamed Kamal) Date: Fri, 27 May 2016 15:19:21 +0200 (EET) Subject: Preferring RSVP for only one l2circuit. Message-ID: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> I have a full-mesh LDP LSPs between my MX-104 routers, however, between two specific routers and on the same loopbacks I configured RSVP LSP to be used as the transport for only one l2circuit and no more. The problem is, when the RSVP gets signaled, it gets installed in the inet.3 and gets preferred over any other LDP LSP. So all the traffic destined to RSVP tail-end will prefer the RSVP over the LDP. I have increased the preference of the RSVP, and it has been taken out of the inet.3, so the l2circuit didn't prefer the RSVP path anymore! Do anyone has a working configuration for this? or should I configured another loopback address on every pair of routers for the RSVP signalling? -- mk From Timothy.Creswick at vorboss.com Fri May 27 13:30:08 2016 From: Timothy.Creswick at vorboss.com (Timothy Creswick) Date: Fri, 27 May 2016 14:30:08 +0100 Subject: Preferring RSVP for only one l2circuit. In-Reply-To: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> References: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> Message-ID: <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> > I have increased the preference of the RSVP, and it has been taken out of the inet.3, so the l2circuit didn't prefer > the RSVP path anymore! Just add "no-install-to-address" to the LSP. From mkamal at noor.net Fri May 27 13:46:42 2016 From: mkamal at noor.net (Mohamed Kamal) Date: Fri, 27 May 2016 15:46:42 +0200 (EET) Subject: Preferring RSVP for only one l2circuit. In-Reply-To: <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> References: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> Message-ID: <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> tried this Timothy, and the RSVP didn't appear in the inet.3. Failed to work! ----- Original Message ----- From: "Timothy Creswick" To: "Mohamed Kamal" , nanog at nanog.org Sent: Friday, May 27, 2016 3:30:08 PM Subject: RE: Preferring RSVP for only one l2circuit. > I have increased the preference of the RSVP, and it has been taken out of the inet.3, so the l2circuit didn't prefer > the RSVP path anymore! Just add "no-install-to-address" to the LSP. From bicknell at ufp.org Fri May 27 15:55:19 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 27 May 2016 08:55:19 -0700 Subject: LLDP via SNMP In-Reply-To: References: <20160526144715.AA0D655006E16@freedman.net> Message-ID: <20160527155519.GA42318@ussenterprise.ufp.org> In a message written on Thu, May 26, 2016 at 10:16:21PM +0300, Saku Ytti wrote: > LLDP standard itself is in my non-humble opinion broken. There are no > guarantees that standard compliant LLDP will produce useful data. Including inside a particular vendor's own implementation. For instance some junipers advertise the interface name (ge-0/0/0) and some the description ("To Bob's ISP") for the "interface name" field in the CLI. So depending on the platform and version of code you get totally different information from "show lldp neighbors". It really makes it difficult to consume the data by script. Lots of special cases. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From drohan at gmail.com Fri May 27 17:47:07 2016 From: drohan at gmail.com (Daniel Rohan) Date: Fri, 27 May 2016 10:47:07 -0700 Subject: Global/distributed IXP operators? Message-ID: If there are any operators working at distributed/global IXPs and wouldn't mind having their brains picked regarding design questions, would you make yourselves known to me (on or off-list is fine). Thanks, Dan From cscora at apnic.net Fri May 27 18:10:34 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 May 2016 04:10:34 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201605271810.u4RIAYbM018216@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 May, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 594503 Prefixes after maximum aggregation (per Origin AS): 217631 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 291513 Total ASes present in the Internet Routing Table: 53890 Prefixes per ASN: 11.03 Origin-only ASes present in the Internet Routing Table: 36576 Origin ASes announcing only one prefix: 15650 Transit ASes present in the Internet Routing Table: 6452 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 1029 Unregistered ASNs in the Routing Table: 368 Number of 32-bit ASNs allocated by the RIRs: 14035 Number of 32-bit ASNs visible in the Routing Table: 10862 Prefixes from 32-bit ASNs in the Routing Table: 42481 Number of bogon 32-bit ASNs visible in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 362 Number of addresses announced to Internet: 2808989828 Equivalent to 167 /8s, 109 /16s and 200 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.2 Total number of prefixes smaller than registry allocations: 193849 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 152413 Total APNIC prefixes after maximum aggregation: 42506 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 163652 Unique aggregates announced from the APNIC address blocks: 67122 APNIC Region origin ASes present in the Internet Routing Table: 5193 APNIC Prefixes per ASN: 31.51 APNIC Region origin ASes announcing only one prefix: 1187 APNIC Region transit ASes present in the Internet Routing Table: 919 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 54 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2096 Number of APNIC addresses announced to Internet: 754412868 Equivalent to 44 /8s, 247 /16s and 109 /24s Percentage of available APNIC address space announced: 88.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 181275 Total ARIN prefixes after maximum aggregation: 89149 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 186737 Unique aggregates announced from the ARIN address blocks: 88167 ARIN Region origin ASes present in the Internet Routing Table: 16356 ARIN Prefixes per ASN: 11.42 ARIN Region origin ASes announcing only one prefix: 5828 ARIN Region transit ASes present in the Internet Routing Table: 1715 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1237 Number of ARIN addresses announced to Internet: 1099642048 Equivalent to 65 /8s, 139 /16s and 52 /24s Percentage of available ARIN address space announced: 58.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 142652 Total RIPE prefixes after maximum aggregation: 70520 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 151964 Unique aggregates announced from the RIPE address blocks: 94043 RIPE Region origin ASes present in the Internet Routing Table: 18075 RIPE Prefixes per ASN: 8.41 RIPE Region origin ASes announcing only one prefix: 7878 RIPE Region transit ASes present in the Internet Routing Table: 3012 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4806 Number of RIPE addresses announced to Internet: 704609664 Equivalent to 41 /8s, 255 /16s and 125 /24s Percentage of available RIPE address space announced: 102.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61535 Total LACNIC prefixes after maximum aggregation: 12202 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 75875 Unique aggregates announced from the LACNIC address blocks: 36025 LACNIC Region origin ASes present in the Internet Routing Table: 2473 LACNIC Prefixes per ASN: 30.68 LACNIC Region origin ASes announcing only one prefix: 576 LACNIC Region transit ASes present in the Internet Routing Table: 567 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2506 Number of LACNIC addresses announced to Internet: 171169024 Equivalent to 10 /8s, 51 /16s and 213 /24s Percentage of available LACNIC address space announced: 102.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 14037 Total AfriNIC prefixes after maximum aggregation: 3217 AfriNIC Deaggregation factor: 4.36 Prefixes being announced from the AfriNIC address blocks: 15913 Unique aggregates announced from the AfriNIC address blocks: 5825 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 21.62 AfriNIC Region origin ASes announcing only one prefix: 181 AfriNIC Region transit ASes present in the Internet Routing Table: 167 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 217 Number of AfriNIC addresses announced to Internet: 78714880 Equivalent to 4 /8s, 177 /16s and 24 /24s Percentage of available AfriNIC address space announced: 78.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5559 4192 76 China Education and Research 7545 3342 356 223 TPG Telecom Limited 4766 3177 11144 1123 Korea Telecom 17974 2946 914 96 PT Telekomunikasi Indonesia 9829 2522 1479 497 National Internet Backbone 9808 2096 8781 40 Guangdong Mobile Communicatio 4755 2092 431 241 TATA Communications formerly 4808 1701 2301 552 CNCGROUP IP network China169 9583 1510 122 556 Sify Limited 38197 1509 94 218 Sun Network (Hong Kong) Limit Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3331 2947 139 Cox Communications Inc. 6389 2298 3671 41 BellSouth.net Inc. 18566 2195 394 275 MegaPath Corporation 20115 1923 1938 403 Charter Communications 209 1695 4971 773 Qwest Communications Company, 30036 1692 336 415 Mediacom Communications Corp 6983 1690 849 232 EarthLink, Inc. 4323 1512 984 372 tw telecom holdings, inc. 701 1297 10718 705 MCI Communications Services, 11492 1283 234 584 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2595 1002 1863 Akamai International B.V. 34984 1965 326 358 TELLCOM ILETISIM HIZMETLERI A 12479 1229 998 88 France Telecom Espana SA 8551 1220 376 55 Bezeq International-Ltd 6849 1148 355 21 JSC "Ukrtelecom" 8402 1124 544 15 OJSC "Vimpelcom" 13188 1078 98 68 TOV "Bank-Inform" 31148 1024 47 44 Freenet Ltd. 9198 936 352 26 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3472 541 155 Telmex Colombia S.A. 8151 2258 3425 576 Uninet S.A. de C.V. 7303 1511 940 234 Telecom Argentina S.A. 11830 1476 368 51 Instituto Costarricense de El 6503 1473 437 56 Axtel, S.A.B. de C.V. 6147 1112 377 27 Telefonica del Peru S.A.A. 26615 1007 2325 34 Tim Celular S.A. 3816 1002 479 175 COLOMBIA TELECOMUNICACIONES S 7738 994 1882 40 Telemar Norte Leste S.A. 11172 907 125 77 Alestra, S. de R.L. de C.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1087 402 44 Link Egypt (Link.NET) 37611 639 48 2 Afrihost-Brevis Computer Serv 36903 626 315 103 Office National des Postes et 36992 509 1359 27 ETISALAT MISR 8452 489 1472 15 TE-AS 37492 395 234 68 Orange Tunisie 29571 301 37 13 Cote d'Ivoire Telecom 24835 294 466 14 Vodafone Data 15399 285 35 10 Wananchi Group (Kenya) Limite 2018 257 327 74 TENET (The UNINET Project) Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5559 4192 76 China Education and Research 10620 3472 541 155 Telmex Colombia S.A. 7545 3342 356 223 TPG Telecom Limited 22773 3331 2947 139 Cox Communications Inc. 4766 3177 11144 1123 Korea Telecom 17974 2946 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2595 1002 1863 Akamai International B.V. 9829 2522 1479 497 National Internet Backbone 6389 2298 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3472 3317 Telmex Colombia S.A. 22773 3331 3192 Cox Communications Inc. 7545 3342 3119 TPG Telecom Limited 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2946 2850 PT Telekomunikasi Indonesia 6389 2298 2257 BellSouth.net Inc. 9808 2096 2056 Guangdong Mobile Communicatio 4766 3177 2054 Korea Telecom 9829 2522 2025 National Internet Backbone 18566 2195 1920 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/22 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:266 /13:514 /14:1036 /15:1763 /16:13043 /17:7609 /18:12712 /19:25937 /20:38001 /21:39713 /22:65681 /23:57477 /24:328881 /25:560 /26:598 /27:419 /28:48 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2557 3331 Cox Communications Inc. 18566 2097 2195 MegaPath Corporation 30036 1507 1692 Mediacom Communications Corp 6389 1476 2298 BellSouth.net Inc. 10620 1376 3472 Telmex Colombia S.A. 6983 1340 1690 EarthLink, Inc. 34984 1249 1965 TELLCOM ILETISIM HIZMETLERI A 11492 1186 1283 CABLE ONE, INC. 6849 968 1148 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1575 2:748 4:20 5:2065 6:31 8:962 12:1779 13:39 14:1699 15:45 16:2 17:84 18:90 20:48 22:1 23:1514 24:1763 27:2275 31:1767 32:59 33:2 34:2 35:5 36:292 37:2231 38:1221 39:25 40:91 41:2826 42:397 43:1724 44:43 45:1938 46:2493 47:78 49:1168 50:875 51:33 52:195 54:331 55:7 56:7 57:42 58:1529 59:886 60:344 61:1823 62:1499 63:1936 64:4445 65:2164 66:4255 67:2193 68:1093 69:3293 70:1156 71:474 72:2006 74:2536 75:346 76:349 77:1375 78:1298 79:845 80:1274 81:1352 82:948 83:698 84:831 85:1578 86:480 87:1057 88:563 89:2000 90:172 91:6036 92:914 93:2323 94:2385 95:2314 96:499 97:359 98:937 99:46 100:75 101:1044 103:10902 104:2448 105:125 106:405 107:1181 108:669 109:2195 110:1241 111:1639 112:1012 113:1169 114:1060 115:1613 116:1580 117:1439 118:2065 119:1626 120:930 121:1178 122:2178 123:2023 124:1576 125:1730 128:735 129:400 130:418 131:1321 132:620 133:176 134:455 135:127 136:373 137:348 138:1729 139:274 140:543 141:459 142:639 143:896 144:696 145:159 146:872 147:631 148:1481 149:507 150:645 151:883 152:618 153:285 154:632 155:934 156:503 157:444 158:337 159:1119 160:488 161:715 162:2321 163:548 164:884 165:1033 166:320 167:1147 168:1873 169:662 170:1612 171:263 172:571 173:1643 174:746 175:723 176:1744 177:3927 178:2209 179:1129 180:2042 181:1772 182:1862 183:980 184:807 185:6515 186:2964 187:2120 188:2116 189:1689 190:7681 191:1209 192:8933 193:5743 194:4384 195:3763 196:1673 197:1073 198:5556 199:5700 200:6937 201:3744 202:10177 203:9643 204:4519 205:2728 206:2986 207:3135 208:4053 209:3873 210:3882 211:2049 212:2676 213:2228 214:852 215:71 216:5793 217:1967 218:797 219:607 220:1689 221:865 222:668 223:1237 End of report From ahebert at pubnix.net Fri May 27 18:36:35 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 27 May 2016 14:36:35 -0400 Subject: MPLS Reference Designs In-Reply-To: <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> References: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> Message-ID: <096e8320-1f6a-7e47-0f2a-3e4811b692f1@pubnix.net> Hi, ( it might be a bit much to look for that here, but meh its Friday ) Goals Usual Multi-point L2 services, with L3 path(s) to the Internet -and/or- inter-site L3 routing (VRF per customer). This is a simple project involving upgrading a L2 MAN into and more flexible and isolated (MACs wise) MPLS infrastructure. Road blocks We're wasting way too much time with sales rep/engineer, for then, ending up finding some irrelevant limitation after having spent ~20h of man power looking at their offering. Question ( Obviously interoperability is just ridiculous when talking MPLS... ) Thus I'm looking for reference designs from different vendor viewpoint. Simple enough, but I would like to put the "make/model of the actual device capable" of doing the function at the P, PE and CE level of their design. Too many times we ended up finding boxes that look the part but are limited in such a way to accomplish only the task that fit the vendor own MPLS paradigm. ( TLDR: Make us spend more $$$ than needed =D long gone is the swiss-knife concept ) Offlist answers are fine. From mark.tinka at seacom.mu Fri May 27 21:49:44 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 27 May 2016 23:49:44 +0200 Subject: Preferring RSVP for only one l2circuit. In-Reply-To: <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> References: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> Message-ID: On 27/May/16 15:46, Mohamed Kamal wrote: > tried this Timothy, and the RSVP didn't appear in the inet.3. Failed to work! Best option is to create a separate Loopback interface on each router, and use that to signal the RSVP tunnels. It's the only way to keep your LDP and RSVP tunnels from mingling with each other for EoMPLS circuits you want to nail on a given path. Mark. From mark.tinka at seacom.mu Fri May 27 21:52:05 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 27 May 2016 23:52:05 +0200 Subject: MPLS Reference Designs In-Reply-To: <096e8320-1f6a-7e47-0f2a-3e4811b692f1@pubnix.net> References: <1446481823.1311002.1464355161379.JavaMail.zimbra@noor.net> <6D526C4EE4FA2745AD0D768DC25211F008FE546E5264@MBOX-CLUSTER.hosted.vorboss.net> <659655545.1317035.1464356802091.JavaMail.zimbra@noor.net> <096e8320-1f6a-7e47-0f2a-3e4811b692f1@pubnix.net> Message-ID: <14dbb30c-f894-2043-b0ce-2579b94b9b72@seacom.mu> On 27/May/16 20:36, Alain Hebert wrote: > > ( Obviously interoperability is just ridiculous when talking MPLS... ) Why would you think so? > > Too many times we ended up finding boxes that look the part but are > limited in such a way to accomplish only the task that fit the vendor > own MPLS paradigm. > ( TLDR: Make us spend more $$$ than needed =D long gone is the > swiss-knife concept ) What platforms have you worked on before that have caused you grief? Mark. From magicsata at gmail.com Sat May 28 12:04:47 2016 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sat, 28 May 2016 13:04:47 +0100 Subject: Netflix IP Space Message-ID: Hi All, Does anyone on either lists have a list of Netflix's IP space that they are using for streams and "unblocker" detection? We are doing policy based VPN and Netflix needs to be excluded from this to work around their restrictions. They are on AWS so not as easy as just finding their ASN... Thanks, Alistair From jared at puck.nether.net Sat May 28 13:05:15 2016 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 28 May 2016 09:05:15 -0400 Subject: Netflix IP Space In-Reply-To: References: Message-ID: Perhaps just consider all of these:? % ./bgpq3 as2906 % ./bgpq3 as16509 % ./bgpq3 as14618 Obviously make sure you have it properly in your tools for automation. - Jared > On May 28, 2016, at 8:04 AM, Alistair Mackenzie wrote: > > Hi All, > > Does anyone on either lists have a list of Netflix's IP space that they are > using for streams and "unblocker" detection? > > We are doing policy based VPN and Netflix needs to be excluded from this to > work around their restrictions. > > They are on AWS so not as easy as just finding their ASN... > > Thanks, > Alistair From faisal at snappytelecom.net Sat May 28 19:19:32 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 28 May 2016 19:19:32 +0000 (GMT) Subject: Netflix IP Space In-Reply-To: References: Message-ID: <985560723.330978.1464463172866.JavaMail.zimbra@snappytelecom.net> I would suggest that you contact their NOC for the appropriate answer, since they don't advertise all of their prefixes out of all locations, plus they also use geo coding as well to determine from where they are going to stream the customer from. Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Alistair Mackenzie" > To: "nanog list" , uknof at lists.uknof.org.uk > Sent: Saturday, May 28, 2016 8:04:47 AM > Subject: Netflix IP Space > Hi All, > > Does anyone on either lists have a list of Netflix's IP space that they are > using for streams and "unblocker" detection? > > We are doing policy based VPN and Netflix needs to be excluded from this to > work around their restrictions. > > They are on AWS so not as easy as just finding their ASN... > > Thanks, > Alistair From nanog at ics-il.net Sat May 28 22:36:28 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 May 2016 17:36:28 -0500 (CDT) Subject: FlowSpec Support Message-ID: <541931670.3228.1464474985954.JavaMail.mhammett@ThunderFuck> I know support (from customers) is limited among networks. I know it isn't on all hardware, but does appear to be on at least a couple platforms from the major router vendors. It is supported on an increasing number of DDoS appliances and software packages. What all networks support receiving BGP FlowSpec information from customers and acting upon it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From josh at kyneticwifi.com Sat May 28 22:41:38 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 28 May 2016 17:41:38 -0500 Subject: FlowSpec Support In-Reply-To: <541931670.3228.1464474985954.JavaMail.mhammett@ThunderFuck> References: <541931670.3228.1464474985954.JavaMail.mhammett@ThunderFuck> Message-ID: There was just a recent discussion about this. None of the big upstreams support it because they are all too busy selling their own DDoS mitigation services :) On May 28, 2016 5:38 PM, "Mike Hammett" wrote: > I know support (from customers) is limited among networks. I know it isn't > on all hardware, but does appear to be on at least a couple platforms from > the major router vendors. It is supported on an increasing number of DDoS > appliances and software packages. > > What all networks support receiving BGP FlowSpec information from > customers and acting upon it? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From nanog at ics-il.net Sat May 28 23:47:27 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 May 2016 18:47:27 -0500 (CDT) Subject: FlowSpec Support In-Reply-To: References: <541931670.3228.1464474985954.JavaMail.mhammett@ThunderFuck> Message-ID: <606830666.3264.1464477228485.JavaMail.mhammett@ThunderFuck> I read that discussion (and several others going back about two or three years) before I posted this. As an occasional OP on here, I've noticed I get a lot of off-list responses so I obviously wouldn't have seen any of those from other people's threads. I didn't take that observation away from that thread, but maybe I'm dense. ;-) I know it was suggested that they wanted to bill for that sued capacity, but that was debunked. I know DDoS services were mentioned, but I didn't see a clear line drawn to that's why it isn't happening... nor confirmed. Also, what's big? Listed on the Baker's Dozen? Wide-spread POPs on six continents? Showing up on 50 IXPs? 1k IPv4 adjacencies? A medium sized network that does FlowSpec could be vastly more useful to you than a large network that doesn't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, May 28, 2016 5:41:38 PM Subject: Re: FlowSpec Support There was just a recent discussion about this. None of the big upstreams support it because they are all too busy selling their own DDoS mitigation services :) On May 28, 2016 5:38 PM, "Mike Hammett" < nanog at ics-il.net > wrote: I know support (from customers) is limited among networks. I know it isn't on all hardware, but does appear to be on at least a couple platforms from the major router vendors. It is supported on an increasing number of DDoS appliances and software packages. What all networks support receiving BGP FlowSpec information from customers and acting upon it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From freetexwatson at gmail.com Sun May 29 01:51:04 2016 From: freetexwatson at gmail.com (B F) Date: Sat, 28 May 2016 21:51:04 -0400 Subject: NIST NTP servers Message-ID: <6fvo6vreshgtxb5o5rwpqnhh.1464486459527@email.android.com> All, ? Thanks very much for all the replies. Extremely helpful. "...ask someone what time it is and they'll tell you how to build a watch." Luckily I got both. Ed -------- Original message -------- From: Lamar Owen Date: 5/14/2016 10:27 AM (GMT-05:00) To: NANOG Subject: Re: NIST NTP servers On 05/13/2016 04:38 PM, Mel Beckman wrote: > But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. While this is drifting a bit off-topic for NANOG (and drifting into the topic range for time-nuts at febo.com), I'll just add one more thing to this.? The Hold time (when the oscillator is free-running) is a very important consideration, especially, as you say, when terrain is an issue. For us it is even more important, as the 10MHz output from the timing rack is used as a site-wide frequency standard.? Of course, you never discipline a cesium PRS, but the rubidium secondary is disciplined by circuitry in the SSU2000. Back in the days of common backbone delivery over SONET discussion of cesium standards would have been on-topic, as some SONET gear (Nortel Optera for instance) needs a master clock; especially if you were delivering channelized circuits or interfacing with customers and telcos with DS3 or even DS1 circuits or DS0 fractions within them.? Ethernet is far more forgiving. From nanog at ics-il.net Sun May 29 12:26:29 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 29 May 2016 07:26:29 -0500 (CDT) Subject: Global/distributed IXP operators? In-Reply-To: References: Message-ID: <230732850.196.1464524787663.JavaMail.mhammett@ThunderFuck> Could you define what you mean by a distributed\global IXP? There are plenty of IXPs, but there aren't really global IXPs, those just become networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Daniel Rohan" To: "NANOG" Sent: Friday, May 27, 2016 12:47:07 PM Subject: Global/distributed IXP operators? If there are any operators working at distributed/global IXPs and wouldn't mind having their brains picked regarding design questions, would you make yourselves known to me (on or off-list is fine). Thanks, Dan From marty at cloudflare.com Sun May 29 12:32:18 2016 From: marty at cloudflare.com (Marty Strong) Date: Sun, 29 May 2016 13:32:18 +0100 Subject: Global/distributed IXP operators? In-Reply-To: <230732850.196.1464524787663.JavaMail.mhammett@ThunderFuck> References: <230732850.196.1464524787663.JavaMail.mhammett@ThunderFuck> Message-ID: <85AD72DB-C1D7-4C85-8885-073C9CB62EC3@cloudflare.com> I think he means IXes like NetIX: http://netix.net/map, a single distributed fabric. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 29 May 2016, at 13:26, Mike Hammett wrote: > > Could you define what you mean by a distributed\global IXP? There are plenty of IXPs, but there aren't really global IXPs, those just become networks. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Daniel Rohan" > To: "NANOG" > Sent: Friday, May 27, 2016 12:47:07 PM > Subject: Global/distributed IXP operators? > > If there are any operators working at distributed/global IXPs and wouldn't > mind having their brains picked regarding design questions, would you make > yourselves known to me (on or off-list is fine). > > Thanks, > > Dan > From dovid at telecurve.com Sun May 29 15:37:13 2016 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 29 May 2016 11:37:13 -0400 Subject: VOIP Monitoring Solution In-Reply-To: References: Message-ID: Check out voipmonitor.org. On Wed, May 25, 2016 at 3:10 AM, segs wrote: > Hi All, > > I Am on the lookout for a solution that can monitor IP phones in use on the > network. > > The solution should have > > -- a very intuitive GUI > > -- detailed reporting mechanism. > > --- send basic commands like restart to the phones > > ---- monitor number of active calls on the call manager > > ---- monitor status of trunks > --- can show visual details of two ip > phones in an active call > > --- show details of call quality. > > The environment in question is using Cisco Call manager BE7k and cisco Ip > phones. > > Thanks in advance. > > Segun Rufai > From mj at doze.net Sat May 28 03:37:14 2016 From: mj at doze.net (Mike Joseph) Date: Fri, 27 May 2016 23:37:14 -0400 Subject: NANOG 67 closing social Message-ID: Sending this to the list as well as Betty, in case anyone on the PC has more details: I've noticed on the NANOG 67 agenda that there's a social scheduled for Wednesday night, which I think is odd since we (almost) never have any social or other events after conference closing. In fact, I noticed something very similar on a version of the NANOG 66 agenda and then it was revised a week or two before the conference. So, the question is pose is: *Is this an error on the NANOG 67 agenda, or are we really having a social on the last night?* -MJ From mj at doze.net Sat May 28 03:37:51 2016 From: mj at doze.net (Mike Joseph) Date: Fri, 27 May 2016 23:37:51 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: I can say via firsthand knowledge that CALEA requests are definitely happening and are not even that rare, proportional to a reasonably sized subscriber-base. It would be unlawful for me to comment specifically on any actual CALEA requests, however. But if you have general questions about my observations, feel free to reach out directly. -MJ On Thu, May 12, 2016 at 11:28 AM, Brian Mengel wrote: > My comments were strictly limited to my understanding of CALEA as it > applied to ISPs, not telcos. A request for a lawful intercept can entail > mirroring a real time stream of all data sent to/from a customer's Internet > connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this > requires mediation before being sent to the LEA and it is the mediation > server itself that initiates the intercept when so configured by the ISP. > Perhaps some LEAs have undertaken the mediation function so as to > facilitate these intercepts where the neither the ISP nor a third party can > do so. If that were the case then very little would be needed on the part > of the ISP in order to comply with a request for lawful intercept. I can > say with certainty that these types of requests are being made of broadband > ISPs though I agree that they are very rare. > > On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: > > > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel > > wrote: > > > > AFAIK being able to do a lawful intercept on a specific, named, > >> individual's service has been a requirement for providers since 2007. > >> > > > > It's been required for longer than that. The telco I worked for over a > > decade ago didn't build the infrastructure until the FCC said they were > > going to stop funding upgrades. That really got 'em movin'. (suddenly > "data > > services" people -- i.e. ME -- weren't redheaded stepchildren.) > > > > have never heard of a provider, big or small, being called out for being > >> unable to provide this service when requested. > >> > > > > Where existing infrastructure is not already in place (read: > T1/BRI/etc.), > > the telco can take up to 60 days to get that setup. I know more than one > > telco that used that grace period to actually setup CALEA in the first > > place. > > > > did not perform intercepts routinely. > >> > > > > The historic published figures (i've not looked in years) suggest CALEA > > requests are statistically rare. The NC based telco I worked for had > never > > received an order in the then ~40yr life of the company. > > > > The mediation server needed to "mediate" between your customer > aggregation > >> box and the LEA is not inexpensive. > >> > > > > And also is not the telco's problem. Mediation is done by the LEA or 3rd > > party under contract to any number of agencies. For example, a telco tap > > order would mirror the control and voice traffic of a POTS line (T1/PRI > > channel, etc.) into a BRI or specific T1 channel. (dialup was later > added, > > but wasn't required in my era, so we didn't support it.) We used to test > > that by tapping a tech's phone. Not having any mediation software, all I > > could do is "yeap, it's sending data" and listen to the voice channels > on a > > t-berd. > > > > --Ricky > > > > From josh at imaginenetworksllc.com Sun May 29 20:04:10 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 29 May 2016 16:04:10 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: How many requests per 1k or 10k customers? Is primarily residential a safe assumption? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, May 27, 2016 at 11:37 PM, Mike Joseph wrote: > I can say via firsthand knowledge that CALEA requests are definitely > happening and are not even that rare, proportional to a reasonably sized > subscriber-base. It would be unlawful for me to comment specifically on > any actual CALEA requests, however. But if you have general questions > about my observations, feel free to reach out directly. > > -MJ > > On Thu, May 12, 2016 at 11:28 AM, Brian Mengel wrote: > > > My comments were strictly limited to my understanding of CALEA as it > > applied to ISPs, not telcos. A request for a lawful intercept can entail > > mirroring a real time stream of all data sent to/from a customer's > Internet > > connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this > > requires mediation before being sent to the LEA and it is the mediation > > server itself that initiates the intercept when so configured by the ISP. > > Perhaps some LEAs have undertaken the mediation function so as to > > facilitate these intercepts where the neither the ISP nor a third party > can > > do so. If that were the case then very little would be needed on the > part > > of the ISP in order to comply with a request for lawful intercept. I can > > say with certainty that these types of requests are being made of > broadband > > ISPs though I agree that they are very rare. > > > > On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: > > > > > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel > > > wrote: > > > > > > AFAIK being able to do a lawful intercept on a specific, named, > > >> individual's service has been a requirement for providers since 2007. > > >> > > > > > > It's been required for longer than that. The telco I worked for over a > > > decade ago didn't build the infrastructure until the FCC said they were > > > going to stop funding upgrades. That really got 'em movin'. (suddenly > > "data > > > services" people -- i.e. ME -- weren't redheaded stepchildren.) > > > > > > have never heard of a provider, big or small, being called out for > being > > >> unable to provide this service when requested. > > >> > > > > > > Where existing infrastructure is not already in place (read: > > T1/BRI/etc.), > > > the telco can take up to 60 days to get that setup. I know more than > one > > > telco that used that grace period to actually setup CALEA in the first > > > place. > > > > > > did not perform intercepts routinely. > > >> > > > > > > The historic published figures (i've not looked in years) suggest CALEA > > > requests are statistically rare. The NC based telco I worked for had > > never > > > received an order in the then ~40yr life of the company. > > > > > > The mediation server needed to "mediate" between your customer > > aggregation > > >> box and the LEA is not inexpensive. > > >> > > > > > > And also is not the telco's problem. Mediation is done by the LEA or > 3rd > > > party under contract to any number of agencies. For example, a telco > tap > > > order would mirror the control and voice traffic of a POTS line (T1/PRI > > > channel, etc.) into a BRI or specific T1 channel. (dialup was later > > added, > > > but wasn't required in my era, so we didn't support it.) We used to > test > > > that by tapping a tech's phone. Not having any mediation software, all > I > > > could do is "yeap, it's sending data" and listen to the voice channels > > on a > > > t-berd. > > > > > > --Ricky > > > > > > > > From ilissa at imillerpr.com Sun May 29 23:08:07 2016 From: ilissa at imillerpr.com (Ilissa Miller) Date: Sun, 29 May 2016 19:08:07 -0400 Subject: NANOG 67 closing social In-Reply-To: References: Message-ID: <979961988885930246@unknownmsgid> There is indeed a social weds night! The host sponsor, EdgeConneX is holding its social on Weds. Please plan accordingly! Ilissa Miller > On May 29, 2016, at 4:00 PM, Mike Joseph wrote: > > Sending this to the list as well as Betty, in case anyone on the PC has > more details: > > I've noticed on the NANOG 67 agenda that there's a social scheduled for > Wednesday night, which I think is odd since we (almost) never have any > social or other events after conference closing. > > In fact, I noticed something very similar on a version of the NANOG 66 > agenda and then it was revised a week or two before the conference. > > So, the question is pose is: *Is this an error on the NANOG 67 agenda, or > are we really having a social on the last night?* > > -MJ From tdurack at gmail.com Mon May 30 01:07:31 2016 From: tdurack at gmail.com (Tim Durack) Date: Sun, 29 May 2016 21:07:31 -0400 Subject: Public DNS64 In-Reply-To: References: Message-ID: For the record: Tim, I'm not on the NANOG lists and I don't see how I can respond to this thread: https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html but I figured I'd let you know that: https://developers.google.com/speed/public-dns/docs/dns64 is now available for testing. Perhaps it will be some use. Regards, -Erik On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > Anyone know of a reliable public DNS64 service? > > Would be cool if Google added a Public DNS64 service, then I could point > the NAT64 prefix at appropriately placed boxes in my network. > > Why? Other people are better than me at running DNS resolvers :-) > > -- > Tim:> > -- Tim:> From baldur.norddahl at gmail.com Mon May 30 01:25:51 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 30 May 2016 03:25:51 +0200 Subject: Public DNS64 In-Reply-To: References: Message-ID: Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" : > For the record: > > Tim, > > I'm not on the NANOG lists and I don't see how I can respond to this > thread: > > https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html > > but I figured I'd let you know that: > > https://developers.google.com/speed/public-dns/docs/dns64 > > is now available for testing. Perhaps it will be some use. > > Regards, > -Erik > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > Anyone know of a reliable public DNS64 service? > > > > Would be cool if Google added a Public DNS64 service, then I could point > > the NAT64 prefix at appropriately placed boxes in my network. > > > > Why? Other people are better than me at running DNS resolvers :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> > From baldur.norddahl at gmail.com Mon May 30 01:33:10 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 30 May 2016 03:33:10 +0200 Subject: Public DNS64 In-Reply-To: References: Message-ID: Ok that would be a bad idea. Nat64 is not stateless so to anycast it would be unstable. Sorry time to get to sleep. Regards Baldur Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : > Interesting. Now we just need someone like he.net to announce the > 64:ff9b::/96 prefix and run a public nat64 service. > Den 30. maj 2016 03.08 skrev "Tim Durack" : > >> For the record: >> >> Tim, >> >> I'm not on the NANOG lists and I don't see how I can respond to this >> thread: >> >> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html >> >> but I figured I'd let you know that: >> >> https://developers.google.com/speed/public-dns/docs/dns64 >> >> is now available for testing. Perhaps it will be some use. >> >> Regards, >> -Erik >> >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: >> >> > Anyone know of a reliable public DNS64 service? >> > >> > Would be cool if Google added a Public DNS64 service, then I could point >> > the NAT64 prefix at appropriately placed boxes in my network. >> > >> > Why? Other people are better than me at running DNS resolvers :-) >> > >> > -- >> > Tim:> >> > >> >> >> >> -- >> Tim:> >> > From marka at isc.org Mon May 30 01:39:50 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 30 May 2016 11:39:50 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Sun, 29 May 2016 21:07:31 -0400." References: Message-ID: <20160530013950.DA7DF4A4A310@rock.dv.isc.org> DNS64 is a bad solution. It breaks DNSSEC. The proported benefits of DNS64 over other ways of providing IPv4 over IPv6 don't actually exist. DS-Lite or one of the MAP encapsulation will actually be better in the long run. I say this as someone who has written a DNS64 implementation. Mark In message , Tim Durack writes: > For the record: > > Tim, > > I'm not on the NANOG lists and I don't see how I can respond to this thread: > > https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html > > but I figured I'd let you know that: > > https://developers.google.com/speed/public-dns/docs/dns64 > > is now available for testing. Perhaps it will be some use. > > Regards, > -Erik > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > Anyone know of a reliable public DNS64 service? > > > > Would be cool if Google added a Public DNS64 service, then I could point > > the NAT64 prefix at appropriately placed boxes in my network. > > > > Why? Other people are better than me at running DNS resolvers :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon May 30 01:45:11 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 30 May 2016 11:45:11 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Mon, 30 May 2016 03:33:10 +0200." References: Message-ID: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> In message , Baldur Norddahl writes: > Ok that would be a bad idea. Nat64 is not stateless so to anycast it would > be unstable. This is not anycast NAT64. It is anycast DNS64 with the well known 64:ff9b::/96 prefix and a local NAT64 box. While I don't like DNS64 as a solution, this service doesn't need to be critised for faults that don't exist with it. Mark > Sorry time to get to sleep. > > Regards > > Baldur > Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : > > > Interesting. Now we just need someone like he.net to announce the > > 64:ff9b::/96 prefix and run a public nat64 service. > > Den 30. maj 2016 03.08 skrev "Tim Durack" : > > > >> For the record: > >> > >> Tim, > >> > >> I'm not on the NANOG lists and I don't see how I can respond to this > >> thread: > >> > >> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html > >> > >> but I figured I'd let you know that: > >> > >> https://developers.google.com/speed/public-dns/docs/dns64 > >> > >> is now available for testing. Perhaps it will be some use. > >> > >> Regards, > >> -Erik > >> > >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > >> > >> > Anyone know of a reliable public DNS64 service? > >> > > >> > Would be cool if Google added a Public DNS64 service, then I could point > >> > the NAT64 prefix at appropriately placed boxes in my network. > >> > > >> > Why? Other people are better than me at running DNS resolvers :-) > >> > > >> > -- > >> > Tim:> > >> > > >> > >> > >> > >> -- > >> Tim:> > >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon May 30 02:01:34 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 30 May 2016 12:01:34 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Sun, 29 May 2016 21:07:31 -0400." References: Message-ID: <20160530020134.40E844A4B9B7@rock.dv.isc.org> IP6.ARPA lookups aren't working. Adobe.com doesn't have AAAA record so it correctly returns a DNS64 mapped AAAA record. However when you attempt to do a IP6.ARPA lookup on that address it does not follow the synthesised CNAME record as you would expect from a recursive DNS64 server. Mark ; <<>> DiG 9.11.0a2 <<>> aaaa adobe.com @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16081 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;adobe.com. IN AAAA ;; ANSWER SECTION: adobe.com. 10799 IN AAAA 64:ff9b::c096:1075 ;; Query time: 435 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:55:56 EST 2016 ;; MSG SIZE rcvd: 66 ; <<>> DiG 9.11.0a2 <<>> -x 64:ff9b::c096:1075 @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16070 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN PTR ;; ANSWER SECTION: 5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. 10799 IN CNAME 117.16.150.192.in-addr.arpa. ;; Query time: 355 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:56:12 EST 2016 ;; MSG SIZE rcvd: 138 ; <<>> DiG 9.11.0a2 <<>> ptr 117.16.150.192.in-addr.arpa @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 93 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;117.16.150.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 117.16.150.192.in-addr.arpa. 10532 IN PTR www.wip4.adobe.com. ;; Query time: 338 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:56:36 EST 2016 ;; MSG SIZE rcvd: 88 In message , Tim Durack writes: > For the record: > > Tim, > > I'm not on the NANOG lists and I don't see how I can respond to this thread: > > https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html > > but I figured I'd let you know that: > > https://developers.google.com/speed/public-dns/docs/dns64 > > is now available for testing. Perhaps it will be some use. > > Regards, > -Erik > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > Anyone know of a reliable public DNS64 service? > > > > Would be cool if Google added a Public DNS64 service, then I could point > > the NAT64 prefix at appropriately placed boxes in my network. > > > > Why? Other people are better than me at running DNS resolvers :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hugo at slabnet.com Mon May 30 15:18:53 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 30 May 2016 08:18:53 -0700 Subject: Public DNS64 In-Reply-To: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> Message-ID: <20160530151853.GD6467@bamboo.slabnet.com> On Mon 2016-May-30 11:45:11 +1000, Mark Andrews wrote: > >In message >, Baldur Norddahl writes: >> Ok that would be a bad idea. Nat64 is not stateless so to anycast it would >> be unstable. > >This is not anycast NAT64. It is anycast DNS64 with the well known >64:ff9b::/96 prefix and a local NAT64 box. > >While I don't like DNS64 as a solution, this service doesn't need >to be critised for faults that don't exist with it. Pretty sure this was in response to: >> > Interesting. Now we just need someone like he.net to announce the >> > 64:ff9b::/96 prefix and run a public nat64 service. ...so specifically regarding the idea of a public, anycast NAT64 service, rather than the public DNS64 service Google is doing. > >Mark -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal > >> Sorry time to get to sleep. >> >> Regards >> >> Baldur >> Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : >> >> > Interesting. Now we just need someone like he.net to announce the >> > 64:ff9b::/96 prefix and run a public nat64 service. >> > Den 30. maj 2016 03.08 skrev "Tim Durack" : >> > >> >> For the record: >> >> >> >> Tim, >> >> >> >> I'm not on the NANOG lists and I don't see how I can respond to this >> >> thread: >> >> >> >> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html >> >> >> >> but I figured I'd let you know that: >> >> >> >> https://developers.google.com/speed/public-dns/docs/dns64 >> >> >> >> is now available for testing. Perhaps it will be some use. >> >> >> >> Regards, >> >> -Erik >> >> >> >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: >> >> >> >> > Anyone know of a reliable public DNS64 service? >> >> > >> >> > Would be cool if Google added a Public DNS64 service, then I could point >> >> > the NAT64 prefix at appropriately placed boxes in my network. >> >> > >> >> > Why? Other people are better than me at running DNS resolvers :-) >> >> > >> >> > -- >> >> > Tim:> >> >> > >> >> >> >> >> >> >> >> -- >> >> Tim:> >> >> >> > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From swmike at swm.pp.se Mon May 30 15:27:41 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 30 May 2016 17:27:41 +0200 (CEST) Subject: Public DNS64 In-Reply-To: <20160530151853.GD6467@bamboo.slabnet.com> References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: On Mon, 30 May 2016, Hugo Slabbert wrote: > ...so specifically regarding the idea of a public, anycast NAT64 service, > rather than the public DNS64 service Google is doing. Like HE is doing? swmike at uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data bytes 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Mon May 30 21:40:44 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 31 May 2016 07:40:44 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Mon, 30 May 2016 17:27:41 +0200." References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: <20160530214044.707EE4A55241@rock.dv.isc.org> In message , Mikael Abrah amsson writes: > On Mon, 30 May 2016, Hugo Slabbert wrote: > > > ...so specifically regarding the idea of a public, anycast NAT64 service, > > rather than the public DNS64 service Google is doing. > > Like HE is doing? > > swmike at uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net > 2001:470:64:ffff::d4f7:c88f > swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data > bytes > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms > > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means > the NAT64 isn't very local to me... :P I don't know if that is a anycast NAT64. Just because pings get through doesn't mean that other traffic will get through. It really depends upon whether all the IPv6 traffic in the stream all gets routed to the same NAT64 instance. For short lived session this is highly likely. For long lived sessions not so much. For ping there is a single packet each direction. For other protocols there isn't. Mark > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baldur.norddahl at gmail.com Mon May 30 23:28:42 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 31 May 2016 01:28:42 +0200 Subject: Public DNS64 In-Reply-To: References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: > > Like HE is doing? > > swmike at uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net > 2001:470:64:ffff::d4f7:c88f > swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data bytes > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms > > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means > the NAT64 isn't very local to me... :P It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96. An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state. A more simple solution is just to have the DNS64 be anycast and have a DNS64 at each NAT64 location with the DNS64 returning pointers to the local NAT64. Now, can we have a public MAP server? That might scale. The geo blockers will hate it. What is not to like? Regards, Baldur From cb.list6 at gmail.com Mon May 30 23:44:05 2016 From: cb.list6 at gmail.com (Ca By) Date: Mon, 30 May 2016 16:44:05 -0700 Subject: Public DNS64 In-Reply-To: References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: On Monday, May 30, 2016, Baldur Norddahl wrote: > > > > Like HE is doing? > > > > swmike at uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net > > 2001:470:64:ffff::d4f7:c88f > > swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f > > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data > bytes > > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms > > > > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means > > the NAT64 isn't very local to me... :P > > > > It goes to the USA and back again. They would need NAT64 servers in every > region and then let the DNS64 service decide which one is close to you by > encoding the region information in the returned IPv6 address. Such as > 2001:470:64:[region number]::/96. > > An anycast solution would need a distributed NAT64 implementation, such > that the NAT64 servers could somehow synchronize state. A more simple > solution is just to have the DNS64 be anycast and have a DNS64 at each > NAT64 location with the DNS64 returning pointers to the local NAT64. > > Now, can we have a public MAP server? That might scale. The geo blockers > will hate it. What is not to like? > > MAP scale. I know folks think it is theoretically nice but.... Just curious, has anyone yet deployed MAP at scale? I know of several production and large scale nat64s (usually mobile 464xlat related), and a few large ds-lite, but never MAP in production at scale. Maybe i am missing something. CB Regards, > > Baldur > From randy at psg.com Tue May 31 05:03:33 2016 From: randy at psg.com (Randy Bush) Date: Mon, 30 May 2016 22:03:33 -0700 Subject: rfc 1812 third party address on traceroute Message-ID: rfc1812 says 4.3.2.4 ICMP Message Source Address Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If the interface has no IP addresses associated with it, the router's router-id (see Section [5.2.5]) is used instead. some folk have interpreted this to mean that, if a router R has three interfaces .-----------------. | | | B |--------- D S ---------| A R | | C |--------- (toward S) | | `-----------------' if the source of a traceroute from S toward D with TTL to expire on R, and R's FIB wants to exit via C to get back to S (yes, virginia, the internet is highly asymmetric), the source address of the time exceeded message should be C. of course, simpletons such as i would desire the source of the time exceeded message to be A. after all, this is the interface to which i sent the icmp with the TTL to expire. ras's preso, https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf page 10 illustrates this issue with rfc1812 cursory research and talking with C & J seem to indicate that they do what i want not what some folk have interpreted 1812 to mean. at least on some models. is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how common is it? randy From swmike at swm.pp.se Tue May 31 05:30:42 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 31 May 2016 07:30:42 +0200 (CEST) Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: On Mon, 30 May 2016, Randy Bush wrote: > of course, simpletons such as i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. I agree 100%, and I'd venture to guess that most of the people running networks expect it to work like you describe. > cursory research and talking with C & J seem to indicate that they do > what i want not what some folk have interpreted 1812 to mean. at least > on some models. > > is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how > common is it? I have been told that there were versions of IOS XR that stopped doing what people wanted, people screamed, and then it's now back to the behaviour that you describe. In RFC1812 2.2.7 there is talk about router-id. When reading that I think it is generic enough to work for IPv6 as well? Another thing I've seen: People number their links with ULAs. ICMP error messages (including PTBs) are then sent from the router using the ULA address. This is obviously a disaster since that PTB sourced from ULA address is going to be BCP38:ed (hopefully). What's the interaction here with choosing a source address for the ICMP error message from something with the same RFC6724 label as the ICMP error message is being sent to? -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Tue May 31 05:44:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 31 May 2016 07:44:36 +0200 Subject: Public DNS64 In-Reply-To: References: <20160530014512.04C3E4A4A3DE@rock.dv.isc.org> <20160530151853.GD6467@bamboo.slabnet.com> Message-ID: On 31/May/16 01:28, Baldur Norddahl wrote: >> >> >> It goes to the USA and back again. They would need NAT64 servers in every >> region and then let the DNS64 service decide which one is close to you by >> encoding the region information in the returned IPv6 address. Such as >> 2001:470:64:[region number]::/96. >> >> An anycast solution would need a distributed NAT64 implementation, such >> that the NAT64 servers could somehow synchronize state. A more simple >> solution is just to have the DNS64 be anycast and have a DNS64 at each >> NAT64 location with the DNS64 returning pointers to the local NAT64. That is what we do. We've got NAT64 routers deployed at every PoP/region, to keep NAT64 state local and more predictable. Needless to say, the distribution reduces the impact of the "CG" from the "CG-NAT64". Mark. From larrysheldon at cox.net Tue May 31 06:00:41 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 31 May 2016 01:00:41 -0500 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: <70d20e98-365f-f990-dd5b-0f9f079ead97@cox.net> I am completely innocent of rfc1812, and have been out of the game for a long time, but I am pretty sure I was taught (and in turn taught) that a router would reply using the address of the interface that originated the reply unless that interface was unnumbered, in which case it would reply from the loop-back address. Never too old to learn something. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From marka at isc.org Tue May 31 06:56:19 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 31 May 2016 16:56:19 +1000 Subject: EDNS compliance of servers for the Alexa Top 1M Message-ID: <20160531065620.06DD84A5CD0D@rock.dv.isc.org> If you are a Alexa Top 1M entry or host the DNS for a Alexa Top 1M entry you should be paying attention. I'm focusing here on unknown EDNS option handling as ISC is about to release a version of named which will exercise these errors in your nameservers. BIND 9.11.0 will ship with EDNS COOKIE enabled by default (RFC 7873) which will appear to be a unknown EDNS option to servers that do not understand it. RFC 6891 states that unknown EDNS options should be ignored but that is not always the case. These answers are all for servers that nominally support EDNS. You can test your servers via https://ednscomp.isc.org Mark 232270 ednsopt=noopt Servers that only respond with a EDNS response if something else is in the EDNS query (DO=1, a known EDNS option e.g. ECS or NSID present). 220083 ednsopt=timeout The firewall is dropping queries with EDNS options present. THIS WILL CAUSE INTERMITTENT LOOKUP FAILURES. This stupidity needs to be fixed along with dropping queries due to unknown EDNS versions, unknown EDNS/DNS flags and unknown query types. 64945 ednsopt=formerr,echoed,nosoa Failed to ignore the EDNS option. This results in EDNS being disabled for the server and additional queries being made. If it is serving a signed zone this may result in PERMANENT lookup failures if all the available servers for the zone exibit this error. 30917 ednsopt=echoed This is a benign failure for DNS COOKIES but could result in errors for other options. 2142 ednsopt=noopt,nosoa This is similar to ednsopt=noopt but no SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. 1490 ednsopt=nosoa No SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. 774 ednsopt=badvers,nosoa BADVERS is supposed to be for EDNS version negotiation. Named will treat the server as not supporting EDNS. This results in additional queries being made. If it is serving a signed zone this may result in PERMANENT lookup failures if all the available servers for the zone exibit this error. 106 ednsopt=echoed,nosoa No SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. The echoed EDNS option is benign for DNS COOKIES but could result in errors for other options. 93 ednsopt=servfail,noopt,nosoa Possible a false positive due to the plain DNS query timing out or the server returning SERVFAIL. If the later this is unrecoverable and will result in lookup failures. 69 ednsopt=badversion Absolutely bizarre response as the EDNS version was non 0. Probably a proxy which is not EDNS version aware. 68 ednsopt=status,nosoa Unknown RCODE returned. 54 ednsopt=badversion,echoed Absolutely bizarre response as the EDNS version was non 0. Probably a proxy which is not EDNS version aware. 20 ednsopt=refused,nosoa Possible a false positive due to the plain DNS query timing out or the server returning REFUSED. If the later this is unrecoverable and will result in lookup failures. 14 ednsopt=status,noopt,nosoa Unknown RCODE returned. 14 ednsopt=formerr,nosoa This is similar to ednsopt=formerr,echoed,nosoa above. 13 ednsopt=nxdomain Possible a false positive due to the plain DNS query timing out or the server returning NXDOMAIN. If the later this is unrecoverable and will result in lookup failures. 9 ednsopt=servfail,nosoa This is similar to ednsopt=servfail,echoed,nosoa above. 6 ednsopt=formerr,echoed This is similar to ednsopt=formerr,echoed,nosoa above. 3 ednsopt=nxdomain,echoed,nosoa 2 ednsopt=nxdomain,noopt 1 ednsopt=refused,noopt,nosoa 1 ednsopt=formerr,badversion,echoed,nosoa -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hannigan at gmail.com Tue May 31 07:10:56 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 31 May 2016 09:10:56 +0200 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: CALEA isn't a type of request, it's a law that enabled par function access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF translation, three-way/off hook ops and the call content (not necessarily in that order). You can see the non national security activity here: On Sat, May 28, 2016 at 5:37 AM, Mike Joseph wrote: > I can say via firsthand knowledge that CALEA requests are definitely > happening and are not even that rare, proportional to a reasonably sized > subscriber-base. It would be unlawful for me to comment specifically on > any actual CALEA requests, however. But if you have general questions > about my observations, feel free to reach out directly. > > -MJ > > On Thu, May 12, 2016 at 11:28 AM, Brian Mengel wrote: > >> My comments were strictly limited to my understanding of CALEA as it >> applied to ISPs, not telcos. A request for a lawful intercept can entail >> mirroring a real time stream of all data sent to/from a customer's Internet >> connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this >> requires mediation before being sent to the LEA and it is the mediation >> server itself that initiates the intercept when so configured by the ISP. >> Perhaps some LEAs have undertaken the mediation function so as to >> facilitate these intercepts where the neither the ISP nor a third party can >> do so. If that were the case then very little would be needed on the part >> of the ISP in order to comply with a request for lawful intercept. I can >> say with certainty that these types of requests are being made of broadband >> ISPs though I agree that they are very rare. >> >> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: >> >> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel >> > wrote: >> > >> > AFAIK being able to do a lawful intercept on a specific, named, >> >> individual's service has been a requirement for providers since 2007. >> >> >> > >> > It's been required for longer than that. The telco I worked for over a >> > decade ago didn't build the infrastructure until the FCC said they were >> > going to stop funding upgrades. That really got 'em movin'. (suddenly >> "data >> > services" people -- i.e. ME -- weren't redheaded stepchildren.) >> > >> > have never heard of a provider, big or small, being called out for being >> >> unable to provide this service when requested. >> >> >> > >> > Where existing infrastructure is not already in place (read: >> T1/BRI/etc.), >> > the telco can take up to 60 days to get that setup. I know more than one >> > telco that used that grace period to actually setup CALEA in the first >> > place. >> > >> > did not perform intercepts routinely. >> >> >> > >> > The historic published figures (i've not looked in years) suggest CALEA >> > requests are statistically rare. The NC based telco I worked for had >> never >> > received an order in the then ~40yr life of the company. >> > >> > The mediation server needed to "mediate" between your customer >> aggregation >> >> box and the LEA is not inexpensive. >> >> >> > >> > And also is not the telco's problem. Mediation is done by the LEA or 3rd >> > party under contract to any number of agencies. For example, a telco tap >> > order would mirror the control and voice traffic of a POTS line (T1/PRI >> > channel, etc.) into a BRI or specific T1 channel. (dialup was later >> added, >> > but wasn't required in my era, so we didn't support it.) We used to test >> > that by tapping a tech's phone. Not having any mediation software, all I >> > could do is "yeap, it's sending data" and listen to the voice channels >> on a >> > t-berd. >> > >> > --Ricky >> > >> >> From hannigan at gmail.com Tue May 31 07:12:22 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 31 May 2016 09:12:22 +0200 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: Misfire. Sorry, early in the AM. The URL I intended to send is here: http://www.uscourts.gov/statistics-reports/wiretap-report-2014 Best, -M< On Tue, May 31, 2016 at 9:10 AM, Martin Hannigan wrote: > CALEA isn't a type of request, it's a law that enabled par function > access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF > translation, three-way/off hook ops and the call content (not > necessarily in that order). > > You can see the non national security activity here: > > > On Sat, May 28, 2016 at 5:37 AM, Mike Joseph wrote: >> I can say via firsthand knowledge that CALEA requests are definitely >> happening and are not even that rare, proportional to a reasonably sized >> subscriber-base. It would be unlawful for me to comment specifically on >> any actual CALEA requests, however. But if you have general questions >> about my observations, feel free to reach out directly. >> >> -MJ >> >> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel wrote: >> >>> My comments were strictly limited to my understanding of CALEA as it >>> applied to ISPs, not telcos. A request for a lawful intercept can entail >>> mirroring a real time stream of all data sent to/from a customer's Internet >>> connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this >>> requires mediation before being sent to the LEA and it is the mediation >>> server itself that initiates the intercept when so configured by the ISP. >>> Perhaps some LEAs have undertaken the mediation function so as to >>> facilitate these intercepts where the neither the ISP nor a third party can >>> do so. If that were the case then very little would be needed on the part >>> of the ISP in order to comply with a request for lawful intercept. I can >>> say with certainty that these types of requests are being made of broadband >>> ISPs though I agree that they are very rare. >>> >>> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: >>> >>> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel >>> > wrote: >>> > >>> > AFAIK being able to do a lawful intercept on a specific, named, >>> >> individual's service has been a requirement for providers since 2007. >>> >> >>> > >>> > It's been required for longer than that. The telco I worked for over a >>> > decade ago didn't build the infrastructure until the FCC said they were >>> > going to stop funding upgrades. That really got 'em movin'. (suddenly >>> "data >>> > services" people -- i.e. ME -- weren't redheaded stepchildren.) >>> > >>> > have never heard of a provider, big or small, being called out for being >>> >> unable to provide this service when requested. >>> >> >>> > >>> > Where existing infrastructure is not already in place (read: >>> T1/BRI/etc.), >>> > the telco can take up to 60 days to get that setup. I know more than one >>> > telco that used that grace period to actually setup CALEA in the first >>> > place. >>> > >>> > did not perform intercepts routinely. >>> >> >>> > >>> > The historic published figures (i've not looked in years) suggest CALEA >>> > requests are statistically rare. The NC based telco I worked for had >>> never >>> > received an order in the then ~40yr life of the company. >>> > >>> > The mediation server needed to "mediate" between your customer >>> aggregation >>> >> box and the LEA is not inexpensive. >>> >> >>> > >>> > And also is not the telco's problem. Mediation is done by the LEA or 3rd >>> > party under contract to any number of agencies. For example, a telco tap >>> > order would mirror the control and voice traffic of a POTS line (T1/PRI >>> > channel, etc.) into a BRI or specific T1 channel. (dialup was later >>> added, >>> > but wasn't required in my era, so we didn't support it.) We used to test >>> > that by tapping a tech's phone. Not having any mediation software, all I >>> > could do is "yeap, it's sending data" and listen to the voice channels >>> on a >>> > t-berd. >>> > >>> > --Ricky >>> > >>> >>> From job at instituut.net Tue May 31 08:27:33 2016 From: job at instituut.net (Job Snijders) Date: Tue, 31 May 2016 10:27:33 +0200 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: <20160531082733.GA1862@57.rev.meerval.net> On Mon, May 30, 2016 at 10:03:33PM -0700, Randy Bush wrote: > .-----------------. > | | > | B |--------- D > S ---------| A R | > | C |--------- (toward S) > | | > `-----------------' > > if the source of a traceroute from S toward D with TTL to expire on R, > and R's FIB wants to exit via C to get back to S (yes, virginia, the > internet is highly asymmetric), the source address of the time exceeded > message should be C. > > of course, simpletons such as i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. > > is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how > common is it? On most Linux the default behaviour is using source address "C", but this can be corrected by setting the following somewhere in your /etc/sysctl.d/ files: # make traceroute nice net.ipv4.icmp_errors_use_inbound_ifaddr=1 Kind regards, Job From morrowc.lists at gmail.com Tue May 31 14:31:44 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 31 May 2016 10:31:44 -0400 Subject: CALEA In-Reply-To: References: <8668D881-135D-4281-B65F-D6B6E3D8727B@mtin.net> <57323B6C.6060703@rivervalleyinternet.net> Message-ID: "Encryption The number of state wiretaps in which encryption was encountered decreased from 41 in 2013 to 22 in 2014. In two of these wiretaps, officials were unable to decipher the plain text of the messages. Three federal wiretaps were reported as being encrypted in 2014, of which two could not be decrypted. Encryption was also reported for five federal wiretaps that were conducted during previous years, but reported to the AO for the first time in 2014. Officials were able to decipher the plain text of the communications in four of the five intercepts." that's certainly interesting... On Tue, May 31, 2016 at 3:12 AM, Martin Hannigan wrote: > Misfire. Sorry, early in the AM. The URL I intended to send is here: > > http://www.uscourts.gov/statistics-reports/wiretap-report-2014 > > > Best, > > -M< > > On Tue, May 31, 2016 at 9:10 AM, Martin Hannigan > wrote: > > CALEA isn't a type of request, it's a law that enabled par function > > access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF > > translation, three-way/off hook ops and the call content (not > > necessarily in that order). > > > > You can see the non national security activity here: > > > > > > On Sat, May 28, 2016 at 5:37 AM, Mike Joseph wrote: > >> I can say via firsthand knowledge that CALEA requests are definitely > >> happening and are not even that rare, proportional to a reasonably sized > >> subscriber-base. It would be unlawful for me to comment specifically on > >> any actual CALEA requests, however. But if you have general questions > >> about my observations, feel free to reach out directly. > >> > >> -MJ > >> > >> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel > wrote: > >> > >>> My comments were strictly limited to my understanding of CALEA as it > >>> applied to ISPs, not telcos. A request for a lawful intercept can > entail > >>> mirroring a real time stream of all data sent to/from a customer's > Internet > >>> connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this > >>> requires mediation before being sent to the LEA and it is the mediation > >>> server itself that initiates the intercept when so configured by the > ISP. > >>> Perhaps some LEAs have undertaken the mediation function so as to > >>> facilitate these intercepts where the neither the ISP nor a third > party can > >>> do so. If that were the case then very little would be needed on the > part > >>> of the ISP in order to comply with a request for lawful intercept. I > can > >>> say with certainty that these types of requests are being made of > broadband > >>> ISPs though I agree that they are very rare. > >>> > >>> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: > >>> > >>> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel > >>> > wrote: > >>> > > >>> > AFAIK being able to do a lawful intercept on a specific, named, > >>> >> individual's service has been a requirement for providers since > 2007. > >>> >> > >>> > > >>> > It's been required for longer than that. The telco I worked for over > a > >>> > decade ago didn't build the infrastructure until the FCC said they > were > >>> > going to stop funding upgrades. That really got 'em movin'. (suddenly > >>> "data > >>> > services" people -- i.e. ME -- weren't redheaded stepchildren.) > >>> > > >>> > have never heard of a provider, big or small, being called out for > being > >>> >> unable to provide this service when requested. > >>> >> > >>> > > >>> > Where existing infrastructure is not already in place (read: > >>> T1/BRI/etc.), > >>> > the telco can take up to 60 days to get that setup. I know more than > one > >>> > telco that used that grace period to actually setup CALEA in the > first > >>> > place. > >>> > > >>> > did not perform intercepts routinely. > >>> >> > >>> > > >>> > The historic published figures (i've not looked in years) suggest > CALEA > >>> > requests are statistically rare. The NC based telco I worked for had > >>> never > >>> > received an order in the then ~40yr life of the company. > >>> > > >>> > The mediation server needed to "mediate" between your customer > >>> aggregation > >>> >> box and the LEA is not inexpensive. > >>> >> > >>> > > >>> > And also is not the telco's problem. Mediation is done by the LEA or > 3rd > >>> > party under contract to any number of agencies. For example, a telco > tap > >>> > order would mirror the control and voice traffic of a POTS line > (T1/PRI > >>> > channel, etc.) into a BRI or specific T1 channel. (dialup was later > >>> added, > >>> > but wasn't required in my era, so we didn't support it.) We used to > test > >>> > that by tapping a tech's phone. Not having any mediation software, > all I > >>> > could do is "yeap, it's sending data" and listen to the voice > channels > >>> on a > >>> > t-berd. > >>> > > >>> > --Ricky > >>> > > >>> > >>> > From owen at delong.com Tue May 31 14:35:30 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2016 07:35:30 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <20160531082733.GA1862@57.rev.meerval.net> References: <20160531082733.GA1862@57.rev.meerval.net> Message-ID: <19F3FF9B-1AA6-4836-ACD7-F862C6167433@delong.com> It seems to me that a plain text reading of RFC-1812 is as Randy describes undesirable. It also seems that the violation of this text is commonplace in actual implementations because of yet another time where operators have made it clear to developers that the IETF is silly. I like the Linux solution... Comply with the RFC by default and provide a knob to do the "right thing" if desired. Best of all would be to put forth an errata against RFC1813 to change the text to specify the inbound interface of the packet triggering the ICMP message when applicable. The behavior currently described should be preserved for ICMP packets which are not triggered by inbound packets. Owen > On May 31, 2016, at 01:27, Job Snijders wrote: > >> On Mon, May 30, 2016 at 10:03:33PM -0700, Randy Bush wrote: >> .-----------------. >> | | >> | B |--------- D >> S ---------| A R | >> | C |--------- (toward S) >> | | >> `-----------------' >> >> if the source of a traceroute from S toward D with TTL to expire on R, >> and R's FIB wants to exit via C to get back to S (yes, virginia, the >> internet is highly asymmetric), the source address of the time exceeded >> message should be C. >> >> of course, simpletons such as i would desire the source of the time >> exceeded message to be A. after all, this is the interface to which i >> sent the icmp with the TTL to expire. >> >> is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how >> common is it? > > On most Linux the default behaviour is using source address "C", but > this can be corrected by setting the following somewhere in your > /etc/sysctl.d/ files: > > # make traceroute nice > net.ipv4.icmp_errors_use_inbound_ifaddr=1 > > Kind regards, > > Job From bryn.sadler at essensys.tech Tue May 31 15:25:19 2016 From: bryn.sadler at essensys.tech (Bryn Sadler) Date: Tue, 31 May 2016 15:25:19 +0000 Subject: Akamai Geolocation Message-ID: <6C5D2852-1DFE-4257-8E3C-E2FC17D69A93@essensys.co.uk> Hi all, anyone on-list from Akamai that could help out with a Geolocation issue our customers are experiencing? We tried the support channels on the website. Many thanks, Bryn Sadler Chief Technical Officer T: +44 (0)20 3102 5254 M: +44 (0)7872 684 671 C: +1 (347) 558 2133 W: essensys.tech The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately by reply. essensys Ltd | 1 Triton Square Regents Place London NW1 3DX | Registration No. 05959557 essensys Inc | 450 7th Avenue Suite 2407 New York NY 10123 Please consider the environment when reading this email and only print a copy if you think it's really necessary. From bill at herrin.us Tue May 31 15:26:03 2016 From: bill at herrin.us (William Herrin) Date: Tue, 31 May 2016 11:26:03 -0400 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: On Tue, May 31, 2016 at 1:03 AM, Randy Bush wrote: > .-----------------. > | | > | B |--------- D > S ---------| A R | > | C |--------- (toward S) > | | > `-----------------' > > i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. Hi Randy, I've thought for a number of years that routers should have an "ip icmp-error-from" interface directive which allows the operator to specify the source address for ICMP errors messages generated due to packets received on that interface. The behavior you describe where the time-exceeded message comes from C instead of A is a nuisance. The RDNS gives you clues which point in the wrong direction. Darn. Guess you'll have to rely on the preceding router to tell you where the packet came from before it reached R. The behavior Mikael notes is more deadly. Bogon filters drop packets from RFC1918 sources. They aren't subtle enough to allow ICMP errors through while dropping other IP packets. With bogon filters in place, ICMP errors originated from RFC1918 space don't reach S. PMTUD dies and your TCP connections die along with it. It's really important that an Internet router not originate ICMP from 192.168.1.1! It would also have been nice if ICMP error messages had defined a text comment field where ops could place diagnostic information such as the received interface. Overloading the functionality of the layer-3 address for any purpose (such as hanging an RDNS entry with textual diagnostic information) is bad bad bad. Probably too late to shoehorn that in. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From octalnanog at alvarezp.org Tue May 31 16:08:42 2016 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Tue, 31 May 2016 09:08:42 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: References: Message-ID: <574DB70A.2010209@alvarezp.org> On 05/30/2016 10:03 PM, Randy Bush wrote: > rfc1812 says > > 4.3.2.4 ICMP Message Source Address > > Except where this document specifies otherwise, the IP source address > in an ICMP message originated by the router MUST be one of the IP > addresses associated with the physical interface over which the ICMP > message is transmitted. If the interface has no IP addresses > associated with it, the router's router-id (see Section [5.2.5]) is > used instead. > > some folk have interpreted this to mean that, if a router R has three > interfaces > > .-----------------. > | | > | B |--------- D > S ---------| A R | > | C |--------- (toward S) > | | > `-----------------' > > of course, simpletons such as i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. Do you mean the source address or the source interface? I'm not sure if you mean that, if sent through C it should have the source addres of A, or that it should actually be sent through A regardless of the routing table (which sounds better to me). Octavio. From hugo at slabnet.com Tue May 31 16:52:00 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 31 May 2016 09:52:00 -0700 Subject: rfc 1812 third party address on traceroute In-Reply-To: <574DB70A.2010209@alvarezp.org> References: <574DB70A.2010209@alvarezp.org> Message-ID: <20160531165200.GE6467@bamboo.slabnet.com> On Tue 2016-May-31 09:08:42 -0700, Octavio Alvarez wrote: >On 05/30/2016 10:03 PM, Randy Bush wrote: >> rfc1812 says >> >> 4.3.2.4 ICMP Message Source Address >> >> Except where this document specifies otherwise, the IP source address >> in an ICMP message originated by the router MUST be one of the IP >> addresses associated with the physical interface over which the ICMP >> message is transmitted. If the interface has no IP addresses >> associated with it, the router's router-id (see Section [5.2.5]) is >> used instead. >> >> some folk have interpreted this to mean that, if a router R has three >> interfaces >> >> .-----------------. >> | | >> | B |--------- D >> S ---------| A R | >> | C |--------- (toward S) >> | | >> `-----------------' >> >> of course, simpletons such as i would desire the source of the time >> exceeded message to be A. after all, this is the interface to which i >> sent the icmp with the TTL to expire. > >Do you mean the source address or the source interface? > >I'm not sure if you mean that, if sent through C it should have the >source addres of A, or that it should actually be sent through A >regardless of the routing table (which sounds better to me). How is the latter better? What guarantees are there that the adjacent L3 device on R's interface A has a route for S and if such a route exists that it doesn't simply point at R? As Randy so eloquently put it: >> (yes, virginia, the internet is highly asymmetric) > >Octavio. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From lorell at hathcock.org Tue May 31 18:14:17 2016 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 31 May 2016 13:14:17 -0500 Subject: ISP License in the USA? Message-ID: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> NANOG: Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. He is suggesting COALS with which I am completely unfamiliar. Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. Thanks, Lorell Hathcock From bill at herrin.us Tue May 31 18:22:36 2016 From: bill at herrin.us (William Herrin) Date: Tue, 31 May 2016 14:22:36 -0400 Subject: rfc 1812 third party address on traceroute In-Reply-To: <574DB70A.2010209@alvarezp.org> References: <574DB70A.2010209@alvarezp.org> Message-ID: On Tue, May 31, 2016 at 12:08 PM, Octavio Alvarez wrote: >> .-----------------. >> | | >> | B |--------- D >> S ---------| A R | >> | C |--------- (toward S) >> | | >> `-----------------' > I'm not sure if you mean that, if sent through C it should have the > source addres of A, or that it should actually be sent through A > regardless of the routing table (which sounds better to me). Howdy, That doesn't make sense. There may be multiple next hops out A. If the next hop in the FIB is out C, how would the router pick the next hop to send to out A? Anyway, Randy's comment was about source address selection, not routing. With the packet coming from S into interface A, he'd prefer that the ICMP error message be sourced from the IP address assigned to A, not the IP address assigned to C or R. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From dwhite at olp.net Tue May 31 18:24:35 2016 From: dwhite at olp.net (Dan White) Date: Tue, 31 May 2016 13:24:35 -0500 Subject: ISP License in the USA? In-Reply-To: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <20160531182435.GD8834@dan.olp.net> Not familiar with the process, but look at E-rate if you want to provide service to schools, libraries and health providers. On 05/31/16?13:14?-0500, Lorell Hathcock wrote: >NANOG: > >Our owner has hired a consultant who insists that we should have an ISP >license to operate in the United States. (Like they have in other countries >like Germany and in Africa where he has extensive personal experience.) > >I am asking him to tell me which license we should have because I don't know >of a license that we are required to have to route IP traffic to end >customers. > >I am familiar with CLEC status filed with our state. But it is not a >requirement to pass traffic. > >He is suggesting COALS with which I am completely unfamiliar. > >Can anyone tell me if there is a Texas state and/or USA Federal license for >a small operator to pass IP traffic from the internet to end users >(commercial and/or residential). > >I am aware that there are some CALEA requirements of ISPs that seem to kick >in once a CALEA request is made, but is that different from a license. -- Dan White BTC Broadband From ray at orsiniit.com Tue May 31 18:31:43 2016 From: ray at orsiniit.com (Ray Orsini) Date: Tue, 31 May 2016 14:31:43 -0400 Subject: ISP License in the USA? In-Reply-To: <20160531182435.GD8834@dan.olp.net> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: Just to clarify. You don't need a SPIN (e-rate Service Provider Identification Number) to provide service to those entities. You only need a SPIN to qualify for USF/USAC funding for those entities. If they want to pay full price (which some do) you don't need the SPIN. Applying for a SPIN is extremely easy. Applying for e-rate funding, on the other hand, is usually best done via a consultant. Thankfully that's the customer's problem, not yours. Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan White Sent: Tuesday, May 31, 2016 2:25 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: ISP License in the USA? Not familiar with the process, but look at E-rate if you want to provide service to schools, libraries and health providers. On 05/31/16 13:14 -0500, Lorell Hathcock wrote: >NANOG: > >Our owner has hired a consultant who insists that we should have an ISP >license to operate in the United States. (Like they have in other >countries like Germany and in Africa where he has extensive personal >experience.) > >I am asking him to tell me which license we should have because I don't >know of a license that we are required to have to route IP traffic to >end customers. > >I am familiar with CLEC status filed with our state. But it is not a >requirement to pass traffic. > >He is suggesting COALS with which I am completely unfamiliar. > >Can anyone tell me if there is a Texas state and/or USA Federal license >for a small operator to pass IP traffic from the internet to end users >(commercial and/or residential). > >I am aware that there are some CALEA requirements of ISPs that seem to >kick in once a CALEA request is made, but is that different from a license. -- Dan White BTC Broadband From Curtis.Starnes at granburyisd.org Tue May 31 18:34:06 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 31 May 2016 18:34:06 +0000 Subject: ISP License in the USA? In-Reply-To: <20160531182435.GD8834@dan.olp.net> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: E-Rate is more of a "discounted" rate process than a license. I work for a mid-sized school district and apply for and are granted E-Rate funding every year. So from the end user stand point not as a transit ISP, E-Rate would not apply. Curtis Starnes Senior Network Administrator Granbury ISD 600 W. Bridge St. Ste. 40 Granbury, Texas? 76048 (817) 408-4104 (817) 408-4126 Fax curtis.starnes at granburyisd.org www.granburyisd.org ? ? OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan White Sent: Tuesday, May 31, 2016 1:25 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: ISP License in the USA? Not familiar with the process, but look at E-rate if you want to provide service to schools, libraries and health providers. On 05/31/16?13:14?-0500, Lorell Hathcock wrote: >NANOG: > >Our owner has hired a consultant who insists that we should have an ISP >license to operate in the United States. (Like they have in other >countries like Germany and in Africa where he has extensive personal >experience.) > >I am asking him to tell me which license we should have because I don't >know of a license that we are required to have to route IP traffic to >end customers. > >I am familiar with CLEC status filed with our state. But it is not a >requirement to pass traffic. > >He is suggesting COALS with which I am completely unfamiliar. > >Can anyone tell me if there is a Texas state and/or USA Federal license >for a small operator to pass IP traffic from the internet to end users >(commercial and/or residential). > >I am aware that there are some CALEA requirements of ISPs that seem to >kick in once a CALEA request is made, but is that different from a license. -- Dan White BTC Broadband From Curtis.Starnes at granburyisd.org Tue May 31 18:35:45 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 31 May 2016 18:35:45 +0000 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: +1 on the SPIN, when we file our e-Rate form 470 and form 471's each year with USAC, we have to provide our carrier's SPIN on these forms. Curtis Starnes Senior Network Administrator Granbury ISD 600 W. Bridge St. Ste. 40 Granbury, Texas? 76048 (817) 408-4104 (817) 408-4126 Fax curtis.starnes at granburyisd.org www.granburyisd.org ? ? OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Orsini Sent: Tuesday, May 31, 2016 1:32 PM To: Dan White ; Lorell Hathcock Cc: NANOG list Subject: RE: ISP License in the USA? Just to clarify. You don't need a SPIN (e-rate Service Provider Identification Number) to provide service to those entities. You only need a SPIN to qualify for USF/USAC funding for those entities. If they want to pay full price (which some do) you don't need the SPIN. Applying for a SPIN is extremely easy. Applying for e-rate funding, on the other hand, is usually best done via a consultant. Thankfully that's the customer's problem, not yours. Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan White Sent: Tuesday, May 31, 2016 2:25 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: ISP License in the USA? Not familiar with the process, but look at E-rate if you want to provide service to schools, libraries and health providers. On 05/31/16 13:14 -0500, Lorell Hathcock wrote: >NANOG: > >Our owner has hired a consultant who insists that we should have an ISP >license to operate in the United States. (Like they have in other >countries like Germany and in Africa where he has extensive personal >experience.) > >I am asking him to tell me which license we should have because I don't >know of a license that we are required to have to route IP traffic to >end customers. > >I am familiar with CLEC status filed with our state. But it is not a >requirement to pass traffic. > >He is suggesting COALS with which I am completely unfamiliar. > >Can anyone tell me if there is a Texas state and/or USA Federal license >for a small operator to pass IP traffic from the internet to end users >(commercial and/or residential). > >I am aware that there are some CALEA requirements of ISPs that seem to >kick in once a CALEA request is made, but is that different from a license. -- Dan White BTC Broadband From faisal at snappytelecom.net Tue May 31 18:42:46 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 31 May 2016 18:42:46 +0000 (GMT) Subject: ISP License in the USA? In-Reply-To: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <649583514.348940.1464720166111.JavaMail.zimbra@snappytelecom.net> >>> > He is suggesting COALS ......... as in lumps of coals, is what you are going to get on christmas from him, if he does not get this gig ! :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Lorell Hathcock" > To: "nanog list" > Sent: Tuesday, May 31, 2016 2:14:17 PM > Subject: ISP License in the USA? > NANOG: > > > > Our owner has hired a consultant who insists that we should have an ISP > license to operate in the United States. (Like they have in other countries > like Germany and in Africa where he has extensive personal experience.) > > > > I am asking him to tell me which license we should have because I don't know > of a license that we are required to have to route IP traffic to end > customers. > > > > I am familiar with CLEC status filed with our state. But it is not a > requirement to pass traffic. > > > > He is suggesting COALS with which I am completely unfamiliar. > > > > Can anyone tell me if there is a Texas state and/or USA Federal license for > a small operator to pass IP traffic from the internet to end users > (commercial and/or residential). > > > > I am aware that there are some CALEA requirements of ISPs that seem to kick > in once a CALEA request is made, but is that different from a license. > > > > Thanks, > > > > Lorell Hathcock From dmburgess at linktechs.net Tue May 31 18:53:08 2016 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 31 May 2016 18:53:08 +0000 Subject: ISP License in the USA? In-Reply-To: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: I would suggest getting a new consultant .. :) Possible Acronyms College of Arts and Letters (Missouri State University; Springfield, MO) Cartridge Overall Length (shooting) Client Object Access Layer Circle of Acro Lovers Columbus Ohio Area Local Consolidated Operational Activities List Customer Order Acceptance List Common Operational Activities List (US Navy) Chance of a Lifetime (raffle) Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock Sent: Tuesday, May 31, 2016 1:14 PM To: 'NANOG list' Subject: ISP License in the USA? NANOG: Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. He is suggesting COALS with which I am completely unfamiliar. Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. Thanks, Lorell Hathcock From sean at donelan.com Tue May 31 18:54:30 2016 From: sean at donelan.com (Sean Donelan) Date: Tue, 31 May 2016 14:54:30 -0400 (EDT) Subject: ISP License in the USA? In-Reply-To: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: On Tue, 31 May 2016, Lorell Hathcock wrote: > Our owner has hired a consultant who insists that we should have an ISP > license to operate in the United States. (Like they have in other countries > like Germany and in Africa where he has extensive personal experience.) > > I am asking him to tell me which license we should have because I don't know > of a license that we are required to have to route IP traffic to end > customers. > I am familiar with CLEC status filed with our state. But it is not a > requirement to pass traffic. > > He is suggesting COALS with which I am completely unfamiliar. > > Can anyone tell me if there is a Texas state and/or USA Federal license for > a small operator to pass IP traffic from the internet to end users > (commercial and/or residential). > > I am aware that there are some CALEA requirements of ISPs that seem to kick > in once a CALEA request is made, but is that different from a license. As always, you should consult with your company's attorney or legal advisor. ISP's do not have a seperate license in the USA (besides normal business and tax licenses). COALS refers to cable operators and multichannel video programming distributors. CLEC refers to competitive local exchange carriers (i.e. telephone and private line circuits). Wireless ISPs may need a FCC radio frequency license for high power or exclusive use of radio frequencies. Low-powered Wi-Fi doesn't need a license. Generally you need some kind of permission or license to install facilities in a public right of way or exclusive use of public airwaves. ISPs can lease those facilities from licensed operators, and don't need a license themselves. In practice, most cable operators and telephone companies are also "self-provisioned" ISPs. They have "license" from a state and/or FCC; but that's because they are cable or telephone companies installing telecommunication facilities in public rights of way, not because they are ISPs. From eric at flanery.us Tue May 31 18:54:38 2016 From: eric at flanery.us (Eric Flanery (eric)) Date: Tue, 31 May 2016 11:54:38 -0700 Subject: ISP License in the USA? In-Reply-To: <20160531182435.GD8834@dan.olp.net> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: There is no such thing as an 'ISP license' in the US. I have a hard time imagining Texas of all places would have such a requirement. Depending on what exactly you are doing, there are various and highly varied requirements, such as acquiring a SPIN number for E-Rate, filing FCC 477 if you do broadband, FCC 499 if you do VoIP (CLEC and ETC also apply there), a FRN if you do pretty much anything FCC-related, various sorts of licenses for most radio/microwave systems (excepting part 15 stuff), CALEA, open internet, etc... COALS _could_ apply _if_ you are running a cable TV system that also delivers data services, but it isn't an 'ISP thing'. More to the point... I wouldn't take US legal advice from any consultant not familiar with US law, or really any non-lawyer consultant at all. I wouldn't take it from NANOG either; while it's a tremendous technical resource, it is not your attorney. There are a number of telecommunications focused law firms out there, with knowledgeable lawyers. It would be a good idea to establish a relationship with one, if you intend to enter the increasingly complex legal minefield of being an ISP. --Eric On Tue, May 31, 2016 at 11:24 AM, Dan White wrote: > Not familiar with the process, but look at E-rate if you want to provide > service to schools, libraries and health providers. > > > On 05/31/16 13:14 -0500, Lorell Hathcock wrote: > >> NANOG: >> >> Our owner has hired a consultant who insists that we should have an ISP >> license to operate in the United States. (Like they have in other >> countries >> like Germany and in Africa where he has extensive personal experience.) >> >> I am asking him to tell me which license we should have because I don't >> know >> of a license that we are required to have to route IP traffic to end >> customers. >> >> I am familiar with CLEC status filed with our state. But it is not a >> requirement to pass traffic. >> >> He is suggesting COALS with which I am completely unfamiliar. >> >> Can anyone tell me if there is a Texas state and/or USA Federal license >> for >> a small operator to pass IP traffic from the internet to end users >> (commercial and/or residential). >> >> I am aware that there are some CALEA requirements of ISPs that seem to >> kick >> in once a CALEA request is made, but is that different from a license. >> > > -- > Dan White > BTC Broadband > From dustin at rseng.net Tue May 31 19:05:29 2016 From: dustin at rseng.net (Dustin Jurman) Date: Tue, 31 May 2016 19:05:29 +0000 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: Local Business License. Dustin -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dennis Burgess Sent: Tuesday, May 31, 2016 2:53 PM To: North American Network Operators' Group Subject: RE: ISP License in the USA? I would suggest getting a new consultant .. :) Possible Acronyms College of Arts and Letters (Missouri State University; Springfield, MO) Cartridge Overall Length (shooting) Client Object Access Layer Circle of Acro Lovers Columbus Ohio Area Local Consolidated Operational Activities List Customer Order Acceptance List Common Operational Activities List (US Navy) Chance of a Lifetime (raffle) Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock Sent: Tuesday, May 31, 2016 1:14 PM To: 'NANOG list' Subject: ISP License in the USA? NANOG: Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. He is suggesting COALS with which I am completely unfamiliar. Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. Thanks, Lorell Hathcock From mfidelman at meetinghouse.net Tue May 31 19:05:56 2016 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 31 May 2016 15:05:56 -0400 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> On 5/31/16 2:53 PM, Dennis Burgess wrote: > I would suggest getting a new consultant .. :) > What Dennis said. > Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) But only if you provide: - facilities-based broadband services, and/or, - provide wired or fixed wireless local exchange telephone service - provide interconnected VoIP service - provide facilities based wireless telephony (see https://transition.fcc.gov/form477/WhoMustFileForm477.pdf) If you provide basic dial-up services, or wireless Internet over unlicensed channels - there's no licensing requirement whatever. As Dennis said - first get a new consultant. Look for one who can work through your service model - what you're going to be selling, to whom, using what technology(ies) - and work from there to whatever licenses (if any) that you require. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From web at typo.org Tue May 31 19:12:03 2016 From: web at typo.org (Wayne Bouchard) Date: Tue, 31 May 2016 12:12:03 -0700 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531182435.GD8834@dan.olp.net> Message-ID: <20160531191203.GA81087@spider.typo.org> +1 Do not confuse a desire from some party you wish to do business saying, "Our own consultants have said that we shouldn't do business with anyone not compliant with these standards," as a requirement for licensure. Bureaucrats simply like certificates and that's all this really boils down to, a way for consultants and/or politicians to meddle in both ends of what has previously been a pretty open process, creating a solution in search of a problem and adding complexity where it's generally not needed. In fine, the only thing you need in the US to be an ISP is a network. The rest is mostly all about trying to get customers from one section or another of business or of the general public. -Wayne On Tue, May 31, 2016 at 11:54:38AM -0700, Eric Flanery (eric) wrote: > There is no such thing as an 'ISP license' in the US. I have a hard time > imagining Texas of all places would have such a requirement. > > Depending on what exactly you are doing, there are various and highly > varied requirements, such as acquiring a SPIN number for E-Rate, filing FCC > 477 if you do broadband, FCC 499 if you do VoIP (CLEC and ETC also apply > there), a FRN if you do pretty much anything FCC-related, various sorts of > licenses for most radio/microwave systems (excepting part 15 stuff), CALEA, > open internet, etc... > > COALS _could_ apply _if_ you are running a cable TV system that also > delivers data services, but it isn't an 'ISP thing'. > > More to the point... > > I wouldn't take US legal advice from any consultant not familiar with US > law, or really any non-lawyer consultant at all. I wouldn't take it from > NANOG either; while it's a tremendous technical resource, it is not your > attorney. > > There are a number of telecommunications focused law firms out there, with > knowledgeable lawyers. It would be a good idea to establish a relationship > with one, if you intend to enter the increasingly complex legal minefield > of being an ISP. > > --Eric > > On Tue, May 31, 2016 at 11:24 AM, Dan White wrote: > > > Not familiar with the process, but look at E-rate if you want to provide > > service to schools, libraries and health providers. > > > > > > On 05/31/16 13:14 -0500, Lorell Hathcock wrote: > > > >> NANOG: > >> > >> Our owner has hired a consultant who insists that we should have an ISP > >> license to operate in the United States. (Like they have in other > >> countries > >> like Germany and in Africa where he has extensive personal experience.) > >> > >> I am asking him to tell me which license we should have because I don't > >> know > >> of a license that we are required to have to route IP traffic to end > >> customers. > >> > >> I am familiar with CLEC status filed with our state. But it is not a > >> requirement to pass traffic. > >> > >> He is suggesting COALS with which I am completely unfamiliar. > >> > >> Can anyone tell me if there is a Texas state and/or USA Federal license > >> for > >> a small operator to pass IP traffic from the internet to end users > >> (commercial and/or residential). > >> > >> I am aware that there are some CALEA requirements of ISPs that seem to > >> kick > >> in once a CALEA request is made, but is that different from a license. > >> > > > > -- > > Dan White > > BTC Broadband > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From Curtis.Starnes at granburyisd.org Tue May 31 19:12:07 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 31 May 2016 19:12:07 +0000 Subject: ISP License in the USA? In-Reply-To: <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> Message-ID: Maybe the consultant is confusing "licensing" with IP address allocations from ARIN. Curtis Starnes Senior Network Administrator Granbury ISD 600 W. Bridge St. Ste. 40 Granbury, Texas? 76048 (817) 408-4104 (817) 408-4126 Fax curtis.starnes at granburyisd.org www.granburyisd.org ? ? OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Miles Fidelman Sent: Tuesday, May 31, 2016 2:06 PM To: nanog at nanog.org Subject: Re: ISP License in the USA? On 5/31/16 2:53 PM, Dennis Burgess wrote: > I would suggest getting a new consultant .. :) > What Dennis said. > Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) But only if you provide: - facilities-based broadband services, and/or, - provide wired or fixed wireless local exchange telephone service - provide interconnected VoIP service - provide facilities based wireless telephony (see https://transition.fcc.gov/form477/WhoMustFileForm477.pdf) If you provide basic dial-up services, or wireless Internet over unlicensed channels - there's no licensing requirement whatever. As Dennis said - first get a new consultant. Look for one who can work through your service model - what you're going to be selling, to whom, using what technology(ies) - and work from there to whatever licenses (if any) that you require. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From web at typo.org Tue May 31 19:14:38 2016 From: web at typo.org (Wayne Bouchard) Date: Tue, 31 May 2016 12:14:38 -0700 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <20160531191438.GB81087@spider.typo.org> Well, now you're talking tax ID or, rather, a general license to operate a commercial enterprise, not a specific license related to ISPs. On Tue, May 31, 2016 at 07:05:29PM +0000, Dustin Jurman wrote: > Local Business License. > > Dustin > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dennis Burgess > Sent: Tuesday, May 31, 2016 2:53 PM > To: North American Network Operators' Group > Subject: RE: ISP License in the USA? > > I would suggest getting a new consultant .. :) > > Possible Acronyms > > College of Arts and Letters (Missouri State University; Springfield, MO) > Cartridge Overall Length (shooting) > Client Object Access Layer > Circle of Acro Lovers > Columbus Ohio Area Local > Consolidated Operational Activities List Customer Order Acceptance List > Common Operational Activities List (US Navy) > Chance of a Lifetime (raffle) > > Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) > > > www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock > Sent: Tuesday, May 31, 2016 1:14 PM > To: 'NANOG list' > Subject: ISP License in the USA? > > NANOG: > > > > Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) > > > > I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. > > > > I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. > > > > He is suggesting COALS with which I am completely unfamiliar. > > > > Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). > > > > I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. > > > > Thanks, > > > > Lorell Hathcock > > > > > > > > > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From Curtis.Starnes at granburyisd.org Tue May 31 19:29:28 2016 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 31 May 2016 19:29:28 +0000 Subject: ISP License in the USA? In-Reply-To: <20160531191438.GB81087@spider.typo.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <20160531191438.GB81087@spider.typo.org> Message-ID: I've got it! Send $25,000 and I will print you a shiny new license to hang on the wall! Curtis Starnes Senior Network Administrator Granbury ISD 600 W. Bridge St. Ste. 40 Granbury, Texas? 76048 (817) 408-4104 (817) 408-4126 Fax curtis.starnes at granburyisd.org www.granburyisd.org ? ? OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Wayne Bouchard Sent: Tuesday, May 31, 2016 2:15 PM To: Dustin Jurman Cc: North American Network Operators' Group Subject: Re: ISP License in the USA? Well, now you're talking tax ID or, rather, a general license to operate a commercial enterprise, not a specific license related to ISPs. On Tue, May 31, 2016 at 07:05:29PM +0000, Dustin Jurman wrote: > Local Business License. > > Dustin > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dennis > Burgess > Sent: Tuesday, May 31, 2016 2:53 PM > To: North American Network Operators' Group > Subject: RE: ISP License in the USA? > > I would suggest getting a new consultant .. :) > > Possible Acronyms > > College of Arts and Letters (Missouri State University; Springfield, MO) > Cartridge Overall Length (shooting) > Client Object Access Layer > Circle of Acro Lovers > Columbus Ohio Area Local > Consolidated Operational Activities List Customer Order Acceptance List > Common Operational Activities List (US Navy) > Chance of a Lifetime (raffle) > > Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) > > > www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell > Hathcock > Sent: Tuesday, May 31, 2016 1:14 PM > To: 'NANOG list' > Subject: ISP License in the USA? > > NANOG: > > > > Our owner has hired a consultant who insists that we should have an > ISP license to operate in the United States. (Like they have in other > countries like Germany and in Africa where he has extensive personal > experience.) > > > > I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. > > > > I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. > > > > He is suggesting COALS with which I am completely unfamiliar. > > > > Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). > > > > I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. > > > > Thanks, > > > > Lorell Hathcock > > > > > > > > > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From SNaslund at medline.com Tue May 31 19:58:12 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 31 May 2016 19:58:12 +0000 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401E6616426@MUNPRDMBXA1.medline.com> What you have been hearing so far is correct. You do not need a license to be an ISP other than normal business licenses in your municipality/state. The only thing I can think of would be if you were a voice carrier or wanted to become a CLEC which would give you better/cheaper access to local infrastructure via interconnection agreements (like local loops for DSL and duct/conduit access for building out your own fiber network). I can tell you that the CLEC route is pretty expensive and has quite extensive regulatory hurdles at both the state and federal level. If you are a pure data ISP (i.e. not originating voice services) running on leased access circuits there is not much more you should need to do. Of course, you could and should ask this same question of your state's communications commission if you need a legally sound opinion on this. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan Sent: Tuesday, May 31, 2016 1:55 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: ISP License in the USA? On Tue, 31 May 2016, Lorell Hathcock wrote: > Our owner has hired a consultant who insists that we should have an > ISP license to operate in the United States. (Like they have in other > countries like Germany and in Africa where he has extensive personal > experience.) > > I am asking him to tell me which license we should have because I > don't know of a license that we are required to have to route IP > traffic to end customers. > I am familiar with CLEC status filed with our state. But it is not a > requirement to pass traffic. > > He is suggesting COALS with which I am completely unfamiliar. > > Can anyone tell me if there is a Texas state and/or USA Federal > license for a small operator to pass IP traffic from the internet to > end users (commercial and/or residential). > > I am aware that there are some CALEA requirements of ISPs that seem to > kick in once a CALEA request is made, but is that different from a license. As always, you should consult with your company's attorney or legal advisor. ISP's do not have a seperate license in the USA (besides normal business and tax licenses). COALS refers to cable operators and multichannel video programming distributors. CLEC refers to competitive local exchange carriers (i.e. telephone and private line circuits). Wireless ISPs may need a FCC radio frequency license for high power or exclusive use of radio frequencies. Low-powered Wi-Fi doesn't need a license. Generally you need some kind of permission or license to install facilities in a public right of way or exclusive use of public airwaves. ISPs can lease those facilities from licensed operators, and don't need a license themselves. In practice, most cable operators and telephone companies are also "self-provisioned" ISPs. They have "license" from a state and/or FCC; but that's because they are cable or telephone companies installing telecommunication facilities in public rights of way, not because they are ISPs. From dmburgess at linktechs.net Tue May 31 20:07:49 2016 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 31 May 2016 20:07:49 +0000 Subject: craigslist.com admin Message-ID: Looking for a craigslist.com admin to connect with offlist about a block :) [DennisBurgessSignature] www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net From bill at herrin.us Tue May 31 20:16:26 2016 From: bill at herrin.us (William Herrin) Date: Tue, 31 May 2016 16:16:26 -0400 Subject: ISP License in the USA? In-Reply-To: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: On Tue, May 31, 2016 at 2:14 PM, Lorell Hathcock wrote: > Our owner has hired a consultant who insists that we should have an ISP > license to operate in the United States. (Like they have in other countries > like Germany and in Africa where he has extensive personal experience.) Howdy, There is generally no license required to be an ISP. If you wish to own physical infrastructure located in the public right of ways or use licensed radio frequencies, there are various licensing and regulatory requirements. We call those "cable companies," "telcos," "LECs," or "CLECs" even if they also provide ISP service. If you lease your long-haul cabling infrastructure (from folks who are licensed) or implement physical infrastructure only on property you own or lease, you need not address licensing yourself. > He is suggesting COALS with which I am completely unfamiliar. https://apps.fcc.gov/coals/ That's if you want to be a cable TV operator (plus Internet). Unless you're planning to run your own coax on the telephone poles, you don't need that. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jared at puck.nether.net Tue May 31 20:30:52 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 31 May 2016 16:30:52 -0400 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: <85016CFB-A22B-4DC7-ABE5-D21FFA5448DE@puck.nether.net> > On May 31, 2016, at 4:16 PM, William Herrin wrote: > > On Tue, May 31, 2016 at 2:14 PM, Lorell Hathcock wrote: >> Our owner has hired a consultant who insists that we should have an ISP >> license to operate in the United States. (Like they have in other countries >> like Germany and in Africa where he has extensive personal experience.) > > Howdy, > > There is generally no license required to be an ISP. > > If you wish to own physical infrastructure located in the public right > of ways or use licensed radio frequencies, there are various licensing > and regulatory requirements. > > We call those "cable companies," "telcos," "LECs," or "CLECs" even if > they also provide ISP service. > > If you lease your long-haul cabling infrastructure (from folks who are > licensed) or implement physical infrastructure only on property you > own or lease, you need not address licensing yourself. In some cases it?s very simple to do something, in Michigan (for example) you can run fiber and place items in the right of way by meeting the standards of a Metro Permit, eg: http://www.michigan.gov/lcsa/0,5798,7-333-23730-221070--,00.html For most places, you just need to pay the state or local licensing fees. You can generally do this for low cost, setting up a new C-corp or LLC is $50 to file in my area. Well worth it if you just want to establish yourself as a legal entity. Then you can do business with that and usual minimal paperwork. You can pay hundreds to nearly infinite money to establish your structure(s). You do need to have some sort of TIN or EIN. This gets complex and imposes requirements, consult an accountant, CPA or lawyer as well in this area. It shouldn?t be more than $1k to establish the legal entity unless there are very complex situations involved. https://www.irs.gov/businesses/small-businesses-self-employed/apply-for-an-employer-identification-number-ein-online Unless you are offering certain regulated services, the bar is quite low to establish a company and maintain yourself. I?d say when possible avoid complex programs, they tend to come with high reporting and auditing costs. - Jared From owen at delong.com Tue May 31 20:46:50 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2016 13:46:50 -0700 Subject: ISP License in the USA? In-Reply-To: References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> Message-ID: Not necessarily? If you aren?t a facilities-based carrier: https://transition.fcc.gov/form477/WhoMustFileForm477.pdf You don?t need to. Owen > On May 31, 2016, at 11:53 , Dennis Burgess wrote: > > I would suggest getting a new consultant .. :) > > Possible Acronyms > > College of Arts and Letters (Missouri State University; Springfield, MO) > Cartridge Overall Length (shooting) > Client Object Access Layer > Circle of Acro Lovers > Columbus Ohio Area Local > Consolidated Operational Activities List > Customer Order Acceptance List > Common Operational Activities List (US Navy) > Chance of a Lifetime (raffle) > > Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) > > > www.linktechs.net - 314-735-0270 x103 - dmburgess at linktechs.net > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock > Sent: Tuesday, May 31, 2016 1:14 PM > To: 'NANOG list' > Subject: ISP License in the USA? > > NANOG: > > > > Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) > > > > I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. > > > > I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. > > > > He is suggesting COALS with which I am completely unfamiliar. > > > > Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). > > > > I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. > > > > Thanks, > > > > Lorell Hathcock > > > > > > > > > > > From owen at delong.com Tue May 31 20:48:24 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 31 May 2016 13:48:24 -0700 Subject: ISP License in the USA? In-Reply-To: <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> References: <068e01d1bb68$3ebdbcf0$bc3936d0$@hathcock.org> <90726ac6-9462-2cbe-680e-c11614e7c81e@meetinghouse.net> Message-ID: <01ABE89A-37ED-409C-81F7-5F1F9CC00C97@delong.com> > On May 31, 2016, at 12:05 , Miles Fidelman wrote: > > On 5/31/16 2:53 PM, Dennis Burgess wrote: > >> I would suggest getting a new consultant .. :) >> > What Dennis said. > >> Lol got me! There is nothing that I know of that you have to "license" to become a ISP in the US of A. . You do have to fill out Form 477 twice a year. :) > > But only if you provide: > - facilities-based broadband services, and/or, > - provide wired or fixed wireless local exchange telephone service > - provide interconnected VoIP service > - provide facilities based wireless telephony > (see https://transition.fcc.gov/form477/WhoMustFileForm477.pdf) > > If you provide basic dial-up services, or wireless Internet over unlicensed channels - there's no licensing requirement whatever. This also applies if you are applying over unbundled elements or other leased facilities AIUI. Owen