From mohta at necom830.hpcl.titech.ac.jp Sun Sep 1 00:04:03 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 1 Sep 2019 09:04:03 +0900 Subject: Weekly Routing Table Report In-Reply-To: <328481.1567294462@turing-police> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <328481.1567294462@turing-police> Message-ID: <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> Valdis Klētnieks wrote: >> The solution is: >> >> https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 > > All I see there is some handwaving about separating something from > something else, without even a description of why it was better than > what was available when you wrote the draft. Read the first three paragraphs of abstract of the draft: This memo describes the architecture of end to end multihoming. End to end multihoming does not burden routing system for multihoming. That is, even extensive use of end to end multihoming does not increase the number of entries in a global routing table. Traditionally with IPv4, multihoming capability is offered by an intelligent routing system, which, as is always the case with violating the end to end principle, lacks scalability on a global routing table size and robustness against link failures. On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. > I don't see anything about how it's supposed to work - for example, if my cell > phone had an IP address via DHCP from my home wireless router but also has an > IPv6 from cellular connection, how *exactly* does it *securely* fall back to > cellular if a thunderstorn knocks out Comcast's gear in the area? Read the title of the draft. The draft is not intended to describe protocol details. There are other articles, some of which are peer reviewed papers, describing details. But, first thing for you to do is to read the title and the abstract section of the architectural draft > Try attaching an actual protocol specification Read the title of the draft. Masataka Ohta From ross at tajvar.io Sun Sep 1 00:21:41 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 31 Aug 2019 20:21:41 -0400 Subject: Weekly Routing Table Report In-Reply-To: <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <328481.1567294462@turing-police> <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> Message-ID: > There are other articles, some of which are peer reviewed papers, > describing details. Can you link those? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Sun Sep 1 00:58:29 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 1 Sep 2019 09:58:29 +0900 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <328481.1567294462@turing-police> <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> Message-ID: On 2019/09/01 9:21, Ross Tajvar wrote: >> There are other articles, some of which are peer reviewed papers, >> describing details. > > Can you link those? For detailed example of modified TCP: https://tools.ietf.org/html/draft-arifumi-tcp-mh-00 For automatic renumbering: https://dl.acm.org/citation.cfm?id=2089037 Masataka Ohta From owen at delong.com Sun Sep 1 01:27:49 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 31 Aug 2019 18:27:49 -0700 Subject: Weekly Routing Table Report In-Reply-To: <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> Message-ID: > On Aug 31, 2019, at 05:04, Masataka Ohta wrote: > > Owen DeLong wrote: > >> However, since you don’t like Comcast, let’s try another one that has >> few (if any) mergers involved: > > I don't think so. Care to expand on this? > >> AS6939 — 125 prefixes... > > Are you spamming? No... HE has not acquired a significant number of other businesses to the best of my knowledge. > >> Admittedly some of this appears to be TE routes, but compare with: >> 2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48 > > If you are saying some merger happened before v6 transition, > which explains why there are less v6 prefix than v4, I can agree > with you. > > But, so what? To the best of my knowledge, HE transitioned to v6 very early in their history, so I tend to doubt it. > >>> Without automatic renumbering, IPv6 is of no help against mergers. >> Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 >> prefixes. Merging 10 organizations each of whom have 125 IPv4 >> prefixes = 1250 prefixes. > > The number of prefixes by swamp is recognized to be not a problem > even when we were discussing it in 1998 when there was only less > than 50000 prefixes. > >>>> Sure, but the number of multi homed sites is way _WAY_ less than >>>> the IPv4 routing table size. > >> Yeah, not quite the whole story in that one word… Let's look at what >> is driving that increase in "multihoming"… > > OK. You admit that the problem is caused by multihoming. OK. No, I admit multihoming is one of several factors. > >>> I don't think I must explain the current routing practice here. >> You don’t need to explain the current routing practice, but if you >> want to be taken seriously, simply assuming that every possible /24 >> in IPv4 and/or every possible /48 in IPv6 will be eventually >> advertised is a case of reductio ad absurdum. I was trying to give >> you a chance to provide a better argument for your position. > > I don't think I need such chance as my argument is already good enough. We can agree to disagree about this as is usually the case. > >> While I appreciate that you enjoy speaking to people in condescending >> tones, looking at the history and current trends shows that we are in >> a period where Moore's law is leveling off. > > I'm afraid you are not very familiar with semiconductor technology > trend. Repeating your condescending statement doesn’t make it any more accurate the second time. Owen From valdis.kletnieks at vt.edu Sun Sep 1 01:42:06 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 31 Aug 2019 21:42:06 -0400 Subject: Weekly Routing Table Report In-Reply-To: <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <328481.1567294462@turing-police> <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> Message-ID: <334694.1567302126@turing-police> On Sun, 01 Sep 2019 09:04:03 +0900, Masataka Ohta said: > > All I see there is some handwaving about separating something from > > something else, without even a description of why it was better than > > what was available when you wrote the draft. > > Read the first three paragraphs of abstract of the draft: And it doesn't actually explain why it's better. It says it's different, but doesn't give reasons to do it other than "it's different". > Read the title of the draft. The draft is not intended to describe > protocol details. In other words, you have a wish list, not a workable idea. > > Try attaching an actual protocol specification > > Read the title of the draft. The Architecture of End to End Multihoming However, the draft is lacking in any description of an actual architecture. Read RFC1518, which *does* describe an architecture, and ask yourself what's in that RFC that isn't in your draft. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Sun Sep 1 01:48:31 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 1 Sep 2019 10:48:31 +0900 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> Message-ID: <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >>> However, since you don’t like Comcast, let’s try another one that >>> has few (if any) mergers involved: >> >> I don't think so. > > Care to expand on this? See below. > No... HE has not acquired a significant number of other businesses to > the best of my knowledge. People, including me, are not interested in relying on your knowledge. If you think we should blindly believe your unfounded statement not supported by any verifiable reference, that is the condescending behavior. Moreover, your logic is flawed, because, even though HE may acquire only one business, the acquired business may have acquired a lot of other businesses. > Repeating your condescending statement doesn't make it any more > accurate the second time. That is an accurate and proper reaction to those who insists that Moore's law were not ending. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sun Sep 1 02:05:53 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 1 Sep 2019 11:05:53 +0900 Subject: Weekly Routing Table Report In-Reply-To: <334694.1567302126@turing-police> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <328481.1567294462@turing-police> <23990c42-5cd1-858e-c043-23a9048ae526@necom830.hpcl.titech.ac.jp> <334694.1567302126@turing-police> Message-ID: Valdis Kletnieks wrote: >> Read the first three paragraphs of abstract of the draft: > > And it doesn't actually explain why it's better. multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network does not introduce any problem in the network is the reason. > The Architecture of End to End Multihoming > > However, the draft is lacking in any description of an actual architecture. That is a very convincing argument made by a person who haven't read title or abstract of the draft at all. Thank you very much. > Read RFC1518, which *does* describe an architecture, and ask yourself > what's in that RFC that isn't in your draft. *YOU* should read rfc1518. Then, you could have noticed that the rfc, despite its title, says: Status of this Memo This RFC specifies an Internet standards track protocol for the Internet community though, with modern terminology, the rfc is rather a BCP than on standard track. Masataka Ohta From owen at delong.com Sun Sep 1 18:30:12 2019 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Sep 2019 11:30:12 -0700 Subject: Weekly Routing Table Report In-Reply-To: <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> Message-ID: <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> > On Aug 31, 2019, at 18:48 , Masataka Ohta wrote: > > Owen DeLong wrote: > >>>> However, since you don’t like Comcast, let’s try another one that >>>> has few (if any) mergers involved: >>> I don't think so. >> Care to expand on this? > > See below. > >> No... HE has not acquired a significant number of other businesses to >> the best of my knowledge. > > People, including me, are not interested in relying on your > knowledge. My knowledge in this case is having been an HE employee for several years. Admittedly, that was some time ago, but I am pretty sure I would have heard of any major acquisitions by HE. > > If you think we should blindly believe your unfounded statement > not supported by any verifiable reference, that is the > condescending behavior. Do you have contravening knowledge or information? HE Is a private company, so it’s nearly impossible to get detailed information about such things. You offer no counter-argument nor any reason that my knowledge is inaccurate, you simply claim it’s not credible because you don’t like what it says. That’s far more condescending. > Moreover, your logic is flawed, because, even though HE may acquire > only one business, the acquired business may have acquired a lot of > other businesses. The business I know it acquired was (at the time of acquisition) a relatively small east coast ISP startup. It did not have a significant history of acquisitions. >> Repeating your condescending statement doesn't make it any more >> accurate the second time. > > That is an accurate and proper reaction to those who insists that > Moore's law were not ending. We can again agree to disagree. You’ve offered no proof, no actual evidence to support this, only your own assertion. To quote your own statement: “If you think we should blindly believe your unfounded statement not supported by any verifiable reference…” Owen From owen at delong.com Sun Sep 1 18:46:58 2019 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Sep 2019 11:46:58 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> Message-ID: <7D39A71D-B545-4F0E-9386-7ECF44529C98@delong.com> > On Aug 31, 2019, at 09:23 , Doug Barton wrote: > > On 8/27/19 8:52 PM, Owen DeLong wrote: >>> On Jul 26, 2019, at 21:59 , Doug Barton > wrote: >>> >>> Responding to no one in particular, and not representing views of any current or former employer ... >>> >>> I find all of this hullabaloo to be ... fascinating. A little background to frame my comments below. I was GM of the IANA in the early 2000's, I held a tech license from 1994 through 2004 (I gave it up because life changed, and I no longer had time; but I still have all my toys, err, I mean, gear); and I have known two of the ARDC board members and one of the advisors listed at https://www.ampr.org/amprnet/ for over fifteen years. I consider them all friends, and trust their judgement explicitly. One of them I've known for over 20 years, and consider a close and very dear friend. >>> >>> There have been a number of points over the past 30 years where anyone who genuinely cared about this space could have used any number of mechanisms to raise concerns over how it's been managed, and by whom. I cannot help but think that some of this current sound and fury is an excuse to express righteous indignation for its own sake. The folks involved with ARDC have been caring for the space for a long time. From my perspective, seeing the writing on the wall regarding the upcoming friction around IPv4 space as an asset with monetary value increasing exponentially, they took quite reasonable steps to create a legal framework to ensure that their ability to continue managing the space would be protected. Some of you may remember that other groups, like the IETF, were taking similar steps before during and after that same time frame. Sure, you can complain about what was done, how it was done, etc.; but where were you then? Are you sure that at least part of your anger isn't due to the fact that all of these things have happened over the last 20 years, and you had no idea they were happening? >>> >> Certainly part of my anger is that I did not know some of them were happening. > > Fair enough. > >> However, most of my anger is around the fact that: >> 1.It never in a million years would have occurred to me that these people who I also consider friends and also trust explicitly >> would take this particular action without significant prior (and much wider) consultation with the amateur radio community. >> 2.I believe this was done quietly and carefully orchestrated specifically to avoid any risk of successful backlash by the time >> the community became aware of this particular intended action. > > I have actually been in this exact same position, of knowing that a thing is the right thing to do, but also knowing that doing it would create a poop-storm. I don't know if your analysis is right or not, but if I had been in their shoes I probably would have done the same thing. Well, I suppose that’s a matter of perspective and personal conviction. For me, It’s hard to defend a belief that an action is correct if I’m afraid that the community I’m a steward for will offer up significant opposition to the point that I want to take the action in secret behind the back of the community. I’m not intending any insult, or judgment on your value system, but from my perspective, avoiding the community discussion of a plan and acting on it behind their backs is an act of cowardice, not an act of conviction. >> If you want to say shame on us for trusting these people and not noticing the severe corporate governance problems with ARDC until >> they took this particular action, then I suppose that’s a fair comment. > > No, I am not attempting to shame anyone (although I admit my message was a bit testy). My point is simply that all of this after-the-fact griping, in the absence of any proven harm, is probably not as much about the thing as it is about self-culpability in what lead up to the thing. But as humans it's hard to direct that anger towards ourselves, so it gets directed outwardly. So, no shame, as it's a very human reaction. But a little more self-awareness would not be out of place. There is proven harm. There were active users of the address space sold that were (at the very least) forced to renumber. >>> So let's talk a little about what "stewardship" means. Many folks have complained about how ARDC has not done a good job of $X function that stewards of the space should perform. Do you think having some money in the bank will help contribute to their ability to do that? Has anyone looked at how much of the space is actually being used now, and what percentage reduction in available space carving out a /10 actually represents? And nowadays when IPv6 is readily available essentially "for free," how much is the amateur community actually being affected by this? >>> >> All of those are good questions. I don’t have data to answer any of them > > So shouldn't actually looking at the space to determine if any real harm was done be the next step? There were definitely allocations/assignments in the space sold. I think that the next step should be finding a way to alter the ARDC governance and board to ensure that such an action is not possible in the future without significant community review prior to the action being taken. ARDC must be reorganized to empower the Amateur Community. Owen From surfer at mauigateway.com Mon Sep 2 00:05:09 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 1 Sep 2019 17:05:09 -0700 Subject: Weekly Routing Table Report Message-ID: <20190901170509.3E69FDC2@m0117566.ppops.net> --- mohta at necom830.hpcl.titech.ac.jp wrote: From: Masataka Ohta Scott Weeks wrote: > I have been reading your posts on IETF and here regarding the > above and I'm curious as to your thoughts on John Day's RINA. As you give no reference, let's rely on wikipedia https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture -------------------------------------------------------- Yes, my apologies for no reference. Further, I have no URL to point to as I read the book. (actual book; no e-something) Here's something: http://pouzinsociety.org Like the book, in the Wikipedia article you have to get through or skip the first part. In the book, that's the first 5 or so chapters. He just describes why, in his opinion, previous things have failed and the way he does it turns a lot of folks off. Likewise, I skipped the last 1-2 chapters. So in the Wikipedia article skip to the Introduction" section. A couple more things: --------------- E2E (end-to-end principle) is not relevant IPv6 is/was a waste of time The RINA's fundamental principles are that computer networking is just Inter-Process Communication or IPC, and that layering should be done based on scope/scale, with a single recurring set of protocols, rather than function, with specialized protocols. --------------- ------------ more from Wikipedia ---------------- The IPC model of RINA concretizes distributed applications in Distributed Application Facilities or DAFs, as illustrated in Figure 2. A DAF is composed of two or more Distributed Application or DAPs, which collaborate to perform a task. These DAPs communicate using a single application protocol called Common Distributed Application Protocol or CDAP, which enables two DAPs to exchange structured data in the form of objects. All of the DAP's externally visible information is represented by objects and structured in a Resource Information Base or RIB, which provides a naming schema and a logical organization to the objects known by the DAP (for example a naming tree). CDAP allows the DAPs to perform six remote operations on the peer's objects: create, delete, read, write, start and stop. In order to exchange information, DAPs need an underlying facility that provides communication services to them. This facility is another DAF whose task is to provide and manage Inter Process Communication services over a certain scope, and is called a Distributed IPC Facility or DIF. A DIF can be thought of as a layer, and enables a DAP to allocate flows to one or more DAPs, by just providing the names of the targeted DAPs and the characteristics required for the flow such as bounds on data loss and delay, in-order delivery of data, reliability, etc. DIFs, being DAFs, can in turn use other underlying DIFs themselves. This is the recursion of the RINA. scott and restrict scope only for multihoming. Then, it is true that: > 1972. Multi-homing not supported by the ARPANET. which means current specifications do not support multihoming very well. but, the statement > The solution was obvious: as in operating systems, a logical address > space naming the nodes (hosts and routers) was required on top of the > physical interface address space. is wrong, because it is enough to let transport layer identify connections based on a set of physical interface addresses of all the interfaces, which is what draft-ohta-e2e-multihoming-* proposes. That is, he misunderstand restrictions by the current specification something inevitably required by layering. > It tosses all this on its head. If you have some text of RINA denying the E2E argument, quote it with URLs please. Masataka Ohta From surfer at mauigateway.com Mon Sep 2 00:14:54 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 1 Sep 2019 17:14:54 -0700 Subject: list admin contact is only a web gui??? Message-ID: <20190901171454.3E69FD20@m0117566.ppops.net> We can only get to the list admins through a GUI (ewww) now days, or am I having drinks on the beach and not finding it on the web site because of that? Please stop this guy. Four of these for every post. scott --- Begin forwarded message: From: To: Subject: Date: 01 Sep 2019 20:06:08 EDT Message to 7867650283 at email.uscc.net failed. From mohta at necom830.hpcl.titech.ac.jp Mon Sep 2 05:02:43 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 2 Sep 2019 14:02:43 +0900 Subject: Weekly Routing Table Report In-Reply-To: <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> Message-ID: Owen DeLong wrote: > My knowledge in this case is having been an HE employee for several > years. Admittedly, that was some time ago, but I am pretty sure I would > have heard of any major acquisitions by HE. If you think we should blindly believe your unfounded statement not supported by any verifiable reference, that is the condescending behavior. > You offer no counter-argument nor any reason that my knowledge is > inaccurate, I'm saying your opinion is untrustworthy. Masataka Ohta From ross at tajvar.io Mon Sep 2 05:11:46 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 2 Sep 2019 01:11:46 -0400 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> Message-ID: Is anyone else getting flashbacks to the guy who said he solved the spam problem? I don't think this conversation is going anywhere productive. On Mon, Sep 2, 2019 at 1:05 AM Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Owen DeLong wrote: > > > My knowledge in this case is having been an HE employee for several > > years. Admittedly, that was some time ago, but I am pretty sure I would > > have heard of any major acquisitions by HE. > > If you think we should blindly believe your unfounded statement > not supported by any verifiable reference, that is the > condescending behavior. > > > You offer no counter-argument nor any reason that my knowledge is > > inaccurate, > > I'm saying your opinion is untrustworthy. > > Masataka Ohta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Sep 2 05:34:51 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 2 Sep 2019 01:34:51 -0400 (EDT) Subject: Cat 5 hurricane -- How are the Bahamas doing? Message-ID: It is too early for damage assessments. BTC, local Bahama telecommunications company, is reporting widespread power outages, and intermittent mobile and wireline telephone service. The Abaco Islands in northern Bahamas seem to be taking the worst of it. Network measurements sites are reporting less than 6% reachability in Hope Town, Bahamas. Other parts of Bahamas have less than 50% reachability. From mohta at necom830.hpcl.titech.ac.jp Mon Sep 2 05:44:52 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 2 Sep 2019 14:44:52 +0900 Subject: Weekly Routing Table Report In-Reply-To: <20190901170509.3E69FDC2@m0117566.ppops.net> References: <20190901170509.3E69FDC2@m0117566.ppops.net> Message-ID: <88ff0a5f-4dab-70c9-4e4b-b57662dff17a@necom830.hpcl.titech.ac.jp> Scott Weeks wrote: > Yes, my apologies for no reference. Further, I have no URL to > point to as I read the book. (actual book; no e-something) > > Here's something: http://pouzinsociety.org as I can't find open access papers or something like that there, let me stick to wikipedia. > Like the book, in the Wikipedia article you have to get through > or skip the first part. In the book, that's the first 5 or so > chapters. He just describes why, in his opinion, previous things > have failed and the way he does it turns a lot of folks off. Another major misunderstanding of him is that he is not aware that domain name with MX is application name and there are proposals (though unnecessarily complicated) such as SRV to cover other applications beyond SMTP. With SRV, non-default port numbers do not have to be specified in URLs. So, we already have application names of domain names and mapping mechanism between names and addresses/port_numers of DNS. > E2E (end-to-end principle) is not relevant That someone can not recognize relevance between something and the E2E principle does not mean much. > IPv6 is/was a waste of time True, but, the reason is because IPv4 Internet with DNS, TCP and NAT is good enough. That TCP identifies connections only by single source and destination addresses is certainly a problem. But, the least painful solution is to extend TCP to be able to identify connections by multiple addresses. Properly designed NAT can save IP addresses a lot still keeping the E2E transparency. > The RINA's fundamental principles are that computer > networking is just Inter-Process Communication or IPC, That is a too much computer centric view not very applicable to communications involving human beings, where the E2E argument must often be applied to human beings (true end) behind applications (tentative end in a computer). Masataka Ohta From mark.tinka at seacom.mu Mon Sep 2 08:16:10 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:16:10 +0200 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> On 8/Aug/19 05:33, Brandon Martin wrote: >   > > MX204 is a very nice pizza box router for service providers.  I'm not > aware of anything quite like it in terms of having a mature control > plane.  I like the JunOS config language better than Cisco-style that > most other folks use. The MX204 is pretty hard to beat. It fits well as a peering/transit router, as well as a Metro-E router where you need a 100Gbps ring to carry 10Gbps customers, as well as downstream cheaper routers that will do sub-10Gbps quite nicely. That said, at least for the Metro, I still believe a lighter version of the MX204, with dense 1Gbps capability, is still needed. Been asking since 2007. Mark. From mark.tinka at seacom.mu Mon Sep 2 08:18:02 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:18:02 +0200 Subject: Mx204 alternative In-Reply-To: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On 8/Aug/19 06:46, Randy Carpenter wrote: > If you don't require redundant routing engines, there is nothing from > Juniper that will cost less and have the capacity you require. In > fact, there really aren't any cheaper MX options at all, other than > the kneecapped MX80 and MX104 variants. MX204 is really a nice box. I > only wish they had a redundant version. The MX80 and MX104 have no business being in any modern conversation these days :-). For what you could do with it, the MX204 is pretty neat. Juniper have never really considered the Metro in a serious way, because if they did, they'd have an MX204-1G (if you can call it that). They've lost plenty of ground to Cisco's ASR920 (and older MX3600X) on the back of this. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 2 08:18:45 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:18:45 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On 8/Aug/19 08:33, Baldur Norddahl wrote: > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > 25k or less. It is actually quite cheap, so I doubt the OP will find > anything much cheaper without going used or do a software router. > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > random switch as port expander also will be able to fulfil the > requirements and for a fraction of any other solution. Including the code maturity for BGP, IS-IS, OSPF and friends? Mark. From mark.tinka at seacom.mu Mon Sep 2 08:20:23 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:20:23 +0200 Subject: Mx204 alternative In-Reply-To: References: Message-ID: On 8/Aug/19 14:20, Eric Kuhnke wrote: > I am not certain on the value of having 1GbE interfaces natively on a > $25k plus router in the year 2019. Pair the router with a nice 1RU > 1/10GbE switch installed directly next to it with full metro Ethernet > layer 2 feature set.  > > Anything that needs a 1GbE inteface, attach it to that switch, give > the switch a single 10GbE port to the router, and create the 1Gbps on > the router as a subinterface. That's what we do for Metro-E rings that require 10Gbps to customers. Use an MX204 to upgrade the ring to 100Gbps, hand an ASR920 on one of the MX204 10Gbps ports, and feed 1Gbps customers from the Cisco. 10Gbps customers can enjoy the MX204. Mark. From mark.tinka at seacom.mu Mon Sep 2 08:21:45 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:21:45 +0200 Subject: Mx204 alternative In-Reply-To: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: On 8/Aug/19 16:50, Tom Hill wrote: > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > (not 9001) with traditional router bits in it. This is the closest competitor to the MX204 as in-house silicon-based boxes go. But for me, I've always felt that IOS XR is too bloated for Metro-E applications. I actually prefer IOS XE in the Metro. Mark. From mark.tinka at seacom.mu Mon Sep 2 08:24:27 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:24:27 +0200 Subject: Mx204 alternative In-Reply-To: References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: <2542177f-7dc1-2d91-33ad-97ab3c1a3443@seacom.mu> On 9/Aug/19 08:06, Radu-Adrian Feurdean wrote: > 9001, while approaching EoL, can be a good solution if your needs are limited : 8x10G + 20x1G, you should get it for a good price - refurbished. Although better than the MX80, those are in the, as we say in Africa, "the same WhatsApp group" :-). Mark. From mark.tinka at seacom.mu Mon Sep 2 08:28:19 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:28:19 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <94dd2090-99df-189a-a021-def6acc62568@seacom.mu> On 9/Aug/19 20:18, Forrest Christian (List Account) wrote: > > Assuming one can find a used mx204, what is the official juniper > licensing policy? They are too new... doubt you'll find any pre-owned units on sale. Mark. From hank at efes.iucc.ac.il Mon Sep 2 08:28:23 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 2 Sep 2019 11:28:23 +0300 Subject: Mx204 alternative In-Reply-To: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> Message-ID: <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> On 02/09/2019 11:16, Mark Tinka wrote: > > On 8/Aug/19 05:33, Brandon Martin wrote: > >> >> >> MX204 is a very nice pizza box router for service providers.  I'm not >> aware of anything quite like it in terms of having a mature control >> plane.  I like the JunOS config language better than Cisco-style that >> most other folks use. > The MX204 is pretty hard to beat. It fits well as a peering/transit > router, as well as a Metro-E router where you need a 100Gbps ring to > carry 10Gbps customers, as well as downstream cheaper routers that will > do sub-10Gbps quite nicely. > > That said, at least for the Metro, I still believe a lighter version of > the MX204, with dense 1Gbps capability, is still needed. Been asking > since 2007. > > Mark. What about handling LAG on 1Gb/sec links?  That is a major showstopper if indeed it is missing: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html •            On MX10003 and MX204 routers, rate selectability at PIC level and port level does not support 1-Gbps speed. •            On MX10003 and MX204 routers, the interface name prefix must be xe. •            On MX10003 and MX204 routers, even after configuring 1-Gbps speed, the protocol continues to advertise the bandwidth as 10-Gigabit Ethernet. •            On MX10003 and MX204 routers, Link Aggregation Group (LAG) is supported on 10-Gbps speed only. It is not supported on 1-Gbps speed. -Hank From saku at ytti.fi Mon Sep 2 08:28:14 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Sep 2019 11:28:14 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On Mon, 2 Sep 2019 at 11:24, Mark Tinka wrote: > > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > > 25k or less. It is actually quite cheap, so I doubt the OP will find > > anything much cheaper without going used or do a software router. > > > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > > random switch as port expander also will be able to fulfil the > > requirements and for a fraction of any other solution. > > Including the code maturity for BGP, IS-IS, OSPF and friends? I think the Baldur's proposal works for organisation with few and highly skilled employees. But for larger organisation the CAPEX isn't relevant, it's the OPEX that matters and managing that magic linux box is going to be very OPEX heavy. Also XEON isn't cheap chip, Jericho/PE/Trio/Solar/FP all are cheaper, significantly so. XEON does cover some segment of the market, but it's not large one. -- ++ytti From bjorn at mork.no Mon Sep 2 08:29:19 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 02 Sep 2019 10:29:19 +0200 Subject: Mx204 alternative In-Reply-To: (Mark Tinka's message of "Mon, 2 Sep 2019 10:18:02 +0200") References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <87blw33xuo.fsf@miraculix.mork.no> Mark Tinka writes: > The MX80 and MX104 have no business being in any modern conversation > these days :-). Except for the other MX-80, of course, which are better than ever. https://en.wikipedia.org/wiki/MX-80 Bjørn From mark.tinka at seacom.mu Mon Sep 2 08:49:22 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:49:22 +0200 Subject: Mx204 alternative In-Reply-To: <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> Message-ID: <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> On 2/Sep/19 10:28, Hank Nussbacher wrote: >   > > What about handling LAG on 1Gb/sec links?  That is a major showstopper > if indeed it is missing: > > https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html > > •            On MX10003 and MX204 routers, rate selectability at PIC > level and port level does not support 1-Gbps speed. > •            On MX10003 and MX204 routers, the interface name prefix > must be xe. > •            On MX10003 and MX204 routers, even after configuring > 1-Gbps speed, the protocol continues to advertise the bandwidth as > 10-Gigabit Ethernet. > •            On MX10003 and MX204 routers, Link Aggregation Group > (LAG) is supported on 10-Gbps speed only. It is not supported on > 1-Gbps speed. Well, that's not ideal at all. That said, in the Metro, we don't generally support LAG's toward customers because getting policing to work reliably on them is difficult. So we wouldn't hit this issue, although I can see how annoying it would be for networks that prefer to do this. Mark. From mark.tinka at seacom.mu Mon Sep 2 08:52:04 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 10:52:04 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On 2/Sep/19 10:28, Saku Ytti wrote: > I think the Baldur's proposal works for organisation with few and > highly skilled employees. But for larger organisation the CAPEX isn't > relevant, it's the OPEX that matters and managing that magic linux box > is going to be very OPEX heavy. Totally agreed. > Also XEON isn't cheap chip, Jericho/PE/Trio/Solar/FP all are cheaper, > significantly so. XEON does cover some segment of the market, but it's > not large one. Agreed as well. Years back, when we considered virtual routers on servers + a cheap Layer 2 switch to run a proper but inexpensive "small router", the servers always worked out more expensive to maintain over time. Mark. From lists.nanog at monmotha.net Mon Sep 2 08:52:38 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 2 Sep 2019 04:52:38 -0400 Subject: Mx204 alternative In-Reply-To: <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: On 9/2/19 4:49 AM, Mark Tinka wrote: > That said, in the Metro, we don't generally support LAG's toward > customers because getting policing to work reliably on them is > difficult. So we wouldn't hit this issue, although I can see how > annoying it would be for networks that prefer to do this. I try to avoid them in customer-facing applications, too. And in intra-network situations, I don't know why you'd be LAGging 1Gbps links anymore. But yeah, MX204 and similar LCs on the chassis platforms have some bizarre port usage/speed limitations. Juniper has a little web page to validate your port configurations, but it still seems easy to hit gotchas like this. -- Brandon Martin From mark.tinka at seacom.mu Mon Sep 2 09:02:33 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 11:02:33 +0200 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: <52247a11-363e-1c01-e1df-f5f3cbbfa2ac@seacom.mu> On 2/Sep/19 10:52, Brandon Martin wrote: >   > I try to avoid them in customer-facing applications, too.  And in > intra-network situations, I don't know why you'd be LAGging 1Gbps > links anymore. In the backbone, we moved away from LAG's to ECMP. The only places we run Layer 2 LAG's is on switch<=>router trunks (in the edge), and of course, on peering routers facing the exchange point. > > But yeah, MX204 and similar LCs on the chassis platforms have some > bizarre port usage/speed limitations.  Juniper has a little web page > to validate your port configurations, but it still seems easy to hit > gotchas like this. You need to have regular lunches with your Juniper SE to get on top of this :-)... Mark. From aled.w.morris at googlemail.com Mon Sep 2 09:02:55 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Mon, 2 Sep 2019 10:02:55 +0100 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 2 09:13:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 11:13:11 +0200 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: On 2/Sep/19 11:02, Aled Morris via NANOG wrote: > The forthcoming Juniper ACX700 sounds like a good fit for metro > Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. Do you know what chip it's running? Mark. From aled.w.morris at googlemail.com Mon Sep 2 09:24:07 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Mon, 2 Sep 2019 10:24:07 +0100 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: On Mon, 2 Sep 2019 at 10:14, Mark Tinka wrote: > > > On 2/Sep/19 11:02, Aled Morris via NANOG wrote: > > The forthcoming Juniper ACX700 sounds like a good fit for metro > > Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. > > Do you know what chip it's running? > Sorry I have no inside info, only what's been released publicly. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 2 10:26:52 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 2 Sep 2019 12:26:52 +0200 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: <9e53637a-0d98-39f5-856e-2589c4851e4a@seacom.mu> On 2/Sep/19 11:24, Aled Morris wrote: > > > Sorry I have no inside info, only what's been released publicly. We stayed away from the ACX5000 because the Broadcom chip in there wasn't great for high-touch services. I hope this ACX700 has a better plan. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghenry at suretec.co.uk Mon Sep 2 10:52:51 2019 From: ghenry at suretec.co.uk (Gavin Henry) Date: Mon, 2 Sep 2019 11:52:51 +0100 Subject: Mx204 alternative In-Reply-To: <9e53637a-0d98-39f5-856e-2589c4851e4a@seacom.mu> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> <9e53637a-0d98-39f5-856e-2589c4851e4a@seacom.mu> Message-ID: Does anyone use Juniper 0% finance? We're looking to upgrade from 4 x MX80s and they are a big jump. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Mon Sep 2 11:11:57 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 2 Sep 2019 11:11:57 +0000 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> <9e53637a-0d98-39f5-856e-2589c4851e4a@seacom.mu> Message-ID: > Does anyone use Juniper 0% finance? We're looking to upgrade from 4 x MX80s and they are a big jump. Last I heard, it was $250k minimum order value so you'll struggle if you're only buying 4 units From baldur.norddahl at gmail.com Mon Sep 2 12:52:11 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 2 Sep 2019 14:52:11 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: man. 2. sep. 2019 10.22 skrev Mark Tinka : > > > On 8/Aug/19 08:33, Baldur Norddahl wrote: > > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > > 25k or less. It is actually quite cheap, so I doubt the OP will find > > anything much cheaper without going used or do a software router. > > > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > > random switch as port expander also will be able to fulfil the > > requirements and for a fraction of any other solution. > > Including the code maturity for BGP, IS-IS, OSPF and friends? > > Mark. > Maturity is such a subjective word. But yes there are plenty of options for routing protocols on a Linux. Every internet exchange is running BGP on Linux for the route server after all. I am not recommending a server over MX204. I think MX204 is brilliant. It is one of the cheapest options and if that is not cheap enough, THEN the server solution is probably what you may be looking for. You can move a lot of traffic even with an old leftover server. Especially if you are not concerned with moving 64 bytes DDoS at line speed, because likely you would be down anyway in that case. As to the OPEX I would claim there are small shops that would have an easier time with a server, because they know how to do that. They would have only one or two routers and learning how to run JUNOS just for that might never happen. It all depends on what workforce you have. Network people or server guys? Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Mon Sep 2 13:23:46 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Mon, 02 Sep 2019 16:23:46 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On 2019-09-02 15:52, Baldur Norddahl wrote: > > Maturity is such a subjective word. But yes there are plenty of > options for routing protocols on a Linux. Every internet exchange is > running BGP on Linux for the route server after all. > > I am not recommending a server over MX204. I think MX204 is brilliant. > It is one of the cheapest options and if that is not cheap enough, > THEN the server solution is probably what you may be looking for. > > You can move a lot of traffic even with an old leftover server. > Especially if you are not concerned with moving 64 bytes DDoS at line > speed, because likely you would be down anyway in that case. > > As to the OPEX I would claim there are small shops that would have an > easier time with a server, because they know how to do that. They > would have only one or two routers and learning how to run JUNOS just > for that might never happen. It all depends on what workforce you > have. Network people or server guys? > > Regards > > Baldur > >> I think that such types of DDoS are much easier to solve on a server with XDP/eBPF than on MX. And much cheaper if we are talking about the new SYN+ACK DDoS and it is exactly 64b ddos case. I used multiple 82599. From snabbco discussion, issue #1013, "If you read Intel datasheets then the minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for 40G (XL710), and 256B for 100G (FM10K)." But "hardware", ASIC enabled routers such as MX might be not better and even need some tuning. https://kb.juniper.net/InfoCenter/index?page=content&id=KB33477&actp=METADATA "On summit MX204 and MX10003 platforms, the line rate frame size is 119 byte for 10/40GbE port and 95 byte for 100GbE port." or some QFX, for example, Broadcom Tomahawk 32x100G switches only do line-rate with >= 250B packets according to datasheets. From dot at dotat.at Mon Sep 2 13:33:56 2019 From: dot at dotat.at (Tony Finch) Date: Mon, 2 Sep 2019 14:33:56 +0100 Subject: Weekly Routing Table Report In-Reply-To: <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: Patrick W. Gilmore wrote: > > This time I waited for 768,000. (Everyone happy now?) I thought the magic number for breaking old Cisco gear was 786432 (768 * 1024) ... there was a panic about it earlier this year but growth slowed so it didn't happen as soon as they feared. https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/ But looking at https://twitter.com/bgp4_table I see we passed the higher thresold (by some metrics) last month without any apparent routing failures so maybe the old Cisco gear isn't very important any more! Tony. -- f.anthony.n.finch http://dotat.at/ North Foreland to Selsey Bill: Southwesterly veering westerly, 4 or 5, occasionally 6 at first in east. Smooth or slight, becoming slight, occasionally moderate. Showers later. Good. From jared at puck.nether.net Mon Sep 2 13:40:35 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 2 Sep 2019 09:40:35 -0400 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: <548619F3-66F6-42CC-B6ED-EEA20FCD93BE@puck.nether.net> > On Sep 2, 2019, at 9:33 AM, Tony Finch wrote: > > Patrick W. Gilmore wrote: >> >> This time I waited for 768,000. (Everyone happy now?) > > I thought the magic number for breaking old Cisco gear was 786432 > (768 * 1024) ... there was a panic about it earlier this year but growth > slowed so it didn't happen as soon as they feared. > > https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/ > > But looking at https://twitter.com/bgp4_table I see we passed the higher > thresold (by some metrics) last month without any apparent routing > failures so maybe the old Cisco gear isn't very important any more! It may be that there were failures but not at the core, which is more likely. I recall writing the internal technical note on the edge devices when we hit 128k and 256k numbers, especially as I was a promoter of u-RPF and this halved the TCAM size. It was only certain devices/customers that may have seen an issue, AND only for new routes not older stable ones. People who want to promote BGP churn as a platform solution need to keep this in mind. It also matters if you have the ability to disaggregate your FIB (default) vs RIB. I’m seeing more of this right now which I think is overall good. Don’t need to install all those routes in hardware if they’re all going the same way. From valdis.kletnieks at vt.edu Mon Sep 2 13:48:53 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 02 Sep 2019 09:48:53 -0400 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> Message-ID: <488935.1567432133@turing-police> On Mon, 02 Sep 2019 14:02:43 +0900, Masataka Ohta said: > If you think we should blindly believe your unfounded statement > not supported by any verifiable reference, that is the > condescending behavior. Well Masataka... If "Owen DeLong, who was widely known to have been in an actual job position to know of certain facts, stating these facts" isn't sufficient evidence for you, then applying that very same standard of evidence to your assertions leads directly to "can safely be ignored" *plonk* (the sound of an email address dropping into a not-often-used ignore file) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Mon Sep 2 14:03:21 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 02 Sep 2019 10:03:21 -0400 Subject: Mx204 alternative In-Reply-To: References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: <489828.1567433001@turing-police> On Mon, 02 Sep 2019 10:02:55 +0100, Aled Morris via NANOG said: > The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet > with 4x100G and 24x10G in a shallow 1U hardened form factor. Hardened? Is this just "will survive in a not-well-cooled telco closet" hardening, or something more.... unusual? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From nick at foobar.org Mon Sep 2 14:04:47 2019 From: nick at foobar.org (Nick Hilliard) Date: Mon, 2 Sep 2019 15:04:47 +0100 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <990bb86f-5570-32e3-6bd8-26913d508ac2@foobar.org> Baldur Norddahl wrote on 02/09/2019 13:52: > You can move a lot of traffic even with an old leftover server. > Especially if you are not concerned with moving 64 bytes DDoS at line > speed, because likely you would be down anyway in that case. indeed, and there are very few problems that might happen in practice that couldn't be solved by something with kernel development experience. Nick From saku at ytti.fi Mon Sep 2 14:16:50 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Sep 2019 17:16:50 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On Mon, 2 Sep 2019 at 16:26, Denys Fedoryshchenko wrote: > or some QFX, for example, Broadcom Tomahawk 32x100G switches only do > line-rate with >= 250B packets according to datasheets. Only is peculiar term here. 100Gbps is 148Mpps, give or take 100PPM, at 250B it's still some 50Mpps. Times 32 that's 1600Mpps, or 1.6Gpps. Only implies it's modest compared to some other solution, what is that solution? XEON doing ~nothing (not proper lookup even) is some couple hundred Mpps, far cry from 1.6Gpps with ACL, QoS and L3 lookup. I don't care about wire rate on chip with lot of ports, because statistics. 250B average size on 32x100GE on a chip is fine to me. 250B average size on 32x100GE with 32 chips, would be horrifying. I'm not saying XEON does not have application, I'm just saying XEON is bps and pps expensive chip compared to almost anything out there, however there are some application with very deep touch where it is marketable. Btw. technically Tomahawk and Trio are very different, Trio has tens or hundreds of cores executing software, cores happen to have domain specific instruction set, but still software box with lot of cores. Tomahawk is pipeline box, having domain specific hardware and largely not running a software (but all pipelines today are somewhat programmable anyhow). On Trio you are mostly just time limited on what you can do, on Tomahawk you have physical hardware restrictions on what you can do. -- ++ytti From nuclearcat at nuclearcat.com Mon Sep 2 14:48:21 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Mon, 02 Sep 2019 17:48:21 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On 2019-09-02 17:16, Saku Ytti wrote: > On Mon, 2 Sep 2019 at 16:26, Denys Fedoryshchenko > wrote: > >> or some QFX, for example, Broadcom Tomahawk 32x100G switches only do >> line-rate with >= 250B packets according to datasheets. > > Only is peculiar term here. 100Gbps is 148Mpps, give or take 100PPM, > at 250B it's still some 50Mpps. Times 32 that's 1600Mpps, or 1.6Gpps. > Only implies it's modest compared to some other solution, what is that > solution? XEON doing ~nothing (not proper lookup even) is some couple > hundred Mpps, far cry from 1.6Gpps with ACL, QoS and L3 lookup. > I don't care about wire rate on chip with lot of ports, because > statistics. 250B average size on 32x100GE on a chip is fine to me. > 250B average size on 32x100GE with 32 chips, would be horrifying. > > I'm not saying XEON does not have application, I'm just saying XEON is > bps and pps expensive chip compared to almost anything out there, > however there are some application with very deep touch where it is > marketable. > Btw. technically Tomahawk and Trio are very different, Trio has tens > or hundreds of cores executing software, cores happen to have domain > specific instruction set, but still software box with lot of cores. > Tomahawk is pipeline box, having domain specific hardware and largely > not running a software (but all pipelines today are somewhat > programmable anyhow). On Trio you are mostly just time limited on what > you can do, on Tomahawk you have physical hardware restrictions on > what you can do. Of course, they are much stronger (and cheaper in $/bps or $/pps) when it comes to L2/L3 lookup, basic stateless filters, simple QoS. But can Trio perform stateful firewall filtering for millions of flows+ lot of mpps that Xeon easily handle? Thats the case of recent DDoS attacks. From saku at ytti.fi Mon Sep 2 15:07:16 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Sep 2019 18:07:16 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: On Mon, 2 Sep 2019 at 17:48, Denys Fedoryshchenko wrote: > Of course, they are much stronger (and cheaper in $/bps or $/pps) when > it comes to L2/L3 lookup, basic stateless filters, simple QoS. > But can Trio perform stateful firewall filtering for millions of flows+ > lot of mpps that Xeon easily handle? Thats the case of recent DDoS > attacks. No it can't, certainly domain where XEON is marketable. Technically if you could program Trio, it could do that and lot more, cheaper and faster than XEON, but you can't program it. I feel like we're at networking vendors same place where we were in early 90s with linux and GPU/NIC, vendors thought their code is secret sauce and wouldn't release specs for people to write their own free software fopr them. Hopefully we'll start seeing network specific chips enter the market with public specs, P5 compiler, no questions (signatures, contracts) asked. I'm convinced there is market that is not being addressed, who is now forced to use XEON but could use something much more efficient, if they were allowed to. Looking at JNPR's market cap evolution over past couple decades, they certainly need to figure out something new. Like how about 8-16*100GE single Trio PCI card with no-questions asked, specification released, would there be a market? I like to think there would be. -- ++ytti From olivier.benghozi at wifirst.fr Mon Sep 2 16:02:06 2019 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Mon, 2 Sep 2019 18:02:06 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <43C38EAD-DEEC-4656-88A9-EA72BF444FFC@wifirst.fr> By the way they now say in this KB article that they implemented a «high performance mode» for MX204 / MX10003 with some «set chassis fpc slot high-performance-mode». Anyone wiling to test? :) > Le 2 sept. 2019 à 15:23, Denys Fedoryshchenko a écrit : > > From snabbco discussion, issue #1013, "If you read Intel datasheets then the minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for 40G (XL710), and 256B for 100G (FM10K)." > > But "hardware", ASIC enabled routers such as MX might be not better and even need some tuning. > https://kb.juniper.net/InfoCenter/index?page=content&id=KB33477&actp=METADATA > "On summit MX204 and MX10003 platforms, the line rate frame size is 119 byte for 10/40GbE port and 95 byte for 100GbE port." From tim at pelican.org Mon Sep 2 16:07:07 2019 From: tim at pelican.org (tim at pelican.org) Date: Mon, 2 Sep 2019 17:07:07 +0100 (BST) Subject: Mx204 alternative In-Reply-To: <489828.1567433001@turing-police> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> <489828.1567433001@turing-police> Message-ID: <1567440427.947818315@apps.rackspace.com> On Monday, 2 September, 2019 15:03, "Valdis Klētnieks" said: > Hardened? Is this just "will survive in a not-well-cooled telco closet" > hardening, > or something more.... unusual? I don't see specs yet, but I would expect it's the former, similar to the MX104 against the rest of the MX range. NEBS-compliances, and -40C to 65C operating temperature range (standard 0C to 46C). We've been very grateful for the latter in exchange (CO) installations - old, brick buildings weary from decades of housing Strowgers are at times hot and filthy compared to your average DC. Regards, Tim. From nick at nanocat.net Mon Sep 2 17:33:42 2019 From: nick at nanocat.net (Nick Morrison) Date: Mon, 2 Sep 2019 19:33:42 +0200 Subject: Weekly Routing Table Report In-Reply-To: <488935.1567432133@turing-police> References: <488935.1567432133@turing-police> Message-ID: > On 2. Sep 2019, at 15:49, Valdis Klētnieks wrote: > > *plonk* (the sound of an email address dropping into a not-often-used ignore file) mmhmm nice nerd burn. ouchie. From adamv0025 at netconsultings.com Mon Sep 2 17:42:59 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Mon, 2 Sep 2019 18:42:59 +0100 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> > Denys Fedoryshchenko > Sent: Monday, September 2, 2019 2:24 PM > > On 2019-09-02 15:52, Baldur Norddahl wrote: > > > > Maturity is such a subjective word. But yes there are plenty of > > options for routing protocols on a Linux. Every internet exchange is > > running BGP on Linux for the route server after all. > > > > I am not recommending a server over MX204. I think MX204 is brilliant. > > It is one of the cheapest options and if that is not cheap enough, > > THEN the server solution is probably what you may be looking for. > > > > You can move a lot of traffic even with an old leftover server. > > Especially if you are not concerned with moving 64 bytes DDoS at line > > speed, because likely you would be down anyway in that case. > > > > As to the OPEX I would claim there are small shops that would have an > > easier time with a server, because they know how to do that. They > > would have only one or two routers and learning how to run JUNOS just > > for that might never happen. It all depends on what workforce you > > have. Network people or server guys? > > > > Regards > > > > Baldur > > > >> > > I think that such types of DDoS are much easier to solve on a server with > XDP/eBPF than on MX. > And much cheaper if we are talking about the new SYN+ACK DDoS and it is > exactly 64b ddos case. I used multiple 82599. > > From snabbco discussion, issue #1013, "If you read Intel datasheets then the > minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for > 40G (XL710), and 256B for 100G (FM10K)." > > But "hardware", ASIC enabled routers such as MX might be not better and > even need some tuning. > https://kb.juniper.net/InfoCenter/index?page=content&id=KB33477&actp= > METADATA > "On summit MX204 and MX10003 platforms, the line rate frame size is 119 > byte for 10/40GbE port and 95 byte for 100GbE port." > or some QFX, for example, Broadcom Tomahawk 32x100G switches only do > line-rate with >= 250B packets according to datasheets. > You nailed it, Actually very few line-cards or fabric-less boxes with (run to completion vendor chips) out there do line-rate at 64B packets nowadays. -with the advent of 100G the "line-rate at 64B" is pretty much not a thing anymore... Something to consider, not because one wants to push 64B packets at line-rate on all ports but because one needs to push IMIX through QOS or filters... and the card/box might simply not deliver. adam From brandon at rd.bbc.co.uk Mon Sep 2 17:44:42 2019 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 2 Sep 2019 18:44:42 +0100 Subject: Mx204 alternative In-Reply-To: <1567440427.947818315@apps.rackspace.com> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> <489828.1567433001@turing-police> <1567440427.947818315@apps.rackspace.com> Message-ID: <20190902174442.GA27896@sunf10.rd.bbc.co.uk> On Mon Sep 02, 2019 at 05:07:07PM +0100, tim at pelican.org wrote: > On Monday, 2 September, 2019 15:03, "Valdis Kl??tnieks" said: > > > Hardened? Is this just "will survive in a not-well-cooled telco closet" > > hardening, > > or something more.... unusual? > > I don't see specs yet, but I would expect it's the former, similar to the MX104 against the rest of the MX range. NEBS-compliances, and -40C to 65C operating temperature range (standard 0C to 46C). For telco sites Cisco do theirs NCS-55A2-MOD-HD-S: Temperature-hardened NCS-55A2-MOD-HX-S: Temperature-hardened, conformal coated Operating Temperature -40C to +70C they don't say to what degree the conformal coating protects it but that is usually used in dirty environments (military was a common user, I don't know their target for this) brandon From adamv0025 at netconsultings.com Mon Sep 2 17:49:19 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Mon, 2 Sep 2019 18:49:19 +0100 Subject: Mx204 alternative In-Reply-To: <43C38EAD-DEEC-4656-88A9-EA72BF444FFC@wifirst.fr> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <43C38EAD-DEEC-4656-88A9-EA72BF444FFC@wifirst.fr> Message-ID: <01f701d561b6$bf435220$3dc9f660$@netconsultings.com> > Olivier Benghozi > Sent: Monday, September 2, 2019 5:02 PM > > By the way they now say in this KB article that they implemented a «high > performance mode» for MX204 / MX10003 with some «set chassis fpc slot > high-performance-mode». > Anyone wiling to test? :) > Judging from mpc7 with hyper-mode I'm sceptical, but as always subject to test results. adam From adamv0025 at netconsultings.com Mon Sep 2 18:00:43 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Mon, 2 Sep 2019 19:00:43 +0100 Subject: Mx204 alternative In-Reply-To: References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: <01fa01d561b8$56b09ef0$0411dcd0$@netconsultings.com> > Mark Tinka > Sent: Monday, September 2, 2019 9:22 AM > > > On 8/Aug/19 16:50, Tom Hill wrote: > > > > > No-one has mentioned it yet, so for completeness big C have the ASR > > 9901 (not 9001) with traditional router bits in it. > > This is the closest competitor to the MX204 as in-house silicon-based boxes > go. > > But for me, I've always felt that IOS XR is too bloated for Metro-E > applications. I actually prefer IOS XE in the Metro. > I'm afraid I have some bad news for you then, since the new metro portfolio (NCS) from Cisco is all XR. But on the upside it means better support for YANG... adam From saku at ytti.fi Mon Sep 2 18:05:49 2019 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Sep 2019 21:05:49 +0300 Subject: Mx204 alternative In-Reply-To: <01f701d561b6$bf435220$3dc9f660$@netconsultings.com> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <43C38EAD-DEEC-4656-88A9-EA72BF444FFC@wifirst.fr> <01f701d561b6$bf435220$3dc9f660$@netconsultings.com> Message-ID: On Mon, 2 Sep 2019 at 20:51, wrote: > Judging from mpc7 with hyper-mode I'm sceptical, but as always subject to test results. We saw 25% pps advantage with hyper-mode on MX10k (which supposedly is same as high-performance-mode). New linecards will be high-performance-mode out-of-box. I think this sort of microcode cleanup periodically makes sense, if you have long enough story on hardware capable of running same microcode. Usually you have to start hardware from scratch which forces the same, rewriting the forwarding plane code and paying some technology debts. -- ++ytti From mark.tinka at seacom.mu Mon Sep 2 22:01:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 3 Sep 2019 00:01:03 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <62c0bcd7-fb65-e763-23da-d69613d34fc7@seacom.mu> On 2/Sep/19 14:52, Baldur Norddahl wrote: > > Maturity is such a subjective word. As service provider operations go, maturity. > But yes there are plenty of options for routing protocols on a Linux. > Every internet exchange is running BGP on Linux for the route server > after all. Not quite the same thing, but I take your point. > > I am not recommending a server over MX204. I think MX204 is brilliant. > It is one of the cheapest options and if that is not cheap enough, > THEN the server solution is probably what you may be looking for.  > > You can move a lot of traffic even with an old leftover server. > Especially if you are not concerned with moving 64 bytes DDoS at line > speed, because likely you would be down anyway in that case. > > As to the OPEX I would claim there are small shops that would have an > easier time with a server, because they know how to do that. They > would have only one or two routers and learning how to run JUNOS just > for that might never happen. It all depends on what workforce you > have. Network people or server guys? That's what Saku was alluding to earlier - opex is not just in the hardware. Mark. From mark.tinka at seacom.mu Mon Sep 2 22:04:48 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 3 Sep 2019 00:04:48 +0200 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <9f0fba41-828c-48e7-1536-5f7c3e435d29@seacom.mu> On 2/Sep/19 17:07, Saku Ytti wrote: > Like how about 8-16*100GE single Trio PCI card with no-questions > asked, specification released, would there be a market? I like to > think there would be. I'd be down for this. Mark. From mark.tinka at seacom.mu Mon Sep 2 22:06:26 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 3 Sep 2019 00:06:26 +0200 Subject: Mx204 alternative In-Reply-To: <01fa01d561b8$56b09ef0$0411dcd0$@netconsultings.com> References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> <01fa01d561b8$56b09ef0$0411dcd0$@netconsultings.com> Message-ID: <429254a0-41f4-81ce-2e46-9094ad5293c2@seacom.mu> On 2/Sep/19 20:00, adamv0025 at netconsultings.com wrote: > I'm afraid I have some bad news for you then, since the new metro portfolio (NCS) from Cisco is all XR. > But on the upside it means better support for YANG... We'll see what happens when we get to that bridge. Mark. From kenneth.mcrae at me.com Mon Sep 2 22:27:16 2019 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Mon, 2 Sep 2019 15:27:16 -0700 Subject: Mx204 alternative In-Reply-To: <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> Message-ID: <81160B16-186D-4640-88AF-DF2FD233E091@me.com> 1 Gig is supported on later release versions Sent from my iPhone > On Sep 2, 2019, at 1:49 AM, Mark Tinka wrote: > > > >> On 2/Sep/19 10:28, Hank Nussbacher wrote: >> >> >> >> What about handling LAG on 1Gb/sec links? That is a major showstopper >> if indeed it is missing: >> >> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html >> >> • On MX10003 and MX204 routers, rate selectability at PIC >> level and port level does not support 1-Gbps speed. >> • On MX10003 and MX204 routers, the interface name prefix >> must be xe. >> • On MX10003 and MX204 routers, even after configuring >> 1-Gbps speed, the protocol continues to advertise the bandwidth as >> 10-Gigabit Ethernet. >> • On MX10003 and MX204 routers, Link Aggregation Group >> (LAG) is supported on 10-Gbps speed only. It is not supported on >> 1-Gbps speed. > > Well, that's not ideal at all. > > That said, in the Metro, we don't generally support LAG's toward > customers because getting policing to work reliably on them is > difficult. So we wouldn't hit this issue, although I can see how > annoying it would be for networks that prefer to do this. > > Mark. From kenneth.mcrae at me.com Mon Sep 2 22:36:37 2019 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Mon, 2 Sep 2019 15:36:37 -0700 Subject: Mx204 alternative In-Reply-To: <81160B16-186D-4640-88AF-DF2FD233E091@me.com> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> <4b39de1d-595a-1e23-45a3-bcb3f486df4e@seacom.mu> <81160B16-186D-4640-88AF-DF2FD233E091@me.com> Message-ID: On the MX204 that is.. Sent from my iPhone > On Sep 2, 2019, at 3:27 PM, Kenneth McRae via NANOG wrote: > > 1 Gig is supported on later release versions > > Sent from my iPhone > >> On Sep 2, 2019, at 1:49 AM, Mark Tinka wrote: >> >> >> >>> On 2/Sep/19 10:28, Hank Nussbacher wrote: >>> >>> >>> >>> What about handling LAG on 1Gb/sec links? That is a major showstopper >>> if indeed it is missing: >>> >>> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html >>> >>> • On MX10003 and MX204 routers, rate selectability at PIC >>> level and port level does not support 1-Gbps speed. >>> • On MX10003 and MX204 routers, the interface name prefix >>> must be xe. >>> • On MX10003 and MX204 routers, even after configuring >>> 1-Gbps speed, the protocol continues to advertise the bandwidth as >>> 10-Gigabit Ethernet. >>> • On MX10003 and MX204 routers, Link Aggregation Group >>> (LAG) is supported on 10-Gbps speed only. It is not supported on >>> 1-Gbps speed. >> >> Well, that's not ideal at all. >> >> That said, in the Metro, we don't generally support LAG's toward >> customers because getting policing to work reliably on them is >> difficult. So we wouldn't hit this issue, although I can see how >> annoying it would be for networks that prefer to do this. >> >> Mark. > From mohta at necom830.hpcl.titech.ac.jp Mon Sep 2 22:02:53 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 3 Sep 2019 07:02:53 +0900 Subject: Weekly Routing Table Report In-Reply-To: <488935.1567432133@turing-police> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> <488935.1567432133@turing-police> Message-ID: <86e8ad05-1a90-573e-8fd5-0e4072f7cd82@necom830.hpcl.titech.ac.jp> Valdis Klētnieks wrote: >> If you think we should blindly believe your unfounded statement >> not supported by any verifiable reference, that is the >> condescending behavior. As you can see, that you finally mentioned rfc1518 as reference helped a lot to suppress unfounded and, thus, useless messages from you, because I verified the rfc to find that all of your points are denied. That's the point to have verifiable references. > Well Masataka... If "Owen DeLong, who was widely known to have been in an > actual job position to know of certain facts, stating these facts" isn't > sufficient evidence for you, I can't see any confirmed facts. Moreover, even if some of his point on a single company might be valid, it is nothing for the discussion on the entire Internet. > then applying that very same standard of > evidence to your assertions leads directly to "can safely be ignored" As I already wrote: > The following page by Geoff Huston is better than your delusion. > http://www.potaroo.net/ispcolumn/2001-03-bgp.html > What is driving this recent change to exponential growth > of the routing table? > In a word, multi-homing. feel free to verify it. Masataka Ohta From sethm at rollernet.us Mon Sep 2 23:40:37 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Sep 2019 16:40:37 -0700 Subject: Weekly Routing Table Report In-Reply-To: <86e8ad05-1a90-573e-8fd5-0e4072f7cd82@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> <488935.1567432133@turing-police> <86e8ad05-1a90-573e-8fd5-0e4072f7cd82@necom830.hpcl.titech.ac.jp> Message-ID: <9bda0da9-f8d9-855a-850c-5383a97781c0@rollernet.us> On 9/2/19 15:02, Masataka Ohta wrote: > >> then applying that very same standard of >> evidence to your assertions leads directly to "can safely be ignored" > > As I already wrote: > > > The following page by Geoff Huston is better than your delusion. > > http://www.potaroo.net/ispcolumn/2001-03-bgp.html > >     What is driving this recent change to exponential growth > >     of the routing table? > >     In a word, multi-homing. > > feel free to verify it. May the world come to an end if someone dares to have an independent thought or shares original information that can't be backed up by at least 50 crosschecked references. From mohta at necom830.hpcl.titech.ac.jp Tue Sep 3 01:36:00 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 3 Sep 2019 10:36:00 +0900 Subject: Weekly Routing Table Report In-Reply-To: <9bda0da9-f8d9-855a-850c-5383a97781c0@rollernet.us> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> <488935.1567432133@turing-police> <86e8ad05-1a90-573e-8fd5-0e4072f7cd82@necom830.hpcl.titech.ac.jp> <9bda0da9-f8d9-855a-850c-5383a97781c0@rollernet.us> Message-ID: Seth Mattinen wrote: > May the world come to an end if someone dares to have an independent > thought or shares original information that can't be backed up by at > least 50 crosschecked references. Unlike references to facts, references to thought are required when the thought is not purely original and derived from someone else's thought. As such, if the thought is really independent, no references necessary. Masataka Ohta From lists.nanog at monmotha.net Tue Sep 3 02:07:11 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 2 Sep 2019 22:07:11 -0400 Subject: Mx204 alternative In-Reply-To: <9f0fba41-828c-48e7-1536-5f7c3e435d29@seacom.mu> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <9f0fba41-828c-48e7-1536-5f7c3e435d29@seacom.mu> Message-ID: <65322588-6e38-22eb-63bf-daab0d4aaaae@monmotha.net> On 9/2/19 6:04 PM, Mark Tinka wrote: >> Like how about 8-16*100GE single Trio PCI card with no-questions >> asked, specification released, would there be a market? I like to >> think there would be. > I'd be down for this. > > Mark. Oh my gosh this. Especially if the docs are truly public (i.e. available with single click-wrap "don't be an asshat" license or even something like GDFL) and not just under NDA, but honestly even if it's an NDA required as long as it's broadly available for issuance (no need to be a high-volume) Broadcom partner and allows the results of its use to be distributed as F/OSS software, I'm game. I kinda wonder if the culture at Broadcom has changed any since the merger/acquisition with Avagao. Obviously in ye olde days, you wouldn't even get the time of day from them unless you were wanting to commit to a million or so in sales. I spread my interest (and professional practice) between SP networking, industrial networking, industrial controls, and industrial computing including hardware, so this is drool-level interest for me even if I don't get to work on it directly. So much so that I've been wanting to play with an FPGA platform for this sort of thing, but there's just no compelling reason given that existing, openly-documented accelerated NICs from e.g. Intel on high-end PC hardware can basically match the performance of any reasonable-cost FPGA Ethernet switching system in useful workloads. -- Brandon Martin From list at satchell.net Tue Sep 3 02:20:28 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 2 Sep 2019 19:20:28 -0700 Subject: Weekly Routing Table Report In-Reply-To: <9bda0da9-f8d9-855a-850c-5383a97781c0@rollernet.us> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> <4b1b0b3e-aab3-b357-103e-e0183da9671c@necom830.hpcl.titech.ac.jp> <9D5C4B71-4405-4E3B-85AB-7BA481A41721@delong.com> <488935.1567432133@turing-police> <86e8ad05-1a90-573e-8fd5-0e4072f7cd82@necom830.hpcl.titech.ac.jp> <9bda0da9-f8d9-855a-850c-5383a97781c0@rollernet.us> Message-ID: On 9/2/19 4:40 PM, Seth Mattinen wrote: > May the world come to an end if someone dares to have an independent > thought or shares original information that can't be backed up by at > least 50 crosschecked references. Actually, independent thought or original information is welcome to anyone with a brain, as long as the author shows his/her work such that it can be verified and reproduced by others. You don't need a ton of references to the work (and conclusions) of others if you do a complete job yourself. There is a reason for the joke publication _The Journal of Irreproducible Results_, started in 1955. So many "scientific" publications have this little tiny problem: no one can duplicate the work. From ross at tajvar.io Tue Sep 3 02:48:34 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 2 Sep 2019 22:48:34 -0400 Subject: Mx204 alternative In-Reply-To: <65322588-6e38-22eb-63bf-daab0d4aaaae@monmotha.net> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <9f0fba41-828c-48e7-1536-5f7c3e435d29@seacom.mu> <65322588-6e38-22eb-63bf-daab0d4aaaae@monmotha.net> Message-ID: I'd like to register my interest as well. I think an open hardware platform will do a lot to move the industry forward. On Mon, Sep 2, 2019, 10:09 PM Brandon Martin wrote: > On 9/2/19 6:04 PM, Mark Tinka wrote: > >> Like how about 8-16*100GE single Trio PCI card with no-questions > >> asked, specification released, would there be a market? I like to > >> think there would be. > > I'd be down for this. > > > > Mark. > > Oh my gosh this. Especially if the docs are truly public (i.e. > available with single click-wrap "don't be an asshat" license or even > something like GDFL) and not just under NDA, but honestly even if it's > an NDA required as long as it's broadly available for issuance (no need > to be a high-volume) Broadcom partner and allows the results of its use > to be distributed as F/OSS software, I'm game. > > I kinda wonder if the culture at Broadcom has changed any since the > merger/acquisition with Avagao. Obviously in ye olde days, you wouldn't > even get the time of day from them unless you were wanting to commit to > a million or so in sales. > > I spread my interest (and professional practice) between SP networking, > industrial networking, industrial controls, and industrial computing > including hardware, so this is drool-level interest for me even if I > don't get to work on it directly. So much so that I've been wanting to > play with an FPGA platform for this sort of thing, but there's just no > compelling reason given that existing, openly-documented accelerated > NICs from e.g. Intel on high-end PC hardware can basically match the > performance of any reasonable-cost FPGA Ethernet switching system in > useful workloads. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ray at oneunified.net Tue Sep 3 03:06:00 2019 From: ray at oneunified.net (Raymond Burkholder) Date: Mon, 2 Sep 2019 21:06:00 -0600 Subject: Mx204 alternative In-Reply-To: <65322588-6e38-22eb-63bf-daab0d4aaaae@monmotha.net> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <9f0fba41-828c-48e7-1536-5f7c3e435d29@seacom.mu> <65322588-6e38-22eb-63bf-daab0d4aaaae@monmotha.net> Message-ID: On 2019-09-02 8:07 p.m., Brandon Martin wrote: > On 9/2/19 6:04 PM, Mark Tinka wrote: >>> Like how about 8-16*100GE single Trio PCI card with no-questions >>> asked, specification released, would there be a market? I like to >>> think there would be. >> > Oh my gosh this.  Especially if the docs are truly public (i.e. > available with single click-wrap "don't be an asshat" license or even > something like GDFL) and not just under NDA, but honestly even if it's > an NDA required as long as it's broadly available for issuance (no > need to be a high-volume) Broadcom partner and allows the results of > its use to be distributed as F/OSS software, I'm game. In light of the xeon cost benefit mentioned earlier, I don't know how this fits, but with enough pcie lanes going to an appropriate number of cores, Mellanox has dual port 100gbps and 200gbps ConnectX cards.  Plunk four of those cards into a suitable chassis, you could conceivably have 8 ports by 100 or 200gbps.  From their site, ConnectX-6 can do various smart offload and such.  ConnectX has some sort of XDP Redirect capability, so may have eBPF hardware/software offload capability.  Not sure. A commit back in December indicates 100Mpps on single port and 72Mpps on dual port depending upon how things are setup. Actual routing/switching actions at those rates might be challenging but for smaller shops with pipes not fully utilized, might be an entertaining evaluation. Raymond. From lukasz at bromirski.net Tue Sep 3 07:24:25 2019 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Tue, 3 Sep 2019 09:24:25 +0200 Subject: Mx204 alternative In-Reply-To: <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> Message-ID: Adam, > On 2 Sep 2019, at 19:42, adamv0025 at netconsultings.com wrote: > > You nailed it, > Actually very few line-cards or fabric-less boxes with (run to completion > vendor chips) out there do line-rate at 64B packets nowadays. > -with the advent of 100G the "line-rate at 64B" is pretty much not a thing > anymore... > Something to consider, not because one wants to push 64B packets at > line-rate on all ports but because one needs to push IMIX through QOS or > filters... and the card/box might simply not deliver. But those are two completely different use cases. The fact that vendors (full disclosure - I work for Cisco) don’t want to optimize for 64 bytes forwarding is totally independent on how those architectures deal/manage to apply policies on the traffic. 64B traffic simply doesn’t happen apart from DDoS scenarios, so why bother at all? Customers anyway want to use dedicated anty-DDoS boxes, so apart from synthetic performance testing, pushing the architecture to be able to forward couple of mpps more just to cover the “64B” scenario means $ (sometimes $$$) just to satisfy requirement that’s usually simply not there. In other words, the fact that given architecture can’t forward "wire-rate" of 64B traffic doesn’t mean that it can’t apply QoS for IMIX pattern at wire-speed. Forwarding engine is usually different part of hardware than services, more often than not decisions are totally independent to speed up processing. -- Łukasz Bromirski CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Sep 3 08:55:25 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 3 Sep 2019 11:55:25 +0300 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> Message-ID: On Tue, 3 Sep 2019 at 10:27, Łukasz Bromirski wrote: > 64B traffic simply doesn’t happen apart from DDoS scenarios, so > why bother at all? Customers anyway want to use dedicated ACK. And as such, you're not going to get DDoS on all ports at the same time. So you just need to have enough ports on a chip and even very high average packet size, is more than enough. And if you absolutely need 64B on every port, that's easy, just put putty on the remaining ports, boom. The problem is when you rock 1 chip per port and you don't get 64B. But if it's 8, 16, 32 ports per chip, 64B is simply not needed. And like you said, QoS and filters usually have 0 pps cost. Only feature that typically has pps cost is uRPF which is not really needed for anything. -- ++ytti From adamv0025 at netconsultings.com Tue Sep 3 12:11:17 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 3 Sep 2019 13:11:17 +0100 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> Message-ID: <212e01d56250$b078a520$1169ef60$@netconsultings.com> > From: Saku Ytti > Sent: Tuesday, September 3, 2019 9:55 AM > > On Tue, 3 Sep 2019 at 10:27, Łukasz Bromirski wrote: > > > 64B traffic simply doesn’t happen apart from DDoS scenarios, so why > > bother at all? Customers anyway want to use dedicated > > > And like you said, QoS and filters usually have 0 pps cost. > Not true. This is the case only in fixed pipelines. adam From werzacabak at gmail.com Mon Sep 2 07:17:38 2019 From: werzacabak at gmail.com (howard stearn) Date: Mon, 2 Sep 2019 01:17:38 -0600 Subject: Weekly Routing Table Report In-Reply-To: <88ff0a5f-4dab-70c9-4e4b-b57662dff17a@necom830.hpcl.titech.ac.jp> References: <20190901170509.3E69FDC2@m0117566.ppops.net> <88ff0a5f-4dab-70c9-4e4b-b57662dff17a@necom830.hpcl.titech.ac.jp> Message-ID: Did we all forget the size of the IPv6 table is nearing a milestone number in the DFZ? ;) > It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. > Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done. Patrick W. Gilmore (Okay pat the back of your local network engineer if you forgot.) Aclamaciones, Cheers, À votre santé! > Nowadays boxes can easily take 5x the current 768 in > tcam and in control-plane -only sky is the limit, so for example there's no > need for any clever RR infrastructure designs anymore to hold all the routes > in your AS control-plane. > adamv0025 If you have an older router that can only handle x number of routes in TCAM less than the current number of routes; what software are you using to keep it default free? Or if the sky is really the limit, sell me your most or least expensive Tbps capable TCAM that will hold a routing table of 3M+ routes IPv4 and another 3M+ IPv6 without gimmicks or stipulations. (Low or high number of interfaces, small or god-sized box.) Let me know why you like what you have, or what you want to have. Be thankful for your network. What's in your rack? Good Luck On Sun, Sep 1, 2019 at 11:46 PM Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Weeks wrote: > > > Yes, my apologies for no reference. Further, I have no URL to > > point to as I read the book. (actual book; no e-something) > > > > Here's something: http://pouzinsociety.org > > as I can't find open access papers or something like that there, > let me stick to wikipedia. > > > Like the book, in the Wikipedia article you have to get through > > or skip the first part. In the book, that's the first 5 or so > > chapters. He just describes why, in his opinion, previous things > > have failed and the way he does it turns a lot of folks off. > > Another major misunderstanding of him is that he is not aware that > domain name with MX is application name and there are proposals > (though unnecessarily complicated) such as SRV to cover other > applications beyond SMTP. With SRV, non-default port numbers do not > have to be specified in URLs. > > So, we already have application names of domain names and mapping > mechanism between names and addresses/port_numers of DNS. > > E2E (end-to-end principle) is not relevant > > That someone can not recognize relevance between something and the > E2E principle does not mean much. > > IPv6 is/was a waste of time > > True, but, the reason is because IPv4 Internet with DNS, TCP > and NAT is good enough. > > That TCP identifies connections only by single source and destination > addresses is certainly a problem. But, the least painful solution > is to extend TCP to be able to identify connections by multiple > addresses. > > Properly designed NAT can save IP addresses a lot still keeping the > E2E transparency. > > > The RINA's fundamental principles are that computer > > networking is just Inter-Process Communication or IPC, > > That is a too much computer centric view not very > applicable to communications involving human beings, > where the E2E argument must often be applied to human > beings (true end) behind applications (tentative end > in a computer). > > Masataka Ohta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwf at loonybin.net Mon Sep 2 09:07:07 2019 From: rwf at loonybin.net (Rob Foehl) Date: Mon, 2 Sep 2019 05:07:07 -0400 (EDT) Subject: Mx204 alternative In-Reply-To: <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> References: <41d9817a-8d7d-dd0b-5875-5e433ce9d927@seacom.mu> <585b69de-95a3-4437-6067-dc34f9f50913@efes.iucc.ac.il> Message-ID: On Mon, 2 Sep 2019, Hank Nussbacher wrote: > What about handling LAG on 1Gb/sec links?  That is a major showstopper if > indeed it is missing: It works, but only about as well as anything else to do with 1G interfaces works on the MX204, and only then when you're running at least 18.1R3... > show version |match "(model|junos):" Model: mx204 Junos: 18.1R3-S4.2 > show interfaces ae0 |match speed Link-level type: Flexible-Ethernet, MTU: 1522, Speed: 40Gbps, > show lacp interfaces ae0 |find protocol LACP protocol: Receive State Transmit State Mux State xe-0/1/4 Current Slow periodic Collecting distributing xe-0/1/5 Current Slow periodic Collecting distributing xe-0/1/6 Current Slow periodic Collecting distributing xe-0/1/7 Current Slow periodic Collecting distributing > show chassis hardware |match SX Xcvr 4 REV 02 740-011613 - SFP-SX Xcvr 5 REV 02 740-011613 - SFP-SX Xcvr 6 REV 02 740-011613 - SFP-SX Xcvr 7 REV 02 740-011613 - SFP-SX > show interfaces xe-0/1/4 |match speed Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None, Flow control: Disabled, Speed Configuration: 1G It just gets more bizarre from there. Don't run 1G on these boxes if you can find any way to avoid it. -Rob From steve.spence at arkitechs.com Mon Sep 2 06:31:59 2019 From: steve.spence at arkitechs.com (Steve Spence) Date: Mon, 2 Sep 2019 06:31:59 +0000 Subject: The Curious Case of 143.95.0.0/16 In-Reply-To: <80277.1566973628@segfault.tristatelogic.com> References: <80277.1566973628@segfault.tristatelogic.com> Message-ID: Very interesting story great work Ronald -----Original Message----- From: NANOG On Behalf Of Ronald F. Guilmette Sent: Wednesday, August 28, 2019 2:27 AM To: nanog at nanog.org Subject: The Curious Case of 143.95.0.0/16 Fair Warning: Those of you not enamored of my long-winded exposés of various remarkable oddities of the IPv4 address space may wish to click on the tiny little wastebasket icons on your mail clients at this point. For the rest of you, please read on. I think you may find the following story intriguing. It contains at least a few surprising twists. +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ ++_ Our story today consists of three acts. Act 1 - It is Born ------------------ In mid-February of 1990 a new venture-capital backed company was formed in Sunnyvale, California. In some ways it was no different than the hundreds or thousands of hopeful high-tech startups that had been formed in Silicon Valley, both before and since. It started with a hopeful dream that, in the end, just didn't work out. The founders of this company settled initially on a temporary placeholder company name, XYZ Corporation: https://drive.google.com/file/d/1CkDNKq4M1DQKuTxBBhlYxUNAjU2cvDnY/view The mission of the company was to design and manufacture so-called X-Windows terminals. These would be diskless workstations, complete with CPUs, color (CRT) displays, graphics, memory, and an ethernet interface. The basic idea what that such a diskless workstation could run the free X-Windows client software, and that the system would be cheaper than ordinary PeeCees due to it not having any hard drives or optical drives. By some odd twist of fate, I myself was working in the same geographic area as a software engineer at around the same time, but I worked for a different Silicon Valley startup, just down the road from XYZ Corporation. And by a rather remarkable coincidence, the company I worked for had exactly the same goal and mission as the XYZ Corporation. The name of this other X-Windows workstation startup was Network Computing Devices, or just "NCD" for short. Quite obviously, both companies were inherently "network-centric" and thus, both requested and were granted blocks of IPv4 addresses. That wasn't at all within my area of responsibility at NCD, so I don't know who actually issued those blocks. My guess, based on published historical accounts, was that it was most probably Dr. Jon Postel who assigned the blocks. I'm sure that someone will correct me if I'm wrong. Months passed, and eventually the founders of XYZ Corporation settled on something they would use as a permanent replacement for their temporary placeholder corporate name. They decided to call the thing Athenix, Inc. Once they had settled on that name, they filed papers to update their records with the California Secretary of State's office: https://drive.google.com/file/d/1dUjsvSkzzdzUsIbIZCS7RF0afsI3uU0l/view At some point, they also and likewise updated the ARIN WHOIS record for the /16 block which had been assigned to them, on or about 1990-09-06, as was appropriate to reflect their new permanent corporate identity: https://pastebin.com/raw/YbH6zYrR More time passed and eventually it became clear that the entire world was not in fact breathlessly waiting for -two- companies to bring to market diskless X-Windows workstations. In fact, as history now shows, market demand would not support even one such company over the long term. Thus it came to pass in the year 1993 that an all-too-familiar end-of-life ritual played out once again in Silicon Valley. At Athenix, Inc. HQ in Sunnyvale, the people were all let go, including the founders. The desks, the chairs, the phones, the computers, and the tools were all sold at auction, with the proceeds going to the preferred shareholders, i.e. the poor fools who had put up all of the money for this now-failed venture in the first place, the venture capitalists. Foremost among those in this instance, was the venerable Menlo Park venture capital firm Kleiner Perkins. I've confirmed this historical account of the rise and fall of the original 1990-vintage Athenix, Inc. in multiple phone and email exchanges with both the original CEO of the original Athenix, Mr. Robert ("Bob") Garrow. lately of Los Altos, California, and also the original CTO of the company, Mr. John Garman, lately of Reno, Nevada. Act 2 - Rebirth - The Athenix Phoenix ------------------------------------- Fast forward fifteen years. On April 22, 2008 a pair of gentlemen in the Commonwealth of Massachusetts elected to establish a new corporate entity within the commonwealth. It's name would be Athenic, Inc.[1] https://drive.google.com/file/d/1jYUqtgYprI4iyJkTT91-yRBYJt0c2ufF/view https://drive.google.com/file/d/1mlVML8z7vzp7aeGmOK-3cWBBJeNBuThn/view As you can see in the documents above, a certain Mr. Ofer Inbar and a certain Mr. Robert Anita, both of the greater Boston area, formed this new corporate entity in Massachusetts. At its formation, the younger Mr. Inbar was the President, while the more senior Mr. Antia served as the corporate secretary and treasurer. Various other records, which I shall not include here, suggest that both Mr. Inbar and Mr. Anita were at some point in the distant past affiliated, in at least some tangential way, with the well-regarded white-hat Boston area hacking collective known as L0pht, aka L0pht Heavy Industries. I cannot say much about this apparent connection, other than to say that the details I have ferreted out about this connection are sketchy at best. I do however have it on reasonably good authority that Mr. Inbar has of late relocated to the greater Seattle metropolitan area, and that he is or was working as a network administrator for Google, Inc. in that area. Mr. Antia, in contrast, is still, when I last checked, a resident of the greater Boston area, and is a well regarded "graybeard" in the computing community in and around Boston, having been in the business, one way or another, for decades. Mr. Anita currently serves as President of the Boston area chapter of the public/private critical infrastructure cybersecurity defense partnership known as InfraGuard. https://infragard-boston.org/ The evidence currently available to me suggests that not long after the creation of Mr. Inbar's and Mr. Antia's Massachusetts Athenix, Inc., ARIN elected to delegate responsibility for the reverse DNS for the 143.95.0.0/16 IPv4 block to a pair of name servers called dns1.athenixinc.com and dns2.athenixinc.com. That delegation was already in place by 2010-06-24, which is about the time that Farsight Security Inc., my data source, first began passively collecting its historical archives of DNS response records. Historical records made available to me by Domaintools, LLC indicate that the athenixinc.com domain name was, at least initially, registered to Mr. Anita in Lincoln, Massachusetts. https://pastebin.com/raw/GNhbFDFz Subsequent historical WHOIS data collected by Domaintools in relation to the athenixinc.com domain name shows that after Mr. Anita, the domain name registration passed into the hands of at least one other individual, and eventually, to an entirely different corporate entity. We will come to that shortly. Almost a year ago now, when I was first investigating the 143.95.0.0/16 block, I attempted to interview Mr. Inbar by phone regarding his and Mr. Anita's Athenix, Inc. and the unusual history of the 143.95.0.0/16 block. It did not go well. Mr. Inbar was apparently reluctant to engage with me by phone on these or any other topics. He and I did have a few brief and truncated email exchanges after that however, but apparently my questions regarding how Mr. Inbar and Mr. Anita came to exercise effective day-to-day control over the 143.95.0.0/16 ARIN legacy block were not ones that Mr. Inbar felt in any way obliged to answer, and at some point he simply ceased answering my emails. In contrast, Mr. Antia was a veritable fount of information and he and I had multiple phone conversations as well as multiple email exchanges. From these exchanges I quickly deduced that Mr. Antia saw absolutely nothing wrong with, much less anything at all to be shy about with respect to the history of the 143.95.0.0/16 block -or- his formation, along with Mr. Inbar, of a new Athenix, Inc. in Massachusetts back in in 2008. Quite the contrary! Mr. Anita was kind enough for forward me a copy of the following really rather remarkable lease agreement, in which Mr. Inbar and Mr. Anita together undertook to lease the 143.95.0.0/16 IPv4 block to a certain Nevada- incorporated and Colorado-resident limited liability company known as Media Breakaway, LLC: https://drive.google.com/file/d/1ASXrUsiNAIq1IIZO5Lw1BqjD1qucqFmI/view As you can see, the term of the lease is 20 years, beginning from the 28th day of May, 2008. The compensation to be paid to Mr. Inbar's and Mr. Anita's Massachusetts Athenic, Inc. in return for this 20 year leasehold was to be $100,000 USD As Mr. Anita related to me, this sum was in fact paid, and Mr. Inbar and Mr. Anita split it evenly. (But of course, I have no way to independently verify that.) For those unaware, I pause here just long enough to note that the CEO of Media Breakaway, LLC is none other than Mr. Scott Richter, one-time "Spam King" and a man who both Wikipedia and the KrebsOnSecurity blog have asserted is a convicted felon. And of couurse, this is the very same Scott Richter who figured so prominently in Brian Krebs' report about pilfered legacy ARIN /16 blocks, published on the Washington Post, way back in April, 2008. Of course, in my phone conversations with Mr. Anita, I acquainted him with these relevant historical allegations. He confessed at the time that he had not personally done much at all in the way of due diligence with respect to either Mr. Richter or his company -- a lapse which I personally found (and find) quite unfortunate, to say the least, and not least because of Mr. Anita's position as the President of the Boston Chapter of Infraguard, the public/private partnership whose mission is the protection of the nation's critical infrastructure assets from cyber-threats. I would have hoped that a person in such a position would have been in the general habit of exercising at least some due diligence with respect to the people he does business with and, in this specific instance, preferably at some moment *before* Mr. Anita cashed his $50,000 check. Act 3 - Final Dispensation -------------------------- Now we come to the final remarkable chapter in the already remarkable history of the 143.95.0.0/16 legacy IPv4 ARIN address block. Some months after the formation of the Massachusetts "Athenix, Inc.", on Sepetember 2nd, 2008 a new corporate entity calling itself "Athenix Corporation" was incorporated in the State of California. Curiously, this third Athenix gave both its actual address and its mailing address as 10 Corporate Drive, Burlington, MA 01813. https://drive.google.com/file/d/1GHhwuPGPKdx5n46cYQ2UhTGiMSdxonFu/view https://drive.google.com/file/d/1ZLtcY2HWoi5vmNFAJleHep8DxIS3igVR/view As it happens, that street address is also the headquarters address of the publicly-traded Endurance International Group, Inc. (EIGI). There is substantial evidence indicating that EIGI is effectively in complete functional control of the 143.95.0.0/16 address block at the present moment. The company's primary ASN, AS29873 and also, an AS number belonging to one of the company's many acquired subsidiaries, A Small Orange LLC, AS62729 are each routing significant portions of the 143.95.0.0/16 block at the present time. https://bgp.he.net/AS29873#_prefixes https://bgp.he.net/AS62729#_prefixes Additionally, on or about 2017-05-22, EIGI became the registrant of the athenixinc.com domain, whose associated name servers (dns1 dns2) had provided revserse DNS service for the entire 143.95.0.0/16 block during 2011 and 2012. Delegation of the reverse DNS responsibility for the entire 143.95.0.0/16 block changed on or about 2013-11-28 so that the new name servers were ones associated with the domain name asonoc.com, at least according to the relevant historical data provided to me by Farsight Security, Inc. https://pastebin.com/raw/MVmzhirc Historically, and as recently as 2018-04-20, the domain name asonoc.com was and has been registered to the EIGI subsidiary A Small Orange LLC. https://pastebin.com/raw/Xy8UHZNw Responsibility for the reverse DNS for the entire 143.95.0.0/16 block remains delegated to the rdns1.asonoc.com and rdns2.asonoc.com name servers at the present moment. EIGI is primarily a web hosting company. It has, over time. exhibited a tendency to acquire other and smaller web hosting companies which it has then absorbed into and under its corporate unbrella. Unlike most other corporate acquirers however, EIGI is somewhat unique in its notable tendency to not rebrand its acqusitions so that they would be additive to its main corporate brand, generally electing instead to maintain the pre-acqusition brand names for its newly acquired web hosting businesses. One such EIGI- acquired propery that has retained its pre-acqusition brand name is the aforementioned Texas-based web hosting company called A Small Orange LLC, aka AS62729. (Those who may be interested in more backgound regarding EIGI and past controversies, specifically with relating to the company's accounting practices as well as the online activities of its clientele, are encouraged to consult the footnotes below.[2]) The available evidence suggests the clear possibility that EIGI and its subsidiary, A Small Orange LLC. may be controling and using the 143.95.0.0/16 block in a manner inconsistant with ordinary business rules of fair dealing and/or in a manner inconsistant with current ARIN policy, and further, that the company and/or its various C-suite officers may have arrived at this current situation not by happentance but rather by some very carefully considered premeditation. I mention specifically EIGI's C-suite officers, because the available evidence suggests that EIGI's apparent takeover of the 143.95.0.0/16 block was not purely or only the product of some unsanctioned rogue activity on the part of lower-level company functionaries. Multiple publicly available records obtained from the web site of the California Secretary of State implicate multiple current and former EIGI C-suite officers as having been, at the very least, directly aware of the formation of the third "Athenix", even if perhaps not directly or personally responsible for that rather suspicious company formation. https://drive.google.com/file/d/12gm41jG9iFIC9KvIJmfWNjUqCmRtTfxN/view https://drive.google.com/file/d/1zdhru_hpYVIJfVKi-s5X1MW0znrErJzQ/view https://drive.google.com/file/d/1dVHDSPKD4Qvur9rzCK9YZDEtOkFA2raS/view Plese note that Mr. Hari Ravichandran is the now-former CEO of EIGI. Mr. David Bryson was and remains EIGI's Chief Legal Officer. Mr. Marc Montagner was and remains EIGI's Chief Financial Officer. Mr. Jeffrey Fox is EIGI's current CEO, having succeded Mr. Ravichandran in that post. https://www.endurance.com/our-company/our-team https://exechange.com/7850/endurance-ceo-hari-ravichandran-leaves-2/7850 https://www.linkedin.com/in/hari-ravichandran-9b949b8 https://jumpv.com/meet-the-team/ https://www.linkedin.com/in/davidbryson https://www1.salary.com/David-C-Bryson-Salary-Bonus-Stock-Options-for-ENDURANCE-INTL-GRP-HLDGS-INC.html https://www.linkedin.com/in/marc-montagner-b112a1b1 https://wallmine.com/people/6106/marc-montagner https://www.linkedin.com/in/jeff-fox-820a0413 https://wallmine.com/people/2962/jeffrey-h-fox Given that EIGI's rights in and/or legal title to the 143.95.0.0/16 block appear to be, at best, on somewhat shaky ground, and given that the new 2008-vintage Athenix Corporation does not obviously possess any other obvious or apparent assets to speak of, it appears, to this writer at least, more than a little incongruous to see that EIGI apparently listed Athenix Corporation as a collateral asset on what, to a layman such as myself, appears to be a bank collateral statement which was filed, apparently in 2013, with the United States Securities and Exchange Comission. https://www.sec.gov/Archives/edgar/data/1237746/000119312514077774/d635170dex1025.htm All I can say about that is that I personally was turned down for a bank loan, some years ago, when I attempted to use the monthly -liability- of my recurring water bills as collateral for the loan. But then I have never been anywhere near as accomplished at high finance as any of the gentlemen mentioned above surely are. Responses --------- More than 24 hours prior to posting this message, I reached out to the press contact email address listed on EIGI's web site, press (at) endurance.com, for comment about the facts elaborated above. No response was received from the company by press time. Prior to posting, I also reached out to John Curran @ ARIN for his response to the facts set forth above. John was kind enough to provide the following official on-the-record ARIN response: ARIN does not comment on specific registry changes (as number resource change requests are made in confidence), but we do take matters of potential number resource fraud quite seriously. I would recommend that you report potential incidents of registry fraud (if you have not done so already) via our Internet Number Resource Fraud Reporting process at https://www.arin.net/resources/fraud/, and we will promptly investigate. – John Curran, CEO, ARIN +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ ++_ FULL DISCLOSURE: I hold no postions, either short or long in EIGI or in any related company. +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ ++_ Acknowledgements ---------------- My thanks to Farsight Security, Inc. and to Domaintools, LLC for their kind support of this research. Footnotes: ======================================================================= [1] Rather remarkably, the Massachusetts Athenix, Inc. was incorporated a mere six days before my friend, journalist Brian Krebs, put up a story on the Washington Post web site, detailing how a pair of legacy ARIN IPv4 /16 blocks had somewhat inexplicably ended up in the hands of one of the world's most notorious spammers, Scott Richter. That story, as some of you will already know, alleged that a rather simple and yet elaborate fraud had been perpetrated against ARIN, a fraud which amounted to nothing less than corporate identity theft, with the one and only apparent goal being the effective take-over of two quite valuable legacy ARIN IPv4 /16 blocks, a goal which was, it appeared, successfully achieved with only a relatively minor investment of effort and expense. [2] In recent years, all has not gone well for EIGI. In the year 2015, a somewhat mysterious New York City short seller using the pen name Gotham City Research published a sequence of four reports detailing his beliefs that all was not as it should be at EIGI, both with respect to the company's financial statements and with respect to its clientele and their (allegedly) questionable online activities. 2015-04-28 - Endurance International Group - A Web of Deceit https://bit.ly/2KZXPLA 2015-04-29 - Initial Follow-up To: A Web of Deceit https://bit.ly/2L5Vv4o 2015-05-05 - EIGI’s Adjusted EBITDA is a Meaningless Metric https://bit.ly/342x4xE 2015-08-03 - Endurance International Group: Malicious Activities https://bit.ly/30Gk4vr The value of EIGI stock dropped rather precepitously following the publication of the Gotham City Research reports and has yet to recover to its earlier highs. https://drive.google.com/file/d/1BaGzFglnrbAca9DsRIqt2eD0m_jnrCMw/view The SEC's investigation of EIGI, and the SEC's subsequent enforcement actions against the company and its officers in 2018 also didn't help matters much with respect to EIGI and its stock price: https://www.sec.gov/enforce/33-10504-s https://www.bizjournals.com/boston/news/2018/08/22/former-endurance-group-execs-pay-1-4m-to-settle.html From saku at ytti.fi Tue Sep 3 12:38:11 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 3 Sep 2019 15:38:11 +0300 Subject: Mx204 alternative In-Reply-To: <212e01d56250$b078a520$1169ef60$@netconsultings.com> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> <212e01d56250$b078a520$1169ef60$@netconsultings.com> Message-ID: On Tue, 3 Sep 2019 at 15:10, wrote: > Not true. > This is the case only in fixed pipelines. Also true in say MX Trio and ASR9k EZchip, I can't immediately think of platform where ACL or QoS costs pps. ASR9k is TCAM for ACL so O(1) and MX Trio is just fast enough to not affect pps performance. QoS isn't expensive at all in lookup terms, just expensive to have the memory. -- ++ytti From adamv0025 at netconsultings.com Tue Sep 3 13:15:24 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 3 Sep 2019 14:15:24 +0100 Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> <01ef01d561b5$dcee5780$96cb0680$@netconsultings.com> <212e01d56250$b078a520$1169ef60$@netconsultings.com> Message-ID: <213e01d56259$a5e3d180$f1ab7480$@netconsultings.com> > From: Saku Ytti > Sent: Tuesday, September 3, 2019 1:38 PM > > On Tue, 3 Sep 2019 at 15:10, wrote: > > > Not true. > > This is the case only in fixed pipelines. > > Also true in say MX Trio and ASR9k EZchip, I can't immediately think of > platform where ACL or QoS costs pps. ASR9k is TCAM for ACL so O(1) and MX > Trio is just fast enough to not affect pps performance. QoS isn't expensive at > all in lookup terms, just expensive to have the memory. > I'm afraid I'd have to disagree. adam From jtk at depaul.edu Tue Sep 3 13:32:18 2019 From: jtk at depaul.edu (John Kristoff) Date: Tue, 3 Sep 2019 08:32:18 -0500 Subject: Weekly Routing Table Report In-Reply-To: <82a3456ca8c6442fadfeec5feee8545b@ex16prd04a.dpu.depaul.edu> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <82a3456ca8c6442fadfeec5feee8545b@ex16prd04a.dpu.depaul.edu> Message-ID: <20190903083218.43873f26@p50.localdomain> On Sat, 31 Aug 2019 10:35:39 +0000 Masataka Ohta wrote: > If you can't accept the following principle of the End to End > argument: I think it is better to stick with what the paper refers to them e2e as, an argument. The e2e paper is by far one of the closest things we have to network canon and its reasoning is exceptionally simple and compelling. Yet, these are arguments, not laws. Even the original authors have revisited and questioned the original ideas. The paper also says something about needing a great deal of system implementation detail to intelligently make the choice of where to place functions. I like pointing that out, because it seems people often miss this part in the paper where the only form of the word intelligence is ever used in the paper. Note, I'm not agreeing or disagreeing with any particular position about multihoming in this thread, just trying to argue that the e2e paper is a lot more nuanced than is often presented in debates especially since it has often been used to support opposing views. :-) John From nanog2 at adns.net Tue Sep 3 16:17:35 2019 From: nanog2 at adns.net (ADNS NetBSD List Subscriber) Date: Tue, 3 Sep 2019 11:17:35 -0500 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation Message-ID: <6A23DA07C7724B15936416567284BC2C@TAKA> I have a need for a BGP enabled connection in the River North section of Chicago. We have a small number of IP blocks that we want to use. Currently, we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking at downsizing and bringing stuff in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). I know RCN offers business cable-modem service but probably not BGP. Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size router, but none of them seem to do BGP (not surprising). Any recommendations on hardware would be welcome as well -------------- next part -------------- An HTML attachment was scrubbed... URL: From florianb at globalone.io Tue Sep 3 17:52:34 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Tue, 3 Sep 2019 19:52:34 +0200 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: <6A23DA07C7724B15936416567284BC2C@TAKA> References: <6A23DA07C7724B15936416567284BC2C@TAKA> Message-ID: <03A50E56-DE08-4591-A575-3DE2B3C2ACA4@getmailspring.com> Might be worth to consider running a software router on that scale with perhaps some cheap quad-port GbE PCIe NICs. BIRD would be the BGP daemon to go, or FRRouting if you want an integrated shell. Hardware routers for 100 Mbit egress seem a bit overpowered, however, as scaleable you want to go, some Ubiquiti routers might be a cheap option. As for transit, have you considered a redundant tunnel-based solution instead? You can run that transparently on top of your RCN connection, with negligible costs for your commit and no additional connection fees. On Sep. 3 2019, at 6:17 pm, ADNS NetBSD List Subscriber wrote: > I have a need for a BGP enabled connection in the River North section of Chicago. We have a small number of IP blocks that we want to use. Currently, we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking at downsizing and bringing stuff > in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). > > I know RCN offers business cable-modem service but probably not BGP. > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size router, but none of them seem to do BGP (not surprising). Any recommendations on hardware would be welcome as well > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Tue Sep 3 18:19:04 2019 From: matt at netfire.net (Matt Harris) Date: Tue, 3 Sep 2019 13:19:04 -0500 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: <6A23DA07C7724B15936416567284BC2C@TAKA> References: <6A23DA07C7724B15936416567284BC2C@TAKA> Message-ID: On Tue, Sep 3, 2019 at 12:44 PM ADNS NetBSD List Subscriber wrote: > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” > size router, but none of them seem to do BGP (not surprising). Any > recommendations on hardware would be welcome as well > I can think of lots of smaller, even desktop sized routers that have no problem doing BGP assuming you're only taking a single transit circuit and only accepting a default route from your upstream provider. Ubiquiti's tiniest EdgeRouters which cost around $100 will do BGP just fine under those circumstances if you're not pushing tons of traffic or pps. If you want something a little nicer/fancier, you can get a Juniper SRX (probably a 300, 320, or 345 depending on how much bandwidth you're going to use). If you want to run multiple transits and take full tables, then at that point I'd recommend going a bit bigger: maybe a Juniper MX or a Cisco ASR. But even the higher-end Ubiquiti EdgeRouter series products can handle full tables if you understand and accept their limitations in doing so if budget is a huge concern but you still need to take full tables. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From budic at onholyground.com Tue Sep 3 18:46:01 2019 From: budic at onholyground.com (Darrell Budic) Date: Tue, 3 Sep 2019 13:46:01 -0500 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: <03A50E56-DE08-4591-A575-3DE2B3C2ACA4@getmailspring.com> References: <6A23DA07C7724B15936416567284BC2C@TAKA> <03A50E56-DE08-4591-A575-3DE2B3C2ACA4@getmailspring.com> Message-ID: I’ve had BGP from comcast business in River North before, not sure what their minimum bandwidth is for that. Tunnels may be simplest at that bandwidth level. > On Sep 3, 2019, at 12:52 PM, Florian Brandstetter via NANOG wrote: > > Might be worth to consider running a software router on that scale with perhaps some cheap quad-port GbE PCIe NICs. BIRD would be the BGP daemon to go, or FRRouting if you want an integrated shell. Hardware routers for 100 Mbit egress seem a bit overpowered, however, as scaleable you want to go, some Ubiquiti routers might be a cheap option. > > As for transit, have you considered a redundant tunnel-based solution instead? You can run that transparently on top of your RCN connection, with negligible costs for your commit and no additional connection fees. > > On Sep. 3 2019, at 6:17 pm, ADNS NetBSD List Subscriber wrote: > I have a need for a BGP enabled connection in the River North section of Chicago. We have a small number of IP blocks that we want to use. Currently, we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking at downsizing and bringing stuff > in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). > > I know RCN offers business cable-modem service but probably not BGP. > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size router, but none of them seem to do BGP (not surprising). Any recommendations on hardware would be welcome as well > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Tue Sep 3 19:32:56 2019 From: bruns at 2mbit.com (Brielle) Date: Tue, 3 Sep 2019 13:32:56 -0600 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: References: <6A23DA07C7724B15936416567284BC2C@TAKA> Message-ID: On 9/3/2019 12:19 PM, Matt Harris wrote: > But even the higher-end Ubiquiti EdgeRouter series products can handle > full tables if you understand and accept their limitations in doing so > if budget is a huge concern but you still need to take full tables. As long as you stick with the 1.10.10 series of firmware, the EdgeRouter series is pretty stable. I run an EdgeRouter Infinity (8 x 10G SFP+) at home with both IPv4 and IPv6 BGP feeds on a CenturyLink Fiber+ connection. You can get the original EdgeRouter Lite for sub $100 and it will have no problem taking a full feed for both v4 and v6... However, better choice is the EdgeRouter 4, which is a bit newer and much faster. There's also the ER6P if you need something with more ports, or even the ER12/12P if you want something with a built in network switch. Just avoid the budget oriented ERX and ER10X which lack the RAM. All of the ERs are low power consumption and Linux based with a Vyatta/VyOS/Juniper-like CLI, so pretty easy to work with. (I do Ubiquiti deployments, so can answer a lot of questions anyone might have). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ross at tajvar.io Tue Sep 3 20:11:13 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 3 Sep 2019 16:11:13 -0400 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: References: <6A23DA07C7724B15936416567284BC2C@TAKA> Message-ID: I will note that Comcast will do BGP on their enterprise fiber circuits. Comcast DIA (which they call EDI) comes in increments of 1M up to 10M, then 10M up to 100M, etc. So you could get 10M or 80M (not sure if "10MB/Sec" means 10Mbps or 80MBps) and do BGP over that, if it's available. RCN is likely similar but I'm not as familiar with their offerings. On Tue, Sep 3, 2019 at 3:35 PM Brielle wrote: > On 9/3/2019 12:19 PM, Matt Harris wrote: > > But even the higher-end Ubiquiti EdgeRouter series products can handle > > full tables if you understand and accept their limitations in doing so > > if budget is a huge concern but you still need to take full tables. > > As long as you stick with the 1.10.10 series of firmware, the EdgeRouter > series is pretty stable. I run an EdgeRouter Infinity (8 x 10G SFP+) at > home with both IPv4 and IPv6 BGP feeds on a CenturyLink Fiber+ connection. > > You can get the original EdgeRouter Lite for sub $100 and it will have > no problem taking a full feed for both v4 and v6... However, better > choice is the EdgeRouter 4, which is a bit newer and much faster. > > There's also the ER6P if you need something with more ports, or even the > ER12/12P if you want something with a built in network switch. Just > avoid the budget oriented ERX and ER10X which lack the RAM. > > All of the ERs are low power consumption and Linux based with a > Vyatta/VyOS/Juniper-like CLI, so pretty easy to work with. > > (I do Ubiquiti deployments, so can answer a lot of questions anyone > might have). > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Tue Sep 3 20:13:10 2019 From: bruns at 2mbit.com (Brielle) Date: Tue, 3 Sep 2019 14:13:10 -0600 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: <69414933-770B-464C-B9DA-A8F7A61566A1@getmailspring.com> References: <69414933-770B-464C-B9DA-A8F7A61566A1@getmailspring.com> Message-ID: <2f1b3937-8b0e-83bd-d0e7-6d155fca79a6@2mbit.com> On 9/3/2019 1:54 PM, Florian Brandstetter wrote: > I don't see full tables happening from a memory perspective on the > EdgeRouter Lite, you would want to look at something with at least 2 GiB > of memory to keep the whole system running smoothly, and when using > Quagga and Zebra, that's still aimed rather low. FRRouting at this point > uses 2 GiB for 4 full tables on an x86 system, without any magic attached. I'm going based on actual tests done when the ERL came out in 2012. While its cores are anemic by today's standards, it handled multiple full tables fine back then. Since then, the ERs have stopped using Quagga/Zebra and now use ZebOS (which is also used in several other commercial products). It's a bit faster and smaller. In today's world, its tight, but it will still work. > > You might want to install something like OpenWRT (which I don't know the > possibility of on an ERL), and run BIRD if you're tied to a low memory > footprint, however, in a base vendor-generic setup of the ERL, it's > beyond my understanding why one would even suggest running a full table > on it. As I pointed out, its the dirt cheap option. Better option is the ER4 and later which is better suited to the increased table size. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mohta at necom830.hpcl.titech.ac.jp Wed Sep 4 01:37:43 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 4 Sep 2019 10:37:43 +0900 Subject: Weekly Routing Table Report In-Reply-To: <20190903083218.43873f26@p50.localdomain> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <82a3456ca8c6442fadfeec5feee8545b@ex16prd04a.dpu.depaul.edu> <20190903083218.43873f26@p50.localdomain> Message-ID: John Kristoff wrote: >> If you can't accept the following principle of the End to End >> argument: > > I think it is better to stick with what the paper refers to them e2e as, > an argument. The e2e paper is by far one of the closest things we > have to network canon and its reasoning is exceptionally simple and > compelling. Yet, these are arguments, not laws. Proof of the argument seems to be easy, see slide 11 of http://www.ocw.titech.ac.jp/index.php?module=General&action=DownLoad&file=201904901-2662-0-35.pdf&type=cal&JWC=201904901 > Even the original > authors have revisited and questioned the original ideas. Extension of the argument to intermediate systems (to make the argument directly applicable to protocols used within a network such as routing protocols) and modern layering (the original paper is skeptical to layering stating "it is fashionable these days to talk about layered communication protocols" obviously because OSI layering popular at that time is terrible) should be useful. > Note, I'm not agreeing or disagreeing with any particular position > about multihoming in this thread, Can you agree that, by applying the argument to function of multihoming, we can get the following: multihoming can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing multihoming as a feature of the communication system itself is not possible. then, the constructive question to ask is: with the knowledge and help of the application standing at the end points of the communication system, can multihoming completely and correctly be implemented? Once the question is asked, it is not very difficult to construct a multihoming architecture to show the answer is "yes". With such questions, the principle is very powerful tool to know the right direction to perform research. > just trying to argue that the e2e > paper is a lot more nuanced than is often presented in debates > especially since it has often been used to support opposing views. :-) The most serious problem with such debates is that people just do not read the original paper: http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf and have their own random definitions on the principle, which makes the debates completely meaningless. There are a lot of proofs saying the principle is invalid, using their own definitions of the principle. Masataka Ohta From florianb at globalone.io Tue Sep 3 19:54:07 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Tue, 3 Sep 2019 21:54:07 +0200 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: References: Message-ID: <69414933-770B-464C-B9DA-A8F7A61566A1@getmailspring.com> Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of which after startup, roughly 491 MiB can be utilized. 119 MiB of the remaining memory are allocated by the base of the router already, which leaves you with a remainder of 372 MiB memory. Memory usage depends on the architecture for objects, for example there's a large difference between x86 and x86_64, since on x86_64, the compiler will generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 architecture, which will have a similar trade-off. To get to the point, let's have a quick look at the components using memory: bgpd, zebra, kernel. Roughly 180 MiB of memory are required to keep a single full table in bgpd alone, leaving you with 192 MiB of free memory. Accounting further, zebra will eat at least another 100 MiB for exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. At this point, you have a mere 92 MiB left for fitting the routes into the kernel, and to leave room for RX buff ers on sockets. I don't see full tables happening from a memory perspective on the EdgeRouter Lite, you would want to look at something with at least 2 GiB of memory to keep the whole system running smoothly, and when using Quagga and Zebra, that's still aimed rather low. FRRouting at this point uses 2 GiB for 4 full tables on an x86 system, without any magic attached. Having kept it unmentioned, the EdgeRouter Lite has a dual-core with 500 MHz, and surely your BGP updates processing isn't offloaded, hence you will pretty quickly kill the whole router when you flood it with a full table, unless you set very low queue sizes, which isn't really reliable though since you generally want BGP to converge fast - not after a period of 15 minutes with the CPU sitting on 100%. You might want to install something like OpenWRT (which I don't know the possibility of on an ERL), and run BIRD if you're tied to a low memory footprint, however, in a base vendor-generic setup of the ERL, it's beyond my understanding why one would even suggest running a full table on it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Wed Sep 4 18:17:15 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 4 Sep 2019 21:17:15 +0300 Subject: Looking for Cloudfront clue Message-ID: <68cf5768-7a1f-9072-68a3-677abcd70958@efes.iucc.ac.il> Can someone with routing/BGP/peering clue in AWS's Cloudfront, please contact me offlist? Thanks, Hank From sean at donelan.com Wed Sep 4 19:25:42 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 4 Sep 2019 15:25:42 -0400 (EDT) Subject: Cat 5 hurricane -- How are the Bahamas doing? In-Reply-To: References: Message-ID: On Mon, 2 Sep 2019, Sean Donelan wrote: > It is too early for damage assessments. BTC, local Bahama telecommunications > company, is reporting widespread power outages, and intermittent mobile and > wireline telephone service. The Abaco Islands in northern Bahamas seem to be > taking the worst of it. Folks asking for updates on Bahamas. The simple answer is I'm not hearing any information out of the Bahamas, which is concerning in itself. My big secret how I do network outage reports is people send me the information. Usually, I get lots of random emails from network people about problems all over the U.S. and other places in the world. But Bahamas has gone very quiet. From jeremyparr at gmail.com Wed Sep 4 21:30:37 2019 From: jeremyparr at gmail.com (Jeremy Parr) Date: Wed, 4 Sep 2019 17:30:37 -0400 Subject: Cat 5 hurricane -- How are the Bahamas doing? In-Reply-To: References: Message-ID: Things are bad in some places, fine in others. I can provide a more thorough update this evening. On Wed, Sep 4, 2019, 15:27 Sean Donelan wrote: > On Mon, 2 Sep 2019, Sean Donelan wrote: > > It is too early for damage assessments. BTC, local Bahama > telecommunications > > company, is reporting widespread power outages, and intermittent mobile > and > > wireline telephone service. The Abaco Islands in northern Bahamas seem > to be > > taking the worst of it. > > Folks asking for updates on Bahamas. The simple answer is I'm not hearing > any information out of the Bahamas, which is concerning in itself. > > > My big secret how I do network outage reports is people send me the > information. Usually, I get lots of random emails from network people > about problems all over the U.S. and other places in the world. But > Bahamas has gone very quiet. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at telcodata.us Wed Sep 4 22:02:26 2019 From: paul at telcodata.us (Paul Timmins) Date: Wed, 4 Sep 2019 18:02:26 -0400 Subject: BGP Enabled transit in Chicago (River North) and equipment recommendation In-Reply-To: <69414933-770B-464C-B9DA-A8F7A61566A1@getmailspring.com> References: <69414933-770B-464C-B9DA-A8F7A61566A1@getmailspring.com> Message-ID: <0720ce68-f761-b68c-6f96-88852f75c0dc@telcodata.us> They are obviously not running full tables on their 3640. I'd imagine a raspberry pi would have more BGP capability and throughput than a 3640, though I don't recommend doing that even as a joke. But an ERR would be fine if they're expecting nothing more than a slightly faster 3640 with maybe some extra features. On 9/3/19 3:54 PM, Florian Brandstetter via NANOG wrote: > Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of > which after startup, roughly 491 MiB can be utilized. 119 MiB of the > remaining memory are allocated by the base of the router already, > which leaves you with a remainder of 372 MiB memory. Memory usage > depends on the architecture for objects, for example there's a large > difference between x86 and x86_64, since on x86_64, the compiler will > generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 > architecture, which will have a similar trade-off. To get to the > point, let's have a quick look at the components using memory: bgpd, > zebra, kernel. Roughly 180 MiB of memory are required to keep a single > full table in bgpd alone, leaving you with 192 MiB of free memory. > Accounting further, zebra will eat at least another 100 MiB for > exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. > At this point, you have a mere 92 MiB left for fitting the routes into > the kernel, and to leave room for RX buffers on sockets. > > I don't see full tables happening from a memory perspective on the > EdgeRouter Lite, you would want to look at something with at least 2 > GiB of memory to keep the whole system running smoothly, and when > using Quagga and Zebra, that's still aimed rather low. FRRouting at > this point uses 2 GiB for 4 full tables on an x86 system, without any > magic attached. > > Having kept it unmentioned, the EdgeRouter Lite has a dual-core with > 500 MHz, and surely your BGP updates processing isn't offloaded, hence > you will pretty quickly kill the whole router when you flood it with a > full table, unless you set very low queue sizes, which isn't really > reliable though since you generally want BGP to converge fast - not > after a period of 15 minutes with the CPU sitting on 100%. > > You might want to install something like OpenWRT (which I don't know > the possibility of on an ERL), and run BIRD if you're tied to a low > memory footprint, however, in a base vendor-generic setup of the ERL, > it's beyond my understanding why one would even suggest running a full > table on it. > Sent from Mailspring -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Wed Sep 4 23:08:31 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Wed, 4 Sep 2019 18:08:31 -0500 Subject: Cat 5 hurricane -- How are the Bahamas doing? In-Reply-To: References: Message-ID: Bahamas are essentially flattened as per recent reports. Or in other words .... BAAAAAAD -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Sep 4, 2019, at 14:26, Sean Donelan wrote: > > On Mon, 2 Sep 2019, Sean Donelan wrote: >> It is too early for damage assessments. BTC, local Bahama telecommunications company, is reporting widespread power outages, and intermittent mobile and wireline telephone service. The Abaco Islands in northern Bahamas seem to be taking the worst of it. > > Folks asking for updates on Bahamas. The simple answer is I'm not hearing any information out of the Bahamas, which is concerning in itself. > > > My big secret how I do network outage reports is people send me the information. Usually, I get lots of random emails from network people about problems all over the U.S. and other places in the world. But Bahamas has gone very quiet. > From karim.adel at gmail.com Thu Sep 5 05:09:45 2019 From: karim.adel at gmail.com (Kasper Adel) Date: Wed, 4 Sep 2019 22:09:45 -0700 Subject: Art and Tech is madness Message-ID: In SPRING a time when segment and routing had no mismatch, a time when isis and ospf ate a forbidden encap, all they had to do was forward bgp like its hot, but crazy flapping doesnt leave any real LDP without some real FSM check, My dynamic unnumbered neighbor. Suddenly, Out of order, an AS is overridden, we see frames dropping, we sniff a bit and it turns out, sfps are burning, we are in a place right now where ping and pong are jittery, their latency is tested, they cant strengthen their icmp bond with a warm bfd message, how can they keep everyone in ACK, safe from teardown and dampening, with this kind of ixp relationship??! but oh admin, we know forwarding works in its own mysterious ways. We are left with two non rfc compliant scavengers, bastard 802.1ah fools in a leaky yet shaped, buffer display of some runts and nimbles, and a giant too. They start their life of a packet, leaving one interface to a neighbor, from an adjacency to a peer, an endless loop, its a prefix hijack, but as they move from one stack to another, finding their way through a tunnel of memory failures and RMAs, one hell of an LSP ride, through firewall horrors and MTU mismatches, leaving behind, a sea of syslog messages and snmp alarms. Anyway, Their ttl expired and one funny access list abruptly denies them life, sending them to Null0, where they can be peacefully discarded. Thats what tech does to yeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 5 08:35:19 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 5 Sep 2019 17:35:19 +0900 Subject: IPAM recommendations Message-ID: Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mansaxel at besserwisser.org Thu Sep 5 08:37:49 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 5 Sep 2019 10:37:49 +0200 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <20190905083748.GL29721@besserwisser.org> Subject: IPAM recommendations Date: Thu, Sep 05, 2019 at 05:35:19PM +0900 Quoting Mehmet Akcin (mehmet at akcin.net): > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. nipap infoblox if you are an enterprise needing AD herding and got too much cash. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I had pancake makeup for brunch! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From toddunder at gmail.com Thu Sep 5 08:39:38 2019 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 5 Sep 2019 04:39:38 -0400 Subject: IPAM recommendations In-Reply-To: References: Message-ID: What have you evaluated so far? Can you share your evaluation grid, how you selected the candidates, how you are weighting criteria and specific interesting findings so far? Thanks! t On Thu, Sep 5, 2019 at 4:37 AM Mehmet Akcin wrote: > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. > > thanks in advance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 5 08:42:20 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 5 Sep 2019 17:42:20 +0900 Subject: IPAM recommendations In-Reply-To: References: Message-ID: Not much beyond this, https://appuals.com/the-5-best-ip-address-management-ipam-software/ On Thu, Sep 5, 2019 at 5:39 PM Todd Underwood wrote: > What have you evaluated so far? Can you share your evaluation grid, how > you selected the candidates, how you are weighting criteria and specific > interesting findings so far? > > Thanks! > > t > > On Thu, Sep 5, 2019 at 4:37 AM Mehmet Akcin wrote: > >> Looking for IPAM recommendations, preferably open source, API is a plus >> (almost must, almost..). 40-50K IPs to be managed. >> >> thanks in advance. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 5 08:52:09 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 5 Sep 2019 17:52:09 +0900 Subject: IPAM recommendations In-Reply-To: <1579220644.4027.1567673463234.JavaMail.zimbra@hashpower.pt> References: <1579220644.4027.1567673463234.JavaMail.zimbra@hashpower.pt> Message-ID: I forgot to mention Netbox https://github.com/netbox-community/netbox integration (of some kind ) with LibreNMS is plus On Thu, Sep 5, 2019 at 5:51 PM Nuno Vieira wrote: > Check phpipam > > https://phpipam.net/ > > > > ------------------------------ > *From: *"Mehmet Akcin" > *To: *"North American Network Operators' Group" > *Sent: *Thursday, 5 September, 2019 09:35:19 > *Subject: *IPAM recommendations > > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. > thanks in advance. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddunder at gmail.com Thu Sep 5 09:56:04 2019 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 5 Sep 2019 05:56:04 -0400 Subject: IPAM recommendations In-Reply-To: References: Message-ID: i don't think that this is a reasonable use of nanog. if you have research to present and then a question to ask, that's totally great. this is especially true if you can add evaluative criteria and information before asking questions from people who have relevant experience. you read a single web page and are asking nanog to do your homework for you. that's unkind and is taking advantage of the attention and goodwill of the community here. this is becoming a pattern. please either do some research yourself and start a conversation substantively, or look to paid consultants to evaluate your software/hardware/datacenter space/networking gear etc. best, t On Thu, Sep 5, 2019 at 4:42 AM Mehmet Akcin wrote: > Not much beyond this, > https://appuals.com/the-5-best-ip-address-management-ipam-software/ > > On Thu, Sep 5, 2019 at 5:39 PM Todd Underwood wrote: > >> What have you evaluated so far? Can you share your evaluation grid, how >> you selected the candidates, how you are weighting criteria and specific >> interesting findings so far? >> >> Thanks! >> >> t >> >> On Thu, Sep 5, 2019 at 4:37 AM Mehmet Akcin wrote: >> >>> Looking for IPAM recommendations, preferably open source, API is a plus >>> (almost must, almost..). 40-50K IPs to be managed. >>> >>> thanks in advance. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Sep 5 12:16:48 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 5 Sep 2019 12:16:48 +0000 Subject: IPAM recommendations In-Reply-To: References: , Message-ID: Todd, I don’t think this is a reasonable understanding of Nanog. Nanog members ask each other for operational tool recommendations all the time, and since these products are right up the alley of Nanog’s mission — network operations — it’s a perfectly reasonable use of Nanog. But you read a single comment without researching any Nanog history, which would immediately show you how frequently Nanog serves in just this kind of valuable role, THAT’S unkind. -mel On Sep 5, 2019, at 2:56 AM, Todd Underwood > wrote: i don't think that this is a reasonable use of nanog. if you have research to present and then a question to ask, that's totally great. this is especially true if you can add evaluative criteria and information before asking questions from people who have relevant experience. you read a single web page and are asking nanog to do your homework for you. that's unkind and is taking advantage of the attention and goodwill of the community here. this is becoming a pattern. please either do some research yourself and start a conversation substantively, or look to paid consultants to evaluate your software/hardware/datacenter space/networking gear etc. best, t On Thu, Sep 5, 2019 at 4:42 AM Mehmet Akcin > wrote: Not much beyond this, https://appuals.com/the-5-best-ip-address-management-ipam-software/ On Thu, Sep 5, 2019 at 5:39 PM Todd Underwood > wrote: What have you evaluated so far? Can you share your evaluation grid, how you selected the candidates, how you are weighting criteria and specific interesting findings so far? Thanks! t On Thu, Sep 5, 2019 at 4:37 AM Mehmet Akcin > wrote: Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 5 12:20:19 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 5 Sep 2019 21:20:19 +0900 Subject: IPAM recommendations In-Reply-To: References: Message-ID: Lets focus on the technology. Netbox is solid. I am leaning towards this since its open source and there is some librenms integration. I was using another product till few days ago (i won’t mention name) i am not happy and decided to go with something open source On Thu, Sep 5, 2019 at 21:16 Mel Beckman wrote: > Todd, > > I don’t think this is a reasonable understanding of Nanog. Nanog members > ask each other for operational tool recommendations all the time, and since > these products are right up the alley of Nanog’s mission — network > operations — it’s a perfectly reasonable use of Nanog. > > But you read a single comment without researching any Nanog history, which > would immediately show you how frequently Nanog serves in just this kind of > valuable role, THAT’S unkind. > > > -mel > > On Sep 5, 2019, at 2:56 AM, Todd Underwood wrote: > > i don't think that this is a reasonable use of nanog. if you have > research to present and then a question to ask, that's totally great. this > is especially true if you can add evaluative criteria and information > before asking questions from people who have relevant experience. > > you read a single web page and are asking nanog to do your homework for > you. that's unkind and is taking advantage of the attention and goodwill > of the community here. this is becoming a pattern. please either do some > research yourself and start a conversation substantively, or look to paid > consultants to evaluate your software/hardware/datacenter space/networking > gear etc. > > best, > > t > > > > On Thu, Sep 5, 2019 at 4:42 AM Mehmet Akcin wrote: > >> Not much beyond this, >> https://appuals.com/the-5-best-ip-address-management-ipam-software/ >> >> On Thu, Sep 5, 2019 at 5:39 PM Todd Underwood >> wrote: >> >>> What have you evaluated so far? Can you share your evaluation grid, how >>> you selected the candidates, how you are weighting criteria and specific >>> interesting findings so far? >>> >>> Thanks! >>> >>> t >>> >>> On Thu, Sep 5, 2019 at 4:37 AM Mehmet Akcin wrote: >>> >>>> Looking for IPAM recommendations, preferably open source, API is a plus >>>> (almost must, almost..). 40-50K IPs to be managed. >>>> >>>> thanks in advance. >>>> >>> -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Thu Sep 5 12:52:36 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 5 Sep 2019 07:52:36 -0500 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <2EBBFB08-65F7-450B-A548-7C912F1735E7@dataix.net> phpIPAM -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Sep 5, 2019, at 03:36, Mehmet Akcin wrote: > >  > Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. > > thanks in advance. From niels=nanog at bakker.net Thu Sep 5 12:54:36 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Thu, 5 Sep 2019 14:54:36 +0200 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <20190905125436.GA30112@jima.tpb.net> * mel at beckman.org (Mel Beckman) [Thu 05 Sep 2019, 14:17 CEST]: >I don’t think this is a reasonable understanding of Nanog. Nanog >members ask each other for operational tool recommendations all the >time, and since these products are right up the alley of Nanog’s >mission — network operations — it’s a perfectly reasonable use of >Nanog. Did you read Todd's email at all? He asked the poster to do more homework before bothering the mailing list membership, an entirely reasonable request, especially given their recent posting history of similarly worded questions with lack of background supplied. >But you read a single comment without researching any Nanog history, This is laughably wrong. Todd is a long-time NANOG attendee and has even served on its Program Committee. (Pot, kettle, black.) -- Niels. From hank at efes.iucc.ac.il Thu Sep 5 13:08:46 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 5 Sep 2019 16:08:46 +0300 Subject: Art and Tech is madness In-Reply-To: References: Message-ID: On 05/09/2019 08:09, Kasper Adel wrote: No.  This is art & tech from 12 years ago: https://www.youtube.com/watch?v=_y36fG2Oba0 -Hank > In SPRING a time when segment and routing had no mismatch, a time when > isis and ospf ate a forbidden encap, all they had to do was forward > bgp like its hot, but crazy flapping doesnt leave any real LDP without > some real FSM check, My dynamic unnumbered neighbor. > > > Suddenly, Out of order, an AS is overridden, we see frames dropping, > we sniff a bit and it turns out, sfps are burning, we are in a place > right now where ping and pong are jittery, their latency is tested, > they cant strengthen their icmp bond with a warm bfd message, how can > they keep everyone in ACK, safe from teardown and dampening, with this > kind of ixp relationship??! but oh admin, we know forwarding works in > its own mysterious ways. We are left with two non rfc compliant > scavengers, bastard 802.1ah fools in a leaky yet shaped, buffer > display of some runts and nimbles, and a giant too. > > They start their life of a packet, leaving one interface to a > neighbor, from an adjacency to a peer, an endless loop, its a prefix > hijack, but as they move from one stack to another, finding their way > through a tunnel of memory failures and RMAs, one hell of an LSP ride, > through firewall horrors and MTU mismatches, leaving behind, a sea of > syslog messages and snmp alarms. Anyway, Their ttl expired and one > funny access list abruptly denies them life, sending them to Null0, > where they can be peacefully discarded. > > > Thats what tech does to yeh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Thu Sep 5 13:13:33 2019 From: cb.list6 at gmail.com (Ca By) Date: Thu, 5 Sep 2019 06:13:33 -0700 Subject: IPAM recommendations In-Reply-To: References: Message-ID: On Thu, Sep 5, 2019 at 2:58 AM Todd Underwood wrote: > > that's unkind and is taking advantage of the attention and goodwill of > the community here. this is becoming a pattern. > +1 on this noisy pattern. Hire an consultant to google these things for you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Thu Sep 5 13:14:57 2019 From: cb.list6 at gmail.com (Ca By) Date: Thu, 5 Sep 2019 06:14:57 -0700 Subject: Art and Tech is madness In-Reply-To: References: Message-ID: See below for high value of the list, both items are very pleasing On Thu, Sep 5, 2019 at 6:10 AM Hank Nussbacher wrote: > On 05/09/2019 08:09, Kasper Adel wrote: > > No. This is art & tech from 12 years ago: > https://www.youtube.com/watch?v=_y36fG2Oba0 > > -Hank > > In SPRING a time when segment and routing had no mismatch, a time when > isis and ospf ate a forbidden encap, all they had to do was forward bgp > like its hot, but crazy flapping doesnt leave any real LDP without some > real FSM check, My dynamic unnumbered neighbor. > > > Suddenly, Out of order, an AS is overridden, we see frames dropping, we > sniff a bit and it turns out, sfps are burning, we are in a place right now > where ping and pong are jittery, their latency is tested, they cant > strengthen their icmp bond with a warm bfd message, how can they keep > everyone in ACK, safe from teardown and dampening, with this kind of ixp > relationship??! but oh admin, we know forwarding works in its own > mysterious ways. We are left with two non rfc compliant scavengers, bastard > 802.1ah fools in a leaky yet shaped, buffer display of some runts and > nimbles, and a giant too. > > They start their life of a packet, leaving one interface to a neighbor, > from an adjacency to a peer, an endless loop, its a prefix hijack, but as > they move from one stack to another, finding their way through a tunnel of > memory failures and RMAs, one hell of an LSP ride, through firewall horrors > and MTU mismatches, leaving behind, a sea of syslog messages and snmp > alarms. Anyway, Their ttl expired and one funny access list abruptly denies > them life, sending them to Null0, where they can be peacefully discarded. > > > Thats what tech does to yeh > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lathama at gmail.com Thu Sep 5 13:19:35 2019 From: lathama at gmail.com (Andrew Latham) Date: Thu, 5 Sep 2019 08:19:35 -0500 Subject: IPAM recommendations In-Reply-To: References: Message-ID: Please check the mailing list archives as a resource. I made a short list last time https://lathama.net/DCIM which looks to be June 20th 2018 On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin wrote: > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. > > thanks in advance. > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipc at phmgmt.com Thu Sep 5 13:48:18 2019 From: phillipc at phmgmt.com (Phillip Carroll) Date: Thu, 5 Sep 2019 13:48:18 +0000 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> https://github.com/netbox-community/netbox From: NANOG On Behalf Of Andrew Latham Sent: Thursday, September 5, 2019 8:20 AM Cc: nanog Subject: Re: IPAM recommendations [EXTERNAL EMAIL] Please check the mailing list archives as a resource. I made a short list last time https://lathama.net/DCIM which looks to be June 20th 2018 On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin > wrote: Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu Sep 5 14:24:43 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 05 Sep 2019 10:24:43 -0400 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <722443.1567693483@turing-police> On Thu, 05 Sep 2019 21:20:19 +0900, Mehmet Akcin said: > I was using another product till few days ago (i won’t mention name) i am > not happy and decided to go with something open source Can you mention why you're unhappy with the product? Price, a critical feature that was lacking, something else? Software in a segment never improves unless the vendors/developers know that doing XYZ well/poorly is a market differentiator.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mel at beckman.org Thu Sep 5 14:46:36 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 5 Sep 2019 14:46:36 +0000 Subject: IPAM recommendations In-Reply-To: <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> References: , <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> Message-ID: <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> I agree with Phil, Netbox is a great opens source IPAM project. We currently use ManageEngine, but I plan to switch to Netbox when our current license is up for renewal. NetBox. The project is supported by Digital Ocean, which is the kind of corporate sponsorship that keeps open source project from dying out. It’s one of the few IPAM products that recognizes that IP addresses can be assigned to interfaces on a device, not necessarily the device itself. It also supports interfaces having multiple IP addresses. Netbox uses Postgres under the covers, which has IP addresses as a native data type. That means you can also build your own SQL queries to interface with other systems. The tool is not frilly, but has all the features an IPAM should have for accurate and timely resource management. Plus the code looks clean. -mel On Sep 5, 2019, at 6:48 AM, Phillip Carroll > wrote: https://github.com/netbox-community/netbox From: NANOG > On Behalf Of Andrew Latham Sent: Thursday, September 5, 2019 8:20 AM Cc: nanog > Subject: Re: IPAM recommendations [EXTERNAL EMAIL] Please check the mailing list archives as a resource. I made a short list last time https://lathama.net/DCIM which looks to be June 20th 2018 On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin > wrote: Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 5 14:52:16 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 5 Sep 2019 23:52:16 +0900 Subject: IPAM recommendations In-Reply-To: <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> References: <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> Message-ID: Thanks for confirming. This is exactly what I think. On Thu, Sep 5, 2019 at 23:47 Mel Beckman wrote: > I agree with Phil, Netbox is a great opens source IPAM project. We > currently use ManageEngine, but I plan to switch to Netbox when our current > license is up for renewal. NetBox. The project is supported by Digital > Ocean, which is the kind of corporate sponsorship that keeps open source > project from dying out. > > It’s one of the few IPAM products that recognizes that IP addresses can be > assigned to interfaces on a device, not necessarily the device itself. It > also supports interfaces having multiple IP addresses. Netbox uses Postgres > under the covers, which has IP addresses as a native data type. That means > you can also build your own SQL queries to interface with other systems. > > The tool is not frilly, but has all the features an IPAM should have for > accurate and timely resource management. Plus the code looks clean. > > > -mel > > On Sep 5, 2019, at 6:48 AM, Phillip Carroll wrote: > > > > https://github.com/netbox-community/netbox > > > > > > *From:* NANOG *On Behalf Of > *Andrew Latham > *Sent:* Thursday, September 5, 2019 8:20 AM > *Cc:* nanog > *Subject:* Re: IPAM recommendations > > > > [EXTERNAL EMAIL] > > > > Please check the mailing list archives as a resource. I made a short list > last time https://lathama.net/DCIM which looks to be June 20th 2018 > > > > On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin wrote: > > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. > > > > thanks in advance. > > > > > -- > > - Andrew "lathama" Latham - > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuno at hashpower.pt Thu Sep 5 08:51:03 2019 From: nuno at hashpower.pt (Nuno Vieira) Date: Thu, 5 Sep 2019 09:51:03 +0100 (WEST) Subject: IPAM recommendations In-Reply-To: References: Message-ID: <1579220644.4027.1567673463234.JavaMail.zimbra@hashpower.pt> Check phpipam [ https://phpipam.net/ | https://phpipam.net/ ] From: "Mehmet Akcin" To: "North American Network Operators' Group" Sent: Thursday, 5 September, 2019 09:35:19 Subject: IPAM recommendations Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.grimes at msstate.edu Thu Sep 5 09:28:52 2019 From: greg.grimes at msstate.edu (Grimes, Greg) Date: Thu, 5 Sep 2019 09:28:52 +0000 Subject: IPAM recommendations In-Reply-To: References: <1579220644.4027.1567673463234.JavaMail.zimbra@hashpower.pt>, Message-ID: I highly recommend Netbox. We use it for our Source of Truth. ________________________________ From: NANOG on behalf of Mehmet Akcin Sent: Thursday, September 5, 2019 3:52:09 AM To: Nuno Vieira Cc: North American Network Operators' Group Subject: Re: IPAM recommendations I forgot to mention Netbox https://github.com/netbox-community/netbox integration (of some kind ) with LibreNMS is plus On Thu, Sep 5, 2019 at 5:51 PM Nuno Vieira > wrote: Check phpipam https://phpipam.net/ ________________________________ From: "Mehmet Akcin" > To: "North American Network Operators' Group" > Sent: Thursday, 5 September, 2019 09:35:19 Subject: IPAM recommendations Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Thu Sep 5 15:06:46 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 5 Sep 2019 15:06:46 +0000 Subject: IPAM recommendations In-Reply-To: <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> References: <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> Message-ID: I wish Digital Ocean would put as much effort into policing their network; at least two thirds of the malicious traffic hitting our customers comes from an even split between them and OVH. From: NANOG on behalf of Mel Beckman Date: Thursday, September 5, 2019 at 10:48 AM To: Phillip Carroll Cc: nanog Subject: Re: IPAM recommendations I agree with Phil, Netbox is a great opens source IPAM project. We currently use ManageEngine, but I plan to switch to Netbox when our current license is up for renewal. NetBox. The project is supported by Digital Ocean, which is the kind of corporate sponsorship that keeps open source project from dying out. It’s one of the few IPAM products that recognizes that IP addresses can be assigned to interfaces on a device, not necessarily the device itself. It also supports interfaces having multiple IP addresses. Netbox uses Postgres under the covers, which has IP addresses as a native data type. That means you can also build your own SQL queries to interface with other systems. The tool is not frilly, but has all the features an IPAM should have for accurate and timely resource management. Plus the code looks clean. -mel On Sep 5, 2019, at 6:48 AM, Phillip Carroll > wrote: https://github.com/netbox-community/netbox From: NANOG > On Behalf Of Andrew Latham Sent: Thursday, September 5, 2019 8:20 AM Cc: nanog > Subject: Re: IPAM recommendations [EXTERNAL EMAIL] Please check the mailing list archives as a resource. I made a short list last time https://lathama.net/DCIM which looks to be June 20th 2018 On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin > wrote: Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. thanks in advance. -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Thu Sep 5 16:25:26 2019 From: ben at 6by7.net (Ben Cannon) Date: Thu, 5 Sep 2019 09:25:26 -0700 Subject: IPAM recommendations In-Reply-To: References: <3dc60ec15af94d98b1711c1216ef7ea5@phmgmt.com> <2070AE3D-DEC7-4DDB-A3F9-D57F1199F5B1@beckman.org> Message-ID: <5AD128DB-B257-463D-8268-BC73E2180F60@6by7.net> I’ve both been exposed to newer and better tools - and been annoyed at the noise - in NANOG for almost 2 decades now. So far phpipam has suited our needs. However it takes quite a few clicks to get things done, and anytime you can remove friction you have an opportunity for a better product. -Ben > On Sep 5, 2019, at 8:06 AM, David Hubbard wrote: > > I wish Digital Ocean would put as much effort into policing their network; at least two thirds of the malicious traffic hitting our customers comes from an even split between them and OVH. > > From: NANOG on behalf of Mel Beckman > Date: Thursday, September 5, 2019 at 10:48 AM > To: Phillip Carroll > Cc: nanog > Subject: Re: IPAM recommendations > > I agree with Phil, Netbox is a great opens source IPAM project. We currently use ManageEngine, but I plan to switch to Netbox when our current license is up for renewal. NetBox. The project is supported by Digital Ocean, which is the kind of corporate sponsorship that keeps open source project from dying out. > > It’s one of the few IPAM products that recognizes that IP addresses can be assigned to interfaces on a device, not necessarily the device itself. It also supports interfaces having multiple IP addresses. Netbox uses Postgres under the covers, which has IP addresses as a native data type. That means you can also build your own SQL queries to interface with other systems. > > The tool is not frilly, but has all the features an IPAM should have for accurate and timely resource management. Plus the code looks clean. > > -mel > > On Sep 5, 2019, at 6:48 AM, Phillip Carroll wrote: > > > https://github.com/netbox-community/netbox > > > > From: NANOG On Behalf Of Andrew Latham > Sent: Thursday, September 5, 2019 8:20 AM > Cc: nanog > Subject: Re: IPAM recommendations > > [EXTERNAL EMAIL] > > Please check the mailing list archives as a resource. I made a short list last time https://lathama.net/DCIM which looks to be June 20th 2018 > > On Thu, Sep 5, 2019 at 3:37 AM Mehmet Akcin wrote: > Looking for IPAM recommendations, preferably open source, API is a plus (almost must, almost..). 40-50K IPs to be managed. > > thanks in advance. > > > -- > - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Thu Sep 5 18:05:36 2019 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 5 Sep 2019 14:05:36 -0400 (EDT) Subject: rr.level3.net on autopilot? Message-ID: I was doing some IRR clean-up and after a few successful updates, I'm no longer able to alter or delete our objects in rr.level3.com. Emails to rpsl at level3.com result in no action and no response. I've tried reaching out to the Level3 (Centurylink) NOC via email and phone, and can't seem to find anyone who knows what rr.level3.com is, much less knows who to talk to about troubleshooting. Anyone know who (if anyone) keeps the wheels spinning on the Level3 IRR? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From eric.kuhnke at gmail.com Thu Sep 5 19:00:04 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 5 Sep 2019 12:00:04 -0700 Subject: IPAM recommendations In-Reply-To: References: Message-ID: Many others have already recommended these, but I suggest installing test VMs of both phpipam and nipap and seeing which works best for your use case. NIPAP has fairly extensive tools supporting automation for provisioning. phpipam has a few additional functions on top of only ip address management, it also appears to have been designed for a use case where people are running geographically spread out layer 2 services and keeping track of which vlan belongs to which customer. On Thu, Sep 5, 2019 at 1:36 AM Mehmet Akcin wrote: > Looking for IPAM recommendations, preferably open source, API is a plus > (almost must, almost..). 40-50K IPs to be managed. > > thanks in advance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Thu Sep 5 21:54:58 2019 From: jbothe at me.com (JASON BOTHE) Date: Thu, 5 Sep 2019 16:54:58 -0500 Subject: Spam due to new ARIN allocation In-Reply-To: References: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> Message-ID: <1C4FF5E2-1DCD-40AE-BB34-46410596094B@me.com> Oddly enough, I created a Z Org for legacy resources and got hit up on linked-in by IPv4 brokers as well as some spam from Cogent. Annoying. > On Aug 4, 2019, at 09:29, Tim Burke wrote: > > Done, Sir. Thanks. > > Tim Burke > tim at burke.us > >> On Sat, Aug 3, 2019, at 10:42 PM, John Curran wrote: >> Tim - >> >> When you have moment, could you forward both of those Whois spam messages to compliance at arin.net ? >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers] >> >> >>> On 2 Aug 2019, at 7:32 PM, Tim Burke wrote: >>> >>> We recently received a new ASN from ARIN - you know what that means... the sales vultures come out to play! >>> >>> So far, it has resulted in spam from Cogent (which is, of course, to be expected), and now another company called "CapCon Networks" - http://www.capconnetworks.com. As far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, complete with these jokers, and other vultures that engage in similar tactics? >>> >>> Regards, >>> Tim Burke >>> tim at burke.us > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Thu Sep 5 23:45:04 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 5 Sep 2019 19:45:04 -0400 Subject: rr.level3.net on autopilot? In-Reply-To: References: Message-ID: On 9/5/19 2:05 PM, Jon Lewis wrote: > I was doing some IRR clean-up and after a few successful updates, I'm no > longer able to alter or delete our objects in rr.level3.com. > > Emails to rpsl at level3.com result in no action and no response. I've tried > reaching out to the Level3 (Centurylink) NOC via email and phone, and > can't seem to find anyone who knows what rr.level3.com is, much less knows > who to talk to about troubleshooting. Anyone know who (if anyone) keeps > the wheels spinning on the Level3 IRR? The other day I tried to clean up some old entries from the 2000's and Genuity entries that became part of it. This was a failure, the NOC knew nothing about it, and worse didn't get my black rocket jokes. No one working there knew what Genuity was. I gave up. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From Anthony.DeLaCruz at CenturyLink.com Fri Sep 6 03:23:06 2019 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Fri, 6 Sep 2019 03:23:06 +0000 Subject: rr.level3.net on autopilot? In-Reply-To: References: Message-ID: <398B250423578A4E97AFE1B8B67C686C653598C5@PDDCWMBXEX503.ctl.intranet> Shoot an email to ipadmin at centurylink.com and we'll give you a hand. If you are an active customer with valid circuit ID getting help from the NOC on this should be a solution they know how to provide, if you have reached the correct center. Folks that are not or have left behind old entries needing removed without a current relationship reach out to the ipadmin team for help. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Lewis Sent: Thursday, September 05, 2019 1:06 PM To: nanog at nanog.org Subject: rr.level3.net on autopilot? I was doing some IRR clean-up and after a few successful updates, I'm no longer able to alter or delete our objects in rr.level3.com. Emails to rpsl at level3.com result in no action and no response. I've tried reaching out to the Level3 (Centurylink) NOC via email and phone, and can't seem to find anyone who knows what rr.level3.com is, much less knows who to talk to about troubleshooting. Anyone know who (if anyone) keeps the wheels spinning on the Level3 IRR? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From cboyd at gizmopartners.com Fri Sep 6 04:04:30 2019 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 5 Sep 2019 23:04:30 -0500 Subject: Art and Tech is madness In-Reply-To: References: Message-ID: <10D1B50B-9C30-4171-ADEB-85AD1F1B4C3E@gizmopartners.com> There’s also this gem from 2005 or 2007 days. I’ve heard Cisco staff was involved in its creation. http://www.mattzrelak.com/mp3/t1down.htm —Chris > On Sep 5, 2019, at 8:14 AM, Ca By wrote: > > See below for high value of the list, both items are very pleasing > > On Thu, Sep 5, 2019 at 6:10 AM Hank Nussbacher wrote: > On 05/09/2019 08:09, Kasper Adel wrote: > > No. This is art & tech from 12 years ago: > https://www.youtube.com/watch?v=_y36fG2Oba0 > > -Hank > >> In SPRING a time when segment and routing had no mismatch, a time when isis and ospf ate a forbidden encap, all they had to do was forward bgp like its hot, but crazy flapping doesnt leave any real LDP without some real FSM check, My dynamic unnumbered neighbor. >> >> >> >> Suddenly, Out of order, an AS is overridden, we see frames dropping, we sniff a bit and it turns out, sfps are burning, we are in a place right now where ping and pong are jittery, their latency is tested, they cant strengthen their icmp bond with a warm bfd message, how can they keep everyone in ACK, safe from teardown and dampening, with this kind of ixp relationship??! but oh admin, we know forwarding works in its own mysterious ways. We are left with two non rfc compliant scavengers, bastard 802.1ah fools in a leaky yet shaped, buffer display of some runts and nimbles, and a giant too. >> >> They start their life of a packet, leaving one interface to a neighbor, from an adjacency to a peer, an endless loop, its a prefix hijack, but as they move from one stack to another, finding their way through a tunnel of memory failures and RMAs, one hell of an LSP ride, through firewall horrors and MTU mismatches, leaving behind, a sea of syslog messages and snmp alarms. Anyway, Their ttl expired and one funny access list abruptly denies them life, sending them to Null0, where they can be peacefully discarded. >> >> >> >> Thats what tech does to yeh > > > > > From eyeronic.design at gmail.com Fri Sep 6 06:42:35 2019 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 5 Sep 2019 23:42:35 -0700 Subject: Cat 5 hurricane -- How are the Bahamas doing? In-Reply-To: References: Message-ID: Any further details? On Wed, Sep 4, 2019 at 4:10 PM J. Hellenthal via NANOG wrote: > > Bahamas are essentially flattened as per recent reports. Or in other words .... BAAAAAAD > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > > > On Sep 4, 2019, at 14:26, Sean Donelan wrote: > > > > On Mon, 2 Sep 2019, Sean Donelan wrote: > >> It is too early for damage assessments. BTC, local Bahama telecommunications company, is reporting widespread power outages, and intermittent mobile and wireline telephone service. The Abaco Islands in northern Bahamas seem to be taking the worst of it. > > > > Folks asking for updates on Bahamas. The simple answer is I'm not hearing any information out of the Bahamas, which is concerning in itself. > > > > > > My big secret how I do network outage reports is people send me the information. Usually, I get lots of random emails from network people about problems all over the U.S. and other places in the world. But Bahamas has gone very quiet. > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From rfg at tristatelogic.com Fri Sep 6 08:30:00 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 06 Sep 2019 01:30:00 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? Message-ID: <20553.1567758600@segfault.tristatelogic.com> Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg From bryan at shout.net Fri Sep 6 08:38:21 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 6 Sep 2019 10:38:21 +0200 Subject: rr.level3.net on autopilot? In-Reply-To: References: Message-ID: <0bda15f7-be80-a7df-83c7-9b6ceccf4090@shout.net> AS1, baby!! On 9/6/19 1:45 AM, Bryan Fields wrote: > On 9/5/19 2:05 PM, Jon Lewis wrote: >> I was doing some IRR clean-up and after a few successful updates, I'm no >> longer able to alter or delete our objects in rr.level3.com. >> >> Emails to rpsl at level3.com result in no action and no response. I've tried >> reaching out to the Level3 (Centurylink) NOC via email and phone, and >> can't seem to find anyone who knows what rr.level3.com is, much less knows >> who to talk to about troubleshooting. Anyone know who (if anyone) keeps >> the wheels spinning on the Level3 IRR? > > The other day I tried to clean up some old entries from the 2000's and Genuity > entries that became part of it. This was a failure, the NOC knew nothing > about it, and worse didn't get my black rocket jokes. No one working there > knew what Genuity was. > > I gave up. > From adamv0025 at netconsultings.com Fri Sep 6 09:05:42 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 6 Sep 2019 10:05:42 +0100 Subject: IPAM recommendations In-Reply-To: References: Message-ID: <016201d56492$430f80f0$c92e82d0$@netconsultings.com> I tried all 3 netbox, nipap and phpipam as a gui user and I like the phpipam the best as it has most knobs and features and is very intuitive, (can't comment on the api richness, yet) But what is strange is that none of these tools provides RT (or extended/standard communities or even vlan for that matter) management the way they provide IP management, that is allow one to create custom pools and then have the next free resource allocated from a pool if needed. adam From reichert at numachi.com Fri Sep 6 11:56:29 2019 From: reichert at numachi.com (Brian Reichert) Date: Fri, 6 Sep 2019 07:56:29 -0400 Subject: Art and Tech is madness In-Reply-To: <10D1B50B-9C30-4171-ADEB-85AD1F1B4C3E@gizmopartners.com> References: <10D1B50B-9C30-4171-ADEB-85AD1F1B4C3E@gizmopartners.com> Message-ID: <20190906115629.GM64917@numachi.com> On Thu, Sep 05, 2019 at 11:04:30PM -0500, Chris Boyd wrote: > There???s also this gem from 2005 or 2007 days. I???ve heard Cisco staff was involved in its creation. > > http://www.mattzrelak.com/mp3/t1down.htm If this is keeping on topic: https://www.youtube.com/watch?v=CyvQ5Pu_k1o > > ???Chris -- Brian Reichert BSD admin/developer at large From randy at psg.com Fri Sep 6 12:55:48 2019 From: randy at psg.com (Randy Bush) Date: Fri, 06 Sep 2019 05:55:48 -0700 Subject: gtt bgp fu? Message-ID: hi. i would love to chat (email) with someone in gtt (AS3257) who has bgp fu. doing some bgp measurements, we see something we do not understand and would love a clue. thanks. randy From mel at beckman.org Fri Sep 6 13:23:20 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 6 Sep 2019 13:23:20 +0000 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <20553.1567758600@segfault.tristatelogic.com> References: <20553.1567758600@segfault.tristatelogic.com> Message-ID: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> A quick check of one of your facts produces unexpected results, so you might want to perform more research. According the APNIC, 139.44.0.0/16 does not “belong unambiguously to the Port Authority of Melbourne”. It belongs to an individual, with an office address at a building called “Port Authority of Melbourne”: person: Rob Shute address: Port of Melbourne Authority Level 47 South 525 Collins St country: AU phone: +61 3 9628 7613 e-mail: djk at pma.vic.gov.au nic-hdl: RS54-AP remarks: ---------- remarks: imported from ARIN object: remarks: remarks: poc-handle: RS546-ARIN remarks: is-role: N remarks: last-name: Shute remarks: first-name: Rob remarks: street: Port of Melbourne Authority Level 47 South 525 Collins St remarks: country: AU remarks: mailbox: djk at pma.vic.gov.au remarks: bus-phone: +61 3 9628 7613 remarks: reg-date: 1970-01-01 remarks: changed: hostmaster at arin.poc 20001127 remarks: source: ARIN remarks: remarks: ---------- notify: djk at pma.vic.gov.au mnt-by: MNT-ERX-PRTMELAUTH-NON-AU last-modified: 2008-09-04T07:31:33Z source: APNIC The building called the Port Authority of Melbourne is not, by all accounts, a government agency. It’s just the name of a 54-story office building, like the World Trade Center in NYC. In fact, World Trade Centre (Melbourne) is another name for the building, and although it houses the Port of Melbourne Authority agency (on Level 4, not Level 47), it appears to be largely just a toney address for business offices. Some, perhaps, not unlike American “Mail Boxes Etc” (although I haven’t confirmed this). But the following Wikipedia excerpt says this unambiguously: The building currently houses some offices of the headquarters of Victoria Police, and the Victoria Police Museum , a collection of exhibits and memorabilia from over 150 years of policing in Victoria.[3] It also houses offices for companies, including Thales Australia. https://en.m.wikipedia.org/wiki/Port_of_Melbourne_Authority Now, I’m not an Ossie, and in fact have never been down under, but it seems likely that the address in the registration is akin to a US business having a World Trade Center address in NYC. It means nothing as far as APNIC asset ownership is concerned. It’s just an address. I could be wrong. However, it seems a simple fact to verify by calling management at that building. I tried sending email to the registered “.gov.au” address: djk at pma.vic.gov.au But the domain does not exist. -mel beckman On Sep 6, 2019, at 1:30 AM, Ronald F. Guilmette > wrote: Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Fri Sep 6 13:57:23 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 6 Sep 2019 14:57:23 +0100 (WEST) Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> References: <20553.1567758600@segfault.tristatelogic.com> <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> Message-ID: Hi, (Also never been in Australia, unfortunately...) Netname is "PMANET": ...isn't it OK to assume it could stand for "Port of Melbourne Authority Network"? * pma.vic.gov.au is not operational (i wonder what can be found with passive dns) * vic.gov.au is still operational. Quick googling also allowed me to find this: https://www.portofmelbourne.com/about-us/port-history/timeline/ "1996 Melbourne Port Corporation established as successor to Port of Melbourne Authority." Regards, Carlos On Fri, 6 Sep 2019, Mel Beckman wrote: > A quick check of one of your facts produces unexpected results, so you might want to perform more research. According the APNIC, > 139.44.0.0/16  does not ?belong unambiguously to the Port Authority of Melbourne?. It belongs to an individual, with an office address > at a building called ?Port Authority of Melbourne?: > person: > Rob Shute > > address: > Port of Melbourne Authority > Level 47 South > 525 Collins St > > country: > AU > phone: > +61 3 9628 7613 > e-mail: > djk at pma.vic.gov.au > nic-hdl: > RS54-AP > remarks: > ---------- > remarks: > imported from ARIN object: > remarks: > remarks: > poc-handle: RS546-ARIN > remarks: > is-role: N > remarks: > last-name: Shute > remarks: > first-name: Rob > remarks: > street: Port of Melbourne Authority > Level 47 South > 525 Collins St > remarks: > country: AU > remarks: > mailbox: djk at pma.vic.gov.au > remarks: > bus-phone: +61 3 9628 7613 > remarks: > reg-date: 1970-01-01 > remarks: > changed: hostmaster at arin.poc 20001127 > remarks: > source: ARIN > remarks: > remarks: > ---------- > notify: > djk at pma.vic.gov.au > mnt-by: > MNT-ERX-PRTMELAUTH-NON-AU > last-modified: > 2008-09-04T07:31:33Z > source: > APNIC > The building called the Port Authority of Melbourne is not, by all accounts, a government agency. It?s just the name of a 54-story > office building, like the World Trade Center in NYC. In fact, World Trade Centre (Melbourne) is another name for the building, and > although it houses the Port of Melbourne Authority agency (on Level 4, not Level 47), it appears to be largely just a toney address > for business offices. Some, perhaps, not unlike American ?Mail Boxes Etc? (although I haven?t confirmed this). But the following Wikipedia > excerpt says this unambiguously: > > The building currently houses some offices of the headquarters of Victoria Police, and the Victoria Police Museum , a collection of > exhibits and memorabilia from over 150 years of policing in Victoria.[3] It also houses offices for companies, including Thales > Australia. > > https://en.m.wikipedia.org/wiki/Port_of_Melbourne_Authority > > Now, I?m not an Ossie, and in fact have never been down under, but it seems likely that the address in the registration is akin to a > US business having a World Trade Center address in NYC. It means nothing as far as APNIC asset ownership is concerned. It?s just an > address. > > I could be wrong. However, it seems a simple fact to verify by calling management at that building. I tried sending email to the > registered ?.gov.au? address: > > djk at pma.vic.gov.au > > But the domain does not exist.  > >  -mel beckman > > On Sep 6, 2019, at 1:30 AM, Ronald F. Guilmette wrote: > > Few of you here probably know about this, but nearly a week ago now > an article appeared in South Africa's largest and most popular online > tech publication, MyBroadband.co.za.  It detailed many, but certainly not > all of the results of my multi-month investigation of a massive and > ongoing fraud involving the theft of large numbers of large (generally > /16 or larger) abandoned legacy blocks, taken from the AFRINIC region > and beyond: > > https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html > > > For various editorial reasons, the article that was published actually > downplayed the magnitude of the of the thefts quite dramatically.  The > totality of the IPv4 space that has been stolen or squatted, primarily > but not exclusively, from South African companies and South African national > goverment agencies and departments is actually at least 5x bigger than what > was reported in the MyBroadband.co.za article. > > The overwhelming majority of this stolen and squatted IPv4 space has > been helpfully routed by Cogent (AS174), to their customer, FDCServers > of Chicago, and then on to the prefered destinations of a certain Mr. > Elad Cohen of Israel, and his company Netstyle Atarim, Ltd.  (I have > saved traceroutes up the wazoo that prove the involvement of FDCServers, > in particular, in all of this.) > > Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting > activities, basically grabbing everything that wasn't nailed down, both > within the AFRINIC region and also within the APNIC region. > > In order to try to legitimize all of these thefts and squats, Mr. Cohen > created quite a sizable number of fradulent route: objects within the > Merit/RADB data base which, as most here should already know, has > essentially zero authentication of any kind before it allows J. Random > Luser to add pretty much any any route: object he wants to the RADB. > > Here's a full listing of all of Mr. Cohen's RADB route: objects as they > existed as recently as August 17th: > >    https://pastebin.com/raw/ZNgNuvtt > > And here is the short summary version showing just all of the prefixes/CIDRs > that Mr. Cohen was effectively claiming rights and/or title to as of that > same date: > >    https://pastebin.com/raw/4LTaCg5R > > Plese do note the numerous blocks of size /16 or greater. > > The bottom line is that this one tiny little Israeli company was effectively > claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of > August 17th, 2019.  (Not too shabby for one lone guy who teaches programming > classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, > and generally consists of blocks having sizes of /16 or larger. > > Some of Mr. Cohen claims in his RADB entries are as humorous as they > are pathetically fradulent.  For example, Mr. Cohen has effectively > claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port > Authority of the City of Melbourne, Australia.  But hell!  That's merely > city property!  Mr. Cohen's limitless appetite for other people's IPv4 > space is more vividly on display in his claims to ownerhip over the > 168.198.0.0/16 block, which actually belongs to the Department of Finance > of the Australian national government.  And I haven't even mentioned yet > another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, > which he did not see fit to create an RADB entry for, but which he's > been squatting on for for quite some time now, quite clearly with the > aid and assistance of both Cogent and FDCServers.  That one belongs to > th City of Cape Town, South Africa.  That city's engineers have been > struggling to regain control of their block back from Cogent, from > FDCServers, and from Mr. Cohen for some time now.   I know because I've > personally spoken to them about it.  Cogent, in its infinite wisdom, is > continuing to fight the city for control over property that clearly and > righfully belongs to the City of Cape Town, even as we speak: > >    https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view > > When asked for LOAs attesting to his legitimate authority to route at > least a few of these blocks, Mr. Cohen has produced blatantly forged > documents, many of which appeared in the MyBroadband.co.za story.  And > when I say "blatant" that's a gross understatement.  Any half-way decent > forger would consider these documents an embarrasment.  The documents all > bear identical signatures, and identical and vaguely official looking > stamps, and purport to actually be sales reciepts attesting to the > alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell > company, Afri Holdings, Ltd., of various /16 blocks from a mysterious > company called Afrivestment, Ltd., which may actually exist in some > faraway galaxy, or in Mr. Cohen's active imagination, but which both > Google and OpenCorporates.com seem to agree exists exactly noplace on > this planet.  Here are the manufactured LOAs supplied by Mr. Cohen: > >    https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view >    https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view >    https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view > > Recently, Cohen started to move some, but not all, of his stolen and squatted > IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof > hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or > to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, > coincidently, just happen to be owned by the exact same pair of Dutch > gentlemen who previously owned the notorious Ecatel, follwed by the notorious > Quasi Networks.  (IP Volume, Inc. appears to have intherited all or nearly > all of its legitimately assigned IP space from its predecessor entities, > Ecatel and Quasi Networks.) > > Despite these relocations, many of Mr. Cohen's stolen and squatted blocks > are still helpfully being routed to Mr. Cohen's preferred desitnations by > his good friends at Cogent and FDCServers, even as we speak.  The current > set of such routes that Cogent is maintaining, at the moment, apparently on > behalf of their customer, Mr. Cohen, consists of the prefixes listed here: > >    https://pastebin.com/raw/EA3xJVLF > > When I noticed two days ago that all of these routes were still up I was > deeply confused.  Did both Cogent and FDCServrs not get the memo??  Do > they not know yet that Cohen is stealing stuff, left, right, and sideways? > Did nobody even tell them about the MyBroadband.co.za article which was > published this past Sunday?  I decided that it was incumbant upon me to > find out. > > Thus, more that 48 hours ago now I sent the following polite but firm > inquiry to Cogent, and a separate nearly identical one directly to the > CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). > >    https://pastebin.com/raw/ztipqE96 > > A full forty eight hours later, I have received no reply whatsoever from > either Cogent or FDCServers, not even a "Go pound sand" type of response. > > More importantly, most of the stolen IPv4 space that I called out, very > specifically, to both Cogent and FDCservers two+ days ago now is still > being routed by Cogent/FDCservers to their fun-loving and, I'm sure, > promptly paying customer, Mr. Cohen.  If neither Cogent nor FDCServers > still do not know now that Mr. Cohen is a crook, and that he has glommed > onto quite a lot of stolen and squatted IPv4 space... which they have > been helpfully routing for him, no doubt in exchange for some handsome > payments... then I am foreced to say that it appears to be a reasonable > conclusion that it must be because neither Cogent nor FDCServers really > wants to know what sort of a character Cohen is, or what he has been up > to, specifically with their ongoing and material assistance. > > But you all be the judges.  What does it look like to you? > > > Regards, > rfg > > > From ben at 6by7.net Fri Sep 6 14:02:42 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 6 Sep 2019 07:02:42 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: References: <20553.1567758600@segfault.tristatelogic.com> <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> Message-ID: Important realization: Things don’t always work there like they work here (wherever “here” is for you). -Ben > On Sep 6, 2019, at 6:57 AM, Carlos Friaças via NANOG wrote: > > > Hi, > > (Also never been in Australia, unfortunately...) > > Netname is "PMANET": > ...isn't it OK to assume it could stand for "Port of Melbourne Authority Network"? > > * pma.vic.gov.au is not operational > (i wonder what can be found with passive dns) > > * vic.gov.au is still operational. > > > Quick googling also allowed me to find this: > > https://www.portofmelbourne.com/about-us/port-history/timeline/ > > "1996 Melbourne Port Corporation established as successor to Port of > Melbourne Authority." > > > Regards, > Carlos > > > >> On Fri, 6 Sep 2019, Mel Beckman wrote: >> >> A quick check of one of your facts produces unexpected results, so you might want to perform more research. According the APNIC, >> 139.44.0.0/16 does not ?belong unambiguously to the Port Authority of Melbourne?. It belongs to an individual, with an office address >> at a building called ?Port Authority of Melbourne?: >> person: >> Rob Shute >> address: >> Port of Melbourne Authority >> Level 47 South >> 525 Collins St >> country: >> AU >> phone: >> +61 3 9628 7613 >> e-mail: >> djk at pma.vic.gov.au >> nic-hdl: >> RS54-AP >> remarks: >> ---------- >> remarks: >> imported from ARIN object: >> remarks: >> remarks: >> poc-handle: RS546-ARIN >> remarks: >> is-role: N >> remarks: >> last-name: Shute >> remarks: >> first-name: Rob >> remarks: >> street: Port of Melbourne Authority >> Level 47 South >> 525 Collins St >> remarks: >> country: AU >> remarks: >> mailbox: djk at pma.vic.gov.au >> remarks: >> bus-phone: +61 3 9628 7613 >> remarks: >> reg-date: 1970-01-01 >> remarks: >> changed: hostmaster at arin.poc 20001127 >> remarks: >> source: ARIN >> remarks: >> remarks: >> ---------- >> notify: >> djk at pma.vic.gov.au >> mnt-by: >> MNT-ERX-PRTMELAUTH-NON-AU >> last-modified: >> 2008-09-04T07:31:33Z >> source: >> APNIC >> The building called the Port Authority of Melbourne is not, by all accounts, a government agency. It?s just the name of a 54-story >> office building, like the World Trade Center in NYC. In fact, World Trade Centre (Melbourne) is another name for the building, and >> although it houses the Port of Melbourne Authority agency (on Level 4, not Level 47), it appears to be largely just a toney address >> for business offices. Some, perhaps, not unlike American ?Mail Boxes Etc? (although I haven?t confirmed this). But the following Wikipedia >> excerpt says this unambiguously: >> The building currently houses some offices of the headquarters of Victoria Police, and the Victoria Police Museum , a collection of >> exhibits and memorabilia from over 150 years of policing in Victoria.[3] It also houses offices for companies, including Thales >> Australia. >> https://en.m.wikipedia.org/wiki/Port_of_Melbourne_Authority >> Now, I?m not an Ossie, and in fact have never been down under, but it seems likely that the address in the registration is akin to a >> US business having a World Trade Center address in NYC. It means nothing as far as APNIC asset ownership is concerned. It?s just an >> address. >> I could be wrong. However, it seems a simple fact to verify by calling management at that building. I tried sending email to the >> registered ?.gov.au? address: >> djk at pma.vic.gov.au >> But the domain does not exist. >> -mel beckman >> On Sep 6, 2019, at 1:30 AM, Ronald F. Guilmette wrote: >> >> Few of you here probably know about this, but nearly a week ago now >> an article appeared in South Africa's largest and most popular online >> tech publication, MyBroadband.co.za. It detailed many, but certainly not >> all of the results of my multi-month investigation of a massive and >> ongoing fraud involving the theft of large numbers of large (generally >> /16 or larger) abandoned legacy blocks, taken from the AFRINIC region >> and beyond: >> https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html >> >> For various editorial reasons, the article that was published actually >> downplayed the magnitude of the of the thefts quite dramatically. The >> totality of the IPv4 space that has been stolen or squatted, primarily >> but not exclusively, from South African companies and South African national >> goverment agencies and departments is actually at least 5x bigger than what >> was reported in the MyBroadband.co.za article. >> >> The overwhelming majority of this stolen and squatted IPv4 space has >> been helpfully routed by Cogent (AS174), to their customer, FDCServers >> of Chicago, and then on to the prefered destinations of a certain Mr. >> Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have >> saved traceroutes up the wazoo that prove the involvement of FDCServers, >> in particular, in all of this.) >> >> Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting >> activities, basically grabbing everything that wasn't nailed down, both >> within the AFRINIC region and also within the APNIC region. >> >> In order to try to legitimize all of these thefts and squats, Mr. Cohen >> created quite a sizable number of fradulent route: objects within the >> Merit/RADB data base which, as most here should already know, has >> essentially zero authentication of any kind before it allows J. Random >> Luser to add pretty much any any route: object he wants to the RADB. >> >> Here's a full listing of all of Mr. Cohen's RADB route: objects as they >> existed as recently as August 17th: >> >> https://pastebin.com/raw/ZNgNuvtt >> >> And here is the short summary version showing just all of the prefixes/CIDRs >> that Mr. Cohen was effectively claiming rights and/or title to as of that >> same date: >> >> https://pastebin.com/raw/4LTaCg5R >> >> Plese do note the numerous blocks of size /16 or greater. >> >> The bottom line is that this one tiny little Israeli company was effectively >> claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of >> August 17th, 2019. (Not too shabby for one lone guy who teaches programming >> classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, >> and generally consists of blocks having sizes of /16 or larger. >> >> Some of Mr. Cohen claims in his RADB entries are as humorous as they >> are pathetically fradulent. For example, Mr. Cohen has effectively >> claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port >> Authority of the City of Melbourne, Australia. But hell! That's merely >> city property! Mr. Cohen's limitless appetite for other people's IPv4 >> space is more vividly on display in his claims to ownerhip over the >> 168.198.0.0/16 block, which actually belongs to the Department of Finance >> of the Australian national government. And I haven't even mentioned yet >> another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, >> which he did not see fit to create an RADB entry for, but which he's >> been squatting on for for quite some time now, quite clearly with the >> aid and assistance of both Cogent and FDCServers. That one belongs to >> th City of Cape Town, South Africa. That city's engineers have been >> struggling to regain control of their block back from Cogent, from >> FDCServers, and from Mr. Cohen for some time now. I know because I've >> personally spoken to them about it. Cogent, in its infinite wisdom, is >> continuing to fight the city for control over property that clearly and >> righfully belongs to the City of Cape Town, even as we speak: >> >> https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view >> >> When asked for LOAs attesting to his legitimate authority to route at >> least a few of these blocks, Mr. Cohen has produced blatantly forged >> documents, many of which appeared in the MyBroadband.co.za story. And >> when I say "blatant" that's a gross understatement. Any half-way decent >> forger would consider these documents an embarrasment. The documents all >> bear identical signatures, and identical and vaguely official looking >> stamps, and purport to actually be sales reciepts attesting to the >> alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell >> company, Afri Holdings, Ltd., of various /16 blocks from a mysterious >> company called Afrivestment, Ltd., which may actually exist in some >> faraway galaxy, or in Mr. Cohen's active imagination, but which both >> Google and OpenCorporates.com seem to agree exists exactly noplace on >> this planet. Here are the manufactured LOAs supplied by Mr. Cohen: >> >> https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view >> https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view >> https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view >> >> Recently, Cohen started to move some, but not all, of his stolen and squatted >> IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof >> hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or >> to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, >> coincidently, just happen to be owned by the exact same pair of Dutch >> gentlemen who previously owned the notorious Ecatel, follwed by the notorious >> Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly >> all of its legitimately assigned IP space from its predecessor entities, >> Ecatel and Quasi Networks.) >> >> Despite these relocations, many of Mr. Cohen's stolen and squatted blocks >> are still helpfully being routed to Mr. Cohen's preferred desitnations by >> his good friends at Cogent and FDCServers, even as we speak. The current >> set of such routes that Cogent is maintaining, at the moment, apparently on >> behalf of their customer, Mr. Cohen, consists of the prefixes listed here: >> >> https://pastebin.com/raw/EA3xJVLF >> >> When I noticed two days ago that all of these routes were still up I was >> deeply confused. Did both Cogent and FDCServrs not get the memo?? Do >> they not know yet that Cohen is stealing stuff, left, right, and sideways? >> Did nobody even tell them about the MyBroadband.co.za article which was >> published this past Sunday? I decided that it was incumbant upon me to >> find out. >> >> Thus, more that 48 hours ago now I sent the following polite but firm >> inquiry to Cogent, and a separate nearly identical one directly to the >> CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). >> >> https://pastebin.com/raw/ztipqE96 >> >> A full forty eight hours later, I have received no reply whatsoever from >> either Cogent or FDCServers, not even a "Go pound sand" type of response. >> >> More importantly, most of the stolen IPv4 space that I called out, very >> specifically, to both Cogent and FDCservers two+ days ago now is still >> being routed by Cogent/FDCservers to their fun-loving and, I'm sure, >> promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers >> still do not know now that Mr. Cohen is a crook, and that he has glommed >> onto quite a lot of stolen and squatted IPv4 space... which they have >> been helpfully routing for him, no doubt in exchange for some handsome >> payments... then I am foreced to say that it appears to be a reasonable >> conclusion that it must be because neither Cogent nor FDCServers really >> wants to know what sort of a character Cohen is, or what he has been up >> to, specifically with their ongoing and material assistance. >> >> But you all be the judges. What does it look like to you? >> >> Regards, >> rfg >> From neo at soonkeat.sg Fri Sep 6 13:46:10 2019 From: neo at soonkeat.sg (Neo Soon Keat) Date: Fri, 6 Sep 2019 13:46:10 +0000 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> References: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> Message-ID: Sorry, re-sending to include the list. Looking at the history of the prefix, it does look like it did belong to the now-defunct Port of Melbourne Authority, with the matching e-mail address. That particular organization, however, no longer exists, having been absorbed into the Port of Melbourne Corporation, which is a proper statutory organization in Australia. A quick MX lookup does show that pma.vic.gov.au does not have any functioning mail servers on it however, and likely hasn’t been for some time (given it was absorbed in 2003). On Sep 6, 2019, at 21:26, Mel Beckman wrote:  A quick check of one of your facts produces unexpected results, so you might want to perform more research. According the APNIC, 139.44.0.0/16 does not “belong unambiguously to the Port Authority of Melbourne”. It belongs to an individual, with an office address at a building called “Port Authority of Melbourne”: person: Rob Shute address: Port of Melbourne Authority Level 47 South 525 Collins St country: AU phone: +61 3 9628 7613 e-mail: djk at pma.vic.gov.au nic-hdl: RS54-AP remarks: ---------- remarks: imported from ARIN object: remarks: remarks: poc-handle: RS546-ARIN remarks: is-role: N remarks: last-name: Shute remarks: first-name: Rob remarks: street: Port of Melbourne Authority Level 47 South 525 Collins St remarks: country: AU remarks: mailbox: djk at pma.vic.gov.au remarks: bus-phone: +61 3 9628 7613 remarks: reg-date: 1970-01-01 remarks: changed: hostmaster at arin.poc 20001127 remarks: source: ARIN remarks: remarks: ---------- notify: djk at pma.vic.gov.au mnt-by: MNT-ERX-PRTMELAUTH-NON-AU last-modified: 2008-09-04T07:31:33Z source: APNIC The building called the Port Authority of Melbourne is not, by all accounts, a government agency. It’s just the name of a 54-story office building, like the World Trade Center in NYC. In fact, World Trade Centre (Melbourne) is another name for the building, and although it houses the Port of Melbourne Authority agency (on Level 4, not Level 47), it appears to be largely just a toney address for business offices. Some, perhaps, not unlike American “Mail Boxes Etc” (although I haven’t confirmed this). But the following Wikipedia excerpt says this unambiguously: The building currently houses some offices of the headquarters of Victoria Police, and the Victoria Police Museum , a collection of exhibits and memorabilia from over 150 years of policing in Victoria.[3] It also houses offices for companies, including Thales Australia. https://en.m.wikipedia.org/wiki/Port_of_Melbourne_Authority Now, I’m not an Ossie, and in fact have never been down under, but it seems likely that the address in the registration is akin to a US business having a World Trade Center address in NYC. It means nothing as far as APNIC asset ownership is concerned. It’s just an address. I could be wrong. However, it seems a simple fact to verify by calling management at that building. I tried sending email to the registered “.gov.au” address: djk at pma.vic.gov.au But the domain does not exist. -mel beckman On Sep 6, 2019, at 1:30 AM, Ronald F. Guilmette > wrote: Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rob.Wcislo at gtt.net Fri Sep 6 15:28:18 2019 From: Rob.Wcislo at gtt.net (Rob Wcislo) Date: Fri, 6 Sep 2019 15:28:18 +0000 Subject: gtt bgp fu? In-Reply-To: References: Message-ID: <4b6a4fb5b7034d858e1b1c7aa1fc53d1@gtt.net> + @Adam Davenport Rob Wcislo VP, Sales office: +1(908)516-4211 www.gtt.net [GTT_Logo_RGB_Blue] -----Original Message----- From: NANOG On Behalf Of Randy Bush Sent: Friday, September 6, 2019 8:56 AM To: North American Network Operators' Group Subject: gtt bgp fu? hi. i would love to chat (email) with someone in gtt (AS3257) who has bgp fu. doing some bgp measurements, we see something we do not understand and would love a clue. thanks. randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Fri Sep 6 15:38:41 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Sep 2019 08:38:41 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: References: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> Message-ID: On Fri, Sep 6, 2019 at 8:13 AM Neo Soon Keat wrote: > Sorry, re-sending to include the list. > > Looking at the history of the prefix, it does look like it did belong to > the now-defunct Port of Melbourne Authority, with the matching e-mail > address. That particular organization, however, no longer exists, having > been absorbed into the Port of Melbourne Corporation, which is a proper > statutory organization in Australia. > > A quick MX lookup does show that pma.vic.gov.au does not have any > functioning mail servers on it however, and likely hasn’t been for some > time (given it was absorbed in 2003). > > it's hard for a domein that doesn't exist to have any records, really... just sayin. > On Sep 6, 2019, at 21:26, Mel Beckman wrote: > >  > A quick check of one of your facts produces unexpected results, so you > might want to perform more research. According the APNIC, 139.44.0.0/16 > does not “belong unambiguously to the Port Authority of Melbourne”. It > belongs to an individual, with an *office address *at a building *called > “*Port Authority of Melbourne”: > > person: Rob Shute > > address: Port of Melbourne Authority > Level 47 South > 525 Collins St > > country: AU > phone: +61 3 9628 7613 > e-mail: djk at pma.vic.gov.au > nic-hdl: RS54-AP > remarks: ---------- > remarks: imported from ARIN object: > remarks: > remarks: poc-handle: RS546-ARIN > remarks: is-role: N > remarks: last-name: Shute > remarks: first-name: Rob > remarks: street: Port of Melbourne Authority > Level 47 South > 525 Collins St > remarks: country: AU > remarks: mailbox: djk at pma.vic.gov.au > remarks: bus-phone: +61 3 9628 7613 > remarks: reg-date: 1970-01-01 > remarks: changed: hostmaster at arin.poc 20001127 > remarks: source: ARIN > remarks: > remarks: ---------- > notify: djk at pma.vic.gov.au > mnt-by: MNT-ERX-PRTMELAUTH-NON-AU > > last-modified: 2008-09-04T07:31:33Z > source: APNIC > > The *building *called the Port Authority of Melbourne is not, by all > accounts, a government agency. It’s just the name of a 54-story office > building, like the World Trade Center in NYC. In fact, *World Trade > Centre (Melbourne) *is another name for the building, and although it > houses the Port of Melbourne Authority agency (on Level 4, not Level 47), > it appears to be largely just a toney address for business offices. Some, > perhaps, not unlike American “Mail Boxes Etc” (although I haven’t confirmed > this). But the following Wikipedia excerpt says this unambiguously: > > *The building currently houses some offices of the headquarters of > Victoria Police, and the Victoria Police Museum , a collection of exhibits > and memorabilia from over 150 years of policing in Victoria.[3] It also > houses offices for companies, including Thales Australia.* > > https://en.m.wikipedia.org/wiki/Port_of_Melbourne_Authority > > Now, I’m not an Ossie, and in fact have never been down under, but it > seems likely that the *address* in the registration is akin to a US > business having a World Trade Center address in NYC. It means nothing as > far as APNIC asset ownership is concerned. It’s just an address. > > I could be wrong. However, it seems a simple fact to verify by calling > management at that building. I tried sending email to the registered “. > gov.au” address: > > djk at pma.vic.gov.au > > But the domain does not exist. > > -mel beckman > > On Sep 6, 2019, at 1:30 AM, Ronald F. Guilmette > wrote: > > Few of you here probably know about this, but nearly a week ago now > an article appeared in South Africa's largest and most popular online > tech publication, MyBroadband.co.za. It detailed many, but certainly not > all of the results of my multi-month investigation of a massive and > ongoing fraud involving the theft of large numbers of large (generally > /16 or larger) abandoned legacy blocks, taken from the AFRINIC region > and beyond: > > > https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html > > For various editorial reasons, the article that was published actually > downplayed the magnitude of the of the thefts quite dramatically. The > totality of the IPv4 space that has been stolen or squatted, primarily > but not exclusively, from South African companies and South African > national > goverment agencies and departments is actually at least 5x bigger than what > was reported in the MyBroadband.co.za article. > > The overwhelming majority of this stolen and squatted IPv4 space has > been helpfully routed by Cogent (AS174), to their customer, FDCServers > of Chicago, and then on to the prefered destinations of a certain Mr. > Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have > saved traceroutes up the wazoo that prove the involvement of FDCServers, > in particular, in all of this.) > > Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting > activities, basically grabbing everything that wasn't nailed down, both > within the AFRINIC region and also within the APNIC region. > > In order to try to legitimize all of these thefts and squats, Mr. Cohen > created quite a sizable number of fradulent route: objects within the > Merit/RADB data base which, as most here should already know, has > essentially zero authentication of any kind before it allows J. Random > Luser to add pretty much any any route: object he wants to the RADB. > > Here's a full listing of all of Mr. Cohen's RADB route: objects as they > existed as recently as August 17th: > > https://pastebin.com/raw/ZNgNuvtt > > And here is the short summary version showing just all of the > prefixes/CIDRs > that Mr. Cohen was effectively claiming rights and/or title to as of that > same date: > > https://pastebin.com/raw/4LTaCg5R > > Plese do note the numerous blocks of size /16 or greater. > > The bottom line is that this one tiny little Israeli company was > effectively > claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of > August 17th, 2019. (Not too shabby for one lone guy who teaches > programming > classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, > and generally consists of blocks having sizes of /16 or larger. > > Some of Mr. Cohen claims in his RADB entries are as humorous as they > are pathetically fradulent. For example, Mr. Cohen has effectively > claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port > Authority of the City of Melbourne, Australia. But hell! That's merely > city property! Mr. Cohen's limitless appetite for other people's IPv4 > space is more vividly on display in his claims to ownerhip over the > 168.198.0.0/16 block, which actually belongs to the Department of Finance > of the Australian national government. And I haven't even mentioned yet > another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, > which he did not see fit to create an RADB entry for, but which he's > been squatting on for for quite some time now, quite clearly with the > aid and assistance of both Cogent and FDCServers. That one belongs to > th City of Cape Town, South Africa. That city's engineers have been > struggling to regain control of their block back from Cogent, from > FDCServers, and from Mr. Cohen for some time now. I know because I've > personally spoken to them about it. Cogent, in its infinite wisdom, is > continuing to fight the city for control over property that clearly and > righfully belongs to the City of Cape Town, even as we speak: > > https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view > > When asked for LOAs attesting to his legitimate authority to route at > least a few of these blocks, Mr. Cohen has produced blatantly forged > documents, many of which appeared in the MyBroadband.co.za story. And > when I say "blatant" that's a gross understatement. Any half-way decent > forger would consider these documents an embarrasment. The documents all > bear identical signatures, and identical and vaguely official looking > stamps, and purport to actually be sales reciepts attesting to the > alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell > company, Afri Holdings, Ltd., of various /16 blocks from a mysterious > company called Afrivestment, Ltd., which may actually exist in some > faraway galaxy, or in Mr. Cohen's active imagination, but which both > Google and OpenCorporates.com seem to agree exists exactly noplace on > this planet. Here are the manufactured LOAs supplied by Mr. Cohen: > > https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view > https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view > https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view > > Recently, Cohen started to move some, but not all, of his stolen and > squatted > IPv4 blocks off of Cogent/FDCServers and onto a friendly little > bullet-proof > hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or > to its several sister networks, e.g. AS204655 - Novogara Ltd., all of > which, > coincidently, just happen to be owned by the exact same pair of Dutch > gentlemen who previously owned the notorious Ecatel, follwed by the > notorious > Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly > all of its legitimately assigned IP space from its predecessor entities, > Ecatel and Quasi Networks.) > > Despite these relocations, many of Mr. Cohen's stolen and squatted blocks > are still helpfully being routed to Mr. Cohen's preferred desitnations by > his good friends at Cogent and FDCServers, even as we speak. The current > set of such routes that Cogent is maintaining, at the moment, apparently on > behalf of their customer, Mr. Cohen, consists of the prefixes listed here: > > https://pastebin.com/raw/EA3xJVLF > > When I noticed two days ago that all of these routes were still up I was > deeply confused. Did both Cogent and FDCServrs not get the memo?? Do > they not know yet that Cohen is stealing stuff, left, right, and sideways? > Did nobody even tell them about the MyBroadband.co.za article which was > published this past Sunday? I decided that it was incumbant upon me to > find out. > > Thus, more that 48 hours ago now I sent the following polite but firm > inquiry to Cogent, and a separate nearly identical one directly to the > CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). > > https://pastebin.com/raw/ztipqE96 > > A full forty eight hours later, I have received no reply whatsoever from > either Cogent or FDCServers, not even a "Go pound sand" type of response. > > More importantly, most of the stolen IPv4 space that I called out, very > specifically, to both Cogent and FDCservers two+ days ago now is still > being routed by Cogent/FDCservers to their fun-loving and, I'm sure, > promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers > still do not know now that Mr. Cohen is a crook, and that he has glommed > onto quite a lot of stolen and squatted IPv4 space... which they have > been helpfully routing for him, no doubt in exchange for some handsome > payments... then I am foreced to say that it appears to be a reasonable > conclusion that it must be because neither Cogent nor FDCServers really > wants to know what sort of a character Cohen is, or what he has been up > to, specifically with their ongoing and material assistance. > > But you all be the judges. What does it look like to you? > > > Regards, > rfg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Sep 6 15:52:23 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Sep 2019 08:52:23 -0700 Subject: IPAM recommendations In-Reply-To: <016201d56492$430f80f0$c92e82d0$@netconsultings.com> References: <016201d56492$430f80f0$c92e82d0$@netconsultings.com> Message-ID: You might also want to look at 6connect. Owen > On Sep 6, 2019, at 02:05 , wrote: > > I tried all 3 netbox, nipap and phpipam as a gui user and I like the phpipam the best as it has most knobs and features and is very intuitive, (can't comment on the api richness, yet) > But what is strange is that none of these tools provides RT (or extended/standard communities or even vlan for that matter) management the way they provide IP management, that is allow one to create custom pools and then have the next free resource allocated from a pool if needed. > > adam > From cscora at apnic.net Fri Sep 6 18:04:07 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Sep 2019 04:04:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190906180407.63891C34BB@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 Sep, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 770473 Prefixes after maximum aggregation (per Origin AS): 296709 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 371261 Total ASes present in the Internet Routing Table: 65415 Prefixes per ASN: 11.78 Origin-only ASes present in the Internet Routing Table: 56261 Origin ASes announcing only one prefix: 24079 Transit ASes present in the Internet Routing Table: 9154 Transit-only ASes present in the Internet Routing Table: 269 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 43 Max AS path prepend of ASN ( 19955) 41 Prefixes from unregistered ASNs in the Routing Table: 25 Number of instances of unregistered ASNs: 25 Number of 32-bit ASNs allocated by the RIRs: 28534 Number of 32-bit ASNs visible in the Routing Table: 23329 Prefixes from 32-bit ASNs in the Routing Table: 106198 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 290 Number of addresses announced to Internet: 2836686336 Equivalent to 169 /8s, 20 /16s and 102 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 257262 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 208408 Total APNIC prefixes after maximum aggregation: 62204 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 203158 Unique aggregates announced from the APNIC address blocks: 84758 APNIC Region origin ASes present in the Internet Routing Table: 10041 APNIC Prefixes per ASN: 20.23 APNIC Region origin ASes announcing only one prefix: 2790 APNIC Region transit ASes present in the Internet Routing Table: 1505 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5042 Number of APNIC addresses announced to Internet: 767127552 Equivalent to 45 /8s, 185 /16s and 112 /24s 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, 64297-64395, 131072-141625 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: 227493 Total ARIN prefixes after maximum aggregation: 106316 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 226235 Unique aggregates announced from the ARIN address blocks: 107595 ARIN Region origin ASes present in the Internet Routing Table: 18566 ARIN Prefixes per ASN: 12.19 ARIN Region origin ASes announcing only one prefix: 6861 ARIN Region transit ASes present in the Internet Routing Table: 1911 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 43 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2884 Number of ARIN addresses announced to Internet: 1069426304 Equivalent to 63 /8s, 190 /16s and 38 /24s 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-399260 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, 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: 215319 Total RIPE prefixes after maximum aggregation: 100703 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 211327 Unique aggregates announced from the RIPE address blocks: 124619 RIPE Region origin ASes present in the Internet Routing Table: 26418 RIPE Prefixes per ASN: 8.00 RIPE Region origin ASes announcing only one prefix: 11653 RIPE Region transit ASes present in the Internet Routing Table: 3737 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8451 Number of RIPE addresses announced to Internet: 721233280 Equivalent to 42 /8s, 253 /16s and 37 /24s 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, 64396-64495 196608-210331 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: 98559 Total LACNIC prefixes after maximum aggregation: 23000 LACNIC Deaggregation factor: 4.29 Prefixes being announced from the LACNIC address blocks: 99769 Unique aggregates announced from the LACNIC address blocks: 44405 LACNIC Region origin ASes present in the Internet Routing Table: 8784 LACNIC Prefixes per ASN: 11.36 LACNIC Region origin ASes announcing only one prefix: 2311 LACNIC Region transit ASes present in the Internet Routing Table: 1628 Average LACNIC Region AS path length visible: 5.5 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6347 Number of LACNIC addresses announced to Internet: 173868032 Equivalent to 10 /8s, 93 /16s and 4 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20668 Total AfriNIC prefixes after maximum aggregation: 4466 AfriNIC Deaggregation factor: 4.63 Prefixes being announced from the AfriNIC address blocks: 29694 Unique aggregates announced from the AfriNIC address blocks: 9623 AfriNIC Region origin ASes present in the Internet Routing Table: 1321 AfriNIC Prefixes per ASN: 22.48 AfriNIC Region origin ASes announcing only one prefix: 464 AfriNIC Region transit ASes present in the Internet Routing Table: 257 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 27 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 605 Number of AfriNIC addresses announced to Internet: 104769536 Equivalent to 6 /8s, 62 /16s and 168 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4966 599 583 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3245 1331 26 VIETEL-AS-AP Viettel Group, VN 45899 3054 1761 113 VNPT-AS-VN VNPT Corp, VN 9829 2733 1494 547 BSNL-NIB National Internet Backbone, IN 9808 2703 9043 63 CMNET-GD Guangdong Mobile Communication 4766 2545 11119 764 KIXS-AS-KR Korea Telecom, KR 7713 2258 685 603 TELKOMNET-AS-AP PT Telekomunikasi Indon 9498 2165 435 208 BBIL-AP BHARTI Airtel Ltd., IN 4755 2159 442 195 TATACOMM-AS TATA Communications formerl 9394 2079 4898 24 CTTNET China TieTong Telecommunications 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 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3656 238 673 CABLEONE - CABLE ONE, INC., US 6327 3496 1324 94 SHAW - Shaw Communications Inc., CA 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3119 6585 1472 AMAZON-02 - Amazon.com, Inc., US 16625 2766 1457 1992 AKAMAI-AS - Akamai Technologies, Inc., 30036 2188 349 170 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2146 2764 525 CHARTER-20115 - Charter Communications, 18566 2086 405 105 MEGAPATH5-US - MegaPath Corporation, US 5650 2074 3073 1453 FRONTIER-FRTR - Frontier Communications 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 12479 5529 1615 141 UNI2-AS, ES 39891 3780 219 19 ALJAWWALSTC-AS, SA 8551 2912 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2744 498 1939 AKAMAI-ASN1, US 31334 2604 484 13 KABELDEUTSCHLAND-AS, DE 12389 2389 2231 685 ROSTELECOM-AS, RU 34984 2132 348 529 TELLCOM-AS, TR 9121 2040 1692 19 TTNET, TR 9009 1766 191 967 M247, GB 13188 1604 100 47 TRIOLAN, UA 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 8151 6204 3352 610 Uninet S.A. de C.V., MX 10620 3368 534 445 Telmex Colombia S.A., CO 11830 2691 370 54 Instituto Costarricense de Electricidad 6503 1611 378 415 Axtel, S.A.B. de C.V., MX 7303 1479 1027 272 Telecom Argentina S.A., AR 28573 1167 2230 207 CLARO S.A., BR 6147 1103 380 35 Telefonica del Peru S.A.A., PE 3816 1059 538 124 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 1003 482 249 Mega Cable, S.A. de C.V., MX 11172 932 110 60 Alestra, S. de R.L. de C.V., MX 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 1121 393 23 LINKdotNET-AS, EG 36992 955 1535 73 ETISALAT-MISR, EG 24835 892 590 21 RAYA-AS, EG 36903 745 374 208 MT-MPLS, MA 8452 659 1857 19 TE-AS TE-AS, EG 29571 529 68 11 ORANGE-COTE-IVOIRE, CI 15399 415 45 11 WANANCHI-, KE 37342 369 32 1 MOVITEL, MZ 15706 362 32 6 Sudatel, SD 23889 359 231 15 MauritiusTelecom, MU 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 8151 6204 3352 610 Uninet S.A. de C.V., MX 12479 5529 1615 141 UNI2-AS, ES 7545 4966 599 583 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 219 19 ALJAWWALSTC-AS, SA 11492 3656 238 673 CABLEONE - CABLE ONE, INC., US 6327 3496 1324 94 SHAW - Shaw Communications Inc., CA 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3368 534 445 Telmex Colombia S.A., CO 7552 3245 1331 26 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5529 5388 UNI2-AS, ES 7545 4966 4383 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 4040 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 3761 ALJAWWALSTC-AS, SA 6327 3496 3402 SHAW - Shaw Communications Inc., CA 22773 3454 3298 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3245 3219 VIETEL-AS-AP Viettel Group, VN 11492 3656 2983 CABLEONE - CABLE ONE, INC., US 45899 3054 2941 VNPT-AS-VN VNPT Corp, VN 10620 3368 2923 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 68710 UNALLOCATED 45.170.231.0/24 268710 UNKNOWN 260984 UNALLOCATED 45.175.186.0/23 16735 ALGAR TELECOM S/A, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ 41.242.93.0/24 37643 -Reserved AS-, ZZ 43.229.16.0/22 136800 XIAOZHIYUN1-AS-AP ICIDC NETWORK, US 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:10 /9:12 /10:37 /11:99 /12:290 /13:573 /14:1145 /15:1917 /16:13245 /17:7986 /18:13746 /19:25628 /20:40262 /21:47249 /22:96314 /23:77879 /24:443175 /25:906 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4488 5529 UNI2-AS, ES 6327 3282 3496 SHAW - Shaw Communications Inc., CA 7155 3156 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3780 ALJAWWALSTC-AS, SA 11492 2867 3656 CABLEONE - CABLE ONE, INC., US 22773 2684 3454 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 31334 2492 2604 KABELDEUTSCHLAND-AS, DE 8551 2365 2912 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2039 2691 Instituto Costarricense de Electricidad y Telec 18566 1981 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1732 2:1098 3:6 4:22 5:3028 6:50 7:1 8:1359 9:1 12:1795 13:398 14:2115 15:42 16:7 17:271 18:81 20:56 23:2912 24:2591 25:4 27:2465 31:2723 32:107 35:37 36:908 37:3125 38:1808 39:303 40:121 41:3371 42:835 43:2089 44:175 45:10235 46:3353 47:269 49:1446 50:1098 51:341 52:1063 54:265 55:686 56:6 57:47 58:2057 59:1115 60:582 61:2224 62:1989 63:1855 64:5031 65:2248 66:4806 67:2747 68:1200 69:3571 70:1386 71:671 72:2679 74:2692 75:1291 76:596 77:2546 78:1972 79:2151 80:1818 81:1505 82:1161 83:963 84:1171 85:2360 86:563 87:1567 88:1088 89:2563 90:230 91:6597 92:1449 93:2475 94:2585 95:3641 96:954 97:340 98:957 99:833 100:88 101:1197 102:651 103:22071 104:3631 105:282 106:815 107:1791 108:691 109:3564 110:1763 111:2021 112:1539 113:1427 114:1282 115:1781 116:1749 117:1971 118:2228 119:1656 120:1065 121:1047 122:2305 123:1860 124:1532 125:2019 128:1345 129:855 130:547 131:1810 132:755 133:224 134:1106 135:255 136:598 137:799 138:2050 139:949 140:635 141:873 142:785 143:1076 144:887 145:281 146:1369 147:856 148:1786 149:1033 150:825 151:1026 152:1375 153:359 154:4363 155:892 156:2230 157:1056 158:696 159:1942 160:1581 161:956 162:2986 163:837 164:1272 165:1157 166:517 167:1441 168:3462 169:472 170:4209 171:665 172:1714 173:2231 174:1040 175:1001 176:2442 177:3972 178:2723 179:1438 180:2142 181:2380 182:2780 183:1155 184:2278 185:15490 186:3714 187:2552 188:3435 189:2045 190:8258 191:1462 192:10087 193:6755 194:5529 195:4194 196:3101 197:1738 198:6019 199:5974 200:7147 201:5149 202:10377 203:10309 204:4567 205:3055 206:3224 207:3285 208:3934 209:4318 210:3930 211:2035 212:3276 213:2947 214:1128 215:54 216:5927 217:2245 218:871 219:601 220:1917 221:973 222:985 223:1379 End of report From surfer at mauigateway.com Fri Sep 6 18:18:44 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Sep 2019 11:18:44 -0700 Subject: Art and Tech is madness Message-ID: <20190906111844.FEC5A52D@m0117460.ppops.net> --- cboyd at gizmopartners.com wrote: From: Chris Boyd There’s also this gem from 2005 or 2007 days. I’ve heard Cisco staff was involved in its creation. http://www.mattzrelak.com/mp3/t1down.htm ------------------------------ At work... ====================================== This site is blocked due to a security threat. www.mattzrelak.com This site is blocked due to a security threat that was discovered by the Cisco Umbrella security researchers. Report an incorrect block ===================================== scott From chip at 2bithacker.net Fri Sep 6 19:11:55 2019 From: chip at 2bithacker.net (Chip Marshall) Date: Fri, 6 Sep 2019 12:11:55 -0700 Subject: Google DNS Oddity Message-ID: <20190906191155.GA1768@2bithacker.net> Hello, I'm seeing an oddity when doing DNS lookups for www.google.com from our London datacenter, and I'm curious if other people are seeing the same behavior. It appears that when we ask for www.google.com. we sometimes get an answer that only contains records for www-anycast.google.com., which our resolver ignores as they don't match the query. As seen with dig: ``` # dig @ns1.google.com. www.google.com. aaaa ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42641 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 ;; Query time: 7 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Fri Sep 06 19:05:32 UTC 2019 ;; MSG SIZE rcvd: 167 ``` So far I've observed this with A and AAAA queries. It's my understanding that without a CNAME record in the answer, the resolver is doing the right thing by ignoring the answer, as there's no linkage between www and www-anycast. Is this broken, or is this just some weird DNS trick I've not come across before? -- Chip Marshall From jared at puck.nether.net Fri Sep 6 19:17:07 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 6 Sep 2019 15:17:07 -0400 Subject: Google DNS Oddity In-Reply-To: <20190906191155.GA1768@2bithacker.net> References: <20190906191155.GA1768@2bithacker.net> Message-ID: > On Sep 6, 2019, at 3:11 PM, Chip Marshall via NANOG wrote: > > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com from our > London datacenter, and I'm curious if other people are seeing the same > behavior. > > It appears that when we ask for www.google.com. we sometimes get an answer > that only contains records for www-anycast.google.com., which our resolver > ignores as they don't match the query. > > As seen with dig: > > ``` > # dig @ns1.google.com. www.google.com. aaaa > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42641 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.google.com. IN AAAA > > ;; ANSWER SECTION: > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 > > ;; Query time: 7 msec > ;; SERVER: 216.239.32.10#53(216.239.32.10) > ;; WHEN: Fri Sep 06 19:05:32 UTC 2019 > ;; MSG SIZE rcvd: 167 > ``` > > So far I've observed this with A and AAAA queries. It's my understanding that > without a CNAME record in the answer, the resolver is doing the right thing by > ignoring the answer, as there's no linkage between www and www-anycast. > > Is this broken, or is this just some weird DNS trick I've not come across > before? You may want to post on dns-operations instead. Can you do a dig +trace www.google.com instead, that would be more instructive about what’s happening at each layer of the delegation. - Jared From stuart at tech.org Fri Sep 6 19:49:08 2019 From: stuart at tech.org (Stephen Stuart) Date: Fri, 06 Sep 2019 19:49:08 +0000 Subject: Google DNS Oddity In-Reply-To: References: <20190906191155.GA1768@2bithacker.net> Message-ID: <201909061949.x86Jn8NG017406@nb.tech.org> Do you see the same behavior when you execute your dig query without the trailing dot? Thanks, Stephen > > On Sep 6, 2019, at 3:11 PM, Chip Marshall via NANOG wrote: > > > > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com from our > > London datacenter, and I'm curious if other people are seeing the same > > behavior. > > > > It appears that when we ask for www.google.com. we sometimes get an answer > > that only contains records for www-anycast.google.com., which our resolver > > ignores as they don't match the query. > > > > As seen with dig: > > > > ``` > > # dig @ns1.google.com. www.google.com. aaaa > > > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42641 > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; WARNING: recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 512 > > ;; QUESTION SECTION: > > ;www.google.com. IN AAAA > > > > ;; ANSWER SECTION: > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 > > > > ;; Query time: 7 msec > > ;; SERVER: 216.239.32.10#53(216.239.32.10) > > ;; WHEN: Fri Sep 06 19:05:32 UTC 2019 > > ;; MSG SIZE rcvd: 167 > > ``` > > > > So far I've observed this with A and AAAA queries. It's my understanding that > > without a CNAME record in the answer, the resolver is doing the right thing by > > ignoring the answer, as there's no linkage between www and www-anycast. > > > > Is this broken, or is this just some weird DNS trick I've not come across > > before? > > You may want to post on dns-operations instead. > > Can you do a dig +trace www.google.com instead, that would be more instructive about whatт€™s happening at each layer o f the delegation. > > - Jared From nick at foobar.org Fri Sep 6 20:19:47 2019 From: nick at foobar.org (Nick Hilliard) Date: Fri, 6 Sep 2019 21:19:47 +0100 Subject: Google DNS Oddity In-Reply-To: <20190906191155.GA1768@2bithacker.net> References: <20190906191155.GA1768@2bithacker.net> Message-ID: Chip Marshall via NANOG wrote on 06/09/2019 20:11: > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com from our > London datacenter, and I'm curious if other people are seeing the same > behavior. I saw a bunch of monitoring systems queries for www.google.com/A return back with no A records at ~20:35 BST. It's returned back to normal now, but we needed to flush a bunch of DNS caches. Nick From chip at 2bithacker.net Fri Sep 6 20:33:23 2019 From: chip at 2bithacker.net (Chip Marshall) Date: Fri, 6 Sep 2019 13:33:23 -0700 Subject: Google DNS Oddity In-Reply-To: References: <20190906191155.GA1768@2bithacker.net> Message-ID: <20190906203323.GB1768@2bithacker.net> On 2019-09-06, Jared Mauch sent: > You may want to post on dns-operations instead. Will do. > Can you do a dig +trace www.google.com instead, that would be more > instructive about what’s happening at each layer of the delegation. # dig +trace www.google.com. aaaa ; <<>> DiG 9.10.3-P4-Ubuntu <<>> +trace www.google.com. aaaa ;; global options: +cmd . 40841 IN NS b.root-servers.net. . 40841 IN NS g.root-servers.net. . 40841 IN NS k.root-servers.net. . 40841 IN NS i.root-servers.net. . 40841 IN NS m.root-servers.net. . 40841 IN NS c.root-servers.net. . 40841 IN NS l.root-servers.net. . 40841 IN NS e.root-servers.net. . 40841 IN NS d.root-servers.net. . 40841 IN NS f.root-servers.net. . 40841 IN NS h.root-servers.net. . 40841 IN NS j.root-servers.net. . 40841 IN NS a.root-servers.net. . 40841 IN RRSIG NS 8 0 518400 20190917050000 20190904040000 59944 . W93v8sQLROIXL1qvcezKKnL8XwzzxuFb6VbyV7h+SG27BIgJiOGrNE5q M6ncTYozvKd3tKJ/cQZcnIO9zi9tInPKgVctNF1Fp2FGb8TnFuTkIOMy MEVzbWEZrZErcToDRaK1WzlrxBL6gsIfegE8gjC/2XVnKQENZCJ4qgg8 V/u1CKbJGV0nmnVusCZ6pXnkVJDDdvvicaUf0IoxqEONh1h/xKghX14R 6leOUCJpAtdS0M9eyPeBL5myCm7olOVhi/A+9QjZLv60vefYAF7aREtW 5mEvg/YyNz4dUOHrhz/iRbK/wGIbtyuTpvy3Gg/F2dtrVfJBzobDnGpv sFO4xA== ;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 1 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20190919170000 20190906160000 59944 . ep9gNcyySwR/AqNOnfjXq3OCw5IwOJnIxU4U25UdZ2ejwbJqLf8ytp68 O5DQz1N/PvrEhi1Wg8XyQHZM+fc38cYhhjG5HMVOcEN3wvifnxTWEwBs ay2GxF10TtUpg9TF4Qs2+V8k0ABWwAKIBbSAeZ+C+l5mBg18CCnTgjeg PR+466SgA7sHbzaI9PYK57suhq3uLrphcC2Ti7jmV9V41H5D52gNTiV5 eQ2BsPo+l5LyLrvusailMOzogav9v4M9bnOSGTcc85nf/wD5/Vo4R4MU OexIxio0NGBl7GeS3zoPKV29CYnfcuZBkD2VBuPKZafxp0nIo4olMznn szi9lg== ;; Received 1174 bytes from 199.7.83.42#53(l.root-servers.net) in 60 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190912044627 20190905033627 17708 com. kXWtAEptQhH9JpsAJzpvEwEwRtybI/FVl9Hrd1lr/GTkZ3P4clnR7YLB quX4CVf8E0+gEfwf4U2PpmphROV1eHweyycVydvTE8etaDipTpItbtyG 7Iz/uKjp1TY3RD+qNa6LZ1juEs70aKPsbmEV79rtiTW2kurdgqslP5jH Jg0= S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN NSEC3 1 1 0 - S84CFH3A62N0FJPC5D9IJ2VJR71OGLV5 NS DS RRSIG S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN RRSIG NSEC3 8 2 86400 20190913045601 20190906034601 17708 com. bJE7LV1REfTtY1jFj/9qA1CKIDBgCJOTV42tSwf92aqhTAkflM9QFH7/ 3Z5440IkZ8PoWMt9Yn7fn+Q+cTZVnbj071jVpiLNXshhMQbtDC1eJkLz AIuATIj+dqWTWQg7vut0oiy0wnJ2ktSgqTFe4JtwRD0lWO6+NgnhbgQD 2yg= ;; Received 776 bytes from 192.43.172.30#53(i.gtld-servers.net) in 74 ms www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 ;; Received 167 bytes from 216.239.38.10#53(ns4.google.com) in 6 ms -- Chip Marshall From rfg at tristatelogic.com Fri Sep 6 20:34:26 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 06 Sep 2019 13:34:26 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <5233B9B9-1BFF-425D-BB8F-E3853703B3F3@beckman.org> Message-ID: <23540.1567802066@segfault.tristatelogic.com> In message <5233B9B9-1BFF-425D-BB8F-E3853703B3F3 at beckman.org>, Mel Beckman wrote: >A quick check of one of your facts produces unexpected results, so you might >want to perform more research. According the APNIC, 139.44.0.0/16 does not >“belong unambiguously to the Port Authority of Melbourne”. Please, let's not start staring at -one- tree out of the sveeral that I've talked about, and then start arguing about the shape of the pine cones on that one tree. Doing that will give short shrift to the rather larger forrest that I've tried to expose here. Is anyone disputing that 168.198.0.0/16 belongs to the Australian national government, or that AS174, Cogent was, until quite recently, routing that down to their pals at FDCServers who then were routing it down to their customer, Elad Cohen? If so, I ask that people look up this network in the RIPE Routing history tool and ALSO that folks have a look at, and explain, the following traceroute from August 23: https://pastebin.com/raw/2nJtbwjs Is anyone disputing that the 165.25.0.0/16 block rightfully belongs to the City of Cape Town, or that Cogent -continues- even as we speak, to announce a competing route to it? If so, I ask any such parties to please explain this traceroute from August 20th: https://pastebin.com/raw/2nJtbwjs Is anyones disputing that the LOAs that Mr. Cohen has produced in response to queries about some of the blocks he has stolen, and then routed via Cogent and FDCServers, are blatant and indeed really bad forgeries? Is anyone disputing that Mr. Cohen has, in effect, and via the Merit/RADB data base, claimed rights over more than a million IPv4 addresses, many of which self-evidently do not belong to him, or that Mr. Cohen's gracious and helpful providers, FDCSewers and Cogent appear to have effectively turned a blind eye to all this, or that they continue to do so, even as we speak? The Subject line that I used to start this thread may have seemed to some to be over-the-top and provocative, but to be frank, I think now that I may have not gone far enough. Cogent has been announcing a route to the 165.25.0.0/16 block, which unambiguously belongs to the City of Cape Town, At what point does such interference with legitimate governmental functions an authority, on Cogent's part, cross over from being merely bad manners and into the realm of criminality? Regards, rfg From chip at 2bithacker.net Fri Sep 6 20:34:41 2019 From: chip at 2bithacker.net (Chip Marshall) Date: Fri, 6 Sep 2019 13:34:41 -0700 Subject: Google DNS Oddity In-Reply-To: <201909061949.x86Jn8NG017406@nb.tech.org> References: <20190906191155.GA1768@2bithacker.net> <201909061949.x86Jn8NG017406@nb.tech.org> Message-ID: <20190906203441.GC1768@2bithacker.net> On 2019-09-06, Stephen Stuart sent: > Do you see the same behavior when you execute your dig query without > the trailing dot? Yes. dig adds on the trailing dot to make it an FQDN anyway, so the on-wire qname is the same either way. -- Chip Marshall From rfg at tristatelogic.com Fri Sep 6 21:06:32 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 06 Sep 2019 14:06:32 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <23540.1567802066@segfault.tristatelogic.com> Message-ID: <23795.1567803992@segfault.tristatelogic.com> In message <23540.1567802066 at segfault.tristatelogic.com>, I wrote: >Is anyone disputing that 168.198.0.0/16 belongs to the Australian >national government, or that AS174, Cogent was, until quite recently, >routing that down to their pals at FDCServers who then were routing >it down to their customer, Elad Cohen? If so, I ask that people look >up this network in the RIPE Routing history tool and ALSO that folks >have a look at, and explain, the following traceroute from August 23: > > https://pastebin.com/raw/2nJtbwjs My apologies. In my furious haste, I botched that one URL. Here is the correct file conatining my traceroute to 168.198.12.242 as performed by me on August 23rd: https://pastebin.com/raw/TrLbGZuW Regards, rfg From Bryan at bryanfields.net Fri Sep 6 21:12:12 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 6 Sep 2019 17:12:12 -0400 Subject: rr.level3.net on autopilot? In-Reply-To: <398B250423578A4E97AFE1B8B67C686C653598C5@PDDCWMBXEX503.ctl.intranet> References: <398B250423578A4E97AFE1B8B67C686C653598C5@PDDCWMBXEX503.ctl.intranet> Message-ID: For following up, their IPadmin team (person) did reach out and resolve this asap for us. Thanks! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From nick at foobar.org Fri Sep 6 21:17:20 2019 From: nick at foobar.org (Nick Hilliard) Date: Fri, 6 Sep 2019 22:17:20 +0100 Subject: Google DNS Oddity In-Reply-To: References: <20190906191155.GA1768@2bithacker.net> Message-ID: Nick Hilliard wrote on 06/09/2019 21:19: > Chip Marshall via NANOG wrote on 06/09/2019 20:11: >> Hello, I'm seeing an oddity when doing DNS lookups for www.google.com >> from our >> London datacenter, and I'm curious if other people are seeing the same >> behavior. > > I saw a bunch of monitoring systems queries for www.google.com/A return > back with no A records at ~20:35 BST.  It's returned back to normal now, > but we needed to flush a bunch of DNS caches. ... aaaand there we go again at 22:07 BST. Nick From rfg at tristatelogic.com Fri Sep 6 21:58:31 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 06 Sep 2019 14:58:31 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <67B3E0D5-7D09-42E2-A753-EB6C93859F12@getmailspring.com> Message-ID: <24084.1567807111@segfault.tristatelogic.com> In message <67B3E0D5-7D09-42E2-A753-EB6C93859F12 at getmailspring.com>, Florian Brandstetter wrote: >if you'd open the traceroute you just sent you'd see that the target >is route looping and not actually used by their alleged customer? Yea. So? How is that relevant to my fundamental narrative? Cogent was announcing the whole of 168.198.0.0/16. Do we agree? Theye were most probably *not* doing so just for laughs or just to create routing loops. Do we agree? Traceroutes show that from Cogent, packets were further being passed to FDCServers. Do we agree? Now, if you want to know who FDCSewer's customer was in this case, why don't you try asking them? I am satisfied that the intel that I've already collected indicates the exceptionally high probability that this entire legacy /16 block... along with many many others, also of entirely dubious provenance... were all being routed to and for a certain Mr. Elad Cohen and his company, Netstyle Atarim, Ltd.: organisation: ORG-NAL9-RIPE org-name: NETSTYLE A. LTD org-type: LIR address: Derech Menachem Begin 156 address: 6492108 address: Tel-Aviv address: ISRAEL phone: +972-1-800-204-404 e-mail: info (at) netstyle.io >Also, what would the target IP have been in this case, since it was omitted? If you look carefully, I gave that in the post you are responding to: >> My apologies. In my furious haste, I botched that one URL. Here is the >> correct file conatining my traceroute to 168.198.12.242 as performed by >> me on August 23rd: >> >> https://pastebin.com/raw/TrLbGZuW Regards, rfg From mel at beckman.org Fri Sep 6 23:59:03 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 6 Sep 2019 23:59:03 +0000 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <23795.1567803992@segfault.tristatelogic.com> References: <23540.1567802066@segfault.tristatelogic.com>, <23795.1567803992@segfault.tristatelogic.com> Message-ID: Ron, I’m just saying that I randomly checked one fact and it doesn’t meet the level of positive certainty that you asserted. It’s thus reasonable to ask you to double check your research all around. I’m not willing to be your unpaid copy editor, so let me know when you’ve done a double check and I’ll be willing to invest time in your story again. -mel via cell > On Sep 6, 2019, at 2:07 PM, Ronald F. Guilmette wrote: > > In message <23540.1567802066 at segfault.tristatelogic.com>, I wrote: > >> Is anyone disputing that 168.198.0.0/16 belongs to the Australian >> national government, or that AS174, Cogent was, until quite recently, >> routing that down to their pals at FDCServers who then were routing >> it down to their customer, Elad Cohen? If so, I ask that people look >> up this network in the RIPE Routing history tool and ALSO that folks >> have a look at, and explain, the following traceroute from August 23: >> >> https://pastebin.com/raw/2nJtbwjs > > My apologies. In my furious haste, I botched that one URL. Here is the > correct file conatining my traceroute to 168.198.12.242 as performed by > me on August 23rd: > > https://pastebin.com/raw/TrLbGZuW > > > Regards, > rfg From ops.lists at gmail.com Sat Sep 7 00:28:47 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Sep 2019 00:28:47 +0000 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: References: <23540.1567802066@segfault.tristatelogic.com>, <23795.1567803992@segfault.tristatelogic.com>, Message-ID: The fact that the port authority building is also an office building with multiple other tenants? Whois contacts on a defunct domain belonging to an Australian government port authority agency that’s since been renamed don’t appear to support your hypothesis that this is another tenant of a government owned building. --srs ________________________________ From: NANOG on behalf of Mel Beckman Sent: Saturday, September 7, 2019 5:30 AM To: Ronald F. Guilmette Cc: nanog at nanog.org Subject: Re: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? Ron, I’m just saying that I randomly checked one fact and it doesn’t meet the level of positive certainty that you asserted. It’s thus reasonable to ask you to double check your research all around. I’m not willing to be your unpaid copy editor, so let me know when you’ve done a double check and I’ll be willing to invest time in your story again. -mel via cell > On Sep 6, 2019, at 2:07 PM, Ronald F. Guilmette wrote: > > In message <23540.1567802066 at segfault.tristatelogic.com>, I wrote: > >> Is anyone disputing that 168.198.0.0/16 belongs to the Australian >> national government, or that AS174, Cogent was, until quite recently, >> routing that down to their pals at FDCServers who then were routing >> it down to their customer, Elad Cohen? If so, I ask that people look >> up this network in the RIPE Routing history tool and ALSO that folks >> have a look at, and explain, the following traceroute from August 23: >> >> https://pastebin.com/raw/2nJtbwjs > > My apologies. In my furious haste, I botched that one URL. Here is the > correct file conatining my traceroute to 168.198.12.242 as performed by > me on August 23rd: > > https://pastebin.com/raw/TrLbGZuW > > > Regards, > rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Sat Sep 7 00:51:17 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 06 Sep 2019 17:51:17 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: Message-ID: <24802.1567817477@segfault.tristatelogic.com> In message , Mel Beckman wrote: >I’m just saying that I randomly checked one fact and it doesn’t meet >the level of positive certainty that you asserted. It’s thus reasonable >to ask you to double check your research all around. I’m not willing >to be your unpaid copy editor, so let me know when you’ve done a double >check and I’ll be willing to invest time in your story again. Well, let's dissect that a bit. You're asserting an inadequate "level of positive certainty" but you have not specified about what, in particular. I posted a link to a list of 71 different RADB entries that were present in the Merit/RADB data base as of August 17th, all of which gave every appearance of having been created by Mr. Elad Cohen. I will assume for the moment that you are not calling into question the "positive certainty" that I have about any of that data or about any of those RADB entries. Out of those 71 routes, most of which appear to be rather clearly fradulent, you have picked out exactly and only -one- of those 71, and your only criticism seems to be that I haven't been quite precise enough in my identification of the exact victim, somewhere in Australia, in that one particular case. I just want to make sure that I understand. You're -not- claiming that either Mr. Cohen or FDCServers, or Cogent had any legitimate rights or titles to that specific block (139.44.0.0/16), correct? You are only claiming that I have mis-identified the victim of this particular squat as being `X' when I should more properly have said that the actual victim was in fact `Y'. Am I summarizing your criticism accurately? Regards, rfg P.S. Not that it matters to the point Mel raised, but I would like to just note in passing that the 139.44.0.0/16 block, may perhaps *not* in fact be routed by AS174 (Cogent) anymore, although it did appear to still be routed by AS17, at least to bgp.he.net, as of 05 Sep 2019 20:34 PST: https://bgp.he.net/net/139.44.0.0/16 More current data from RIPEStat indicates that this entire /16 is now being routed by Mr. Cohen's new good friends at AS204655, Novogara Ltd., which appears to be owned and operated by the same two sterling Dutch gentlemen, Mr. Ferdinand Reinier Van Eeden and Mr. Bartholomeus Johannes ("Bap") Karreman, who also appear to be the owners/operators of what is noadays called "IP Volume Inc." and which previously was known as Quasi Networks, and which was, before that, known as Ecatel. Novogara appears to have become home to quite a number of sizable IPv4 legacy blocks, from both the AFRINIC region and also the APNIC region, in very recent days: https://bgp.he.net/AS204655#_prefixes The fact that there seems to be a rather significant correlation between the IPv4 legacy blocks currently being announced by Mr. Van Eeden's and Mr. Karreman's several Dutch ASNs and the list of pilfered IPv4 legacy blocks that Mr. Cohen was kind enough to supply in the RADB data base should, in my opinion, come as a surprise to exactly no one. From cboyd at gizmopartners.com Sat Sep 7 22:59:11 2019 From: cboyd at gizmopartners.com (Chris Boyd) Date: Sat, 7 Sep 2019 17:59:11 -0500 Subject: Art and Tech is madness In-Reply-To: <20190906111844.FEC5A52D@m0117460.ppops.net> References: <20190906111844.FEC5A52D@m0117460.ppops.net> Message-ID: <08DE2712-FD67-4C38-B5CE-78813E08CFF0@gizmopartners.com> > On Sep 6, 2019, at 1:18 PM, Scott Weeks wrote: > > This site is blocked due to a security threat that was discovered by the > Cisco Umbrella security researchers. Here’s a YouTube link. https://www.youtube.com/watch?v=9k6A0ZlhTyw —Chris From adamv0025 at netconsultings.com Sun Sep 8 09:51:37 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Sun, 8 Sep 2019 10:51:37 +0100 Subject: IPAM recommendations In-Reply-To: References: <016201d56492$430f80f0$c92e82d0$@netconsultings.com> Message-ID: <027701d5662b$02517f60$06f47e20$@netconsultings.com> > From: Owen DeLong > Sent: Friday, September 6, 2019 4:52 PM > > You might also want to look at 6connect. > > I actually did recently, to potentially migrate from phpipam, but I couldn't even drive the IPAM thing :( Just saying, in phpipam I didn't have any trouble figuring out basic stuff like how to name a subnet, assign IP to A-side host and B-side host on a p2p link with /31 (or /30) subnet, or how to create children off of a parent block in no time. Though what I like about 6conenc is that its insanely customizable and I like the automatic chopping of subnet to equal sized blocks and ability to merge etc., but... as I said couldn't drive even the basic stuff... And regarding the automation capabilities -I actually like the full blown ONAP style automation better. adam From florianb at globalone.io Fri Sep 6 20:08:19 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Fri, 6 Sep 2019 22:08:19 +0200 Subject: Google DNS Oddity In-Reply-To: <201909061949.x86Jn8NG017406@nb.tech.org> References: <201909061949.x86Jn8NG017406@nb.tech.org> Message-ID: Unable to replicate this in London: ``` ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61970 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 300 IN AAAA 2a00:1450:4009:80d::2004 ``` going by the latency, ns1.google.com (https://link.getmailspring.com/link/C27D5EBE-B680-425A-B057-218C6300A7B4 at getmailspring.com/0?redirect=ns1.google.com&recipient=bmFub2dAbmFub2cub3Jn) travels to NL from our UK PoPs though: ``` Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. ??? 3. ae26-0.ebr01.lon3.uk.globalone 0.0% 13 2.1 6.2 1.0 45.7 12.9 4. 2001:7f8:4::3b41:1 0.0% 13 0.7 0.8 0.6 1.7 0.4 5. 2001:4860:0:1101::10 0.0% 13 0.7 2.7 0.7 14.2 4.2 6. 2001:4860::c:4000:cf5b 0.0% 13 1.8 2.1 1.5 4.0 0.7 7. 2001:4860::8:4000:d325 0.0% 13 8.6 7.3 6.6 9.5 0.9 8. 2001:4860::22:4001:70b 0.0% 13 6.4 9.5 6.4 36.9 8.3 9. 2001:4860:0:1::be7 23.1% 13 7.3 7.5 7.3 7.7 0.1 10. ??? 11. ??? 12. ??? 13. ??? 14. ??? 15. ??? 16. ??? 17. ??? 18. ??? 19. ns1.google.com 0.0% 12 6.4 6.4 6.3 6.5 0.0 ``` On Sep. 6 2019, at 9:49 pm, Stephen Stuart wrote: > Do you see the same behavior when you execute your dig query without > the trailing dot? > > Thanks, > Stephen > > > > On Sep 6, 2019, at 3:11 PM, Chip Marshall via NANOG wrote: > > > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com from our > > > London datacenter, and I'm curious if other people are seeing the same > > > behavior. > > > > > > It appears that when we ask for www.google.com. we sometimes get an answer > > > that only contains records for www-anycast.google.com., which our resolver > > > ignores as they don't match the query. > > > > > > As seen with dig: > > > ``` > > > # dig @ns1.google.com. www.google.com. aaaa > > > > > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa > > > ; (2 servers found) > > > ;; global options: +cmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42641 > > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > > ;; WARNING: recursion requested but not available > > > > > > ;; OPT PSEUDOSECTION: > > > ; EDNS: version: 0, flags:; udp: 512 > > > ;; QUESTION SECTION: > > > ;www.google.com. IN AAAA > > > > > > ;; ANSWER SECTION: > > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 > > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 > > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 > > > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 > > > > > > ;; Query time: 7 msec > > > ;; SERVER: 216.239.32.10#53(216.239.32.10) > > > ;; WHEN: Fri Sep 06 19:05:32 UTC 2019 > > > ;; MSG SIZE rcvd: 167 > > > ``` > > > > > > So far I've observed this with A and AAAA queries. It's my understanding that > > > without a CNAME record in the answer, the resolver is doing the right thing by > > > ignoring the answer, as there's no linkage between www and www-anycast. > > > > > > Is this broken, or is this just some weird DNS trick I've not come across > > > before? > > > > > > You may want to post on dns-operations instead. > > Can you do a dig +trace www.google.com instead, that would be more instructive about whatт€™s happening at each layer o > f the delegation. > > > > - Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From florianb at globalone.io Fri Sep 6 21:12:13 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Fri, 6 Sep 2019 23:12:13 +0200 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <23795.1567803992@segfault.tristatelogic.com> References: <23795.1567803992@segfault.tristatelogic.com> Message-ID: <67B3E0D5-7D09-42E2-A753-EB6C93859F12@getmailspring.com> Hello Ronald, if you'd open the traceroute you just sent you'd see that the target is route looping and not actually used by their alleged customer? Since the loop is actually between the FDC aggregation router and Cogent's backbone router. Also, what would the target IP have been in this case, since it was omitted? On Sep. 6 2019, at 11:06 pm, Ronald F. Guilmette wrote: > In message <23540.1567802066 at segfault.tristatelogic.com>, I wrote: > > > Is anyone disputing that 168.198.0.0/16 belongs to the Australian > > national government, or that AS174, Cogent was, until quite recently, > > routing that down to their pals at FDCServers who then were routing > > it down to their customer, Elad Cohen? If so, I ask that people look > > up this network in the RIPE Routing history tool and ALSO that folks > > have a look at, and explain, the following traceroute from August 23: > > > > https://pastebin.com/raw/2nJtbwjs > My apologies. In my furious haste, I botched that one URL. Here is the > correct file conatining my traceroute to 168.198.12.242 as performed by > me on August 23rd: > > https://pastebin.com/raw/TrLbGZuW > > Regards, > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From florianb at globalone.io Fri Sep 6 21:23:36 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Fri, 6 Sep 2019 23:23:36 +0200 Subject: Google DNS Oddity In-Reply-To: References: Message-ID: Where are you based? I can check if this can be replicated in our backbone, in case we have a PoP close. On Sep. 6 2019, at 11:17 pm, Nick Hilliard wrote: > Nick Hilliard wrote on 06/09/2019 21:19: > > Chip Marshall via NANOG wrote on 06/09/2019 20:11: > > > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com > > > from our > > > London datacenter, and I'm curious if other people are seeing the same > > > behavior. > > > > > > I saw a bunch of monitoring systems queries for www.google.com/A return > > back with no A records at ~20:35 BST. It's returned back to normal now, > > but we needed to flush a bunch of DNS caches. > > > ... aaaand there we go again at 22:07 BST. > Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoofer-info at caida.org Sun Sep 8 17:00:06 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Sun, 8 Sep 2019 10:00:06 -0700 Subject: Spoofer Report for NANOG for Aug 2019 Message-ID: <201909081700.x88H06aQ078227@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Aug 2019: ASN Name Fixed-By 4 ISI 2019-08-06 6939 HURRICANE 2019-08-10 7922 COMCAST-7922 2019-08-16 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Aug 2019: ASN Name First-Spoofed Last-Spoofed 7029 WINDSTREAM 2016-06-21 2019-08-23 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-08-28 6128 CABLE-NET-1 2016-09-03 2019-08-28 27364 ACS-INTERNET 2016-09-27 2019-08-30 20412 CLARITY-TELECOM 2016-09-30 2019-08-28 6181 FUSE-NET 2016-10-10 2019-08-31 25787 ROWE-NETWORKS 2016-10-21 2019-08-25 32440 LONI 2016-11-03 2019-08-29 12083 WOW-INTERNET 2016-11-09 2019-08-26 39939 RISE-CO-AS39939 2016-11-11 2019-08-27 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-08-28 9009 M247 2017-01-10 2019-08-26 21832 KELLINCOM-1 2017-02-03 2019-08-21 19624 SERVERROOM 2017-06-02 2019-08-27 63296 AMARILLO-WIRELESS 2017-09-01 2019-08-29 546 PARSONS-PGS-1 2017-11-20 2019-08-23 54540 INCERO 2018-01-15 2019-08-26 12222 AKAMAI 2018-02-14 2019-08-30 4201 ORST 2018-04-19 2019-08-28 11827 WSU 2018-05-07 2019-08-26 393564 SPOKANE 2018-06-05 2019-08-27 225 VIRGINIA 2018-06-18 2019-08-28 33452 RW 2018-09-19 2019-08-29 20448 VPNTRANET-LLC 2018-09-20 2019-08-26 393437 KLAYER 2018-12-21 2019-08-13 63275 RADIOWIRE 2019-02-07 2019-08-14 8047 GCI 2019-04-11 2019-08-30 10745 ARIN-ASH-CHA 2019-04-29 2019-08-29 6058 NORTHWESTEL-INC 2019-05-06 2019-08-07 6536 CITYNET 2019-05-15 2019-08-20 138576 2019-05-21 2019-08-10 33387 DATASHACK 2019-06-06 2019-08-16 16787 CHARTER-16787 2019-06-17 2019-08-26 210 WEST-NET-WEST 2019-08-04 2019-08-04 13760 SOUTHERN-LIGHT 2019-08-13 2019-08-13 32 STANFORD 2019-08-21 2019-08-29 54600 PEGTECHINC 2019-08-28 2019-08-28 26658 HENGTONG-IDC-LLC 2019-08-30 2019-08-30 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From warren at kumari.net Mon Sep 9 18:32:22 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 9 Sep 2019 14:32:22 -0400 Subject: Google DNS Oddity In-Reply-To: References: <201909061949.x86Jn8NG017406@nb.tech.org> Message-ID: Yes, this is no longer occurring / is resolved. Apologies, W On Mon, Sep 9, 2019 at 1:37 PM Florian Brandstetter via NANOG < nanog at nanog.org> wrote: > Unable to replicate this in London: > > ``` > ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> @ns1.google.com. > www.google.com. aaaa > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61970 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.google.com. IN AAAA > ;; ANSWER SECTION: > www.google.com. 300 IN AAAA 2a00:1450:4009:80d::2004 > ``` > > going by the latency, ns1.google.com > > travels to NL from our UK PoPs though: > > ``` > Host Loss% Snt Last Avg Best Wrst > StDev > 1. ??? > 2. ??? > 3. ae26-0.ebr01.lon3.uk.globalone 0.0% 13 2.1 6.2 1.0 45.7 > 12.9 > 4. 2001:7f8:4::3b41:1 0.0% 13 0.7 0.8 0.6 1.7 > 0.4 > 5. 2001:4860:0:1101::10 0.0% 13 0.7 2.7 0.7 14.2 > 4.2 > 6. 2001:4860::c:4000:cf5b 0.0% 13 1.8 2.1 1.5 4.0 > 0.7 > 7. 2001:4860::8:4000:d325 0.0% 13 8.6 7.3 6.6 9.5 > 0.9 > 8. 2001:4860::22:4001:70b 0.0% 13 6.4 9.5 6.4 36.9 > 8.3 > 9. 2001:4860:0:1::be7 23.1% 13 7.3 7.5 7.3 7.7 > 0.1 > 10. ??? > 11. ??? > 12. ??? > 13. ??? > 14. ??? > 15. ??? > 16. ??? > 17. ??? > 18. ??? > 19. ns1.google.com 0.0% 12 6.4 6.4 6.3 6.5 > 0.0 > ``` > On Sep. 6 2019, at 9:49 pm, Stephen Stuart wrote: > > Do you see the same behavior when you execute your dig query without > the trailing dot? > > Thanks, > Stephen > > On Sep 6, 2019, at 3:11 PM, Chip Marshall via NANOG > wrote: > > Hello, I'm seeing an oddity when doing DNS lookups for www.google.com > from our > London datacenter, and I'm curious if other people are seeing the same > behavior. > > It appears that when we ask for www.google.com. we sometimes get an answer > that only contains records for www-anycast.google.com., which our resolver > ignores as they don't match the query. > > As seen with dig: > > ``` > # dig @ns1.google.com. www.google.com. aaaa > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.google.com. www.google.com. aaaa > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42641 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.google.com. IN AAAA > > ;; ANSWER SECTION: > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:34::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:38::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:36::75 > www-anycast.google.com. 300 IN AAAA 2001:4860:4802:32::75 > > ;; Query time: 7 msec > ;; SERVER: 216.239.32.10#53(216.239.32.10) > ;; WHEN: Fri Sep 06 19:05:32 UTC 2019 > ;; MSG SIZE rcvd: 167 > ``` > > So far I've observed this with A and AAAA queries. It's my understanding > that > without a CNAME record in the answer, the resolver is doing the right > thing by > ignoring the answer, as there's no linkage between www and www-anycast. > > Is this broken, or is this just some weird DNS trick I've not come across > before? > > > You may want to post on dns-operations instead. > > Can you do a dig +trace www.google.com instead, that would be more > instructive about whatт€™s happening at each layer o > > f the delegation. > > > - Jared > > [image: Sent from Mailspring] -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Tue Sep 10 01:04:12 2019 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 9 Sep 2019 21:04:12 -0400 (EDT) Subject: rr.level3.net on autopilot? In-Reply-To: References: Message-ID: On Thu, 5 Sep 2019, Jon Lewis wrote: > I was doing some IRR clean-up and after a few successful updates, I'm no > longer able to alter or delete our objects in rr.level3.com. > > Emails to rpsl at level3.com result in no action and no response. I've tried > reaching out to the Level3 (Centurylink) NOC via email and phone, and can't > seem to find anyone who knows what rr.level3.com is, much less knows who to > talk to about troubleshooting. Anyone know who (if anyone) keeps the wheels > spinning on the Level3 IRR? I was going to post this morning that things are all sorted out. Centurylink's IP Admin reached out and worked with me to figure out the issue, which appears to have been that someone a few layers up from rpsl at level3.com cranked their spam filtering up to 11, resulting in all externally originated email getting eaten somewhere in their systems. Before posting, I ran one more test, and found that there's still something not quite right. We worked together again today, trying to figure it out, but ended up giving up for now. Mail from my personal system and from a Linux server at work both get delivered and processed properly. Mail from my work email Outlook/Microsoft/Mimecast gets delivered to Level3.com, but the IRRD system fails to find any objects in the body and responds that no object was found. Yes, it's being sent as plain text (Content-Type: text/plain; charset=UTF-8). Sending the same message from work to my personal address, then taking that, changing To: and playing the entire thing (all the headers + body) through sendmail -oi -t on a Linux server at work, it gets delivered and properly processed. So, anyone else who's had trouble the past 2 weeks getting anything processed by rpsl at level3.com, you should be able to at least get your messages delivered now. I'm curious if any other Office365/Outlook.com users have issues with rpsl at level3.com not finding any objects in your updates. If you're having that problem, resend your message via another mail system and see if that works for you too. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From will at loopfree.net Mon Sep 9 23:06:54 2019 From: will at loopfree.net (Will Orton) Date: Mon, 9 Sep 2019 16:06:54 -0700 Subject: Comcast route server not reflecting their reality Message-ID: <20190909230654.GA25249@tyranny.loopfree.net> I'm seeing odditiies when trying to traffic-engineering my way around an AS 3356-to-7922 performance issue. I buy transit from 3356 and announce my /19 to 3356. I set traffic engineering community 65000:7922 to supress announcement of it from 3356 to 7922. When I do that, at route-server.newyork.ny.ibone.comcast.net I see the AS-path for my /19 change from: 3356 to: 2914 which makes sense as I also have transit from 2914. So that's great, 7922 should be routing to me via 2914 or, any path not via 3356. But then if I go to a customer location on 7922's network, and traceroute to my /19, it still goes via 7922 3356 ! Is 7922's looking glass no longer reflecting actual route selection in their network? Does Comcast do traffic engineering that is not otherwise reflected at their looking glass? If I deaggregate my /19 and announce a /24 from it to 2914, I can draw the inbound traffic to me away from the 7922 3356 path. Which is not a real nice long-term solution... -Will From martijnschmidt at i3d.net Tue Sep 10 16:42:10 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Tue, 10 Sep 2019 16:42:10 +0000 Subject: Comcast route server not reflecting their reality In-Reply-To: <20190909230654.GA25249@tyranny.loopfree.net> References: <20190909230654.GA25249@tyranny.loopfree.net> Message-ID: Hi Will, Unlike AS2914 which purely interconnects with AS7922, it seems that AS3356 also has direct interconnections to the various Comcast subsidiary networks which are hidden from the DFZ through no-export communities.. I figured this out due to a routing leak which happened a few years ago: https://dyn.com/blog/widespread-impact-caused-by-level-3-bgp-route-leak/ Give it a shot with the following list of communities - that should swing your traffic away from the AS3356 links: 65000:7922 65000:7015 65000:7016 65000:7725 65000:13367 65000:20214 65000:22909 65000:33287 65000:33490 65000:33491 65000:33650 65000:33651 65000:33652 65000:33657 65000:33659 65000:33660 65000:33662 65000:33667 65000:33668 Best regards, Martijn Schmidt ________________________________ From: NANOG on behalf of Will Orton Sent: 10 September 2019 01:06 To: nanog at nanog.org Subject: Comcast route server not reflecting their reality I'm seeing odditiies when trying to traffic-engineering my way around an AS 3356-to-7922 performance issue. I buy transit from 3356 and announce my /19 to 3356. I set traffic engineering community 65000:7922 to supress announcement of it from 3356 to 7922. When I do that, at route-server.newyork.ny.ibone.comcast.net I see the AS-path for my /19 change from: 3356 to: 2914 which makes sense as I also have transit from 2914. So that's great, 7922 should be routing to me via 2914 or, any path not via 3356. But then if I go to a customer location on 7922's network, and traceroute to my /19, it still goes via 7922 3356 ! Is 7922's looking glass no longer reflecting actual route selection in their network? Does Comcast do traffic engineering that is not otherwise reflected at their looking glass? If I deaggregate my /19 and announce a /24 from it to 2914, I can draw the inbound traffic to me away from the 7922 3356 path. Which is not a real nice long-term solution... -Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed Sep 11 04:53:52 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 11 Sep 2019 00:53:52 -0400 (EDT) Subject: Bahamas: Hurricane Dorian recovery status Message-ID: Telecommunications and mobile services have been restored in about 90% of the Grand Bahama island area, however network capacity is still limited. Only about 10% of mobile and telecommunication service has been restored on the Abaco island. Over 60% of the housing and buildings on Abaco was destroyed. Four critical communications points have been established on Abaco for relief efforts. BTC and Aliv, the two major mobile providers in the Bahamas, have entered into a free roaming agreement for the next 30 days allowing customers to connect to either working cell towers without roaming charges. The Emergency Telecommunications Cluster partnered CISCO TacOps, Ericsson Response, NetHope, TSF and Vodafone Foundation are providing connectivity for humanitarian responders in four sites: - The Marsh Harbour port and international airport (set up by Ericsson Response, CISCO TacOps and WFP); - Maxwell Supermarket, used as the military EOC (set up by TSF); - A healthcare facility (set up by Vodafone Foundation). Equipment has been provided by the ETS partners on the ground as well as by Eutelsat and Hispasat ‒ and services by Inmarsat ‒ as part of the Crisis Connectivity Charter. From will at loopfree.net Tue Sep 10 20:17:12 2019 From: will at loopfree.net (Will Orton) Date: Tue, 10 Sep 2019 13:17:12 -0700 Subject: Comcast route server not reflecting their reality In-Reply-To: References: <20190909230654.GA25249@tyranny.loopfree.net> Message-ID: <20190910201712.GA1419@tyranny.loopfree.net> On Tue, Sep 10, 2019 at 04:42:10PM +0000, Martijn Schmidt wrote: > Hi Will, > > Unlike AS2914 which purely interconnects with AS7922, it seems that AS3356 also has direct interconnections to the various Comcast subsidiary networks which are hidden from the DFZ through no-export communities.. I figured this out due to a routing leak which happened a few years ago: https://dyn.com/blog/widespread-impact-caused-by-level-3-bgp-route-leak/ > > Give it a shot with the following list of communities - that should swing your traffic away from the AS3356 links: 65000:7922 65000:7015 65000:7016 65000:7725 65000:13367 65000:20214 65000:22909 65000:33287 65000:33490 65000:33491 65000:33650 65000:33651 65000:33652 65000:33657 65000:33659 65000:33660 65000:33662 65000:33667 65000:33668 > > Best regards, > Martijn Schmidt Thanks Martijn, That's the info I was missing. I have found I can now 65000:XXX or even 65001:XXX to 3356 with the Comcast regional network AS numbers and see the traffic jump to the 7922 network which has a different set of links to 3356, then I can further do 65001:7922 to get it off 3356 entirely if I need to. And I can find the specific regional AS# by checking the aforementioned Comcast route views server so it can be applied to only problem areas. I wish none of this was necessary but when you can't get >100mbit from a Comcast gigabit subscriber into 3356 then customers complain. -Will From ross at tajvar.io Wed Sep 11 16:29:58 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 11 Sep 2019 12:29:58 -0400 Subject: Comcast route server not reflecting their reality In-Reply-To: <20190910201712.GA1419@tyranny.loopfree.net> References: <20190909230654.GA25249@tyranny.loopfree.net> <20190910201712.GA1419@tyranny.loopfree.net> Message-ID: > > Unlike AS2914 which purely interconnects with AS7922, it seems that AS3356 > also has direct interconnections to the various Comcast subsidiary > networks which are hidden from the DFZ through no-export communities. I'm curious how this works and why it's done this way. I have a friend who has transit from AS7922 (the remote AS in his BGP sessions are all 7922), but CenturyLink's looking glass shows an AS path of "33657 " and includes the no-export community. Why is the AS path rewritten? What is the design here? -Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.jun at towardex.com Wed Sep 11 16:44:46 2019 From: james.jun at towardex.com (James Jun) Date: Wed, 11 Sep 2019 12:44:46 -0400 Subject: Comcast route server not reflecting their reality In-Reply-To: References: <20190909230654.GA25249@tyranny.loopfree.net> <20190910201712.GA1419@tyranny.loopfree.net> Message-ID: <20190911164445.GA8319@mis10.towardex.com> On Wed, Sep 11, 2019 at 12:29:58PM -0400, Ross Tajvar wrote: > > I'm curious how this works and why it's done this way. I have a friend who > has transit from AS7922 (the remote AS in his BGP sessions are all 7922), Are you sure your friend has transit from as7922? It sounds like your friend is buying from Comcast Enterprise (Ethernet Dedicated Internet), which places him on the regional CRAN network, not the 7922 national backbone (ibone). > but CenturyLink's looking glass shows an AS path of "33657 " and > includes the no-export community. Why is the AS path rewritten? What is the > design here? IIRC, Comcast uses "local-as 7922" path rewriting for all enterprise EDI customers running BGP off of regional CRANs, unless I'm mistaken. So if your regional CRAN is as7015 (for New England), even if your physical circuit and BGP session land on a local SUR in your area, you have to use remote-as 7922 to setup the session with Comcast ENS, regardless of the fact that actual peer's router is using as7015. What Level 3/CTL looking glass is showing ("33657 ") is most likely the true path reflecting of actual network topology behind the scenes. Your friend is connected to 33567/CRAN, not 7922/ibone. James From ross at tajvar.io Wed Sep 11 17:05:11 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 11 Sep 2019 13:05:11 -0400 Subject: Comcast route server not reflecting their reality In-Reply-To: <20190911164445.GA8319@mis10.towardex.com> References: <20190909230654.GA25249@tyranny.loopfree.net> <20190910201712.GA1419@tyranny.loopfree.net> <20190911164445.GA8319@mis10.towardex.com> Message-ID: > > IIRC, Comcast uses "local-as 7922" path rewriting for all enterprise EDI > customers > running BGP off of regional CRANs, unless I'm mistaken. So if your > regional CRAN > is as7015 (for New England), even if your physical circuit and BGP session > land > on a local SUR in your area, you have to use remote-as 7922 to setup the > session > with Comcast ENS, regardless of the fact that actual peer's router is > using as7015. > This totally makes sense, thanks for the explanation! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Sep 15 13:42:30 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 15 Sep 2019 08:42:30 -0500 (CDT) Subject: Geolocation\VPN Assistance In-Reply-To: <331447562.1377.1568553539622.JavaMail.mhammett@ThunderFuck> Message-ID: <1966007999.1407.1568554949228.JavaMail.mhammett@ThunderFuck> I'm building a page that has links and contact information for various IP geolocation services as well as contacts and links at companies that people often have issues with. There used to be a wiki page on CluePon that had some information, but that's been gone a few years. My intent is to direct people there whenever Netflix, Hulu, whatever says that they can't get content due to a country restriction... or a VPN restriction (if they're not using a VPN), etc. Then we don't have to rehash everything every time. BTW: This comes up a lot more often in different circles, more focused on eyeball ISPs. http://thebrotherswisp.com/index.php/geo-and-vpn/ Please provide OFFLIST constructive feedback and additions. Please note the, "This page is very incomplete and poorly organized. With time, hopefully, that gets corrected." ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From benlogan at myriverstreet.net Mon Sep 16 11:35:20 2019 From: benlogan at myriverstreet.net (Ben Logan) Date: Mon, 16 Sep 2019 07:35:20 -0400 Subject: Consistent routing policy? Message-ID: Hello, In reviewing our BGP routing policies last week, I realized that we are advertising our address space upstream in slightly different ways to our two upstream providers. For example, we might advertise a /21 to one provider and break that into two /22s when advertising it to the other. (The reason this was done was to help with traffic engineering--we'd prepend one of the /22s to help balance the traffic. Prepending the entire /21 might have been too much.) I'm just wondering if that's acceptable practice, or if we should advertise consistent prefixes between providers? Thanks, Ben -- Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan at myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net myriverstreet.net This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 16 11:47:17 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 16 Sep 2019 13:47:17 +0200 Subject: Consistent routing policy? In-Reply-To: References: Message-ID: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> On 16/Sep/19 13:35, Ben Logan wrote: > Hello, > > In reviewing our BGP routing policies last week, I realized that we > are advertising our address space upstream in slightly different ways > to our two upstream providers.  For example, we might advertise a /21 > to one provider and break that into two /22s when advertising it to > the other.  (The reason this was done was to help with traffic > engineering--we'd prepend one of the /22s to help balance the > traffic.  Prepending the entire /21 might have been too much.) > > I'm just wondering if that's acceptable practice, or if we should > advertise consistent prefixes between providers? While de-aggregating certainly puts pressure on the Internet, it's reasonably acceptable if done conservatively. What you are doing is acceptable, so it can be considered okay, particularly if your bandwidth purchases from your upstreams is not symmetric. Also, I recall prepending did have some material result as much as 10 years ago. I'm not sure whether it is as effective in 2019, considering how well peering has grown globally. From my side, since about 2012, it's a feature we haven't utilized in any way or form, even if we do currently offer it to our customers via a BGP community. YMMV... Mark. From benlogan at myriverstreet.net Mon Sep 16 12:47:53 2019 From: benlogan at myriverstreet.net (Ben Logan) Date: Mon, 16 Sep 2019 08:47:53 -0400 Subject: Consistent routing policy? In-Reply-To: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> Message-ID: Thanks, Mark. So the discrepancy between what's being advertised (/21 vs /22) shouldn't cause any issues? That's the part I got a bit confused about. I don't see how it would, but I wanted to make sure. Thanks, Ben On Mon, Sep 16, 2019 at 7:47 AM Mark Tinka wrote: > > > On 16/Sep/19 13:35, Ben Logan wrote: > > Hello, > > > > In reviewing our BGP routing policies last week, I realized that we > > are advertising our address space upstream in slightly different ways > > to our two upstream providers. For example, we might advertise a /21 > > to one provider and break that into two /22s when advertising it to > > the other. (The reason this was done was to help with traffic > > engineering--we'd prepend one of the /22s to help balance the > > traffic. Prepending the entire /21 might have been too much.) > > > > I'm just wondering if that's acceptable practice, or if we should > > advertise consistent prefixes between providers? > > While de-aggregating certainly puts pressure on the Internet, it's > reasonably acceptable if done conservatively. What you are doing is > acceptable, so it can be considered okay, particularly if your bandwidth > purchases from your upstreams is not symmetric. > > Also, I recall prepending did have some material result as much as 10 > years ago. I'm not sure whether it is as effective in 2019, considering > how well peering has grown globally. From my side, since about 2012, > it's a feature we haven't utilized in any way or form, even if we do > currently offer it to our customers via a BGP community. > > YMMV... > > Mark. > -- Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan at myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net myriverstreet.net This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 16 13:05:08 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 16 Sep 2019 15:05:08 +0200 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> Message-ID: <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> On 16/Sep/19 14:47, Ben Logan wrote: > Thanks, Mark.  So the discrepancy between what's being advertised (/21 > vs /22) shouldn't cause any issues?  That's the part I got a bit > confused about.  I don't see how it would, but I wanted to make sure. Longest match always wins... so provided your /22's are in the global table, traffic will follow the path toward them before the /21 is preferred. So, for example, if the upstream to whom you are sending the /21 doesn't do anything about how they learn the /22 from another source, (for their network) they will also send traffic back to you via the /22 path. This may or may not be preferred by you, or them. I suppose that's the main thing to think about. Mark. From noc at as37662.com Sun Sep 15 20:13:55 2019 From: noc at as37662.com (noc@as37662.com noc@as37662.com) Date: Sun, 15 Sep 2019 16:13:55 -0400 (EDT) Subject: Cogent sales reps who actually respond Message-ID: <1807845517.138566.1568578435406@privateemail.com> Hi fellow network operators, Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. Thanks Ruldu -------------- next part -------------- An HTML attachment was scrubbed... URL: From fohdeesha at gmail.com Mon Sep 16 13:30:48 2019 From: fohdeesha at gmail.com (Jon Sands) Date: Mon, 16 Sep 2019 09:30:48 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: <1807845517.138566.1568578435406@privateemail.com> References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> The last time I dealt with them, it took a little over 3 months to get them to turn up basic BGP service. To top it off the sales rep was fired in the middle of our deployment. Cogent seems to have higher rep turnover than anything else I've dealt with. Buckle up and have fun! On 9/15/2019 4:13 PM, noc at as37662.com noc at as37662.com wrote: > > Hi fellow network operators, > > Do any orgs here have experience with a good Cogent rep? The rep we > got via Cogent's website is unresponsive to even basic questions. It > feels like we are dealing with a bot and copy-pasted replies. > > Thanks > Ruldu > -- Jon Sands MFI Labs https://fohdeesha.com/ From shawnl at up.net Mon Sep 16 13:36:08 2019 From: shawnl at up.net (Shawn L) Date: Mon, 16 Sep 2019 09:36:08 -0400 (EDT) Subject: Cogent sales reps who actually respond In-Reply-To: <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> References: <1807845517.138566.1568578435406@privateemail.com> <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> Message-ID: <1568640968.44527852@upnet.mymailsrvr.com> I have one who calls me bi-weekly even though we have declined to purchase service from them at this time. I'd be happy to provide contact details off-line. -----Original Message----- From: "Jon Sands" Sent: Monday, September 16, 2019 9:30am To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond The last time I dealt with them, it took a little over 3 months to get them to turn up basic BGP service. To top it off the sales rep was fired in the middle of our deployment. Cogent seems to have higher rep turnover than anything else I've dealt with. Buckle up and have fun! On 9/15/2019 4:13 PM, noc at as37662.com noc at as37662.com wrote: > > Hi fellow network operators, > > Do any orgs here have experience with a good Cogent rep? The rep we > got via Cogent's website is unresponsive to even basic questions. It > feels like we are dealing with a bot and copy-pasted replies. > > Thanks > Ruldu > -- Jon Sands MFI Labs https://fohdeesha.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Mon Sep 16 13:38:01 2019 From: ben at 6by7.net (Ben Cannon) Date: Mon, 16 Sep 2019 06:38:01 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <1807845517.138566.1568578435406@privateemail.com> References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: <3F4AC1D3-6802-4B04-827B-D22F75678B5D@6by7.net> Actually yes, I have a few great contacts over there these days. Very different company from years back. -Ben. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Sep 15, 2019, at 1:13 PM, noc at as37662.com noc at as37662.com wrote: > > Hi fellow network operators, > > Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. > > Thanks > Ruldu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuenzler at init7.net Mon Sep 16 13:42:00 2019 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 16 Sep 2019 15:42:00 +0200 Subject: Cogent sales reps who actually respond In-Reply-To: <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> References: <1807845517.138566.1568578435406@privateemail.com> <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> Message-ID: When they do their cold calls I tend to answer «Call again in 6 months, if you are still with Cogent then.» Most sales reps don‘t survive that long. #SCNR -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/ > Am 16.09.2019 um 15:30 schrieb Jon Sands : > > The last time I dealt with them, it took a little over 3 months to get them to turn up basic BGP service. To top it off the sales rep was fired in the middle of our deployment. Cogent seems to have higher rep turnover than anything else I've dealt with. Buckle up and have fun! > >> On 9/15/2019 4:13 PM, noc at as37662.com noc at as37662.com wrote: >> >> Hi fellow network operators, >> >> Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. >> >> Thanks >> Ruldu >> > > -- > Jon Sands > MFI Labs > https://fohdeesha.com/ > From msa at latt.net Mon Sep 16 13:47:14 2019 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 16 Sep 2019 09:47:14 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: <1807845517.138566.1568578435406@privateemail.com> References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: <20190916134714.GB3739606@puck.nether.net> On Sun, Sep 15, 2019 at 04:13:55PM -0400, noc at as37662.com noc at as37662.com wrote: > Do any orgs here have experience with a good Cogent rep? The rep we got > via Cogent's website is unresponsive to even basic questions. It feels > like we are dealing with a bot and copy-pasted replies. Just put your real phone number in WHOIS and wait. --msa From kuenzler at init7.net Mon Sep 16 13:42:00 2019 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 16 Sep 2019 15:42:00 +0200 Subject: Cogent sales reps who actually respond In-Reply-To: <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> References: <1807845517.138566.1568578435406@privateemail.com> <172a8c7a-5015-f138-a96e-752cedebd6b1@gmail.com> Message-ID: When they do their cold calls I tend to answer «Call again in 6 months, if you are still with Cogent then.» Most sales reps don‘t survive that long. #SCNR -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/ > Am 16.09.2019 um 15:30 schrieb Jon Sands : > > The last time I dealt with them, it took a little over 3 months to get them to turn up basic BGP service. To top it off the sales rep was fired in the middle of our deployment. Cogent seems to have higher rep turnover than anything else I've dealt with. Buckle up and have fun! > >> On 9/15/2019 4:13 PM, noc at as37662.com noc at as37662.com wrote: >> >> Hi fellow network operators, >> >> Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. >> >> Thanks >> Ruldu >> > > -- > Jon Sands > MFI Labs > https://fohdeesha.com/ > From benlogan at myriverstreet.net Mon Sep 16 14:12:08 2019 From: benlogan at myriverstreet.net (Ben Logan) Date: Mon, 16 Sep 2019 10:12:08 -0400 Subject: Consistent routing policy? In-Reply-To: <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: Thanks, Mark, that makes sense. Take care, Ben On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka wrote: > > > On 16/Sep/19 14:47, Ben Logan wrote: > > Thanks, Mark. So the discrepancy between what's being advertised (/21 > > vs /22) shouldn't cause any issues? That's the part I got a bit > > confused about. I don't see how it would, but I wanted to make sure. > > Longest match always wins... so provided your /22's are in the global > table, traffic will follow the path toward them before the /21 is > preferred. > > So, for example, if the upstream to whom you are sending the /21 doesn't > do anything about how they learn the /22 from another source, (for their > network) they will also send traffic back to you via the /22 path. This > may or may not be preferred by you, or them. I suppose that's the main > thing to think about. > > Mark. > -- Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan at myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net myriverstreet.net This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Mon Sep 16 14:24:02 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Mon, 16 Sep 2019 14:24:02 +0000 Subject: Consistent routing policy? In-Reply-To: <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: Hi Ben, Prefix deaggregation and inconsistent announcements might work fine in the US where all paths are mostly of equal quality, but is the bane of my existence when it happens in regions like the Middle East or Africa where one transit used by a target ISP might be connected locally and the other connected in Europe. If you want to steer traffic you may be better off using BGP action communities, I'll leave you with this excellent presentation from RAS to provide some background on what might be achieved with that: https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Best regards, Martijn On 9/16/19 3:05 PM, Mark Tinka wrote: > > On 16/Sep/19 14:47, Ben Logan wrote: >> Thanks, Mark.  So the discrepancy between what's being advertised (/21 >> vs /22) shouldn't cause any issues?  That's the part I got a bit >> confused about.  I don't see how it would, but I wanted to make sure. > Longest match always wins... so provided your /22's are in the global > table, traffic will follow the path toward them before the /21 is preferred. > > So, for example, if the upstream to whom you are sending the /21 doesn't > do anything about how they learn the /22 from another source, (for their > network) they will also send traffic back to you via the /22 path. This > may or may not be preferred by you, or them. I suppose that's the main > thing to think about. > > Mark. From josh at imaginenetworksllc.com Mon Sep 16 15:40:52 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 16 Sep 2019 11:40:52 -0400 Subject: Geolocation\VPN Assistance In-Reply-To: <1966007999.1407.1568554949228.JavaMail.mhammett@ThunderFuck> References: <331447562.1377.1568553539622.JavaMail.mhammett@ThunderFuck> <1966007999.1407.1568554949228.JavaMail.mhammett@ThunderFuck> Message-ID: Regarding Netflix... geosupport at netflix.com are the right folks to help you with this. In the unlikely event that doesn't get you what you need, or if you otherwise need to reach someone at Netflix on the CDN side, please use cdnetops at netflix.com Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Sep 15, 2019 at 9:43 AM Mike Hammett wrote: > I'm building a page that has links and contact information for various IP > geolocation services as well as contacts and links at companies that people > often have issues with. There used to be a wiki page on CluePon that had > some information, but that's been gone a few years. My intent is to direct > people there whenever Netflix, Hulu, whatever says that they can't get > content due to a country restriction... or a VPN restriction (if they're > not using a VPN), etc. Then we don't have to rehash everything every time. > BTW: This comes up a lot more often in different circles, more focused on > eyeball ISPs. > > http://thebrotherswisp.com/index.php/geo-and-vpn/ > > Please provide OFFLIST constructive feedback and additions. Please note > the, "This page is very incomplete and poorly organized. With time, > hopefully, that gets corrected." > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Mon Sep 16 15:42:34 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 16 Sep 2019 11:42:34 -0400 Subject: Geolocation\VPN Assistance In-Reply-To: References: <331447562.1377.1568553539622.JavaMail.mhammett@ThunderFuck> <1966007999.1407.1568554949228.JavaMail.mhammett@ThunderFuck> Message-ID: Found one on Hulu... supportrequest at hulu.com Looks like last October mehmet at akcin.net should have emailed you some Hulu information offlist. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Sep 16, 2019 at 11:40 AM Josh Luthman wrote: > Regarding Netflix... > > geosupport at netflix.com are the right folks to help you with this. > > In the unlikely event that doesn't get you what you need, or if you > otherwise need to reach someone at Netflix on the CDN side, please use > cdnetops at netflix.com > > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Sun, Sep 15, 2019 at 9:43 AM Mike Hammett wrote: > >> I'm building a page that has links and contact information for various IP >> geolocation services as well as contacts and links at companies that people >> often have issues with. There used to be a wiki page on CluePon that had >> some information, but that's been gone a few years. My intent is to direct >> people there whenever Netflix, Hulu, whatever says that they can't get >> content due to a country restriction... or a VPN restriction (if they're >> not using a VPN), etc. Then we don't have to rehash everything every time. >> BTW: This comes up a lot more often in different circles, more focused on >> eyeball ISPs. >> >> http://thebrotherswisp.com/index.php/geo-and-vpn/ >> >> Please provide OFFLIST constructive feedback and additions. Please note >> the, "This page is very incomplete and poorly organized. With time, >> hopefully, that gets corrected." >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariev at vayner.net Mon Sep 16 15:26:26 2019 From: ariev at vayner.net (Arie Vayner) Date: Mon, 16 Sep 2019 08:26:26 -0700 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: Ben, To make it a bit cleaner, you most likely want to send your aggregate (/21) to all service providers, and then if you choose to deaggregate and create more specific advertisements for traffic engineering purposes, you just advertise the relevant longer prefixes (/22's for example) on the specific uplink you want the traffic to return on. So for example, let's say you have a /21, and you want to split the traffic across 2x /22's, you advertise the /21 on both ISP links, and a single (different) /22 on each ISP link. This way the more specific route (/22) will pull the traffic towards the ISP that is advertising it, but in case of a failure on one of those links, you still have the /21 aggregate that will pull all the traffic to the other link. This should generally work, but may have strange edge cases, especially when ISPs do their own (not necessarily standard) traffic engineering. For example ISP A, getting a /21 could set the local preference for that /21 higher than other peers (where they would be learning your other /22), so traffic originating from this local ISP would take the local path regardless of your policy. This is when you will have to start looking at their BGP communities... Tnx Arie On Mon, Sep 16, 2019 at 7:13 AM Ben Logan wrote: > Thanks, Mark, that makes sense. > > Take care, > Ben > > On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka wrote: > >> >> >> On 16/Sep/19 14:47, Ben Logan wrote: >> > Thanks, Mark. So the discrepancy between what's being advertised (/21 >> > vs /22) shouldn't cause any issues? That's the part I got a bit >> > confused about. I don't see how it would, but I wanted to make sure. >> >> Longest match always wins... so provided your /22's are in the global >> table, traffic will follow the path toward them before the /21 is >> preferred. >> >> So, for example, if the upstream to whom you are sending the /21 doesn't >> do anything about how they learn the /22 from another source, (for their >> network) they will also send traffic back to you via the /22 path. This >> may or may not be preferred by you, or them. I suppose that's the main >> thing to think about. >> >> Mark. >> > > > -- > > Ben Logan > Senior Network Engineer | Working Lead > Wilkes Communications | RiverStreet Networks > > Address: 1400 River St Wilkesboro, NC 28697 > Email: benlogan at myriverstreet.net > Phone: 336-973-9075 > Mobile: 336-452-8072 > wilkes.net > myriverstreet.net > > > > > > > > This email transmission contains information which may be confidential > and/or privileged. The information is intended to be for the use of the > individual or entity named on this transmission. If you are not the > intended recipient, be aware that any disclosure, copying, distribution or > use of the contents of this email information is prohibited. If you have > received this email in error, please notify the sender to arrange for > retrieval of the original documents. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 16 16:19:12 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Sep 2019 09:19:12 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <1807845517.138566.1568578435406@privateemail.com> References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: Given their practice of harvesting whois updates in order to spam newly acquired AS contacts, any time it is my decision, Cogent is ineligible as a vendor. I’ve had no trouble getting their reps to respond when the decision has come from above, but I prefer to avoid doing business with them. Owen > On Sep 15, 2019, at 13:13 , noc at as37662.com noc at as37662.com wrote: > > Hi fellow network operators, > > Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. > > Thanks > Ruldu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manager at monmouth.com Mon Sep 16 16:32:03 2019 From: manager at monmouth.com (Mark Stevens) Date: Mon, 16 Sep 2019 12:32:03 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: Probably going to shoot myself in the foot but we have been with Cogent for 14 years and I have nothing but praise for their Service,  NOC and my Sales Rep who is top notch. As usual, everyone's mileage will vary but it seems I am on the luckier side in having this good experience with Cogent as opposed to others on this list. Mark On 9/16/2019 12:19 PM, Owen DeLong wrote: > Given their practice of harvesting whois updates in order to spam > newly acquired AS contacts, any time it is my decision, Cogent is > ineligible as a vendor. > > I’ve had no trouble getting their reps to respond when the decision > has come from above, but I prefer to avoid doing business with them. > > Owen > > >> On Sep 15, 2019, at 13:13 , noc at as37662.com >> noc at as37662.com > > wrote: >> >> Hi fellow network operators, >> >> Do any orgs here have experience with a good Cogent rep? The rep we >> got via Cogent's website is unresponsive to even basic questions. It >> feels like we are dealing with a bot and copy-pasted replies. >> >> Thanks >> Ruldu >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Mon Sep 16 16:35:48 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 16 Sep 2019 16:35:48 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: <1807845517.138566.1568578435406@privateemail.com> Message-ID: <06D75AE5-A47B-4A2A-85C1-B60C334AEDF5@dino.hostasaurus.com> Our sales rep has been great, but unfortunately, for him, every time he calls and I ask if Cogent is going to get me IPv6 transit to Google, he has to say no, and then I tell him I can’t purchase any more circuits. From: NANOG on behalf of Owen DeLong Date: Monday, September 16, 2019 at 9:20 AM To: "noc at as37662.com noc at as37662.com" Cc: "nanog at nanog.org" Subject: Re: Cogent sales reps who actually respond Given their practice of harvesting whois updates in order to spam newly acquired AS contacts, any time it is my decision, Cogent is ineligible as a vendor. I’ve had no trouble getting their reps to respond when the decision has come from above, but I prefer to avoid doing business with them. Owen On Sep 15, 2019, at 13:13 , noc at as37662.com noc at as37662.com > wrote: Hi fellow network operators, Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. Thanks Ruldu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Mon Sep 16 17:13:24 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 16 Sep 2019 13:13:24 -0400 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: > > https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf > Don’t let anyone send you Informational tags, these should only be set by > you, and you should strip them from all BGP neighbors (customers, transits, > peers, etc). Otherwise you have a massive security problem. I often see informational tags propagated through multiple ASes. What is the security risk there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Mon Sep 16 17:19:09 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 16 Sep 2019 19:19:09 +0200 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: <20190916171909.GB30112@jima.tpb.net> >> https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf >>Don’t let anyone send you Informational tags, these should only be >>set by you, and you should strip them from all BGP neighbors >>(customers, transits, peers, etc). Otherwise you have a massive >>security problem. * ross at tajvar.io (Ross Tajvar) [Mon 16 Sep 2019, 19:14 CEST]: >I often see informational tags propagated through multiple ASes. >What is the security risk there? Don't let anyone send you *your* informational tags. -- Niels. From ximaera at gmail.com Mon Sep 16 18:26:33 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 16 Sep 2019 11:26:33 -0700 Subject: Consistent routing policy? In-Reply-To: <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: Peace, On Mon, Sep 16, 2019, 6:06 AM Mark Tinka wrote: > Longest match always wins... so provided your /22's are in the global > table, traffic will follow the path toward them before the /21 is > preferred. > Not always. E.g. imagine an ISP who has two connections to the outside world: one through a major ISP and the other through an IX. Such an ISP would be quite inclined both financially and technically to import routes just from the IX and set the default to the upstream ISP link. Therefore, an advertisement from the IX would always win no matter the length. There are more complicated cases as well. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 16 19:04:08 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Sep 2019 12:04:08 -0700 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: For any router which receives both announcements, longest match always wins over all other BGP tie-breaking criteria. This is almost always summarized as “Longest Match always wins” because virtually any engineer recognizes that the winner is selected only from the available contestants, not from unknown distant contestants not present at the router in question. Owen > On Sep 16, 2019, at 11:26 , Töma Gavrichenkov wrote: > > Peace, > > On Mon, Sep 16, 2019, 6:06 AM Mark Tinka > wrote: > Longest match always wins... so provided your /22's are in the global > table, traffic will follow the path toward them before the /21 is preferred. > > Not always. > > E.g. imagine an ISP who has two connections to the outside world: one through a major ISP and the other through an IX. > > Such an ISP would be quite inclined both financially and technically to import routes just from the IX and set the default to the upstream ISP link. Therefore, an advertisement from the IX would always win no matter the length. > > There are more complicated cases as well. > > -- > Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Mon Sep 16 19:06:24 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 16 Sep 2019 19:06:24 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: <06D75AE5-A47B-4A2A-85C1-B60C334AEDF5@dino.hostasaurus.com> References: <1807845517.138566.1568578435406@privateemail.com> <06D75AE5-A47B-4A2A-85C1-B60C334AEDF5@dino.hostasaurus.com> Message-ID: This last comment made me laugh out loud…. >>> Our sales rep has been great, but unfortunately, for him, every time he calls and I ask if Cogent is going to get me IPv6 transit to Google, he has to say no, and then I tell him I can’t purchase any more circuits. From: NANOG On Behalf Of David Hubbard Sent: Monday, September 16, 2019 11:36 AM To: noc at as37662.com noc at as37662.com ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond Our sales rep has been great, but unfortunately, for him, every time he calls and I ask if Cogent is going to get me IPv6 transit to Google, he has to say no, and then I tell him I can’t purchase any more circuits. From: NANOG > on behalf of Owen DeLong > Date: Monday, September 16, 2019 at 9:20 AM To: "noc at as37662.com noc at as37662.com" > Cc: "nanog at nanog.org" > Subject: Re: Cogent sales reps who actually respond Given their practice of harvesting whois updates in order to spam newly acquired AS contacts, any time it is my decision, Cogent is ineligible as a vendor. I’ve had no trouble getting their reps to respond when the decision has come from above, but I prefer to avoid doing business with them. Owen On Sep 15, 2019, at 13:13 , noc at as37662.com noc at as37662.com > wrote: Hi fellow network operators, Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. Thanks Ruldu ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Mon Sep 16 19:55:55 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 16 Sep 2019 12:55:55 -0700 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: Peace, On Mon, Sep 16, 2019, 12:04 PM Owen DeLong wrote: > For any router which receives both announcements, longest match always > wins over all other BGP tie-breaking criteria. > > This is almost always summarized as “Longest Match always wins” because > virtually any engineer recognizes that the > winner is selected only from the available contestants, not from unknown > distant contestants not present at the router > in question. > The point is that you must expect inbound traffic to any prefix you advertise to the outside world, even a more specific announcement is also being advertised. There are legitimate circumstances where an ISP would prefer the super-block. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Mon Sep 16 20:53:40 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 16 Sep 2019 13:53:40 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: Message-ID: <40843.1568667220@segfault.tristatelogic.com> In message , Owen DeLong wrote: >Given their practice of harvesting whois updates in order to spam newly >acquired AS contacts, any time it is my decision, Cogent is ineligible >as a vendor. So I guess then that their aiding and abetting of fraud and IP block theft, as I documented here recently, is an entirely secondary concern... as long as they don't spam you, yes? Regards, rfg From mike.lyon at gmail.com Mon Sep 16 20:59:55 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 16 Sep 2019 13:59:55 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <40843.1568667220@segfault.tristatelogic.com> References: <40843.1568667220@segfault.tristatelogic.com> Message-ID: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. -Mike > On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: > > In message , > Owen DeLong wrote: > >> Given their practice of harvesting whois updates in order to spam newly >> acquired AS contacts, any time it is my decision, Cogent is ineligible >> as a vendor. > > So I guess then that their aiding and abetting of fraud and IP block > theft, as I documented here recently, is an entirely secondary concern... > as long as they don't spam you, yes? > > > Regards, > rfg From dhubbard at dino.hostasaurus.com Mon Sep 16 21:50:18 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 16 Sep 2019 21:50:18 +0000 Subject: Security alert aggregator? Message-ID: <970951DE-A1EE-45F4-84F4-175739AC3618@dino.hostasaurus.com> Curious if anyone knows of a security alert aggregation service? For example, go and plug in all the various vendors hardware and software packages your enterprise uses, and then the service subscribes to all the random RSS feeds, CVE lists, vendor mailing lists, etc. to feed you the data instead of needing staff to write something custom, and then have checks to ensure the custom thing is still pulling from the right location, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at joelwhitehouse.com Mon Sep 16 22:22:31 2019 From: code at joelwhitehouse.com (Joel Whitehouse) Date: Mon, 16 Sep 2019 17:22:31 -0500 Subject: Security alert aggregator? In-Reply-To: <970951DE-A1EE-45F4-84F4-175739AC3618@dino.hostasaurus.com> References: <970951DE-A1EE-45F4-84F4-175739AC3618@dino.hostasaurus.com> Message-ID: <3b9b0ba2-7401-e061-cd9a-ea70c9755e6d@joelwhitehouse.com> On 9/16/19 4:50 PM, David Hubbard wrote: > Curious if anyone knows of a security alert aggregation service?  For > example, go and plug in all the various vendors hardware and software > packages your enterprise uses, and then the service subscribes to all > the random RSS feeds, CVE lists, vendor mailing lists, etc. to feed you > the data instead of needing staff to write something custom, and then > have checks to ensure the custom thing is still pulling from the right > location, etc. > > Thanks > There's always the US CERT Bulletins, which aggregate CVEs into a handy list and is published as an RSS feed: https://www.us-cert.gov/ncas/bulletins -- Joel Whitehouse Software Developer +1.319.521.7762 From stephen.myspam at gmail.com Mon Sep 16 22:59:18 2019 From: stephen.myspam at gmail.com (Stephen M.) Date: Mon, 16 Sep 2019 23:59:18 +0100 Subject: Cogent sales reps who actually respond In-Reply-To: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. If you like Cogent - explain. If you don’t like Cogent - explain. Cheers, Stephen //please pardon any brevities - sent from mobile// > On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: > > Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” > > I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. > > -Mike > >>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: >>> >>> In message , >>> Owen DeLong wrote: >>> >>> Given their practice of harvesting whois updates in order to spam newly >>> acquired AS contacts, any time it is my decision, Cogent is ineligible >>> as a vendor. >> >> So I guess then that their aiding and abetting of fraud and IP block >> theft, as I documented here recently, is an entirely secondary concern... >> as long as they don't spam you, yes? >> >> >> Regards, >> rfg From creynolds at tsieda.com Mon Sep 16 22:06:23 2019 From: creynolds at tsieda.com (Chuck Reynolds) Date: Mon, 16 Sep 2019 18:06:23 -0400 Subject: Security alert aggregator? In-Reply-To: <970951DE-A1EE-45F4-84F4-175739AC3618@dino.hostasaurus.com> References: <970951DE-A1EE-45F4-84F4-175739AC3618@dino.hostasaurus.com> Message-ID: <54119D7A-19C6-44BD-9792-BFE99CCF0D72@tsieda.com> Yes. Please contact me offline. There are a few different ones to recommend based on your needs Sent from my iPhone > On Sep 16, 2019, at 5:50 PM, David Hubbard wrote: > > Curious if anyone knows of a security alert aggregation service? For example, go and plug in all the various vendors hardware and software packages your enterprise uses, and then the service subscribes to all the random RSS feeds, CVE lists, vendor mailing lists, etc. to feed you the data instead of needing staff to write something custom, and then have checks to ensure the custom thing is still pulling from the right location, etc. > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Mon Sep 16 23:21:37 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 16 Sep 2019 16:21:37 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> The argument has been listed numerous times so i didn’t want to bore people: 1. Sprint peering battle. Google it 2. He.net peering battle. Google it. 3. Google IPv6 peering battle. Google it. All of which point to them being pompous assholes. They also run their links hot which create latency for anything flowing through it. Cheers, Mike > On Sep 16, 2019, at 15:59, Stephen M. wrote: > > Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. > > If you like Cogent - explain. > If you don’t like Cogent - explain. > > Cheers, > Stephen > > //please pardon any brevities - sent from mobile// > >> On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: >> >> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” >> >> I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. >> >> -Mike >> >>>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: >>>> >>>> In message , >>>> Owen DeLong wrote: >>>> >>>> Given their practice of harvesting whois updates in order to spam newly >>>> acquired AS contacts, any time it is my decision, Cogent is ineligible >>>> as a vendor. >>> >>> So I guess then that their aiding and abetting of fraud and IP block >>> theft, as I documented here recently, is an entirely secondary concern... >>> as long as they don't spam you, yes? >>> >>> >>> Regards, >>> rfg From owen at delong.com Tue Sep 17 00:21:36 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Sep 2019 17:21:36 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: > On Sep 16, 2019, at 16:21 , Mike Lyon wrote: > > The argument has been listed numerous times so i didn’t want to bore people: > > 1. Sprint peering battle. Google it Amusingly in this particular case, I’d say SPRINT started it as SPRINT was the original "we’re too arrogant to peer with you, buy from us” company. > 2. He.net peering battle. Google it. > 3. Google IPv6 peering battle. Google it. > > All of which point to them being pompous assholes. You left out (as I mentioned earlier) persistent abuse and violation of ARIN WHOIS TOS/AUP. > They also run their links hot which create latency for anything flowing through it. They seem to have been doing a little bit less of this lately, though… They are extremely slow to add capacity to existing PNIs when they start to congest. Owen From michel.py at tsisemi.com Tue Sep 17 00:23:13 2019 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 17 Sep 2019 00:23:13 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: > If you don’t like Cogent - explain. Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. They abuse whois. They are one of the primary reasons few people put their real phone number in whois. And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From nanog at ics-il.net Tue Sep 17 00:29:20 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 16 Sep 2019 19:29:20 -0500 (CDT) Subject: Cogent sales reps who actually respond In-Reply-To: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: <415331117.2443.1568680155789.JavaMail.mhammett@ThunderFuck> Regarding the latency, it looks like Cogent isn't much worse than anyone else. When they are bad, there's typically someone else bad there with them. https://www.noction.com/wp-content/uploads/2019/09/TIER1-AUG-2019.pdf ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mike Lyon" To: "Stephen M." Cc: nanog at nanog.org Sent: Monday, September 16, 2019 6:21:37 PM Subject: Re: Cogent sales reps who actually respond The argument has been listed numerous times so i didn’t want to bore people: 1. Sprint peering battle. Google it 2. He.net peering battle. Google it. 3. Google IPv6 peering battle. Google it. All of which point to them being pompous assholes. They also run their links hot which create latency for anything flowing through it. Cheers, Mike > On Sep 16, 2019, at 15:59, Stephen M. wrote: > > Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. > > If you like Cogent - explain. > If you don’t like Cogent - explain. > > Cheers, > Stephen > > //please pardon any brevities - sent from mobile// > >> On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: >> >> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” >> >> I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. >> >> -Mike >> >>>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: >>>> >>>> In message , >>>> Owen DeLong wrote: >>>> >>>> Given their practice of harvesting whois updates in order to spam newly >>>> acquired AS contacts, any time it is my decision, Cogent is ineligible >>>> as a vendor. >>> >>> So I guess then that their aiding and abetting of fraud and IP block >>> theft, as I documented here recently, is an entirely secondary concern... >>> as long as they don't spam you, yes? >>> >>> >>> Regards, >>> rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Sep 17 00:48:27 2019 From: randy at psg.com (Randy Bush) Date: Mon, 16 Sep 2019 17:48:27 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: > 1. Sprint peering battle. Google it > 2. He.net peering battle. Google it. > 3. Google IPv6 peering battle. Google it. > > All of which point to them being pompous assholes. or point to them treating ipv6 the same as ipv4 when it comes to peering, tech, ... we are supposed to think ipv6 parity is a good thing. randy From ross at tajvar.io Tue Sep 17 00:53:11 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 16 Sep 2019 20:53:11 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: > > > 1. Sprint peering battle. Google it > > 2. He.net peering battle. Google it. > > 3. Google IPv6 peering battle. Google it. > > > > All of which point to them being pompous assholes. > > or point to them treating ipv6 the same as ipv4 when it comes to > peering, tech, ... we are supposed to think ipv6 parity is a good > thing. > Can you elaborate on this? What are they doing/not doing that you take issue with? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Sep 17 01:01:20 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 16 Sep 2019 21:01:20 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: Ah, sorry, I didn't understand your message. Nevermind. On Mon, Sep 16, 2019 at 8:53 PM Ross Tajvar wrote: > > 1. Sprint peering battle. Google it >> > 2. He.net peering battle. Google it. >> > 3. Google IPv6 peering battle. Google it. >> > >> > All of which point to them being pompous assholes. >> >> or point to them treating ipv6 the same as ipv4 when it comes to >> peering, tech, ... we are supposed to think ipv6 parity is a good >> thing. >> > > Can you elaborate on this? What are they doing/not doing that you take > issue with? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Sep 17 01:04:43 2019 From: randy at psg.com (Randy Bush) Date: Mon, 16 Sep 2019 18:04:43 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: >>> 1. Sprint peering battle. Google it >>> 2. He.net peering battle. Google it. >>> 3. Google IPv6 peering battle. Google it. >>> >>> All of which point to them being pompous assholes. >> >> or point to them treating ipv6 the same as ipv4 when it comes to >> peering, tech, ... we are supposed to think ipv6 parity is a good >> thing. > > Can you elaborate on this? What are they doing/not doing that you take > issue with? i am not taking issue; the opposite. cogent says that it peers v6 if and only if you are a v4 peer. some folk seem to think v6 peering should more more promiscuous. they are entitled to their opinions :) From ben at 6by7.net Tue Sep 17 01:44:35 2019 From: ben at 6by7.net (Ben Cannon) Date: Mon, 16 Sep 2019 18:44:35 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: <80866A43-9614-488F-AB11-71E4F5C0F785@6by7.net> “They also run their links hot which create latency for anything flowing through it.” Mike, I’d have agreed with you - 15 years ago. Is this current at all? My views on Cogent have evolved dramatically over the years. How recent is your data? -Ben > On Sep 16, 2019, at 4:21 PM, Mike Lyon wrote: > > The argument has been listed numerous times so i didn’t want to bore people: > > 1. Sprint peering battle. Google it > 2. He.net peering battle. Google it. > 3. Google IPv6 peering battle. Google it. > > All of which point to them being pompous assholes. > > They also run their links hot which create latency for anything flowing through it. > > Cheers, > Mike > >> On Sep 16, 2019, at 15:59, Stephen M. wrote: >> >> Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. >> >> If you like Cogent - explain. >> If you don’t like Cogent - explain. >> >> Cheers, >> Stephen >> >> //please pardon any brevities - sent from mobile// >> >>> On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: >>> >>> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” >>> >>> I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. >>> >>> -Mike >>> >>>>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: >>>>> >>>>> In message , >>>>> Owen DeLong wrote: >>>>> >>>>> Given their practice of harvesting whois updates in order to spam newly >>>>> acquired AS contacts, any time it is my decision, Cogent is ineligible >>>>> as a vendor. >>>> >>>> So I guess then that their aiding and abetting of fraud and IP block >>>> theft, as I documented here recently, is an entirely secondary concern... >>>> as long as they don't spam you, yes? >>>> >>>> >>>> Regards, >>>> rfg From morrowc.lists at gmail.com Tue Sep 17 01:58:35 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 16 Sep 2019 21:58:35 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: <80866A43-9614-488F-AB11-71E4F5C0F785@6by7.net> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> <80866A43-9614-488F-AB11-71E4F5C0F785@6by7.net> Message-ID: On Mon, Sep 16, 2019 at 9:45 PM Ben Cannon wrote: > > “They also run their links hot which create latency for anything flowing through it.” > > Mike, I’d have agreed with you - 15 years ago. Is this current at all? My views on Cogent have evolved dramatically over the years. How recent is your data? > isn't any decision about any provider generally: "Will they carry my bits reliably, and on a path 'short enough' for my requirements, at a cost I'm willing to pay?" Whether cogent, telia, ntt, l3, all carriers have their issues in certain places... some are the only path to certain other things. Would you rather deal with a third party's ideas of customer-service and upgrade/capacity augment? or would you rather be able to do that directly? (for instance) > -Ben > > > On Sep 16, 2019, at 4:21 PM, Mike Lyon wrote: > > > > The argument has been listed numerous times so i didn’t want to bore people: > > > > 1. Sprint peering battle. Google it > > 2. He.net peering battle. Google it. > > 3. Google IPv6 peering battle. Google it. > > > > All of which point to them being pompous assholes. > > > > They also run their links hot which create latency for anything flowing through it. > > > > Cheers, > > Mike > > > >> On Sep 16, 2019, at 15:59, Stephen M. wrote: > >> > >> Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. > >> > >> If you like Cogent - explain. > >> If you don’t like Cogent - explain. > >> > >> Cheers, > >> Stephen > >> > >> //please pardon any brevities - sent from mobile// > >> > >>> On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: > >>> > >>> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” > >>> > >>> I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. > >>> > >>> -Mike > >>> > >>>>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: > >>>>> > >>>>> In message , > >>>>> Owen DeLong wrote: > >>>>> > >>>>> Given their practice of harvesting whois updates in order to spam newly > >>>>> acquired AS contacts, any time it is my decision, Cogent is ineligible > >>>>> as a vendor. > >>>> > >>>> So I guess then that their aiding and abetting of fraud and IP block > >>>> theft, as I documented here recently, is an entirely secondary concern... > >>>> as long as they don't spam you, yes? > >>>> > >>>> > >>>> Regards, > >>>> rfg From owen at delong.com Tue Sep 17 02:35:08 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Sep 2019 19:35:08 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: > On Sep 16, 2019, at 17:48 , Randy Bush wrote: > >> 1. Sprint peering battle. Google it >> 2. He.net peering battle. Google it. >> 3. Google IPv6 peering battle. Google it. >> >> All of which point to them being pompous assholes. > > or point to them treating ipv6 the same as ipv4 when it comes to > peering, tech, ... we are supposed to think ipv6 parity is a good > thing. > > randy Actually, their peering behavior in IPv4 is not quite as arrogant as it is in IPv6, so no, they aren’t doing parity. Owen From mike.lyon at gmail.com Tue Sep 17 02:54:37 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 16 Sep 2019 19:54:37 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <80866A43-9614-488F-AB11-71E4F5C0F785@6by7.net> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> <80866A43-9614-488F-AB11-71E4F5C0F785@6by7.net> Message-ID: <1B222EAC-B8F9-4922-8A3A-333975F7F6FC@gmail.com> Within the past year or two i’ve seen it occur. > On Sep 16, 2019, at 18:44, Ben Cannon wrote: > > “They also run their links hot which create latency for anything flowing through it.” > > Mike, I’d have agreed with you - 15 years ago. Is this current at all? My views on Cogent have evolved dramatically over the years. How recent is your data? > > -Ben > >> On Sep 16, 2019, at 4:21 PM, Mike Lyon wrote: >> >> The argument has been listed numerous times so i didn’t want to bore people: >> >> 1. Sprint peering battle. Google it >> 2. He.net peering battle. Google it. >> 3. Google IPv6 peering battle. Google it. >> >> All of which point to them being pompous assholes. >> >> They also run their links hot which create latency for anything flowing through it. >> >> Cheers, >> Mike >> >>> On Sep 16, 2019, at 15:59, Stephen M. wrote: >>> >>> Please don’t praise or complain like we’re supposed to take it at a total face value. If you don’t like them so much - we are you’re audience. Explain. >>> >>> If you like Cogent - explain. >>> If you don’t like Cogent - explain. >>> >>> Cheers, >>> Stephen >>> >>> //please pardon any brevities - sent from mobile// >>> >>>> On Sep 16, 2019, at 10:01 PM, Mike Lyon wrote: >>>> >>>> Whenever asked about Cogent, i just say, “Friends don’t let friends use Cogent.” >>>> >>>> I’ve told two of their reps over the past two years that even if the service was free, i wouldn’t use it. And yet, they still call. >>>> >>>> -Mike >>>> >>>>>> On Sep 16, 2019, at 13:53, Ronald F. Guilmette wrote: >>>>>> >>>>>> In message , >>>>>> Owen DeLong wrote: >>>>>> >>>>>> Given their practice of harvesting whois updates in order to spam newly >>>>>> acquired AS contacts, any time it is my decision, Cogent is ineligible >>>>>> as a vendor. >>>>> >>>>> So I guess then that their aiding and abetting of fraud and IP block >>>>> theft, as I documented here recently, is an entirely secondary concern... >>>>> as long as they don't spam you, yes? >>>>> >>>>> >>>>> Regards, >>>>> rfg From mike.lyon at gmail.com Tue Sep 17 02:58:21 2019 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 16 Sep 2019 19:58:21 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: <9FAC1DBA-B633-4843-AFEB-8A00FFAA4956@gmail.com> And why are they not on any public peering exchange? Why only private? > On Sep 16, 2019, at 19:35, Owen DeLong wrote: > > > >>> On Sep 16, 2019, at 17:48 , Randy Bush wrote: >>> >>> 1. Sprint peering battle. Google it >>> 2. He.net peering battle. Google it. >>> 3. Google IPv6 peering battle. Google it. >>> >>> All of which point to them being pompous assholes. >> >> or point to them treating ipv6 the same as ipv4 when it comes to >> peering, tech, ... we are supposed to think ipv6 parity is a good >> thing. >> >> randy > > Actually, their peering behavior in IPv4 is not quite as arrogant as it is in IPv6, so no, they aren’t doing parity. > > Owen > From randy at psg.com Tue Sep 17 03:19:22 2019 From: randy at psg.com (Randy Bush) Date: Mon, 16 Sep 2019 20:19:22 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: <9FAC1DBA-B633-4843-AFEB-8A00FFAA4956@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> <9FAC1DBA-B633-4843-AFEB-8A00FFAA4956@gmail.com> Message-ID: > And why are they not on any public peering exchange? Why only private? the deeper question is why do they only use green ether cables when they should use magenta? tier ones do not push a lot over public ixen. their choice. welcome to the realities of the internet. glad you found us. randy From rfg at tristatelogic.com Tue Sep 17 04:07:58 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 16 Sep 2019 21:07:58 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: Message-ID: <42289.1568693278@segfault.tristatelogic.com> In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg From emile.aben at ripe.net Tue Sep 17 10:23:07 2019 From: emile.aben at ripe.net (Emile Aben) Date: Tue, 17 Sep 2019 12:23:07 +0200 Subject: diversity in the RIPE Route Collectors Message-ID: Hi NANOG, in light of a recent discussion on RIS-live, and a question on where best have RIS peers, this might be of interest to the NANOG crowd: https://labs.ripe.net/Members/emileaben/how-diverse-is-ris best regards, Emile Aben RIPE NCC From mark.tinka at seacom.mu Tue Sep 17 11:41:57 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Sep 2019 13:41:57 +0200 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: <4beb105f-d4b2-3890-a6ed-4de80df1e295@seacom.mu> On 16/Sep/19 20:26, Töma Gavrichenkov wrote: > > > Not always. No, longest match ALWAYS wins. > > E.g. imagine an ISP who has two connections to the outside world: one > through a major ISP and the other through an IX. > > Such an ISP would be quite inclined both financially and technically > to import routes just from the IX and set the default to the upstream > ISP link.  Therefore, an advertisement from the IX would always win no > matter the length. Which is why I included, in my previous message:     So, for example, if the upstream to whom you are sending the /21 doesn't     do anything about how they learn the /22 from another source, (for their     network)... Mark. From mark.tinka at seacom.mu Tue Sep 17 11:43:37 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Sep 2019 13:43:37 +0200 Subject: Consistent routing policy? In-Reply-To: References: <15ae1a14-2d9a-debc-5f4a-b8e6daade4d2@seacom.mu> <62ccfc0b-f2a7-6157-e802-cbdcbad07ba6@seacom.mu> Message-ID: <95579467-07f8-9dbd-3feb-7fe78bb90027@seacom.mu> On 16/Sep/19 21:55, Töma Gavrichenkov wrote: > > > The point is that you must expect inbound traffic to any prefix you > advertise to the outside world, even a more specific announcement is > also being advertised.  There are legitimate circumstances where an > ISP would prefer the super-block. It's not about the business reasons for wanting it, it's about what the router does if it's presented with the options. Like I said before, you can do things to your network to prevent your router from installing a longer prefix. But if you do not, the longer prefix will always be installed and used, first. Mark. From rfg at tristatelogic.com Tue Sep 17 11:53:28 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 17 Sep 2019 04:53:28 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: Message-ID: <44347.1568721208@segfault.tristatelogic.com> In message , Elad Cohen wrote: >The defamatory and invective words, the mudslinging and slander of my name, > by Ronald Guilmette, are not true at all and they are completely false, in > my hand there are all the purchases approval for purchasing ipv4 and that >were paid completely by me. > >Anyone who wants confirmation the ips belong to us can sent me a direct >e-mail and i would be happy to explain and provide evidence. thank you. You can stop dancing around the issue Mr. Cohen, and come clean, any time you want. Like for example right here and right now. Stop prevaricating. Put up or shut up. Either that or have the decency to admit that you are dyed-in-the-wool con man and fraud, as your onetime pals at Cogent and FDCServers have apparently finally figured out. By all means, show us all of these allged "purchase approvals" you have for the following blocks which you managed... temporarily at least... to get your compliant pals at Cogent and FDCSewers to route for you: APNIC region: 168.198.0.0/16 -- Department of Finance and Deregulation (AU) 139.44.0.0/16 -- Port of Melbourne Authority (AU) 143.136.0.0/16 143.253.0.0/16 146.51.0.0/16 AFRINIC region: 168.206.0.0/16 160.122.0.0/16 163.198.0.0/16 165.3.0.0/16 196.16.0.0/14 196.193.0.0/16 155.159.0.0/16 163.197.0.0/16 164.155.0.0/16 165.25.0.0/16 -- City of Cape Town 196.15.64.0/18 160.121.0.0/16 155.235.0.0/16 196.10.64.0/19 160.116.0.0/16 168.206.0.0/16 -- The Atomic Energy Board (South Africa) 165.52.0.0/14 -- Cape of Good Hope Bank (South Africa) For one little guy, you sure managed to accumulate one hell of huge stash of IPv4 addresses! Well over $30 million dollars worth, in fact. So please Mr. Cohen, by all means, please do tell us what all of these mountains of IPv4 addresses cost you, who you paid for them, and what exactly you planned to do with them, and with whom. Please do show us any and all documentation you have of your alleged "purchases". I'm sure that we are all keen to see how you cleverly outwitted all other bidders to come out on top in the bidding war for the City of Cape Town's block or for the one you apparently lifted from the Australian Department of Finance and Deregulation. But please, don't insult our intelligence by showing us more of those blatantly fradulent "LOAs" that were presented in the MyBroadband.co.za report. As I've already pointed out here, no self respecting forger would even have tried to pass those. The perfectly identical signatures and vaguely official-looking stamps on all of them render them not even third-rate forgeries. Oh! And by the way Mr. Cohen, as it happens I myself am the proud owner of a perfectly valid "purchase approval" for the Brooklyn Bridge. So you see, we have something in common! Looking forward to you next missive. Love and kisses, rfg From vivek at apnic.net Tue Sep 17 07:48:45 2019 From: vivek at apnic.net (Vivek Nigam) Date: Tue, 17 Sep 2019 07:48:45 +0000 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? Message-ID: <9567B241-12CE-4728-8E73-FF7143907CEF@apnic.net> Hi Ronald, APNIC has contacted the custodians of 139.44.0.0/16 and 168.198.0.0/16 and brought this matter to their attention. Regards, Vivek Member Services Manager, APNIC From: Ronald F. Guilmette Date: Fri, Sep 6, 2019 at 6:30 PM Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? To: Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net). https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Tue Sep 17 09:09:19 2019 From: elad at netstyle.io (Elad Cohen) Date: Tue, 17 Sep 2019 09:09:19 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: <42289.1568693278@segfault.tristatelogic.com> References: , <42289.1568693278@segfault.tristatelogic.com> Message-ID: The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Tuesday, September 17, 2019 7:07 AM To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Sep 17 15:34:39 2019 From: randy at psg.com (Randy Bush) Date: Tue, 17 Sep 2019 08:34:39 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: Message-ID: > The defamatory and invective words, the mudslinging and slander of my > name, by Ronald Guilmette is he a cogent sales rep? that would explain a lot! From morrowc.lists at gmail.com Tue Sep 17 18:36:15 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2019 14:36:15 -0400 Subject: diversity in the RIPE Route Collectors In-Reply-To: References: Message-ID: On Tue, Sep 17, 2019 at 6:24 AM Emile Aben wrote: > > Hi NANOG, > > in light of a recent discussion on RIS-live, and a question on where > best have RIS peers, this might be of interest to the NANOG crowd: > https://labs.ripe.net/Members/emileaben/how-diverse-is-ris > thanks for taking a look at this! I think the first reaction (of mine anyway) is: "moar is better", but that's clearly not correct. Taking some time to review and figure out what costs/concerns/benefits there are with more coverage in which places such that improvements in the data set (and view of the bgp world) could be made... is great! -chris From rfg at tristatelogic.com Tue Sep 17 20:43:36 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 17 Sep 2019 13:43:36 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <9567B241-12CE-4728-8E73-FF7143907CEF@apnic.net> Message-ID: <46051.1568753016@segfault.tristatelogic.com> In message <9567B241-12CE-4728-8E73-FF7143907CEF at apnic.net>, Vivek Nigam wrote: >APNIC has contacted the custodians of 139.44.0.0/16 and 168.198.0.0/16 and >brought this matter to their attention. Excellent. Thank you. If possible, it would be Good if APNIC could also make contact with the rightful owners of the following additional 3 Japanese blocks, all of which were, of late, routed by Cogent to FDCServers and thence, presumably, to Mr. Cohen. 143.136.0.0/16 143.253.0.0/16 146.51.0.0/16 I tried to make contact myself with the legit owners of all of the above, but found it to be quite difficult. The registered owner of the first one appears to have gone into hiding on a remote island someplace. I only say that because, despite some considerable effort on my part, I was not able to find him. Making contact with the legitimate owners of the other two blocks, both of which belong to Japanese corporations that are still very much alive, was rather difficult also, because I am only a stupid gaijin, and don't speak a word of Japanese. Regards, rfg From martijnschmidt at i3d.net Tue Sep 17 20:44:38 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Tue, 17 Sep 2019 20:44:38 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: , <42289.1568693278@segfault.tristatelogic.com>, Message-ID: Hi Elad, If you were to create RPKI ROAs for the IPs in question that'd end the discussion about prefix ownership once and for all. It's the best way to definitively prove, in public, that the accusations of theft are false. And it also helps to protect your resources from accidental leaks or hijacks, so that's a nice bonus. :) Best regards, Martijn Schmidt ________________________________ From: NANOG on behalf of Elad Cohen Sent: 17 September 2019 11:09:19 To: Ronald F. Guilmette ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Tuesday, September 17, 2019 7:07 AM To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Tue Sep 17 21:48:06 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 17 Sep 2019 14:48:06 -0700 Subject: RPKI (was: Re: Cogent sales reps who actually respond) In-Reply-To: Message-ID: <46308.1568756886@segfault.tristatelogic.com> In message , Martijn Schmidt wrote: >Hi Elad, > >If you were to create RPKI ROAs for the IPs in question... Thanks Martijn, for reminding me of a follow-up point that I had intended to make regarding my recent post about the 143.95.0.0/16 (Athenix) block. RPKI is the best we have and I cannot wait for the day when it will see universal deployment. But it isn't actually the 100% solution that everyone has been hoping it would be. As the case of the 143.95.0.0/16 block illustrates, if the RIR has itself been snookered into believing that party X actually owns party Y's block, then that's it. Game over, and RPKI doesn't help, because if the RIR believes that you own the block, and if you are insisting on driving it off the lot, right now, today, then they *are* going to give you the keys, even if the "keys", in future, will include some additional RPKI mumbo jumbo, along with WHOIS records reflecting your desired public persona, and reverse DNS delegation, etc. In short, it appears to me that RPKI only secures resources from the RIR outwards, and if there is a problem of either competency or trust within the RIR, then RPKI can't and won't solve that... ... but I feel sure that someone will correct me if I'm wrong. Regards, rfg From morrowc.lists at gmail.com Tue Sep 17 22:20:54 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2019 18:20:54 -0400 Subject: RPKI (was: Re: Cogent sales reps who actually respond) In-Reply-To: <46308.1568756886@segfault.tristatelogic.com> References: <46308.1568756886@segfault.tristatelogic.com> Message-ID: On Tue, Sep 17, 2019 at 5:49 PM Ronald F. Guilmette wrote: > > In message , > Martijn Schmidt wrote: > > >Hi Elad, > > > >If you were to create RPKI ROAs for the IPs in question... > > Thanks Martijn, for reminding me of a follow-up point that I had intended > to make regarding my recent post about the 143.95.0.0/16 (Athenix) block. > > RPKI is the best we have and I cannot wait for the day when it will see > universal deployment. But it isn't actually the 100% solution that > everyone has been hoping it would be. > > As the case of the 143.95.0.0/16 block illustrates, if the RIR has itself > been snookered into believing that party X actually owns party Y's block, > then that's it. Game over, and RPKI doesn't help, because if the I really don't think this part of the problem matters. If a block is moved from one entity to another, that's it, nothing to be done/seen here. it's sad and someone should weep for the lost integers, but.. meh. The RIR abuse process can cleanup as required mr curran's notes about: "please send to fraud@" would apply here directly. -chris From martijnschmidt at i3d.net Tue Sep 17 22:40:24 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Tue, 17 Sep 2019 22:40:24 +0000 Subject: RPKI (was: Re: Cogent sales reps who actually respond) In-Reply-To: <46308.1568756886@segfault.tristatelogic.com> References: , <46308.1568756886@segfault.tristatelogic.com> Message-ID: Hi Ronald, I think we have to place our trust somewhere somehow.. I certainly don't have the time nor the skill-set which would be needed to perform due diligence on the ownership of every IP block on the Internet, and though you make a laudable effort of it yourself this responsibility can't be borne in its entirety by one volunteering person. It just doesn't scale. Given that there is (or should be) an unbroken chain of contracts and payments from IANA to RIR (to NIR) to LIR and beyond for all non-legacy resources, I'd say they are in a pretty good position to take care of the due diligence work to validate an organisation's ownership as well as its associated resources and subsequently publish the result through a cryptographic signature. If one of the RIRs or NIRs is not doing that job properly then we should (at first privately) call them out on it and push them to improve. Best regards, Martijn ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: 17 September 2019 23:48:06 To: nanog at nanog.org Subject: RPKI (was: Re: Cogent sales reps who actually respond) In message , Martijn Schmidt wrote: >Hi Elad, > >If you were to create RPKI ROAs for the IPs in question... Thanks Martijn, for reminding me of a follow-up point that I had intended to make regarding my recent post about the 143.95.0.0/16 (Athenix) block. RPKI is the best we have and I cannot wait for the day when it will see universal deployment. But it isn't actually the 100% solution that everyone has been hoping it would be. As the case of the 143.95.0.0/16 block illustrates, if the RIR has itself been snookered into believing that party X actually owns party Y's block, then that's it. Game over, and RPKI doesn't help, because if the RIR believes that you own the block, and if you are insisting on driving it off the lot, right now, today, then they *are* going to give you the keys, even if the "keys", in future, will include some additional RPKI mumbo jumbo, along with WHOIS records reflecting your desired public persona, and reverse DNS delegation, etc. In short, it appears to me that RPKI only secures resources from the RIR outwards, and if there is a problem of either competency or trust within the RIR, then RPKI can't and won't solve that... ... but I feel sure that someone will correct me if I'm wrong. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Tue Sep 17 22:45:12 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Tue, 17 Sep 2019 22:45:12 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: , <42289.1568693278@segfault.tristatelogic.com>, , , Message-ID: Hi Elad, Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? Best regards, Martijn ________________________________ From: Elad Cohen Sent: 18 September 2019 00:40:13 To: Martijn Schmidt ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. ________________________________ From: Martijn Schmidt Sent: Tuesday, September 17, 2019 11:44 PM To: Elad Cohen ; Ronald F. Guilmette ; nanog at nanog.org ; Martijn Schmidt Subject: Re: Cogent sales reps who actually respond Hi Elad, If you were to create RPKI ROAs for the IPs in question that'd end the discussion about prefix ownership once and for all. It's the best way to definitively prove, in public, that the accusations of theft are false. And it also helps to protect your resources from accidental leaks or hijacks, so that's a nice bonus. :) Best regards, Martijn Schmidt ________________________________ From: NANOG on behalf of Elad Cohen Sent: 17 September 2019 11:09:19 To: Ronald F. Guilmette ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Tuesday, September 17, 2019 7:07 AM To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 18 01:46:03 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Sep 2019 21:46:03 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <42289.1568693278@segfault.tristatelogic.com> Message-ID: On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG wrote: > > Hi Elad, > > Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? > > Best regards, > Martijn ________________________________ > From: Elad Cohen > Sent: 18 September 2019 00:40:13 > To: Martijn Schmidt ; nanog at nanog.org > Subject: Re: Cogent sales reps who actually respond > > Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. > _ technically possible to transfer your afrnic space to ripe though, right? and do rpki there. From patrick at ianai.net Wed Sep 18 02:55:36 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 17 Sep 2019 22:55:36 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <42289.1568693278@segfault.tristatelogic.com> Message-ID: <98D7D283-C626-4362-AC6B-30D7FE9EC96F@ianai.net> On Sep 17, 2019, at 9:46 PM, Christopher Morrow wrote: > On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG > wrote: >> >> Hi Elad, >> >> Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? >> >> Best regards, >> Martijn ________________________________ >> From: Elad Cohen >> Sent: 18 September 2019 00:40:13 >> To: Martijn Schmidt ; nanog at nanog.org >> Subject: Re: Cogent sales reps who actually respond >> >> Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. >> _ > > technically possible to transfer your afrnic space to ripe though, > right? and do rpki there. I do not believe so. AFRINIC has no inter-RIR transfer policy. I do not believe the fact it is legacy space matters, AFRINIC won’t let you move it out, and RIPE wouldn’t let you bring it in anyway - AFAIK. They are the only RIR that does not have an inter-RIR policy. Well, LACNIC just voted one in, but it is not implemented - yet. -- TTFN, patrick From Bryan at bryanfields.net Wed Sep 18 03:06:49 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 17 Sep 2019 23:06:49 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <5B29FF27-E3B2-4745-AD0C-E6581FEC37D9@gmail.com> Message-ID: On 9/16/19 7:21 PM, Mike Lyon wrote: > 1. Sprint peering battle. Google it > 2. He.net peering battle. Google it. > 3. Google IPv6 peering battle. Google it. > > All of which point to them being pompous assholes. Add in Level3, Telia, ESnet, and I'm sure I'm forgetting others here. Hurricane Electric even baked them a cake, yet they still wont peer. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From morrowc.lists at gmail.com Wed Sep 18 04:19:01 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Sep 2019 00:19:01 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: <98D7D283-C626-4362-AC6B-30D7FE9EC96F@ianai.net> References: <42289.1568693278@segfault.tristatelogic.com> <98D7D283-C626-4362-AC6B-30D7FE9EC96F@ianai.net> Message-ID: On Tue, Sep 17, 2019 at 10:56 PM Patrick W. Gilmore wrote: > > On Sep 17, 2019, at 9:46 PM, Christopher Morrow wrote: > > On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG > > wrote: > >> > >> Hi Elad, > >> > >> Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? > >> > >> Best regards, > >> Martijn ________________________________ > >> From: Elad Cohen > >> Sent: 18 September 2019 00:40:13 > >> To: Martijn Schmidt ; nanog at nanog.org > >> Subject: Re: Cogent sales reps who actually respond > >> > >> Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. > >> _ > > > > technically possible to transfer your afrnic space to ripe though, > > right? and do rpki there. > > I do not believe so. oh :( bummer. > AFRINIC has no inter-RIR transfer policy. I do not believe the fact it is legacy space matters, AFRINIC won’t let you move it out, and RIPE wouldn’t let you bring it in anyway - AFAIK. > > They are the only RIR that does not have an inter-RIR policy. Well, LACNIC just voted one in, but it is not implemented - yet. > > -- > TTFN, > patrick > From mohta at necom830.hpcl.titech.ac.jp Wed Sep 18 05:04:02 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 18 Sep 2019 14:04:02 +0900 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <46051.1568753016@segfault.tristatelogic.com> References: <46051.1568753016@segfault.tristatelogic.com> Message-ID: <152f0dbc-f7af-2a78-c5a7-f2062effed23@necom830.hpcl.titech.ac.jp> Ronald F. Guilmette wrote: > If possible, it would be Good if APNIC could also make contact with the > rightful owners of the following additional 3 Japanese blocks, Because whois contact information is, seemingly by acquisition and relocation, obsolete, it should be impossible for APNIC to do so. > 143.136.0.0/16 > 143.253.0.0/16 > 146.51.0.0/16 > > I tried to make contact myself with the legit owners of all of the above, > but found it to be quite difficult. The registered owner of the first > one appears to have gone into hiding on a remote island someplace. From whois information: remarks: reg-date: 1993-03-22 notify: tmiyoko at gaijin.co.jp mnt-by: MNT-ERX-CROSFIELDELE-NON-JP last-modified: 2008-09-04T07:31:15Z I guess CROSFIELDELE is Japanese branch of: https://en.wikipedia.org/wiki/Crosfield_Electronics The firm was eventually taken over by Fujifilm Japan and named Fujifilm Electronic Imaging, now FFEI Ltd. following a management buy-out in 2008.[1] though, according to: https://www.ffei.co.uk/about-ffei-design-and-manufacture-digital-inkjet/ MBO was in 2006. In the page, we can also confirm that FFEI was crosfield until 1997. > Making contact with the legitimate owners of the other > two blocks, both of which belong to Japanese corporations that are still > very much alive, was rather difficult also, because I am only a stupid > gaijin, and don't speak a word of Japanese. Both relocated. I send queries to the current contact points. Maybe, blocks with stale contact information are attacked. Masataka Ohta From cfriacas at fccn.pt Wed Sep 18 06:40:31 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 18 Sep 2019 07:40:31 +0100 (WEST) Subject: Cogent sales reps who actually respond In-Reply-To: References: <42289.1568693278@segfault.tristatelogic.com> <98D7D283-C626-4362-AC6B-30D7FE9EC96F@ianai.net> Message-ID: >>> On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG >>> wrote: >>>> >>>> Hi Elad, >>>> >>>> Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? >>>> >>>> Best regards, >>>> Martijn ________________________________ >>>> From: Elad Cohen >>>> Sent: 18 September 2019 00:40:13 >>>> To: Martijn Schmidt ; nanog at nanog.org >>>> Subject: Re: Cogent sales reps who actually respond >>>> >>>> Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. >>>> _ Hi, https://afrinic.net/membership/legacy-resource "AFRINIC encourages legacy resource holders to become AFRINIC members and to take advantage of all services it offers to its members". What i can read from this is: Yes, it's possible, but it won't be "free". Maybe hostmaster at afrinic.net (Cc:'ed) can clarify... :-) Cheers, Carlos From jeroen at massar.ch Wed Sep 18 07:15:49 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Sep 2019 09:15:49 +0200 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users Message-ID: Hi Folks, While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore (NXDOMAIN use-application-dns.net to avoid that[1]). Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] For pdns "qname-minimization=yes" [6] For unbound "qname­-minimisation: yes" [5] For BIND "qname-minimization" option [3] and [4] Of course, do also provider your users with the option of using DoT or even DoH on your recursors... Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... Some more details in DNS Privacy Wiki [8]... Discuss! :) Greets, Jeroen [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https [2] https://tools.ietf.org/html/rfc7816 [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf [6] https://github.com/PowerDNS/pdns/issues/2311 [7] https://wiki.mozilla.org/Security/DOH-resolver-policy [8] https://dnsprivacy.org/wiki/ From rfg at tristatelogic.com Wed Sep 18 08:59:01 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 18 Sep 2019 01:59:01 -0700 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <152f0dbc-f7af-2a78-c5a7-f2062effed23@necom830.hpcl.titech.ac.jp> Message-ID: <48469.1568797141@segfault.tristatelogic.com> In message <152f0dbc-f7af-2a78-c5a7-f2062effed23 at necom830.hpcl.titech.ac.jp>, Masataka Ohta wrote: > From whois information: > > remarks: reg-date: 1993-03-22 > > notify: tmiyoko at gaijin.co.jp ^^^^^^^^^^^^ I already talked to the guy who has owned the above domain name for mre than 25+ years. He's an American, living in Southern California, who these days runs a solar panel installation company. He told me that he has no way to find "tmiyoko" anymore and that that guy was just one of thousands of customers the guy in SoCal had, back 20+ years ago, for his Japanese ISP business. Regards, rfg From mohta at necom830.hpcl.titech.ac.jp Wed Sep 18 09:05:34 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 18 Sep 2019 18:05:34 +0900 Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? In-Reply-To: <48469.1568797141@segfault.tristatelogic.com> References: <48469.1568797141@segfault.tristatelogic.com> Message-ID: Ronald F. Guilmette wrote: To me: >> notify: tmiyoko at gaijin.co.jp merely suggest miyoko has some relationships with gaijin (foreigners), which is partly why I guess: www.ffei.co.uk is the owner. Masataka Ohta From brian at interlinx.bc.ca Wed Sep 18 10:24:08 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 18 Sep 2019 06:24:08 -0400 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: References: Message-ID: On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote: > Hi Folks, Hi. > While in the US soon all Firefox users will *NOT* use your DNS > Recursives configured using DHCP anymore > (NXDOMAIN use-application-dns.net to avoid that[1]). What am I misunderstanding? Isn't use-application-dns.net supposed to return A results until "defeated"? I have not configured my own DNS server to NXDOMAIN that yet, however: $ dig use-application-dns.net a ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> use-application-dns.net a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33589 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; Query time: 1181 msec ;; SERVER: fd31:aeb1:48df::2#53(fd31:aeb1:48df::2) ;; WHEN: Wed Sep 18 06:22:19 EDT 2019 ;; MSG SIZE rcvd: 52 And even Google's global DNS: $ dig @8.8.8.8 use-application-dns.net a ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> @8.8.8.8 use-application- dns.net a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33725 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; Query time: 1454 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Sep 18 06:22:42 EDT 2019 ;; MSG SIZE rcvd: 52 Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From jeroen at massar.ch Wed Sep 18 10:51:53 2019 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Sep 2019 12:51:53 +0200 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: References: Message-ID: <8580e3e4-98b8-2828-e43f-6115c92faee5@massar.ch> On 2019-09-18 12:24, Brian J. Murrell wrote: > On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote: >> Hi Folks, > > Hi. > >> While in the US soon all Firefox users will *NOT* use your DNS >> Recursives configured using DHCP anymore >> (NXDOMAIN use-application-dns.net to avoid that[1]). > > What am I misunderstanding? Isn't use-application-dns.net supposed to > return A results until "defeated"? I have not configured my own DNS > server to NXDOMAIN that yet, however: That just means that somebody broke that setup as it worked last week and was pointing to Github Pages serving: https://github.com/agrover/global-canary/ Maybe Google does not want Mozilla/CloudFlare to get all the DoH queries? :) Nah likely just a failure somewhere, as both are supported heavily by Google (if there was no competition then Google would truly have a monopoly in the browser market and that would be bad, at least with them funding Mozilla and CF through the backdoor it looks like it isn't a monopoly as there "is that other thing") There is a little thread about that domain here on dns-operations: https://lists.dns-oarc.net/pipermail/dns-operations/2019-September/019179.html Currently though: use-application-dns.net. 172800 IN NS ns-cloud-b1.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b2.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b3.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b4.googledomains.com. $ dig @ns-cloud-b1.googledomains.com. use-application-dns.net. a [..] ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21669 ... that is from my test host, but of course, from my other hosts it nicely NXDOMAINs.... but those hosts also route 1.1.1.1/8.8.8.8/8.8.4.4 and the IPv6 equivalents and many other such IPs (OpenDNS, etc and even root servers) to the local anycasted edition.... cause I don't want that in my networks. Then again, as that makes me not a sheep, I am likely more visible anyway...[1] Greets, Jeroen [1] https://jeroen.massar.ch/presentations/vid/27C3-JeroenMassar-HowTheInternetSeesYou/ From nanog at ics-il.net Wed Sep 18 14:19:28 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Sep 2019 09:19:28 -0500 (CDT) Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: References: Message-ID: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as default behavior? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jeroen Massar" To: "NANOG" Sent: Wednesday, September 18, 2019 2:15:49 AM Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users Hi Folks, While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore (NXDOMAIN use-application-dns.net to avoid that[1]). Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] For pdns "qname-minimization=yes" [6] For unbound "qname­-minimisation: yes" [5] For BIND "qname-minimization" option [3] and [4] Of course, do also provider your users with the option of using DoT or even DoH on your recursors... Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... Some more details in DNS Privacy Wiki [8]... Discuss! :) Greets, Jeroen [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https [2] https://tools.ietf.org/html/rfc7816 [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf [6] https://github.com/PowerDNS/pdns/issues/2311 [7] https://wiki.mozilla.org/Security/DOH-resolver-policy [8] https://dnsprivacy.org/wiki/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at as397444.net Wed Sep 18 14:25:43 2019 From: nanog at as397444.net (Matt Corallo) Date: Wed, 18 Sep 2019 16:25:43 +0200 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> References: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> Message-ID: Because getting each ISP in the world to comply with NSA monitoring requests was too hard, instead they get to centralize the full list of every website the everyone in the world visits on a single fleet of servers in Cloudflare's datacenters. This means we only need to compromise one person to monitor the world, saving the US taxpayer significantly. Progress! Matt > On Sep 18, 2019, at 16:19, Mike Hammett wrote: > > Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as default behavior? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Jeroen Massar" > To: "NANOG" > Sent: Wednesday, September 18, 2019 2:15:49 AM > Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users > > Hi Folks, > > While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore > (NXDOMAIN use-application-dns.net to avoid that[1]). > Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. > > > For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run > DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] > > For pdns "qname-minimization=yes" [6] > For unbound "qname­-minimisation: yes" [5] > For BIND "qname-minimization" option [3] and [4] > > Of course, do also provider your users with the option of using DoT or even DoH on your recursors... > > Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... > > Some more details in DNS Privacy Wiki [8]... > > Discuss! :) > > Greets, > Jeroen > > > [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https > [2] https://tools.ietf.org/html/rfc7816 > [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ > [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 > [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf > [6] https://github.com/PowerDNS/pdns/issues/2311 > [7] https://wiki.mozilla.org/Security/DOH-resolver-policy > [8] https://dnsprivacy.org/wiki/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Wed Sep 18 15:19:26 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 18 Sep 2019 09:19:26 -0600 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> Message-ID: <1dd13364a2ad2246a14cfbd1a128172e@mail.dessus.com> For efficiency of censorship. If you want to stop some domain name from resolving you have to get everyone on the planet to block that DNS resolution in their recursive resolver. However, if everyone uses the same single DNS server operated by a single entity, then you only have to coerce that one entity to block resolution of that DNS name. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG On Behalf Of Mike Hammett >Sent: Wednesday, 18 September, 2019 08:19 >To: Jeroen Massar >Cc: NANOG >Subject: Re: DNS Recursive Operators: Please enable QNAME minimization >(RFC7816) for the enhanced privacy of your users > >Why on Earth would anyone want that (Firefox deciding to do it's own DNS) >as default behavior? > > > > >----- >Mike Hammett >Intelligent Computing Solutions > > > > >Midwest Internet Exchange > > > >The Brothers WISP > > > >________________________________ > >From: "Jeroen Massar" >To: "NANOG" >Sent: Wednesday, September 18, 2019 2:15:49 AM >Subject: DNS Recursive Operators: Please enable QNAME minimization >(RFC7816) for the enhanced privacy of your users > >Hi Folks, > >While in the US soon all Firefox users will *NOT* use your DNS Recursives >configured using DHCP anymore >(NXDOMAIN use-application-dns.net to avoid that[1]). >Next to that, it seems some of the root operators are now creating >instances in the same networks that offer these kind of services for >globally figuring out what queries are being made. > > >For those that thus either opt-out or otherwise want to use their own >system resolvers, I suggest that all that run >DNS Recursive setups enable "QNAME minimization" as defined in >(experimental) RFC7816 [2] > >For pdns "qname-minimization=yes" [6] >For unbound "qname­-minimisation: yes" [5] >For BIND "qname-minimization" option [3] and [4] > >Of course, do also provider your users with the option of using DoT or >even DoH on your recursors... > >Noting that DoH operators are supposed to enable RFC7816 also [7], guess >they do not want others to see all the details they get... > >Some more details in DNS Privacy Wiki [8]... > >Discuss! :) > >Greets, > Jeroen > > >[1] https://support.mozilla.org/en-US/kb/configuring-networks-disable- >dns-over-https >[2] https://tools.ietf.org/html/rfc7816 >[3] https://www.isc.org/blogs/qname-minimization-and-privacy/ >[4] https://gitlab.isc.org/isc-projects/bind9/issues/16 >[5] >https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf >[6] https://github.com/PowerDNS/pdns/issues/2311 >[7] https://wiki.mozilla.org/Security/DOH-resolver-policy >[8] https://dnsprivacy.org/wiki/ > From elad at netstyle.io Tue Sep 17 22:40:13 2019 From: elad at netstyle.io (Elad Cohen) Date: Tue, 17 Sep 2019 22:40:13 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: , <42289.1568693278@segfault.tristatelogic.com>, , Message-ID: Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. ________________________________ From: Martijn Schmidt Sent: Tuesday, September 17, 2019 11:44 PM To: Elad Cohen ; Ronald F. Guilmette ; nanog at nanog.org ; Martijn Schmidt Subject: Re: Cogent sales reps who actually respond Hi Elad, If you were to create RPKI ROAs for the IPs in question that'd end the discussion about prefix ownership once and for all. It's the best way to definitively prove, in public, that the accusations of theft are false. And it also helps to protect your resources from accidental leaks or hijacks, so that's a nice bonus. :) Best regards, Martijn Schmidt ________________________________ From: NANOG on behalf of Elad Cohen Sent: 17 September 2019 11:09:19 To: Ronald F. Guilmette ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Tuesday, September 17, 2019 7:07 AM To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Tue Sep 17 22:54:41 2019 From: elad at netstyle.io (Elad Cohen) Date: Tue, 17 Sep 2019 22:54:41 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: , <42289.1568693278@segfault.tristatelogic.com>, , , , Message-ID: Please see the following link: https://afrinic.net/resource-certification As you can see, a MyAFRINIC account is required. Yes, route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI can be created and they were created by us. ________________________________ From: Martijn Schmidt Sent: Wednesday, September 18, 2019 1:45 AM To: Elad Cohen ; nanog at nanog.org ; Martijn Schmidt Subject: Re: Cogent sales reps who actually respond Hi Elad, Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? Best regards, Martijn ________________________________ From: Elad Cohen Sent: 18 September 2019 00:40:13 To: Martijn Schmidt ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. ________________________________ From: Martijn Schmidt Sent: Tuesday, September 17, 2019 11:44 PM To: Elad Cohen ; Ronald F. Guilmette ; nanog at nanog.org ; Martijn Schmidt Subject: Re: Cogent sales reps who actually respond Hi Elad, If you were to create RPKI ROAs for the IPs in question that'd end the discussion about prefix ownership once and for all. It's the best way to definitively prove, in public, that the accusations of theft are false. And it also helps to protect your resources from accidental leaks or hijacks, so that's a nice bonus. :) Best regards, Martijn Schmidt ________________________________ From: NANOG on behalf of Elad Cohen Sent: 17 September 2019 11:09:19 To: Ronald F. Guilmette ; nanog at nanog.org Subject: Re: Cogent sales reps who actually respond The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Tuesday, September 17, 2019 7:07 AM To: nanog at nanog.org Subject: Re: Cogent sales reps who actually respond In message , "Stephen M." wrote: >Please don't praise or complain like we're supposed to take >it at a total face value. If you don=E2=80=99t like them so much - we are >you're audience. Explain. > >If you like Cogent - explain. >If you don=E2=80=99t like Cogent - explain. I see that many others have already chimed in to comment on Cogent's technical prowess, or lack thereof, and on Cogent's customer service, or lack thereof. These things are neither my forte nor my concern. My issue with the company is what I believe is, and rightly should be a meta-issue that should be of overriding concern of all who use or work on the Internet, i.e. the degree to which the company, wittingly or othewise, has enabled theft or squatting on -numerous- large chunks of IPv4 space by what amount to Internet criminals. I already detailed my concerns here, and quite recently: https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html The case is both clear and unambiguous. Some little guy by the name of Elad Cohen, living and working in Israel, who has some little two-bit "hosting" company, has been, in very recent times, rather blatantly squatting on numerous previously abandoned legacy blocks... /16 after /16 after /16... perhaps 20 or more such blocks... all of them being used, self evidently, by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has no legitimate rights to whatsoever... like the blocks he squatted on which belong to the Australian national government's Department of Finance, and another seemingly abandoned legacy /16 that belongs to the City of Cape Town, South Africa. And who were the primary enablers of all of this fraud and theft? Well, it was Mr. Cohen's helpful friends at a hosting company called FDCServers, headquartered in the one American city most known for its high ideals and consistantly ethical behavior, Chicago. FDCServers is not a big company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely oblivious to Mr. Cohen's crooked shenanigans, especially after I personally and explicitly informed him of it all. https://www.linkedin.com/in/fdcservers But the thing of it is that FDCServers, which appears to be a major customer of Cogent, does none of its own routing, preferring instead to have their bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to their customer, Mr. Cohen, on their behalf.... which Cogent apparently continued to do, right up through and including this past weekend, e.g. for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. My beef with both Cogent and FDCServers is simple. They both took Cohen's money and quite clearly didn't ask -any- reasonable questions, prefering instead to just accept Cohen's blatant forgeries as "evidence" of his ownership of the stolen blocks they routed for him. And they continued to do that, and only that, until well after I had explicitly and quite pointedly informed them of the self-evident problems with Mr. Cohen and his blatantly crooked business model. The crimes of Cogent and FDCServers, such as they are, do not rise to the level of "receiving stolen property", but I do think that they qualify under the heading of -transporting- stolen property. And believe me, if a cop pulls you over while you are driving your van, looks in the back and finds a whole lot of stolen bicycles that were ripped off from a nearby University campus, your protestations that you were "only delivering them to a friend" won't wash to get you out of a short stint in the Graybar Hotel. Cohen, with the help of FDCServers and Cogent, stole millions of dollars worth of valuable IPv4 real estate. Unfortunately, due to the lack of sophistication of crinminal authorities, combined with the trans-border and international nature of these crimes, Cohen will undoubtedly walk, as will Cogent and FDCServers. (So much for equal justice under law!) But I'll tell you straight up that I personally wouldn't trust any of these clowns to hold my wallet, not even for five minutes, and not even if it were empty. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From blopez at mailjet.com Wed Sep 18 08:50:49 2019 From: blopez at mailjet.com (Brice Lopez) Date: Wed, 18 Sep 2019 10:50:49 +0200 Subject: Contact at OLM LLC or Windstream Communications Message-ID: Hello, Anyone would have a contact at OLM LLC (AS19916)? They are still announcing a /24, part of a /22 we bought a few months ago. I guess it's a misconfiguration on their side, but I'm unable to reach them. I'm now trying to reach their transit, Windstream Communications (AS7029), because they could filter that illegitimate announce. If anyone has a contact at OLM or Windstream, it would be very helpful. Regards, Brice Lopez From morrowc.lists at gmail.com Wed Sep 18 17:29:48 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Sep 2019 13:29:48 -0400 Subject: Cogent sales reps who actually respond In-Reply-To: References: <42289.1568693278@segfault.tristatelogic.com> Message-ID: On Wed, Sep 18, 2019 at 11:54 AM Elad Cohen wrote: > > Please see the following link: > > https://afrinic.net/resource-certification > > As you can see, a MyAFRINIC account is required. > seems like you should do this step, then do the rpki step. > Yes, route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI can be created and they were created by us. > > ________________________________ > From: Martijn Schmidt > Sent: Wednesday, September 18, 2019 1:45 AM > To: Elad Cohen ; nanog at nanog.org ; Martijn Schmidt > Subject: Re: Cogent sales reps who actually respond > > Hi Elad, > > Is this policy officially documented by AFRINIC somewhere? Can you make route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI? > > Best regards, > Martijn ________________________________ > From: Elad Cohen > Sent: 18 September 2019 00:40:13 > To: Martijn Schmidt ; nanog at nanog.org > Subject: Re: Cogent sales reps who actually respond > > Hello Martin, unfortunately RPKI is not yet technically possible for a legacy range in Afrinic. > ________________________________ > From: Martijn Schmidt > Sent: Tuesday, September 17, 2019 11:44 PM > To: Elad Cohen ; Ronald F. Guilmette ; nanog at nanog.org ; Martijn Schmidt > Subject: Re: Cogent sales reps who actually respond > > Hi Elad, > > If you were to create RPKI ROAs for the IPs in question that'd end the discussion about prefix ownership once and for all. It's the best way to definitively prove, in public, that the accusations of theft are false. And it also helps to protect your resources from accidental leaks or hijacks, so that's a nice bonus. :) > > Best regards, > Martijn Schmidt ________________________________ > From: NANOG on behalf of Elad Cohen > Sent: 17 September 2019 11:09:19 > To: Ronald F. Guilmette ; nanog at nanog.org > Subject: Re: Cogent sales reps who actually respond > > The defamatory and invective words, the mudslinging and slander of my name, by Ronald Guilmette, are not true at all and they are completely false, in my hand there are all the purchases approval for purchasing ipv4 and that were paid completely by me. > > Anyone who wants confirmation the ips belong to us can sent me a direct e-mail and i would be happy to explain and provide evidence. thank you. > ________________________________ > From: NANOG on behalf of Ronald F. Guilmette > Sent: Tuesday, September 17, 2019 7:07 AM > To: nanog at nanog.org > Subject: Re: Cogent sales reps who actually respond > > In message , > "Stephen M." wrote: > > >Please don't praise or complain like we're supposed to take > >it at a total face value. If you don=E2=80=99t like them so much - we are > >you're audience. Explain. > > > >If you like Cogent - explain. > >If you don=E2=80=99t like Cogent - explain. > > I see that many others have already chimed in to comment on Cogent's > technical prowess, or lack thereof, and on Cogent's customer service, > or lack thereof. > > These things are neither my forte nor my concern. My issue with the company > is what I believe is, and rightly should be a meta-issue that should be of > overriding concern of all who use or work on the Internet, i.e. the degree > to which the company, wittingly or othewise, has enabled theft or squatting > on -numerous- large chunks of IPv4 space by what amount to Internet criminals. > > I already detailed my concerns here, and quite recently: > > https://mailman.nanog.org/pipermail/nanog/2019-September/102944.html > > The case is both clear and unambiguous. Some little guy by the name of Elad > Cohen, living and working in Israel, who has some little two-bit "hosting" > company, has been, in very recent times, rather blatantly squatting on > numerous previously abandoned legacy blocks... /16 after /16 after /16... > perhaps 20 or more such blocks... all of them being used, self evidently, > by Mr. Cohen, and many most or all of which Mr. Cohen demonstratably has > no legitimate rights to whatsoever... like the blocks he squatted on which > belong to the Australian national government's Department of Finance, and > another seemingly abandoned legacy /16 that belongs to the City of Cape > Town, South Africa. > > And who were the primary enablers of all of this fraud and theft? Well, > it was Mr. Cohen's helpful friends at a hosting company called FDCServers, > headquartered in the one American city most known for its high ideals > and consistantly ethical behavior, Chicago. FDCServers is not a big > company, so I have to assume that its CEO, Mr. Petr Kral, was not entirely > oblivious to Mr. Cohen's crooked shenanigans, especially after I personally > and explicitly informed him of it all. > > https://www.linkedin.com/in/fdcservers > > But the thing of it is that FDCServers, which appears to be a major customer > of Cogent, does none of its own routing, preferring instead to have their > bigger pals, Cogent (AS174) route all of this stolen IPv4 real estate to > their customer, Mr. Cohen, on their behalf.... which Cogent apparently > continued to do, right up through and including this past weekend, e.g. > for the stolen blocks 165.53.0.0/16 and 168.206.0.0/16. > > My beef with both Cogent and FDCServers is simple. They both took Cohen's > money and quite clearly didn't ask -any- reasonable questions, prefering > instead to just accept Cohen's blatant forgeries as "evidence" of his > ownership of the stolen blocks they routed for him. And they continued > to do that, and only that, until well after I had explicitly and quite > pointedly informed them of the self-evident problems with Mr. Cohen and > his blatantly crooked business model. > > The crimes of Cogent and FDCServers, such as they are, do not rise to the > level of "receiving stolen property", but I do think that they qualify > under the heading of -transporting- stolen property. And believe me, > if a cop pulls you over while you are driving your van, looks in the > back and finds a whole lot of stolen bicycles that were ripped off from > a nearby University campus, your protestations that you were "only > delivering them to a friend" won't wash to get you out of a short stint > in the Graybar Hotel. > > Cohen, with the help of FDCServers and Cogent, stole millions of dollars > worth of valuable IPv4 real estate. Unfortunately, due to the lack of > sophistication of crinminal authorities, combined with the trans-border > and international nature of these crimes, Cohen will undoubtedly walk, > as will Cogent and FDCServers. (So much for equal justice under law!) > But I'll tell you straight up that I personally wouldn't trust any of > these clowns to hold my wallet, not even for five minutes, and not even > if it were empty. > > > Regards, > rfg From mohta at necom830.hpcl.titech.ac.jp Wed Sep 18 20:25:05 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 05:25:05 +0900 Subject: Registration fraud (was Re: RPKI) In-Reply-To: References: <46308.1568756886@segfault.tristatelogic.com> Message-ID: <9f4ccfcc-3f84-0d5b-be8e-15c2bd735d9b@necom830.hpcl.titech.ac.jp> Martijn Schmidt via NANOG wrote: > Given that there is (or should be) an unbroken chain of contracts and > payments from IANA to RIR (to NIR) to LIR and beyond for all > non-legacy resources, I'd say they are in a pretty good position to > take care of the due diligence work to validate an organisation's > ownership as well as its associated resources and subsequently > publish the result through a cryptographic signature. If one of the > RIRs or NIRs is not doing that job properly then we should (at first > privately) call them out on it and push them to improve. I'm afraid that improvement is very hard, given the reality of fraud involving intra-national real estate registration as is exemplified by: https://www.hg.org/legal-articles/legal-options-available-to-victims-of-real-estate-fraud-in-ontario-7376 Real estate fraud in Ontario generally includes "mortgage fraud" (e.g. fraudsters acquire a mortgage fraudulently through false information or identification and run away with the money, leaving the true home owners with a significant liability) and "title fraud" (e.g. fraudsters use stolen identity or forged documents to transfer a registered owner's title to him or herself without the owner's knowledge). How can a real estate or IP address registrar detect "forged documents to transfer a registered owner's title to him or herself without the owner's knowledge", especially when the transfer is international? Also, though I think existing code is applicable to fraud involving IP addresses, its practical applicability for international cases is questionable. Masataka Ohta From rfg at tristatelogic.com Wed Sep 18 21:52:53 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 18 Sep 2019 14:52:53 -0700 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: Message-ID: <51414.1568843573@segfault.tristatelogic.com> In message , Elad Cohen wrote: >Please see the following link: > >https://afrinic.net/resource-certification > >As you can see, a MyAFRINIC account is required. > >Yes, route objects for legacy AFRINIC resources in their RIR operated IRRDB > as a fallback for RPKI can be created and they were created by us. What Mr. Cohen continues to dance around is the inconvenient truth that even if he had an AFRINIC account, this would neither help nor explain his thefts of the several AFRINIC -and- APNIC region blocks that I have already listed here. RIPE Routing History reveals the truth, for anyone who wishes to consult that historical data, and I also have plenty of saved traceroutes for each of those APNIC blocks, as well as all of the others that Mr. Cohen stole from the AFRINIC region. Those were all helpfully routed, until quite recently, to Mr. Cohen, and by Mr. Cohen's dear friends at FDCServers and Cogent. Come now Mr. Cohen, please do tell us who you paid for rights to the 168.198.0.0/16 block, which belongs to the Australian government, and which your pals at Cogent and FDCServers were routing to you until quite recently. Who did you pay and how much did you pay for your "rights" to the City of Cape Town's 165.25.0.0/16 block? It's OK. No need to be shy. Show us the your sales reciepts for those blocks please! We could all use a good laugh today. Alternatively, if you can't or won't show us that, then at least have the decency to admit that you're a liar, a fraud, and a con man, and that until I caught you, you were stealing all of the IPv4 space that wasn't nailed down in both the AFRINIC region and the APNIC region. Did you seriously think that you could get away with all this and that nobody would even notice? If so, then you're even dumber that you look in all of the online pictures of you I've seen. Regards, rfg From job at instituut.net Wed Sep 18 22:01:49 2019 From: job at instituut.net (Job Snijders) Date: Thu, 19 Sep 2019 01:01:49 +0300 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <51414.1568843573@segfault.tristatelogic.com> References: <51414.1568843573@segfault.tristatelogic.com> Message-ID: It would be good to see some receipts, offered by the selling party. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Wed Sep 18 22:14:27 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 07:14:27 +0900 Subject: Elad Cohen In-Reply-To: <51414.1568843573@segfault.tristatelogic.com> References: <51414.1568843573@segfault.tristatelogic.com> Message-ID: <15744848-5638-ad01-2c9c-a89825f9d1b0@necom830.hpcl.titech.ac.jp> Ronald F. Guilmette wrote: > Come now Mr. Cohen, please do tell us who you paid for rights to the > 168.198.0.0/16 block, which belongs to the Australian government, If you think the Australian government haven't transfer its IP address to Mr. Cohen, all you should do is let the Australian government accuse Mr. Cohen. According to: https://www.sydneycriminallawyers.com.au/blog/which-countries-have-extradition-treaties-with-australia/ There are a number of countries that have bilateral extradition arrangements with Australia. These are: Israel the accusation can be effective to people living in Israel. Masataka Ohta From me at anuragbhatia.com Wed Sep 18 22:34:52 2019 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 19 Sep 2019 04:04:52 +0530 Subject: Question about mismatch of origin ASN in parent and more specific route object Message-ID: Hello everyone Trying to understand the case from operators here who generate IRR based filters. Say if a given example: AS X originating 2001:DB8::/32 with IRR route object having AS X in the origin AS X originating 2001:DB8::/48 with IRR route object having AS Y in the origin Now for folks who are generating filters, will your tools filter 2001:DB8::/48 because there's a more specific IRR route object which says AS Y while prefix is coming from AS X? Or since generation is based on ASNs (as known directly or resolved via AS SETs) your tools will just generate filter for AS X allowing 2001:DB8::/32 (upto say /48) and won't really for mismatching route object for 2001:DB8::/48? Thanks. -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Sep 18 22:55:44 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 Sep 2019 18:55:44 -0400 Subject: Question about mismatch of origin ASN in parent and more specific route object In-Reply-To: References: Message-ID: <6259825A-BB26-4DA4-BD46-7414CF56740F@puck.nether.net> > On Sep 18, 2019, at 6:34 PM, Anurag Bhatia wrote: > > Hello everyone > > > Trying to understand the case from operators here who generate IRR based filters. > > > > Say if a given example: > > AS X originating 2001:DB8::/32 with IRR route object having AS X in the origin > AS X originating 2001:DB8::/48 with IRR route object having AS Y in the origin > > > Now for folks who are generating filters, will your tools filter 2001:DB8::/48 because there's a more specific IRR route object which says AS Y while prefix is coming from AS X? > Or since generation is based on ASNs (as known directly or resolved via AS SETs) your tools will just generate filter for AS X allowing 2001:DB8::/32 (upto say /48) and won't really for mismatching route object for 2001:DB8::/48? > Generally you might build the filters one of two ways: 1) with just the ASN, eg: 267 where you would build just with that origin ASN. 2) with the AS-SET, eg: AS-NETHER This includes 2 ASNs (but could also include other things, eg: AS-AKAMAI) and those are also expanded. - Jared From johnl at iecc.com Wed Sep 18 23:30:06 2019 From: johnl at iecc.com (John Levine) Date: 18 Sep 2019 16:30:06 -0700 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: <8580e3e4-98b8-2828-e43f-6115c92faee5@massar.ch> Message-ID: <20190918233006.CC4159EF945@ary.local> In article <8580e3e4-98b8-2828-e43f-6115c92faee5 at massar.ch> you write: >Currently though: > >use-application-dns.net. 172800 IN NS ns-cloud-b1.googledomains.com. >use-application-dns.net. 172800 IN NS ns-cloud-b2.googledomains.com. >use-application-dns.net. 172800 IN NS ns-cloud-b3.googledomains.com. >use-application-dns.net. 172800 IN NS ns-cloud-b4.googledomains.com. Nope. ;; ANSWER SECTION: ;; AUTHORITY SECTION: use-application-dns.net. 172800 IN NS ns4-64.akam.net. use-application-dns.net. 172800 IN NS ns7-66.akam.net. use-application-dns.net. 172800 IN NS ns5-65.akam.net. use-application-dns.net. 172800 IN NS ns1-240.akam.net. $ drill @ns5-65.akam.net. use-application-dns.net a ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48353 ;; flags: qr aa rd ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; use-application-dns.net. IN A ;; ANSWER SECTION: use-application-dns.net. 60 IN A 185.199.108.153 use-application-dns.net. 60 IN A 185.199.109.153 use-application-dns.net. 60 IN A 185.199.111.153 use-application-dns.net. 60 IN A 185.199.110.153 I have this special-cased in my own resolver, of course. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From rfg at tristatelogic.com Wed Sep 18 23:31:27 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 18 Sep 2019 16:31:27 -0700 Subject: Elad Cohen In-Reply-To: <15744848-5638-ad01-2c9c-a89825f9d1b0@necom830.hpcl.titech.ac.jp> Message-ID: <51797.1568849487@segfault.tristatelogic.com> In message <15744848-5638-ad01-2c9c-a89825f9d1b0 at necom830.hpcl.titech.ac.jp>, Masataka Ohta wrote: >Ronald F. Guilmette wrote: > >> Come now Mr. Cohen, please do tell us who you paid for rights to the >> 168.198.0.0/16 block, which belongs to the Australian government, > >If you think the Australian government haven't transfer its IP address >to Mr. Cohen, all you should do is let the Australian government >accuse Mr. Cohen. It is a well known fundamental tenet of logical reasoning and argument that it is not possible for -anyone- to prove a negative, which is what you've just asked me to do. I certainly cannot prove, to any degree of certainty, that the Australian national government, in its infinite wisdom, didn't send one of its stealthy representatives to meet Mr. Cohen in some dark back allley, on some dark night, somewhere in Canberra, and that this mysterious representaive did not meet Mr. Cohen and then sell him the government's rights in, and titles to the 168.198.0.0/16 block. If that had happened, then I wouldn't know about it. None of us would. (And stranger things quite certainly -have- happened when it comes to government corruption.) All I can do is make it quite plain that I believe that this theory of events is somewhere beyond implausible. In any event, it is not for me to prove the negative in this case. Rather, it is incumbant upon Mr. Cohen to prove his implicit -and- explicit affirmative assertion that he has or had some rights (i.e. -any- rights) to the 168.198.0.0/16 block or to any of the numerous other nice juicy and valuable IPv4 blocks, all of size /16 or greater, that he, with the help of his friends, appears to have been using of late. With regards to any of these numerous valuable IPv4 blocks, both legacy and otherwise, Mr. Cohen offers us not a single shread of proof that he has now, or ever had, any rights at all to any of these blocks whatsoever, insisting instead that we all just take his word on faith. Is this the behaviour of an honest man, attempting, reasonably, to defend his reputation and his good name? I think not. Not to put too fine a point on it, but Mr. Cohen is clearly hiding something. And not just one thing, but many things. With respect to the Australian government, none of us needs to wait for it to wake from its slumber in order to know precisely what happened here. If I am on the street, near a school or a University, and if I see a man back a large truck up to a bicycle rack and then see the man get out and use a large set of bolt cutters to cut the locks on bicycle after bicycle, loading them one by one into the truck, then I, for one, do not need to await the arrival of the true owners of said bicycles in order to know that something is seriously amiss -or- to take action to stop what is going on. That may be your approach to such situations, but it is not mine. The difference is what some people might call "civilization" and without it we are all doomed. Regards, rfg P.S. For those who may still harbor any doubts about Mr. Cohen's claims, I encourage you all to speak with a certain Mr. Alister van Tonder, (Alister.vanTonder (at) capetown.gov.za - phone: +27-21-400-9080), a network engineer employed by the City of Cape Town, who I'm sure will be only to happy to describe to you, as he did to me, the efforts that he and his collegues were forced to expend in order to just simply take back the City's rightful property, the 165.25.0.0/16 block, from the clutches of Mr. Cohen and his allies at FDCServers and Cogent. From rgolodner at infratection.com Thu Sep 19 00:28:54 2019 From: rgolodner at infratection.com (Richard) Date: Wed, 18 Sep 2019 19:28:54 -0500 Subject: Elad Cohen, show us! In-Reply-To: <51414.1568843573@segfault.tristatelogic.com> References: <51414.1568843573@segfault.tristatelogic.com> Message-ID: <6ed95c67-584d-1daf-bd6d-98571e3eaf3c@infratection.com> Mr. Guilmette, my curiosity has now been increased as I notice Cogent is no longer supplying routing for the /16's you have spoken of. It certainly would be nice to see Mr. Cohen demonstrate proof of legitimate ownership. I have never seen Cogent behave in this manner unless there really is some nefarious activity in regards to the blocks in question. Please Mr.Cohen, stand up and demonstrate how you obtained so much valuable v4 space. Richard Golodner Infratection IT Services On 9/18/19 4:52 PM, Ronald F. Guilmette wrote: > In message ROD.OUTLOOK.COM>, Elad Cohen wrote: > >> Please see the following link: >> >> https://afrinic.net/resource-certification >> >> As you can see, a MyAFRINIC account is required. >> >> Yes, route objects for legacy AFRINIC resources in their RIR operated IRRDB >> as a fallback for RPKI can be created and they were created by us. > > What Mr. Cohen continues to dance around is the inconvenient truth that > even if he had an AFRINIC account, this would neither help nor explain > his thefts of the several AFRINIC -and- APNIC region blocks that I have > already listed here. > > RIPE Routing History reveals the truth, for anyone who wishes to consult > that historical data, and I also have plenty of saved traceroutes for > each of those APNIC blocks, as well as all of the others that Mr. Cohen > stole from the AFRINIC region. > > Those were all helpfully routed, until quite recently, to Mr. Cohen, and > by Mr. Cohen's dear friends at FDCServers and Cogent. > > Come now Mr. Cohen, please do tell us who you paid for rights to the > 168.198.0.0/16 block, which belongs to the Australian government, and > which your pals at Cogent and FDCServers were routing to you until > quite recently. Who did you pay and how much did you pay for your > "rights" to the City of Cape Town's 165.25.0.0/16 block? > > It's OK. No need to be shy. Show us the your sales reciepts for those > blocks please! We could all use a good laugh today. > > Alternatively, if you can't or won't show us that, then at least have the > decency to admit that you're a liar, a fraud, and a con man, and that > until I caught you, you were stealing all of the IPv4 space that wasn't > nailed down in both the AFRINIC region and the APNIC region. > > Did you seriously think that you could get away with all this and that > nobody would even notice? If so, then you're even dumber that you look > in all of the online pictures of you I've seen. > > > Regards, > rfg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Thu Sep 19 00:31:27 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 09:31:27 +0900 Subject: Elad Cohen In-Reply-To: <51797.1568849487@segfault.tristatelogic.com> References: <51797.1568849487@segfault.tristatelogic.com> Message-ID: Ronald F. Guilmette wrote: > It is a well known fundamental tenet of logical reasoning and argument > that it is not possible for -anyone- to prove a negative, which is what > you've just asked me to do. So, Australian government does not think it is a victim of a crime. Right? > I certainly cannot prove, You don't have to prove. All you have to do is to find an entity which thinks it is a victim of a crime and let the entity accuse. > P.S. For those who may still harbor any doubts about Mr. Cohen's claims, > I encourage you all to speak with a certain Mr. Alister van Tonder, > (Alister.vanTonder (at) capetown.gov.za - phone: +27-21-400-9080), OK. You have found one. Anyone else? Masataka Ohta From sami.joseph at gmail.com Thu Sep 19 00:40:27 2019 From: sami.joseph at gmail.com (Sami Joseph) Date: Wed, 18 Sep 2019 17:40:27 -0700 Subject: Op-Ed : Multi-cloud is a fad ? Message-ID: This article assumes Multi-cloud is a fad because it doesnt offer much value and its like sd-wan, a mere marchitecture. What if these products turn into controllers, working with Equinix and/or carriers to provide cloud-coloco, orchestrated by the cloud. https://medium.com/@kenhuiny/multi-cloud-is-mostly-a-waste-of-time-2d689b25d37f Reasons why there is no value: 1) Geography and Latency Requirements are all great now across the same cloud regions. 2) Mitigation Against Cloud Outages doesnt matter much. 3) Avoidance of Vendor Lock-in is a joke Opinions or facts would both be appreciated. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Thu Sep 19 01:35:01 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 18 Sep 2019 18:35:01 -0700 Subject: Elad Cohen In-Reply-To: Message-ID: <52273.1568856901@segfault.tristatelogic.com> In message , Masataka Ohta wrote: >Ronald F. Guilmette wrote: > >> It is a well known fundamental tenet of logical reasoning and argument >> that it is not possible for -anyone- to prove a negative, which is what >> you've just asked me to do. > >So, Australian government does not think it is a victim of a >crime. Right? That's a two part question. I'll answer each part. Regarding "crime", there are crimes and there are Crimes. It wasn't a Crime, until well after 2008, to sell stupid and naive investors so-called "mortgage backed securities" which turned out to be worthless, based on bogus financial projections. The law had not yet caught up to innovation in the financial sector. But some of the people who were selling this garbage to unsuspecting rubes back in 2008 and earlier knew full well, in their heart of hearts, that they were screwing people. Mulitple email exchanges that came to light after that showed these sellers -joking- about how they were screwing people. The same thing happened also in the case of Enron, whose traders joked in email exchanges about how they were screwing my own home state of California. At present, the law has likewise not caught up to this "innovation" called the Internet. It has had 20+ years to do that, but it still hasn't, in no small part because legislators the world over understand the Internet even less than they now understand mortgage backed securities. So, if you are looking for a Crime here, i.e. one defined under law, there isn't one. But the concepts of stealing and unfairness are even older that the world's so-called oldest profession, and they are so fundamental and apparent that one does not even need to be a "highly evolved" human in order to grasp these moral and ethical principals: https://www.youtube.com/watch?v=meiU6TxysCg In short, stealing is stealing. If I steal a watch out of the pocket of a dead man, it is still stealing, even if there is no specific legislation of the subject, and even if the dead man unhelpfully declines to file a police report on the incident. With respect to the Australian government's knowledge or lack thereof, I really have no idea. If you want to know what they know, or do not know, I encourage you to ask them yourself. It appears that this will be rather easier for you to do, than for me to do, since you are in their same general time zone, and I am not, and thus you have a better shot at reaching them on the phone, during their working hours, than I do. The relevant WHOIS contact info is reproduced below, for your convenience. Regards, rfg ========================================================================= inetnum: 168.198.0.0 - 168.198.255.255 netname: DOFD descr: DOFD Department of Finance and Deregulation descr: Australian Government country: AU admin-c: FIAR1-AP tech-c: FIAR1-AP status: ALLOCATED PORTABLE mnt-by: APNIC-HM mnt-lower: MAINT-AU-DOFD mnt-routes: MAINT-AU-DOFD mnt-irt: IRT-DOFD-AU last-modified: 2013-07-24T04:25:39Z source: APNIC irt: IRT-DOFD-AU address: John Gorton Building, King Edward Terrace, Parkes ACT 2600 e-mail: ipaddressing(at)finance.gov.au abuse-mailbox: ipaddressing(at)finance.gov.au admin-c: FIAR1-AP tech-c: FIAR1-AP auth: # Filtered mnt-by: MAINT-AU-DOFD last-modified: 2013-07-23T04:50:09Z source: APNIC role: Finance Internet Address Registry - CIOD address: John Gorton Building, King Edward Terrace, Parkes ACT 2600 country: AU phone: + 61 2 6215 2222 e-mail: ipaddressing(at)finance.gov.au admin-c: FIAR1-AP tech-c: FIAR1-AP nic-hdl: FIAR1-AP mnt-by: MAINT-AU-DOFD last-modified: 2013-07-23T04:27:45Z source: APNIC From morrowc.lists at gmail.com Thu Sep 19 01:57:54 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Sep 2019 21:57:54 -0400 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: References: <51414.1568843573@segfault.tristatelogic.com> Message-ID: I tried to ask this earlier, I think, but... "who cares about the sale?" I ask this because I think getting wrapped around that axle is the wrong place to spend resources. If the outcome of 'someone' controlling IP space is that there is abusive activity coming from that space and either no actions are taken to correct that, OR the problem is endemic and there is no change over time, then the action the community should take is not accepting routes to these prefixes. Once everyone (or enough everyones) stop accepting packets/paths the address space isn't important anymore. If the 'rightful owners' of the space need/want it back there's clear redress for them via their RIR and the various networks which are / were offering transit to these prefixes. -chris On Wed, Sep 18, 2019 at 6:02 PM Job Snijders wrote: > > It would be good to see some receipts, offered by the selling party. From ben at 6by7.net Thu Sep 19 03:19:18 2019 From: ben at 6by7.net (Ben Cannon) Date: Wed, 18 Sep 2019 20:19:18 -0700 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: References: <51414.1568843573@segfault.tristatelogic.com> Message-ID: <9BAD8173-B894-4A31-86D1-2128325B867E@6by7.net> With the difficulty of getting IPs off SPAM RBLs being what they are, I’m not sure I like the bone-chilling idea of accepting null-routing entire ranges as standard practice. Same reasons, no central repository, no easy/quick/objective/cheap way to remove an illegitimate entry - and then the real problem, there’s just 6 billion of them now and they’re all over the place and you’re listed in one of them probably no matter who you are. -Ben. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Sep 18, 2019, at 6:57 PM, Christopher Morrow wrote: > > I tried to ask this earlier, I think, but... > > "who cares about the sale?" > > I ask this because I think getting wrapped around that axle is the > wrong place to spend resources. > If the outcome of 'someone' controlling IP space is that there is > abusive activity coming from that space and either no actions are > taken to correct that, OR the problem is endemic and there is no > change over time, then the action the community should take is not > accepting routes to these prefixes. Once everyone (or enough > everyones) stop accepting packets/paths the address space isn't > important anymore. > > If the 'rightful owners' of the space need/want it back there's clear > redress for them via their RIR and the various networks which are / > were offering transit to these prefixes. > > -chris > > On Wed, Sep 18, 2019 at 6:02 PM Job Snijders wrote: >> >> It would be good to see some receipts, offered by the selling party. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Sep 19 03:30:41 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Sep 2019 23:30:41 -0400 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <9BAD8173-B894-4A31-86D1-2128325B867E@6by7.net> References: <51414.1568843573@segfault.tristatelogic.com> <9BAD8173-B894-4A31-86D1-2128325B867E@6by7.net> Message-ID: On Wed, Sep 18, 2019 at 11:19 PM Ben Cannon wrote: > With the difficulty of getting IPs off SPAM RBLs being what they are, I’m > not sure I like the bone-chilling idea of accepting null-routing entire > ranges as standard practice. > I didn't say spam-rbl. > > Same reasons, no central repository, no easy/quick/objective/cheap way to > remove an illegitimate entry - and then the real problem, there’s just 6 > billion of them now and > they’re all over the place and you’re listed in one of them probably no > matter who you are. > > -Ben. > > -Ben Cannon > CEO 6x7 Networks & 6x7 Telecom, LLC > ben at 6by7.net > > > > On Sep 18, 2019, at 6:57 PM, Christopher Morrow > wrote: > > I tried to ask this earlier, I think, but... > > "who cares about the sale?" > > I ask this because I think getting wrapped around that axle is the > wrong place to spend resources. > If the outcome of 'someone' controlling IP space is that there is > abusive activity coming from that space and either no actions are > taken to correct that, OR the problem is endemic and there is no > change over time, then the action the community should take is not > accepting routes to these prefixes. Once everyone (or enough > everyones) stop accepting packets/paths the address space isn't > important anymore. > > If the 'rightful owners' of the space need/want it back there's clear > redress for them via their RIR and the various networks which are / > were offering transit to these prefixes. > > -chris > > On Wed, Sep 18, 2019 at 6:02 PM Job Snijders wrote: > > > It would be good to see some receipts, offered by the selling party. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Thu Sep 19 05:22:10 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 14:22:10 +0900 Subject: Elad Cohen In-Reply-To: <52273.1568856901@segfault.tristatelogic.com> References: <52273.1568856901@segfault.tristatelogic.com> Message-ID: Ronald F. Guilmette wrote: > So, if you are looking for a Crime here, i.e. one defined under law, > there isn't one. You don't know how broadly crime of fraud is defined by the current code. Just injecting false route information may not be a crime. However, doing so for financial gain maybe a crime of fraud. False registration for financial gain by deceiving a registrar is definitely a crime, regardless of what is registered. See the actual code: https://www.legislation.gov.au/Details/C2015C00507 134.2 Obtaining a financial advantage by deception (1) A person is guilty of an offence if (a) the person, by a deception, dishonestly obtains a financial advantage from another person; and 135.1 General dishonesty (1) A person is guilty of an offence if: (a) the person does anything with the intention of dishonestly obtaining a gain from another person; and (3) A person is guilty of an offence if: (a) the person conspires with another person with the intention of dishonestly causing a loss to a third person; and (5) A person is guilty of an offence if: (a) the person conspires with another person to dishonestly cause a loss, or to dishonestly cause a risk of loss, to a third person; and (b) the first‑mentioned person knows or believes that the loss will occur or that there is a substantial risk of the loss occurring; and Australian code on fraud is very similar to that of Japan. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Sep 19 05:50:56 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 14:50:56 +0900 Subject: Any Australian? (was Re: Elad Cohen) In-Reply-To: <52273.1568856901@segfault.tristatelogic.com> References: <52273.1568856901@segfault.tristatelogic.com> Message-ID: <0acf6472-99da-0ece-6b88-afb7abf38eb9@necom830.hpcl.titech.ac.jp> Ronald F. Guilmette wrote: > With respect to the Australian government's knowledge or lack thereof, > I really have no idea. If you want to know what they know, or do not > know, I encourage you to ask them yourself. It appears that this will > be rather easier for you to do, than for me to do, since you are in their > same general time zone, and I am not, and thus you have a better shot > at reaching them on the phone, during their working hours, than I do. As weekly routing table report is still coming from APNIC/potaroo, isn't Geoff Huston or someone around him here? Masataka Ohta From mehmet at akcin.net Thu Sep 19 06:37:51 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 19 Sep 2019 01:37:51 -0500 Subject: Colombia Network Operators Group Message-ID: Hello there Few people who is doing a lot of work in Colombia, we decided to start Colombia network operators group and arrange local meetups, provide people support who want to have infrastructure here. Feel free to join www.nog.com.co and our first face to face meeting will be in december, date to be announced soon! Cheers! Mwhmwt -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Thu Sep 19 08:04:43 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 19 Sep 2019 01:04:43 -0700 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: Message-ID: <53490.1568880283@segfault.tristatelogic.com> In message Christopher Morrow wrote: >"who cares about the sale?" My apologies. I see that I have failed to be adequately clear. There was no "sale". There was only theft, and then stolen goods being passed from hand to hand to hand, ultimately ending up in the hands of Mr. Cohen, who has acted and who is still acting, even as we speak, as the penultimate monitizer of these purloined resources, with the ongoing and helpful endorsement, I should note, of the Merit RADB data base: https://pastebin.com/raw/115RifX3 https://pastebin.com/raw/r9SRMJJk Please note in particular, in that first file, Mr. Cohen's route object for the entire 196.16.0.0/14 block... a block which AFRINIC historical WHOIS records show clearly was and is the rightful property of a thing called "Infoplan", which was the South African national government's captive IT services arm until the passage of the "SITA Act" (1998) in South Africa, by whose express and explict terms what used to be "Infoplan" was subsumed and taken over, lock, stock and barrel, by the South African government's newly formed replacement captive IT services provider, The State Information and Technology Agency (SITA): https://pastebin.com/raw/cXLy6QYf But apparently, by some miracle of persuasiveness, in addition to making the Right Friends inside that Australian national government AND inside the administration of the City of Cape Town... at least briefly... Mr. Cohen also also deftly persuaded the national government of South Africa that they really didn't need that $4 million dollar (USD) IPv4 asset after all (i.e. the 196.16.0.0/14 block) and that they should sell it to him for an as yet undisclosed price. >If the outcome of 'someone' controlling IP space is that there is >abusive activity coming from that space... Nobody knows what the hell is really going on with that space or what Mr. Cohen's customers need quite so much IPv4 space for... an amount that lots of folks in the ARIN region would kill for. I tried to make some polite inquiries with one of Mr. Cohen's apparent better and more noteworthy customers, and I am still awaiting some reply, adequate or otherwise, from that company. In the meantime, Mr. Cohen's English language web site became notably scrubbed of the glowing customer testimonials with which it had been previously adorned, shortly before I started asking questions. Nothing at all suspicious about that, now is there? It would appear that at least one of the companies that are Mr. Cohen's best customers, and that had previously given Mr. Cohen's company glowing testimonials no longer wish to have their company names associated with him or his company, at least not in public. Now why do you suppose that might be? And what are THEY doing with the large and illicitly snatched IPv4 blocks that he has leased to them? In due course, I will have more to say about Mr. Cohen's customers and what I believe them to be up to, based on the evidence. >If the 'rightful owners' of the space need/want it back there's clear >redress for them via their RIR and the various networks which are / >were offering transit to these prefixes. No, actually, there isn't, and that's the point. Firstly, the RIRs are not the Internet Police, and by and large they are adamantly unwilling (and allegedly even unable) to interject even so much as their views or firmly held beliefs into the global BGP system of routing. In fact, the overwhelming majority of them are so throughly cowed, both by their memberships and their respective legal teams, that they dare not even speak the truth of whether it is night or day for fear of such public pronouncements being the cause of subsequent litigation. With regards to transit providers, Mr. Cohen and his ill-gotten resorces have now, at long last, been 100% kicked off of Cogent, indicating that even they, at least, find it no longer plausibly deniable that most or all of Mr. Cohen's allegedly purchased IPv4 space just simply doesn't belong to him. It only took them about 15 days of fiddling to finally come around to this inescapable conclusion, but better late than never. With regards to to the various relevant transit providers for the small group of commonly-owned Dutch networks to which Mr. Cohen has, of late, been migrating his booty, I have already spent more than a week, politely browbeating all of these transit providers, as well as an official at AMS-IX, and I have tried my best to acquaint them all with the plain facts of this case. The net effect of all this effort on my part has been that AMS-IX has shrugged and told me that there is simply nothing they can do, and the transit providers have politely informed me that they are all "still investigating". Meanwhile, Mr. Cohen continues to laugh all the way to the bank, and continues to enjoy much connectivity, centered primarily in Amsterdam, and all of it apparently immune to anything resembling "peer pressure". Th net effects of my sincere entreaties, over the past week or more, to the various relevant transit providers, and to AMS-IX, do not appear to have been materially influenced at all by me sharing with all of these folks the information that the following commonly-owned and mutually interconnected Dutch "bullet proof" networks seem to be Mr. Cohen's destination of choice these days: Novogara, ltd. -- AS204655 FiberXpress -- AS57717 **** Reba Holding -- AS56611 **** IP Volume, Inc. -- AS202425 **** SpectraIP, B.V. -- AS62068 (The ASNs with the asterisks above are all residents in AMS-IX.) The above named networks and companies can all quite easily be tied directly to two Dutch gentlemen named Ferdinand Reinier Van Eeden and Bartholomeus Johannes ("Bap") Karreman. All available public records point to the conclusion that these two gentlemen, or perhaps Mr. Van Eeden alone, are the proprietors -and- owners of all of the above named companies and networks. Why they need quite so many is something I leave for them to comment on, if they so wish. It is worthy of note however that many most or all of the IPv4 blocks currently assigned, by RIPE to what is nowadays called "IP volume, Inc."... an entity allegedly incorporated in the Seychelles Islands... were blocks that were prevously the property of the bullet proof Dutch hosting company known, until its disapperance, as Ecatel, and that these same blocks were then the property of the Dutch bullet proof hosting network known as Quasi Networks, until it's disapperance, in turn. https://pastebin.com/raw/9zft6eVZ https://pastebin.com/raw/6czXQVTg https://pastebin.com/raw/Y1j5B1cp Based on the historical record, one could be forgiven, I think, for inferring that Mr. Van Eeden and Mr. Karreman, in the form of their various corporate personas, may have repeatedly changed their stripes in order to avoid scrutiny and/or to dodge the bad publicity associated with their prior and now defunct networking company facades. I mean seriously... Who would today guess that IP Volume, or either Mr. Van Eeden or Mr. Karreman had ever had anything at all to do with the now dissolved Quasi Networks, a company that even Dhia Mahjoub, head of Cicso's Umbrella network security division characterized, in his RIPE-77 presentation, as an unrepentant "bullet proof hoster"? (See slide 11, lower right.) https://ripe77.ripe.net/wp-content/uploads/presentations/134-RIPE77_Anti_Abuse_WG.pdf So now, it seems, after having had their prior bullet proof corporate entities become of such ill-repute that they became a hidrance, rather than a help, Mr. Van Eeden and Mr. Karreman have now discovered the advantages of the Seychelles Islands, where questions can be asked, but where none are ever answered. (Mind you that is -only- where Mr. Van Eeden's and Mr. Karreman's latest business venture is incorpotated. The acutual network is still very firmly in place in Amsterdam, as far as I can tell.) And now that the demonstratably ethical Mr. Cohen has had his ass kicked to the curb by even Cogent, he has signed up for routing service with the ever socially-responsible Mr. Van Eeden and Mr. Karreman. Who woulda thunk it! The important take away is that all of these clowns and crooks are still very much in business, as we speak and, as I have said, laughing all the way to the bank. The transit providers and AMS-IX all apparently need something more than I have it in my power to give them, before they can be persuaded to drop all of these mischievous turkeys, as they all quite certainly should. In the case of AMS-IX, it is my sincere hope that it will not again require another unfortunate confrontation with Spamhaus in order to bring them around to yet another "Come To Jesus" moment, but at present they do appear bent on defending their rights to do the indefensible, despite anything approximating reasoned argument... as has happened before in their case. I never like to generalize to entire populations, and I will therefore refrain from suggesting any endemic or widespread defect in the Dutch national psyche, but I cannot help but note that, as pointed out in the MyBroadband.co.za news report, a gentleman named Maikel Uerlings, who is also Dutch, and who presently appears to be notably absent from the Netherlands, perhaps due to certain less-than-friendly legal entanglements, is also, it appears, intimately connected to Mr. Cohen and to his business, such as it is. It would be entirely improper for me to say or even to suggest that the Dutch are any more inclined toward cybercrime, or toward looking the other way while it takes place, than anyone else. I will instead only paraphrase William Shakespeare and say that there is something rotten in the Netherlands, and that whatever it is, it ain't doing their national reputation any good at all. I continue to hope that they themselves will rectify that in short order. Regards, rfg From rfg at tristatelogic.com Thu Sep 19 08:22:24 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 19 Sep 2019 01:22:24 -0700 Subject: Elad Cohen In-Reply-To: Message-ID: <53564.1568881344@segfault.tristatelogic.com> In message , Masataka Ohta wrote: >Ronald F. Guilmette wrote: > > > So, if you are looking for a Crime here, i.e. one defined under law, > > there isn't one. > >You don't know how broadly crime of fraud is defined by the current code. > >Just injecting false route information may not be a crime. > >However, doing so for financial gain maybe a crime of fraud. I guess that there is something that either you, or perhaps I, are not understanding here. Did you mean to suggest that either Mr. Cohen or any of the friendly networks that he has persuaded to announce routes for him (by paying them to do so) are doing any of this just for their health? Financial gain appears to me to be the obvious motivation for all of this. >False registration for financial gain by deceiving a registrar >is definitely a crime, regardless of what is registered. > >See the actual code: > > https://www.legislation.gov.au/Details/C2015C00507 Allow me to clarify. In the case if the APNIC region blocks that I have called out, I have -no- evidence to suggest that there has been any deception or untoward manipulation of registry information whatsoever. With respect to the AFRINIC region blocks I have called out, if you have a relevant citation from the criminal code of the island nation of Mauritius, I would be most appreciative if you would share that with me. It may come in handy at some point. Regards, rfg From niels=nanog at bakker.net Thu Sep 19 08:46:49 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Thu, 19 Sep 2019 10:46:49 +0200 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <53490.1568880283@segfault.tristatelogic.com> References: <53490.1568880283@segfault.tristatelogic.com> Message-ID: <20190919084649.GC30112@jima.tpb.net> * rfg at tristatelogic.com (Ronald F. Guilmette) [Thu 19 Sep 2019, 10:05 CEST]: >I never like to generalize to entire populations, and I will >therefore refrain from suggesting any endemic or widespread defect >in the Dutch national psyche, but I cannot help but note that, as >pointed out in the MyBroadband.co.za news report, a gentleman named >Maikel Uerlings, who is also Dutch, and who presently appears to be >notably absent from the Netherlands, perhaps due to certain >less-than-friendly legal entanglements, is also, it appears, >intimately connected to Mr. Cohen and to his business, such as it >is. It would be entirely improper for me to say or even to suggest >that the Dutch are any more inclined toward cybercrime, or toward >looking the other way while it takes place, than anyone else. I >will instead only paraphrase William Shakespeare and say that there >is something rotten in the Netherlands, and that whatever it is, it >ain't doing their national reputation any good at all. Couching your racism in some faux plausible deniability by using phrases such as "It would be entirely improper of me to" or "I will refrain from [making a certain racist suggestion]" and then immediately making that racist suggestion, doesn't make your remarks not racist. Nor can you hide behind the classics. Racism has no place in this community and you would do well to refrain from posting any more such remarks. -- Niels. From elad at netstyle.io Thu Sep 19 09:33:45 2019 From: elad at netstyle.io (Elad Cohen) Date: Thu, 19 Sep 2019 09:33:45 +0000 Subject: Elad Cohen In-Reply-To: <53564.1568881344@segfault.tristatelogic.com> References: , <53564.1568881344@segfault.tristatelogic.com> Message-ID: Mr. Ronald Guilmette Everything you did and you wrote in this forum until today, including mudslinging and slandering, including thieves and crooks, they are libel for all intents and purposes with everything it implies, and this without to display any proof. We return and say, in our hands are all the agreements of the purchases that we've purchased properly with our best money. It is hinted from your tongue-lashing, that you are connected clearly with Spamhaus and ARIN, that have an interest to receive the ranges, following the increase of value of the ranges in the free market and the lack of them. All of this subject was transferred to our lawyers, due to the mudslinging and slandering and the nicknames you wrote thieves and crooks in this forum, a libel suit against you will be filed with a high amount, of course that all of the written proofs an agreements regarding the legal purchases that we've made will be added to the libel suit. Copies: Mr. Bennet Kelley ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Thursday, September 19, 2019 11:22 AM To: nanog at nanog.org Subject: Re: Elad Cohen In message , Masataka Ohta wrote: >Ronald F. Guilmette wrote: > > > So, if you are looking for a Crime here, i.e. one defined under law, > > there isn't one. > >You don't know how broadly crime of fraud is defined by the current code. > >Just injecting false route information may not be a crime. > >However, doing so for financial gain maybe a crime of fraud. I guess that there is something that either you, or perhaps I, are not understanding here. Did you mean to suggest that either Mr. Cohen or any of the friendly networks that he has persuaded to announce routes for him (by paying them to do so) are doing any of this just for their health? Financial gain appears to me to be the obvious motivation for all of this. >False registration for financial gain by deceiving a registrar >is definitely a crime, regardless of what is registered. > >See the actual code: > > https://www.legislation.gov.au/Details/C2015C00507 Allow me to clarify. In the case if the APNIC region blocks that I have called out, I have -no- evidence to suggest that there has been any deception or untoward manipulation of registry information whatsoever. With respect to the AFRINIC region blocks I have called out, if you have a relevant citation from the criminal code of the island nation of Mauritius, I would be most appreciative if you would share that with me. It may come in handy at some point. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Sep 19 09:42:50 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 19 Sep 2019 09:42:50 +0000 Subject: Elad Cohen In-Reply-To: References: , <53564.1568881344@segfault.tristatelogic.com>, Message-ID: I think it’s time to take this name-calling, libel-threatening tirade off of Nanog, gentlemen. I can’t see any further relevance in this discussion to Nanog’s mission of operational issues, and you all just burn CPU cycles the rest of us don’t want to give up. Have a nice day. -mel beckman On Sep 19, 2019, at 2:34 AM, Elad Cohen > wrote: Mr. Ronald Guilmette Everything you did and you wrote in this forum until today, including mudslinging and slandering, including thieves and crooks, they are libel for all intents and purposes with everything it implies, and this without to display any proof. We return and say, in our hands are all the agreements of the purchases that we've purchased properly with our best money. It is hinted from your tongue-lashing, that you are connected clearly with Spamhaus and ARIN, that have an interest to receive the ranges, following the increase of value of the ranges in the free market and the lack of them. All of this subject was transferred to our lawyers, due to the mudslinging and slandering and the nicknames you wrote thieves and crooks in this forum, a libel suit against you will be filed with a high amount, of course that all of the written proofs an agreements regarding the legal purchases that we've made will be added to the libel suit. Copies: Mr. Bennet Kelley ________________________________ From: NANOG > on behalf of Ronald F. Guilmette > Sent: Thursday, September 19, 2019 11:22 AM To: nanog at nanog.org > Subject: Re: Elad Cohen In message >, Masataka Ohta > wrote: >Ronald F. Guilmette wrote: > > > So, if you are looking for a Crime here, i.e. one defined under law, > > there isn't one. > >You don't know how broadly crime of fraud is defined by the current code. > >Just injecting false route information may not be a crime. > >However, doing so for financial gain maybe a crime of fraud. I guess that there is something that either you, or perhaps I, are not understanding here. Did you mean to suggest that either Mr. Cohen or any of the friendly networks that he has persuaded to announce routes for him (by paying them to do so) are doing any of this just for their health? Financial gain appears to me to be the obvious motivation for all of this. >False registration for financial gain by deceiving a registrar >is definitely a crime, regardless of what is registered. > >See the actual code: > > https://www.legislation.gov.au/Details/C2015C00507 Allow me to clarify. In the case if the APNIC region blocks that I have called out, I have -no- evidence to suggest that there has been any deception or untoward manipulation of registry information whatsoever. With respect to the AFRINIC region blocks I have called out, if you have a relevant citation from the criminal code of the island nation of Mauritius, I would be most appreciative if you would share that with me. It may come in handy at some point. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Sep 19 09:47:42 2019 From: elad at netstyle.io (Elad Cohen) Date: Thu, 19 Sep 2019 09:47:42 +0000 Subject: Elad Cohen, show us! In-Reply-To: <6ed95c67-584d-1daf-bd6d-98571e3eaf3c@infratection.com> References: <51414.1568843573@segfault.tristatelogic.com>, <6ed95c67-584d-1daf-bd6d-98571e3eaf3c@infratection.com> Message-ID: Hello Richard, It is not related to nefarious activity as you wrote, FDCServers policy is to stop routing any ranges which is in Spamhaus SBL (no matter what), due to the phear from Spamhaus to list all of FDCServers ranges in SBL, which was told to us in a documented phone call, listing all of the ranges by Spamhaus is a known agrressive and bullying tactic by Spamhaus as you can find in many webpages online. You can find the same aggressive Spamhaus bullying tactic written here by Ronald Guilmette vs AMS-IX: "In the case of AMS-IX, it is my sincere hope that it will not again require another unfortunate confrontation with Spamhaus in order to bring them around to yet another "Come To Jesus" moment, but at present they do appear bent on defending their rights to do the indefensible, despite anything approximating reasoned argument... as has happened before in their case." ________________________________ From: NANOG on behalf of Richard Sent: Thursday, September 19, 2019 3:28 AM To: nanog at nanog.org Subject: Elad Cohen, show us! Mr. Guilmette, my curiosity has now been increased as I notice Cogent is no longer supplying routing for the /16's you have spoken of. It certainly would be nice to see Mr. Cohen demonstrate proof of legitimate ownership. I have never seen Cogent behave in this manner unless there really is some nefarious activity in regards to the blocks in question. Please Mr.Cohen, stand up and demonstrate how you obtained so much valuable v4 space. Richard Golodner Infratection IT Services On 9/18/19 4:52 PM, Ronald F. Guilmette wrote: In message , Elad Cohen wrote: Please see the following link: https://afrinic.net/resource-certification As you can see, a MyAFRINIC account is required. Yes, route objects for legacy AFRINIC resources in their RIR operated IRRDB as a fallback for RPKI can be created and they were created by us. What Mr. Cohen continues to dance around is the inconvenient truth that even if he had an AFRINIC account, this would neither help nor explain his thefts of the several AFRINIC -and- APNIC region blocks that I have already listed here. RIPE Routing History reveals the truth, for anyone who wishes to consult that historical data, and I also have plenty of saved traceroutes for each of those APNIC blocks, as well as all of the others that Mr. Cohen stole from the AFRINIC region. Those were all helpfully routed, until quite recently, to Mr. Cohen, and by Mr. Cohen's dear friends at FDCServers and Cogent. Come now Mr. Cohen, please do tell us who you paid for rights to the 168.198.0.0/16 block, which belongs to the Australian government, and which your pals at Cogent and FDCServers were routing to you until quite recently. Who did you pay and how much did you pay for your "rights" to the City of Cape Town's 165.25.0.0/16 block? It's OK. No need to be shy. Show us the your sales reciepts for those blocks please! We could all use a good laugh today. Alternatively, if you can't or won't show us that, then at least have the decency to admit that you're a liar, a fraud, and a con man, and that until I caught you, you were stealing all of the IPv4 space that wasn't nailed down in both the AFRINIC region and the APNIC region. Did you seriously think that you could get away with all this and that nobody would even notice? If so, then you're even dumber that you look in all of the online pictures of you I've seen. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Thu Sep 19 10:02:53 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 19 Sep 2019 19:02:53 +0900 Subject: Elad Cohen In-Reply-To: <53564.1568881344@segfault.tristatelogic.com> References: <53564.1568881344@segfault.tristatelogic.com> Message-ID: Ronald F. Guilmette wrote: >> Just injecting false route information may not be a crime. >> >> However, doing so for financial gain maybe a crime of fraud. > > I guess that there is something that either you, or perhaps I, are not > understanding here. > Financial gain appears to me to be the obvious motivation for all > of this. You still don't understand what are the "elements" of a crime of fraud, even though the code explicitly state: (1) A person is guilty of an offence if (a) the person, by a deception, dishonestly obtains a financial advantage from another person; and which means prosecutors must prove existence of "financial advantage" in court with evidences even if you think it obvious. > In the case if the APNIC region blocks that I have called out, I have -no- > evidence to suggest that there has been any deception or untoward manipulation > of registry information whatsoever. For the purpose of criminal prosecution, it is enough if someone in APNIC, Merit, FDCservers or Cogent is deceived. As, according to you, false route is actually advertised, someone should be deceived. > With respect to the AFRINIC region blocks I have called out, if you have a > relevant citation from the criminal code of the island nation of Mauritius, > I would be most appreciative if you would share that with me. It may come > in handy at some point. I'm afraid code more useful to a person living in Zambia is that of Zambia. Anyway, in any country where registration fraud of real estate is criminal, which practically means in all the countries, registration fraud of IPv4 address is criminal. A problem, however, is that prosecution in Zambia or Mauritius may not be very effective to a person living in Israel. Anyway, as accusation is free, you may try. Masataka Ohta From rfg at tristatelogic.com Thu Sep 19 10:12:07 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 19 Sep 2019 03:12:07 -0700 Subject: Elad Cohen In-Reply-To: Message-ID: <54360.1568887927@segfault.tristatelogic.com> In message , Elad Cohen wrote: >Mr. Ronald Guilmette > >Everything you did and you wrote in this forum until today, including mud- >slinging and slandering, including thieves and crooks, they are libel for all >intents and purposes with everything it implies, and this without to >display any proof. > >We return and say, in our hands are all the agreements of the purchases that >we've purchased properly with our best money. Mr. Cohen, I'm sure that I speak for many when I say that we all very much look forward to seeing the unredacted copies of those alleged purchase agreements, whenever you can take time out from your busy schedule to produce them. It would also be helpful if you would include whatever additional documents, as may be necessary, to demonstrate convincingly that whoever you allegedly bought the blocks from came by them honestly, and not due to some earlier skulduggery, particularly the ones I have already mentioned, e.g. the 168.198.0.0/16 block, the 139.44.0.0/16 block, the 165.25.0.0/16 block, and not least the Infoplan/SITA block, 196.16.0.0/14. >It is hinted from your tongue-lashing, that you are connected clearly with >Spamhaus and ARIN, that have an interest to receive the ranges, following >the increase of value of the ranges in the free market and the lack of them. Gosh darm it! You caught me! I'm really a stealth IP speculator. I didn't want it publicly known that I have been sitting all this time on an enormous stash of no fewer than two whole IPv4 addresses. I also didn't want it known that I am actually in league with Spamhaus, ARIN, Vladimir Putin, the Marx Brothers, Boris Johnson, Ricky Gervais, and oh yes, Beelzebub. But now that the cat is out of the bag, I might as well fess up. Yes, we have all been plotting together to steal your valuable stash of IPv4 addresses, and in fact, Cogent is in on the plot too. I would have told you sooner, but I was busy eating children... with a nice chianti, of course. >All of this subject was transferred to our lawyers, due to the mudslinging >and slandering and the nicknames you wrote thieves and crooks in this forum >a libel suit against you will be filed with a high amount, of course that >all of the written proofs an agreements regarding the legal purchases that >we've made will be added to the libel suit. Is the official NANOG historian in the house? I just want to ruling on this. Am I the first and only person who has ever received a cartooney directly on the NANOG list? I just want to know if I can go ahead and contact the Guinness people, and get this unique feat recorded officially. Regards, rfg From fohdeesha at gmail.com Thu Sep 19 10:21:46 2019 From: fohdeesha at gmail.com (Jon Sands) Date: Thu, 19 Sep 2019 06:21:46 -0400 Subject: Elad Cohen In-Reply-To: <54360.1568887927@segfault.tristatelogic.com> References: <54360.1568887927@segfault.tristatelogic.com> Message-ID: On 9/19/2019 6:12 AM, Ronald F. Guilmette wrote: > > I just want to ruling on this. Am I the first and only person who has ever > received a cartooney directly on the NANOG list? I can't remember if it was over NANOG or not, but back in 2010 a good friend of mine Mike Bailey (now deceased) received similar bold faced legal threats (mostly threats of DMCA if I remember right) from FDC Servers when he exposed to the WHT forums that they were at the time using power strips daisy chained, motherboards sitting on cardboard, etc in their chicago datacenter - he documented with pictures a number of fire code violations and was threatened with DMCA notices for it. Sadly the pictures no longer load, but oh boy were they special: https://web.archive.org/web/20100228172939/http://ub3r.net/fdc/readme.htm I do agree though, this should probably be taken way off-list. -- Jon Sands MFI Labs https://fohdeesha.com/ From florianb at globalone.io Thu Sep 19 10:23:13 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Thu, 19 Sep 2019 12:23:13 +0200 Subject: Elad Cohen In-Reply-To: <54360.1568887927@segfault.tristatelogic.com> References: <54360.1568887927@segfault.tristatelogic.com> Message-ID: <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2@globalone.io> Hello Ronald, I don’t particularly side with any party here, but as already made clear indirectly by my passive aggressive tone on your trace route (which was nothing but a route loop in cogent’s network), I do certainly disagree with the way you treat Mr. Cohen. This comes due to the nature that whilst this whole story might be quite funny and interesting to follow, this is certainly not a place where you can slander his name or anyone associated with him in any manner for the entertainment of everyone. It is - at least speaking for myself - fairly interesting to follow the development of this story, but then again you act a lot like you just want to slander Mr. Cohen and his affiliates instead of doing this is some sort of general pointing out (which then again defeats the point of taking this on the list). Perhaps keeping messages to the list limited to updates with actual proof behind might be the way forward instead of starting a legal war. Keep in mind, I’m not even judging here if what happens is legitimate or not. — Florian > On 19.09.2019, at 12:12, Ronald F. Guilmette wrote: > > In message ROD.OUTLOOK.COM>, Elad Cohen wrote: > >> Mr. Ronald Guilmette >> >> Everything you did and you wrote in this forum until today, including mud- >> slinging and slandering, including thieves and crooks, they are libel for all >> intents and purposes with everything it implies, and this without to >> display any proof. >> >> We return and say, in our hands are all the agreements of the purchases that >> we've purchased properly with our best money. > > Mr. Cohen, > > I'm sure that I speak for many when I say that we all very much look > forward to seeing the unredacted copies of those alleged purchase > agreements, whenever you can take time out from your busy schedule to > produce them. > > It would also be helpful if you would include whatever additional documents, > as may be necessary, to demonstrate convincingly that whoever you allegedly > bought the blocks from came by them honestly, and not due to some earlier > skulduggery, particularly the ones I have already mentioned, e.g. the > 168.198.0.0/16 block, the 139.44.0.0/16 block, the 165.25.0.0/16 block, > and not least the Infoplan/SITA block, 196.16.0.0/14. > >> It is hinted from your tongue-lashing, that you are connected clearly with >> Spamhaus and ARIN, that have an interest to receive the ranges, following >> the increase of value of the ranges in the free market and the lack of them. > > Gosh darm it! You caught me! I'm really a stealth IP speculator. I didn't > want it publicly known that I have been sitting all this time on an enormous > stash of no fewer than two whole IPv4 addresses. I also didn't want it > known that I am actually in league with Spamhaus, ARIN, Vladimir Putin, > the Marx Brothers, Boris Johnson, Ricky Gervais, and oh yes, Beelzebub. > But now that the cat is out of the bag, I might as well fess up. Yes, > we have all been plotting together to steal your valuable stash of IPv4 > addresses, and in fact, Cogent is in on the plot too. I would have told > you sooner, but I was busy eating children... with a nice chianti, of > course. > >> All of this subject was transferred to our lawyers, due to the mudslinging >> and slandering and the nicknames you wrote thieves and crooks in this forum >> a libel suit against you will be filed with a high amount, of course that >> all of the written proofs an agreements regarding the legal purchases that >> we've made will be added to the libel suit. > > Is the official NANOG historian in the house? > > I just want to ruling on this. Am I the first and only person who has ever > received a cartooney directly on the NANOG list? > > I just want to know if I can go ahead and contact the Guinness people, and > get this unique feat recorded officially. > > > Regards, > rfg From elad at netstyle.io Thu Sep 19 10:25:40 2019 From: elad at netstyle.io (Elad Cohen) Date: Thu, 19 Sep 2019 10:25:40 +0000 Subject: Elad Cohen In-Reply-To: <54360.1568887927@segfault.tristatelogic.com> References: , <54360.1568887927@segfault.tristatelogic.com> Message-ID: Mr. Ronald Guilmette You are the only person that called us thieves and crooks without any proof and for that we will discuss in the lawsuit against you. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Thursday, September 19, 2019 1:12 PM To: nanog at nanog.org Subject: Re: Elad Cohen In message , Elad Cohen wrote: >Mr. Ronald Guilmette > >Everything you did and you wrote in this forum until today, including mud- >slinging and slandering, including thieves and crooks, they are libel for all >intents and purposes with everything it implies, and this without to >display any proof. > >We return and say, in our hands are all the agreements of the purchases that >we've purchased properly with our best money. Mr. Cohen, I'm sure that I speak for many when I say that we all very much look forward to seeing the unredacted copies of those alleged purchase agreements, whenever you can take time out from your busy schedule to produce them. It would also be helpful if you would include whatever additional documents, as may be necessary, to demonstrate convincingly that whoever you allegedly bought the blocks from came by them honestly, and not due to some earlier skulduggery, particularly the ones I have already mentioned, e.g. the 168.198.0.0/16 block, the 139.44.0.0/16 block, the 165.25.0.0/16 block, and not least the Infoplan/SITA block, 196.16.0.0/14. >It is hinted from your tongue-lashing, that you are connected clearly with >Spamhaus and ARIN, that have an interest to receive the ranges, following >the increase of value of the ranges in the free market and the lack of them. Gosh darm it! You caught me! I'm really a stealth IP speculator. I didn't want it publicly known that I have been sitting all this time on an enormous stash of no fewer than two whole IPv4 addresses. I also didn't want it known that I am actually in league with Spamhaus, ARIN, Vladimir Putin, the Marx Brothers, Boris Johnson, Ricky Gervais, and oh yes, Beelzebub. But now that the cat is out of the bag, I might as well fess up. Yes, we have all been plotting together to steal your valuable stash of IPv4 addresses, and in fact, Cogent is in on the plot too. I would have told you sooner, but I was busy eating children... with a nice chianti, of course. >All of this subject was transferred to our lawyers, due to the mudslinging >and slandering and the nicknames you wrote thieves and crooks in this forum >a libel suit against you will be filed with a high amount, of course that >all of the written proofs an agreements regarding the legal purchases that >we've made will be added to the libel suit. Is the official NANOG historian in the house? I just want to ruling on this. Am I the first and only person who has ever received a cartooney directly on the NANOG list? I just want to know if I can go ahead and contact the Guinness people, and get this unique feat recorded officially. Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Thu Sep 19 10:42:11 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 19 Sep 2019 12:42:11 +0200 Subject: Elad Cohen In-Reply-To: (Jon Sands's message of "Thu, 19 Sep 2019 06:21:46 -0400") References: <54360.1568887927@segfault.tristatelogic.com> Message-ID: <87tv98h8jg.fsf@miraculix.mork.no> Jon Sands writes: > On 9/19/2019 6:12 AM, Ronald F. Guilmette wrote: >> >> I just want to ruling on this. Am I the first and only person who has ever >> received a cartooney directly on the NANOG list? > > I can't remember if it was over NANOG or not, but back in 2010 a good > friend of mine Mike Bailey (now deceased) received similar bold faced > legal threats (mostly threats of DMCA if I remember right) from FDC > Servers when he exposed to the WHT forums that they were at the time > using power strips daisy chained, motherboards sitting on cardboard, > etc in their chicago datacenter - he documented with pictures a number > of fire code violations and was threatened with DMCA notices for > it. Sadly the pictures no longer load, but oh boy were they special: > https://web.archive.org/web/20100228172939/http://ub3r.net/fdc/readme.htm You can see one of those pics here: https://itknowledgeexchange.techtarget.com/IT-watch-blog/fdcservers-colocation-data-center-gives-new-life-to-the-term-boxen/ > I do agree though, this should probably be taken way off-list. Sure. But there is still some popcorn left ;-) Bjørn From rfg at tristatelogic.com Thu Sep 19 11:03:35 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 19 Sep 2019 04:03:35 -0700 Subject: Elad Cohen In-Reply-To: <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2@globalone.io> Message-ID: <54615.1568891015@segfault.tristatelogic.com> In message <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2 at globalone.io>, Florian Brandstetter wrote: >... this is certainly not a place where you can >slander his name or anyone associated with him in any manner for the >entertainment of everyone... If I have slandered anyone, then I shall bear the price for that, in accordance with law. I have accepted that risk, in order to say what I have said, and I have done so from within the most litigious nation on earth. Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he pay for his misdeeds, and who will see to it that he receives the justice due him? Mr. Cohen sits with impunity in Israel, and by remote control appears to request his California lawyer, the colorful and storied Mr. Bennett Kelley, to file suit against me, even as Mr. Cohen takes IPv4 space away from legitimate businesses and governmental entities in South Africa, Australia, and Japan, also by remote control, and also with the relative impunity afforded him by his sheer distance from these places. I have risked my neck, my reputation, and my entire bank account in order to call him out, and if you think that I have done so lightly or without evidence you are wrong. Meanwhile, what has Mr. Cohen risked? And who will see to it that he pays an appropriate price, in Israel, if I am right and he is wrong? Regards, rfg From elad at netstyle.io Thu Sep 19 11:18:29 2019 From: elad at netstyle.io (Elad Cohen) Date: Thu, 19 Sep 2019 11:18:29 +0000 Subject: Elad Cohen In-Reply-To: <54615.1568891015@segfault.tristatelogic.com> References: <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2@globalone.io>, <54615.1568891015@segfault.tristatelogic.com> Message-ID: Mr. Ronald Guilmette The way you called us in this forum incessantly, thieves and crooks, is not the right way, this is libel for all intents and purposes, we will not wrangle with you in this forum as this subject was transferred our lawyers. We are sure that in one year, you will not be such a "hero" and a "savior" as you represent yourself today. ________________________________ From: NANOG on behalf of Ronald F. Guilmette Sent: Thursday, September 19, 2019 2:03 PM To: nanog at nanog.org Subject: Re: Elad Cohen In message <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2 at globalone.io>, Florian Brandstetter wrote: >... this is certainly not a place where you can >slander his name or anyone associated with him in any manner for the >entertainment of everyone... If I have slandered anyone, then I shall bear the price for that, in accordance with law. I have accepted that risk, in order to say what I have said, and I have done so from within the most litigious nation on earth. Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he pay for his misdeeds, and who will see to it that he receives the justice due him? Mr. Cohen sits with impunity in Israel, and by remote control appears to request his California lawyer, the colorful and storied Mr. Bennett Kelley, to file suit against me, even as Mr. Cohen takes IPv4 space away from legitimate businesses and governmental entities in South Africa, Australia, and Japan, also by remote control, and also with the relative impunity afforded him by his sheer distance from these places. I have risked my neck, my reputation, and my entire bank account in order to call him out, and if you think that I have done so lightly or without evidence you are wrong. Meanwhile, what has Mr. Cohen risked? And who will see to it that he pays an appropriate price, in Israel, if I am right and he is wrong? Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at as397444.net Thu Sep 19 11:35:58 2019 From: nanog at as397444.net (Matt Corallo) Date: Thu, 19 Sep 2019 13:35:58 +0200 Subject: Elad Cohen In-Reply-To: References: <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2@globalone.io> <54615.1568891015@segfault.tristatelogic.com> Message-ID: <3D4BA675-3CA2-488E-9B75-BCAFD1428A7E@as397444.net> Come on dude, you could just respond with the requested LoAs and purchase agreements and yet instead you threaten lawsuits. No one with half a brain even skimming this thread will conclude that you're innocent in this matter (a lapse in accuracy or two here and there by Mr Guilmette notwithstanding). Take your useless grandstanding elsewhere. Matt > On Sep 19, 2019, at 13:18, Elad Cohen wrote: > > Mr. Ronald Guilmette > > The way you called us in this forum incessantly, thieves and crooks, is not the right way, this is libel for all intents and purposes, we will not wrangle with you in this forum as this subject was transferred our lawyers. > > We are sure that in one year, you will not be such a "hero" and a "savior" as you represent yourself today. > From: NANOG on behalf of Ronald F. Guilmette > Sent: Thursday, September 19, 2019 2:03 PM > To: nanog at nanog.org > Subject: Re: Elad Cohen > > In message <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2 at globalone.io>, > Florian Brandstetter wrote: > > >... this is certainly not a place where you can > >slander his name or anyone associated with him in any manner for the > >entertainment of everyone... > > If I have slandered anyone, then I shall bear the price for that, in > accordance with law. I have accepted that risk, in order to say what > I have said, and I have done so from within the most litigious nation > on earth. > > Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he > pay for his misdeeds, and who will see to it that he receives the justice > due him? > > Mr. Cohen sits with impunity in Israel, and by remote control appears to > request his California lawyer, the colorful and storied Mr. Bennett Kelley, > to file suit against me, even as Mr. Cohen takes IPv4 space away from > legitimate businesses and governmental entities in South Africa, Australia, > and Japan, also by remote control, and also with the relative impunity > afforded him by his sheer distance from these places. I have risked > my neck, my reputation, and my entire bank account in order to call him > out, and if you think that I have done so lightly or without evidence you > are wrong. Meanwhile, what has Mr. Cohen risked? And who will see to it > that he pays an appropriate price, in Israel, if I am right and he is wrong? > > > Regards, > rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Sep 19 11:51:02 2019 From: elad at netstyle.io (Elad Cohen) Date: Thu, 19 Sep 2019 11:51:02 +0000 Subject: Elad Cohen In-Reply-To: <3D4BA675-3CA2-488E-9B75-BCAFD1428A7E@as397444.net> References: <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2@globalone.io> <54615.1568891015@segfault.tristatelogic.com> , <3D4BA675-3CA2-488E-9B75-BCAFD1428A7E@as397444.net> Message-ID: Agreements were already sent to Spamhaus and from there were transferred to Jan Vermeulen, the "friend" of Ronald, unfortunately Ronald decided that they are "forged" because they have the same police stamp in the same position (these are not different documents, but the same single document that on each sending to Spamhaus, the other non-relevant netblocks were grayed-out) Regarding: "No one with half a brain even skimming this thread will conclude that you're innocent in this matter" Can you please write based on what you are writing it? (we will very appreciate facts and not opinions) ________________________________ From: Matt Corallo Sent: Thursday, September 19, 2019 2:35 PM To: Elad Cohen Cc: Ronald F. Guilmette ; nanog at nanog.org Subject: Re: Elad Cohen Come on dude, you could just respond with the requested LoAs and purchase agreements and yet instead you threaten lawsuits. No one with half a brain even skimming this thread will conclude that you're innocent in this matter (a lapse in accuracy or two here and there by Mr Guilmette notwithstanding). Take your useless grandstanding elsewhere. Matt On Sep 19, 2019, at 13:18, Elad Cohen > wrote: Mr. Ronald Guilmette The way you called us in this forum incessantly, thieves and crooks, is not the right way, this is libel for all intents and purposes, we will not wrangle with you in this forum as this subject was transferred our lawyers. We are sure that in one year, you will not be such a "hero" and a "savior" as you represent yourself today. ________________________________ From: NANOG > on behalf of Ronald F. Guilmette > Sent: Thursday, September 19, 2019 2:03 PM To: nanog at nanog.org > Subject: Re: Elad Cohen In message <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2 at globalone.io>, Florian Brandstetter > wrote: >... this is certainly not a place where you can >slander his name or anyone associated with him in any manner for the >entertainment of everyone... If I have slandered anyone, then I shall bear the price for that, in accordance with law. I have accepted that risk, in order to say what I have said, and I have done so from within the most litigious nation on earth. Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he pay for his misdeeds, and who will see to it that he receives the justice due him? Mr. Cohen sits with impunity in Israel, and by remote control appears to request his California lawyer, the colorful and storied Mr. Bennett Kelley, to file suit against me, even as Mr. Cohen takes IPv4 space away from legitimate businesses and governmental entities in South Africa, Australia, and Japan, also by remote control, and also with the relative impunity afforded him by his sheer distance from these places. I have risked my neck, my reputation, and my entire bank account in order to call him out, and if you think that I have done so lightly or without evidence you are wrong. Meanwhile, what has Mr. Cohen risked? And who will see to it that he pays an appropriate price, in Israel, if I am right and he is wrong? Regards, rfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From florianb at globalone.io Thu Sep 19 11:53:17 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Thu, 19 Sep 2019 13:53:17 +0200 Subject: Elad Cohen In-Reply-To: <54615.1568891015@segfault.tristatelogic.com> References: <54615.1568891015@segfault.tristatelogic.com> Message-ID: <056F63CF-5F15-4EC5-9A43-E7200FFCDDFC@globalone.io> Ronald, You don’t have to jump into such a defensive position to my comment. I am neither siding with Mr. Cohen on this case nor with your side, I am merely a neutral third sharing his thoughts. > Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he > pay for his misdeeds, and who will see to it that he receives the justice > due him? Inevitably, he will lose access to the resources mentioned shall it turn out you are right on this case, whilst this does not impose any further consequences in itself, you at least achieved a re-establishment of ordinariness, which, given this is an open discussion on a public mailing list, should be priority #1. I will be honest with you here, you could have brought the point(s) you are making across in a different fashion, which does not even give the accused party any opportunities to sue for libel or slander. Given that you are right on this case, this ultimately should not matter, however, shall it turn out you are wrong, or your point is deemed to be invalid (by whoever), you might not have a joker left to pull. Ultimately to cut a lot of words short, you might have more success in this case by sticking closely to obvious or proven facts which they can not subsequently declare as libel. I do not comment on this because I am against your desire to have a clear overview of what actually goes on here, I am also not commenting to have fun or mess with either of you, I am merely objecting the way of communication that happens at this stage. > On 19.09.2019, at 13:03, Ronald F. Guilmette wrote: > > In message <8A49BF73-7A68-4B8F-9DC5-E94B7FE637F2 at globalone.io>, > Florian Brandstetter wrote: > >> ... this is certainly not a place where you can >> slander his name or anyone associated with him in any manner for the >> entertainment of everyone... > > If I have slandered anyone, then I shall bear the price for that, in > accordance with law. I have accepted that risk, in order to say what > I have said, and I have done so from within the most litigious nation > on earth. > > Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he > pay for his misdeeds, and who will see to it that he receives the justice > due him? > > Mr. Cohen sits with impunity in Israel, and by remote control appears to > request his California lawyer, the colorful and storied Mr. Bennett Kelley, > to file suit against me, even as Mr. Cohen takes IPv4 space away from > legitimate businesses and governmental entities in South Africa, Australia, > and Japan, also by remote control, and also with the relative impunity > afforded him by his sheer distance from these places. I have risked > my neck, my reputation, and my entire bank account in order to call him > out, and if you think that I have done so lightly or without evidence you > are wrong. Meanwhile, what has Mr. Cohen risked? And who will see to it > that he pays an appropriate price, in Israel, if I am right and he is wrong? > > > Regards, > rfg From jsage at finchhaven.com Thu Sep 19 13:08:52 2019 From: jsage at finchhaven.com (John Sage) Date: Thu, 19 Sep 2019 06:08:52 -0700 Subject: This endless pissing contest is operational, how? Re: Elad Cohen In-Reply-To: References: <54360.1568887927@segfault.tristatelogic.com> Message-ID: <7983e3f9-e126-4218-915c-04c2d84dd474@finchhaven.com> On 9/19/19 3:25 AM, Elad Cohen wrote: > Mr. Ronald Guilmette Are there *any* moderators #OnHere at all? From chris.wescott at Edgarhighspeed.com Thu Sep 19 00:50:37 2019 From: chris.wescott at Edgarhighspeed.com (Chris Wescott) Date: Thu, 19 Sep 2019 00:50:37 +0000 Subject: Akamai IP Geo Location incorrect for IP blocks below In-Reply-To: References: Message-ID: Hello, I am looking for some help with Akamai, I have been in contact with their support rep on the phone and they confirmed our 2 blocks below are showing incorrectly. I was asked to email their support and they would get it changed. I emailed support and was told they couldn’t help unless we had an account. So I am looking for a contact or some help on this. Our ips show up correctly in all other geo ip databases. The 2 blocks geo location show as Burnaby, B.C. and they should be showing are Red Deer, A.B. Canada. IP Blocks 23.167.64.0/24 23.179.160.0/24 We are the Arin registered owner of the above blocks. I would appreciate it someone would reply to this message and let me know the status when updates have been done. Regards, Chris Wescott Edgar HighSpeed Inc President 403-713-1016 (Opt 1) www.edgarhighspeed.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Thu Sep 19 14:28:59 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 19 Sep 2019 10:28:59 -0400 Subject: Akamai IP Geo Location incorrect for IP blocks below In-Reply-To: References: Message-ID: Akamai: Please e-mail ccare at akamai.com with IP address, City, State/Province, Zip code (if available), and Country. SRC: http://thebrotherswisp.com/index.php/geo-and-vpn/ Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 19, 2019 at 10:16 AM Chris Wescott < chris.wescott at edgarhighspeed.com> wrote: > Hello, > > I am looking for some help with Akamai, I have been in contact with their > support rep on the phone and they confirmed our 2 blocks below are showing > incorrectly. I was asked to email their support and they would get it > changed. I emailed support and was told they couldn’t help unless we had an > account. > > So I am looking for a contact or some help on this. Our ips show up > correctly in all other geo ip databases. > > The 2 blocks geo location show as Burnaby, B.C. and they should be showing > are Red Deer, A.B. Canada. > > > > IP Blocks > > > > 23.167.64.0/24 > > 23.179.160.0/24 > > > > > > We are the Arin registered owner of the above blocks. > > > > I would appreciate it someone would reply to this message and let me know > the status when updates have been done. > > Regards, > Chris Wescott > Edgar HighSpeed Inc > President > 403-713-1016 (Opt 1) > www.edgarhighspeed.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Thu Sep 19 14:31:15 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Sep 2019 10:31:15 -0400 Subject: Akamai IP Geo Location incorrect for IP blocks below In-Reply-To: References: Message-ID: I already took care of this via another forum for Chris. If you have issues let me know in private. Thanks. - Jared > On Sep 18, 2019, at 8:50 PM, Chris Wescott wrote: > > Hello, > > I am looking for some help with Akamai, I have been in contact with their support rep on the phone and they confirmed our 2 blocks below are showing incorrectly. I was asked to email their support and they would get it changed. I emailed support and was told they couldn’t help unless we had an account. > > So I am looking for a contact or some help on this. Our ips show up correctly in all other geo ip databases. > > The 2 blocks geo location show as Burnaby, B.C. and they should be showing are Red Deer, A.B. Canada. > > > > IP Blocks > > > > 23.167.64.0/24 > > 23.179.160.0/24 > > > > > > We are the Arin registered owner of the above blocks. > > > > I would appreciate it someone would reply to this message and let me know the status when updates have been done. > > Regards, > Chris Wescott > Edgar HighSpeed Inc > President > 403-713-1016 (Opt 1) > www.edgarhighspeed.com From list at satchell.net Thu Sep 19 14:38:04 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 19 Sep 2019 07:38:04 -0700 Subject: Elad Cohen, show us! In-Reply-To: References: <51414.1568843573@segfault.tristatelogic.com> <6ed95c67-584d-1daf-bd6d-98571e3eaf3c@infratection.com> Message-ID: <78010b9b-f564-6c0a-afc5-297f07dba483@satchell.net> On 9/19/19 2:47 AM, Elad Cohen wrote: > It is not related to nefarious activity as you wrote, FDCServers > policy is to stop routing any ranges which is in Spamhaus SBL (no > matter what), due to the phear from Spamhaus to list all of > FDCServers ranges in SBL, which was told to us in a documented phone > call, listing all of the ranges by Spamhaus is a known agrressive and > bullying tactic by Spamhaus as you can find in many webpages online. Do you think Spamhaus uses "aggressive and bullying tactic[s]"? You never lived under the sword of SPEWS. > https://en.wikipedia.org/wiki/Spam_Prevention_Early_Warning_System As a former abuse and mail admin in a web hosting company with (at the time) 3000 domains serviced, I found Spamhaus to be a firm but fair organization. Respond quickly and effectively to abuse complaints, stoping the spam flow, Spamhaus delisted -- sometimes without being asked to. Note: this list is of and for network operators. Spamhaus and other DNSBLs are the subject for a mailing list of and for mail admins. From list at satchell.net Thu Sep 19 14:46:03 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 19 Sep 2019 07:46:03 -0700 Subject: Elad Cohen, show us! In-Reply-To: References: <51414.1568843573@segfault.tristatelogic.com> <6ed95c67-584d-1daf-bd6d-98571e3eaf3c@infratection.com> Message-ID: On 9/19/19 2:47 AM, Elad Cohen wrote: > It is not related to nefarious activity as you wrote, FDCServers > policy is to stop routing any ranges which is in Spamhaus SBL (no > matter what), due to the phear from Spamhaus to list all of > FDCServers ranges in SBL, which was told to us in a documented phone > call, listing all of the ranges by Spamhaus is a known agrressive and > bullying tactic by Spamhaus as you can find in many webpages online. Do you think Spamhaus uses "aggressive and bullying tactic[s]"? You never lived under the sword of SPEWS. > https://en.wikipedia.org/wiki/Spam_Prevention_Early_Warning_System As a former abuse and mail admin in a web hosting company with (at the time) 3000 domains serviced, I found Spamhaus to be a firm but fair organization. Respond quickly and effectively to abuse complaints, stoping the spam flow, Spamhaus delisted -- sometimes without being asked to. Note: this list is of and for network operators. Spamhaus and other DNSBLs are the subject for a mailing list of and for mail admins. From morrowc.lists at gmail.com Thu Sep 19 14:57:50 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Sep 2019 10:57:50 -0400 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <53490.1568880283@segfault.tristatelogic.com> References: <53490.1568880283@segfault.tristatelogic.com> Message-ID: On Thu, Sep 19, 2019 at 4:05 AM Ronald F. Guilmette wrote: > > In message > Christopher Morrow wrote: > > >"who cares about the sale?" > > My apologies. I see that I have failed to be adequately clear. > I was misunderstood I think. What I'm asking is: "there is already repair for the harmed parties, if they are not taking advantage of this then I don't think we need to spend more time on this topic" There is a bunch of focus on 'sale' or 'barter' or 'receipts' or 'theft', none of that really matters if the harmed parties and RIRs aren't going to request/take action. -chris From dmitry at interhost.net Thu Sep 19 15:05:30 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Thu, 19 Sep 2019 15:05:30 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" wrote: > If you don’t like Cogent - explain. Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. They abuse whois. They are one of the primary reasons few people put their real phone number in whois. And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From dmitry at interhost.net Thu Sep 19 15:12:21 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Thu, 19 Sep 2019 15:12:21 +0000 Subject: Telecommunications Breakdown: How Russian Telco Infrastructure was Message-ID: https://www.upguard.com/breaches/mts-nokia-telecom-inventory-data-exposure?fbclid=IwAR3QbgiqwYJZ-sFTIDAkKn6mqRESV4_lJB5nK4gT8ix_vB0xDel_la8ONQg -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Sep 19 15:43:24 2019 From: bill at herrin.us (William Herrin) Date: Thu, 19 Sep 2019 08:43:24 -0700 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: References: <53490.1568880283@segfault.tristatelogic.com> Message-ID: On Thu, Sep 19, 2019 at 7:58 AM Christopher Morrow wrote: > What I'm asking is: "there is already repair for the harmed parties, > if they are not taking advantage of this then I don't think we need to > spend more time on this topic" > Hi Chris, I respectfully disagree with the assertion that "there is already repair." Getting an entity on the other side of the planet whose front-line contacts don't speak your language to correct local configuration overrides associated with your address space turns out to be a hard task. Getting several hundred entities to do so, because they've all acted independently in response to the problem with your address space, is functionally insurmountable. It victimizes the folks whose addresses were stolen beyond repair. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at ianai.net Thu Sep 19 16:03:22 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 19 Sep 2019 12:03:22 -0400 Subject: This endless pissing contest is operational, how? Re: Elad Cohen In-Reply-To: <7983e3f9-e126-4218-915c-04c2d84dd474@finchhaven.com> References: <54360.1568887927@segfault.tristatelogic.com> <7983e3f9-e126-4218-915c-04c2d84dd474@finchhaven.com> Message-ID: <8ED4601F-9614-49F8-834B-0A30539E426C@ianai.net> On Sep 19, 2019, at 9:08 AM, John Sage wrote: > > On 9/19/19 3:25 AM, Elad Cohen wrote: >> Mr. Ronald Guilmette > > Are there *any* moderators #OnHere at all? Moderators? No. Anyone subscribed to the list can post anything at any time. But posts are reviewed after the fact if there is suspicion or accusations of AUP violation. That is not a real-time process. Give them a day or so. In the mean time, may I suggest procmail (or whatever your MTA/MUA's filtering system is called)? -- TTFN, patrick From jsage at finchhaven.com Thu Sep 19 16:15:46 2019 From: jsage at finchhaven.com (John Sage) Date: Thu, 19 Sep 2019 09:15:46 -0700 Subject: This endless pissing contest is operational, how? Re: Elad Cohen In-Reply-To: <8ED4601F-9614-49F8-834B-0A30539E426C@ianai.net> References: <54360.1568887927@segfault.tristatelogic.com> <7983e3f9-e126-4218-915c-04c2d84dd474@finchhaven.com> <8ED4601F-9614-49F8-834B-0A30539E426C@ianai.net> Message-ID: <38fb49f4-383f-112d-0298-d8c9868f15ea@finchhaven.com> On 9/19/19 9:03 AM, Patrick W. Gilmore wrote: > On Sep 19, 2019, at 9:08 AM, John Sage wrote: >> >> On 9/19/19 3:25 AM, Elad Cohen wrote: >>> Mr. Ronald Guilmette >> >> Are there *any* moderators #OnHere at all? > > Moderators? No. Anyone subscribed to the list can post anything at any time. > > But posts are reviewed after the fact if there is suspicion or accusations of AUP violation. > > That is not a real-time process. Give them a day or so. > > In the mean time, may I suggest procmail (or whatever your MTA/MUA's filtering system is called)? > Yes. Already getting hits in my killfile (as I still call it; I'm old...) http://manpages.ubuntu.com/manpages/bionic/man1/procmail.1.html - John -- From morrowc.lists at gmail.com Thu Sep 19 17:25:15 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Sep 2019 13:25:15 -0400 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: References: <53490.1568880283@segfault.tristatelogic.com> Message-ID: On Thu, Sep 19, 2019 at 11:43 AM William Herrin wrote: > > > > On Thu, Sep 19, 2019 at 7:58 AM Christopher Morrow wrote: >> >> What I'm asking is: "there is already repair for the harmed parties, >> if they are not taking advantage of this then I don't think we need to >> spend more time on this topic" > > > Hi Chris, > > I respectfully disagree with the assertion that "there is already repair." Getting an entity cool! :) > on the other side of the planet whose front-line contacts don't speak your language to > correct local configuration overrides associated with your address space turns out to be > a hard task. Getting several hundred entities Sure, getting in touch can be rough. 1) publish ROA for your prefixes 2) call upstream and have them note the presence of the ROA 3) done it's always a tad more complex, and in situations where actual traffic loss is occurring this is frustrating to deal with :( but... These are the tools available. Shouting into the wind (nanog) really isn't helping, and I'd argue that in this particular case the 'original owners[tm]' don't know and probably don't even care. Of course, the above 3 step process does mean that: o You have the RIR credentials to do the RPKI dances. o You actually noticed the problem. o Where in the world waldo (or your prefixes) appeared mattered to you I think in the cases outlined so far here, these three are missing and arguably not important to the 'original owner[tm]' of the space/blocks. > to do so, because they've all acted independently in response to the problem with your > address space, is functionally insurmountable. It victimizes the folks whose addresses > were stolen beyond repair. In this case I don't think 'stolen' is important... sadly these spaces went fallow and were lost in time :( having dealt with many cases of this for my current/past employer I'm sensitive to the problem :( and have had good/bad dealings with folks with problems like this... The tools do exist, we should all use them. > Regards, > Bill Herrin always a pleasure! :) -chris > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ From michel.py at tsisemi.com Thu Sep 19 18:44:56 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 19 Sep 2019 18:44:56 +0000 Subject: Elad Cohen In-Reply-To: References: , <53564.1568881344@segfault.tristatelogic.com> Message-ID: <721768af04bf4d9ba422f2db075070d2@CRA114.am.necel.com> > Elad Cohen wrote : > Mr. Ronald Guilmette > It is hinted from your tongue-lashing, that you are connected clearly with Spamhaus and ARIN What a joke, given the sour relation between him and ARIN and his very public views about enforcing the law of the land locally. Ronald may be tilting at windmills at times and not be the most polite person, but I don't doubt his motives. > Matt Corallo wrote : > Come on dude, you could just respond with the requested LoAs and purchase agreements and yet instead you threaten > lawsuits. No one with half a brain even skimming this thread will conclude that you're innocent in this matter (a lapse in > accuracy or two here and there by Mr Guilmette notwithstanding). Take your useless grandstanding elsewhere. +1 > Richard Golodner wrote : > Mr. Guilmette, my curiosity has now been increased as I notice Cogent is no longer supplying routing for the /16's you have spoken of. [..] I have never seen Cogent behave in this manner unless there really is some nefarious activity in regards to the blocks in question. I would second that, and it depends on your definition of nefarious. Cogent will route any block you pay them to, even if you had to kill their own mother to obain it. As long as you pay. I suspect there is a financial aspect in that. The little popcorn we see in here does not strike me as a good enough reason for Cogent to dump a paying customer. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From rfg at tristatelogic.com Thu Sep 19 22:50:05 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 19 Sep 2019 15:50:05 -0700 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <20190919084649.GC30112@jima.tpb.net> Message-ID: <57420.1568933405@segfault.tristatelogic.com> In message <20190919084649.GC30112 at jima.tpb.net>, niels=nanog at bakker.net wrote: >* rfg at tristatelogic.com (Ronald F. Guilmette) [Thu 19 Sep 2019, 10:05 CEST]: >>I never like to generalize to entire populations, and I will >>therefore refrain from suggesting any endemic or widespread defect >>in the Dutch national psyche, but I cannot help but note that, as >>pointed out in the MyBroadband.co.za news report, a gentleman named >>Maikel Uerlings, who is also Dutch, and who presently appears to be >>notably absent from the Netherlands, perhaps due to certain >>less-than-friendly legal entanglements, is also, it appears, >>intimately connected to Mr. Cohen and to his business, such as it >>is. It would be entirely improper for me to say or even to suggest >>that the Dutch are any more inclined toward cybercrime, or toward >>looking the other way while it takes place, than anyone else. I >>will instead only paraphrase William Shakespeare and say that there >>is something rotten in the Netherlands, and that whatever it is, it >>ain't doing their national reputation any good at all. > >Couching your racism in some faux plausible deniability by using >phrases such as "It would be entirely improper of me to" or "I will >refrain from [making a certain racist suggestion]" and then immediately >making that racist suggestion, doesn't make your remarks not racist. >Nor can you hide behind the classics. > >Racism has no place in this community and you would do well to refrain >from posting any more such remarks. Leaving aside the minor quibble that "Dutch" is not, as far as I am aware, a "race" per se, I do apologize for having improperly and quite wrongly generalized the apparent confluence of of certain events and actions to the Dutch people generally. That was entirely incorrect and improper on my part and I do sincerly apologize. Looking back now at one of my own posts here from a couple of years ago, I do see that at the time, there did seem to be some similar sorts of undesirable and arguably untowards routing events which were emmanating from AS260, Xconnect24 Inc., which at the time appeared to me to be an Amsterdam-based networking company: https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html (The company still does appear to have some footprint in Amsterdam.) Obviously, those historical events have no relation whatsoever to present circumstances or to recent events, but given that I've not generally seen much of this kind of stuff from other European locales... with the exception of Ukraine... it's difficult for me not to infer a possible pattern. That having been said, the "pattern" such as it is, is quite obviously not one that can or should be attributed to the Dutch people generally, who make the world's best and most admirable chocolate, wooden shoes, and windmills, by the way. Rather, the pattern, if there even is one, seems to be confined exclusively and only to the networking community and its associated professionals within the city limits of Amsterdam. And furthermore, I am quite entirely sure that even the majority of this small group are admirable and honorable people, doing their level best, day in and day out, to provide quality and honest service to their neighbors, their countrymen, and to the people of Europe generally. My hope is that it will not be inappropriate for me to simply express my sincere desire that this overwehlming majority, i.e. the good men and women of the Amsterdam networking community will, over time, work to insure that that all members of their community adhere to the highest ethical standards in all respects and at all times. Regards, rfg From egon at egon.cc Thu Sep 19 20:38:57 2019 From: egon at egon.cc (James Downs) Date: Thu, 19 Sep 2019 13:38:57 -0700 Subject: Word Usage (was Re: Elad Cohen) In-Reply-To: References: <53564.1568881344@segfault.tristatelogic.com> Message-ID: <20190919203857.GU19680@nemesis.egontech.com> For the record: Slander is false *spoken* statements. Libel is false *written* statements. HTH, HAND. From nwarren at barryelectric.com Fri Sep 20 12:31:57 2019 From: nwarren at barryelectric.com (Nicholas Warren) Date: Fri, 20 Sep 2019 12:31:57 +0000 Subject: sfps from fs dot com Message-ID: Anyone have experience with fs.com's lasers? Are they reliable? From jared at puck.nether.net Fri Sep 20 12:33:13 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Sep 2019 08:33:13 -0400 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: > On Sep 20, 2019, at 8:31 AM, Nicholas Warren wrote: > > Anyone have experience with fs.com's lasers? Are they reliable? Yes. From lists.nanog at monmotha.net Fri Sep 20 12:37:51 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 20 Sep 2019 08:37:51 -0400 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: <5f69940a-85eb-f9c5-06b1-09e29274409f@monmotha.net> On 9/20/19 8:31 AM, Nicholas Warren wrote: > Anyone have experience with fs.com's lasers? Are they reliable? I've had no complaints about reliability. In terms of transmit power and receiver performance, they seem to have a bit more variability than some of the bigger brands' offerings, but they seem to always be within spec. They're cheap enough to keep several spares around and still come out ahead of buying name-brand let alone OEM vendor-branded optics, too. -- Brandon Martin From bryan at shout.net Fri Sep 20 12:40:19 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 20 Sep 2019 14:40:19 +0200 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: <94cbec80-f622-e653-5898-9c2d57b1ae06@shout.net> On 9/20/19 2:31 PM, Nicholas Warren wrote: > Anyone have experience with fs.com's lasers? Are they reliable? > YMMV. From jason+nanog at lixfeld.ca Fri Sep 20 12:41:04 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Fri, 20 Sep 2019 08:41:04 -0400 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> We have maybe 1:50 DOA, but they’re so cheap, we just throw them out because it’s not worth the RMA. That said, I can’t remember the last time we’ve had any of these fail in the field, or have had any issues with variablity in TX/RX power. We have tens of thousands of these in the field, from 100Mb Bidi to 100G-LR and everything in between, including *WDM up to 80KM. > On Sep 20, 2019, at 8:31 AM, Nicholas Warren wrote: > > Anyone have experience with fs.com's lasers? Are they reliable? From jared at puck.nether.net Fri Sep 20 12:46:00 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Sep 2019 08:46:00 -0400 Subject: DARAZ.COM.BD Message-ID: Can you please turn off your salesforce/autoresponder to nanog posts please? - jared From mikebolitho at gmail.com Fri Sep 20 12:49:38 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Fri, 20 Sep 2019 05:49:38 -0700 Subject: Word Usage (was Re: Elad Cohen) In-Reply-To: <20190919203857.GU19680@nemesis.egontech.com> References: <53564.1568881344@segfault.tristatelogic.com> <20190919203857.GU19680@nemesis.egontech.com> Message-ID: Everytime you guys change the subject on this pointless thread, you break my filter. Admins can you please take action on this? Enough is enough. -Mike Bolitho On Fri, Sep 20, 2019, 3:21 AM James Downs via NANOG wrote: > For the record: > > Slander is false *spoken* statements. > Libel is false *written* statements. > > HTH, HAND. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Fri Sep 20 12:54:27 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 20 Sep 2019 14:54:27 +0200 Subject: sfps from fs dot com In-Reply-To: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> References: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> Message-ID: It boils down to a business case. In my travels we see a high failure rate -- higher than I'd like to see --, but $boss likes the price, and, as Jason pointed out below, for the price, it can be a "successful" business model. In a nutshell: For someone on a budget, they're great; buy spares. For someone who doesn't want to deal with outages, call-volume, hands tickets, truck-rolls, and has money to burn, there are better alternatives. On 9/20/19 2:41 PM, Jason Lixfeld wrote: > We have maybe 1:50 DOA, but they’re so cheap, we just throw them out because it’s not worth the RMA. > > That said, I can’t remember the last time we’ve had any of these fail in the field, or have had any issues with variablity in TX/RX power. We have tens of thousands of these in the field, from 100Mb Bidi to 100G-LR and everything in between, including *WDM up to 80KM. > >> On Sep 20, 2019, at 8:31 AM, Nicholas Warren wrote: >> >> Anyone have experience with fs.com's lasers? Are they reliable? > From jason+nanog at lixfeld.ca Fri Sep 20 12:58:36 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Fri, 20 Sep 2019 08:58:36 -0400 Subject: sfps from fs dot com In-Reply-To: References: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> Message-ID: <81F9BAD0-5E9C-4312-8F37-0D8517D04C28@lixfeld.ca> > On Sep 20, 2019, at 8:54 AM, Bryan Holloway wrote: > > In my travels we see a high failure rate -- higher than I'd like to see --, but $boss likes the price, and, as Jason pointed out below, for the price, it can be a "successful" business model. > For someone who doesn't want to deal with outages, call-volume, hands tickets, truck-rolls, and has money to burn, there are better alternatives. Indeed. My tune would be very different if we had 1:50 fail in the field. From kmccormick at mdtc.net Fri Sep 20 13:09:10 2019 From: kmccormick at mdtc.net (Kevin McCormick) Date: Fri, 20 Sep 2019 13:09:10 +0000 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: <2b10bd41702e440b92f74f58f356c0e6@mdtc.net> Yes. I never have seen a failure in the last few years. We have used Cisco compatible 1G / 10G DAC, SR, LR, and DWDM. Buy spares if you are concerned, they are priced so you can. We do like having spares in a rack drawer. Thank you, Kevin McCormick -----Original Message----- From: NANOG On Behalf Of Nicholas Warren Sent: Friday, September 20, 2019 7:32 AM To: nanog at nanog.org Subject: sfps from fs dot com Anyone have experience with fs.com's lasers? Are they reliable? From CGross at ninestarconnect.com Fri Sep 20 13:21:52 2019 From: CGross at ninestarconnect.com (Chris Gross) Date: Fri, 20 Sep 2019 13:21:52 +0000 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: Biggest issue I've seen is it may work on some Cisco models and not others. I got their flashing box to just reflash the firmware and that has fixed even "dead" optics. -----Original Message----- From: NANOG On Behalf Of Nicholas Warren Sent: Friday, September 20, 2019 8:32 AM To: nanog at nanog.org Subject: sfps from fs dot com CAUTION: This email originated from outside NineStar Connect. Do not click links or open attachments unless you recognize the sender and know that the content is safe. If you have any concerns, click here to open a ticket with the NetAdmin team. ________________________________ Anyone have experience with fs.com's lasers? Are they reliable? From dennis at umnum.ca Fri Sep 20 14:35:55 2019 From: dennis at umnum.ca (=?UTF-8?Q?Dennis_Lundstr=C3=B6m?=) Date: Fri, 20 Sep 2019 10:35:55 -0400 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: Had some issues in the past with Juniper-coded LR4 with sporadic disconnections. Apart from those I don’t have any complaints beyond the odd DOA. —Dennis On Fri, Sep 20, 2019 at 08:32 Nicholas Warren wrote: > Anyone have experience with fs.com's lasers? Are they reliable? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri Sep 20 14:43:34 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 20 Sep 2019 14:43:34 +0000 Subject: sfps from fs dot com In-Reply-To: References: , Message-ID: <460C9F3E-5F6A-4256-BFD6-ACCCCA05A9CB@beckman.org> We buy them extensively and have had zero data problems with more than 300 parts in the field. Some switch/router manufacturers’ firmware poutily refuses to let you read snmp stats from any “unauthorized” SFPs modules, and some oem salespeople lyingly claim that using them voids your warranty, but this is just an attempt to keep customers captive to insanely overpriced OEM parts. FS.com’s bi-di modules are particularly ingenious, letting you add bidirectional fiber to devices the oem manufacture doesn’t even sell optics for in an attempt to create artificial product segmentation. -mel > On Sep 20, 2019, at 5:35 AM, Jared Mauch wrote: > > > >> On Sep 20, 2019, at 8:31 AM, Nicholas Warren wrote: >> >> Anyone have experience with fs.com's lasers? Are they reliable? > > Yes. > From mel at beckman.org Fri Sep 20 14:48:41 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 20 Sep 2019 14:48:41 +0000 Subject: DARAZ.COM.BD In-Reply-To: References: Message-ID: <47BB61D6-FE99-4F61-81AF-035A8794DEC0@beckman.org> Maybe email them directly? Posting to the list just gets us all more spam. -mel via cell > On Sep 20, 2019, at 5:47 AM, Jared Mauch wrote: > > Can you please turn off your salesforce/autoresponder to nanog posts please? > > - jared From lists.nanog at monmotha.net Fri Sep 20 15:04:52 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 20 Sep 2019 11:04:52 -0400 Subject: sfps from fs dot com In-Reply-To: <460C9F3E-5F6A-4256-BFD6-ACCCCA05A9CB@beckman.org> References: <460C9F3E-5F6A-4256-BFD6-ACCCCA05A9CB@beckman.org> Message-ID: On 9/20/19 10:43 AM, Mel Beckman wrote: > We buy them extensively and have had zero data problems with more than 300 parts in the field. Some switch/router manufacturers’ firmware poutily refuses to let you read snmp stats from any “unauthorized” SFPs modules, and some oem salespeople lyingly claim that using them voids your warranty, but this is just an attempt to keep customers captive to insanely overpriced OEM parts. And if you buy them coded to said switch/router vendor (or code them yourself with the "fs box" which is reasonably priced), said switch/routers usually start cooperating for you. -- Brandon Martin From matthew at corp.crocker.com Fri Sep 20 15:12:33 2019 From: matthew at corp.crocker.com (Matthew Crocker) Date: Fri, 20 Sep 2019 15:12:33 +0000 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: I have had some fail and SFP+ & QSFP28s that my Juniper MC480s refuse to recognize even though I ordered 'branded Juniper' optics. 99% of my stuff is from FlexOptix (https://www.flexoptix.net/). They are a bit more expensive but I've had 100% reliability and they have worked in all systems I've put them in. On 9/20/19, 8:33 AM, "NANOG on behalf of Nicholas Warren" wrote: Anyone have experience with fs.com's lasers? Are they reliable? From eyeronic.design at gmail.com Fri Sep 20 15:24:27 2019 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 20 Sep 2019 08:24:27 -0700 Subject: DARAZ.COM.BD In-Reply-To: <47BB61D6-FE99-4F61-81AF-035A8794DEC0@beckman.org> References: <47BB61D6-FE99-4F61-81AF-035A8794DEC0@beckman.org> Message-ID: Lovely Spam! Wonderful Spam! Lovely Spam! Wonderful Spam On Fri, Sep 20, 2019, 7:50 AM Mel Beckman wrote: > Maybe email them directly? Posting to the list just gets us all more spam. > > -mel via cell > > > On Sep 20, 2019, at 5:47 AM, Jared Mauch wrote: > > > > Can you please turn off your salesforce/autoresponder to nanog posts > please? > > > > - jared > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl-lists at portnetworks.com Fri Sep 20 15:42:09 2019 From: carl-lists at portnetworks.com (Carl Peterson) Date: Fri, 20 Sep 2019 10:42:09 -0500 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: We have had some failures with 10G BiDi optics coded for Juniper. We buy a ton of other stuff from FS but for optics we have moved over to Approved Optics for everything but active ethernet residential subscribers. On Fri, Sep 20, 2019 at 7:33 AM Nicholas Warren wrote: > Anyone have experience with fs.com's lasers? Are they reliable? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwarren at barryelectric.com Fri Sep 20 16:37:35 2019 From: nwarren at barryelectric.com (Nicholas Warren) Date: Fri, 20 Sep 2019 16:37:35 +0000 Subject: Sales Contact Opt-out? Message-ID: Is it possible to opt out of sales contact from those on the list? Or is this simply the price to pay for seeking the list's wisdom? > -----Original Message----- > From: Jason Barrette > Sent: Friday, September 20, 2019 11:28 AM > To: Gary A Mumphrey ; Nicholas Warren > Subject: RE: sfps from fs dot com > > Hi Gary, > [snip...] > > Jason M. Barrette > President > > D (949) 242-8077 M (714) 357-6295 > > Email: jason at enetusa.com > Visit us at: www.enetusa.com > > From: Gary A Mumphrey > Sent: Friday, September 20, 2019 7:44 AM > To: nwarren at barryelectric.com > Cc: Jason Barrette > Subject: RE: sfps from fs dot com > > Nicholas, > [snip...] From mel at beckman.org Fri Sep 20 16:40:24 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 20 Sep 2019 16:40:24 +0000 Subject: Sales Contact Opt-out? In-Reply-To: References: Message-ID: <04FF9973-A930-44B5-AEDE-2D345E724CBD@beckman.org> marketing is already prohibited by the rules of the group. It’s up to the moderators to police. -mel > On Sep 20, 2019, at 9:38 AM, Nicholas Warren wrote: > > Is it possible to opt out of sales contact from those on the list? > Or is this simply the price to pay for seeking the list's wisdom? > >> -----Original Message----- >> From: Jason Barrette >> Sent: Friday, September 20, 2019 11:28 AM >> To: Gary A Mumphrey ; Nicholas Warren >> Subject: RE: sfps from fs dot com >> >> Hi Gary, >> > [snip...] >> >> Jason M. Barrette >> President >> >> D (949) 242-8077 M (714) 357-6295 >> >> Email: jason at enetusa.com >> Visit us at: www.enetusa.com >> >> From: Gary A Mumphrey >> Sent: Friday, September 20, 2019 7:44 AM >> To: nwarren at barryelectric.com >> Cc: Jason Barrette >> Subject: RE: sfps from fs dot com >> >> Nicholas, >> > [snip...] > From brad.raymo at gmail.com Fri Sep 20 16:53:33 2019 From: brad.raymo at gmail.com (Bradley Raymo) Date: Fri, 20 Sep 2019 09:53:33 -0700 Subject: Sales Contact Opt-out? In-Reply-To: <04FF9973-A930-44B5-AEDE-2D345E724CBD@beckman.org> References: <04FF9973-A930-44B5-AEDE-2D345E724CBD@beckman.org> Message-ID: Please report to abuse at nanog.org On Fri, Sep 20, 2019 at 9:42 AM Mel Beckman wrote: > marketing is already prohibited by the rules of the group. It’s up to the > moderators to police. > > -mel > > > On Sep 20, 2019, at 9:38 AM, Nicholas Warren > wrote: > > > > Is it possible to opt out of sales contact from those on the list? > > Or is this simply the price to pay for seeking the list's wisdom? > > > >> -----Original Message----- > >> From: Jason Barrette > >> Sent: Friday, September 20, 2019 11:28 AM > >> To: Gary A Mumphrey ; Nicholas Warren < > nwarren at barryelectric.com> > >> Subject: RE: sfps from fs dot com > >> > >> Hi Gary, > >> > > [snip...] > >> > >> Jason M. Barrette > >> President > >> > >> D (949) 242-8077 M (714) 357-6295 > >> > >> Email: jason at enetusa.com > >> Visit us at: www.enetusa.com > >> > >> From: Gary A Mumphrey > >> Sent: Friday, September 20, 2019 7:44 AM > >> To: nwarren at barryelectric.com > >> Cc: Jason Barrette > >> Subject: RE: sfps from fs dot com > >> > >> Nicholas, > >> > > [snip...] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Fri Sep 20 17:10:05 2019 From: bruns at 2mbit.com (Brielle) Date: Fri, 20 Sep 2019 11:10:05 -0600 Subject: Sales Contact Opt-out? In-Reply-To: References: Message-ID: <24172139-3ca3-7e4e-5d5c-33e8bdd3c0d1@2mbit.com> Yay, another company I can add to my 'never ever do business with even if they were the last company on earth'. Thx! On 9/20/2019 10:37 AM, Nicholas Warren wrote: > Is it possible to opt out of sales contact from those on the list? > Or is this simply the price to pay for seeking the list's wisdom? > >> -----Original Message----- >> From: Jason Barrette >> Sent: Friday, September 20, 2019 11:28 AM >> To: Gary A Mumphrey ; Nicholas Warren >> Subject: RE: sfps from fs dot com >> >> Hi Gary, >> > [snip...] >> >> Jason M. Barrette >> President >> >> D (949) 242-8077 M (714) 357-6295 >> >> Email: jason at enetusa.com >> Visit us at: www.enetusa.com >> >> From: Gary A Mumphrey >> Sent: Friday, September 20, 2019 7:44 AM >> To: nwarren at barryelectric.com >> Cc: Jason Barrette >> Subject: RE: sfps from fs dot com >> >> Nicholas, >> > [snip...] > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From michel.py at tsisemi.com Fri Sep 20 17:29:33 2019 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 20 Sep 2019 17:29:33 +0000 Subject: sfps from fs dot com In-Reply-To: References: Message-ID: > Nicholas Warren wrote : > Anyone have experience with fs.com's lasers? Are they reliable? I have a few hundreds of them, started buying from them about 3 years ago, not a single issue so far. I'm going to buy their box soon, so I could recode a Cisco optic into an HP one, easier on spares management. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From neil at shrug.pw Fri Sep 20 13:06:08 2019 From: neil at shrug.pw (Neil Hanlon) Date: Fri, 20 Sep 2019 09:06:08 -0400 Subject: sfps from fs dot com In-Reply-To: <81F9BAD0-5E9C-4312-8F37-0D8517D04C28@lixfeld.ca> References: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> <81F9BAD0-5E9C-4312-8F37-0D8517D04C28@lixfeld.ca> Message-ID: I've got a whole bunch running with no issues.. Mostly MM/850nm though, so maybe a bit different than their SM stuff. Also have a handful (literally) of the SM ones, and haven't had any issues (yet). Only "problem" I've had is a copper SFP from them which may have burned out and fried a switchport... oops. On Fri, Sep 20, 2019 at 9:01 AM Jason Lixfeld wrote: > > > On Sep 20, 2019, at 8:54 AM, Bryan Holloway wrote: > > > > In my travels we see a high failure rate -- higher than I'd like to see > --, but $boss likes the price, and, as Jason pointed out below, for the > price, it can be a "successful" business model. > > > For someone who doesn't want to deal with outages, call-volume, hands > tickets, truck-rolls, and has money to burn, there are better alternatives. > > Indeed. My tune would be very different if we had 1:50 fail in the field. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at pedantictheory.com Fri Sep 20 18:35:29 2019 From: richard at pedantictheory.com (Richard Porter) Date: Fri, 20 Sep 2019 13:35:29 -0500 Subject: DARAZ.COM.BD In-Reply-To: References: <47BB61D6-FE99-4F61-81AF-035A8794DEC0@beckman.org> Message-ID: "Ham eggs bacon and spam?" - MP Could not resist.... MUST ... Sing ... SONG! On Fri, Sep 20, 2019 at 10:26 AM Mike Hale wrote: > Lovely Spam! Wonderful Spam! > Lovely Spam! Wonderful Spam > > On Fri, Sep 20, 2019, 7:50 AM Mel Beckman wrote: > >> Maybe email them directly? Posting to the list just gets us all more >> spam. >> >> -mel via cell >> >> > On Sep 20, 2019, at 5:47 AM, Jared Mauch wrote: >> > >> > Can you please turn off your salesforce/autoresponder to nanog posts >> please? >> > >> > - jared >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at neko.id.au Fri Sep 20 22:20:50 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Fri, 20 Sep 2019 22:20:50 +0000 Subject: sfps from fs dot com In-Reply-To: References: , Message-ID: <2F01E3E3-CF7C-40A0-BBCC-1AA0297757CF@neko.id.au> Another vote for Approved here, awesome group of people and very thorough in their testing and fault analysis. We buy from them for Juniper, Ciena, Mellanox, Intel and a bunch of other random stuff. I’ve had mixed results with FS. Some stuff works fine, others we have high failure rates on longer term after 18 months give or take a little bit. The failed units typically come from interfaces that run at very high utilization levels 24x7 but have never done any more correlation than that. Sent from my iPhone On Sep 20, 2019, at 11:44 AM, Carl Peterson > wrote: We have had some failures with 10G BiDi optics coded for Juniper. We buy a ton of other stuff from FS but for optics we have moved over to Approved Optics for everything but active ethernet residential subscribers. On Fri, Sep 20, 2019 at 7:33 AM Nicholas Warren > wrote: Anyone have experience with fs.com's lasers? Are they reliable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tb at tburke.us Sun Sep 22 12:52:32 2019 From: tb at tburke.us (Tim Burke) Date: Sun, 22 Sep 2019 07:52:32 -0500 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: That is just The Cogent Way™, unfortunately. I just had (yet another) Cogent rep spam me using an email address that is _only_ used as an ARIN contact, trying to sell me bandwidth. When I called him out on it, with compliance at arin.net CCed, he backpedaled and claimed to obtain my information from Google. Gotta love these awful bottom feeding companies. On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: > Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. > > -- > Dmitry Sherman > Interhost Networks Ltd > Dmitry at interhost.net > Mobile: +972-54-3181182 > Office: +972-74-7029881 > Web: www.interhost.co.il > > On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" wrote: > > > If you don’t like Cogent - explain. > > Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. > They abuse whois. They are one of the primary reasons few people put their real phone number in whois. > > And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. > Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. > > If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. > > Michel > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Sun Sep 22 13:02:27 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Sun, 22 Sep 2019 08:02:27 -0500 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. Don't get mad at the sales reps, maybe think a little higher up the food chain. Each rep I've had has been very fair and respectful. If I don't need anything new, I tell them to followup with me in 6 months and they do. At most they send me a 2 sentence email to see if I need anything. That's something a good rep should do to make sure they're always in the back of your mind and easy to reach. Also, just because you don't like their sales process doesn't mean their network is bad. We've had them for 3 years and never had a single outage. The very few times we did call them for routing questions, they picked up the phone immediately and knew what to do. That already makes them better than some companies that cost 5 times as much. At cogent pricing, you should receive the worst support but it's damn good right along with HE support. Both are the most affordable transit providers but offer the best support. The more expensive guys should get their crap together. On Sun, Sep 22, 2019, 7:54 AM Tim Burke wrote: > That is just The Cogent Way™, unfortunately. I just had (yet another) > Cogent rep spam me using an email address that is _only_ used as an ARIN > contact, trying to sell me bandwidth. When I called him out on it, with > compliance at arin.net CCed, he backpedaled and claimed to obtain my > information from Google. > > Gotta love these awful bottom feeding companies. > > On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: > > Cogent are spamming seriously, they call me from different phone number in > Frankfurt and USA in holidays or at night. > > -- > Dmitry Sherman > Interhost Networks Ltd > Dmitry at interhost.net > Mobile: +972-54-3181182 > Office: +972-74-7029881 > Web: www.interhost.co.il > > On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" < > nanog-bounces at nanog.org on behalf of michel.py at tsisemi.com> wrote: > > > If you don’t like Cogent - explain. > > Besides the peering issues, they can't stop spamming. If after 20 > attempts on the phone you have not picked up, they start to send email. > They abuse whois. They are one of the primary reasons few people put > their real phone number in whois. > > And I have never talked to that level of incompetence. Tell their > sales droids that you want a link over RFC 1149, or that you need BGT > (instead of BGP), they will tell you no problem. > Don't even try to ask anything about communities or RPKI; they can't > tell the difference between a router and a connected coffee pot. If you > must deal with them, record everything. > > If someone has a cheap Asterisk trick so when the caller ID says > COGENT it goes directly to Lenny I'll take it. > > Michel > > TSI Disclaimer: This message and any files or text attached to it are > intended only for the recipients named above and contain information that > may be confidential or privileged. If you are not the intended recipient, > you must not forward, copy, use or otherwise disclose this communication or > the information contained herein. In the event you have received this > message in error, please notify the sender immediately by replying to this > message, and then delete all copies of it from your system. Thank you!... > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tb at tburke.us Sun Sep 22 13:48:41 2019 From: tb at tburke.us (Tim Burke) Date: Sun, 22 Sep 2019 08:48:41 -0500 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: <46d06de9-9a30-47d2-9413-044be26db692@www.fastmail.com> Ethical business practices are quite important to me... I don't care how their pricing is, if every one of their sales reps is on-par with a used car salesman, I want nothing to do with them. No other carrier I deal with acts in this fashion. If you're OK with cheap bandwidth sold by car sales rejects, that's fine... but I am most certainly not interested. On Sun, Sep 22, 2019, at 8:02 AM, Darin Steffl wrote: > It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. > > Don't get mad at the sales reps, maybe think a little higher up the food chain. Each rep I've had has been very fair and respectful. If I don't need anything new, I tell them to followup with me in 6 months and they do. At most they send me a 2 sentence email to see if I need anything. That's something a good rep should do to make sure they're always in the back of your mind and easy to reach. > > Also, just because you don't like their sales process doesn't mean their network is bad. We've had them for 3 years and never had a single outage. The very few times we did call them for routing questions, they picked up the phone immediately and knew what to do. > > That already makes them better than some companies that cost 5 times as much. At cogent pricing, you should receive the worst support but it's damn good right along with HE support. Both are the most affordable transit providers but offer the best support. The more expensive guys should get their crap together. > > On Sun, Sep 22, 2019, 7:54 AM Tim Burke wrote: >> __ >> That is just The Cogent Way™, unfortunately. I just had (yet another) Cogent rep spam me using an email address that is _only_ used as an ARIN contact, trying to sell me bandwidth. When I called him out on it, with compliance at arin.net CCed, he backpedaled and claimed to obtain my information from Google. >> >> Gotta love these awful bottom feeding companies. >> >> On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: >>> Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. >>> >>> -- >>> Dmitry Sherman >>> Interhost Networks Ltd >>> Dmitry at interhost.net >>> Mobile: +972-54-3181182 >>> Office: +972-74-7029881 >>> Web: www.interhost.co.il >>> >>> On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" wrote: >>> >>> > If you don’t like Cogent - explain. >>> >>> Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. >>> They abuse whois. They are one of the primary reasons few people put their real phone number in whois. >>> >>> And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. >>> Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. >>> >>> If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. >>> >>> Michel >>> >>> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at interhost.net Sun Sep 22 14:54:05 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Sun, 22 Sep 2019 14:54:05 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: <46d06de9-9a30-47d2-9413-044be26db692@www.fastmail.com> References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> , <46d06de9-9a30-47d2-9413-044be26db692@www.fastmail.com> Message-ID: They are not that cheap... Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry at interhost.net Mob: 054-3181182 Sent from Steve's creature [X] On 22 Sep 2019, at 16:49, Tim Burke > wrote: Ethical business practices are quite important to me... I don't care how their pricing is, if every one of their sales reps is on-par with a used car salesman, I want nothing to do with them. No other carrier I deal with acts in this fashion. If you're OK with cheap bandwidth sold by car sales rejects, that's fine... but I am most certainly not interested. On Sun, Sep 22, 2019, at 8:02 AM, Darin Steffl wrote: It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. Don't get mad at the sales reps, maybe think a little higher up the food chain. Each rep I've had has been very fair and respectful. If I don't need anything new, I tell them to followup with me in 6 months and they do. At most they send me a 2 sentence email to see if I need anything. That's something a good rep should do to make sure they're always in the back of your mind and easy to reach. Also, just because you don't like their sales process doesn't mean their network is bad. We've had them for 3 years and never had a single outage. The very few times we did call them for routing questions, they picked up the phone immediately and knew what to do. That already makes them better than some companies that cost 5 times as much. At cogent pricing, you should receive the worst support but it's damn good right along with HE support. Both are the most affordable transit providers but offer the best support. The more expensive guys should get their crap together. On Sun, Sep 22, 2019, 7:54 AM Tim Burke > wrote: That is just The Cogent Way™, unfortunately. I just had (yet another) Cogent rep spam me using an email address that is _only_ used as an ARIN contact, trying to sell me bandwidth. When I called him out on it, with compliance at arin.net CCed, he backpedaled and claimed to obtain my information from Google. Gotta love these awful bottom feeding companies. On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. -- Dmitry Sherman Interhost Networks Ltd Dmitry at interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" on behalf of michel.py at tsisemi.com> wrote: > If you don’t like Cogent - explain. Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. They abuse whois. They are one of the primary reasons few people put their real phone number in whois. And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Sun Sep 22 16:20:20 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Sun, 22 Sep 2019 11:20:20 -0500 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <46d06de9-9a30-47d2-9413-044be26db692@www.fastmail.com> Message-ID: Tim, The reps themselves have not been unethical. They've not lied or been dishonest to me in the sales process at all. Comparing them to a shady used car salesman is not a fair comparison. They are likely given a list of leads and need to make so many cold calls to show they're trying to make sales. That's not to say some reps will do unethical things vs other reps like ours who were nothing but honest, good people. I think it's juvenile to avoid a company solely on reps reaching out to sell to you. That's their job. If their network and support is good and their cost is attractive, get over your petty reasons for avoiding them. You're stuck on one point and hold a grudge because "their sales process is shady". I've seen shady companies and cogent isn't one of them. Take CenturyLink where they quote a small business $100 for internet and phone but the bill is actually $197 after all the hidden fees and tax. That's shady. Cogent has never done that. They bill you exactly what's in the contract and not a penny more. Zayo adds hidden fees and BS reasons for why they collect them and there's no way out of it. Again, not a problem with cogent or Hurricane. On Sun, Sep 22, 2019, 9:53 AM Dmitry Sherman wrote: > They are not that cheap... > > Best regards, > Dmitry Sherman > Interhost Networks > www.interhost.co.il > Dmitry at interhost.net > Mob: 054-3181182 > Sent from Steve's creature > > On 22 Sep 2019, at 16:49, Tim Burke wrote: > > Ethical business practices are quite important to me... I don't care how > their pricing is, if every one of their sales reps is on-par with a used > car salesman, I want nothing to do with them. No other carrier I deal with > acts in this fashion. > > If you're OK with cheap bandwidth sold by car sales rejects, that's > fine... but I am most certainly not interested. > > On Sun, Sep 22, 2019, at 8:02 AM, Darin Steffl wrote: > > It may be unethical to pull emails from ARIN listings but their sales guys > have a job to do and quotas to meet. > > Don't get mad at the sales reps, maybe think a little higher up the food > chain. Each rep I've had has been very fair and respectful. If I don't need > anything new, I tell them to followup with me in 6 months and they do. At > most they send me a 2 sentence email to see if I need anything. That's > something a good rep should do to make sure they're always in the back of > your mind and easy to reach. > > Also, just because you don't like their sales process doesn't mean their > network is bad. We've had them for 3 years and never had a single outage. > The very few times we did call them for routing questions, they picked up > the phone immediately and knew what to do. > > That already makes them better than some companies that cost 5 times as > much. At cogent pricing, you should receive the worst support but it's damn > good right along with HE support. Both are the most affordable transit > providers but offer the best support. The more expensive guys should get > their crap together. > > On Sun, Sep 22, 2019, 7:54 AM Tim Burke wrote: > > > That is just The Cogent Way™, unfortunately. I just had (yet another) > Cogent rep spam me using an email address that is _only_ used as an ARIN > contact, trying to sell me bandwidth. When I called him out on it, with > compliance at arin.net CCed, he backpedaled and claimed to obtain my > information from Google. > > Gotta love these awful bottom feeding companies. > > On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: > > Cogent are spamming seriously, they call me from different phone number in > Frankfurt and USA in holidays or at night. > > -- > Dmitry Sherman > Interhost Networks Ltd > Dmitry at interhost.net > Mobile: +972-54-3181182 > Office: +972-74-7029881 > Web: www.interhost.co.il > > On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" < > nanog-bounces at nanog.org on behalf of michel.py at tsisemi.com> wrote: > > > If you don’t like Cogent - explain. > > Besides the peering issues, they can't stop spamming. If after 20 > attempts on the phone you have not picked up, they start to send email. > They abuse whois. They are one of the primary reasons few people put > their real phone number in whois. > > And I have never talked to that level of incompetence. Tell their > sales droids that you want a link over RFC 1149, or that you need BGT > (instead of BGP), they will tell you no problem. > Don't even try to ask anything about communities or RPKI; they can't > tell the difference between a router and a connected coffee pot. If you > must deal with them, record everything. > > If someone has a cheap Asterisk trick so when the caller ID says > COGENT it goes directly to Lenny I'll take it. > > Michel > > TSI Disclaimer: This message and any files or text attached to it are > intended only for the recipients named above and contain information that > may be confidential or privileged. If you are not the intended recipient, > you must not forward, copy, use or otherwise disclose this communication or > the information contained herein. In the event you have received this > message in error, please notify the sender immediately by replying to this > message, and then delete all copies of it from your system. Thank you!... > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tb at tburke.us Sun Sep 22 17:08:21 2019 From: tb at tburke.us (Tim Burke) Date: Sun, 22 Sep 2019 12:08:21 -0500 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> <46d06de9-9a30-47d2-9413-044be26db692@www.fastmail.com> Message-ID: Call me juvenile all you like, it doesn't bother me... :-) Being one of the younger folks in this industry, it's definitely not the first time. If you like Cogent, that's great, but don't attack me just because I think their sales reps are shady. I can assure you that the reps that were harassing me weren't just given a list of leads, they went out of their way to look through ARIN's new allocation list and spam the living crap out of people. With that said, I am a man of ethics and morals, and will do whatever I can to ensure that I do not do business with companies that employ people that engage in unethical tactics. I've had no other bandwidth provider engage in Cogent's tactics, including the three that I currently do business with, and have an extremely positive relationship with. On Sun, Sep 22, 2019, at 11:20 AM, Darin Steffl wrote: > Tim, > > The reps themselves have not been unethical. They've not lied or been dishonest to me in the sales process at all. Comparing them to a shady used car salesman is not a fair comparison. > > They are likely given a list of leads and need to make so many cold calls to show they're trying to make sales. > > That's not to say some reps will do unethical things vs other reps like ours who were nothing but honest, good people. > > I think it's juvenile to avoid a company solely on reps reaching out to sell to you. That's their job. If their network and support is good and their cost is attractive, get over your petty reasons for avoiding them. You're stuck on one point and hold a grudge because "their sales process is shady". > > I've seen shady companies and cogent isn't one of them. Take CenturyLink where they quote a small business $100 for internet and phone but the bill is actually $197 after all the hidden fees and tax. That's shady. Cogent has never done that. They bill you exactly what's in the contract and not a penny more. > > Zayo adds hidden fees and BS reasons for why they collect them and there's no way out of it. Again, not a problem with cogent or Hurricane. > > > On Sun, Sep 22, 2019, 9:53 AM Dmitry Sherman wrote: >> They are not that cheap... >> >> Best regards, >> Dmitry Sherman >> Interhost Networks >> www.interhost.co.il >> Dmitry at interhost.net >> Mob: 054-3181182 >> Sent from Steve's creature >> >> >> On 22 Sep 2019, at 16:49, Tim Burke wrote: >> >>> Ethical business practices are quite important to me... I don't care how their pricing is, if every one of their sales reps is on-par with a used car salesman, I want nothing to do with them. No other carrier I deal with acts in this fashion. >>> >>> If you're OK with cheap bandwidth sold by car sales rejects, that's fine... but I am most certainly not interested. >>> >>> On Sun, Sep 22, 2019, at 8:02 AM, Darin Steffl wrote: >>>> It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. >>>> >>>> Don't get mad at the sales reps, maybe think a little higher up the food chain. Each rep I've had has been very fair and respectful. If I don't need anything new, I tell them to followup with me in 6 months and they do. At most they send me a 2 sentence email to see if I need anything. That's something a good rep should do to make sure they're always in the back of your mind and easy to reach. >>>> >>>> Also, just because you don't like their sales process doesn't mean their network is bad. We've had them for 3 years and never had a single outage. The very few times we did call them for routing questions, they picked up the phone immediately and knew what to do. >>>> >>>> That already makes them better than some companies that cost 5 times as much. At cogent pricing, you should receive the worst support but it's damn good right along with HE support. Both are the most affordable transit providers but offer the best support. The more expensive guys should get their crap together. >>>> >>>> On Sun, Sep 22, 2019, 7:54 AM Tim Burke wrote: >>>>> __ >>>>> That is just The Cogent Way™, unfortunately. I just had (yet another) Cogent rep spam me using an email address that is _only_ used as an ARIN contact, trying to sell me bandwidth. When I called him out on it, with compliance at arin.net CCed, he backpedaled and claimed to obtain my information from Google. >>>>> >>>>> Gotta love these awful bottom feeding companies. >>>>> >>>>> On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: >>>>>> Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. >>>>>> >>>>>> -- >>>>>> Dmitry Sherman >>>>>> Interhost Networks Ltd >>>>>> Dmitry at interhost.net >>>>>> Mobile: +972-54-3181182 >>>>>> Office: +972-74-7029881 >>>>>> Web: www.interhost.co.il >>>>>> >>>>>> On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" wrote: >>>>>> >>>>>> > If you don’t like Cogent - explain. >>>>>> >>>>>> Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. >>>>>> They abuse whois. They are one of the primary reasons few people put their real phone number in whois. >>>>>> >>>>>> And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. >>>>>> Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. >>>>>> >>>>>> If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. >>>>>> >>>>>> Michel >>>>>> >>>>>> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... >>>>>> >>>>>> >>>>>> >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Sep 22 18:01:29 2019 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Sep 2019 11:01:29 -0700 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: > On Sep 22, 2019, at 06:02 , Darin Steffl wrote: > > It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. It’s not just unethical. It violates the ToS/AUP for Whois which is clearly attached to the results from each whois query. Also, I suspect that given the volume and rate of Cogent SPAM, they are subscribed to bulk whois and/or one or more of ARIN’s update feeds. Subscribing to those requires signing a contract agreeing to the ToS/AUP. I encourage anyone who is fed up with Cogent SPAM to forward copies of it with as much evidence as you have to show that the information must have been obtained via WHOIS to compliance at arin.net. The more evidence ARIN receives, the more likely it is that they can take effective action. > Don't get mad at the sales reps, maybe think a little higher up the food chain. Each rep I've had has been very fair and respectful. If I don't need anything new, I tell them to followup with me in 6 months and they do. At most they send me a 2 sentence email to see if I need anything. That's something a good rep should do to make sure they're always in the back of your mind and easy to reach. Why on earth not? They’re doing something unethical _AND_ against the ToS for the service they are using in order to obtain the information. I get angry with the Sales representatives as well as higher up the food chain all the way to the top of Cogent management. I’ve repeatedly told them to never contact me again and yet every time I register anything with ARIN on behalf of one of my clients, I get more Cogent SPAM. > Also, just because you don't like their sales process doesn't mean their network is bad. We've had them for 3 years and never had a single outage. The very few times we did call them for routing questions, they picked up the phone immediately and knew what to do. On the other hand, just because their sales representatives and management are proven to behave unethically (at best) and well known to violate terms of contracts that are inconvenient to them DOES mean that I do not want to do business with them. > That already makes them better than some companies that cost 5 times as much. At cogent pricing, you should receive the worst support but it's damn good right along with HE support. Both are the most affordable transit providers but offer the best support. The more expensive guys should get their crap together. Even if they ran the best network on the planet with the best customer service I’d ever experienced (they don’t in my experience and my experience differs greatly from yours), I still prefer not to do business with companies I KNOW are unethical and untrustworthy. If you enjoy the customer experience of doing business with unethical companies, then by all means, continue along. OTOH, if you want to see this behavior stop, the best thing you can do is vote with your dollars the way capitalism and the free market is supposed to work. If you reward unethical behavior, you get more unethical behavior. Owen > > On Sun, Sep 22, 2019, 7:54 AM Tim Burke > wrote: > That is just The Cogent Way™, unfortunately. I just had (yet another) Cogent rep spam me using an email address that is _only_ used as an ARIN contact, trying to sell me bandwidth. When I called him out on it, with compliance at arin.net CCed, he backpedaled and claimed to obtain my information from Google. > > Gotta love these awful bottom feeding companies. > > On Thu, Sep 19, 2019, at 10:05 AM, Dmitry Sherman wrote: >> Cogent are spamming seriously, they call me from different phone number in Frankfurt and USA in holidays or at night. >> >> -- >> Dmitry Sherman >> Interhost Networks Ltd >> Dmitry at interhost.net >> Mobile: +972-54-3181182 >> Office: +972-74-7029881 >> Web: www.interhost.co.il >> >> On 17/09/2019, 3:25, "NANOG on behalf of Michel Py" on behalf of michel.py at tsisemi.com > wrote: >> >> > If you don’t like Cogent - explain. >> >> Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. >> They abuse whois. They are one of the primary reasons few people put their real phone number in whois. >> >> And I have never talked to that level of incompetence. Tell their sales droids that you want a link over RFC 1149, or that you need BGT (instead of BGP), they will tell you no problem. >> Don't even try to ask anything about communities or RPKI; they can't tell the difference between a router and a connected coffee pot. If you must deal with them, record everything. >> >> If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes directly to Lenny I'll take it. >> >> Michel >> >> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djratkay79 at gmail.com Mon Sep 23 08:01:43 2019 From: djratkay79 at gmail.com (David Ratkay) Date: Mon, 23 Sep 2019 04:01:43 -0400 Subject: ISP Job Message-ID: I have been looking to work at an ISP for a long time now. I live in Northern Indiana in the US and there seems to not be much opportunities to work for an ISP in this region. Any recommendations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Sep 23 08:20:01 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 23 Sep 2019 08:20:01 +0000 Subject: ISP Job In-Reply-To: References: Message-ID: <82F3DB1D-DF19-49A8-B43E-9717565DE243@beckman.org> What are your credentials? -mel beckman > On Sep 23, 2019, at 1:02 AM, David Ratkay wrote: > > I have been looking to work at an ISP for a long time now. I live in Northern Indiana in the US and there seems to not be much opportunities to work for an ISP in this region. Any recommendations? From ahebert at pubnix.net Mon Sep 23 13:19:45 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 23 Sep 2019 09:19:45 -0400 Subject: sfps from fs dot com In-Reply-To: References: <994E43E7-3F8A-4CEC-8731-6D1B44526D88@lixfeld.ca> Message-ID: <4628717a-8650-0f4e-e642-2273c2221242@pubnix.net>     Hi,     Back last year, I experienced less than expected reliability with QFX and their QSFPs.     We prefer to use optic.ca since they're a few minutes from our DC's and will respond within the day, with platform and firmware changes, which we can test in lab before shipping to our remotes.     The price difference is made reducing downtime in our case. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 2019-09-20 08:54, Bryan Holloway wrote: > It boils down to a business case. > > In my travels we see a high failure rate -- higher than I'd like to > see --, but $boss likes the price, and, as Jason pointed out below, > for the price, it can be a "successful" business model. > > In a nutshell: > > For someone on a budget, they're great; buy spares. > > For someone who doesn't want to deal with outages, call-volume, hands > tickets, truck-rolls, and has money to burn, there are better > alternatives. > > > On 9/20/19 2:41 PM, Jason Lixfeld wrote: >> We have maybe 1:50 DOA, but they’re so cheap, we just throw them out >> because it’s not worth the RMA. >> >> That said, I can’t remember the last time we’ve had any of these fail >> in the field, or have had any issues with variablity in TX/RX power.  >> We have tens of thousands of these in the field, from 100Mb Bidi to >> 100G-LR and everything in between, including *WDM up to 80KM. >> >>> On Sep 20, 2019, at 8:31 AM, Nicholas Warren >>> wrote: >>> >>> Anyone have experience with fs.com's lasers? Are they reliable? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.py at tsisemi.com Mon Sep 23 18:00:31 2019 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 23 Sep 2019 18:00:31 +0000 Subject: Cogent sales reps who actually respond In-Reply-To: References: <55DD5B14-8BE1-49D1-8AE5-7FB9D653DEE6@gmail.com> Message-ID: > Darin Steffl wrote : > It may be unethical to pull emails from ARIN listings but their sales guys have a job to do and quotas to meet. There is no excuse for spamming. Ever. > Also, just because you don't like their sales process doesn't mean their network is bad. It actually does. They provide service to anyone regardless of how unethical or illegal the business is. By doing so, they provoke congestions at points they they refuse to upgrade hoping to milk both sides. If you get transit from Cogent, you may end up being on the same side as an oversubcribed link as crooks such as Megaupload and get degraded service for your customers. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From meirea at charterschoolit.com Mon Sep 23 18:43:31 2019 From: meirea at charterschoolit.com (Mario Eirea) Date: Mon, 23 Sep 2019 18:43:31 +0000 Subject: EA Sports Message-ID: Greetings, Trying to get passed tier one tech support in EA sports. Looks like one of our external IP may have been mistakenly flagged as a bot, if anyone from EA sports is available please contract me offline. Thank you, Mario Eirea IT Department Layer 8 Solutions 7701 W 26th Ave Unit 2 Hialeah, FL 33016-5603 25.892545°, -80.335783° U.S.A., Earth, Solar System, Milky Way, Local Group, Universe Ph: 786-212-1660 "Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest." - Albert Einstein [https://charterschoolit.com/1up_micro.png] [http://charterschoolit.com/layer8_micro.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Mon Sep 23 19:05:43 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 23 Sep 2019 12:05:43 -0700 Subject: Colombia Network Operators Group Message-ID: <20190923120543.FEC402B5@m0117567.ppops.net> --- mehmet at akcin.net wrote: From: Mehmet Akcin Few people who is doing a lot of work in Colombia, we decided to start Colombia network operators group and arrange local meetups, provide people support who want to have infrastructure here. Feel free to join www.nog.com.co and our first face to face meeting will be in december, date to be announced soon! ----------------------------------------- For whatever reason, cisco is not happy with the site: "This site is blocked due to a security threat that was discovered by the Cisco Umbrella security researchers." scott From kmedcalf at dessus.com Mon Sep 23 19:59:27 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 23 Sep 2019 13:59:27 -0600 Subject: Colombia Network Operators Group In-Reply-To: <20190923120543.FEC402B5@m0117567.ppops.net> Message-ID: <6f2876a6abe02547ba85adb58bd21692@mail.dessus.com> Fascinating. What is the security threat I wonder, that there is no JavaScript? >-----Original Message----- >From: NANOG On Behalf Of Scott Weeks >Sent: Monday, 23 September, 2019 13:06 >To: nanog at nanog.org >Subject: Re: Colombia Network Operators Group > > > >--- mehmet at akcin.net wrote: >From: Mehmet Akcin > >Few people who is doing a lot of work in Colombia, we decided to start >Colombia network operators group and arrange local meetups, provide >people >support who want to have infrastructure here. > >Feel free to join www.nog.com.co and our first face to face meeting will >be >in december, date to be announced soon! >----------------------------------------- > > > >For whatever reason, cisco is not happy with the site: > >"This site is blocked due to a security threat that was discovered by >the Cisco Umbrella security researchers." > >scott From rfg at tristatelogic.com Mon Sep 23 20:45:12 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 23 Sep 2019 13:45:12 -0700 Subject: Colombia Network Operators Group In-Reply-To: <6f2876a6abe02547ba85adb58bd21692@mail.dessus.com> Message-ID: <5162.1569271512@segfault.tristatelogic.com> In message <6f2876a6abe02547ba85adb58bd21692 at mail.dessus.com>, "Keith Medcalf" wrote: >Fascinating. What is the security threat I wonder, that there is no >JavaScript? Undoubtedly drug smuggling over HTTP. From surfer at mauigateway.com Mon Sep 23 21:06:36 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 23 Sep 2019 14:06:36 -0700 Subject: Colombia Network Operators Group Message-ID: <20190923140636.FEC409F6@m0117567.ppops.net> >-----Original Message----- >From: NANOG On Behalf Of Scott Weeks >--- mehmet at akcin.net wrote: >From: Mehmet Akcin > >Few people who is doing a lot of work in Colombia, we decided to start >Colombia network operators group and arrange local meetups, provide >people >support who want to have infrastructure here. > >Feel free to join www.nog.com.co and our first face to face meeting will >be >in december, date to be announced soon! >----------------------------------------- >For whatever reason, cisco is not happy with the site: > >"This site is blocked due to a security threat that was discovered by >the Cisco Umbrella security researchers." --- kmedcalf at dessus.com wrote: From: "Keith Medcalf" Fascinating. What is the security threat I wonder, that there is no JavaScript? ----------------------------------------------- I don't know. New job with new security stuff (that I don't have anything to do with) and I am sure I'm not the one, so I thought I'd let folks know. scott From amekkaoui at mektel.ca Mon Sep 23 21:09:57 2019 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Mon, 23 Sep 2019 17:09:57 -0400 Subject: NetworkLayer Message-ID: <00cb01d57253$4207b0f0$c61712d0$@ca> Hi Anyone from Network Layer to help? We are experiencing packet loss on the their MPLS network. I have attached a screenshot. Thank you 4 38.140.46.161 0% 31 16.3ms 18.6 6.4 153.1 24.9 5 154.54.45.113 0% 31 9.8ms 13.9 9 19.2 2.9 6 62.115.168.46 0% 31 12.5ms 16.3 10.2 66 9.7 7 62.115.134.48 0% 31 25.6ms 23.4 16.5 39.2 5.7 8 62.115.51.98 0% 31 19.4ms 22.6 16.6 49.9 6.1 9 50.97.19.12 0% 31 20.2ms 22 12.8 37.9 4.3 10 50.97.19.15 0% 31 35.9ms 33 28.6 41.7 3 11 50.97.17.30 71% 31 timeout 35.3 29.8 42.8 4.9 12 169.45.18.4 40% 31 58ms 56.4 50.6 61.6 3.1 13 169.45.18.41 0% 30 149.6ms 62.7 50.5 149.6 23.4 14 169.48.118.131 0% 30 133.4ms 59.8 50.2 133.4 14.7 Karim -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddunder at gmail.com Mon Sep 23 21:11:27 2019 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 23 Sep 2019 17:11:27 -0400 Subject: Colombia Network Operators Group In-Reply-To: <5162.1569271512@segfault.tristatelogic.com> References: <6f2876a6abe02547ba85adb58bd21692@mail.dessus.com> <5162.1569271512@segfault.tristatelogic.com> Message-ID: References to all things Colombian being related to drugs and smuggling are racist. Please don't be racist here. Thanks! t On Mon, Sep 23, 2019 at 4:46 PM Ronald F. Guilmette wrote: > In message <6f2876a6abe02547ba85adb58bd21692 at mail.dessus.com>, > "Keith Medcalf" wrote: > > >Fascinating. What is the security threat I wonder, that there is no > >JavaScript? > > Undoubtedly drug smuggling over HTTP. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Mon Sep 23 21:16:30 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 23 Sep 2019 17:16:30 -0400 Subject: ISP Job In-Reply-To: <82F3DB1D-DF19-49A8-B43E-9717565DE243@beckman.org> References: <82F3DB1D-DF19-49A8-B43E-9717565DE243@beckman.org> Message-ID: There are many many WISPs in Indiana. If you'd like help tracking them down, shoot me a message. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Sep 23, 2019 at 4:20 AM Mel Beckman wrote: > What are your credentials? > > -mel beckman > > > On Sep 23, 2019, at 1:02 AM, David Ratkay wrote: > > > > I have been looking to work at an ISP for a long time now. I live in > Northern Indiana in the US and there seems to not be much opportunities to > work for an ISP in this region. Any recommendations? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Mon Sep 23 21:16:56 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 23 Sep 2019 21:16:56 +0000 Subject: NetworkLayer In-Reply-To: <00cb01d57253$4207b0f0$c61712d0$@ca> References: <00cb01d57253$4207b0f0$c61712d0$@ca> Message-ID: Before the mob descends, I'll take the liberty of pointing you at this: https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf If the loss does not extend past a given hop to the end of the trace, it's not loss - it's probably a transit router rate limiting your trace packets. From mehmet at akcin.net Mon Sep 23 21:42:59 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 23 Sep 2019 14:42:59 -0700 Subject: Colombia Network Operators Group In-Reply-To: <5162.1569271512@segfault.tristatelogic.com> References: <6f2876a6abe02547ba85adb58bd21692@mail.dessus.com> <5162.1569271512@segfault.tristatelogic.com> Message-ID: This isn't funny. This is actually incredibly offensive. On Mon, Sep 23, 2019 at 1:45 PM Ronald F. Guilmette wrote: > In message <6f2876a6abe02547ba85adb58bd21692 at mail.dessus.com>, > "Keith Medcalf" wrote: > > >Fascinating. What is the security threat I wonder, that there is no > >JavaScript? > > Undoubtedly drug smuggling over HTTP. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.william.smith at gmail.com Mon Sep 23 21:45:07 2019 From: andrew.william.smith at gmail.com (Andrew Smith) Date: Mon, 23 Sep 2019 16:45:07 -0500 Subject: ISP Job In-Reply-To: References: Message-ID: http://www.wispa.org/Directories/Find-a-WISP On Mon, Sep 23, 2019 at 3:03 AM David Ratkay wrote: > I have been looking to work at an ISP for a long time now. I live in > Northern Indiana in the US and there seems to not be much opportunities to > work for an ISP in this region. Any recommendations? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Mon Sep 23 21:57:11 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 23 Sep 2019 21:57:11 +0000 Subject: NetworkLayer In-Reply-To: <00cb01d57253$4207b0f0$c61712d0$@ca> References: <00cb01d57253$4207b0f0$c61712d0$@ca> Message-ID: Just a tip, but you cannot really determine packet loss on an MPLS network with a traceroute. The nodes between the provider edge routers may not even represent your real path. Also, provider routers within their network will be handling pings much differently than they handle your actual traffic. The pings require processing whereas your MPLS traffic will be label switched. Much different performance. Now from the trace below : If you have zero packet loss to the final hop, how could you possibly have packet loss along the path? Answer, you can't and there is no loss between you and the final hop for your traffic. What you are seeing is the intermediate node not bothering or being too busy to answer your ping. Steven Naslund Chicago IL From: NANOG On Behalf Of K MEKKAOUI Sent: Monday, September 23, 2019 4:10 PM To: nanog at nanog.org Subject: NetworkLayer Hi Anyone from Network Layer to help? We are experiencing packet loss on the their MPLS network. I have attached a screenshot. Thank you 4 38.140.46.161 0% 31 16.3ms 18.6 6.4 153.1 24.9 5 154.54.45.113 0% 31 9.8ms 13.9 9 19.2 2.9 6 62.115.168.46 0% 31 12.5ms 16.3 10.2 66 9.7 7 62.115.134.48 0% 31 25.6ms 23.4 16.5 39.2 5.7 8 62.115.51.98 0% 31 19.4ms 22.6 16.6 49.9 6.1 9 50.97.19.12 0% 31 20.2ms 22 12.8 37.9 4.3 10 50.97.19.15 0% 31 35.9ms 33 28.6 41.7 3 11 50.97.17.30 71% 31 timeout 35.3 29.8 42.8 4.9 12 169.45.18.4 40% 31 58ms 56.4 50.6 61.6 3.1 13 169.45.18.41 0% 30 149.6ms 62.7 50.5 149.6 23.4 14 169.48.118.131 0% 30 133.4ms 59.8 50.2 133.4 14.7 Karim -------------- next part -------------- An HTML attachment was scrubbed... URL: From allenmckinleykitchen at gmail.com Mon Sep 23 22:21:20 2019 From: allenmckinleykitchen at gmail.com (Allen Kitchen) Date: Mon, 23 Sep 2019 18:21:20 -0400 Subject: Barely operational .. hoping to find myspace help Message-ID: In a side volunteer "job", I work with men released from prison, often with sexual offense histories. Generally they are still on parole / supervision. Currently I have one "client" who is barely literate technically but who had a myspace account before he went to prison about 6 years ago. He's been told by state police here in PA that he must delete his old myspace account or risk re-incarceration, whether or not he has used the account. But he's also prohibited from using any social media accounts in any manner whatsoever - and has no idea what his old email was when he set this account up as a teenager. So he has asked for my help in shutting down his old unused profile. The myspace website is rather unhelpful in trying to find a way to do this without having him log in - which is both practically impossible and legally prohibited. Any myspace ops folks on the list? Please contact me off-list. All others - I truly apologize for the barely-operational content, but other avenues have been brick walls. allenmckinleykitchen at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Sep 24 00:06:39 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 23 Sep 2019 17:06:39 -0700 Subject: Colombia Network Operators Group In-Reply-To: <20190923120543.FEC402B5@m0117567.ppops.net> References: <20190923120543.FEC402B5@m0117567.ppops.net> Message-ID: This is now fixed. Thx secret Cisco team hero On Mon, Sep 23, 2019 at 12:06 Scott Weeks wrote: > > > --- mehmet at akcin.net wrote: > From: Mehmet Akcin > > Few people who is doing a lot of work in Colombia, we decided to start > Colombia network operators group and arrange local meetups, provide people > support who want to have infrastructure here. > > Feel free to join www.nog.com.co and our first face to face meeting will > be > in december, date to be announced soon! > ----------------------------------------- > > > > For whatever reason, cisco is not happy with the site: > > "This site is blocked due to a security threat that was discovered by > the Cisco Umbrella security researchers." > > scott > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From djratkay79 at gmail.com Tue Sep 24 00:46:41 2019 From: djratkay79 at gmail.com (David Ratkay) Date: Mon, 23 Sep 2019 20:46:41 -0400 Subject: ISP Job In-Reply-To: References: Message-ID: To give some more info I live in South Bend, Indiana. So Michigan actually could be an option. On Mon, Sep 23, 2019, 4:01 AM David Ratkay wrote: > I have been looking to work at an ISP for a long time now. I live in > Northern Indiana in the US and there seems to not be much opportunities to > work for an ISP in this region. Any recommendations? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Sep 24 00:53:23 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 23 Sep 2019 20:53:23 -0400 Subject: ISP Job In-Reply-To: References: Message-ID: You haven't answered the question about your credentials, though. On Mon, Sep 23, 2019, 8:48 PM David Ratkay wrote: > To give some more info I live in South Bend, Indiana. So Michigan actually > could be an option. > > On Mon, Sep 23, 2019, 4:01 AM David Ratkay wrote: > >> I have been looking to work at an ISP for a long time now. I live in >> Northern Indiana in the US and there seems to not be much opportunities to >> work for an ISP in this region. Any recommendations? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djratkay79 at gmail.com Tue Sep 24 01:02:08 2019 From: djratkay79 at gmail.com (David Ratkay) Date: Mon, 23 Sep 2019 21:02:08 -0400 Subject: ISP Job In-Reply-To: References: Message-ID: I have about over a year or so of IT helpdesk experience. I worked with some Cisco switches, basic configuration such as vlans, ssh, acl's. Installing OS's on Cisco switches. I have the CCNA R&S cert On Mon, Sep 23, 2019, 4:01 AM David Ratkay wrote: > I have been looking to work at an ISP for a long time now. I live in > Northern Indiana in the US and there seems to not be much opportunities to > work for an ISP in this region. Any recommendations? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Sep 24 01:20:56 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 24 Sep 2019 01:20:56 +0000 Subject: ISP Job In-Reply-To: References: , Message-ID: <893FD5B8-DB05-41AE-B8A9-BE53725F17F3@beckman.org> What is it windows desktop helpdesk support? That’s the most common, but the least useful for ISPs. If you have help desk support troubleshooting network problems, that’s more useful. Your Cisco skills will get you in an entry level position at most WISPs, and MPLS skills are a plus, as many larger WISPs rub MPLS in their core. Other technologies to acquire skill in are WiFi standards, radio configuration, spanning tree protocol, SNMP, and PPPoE. Start calling WISPs to offer your services as an entry level tech. WISPs are the fastest growing service provider segment. -mel via cell On Sep 23, 2019, at 6:02 PM, David Ratkay > wrote: I have about over a year or so of IT helpdesk experience. I worked with some Cisco switches, basic configuration such as vlans, ssh, acl's. Installing OS's on Cisco switches. I have the CCNA R&S cert On Mon, Sep 23, 2019, 4:01 AM David Ratkay > wrote: I have been looking to work at an ISP for a long time now. I live in Northern Indiana in the US and there seems to not be much opportunities to work for an ISP in this region. Any recommendations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Sep 24 02:59:56 2019 From: bill at herrin.us (William Herrin) Date: Mon, 23 Sep 2019 19:59:56 -0700 Subject: Barely operational .. hoping to find myspace help In-Reply-To: References: Message-ID: On Mon, Sep 23, 2019 at 3:21 PM Allen Kitchen < allenmckinleykitchen at gmail.com> wrote: > In a side volunteer "job", I work with men released from prison, often > with sexual offense histories. Generally they are still on parole / > supervision. > > Currently I have one "client" who is barely literate technically but who > had a myspace account before he went to prison about 6 years ago. > > He's been told by state police here in PA that he must delete his old > myspace account or risk re-incarceration, whether or not he has used the > account. But he's also prohibited from using any social media accounts in > any manner whatsoever - and has no idea what his old email was when he set > this account up as a teenager. So he has asked for my help in shutting down > his old unused profile. > > The myspace website is rather unhelpful in trying to find a way to do this > without having him log in - which is both practically impossible and > legally prohibited. > > https://help.myspace.com/hc/en-us search for "legal" The first link is "law enforcement." Down at the end it has an address. Prepare a letter on a lawyer's letterhead. Include a copy of the instruction you have on government letterhead ordering your client to delete his account. Send it certified mail. If the account remains online after you get the receipt for the letter's delivery, return to the judge and ask for a letter ordering myspace to delete the account. Then send a copy of that to the address. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Sep 24 05:44:00 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Sep 2019 08:44:00 +0300 Subject: NetworkLayer In-Reply-To: References: <00cb01d57253$4207b0f0$c61712d0$@ca> Message-ID: On Tue, 24 Sep 2019 at 00:59, Naslund, Steve wrote: > Just a tip, but you cannot really determine packet loss on an MPLS network with a traceroute. The nodes between the provider edge routers may not even represent your real path. Also, provider routers within their network will be handling pings much differently than they handle your actual traffic. The pings require processing whereas your MPLS traffic will be label switched. Much different performance. This is not MPSL specific, equally in natively forwarded you can only determine packet loss for the ultimate host, this is because TTL==1 packets are punted to software processing typically, and such punting is heavily rate-limited to conserve control-plane resources, so reply may not come. This isn't something devices have to do, but it is something they do, NPU based devices could reply to TTL==1 from NPU at wire-rate to fix this problem, and is only a matter of someone asking their vendor to do that. The MPLS speciality is that RTT may be far-end RTT for whole transit, because LSR may not know how to send reply, LSR may only have IGP, so LSR may need to send TTL unreachable message to far-end LER, which will then reply back to sender, causing each step to represent far-end LER RTT. This is not happening in the described traceroute. Hope this helps. -- ++ytti From sami.joseph at gmail.com Tue Sep 24 05:51:46 2019 From: sami.joseph at gmail.com (Sami Joseph) Date: Mon, 23 Sep 2019 22:51:46 -0700 Subject: Who provides this service in the US Message-ID: Hi, Any operators that would allow a customer to spin up a controller in the cloud that provisions their colo connectivity based on some App demand? Thanks Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Tue Sep 24 11:58:43 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 24 Sep 2019 13:58:43 +0200 Subject: Elad Cohen (was: Re: Cogent sales reps who actually respond) In-Reply-To: <57420.1568933405@segfault.tristatelogic.com> References: <20190919084649.GC30112@jima.tpb.net> <57420.1568933405@segfault.tristatelogic.com> Message-ID: <20190924115843.GE30112@jima.tpb.net> * rfg at tristatelogic.com (Ronald F. Guilmette) [Fri 20 Sep 2019, 00:50 CEST]: >Leaving aside the minor quibble that "Dutch" is not, as far as I am >aware, a "race" per se, I do apologize for having improperly and >quite wrongly generalized the apparent confluence of of certain >events and actions to the Dutch people generally. That was entirely >incorrect and improper on my part and I do sincerly apologize. Apologies on my end as well, Ronald. I should not have said racist; bigoted would have been a more apt description of your earlier screed. Again, I do apologise, I was clearly in the wrong here. >... it's difficult for me not to infer a possible pattern. Yep. Sure. -- Niels. From edugas at unknowndevice.ca Tue Sep 24 15:02:13 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 24 Sep 2019 11:02:13 -0400 Subject: AS16509 contact Message-ID: <99C97530-5A90-4E31-9416-9D67D6222FA6@getmailspring.com> Hello, Anyone has peering contacts in AS16509 other than peering @ amazon.com to setup a PNI? All my previous contacts are gone. Thanks Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From infowolfe at gmail.com Tue Sep 24 13:40:57 2019 From: infowolfe at gmail.com (Chip Parker) Date: Tue, 24 Sep 2019 09:40:57 -0400 Subject: TATA, CableVision, Verizon IP reassignment contacts? Message-ID: Does anybody have any contacts for IP assignment/reassignment with: TATA CableVision MCI dba Verizon I'm looking to talk to someone at each of the above companies about some reassignments that I've inherited from a company that the company I work for purchased a few years ago. TL;DR trying to "fix" reassignments in ARIN, but can't without contact with the above companies. Trying to find a contact that'll speak to me about fixing these reassignments. TIA Chip Parker From sean at donelan.com Tue Sep 24 16:43:58 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 24 Sep 2019 12:43:58 -0400 (EDT) Subject: Carrier responses to FCC wildfire prepardness query Message-ID: Today, AT&T, Sprint, T-Mobile, US Cellular and Verizon have responded to the FCC's inquiry about their prepardness for California wildfires and preventative public safety electric grid shutdowns. PSHB proceeding number 19-251 https://www.fcc.gov/ecfs/search/filings?proceedings_name=19-251&sort=date_disseminated,DESC As typical, the carrier responses were mostly happy, happy, joy, joy letters. The FCC asked about backup power readiness, but last year many of the communication outages were because of damaged fiber routes during wildfires isolating cell towers and mobile switching stations. Carriers minimize spending on route diversity in rural areas. COWs, COLTs, etc. use alternative satellite and microwave backhaul, but alternative backhaul is less common for permanent facilities. I didn't hear about any WISPs during last year's wildfires. From edugas at unknowndevice.ca Tue Sep 24 17:30:52 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 24 Sep 2019 13:30:52 -0400 Subject: AS16509 contact In-Reply-To: <99C97530-5A90-4E31-9416-9D67D6222FA6@getmailspring.com> References: <99C97530-5A90-4E31-9416-9D67D6222FA6@getmailspring.com> Message-ID: Thanks everyone for the off-list replies. On Tue, Sep 24, 2019 at 11:02 AM Eric Dugas wrote: > Hello, > > Anyone has peering contacts in AS16509 other than peering @ amazon.com to > setup a PNI? All my previous contacts are gone. > > Thanks > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allenmckinleykitchen at gmail.com Tue Sep 24 19:42:43 2019 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Tue, 24 Sep 2019 15:42:43 -0400 Subject: Barely operational .. hoping to find myspace help In-Reply-To: References: Message-ID: Thanks! Replying to the list as well .. several kind folks replied off-list. As you can imagine, getting a lawyer's letterhead could involve some expense that our shoestring volunteer organization wishes to avoid .. which is why I sought a tech contact in order to pave the way if possible (sometimes it's still WHO you know more than WHAT you know). Good news is that the parole officer has now assured my client that no matter what PSP told him, the PO won’t technical him for circumstances beyond his control. So the pucker factor is markedly diminished. This is a public thanks to all who have sent off-line offers of help and support! The effort continues but now with more manageable urgency. And thanks to the list for being gracious re this non-operational followup. Blessings.. ..Allen > On Sep 23, 2019, at 22:59, William Herrin wrote: > > > >> On Mon, Sep 23, 2019 at 3:21 PM Allen Kitchen wrote: >> In a side volunteer "job", I work with men released from prison, often with sexual offense histories. Generally they are still on parole / supervision. >> >> Currently I have one "client" who is barely literate technically but who had a myspace account before he went to prison about 6 years ago. >> >> He's been told by state police here in PA that he must delete his old myspace account or risk re-incarceration, whether or not he has used the account. But he's also prohibited from using any social media accounts in any manner whatsoever - and has no idea what his old email was when he set this account up as a teenager. So he has asked for my help in shutting down his old unused profile. >> >> The myspace website is rather unhelpful in trying to find a way to do this without having him log in - which is both practically impossible and legally prohibited. >> > > https://help.myspace.com/hc/en-us > > search for "legal" > > The first link is "law enforcement." Down at the end it has an address. > > Prepare a letter on a lawyer's letterhead. Include a copy of the instruction you have on government letterhead ordering your client to delete his account. Send it certified mail. > > If the account remains online after you get the receipt for the letter's delivery, return to the judge and ask for a letter ordering myspace to delete the account. Then send a copy of that to the address. > > Regards, > Bill Herrin > > > > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Sep 24 20:31:41 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 24 Sep 2019 13:31:41 -0700 Subject: Mexico Message-ID: Hey there I am looking for transit provider(s) who are small and connected networks in Mexico city/Querétaro Please contact me offlist if you can provide this service. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Tue Sep 24 20:57:50 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Tue, 24 Sep 2019 14:57:50 -0600 Subject: Barely operational .. hoping to find myspace help In-Reply-To: References: Message-ID: > As you can imagine, getting a lawyer's letterhead could involve some expense that our shoestring volunteer organization wishes to avoid .. which is why I sought a tech contact in order to pave the way if possible (sometimes it's still WHO you know more than WHAT you know). I may be able to help with that letterhead thing. ;-) LMK offlist if you still need/want it. Anne -- Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy SuretyMail Email Reputation Certification Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Location: Boulder, Colorado From infowolfe at gmail.com Tue Sep 24 18:56:53 2019 From: infowolfe at gmail.com (Chip Parker) Date: Tue, 24 Sep 2019 14:56:53 -0400 Subject: TATA, CableVision, Verizon IP reassignment contacts? In-Reply-To: References: Message-ID: I haven't yet received a response from CableVision's listed ARIN contact, but I've got Tata Communications via ip-addr at tatacommunications.com and I'll be emailing swipper at verizon.net for Verizon a little later today. Thanks for the off-list replies, this thread should be resolved. On Tue, Sep 24, 2019 at 9:40 AM Chip Parker wrote: > > Does anybody have any contacts for IP assignment/reassignment with: > TATA > CableVision > MCI dba Verizon > > I'm looking to talk to someone at each of the above companies about > some reassignments that I've inherited from a company that the company > I work for purchased a few years ago. > > TL;DR trying to "fix" reassignments in ARIN, but can't without contact > with the above companies. Trying to find a contact that'll speak to me > about fixing these reassignments. > > TIA > Chip Parker From tomas.lynch at gmail.com Wed Sep 25 14:08:35 2019 From: tomas.lynch at gmail.com (Tomas Lynch) Date: Wed, 25 Sep 2019 10:08:35 -0400 Subject: KDDI BGP communities Message-ID: I'm looking for KDDI BGP communities without any luck googling for them. Can somebody point me into the right direction please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.meredith at port.ac.uk Wed Sep 25 14:15:14 2019 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Wed, 25 Sep 2019 15:15:14 +0100 Subject: Colombia Network Operators Group In-Reply-To: <20190923140636.FEC409F6@m0117567.ppops.net> References: <20190923140636.FEC409F6@m0117567.ppops.net> Message-ID: <20190925151514.24128a0c@scrofula.eps.is.port.ac.uk> On Mon, 23 Sep 2019 14:06:36 -0700, "Scott Weeks" may have written: > >the Cisco Umbrella security researchers." > > Fascinating. What is the security threat I wonder, that there is no > JavaScript? > ----------------------------------------------- Security threats aren't limited to JavaScript. It could be an entirely static site which is still worth blocking (see phishing). Or it's possible that the registration is new enough that it's blocked just for that reason - although at a month old, it should be beyond that window. Or the site hasn't been categorised ("unknown") which is enough to block for an especially Evil Firewall Admin[0]. 0: I may be an Evil Firewall Admin, but I'm not an especially EFA. -- Mike Meredith, University of Portsmouth Hostmaster, Security, and Chief Systems Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From warren at kumari.net Thu Sep 26 14:41:10 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 26 Sep 2019 10:41:10 -0400 Subject: Recommendation: Good paging / alerting software ? Message-ID: Hi there, I'm looking for a recommendation for a good paging / alerting system *for personal use*. I'm monitoring a number of servers, VMs, routers / switches and such, and currently get ~10 pages a week. Things I've already tried: I'm currently using OpsGenie, but don't really like the UI. I briefly tried PagerTree, and have used PagerDuty in the past -- I was happy with PagerDuty, but don't really want to be paying $10 per month for this (it's just for personal use, and that seemed a bit excessive). I'm also a happy Pushover customer - this works well, but it's ability to customise / close alerts seems to be missing. It works really well for other types of notifications though. Requirements: 1: Cheap! 2 : AlertManager integration - I mainly use Prometheus for monitoring, and it sends alerts to AlertManager. 3: I'd like an iOS / Android app - having things come in over SMS / messages makes it too easy to miss things. I also don't want to use e.g Slack for this because it's too easy to miss them amongst other messages. 4: A web interface would be nice, but not 100% necessary. 5: "Alerts" - the ability to Ack / Close alerts. This signals back to AlertManger. 6: Escalations would be nice - if I don't respond to an alert in N minutes, send it again, possibly with a more grumpy noise. Because this is just for personal use I really don't want to be spending money on this... Thanks in advance for any suggestions... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nanog at aptient.com Thu Sep 26 06:45:48 2019 From: nanog at aptient.com (Chris Phillips) Date: Thu, 26 Sep 2019 16:45:48 +1000 Subject: BGP routes by country Message-ID: Greetings, Is anyone offering a service providing BGP routes by country? I'm not looking to buy transit, but rather build policies based on the routes received to allow traffic from certain countries, or disallow traffic from others. Kind of like the the CYMRU bogons list, but, by country. Thank you in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Cannova at take2games.com Thu Sep 26 16:22:05 2019 From: Andrew.Cannova at take2games.com (Andrew Cannova (T2 International)) Date: Thu, 26 Sep 2019 16:22:05 +0000 Subject: BGP routes by country In-Reply-To: References: Message-ID: <64B37EE3-4C96-4801-A9AD-B7A85D7EF506@take2games.com> https://www.countryipblocks.net/ this might be useful to you From: NANOG on behalf of Chris Phillips Date: Thursday, 26 September 2019 at 17:19 To: "nanog at nanog.org" Subject: BGP routes by country ** EXTERNAL EMAIL ** Greetings, Is anyone offering a service providing BGP routes by country? I'm not looking to buy transit, but rather build policies based on the routes received to allow traffic from certain countries, or disallow traffic from others. Kind of like the the CYMRU bogons list, but, by country. Thank you in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsvec at teamonesolutions.com Thu Sep 26 16:55:55 2019 From: bsvec at teamonesolutions.com (Brandon Svec) Date: Thu, 26 Sep 2019 09:55:55 -0700 Subject: Recommendation: Good paging / alerting software ? In-Reply-To: References: Message-ID: https://papertrailapp.com might meet your needs. They have a free tier and collect syslog messages in their cloud and then have various alerting methods such as SMS, web hooks, email, etc. you could leverage to get the alerts you want. Good luck. > On Sep 26, 2019, at 7:41 AM, Warren Kumari wrote: > > Hi there, > > I'm looking for a recommendation for a good paging / alerting system > *for personal use*. > > I'm monitoring a number of servers, VMs, routers / switches and such, > and currently get ~10 pages a week. > > Things I've already tried: > I'm currently using OpsGenie, but don't really like the UI. > I briefly tried PagerTree, and have used PagerDuty in the past -- I > was happy with PagerDuty, but don't really want to be paying $10 per > month for this (it's just for personal use, and that seemed a bit > excessive). > I'm also a happy Pushover customer - this works well, but it's ability > to customise / close alerts seems to be missing. It works really well > for other types of notifications though. > > Requirements: > 1: Cheap! > > 2 : AlertManager integration - I mainly use Prometheus for monitoring, > and it sends alerts to AlertManager. > > 3: I'd like an iOS / Android app - having things come in over SMS / > messages makes it too easy to miss things. I also don't want to use > e.g Slack for this because it's too easy to miss them amongst other > messages. > > 4: A web interface would be nice, but not 100% necessary. > > 5: "Alerts" - the ability to Ack / Close alerts. This signals back to > AlertManger. > > 6: Escalations would be nice - if I don't respond to an alert in N > minutes, send it again, possibly with a more grumpy noise. > > > Because this is just for personal use I really don't want to be > spending money on this... > > Thanks in advance for any suggestions... > W > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Thu Sep 26 17:31:02 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 26 Sep 2019 12:31:02 -0500 Subject: Recommendation: Good paging / alerting software ? In-Reply-To: References: Message-ID: Have you tried uptime robot? I believe you qualify for the free tier, there is a limit of SMS messages but email to text services at most providers can be substituted to circumvent that. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Sep 26, 2019, at 09:42, Warren Kumari wrote: > > Hi there, > > I'm looking for a recommendation for a good paging / alerting system > *for personal use*. > > I'm monitoring a number of servers, VMs, routers / switches and such, > and currently get ~10 pages a week. > > Things I've already tried: > I'm currently using OpsGenie, but don't really like the UI. > I briefly tried PagerTree, and have used PagerDuty in the past -- I > was happy with PagerDuty, but don't really want to be paying $10 per > month for this (it's just for personal use, and that seemed a bit > excessive). > I'm also a happy Pushover customer - this works well, but it's ability > to customise / close alerts seems to be missing. It works really well > for other types of notifications though. > > Requirements: > 1: Cheap! > > 2 : AlertManager integration - I mainly use Prometheus for monitoring, > and it sends alerts to AlertManager. > > 3: I'd like an iOS / Android app - having things come in over SMS / > messages makes it too easy to miss things. I also don't want to use > e.g Slack for this because it's too easy to miss them amongst other > messages. > > 4: A web interface would be nice, but not 100% necessary. > > 5: "Alerts" - the ability to Ack / Close alerts. This signals back to > AlertManger. > > 6: Escalations would be nice - if I don't respond to an alert in N > minutes, send it again, possibly with a more grumpy noise. > > > Because this is just for personal use I really don't want to be > spending money on this... > > Thanks in advance for any suggestions... > W > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From bill at herrin.us Thu Sep 26 18:06:17 2019 From: bill at herrin.us (William Herrin) Date: Thu, 26 Sep 2019 11:06:17 -0700 Subject: Recommendation: Good paging / alerting software ? In-Reply-To: References: Message-ID: On Thu, Sep 26, 2019 at 7:42 AM Warren Kumari wrote: > I'm looking for a recommendation for a good paging / alerting system > *for personal use*. For personal use, I use gmail. Create a label "pageme," have the monitor send emails to yourname+pageme at gmail.com and set up label notifications on your android gmail app so you get a noise when something hits the pageme label. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Sep 26 18:21:28 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 26 Sep 2019 12:21:28 -0600 Subject: BGP routes by country In-Reply-To: Message-ID: RIR Delegations data is public. https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/rir-statistics-exchange-format/ The various RIR delegation statistics can be gotten from: https://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest https://ftp.apnic.net/stats/apnic/delegated-apnic-latest https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest https://ftp.ripe.net/ripe/stats/delegated-ripencc-latest They do follow the format in the rir-statistics exchange format doc. They are not necessarily located or replicated as described (apparently). Of course, the country code does not necessarily reflect where the resource is used -- I believe it is the CC of the registering org. If it were so simple then all the geolocation companies would be outa business in a flash. >-----Original Message----- >From: NANOG On Behalf Of Chris Phillips >Sent: Thursday, 26 September, 2019 00:46 >To: nanog at nanog.org >Subject: BGP routes by country > >Greetings, > >Is anyone offering a service providing BGP routes by country? I'm not >looking to buy transit, but rather build policies based on the routes >received to allow traffic from certain countries, or disallow traffic >from others. Kind of like the the CYMRU bogons list, but, by country. > >Thank you in advance. From michel.py at tsisemi.com Thu Sep 26 19:31:03 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 26 Sep 2019 19:31:03 +0000 Subject: [nanog] BGP routes by country Message-ID: > Chris Phillips wrote : > Is anyone offering a service providing BGP routes by country? I'm not looking to buy transit, but rather build policies based on the routes > received to allow traffic from certain countries, or disallow traffic from others. Kind of like the the CYMRU bogons list, but, by country. It greatly depends if you receive a full-feed or not. If you do receive a full-feed, chances are that you will get more specific routes than the ones that come into your blacklist and achieve nothing. If you do not have a full-feed, it is relatively straightforward to fetch one of the lists available on the Internet and inject it in your BGP. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From morrowc.lists at gmail.com Thu Sep 26 19:52:43 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Sep 2019 15:52:43 -0400 Subject: [nanog] BGP routes by country In-Reply-To: References: Message-ID: Maybe asking from the get-go: "What are you trying to do?" because the question asked is fraught with peril and disaster... On Thu, Sep 26, 2019 at 3:32 PM Michel Py wrote: > > > Chris Phillips wrote : > > Is anyone offering a service providing BGP routes by country? I'm not looking to buy transit, but rather build policies based on the routes > > received to allow traffic from certain countries, or disallow traffic from others. Kind of like the the CYMRU bogons list, but, by country. > > It greatly depends if you receive a full-feed or not. If you do receive a full-feed, chances are that you will get more specific routes than the ones that come into your blacklist and achieve nothing. > > If you do not have a full-feed, it is relatively straightforward to fetch one of the lists available on the Internet and inject it in your BGP. > > Michel. > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From savage at savage.za.org Thu Sep 26 20:48:10 2019 From: savage at savage.za.org (Chris Knipe) Date: Thu, 26 Sep 2019 22:48:10 +0200 Subject: [nanog] BGP routes by country In-Reply-To: References: Message-ID: On Thu, Sep 26, 2019 at 9:53 PM Christopher Morrow wrote: > Maybe asking from the get-go: > "What are you trying to do?" > > because the question asked is fraught with peril and disaster... > Why? When you have a serious problem with a specific ASN, it's not unreasonable to drop traffic to that entire ASN. When you have a serious problem predominantly originating from a certain country, why is it unreasonable to drop traffic to that entire country? Just because I own an ASN and participate in the world of BGP, doesn't mean I *must* accept everyone's traffic from all over the world. My network, my rules(1) (1) my as in the ASN whom choose to drop prefixes for an entire ASN and/or country. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Sep 26 21:52:18 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Sep 2019 17:52:18 -0400 Subject: [nanog] BGP routes by country In-Reply-To: References: Message-ID: On Thu, Sep 26, 2019 at 4:48 PM Chris Knipe wrote: > > On Thu, Sep 26, 2019 at 9:53 PM Christopher Morrow wrote: >> >> Maybe asking from the get-go: >> "What are you trying to do?" >> >> because the question asked is fraught with peril and disaster... > > > Why? When you have a serious problem with a specific ASN, it's not unreasonable to drop traffic to that entire ASN. isn't the question though not ASN but 'country' ? > When you have a serious problem predominantly originating from a certain country, why is it unreasonable to drop traffic to that entire country? Sure, where is 74.125.0.0/24 originated from? There's not really a simple answer in bgp for this ;( > Just because I own an ASN and participate in the world of BGP, doesn't mean I *must* accept everyone's traffic from all over the world. My network, my rules(1) > sure, and you can drop whatever you want, my point was that it's not really straight forward which ip is which country over time :( > (1) my as in the ASN whom choose to drop prefixes for an entire ASN and/or country. > > From michel.py at tsisemi.com Thu Sep 26 22:05:58 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 26 Sep 2019 22:05:58 +0000 Subject: [nanog] BGP routes by country In-Reply-To: References: Message-ID: <65db650866ca441f8ada51c8e7ca5036@CRA114.am.necel.com> > Christopher Morrow wrote : > Maybe asking from the get-go: "What are you trying to do?" Indeed. > because the question asked is fraught with peril and disaster... Allowing only US and Canada will be be a manual whitelist nightmare and will likely result in some unreachability. A while ago, I tried to block China. The attack profile lowered a little bit, but I did not feel my network was safer. Looks kind of futile to me. The bots are everywhere, blocking entire countries does not reduce the risk much. I totally believe in the "my network, my rules" thing though. I do not provide Internet access to the public so what I deliver is my call. At any given time I blacklist between 30K and 100K prefixes, motsly /32s. http://arneill-py.sacramento.ca.us/cbbc/ Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From ximaera at gmail.com Thu Sep 26 22:32:34 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 27 Sep 2019 01:32:34 +0300 Subject: BGP routes by country In-Reply-To: References: Message-ID: Peace, On Thu, Sep 26, 2019, 7:19 PM Chris Phillips wrote: > Greetings, > > Is anyone offering a service providing BGP routes by country? I'm not > looking to buy transit, but rather build policies based on the routes > received to allow traffic from certain countries, or disallow traffic from > others. > I hope you understand that U.S. citizens, including, but not limited to, your company's employees and executives, are free to travel to any country they please, and they still expect their American Internet services of choice to be available from where they are?.. And some of those countries are blocking VPNs... -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Thu Sep 26 22:39:04 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 27 Sep 2019 01:39:04 +0300 Subject: [nanog] BGP routes by country In-Reply-To: <65db650866ca441f8ada51c8e7ca5036@CRA114.am.necel.com> References: <65db650866ca441f8ada51c8e7ca5036@CRA114.am.necel.com> Message-ID: Peace, On Fri, Sep 27, 2019, 1:07 AM Michel Py wrote: > A while ago, I tried to block China. The attack profile lowered a little > bit, but I did not feel my network was safer. Looks kind of futile to me. > The bots are everywhere, blocking entire countries does not reduce the > risk much. > Just the existence of onion routing makes such protection attempts ridiculous overall. That being said, there are ASes which, as rfg frequently reminds us, not worth handling traffic from. But that's just particular ASes, not countries, and sometimes those ASes belong to generally innocent geographic places. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmaurand at xyonet.com Fri Sep 27 17:33:17 2019 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 27 Sep 2019 13:33:17 -0400 Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users In-Reply-To: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> References: <471000904.3915.1568816367898.JavaMail.mhammett@ThunderFuck> Message-ID: <262bbc2c-f07c-772f-fd58-8c6a6224193f@xyonet.com> powerdns dnsdist supports dns over https so you don't have to be held hostage by cloudflare or google. On 9/18/19 10:19 AM, Mike Hammett wrote: > Why on Earth would anyone want that (Firefox deciding to do it's own > DNS) as default behavior? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Jeroen Massar" > *To: *"NANOG" > *Sent: *Wednesday, September 18, 2019 2:15:49 AM > *Subject: *DNS Recursive Operators: Please enable QNAME minimization > (RFC7816) for the enhanced privacy of your users > > Hi Folks, > > While in the US soon all Firefox users will *NOT* use your DNS > Recursives configured using DHCP anymore > (NXDOMAIN use-application-dns.net to avoid that[1]). > Next to that, it seems some of the root operators are now creating > instances in the same networks that offer these kind of services for > globally figuring out what queries are being made. > > > For those that thus either opt-out or otherwise want to use their own > system resolvers, I suggest that all that run > DNS Recursive setups enable "QNAME minimization" as defined in > (experimental) RFC7816 [2] > > For pdns "qname-minimization=yes" [6] > For unbound "qname­-minimisation: yes" [5] > For BIND "qname-minimization" option [3] and [4] > > Of course, do also provider your users with the option of using DoT or > even DoH on your recursors... > > Noting that DoH operators are supposed to enable RFC7816 also [7], > guess they do not want others to see all the details they get... > > Some more details in DNS Privacy Wiki [8]... > > Discuss! :) > > Greets, >  Jeroen > > > [1] > https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https > [2] https://tools.ietf.org/html/rfc7816 > [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ > [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 > [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf > [6] https://github.com/PowerDNS/pdns/issues/2311 > [7] https://wiki.mozilla.org/Security/DOH-resolver-policy > [8] https://dnsprivacy.org/wiki/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Sep 27 18:03:54 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Sep 2019 04:03:54 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190927180354.C110CC34BB@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 Sep, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 775589 Prefixes after maximum aggregation (per Origin AS): 297759 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 373221 Total ASes present in the Internet Routing Table: 65731 Prefixes per ASN: 11.80 Origin-only ASes present in the Internet Routing Table: 56540 Origin ASes announcing only one prefix: 24212 Transit ASes present in the Internet Routing Table: 9191 Transit-only ASes present in the Internet Routing Table: 272 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 43 Max AS path prepend of ASN ( 19955) 41 Prefixes from unregistered ASNs in the Routing Table: 28 Number of instances of unregistered ASNs: 29 Number of 32-bit ASNs allocated by the RIRs: 28855 Number of 32-bit ASNs visible in the Routing Table: 23645 Prefixes from 32-bit ASNs in the Routing Table: 107863 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 321 Number of addresses announced to Internet: 2840324352 Equivalent to 169 /8s, 75 /16s and 233 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 258570 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 209271 Total APNIC prefixes after maximum aggregation: 62399 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 203840 Unique aggregates announced from the APNIC address blocks: 85033 APNIC Region origin ASes present in the Internet Routing Table: 10089 APNIC Prefixes per ASN: 20.20 APNIC Region origin ASes announcing only one prefix: 2801 APNIC Region transit ASes present in the Internet Routing Table: 1496 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5095 Number of APNIC addresses announced to Internet: 767812352 Equivalent to 45 /8s, 195 /16s and 227 /24s 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, 64297-64395, 131072-141625 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: 227702 Total ARIN prefixes after maximum aggregation: 106365 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 226182 Unique aggregates announced from the ARIN address blocks: 107696 ARIN Region origin ASes present in the Internet Routing Table: 18596 ARIN Prefixes per ASN: 12.16 ARIN Region origin ASes announcing only one prefix: 6887 ARIN Region transit ASes present in the Internet Routing Table: 1922 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 43 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2923 Number of ARIN addresses announced to Internet: 1071049088 Equivalent to 63 /8s, 214 /16s and 233 /24s 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-399260 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, 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: 217466 Total RIPE prefixes after maximum aggregation: 101391 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 213424 Unique aggregates announced from the RIPE address blocks: 125790 RIPE Region origin ASes present in the Internet Routing Table: 26497 RIPE Prefixes per ASN: 8.05 RIPE Region origin ASes announcing only one prefix: 11706 RIPE Region transit ASes present in the Internet Routing Table: 3744 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8528 Number of RIPE addresses announced to Internet: 721798784 Equivalent to 43 /8s, 5 /16s and 198 /24s 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, 64396-64495 196608-210331 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: 99612 Total LACNIC prefixes after maximum aggregation: 23226 LACNIC Deaggregation factor: 4.29 Prefixes being announced from the LACNIC address blocks: 100817 Unique aggregates announced from the LACNIC address blocks: 44768 LACNIC Region origin ASes present in the Internet Routing Table: 8930 LACNIC Prefixes per ASN: 11.29 LACNIC Region origin ASes announcing only one prefix: 2352 LACNIC Region transit ASes present in the Internet Routing Table: 1647 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 42 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6485 Number of LACNIC addresses announced to Internet: 173972480 Equivalent to 10 /8s, 94 /16s and 156 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21509 Total AfriNIC prefixes after maximum aggregation: 4356 AfriNIC Deaggregation factor: 4.94 Prefixes being announced from the AfriNIC address blocks: 31005 Unique aggregates announced from the AfriNIC address blocks: 9646 AfriNIC Region origin ASes present in the Internet Routing Table: 1330 AfriNIC Prefixes per ASN: 23.31 AfriNIC Region origin ASes announcing only one prefix: 466 AfriNIC Region transit ASes present in the Internet Routing Table: 261 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 614 Number of AfriNIC addresses announced to Internet: 105408768 Equivalent to 6 /8s, 72 /16s and 105 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 5003 618 593 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3242 1331 26 VIETEL-AS-AP Viettel Group, VN 45899 3063 1762 114 VNPT-AS-VN VNPT Corp, VN 9829 2733 1493 546 BSNL-NIB National Internet Backbone, IN 7713 2624 801 480 TELKOMNET-AS-AP PT Telekomunikasi Indon 9808 2606 9043 63 CMNET-GD Guangdong Mobile Communication 4766 2549 11121 764 KIXS-AS-KR Korea Telecom, KR 9498 2183 432 207 BBIL-AP BHARTI Airtel Ltd., IN 4755 2156 442 197 TATACOMM-AS TATA Communications formerl 9394 2060 4898 24 CTTNET China TieTong Telecommunications 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 7155 4065 280 27 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3653 238 688 CABLEONE - CABLE ONE, INC., US 6327 3486 1324 94 SHAW - Shaw Communications Inc., CA 22773 3467 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3161 7134 1511 AMAZON-02 - Amazon.com, Inc., US 16625 2756 1447 1992 AKAMAI-AS - Akamai Technologies, Inc., 30036 2210 351 154 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2149 2766 524 CHARTER-20115 - Charter Communications, 18566 2080 405 104 MEGAPATH5-US - MegaPath Corporation, US 5650 2061 3073 1454 FRONTIER-FRTR - Frontier Communications 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 12479 5558 1615 141 UNI2-AS, ES 39891 4034 219 19 ALJAWWALSTC-AS, SA 8551 3225 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2751 490 1934 AKAMAI-ASN1, US 31334 2640 484 13 KABELDEUTSCHLAND-AS, DE 12389 2396 2231 687 ROSTELECOM-AS, RU 9121 2213 1692 18 TTNET, TR 34984 2162 350 537 TELLCOM-AS, TR 9009 1813 196 998 M247, GB 13188 1604 100 47 TRIOLAN, UA 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 8151 6242 3358 606 Uninet S.A. de C.V., MX 10620 3357 534 462 Telmex Colombia S.A., CO 11830 2695 370 54 Instituto Costarricense de Electricidad 6503 1632 378 405 Axtel, S.A.B. de C.V., MX 7303 1477 1027 272 Telecom Argentina S.A., AR 28573 1171 2231 201 CLARO S.A., BR 6147 1092 380 36 Telefonica del Peru S.A.A., PE 3816 1062 546 124 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 1020 488 248 Mega Cable, S.A. de C.V., MX 11172 930 110 59 Alestra, S. de R.L. de C.V., MX 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 1188 394 24 LINKdotNET-AS, EG 36992 983 1535 73 ETISALAT-MISR, EG 24835 969 610 24 RAYA-AS, EG 36903 852 431 115 MT-MPLS, MA 8452 649 1857 19 TE-AS TE-AS, EG 6713 625 1863 34 IAM-AS, MA 29571 542 68 11 ORANGE-COTE-IVOIRE, CI 15399 415 45 10 WANANCHI-, KE 37342 402 32 1 MOVITEL, MZ 23889 363 231 15 MauritiusTelecom, MU 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 8151 6242 3358 606 Uninet S.A. de C.V., MX 12479 5558 1615 141 UNI2-AS, ES 7545 5003 618 593 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 280 27 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 4034 219 19 ALJAWWALSTC-AS, SA 11492 3653 238 688 CABLEONE - CABLE ONE, INC., US 6327 3486 1324 94 SHAW - Shaw Communications Inc., CA 22773 3467 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3357 534 462 Telmex Colombia S.A., CO 7552 3242 1331 26 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5558 5417 UNI2-AS, ES 7545 5003 4410 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 4038 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 4034 4015 ALJAWWALSTC-AS, SA 6327 3486 3392 SHAW - Shaw Communications Inc., CA 22773 3467 3311 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3242 3216 VIETEL-AS-AP Viettel Group, VN 8551 3225 3179 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3653 2965 CABLEONE - CABLE ONE, INC., US 45899 3063 2949 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 208130 UNALLOCATED 45.155.20.0/22 20860 IOMART-AS, GB 208130 UNALLOCATED 45.155.20.0/23 20860 IOMART-AS, GB 260984 UNALLOCATED 45.175.186.0/23 16735 ALGAR TELECOM S/A, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.73.64.0/19 37149 -Reserved AS-, ZZ 41.76.55.0/24 328143 -Reserved AS-, ZZ 41.76.124.0/24 37493 -Reserved AS-, ZZ 41.76.125.0/24 37493 -Reserved AS-, ZZ 41.76.126.0/24 37493 -Reserved AS-, ZZ 41.76.127.0/24 37493 -Reserved AS-, ZZ 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:10 /9:11 /10:37 /11:100 /12:291 /13:573 /14:1146 /15:1919 /16:13254 /17:8110 /18:13858 /19:25684 /20:40452 /21:47407 /22:96876 /23:78403 /24:446585 /25:873 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4517 5558 UNI2-AS, ES 6327 3272 3486 SHAW - Shaw Communications Inc., CA 7155 3154 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 4034 ALJAWWALSTC-AS, SA 11492 2860 3653 CABLEONE - CABLE ONE, INC., US 22773 2694 3467 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2684 3225 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 31334 2496 2640 KABELDEUTSCHLAND-AS, DE 11830 2042 2695 Instituto Costarricense de Electricidad y Telec 18566 1975 2080 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1752 2:1101 3:6 4:22 5:3063 6:50 7:1 8:1357 9:1 12:1801 13:404 14:2123 15:45 16:7 17:270 18:77 20:59 23:2919 24:2586 25:4 27:2470 31:2755 32:108 35:37 36:924 37:3148 38:1820 39:306 40:121 41:3418 42:822 43:2094 44:176 45:10927 46:3353 47:268 49:1454 50:1103 51:347 52:1063 54:260 55:679 56:6 57:47 58:2078 59:1124 60:599 61:2221 62:2049 63:1870 64:5019 65:2258 66:4791 67:2733 68:1219 69:3573 70:1391 71:672 72:2701 74:2684 75:1292 76:595 77:2556 78:2007 79:2395 80:1822 81:1523 82:1184 83:953 84:1178 85:2384 86:564 87:1562 88:1137 89:2601 90:231 91:6609 92:1441 93:2465 94:2622 95:3682 96:954 97:339 98:958 99:833 100:83 101:1101 102:651 103:22280 104:3611 105:294 106:831 107:1799 108:693 109:3638 110:1773 111:1996 112:1554 113:1423 114:1294 115:1806 116:1771 117:1958 118:2238 119:1654 120:1085 121:1052 122:2311 123:1862 124:1535 125:2021 128:1362 129:856 130:550 131:1827 132:741 133:231 134:1101 135:258 136:600 137:805 138:2107 139:957 140:645 141:887 142:792 143:1096 144:888 145:285 146:1411 147:869 148:1812 149:1040 150:827 151:1288 152:1407 153:358 154:4413 155:893 156:2568 157:1063 158:703 159:1940 160:1599 161:974 162:3004 163:851 164:1297 165:1146 166:523 167:1439 168:3584 169:485 170:4205 171:689 172:1743 173:2293 174:1035 175:1004 176:2510 177:3994 178:2743 179:1417 180:2137 181:2373 182:2804 183:1164 184:2276 185:15575 186:3753 187:2514 188:3440 189:2043 190:8271 191:1458 192:10026 193:6758 194:5520 195:4198 196:3160 197:1813 198:5985 199:5937 200:7144 201:5200 202:10409 203:10276 204:4574 205:3070 206:3229 207:3261 208:3932 209:4307 210:3925 211:2043 212:3307 213:2963 214:1149 215:54 216:5862 217:2237 218:881 219:608 220:1918 221:972 222:1013 223:1394 End of report From Nick.Bogle at avistacorp.com Mon Sep 30 03:45:25 2019 From: Nick.Bogle at avistacorp.com (Bogle, Nick) Date: Mon, 30 Sep 2019 03:45:25 +0000 Subject: Cisco Metro Ethernet Switching Message-ID: Hey there! I'm currently working on a project which entails refreshing a few EoL switches that sit on a Metro Ethernet fiber ring that we own acting as essentially a PE handoff. It's primarily just a Layer 2 ring with mostly ME3400E switches. We are not in a place to convert the entire ring to our standard Nokia SAR platform, and just wanted to bring all of our sites to standard on the ME3400E platform for consistency (have four switches on the ring that are currently 3560G's and don't support the needed QoS/CoS). As the ME3400E is currently End of Sale, what would you guys recommend as far as a replacement? I am leaning towards the ASR920's (affordable, seems like a solid proven platform, future flexibility), or the NCS 520 (Ciscos recommended replacement), but neither of them seem like appropriate replacements for a simple Layer 2 switching platform with just the need for decent QoS and CoS capabilities. No Layer 3, MPLS, or 10G+ is required. 12 1G SFP ports is about all we need. Let me know your thoughts -- haven't payed much attention to the Cisco service provider space as of late. Thank you! Nick Bogle Network Engineer [signature] 1411 E Mission Ave. MSC-40 Spokane WA 99202 P 509-495-8525 C 509-220-5763 www.avistacorp.com CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or an agent of the intended recipient, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Mon Sep 30 19:25:20 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 30 Sep 2019 19:25:20 +0000 Subject: Cisco Metro Ethernet Switching In-Reply-To: References: Message-ID: You can get ASR920's with only a layer 2 license, or you can opt for the advanced L3 license to BGP\MPLS, this would enable EoMPLS Tunnels. The NCS520 is designed only to be a NID, there are a lot of limitations on this device. You need to read the configuration guide to see the limitations. I have one on my desk. The NCS540 is the next model up from the ASR920. I think ASR924 is the way to go. Erik ________________________________ From: NANOG on behalf of Bogle, Nick Sent: Sunday, September 29, 2019 10:45 PM To: nanog at nanog.org Subject: Cisco Metro Ethernet Switching Hey there! I'm currently working on a project which entails refreshing a few EoL switches that sit on a Metro Ethernet fiber ring that we own acting as essentially a PE handoff. It's primarily just a Layer 2 ring with mostly ME3400E switches. We are not in a place to convert the entire ring to our standard Nokia SAR platform, and just wanted to bring all of our sites to standard on the ME3400E platform for consistency (have four switches on the ring that are currently 3560G's and don't support the needed QoS/CoS). As the ME3400E is currently End of Sale, what would you guys recommend as far as a replacement? I am leaning towards the ASR920's (affordable, seems like a solid proven platform, future flexibility), or the NCS 520 (Ciscos recommended replacement), but neither of them seem like appropriate replacements for a simple Layer 2 switching platform with just the need for decent QoS and CoS capabilities. No Layer 3, MPLS, or 10G+ is required. 12 1G SFP ports is about all we need. Let me know your thoughts -- haven't payed much attention to the Cisco service provider space as of late. Thank you! Nick Bogle Network Engineer [signature] 1411 E Mission Ave. MSC-40 Spokane WA 99202 P 509-495-8525 C 509-220-5763 www.avistacorp.com CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or an agent of the intended recipient, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: