From randy at psg.com Sat Dec 1 18:09:45 2018 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2018 10:09:45 -0800 Subject: China =?ISO-8859-7?Q?=A2s?= Maxim =?BIG5?Q?=A1V?= Leave No Access Point Unexploited: The Hidden Story of China =?ISO-8859-7?Q?Teleco?= =?ISO-8859-7?Q?m=A2?= s BGP Hijacking In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: >> China Telecom's response: > They forgot to mention that it's technically possible to filter > advertisements from their customer. Which apparently they were/are not > really doing. luckily, CT is the only isp not doing good filtering, or we would be having mis-originations and route leaks every day. oh, wait. randy From morrowc.lists at gmail.com Sat Dec 1 18:56:55 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 1 Dec 2018 13:56:55 -0500 Subject: =?UTF-8?Q?Re=3A_China_=E2=80=99s_Maxim_=E2=80=93_Leave_No_Access_Point_Unexp?= =?UTF-8?Q?loited=3A_The_Hidden_Story_of_China_Telecom=E2=80=99_s_BGP_Hijacking?= In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: On Sat, Dec 1, 2018 at 1:11 PM Randy Bush wrote: > >> China Telecom's response: > > They forgot to mention that it's technically possible to filter > > advertisements from their customer. Which apparently they were/are not > > really doing. > > luckily, CT is the only isp not doing good filtering, or we would be > having mis-originations and route leaks every day. oh, wait. > > Perhaps what you meant to say here was: "Everyone NOT currently filtering should take page out of this latest public incident and talk to their management about: 'hey, we really don't want to look like them folks.. let's figure out this filtering jazz eh'" -------------- next part -------------- An HTML attachment was scrubbed... URL: From josmon at rigozsaurus.com Sat Dec 1 19:07:05 2018 From: josmon at rigozsaurus.com (John Osmon) Date: Sat, 1 Dec 2018 12:07:05 -0700 Subject: [outages] facebook slow In-Reply-To: <56093.1543612347@turing-police.cc.vt.edu> References: <56093.1543612347@turing-police.cc.vt.edu> Message-ID: <20181201190705.GA781@jeeves.rigozsaurus.com> On Fri, Nov 30, 2018 at 04:12:27PM -0500, valdis.kletnieks at vt.edu wrote: [...] > There's the additional factor that security is always about trade-offs - for > many sites, the dangers of using social media logins are *far* outweighed > by being able to just have a big shiny "Log in using Facebook" button instead > of making the user set up an account, pick a password, send them a verification > e-mail, then they have to read their e-mail and click on the link. Do that, and > they just left for another site. Doesn't take many people leaving for another > site before any added "security" added by doing authentication yourself is > outweighed by lost traffic. What is better for the site could be diametrically opposed to what is good for the end user. (Yet another trade-off.) Personally, the process of setting up a separate account for each site is a hoop I require before I will sign up for/with a service. I don't *CARE* if the individual site is compromised, as long as my other logins are disconnected from it completely. (For me, that means separate usernames and password pairs for each site.) I suspect there is a choir here to which I am preaching... From randy at psg.com Sat Dec 1 21:07:40 2018 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2018 13:07:40 -0800 Subject: China =?ISO-8859-7?Q?=A2s?= Maxim =?BIG5?Q?=A1V?= Leave No Access Point Unexploited: The Hidden Story of China =?ISO-8859-7?Q?Teleco?= =?ISO-8859-7?Q?m=A2?= s BGP Hijacking In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: >>> They forgot to mention that it's technically possible to filter >>> advertisements from their customer. Which apparently they were/are >>> not really doing. >> >> luckily, CT is the only isp not doing good filtering, or we would be >> having mis-originations and route leaks every day. oh, wait. > > Perhaps what you meant to say here was: “Then you should say what you mean,” the March Hare went on. “I do,” Alice hastily replied; “at least―at least I mean what I say―that’s the same thing, you know.” “Not the same thing a bit!” said the Hatter. “Why, you might just as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see’!” “You might just as well say,” added the March Hare, “that ‘I like what I get’ is the same thing as ‘I get what I like’!” “You might just as well say,” added the Dormouse, which seemed to be talking in his sleep, “that ‘I breathe when I sleep’ is the same thing as ‘I sleep when I breathe’!” From morrowc.lists at gmail.com Sat Dec 1 23:12:42 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 1 Dec 2018 18:12:42 -0500 Subject: =?UTF-8?Q?Re=3A_China_=E2=80=99s_Maxim_=E2=80=93_Leave_No_Access_Point_Unexp?= =?UTF-8?Q?loited=3A_The_Hidden_Story_of_China_Telecom=E2=80=99_s_BGP_Hijacking?= In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: On Sat, Dec 1, 2018 at 4:07 PM Randy Bush wrote: > >>> They forgot to mention that it's technically possible to filter > >>> advertisements from their customer. Which apparently they were/are > >>> not really doing. > >> > >> luckily, CT is the only isp not doing good filtering, or we would be > >> having mis-originations and route leaks every day. oh, wait. > > > > Perhaps what you meant to say here was: > > “Then you should say what you mean,” the March Hare went on. > > I know. I guess my point was: "Hey, maybe now we can get people's attention?" reminder that IRR data matters, also merry holiday-stuff, and hopefully come jan1 filters will also start mattering a lot more (for me). -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Dec 2 00:27:29 2018 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2018 16:27:29 -0800 Subject: China =?ISO-8859-7?Q?=A2s?= Maxim =?BIG5?Q?=A1V?= Leave No Access Point Unexploited: The Hidden Story of China =?ISO-8859-7?Q?Teleco?= =?ISO-8859-7?Q?m=A2?= s BGP Hijacking In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: >>>>> They forgot to mention that it's technically possible to filter >>>>> advertisements from their customer. Which apparently they were/are >>>>> not really doing. >>>> >>>> luckily, CT is the only isp not doing good filtering, or we would >>>> be having mis-originations and route leaks every day. oh, wait. >>> >>> Perhaps what you meant to say here was: >> >> “Then you should say what you mean,” the March Hare went on. >> > I know. I guess my point was: "Hey, maybe now we can get people's > attention?" my point is that over 20 years of continuing mis-originations and leaks seem not to move the needle very far. heck, you were jacked/leaked maybe ten or so days ago in about the same way you were jacked/leaked some time back. and you will be again. and those mean, nasty, godless, commie, ... chinese have no worse hygiene than 94.3% of the internet. non-chinese just love to get hysterical and accusatory when some prc isp does what almost everyone else is doing multiple times a day. and focusing on china telecom is a red herring, because damned near everyone leaks. and it is the everyone who has to change. doughnut, hole. randy From cb.list6 at gmail.com Sun Dec 2 01:14:16 2018 From: cb.list6 at gmail.com (Ca By) Date: Sat, 1 Dec 2018 17:14:16 -0800 Subject: =?UTF-8?Q?Re=3A_China_=E2=80=99s_Maxim_=E2=80=93_Leave_No_Access_Point_Unexp?= =?UTF-8?Q?loited=3A_The_Hidden_Story_of_China_Telecom=E2=80=99_s_BGP_Hijacking?= In-Reply-To: References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: On Sat, Dec 1, 2018 at 4:28 PM Randy Bush wrote: > >>>>> They forgot to mention that it's technically possible to filter > >>>>> advertisements from their customer. Which apparently they were/are > >>>>> not really doing. > >>>> > >>>> luckily, CT is the only isp not doing good filtering, or we would > >>>> be having mis-originations and route leaks every day. oh, wait. > >>> > >>> Perhaps what you meant to say here was: > >> > >> “Then you should say what you mean,” the March Hare went on. > >> > > I know. I guess my point was: "Hey, maybe now we can get people's > > attention?" > > my point is that over 20 years of continuing mis-originations and leaks > seem not to move the needle very far. heck, you were jacked/leaked > maybe ten or so days ago in about the same way you were jacked/leaked > some time back. and you will be again. > > and those mean, nasty, godless, commie, ... chinese have no worse > hygiene than 94.3% of the internet. non-chinese just love to get > hysterical and accusatory when some prc isp does what almost everyone > else is doing multiple times a day. > > and focusing on china telecom is a red herring, because damned near > everyone leaks. and it is the everyone who has to change. doughnut, > hole. > > randy Never waste a good outage to get buy-in for resources to get something good done. And if you have to pull that natsec fire alarm to move rpki to enforcing or dropping networks with repeated bad hygiene, so be it > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sun Dec 2 01:31:48 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 1 Dec 2018 17:31:48 -0800 Subject: Network Atlas End of Year 2018 Update Message-ID: NANOG Friends, The final month of 2018 is going to be a busy one for Network Atlas, and while I still have a few spare hours, I wanted to share some exciting updates and address a few questions. First, I would like to thank all the people who believe in Network Atlas and have helped it get to where it is today. Network Atlas is at its heart a community concept, and it is energizing to see so many of you excited about its potential and interested in making it better. To that end, the Network Atlas team will be spending the next month working feverishly to improve the product and get it ready for 2019. I am very excited to announce the following list of features that should come online early next year: 1. Cable system operation status allows users to see which segments are up/down/partial and their last outage, along with textual details of previous outages with potential for links 2. Cable system information - length, activation date, and estimated end-of-life 3. Fast page load time of <5 secs for users within the US 4. 3D data center locations 5. “Buy capacity” - a form that generates an email to a specified cable owner 6. Report-an-issue on routes for users to send feedback 7. Ability for users to receive email notifications about cable status changes ,Option to show subsea cables only , Option to show active cables only, Option to show future cables only 8. A Time Machine function that will show cables that will be active in the future 9. Ability to add custom fields in select or all cables to show information such as latency3-tiered Network Atlas Cable 10. Management UI: Users can:Add/Delete/Replace I can’t wait to share this next phase of Network Atlas with you all. Once it’s complete, it will truly be “one map to rule them all.” Next up, let me address the elephant in the room. As many of you know, Network Atlas’ Kickstarter for $100K for 2019 funding came up short of meeting its goal(we cancelled it before the time because many of you reached out wanting to support directly not via Kickstart). However, it was an excellent learning experience, as it provided a chance to interact with potential donors and hear their questions. One of those questions was if Network Atlas could show its 3-year plan for the project. In the interest of transparency, I would like to share with you Network Atlas’ proposed 3-year operating budget as of today. You can see this as details in our blog - https://www.networkatlas.org/blog/eoy2018 Month of December, we will freeze adding new fiber routes to Network Atlas, this will allow us to focus on working the 10 feature we have explained above. If you want to upload fiber routes you own and authorized, feel free to go to https://kmzs.networkatlas.org and upload them and please include your email address in the file name (or create a colder with readme in it) so we can reach back with questions. Our self-service portal will solve this issue in January :) Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning. Have a wonderful December, and a happy new year! Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Sun Dec 2 13:11:22 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 2 Dec 2018 08:11:22 -0500 Subject: [outages] facebook slow In-Reply-To: <56093.1543612347@turing-police.cc.vt.edu> References: <56093.1543612347@turing-police.cc.vt.edu> Message-ID: <20181202131122.GA32570@gsp.org> On Fri, Nov 30, 2018 at 04:12:27PM -0500, valdis.kletnieks at vt.edu wrote: > I'm going to go out on a limb and say that with all the problems inherent in > using a social media account as an authenticator, for 95% of sites it's still > more secure than if they attempted to create their own authentication system. [snip good analysis] However, there can be little doubt at this point that all major social media sites have long since been thorougly compromised. Of course they have: the attacker budget for doing so is enormous, easily enough to bring to bear advanced cryptanalysis techniques, judicious deployment of exploits including home-grown 0-days, and the assistance of willingly/unwillingly co-opted insiders. Meanwhile, the defenders have shown themselves to be stunningly inept and have accrued a long-term track record of massive data breaches almost too numerous to catalog. (And those are just the ones we know about to date. Surely there are more waiting in the wings.) This isn't really surprising: after all, it's not *their* data, so why should they invest time and money in securing it? Sadly, your point about the difficulty of creating homegrown authentication systems is also accurate. Therefore: we're just screwed. ---rsk ---rsk From Matthew.Black at csulb.edu Sun Dec 2 20:46:05 2018 From: Matthew.Black at csulb.edu (Matthew Black) Date: Sun, 2 Dec 2018 20:46:05 +0000 Subject: [outages] facebook slow In-Reply-To: <56093.1543612347@turing-police.cc.vt.edu> References: <56093.1543612347@turing-police.cc.vt.edu> Message-ID: My concern against using FB for authentication is this: Does using FB login give the site read access to my profile, friends, etc? My profile is set to private to keep advertisers at bay. In the early years Facebook warned users that clicking on an external link would grant such access. matthew -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of valdis.kletnieks at vt.edu Sent: Friday, November 30, 2018 1:12 PM To: Keith Medcalf Cc: nanog at nanog.org; Brian Ladd Subject: Re: [outages] facebook slow On Fri, 30 Nov 2018 13:16:31 -0700, "Keith Medcalf" said: > Why don't you just write all your password on big sheets of > construction paper and put them on the front of the building or in the nearest Starbucks? I'm going to go out on a limb and say that with all the problems inherent in using a social media account as an authenticator, for 95% of sites it's still more secure than if they attempted to create their own authentication system. Having even less security expertise than Facebook, they will probably get wrong (possibly in a subtle fashion that gets quietly exploited for years, and possibly in a spectacular fashion that makes it on the evening news). There's the additional factor that security is always about trade-offs - for many sites, the dangers of using social media logins are *far* outweighed by being able to just have a big shiny "Log in using Facebook" button instead of making the user set up an account, pick a password, send them a verification e-mail, then they have to read their e-mail and click on the link. Do that, and they just left for another site. Doesn't take many people leaving for another site before any added "security" added by doing authentication yourself is outweighed by lost traffic. From brandonwade at yahoo.com Sun Dec 2 22:06:30 2018 From: brandonwade at yahoo.com (Brandon Wade) Date: Sun, 2 Dec 2018 22:06:30 +0000 (UTC) Subject: GTT Regulatory Recovery Surcharge References: <958549463.607084.1543788390448.ref@mail.yahoo.com> Message-ID: <958549463.607084.1543788390448@mail.yahoo.com> We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions.  -Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Sun Dec 2 22:11:48 2018 From: matt at netfire.net (Matt Harris) Date: Sun, 2 Dec 2018 16:11:48 -0600 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <958549463.607084.1543788390448@mail.yahoo.com> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: On Sun, Dec 2, 2018 at 4:06 PM Brandon Wade via NANOG wrote: > We've been a GTT customer for several years and on our latest bill we now > have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only > purchase IP Transit services from them, nothing else, and have never had > any fees tacked on top of our contracted agreed upon amount. Has anyone > else ran into this? If this is a legit "surcharge" any idea of why we were > never charged for that before? I figured I'd reach out to the community on > this prior to jumping to further conclusions. > > -Brandon > Yupp, on my GTT IP transit bill as well. This is how telecomm companies pad out their margins these days. You don't even want to know the % of my bill that is just "fees" I'm paying Level3 on a wave circuit. At this point I won't sign for service without knowing exactly what I'll be paying in terms of fees and surcharges and such - there's some stuff you can't avoid on some types of circuits, but for the most part, it's all just padding out their margins. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at mnsi.net Sun Dec 2 22:30:00 2018 From: clayton at mnsi.net (Clayton Zekelman) Date: Sun, 2 Dec 2018 17:30:00 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: GTT is rapidly losing any good will they've had with us over the past number of years. We just got hit with that regulatory recovery fee too, and they totally screwed up the transfer of billing operations when they bought our colo provider, Accelerated Connections (which used to be an awesome company) in Toronto. Sent from my iPhone > On Dec 2, 2018, at 5:11 PM, Matt Harris wrote: > >> On Sun, Dec 2, 2018 at 4:06 PM Brandon Wade via NANOG wrote: >> We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions. >> >> -Brandon > > > Yupp, on my GTT IP transit bill as well. > > This is how telecomm companies pad out their margins these days. You don't even want to know the % of my bill that is just "fees" I'm paying Level3 on a wave circuit. At this point I won't sign for service without knowing exactly what I'll be paying in terms of fees and surcharges and such - there's some stuff you can't avoid on some types of circuits, but for the most part, it's all just padding out their margins. > > Take care, > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Sun Dec 2 22:32:16 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Sun, 2 Dec 2018 17:32:16 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: Message-ID: <1543789840.local-7e08e896-e3d8-v1.5.3-420ce003@getmailspring.com> Saw this on our old GTT bill first and then on our Hibernia account bill when they merge their finance dept. Filled a dispute with GTT finance and after multiple fights, we got these surcharges removed. We ended up with a HUGE mess on our bills, charged in USD when our contracts were in CAD, double-billing, etc. We lost patience and cancelled everything. At least, they should specify the actual amount of the charge on the contract. Eric On Dec 2 2018, at 5:30 pm, Clayton Zekelman wrote: > > GTT is rapidly losing any good will they've had with us over the past number of years. > > We just got hit with that regulatory recovery fee too, and they totally screwed up the transfer of billing operations when they bought our colo provider, Accelerated Connections (which used to be an awesome company) in Toronto. > > > Sent from my iPhone > > On Dec 2, 2018, at 5:11 PM, Matt Harris wrote: > > On Sun, Dec 2, 2018 at 4:06 PM Brandon Wade via NANOG wrote: > > > We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions. > > > > > > -Brandon > > > > Yupp, on my GTT IP transit bill as well. > > > > This is how telecomm companies pad out their margins these days. You don't even want to know the % of my bill that is just "fees" I'm paying Level3 on a wave circuit. At this point I won't sign for service without knowing exactly what I'll be paying in terms of fees and surcharges and such - there's some stuff you can't avoid on some types of circuits, but for the most part, it's all just padding out their margins. > > > > Take care, > > Matt > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Dec 2 22:41:08 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 2 Dec 2018 16:41:08 -0600 (CST) Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <958549463.607084.1543788390448@mail.yahoo.com> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Maybe this? https://en.wikipedia.org/wiki/Universal_Service_Fund https://www.fcc.gov/general/universal-service-fund https://www.fcc.gov/general/universal-service Kinda crappy they don't spell it out. Well, no, I guess USF would be closer to +-18%. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Brandon Wade via NANOG" To: nanog at nanog.org Sent: Sunday, December 2, 2018 4:06:30 PM Subject: GTT Regulatory Recovery Surcharge We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions. -Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Sun Dec 2 22:48:45 2018 From: matt at netfire.net (Matt Harris) Date: Sun, 2 Dec 2018 16:48:45 -0600 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Dec 2, 2018 at 4:41 PM Mike Hammett wrote: > Maybe this? > > https://en.wikipedia.org/wiki/Universal_Service_Fund > https://www.fcc.gov/general/universal-service-fund > https://www.fcc.gov/general/universal-service > > > Kinda crappy they don't spell it out. Well, no, I guess USF would be > closer to +-18%. > > USF should not apply to IP transit connectivity wherein the connection between the transit provider and the customer does not cross state lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at mnsi.net Sun Dec 2 23:04:07 2018 From: clayton at mnsi.net (Clayton Zekelman) Date: Sun, 2 Dec 2018 18:04:07 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: <5952C357-5AFC-4387-8104-71031DBA2C82@mnsi.net> They are charging it to us on a connection they deliver in Toronto Canada. I can't imagine how the corporate sociopaths could justify charging an American recovery fee on a service delivered in Canada. Sent from my iPhone > On Dec 2, 2018, at 5:48 PM, Matt Harris wrote: > >> On Sun, Dec 2, 2018 at 4:41 PM Mike Hammett wrote: >> Maybe this? >> >> https://en.wikipedia.org/wiki/Universal_Service_Fund >> https://www.fcc.gov/general/universal-service-fund >> https://www.fcc.gov/general/universal-service >> >> >> Kinda crappy they don't spell it out. Well, no, I guess USF would be closer to +-18%. >> > > USF should not apply to IP transit connectivity wherein the connection between the transit provider and the customer does not cross state lines. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Sun Dec 2 23:21:34 2018 From: james.cutler at consultant.com (James R Cutler) Date: Sun, 2 Dec 2018 18:21:34 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <5952C357-5AFC-4387-8104-71031DBA2C82@mnsi.net> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> <5952C357-5AFC-4387-8104-71031DBA2C82@mnsi.net> Message-ID: On Dec 2, 2018, at 6:04 PM, Clayton Zekelman wrote: > > I can't imagine how the corporate sociopaths could justify charging an American recovery fee on a service delivered in Canada. I would speculate that the reason is ever popular ‘because they can”. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Dec 2 23:30:36 2018 From: owen at delong.com (Owen DeLong) Date: Sun, 2 Dec 2018 15:30:36 -0800 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: Nope… IP transit doesn’t pay into USF generally speaking. USF is billed as a separate line item (at least on the bills I get where it is a factor). The “regulatory recovery fee” is a bs name telcos use to make it sound like a tax they are passing on to the government. In reality, it’s a slush fund to help pay for their lobbying efforts to get congress and various PUCs to help them screw over their customers even more. Owen > On Dec 2, 2018, at 14:41 , Mike Hammett wrote: > > Maybe this? > > https://en.wikipedia.org/wiki/Universal_Service_Fund > https://www.fcc.gov/general/universal-service-fund > https://www.fcc.gov/general/universal-service > > > Kinda crappy they don't spell it out. Well, no, I guess USF would be closer to +-18%. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Brandon Wade via NANOG" > To: nanog at nanog.org > Sent: Sunday, December 2, 2018 4:06:30 PM > Subject: GTT Regulatory Recovery Surcharge > > We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions. > > -Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Dec 2 23:31:21 2018 From: bill at herrin.us (William Herrin) Date: Sun, 2 Dec 2018 15:31:21 -0800 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Dec 2, 2018 at 2:41 PM Mike Hammett wrote: > https://en.wikipedia.org/wiki/Universal_Service_Fund > https://www.fcc.gov/general/universal-service-fund > https://www.fcc.gov/general/universal-service > > Kinda crappy they don't spell it out. Well, no, I guess USF would be > closer to +-18%. > Doubt it. They usually specify USF because they don't get to keep that money. The generic "Regulatory Recovery Surcharge" is money they keep. They may in some tangential way have an increased cost engineering their network to comply with government regulations but whatever it is there's no connection to your particular bill. Sort of like the airline "fuel surcharge" that never quite goes away when the price of fuel drops. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Sun Dec 2 23:33:09 2018 From: cma at cmadams.net (Chris Adams) Date: Sun, 2 Dec 2018 17:33:09 -0600 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <958549463.607084.1543788390448@mail.yahoo.com> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: <20181202233309.GA13384@cmadams.net> Once upon a time, Brandon Wade via NANOG said: > We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions.  It's a "because they can" fee - consumer cable and phone companies have been doing this for years to advertise lower prices and raise rates on customers in a fixed-price contract. So far, there hasn't been sufficient push-back to make it stop (and almost all of these contracts have binding arbitration clauses, so nobody can get it to a court for a precedent-setting decision). -- Chris Adams From amekkaoui at mektel.ca Sun Dec 2 23:45:40 2018 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Sun, 2 Dec 2018 18:45:40 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: <009e01d48a99$22e29110$68a7b330$@ca> Our experience with GTT was just a nightmare. All kinds of billing problems and surcharges (finance surcharge, regulatory surcharge, etc.). As soon as we finished the contract, we just stopped our business with them. Now, lawyers are taking over. KARIM M. From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: December 2, 2018 6:31 PM To: Mike Hammett Cc: brandonwade at yahoo.com; nanog at nanog.org Subject: Re: GTT Regulatory Recovery Surcharge On Sun, Dec 2, 2018 at 2:41 PM Mike Hammett wrote: https://en.wikipedia.org/wiki/Universal_Service_Fund https://www.fcc.gov/general/universal-service-fund https://www.fcc.gov/general/universal-service Kinda crappy they don't spell it out. Well, no, I guess USF would be closer to +-18%. Doubt it. They usually specify USF because they don't get to keep that money. The generic "Regulatory Recovery Surcharge" is money they keep. They may in some tangential way have an increased cost engineering their network to comply with government regulations but whatever it is there's no connection to your particular bill. Sort of like the airline "fuel surcharge" that never quite goes away when the price of fuel drops. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at paulstewart.org Mon Dec 3 00:53:06 2018 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 3 Dec 2018 00:53:06 +0000 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: Yeah similar experience here …. But we’ve had that fee for a number of years applied. Hibernia as well has been charging us for it since long ago …. ACI – yup going downhill in a hurry ;( From: NANOG on behalf of Clayton Zekelman Date: Sunday, December 2, 2018 at 5:30 PM To: Matt Harris Cc: "brandonwade at yahoo.com" , North American Network Operators' Group Subject: Re: GTT Regulatory Recovery Surcharge GTT is rapidly losing any good will they've had with us over the past number of years. We just got hit with that regulatory recovery fee too, and they totally screwed up the transfer of billing operations when they bought our colo provider, Accelerated Connections (which used to be an awesome company) in Toronto. Sent from my iPhone On Dec 2, 2018, at 5:11 PM, Matt Harris > wrote: On Sun, Dec 2, 2018 at 4:06 PM Brandon Wade via NANOG > wrote: We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions. -Brandon Yupp, on my GTT IP transit bill as well. This is how telecomm companies pad out their margins these days. You don't even want to know the % of my bill that is just "fees" I'm paying Level3 on a wave circuit. At this point I won't sign for service without knowing exactly what I'll be paying in terms of fees and surcharges and such - there's some stuff you can't avoid on some types of circuits, but for the most part, it's all just padding out their margins. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.oboyle at gmail.com Mon Dec 3 01:30:41 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Sun, 02 Dec 2018 20:30:41 -0500 Subject: GTT Regulatory Recovery Surcharge Message-ID: <5axaryfd8c3sc3xx4kf6vkxg.1543800641859@email.android.com> Same situation with us. We have dozens of circuits with them as a result of that acquisition and the previous ACI acquisition of Canopco and OneConnect. Not impressed. Not a happy customer. Already flipping to alternatives. On December 2, 2018, at 5:31 PM, Clayton Zekelman wrote: GTT is rapidly losing any good will they've had with us over the past number of years. We just got hit with that regulatory recovery fee too, and they totally screwed up the transfer of billing operations when they bought our colo provider, Accelerated Connections (which used to be an awesome company) in Toronto. Sent from my iPhone On Dec 2, 2018, at 5:11 PM, Matt Harris wrote: On Sun, Dec 2, 2018 at 4:06 PM Brandon Wade via NANOG wrote: We've been a GTT customer for several years and on our latest bill we now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We only purchase IP Transit services from them, nothing else, and have never had any fees tacked on top of our contracted agreed upon amount. Has anyone else ran into this? If this is a legit "surcharge" any idea of why we were never charged for that before? I figured I'd reach out to the community on this prior to jumping to further conclusions.  -Brandon Yupp, on my GTT IP transit bill as well.   This is how telecomm companies pad out their margins these days.  You don't even want to know the % of my bill that is just "fees" I'm paying Level3 on a wave circuit.  At this point I won't sign for service without knowing exactly what I'll be paying in terms of fees and surcharges and such - there's some stuff you can't avoid on some types of circuits, but for the most part, it's all just padding out their margins.   Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.oboyle at gmail.com Mon Dec 3 01:33:32 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Sun, 02 Dec 2018 20:33:32 -0500 Subject: GTT Regulatory Recovery Surcharge Message-ID: Well... they can until they can't because I'm no longer a customer... On December 2, 2018, at 6:23 PM, James R Cutler wrote: On Dec 2, 2018, at 6:04 PM, Clayton Zekelman wrote: I can't imagine how the corporate sociopaths could justify charging an American recovery fee on a service delivered in Canada. I would speculate that the reason is ever popular ‘because they can”. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at FiberInternetCenter.com Mon Dec 3 02:17:00 2018 From: bob at FiberInternetCenter.com (bob evans) Date: Sun, 2 Dec 2018 18:17:00 -0800 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> <5952C357-5AFC-4387-8104-71031DBA2C82@mnsi.net> Message-ID: <6492dd3657d5b4d43db026b08db1c2ce.squirrel@66.201.44.180> I think it's because they need to...not for any legal reason, but to increase cash flow by every penny possible. As they just spend 2.3 billion dollars on an acquisition. Every penny they can add to a bill is an attempt to slow the bleeding that resulting from over borrowing. 3600 employees, huge major acquisitions half a billion here - 2 billion there, where is this money coming from? Buying sales organizations with no network? One has to ask is this a secretly government funded/owned business? If so, which government? Ours? Bob Evans CTO/Founder > On Dec 2, 2018, at 6:04 PM, Clayton Zekelman wrote: >> >> I can't imagine how the corporate sociopaths could justify charging an >> American recovery fee on a service delivered in Canada. > > I would speculate that the reason is ever popular ‘because they can”. > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu From jhellenthal at dataix.net Mon Dec 3 10:21:22 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 3 Dec 2018 04:21:22 -0600 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <6492dd3657d5b4d43db026b08db1c2ce.squirrel@66.201.44.180> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> <5952C357-5AFC-4387-8104-71031DBA2C82@mnsi.net> <6492dd3657d5b4d43db026b08db1c2ce.squirrel@66.201.44.180> Message-ID: <355A4DC8-F4A9-4743-8A61-414CF60B279F@dataix.net> Down on the farm -- 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 Dec 2, 2018, at 20:17, bob evans wrote: > > I think it's because they need to...not for any legal reason, but to > increase cash flow by every penny possible. As they just spend 2.3 billion > dollars on an acquisition. Every penny they can add to a bill is an > attempt to slow the bleeding that resulting from over borrowing. > > 3600 employees, huge major acquisitions half a billion here - 2 billion > there, where is this money coming from? Buying sales organizations with no > network? > > One has to ask is this a secretly government funded/owned business? If so, > which government? Ours? > > Bob Evans > CTO/Founder > >>> On Dec 2, 2018, at 6:04 PM, Clayton Zekelman wrote: >>> >>> I can't imagine how the corporate sociopaths could justify charging an >>> American recovery fee on a service delivered in Canada. >> >> I would speculate that the reason is ever popular ‘because they can”. >> >> James R. Cutler >> James.cutler at consultant.com >> PGP keys at http://pgp.mit.edu > > From martin at airwire.ie Mon Dec 3 13:49:03 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 3 Dec 2018 13:49:03 +0000 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <958549463.607084.1543788390448@mail.yahoo.com> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> Message-ID: <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> On 02/12/2018 22:06, Brandon Wade via NANOG wrote: > We've been a GTT customer for several years and on our latest bill we > now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We > only purchase IP Transit services from them, nothing else, and have > never had any fees tacked on top of our contracted agreed upon amount. > Has anyone else ran into this? If this is a legit "surcharge" any idea > of why we were never charged for that before? I figured I'd reach out to > the community on this prior to jumping to further conclusions. > > -Brandon Hi, I'm not sure, if thats a stateside thing, but GTT started increasing the prices on customers that were out of contract to try and get them back into a long term contract. For us that was the last straw, where we simply told them to take their IP transit and keep it. Cancelled all GTT connections and replaced them with a carrier, that doesn't try to screw their customer base. Kind regards, Martin List-Petersen -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From beecher at beecher.cc Mon Dec 3 14:01:24 2018 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 3 Dec 2018 09:01:24 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> Message-ID: "Cancelled all GTT connections and replaced them with a carrier, that doesn't try to screw their customer base." Who is this magical unicorn? :) On Mon, Dec 3, 2018 at 8:51 AM Martin List-Petersen wrote: > On 02/12/2018 22:06, Brandon Wade via NANOG wrote: > > We've been a GTT customer for several years and on our latest bill we > > now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We > > only purchase IP Transit services from them, nothing else, and have > > never had any fees tacked on top of our contracted agreed upon amount. > > Has anyone else ran into this? If this is a legit "surcharge" any idea > > of why we were never charged for that before? I figured I'd reach out to > > the community on this prior to jumping to further conclusions. > > > > -Brandon > > Hi, > > I'm not sure, if thats a stateside thing, but GTT started increasing the > prices on customers that were out of contract to try and get them back > into a long term contract. > > For us that was the last straw, where we simply told them to take their > IP transit and keep it. Cancelled all GTT connections and replaced them > with a carrier, that doesn't try to screw their customer base. > > Kind regards, > Martin List-Petersen > -- > Airwire Ltd. - Ag Nascadh Pobail an Iarthair > http://www.airwire.ie > Phone: 091-395 000 > Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in > Ireland No. 508961 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Dec 3 14:04:40 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 3 Dec 2018 08:04:40 -0600 (CST) Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <937271512.5210.1543790465526.JavaMail.mhammett@ThunderFuck> Message-ID: <253854491.5328.1543845877852.JavaMail.mhammett@ThunderFuck> "Should not". I hear of ISPs fighting it all of the time. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Harris" To: nanog at ics-il.net Cc: brandonwade at yahoo.com, "North American Network Operators' Group" Sent: Sunday, December 2, 2018 4:48:45 PM Subject: Re: GTT Regulatory Recovery Surcharge On Sun, Dec 2, 2018 at 4:41 PM Mike Hammett < nanog at ics-il.net > wrote: Maybe this? https://en.wikipedia.org/wiki/Universal_Service_Fund https://www.fcc.gov/general/universal-service-fund https://www.fcc.gov/general/universal-service Kinda crappy they don't spell it out. Well, no, I guess USF would be closer to +-18%. USF should not apply to IP transit connectivity wherein the connection between the transit provider and the customer does not cross state lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at airwire.ie Mon Dec 3 14:05:09 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 3 Dec 2018 14:05:09 +0000 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> Message-ID: <0d0a5e82-4f29-30c2-aa98-6f27b76bc9bd@airwire.ie> On 03/12/2018 14:01, Tom Beecher wrote: > "Cancelled all GTT connections and replaced them > with a carrier, that doesn't try to screw their customer base." > > Who is this magical unicorn? :) Replaced that circuit with NTT. So far, very pleased with that. Kind regards, Martin List-Petersen Airwire Ltd. > > On Mon, Dec 3, 2018 at 8:51 AM Martin List-Petersen > wrote: > >> On 02/12/2018 22:06, Brandon Wade via NANOG wrote: >>> We've been a GTT customer for several years and on our latest bill we >>> now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We >>> only purchase IP Transit services from them, nothing else, and have >>> never had any fees tacked on top of our contracted agreed upon amount. >>> Has anyone else ran into this? If this is a legit "surcharge" any idea >>> of why we were never charged for that before? I figured I'd reach out to >>> the community on this prior to jumping to further conclusions. >>> >>> -Brandon >> >> Hi, >> >> I'm not sure, if thats a stateside thing, but GTT started increasing the >> prices on customers that were out of contract to try and get them back >> into a long term contract. >> >> For us that was the last straw, where we simply told them to take their >> IP transit and keep it. Cancelled all GTT connections and replaced them >> with a carrier, that doesn't try to screw their customer base. >> >> Kind regards, >> Martin List-Petersen >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From beecher at beecher.cc Mon Dec 3 14:11:36 2018 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 3 Dec 2018 09:11:36 -0500 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: <0d0a5e82-4f29-30c2-aa98-6f27b76bc9bd@airwire.ie> References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> <0d0a5e82-4f29-30c2-aa98-6f27b76bc9bd@airwire.ie> Message-ID: There are quite a few not crappy vendors out there, regardless of my snark. NTT is definitely one of the better ones. Unfortunately, telecommunications billing is only slightly less complex than medical billing, and there are plenty of vendors that have made those decisions to invest in more financial engineering than technical since, as has been said, they can. On Mon, Dec 3, 2018 at 9:05 AM Martin List-Petersen wrote: > On 03/12/2018 14:01, Tom Beecher wrote: > > "Cancelled all GTT connections and replaced them > > with a carrier, that doesn't try to screw their customer base." > > > > Who is this magical unicorn? :) > > Replaced that circuit with NTT. So far, very pleased with that. > > Kind regards, > Martin List-Petersen > Airwire Ltd. > > > > > > On Mon, Dec 3, 2018 at 8:51 AM Martin List-Petersen > > wrote: > > > >> On 02/12/2018 22:06, Brandon Wade via NANOG wrote: > >>> We've been a GTT customer for several years and on our latest bill we > >>> now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We > >>> only purchase IP Transit services from them, nothing else, and have > >>> never had any fees tacked on top of our contracted agreed upon amount. > >>> Has anyone else ran into this? If this is a legit "surcharge" any idea > >>> of why we were never charged for that before? I figured I'd reach out > to > >>> the community on this prior to jumping to further conclusions. > >>> > >>> -Brandon > >> > >> Hi, > >> > >> I'm not sure, if thats a stateside thing, but GTT started increasing the > >> prices on customers that were out of contract to try and get them back > >> into a long term contract. > >> > >> For us that was the last straw, where we simply told them to take their > >> IP transit and keep it. Cancelled all GTT connections and replaced them > >> with a carrier, that doesn't try to screw their customer base. > >> > >> Kind regards, > >> Martin List-Petersen > >> -- > >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair > >> http://www.airwire.ie > >> Phone: 091-395 000 > >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in > >> Ireland No. 508961 > >> > > > > > -- > Airwire Ltd. - Ag Nascadh Pobail an Iarthair > http://www.airwire.ie > Phone: 091-395 000 > Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in > Ireland No. 508961 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at airwire.ie Mon Dec 3 14:33:47 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 3 Dec 2018 14:33:47 +0000 Subject: GTT Regulatory Recovery Surcharge In-Reply-To: References: <958549463.607084.1543788390448.ref@mail.yahoo.com> <958549463.607084.1543788390448@mail.yahoo.com> <700fd541-b49b-227a-19c4-76936c9c1ae1@airwire.ie> <0d0a5e82-4f29-30c2-aa98-6f27b76bc9bd@airwire.ie> Message-ID: We have CenturyLink, Cogent, NTT and Viatel in the mix for IP transit. CenturyLink and Cogent are unproblematic, unless you change something (like upgrading a circuit). Cogent will fix billing issues quickly, but they do crop up. CenturyLink is not very communicative. Can't fault the service, but their billing department is a mess. We've had Viatel for years without much issues. They are an european Tier 2. NTT only just enabled their PoP where we haul our backhaul from, so time will show. But they've been very proactive. We used to have PacketExchange, but left them because they were a mess. They were taken over by or merged with GTT eventually. We moved to Tiscali back then, which became TInet and then changed name 2 more times before they got swallowed up by GTT. So we ended up where we started .. including all the problems that came with it. Connectivity was solid enough, once you didn't have to deal with them. But when they increased our monthly pricing, which already was on the higher scale of what we pay in the mix ... we told them to go away. Kind regards, Martin List-Petersen Airwire Ltd. On 03/12/2018 14:11, Tom Beecher wrote: > There are quite a few not crappy vendors out there, regardless of my snark. > NTT is definitely one of the better ones. > > Unfortunately, telecommunications billing is only slightly less complex > than medical billing, and there are plenty of vendors that have made those > decisions to invest in more financial engineering than technical since, as > has been said, they can. > > > > > > On Mon, Dec 3, 2018 at 9:05 AM Martin List-Petersen > wrote: > >> On 03/12/2018 14:01, Tom Beecher wrote: >>> "Cancelled all GTT connections and replaced them >>> with a carrier, that doesn't try to screw their customer base." >>> >>> Who is this magical unicorn? :) >> >> Replaced that circuit with NTT. So far, very pleased with that. >> >> Kind regards, >> Martin List-Petersen >> Airwire Ltd. >> >> >>> >>> On Mon, Dec 3, 2018 at 8:51 AM Martin List-Petersen >>> wrote: >>> >>>> On 02/12/2018 22:06, Brandon Wade via NANOG wrote: >>>>> We've been a GTT customer for several years and on our latest bill we >>>>> now have a "Regulatory Recovery Surcharge" of almost 10% tacked on. We >>>>> only purchase IP Transit services from them, nothing else, and have >>>>> never had any fees tacked on top of our contracted agreed upon amount. >>>>> Has anyone else ran into this? If this is a legit "surcharge" any idea >>>>> of why we were never charged for that before? I figured I'd reach out >> to >>>>> the community on this prior to jumping to further conclusions. >>>>> >>>>> -Brandon >>>> >>>> Hi, >>>> >>>> I'm not sure, if thats a stateside thing, but GTT started increasing the >>>> prices on customers that were out of contract to try and get them back >>>> into a long term contract. >>>> >>>> For us that was the last straw, where we simply told them to take their >>>> IP transit and keep it. Cancelled all GTT connections and replaced them >>>> with a carrier, that doesn't try to screw their customer base. >>>> >>>> Kind regards, >>>> Martin List-Petersen >>>> -- >>>> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >>>> http://www.airwire.ie >>>> Phone: 091-395 000 >>>> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >>>> Ireland No. 508961 >>>> >>> >> >> >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From dave at temk.in Tue Dec 4 18:04:49 2018 From: dave at temk.in (Dave Temkin) Date: Tue, 4 Dec 2018 13:04:49 -0500 Subject: Verizon: Extremely Strange CPE Routing in NYC/NJ Area In-Reply-To: References: Message-ID: See this post for more info: http://www.dslreports.com/forum/r32136909-Has-Vz-disabled-TTL-propagation On Thu, Nov 29, 2018 at 3:09 PM Nick Zurku wrote: > Can anyone from Verizon take a look at this behavior for us? > > > We’re having multiple Verizon FiOS users in the NYC/NJ area appear to > teleport from their FiOS router to our IP in the Pittsburgh region. Users > are seeing extreme slowness with TCP traffic, but ping times seem > reasonable. > > User 1: > 1 fios_quantum_gateway (192.168.1.1) 1.575 ms 2.426 ms 3.193 ms > 2 204.16.244.8 (204.16.244.8) 2.269 ms 3.055 ms 2.727 ms > > User 2: > 1 fios_quantum_gateway (192.168.1.1) 1.565 ms 1.048 ms 0.947 ms > 2 204.16.244.8 (204.16.244.8) 2.162 ms 3.588 ms 3.048 ms > > I can provide end-user NYC/NJ IPs off-list if desirable. > > > Here's a normal looking trace from an FiOS line locally in the Pittsburgh > region: > > > IP: 108.39.229.34 > Tracing route to four.libsyn.com [204.16.244.8] > over a maximum of 30 hops: > > 1 <1 ms <1 ms <1 ms 192.168.1.1 > 2 5 ms 2 ms 7 ms lo0-100.PITBPA-VFTTP-301.verizon-gni.net > [108.39.229.1] > 3 5 ms 6 ms 6 ms B3301.PITBPA-LCR-22.verizon-gni.net > [100.41.223.244] > 4 * * * Request timed out. > 5 * * * Request timed out. > 6 13 ms 12 ms 13 ms 0.et-7-1-5.BR1.IAD8.ALTER.NET > [140.222.226.17] > 7 10 ms 10 ms 10 ms verizon.com.customer.alter.net > [152.179.50.110] > 8 12 ms 12 ms 13 ms be3084.ccr42.dca01.atlas.cogentco.com > [154.54.30.65] > 9 22 ms 22 ms 22 ms be2820.rcr21.pit02.atlas.cogentco.com > [154.54.83.54] > 10 22 ms 22 ms 21 ms 38.104.120.90 > 11 26 ms 21 ms 19 ms 204.16.241.133 > 12 * * * Request timed out. > 13 21 ms 21 ms 21 ms 204.16.244.8 > > Is this a possible traffic engineering blip? I can’t say we’ve ever > seen trace routes return such sparse results and actually make it to the > destination. > > -- > Nick Zurku > Systems Engineer > TeraSwitch, Inc. > Cell: 412-953-0481 > Office: 412-945-7048 > nzurku at teraswitch.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rod.beck at unitedcablecompany.com Tue Dec 4 22:45:10 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 4 Dec 2018 22:45:10 +0000 Subject: Article On Google Message-ID: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge [https://media.newyorker.com/photos/5c0040d75cc0c92d353cfc9c/16:9/w_1200,h_630,c_limit/181210_r33377.jpg] The Friendship That Made Google Huge | The New Yorker www.newyorker.com The Google campus, set beside a highway a few minutes from downtown Mountain View, is a series of squat, unattractive buildings with tinted windows. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Dec 5 16:24:45 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 5 Dec 2018 08:24:45 -0800 Subject: used hardware reseller Message-ID: Hi there I am looking to buy juniper qfx and some dwdm gear to be shipped overseas (indonesia, thailand, colombia, chile...) I am looking to see if therr are any preferred hardware resellers people would recommend? If you know a way to buy local that would be fantastic otherwise shipping it is the way to go. Please contact me offlist Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From msa at latt.net Wed Dec 5 21:12:58 2018 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 5 Dec 2018 16:12:58 -0500 Subject: Network Atlas End of Year 2018 Update In-Reply-To: References: Message-ID: <20181205211258.GA17596@puck.nether.net> On Sat, Dec 01, 2018 at 05:31:48PM -0800, Mehmet Akcin wrote: > Next up, let me address the elephant in the room. As many of you know, > Network Atlas’ Kickstarter for $100K for 2019 funding came up short of > meeting its goal(we cancelled it before the time because many of you > reached out wanting to support directly not via Kickstart). However, it was > an excellent learning experience, as it provided a chance to interact with > potential donors and hear their questions. One of those questions was if > Network Atlas could show its 3-year plan for the project. In the interest > of transparency, I would like to share with you Network Atlas’ proposed > 3-year operating budget as of today. > > You can see this as details in our blog - > https://www.networkatlas.org/blog/eoy2018 Hey Mehmet, Thanks for putting together this resource for the community. Can you expand on some of these line items? I'm at a bit of a loss as to how a community funded, crowd-sourced service likes this needs 18% of its budget allocated to travel. What am I missing? Thanks! --msa From mehmet at akcin.net Wed Dec 5 21:36:18 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 5 Dec 2018 15:36:18 -0600 Subject: Network Atlas End of Year 2018 Update In-Reply-To: <20181205211258.GA17596@puck.nether.net> References: <20181205211258.GA17596@puck.nether.net> Message-ID: Hi Majdi, On Wed, Dec 5, 2018 at 3:12 PM Majdi S. Abbas wrote: > > > https://www.networkatlas.org/blog/eoy2018 > > > Hey Mehmet, > > Thanks for putting together this resource for the community. > > Can you expand on some of these line items? I'm at a bit of a > loss as to how a community funded, crowd-sourced service likes this > needs 18% of its budget allocated to travel. How are you calculating the 18%? > > What am I missing? > > Thanks! > > --msa > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Dec 5 21:43:41 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2018 16:43:41 -0500 Subject: Network Atlas End of Year 2018 Update In-Reply-To: References: <20181205211258.GA17596@puck.nether.net> Message-ID: On Wed, Dec 5, 2018 at 4:37 PM Mehmet Akcin wrote: > Hi Majdi, > > On Wed, Dec 5, 2018 at 3:12 PM Majdi S. Abbas wrote: > >> >> > https://www.networkatlas.org/blog/eoy2018 >> >> >> Hey Mehmet, >> >> Thanks for putting together this resource for the community. >> >> Can you expand on some of these line items? I'm at a bit of a >> loss as to how a community funded, crowd-sourced service likes this >> needs 18% of its budget allocated to travel. > > > How are you calculating the 18%? > > 36000/313000 * 100 = 11.5% (maybe majdi included the line item above as well?) > >> >> What am I missing? >> >> Thanks! >> >> --msa >> > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjs at rob.sh Wed Dec 5 21:53:22 2018 From: rjs at rob.sh (Rob Shakir) Date: Wed, 5 Dec 2018 13:53:22 -0800 Subject: L3 Network topology in YANG In-Reply-To: <1760484f-2f82-ecd8-5dcd-be6110586c6e@noc.grnet.gr> References: <1760484f-2f82-ecd8-5dcd-be6110586c6e@noc.grnet.gr> Message-ID: Hi Yannis, I know that there are some folks using pyangbind with models that correspond to topology including rfc8346, similarly, some folks are using goyang +ygot (where using Go) for dealing with their topology models in YANG. I'm not clear how far these operations are along, but I've handled feature requests related to these models in both. Cheers, r. On Mon, 19 Nov 2018 at 09:44 Yannis Mitsos wrote: > All, > > I was wondering if there is any network operator who exposes > (dynamically?) its topology in YANG based on RFC8346 [1]. I understand > that for commercial operators and purposes, may not be of any > substantial value. > We are assessing some available tools[2],[3],[4] on how to achieve this > but we would like to know if there is any success story out there. > > Regards, > > Yannis > > [1] https://tools.ietf.org/html/rfc8346 > [2] https://github.com/robshakir/pyangbind > [3] https://github.com/YangModels/yang.git > [4] https://developer.cisco.com/site/ydk > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ispcolohost at gmail.com Wed Dec 5 22:01:20 2018 From: ispcolohost at gmail.com (David H) Date: Wed, 5 Dec 2018 22:01:20 +0000 Subject: Monitoring service that has a human component? Message-ID: Hey all, was curious if anyone knows of a website monitoring service that has the option to incorporate a human component into the decision and escalation tree? I’m trying to help a customer find a way around false positives bogging down their NOC staff, by having a human determine the difference between a real error, desired (but different) content, or something in between like “Hey it’s 3am and we’ve taken our website offline for maintenance, we’ll be back up by 6am.” Automated systems tend to only know if test A, or steps A through C, are failing, then this is ‘down’ and do my preconfigured thing, but that ends up needlessly taking NOC time if the customer themselves is performing work on their own site, or just changed it and whatever content was being watched, is now gone. So, the goal would be to have the end user be the first point of contact if it looks like more of a customer-side issue. If they can’t be reached to confirm, THEN contact NOC, and unlike email alerts, keep contacting until a human acknowledges receipt of the alert. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Dec 5 22:12:41 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 5 Dec 2018 17:12:41 -0500 Subject: Monitoring service that has a human component? In-Reply-To: References: Message-ID: <54014F1E-BBDD-4672-B2B8-8AB7D131E378@puck.nether.net> > On Dec 5, 2018, at 5:01 PM, David H wrote: > > Hey all, was curious if anyone knows of a website monitoring service that has the option to incorporate a human component into the decision and escalation tree? I’m trying to help a customer find a way around false positives bogging down their NOC staff, by having a human determine the difference between a real error, desired (but different) content, or something in between like “Hey it’s 3am and we’ve taken our website offline for maintenance, we’ll be back up by 6am.” Automated systems tend to only know if test A, or steps A through C, are failing, then this is ‘down’ and do my preconfigured thing, but that ends up needlessly taking NOC time if the customer themselves is performing work on their own site, or just changed it and whatever content was being watched, is now gone. So, the goal would be to have the end user be the first point of contact if it looks like more of a customer-side issue. If they can’t be reached to confirm, THEN contact NOC, and unlike email alerts, keep contacting until a human acknowledges receipt of the alert. I know there are outsourced NOC services you can hire. I’m not sure how long it would take, but I wonder if you could do an API call to something like mechanical turk as well? - Jared From john at essenz.com Wed Dec 5 22:39:30 2018 From: john at essenz.com (John Von Essen) Date: Wed, 5 Dec 2018 17:39:30 -0500 Subject: Monitoring service that has a human component? In-Reply-To: References: Message-ID: <137ef875-e975-752b-cebf-dcfe586c0d56@essenz.com> Whats your budget? The outsourced NOC firms tend to be expensive (I've looked at them for a project), and they are also not that fast, so dont expect someone to determine if an alarm is valid within a few minutes, instead, in goes into their queue and waits for a tech to pick it up, so it could be 30-60 mins. In a perfect scenario, using freelancer/gig-economy people should be able to get this done quickly, but its needs to be sizeable to start and will involve alot of logistics, which means money. To be honest, the best option may be to hire a developer to custom code really good logic that eliminates a good deal of the false positives so only a handful make it through. -John On 12/5/18 5:01 PM, David H wrote: > > Hey all, was curious if anyone knows of a website monitoring service > that has the option to incorporate a human component into the decision > and escalation tree?  I’m trying to help a customer find a way around > false positives bogging down their NOC staff, by having a human > determine the difference between a real error, desired (but different) > content, or something in between like “Hey it’s 3am and we’ve taken > our website offline for maintenance, we’ll be back up by 6am.” >  Automated systems tend to only know if test A, or steps A through C, > are failing, then this is ‘down’ and do my preconfigured thing, but > that ends up needlessly taking NOC time if the customer themselves is > performing work on their own site, or just changed it and whatever > content was being watched, is now gone.  So, the goal would be to have > the end user be the first point of contact if it looks like more of a > customer-side issue.  If they can’t be reached to confirm, THEN > contact NOC, and unlike email alerts, keep contacting until a human > acknowledges receipt of the alert. > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Dec 5 22:58:46 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 5 Dec 2018 17:58:46 -0500 Subject: Monitoring service that has a human component? In-Reply-To: <137ef875-e975-752b-cebf-dcfe586c0d56@essenz.com> References: <137ef875-e975-752b-cebf-dcfe586c0d56@essenz.com> Message-ID: For my 9-5 we have a company that has a 24/7 NOC that watches all of our boxes. They CEO is in the US and the NOC guys are seas. They are generally very responsive. It's very affordable (about $200.00 per box per month). These guys work real well but they are sort of work in the Box. We need to give them guidelines. For example we do telecom and clients get hit with fraud all the time. There are times where we know it's 90% fraud and we want them to shut it down, there are times where there is a 50/50 chance that it's fraud. If the system thinks there is a 90% chance it emails them "Fraud call from X to Y". They then have a procedure on how to figure out based on the call record who the client is and they shut them down. If it's the 50/50 chance they get an alert "POSSIBLE Fraudulent call from X to Y". For such a call they have to go through a series of checks before they shut them down. What I am getting at is they aren't good at figuring out what is fraud but are very good at following rules and doing exactly what you ask of them. What ever technology we use they learn it (be it OpenSips, Asterisk etc.). We do need to tell them exactly what to monitor and what to do for specific alarms. If you want an intro let me know. On Wed, Dec 5, 2018 at 5:40 PM John Von Essen wrote: > Whats your budget? > > The outsourced NOC firms tend to be expensive (I've looked at them for a > project), and they are also not that fast, so dont expect someone to > determine if an alarm is valid within a few minutes, instead, in goes into > their queue and waits for a tech to pick it up, so it could be 30-60 mins. > > In a perfect scenario, using freelancer/gig-economy people should be able > to get this done quickly, but its needs to be sizeable to start and will > involve alot of logistics, which means money. > > To be honest, the best option may be to hire a developer to custom code > really good logic that eliminates a good deal of the false positives so > only a handful make it through. > -John > > On 12/5/18 5:01 PM, David H wrote: > > Hey all, was curious if anyone knows of a website monitoring service that > has the option to incorporate a human component into the decision and > escalation tree? I’m trying to help a customer find a way around false > positives bogging down their NOC staff, by having a human determine the > difference between a real error, desired (but different) content, or > something in between like “Hey it’s 3am and we’ve taken our website offline > for maintenance, we’ll be back up by 6am.” Automated systems tend to only > know if test A, or steps A through C, are failing, then this is ‘down’ and > do my preconfigured thing, but that ends up needlessly taking NOC time if > the customer themselves is performing work on their own site, or just > changed it and whatever content was being watched, is now gone. So, the > goal would be to have the end user be the first point of contact if it > looks like more of a customer-side issue. If they can’t be reached to > confirm, THEN contact NOC, and unlike email alerts, keep contacting until a > human acknowledges receipt of the alert. > > > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Dec 5 23:19:03 2018 From: randy at psg.com (Randy Bush) Date: Wed, 05 Dec 2018 15:19:03 -0800 Subject: trace from behind tata noam Message-ID: a host in as4128, 198.180.152.15, is having problems getting to stuff behind as6453 (tata). so i try to get an atlas traceroute toward 198.180.152.15 from as6453. but atlas whines Probes selection: Your selected ASN is not covered by our network so not even one measly probe. if anyone here is 'behind' 6453 en route 198.180.152.15, can you send a trace, please? thanks. randy From hank at efes.iucc.ac.il Thu Dec 6 06:41:53 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 6 Dec 2018 08:41:53 +0200 Subject: trace from behind tata noam In-Reply-To: References: Message-ID: <253a23ba-a5e8-57b8-b7a7-068f2c5daddd@efes.iucc.ac.il> On 06/12/2018 01:19, Randy Bush wrote: > a host in as4128, 198.180.152.15, is having problems getting to stuff > behind as6453 (tata). so i try to get an atlas traceroute toward > 198.180.152.15 from as6453. but atlas whines > > Probes selection: Your selected ASN is not covered by our network > > so not even one measly probe. > > if anyone here is 'behind' 6453 en route 198.180.152.15, can you send > a trace, please? > > thanks. > > randy > Rather than letting ATLAS whine, everyone should become an ATLAS ambassador so as to increase the spread of ATLAS probes to exactly those ASNs which are under-represented: https://atlas.ripe.net/get-involved/become-a-ripe-atlas-ambassador/ -Hank From nanog at radu-adrian.feurdean.net Thu Dec 6 10:52:06 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 06 Dec 2018 11:52:06 +0100 Subject: trace from behind tata noam In-Reply-To: References: Message-ID: <1544093526.3084335.1600749144.5CDF27CD@webmail.messagingengine.com> On Thu, Dec 6, 2018, at 00:19, Randy Bush wrote: > if anyone here is 'behind' 6453 en route 198.180.152.15, can you send > a trace, please? They have a looking-glass : http://lg.as6453.net/lg/ which says : Router: gin-pv0-thar1 Site: FR, Paris, PV0 Command: traceroute inet4 198.180.152.15 as-number-lookup traceroute to 198.180.152.15 (198.180.152.15), 30 hops max, 52 byte packets 1 if-ae-6-4.tcore1.pg1-paris.as6453.net (80.231.111.25) 1.258 ms 1.726 ms 1.712 ms MPLS Label=334414 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore1.pvu-paris.as6453.net (80.231.111.6) 1.703 ms 1.516 ms if-ae-7-2.tcore1.pvu-paris.as6453.net (80.231.111.2) 1.360 ms 3 if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 1.266 ms ae-7.r04.parsfr01.fr.bb.gin.ntt.net (129.250.8.1) [AS 2914] 1.126 ms if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 1.246 ms 4 ae-23.r24.amstnl02.nl.bb.gin.ntt.net (129.250.4.137) [AS 2914] 16.599 ms 20.124 ms 13.608 ms MPLS Label=304689 CoS=0 TTL=1 S=1 5 ae-3.r25.amstnl02.nl.bb.gin.ntt.net (129.250.4.69) [AS 2914] 13.669 ms 13.672 ms 14.638 ms MPLS Label=434000 CoS=0 TTL=1 S=0 MPLS Label=531024 CoS=0 TTL=1 S=1 6 ae-5.r23.asbnva02.us.bb.gin.ntt.net (129.250.6.162) [AS 2914] 86.304 ms 86.438 ms 101.443 ms MPLS Label=309569 CoS=0 TTL=1 S=0 MPLS Label=531024 CoS=0 TTL=2 S=1 7 ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 98.043 ms ae-5.r23.asbnva02.us.bb.gin.ntt.net (129.250.6.162) [AS 2914] 115.804 ms ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 91.169 ms MPLS Label=379041 CoS=0 TTL=1 S=0 MPLS Label=531024 CoS=0 TTL=3 S=1 8 ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 89.571 ms ae-6.r22.dllstx09.us.bb.gin.ntt.net (129.250.5.12) [AS 2914] 124.242 ms 130.316 ms MPLS Label=531024 CoS=0 TTL=1 S=1 9 ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914] 130.781 ms 119.661 ms 132.269 ms 10 ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914] 122.000 ms ge-102-0-0-29-53.r11.dllstx09.us.ce.gin.ntt.net (157.238.224.206) [AS 2914] 128.046 ms ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914] 130.434 ms 11 netsrv.dfw.rg.net (198.180.152.15) [AS 4128] 129.176 ms 121.615 ms ge-102-0-0-29-53.r11.dllstx09.us.ce.gin.ntt.net (157.238.224.206) [AS 2914] 126.358 ms {master} From nanog at radu-adrian.feurdean.net Thu Dec 6 10:54:10 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 06 Dec 2018 11:54:10 +0100 Subject: trace from behind tata noam In-Reply-To: <1544093526.3084335.1600749144.5CDF27CD@webmail.messagingengine.com> References: <1544093526.3084335.1600749144.5CDF27CD@webmail.messagingengine.com> Message-ID: <1544093650.3085683.1600751640.27A110DF@webmail.messagingengine.com> On Thu, Dec 6, 2018, at 11:52, Radu-Adrian Feurdean wrote: > Router: gin-pv0-thar1 > Site: FR, Paris, PV0 Very similar results (going to NTT in very few hops) from their 2 NYC routers. From rod.beck at unitedcablecompany.com Thu Dec 6 16:32:04 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 6 Dec 2018 16:32:04 +0000 Subject: CLEC Lawyer - New Jersey Message-ID: Hi, I need a lawyer who can get our company licensed as a CLEC in the state of New Jersey. Any suggestions appreciated? Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstogdill at hammercomm.com Thu Dec 6 16:37:34 2018 From: mstogdill at hammercomm.com (Mark Stogdill) Date: Thu, 6 Dec 2018 11:37:34 -0500 Subject: CLEC Lawyer - New Jersey In-Reply-To: References: Message-ID: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> Scarinci & Hollenbeck. We have a NJ CLEC and they worked with us. Mark > On Dec 6, 2018, at 11:32 AM, Rod Beck wrote: > > Hi, > > I need a lawyer who can get our company licensed as a CLEC in the state of New Jersey. Any suggestions appreciated? > > Roderick Beck > Director of Global Sales > United Cable Company > www.unitedcablecompany.com > New York City & Budapest > rod.beck at unitedcablecompany.com > 36-30-859-5144 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.zack at cira.ca Wed Dec 5 15:46:50 2018 From: jake.zack at cira.ca (Jake Zack) Date: Wed, 5 Dec 2018 15:46:50 +0000 Subject: Call For Presentations - DNS-OARC Workshop, Thailand, Bangkok, 12th/13th May 2019 Message-ID: The 30th DNS-OARC Workshop will take place at the Shangri-La Hotel, Bangkok, Thailand, on May 12th and 13th 2019, hosted by ICANN. (Note that several co-located meetings are taking place immediately prior to the DNS-OARC Workshop, including the GDD Industry Summit, May 6th-9th, the Registrations Operations Workshop, May 9th, and the ICANN DNS Symposium, May 10th-11th.) The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted until the start of the morning session on day two. There will be a Members-only session during the workshop, which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 05 Dec 2018 - Submissions open via Indico 22 Feb 2019 - Deadline for submission 01 Mar 2019 - Initial Contribution list published 22 Mar 2019 - Full agenda published 03 May 2019 - Deadline for slideset submission 12 May 2019 - Workshop Details for presentation submission are published here: https://indico.dns-oarc.net/event/31/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissions at dns-oarc.net Jacob Zack, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact sponsor at dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Dec 6 16:52:18 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 6 Dec 2018 09:52:18 -0700 Subject: CLEC Lawyer - New Jersey In-Reply-To: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> Message-ID: > On Dec 6, 2018, at 9:37 AM, Mark Stogdill wrote: > > Scarinci & Hollenbeck. We have a NJ CLEC and they worked with us. Mark, do you have a direct contact there? I'd love to be put in touch with them to have the connection; I just joined the board of the Denver IX, and CLEC stuff is tangential to my own area of legal expertise, so it's always good to know a colleague in a related area. Thanks either way! Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From amitchell at isipp.com Thu Dec 6 17:59:30 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 6 Dec 2018 10:59:30 -0700 Subject: CLEC Lawyer - New Jersey In-Reply-To: <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> Message-ID: <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> > Hi Anne, > > My contact there is Crystal Prais. Her contact information is below. > > CRYSTAL M. PRAIS | Associate > cprais at scarincihollenbeck.com > Direct Phone: 201-806-3381 | Direct Fax: 201-806-3482 > > Happy connecting! Thank you, Mark! Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From pauldotwall at gmail.com Thu Dec 6 19:03:41 2018 From: pauldotwall at gmail.com (Paul WALL) Date: Thu, 6 Dec 2018 14:03:41 -0500 Subject: CLEC Lawyer - New Jersey In-Reply-To: <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> Message-ID: https://www.quora.com/Is-it-now-considered-business-etiquette-only-to-include-an-email-signature-in-the-first-email-to-someone-and-not-in-subsequent-replies-to-the-same-message https://www.lifewire.com/email-signature-location-1173260 https://www.hanselman.com/blog/EmailSignatureEtiquetteTooMuchFlair.aspx On Thu, Dec 6, 2018 at 1:01 PM Anne P. Mitchell, Esq. wrote: > > > Hi Anne, > > > > My contact there is Crystal Prais. Her contact information is below. > > > > CRYSTAL M. PRAIS | Associate > > cprais at scarincihollenbeck.com > > Direct Phone: 201-806-3381 | Direct Fax: 201-806-3482 > > > > Happy connecting! > > Thank you, Mark! > > Anne > > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Dec 6 19:19:20 2018 From: matt at netfire.net (Matt Harris) Date: Thu, 6 Dec 2018 13:19:20 -0600 Subject: CLEC Lawyer - New Jersey In-Reply-To: References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> Message-ID: On Thu, Dec 6, 2018 at 1:04 PM Paul WALL wrote: > > https://www.quora.com/Is-it-now-considered-business-etiquette-only-to-include-an-email-signature-in-the-first-email-to-someone-and-not-in-subsequent-replies-to-the-same-message > > https://www.lifewire.com/email-signature-location-1173260 > > https://www.hanselman.com/blog/EmailSignatureEtiquetteTooMuchFlair.aspx > Oh snap, it's the sig police coming to enforce the sig law. Somebody find a sig defense lawyer! No but seriously, three links to some random peoples' opinions, none of whom have any connection with this list afaik, without any other text comes off kind of... not great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Dec 6 19:59:43 2018 From: randy at psg.com (Randy Bush) Date: Thu, 06 Dec 2018 11:59:43 -0800 Subject: trace from behind tata noam In-Reply-To: References: Message-ID: thanks all. now i have too much data and not enough insight randy From contact at caglan.net Thu Dec 6 17:01:54 2018 From: contact at caglan.net (Dan Parrish) Date: Thu, 6 Dec 2018 11:01:54 -0600 Subject: used hardware reseller In-Reply-To: References: Message-ID: <33076b2d-e781-1675-c211-669de581caf5@caglan.net> be careful what you wish for... --dan On 12/5/2018 10:24 AM, Mehmet Akcin wrote: > Hi there > > I am looking to buy juniper qfx and some dwdm gear to be shipped > overseas (indonesia, thailand, colombia, chile...) > > I am looking to see if therr are any preferred hardware resellers > people would recommend? If you know a way to buy local that would be > fantastic otherwise shipping it is the way to go. > > Please contact me offlist > > Mehmet > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstogdill at hammercomm.com Thu Dec 6 17:28:48 2018 From: mstogdill at hammercomm.com (Mark Stogdill) Date: Thu, 6 Dec 2018 12:28:48 -0500 Subject: CLEC Lawyer - New Jersey In-Reply-To: References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> Message-ID: <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> Hi Anne, My contact there is Crystal Prais. Her contact information is below. CRYSTAL M. PRAIS | Associate cprais at scarincihollenbeck.com Direct Phone: 201-806-3381 | Direct Fax: 201-806-3482 Happy connecting! Mark > On Dec 6, 2018, at 11:52 AM, Anne P. Mitchell, Esq. wrote: > > > >> On Dec 6, 2018, at 9:37 AM, Mark Stogdill wrote: >> >> Scarinci & Hollenbeck. We have a NJ CLEC and they worked with us. > > Mark, do you have a direct contact there? I'd love to be put in touch with them to have the connection; I just joined the board of the Denver IX, and CLEC stuff is tangential to my own area of legal expertise, so it's always good to know a colleague in a related area. > > Thanks either way! > > Anne > > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at exospec.us Thu Dec 6 18:04:00 2018 From: tyler at exospec.us (Tyler Harden) Date: Thu, 6 Dec 2018 18:04:00 +0000 Subject: CLEC Lawyer - New Jersey In-Reply-To: <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> References: <7FEB2CDD-C0F8-4C5D-824A-EA20FF2B9617@hammercomm.com> <65E1DF24-B18C-4499-ADDC-836768E82D2B@hammercomm.com> <81D0C7C3-0C95-48B1-A99A-9D0F9681D9E1@isipp.com> Message-ID: We have been looking for a similar CLEC Lawyer for the Ohio area. I've exhausted all of my legal contacts and they had not a clue. Appreciate any help. Cheers, Tyler Harden President exospec / Warren Wireless -----Original Message----- From: NANOG On Behalf Of Anne P. Mitchell, Esq. Sent: Thursday, December 06, 2018 1:00 PM To: nanog list Subject: Re: CLEC Lawyer - New Jersey > Hi Anne, > > My contact there is Crystal Prais. Her contact information is below. > > CRYSTAL M. PRAIS | Associate > cprais at scarincihollenbeck.com > Direct Phone: 201-806-3381 | Direct Fax: 201-806-3482 > > Happy connecting! Thank you, Mark! Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From brad.raymo at gmail.com Thu Dec 6 21:32:38 2018 From: brad.raymo at gmail.com (Bradley Raymo) Date: Thu, 6 Dec 2018 16:32:38 -0500 Subject: Security Track @ NANOG 75 Call for Participation In-Reply-To: <20181129164101.394c8833@p50.localdomain> References: <20181129164101.394c8833@p50.localdomain> Message-ID: Dear NANOG Community, The Program Committee wanted to take a moment to clear up some confusion regarding the below email. The Committee votes as a group to accept or decline talk proposals, including tracks and tutorials. At this point, no proposed talks have been accepted for NANOG 75. Additionally, we would like to re-iterate that the Program Committee is currently soliciting talks from anyone that would like to present at NANOG 75. Talks can be submitted via the program committee tool at https://pc.nanog.org. Once you have submitted your talk, you will be assigned a shepherd from the Program Committee who will work with you through the entire process. If there are any questions or concerns regarding presenting at NANOG, please feel free to contact the Program Committee at pc at nanog.org. Kind Regards, Brad Raymo Program Committee Chair On Thu, Nov 29, 2018 at 5:46 PM John Kristoff wrote: > [ Apologies if you saw this elsewhere already - jtk ] > > Friends, colleagues, fellow operators, > > The network security track, formerly known as the ISP security BoF, > has plans to return at NANOG 75 in San Francisco February 18-20. I > will be your track facilitator. > > I have a small handful of topics I'm soliciting from some folks > directly, but options are good, and I may be missing something > important. If you haven't heard from me already, then I want to hear > your ideas or proposals. This is a good, casual place to go with > netsec related ideas, tools, or case studies. Here is an incomplete > list of relevant topics to stir your thoughts: > > * IRRs, BGPSEC, and RPKI > * DDoS attacks and mitigation > * Botnet case studies > * ISP incident response tools > * Network censorship and privacy > * Threat sharing frameworks > * Network equipment configuration/default BCPs > * Spoofing, amplification, reflection threats > * ...insert your idea here > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pratik.Lotia at charter.com Fri Dec 7 06:06:20 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 7 Dec 2018 06:06:20 +0000 Subject: Should ISP block child pornography? Message-ID: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. On one side we want the ISP to not do any kind of censorship or inspection of customer traffic (customers are paying for pipes – not for filtered pipes), on the other side morals/ethics come into play. Keep in mind that if an ISP is blocking it would mean that it is also logging the information (source IP) and law agencies might be wanting access to it. Wondering if any operator is actively doing it or has ever considered doing it? Thanks. With Gratitude, Pratik Lotia “Information is not knowledge.” E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mis at seiden.com Fri Dec 7 06:22:08 2018 From: mis at seiden.com (Mark Seiden) Date: Thu, 6 Dec 2018 22:22:08 -0800 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: where is this list of dirty domains? On Thu, Dec 6, 2018, 10:08 PM Lotia, Pratik M wrote: > Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) content? > Interpol has a ‘worst-of’ list which contains such domains and it wants > ISPs to block it. > > On one side we want the ISP to not do any kind of censorship or inspection > of customer traffic (customers are paying for pipes – not for filtered > pipes), on the other side morals/ethics come into play. Keep in mind that > if an ISP is blocking it would mean that it is also logging the information > (source IP) and law agencies might be wanting access to it. > > > > Wondering if any operator is actively doing it or has ever considered > doing it? > > > > Thanks. > > > > > > With Gratitude, > > > > *Pratik Lotia* > > > > “Information is not knowledge.” > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Fri Dec 7 06:28:53 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 07 Dec 2018 11:58:53 +0530 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <3C7B9491-D32C-4F02-ADA5-45C9B70D0A03@gmail.com> https://www.interpol.int/Crime-areas/Crimes-against-children/Access-blocking From: NANOG on behalf of Mark Seiden Date: Friday, 7 December 2018 at 11:54 AM To: "Lotia, Pratik M" Cc: "nanog at nanog.org" Subject: Re: Should ISP block child pornography? where is this list of dirty domains? On Thu, Dec 6, 2018, 10:08 PM Lotia, Pratik M wrote: Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mis at seiden.com Fri Dec 7 06:46:35 2018 From: mis at seiden.com (Mark Seiden) Date: Thu, 6 Dec 2018 22:46:35 -0800 Subject: Should ISP block child pornography? In-Reply-To: <3C7B9491-D32C-4F02-ADA5-45C9B70D0A03@gmail.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <3C7B9491-D32C-4F02-ADA5-45C9B70D0A03@gmail.com> Message-ID: thanks, suresh. what it seems to say is get in touch with the ncb in your country to sign an nda and get instructions. (but it's actually quite hard to figure out how to do that, no email address or phone numbers apparent for interpol dc) On Thu, Dec 6, 2018, 10:28 PM Suresh Ramasubramanian wrote: > > https://www.interpol.int/Crime-areas/Crimes-against-children/Access-blocking > > > > *From: *NANOG on behalf of Mark Seiden < > mis at seiden.com> > *Date: *Friday, 7 December 2018 at 11:54 AM > *To: *"Lotia, Pratik M" > *Cc: *"nanog at nanog.org" > *Subject: *Re: Should ISP block child pornography? > > > > where is this list of dirty domains? > > On Thu, Dec 6, 2018, 10:08 PM Lotia, Pratik M > wrote: > > Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) content? > Interpol has a ‘worst-of’ list which contains such domains and it wants > ISPs to block it. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Fri Dec 7 06:48:49 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 07 Dec 2018 12:18:49 +0530 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <3C7B9491-D32C-4F02-ADA5-45C9B70D0A03@gmail.com> Message-ID: In the USA, you need to contact NCMEC - http://www.missingkids.com/home or the FBI. From: Mark Seiden Date: Friday, 7 December 2018 at 12:16 PM To: Suresh Ramasubramanian Cc: "Lotia, Pratik M" , "nanog at nanog.org" Subject: Re: Should ISP block child pornography? thanks, suresh. what it seems to say is get in touch with the ncb in your country to sign an nda and get instructions. (but it's actually quite hard to figure out how to do that, no email address or phone numbers apparent for interpol dc) -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Fri Dec 7 07:16:29 2018 From: saku at ytti.fi (Saku Ytti) Date: Fri, 7 Dec 2018 09:16:29 +0200 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: On Fri, 7 Dec 2018 at 08:09, Lotia, Pratik M wrote: > Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. > > On one side we want the ISP to not do any kind of censorship or inspection of customer traffic (customers are paying for pipes – not for filtered pipes), on the other side morals/ethics come into play. Keep in mind that if an ISP is blocking it would mean that it is also logging the information (source IP) and law agencies might be wanting access to it. > > Wondering if any operator is actively doing it or has ever considered doing it? Some jurisdictions legally must, some legally cannot. It's very sensitive subject, with some reductio ad absurdum ghost hiding behind the corner. My thought is, if we know this data exists, and we know where it exists, why are we not following the data to find the people? It seems we're very good at putting leverage in AML/KYC across jurisdictions of arbitrary length, how come same tools don't seem to work here? If ISPs do start to block, voluntarily or involuntarily, are we removing incentives to fix the problem by hiding some of the symptoms? In my opinion leave the infrastructure alone, where ever the road may lead, removing the road won't remove the destination. Does the content create the culprits? Is there research into this? Are people with evolutionarily normal sexual appetites turned pedophiles after exposed to the material? -- ++ytti From Ryan.Hamel at quadranet.com Fri Dec 7 07:17:02 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 7 Dec 2018 07:17:02 +0000 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <3C7B9491-D32C-4F02-ADA5-45C9B70D0A03@gmail.com> Message-ID: When I receive a report, we follow our procedures with the Cyber Tip Line, and then immediately null route the IP address until the content is removed. From: NANOG On Behalf Of Suresh Ramasubramanian Sent: Thursday, December 06, 2018 10:49 PM To: Mark Seiden Cc: nanog at nanog.org Subject: Re: Should ISP block child pornography? In the USA, you need to contact NCMEC - http://www.missingkids.com/home or the FBI. From: Mark Seiden > Date: Friday, 7 December 2018 at 12:16 PM To: Suresh Ramasubramanian > Cc: "Lotia, Pratik M" >, "nanog at nanog.org" > Subject: Re: Should ISP block child pornography? thanks, suresh. what it seems to say is get in touch with the ncb in your country to sign an nda and get instructions. (but it's actually quite hard to figure out how to do that, no email address or phone numbers apparent for interpol dc) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Fri Dec 7 07:53:49 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 7 Dec 2018 02:53:49 -0500 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <23562.9997.816178.920975@gargle.gargle.HOWL> > Does the content create the culprits? Is there research into this? Are > people with evolutionarily normal sexual appetites turned pedophiles > after exposed to the material? I've helped the FBI get child pornographers arrested and I would do it again. But to answer your question the concern is for the children, they are being sexually abused. Consumers of child pornography are creating a market for it thus encouraging more production which requires more children be sexually abused. There's really no way around that. Splitting the hair of whether the actual perp paid for the material is irrelevant, they can let their lawyer argue that in court if they like but it's a weak defense (e.g., ad supported, same as paying, whatever.) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Fri Dec 7 09:14:16 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Dec 2018 01:14:16 -0800 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <249809A9-8DB1-46D3-AD8C-473B24DCCA90@delong.com> How is it that Interpol isn’t taking over/shutting down these domains in the DNS at the registry/registrar level? The GAC pushed hard for the provisions that allow them to do so and there’s a pretty clear (and quick) process for it. Owen > On Dec 6, 2018, at 22:06 , Lotia, Pratik M wrote: > > Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. > On one side we want the ISP to not do any kind of censorship or inspection of customer traffic (customers are paying for pipes – not for filtered pipes), on the other side morals/ethics come into play. Keep in mind that if an ISP is blocking it would mean that it is also logging the information (source IP) and law agencies might be wanting access to it. > > Wondering if any operator is actively doing it or has ever considered doing it? > > Thanks. > > > With Gratitude, > > Pratik Lotia > > “Information is not knowledge.” > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ymitsos at noc.grnet.gr Fri Dec 7 11:21:28 2018 From: ymitsos at noc.grnet.gr (Yannis Mitsos) Date: Fri, 7 Dec 2018 13:21:28 +0200 Subject: L3 Network topology in YANG In-Reply-To: References: <1760484f-2f82-ecd8-5dcd-be6110586c6e@noc.grnet.gr> Message-ID: <20181207112128.GP52962@panoramix> Hi Rob, On 13:53 Wed 05 Dec , Rob Shakir wrote: >Hi Yannis, > >I know that there are some folks using pyangbind with models that correspond to >topology including rfc8346, similarly, some folks are using goyang+ygot (where Would be nice to contact them, if possible, and exchange some experiences. Regards, y. >using Go) for dealing with their topology models in YANG. I'm not clear how far >these operations are along, but I've handled feature requests related to these >models in both. > >Cheers, >r. > > >On Mon, 19 Nov 2018 at 09:44 Yannis Mitsos wrote: > > All, > > I was wondering if there is any network operator who exposes > (dynamically?) its topology in YANG based on RFC8346 [1]. I understand > that for commercial operators and purposes, may not be of any > substantial value. > We are assessing some available tools[2],[3],[4] on how to achieve this > but we would like to know if there is any success story out there. > > Regards, > > Yannis > > [1] https://tools.ietf.org/html/rfc8346 > [2] https://github.com/robshakir/pyangbind > [3] https://github.com/YangModels/yang.git > [4] https://developer.cisco.com/site/ydk > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3379 bytes Desc: not available URL: From alejandroacostaalamo at gmail.com Fri Dec 7 11:52:16 2018 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Fri, 7 Dec 2018 08:52:16 -0300 Subject: Should ISP block child pornography? In-Reply-To: <249809A9-8DB1-46D3-AD8C-473B24DCCA90@delong.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <249809A9-8DB1-46D3-AD8C-473B24DCCA90@delong.com> Message-ID: <03c82b61-3d9e-f4f4-0fd0-2f63488906d0@gmail.com> Agree El 7/12/18 a las 06:14, Owen DeLong escribió: > How is it that Interpol isn’t taking over/shutting down these domains > in the DNS at the registry/registrar level? > > The GAC pushed hard for the provisions that allow them to do so and > there’s a pretty clear (and quick) process for it. > > Owen > > >> On Dec 6, 2018, at 22:06 , Lotia, Pratik M > > wrote: >> >> Hello all, was curious to know the community’s opinion on whether an >> ISP should block domains hosting CPE (child pornography exploitation) >> content? Interpol has a ‘worst-of’ list which contains such domains >> and it wants ISPs to block it. >> On one side we want the ISP to not do any kind of censorship or >> inspection of customer traffic (customers are paying for pipes – not >> for filtered pipes), on the other side morals/ethics come into play. >> Keep in mind that if an ISP is blocking it would mean that it is also >> logging the information (source IP) and law agencies might be wanting >> access to it. >>   >> Wondering if any operator is actively doing it or has ever considered >> doing it? >>   >> Thanks. >>   >>   >> With Gratitude, >> * * >> *Pratik Lotia*       >>   >> “Information is not knowledge.” >> The contents of this e-mail message and  >> any attachments are intended solely for the  >> addressee(s) and may contain confidential  >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you  >> in error, please immediately alert the sender >> by reply e-mail and then delete this message  >> and any attachments. If you are not the  >> intended recipient, you are notified that  >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment  >> is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Fri Dec 7 14:57:17 2018 From: john at essenz.com (John Von Essen) Date: Fri, 7 Dec 2018 09:57:17 -0500 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: I block stuff all the time (like ROKSO's DROP list). The only issue with blocking domains of CPE is I imagine those domains change all the time as they get shutdown, if you block the IP (from domain lookup) its likely that IP maybe be legitimate in the future. It should be stopped it at the DNS level, but even that has workarounds. I would think CPE is a violation of terms of "most" registrars. -John On 12/7/18 1:06 AM, Lotia, Pratik M wrote: > > Hello all, was curious to know the community’s opinion on whether an > ISP should block domains hosting CPE (child pornography exploitation) > content? Interpol has a ‘worst-of’ list which contains such domains > and it wants ISPs to block it. > > On one side we want the ISP to not do any kind of censorship or > inspection of customer traffic (customers are paying for pipes – not > for filtered pipes), on the other side morals/ethics come into play. > Keep in mind that if an ISP is blocking it would mean that it is also > logging the information (source IP) and law agencies might be wanting > access to it. > > Wondering if any operator is actively doing it or has ever considered > doing it? > > Thanks. > > With Gratitude, > > ** > > *Pratik Lotia* > > “Information is not knowledge.” > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lobna_gouda at hotmail.com Fri Dec 7 15:33:01 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Fri, 7 Dec 2018 15:33:01 +0000 Subject: Where you think the market/network will be heading Message-ID: Hello Networks, Might sound unprofessional, but seriously Wanted to get your views about upcoming technlogies or market. Things like virtualization, cloud services , automation and SDN models and its use cases have actually done some shift, no much gap between ISP and DC tech. For example things like SDWAN, EVPN, SR...etc will end classical MPLS this is if you do not want to perform your own scripted PCEP and will be used in ISP, enterprise and DC If you would like to provide a good career advise for someone willing to change, is working in designing datacenter (learning storage, Virtulaztion, cloud services, LB...etc) or working in a mid-size company that is looking for its own solutions type of this and you will utilize your own skills differently and honestly you do not know what you would expect or learn What would you choose and have anyone went through this route before? what is your experience/advise? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Dec 7 15:59:35 2018 From: matt at netfire.net (Matt Harris) Date: Fri, 7 Dec 2018 09:59:35 -0600 Subject: Where you think the market/network will be heading In-Reply-To: References: Message-ID: On Fri, Dec 7, 2018 at 9:33 AM lobna gouda wrote: > Hello Networks, > > Might sound unprofessional, but seriously Wanted to get your views about > upcoming technlogies or market. Things like virtualization, cloud > services , automation and SDN models and its use cases have actually done > some shift, no much gap between ISP and DC tech. For example things like > SDWAN, EVPN, SR...etc will end classical MPLS this is if you do not want to > perform your own scripted PCEP and will be used in ISP, enterprise and DC > > If you would like to provide a good career advise for someone willing to > change, is working in designing datacenter (learning storage, > Virtulaztion, cloud services, LB...etc) or working in a mid-size company > that is looking for its own solutions type of this and you will utilize > your own skills differently and honestly you do not know what you would > expect or learn > > What would you choose and have anyone went through this route before? what > is your experience/advise? > I think the network is moving more towards virtualized and whitebox platforms. Slowly but surely. If you look at how Juniper's virtual platforms - the vSRX and vMX (and I'd imagine vQFX though I haven't played with this myself) work, and at how they built the MX204 router hardware and software stack, I think that speaks to where things will be going over the next decade. Cisco's on board to at least some degree as well with the Nexus 1000v NX-OS platform. All of this coupled with the rise of the cloud - and not just AWS and Azure, but private in-house clouds and smaller public cloud providers running OpenStack or other products which integrate nearly with these virtualized platforms. Beyond the software and virtualized side, there's the hardware side and going beyond how Juniper built the MX204, you have a growing trend among large organizations to run white box hardware solutions which I suspect will eventually trickle down as well. There'll be plenty of fun toys to play with well into the future! ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Dec 7 16:47:39 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 7 Dec 2018 10:47:39 -0600 (CST) Subject: DirecTV Now Geolocation Contact In-Reply-To: <20180821141351.GA28252@dan.olp.net> References: <20180821141351.GA28252@dan.olp.net> Message-ID: <219452307.2640.1544201256475.JavaMail.mhammett@ThunderFuck> Did you get any resolution to this? I have a customer that has had their /21 since April of 2008. DirecTV Now is claiming the location is incorrect. I have gone through what few links there are on the old Cluepon site. https://web.archive.org/web/20130122055317/http://nanog.cluepon.net/index.php/GeoIP ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dan White" To: nanog at nanog.org Sent: Tuesday, August 21, 2018 9:13:51 AM Subject: DirecTV Now Geolocation Contact Are there any DirecTV Now contacts on-list? We are having geolocation trouble with a well established ip range. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Dec 7 17:46:05 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 7 Dec 2018 11:46:05 -0600 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <8A437DFD-D886-445D-9940-1917CF7EF3B4@gvtc.com> What is “ROKSO's DROP list” ? Aaron > On Dec 7, 2018, at 8:57 AM, John Von Essen wrote: > > ROKSO's DROP list From sethm at rollernet.us Fri Dec 7 17:48:33 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 7 Dec 2018 09:48:33 -0800 Subject: Should ISP block child pornography? In-Reply-To: <8A437DFD-D886-445D-9940-1917CF7EF3B4@gvtc.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <8A437DFD-D886-445D-9940-1917CF7EF3B4@gvtc.com> Message-ID: <11ecb3ea-41ee-534f-a275-e26796aac77b@rollernet.us> On 12/7/18 9:46 AM, Aaron1 wrote: > What is “ROKSO's DROP list” ? https://www.spamhaus.org/drop/ From cscora at apnic.net Fri Dec 7 18:03:29 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Dec 2018 04:03:29 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181207180329.31488C44B7@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 08 Dec, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 728472 Prefixes after maximum aggregation (per Origin AS): 280445 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 350812 Total ASes present in the Internet Routing Table: 62662 Prefixes per ASN: 11.63 Origin-only ASes present in the Internet Routing Table: 54096 Origin ASes announcing only one prefix: 23510 Transit ASes present in the Internet Routing Table: 8566 Transit-only ASes present in the Internet Routing Table: 254 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 35 Number of instances of unregistered ASNs: 35 Number of 32-bit ASNs allocated by the RIRs: 25157 Number of 32-bit ASNs visible in the Routing Table: 20374 Prefixes from 32-bit ASNs in the Routing Table: 87547 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 263 Number of addresses announced to Internet: 2837329313 Equivalent to 169 /8s, 30 /16s and 53 /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.1 Total number of prefixes smaller than registry allocations: 242825 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 199092 Total APNIC prefixes after maximum aggregation: 56746 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 196299 Unique aggregates announced from the APNIC address blocks: 80768 APNIC Region origin ASes present in the Internet Routing Table: 9281 APNIC Prefixes per ASN: 21.15 APNIC Region origin ASes announcing only one prefix: 2609 APNIC Region transit ASes present in the Internet Routing Table: 1383 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4278 Number of APNIC addresses announced to Internet: 768663936 Equivalent to 45 /8s, 208 /16s and 225 /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-139577 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: 215940 Total ARIN prefixes after maximum aggregation: 102700 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 215304 Unique aggregates announced from the ARIN address blocks: 103246 ARIN Region origin ASes present in the Internet Routing Table: 18310 ARIN Prefixes per ASN: 11.76 ARIN Region origin ASes announcing only one prefix: 6799 ARIN Region transit ASes present in the Internet Routing Table: 1826 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2516 Number of ARIN addresses announced to Internet: 1076960160 Equivalent to 64 /8s, 49 /16s and 27 /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, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 198612 Total RIPE prefixes after maximum aggregation: 94905 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 195001 Unique aggregates announced from the RIPE address blocks: 115616 RIPE Region origin ASes present in the Internet Routing Table: 25689 RIPE Prefixes per ASN: 7.59 RIPE Region origin ASes announcing only one prefix: 11494 RIPE Region transit ASes present in the Internet Routing Table: 3536 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7657 Number of RIPE addresses announced to Internet: 715823744 Equivalent to 42 /8s, 170 /16s and 154 /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: 94668 Total LACNIC prefixes after maximum aggregation: 21863 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 96052 Unique aggregates announced from the LACNIC address blocks: 41908 LACNIC Region origin ASes present in the Internet Routing Table: 7874 LACNIC Prefixes per ASN: 12.20 LACNIC Region origin ASes announcing only one prefix: 2187 LACNIC Region transit ASes present in the Internet Routing Table: 1486 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5421 Number of LACNIC addresses announced to Internet: 172834560 Equivalent to 10 /8s, 77 /16s and 63 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 20124 Total AfriNIC prefixes after maximum aggregation: 4201 AfriNIC Deaggregation factor: 4.79 Prefixes being announced from the AfriNIC address blocks: 25553 Unique aggregates announced from the AfriNIC address blocks: 9028 AfriNIC Region origin ASes present in the Internet Routing Table: 1231 AfriNIC Prefixes per ASN: 20.76 AfriNIC Region origin ASes announcing only one prefix: 421 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 502 Number of AfriNIC addresses announced to Internet: 102644992 Equivalent to 6 /8s, 30 /16s and 61 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4636 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4634 515 519 TPG-INTERNET-AP TPG Telecom Limited, AU 45899 2991 1716 113 VNPT-AS-VN VNPT Corp, VN 7552 2943 1150 88 VIETEL-AS-AP Viettel Group, VN 4766 2823 11130 771 KIXS-AS-KR Korea Telecom, KR 9829 2748 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2451 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2390 4907 31 CTTNET China TieTong Telecommunications 17974 2262 970 54 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2143 438 176 TATACOMM-AS TATA Communications formerl 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 6327 3507 1326 91 SHAW - Shaw Communications Inc., CA 11492 3478 224 616 CABLEONE - CABLE ONE, INC., US 22773 3302 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2608 5246 967 AMAZON-02 - Amazon.com, Inc., US 16625 2166 1211 1668 AKAMAI-AS - Akamai Technologies, Inc., 18566 2149 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2145 2748 534 CHARTER-20115 - Charter Communications, 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 30036 2084 349 133 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2055 5080 597 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5192 1618 134 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3032 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2588 563 1909 AKAMAI-ASN1, US 12389 2218 2220 622 ROSTELECOM-AS, RU 34984 2045 337 535 TELLCOM-AS, TR 9121 1820 1691 17 TTNET, TR 13188 1603 100 42 TRIOLAN, UA 8402 1294 544 17 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, 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 5455 3317 598 Uninet S.A. de C.V., MX 10620 3132 476 892 Telmex Colombia S.A., CO 11830 2678 371 71 Instituto Costarricense de Electricidad 6503 1662 449 54 Axtel, S.A.B. de C.V., MX 7303 1438 961 220 Telecom Argentina S.A., AR 28573 1187 2241 179 CLARO S.A., BR 6147 1121 377 29 Telefonica del Peru S.A.A., PE 3816 1022 510 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 943 145 69 Alestra, S. de R.L. de C.V., MX 13999 925 538 258 Mega Cable, S.A. 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 1169 394 29 LINKdotNET-AS, EG 37611 908 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 786 1411 44 ETISALAT-MISR, EG 24835 683 632 20 RAYA-AS, EG 8452 648 1728 15 TE-AS TE-AS, EG 29571 474 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 411 45 11 WANANCHI-, KE 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 5455 3317 598 Uninet S.A. de C.V., MX 12479 5192 1618 134 UNI2-AS, ES 4538 4636 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4634 515 519 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3507 1326 91 SHAW - Shaw Communications Inc., CA 11492 3478 224 616 CABLEONE - CABLE ONE, INC., US 22773 3302 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3132 476 892 Telmex Colombia S.A., CO 8551 3032 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 5192 5058 UNI2-AS, ES 4538 4636 4562 ERX-CERNET-BKB China Education and Research Net 7545 4634 4115 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3507 3416 SHAW - Shaw Communications Inc., CA 22773 3302 3127 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3032 2989 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 45899 2991 2878 VNPT-AS-VN VNPT Corp, VN 11492 3478 2862 CABLEONE - CABLE ONE, INC., US 7552 2943 2855 VIETEL-AS-AP Viettel Group, 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 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65599 UNALLOCATED 103.14.27.0/24 134813 CYBERCOMM-BD Cyber Communicati 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:12 /9:11 /10:36 /11:99 /12:291 /13:568 /14:1124 /15:1906 /16:13330 /17:7878 /18:13854 /19:25502 /20:39505 /21:46000 /22:90714 /23:74199 /24:411203 /25:819 /26:652 /27:631 /28:39 /29:20 /30:21 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4036 5192 UNI2-AS, ES 6327 3270 3507 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2765 3478 CABLEONE - CABLE ONE, INC., US 22773 2542 3302 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2488 3032 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2044 2149 MEGAPATH5-US - MegaPath Corporation, US 11830 2023 2678 Instituto Costarricense de Electricidad y Telec 30036 1833 2084 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1629 2:887 4:18 5:2719 6:43 7:1 8:1151 12:1875 13:300 14:1878 15:35 16:3 17:204 18:59 20:48 23:2537 24:2413 25:2 27:2539 31:2011 32:91 35:31 36:533 37:2967 38:1592 39:274 40:119 41:3156 42:730 43:1987 44:138 45:6303 46:3029 47:243 49:1323 50:1075 51:318 52:1104 54:362 55:1 56:6 57:41 58:1709 59:1074 60:462 61:2120 62:1946 63:1802 64:5067 65:2181 66:4780 67:2652 68:1155 69:3410 70:1148 71:602 72:2254 74:2714 75:400 76:527 77:1707 78:1744 79:2204 80:1610 81:1415 82:1041 83:823 84:1061 85:2144 86:555 87:1494 88:938 89:2420 90:211 91:6491 92:1261 93:2340 94:2385 95:3086 96:911 97:348 98:942 99:167 100:88 101:1160 102:315 103:19435 104:3554 105:243 106:899 107:1832 108:706 109:3442 110:1632 111:1832 112:1406 113:1333 114:1148 115:1709 116:1620 117:1892 118:2214 119:1691 120:1123 121:1022 122:2373 123:1650 124:1443 125:1954 128:1206 129:692 130:519 131:1643 132:712 133:193 134:1041 135:230 136:534 137:672 138:1940 139:764 140:568 141:759 142:799 143:1023 144:848 145:503 146:1246 147:774 148:1699 149:775 150:797 151:994 152:920 153:328 154:2235 155:971 156:1628 157:848 158:673 159:1896 160:1484 161:893 162:2649 163:765 164:1122 165:1595 166:455 167:1344 168:3154 169:869 170:4023 171:499 172:1061 173:2124 174:988 175:878 176:2204 177:4062 178:2521 179:1306 180:2091 181:2368 182:2618 183:1332 184:1149 185:14377 186:3656 187:2531 188:2983 189:2087 190:8309 191:1418 192:9946 193:6423 194:5281 195:4035 196:2974 197:1762 198:5684 199:5977 200:7450 201:5020 202:10208 203:10233 204:4623 205:3012 206:3273 207:3254 208:3937 209:4188 210:3901 211:2026 212:3085 213:2802 214:1069 215:53 216:6019 217:2186 218:871 219:579 220:1832 221:995 222:961 223:1407 End of report From maxtul at netassist.ua Fri Dec 7 18:48:02 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 7 Dec 2018 20:48:02 +0200 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> Hi All, we are fighting with censorship in our country. So I have something to say. First, censorship is not just "switch off this website and that webpage". No magic button exist. It is more complex, if you think as for while system. Initially, networks was build without systems (hardware and software) can block something. Yes, you may nullroute some IP with some site, but as the collateral damage you will block part of Cloudflare or Amazon, for example. So you have to buy and install additional equipment and software to do it a bit less painful. That's not so cheap, that should be planned, brought, installed, checked and personal should be learned. After that, your system will be capable to block some website for ~90% of your customers will not proactively avoid blocking. And for *NONE* who will, as CP addicts, terrorists, blackmarkets, gambling, porn and others do. Yep. Now you network is capable to censor something. You just maid the first step to the hell. What's next? Some people send you some websites to ban. This list with CP, Spamhaus DROP, some court orders, some semi-legal copyright protectors orders, some "we just want to block it" requests... And some list positions from time to time became outdated, so you need to clean it from time to time. Do not even expect people sent you the block request will send you unblock request, of course. Then, we have >6000 ISPs in our country - it is not possible to interact with all of them directly. So, you end up under a lot of papers, random interactions with random people and outdated and desyncronized blocking list. It will not work. Next, government realizes there should be one centralized blocking list and introduces it. Ok. Now we have censored Internet. THE SWITCH IS ON. In a very short time the number of organizations have permission to insert something in the list dramatically increases. Corruption rises, it becomes possible, and then becomes cheap to put your competitor's website into the list for some time. And of course, primary target of any censorship is the elections... What about CP and porn addicts, gamblers, killers, terrorists? Surprise, they are even more fine than at the beginning! Why? Because they learned VPN, TOR and have to use it! Investigators end up with TOR and VPN exit IP addresses from another countries instead of their home IPs. Hey. It is a very very bad and very very danger game. Avoid it. Goal of that game is to SWITCH ON that system BY ANY REASON. CP, war, gambling - any reason that will work. After the system will be switched on - in several months you will forget the initial reason. And will awake in another world. 07.12.18 08:06, Lotia, Pratik M пише: > Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) > content? Interpol has a ‘worst-of’ list which contains such domains and > it wants ISPs to block it. > > On one side we want the ISP to not do any kind of censorship or > inspection of customer traffic (customers are paying for pipes – not for > filtered pipes), on the other side morals/ethics come into play. Keep in > mind that if an ISP is blocking it would mean that it is also logging > the information (source IP) and law agencies might be wanting access to it. > >   > > Wondering if any operator is actively doing it or has ever considered > doing it? > >   > > Thanks. > >   > >   > > With Gratitude, > > * * > > *Pratik Lotia*       > >   > > “Information is not knowledge.” > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. From nanog at jack.fr.eu.org Fri Dec 7 19:14:12 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Fri, 7 Dec 2018 20:14:12 +0100 Subject: Should ISP block child pornography? In-Reply-To: <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> Message-ID: <5C0AC684.1010202@jack.fr.eu.org> Well said On 12/07/2018 07:48 PM, Max Tulyev wrote: > Hi All, > > we are fighting with censorship in our country. So I have something to say. > > First, censorship is not just "switch off this website and that > webpage". No magic button exist. It is more complex, if you think as for > while system. > > Initially, networks was build without systems (hardware and software) > can block something. > > Yes, you may nullroute some IP with some site, but as the collateral > damage you will block part of Cloudflare or Amazon, for example. So you > have to buy and install additional equipment and software to do it a bit > less painful. That's not so cheap, that should be planned, brought, > installed, checked and personal should be learned. After that, your > system will be capable to block some website for ~90% of your customers > will not proactively avoid blocking. And for *NONE* who will, as CP > addicts, terrorists, blackmarkets, gambling, porn and others do. > > Yep. Now you network is capable to censor something. You just maid the > first step to the hell. What's next? Some people send you some websites > to ban. This list with CP, Spamhaus DROP, some court orders, some > semi-legal copyright protectors orders, some "we just want to block it" > requests... And some list positions from time to time became outdated, > so you need to clean it from time to time. Do not even expect people > sent you the block request will send you unblock request, of course. > Then, we have >6000 ISPs in our country - it is not possible to interact > with all of them directly. > > So, you end up under a lot of papers, random interactions with random > people and outdated and desyncronized blocking list. It will not work. > > Next, government realizes there should be one centralized blocking list > and introduces it. > > Ok. Now we have censored Internet. THE SWITCH IS ON. > > In a very short time the number of organizations have permission to > insert something in the list dramatically increases. Corruption rises, > it becomes possible, and then becomes cheap to put your competitor's > website into the list for some time. And of course, primary target of > any censorship is the elections... > > What about CP and porn addicts, gamblers, killers, terrorists? Surprise, > they are even more fine than at the beginning! Why? Because they learned > VPN, TOR and have to use it! Investigators end up with TOR and VPN exit > IP addresses from another countries instead of their home IPs. > > Hey. It is a very very bad and very very danger game. Avoid it. > Goal of that game is to SWITCH ON that system BY ANY REASON. CP, war, > gambling - any reason that will work. After the system will be switched > on - in several months you will forget the initial reason. And will > awake in another world. > > 07.12.18 08:06, Lotia, Pratik M пише: >> Hello all, was curious to know the community’s opinion on whether an ISP >> should block domains hosting CPE (child pornography exploitation) >> content? Interpol has a ‘worst-of’ list which contains such domains and >> it wants ISPs to block it. >> >> On one side we want the ISP to not do any kind of censorship or >> inspection of customer traffic (customers are paying for pipes – not for >> filtered pipes), on the other side morals/ethics come into play. Keep in >> mind that if an ISP is blocking it would mean that it is also logging >> the information (source IP) and law agencies might be wanting access to it. >> >> >> >> Wondering if any operator is actively doing it or has ever considered >> doing it? >> >> >> >> Thanks. >> >> >> >> >> >> With Gratitude, >> >> * * >> >> *Pratik Lotia* >> >> >> >> “Information is not knowledge.” >> >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. From Pratik.Lotia at charter.com Fri Dec 7 19:16:10 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 7 Dec 2018 19:16:10 +0000 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <671E7818-6961-4E7D-87B6-480CC7510017@charter.com> >> The only issue with blocking domains of CPE is I imagine those domains change all the time as they get shutdown, if you block the IP >> (from domain lookup) its likely that IP maybe be legitimate in the future. The list would be updated daily/weekly. The ACLs would have to be updated accordingly – this can be automated. This way no stale entries are present. With Gratitude, Pratik Lotia From: NANOG on behalf of John Von Essen Date: Friday, December 7, 2018 at 08:59 To: "nanog at nanog.org" Subject: Re: Should ISP block child pornography? I block stuff all the time (like ROKSO's DROP list). The only issue with blocking domains of CPE is I imagine those domains change all the time as they get shutdown, if you block the IP (from domain lookup) its likely that IP maybe be legitimate in the future. It should be stopped it at the DNS level, but even that has workarounds. I would think CPE is a violation of terms of "most" registrars. -John On 12/7/18 1:06 AM, Lotia, Pratik M wrote: Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. On one side we want the ISP to not do any kind of censorship or inspection of customer traffic (customers are paying for pipes – not for filtered pipes), on the other side morals/ethics come into play. Keep in mind that if an ISP is blocking it would mean that it is also logging the information (source IP) and law agencies might be wanting access to it. Wondering if any operator is actively doing it or has ever considered doing it? Thanks. With Gratitude, Pratik Lotia “Information is not knowledge.” The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pratik.Lotia at charter.com Fri Dec 7 19:20:53 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 7 Dec 2018 19:20:53 +0000 Subject: Should ISP block child pornography? In-Reply-To: <8A437DFD-D886-445D-9940-1917CF7EF3B4@gvtc.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <8A437DFD-D886-445D-9940-1917CF7EF3B4@gvtc.com> Message-ID: <82B7C1C7-809C-494D-A7A1-EC45178AD6AA@charter.com> >>What is “ROKSO's DROP list” ? ROKSO: The Register of Known Spam Operations database is a depository of information and evidence on known persistent spam operations, assembled to assist service providers with customer vetting and the Infosec industry with Actor Attribution. Spamhaus (https://www.spamhaus.org) provides a 'DROP' list which is a list of domains which are hijacked or leased by professional spam operations. As per them this is Not a list of just 'suspicious' domains - they are 100% sure that these are bad domains and one should not peer with them or have a route to them. With Gratitude, Pratik Lotia “Information is not knowledge.” On 12/7/18, 11:47, "NANOG on behalf of Aaron1" wrote: What is “ROKSO's DROP list” ? Aaron > On Dec 7, 2018, at 8:57 AM, John Von Essen wrote: > > ROKSO's DROP list E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From Pratik.Lotia at charter.com Fri Dec 7 19:31:04 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 7 Dec 2018 19:31:04 +0000 Subject: Should ISP block child pornography? In-Reply-To: <5C0AC684.1010202@jack.fr.eu.org> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <5C0AC684.1010202@jack.fr.eu.org> Message-ID: Very well explained, Max! With Gratitude, Pratik Lotia “Information is not knowledge.” On 12/7/18, 13:16, "NANOG on behalf of nanog at jack.fr.eu.org" wrote: Well said On 12/07/2018 07:48 PM, Max Tulyev wrote: > Hi All, > > we are fighting with censorship in our country. So I have something to say. > > First, censorship is not just "switch off this website and that > webpage". No magic button exist. It is more complex, if you think as for > while system. > > Initially, networks was build without systems (hardware and software) > can block something. > > Yes, you may nullroute some IP with some site, but as the collateral > damage you will block part of Cloudflare or Amazon, for example. So you > have to buy and install additional equipment and software to do it a bit > less painful. That's not so cheap, that should be planned, brought, > installed, checked and personal should be learned. After that, your > system will be capable to block some website for ~90% of your customers > will not proactively avoid blocking. And for *NONE* who will, as CP > addicts, terrorists, blackmarkets, gambling, porn and others do. > > Yep. Now you network is capable to censor something. You just maid the > first step to the hell. What's next? Some people send you some websites > to ban. This list with CP, Spamhaus DROP, some court orders, some > semi-legal copyright protectors orders, some "we just want to block it" > requests... And some list positions from time to time became outdated, > so you need to clean it from time to time. Do not even expect people > sent you the block request will send you unblock request, of course. > Then, we have >6000 ISPs in our country - it is not possible to interact > with all of them directly. > > So, you end up under a lot of papers, random interactions with random > people and outdated and desyncronized blocking list. It will not work. > > Next, government realizes there should be one centralized blocking list > and introduces it. > > Ok. Now we have censored Internet. THE SWITCH IS ON. > > In a very short time the number of organizations have permission to > insert something in the list dramatically increases. Corruption rises, > it becomes possible, and then becomes cheap to put your competitor's > website into the list for some time. And of course, primary target of > any censorship is the elections... > > What about CP and porn addicts, gamblers, killers, terrorists? Surprise, > they are even more fine than at the beginning! Why? Because they learned > VPN, TOR and have to use it! Investigators end up with TOR and VPN exit > IP addresses from another countries instead of their home IPs. > > Hey. It is a very very bad and very very danger game. Avoid it. > Goal of that game is to SWITCH ON that system BY ANY REASON. CP, war, > gambling - any reason that will work. After the system will be switched > on - in several months you will forget the initial reason. And will > awake in another world. > > 07.12.18 08:06, Lotia, Pratik M пише: >> Hello all, was curious to know the community’s opinion on whether an ISP >> should block domains hosting CPE (child pornography exploitation) >> content? Interpol has a ‘worst-of’ list which contains such domains and >> it wants ISPs to block it. >> >> On one side we want the ISP to not do any kind of censorship or >> inspection of customer traffic (customers are paying for pipes – not for >> filtered pipes), on the other side morals/ethics come into play. Keep in >> mind that if an ISP is blocking it would mean that it is also logging >> the information (source IP) and law agencies might be wanting access to it. >> >> >> >> Wondering if any operator is actively doing it or has ever considered >> doing it? >> >> >> >> Thanks. >> >> >> >> >> >> With Gratitude, >> >> * * >> >> *Pratik Lotia* >> >> >> >> “Information is not knowledge.” >> >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From clinton.mielke at gmail.com Fri Dec 7 19:43:02 2018 From: clinton.mielke at gmail.com (cosmo) Date: Fri, 7 Dec 2018 11:43:02 -0800 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <5C0AC684.1010202@jack.fr.eu.org> Message-ID: I've done a bit of work in this space, wont elaborate ..... but here are some thoughts : * many less-engaged or new pedophiles may indeed search such content in the clear, however .... * the persistent abusers tend to form communities within TOR hidden services, making them difficult to find. Most are likely just consumers of the material, but many are producers (inc kidnappers) * some underground communities require that prospective members contribute new abuse imagery/videos in order to prove they are not law enforcement. Tragically this encourages abusers to abuse a family member * other communities have plenty of essays espousing the viewpoint that such behavior is quite natural, which does convince some to excuse their behavior. This content itself does have the ability to convert non-offenders to offenders, IMHO. - The following article discuss these communities and their underlying agendas. I'll warn you that you may need therapy after reading it ..... * http://www.cracked.com/personal-experiences-1760-5-things-i-learned-infiltrating-deep-web-child-molesters.html * Some of the content is indeed quite traumatic - it's as bad as they say it is, and many people working in this space have long-term psychological problems * While many of these communities hide in TOR, making it difficult to find the perpetrators, many of the images there actually link to images hosted in public-facing image-hosting servers. This means that the abusers access it through 3 hops through the proxy network instead of 6, for hidden servers. This means that indeed, the majority of people accessing that content on your network may be doing so from hotlinks posted to a hidden server somewhere. You may see them primarily being accessed via known TOR exit nodes. My recommendations : * First, reach out to NCMEC for guidance on filtering/logging * Second, Ive done a teensy bit of work for these guys at Thorn (Ashton Kutchers nonprofit). They have an interesting program that attempts to recognize people searching for abuse imagery, and redirects them to material urging them to seek psychological help for their problem. : https://www.wearethorn.org/deterrence-prevent-child-sexual-abuse-imagery/ On Fri, Dec 7, 2018 at 11:32 AM Lotia, Pratik M wrote: > Very well explained, Max! > > > With Gratitude, > Pratik Lotia > > “Information is not knowledge.” > > On 12/7/18, 13:16, "NANOG on behalf of nanog at jack.fr.eu.org" < > nanog-bounces at nanog.org on behalf of nanog at jack.fr.eu.org> wrote: > > Well said > > > On 12/07/2018 07:48 PM, Max Tulyev wrote: > > Hi All, > > > > we are fighting with censorship in our country. So I have something > to say. > > > > First, censorship is not just "switch off this website and that > > webpage". No magic button exist. It is more complex, if you think as > for > > while system. > > > > Initially, networks was build without systems (hardware and software) > > can block something. > > > > Yes, you may nullroute some IP with some site, but as the collateral > > damage you will block part of Cloudflare or Amazon, for example. So > you > > have to buy and install additional equipment and software to do it a > bit > > less painful. That's not so cheap, that should be planned, brought, > > installed, checked and personal should be learned. After that, your > > system will be capable to block some website for ~90% of your > customers > > will not proactively avoid blocking. And for *NONE* who will, as CP > > addicts, terrorists, blackmarkets, gambling, porn and others do. > > > > Yep. Now you network is capable to censor something. You just maid > the > > first step to the hell. What's next? Some people send you some > websites > > to ban. This list with CP, Spamhaus DROP, some court orders, some > > semi-legal copyright protectors orders, some "we just want to block > it" > > requests... And some list positions from time to time became > outdated, > > so you need to clean it from time to time. Do not even expect people > > sent you the block request will send you unblock request, of course. > > Then, we have >6000 ISPs in our country - it is not possible to > interact > > with all of them directly. > > > > So, you end up under a lot of papers, random interactions with random > > people and outdated and desyncronized blocking list. It will not > work. > > > > Next, government realizes there should be one centralized blocking > list > > and introduces it. > > > > Ok. Now we have censored Internet. THE SWITCH IS ON. > > > > In a very short time the number of organizations have permission to > > insert something in the list dramatically increases. Corruption > rises, > > it becomes possible, and then becomes cheap to put your competitor's > > website into the list for some time. And of course, primary target of > > any censorship is the elections... > > > > What about CP and porn addicts, gamblers, killers, terrorists? > Surprise, > > they are even more fine than at the beginning! Why? Because they > learned > > VPN, TOR and have to use it! Investigators end up with TOR and VPN > exit > > IP addresses from another countries instead of their home IPs. > > > > Hey. It is a very very bad and very very danger game. Avoid it. > > Goal of that game is to SWITCH ON that system BY ANY REASON. CP, war, > > gambling - any reason that will work. After the system will be > switched > > on - in several months you will forget the initial reason. And will > > awake in another world. > > > > 07.12.18 08:06, Lotia, Pratik M пише: > >> Hello all, was curious to know the community’s opinion on whether > an ISP > >> should block domains hosting CPE (child pornography exploitation) > >> content? Interpol has a ‘worst-of’ list which contains such domains > and > >> it wants ISPs to block it. > >> > >> On one side we want the ISP to not do any kind of censorship or > >> inspection of customer traffic (customers are paying for pipes – > not for > >> filtered pipes), on the other side morals/ethics come into play. > Keep in > >> mind that if an ISP is blocking it would mean that it is also > logging > >> the information (source IP) and law agencies might be wanting > access to it. > >> > >> > >> > >> Wondering if any operator is actively doing it or has ever > considered > >> doing it? > >> > >> > >> > >> Thanks. > >> > >> > >> > >> > >> > >> With Gratitude, > >> > >> * * > >> > >> *Pratik Lotia* > >> > >> > >> > >> “Information is not knowledge.” > >> > >> The contents of this e-mail message and > >> any attachments are intended solely for the > >> addressee(s) and may contain confidential > >> and/or legally privileged information. If you > >> are not the intended recipient of this message > >> or if this message has been addressed to you > >> in error, please immediately alert the sender > >> by reply e-mail and then delete this message > >> and any attachments. If you are not the > >> intended recipient, you are notified that > >> any use, dissemination, distribution, copying, > >> or storage of this message or any attachment > >> is strictly prohibited. > > > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Dec 7 19:54:32 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 7 Dec 2018 13:54:32 -0600 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <5C0AC684.1010202@jack.fr.eu.org> Message-ID: Makes we want to cry, so sad Aaron > On Dec 7, 2018, at 1:43 PM, cosmo wrote: > > I've done a bit of work in this space, wont elaborate ..... but here are some thoughts : > > * many less-engaged or new pedophiles may indeed search such content in the clear, however .... > * the persistent abusers tend to form communities within TOR hidden services, making them difficult to find. Most are likely just consumers of the material, but many are producers (inc kidnappers) > * some underground communities require that prospective members contribute new abuse imagery/videos in order to prove they are not law enforcement. Tragically this encourages abusers to abuse a family member > * other communities have plenty of essays espousing the viewpoint that such behavior is quite natural, which does convince some to excuse their behavior. This content itself does have the ability to convert non-offenders to offenders, IMHO. > - The following article discuss these communities and their underlying agendas. I'll warn you that you may need therapy after reading it ..... > * http://www.cracked.com/personal-experiences-1760-5-things-i-learned-infiltrating-deep-web-child-molesters.html > * Some of the content is indeed quite traumatic - it's as bad as they say it is, and many people working in this space have long-term psychological problems > * While many of these communities hide in TOR, making it difficult to find the perpetrators, many of the images there actually link to images hosted in public-facing image-hosting servers. This means that the abusers access it through 3 hops through the proxy network instead of 6, for hidden servers. > > This means that indeed, the majority of people accessing that content on your network may be doing so from hotlinks posted to a hidden server somewhere. You may see them primarily being accessed via known TOR exit nodes. > > My recommendations : > * First, reach out to NCMEC for guidance on filtering/logging > * Second, Ive done a teensy bit of work for these guys at Thorn (Ashton Kutchers nonprofit). They have an interesting program that attempts to recognize people searching for abuse imagery, and redirects them to material urging them to seek psychological help for their problem. : https://www.wearethorn.org/deterrence-prevent-child-sexual-abuse-imagery/ > > > > >> On Fri, Dec 7, 2018 at 11:32 AM Lotia, Pratik M wrote: >> Very well explained, Max! >> >> >> With Gratitude, >> Pratik Lotia >> >> “Information is not knowledge.” >> >> On 12/7/18, 13:16, "NANOG on behalf of nanog at jack.fr.eu.org" wrote: >> >> Well said >> >> >> On 12/07/2018 07:48 PM, Max Tulyev wrote: >> > Hi All, >> > >> > we are fighting with censorship in our country. So I have something to say. >> > >> > First, censorship is not just "switch off this website and that >> > webpage". No magic button exist. It is more complex, if you think as for >> > while system. >> > >> > Initially, networks was build without systems (hardware and software) >> > can block something. >> > >> > Yes, you may nullroute some IP with some site, but as the collateral >> > damage you will block part of Cloudflare or Amazon, for example. So you >> > have to buy and install additional equipment and software to do it a bit >> > less painful. That's not so cheap, that should be planned, brought, >> > installed, checked and personal should be learned. After that, your >> > system will be capable to block some website for ~90% of your customers >> > will not proactively avoid blocking. And for *NONE* who will, as CP >> > addicts, terrorists, blackmarkets, gambling, porn and others do. >> > >> > Yep. Now you network is capable to censor something. You just maid the >> > first step to the hell. What's next? Some people send you some websites >> > to ban. This list with CP, Spamhaus DROP, some court orders, some >> > semi-legal copyright protectors orders, some "we just want to block it" >> > requests... And some list positions from time to time became outdated, >> > so you need to clean it from time to time. Do not even expect people >> > sent you the block request will send you unblock request, of course. >> > Then, we have >6000 ISPs in our country - it is not possible to interact >> > with all of them directly. >> > >> > So, you end up under a lot of papers, random interactions with random >> > people and outdated and desyncronized blocking list. It will not work. >> > >> > Next, government realizes there should be one centralized blocking list >> > and introduces it. >> > >> > Ok. Now we have censored Internet. THE SWITCH IS ON. >> > >> > In a very short time the number of organizations have permission to >> > insert something in the list dramatically increases. Corruption rises, >> > it becomes possible, and then becomes cheap to put your competitor's >> > website into the list for some time. And of course, primary target of >> > any censorship is the elections... >> > >> > What about CP and porn addicts, gamblers, killers, terrorists? Surprise, >> > they are even more fine than at the beginning! Why? Because they learned >> > VPN, TOR and have to use it! Investigators end up with TOR and VPN exit >> > IP addresses from another countries instead of their home IPs. >> > >> > Hey. It is a very very bad and very very danger game. Avoid it. >> > Goal of that game is to SWITCH ON that system BY ANY REASON. CP, war, >> > gambling - any reason that will work. After the system will be switched >> > on - in several months you will forget the initial reason. And will >> > awake in another world. >> > >> > 07.12.18 08:06, Lotia, Pratik M пише: >> >> Hello all, was curious to know the community’s opinion on whether an ISP >> >> should block domains hosting CPE (child pornography exploitation) >> >> content? Interpol has a ‘worst-of’ list which contains such domains and >> >> it wants ISPs to block it. >> >> >> >> On one side we want the ISP to not do any kind of censorship or >> >> inspection of customer traffic (customers are paying for pipes – not for >> >> filtered pipes), on the other side morals/ethics come into play. Keep in >> >> mind that if an ISP is blocking it would mean that it is also logging >> >> the information (source IP) and law agencies might be wanting access to it. >> >> >> >> >> >> >> >> Wondering if any operator is actively doing it or has ever considered >> >> doing it? >> >> >> >> >> >> >> >> Thanks. >> >> >> >> >> >> >> >> >> >> >> >> With Gratitude, >> >> >> >> * * >> >> >> >> *Pratik Lotia* >> >> >> >> >> >> >> >> “Information is not knowledge.” >> >> >> >> The contents of this e-mail message and >> >> any attachments are intended solely for the >> >> addressee(s) and may contain confidential >> >> and/or legally privileged information. If you >> >> are not the intended recipient of this message >> >> or if this message has been addressed to you >> >> in error, please immediately alert the sender >> >> by reply e-mail and then delete this message >> >> and any attachments. If you are not the >> >> intended recipient, you are notified that >> >> any use, dissemination, distribution, copying, >> >> or storage of this message or any attachment >> >> is strictly prohibited. >> >> >> >> E-MAIL CONFIDENTIALITY NOTICE: >> The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton.mielke at gmail.com Fri Dec 7 20:18:29 2018 From: clinton.mielke at gmail.com (cosmo) Date: Fri, 7 Dec 2018 12:18:29 -0800 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <5C0AC684.1010202@jack.fr.eu.org> Message-ID: There's a reason that the subreddit for hidden services has this as a title ..... https://www.reddit.com/r/onions [image: image.png] On Fri, Dec 7, 2018 at 11:54 AM Aaron1 wrote: > Makes we want to cry, so sad > > Aaron > > On Dec 7, 2018, at 1:43 PM, cosmo wrote: > > I've done a bit of work in this space, wont elaborate ..... but here are > some thoughts : > > * many less-engaged or new pedophiles may indeed search such content in > the clear, however .... > * the persistent abusers tend to form communities within TOR hidden > services, making them difficult to find. Most are likely just consumers of > the material, but many are producers (inc kidnappers) > * some underground communities require that prospective members contribute > new abuse imagery/videos in order to prove they are not law enforcement. > Tragically this encourages abusers to abuse a family member > * other communities have plenty of essays espousing the viewpoint that > such behavior is quite natural, which does convince some to excuse their > behavior. This content itself does have the ability to convert > non-offenders to offenders, IMHO. > - The following article discuss these communities and their underlying > agendas. I'll warn you that you may need therapy after reading it ..... > * > http://www.cracked.com/personal-experiences-1760-5-things-i-learned-infiltrating-deep-web-child-molesters.html > * Some of the content is indeed quite traumatic - it's as bad as they say > it is, and many people working in this space have long-term psychological > problems > * While many of these communities hide in TOR, making it difficult to find > the perpetrators, many of the images there actually link to images hosted > in public-facing image-hosting servers. This means that the abusers access > it through 3 hops through the proxy network instead of 6, for hidden > servers. > > This means that indeed, the majority of people accessing that content on > your network may be doing so from hotlinks posted to a hidden server > somewhere. You may see them primarily being accessed via known TOR exit > nodes. > > My recommendations : > * First, reach out to NCMEC for guidance on filtering/logging > * Second, Ive done a teensy bit of work for these guys at Thorn (Ashton > Kutchers nonprofit). They have an interesting program that attempts to > recognize people searching for abuse imagery, and redirects them to > material urging them to seek psychological help for their problem. : > https://www.wearethorn.org/deterrence-prevent-child-sexual-abuse-imagery/ > > > > > On Fri, Dec 7, 2018 at 11:32 AM Lotia, Pratik M > wrote: > >> Very well explained, Max! >> >> >> With Gratitude, >> Pratik Lotia >> >> “Information is not knowledge.” >> >> On 12/7/18, 13:16, "NANOG on behalf of nanog at jack.fr.eu.org" < >> nanog-bounces at nanog.org on behalf of nanog at jack.fr.eu.org> wrote: >> >> Well said >> >> >> On 12/07/2018 07:48 PM, Max Tulyev wrote: >> > Hi All, >> > >> > we are fighting with censorship in our country. So I have something >> to say. >> > >> > First, censorship is not just "switch off this website and that >> > webpage". No magic button exist. It is more complex, if you think >> as for >> > while system. >> > >> > Initially, networks was build without systems (hardware and >> software) >> > can block something. >> > >> > Yes, you may nullroute some IP with some site, but as the collateral >> > damage you will block part of Cloudflare or Amazon, for example. So >> you >> > have to buy and install additional equipment and software to do it >> a bit >> > less painful. That's not so cheap, that should be planned, brought, >> > installed, checked and personal should be learned. After that, your >> > system will be capable to block some website for ~90% of your >> customers >> > will not proactively avoid blocking. And for *NONE* who will, as CP >> > addicts, terrorists, blackmarkets, gambling, porn and others do. >> > >> > Yep. Now you network is capable to censor something. You just maid >> the >> > first step to the hell. What's next? Some people send you some >> websites >> > to ban. This list with CP, Spamhaus DROP, some court orders, some >> > semi-legal copyright protectors orders, some "we just want to block >> it" >> > requests... And some list positions from time to time became >> outdated, >> > so you need to clean it from time to time. Do not even expect people >> > sent you the block request will send you unblock request, of course. >> > Then, we have >6000 ISPs in our country - it is not possible to >> interact >> > with all of them directly. >> > >> > So, you end up under a lot of papers, random interactions with >> random >> > people and outdated and desyncronized blocking list. It will not >> work. >> > >> > Next, government realizes there should be one centralized blocking >> list >> > and introduces it. >> > >> > Ok. Now we have censored Internet. THE SWITCH IS ON. >> > >> > In a very short time the number of organizations have permission to >> > insert something in the list dramatically increases. Corruption >> rises, >> > it becomes possible, and then becomes cheap to put your competitor's >> > website into the list for some time. And of course, primary target >> of >> > any censorship is the elections... >> > >> > What about CP and porn addicts, gamblers, killers, terrorists? >> Surprise, >> > they are even more fine than at the beginning! Why? Because they >> learned >> > VPN, TOR and have to use it! Investigators end up with TOR and VPN >> exit >> > IP addresses from another countries instead of their home IPs. >> > >> > Hey. It is a very very bad and very very danger game. Avoid it. >> > Goal of that game is to SWITCH ON that system BY ANY REASON. CP, >> war, >> > gambling - any reason that will work. After the system will be >> switched >> > on - in several months you will forget the initial reason. And will >> > awake in another world. >> > >> > 07.12.18 08:06, Lotia, Pratik M пише: >> >> Hello all, was curious to know the community’s opinion on whether >> an ISP >> >> should block domains hosting CPE (child pornography exploitation) >> >> content? Interpol has a ‘worst-of’ list which contains such >> domains and >> >> it wants ISPs to block it. >> >> >> >> On one side we want the ISP to not do any kind of censorship or >> >> inspection of customer traffic (customers are paying for pipes – >> not for >> >> filtered pipes), on the other side morals/ethics come into play. >> Keep in >> >> mind that if an ISP is blocking it would mean that it is also >> logging >> >> the information (source IP) and law agencies might be wanting >> access to it. >> >> >> >> >> >> >> >> Wondering if any operator is actively doing it or has ever >> considered >> >> doing it? >> >> >> >> >> >> >> >> Thanks. >> >> >> >> >> >> >> >> >> >> >> >> With Gratitude, >> >> >> >> * * >> >> >> >> *Pratik Lotia* >> >> >> >> >> >> >> >> “Information is not knowledge.” >> >> >> >> The contents of this e-mail message and >> >> any attachments are intended solely for the >> >> addressee(s) and may contain confidential >> >> and/or legally privileged information. If you >> >> are not the intended recipient of this message >> >> or if this message has been addressed to you >> >> in error, please immediately alert the sender >> >> by reply e-mail and then delete this message >> >> and any attachments. If you are not the >> >> intended recipient, you are notified that >> >> any use, dissemination, distribution, copying, >> >> or storage of this message or any attachment >> >> is strictly prohibited. >> >> >> >> E-MAIL CONFIDENTIALITY NOTICE: >> The contents of this e-mail message and any attachments are intended >> solely for the addressee(s) and may contain confidential and/or legally >> privileged information. If you are not the intended recipient of this >> message or if this message has been addressed to you in error, please >> immediately alert the sender by reply e-mail and then delete this message >> and any attachments. If you are not the intended recipient, you are >> notified that any use, dissemination, distribution, copying, or storage of >> this message or any attachment is strictly prohibited. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Fri Dec 7 20:38:23 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 7 Dec 2018 12:38:23 -0800 (PST) Subject: Monitoring service that has a human component? In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018, David H wrote: >Hey all, was curious if anyone knows of a website monitoring service >that has the option to incorporate a human component into the decision >and escalation tree? Isn't this merely a matter of escalation, since either alerts someone and it is just a matter of who, when and how often? The usual way of putting a human in the loop is for some events to create tickets to be triaged as staff has time, or all events get tickets but with some created in a lower priority queue w/o escalation and others in a high priority queue w/escalation. As a service though, sorry, no I've not seen such. /mark From hank at efes.iucc.ac.il Sat Dec 8 17:41:33 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 8 Dec 2018 19:41:33 +0200 Subject: Should ISP block child pornography? In-Reply-To: <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> Message-ID: <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> On 07/12/2018 20:48, Max Tulyev wrote: > Yes, you may nullroute some IP with some site, but as the collateral > damage you will block part of Cloudflare or Amazon, for example. So > you have to buy and install additional equipment and software to do it > a bit less painful. That's not so cheap, that should be planned, > brought, installed, checked and personal should be learned. After > that, your system will be capable to block some website for ~90% of > your customers will not proactively avoid blocking. And for *NONE* who > will, as CP addicts, terrorists, blackmarkets, gambling, porn and > others do. It is even more complex.  As you said filtering by IP address causing collateral damage to multi-host sites. But there are sites that use primarily IPv6 addresses so you need to filter  not only IPv4 but IPv6 as well. Also, sites change their IP address after they find out they are blocked, so you need a cron job which checks the IP addresses every 10-15 minutes and updates the filters (if you are willing to accept collateral damage). But when requested to block a FQDN, and filtering by IPv4 or IPv6 is not an option, again there are issues. You filter/block in your central DNS server, but what about the user at home who is using 8.8.8.8 or 9.9.9.9?  Or the corporate link to some Fortune 500 company with their own DNS servers that bypass the ISP servers.  So now you are in a situation where you have to divert/capture *all *udp/53 and tcp/53 and pass it to some scrubbing server which will only block the requests to the forbidden FQDNs.   Oh but wait, what about DoH? Governments that require ISPs to block "certain" sites have no clue what is required technologically to adhere to their demands. -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Sat Dec 8 18:31:03 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Sat, 8 Dec 2018 20:31:03 +0200 Subject: Should ISP block child pornography? In-Reply-To: <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> Message-ID: <746098dd-f749-e917-a6b8-b9cba8a13c58@netassist.ua> Correct. Also if you update IPs automatically by cron (and you have to automate it as lists only growing and growing) - blocked sites will troll the censorship system. They put IP of some government or critical (for example, VISA/Mastercard processing) sites in their blocked domain - and those victim sites will be blocked. This trolling is very popular in Russia, for example. 08.12.18 19:41, Hank Nussbacher пише: > On 07/12/2018 20:48, Max Tulyev wrote: >> Yes, you may nullroute some IP with some site, but as the collateral >> damage you will block part of Cloudflare or Amazon, for example. So >> you have to buy and install additional equipment and software to do it >> a bit less painful. That's not so cheap, that should be planned, >> brought, installed, checked and personal should be learned. After >> that, your system will be capable to block some website for ~90% of >> your customers will not proactively avoid blocking. And for *NONE* who >> will, as CP addicts, terrorists, blackmarkets, gambling, porn and >> others do. > It is even more complex.  As you said filtering by IP address causing > collateral damage to multi-host sites. > But there are sites that use primarily IPv6 addresses so you need to > filter  not only IPv4 but IPv6 as well. > Also, sites change their IP address after they find out they are > blocked, so you need a cron job which checks the IP addresses every > 10-15 minutes and updates the filters (if you are willing to accept > collateral damage). > > But when requested to block a FQDN, and filtering by IPv4 or IPv6 is not > an option, again there are issues. > > You filter/block in your central DNS server, but what about the user at > home who is using 8.8.8.8 or 9.9.9.9?  Or the corporate link to some > Fortune 500 company with their own DNS servers that bypass the ISP > servers.  So now you are in a situation where you have to divert/capture > *all *udp/53 and tcp/53 and pass it to some scrubbing server which will > only block the requests to the forbidden FQDNs.   Oh but wait, what > about DoH? > > Governments that require ISPs to block "certain" sites have no clue what > is required technologically to adhere to their demands. > > -Hank > > From merculiani at gmail.com Sat Dec 8 19:05:37 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Sat, 8 Dec 2018 14:05:37 -0500 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: As everyone has stated, blocking/filtering is a rabbit hole that we dare not go down or we set ourselves on the same path as oppressive regimes. For a similar situation that's far less depressing, see the numbers of threads about whether or not enterprises should block certain sites. This is an employee behavior problem, so it ought to fall under HR, not IT. But IT should be happy to provide data about what employees visit prohibited sites to HR so that discipline can be administered accordingly. Blocking doesn't stop the problem, it just forces employees to use more cell phone data. Personally, I prefer a policy of direct cooperation with authorities to put these folks where they should be, behind bars (and hopefully) with general population where they have to lie about why they're locked up out of fear of being torn apart for what they've been a part of and the children they've hurt. These animals have always found ways to satisfy their horrid urges. Before the internet was popular, they used sneakernets; we have the opportunity to use the data we have available to make the job of the authorities easier, and we should all strive to contribute to the elimination of child exploitation. If you think cooperation with authorities is also a rabbit hole or violates customer privacy, then know that your AUP should always include a special clause about this specific scenario and you don't "have" to cooperate if you don't think there is sufficient evidence, you can leave that up to a judge to decide. (In the USA at least). If your company refuses to cooperate, all you can do is politely remind them of the reprocussions of obstructing any investigation of this nature, like how when Uncle Sam brings a warrant to the table, it's usually WAY wider reaching than you could have imagined and almost always comes with a free gag order so you can't defend yourself to your customers. This could have unintended consequences the business. We'll never eliminate this problem, even if we shut down all TOR nodes and block all known endpoint IPs/domains. But we can help catch some of them and I take pride whenever I feel like I'm directly contributing to that. -Matt P.S. opening discussion about whether or not null routing on-sight is a good idea because yes, it makes the content inaccessible, which is the end goal, but it also alerts the offender that they've been caught and could initiate a scorched Earth strategy, thus impeeding any investigation by authorities. On Fri, Dec 7, 2018, 01:07 Lotia, Pratik M Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) content? > Interpol has a ‘worst-of’ list which contains such domains and it wants > ISPs to block it. > > On one side we want the ISP to not do any kind of censorship or inspection > of customer traffic (customers are paying for pipes – not for filtered > pipes), on the other side morals/ethics come into play. Keep in mind that > if an ISP is blocking it would mean that it is also logging the information > (source IP) and law agencies might be wanting access to it. > > > > Wondering if any operator is actively doing it or has ever considered > doing it? > > > > Thanks. > > > > > > With Gratitude, > > > > *Pratik Lotia* > > > > “Information is not knowledge.” > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Sat Dec 8 20:29:00 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 08 Dec 2018 13:29:00 -0700 Subject: Should ISP block child pornography? In-Reply-To: <746098dd-f749-e917-a6b8-b9cba8a13c58@netassist.ua> Message-ID: > They put IP of some government or critical (for example, > VISA/Mastercard processing) sites in their blocked > domain - and those victim sites will be blocked. > This trolling is very popular in Russia, for example. This should be very popular everywhere in the free world -- explaining why it is popular in Russia but not in non-free countries such as the United States of America ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From maxtul at netassist.ua Sat Dec 8 20:44:43 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Sat, 8 Dec 2018 22:44:43 +0200 Subject: Should ISP block child pornography? In-Reply-To: References: Message-ID: Because of USA does not have any block lists for example ;) 08.12.18 22:29, Keith Medcalf пише: > >> They put IP of some government or critical (for example, >> VISA/Mastercard processing) sites in their blocked >> domain - and those victim sites will be blocked. >> This trolling is very popular in Russia, for example. > > This should be very popular everywhere in the free world -- explaining why it is popular in Russia but not in non-free countries such as the United States of America ... > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > From bzs at theworld.com Sat Dec 8 22:41:13 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 8 Dec 2018 17:41:13 -0500 Subject: Should ISP block child pornography? In-Reply-To: <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> Message-ID: <23564.18569.614410.349483@gargle.gargle.HOWL> On December 8, 2018 at 19:41 hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > Governments that require ISPs to block "certain" sites have no clue what is > required technologically to adhere to their demands. Well that's certainly true. Australia just passed a law mandating decryption be made available to law enforcement simply ignoring the many technical explanations about why we don't know how to do this without compromising security entirely. I've often said if a judge in their court orders you to raise your left foot in the air you would be well-advised to lift that foot. If the judge orders you to also raise your right foot the judge doesn't have a problem, YOU have a problem. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Sat Dec 8 22:56:34 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 8 Dec 2018 17:56:34 -0500 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <23564.19490.621511.620941@gargle.gargle.HOWL> On December 8, 2018 at 14:05 merculiani at gmail.com (Matt Erculiani) wrote: > As everyone has stated, blocking/filtering is a rabbit hole that we dare not go > down or we set ourselves on the same path as oppressive regimes. > > For a similar situation that's far less depressing, see the numbers of thread Being ordered to block & filter criminals has been a norm for many years at least in the US. What needs to be responded to are the conditions of such orders. What's not acceptable are vague demands to block all child porn or "terrorist" content etc. That's just transferring the entire investigatory and enforcement problem to the folks who happen run the pipes. What we are seeing with facebook, twitter, etc is no less than the privatization of censorship and law enforcement by government fiat. And governments, even well-intentioned governments, are going to find that very attractive and addictive. Why not? Just write down some high-minded objectives like no more criminals allowed, all in favor say aye?, order passed! No budget, no plan, just threaten the people who run the infrastructure with serious penalties if they don't comply. This is potentially billions of dollars in law enforcement being transferred to infrastructure operators with no remuneration. It could easily run all but the absolute largest operators out of business. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Sun Dec 9 02:26:21 2018 From: owen at delong.com (Owen DeLong) Date: Sat, 8 Dec 2018 18:26:21 -0800 Subject: Should ISP block child pornography? In-Reply-To: <23564.18569.614410.349483@gargle.gargle.HOWL> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> <23564.18569.614410.349483@gargle.gargle.HOWL> Message-ID: Which is it… It’s being reported on NPR as “Australia required Apple and others to remove encryption protections from their devices.” That’s a massively different (and arguably even worse) outcome than “Australia is requiring Apple and others to provide decryption technology to law enforcement.” Owen > On Dec 8, 2018, at 14:41 , bzs at theworld.com wrote: > > > On December 8, 2018 at 19:41 hank at efes.iucc.ac.il (Hank Nussbacher) wrote: >> Governments that require ISPs to block "certain" sites have no clue what is >> required technologically to adhere to their demands. > > Well that's certainly true. > > Australia just passed a law mandating decryption be made available to > law enforcement simply ignoring the many technical explanations about > why we don't know how to do this without compromising security > entirely. > > I've often said if a judge in their court orders you to raise your > left foot in the air you would be well-advised to lift that foot. > > If the judge orders you to also raise your right foot the judge > doesn't have a problem, YOU have a problem. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Sun Dec 9 05:54:36 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sun, 9 Dec 2018 00:54:36 -0500 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> <23564.18569.614410.349483@gargle.gargle.HOWL> Message-ID: <23564.44572.960608.708694@gargle.gargle.HOWL> My impression is that like the judge in my previous note they did neither, or both, or all of the above. The law apparently just says if LE or a court of competent jurisdiction demands the contents of a device it has to be provided in a readable form and how that's accomplished is not their (the legislature's, LE's, et al's) problem to specify. Provide it or face consequences. So what you list are two possible solutions, remove encryption entirely or add a backdoor, or sniff and save everything submitted to the encryption routine, etc. I suppose the mischievous thought is whenever one receives such a demand send back a cleartext copy of the Australian Constitution, or the lyrics to the Sex Pistols' "God Save The Queen". How can they prove that's not the correct decryption without the encryption key? I suppose they can drag you in to testify under oath. Next Up: Australia's Legislature Outlaws Cancer! On December 8, 2018 at 18:26 owen at delong.com (Owen DeLong) wrote: > Which is it… > > It’s being reported on NPR as “Australia required Apple and others to remove encryption protections from their devices.” > > That’s a massively different (and arguably even worse) outcome than “Australia is requiring Apple and others to provide > decryption technology to law enforcement.” > > Owen > > > > On Dec 8, 2018, at 14:41 , bzs at theworld.com wrote: > > > > > > On December 8, 2018 at 19:41 hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > >> Governments that require ISPs to block "certain" sites have no clue what is > >> required technologically to adhere to their demands. > > > > Well that's certainly true. > > > > Australia just passed a law mandating decryption be made available to > > law enforcement simply ignoring the many technical explanations about > > why we don't know how to do this without compromising security > > entirely. > > > > I've often said if a judge in their court orders you to raise your > > left foot in the air you would be well-advised to lift that foot. > > > > If the judge orders you to also raise your right foot the judge > > doesn't have a problem, YOU have a problem. > > > > -- > > -Barry Shein > > > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > > The World: Since 1989 | A Public Information Utility | *oo* > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mpalmer at hezmatt.org Sun Dec 9 08:32:31 2018 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 9 Dec 2018 19:32:31 +1100 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <852aa696-2311-6c37-30e0-9640b8d65095@netassist.ua> <772ce9cd-fee9-4120-0c4d-16ad777423ef@efes.iucc.ac.il> <23564.18569.614410.349483@gargle.gargle.HOWL> Message-ID: <20181209083231.5frlrcoooyz47jwe@hezmatt.org> On Sat, Dec 08, 2018 at 06:26:21PM -0800, Owen DeLong wrote: > Which is it… > > It’s being reported on NPR as “Australia required Apple and others to > remove encryption protections from their devices.” > > That’s a massively different (and arguably even worse) outcome than > “Australia is requiring Apple and others to provide decryption technology > to law enforcement.” Part of the problem is... nobody really knows. There's very little meaningful oversight or judicial review of the whole system, and the law is *very* badly written, vague and without any clear guidance as to what is *actually* required. It doesn't even define things like "systemic weakness", which is the standard by which a required change is judged when determining whether it is within the scope of the law: anything which doesn't introduce a "systemic weakness" is a-OK. I'd say lawyers are going to make a fortune out of arguing this, except as I said, there's very little judicial oversight. Someone who is asked to do something which they think introduces a systemic weakness is basically SOL if the Attorney General and Communications Minister disagree. - Matt From mysidia at gmail.com Sun Dec 9 21:19:58 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 9 Dec 2018 15:19:58 -0600 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: On Fri, Dec 7, 2018 at 12:08 AM Lotia, Pratik M wrote: > Hello all, was curious to know the community’s opinion on whether an ISP should block > domains hosting CPE (child pornography exploitation) content? "Whether an ISP should block" ?! Probably not in most cases, except may be required in some jurisdictions mostly outside our region that are under authoritarian regime requiring ISPs block any resource banned at the whim of any blanket order from their executive (without due process); this is within the same vein as a phone company hearing a rumor that a certain payphone is being used for illegal activity and banning all calls from their customers to/from the number, under the presumption that _all_ calls from that phone are for criminal acts. Assuming: said hosting IP address is on a remote network: the ISP does not provide authoritative name service for that domain, and the customer accesses the resource over the network not through a cache or application proxy/other service provided by the ISP ---- the customer expects their ISP merely routes packets and does not participate in content, and an ISP deliberately interfering with expected connectivity jeapordizes stability of the network and the ISP's business relationship with their customers; the best possible affect on the ISP is neutral. Notable exception is emergencies where blocking an IP address or domain actually stops behavior such as DoS that directly disrupts the network, and blocking mitigates a negative affect on the network. For example, let's say we receive a report that www.twitter.com[104.244.42.65] hosts CPE. In that example, the report should be sent to law enforcement and Twitter: no action by anyone else should be required UNLESS Law Enforcement produces to the public a court order to disconnect/block Twitter's communication services, that would normally come after a hearing, and same principle applies regardless of if the domain name is a top1000 domain or not. If each ISP wants to be extra helpful, then perhaps they would like to log all their traffic to Twitter (in that example) and forward to law enforcement as suspected CPE trafficking activity -- although that is a risky invasion of customer privacy; at least reporting suspected potential of access to CPE doesn't deliberately lobomitze IPs from the network or disrupt traffic: not all of which traffic is necessarily CPE-related. In case the ISP oversteps and blocks Twitter traffic that includes legitimate non-CPE traffic (It may even affect e-mail traffic where people are communicating with the site to try to identify the CPE for removal); the ISP may face a loss of subscribers, and in that example Twitter would hopefully pursue various lawsuits or regulatory complaints against the ISPs blocking their IPs for deliberately creating an unreasonable disruption to the network. Possible negatives for the ISP are the risk of those repercussions PLUS the ongoing maintenance costs, personnel time, and other resources required for the ISP to maintain the blocking policy -- and service the extra blocklist, any removals or exceptions needed --- helpdesk hours for all the additional customer complaints that will occur; potential loss of good will and negative reputational affects on the ISP. It begins to seem fairly difficult to business justify the policy and likely fiscally irresponsible for an ISP to start opening this can of worms. > On one side we want the ISP to not do any kind of censorship or inspection of customer traffic [snip] Blocking domains or IP resources is not MERELY censorship. Censorship, which is itself far less objectionable: is selective blocking or removing content, for example, redacting a chapter from a book. Blocking domains or IPs is disconnecting infrastructure, for example: seeking to block twitter due to alleged CPE has an impact that affects much more than the CPE --- its like blocking an entire publisher; it doesn't matter they have printed mostly books that don't contain the content you've objected to - since you (ISPs) lack a censorship system --- censorship is not even an option, and the measures you're talking about are much more drastic than censoring content. Also, when the domain holder eventually responds and works with law enforcement to remove the found example of CPE, the domain block does not go away on its own -- therefore evidencing it is MUCH more than censorship. Furthermore, if the domain is then unblocked any other examples of CPE that had been overlooked (not detected by anybody yet) may become accessible again. Its fair to say a domain block is not technically related to content at all --- its in effect an "Independent ban" of access to a generic host identifier registered to a remote network. (Generic host identifiers aren't content, don't refer to content, and don't have a 1:1 relationship to content) > Pratik Lotia -- -JH From jhellenthal at dataix.net Sun Dec 9 22:23:44 2018 From: jhellenthal at dataix.net (J. Hellenthal) Date: Sun, 9 Dec 2018 16:23:44 -0600 Subject: Should ISP block child pornography? In-Reply-To: References: Message-ID: <20181209222344.759BE36A62F2@DataIX.net> Makes complete! sense \o/ #MoreKnowledgeKneeded On Sat, Dec 08, 2018 at 10:44:43PM +0200, Max Tulyev wrote: > Because of USA does not have any block lists for example ;) > > 08.12.18 22:29, Keith Medcalf пише: > > > >> They put IP of some government or critical (for example, > >> VISA/Mastercard processing) sites in their blocked > >> domain - and those victim sites will be blocked. > >> This trolling is very popular in Russia, for example. > > > > This should be very popular everywhere in the free world -- explaining why it is popular in Russia but not in non-free countries such as the United States of America ... > > > > --- > > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > > > > > -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: not available URL: From sean at donelan.com Mon Dec 10 23:36:48 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 10 Dec 2018 18:36:48 -0500 (EST) Subject: FCC Seeks Comment on Improving Wireless Network Resiliency Message-ID: This one is a chuckle. Wireless providers that want to keep their network outage information secret from the public and their customers want better details and coordination from their backhaul suppliers, which keep their network outage information secret from the public and their customers. PS Docket No. 11-60 Comment Date: January 9, 2019 Reply Date: January 24, 2019 This Public Notice is the first in a series that solicits input on the efficacy of the Wireless Resiliency Cooperative Framework (Framework). The Framework is a voluntary wireless industry commitment to promote resilient wireless communications and situational awareness during disasters. [...] A. Best Practices and Restoration Challenges [...] B. Coordination and Information-Sharing [...] C. Expanding the Scope of the Framework [...] https://docs.fcc.gov/public/attachments/DA-18-1238A1.pdf From shannon at more.net Tue Dec 11 15:31:38 2018 From: shannon at more.net (Spurling, Shannon) Date: Tue, 11 Dec 2018 15:31:38 +0000 Subject: Security issues based on post RIR allocation rules Message-ID: <1077025609d14c6fbbe720998ad4b703@more.net> Hey, I lurk a bit, and try to stay out of stuff if I can, but I've had a bout of problems that appear to have a common source. I work in the Educational networking area, and a lot of our members are pre-RIR formation internet users. They have IP ranges that were allocated from the 150/8 through 170/8 blocks. Unfortunately, a bunch of those are part of the legacy ranges handled by APNIC and AFRINIC. Here in the US, mention of either of those makes security people have dreams of Nigerian princes and Korean/Chinese hackers. Don't get me wrong, these are long term US based governmental and educational institutions. Bonified, accredited institutions. When I call a health care organization, or a web hosting provider, the first thing I get is that they think we are trying to pull one over on them and all these ranges must be in Africa or Asia. I show them the ARIN information for the specific /16, and sometimes I can make some headway. Sometimes there's no convincing them. This issue appears to be getting worse over time, so I was wondering if some misguided organization or group is going around pressing for the rules that are triggering these issues? Is there a public information forum that might be able to educate security administrators to not cut off wide swaths of the US internet from taking advantage of their products and services? It's very frustrating Thanks Shannon Spurling shannon at more.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Thu Dec 6 23:05:00 2018 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 7 Dec 2018 10:05:00 +1100 Subject: Monitoring service that has a human component? In-Reply-To: References: Message-ID: Hi David - Just a bit of insight from my own experience: Common issues when monitoring (and the associated escalation processes) don't work and similar issues are seen as you described: - Inconsistent HTTP response codes across services and service layers (nginx vs the backend tomcat), means you can't use them properly. - Monitoring on arbitrary metrics (90% of something) as opposed to metrics linked to an actual outcome (response times for example). - No runbook in place (engineer to change some setting to switch on/off maintenance mode). - No central view of what engineer is doing what to which systems. Some fairly simple example of when I've seen things work pretty well: Organisation uses HTTP code monitoring, alerting on 5xx but not 503. Services configured (and tested!) to return other, specific 5xx errors, but keep 503 as a 'known and expected maintenance' mode. Runbook in place to let other engineers know what's happening (slack message for example) and then maintenance page on the reverse proxy. Monitor and report on the common 90% metrics (disk space, memory) but no alerts. Don't fill up the disk with logs, only to delete them and let it fill up again.. :) Remove all non-actionable alerts. Of course a good solution could be to implement a rolling-upgrade / ha maintenance strategy, but in reality (depending on how ancient the app is) this can be quite hard. ps. This is a really good read: https://landing.google.com/sre/sre-book/toc/index.html Cheers Heath On Thu, Dec 6, 2018 at 9:03 AM David H wrote: > Hey all, was curious if anyone knows of a website monitoring service that > has the option to incorporate a human component into the decision and > escalation tree? I’m trying to help a customer find a way around false > positives bogging down their NOC staff, by having a human determine the > difference between a real error, desired (but different) content, or > something in between like “Hey it’s 3am and we’ve taken our website offline > for maintenance, we’ll be back up by 6am.” Automated systems tend to only > know if test A, or steps A through C, are failing, then this is ‘down’ and > do my preconfigured thing, but that ends up needlessly taking NOC time if > the customer themselves is performing work on their own site, or just > changed it and whatever content was being watched, is now gone. So, the > goal would be to have the end user be the first point of contact if it > looks like more of a customer-side issue. If they can’t be reached to > confirm, THEN contact NOC, and unlike email alerts, keep contacting until a > human acknowledges receipt of the alert. > > > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at bogle.se Fri Dec 7 03:18:46 2018 From: nick at bogle.se (Nick Bogle) Date: Thu, 6 Dec 2018 19:18:46 -0800 Subject: A few GPON questions... Message-ID: Hello fellow NANOG members :) Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. Feel free to contact me offlist if you have any pertinent info that you don't want on the list. Thanks, Nick Bogle nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoofer-info at caida.org Sat Dec 8 18:00:05 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Sat, 8 Dec 2018 10:00:05 -0800 Subject: Spoofer Report for NANOG for Nov 2018 Message-ID: <201812081800.wB8I05RP099085@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 Nov 2018: ASN Name Fixed-By 396238 FAIRLAWNGIG-NET 2018-11-26 6461 ZAYO-6461 2018-11-27 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Nov 2018: ASN Name First-Spoofed Last-Spoofed 54825 PACKET 2016-04-15 2018-11-15 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-11-29 6128 CABLE-NET-1 2016-09-03 2018-11-28 20412 CLARITY-TELECOM 2016-09-30 2018-11-28 6181 FUSE-NET 2016-10-10 2018-11-30 15305 SYRINGANETWORKS 2016-10-21 2018-11-24 25787 ROWE-NETWORKS 2016-10-21 2018-11-26 174 COGENT-174 2016-10-21 2018-11-20 31857 PRIORITY-TERABIT 2016-10-25 2018-11-30 30341 SCTA-ASN 2016-10-31 2018-11-26 32440 LONI 2016-11-03 2018-11-26 33182 DimeNOC 2016-11-08 2018-11-30 12083 WOW-INTERNET 2016-11-09 2018-11-30 3549 LVLT-3549 2016-11-16 2018-11-29 21832 KELLINCOM-1 2017-02-03 2018-11-24 7122 MTS-ASN 2017-05-16 2018-11-09 6461 ZAYO-6461 2017-06-21 2018-11-30 63296 AMARILLO-WIRELESS 2017-09-01 2018-11-27 7233 YAHOO-US 2017-09-07 2018-11-27 33523 ROWANUNIVERSITY 2017-10-29 2018-11-26 546 PARSONS-PGS-1 2017-11-20 2018-11-29 12222 AKAMAI 2018-02-14 2018-11-29 29384 Qatar-Foundation 2018-03-08 2018-11-27 23148 TERRENAP 2018-03-15 2018-11-27 4201 ORST 2018-04-19 2018-11-26 11827 WSU 2018-04-19 2018-11-26 35911 BNQ-1 2018-06-06 2018-11-29 225 VIRGINIA 2018-06-18 2018-11-26 40911 L2NC 2018-08-31 2018-11-01 2381 WISCNET1 2018-09-04 2018-11-28 54804 CSMIII-BUNKIELA 2018-09-15 2018-11-26 33452 RW 2018-09-19 2018-11-29 20448 VPNTRANET-LLC 2018-09-20 2018-11-28 11996 LOBOIS 2018-09-24 2018-11-26 14031 SCXY 2018-10-18 2018-11-10 19919 VSW 2018-10-23 2018-11-26 36375 UMICH-AS-5 2018-11-13 2018-11-13 13825 TROYCABLE-NET 2018-11-21 2018-11-21 32329 MONKEYBRAINS 2018-11-28 2018-11-28 393422 NEWVISIONS-CNY 2018-11-28 2018-11-28 33363 BHN-TAMPA 2018-11-29 2018-11-29 54483 CALIFORNIA-INTERNET-SOLUTIONS 2018-11-30 2018-11-30 22282 COSMO-MAIN 2018-11-30 2018-11-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 nick at bogle.se Sun Dec 9 05:54:56 2018 From: nick at bogle.se (Nick Bogle) Date: Sat, 8 Dec 2018 21:54:56 -0800 Subject: Enterprise GPON / Zhone Questions Message-ID: Hello fellow NANOG members :) Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. -Is anyone familiar with Zhone CLI? The apparent lack of any "show" configuration commands is infuriating. Feel free to contact me offlist if you have any pertinent info that you don't want on the list. Thanks, Nick Bogle nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From neuro at well.com Sun Dec 9 13:48:29 2018 From: neuro at well.com (William Anderson) Date: Sun, 9 Dec 2018 13:48:29 +0000 Subject: Should ISP block child pornography? In-Reply-To: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M wrote: > Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) content? > Interpol has a ‘worst-of’ list which contains such domains and it wants > ISPs to block it. > This already happens in the UK, and has done for years. https://en.wikipedia.org/wiki/Child_abuse_image_content_list -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From CGross at ninestarconnect.com Tue Dec 11 15:50:58 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Tue, 11 Dec 2018 15:50:58 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: How to deploy with Zhone is to put it in the garbage. I have more than enough horror stories from the provider side of things and enough of their TAC literally screaming at me because I called out of regular hours how my problems are physical fiber issues when it never is. They’ve also caused an 18 hour outage “Just trying to do some quick database cleanup” which worked, if you count wiping it as cleaning. Their GUI for ZMS is awful and their TAC doesn’t even know how to use it. It’s effectively a dead product. Their #1 issue has always been their support but nothing ever seems to improve and I saw a lot of support managers keep rotating in and out while their actual engineers ever changed back when I paid attention. From: NANOG On Behalf Of Nick Bogle Sent: Thursday, December 06, 2018 10:19 PM To: nanog at nanog.org Subject: A few GPON questions... Hello fellow NANOG members :) Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. Feel free to contact me offlist if you have any pertinent info that you don't want on the list. Thanks, Nick Bogle nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Dec 11 16:32:34 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 11 Dec 2018 08:32:34 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. -Ben. AS15206 > On Dec 6, 2018, at 7:18 PM, Nick Bogle wrote: > > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. > > Feel free to contact me offlist if you have any pertinent info that you don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at corp.crocker.com Tue Dec 11 16:39:36 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Tue, 11 Dec 2018 16:39:36 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: This, Rip it out Sorry this isn’t what you want to hear. 3rd party optics *may* work but when they don’t Zhone support will not help you. I recommend Zhone to my competitors. From: NANOG on behalf of Ben Cannon Date: Tuesday, December 11, 2018 at 11:33 AM To: Nick Bogle Cc: "nanog at nanog.org" Subject: Re: A few GPON questions... Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. -Ben. AS15206 On Dec 6, 2018, at 7:18 PM, Nick Bogle > wrote: Hello fellow NANOG members :) Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. Feel free to contact me offlist if you have any pertinent info that you don't want on the list. Thanks, Nick Bogle nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Tue Dec 11 16:48:21 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 11 Dec 2018 16:48:21 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: <1544546901.1820233.1606024040.14141123@webmail.messagingengine.com> The first question to ask yourself is: Why does this need to be GPON? The primary advantage of GPON is that it's *passive* (on the distribution side, at least) - this makes it ideal for building networks where most of your infrastructure located in places that getting power is infeasible: for instance, common residential fibre networks where most of your infrastructure lives on unpowered poles or in ducts/chambers. I have not yet come across a network closet which doesn't have provisions for power: If this is a small-to-medium sized campus network you'd be better served by running ordinary optical ethernet and dropping switches where you need to aggregate capacity. GPON is a rabbit hole that you do not want to go down, if you can feasibly avoid it: Ordinary ethernet is simply easier. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Tue Dec 11 16:50:04 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 11 Dec 2018 11:50:04 -0500 Subject: A few GPON questions... In-Reply-To: References: Message-ID: On 12/6/18 10:18 PM, Nick Bogle wrote: > > -We would like to consider use of 3rd party GPON B+ Optics on the > linecards to add redundancy to the splitter (as the cost of 1st party > are too high). Does anyone have experience with 3rd party > vendors/compatibility/stability issues? We were told they theoretically > should work and just throw a log event, but it hasn't been tested. If > so, what vendors would you recommend? So far all we've really seen are > Ubiquiti and Fiberstore optics. I mean, it'll probably work, but considering the extra requirements placed on PON optics and the relatively low cost of them compared to the rest of the system, I'd be inclined to stick with either ones sold by your vendor or at least buying something they re-label from an authorized distributor of the OEM. > > -As GPON is a standard itself, I'm aware interoperability between OLT > and ONT vendors is heavily limited.. Does anyone have any experience > using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a > different model OLT? I've heard word that Zhone ONT's may be able to > work with Nokia OLT's but it's technically not supported. Yeah, good luck with that. There's some limited degree of interoperability, but you'll often lose management features, at minimum. Some GPON OLT vendors do have a limited list of "qualified" 3rd party ONTs that they maintain for when their 1st-party ones don't fit the bill. Stick to 1st-party when you can and drop to "qualified" 3rd party ones if you absolutely have to. Anything else is going to be a support and maintenance nightmare. > > -We've already experienced some pretty big stability issues (have > replaced 1 line card 5 times..), our contractor is saying it's just > because we were a pretty early adopter of this line and that they've > fixed it and fixed internal policies to add additional QA and testing > before shipping to customers. Does anyone have any experience with > working with Zhone and their overall stability of components? Um, GPON is well established in the field. If you've got stability issues, letting your vendor blame it on being an "early adopter" is total BS. Now if you were deploying NG-PON2 or something, I'd maybe, MAYBE let it slide as long as they gave me a good support contact. > > - Any other thoughts/gotchas/advice for deploying a GPON environment in > a corporate LAN? (or about deploying a Zhone solution) It's pretty > service provider oriented, and is incredible noticeable in the CLI. No idea why people think it's a good idea for corporate deployments. The whole point of a PON is that you don't have to have active elements in the field. That's usually of little consequence in a corporate or even academic campus environment. I'd just stick to active-E. -- Brandon Martin From dot at dotat.at Tue Dec 11 16:58:18 2018 From: dot at dotat.at (Tony Finch) Date: Tue, 11 Dec 2018 16:58:18 +0000 Subject: Security issues based on post RIR allocation rules In-Reply-To: <1077025609d14c6fbbe720998ad4b703@more.net> References: <1077025609d14c6fbbe720998ad4b703@more.net> Message-ID: Spurling, Shannon wrote: > When I call a health care organization, or a web hosting provider, the > first thing I get is that they think we are trying to pull one over on > them and all these ranges must be in Africa or Asia. I show them the > ARIN information for the specific /16, and sometimes I can make some > headway. Sometimes there's no convincing them. This issue appears to be > getting worse over time, so I was wondering if some misguided > organization or group is going around pressing for the rules that are > triggering these issues? I'm somewhat inclined to blame poor `whois` implementations for this. Apart from `whois` being generally very crappy, there are specific issues on the server side and the client side which mean the human driving whois often needs a good deal of expertise to be able to properly track down the authoritative registration details for a netblock. On the server side, APNIC and RIPE do not return proper referrals for ERX netblocks. This is annoying, because they know which of the other RIRs is responsible for the registration - they have to get the reverse DNS information from the other RIR. Examples: 150.108.0.0 (an APNIC /8 but the /16 is allocated to Fordham University and managed through ARIN); and 141.111.0.0 (a RIPE /8 but the /16 is allocated to LANL and managed through ARIN). AfriNIC's whois server is more helpful: it seems to proxy queries to RIPE and APNIC as appopriate, and returns RDAP referrals for ARIN. On the client side, these days it is mostly possible to find the correct whois server to ask by following referrals from IANA. (In the past whois clients had to have a fairly large database of starting points.) A reasonably intelligent referral-oriented whois client can work around missing referrals for early netblock allocations by guessing, which usually means restarting with ARIN. But in practice most whois clients are pretty stupid, and the referral-oriented ones keep breaking when servers change. (e.g. I just found out AfriNIC's behaviour has changed since I last looked...) Tony. -- f.anthony.n.finch http://dotat.at/ West Forties, Cromarty, Forth: Southerly or southeasterly 5 or 6, occasionally 7 in Cromarty. Moderate, becoming moderate or rough. Mainly fair. Good. From baldur.norddahl at gmail.com Tue Dec 11 17:03:03 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 11 Dec 2018 18:03:03 +0100 Subject: A few GPON questions... In-Reply-To: References: Message-ID: Hello We run a small FTTH internet service provider using Zhone MXK198 switches. This is an older discontinued platform and since Zhone and Dasan merged, there might be nothing but the name in common with your equipment. Anyway, ours are stable and in five years on about 15 switches, we only have had one crash. Fixed after a power cycle. This is however the kind of equipment that you only run tested and verified setup on. Lots of stuff does not work quite as it should, but when you find a good configuration and stay with that, it is good. There are some strange things, like vlan 7 being reserved and unusable. When used with fs.com GPON sfp modules, it will work if the port has had a genuine Zhone sfp installed previously. However after a reboot it will reject the module. You then need to shift your genuine module through all the ports to activate them. The switch will reject other brands of ONU/ONT. Contrary to what they tell you, this is not because of lacking standards. There is a secret setting (which I don't have) that will make it accept third party ONU. Likewise if the ONU is programmed with the Zhone vendor code, it will be accepted. We are currently looking at cheaper options that do not come with vendor locks for SFP and ONU. Regards Baldur tir. 11. dec. 2018 16.45 skrev Nick Bogle : > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network > Engineer for a local university where we have primarily a Cisco environment > from phones to switching to routing, etc. Before my time, we hired a > contractor to design a GPON LAN system for a new building as a cost saving > measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we > have gone through the training and such, and I feel confident in my ability > to manage the system, but we have a few questions that the manufacturer of > our equipment and our contractor didn't really want to answer. We are > currently using a Dasan Zhone MXK-F1419 with several different downstream > ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the > linecards to add redundancy to the splitter (as the cost of 1st party are > too high). Does anyone have experience with 3rd party > vendors/compatibility/stability issues? We were told they theoretically > should work and just throw a log event, but it hasn't been tested. If so, > what vendors would you recommend? So far all we've really seen are Ubiquiti > and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and > ONT vendors is heavily limited.. Does anyone have any experience using say, > Zhone ONT's with a different model OLT, or Zhone ONT's with a different > model OLT? I've heard word that Zhone ONT's may be able to work with Nokia > OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced > 1 line card 5 times..), our contractor is saying it's just because we were > a pretty early adopter of this line and that they've fixed it and fixed > internal policies to add additional QA and testing before shipping to > customers. Does anyone have any experience with working with Zhone and > their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a > corporate LAN? (or about deploying a Zhone solution) It's pretty service > provider oriented, and is incredible noticeable in the CLI. > > Feel free to contact me offlist if you have any pertinent info that you > don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrallen1971 at gmail.com Tue Dec 11 16:43:07 2018 From: mrallen1971 at gmail.com (Larry Allen) Date: Tue, 11 Dec 2018 11:43:07 -0500 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: I can't imagine a single rational argument against this. On Tue, Dec 11, 2018, 10:56 William Anderson On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M > wrote: > >> Hello all, was curious to know the community’s opinion on whether an ISP >> should block domains hosting CPE (child pornography exploitation) content? >> Interpol has a ‘worst-of’ list which contains such domains and it wants >> ISPs to block it. >> > > This already happens in the UK, and has done for years. > > https://en.wikipedia.org/wiki/Child_abuse_image_content_list > > > -n > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Tue Dec 11 17:24:56 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 11 Dec 2018 12:24:56 -0500 Subject: A few GPON questions... In-Reply-To: References: Message-ID: > On Dec 11, 2018, at 11:32 AM, Ben Cannon wrote: > > Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. From aaron1 at gvtc.com Tue Dec 11 17:34:08 2018 From: aaron1 at gvtc.com (Aaron1) Date: Tue, 11 Dec 2018 11:34:08 -0600 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <9EAA0C03-A373-4418-AC99-B8188E66399A@gvtc.com> Right... When would it ever be wrong to stop terrible internet activity such as this?! Aaron > On Dec 11, 2018, at 10:43 AM, Larry Allen wrote: > > I can't imagine a single rational argument against this. > >> On Tue, Dec 11, 2018, 10:56 William Anderson >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M wrote: >> >>> Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. >>> >> >> This already happens in the UK, and has done for years. >> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list >> >> >> -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Tue Dec 11 17:35:28 2018 From: aaron1 at gvtc.com (Aaron1) Date: Tue, 11 Dec 2018 11:35:28 -0600 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: ... The only thing I can think of is the idea that I’ve heard before is the way to catch someone is to watch them well they are accessing, the concept of honeypots comes to mind Aaron > On Dec 11, 2018, at 10:43 AM, Larry Allen wrote: > > I can't imagine a single rational argument against this. > >> On Tue, Dec 11, 2018, 10:56 William Anderson >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M wrote: >> >>> Hello all, was curious to know the community’s opinion on whether an ISP should block domains hosting CPE (child pornography exploitation) content? Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs to block it. >>> >> >> This already happens in the UK, and has done for years. >> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list >> >> >> -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Tue Dec 11 17:36:47 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 11 Dec 2018 17:36:47 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: On Tue, 11 Dec 2018 at 17:30, Jason Lixfeld wrote: > There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. A point made earlier was that typically in a campus environment, most every riser cupboard has access to power so you can easily build a regular Ethernet LAN with a switch on every floor/corridor/hub. Basically, everywhere that you'd put a GPON splitter. Aled From maxtul at netassist.ua Tue Dec 11 17:45:14 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 11 Dec 2018 19:45:14 +0200 Subject: Should ISP block child pornography? In-Reply-To: <9EAA0C03-A373-4418-AC99-B8188E66399A@gvtc.com> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <9EAA0C03-A373-4418-AC99-B8188E66399A@gvtc.com> Message-ID: <1ddcfdaf-420b-d057-a5ad-1b1631625aac@netassist.ua> Remember what I said... If the censorship system will be created FOR ANY, ANY REASON - you will forget the initial reason very quickly. 11.12.18 19:34, Aaron1 пише: > Right... When would it ever be wrong to stop terrible internet activity > such as this?! > > Aaron > > On Dec 11, 2018, at 10:43 AM, Larry Allen > wrote: > >> I can't imagine a single rational argument against this.  >> >> On Tue, Dec 11, 2018, 10:56 William Anderson > wrote: >> >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M >> > wrote: >> >> Hello all, was curious to know the community’s opinion on >> whether an ISP should block domains hosting CPE (child >> pornography exploitation) content? Interpol has a ‘worst-of’ >> list which contains such domains and it wants ISPs to block it. >> >> >> This already happens in the UK, and has done for years. >> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list  >> >> >> -n >> From rod.beck at unitedcablecompany.com Tue Dec 11 17:46:13 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 11 Dec 2018 17:46:13 +0000 Subject: Empire Conduit System - NYC Message-ID: Looking for someone who uses the system at the fiber pair level. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Tue Dec 11 17:46:13 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 11 Dec 2018 19:46:13 +0200 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: <97d15929-ec0c-4d71-5557-2b61f34874b0@netassist.ua> ...and you will see the TOR exit nodes instead of crime home IP if censorship is implemented. 11.12.18 19:35, Aaron1 пише: > ... The only thing I can think of is the idea that I’ve heard before is > the way to catch someone is to watch them well they are accessing, the > concept of honeypots comes to mind > > Aaron > > On Dec 11, 2018, at 10:43 AM, Larry Allen > wrote: > >> I can't imagine a single rational argument against this.  >> >> On Tue, Dec 11, 2018, 10:56 William Anderson > wrote: >> >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M >> > wrote: >> >> Hello all, was curious to know the community’s opinion on >> whether an ISP should block domains hosting CPE (child >> pornography exploitation) content? Interpol has a ‘worst-of’ >> list which contains such domains and it wants ISPs to block it. >> >> >> This already happens in the UK, and has done for years. >> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list  >> >> >> -n >> From cra at wpi.edu Tue Dec 11 17:50:12 2018 From: cra at wpi.edu (Anderson, Charles R) Date: Tue, 11 Dec 2018 17:50:12 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: <20181211175008.xqydfymmorhvfi6p@angus.ind.wpi.edu> On Tue, Dec 11, 2018 at 05:36:47PM +0000, Aled Morris via NANOG wrote: > On Tue, 11 Dec 2018 at 17:30, Jason Lixfeld wrote: > > There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. > > A point made earlier was that typically in a campus environment, most > every riser cupboard has access to power so you can easily build a > regular Ethernet LAN with a switch on every floor/corridor/hub. > Basically, everywhere that you'd put a GPON splitter. And WDM gear if necessary...heck even passive CWDM if you have a riser space issue. From ben at 6by7.net Tue Dec 11 18:01:55 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 11 Dec 2018 10:01:55 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> Sure but I can fit quite a lot of fiber in very little space. eg an 864 is approx 1” dia. Fan-outs can be done each floor, etc. And a single single mode strand has prodigious bandwidth available with the right optics. Bonus: if you did this 30 years ago, you’re still good. Anything else (remember FDDI grade Multi-mode?) is not future proof IMO. Basic 9/125 Singlemode always will be. In city wide deployments, a bit different, especially for eg residential service at economical pricing. GPON for sure has it’s place, I just don’t personally feel it’s inside a building all else being equal. - Ben Cannon, AS15206 > On Dec 11, 2018, at 9:24 AM, Jason Lixfeld wrote: > > > >> On Dec 11, 2018, at 11:32 AM, Ben Cannon wrote: >> >> Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. > > There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. From baldur.norddahl at gmail.com Tue Dec 11 18:07:49 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 11 Dec 2018 19:07:49 +0100 Subject: A few GPON questions... In-Reply-To: <20181211175008.xqydfymmorhvfi6p@angus.ind.wpi.edu> References: <20181211175008.xqydfymmorhvfi6p@angus.ind.wpi.edu> Message-ID: > > > And WDM gear if necessary...heck even passive CWDM if you have a riser > space issue. > WDM is much more expensive than GPON. I am still waiting for one of the 10G PON variants to become available. We want to deliver 10G to customers as >1G is becoming common on CPE Wi-Fi routers. But doing it with WDM is too expensive and p2p uses more fiber than we have. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at wpi.edu Tue Dec 11 18:13:11 2018 From: cra at wpi.edu (Anderson, Charles R) Date: Tue, 11 Dec 2018 18:13:11 +0000 Subject: A few GPON questions... In-Reply-To: References: <20181211175008.xqydfymmorhvfi6p@angus.ind.wpi.edu> Message-ID: <20181211181308.l3u6snnrkovh24mu@angus.ind.wpi.edu> On Tue, Dec 11, 2018 at 07:07:49PM +0100, Baldur Norddahl wrote: > > > > > > And WDM gear if necessary...heck even passive CWDM if you have a riser > > space issue. > > > > WDM is much more expensive than GPON. > > I am still waiting for one of the 10G PON variants to become available. We > want to deliver 10G to customers as >1G is becoming common on CPE Wi-Fi > routers. But doing it with WDM is too expensive and p2p uses more fiber > than we have. Passive CWDM is cheap and supports 10gig. From blakjak at blakjak.net Tue Dec 11 18:18:35 2018 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 12 Dec 2018 07:18:35 +1300 Subject: Security issues based on post RIR allocation rules In-Reply-To: References: <1077025609d14c6fbbe720998ad4b703@more.net> Message-ID: <4C55D66A-F7D7-43E4-B86C-0C6571468CE7@blakjak.net> I'll simply endorse the 'stop judging an IP by it's RIR' approach. As a New Zealander (and APNIC is our RIR), having to convince US institutions that our subnets should not be blocked simply because they're out of the same /8 as those used by other Asian nations with poorer IP address reputations , is a challenge because, well, a nation of 4.5M in the south Pacific is insignificant, right? :S Also if the whole /8 doesn't sit within the same organisation or country, how is it smart to use it as any sort of differentiator? Have banged my head against this one many times in my career to-date. Mark. On 12 December 2018 5:58:18 AM NZDT, Tony Finch wrote: >Spurling, Shannon wrote: > >> When I call a health care organization, or a web hosting provider, >the >> first thing I get is that they think we are trying to pull one over >on >> them and all these ranges must be in Africa or Asia. I show them the >> ARIN information for the specific /16, and sometimes I can make some >> headway. Sometimes there's no convincing them. This issue appears to >be >> getting worse over time, so I was wondering if some misguided >> organization or group is going around pressing for the rules that are >> triggering these issues? > >I'm somewhat inclined to blame poor `whois` implementations for this. > >Apart from `whois` being generally very crappy, there are specific >issues >on the server side and the client side which mean the human driving >whois >often needs a good deal of expertise to be able to properly track down >the >authoritative registration details for a netblock. > >On the server side, APNIC and RIPE do not return proper referrals for >ERX >netblocks. This is annoying, because they know which of the other RIRs >is >responsible for the registration - they have to get the reverse DNS >information from the other RIR. Examples: 150.108.0.0 (an APNIC /8 but >the >/16 is allocated to Fordham University and managed through ARIN); and >141.111.0.0 (a RIPE /8 but the /16 is allocated to LANL and managed >through ARIN). > >AfriNIC's whois server is more helpful: it seems to proxy queries to >RIPE >and APNIC as appopriate, and returns RDAP referrals for ARIN. > >On the client side, these days it is mostly possible to find the >correct >whois server to ask by following referrals from IANA. (In the past >whois >clients had to have a fairly large database of starting points.) A >reasonably intelligent referral-oriented whois client can work around >missing referrals for early netblock allocations by guessing, which >usually means restarting with ARIN. But in practice most whois clients >are >pretty stupid, and the referral-oriented ones keep breaking when >servers >change. (e.g. I just found out AfriNIC's behaviour has changed since I >last looked...) > >Tony. >-- >f.anthony.n.finch http://dotat.at/ >West Forties, Cromarty, Forth: Southerly or southeasterly 5 or 6, >occasionally >7 in Cromarty. Moderate, becoming moderate or rough. Mainly fair. Good. -- Sent from a mobile device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Tue Dec 11 18:19:59 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 11 Dec 2018 19:19:59 +0100 Subject: A few GPON questions... In-Reply-To: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> References: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> Message-ID: tir. 11. dec. 2018 19.03 skrev Ben Cannon : > Sure but I can fit quite a lot of fiber in very little space. eg an 864 is > approx 1” dia. > Working with that much fiber is expensive. Too much work at each splice point. Huge inflexible cables. Expensive machinery to blow the fiber. Compare that to blowing a 24f cable of 4 mm into a 6 mm id and 10 mmu od duct. You can carry 24 times 128 users on that. Much more than the 25 mm monster cable running p2p. On top of that the multiduct has 12 of the smaller 10 mm subducts. You can blow additional cables as needed. Granted I have only worked with outside plant delivering FTTH. But I don't see why not for a campus. Regards Baldur > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Tue Dec 11 18:23:48 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 11 Dec 2018 13:23:48 -0500 Subject: A few GPON questions... In-Reply-To: References: <20181211175008.xqydfymmorhvfi6p@angus.ind.wpi.edu> Message-ID: <678d41ee-da71-0347-eb4d-621066358084@monmotha.net> On 12/11/18 1:07 PM, Baldur Norddahl wrote: > I am still waiting for one of the 10G PON variants to become available. > We want to deliver 10G to customers as >1G is becoming common on CPE > Wi-Fi routers. But doing it with WDM is too expensive and p2p uses more > fiber than we have. XGS-PON is available now from some vendors. I know of at least one that's also already supporting NG-PON2 WDM-PON using the same cards and just different optics if you really want to go all the way to 52Gbps per PON (GPON + XGS-PON + 4xNG-PON2 lambdas). OLT-side, the pricing I've seen is actually pretty decent at maybe 2-3x the price per port of GPON despite having ~5x the capacity. ONT-side has a bit of an ouch factor at the moment (also 2-3x or more the price of a GPON ONT...), but if you've got someone who actually wants >1Gbps service and can charge accordingly, it's definitely out there. -- Brandon Martin From bill at herrin.us Tue Dec 11 18:26:28 2018 From: bill at herrin.us (William Herrin) Date: Tue, 11 Dec 2018 10:26:28 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: On Tue, Dec 11, 2018 at 7:44 AM Nick Bogle wrote: > local university [...] we hired a contractor to design a GPON LAN system for a new building as a cost saving measure Hi Nick, Do I correctly understand that you're using GPON *inside* the building for connecting stations to the wiring closets rather than connecting the wiring closets back to campus IT central? Truly using it for the LAN and not the campus WAN? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From karsten.elfenbein at gmail.com Tue Dec 11 18:46:06 2018 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Tue, 11 Dec 2018 19:46:06 +0100 Subject: Monitoring service that has a human component? In-Reply-To: References: Message-ID: Hi, you could let them insert a custom string into the maintenance page. (I hope they are not writing it on demand) So the monitoring would be ok on status code 200-399 or custom string found. You could also use a different escalation chain when "maintenance" is found on an 503 error. Other than that it sounds like a nice AI training field. Karsten Am Mi., 5. Dez. 2018 um 23:04 Uhr schrieb David H : > > Hey all, was curious if anyone knows of a website monitoring service that has the option to incorporate a human component into the decision and escalation tree? I’m trying to help a customer find a way around false positives bogging down their NOC staff, by having a human determine the difference between a real error, desired (but different) content, or something in between like “Hey it’s 3am and we’ve taken our website offline for maintenance, we’ll be back up by 6am.” Automated systems tend to only know if test A, or steps A through C, are failing, then this is ‘down’ and do my preconfigured thing, but that ends up needlessly taking NOC time if the customer themselves is performing work on their own site, or just changed it and whatever content was being watched, is now gone. So, the goal would be to have the end user be the first point of contact if it looks like more of a customer-side issue. If they can’t be reached to confirm, THEN contact NOC, and unlike email alerts, keep contacting until a human acknowledges receipt of the alert. > > > > Thanks From owen at delong.com Tue Dec 11 18:49:37 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Dec 2018 10:49:37 -0800 Subject: A few GPON questions... In-Reply-To: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> References: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> Message-ID: <069CE4EF-B388-451C-89B5-F135A98AA4BF@delong.com> > On Dec 11, 2018, at 10:01 , Ben Cannon wrote: > > Sure but I can fit quite a lot of fiber in very little space. eg an 864 is approx 1” dia. > > Fan-outs can be done each floor, etc. And a single single mode strand has prodigious bandwidth available with the right optics. > > Bonus: if you did this 30 years ago, you’re still good. Anything else (remember FDDI grade Multi-mode?) is not future proof IMO. Basic 9/125 Singlemode always will be. > > In city wide deployments, a bit different, especially for eg residential service at economical pricing. GPON for sure has it’s place, I just don’t personally feel it’s inside a building all else being equal. I’d actually argue that even if you’re going to do GPON on a wide distribution, the economics these days make a pretty good case for future-proofing with home-run fiber and putting your splitters and GPON gear in the same location. The link budgets turn out to be identical regardless of how far upstream the splitter is and once you dig the trench, the cost of the fiber itself is relatively cheap. Home run means you aren’t locked into the PON topology if something better comes along in the future. It also opens up the potential to support competition (which I realize may be considered a detractor by some). Owen > > - Ben Cannon, AS15206 > >> On Dec 11, 2018, at 9:24 AM, Jason Lixfeld wrote: >> >> >> >>> On Dec 11, 2018, at 11:32 AM, Ben Cannon wrote: >>> >>> Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. >> >> There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. > From nick at bogle.se Tue Dec 11 18:59:08 2018 From: nick at bogle.se (Nick Bogle) Date: Tue, 11 Dec 2018 10:59:08 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: Bill, That is correct. We are running SMF from our Datacenter to the end users desk in the building and providing either in wall 4 port ONTs or desktop 8-16 port ONTs. Everywhere there would be a traditional 3 port CAT6 network jack there is a APC fiber jack and/or an in wall ONT. On Tue, Dec 11, 2018 at 10:26 AM William Herrin wrote: > On Tue, Dec 11, 2018 at 7:44 AM Nick Bogle wrote: > > local university [...] we hired a contractor to design a GPON LAN system > for a new building as a cost saving measure > > Hi Nick, > > Do I correctly understand that you're using GPON *inside* the building > for connecting stations to the wiring closets rather than connecting > the wiring closets back to campus IT central? Truly using it for the > LAN and not the campus WAN? > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jllee9753 at gmail.com Tue Dec 11 19:06:11 2018 From: jllee9753 at gmail.com (John Lee) Date: Tue, 11 Dec 2018 14:06:11 -0500 Subject: Should ISP block child pornography? In-Reply-To: <97d15929-ec0c-4d71-5557-2b61f34874b0@netassist.ua> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <97d15929-ec0c-4d71-5557-2b61f34874b0@netassist.ua> Message-ID: It is my understanding that ISPs block IP addresses and domains under court order now for copyright violations, criminal activity which would include CP. They require a court order as they cannot ascertain if it is CP or not, that is a Law Enforcement decision. The US Supreme Court decision's was just being nude is not lewd, also with aging software which can regress photos, LEOs in the US have to ascertain if this is CP or photo shopped. On Tue, Dec 11, 2018 at 12:54 PM Max Tulyev wrote: > ...and you will see the TOR exit nodes instead of crime home IP if > censorship is implemented. > > 11.12.18 19:35, Aaron1 пише: > > ... The only thing I can think of is the idea that I’ve heard before is > > the way to catch someone is to watch them well they are accessing, the > > concept of honeypots comes to mind > > > > Aaron > > > > On Dec 11, 2018, at 10:43 AM, Larry Allen > > wrote: > > > >> I can't imagine a single rational argument against this. > >> > >> On Tue, Dec 11, 2018, 10:56 William Anderson >> wrote: > >> > >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M > >> > wrote: > >> > >> Hello all, was curious to know the community’s opinion on > >> whether an ISP should block domains hosting CPE (child > >> pornography exploitation) content? Interpol has a ‘worst-of’ > >> list which contains such domains and it wants ISPs to block it. > >> > >> > >> This already happens in the UK, and has done for years. > >> > >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list > >> > >> > >> -n > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at bogle.se Tue Dec 11 19:12:00 2018 From: nick at bogle.se (Nick Bogle) Date: Tue, 11 Dec 2018 11:12:00 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: I wish this was an option.... There isn't any budget for ripping out this system and we are already contractually obliged to deploy GPON in another building that will be coming online in 2-3 years. We've severed the contract beyond that already. That being said.... We have ~580 ONTs (remember, we are deploying fiber to the user, not to the MDF. There is no network closet.) To deploy a Cisco compact switch or something similar would cost ~1,000/ea plus $200 minimum for third party optics, then to add a large enough fiber distribution switch for that many ports would be astronomically expensive. It was a poor desicion that will have to be maintained for the next ~25 years until the next remodel thanks to our previous non technical administration listening to the sales people over the previous network administration team. On Tue, Dec 11, 2018 at 8:32 AM Ben Cannon wrote: > Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your > existing (likely SMF thankfully) cable plant. My opinion. > > -Ben. AS15206 > > On Dec 6, 2018, at 7:18 PM, Nick Bogle wrote: > > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network > Engineer for a local university where we have primarily a Cisco environment > from phones to switching to routing, etc. Before my time, we hired a > contractor to design a GPON LAN system for a new building as a cost saving > measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we > have gone through the training and such, and I feel confident in my ability > to manage the system, but we have a few questions that the manufacturer of > our equipment and our contractor didn't really want to answer. We are > currently using a Dasan Zhone MXK-F1419 with several different downstream > ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the > linecards to add redundancy to the splitter (as the cost of 1st party are > too high). Does anyone have experience with 3rd party > vendors/compatibility/stability issues? We were told they theoretically > should work and just throw a log event, but it hasn't been tested. If so, > what vendors would you recommend? So far all we've really seen are Ubiquiti > and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and > ONT vendors is heavily limited.. Does anyone have any experience using say, > Zhone ONT's with a different model OLT, or Zhone ONT's with a different > model OLT? I've heard word that Zhone ONT's may be able to work with Nokia > OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced > 1 line card 5 times..), our contractor is saying it's just because we were > a pretty early adopter of this line and that they've fixed it and fixed > internal policies to add additional QA and testing before shipping to > customers. Does anyone have any experience with working with Zhone and > their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a > corporate LAN? (or about deploying a Zhone solution) It's pretty service > provider oriented, and is incredible noticeable in the CLI. > > Feel free to contact me offlist if you have any pertinent info that you > don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Tue Dec 11 19:23:55 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 11 Dec 2018 21:23:55 +0200 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <97d15929-ec0c-4d71-5557-2b61f34874b0@netassist.ua> Message-ID: <86c6274b-a169-077b-9ba8-83aeef093064@netassist.ua> Yes, in some countries (NOT in US, AFAIK) court can issue an order to block IP/domain/URL. If home operator of crime man is blocking the direct access - he have to use TOR/VPN/... to avoid blocking (or may be you really believe he just stop any tries to watch his lovely CP?) If he use TOR/VPN/... to avoid blocking - the original home IP address will be changed to the exit node of TOR/VPN - and we will lost any chance to catch the crime man. Is it clear? 11.12.18 21:06, John Lee пише: > It is my understanding that ISPs block IP addresses and domains under > court order now for copyright violations, criminal activity which would > include CP. They require a court order as they cannot ascertain if it is > CP or not, that is a Law Enforcement decision. The US Supreme Court > decision's was just being nude is not lewd, also with aging software > which can regress photos, LEOs in the US have to ascertain if this is CP > or photo shopped.  > > On Tue, Dec 11, 2018 at 12:54 PM Max Tulyev > wrote: > > ...and you will see the TOR exit nodes instead of crime home IP if > censorship is implemented. > > 11.12.18 19:35, Aaron1 пише: > > ... The only thing I can think of is the idea that I’ve heard > before is > > the way to catch someone is to watch them well they are accessing, the > > concept of honeypots comes to mind > > > > Aaron > > > > On Dec 11, 2018, at 10:43 AM, Larry Allen > > >> wrote: > > > >> I can't imagine a single rational argument against this.  > >> > >> On Tue, Dec 11, 2018, 10:56 William Anderson > >> > wrote: > >> > >>     On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M > >>      > >> > wrote: > >> > >>         Hello all, was curious to know the community’s opinion on > >>         whether an ISP should block domains hosting CPE (child > >>         pornography exploitation) content? Interpol has a ‘worst-of’ > >>         list which contains such domains and it wants ISPs to > block it. > >> > >> > >>     This already happens in the UK, and has done for years. > >> > >>     https://en.wikipedia.org/wiki/Child_abuse_image_content_list  > >> > >> > >>     -n > >> > From alfie at fdx.services Tue Dec 11 19:28:03 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 11 Dec 2018 19:28:03 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: <1544556483.1220481.1606203336.59B5AD89@webmail.messagingengine.com> Campus network deployments are expensive, by their very nature. You are deploying a *lot* of capacity over a not-insignificant footprint. If your building has been constructed sans wiring closets, then I can forsee other issues in your future - Will you be deploying WiFi on site? If so, where do you intend to situate the Switches/ONTs+PoE injectors for those? I wouldn't put my name to this. ~A -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at bogle.se Tue Dec 11 19:34:44 2018 From: nick at bogle.se (Nick Bogle) Date: Tue, 11 Dec 2018 11:34:44 -0800 Subject: A few GPON questions... In-Reply-To: <1544556483.1220481.1606203336.59B5AD89@webmail.messagingengine.com> References: <1544556483.1220481.1606203336.59B5AD89@webmail.messagingengine.com> Message-ID: Ceiling tiles. There is a special ceiling tile that drops down that maintains our 24 port ONTs that do PoE+ to our Cisco WAPs. It's most definitely isn't what I would have chosen to do. On Tue, Dec 11, 2018 at 11:30 AM Alfie Pates wrote: > Campus network deployments are expensive, by their very nature. You are > deploying a *lot* of capacity over a not-insignificant footprint. > > If your building has been constructed sans wiring closets, then I can > forsee other issues in your future - Will you be deploying WiFi on site? If > so, where do you intend to situate the Switches/ONTs+PoE injectors for > those? > > I wouldn't put my name to this. > > > ~A > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Dec 11 18:33:10 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Dec 2018 10:33:10 -0800 Subject: Security issues based on post RIR allocation rules In-Reply-To: References: <1077025609d14c6fbbe720998ad4b703@more.net> Message-ID: Likely with the growing number of inter-RIR transfers of IPv4 blocks, over time, this is only going to get worse (or better)… Worse in that the size of the problem will continue to grow. Better in that as the size of the problem grows, it might become visible enough to actually get addressed. Owen > On Dec 11, 2018, at 08:58 , Tony Finch wrote: > > Spurling, Shannon wrote: > >> When I call a health care organization, or a web hosting provider, the >> first thing I get is that they think we are trying to pull one over on >> them and all these ranges must be in Africa or Asia. I show them the >> ARIN information for the specific /16, and sometimes I can make some >> headway. Sometimes there's no convincing them. This issue appears to be >> getting worse over time, so I was wondering if some misguided >> organization or group is going around pressing for the rules that are >> triggering these issues? > > I'm somewhat inclined to blame poor `whois` implementations for this. > > Apart from `whois` being generally very crappy, there are specific issues > on the server side and the client side which mean the human driving whois > often needs a good deal of expertise to be able to properly track down the > authoritative registration details for a netblock. > > On the server side, APNIC and RIPE do not return proper referrals for ERX > netblocks. This is annoying, because they know which of the other RIRs is > responsible for the registration - they have to get the reverse DNS > information from the other RIR. Examples: 150.108.0.0 (an APNIC /8 but the > /16 is allocated to Fordham University and managed through ARIN); and > 141.111.0.0 (a RIPE /8 but the /16 is allocated to LANL and managed > through ARIN). > > AfriNIC's whois server is more helpful: it seems to proxy queries to RIPE > and APNIC as appopriate, and returns RDAP referrals for ARIN. > > On the client side, these days it is mostly possible to find the correct > whois server to ask by following referrals from IANA. (In the past whois > clients had to have a fairly large database of starting points.) A > reasonably intelligent referral-oriented whois client can work around > missing referrals for early netblock allocations by guessing, which > usually means restarting with ARIN. But in practice most whois clients are > pretty stupid, and the referral-oriented ones keep breaking when servers > change. (e.g. I just found out AfriNIC's behaviour has changed since I > last looked...) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > West Forties, Cromarty, Forth: Southerly or southeasterly 5 or 6, occasionally > 7 in Cromarty. Moderate, becoming moderate or rough. Mainly fair. Good. From bill at herrin.us Tue Dec 11 20:04:07 2018 From: bill at herrin.us (William Herrin) Date: Tue, 11 Dec 2018 12:04:07 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: On Tue, Dec 11, 2018 at 10:59 AM Nick Bogle wrote: > That is correct. We are running SMF from our Datacenter to the end > users desk in the building and providing either in wall 4 port ONTs or > desktop 8-16 port ONTs. Everywhere there would be a traditional 3 port > CAT6 network jack there is a APC fiber jack and/or an in wall ONT. Hi Nick, Yikes! That's upside down even for PON. The P is for Passive. The whole idea is to not have powered infrastructure in inconvenient locations because that's expensive and super hard to reliably maintain. I think maybe you've found yourself in a "throwing good money after bad" situation. You have the LAN equivalent of motion sensor lighting in the restroom. Sounds great until you realize the maximum delay setting is 15 minutes... how many dark #2s before you have to bite the bullet and take it out? This is going to cost you cash and productivity for as long as you keep trying to make it work. Moreover, the combination of inflexibility and elevated incidence of outages will consume the occupants' productivity as well. There will never be a less expensive time to install a classic (copper) cabling infrastructure than before the building is occupied. This is where you dip in to the organization's contingency funds and take the political hit. And for the love of God, break the contract for the next building. Even if you have to pay it out and just lose the money, save yourself the expense of ever having to operate it. If they won't take your word for it, get an external networking company to do an impact and cost analysis so you can show the administration what they'll lose by continuing this folly. I'll bet your contractor had some questions they didn't want to answer. If I'd sold you this bill of goods there'd be questions I wouldn't want to answer too. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nick at bogle.se Tue Dec 11 20:15:42 2018 From: nick at bogle.se (Nick Bogle) Date: Tue, 11 Dec 2018 12:15:42 -0800 Subject: A few GPON questions... In-Reply-To: References: Message-ID: The cost analysis was already done. The cost is around 10% less. The implications are there is no redundancy, lacking capacity, costs were not factored in for BBUs on every ONT like should have been spec'd out for emergency phone lines, etc. After that was done management said to suck it up and make it work. Unfortunately we're beyond stuck with it at this point as the second building is already under construction and the first buildings grand opening is January 1st. On Tue, Dec 11, 2018 at 12:04 PM William Herrin wrote: > On Tue, Dec 11, 2018 at 10:59 AM Nick Bogle wrote: > > That is correct. We are running SMF from our Datacenter to the end > > users desk in the building and providing either in wall 4 port ONTs or > > desktop 8-16 port ONTs. Everywhere there would be a traditional 3 port > > CAT6 network jack there is a APC fiber jack and/or an in wall ONT. > > Hi Nick, > > Yikes! That's upside down even for PON. The P is for Passive. The > whole idea is to not have powered infrastructure in inconvenient > locations because that's expensive and super hard to reliably > maintain. > > I think maybe you've found yourself in a "throwing good money after > bad" situation. You have the LAN equivalent of motion sensor lighting > in the restroom. Sounds great until you realize the maximum delay > setting is 15 minutes... how many dark #2s before you have to bite the > bullet and take it out? > > This is going to cost you cash and productivity for as long as you > keep trying to make it work. Moreover, the combination of > inflexibility and elevated incidence of outages will consume the > occupants' productivity as well. There will never be a less expensive > time to install a classic (copper) cabling infrastructure than before > the building is occupied. This is where you dip in to the > organization's contingency funds and take the political hit. > > And for the love of God, break the contract for the next building. > Even if you have to pay it out and just lose the money, save yourself > the expense of ever having to operate it. If they won't take your word > for it, get an external networking company to do an impact and cost > analysis so you can show the administration what they'll lose by > continuing this folly. > > I'll bet your contractor had some questions they didn't want to > answer. If I'd sold you this bill of goods there'd be questions I > wouldn't want to answer too. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Tue Dec 11 20:32:43 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 11 Dec 2018 20:32:43 +0000 Subject: A few GPON questions... In-Reply-To: References: Message-ID: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> >The cost analysis was already done. >Costs were not factored in for BBUs on every ONT like should have been >spec'd out for emergency phone lines. These two things do not quite agree. Update your CV - It is not your responsibility to shoulder the stress of your superiors' bad decisions, especially if you have no room to learn from those mistakes. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Dec 11 20:57:06 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 11 Dec 2018 12:57:06 -0800 Subject: A few GPON questions... In-Reply-To: <069CE4EF-B388-451C-89B5-F135A98AA4BF@delong.com> References: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net> <069CE4EF-B388-451C-89B5-F135A98AA4BF@delong.com> Message-ID: We think it makes sense for cost reduction for semi rural or suburban aerial distribution- reducing the fiber count to like. 12. Reduces costs dramatically vs say a 288 count and all the splicing. (Ribbons are better) -Ben > On Dec 11, 2018, at 10:49 AM, Owen DeLong wrote: > > > >> On Dec 11, 2018, at 10:01 , Ben Cannon wrote: >> >> Sure but I can fit quite a lot of fiber in very little space. eg an 864 is approx 1” dia. >> >> Fan-outs can be done each floor, etc. And a single single mode strand has prodigious bandwidth available with the right optics. >> >> Bonus: if you did this 30 years ago, you’re still good. Anything else (remember FDDI grade Multi-mode?) is not future proof IMO. Basic 9/125 Singlemode always will be. >> >> In city wide deployments, a bit different, especially for eg residential service at economical pricing. GPON for sure has it’s place, I just don’t personally feel it’s inside a building all else being equal. > > I’d actually argue that even if you’re going to do GPON on a wide distribution, the economics these days make a pretty good case for future-proofing with home-run fiber and putting your splitters and GPON gear in the same location. The link budgets turn out to be identical regardless of how far upstream the splitter is and once you dig the trench, the cost of the fiber itself is relatively cheap. > > Home run means you aren’t locked into the PON topology if something better comes along in the future. It also opens up the potential to support competition (which I realize may be considered a detractor by some). > > Owen > >> >> - Ben Cannon, AS15206 >> >>> On Dec 11, 2018, at 9:24 AM, Jason Lixfeld wrote: >>> >>> >>> >>>> On Dec 11, 2018, at 11:32 AM, Ben Cannon wrote: >>>> >>>> Rip it out and run 9/125 SMF fiber home runs. Use BiDi SFPs to re-use your existing (likely SMF thankfully) cable plant. My opinion. >>> >>> There’s only so much space in conduits, risers and ducts. At some point, scale would press this up against physical infrastructure realities depending on how far the active gear at the head end is from the subscriber. >> > From rod.beck at unitedcablecompany.com Tue Dec 11 20:57:42 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 11 Dec 2018 20:57:42 +0000 Subject: A few GPON questions... In-Reply-To: References: <6A0D424B-244D-4B13-AB8B-F8854375B0E3@6by7.net>, Message-ID: Fusion splicing .... ________________________________ From: NANOG on behalf of Baldur Norddahl Sent: Tuesday, December 11, 2018 7:19 PM To: nanog at nanog.org Subject: Re: A few GPON questions... tir. 11. dec. 2018 19.03 skrev Ben Cannon >: Sure but I can fit quite a lot of fiber in very little space. eg an 864 is approx 1” dia. Working with that much fiber is expensive. Too much work at each splice point. Huge inflexible cables. Expensive machinery to blow the fiber. Compare that to blowing a 24f cable of 4 mm into a 6 mm id and 10 mmu od duct. You can carry 24 times 128 users on that. Much more than the 25 mm monster cable running p2p. On top of that the multiduct has 12 of the smaller 10 mm subducts. You can blow additional cables as needed. Granted I have only worked with outside plant delivering FTTH. But I don't see why not for a campus. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue Dec 11 20:59:16 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 11 Dec 2018 12:59:16 -0800 Subject: A few GPON questions... In-Reply-To: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: On 12/11/18 12:32 PM, Alfie Pates wrote: > >The cost analysis was already done. > > >Costs were not factored in for BBUs on every ONT like should have been > spec'd out for emergency phone lines. > > These two things do not quite agree. I'm sure management did some kind of cost analysis, but ignored normal IT things like POE for things like phones and cameras. POE is super convenient in a LAN environment. But management doesn't know or usually care about that. I'd have asked the PON guys hey, what's your solution for POE delivery to powered devices? I bet factoring that in alone would have blown the PON cost up. I can't imagine doing anything as insane as PON in a LAN environment. But everyone knows fiber is the best and you must eliminate all that silly copper, with helpful prodding from vendor sales. Could be sales didn't want IT involved because they knew IT will kill the deal, and some management will fall for that because these sales guys must be the experts. Problems later? The IT guy will deal with it. I've had jobs where management refused to consult with or consider suggestions from IT. I once was part of an office move where the modular furniture vendor started asking questions about cabling was entering and port locations blah blah. They were told by management they don't need to know that and IT will just figure it out later. The vendor was like no way, they need to be involved now or we won't proceed. Then IT was brought in at the last minute, but if the furniture vendor hadn't refused to proceed the plan was literally F the IT guys and make them figure it out all the cabling over the weekend before everyone was to move in. Management like that just gets worse until you line up another job and quit. From nick at bogle.se Tue Dec 11 21:04:11 2018 From: nick at bogle.se (Nick Bogle) Date: Tue, 11 Dec 2018 13:04:11 -0800 Subject: A few GPON questions... In-Reply-To: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: Unfortunately management didn't want an apple to apple comparison. They wanted a comparison to how it was spec'd out originally not how we typically deploy it now. I don't think this is a deal breaker for my job, we have 50+ buildings left to manage, and our contractor is responsible for maintaining it for the most part for the next year at minimum. The previous management (CIO/CTO/their assistants) were pretty much fired over this fiasco. New management is much better to deal with. On Tue, Dec 11, 2018 at 12:35 PM Alfie Pates wrote: > >The cost analysis was already done. > > >Costs were not factored in for BBUs on every ONT like should have been > spec'd out for emergency phone lines. > > These two things do not quite agree. > > Update your CV - It is not your responsibility to shoulder the stress of > your superiors' bad decisions, especially if you have no room to learn from > those mistakes. > > > ~a > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Tue Dec 11 21:08:20 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 11 Dec 2018 21:08:20 +0000 Subject: Unsolicited LinkedIn requests Message-ID: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Hi folks, I'm not going to name-and-shame, but I just got a LinkedIn connection request completely out of the blue from somebody with the comment "Greetings from another NANOG user!" I didn't recognise the name, and a quick search of my email history suggests we haven't interacted before. Please don't do this: It's not very polite. ~A From ben at 6by7.net Tue Dec 11 21:11:29 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 11 Dec 2018 13:11:29 -0800 Subject: A few GPON questions... In-Reply-To: References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: Rip it out. Where are your splitters? You can probably fix this with PoE 8-port switches and UPS-es. Every day you wait will cost more. You will never get 25 years out of this, I predict 6mos and then you rip it completely and put in copper/IDFs. -Ben > On Dec 11, 2018, at 1:04 PM, Nick Bogle wrote: > > Unfortunately management didn't want an apple to apple comparison. They wanted a comparison to how it was spec'd out originally not how we typically deploy it now. I don't think this is a deal breaker for my job, we have 50+ buildings left to manage, and our contractor is responsible for maintaining it for the most part for the next year at minimum. The previous management (CIO/CTO/their assistants) were pretty much fired over this fiasco. New management is much better to deal with. > >> On Tue, Dec 11, 2018 at 12:35 PM Alfie Pates wrote: >> >The cost analysis was already done. >> >> >Costs were not factored in for BBUs on every ONT like should have been spec'd out for emergency phone lines. >> >> These two things do not quite agree. >> >> Update your CV - It is not your responsibility to shoulder the stress of your superiors' bad decisions, especially if you have no room to learn from those mistakes. >> >> >> ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Tue Dec 11 21:12:56 2018 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 12 Dec 2018 10:12:56 +1300 Subject: A few GPON questions... In-Reply-To: References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: <014b01d49196$4bb349f0$e319ddd0$@wicks.co.nz> I remember working for this little company called EDS... Some bright spark decided that ATM to the desktop was the future (not this ethernet (or even token ring) thing) and subsequently converted several thousand head office machines to E3 or OC3 to the desktop. Hell of a thing trying to make OS2 drivers work for an OC3 card. That went very badly and the whole lot was ripped out again after a couple of years from memory. -----Original Message----- From: NANOG On Behalf Of Seth Mattinen Sent: Wednesday, 12 December 2018 9:59 AM To: nanog at nanog.org Subject: Re: A few GPON questions... I've had jobs where management refused to consult with or consider suggestions from IT. I once was part of an office move where the modular furniture vendor started asking questions about cabling was entering and port locations blah blah. They were told by management they don't need to know that and IT will just figure it out later. The vendor was like no way, they need to be involved now or we won't proceed. Then IT was brought in at the last minute, but if the furniture vendor hadn't refused to proceed the plan was literally F the IT guys and make them figure it out all the cabling over the weekend before everyone was to move in. Management like that just gets worse until you line up another job and quit. From aled.w.morris at googlemail.com Tue Dec 11 21:30:35 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 11 Dec 2018 21:30:35 +0000 Subject: A few GPON questions... In-Reply-To: <014b01d49196$4bb349f0$e319ddd0$@wicks.co.nz> References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> <014b01d49196$4bb349f0$e319ddd0$@wicks.co.nz> Message-ID: On Tue, 11 Dec 2018 at 21:16, Tony Wicks wrote: > > I remember working for this little company called EDS... Some bright spark decided that ATM to the desktop was the future (not this ethernet (or even token ring) thing) and subsequently converted several thousand head office machines to E3 or OC3 to the desktop. Hell of a thing trying to make OS2 drivers work for an OC3 card. That went very badly and the whole lot was ripped out again after a couple of years from memory. Same thing happened in BA's shiny new office block near Heathrow back in the 90's. ATM25 to the desktop and LANE. Total disaster. Allegedly. Aled From dcorbe at hammerfiber.com Tue Dec 11 21:39:22 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 11 Dec 2018 16:39:22 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: If you don’t want people contacting you on Linkedin then why do you have a link to your profile on your website? at 4:08 PM, Alfie Pates wrote: > Hi folks, > > I'm not going to name-and-shame, but I just got a LinkedIn connection > request completely out of the blue from somebody with the comment > "Greetings from another NANOG user!" > > I didn't recognise the name, and a quick search of my email history > suggests we haven't interacted before. > > Please don't do this: It's not very polite. > > ~A From Daniel.Jameson at tdstelecom.com Tue Dec 11 21:40:58 2018 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 11 Dec 2018 21:40:58 +0000 Subject: A few GPON questions... In-Reply-To: References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: I’ve used this guy a couple times, Use your favorite switch/POE switch and viola PON network using switches. Pretty sure it doesn’t work with Zhone… But Zhone is #88 in my list of PON vendor choices ;) https://supportforums.adtran.com/docs/DOC-8697 From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ben Cannon Sent: Tuesday, December 11, 2018 2:11 PM To: Nick Bogle Cc: nanog at nanog.org Subject: Re: A few GPON questions... Rip it out. Where are your splitters? You can probably fix this with PoE 8-port switches and UPS-es. Every day you wait will cost more. You will never get 25 years out of this, I predict 6mos and then you rip it completely and put in copper/IDFs. -Ben On Dec 11, 2018, at 1:04 PM, Nick Bogle > wrote: Unfortunately management didn't want an apple to apple comparison. They wanted a comparison to how it was spec'd out originally not how we typically deploy it now. I don't think this is a deal breaker for my job, we have 50+ buildings left to manage, and our contractor is responsible for maintaining it for the most part for the next year at minimum. The previous management (CIO/CTO/their assistants) were pretty much fired over this fiasco. New management is much better to deal with. On Tue, Dec 11, 2018 at 12:35 PM Alfie Pates > wrote: >The cost analysis was already done. >Costs were not factored in for BBUs on every ONT like should have been spec'd out for emergency phone lines. These two things do not quite agree. Update your CV - It is not your responsibility to shoulder the stress of your superiors' bad decisions, especially if you have no room to learn from those mistakes. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at chronos.com.tr Tue Dec 11 21:48:46 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Wed, 12 Dec 2018 00:48:46 +0300 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: Well said... But I can't see that on his website... M. OMER GOLGELI --- AS202365 On 2018-12-12 00:39, Daniel Corbe wrote: > If you don’t want people contacting you on Linkedin then why do you > have a link to your profile on your website? > > at 4:08 PM, Alfie Pates wrote: > >> Hi folks, >> >> I'm not going to name-and-shame, but I just got a LinkedIn connection >> request completely out of the blue from somebody with the comment >> "Greetings from another NANOG user!" >> >> I didn't recognise the name, and a quick search of my email history >> suggests we haven't interacted before. >> >> Please don't do this: It's not very polite. >> >> ~A From dave at dogwood.com Tue Dec 11 21:53:07 2018 From: dave at dogwood.com (David Cornejo) Date: Tue, 11 Dec 2018 11:53:07 -1000 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: not sure he was complaining about the request, just that it provided no context or reason why they should link. a personal pet peeve of mine. On Tue, Dec 11, 2018 at 11:50 AM M. Omer GOLGELI wrote: > > Well said... > > But I can't see that on his website... > > > M. OMER GOLGELI > --- > AS202365 > > > On 2018-12-12 00:39, Daniel Corbe wrote: > > If you don’t want people contacting you on Linkedin then why do you > > have a link to your profile on your website? > > > > at 4:08 PM, Alfie Pates wrote: > > > >> Hi folks, > >> > >> I'm not going to name-and-shame, but I just got a LinkedIn connection > >> request completely out of the blue from somebody with the comment > >> "Greetings from another NANOG user!" > >> > >> I didn't recognise the name, and a quick search of my email history > >> suggests we haven't interacted before. > >> > >> Please don't do this: It's not very polite. > >> > >> ~A -- Kailua, Hawaiʻi US +1 (808) 728-3050 UK +44 (020) 3286 2808 From blakjak at blakjak.net Tue Dec 11 21:53:47 2018 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 12 Dec 2018 10:53:47 +1300 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: I got the same invite. Sharing your profile in order to make certain information available to potential customers, vendors, partners etc, is not an invitation to connect on the basis of a tenuous-at-best professional tie-in. I'm firmly in the camp of 'Use LinkedIn to remain connected with people that I know or have done business with', and unsolicited invitations from people I don't know are almost universally ignored and/or blocked... It also tends to flavour my thinking if i'm later in the market for services similar to those offered by someone who's tried it on in this manner in the past. Amazingly I had a sales-type engage with me via InMail just recently, defending his cold sales approach (spam, basically) when I tried to do the polite thing and explain why what he was doing was 'bad'. Mark. > If you don’t want people contacting you on Linkedin then why do you have > a > link to your profile on your website? > > at 4:08 PM, Alfie Pates wrote: > >> Hi folks, >> >> I'm not going to name-and-shame, but I just got a LinkedIn connection >> request completely out of the blue from somebody with the comment >> "Greetings from another NANOG user!" >> >> I didn't recognise the name, and a quick search of my email history >> suggests we haven't interacted before. >> >> Please don't do this: It's not very polite. >> >> ~A > > > From lists.nanog at monmotha.net Tue Dec 11 22:01:52 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 11 Dec 2018 17:01:52 -0500 Subject: A few GPON questions... In-Reply-To: References: <1544560363.1239441.1606280744.0F1AAB1F@webmail.messagingengine.com> Message-ID: On 12/11/18 4:40 PM, Jameson, Daniel wrote: > I’ve used this guy a couple times,  Use your favorite switch/POE switch > and viola PON network using switches.  Pretty sure it doesn’t work with > Zhone… But Zhone is #88 in my list of PON vendor choices ;) > > https://supportforums.adtran.com/docs/DOC-8697 > My Adtran salesperson has told me on a few occasions that they don't recommend those things anymore and may even have discontinued them. Apparently they were never especially stable. Of course, your mileage may vary. I agree it would be an amazingly useful product if indeed it works well. I've also been told that the EPON version they offer is fine, so who knows. -- Brandon Martin From chk at pobox.com Tue Dec 11 22:03:04 2018 From: chk at pobox.com (Harald Koch) Date: Tue, 11 Dec 2018 17:03:04 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: <1544565784.2297487.1606370288.47DB74BC@webmail.messagingengine.com> LinkedIn has a "I don't know this person" option when you decline an invitation. If a user gets too many of those they're kicked, because LinkedIn is explicitly about making cyber connections that you already had IRL. -- Harald From streinerj at gmail.com Tue Dec 11 17:04:20 2018 From: streinerj at gmail.com (Justin M. Streiner) Date: Tue, 11 Dec 2018 12:04:20 -0500 (EST) Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: On Tue, 11 Dec 2018, David Cornejo wrote: > not sure he was complaining about the request, just that it provided > no context or reason why they should link. a personal pet peeve of > mine. Agreed, and I do get unsolicited Linkedin requests quite often. Sometimes, this is clearly the result of someone scraping a list like NANOG in an effort to drum up new business/contacts. Those end up in the bitbucket. It is annoying, but an unfortunate reality these days... Thank you jms From Pratik.Lotia at charter.com Tue Dec 11 22:32:06 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Tue, 11 Dec 2018 22:32:06 +0000 Subject: Should ISP block child pornography? In-Reply-To: <86c6274b-a169-077b-9ba8-83aeef093064@netassist.ua> References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> <97d15929-ec0c-4d71-5557-2b61f34874b0@netassist.ua> <86c6274b-a169-077b-9ba8-83aeef093064@netassist.ua> Message-ID: <73B9A3A7-61C1-4E2F-A47E-41BF7CB9B014@charter.com> Thank you everybody for sharing your views. I think I've got a clear answer. It's better to not go down this slippery path. With Gratitude, Pratik Lotia “Security is like legos. You can build pretty much whatever you want if you have a clear vision of the final product and the skill to put the pieces together correctly.” On 12/11/18, 12:27, "NANOG on behalf of Max Tulyev" wrote: Yes, in some countries (NOT in US, AFAIK) court can issue an order to block IP/domain/URL. If home operator of crime man is blocking the direct access - he have to use TOR/VPN/... to avoid blocking (or may be you really believe he just stop any tries to watch his lovely CP?) If he use TOR/VPN/... to avoid blocking - the original home IP address will be changed to the exit node of TOR/VPN - and we will lost any chance to catch the crime man. Is it clear? 11.12.18 21:06, John Lee пише: > It is my understanding that ISPs block IP addresses and domains under > court order now for copyright violations, criminal activity which would > include CP. They require a court order as they cannot ascertain if it is > CP or not, that is a Law Enforcement decision. The US Supreme Court > decision's was just being nude is not lewd, also with aging software > which can regress photos, LEOs in the US have to ascertain if this is CP > or photo shopped. > > On Tue, Dec 11, 2018 at 12:54 PM Max Tulyev > wrote: > > ...and you will see the TOR exit nodes instead of crime home IP if > censorship is implemented. > > 11.12.18 19:35, Aaron1 пише: > > ... The only thing I can think of is the idea that I’ve heard > before is > > the way to catch someone is to watch them well they are accessing, the > > concept of honeypots comes to mind > > > > Aaron > > > > On Dec 11, 2018, at 10:43 AM, Larry Allen > > >> wrote: > > > >> I can't imagine a single rational argument against this. > >> > >> On Tue, Dec 11, 2018, 10:56 William Anderson > >> > wrote: > >> > >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M > >> > >> > wrote: > >> > >> Hello all, was curious to know the community’s opinion on > >> whether an ISP should block domains hosting CPE (child > >> pornography exploitation) content? Interpol has a ‘worst-of’ > >> list which contains such domains and it wants ISPs to > block it. > >> > >> > >> This already happens in the UK, and has done for years. > >> > >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list > >> > >> > >> -n > >> > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From mis at seiden.com Tue Dec 11 22:37:24 2018 From: mis at seiden.com (mark seiden) Date: Tue, 11 Dec 2018 14:37:24 -0800 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: <0d46d34f-d640-7d80-0496-543a31bdae3b@seiden.com> On 12/11/18 1:53 PM, Mark Foster wrote: > Amazingly I had a sales-type engage with me via InMail just recently, > defending his cold sales approach (spam, basically) when I tried to do the > polite thing and explain why what he was doing was 'bad'. > > Mark. > when on the third un-replied to email asking for a meeting i told one of these sales droids that i had no interest in receiving spam and didn't he get the hint when i didn't reply twice he said "i'm just trying to help". (i said, at least be honest about it.  you're trying to sell me your stuff and mostly help yourself. and complained to linked in about it -- they have a report-spam-or-scam link.  i have no idea what they do with it.) From johnl at iecc.com Tue Dec 11 22:40:14 2018 From: johnl at iecc.com (John Levine) Date: 11 Dec 2018 17:40:14 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: Message-ID: <20181211224014.E3712200B5CC44@ary.qy> In article you write: >Agreed, and I do get unsolicited Linkedin requests quite often. >Sometimes, this is clearly the result of someone scraping a list like >NANOG in an effort to drum up new business/contacts. Those end up in the >bitbucket. When you turn down a connection there should be "I don't know this person" which demotes them somehow. I gather that with enough of those, you can't do invites any more. From rsk at gsp.org Tue Dec 11 22:48:09 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 11 Dec 2018 17:48:09 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: <20181211224809.GA11107@gsp.org> LinkedIn has been spamming since they started. I've got samples sent to me, to mailing lists, to role accounts, to never-existed addresses, to spamtraps, to all kinds of places. My recommendation remains to permanently blacklist them in every mail system you have authority over. ---rsk From kmedcalf at dessus.com Tue Dec 11 22:55:28 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 11 Dec 2018 15:55:28 -0700 Subject: Unsolicited LinkedIn requests In-Reply-To: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: <4aecffd09cf8004aaf635f30bb971c0e@mail.dessus.com> >> Agreed, and I do get unsolicited Linkedin requests quite often. >> Sometimes, this is clearly the result of someone scraping a list >> like NANOG in an effort to drum up new business/contacts. Those >> end up in the bitbucket. > When you turn down a connection there should be "I don't know this > person" which demotes them somehow. I gather that with enough of > those, you can't do invites any more. Permanent Solution: Get rid of LinkedIn (whatever the hillbilly a Linkedin is) --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From gtaylor at tnetconsulting.net Tue Dec 11 23:30:11 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 11 Dec 2018 16:30:11 -0700 Subject: Unsolicited LinkedIn requests In-Reply-To: <4aecffd09cf8004aaf635f30bb971c0e@mail.dessus.com> References: <4aecffd09cf8004aaf635f30bb971c0e@mail.dessus.com> Message-ID: <0347303e-c176-1eb9-17ee-f7950ccdfc74@spamtrap.tnetconsulting.net> On 12/11/2018 03:55 PM, Keith Medcalf wrote: > Permanent Solution: Get rid of LinkedIn (whatever the hillbilly a Linkedin is) I initially created my LinkedIn profile specifically to say I want zero invitations. At the time there was no other way to make LinkedIn /not/ send the invitations. Well, no way that LinkedIn provided. Email filters are a wonderful thing. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From CKimball at misalliance.com Tue Dec 11 21:14:00 2018 From: CKimball at misalliance.com (Chris Kimball) Date: Tue, 11 Dec 2018 21:14:00 +0000 Subject: Unsolicited LinkedIn requests In-Reply-To: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: Sorry that’s me! Often times people post on linked in and I wanted to have it show up in my newsfeed If this isn't allowed let me know and sorry for that! -----Original Message----- From: NANOG On Behalf Of Alfie Pates Sent: Tuesday, December 11, 2018 4:08 PM To: nanog at nanog.org Subject: Unsolicited LinkedIn requests Hi folks, I'm not going to name-and-shame, but I just got a LinkedIn connection request completely out of the blue from somebody with the comment "Greetings from another NANOG user!" I didn't recognise the name, and a quick search of my email history suggests we haven't interacted before. Please don't do this: It's not very polite. ~A - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. From egriliches at gmail.com Tue Dec 11 21:26:25 2018 From: egriliches at gmail.com (Eve Griliches) Date: Tue, 11 Dec 2018 16:26:25 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: That's really lame. On Tue, Dec 11, 2018 at 4:10 PM Alfie Pates wrote: > Hi folks, > > I'm not going to name-and-shame, but I just got a LinkedIn connection > request completely out of the blue from somebody with the comment > "Greetings from another NANOG user!" > > I didn't recognise the name, and a quick search of my email history > suggests we haven't interacted before. > > Please don't do this: It's not very polite. > > ~A > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipc at phmgmt.com Tue Dec 11 21:44:28 2018 From: phillipc at phmgmt.com (Phillip Carroll) Date: Tue, 11 Dec 2018 21:44:28 +0000 Subject: Unsolicited LinkedIn requests In-Reply-To: <10e178ad533a4a598ccaf2c98a22bf42@phmgmt.com> References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> <10e178ad533a4a598ccaf2c98a22bf42@phmgmt.com> Message-ID: Don't complain about people adding you on social media when you sign-up for social media. I can only assume you are complaining to get more views on your social media. I help in your endeavors I have listed your social media's I could find in a quick search. https://www.alfiepates.me/ https://www.linkedin.com/in/alfiepates/ https://en.wikipedia.org/wiki/File:Alfie_Pates_Self-Portrait_2017.jpg https://github.com/alfiepates https://pgp.cs.uu.nl/stats/654a98a79ac41734.html https://www.instagram.com/alfiepates/?hl=en https://www.flickr.com/photos/alfiepates/ https://keybase.io/alfiepates https://www.youtube.com/channel/UCI_1D5aDl30EnvQI6JsOmBw https://soundcloud.com/alfie-pates https://wiki.edinburghhacklab.com/people:alfie https://twitter.com/AlfiePates https://foursquare.com/alfiepates v1apates at inf.ed.ac.uk alfie at alfiepates.me http://lmgtfy.com/?q=alfiepates -----Original Message----- From: NANOG On Behalf Of Alfie Pates Sent: Tuesday, December 11, 2018 3:08 PM To: nanog at nanog.org Subject: Unsolicited LinkedIn requests Hi folks, I'm not going to name-and-shame, but I just got a LinkedIn connection request completely out of the blue from somebody with the comment "Greetings from another NANOG user!" I didn't recognise the name, and a quick search of my email history suggests we haven't interacted before. Please don't do this: It's not very polite. ~A From omer at chronos.com.tr Tue Dec 11 22:02:47 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Wed, 12 Dec 2018 01:02:47 +0300 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: <9d19fd36cf810472da9b5274cf0fd325@chronos.com.tr> Well, that must be my curse... Even when adblocker doesn't notify me, I have stuff blocking stuff... :) M. OMER GOLGELI --- AS202365 [1] https://as202365.peeringdb.com [2] https://bgp.he.net/AS202365 [1] NOC: Phone: +90-533-2600533 Email: omer at chronos.com.tr On 2018-12-12 00:57, Daniel Corbe wrote: > at 4:48 PM, M. Omer GOLGELI wrote: > Well said... > > But I can't see that on his website... > > M. OMER GOLGELI > --- > AS202365 > > On 2018-12-12 00:39, Daniel Corbe wrote: > If you don't want people contacting you on Linkedin then why do you > have a link to your profile on your website? > at 4:08 PM, Alfie Pates wrote: > Hi folks, > I'm not going to name-and-shame, but I just got a LinkedIn connection request completely out of the blue from somebody with the comment "Greetings from another NANOG user!" > I didn't recognise the name, and a quick search of my email history suggests we haven't interacted before. > Please don't do this: It's not very polite. > ~A Links: ------ [1] https://bgp.he.net/AS202365 [2] https://as202365.peeringdb.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at chronos.com.tr Tue Dec 11 22:12:41 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Wed, 12 Dec 2018 01:12:41 +0300 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <1544562500.1249347.1606313040.1F412457@webmail.messagingengine.com> Message-ID: Well, that must be my curse... Even when adblocker doesn't notify me, I have stuff blocking stuff... :) M. OMER GOLGELI --- AS202365 [1] https://as202365.peeringdb.com [2] https://bgp.he.net/AS202365 [1] NOC: Phone: +90-533-2600533 Email: omer at chronos.com.tr On 2018-12-12 00:57, Daniel Corbe wrote: > at 4:48 PM, M. Omer GOLGELI wrote: > Well said... > > But I can't see that on his website... > > M. OMER GOLGELI > --- > AS202365 > > On 2018-12-12 00:39, Daniel Corbe wrote: > If you don't want people contacting you on Linkedin then why do you > have a link to your profile on your website? > at 4:08 PM, Alfie Pates wrote: > Hi folks, > I'm not going to name-and-shame, but I just got a LinkedIn connection request completely out of the blue from somebody with the comment "Greetings from another NANOG user!" > I didn't recognise the name, and a quick search of my email history suggests we haven't interacted before. > Please don't do this: It's not very polite. > ~A Links: ------ [1] https://bgp.he.net/AS202365 [2] https://as202365.peeringdb.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Wed Dec 12 00:21:43 2018 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 11 Dec 2018 19:21:43 -0500 Subject: Should ISP block child pornography? In-Reply-To: References: <864C7E5A-5508-431F-AA9E-6DAC652DDE3D@charter.com> Message-ID: On 12/11/18 11:43 AM, Larry Allen wrote: > On Tue, Dec 11, 2018, 10:56 William Anderson >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M >> wrote: >> >>> Hello all, was curious to know the community’s opinion on whether an ISP >>> should block domains hosting CPE (child pornography exploitation) content? >>> Interpol has a ‘worst-of’ list which contains such domains and it wants >>> ISPs to block it. >>> >> >> This already happens in the UK, and has done for years. >> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list > I can't imagine a single rational argument against this. I've fixed your broken quoting. The simple argument against this; once a system is in place to block cp, it can be used for other things. Don't like a political party? lets add it as extreme "speech" to the list, then we can add AR-15 3d plans and it goes down from there. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From dcorbe at hammerfiber.com Wed Dec 12 00:28:48 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 11 Dec 2018 19:28:48 -0500 Subject: Unsolicited LinkedIn requests In-Reply-To: <20181211224014.E3712200B5CC44@ary.qy> References: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: at 5:40 PM, John Levine wrote: > In article you > write: >> Agreed, and I do get unsolicited Linkedin requests quite often. >> Sometimes, this is clearly the result of someone scraping a list like >> NANOG in an effort to drum up new business/contacts. Those end up in the >> bitbucket. > > When you turn down a connection there should be "I don't know this > person" which demotes them somehow. I gather that with enough of > those, you can't do invites any more. This was the case back when LinkedIn were actively enforcing their TOS. LinkedIn was largely started as and designed to be a referral service. As far as I can tell though, they’ve been letting strangers freely connect with one another for years now. -Daniel From mehmet at akcin.net Wed Dec 12 00:39:12 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 11 Dec 2018 22:39:12 -0200 Subject: Steam and Fortnite network contacts Message-ID: hi there, i am looking for fortnite and steam network/performance team contacts to discuss a performance issue. thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From blakjak at blakjak.net Wed Dec 12 02:19:38 2018 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 12 Dec 2018 15:19:38 +1300 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: > at 5:40 PM, John Levine wrote: > >> In article you >> write: >>> Agreed, and I do get unsolicited Linkedin requests quite often. >>> Sometimes, this is clearly the result of someone scraping a list like >>> NANOG in an effort to drum up new business/contacts. Those end up in >>> the >>> bitbucket. >> >> When you turn down a connection there should be "I don't know this >> person" which demotes them somehow. I gather that with enough of >> those, you can't do invites any more. > > This was the case back when LinkedIn were actively enforcing their TOS. > LinkedIn was largely started as and designed to be a referral service. > As > far as I can tell though, they’ve been letting strangers freely connect > with one another for years now. > I've seen success with the 'I don't know this person' feedback system as well, and encourage it's use. Unfortunately for LinkedIn there's a whole breed of L.I.O.N. (LinkedIn Open Networker) folks who believe in extending their social circle first and breeding connections from there. Somewhat akin to Twitter users who blindly follow everyone they come across, mainly in the hope of a reciprocal follow and not because they have any intent to interact with the person they're following, or even ever read their timeline. It's exposure, exposure, exposure. Mark. From mike.lyon at gmail.com Wed Dec 12 02:24:22 2018 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 11 Dec 2018 18:24:22 -0800 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: And for one that SPAM message that was sent to you on LI, now you've made a bunch of SPAM for all the NANOG folks to read through. Thanks for that... -Mike On Tue, Dec 11, 2018 at 6:21 PM Mark Foster wrote: > > at 5:40 PM, John Levine wrote: > > > >> In article you > >> write: > >>> Agreed, and I do get unsolicited Linkedin requests quite often. > >>> Sometimes, this is clearly the result of someone scraping a list like > >>> NANOG in an effort to drum up new business/contacts. Those end up in > >>> the > >>> bitbucket. > >> > >> When you turn down a connection there should be "I don't know this > >> person" which demotes them somehow. I gather that with enough of > >> those, you can't do invites any more. > > > > This was the case back when LinkedIn were actively enforcing their TOS. > > LinkedIn was largely started as and designed to be a referral service. > > As > > far as I can tell though, they’ve been letting strangers freely connect > > with one another for years now. > > > > I've seen success with the 'I don't know this person' feedback system as > well, and encourage it's use. > > Unfortunately for LinkedIn there's a whole breed of L.I.O.N. (LinkedIn > Open Networker) folks who believe in extending their social circle first > and breeding connections from there. > > Somewhat akin to Twitter users who blindly follow everyone they come > across, mainly in the hope of a reciprocal follow and not because they > have any intent to interact with the person they're following, or even > ever read their timeline. It's exposure, exposure, exposure. > > Mark. > > > -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Wed Dec 12 02:59:46 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Tue, 11 Dec 2018 18:59:46 -0800 Subject: IXPDB Message-ID: Hello, I am one of the operators of EVIX and we recently made data available via IX-F Member Export JSON which is also sometimes known as IXPDB JSON. Someone, who I am unclear if it is IX-F, Euro-IX, someone else, or maybe all of them are the same people, has a list of IXPs, especially those with this JSON data. Accompanying that, are participants to these exchanges, all of the route servers or all the exchanges in one large list, and IXP switches, which is slightly odd. This resource is available at https://ixpdb.euro-ix.net/en/ixpdb/providers/. Now that we have the JSON data available we are wondering how to become part of the list. Does anyone have a contact for someone affiliated with this list? At this point the best we can do is email the contacts listed at the bottom of the github page for the schema (https://github.com/euro-ix/json-schemas). Thank you to anyone that can assist. Thanks ~ Bryce Wilson, AS202313, EVIX AS137933 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Dec 12 04:56:15 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 11 Dec 2018 23:56:15 -0500 Subject: Spam on NANOG (was "Unsolicited LinkedIn requests") In-Reply-To: References: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: While I agree that some of the replies to the original message were not entirely necessary, I would not go so far as to consider them "spam". In any conversation, sometimes people say things you are not interested in hearing. Being a member of a mailing list is like being a part of many conversations at once - some of them will be interesting, some will not, and some will be a mix of both. I don't think it's productive to complain that you are getting messages you don't want. We all are. That's just how it is. I would recommend using sorting rules in your mail client of choice to put NANOG emails into a dedicated folder. It makes it easier to sort out the noise. On Tue, Dec 11, 2018 at 9:26 PM Mike Lyon wrote: > And for one that SPAM message that was sent to you on LI, now you've made > a bunch of SPAM for all the NANOG folks to read through. > > Thanks for that... > > -Mike > > > On Tue, Dec 11, 2018 at 6:21 PM Mark Foster wrote: > >> > at 5:40 PM, John Levine wrote: >> > >> >> In article >> you >> >> write: >> >>> Agreed, and I do get unsolicited Linkedin requests quite often. >> >>> Sometimes, this is clearly the result of someone scraping a list like >> >>> NANOG in an effort to drum up new business/contacts. Those end up in >> >>> the >> >>> bitbucket. >> >> >> >> When you turn down a connection there should be "I don't know this >> >> person" which demotes them somehow. I gather that with enough of >> >> those, you can't do invites any more. >> > >> > This was the case back when LinkedIn were actively enforcing their TOS. >> > LinkedIn was largely started as and designed to be a referral service. >> > As >> > far as I can tell though, they’ve been letting strangers freely connect >> > with one another for years now. >> > >> >> I've seen success with the 'I don't know this person' feedback system as >> well, and encourage it's use. >> >> Unfortunately for LinkedIn there's a whole breed of L.I.O.N. (LinkedIn >> Open Networker) folks who believe in extending their social circle first >> and breeding connections from there. >> >> Somewhat akin to Twitter users who blindly follow everyone they come >> across, mainly in the hope of a reciprocal follow and not because they >> have any intent to interact with the person they're following, or even >> ever read their timeline. It's exposure, exposure, exposure. >> >> Mark. >> >> >> > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Dec 12 06:14:44 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 12 Dec 2018 01:14:44 -0500 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: I don't really have any advice to offer here (sorry), but I am curious how setting up a GPON LAN would save money vs just getting cheaper switches...and also what a GPON LAN even looks like. Does every office or classroom have an ONT? On Tue, Dec 11, 2018 at 10:53 AM Nick Bogle wrote: > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network > Engineer for a local university where we have primarily a Cisco environment > from phones to switching to routing, etc. Before my time, we hired a > contractor to design a GPON LAN system for a new building as a cost saving > measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we > have gone through the training and such, and I feel confident in my ability > to manage the system, but we have a few questions that the manufacturer of > our equipment and our contractor didn't really want to answer. We are > currently using a Dasan Zhone MXK-F1419 with several different downstream > ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the > linecards to add redundancy to the splitter (as the cost of 1st party are > too high). Does anyone have experience with 3rd party > vendors/compatibility/stability issues? We were told they theoretically > should work and just throw a log event, but it hasn't been tested. If so, > what vendors would you recommend? So far all we've really seen are Ubiquiti > and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and > ONT vendors is heavily limited.. Does anyone have any experience using say, > Zhone ONT's with a different model OLT, or Zhone ONT's with a different > model OLT? I've heard word that Zhone ONT's may be able to work with Nokia > OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced > 1 line card 5 times..), our contractor is saying it's just because we were > a pretty early adopter of this line and that they've fixed it and fixed > internal policies to add additional QA and testing before shipping to > customers. Does anyone have any experience with working with Zhone and > their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a > corporate LAN? (or about deploying a Zhone solution) It's pretty service > provider oriented, and is incredible noticeable in the CLI. > > -Is anyone familiar with Zhone CLI? The apparent lack of any "show" > configuration commands is infuriating. > > > Feel free to contact me offlist if you have any pertinent info that you > don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Dec 12 06:46:41 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 12 Dec 2018 07:46:41 +0100 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 7:16 AM Ross Tajvar wrote: > I don't really have any advice to offer here (sorry), but I am curious how > setting up a GPON LAN would save money vs just getting cheaper > switches...and also what a GPON LAN even looks like. Does every office or > classroom have an ONT? > >> >> Hi Ross Every room will have a small switch style ONT. These devices can have a small battery for power outages and provide PoE to voice over IP phones. Typically the ONT switch has from 4 to 24 copper ethernet ports. The building will have a tree like structure of splitters. For example if there are four floors, you might have a 1:4 splitter at the entrance to the building, then on each floor you could have another 1:4 splitter to four sections and then in each section you might have a 1:8 splitter to provide network to 8 rooms. Of course this could be designed in many different configurations depending on the needs and layout of the building. The maximum combined splits is 128. In my example we had 4*4*8 = 128 splits. If you need more, you will deploy additional OLT ports with new splitter trees. As to cheaper I can not say. I am not selling any of this stuff. I can say that the price for a small 4 port ONT switch is about USD 50 to 100. The battery is extra but not very expensive. It is just a small cell phone style battery that plugs directly into the ONT, not a full UPS system. It is possible to build this with redundancy. I suspect it is rarely done. The redundancy works in the way, that the 1:8 splitter can be replaced with a 2:8 splitter. This has the same power budget, but you get two input ports to the splitter. Only one can be active at a time. The GPON OLT switch needs to coordinate which of the input ports is used. How that is done is vendor specific. You would build an independent backbone tree for the second input port to the splitter. It is possible one should not choose this system over a traditional approach, but the people screaming "rip it out" are out of line IMHO. It would be a huge expense to rewire a building with copper and they already got a working fiber system. Much can be said about GPON but it is actually quite stable and easy to manage. Compared to the traditional approach, you will only have one centralized GPON switch to manage. All the small ONT switches are managed through this. Complaints about the interface is vendor specific. Because there is only one centralized switch, it would be fairly cheap to switch vendor. Much cheaper than to rewire with copper in any case. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Wed Dec 12 09:15:44 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Wed, 12 Dec 2018 09:15:44 +0000 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, 12 Dec 2018 at 06:48, Baldur Norddahl wrote: > It is possible one should not choose this system over a traditional approach, but the people screaming "rip it out" are out of line IMHO. It would be a huge expense to rewire a building with copper and they already got a working fiber system. Much can be said about GPON but it is actually quite stable and easy to manage. I don't think anyone is saying replace the existing fibre with copper, but instead to run cheap SFP-equipped switches in basically the same topology as the GPON you described. For a new build, less splitting and more copper in-building would be cheaper and easier. Aled From jared at puck.nether.net Wed Dec 12 09:44:07 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 12 Dec 2018 04:44:07 -0500 Subject: A few GPON questions... In-Reply-To: References: Message-ID: I have tested a variety of equipment as part of my FTTH enterprise. Active Ethernet is where I’m still sitting because I’m not quite happy with some of the PON hardware out there personally. Yes active solutions provide more flexibility in one area but they are only viable in dense environments where the cost to build is already high and the fiber count is cheap comparably. If you are within the b+ optics link budget there are options, but if you are spliced at your splitters any migration may be tricky. I’ve been doing 2F drop to the home so I can later to technology migration as the cost variance is about 7c for 1F vs 10c/ft for 2F. It’s a bit more as those drops are the longer portion vs the backbone legs, but I can change from active to GPON or back without trouble. It sounds like you have a typical vendor management problem where the equipment isn’t meeting your needs. Find a way to migrate to something else. Hopefully you have spare plant and budget to move to something else. If it’s homes, hopefully you can do a migration without coordination and entering the home, if it’s office campus see if you can DWDM or CWDM to get the capacity you need or there are other hardware like the UBNT OLT out there. A lot of the smaller FTTH types are also using the Huwaei hardware. Qualifying a vendor is hard and they change. I’ve spent decades working with my vendors trying to encourage them to do the right thing. The story you tell is a typical one of overworked employees without the power to fix the problems they see. As others said I would consider a change as your business risk may be too high. This is where network operation becomes business risk mitigation. - Jared Sent from my iCar > On Dec 6, 2018, at 10:18 PM, Nick Bogle wrote: > > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network Engineer for a local university where we have primarily a Cisco environment from phones to switching to routing, etc. Before my time, we hired a contractor to design a GPON LAN system for a new building as a cost saving measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we have gone through the training and such, and I feel confident in my ability to manage the system, but we have a few questions that the manufacturer of our equipment and our contractor didn't really want to answer. We are currently using a Dasan Zhone MXK-F1419 with several different downstream ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the linecards to add redundancy to the splitter (as the cost of 1st party are too high). Does anyone have experience with 3rd party vendors/compatibility/stability issues? We were told they theoretically should work and just throw a log event, but it hasn't been tested. If so, what vendors would you recommend? So far all we've really seen are Ubiquiti and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and ONT vendors is heavily limited.. Does anyone have any experience using say, Zhone ONT's with a different model OLT, or Zhone ONT's with a different model OLT? I've heard word that Zhone ONT's may be able to work with Nokia OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced 1 line card 5 times..), our contractor is saying it's just because we were a pretty early adopter of this line and that they've fixed it and fixed internal policies to add additional QA and testing before shipping to customers. Does anyone have any experience with working with Zhone and their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a corporate LAN? (or about deploying a Zhone solution) It's pretty service provider oriented, and is incredible noticeable in the CLI. > > Feel free to contact me offlist if you have any pertinent info that you don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Dec 12 12:35:21 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 12 Dec 2018 13:35:21 +0100 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 10:16 AM Aled Morris wrote: > On Wed, 12 Dec 2018 at 06:48, Baldur Norddahl > wrote: > > It is possible one should not choose this system over a traditional > approach, but the people screaming "rip it out" are out of line IMHO. It > would be a huge expense to rewire a building with copper and they already > got a working fiber system. Much can be said about GPON but it is actually > quite stable and easy to manage. > > I don't think anyone is saying replace the existing fibre with copper, > but instead to run cheap SFP-equipped switches in basically the same > topology as the GPON you described. > That would still be costly in time and money with no obvious gain. You would get some downsides however. Now you have many single point of failures, a lot of small switches at the splitting points that need power backup and be managed. And exactly the same issue with PoE that someone raised. Only you will find more GPON ONT switches that already have the PoE with a battery build in, because those devices where made to answer that. Again not saying that you would make a new build in any particular way, but to rip anything out of a brand new build requires justification. The original poster might indeed have justifications, but the people recommending to "rip it out" does not appear to have anything, but that this is GPON technology. If your justification is that you only want to work with technology known to you, then it is maybe you that needs to be replaced. It is certainly possible to build something close to the GPON system using WDM instead. It is going to be more expensive. GPON splitters are very cheap, WDM splitters less so and the DWDM SFP modules way more expensive than the typical ONT. CWDM modules can be the same price as the ONT but you need to add a switch to that. You will also have a problem with the multi level tree approach. > For a new build, less splitting and more copper in-building would be > cheaper and easier. > Maybe. Those big fat copper runs get unwieldy and take up a lot of space. That GPON system might have a 12 fiber, 3 mm cable as the backbone and a maximum of 8 drop cables (2-3 mm) from the splitter. The drop cables are much smaller than cat 6 cabling. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis at netviscom.com Wed Dec 12 14:08:02 2018 From: travis at netviscom.com (Travis Garrison) Date: Wed, 12 Dec 2018 14:08:02 +0000 Subject: Looking for Telecom Lawyer Message-ID: We are looking for a Telecom Lawyer to help us be a CLEC in the Arkansas, Kansas, Nebraska, Iowa and Oklahoma areas. Also we are looking to setup agreements for peering, transport and resell for ATT and CenturyLink in the same areas and Missouri. We are already a CLEC in Missouri. Thank you Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipc at phmgmt.com Wed Dec 12 17:43:05 2018 From: phillipc at phmgmt.com (Phillip Carroll) Date: Wed, 12 Dec 2018 17:43:05 +0000 Subject: Looking for Telecom Lawyer In-Reply-To: References: Message-ID: <447d62d613fc481eb2e4a3d407045885@phmgmt.com> https://telecomlawyer.net/ https://commlawgroup.com/attorneys/jonathan-s-marashlian/ http://www.telecomlawattorney.com/ http://telecomlawfirm.com/ http://www.telecomlawyers.com/ From: NANOG On Behalf Of Travis Garrison Sent: Wednesday, December 12, 2018 8:08 AM To: North American Network Operators' Group Subject: Looking for Telecom Lawyer We are looking for a Telecom Lawyer to help us be a CLEC in the Arkansas, Kansas, Nebraska, Iowa and Oklahoma areas. Also we are looking to setup agreements for peering, transport and resell for ATT and CenturyLink in the same areas and Missouri. We are already a CLEC in Missouri. Thank you Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 12 18:51:32 2018 From: bill at herrin.us (William Herrin) Date: Wed, 12 Dec 2018 10:51:32 -0800 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Tue, Dec 11, 2018 at 10:47 PM Baldur Norddahl wrote: > Compared to the traditional approach, you will only have one centralized > GPON switch to manage. All the small ONT switches are managed through > this. Complaints about the interface is vendor specific. Because there is only > one centralized switch, it would be fairly cheap to switch vendor. Much cheaper > than to rewire with copper in any case. Except you won't have one central GPON switch because LANs change incrementally. That throwback in office 412 with the fax machine? Can't simply buy him a pots line. You get to futz with fax over the converged phone system. Speaking of the converged phone system, you're now committed to VoIP on a VLAN. When you decide you want to switch to a physically separated network for the phones, well, that's too bad because your cabling infrastructure doesn't make that possible. The AV lab gets screwed. You're running the coax they need through the noisy electrical riser because you didn't build dedicated comms risers and closets. Naturally nobody checked with them so you don't yet realize they can't do what they need to do with video over IP equipment. And what will you do in 5 years when they want the computer lab in 204 upgraded to 100Gig? Maybe run some fiber all the way back to the campus head end because as expensive as that is, it's still cheaper than replacing the OLT with 100-gig capable equipment and then replacing all the ONTs in the building because oops, there's no 100 gig OLT compatible with the old ONTs and you'd have to take the building down for a week to forklift-upgrade the whole mess. Folks have advised Nick rip it out now because they foresee the slow-motion train wreck on its way. That may be extreme, but certainly he should take immediate action to preserve his options. For example, I would demand the creation of comms closets and risers before the building opened and I'd threaten to quit if they weren't. At least then the inevitable modifications can be structured and planned instead of turning in to an ad-hoc mess. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From cjwolff at nola.gov Wed Dec 12 19:51:35 2018 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Wed, 12 Dec 2018 19:51:35 +0000 Subject: Looking for an compromise of an enterprise network from a mobile device Message-ID: <47F264CE123954429FC99B9E768819F29ACFEE88@CNO-XCH02.cityofno.com> Hello NANOG, I'm working on a presentation and need your help. I'm looking for a case study where a compromised iOS, Android or other mobile device was utilized as a backdoor to compromise an enterprise network. Any help will be appreciated. Regards, Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan at allan.vin Wed Dec 12 20:01:31 2018 From: allan at allan.vin (Allan Liska) Date: Wed, 12 Dec 2018 20:01:31 +0000 Subject: Looking for an compromise of an enterprise network from a mobile device In-Reply-To: <47F264CE123954429FC99B9E768819F29ACFEE88@CNO-XCH02.cityofno.com> References: <47F264CE123954429FC99B9E768819F29ACFEE88@CNO-XCH02.cityofno.com> Message-ID: It is an older example, but the DressCode was able to infect enterprise networks from compromised Android phones and, according to Trend Micro it did: [https://blog.trendmicro.com/trendlabs-security-intelligence/dresscode-potential-impact-enterprises/](https://blog.trendmicro.com/trendlabs-security-intelligence/dresscode-potential-impact-enterprises/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Anti-MalwareBlog+%28Trendlabs+Security+Intelligence+Blog%29) allan ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, December 12, 2018 2:51 PM, Christopher J. Wolff wrote: > Hello NANOG, > > I’m working on a presentation and need your help. I’m looking for a case study where a compromised iOS, Android or other mobile device was utilized as a backdoor to compromise an enterprise network. Any help will be appreciated. > > Regards, > > Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Dec 12 20:09:03 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 12 Dec 2018 21:09:03 +0100 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 7:51 PM William Herrin wrote: > On Tue, Dec 11, 2018 at 10:47 PM Baldur Norddahl > wrote: > > Compared to the traditional approach, you will only have one centralized > > GPON switch to manage. All the small ONT switches are managed through > > this. Complaints about the interface is vendor specific. Because there > is only > > one centralized switch, it would be fairly cheap to switch vendor. Much > cheaper > > than to rewire with copper in any case. > > Except you won't have one central GPON switch because LANs change > incrementally. > In my experience, a PON network is extremely flexible. Our FTTH network is ever expanding and there is no master plan. Whenever people in existing areas decide to buy our product or whenever people in a new area decides to take a vote to get us in their area, the network will expand as needed. Often we will discover that we could not make a planed crossing because of something in the ground, but we can just change plans and do it another place. We have a competitor that decided to use p2p (point to point ethernet over fiber) instead and I have watched how they are struggling because they had to plan everything from the outset, and we didn't. The reason being that we use very little fiber for our backbone and can afford to change plans constantly. They need to backhaul hundreds or thousands of fiber strands to the central point, where they have the switches. > > That throwback in office 412 with the fax machine? Can't simply buy > him a pots line. You get to futz with fax over the converged phone > system. > GPON is actually ATM and will provide hard realtime bandwidth guarantees. ISDN delivery over GPON is part of the standard. You will reserve 2x64 Kbit/s channels and GPON guarantees that will always be 100% available with no dropped frames and no jitter. You can do fax, modems, anything that the public phone service will carry over ATM. I have not personally tried this out as fax and modems are completely dead in my part of the world and nobody cares. But I have had a ONT (from Zhone no less) with ISDN ports (not POTS) and thought they are crazy. > > Speaking of the converged phone system, you're now committed to VoIP > on a VLAN. When you decide you want to switch to a physically > separated network for the phones, well, that's too bad because your > cabling infrastructure doesn't make that possible. > Nothing stops you from deploying two independent GPON networks, one for ISDN service and the other for data service. Typically the drop cables will be at least 2 fibers (GPON runs on a single fiber) so you would not need to change anything. In my example the backbone would need a maximum of 7 fibers. With a duplicated GPON network, that would be 14 fibers in the backbone. Personally I think duplicated networks are silly. But who am I to decide? > > The AV lab gets screwed. You're running the coax they need through the > noisy electrical riser because you didn't build dedicated comms risers > and closets. Naturally nobody checked with them so you don't yet > realize they can't do what they need to do with video over IP > equipment. > Fiber will transmit anything that goes on coax as analog signals. Typically on 1550 nm. The converters are dead cheap and are purely analog devices. This is how we deliver TV on a FTTH GPON network. GPON uses 1310 nm for upstream data, 1490 for downstream data and 1550 nm for analog TV. When I say analog TV that is really DVB digital signal these days, but the equipment does not know any of that and just transmits it as an analog signal. Many GPON ONT for residential use come with a coax TV out port that can be turned on and off remotely, so the ISP can control TV delivery. Some also have build in filters that can be remote controlled, so you can have multiple TV packages using the usual system of filtering frequencies on the coax. > > And what will you do in 5 years when they want the computer lab in 204 > upgraded to 100Gig? Maybe run some fiber all the way back to the > campus head end because as expensive as that is, it's still cheaper > than replacing the OLT with 100-gig capable equipment and then > replacing all the ONTs in the building because oops, there's no 100 > gig OLT compatible with the old ONTs and you'd have to take the > building down for a week to forklift-upgrade the whole mess. > One advantage of a fiber to the desktop solution is that you have fiber to every room. You just move a drop cable from the splitter and to a pair of backbone fibers. With this you can get a dedicated connection from any room to any other room including back to your data center. Yes you will have extra dark fibers available, anything else would be stupid. > > Folks have advised Nick rip it out now because they foresee the > slow-motion train wreck on its way. That may be extreme, but certainly > he should take immediate action to preserve his options. For example, > I would demand the creation of comms closets and risers before the > building opened and I'd threaten to quit if they weren't. At least > then the inevitable modifications can be structured and planned > instead of turning in to an ad-hoc mess. > This is out of line IMHO. Hopefully they did add in extra conduits so you could do some special cable runs (including some copper and coax), if needed. But if they did not, it would be the responsibility of management, not yours. It also has nothing to do with fiber nor GPON. Plenty of copper builds have a severe lack of space for future proving. If they did the fiber build in the recommended way, there will be ducts prepared for fiber blowing, so one quickly can add more fiber cabling. I find it silly to threaten to quit if they wont make closets, that are then going to be empty. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Wed Dec 12 21:22:31 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 12 Dec 2018 14:22:31 -0700 Subject: Looking for Telecom Lawyer In-Reply-To: References: Message-ID: > On Dec 12, 2018, at 7:08 AM, Travis Garrison wrote: > > We are looking for a Telecom Lawyer to help us be a CLEC in the Arkansas, Kansas, Nebraska, Iowa and Oklahoma areas. Also we are looking to setup agreements for peering, transport and resell for ATT and CenturyLink in the same areas and Missouri. We are already a CLEC in Missouri. > Travis, contact Laura Miller: https://scarincihollenbeck.com/attorneys/laura-m-miller/ Tell her that Crystal Prais (a former colleague) referred you. Crystal says that she is, and I quote, "fantastic". Anne --- Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From nick at bogle.se Wed Dec 12 21:25:32 2018 From: nick at bogle.se (Nick Bogle) Date: Wed, 12 Dec 2018 13:25:32 -0800 Subject: Extending network over a dry pair Message-ID: A quick question for you guys; If you had a single dry pair (pair of copper wires originally for phones) to a remote site that was around 6 miles away, what would you use? We currently are just extending a T1 line to this site, but 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site on a federally protected wildlife preserve so we can't run any new infrastructure (fiber etc) and it isn't in a geographical place where point to point wireless is practical. We were thinking there is some sort of network extender that uses some form of DSL for higher bandwidth capacity. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis at netviscom.com Wed Dec 12 21:28:03 2018 From: travis at netviscom.com (Travis Garrison) Date: Wed, 12 Dec 2018 21:28:03 +0000 Subject: Looking for Telecom Lawyer In-Reply-To: References: Message-ID: Thanks everyone that replied, we have quite a list now to dig through. Thanks Travis From: NANOG On Behalf Of Travis Garrison Sent: Wednesday, December 12, 2018 8:08 AM To: North American Network Operators' Group Subject: Looking for Telecom Lawyer We are looking for a Telecom Lawyer to help us be a CLEC in the Arkansas, Kansas, Nebraska, Iowa and Oklahoma areas. Also we are looking to setup agreements for peering, transport and resell for ATT and CenturyLink in the same areas and Missouri. We are already a CLEC in Missouri. Thank you Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Wed Dec 12 21:28:20 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 12 Dec 2018 13:28:20 -0800 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On 12/12/18 10:51 AM, William Herrin wrote: > The AV lab gets screwed. You're running the coax they need through the > noisy electrical riser because you didn't build dedicated comms risers > and closets. Naturally nobody checked with them so you don't yet > realize they can't do what they need to do with video over IP > equipment. There are double-shield coax solutions for noisy risers. The outer shield is grounded to the conduit, while the inner shield is grounded at the source equipment. One has to be sure that the voltage differential between shields is kept as low as practical, which means paying attention to grounding for the conduit AND equipment. From lathama at gmail.com Wed Dec 12 21:33:06 2018 From: lathama at gmail.com (Andrew Latham) Date: Wed, 12 Dec 2018 15:33:06 -0600 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 3:27 PM Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? We > currently are just extending a T1 line to this site, but 1.5Mbps isn't > cutting it anymore. Unfortunately it's a research site on a federally > protected wildlife preserve so we can't run any new infrastructure (fiber > etc) and it isn't in a geographical place where point to point wireless is > practical. We were thinking there is some sort of network extender that > uses some form of DSL for higher bandwidth capacity. > > Any suggestions? > Look for an SHDSL Ethernet Extender -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvandolson at esri.com Wed Dec 12 21:33:42 2018 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 12 Dec 2018 13:33:42 -0800 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <20181212213341.GA6253@esri.com> On Wed, Dec 12, 2018 at 01:25:32PM -0800, Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for > phones) to a remote site that was around 6 miles away, what would you > use? We currently are just extending a T1 line to this site, but > 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site > on a federally protected wildlife preserve so we can't run any new > infrastructure (fiber etc) and it isn't in a geographical place where > point to point wireless is practical. We were thinking there is some > sort of network extender that uses some form of DSL for higher > bandwidth capacity. > > Any suggestions? There's this[1], but only rated at one mile. This one[2] claims it can support 15.3Mbps over a single pair. Ray [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amazon.com_Tupavco-2DEthernet-2DExtender-2DKit-2DRepeater-2DVDSL_dp_B01BOD8C9W_ref-3Dpd-5Fcp-5F147-5F2-3Fpd-5Frd-5Fw-3DjJF6B-26pf-5Frd-5Fp-3Def4dc990-2Da9ca-2D4945-2Dae0b-2Df8d549198ed6-26pf-5Frd-5Fr-3DYNZSNN4KVFDD0D7F28BC-26pd-5Frd-5Fr-3Dff2a9a7f-2Dfe54-2D11e8-2D9eb5-2Dcbf5e1b9be77-26pd-5Frd-5Fwg-3DYAFyN-26pd-5Frd-5Fi-3DB01BOD8C9W-26psc-3D1-26refRID-3DYNZSNN4KVFDD0D7F28BC&d=DwIBAg&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=TbF7NHyAPYAnOTcN0mP5L8Mx9bruJ3BQiMGiRuuEjag&s=1uB8i1QuuStq_4H-v8E2AvAuFwvzubQ5sfUHK81L598&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.patton.com_ethernet-2Dextender_cl1314mde_&d=DwIBAg&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=TbF7NHyAPYAnOTcN0mP5L8Mx9bruJ3BQiMGiRuuEjag&s=giCSQ1Y-mYPf-JQmTFLfqlg34eDZuCD87ScHf0sOR20&e= From alfie at fdx.services Wed Dec 12 21:34:29 2018 From: alfie at fdx.services (Alfie Pates) Date: Wed, 12 Dec 2018 21:34:29 +0000 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: <1544650469.3384147.1607496576.172FF411@webmail.messagingengine.com> The discussion was regarding an in-building LAN - residential access networks/WANs are a wholly different beast and GPON is fantastically suitable for that particular problem. There is, however, a reason that a lot of new mixed-use (business && residential) WAN fibre deployments end up building a home-run dark fibre network for business use and overbuilding with GPON for residential use - the 1-1 mapping of end users to patch points/flexibility points makes for a vastly more future-proof network. I think we often underestimate just how long the networks we install stick around. I ordered a 10Gbit/s service not too long ago over the very same fibre that was used to serve 2Mbit/s connections in the mid 90s: I'm not kidding, the fibre was physically disconnected from an old, derelict 2Mbit/s SDH network termination and plugged into a brand new 10Gbit/s EDD. GPON is cool, definitely - I've worked on very large scale GPON deployments before, and it is definitely a very useful technology that allows us to affordably deploy high-bandwidth consumer and small- business connectivity. However - it is a compromise, and I don't think you're gaining anything by running GPON versus the tried-and-tested method of active, switch- based aggregation, especially compared to the sacrifices you make deploying a passively-aggregated network. As I said before - I wouldn't stake my reputation on it. ~A -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Wed Dec 12 21:35:01 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 12 Dec 2018 16:35:01 -0500 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: Something LRE possibly. Could just do VDSL. Are you just looking at more than 1544 kbps or is there a particular threshold you need to meet (to support a camera, etc)? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Dec 12, 2018 at 4:26 PM Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? We > currently are just extending a T1 line to this site, but 1.5Mbps isn't > cutting it anymore. Unfortunately it's a research site on a federally > protected wildlife preserve so we can't run any new infrastructure (fiber > etc) and it isn't in a geographical place where point to point wireless is > practical. We were thinking there is some sort of network extender that > uses some form of DSL for higher bandwidth capacity. > > Any suggestions? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhaustin at gmail.com Wed Dec 12 21:38:10 2018 From: jhaustin at gmail.com (Jeremy Austin) Date: Wed, 12 Dec 2018 12:38:10 -0900 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: For a comparison of distance to capacity on copper, see http://www.impulse-corp.co.uk/knowledge-base/transmission-distance-and-speed-differences-between-shdsl-and-vdsl2.htm You might be able to pair bond -- if you had more than one pair. If wireless isn't possible, you're likely needing satellite. On Wed, Dec 12, 2018 at 12:35 PM Andrew Latham wrote: > On Wed, Dec 12, 2018 at 3:27 PM Nick Bogle wrote: > >> A quick question for you guys; >> >> If you had a single dry pair (pair of copper wires originally for phones) >> to a remote site that was around 6 miles away, what would you use? We >> currently are just extending a T1 line to this site, but 1.5Mbps isn't >> cutting it anymore. Unfortunately it's a research site on a federally >> protected wildlife preserve so we can't run any new infrastructure (fiber >> etc) and it isn't in a geographical place where point to point wireless is >> practical. We were thinking there is some sort of network extender that >> uses some form of DSL for higher bandwidth capacity. >> >> Any suggestions? >> > > Look for an SHDSL Ethernet Extender > > -- > - Andrew "lathama" Latham - > -- Jeremy Austin jhaustin at gmail.com (907) 895-2311 office (907) 803-5422 cell -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Wed Dec 12 21:40:07 2018 From: blake at ispn.net (Blake Hudson) Date: Wed, 12 Dec 2018 15:40:07 -0600 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: Nick Bogle wrote on 12/12/2018 3:25 PM: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for > phones) to a remote site that was around 6 miles away, what would you > use? We currently are just extending a T1 line to this site, but > 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site > on a federally protected wildlife preserve so we can't run any new > infrastructure (fiber etc) and it isn't in a geographical place where > point to point wireless is practical. We were thinking there is some > sort of network extender that uses some form of DSL for higher > bandwidth capacity. > > Any suggestions? Blackbox makes a variety of different types of " network extenders" (aka bridges) - https://www.blackbox.com/en-us/products/black-box-brand-products/networking/extenders As others have said, 6 miles might limit your bandwidth capacity. From alfie at fdx.services Wed Dec 12 21:42:29 2018 From: alfie at fdx.services (Alfie Pates) Date: Wed, 12 Dec 2018 21:42:29 +0000 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <1544650949.3386324.1607522856.542709C1@webmail.messagingengine.com> Six miles is probably pushing it, but Proscend make some interesting Long- Range Ethernet SFP transciever which are VDSL based. They're horrendously documented and they draw *way* more power than the SFP specification allows. They also make a version which is design to terminate VDSL broadband circuits - A couple of those found their way to my desk recently and it turns out that despite the horrendous documentation and sightly scary heat output (they come with a little paper note in the box which says something along the lines of "WARNING! MODULE GETS HOT - DO NOT TOUCH DURING OPERATION."), they do generally Just Work! ~a On Wed, Dec 12, 2018, at 9:25 PM, Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for > phones) to a remote site that was around 6 miles away, what would you > use? We currently are just extending a T1 line to this site, but > 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site > on a federally protected wildlife preserve so we can't run any new > infrastructure (fiber etc) and it isn't in a geographical place where > point to point wireless is practical. We were thinking there is some > sort of network extender that uses some form of DSL for higher > bandwidth capacity.> > Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Dec 12 21:47:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 12 Dec 2018 15:47:31 -0600 (CST) Subject: Enterprise GPON / Zhone Questions In-Reply-To: <1544650469.3384147.1607496576.172FF411@webmail.messagingengine.com> References: <1544650469.3384147.1607496576.172FF411@webmail.messagingengine.com> Message-ID: <174432929.95.1544651250307.JavaMail.mhammett@ThunderFuck> Lower power consumption of electronics and the fact that most (not all) deployments don't need more than 10 megs committed to them, so share a big pipe and burst away. 1U can have 256 endpoints easily and consume less power than a regular switch. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Alfie Pates" To: nanog at nanog.org Sent: Wednesday, December 12, 2018 3:34:29 PM Subject: Re: Enterprise GPON / Zhone Questions The discussion was regarding an in-building LAN - residential access networks/WANs are a wholly different beast and GPON is fantastically suitable for that particular problem. There is, however, a reason that a lot of new mixed-use (business && residential) WAN fibre deployments end up building a home-run dark fibre network for business use and overbuilding with GPON for residential use - the 1-1 mapping of end users to patch points/flexibility points makes for a vastly more future-proof network. I think we often underestimate just how long the networks we install stick around. I ordered a 10Gbit/s service not too long ago over the very same fibre that was used to serve 2Mbit/s connections in the mid 90s: I'm not kidding, the fibre was physically disconnected from an old, derelict 2Mbit/s SDH network termination and plugged into a brand new 10Gbit/s EDD. GPON is cool, definitely - I've worked on very large scale GPON deployments before, and it is definitely a very useful technology that allows us to affordably deploy high-bandwidth consumer and small-business connectivity. However - it is a compromise, and I don't think you're gaining anything by running GPON versus the tried-and-tested method of active, switch-based aggregation, especially compared to the sacrifices you make deploying a passively-aggregated network. As I said before - I wouldn't stake my reputation on it. ~A -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 12 21:52:14 2018 From: bill at herrin.us (William Herrin) Date: Wed, 12 Dec 2018 13:52:14 -0800 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 12:09 PM Baldur Norddahl wrote: > On Wed, Dec 12, 2018 at 7:51 PM William Herrin wrote: >> On Tue, Dec 11, 2018 at 10:47 PM Baldur Norddahl >> wrote: >> > Compared to the traditional approach, you will only have one centralized >> > GPON switch to manage. All the small ONT switches are managed through >> > this. Complaints about the interface is vendor specific. Because there is only >> > one centralized switch, it would be fairly cheap to switch vendor. Much cheaper >> > than to rewire with copper in any case. >> >> Except you won't have one central GPON switch because LANs change >> incrementally. > > In my experience, a PON network is extremely flexible. Our FTTH network [...] Exactly, your FTTH network. PON wouldn't exist if it didn't have valuable use scenarios. Like an FTTH network. I was discussing Nick's scenario which is NOT an FTTH network. It's an in-building LAN with fiber runs measuring in tens or hundreds of feet (not miles) behind walls (not up on accessible utilities poles or down in accessible conduits) with screwy in-wall ONTs (not the user's responsibility to power) stuffed in a space that doesn't dissipate heat well. YOUR use of PON makes reasonably good sense. > One advantage of a fiber to the desktop solution is that you have >fiber to every room. You just move a drop cable from the splitter >and to a pair of backbone fibers. Did it read to you like Nick's installation had drop cables of non-trivial length from easily accessed splitters? It didn't read that way to me. >> I would demand the creation of comms closets and risers before the >> building opened and I'd threaten to quit if they weren't. At least >> then the inevitable modifications can be structured and planned >> instead of turning in to an ad-hoc mess. > > This is out of line IMHO. Hopefully they did add in extra conduits so > you could do some special cable runs (including some copper and > coax), if needed. Nick said they did not create comms closets or a comms riser. > But if they did not, it would be the responsibility > of management, not yours. It also has nothing to do with fiber > nor GPON. Plenty of copper builds have a severe lack of space > for future proving. To an internal user, internal IT *is* part of the management complex. They're the ones who get to choose your password length and VPN rules. They make choices which are enforced on you, hence management. > If they did the fiber build in the recommended way, there will > be ducts prepared for fiber blowing, so one quickly can add more fiber cabling. If they did the fiber build in anything reasonably close to the recommended way there would be ducts connected to comms closets holding the splitters. He's already told us there are no comms closets. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From phillipc at phmgmt.com Wed Dec 12 21:53:05 2018 From: phillipc at phmgmt.com (Phillip Carroll) Date: Wed, 12 Dec 2018 21:53:05 +0000 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: Whenever I have a dry pair I use fluke lube. -----Original Message----- From: NANOG On Behalf Of Blake Hudson Sent: Wednesday, December 12, 2018 3:40 PM To: nanog at nanog.org Subject: Re: Extending network over a dry pair Nick Bogle wrote on 12/12/2018 3:25 PM: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for > phones) to a remote site that was around 6 miles away, what would you > use? We currently are just extending a T1 line to this site, but > 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site > on a federally protected wildlife preserve so we can't run any new > infrastructure (fiber etc) and it isn't in a geographical place where > point to point wireless is practical. We were thinking there is some > sort of network extender that uses some form of DSL for higher > bandwidth capacity. > > Any suggestions? Blackbox makes a variety of different types of " network extenders" (aka bridges) - https://www.blackbox.com/en-us/products/black-box-brand-products/networking/extenders As others have said, 6 miles might limit your bandwidth capacity. From gtaylor at tnetconsulting.net Wed Dec 12 22:14:07 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 12 Dec 2018 15:14:07 -0700 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On 12/12/2018 02:40 PM, Blake Hudson wrote: > As others have said, 6 miles might limit your bandwidth capacity. Are there other places along the path that you could split break the 6 miles into multiple shorter links and regenerate the signal? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From baldur.norddahl at gmail.com Wed Dec 12 22:13:57 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 12 Dec 2018 23:13:57 +0100 Subject: Enterprise GPON / Zhone Questions In-Reply-To: <174432929.95.1544651250307.JavaMail.mhammett@ThunderFuck> References: <1544650469.3384147.1607496576.172FF411@webmail.messagingengine.com> <174432929.95.1544651250307.JavaMail.mhammett@ThunderFuck> Message-ID: Many 1U GPON OLT switches have 16 OLT ports and each port can have up to 128 ONT. This gives you 2048 ONT in one unit for the OLT. Typical power is less than 200 watt. Each ONT has 4 or more ethernet ports. So multiply with that. You could have a small campus on just one unit of OLT. On the other hand, I am not sure you will actually save any power as the ONTs also need power and they are many. Regards Baldur ons. 12. dec. 2018 22.56 skrev Mike Hammett : > Lower power consumption of electronics and the fact that most (not all) > deployments don't need more than 10 megs committed to them, so share a big > pipe and burst away. 1U can have 256 endpoints easily and consume less > power than a regular switch. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Alfie Pates" > *To: *nanog at nanog.org > *Sent: *Wednesday, December 12, 2018 3:34:29 PM > *Subject: *Re: Enterprise GPON / Zhone Questions > > The discussion was regarding an in-building LAN - residential access > networks/WANs are a wholly different beast and GPON is fantastically > suitable for that particular problem. > > There is, however, a reason that a lot of new mixed-use (business && > residential) WAN fibre deployments end up building a home-run dark fibre > network for business use and overbuilding with GPON for residential use - > the 1-1 mapping of end users to patch points/flexibility points makes for a > vastly more future-proof network. > > I think we often underestimate just how long the networks we install stick > around. I ordered a 10Gbit/s service not too long ago over the very same > fibre that was used to serve 2Mbit/s connections in the mid 90s: I'm not > kidding, the fibre was physically disconnected from an old, derelict > 2Mbit/s SDH network termination and plugged into a brand new 10Gbit/s EDD. > > GPON is cool, definitely - I've worked on very large scale GPON > deployments before, and it is definitely a very useful technology that > allows us to affordably deploy high-bandwidth consumer and small-business > connectivity. > > However - it is a compromise, and I don't think you're gaining anything by > running GPON versus the tried-and-tested method of active, switch-based > aggregation, especially compared to the sacrifices you make deploying a > passively-aggregated network. > > As I said before - I wouldn't stake my reputation on it. > > ~A > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Wed Dec 12 22:16:16 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 12 Dec 2018 17:16:16 -0500 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: I'd say that any carrier grade GPON gear is way overkill for a LAN and you're going to have to run single mode fiber to use the consumer grade ONTs which is a big extra expense as few structured wiring companies do single mode. Second, Dasan Zhone is one of the vendors I'd absolutely avoid and I've worked on numerous GPON OLTs (Adtran TA5000/3000, Calix C7, E7, E3, and others). Their configuration is problematic as you've found out and they have a poor track record in security. https://www.securityweek.com/over-million-dasan-routers-vulnerable-remote-hacking Using third party optics is (with all the GPON vendors) a complete crap shoot. Sometimes they will work and suddenly a firmware update from the OLT vendor comes along and they no longer work. Other times they don't work at all or are very unreliable. GPON is a standard, but in North America the vendors have largely not been forced to do interoperability and it's very lacking. Compare that to Europe where the Fritzbox is one of the most popular ONTs. Finally, as many have said I cannot see any scenario where building GPON will be as cost effective, reliable, or performant as simply building out a switched Ethernet network over fiber. On Tue, Dec 11, 2018 at 10:53 AM Nick Bogle wrote: > Hello fellow NANOG members :) > > Let me start with a little bit of background, my day job is a Network > Engineer for a local university where we have primarily a Cisco environment > from phones to switching to routing, etc. Before my time, we hired a > contractor to design a GPON LAN system for a new building as a cost saving > measure (though I am not sure how successful that was). > > Either way, the contractor is about to hand the system off to us, and we > have gone through the training and such, and I feel confident in my ability > to manage the system, but we have a few questions that the manufacturer of > our equipment and our contractor didn't really want to answer. We are > currently using a Dasan Zhone MXK-F1419 with several different downstream > ONT models (all Zhone). > > -We would like to consider use of 3rd party GPON B+ Optics on the > linecards to add redundancy to the splitter (as the cost of 1st party are > too high). Does anyone have experience with 3rd party > vendors/compatibility/stability issues? We were told they theoretically > should work and just throw a log event, but it hasn't been tested. If so, > what vendors would you recommend? So far all we've really seen are Ubiquiti > and Fiberstore optics. > > -As GPON is a standard itself, I'm aware interoperability between OLT and > ONT vendors is heavily limited.. Does anyone have any experience using say, > Zhone ONT's with a different model OLT, or Zhone ONT's with a different > model OLT? I've heard word that Zhone ONT's may be able to work with Nokia > OLT's but it's technically not supported. > > -We've already experienced some pretty big stability issues (have replaced > 1 line card 5 times..), our contractor is saying it's just because we were > a pretty early adopter of this line and that they've fixed it and fixed > internal policies to add additional QA and testing before shipping to > customers. Does anyone have any experience with working with Zhone and > their overall stability of components? > > - Any other thoughts/gotchas/advice for deploying a GPON environment in a > corporate LAN? (or about deploying a Zhone solution) It's pretty service > provider oriented, and is incredible noticeable in the CLI. > > -Is anyone familiar with Zhone CLI? The apparent lack of any "show" > configuration commands is infuriating. > > > Feel free to contact me offlist if you have any pertinent info that you > don't want on the list. > > Thanks, > > Nick Bogle > nick at bogle.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 12 22:17:32 2018 From: bill at herrin.us (William Herrin) Date: Wed, 12 Dec 2018 14:17:32 -0800 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 1:25 PM Nick Bogle wrote: > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? > We currently are just extending a T1 line to this site, but 1.5Mbps > isn't cutting it anymore. Hi Nick, Where are the repeaters? Even using HDSL or VDSL, 1.5mbps T1s don't generally extend 30,000 feet without repeaters. Depending on how far apart the repeaters are and whether you can substitute other equipment, you may have lots of options or none at all. Also, tell us more about the terrain. Just because you don't think it's suitable for ptp wireless doesn't necessarily mean that wireless can't usefully play a role in a hybrid solution. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From CKimball at misalliance.com Wed Dec 12 22:19:10 2018 From: CKimball at misalliance.com (Chris Kimball) Date: Wed, 12 Dec 2018 22:19:10 +0000 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: HA! But the question is; does it pass? ^^^ and that was my official 'first post' beware my linked in requests now😊 -----Original Message----- From: NANOG On Behalf Of Phillip Carroll Sent: Wednesday, December 12, 2018 4:53 PM To: nanog at nanog.org Subject: RE: Extending network over a dry pair Whenever I have a dry pair I use fluke lube. -----Original Message----- From: NANOG On Behalf Of Blake Hudson Sent: Wednesday, December 12, 2018 3:40 PM To: nanog at nanog.org Subject: Re: Extending network over a dry pair Nick Bogle wrote on 12/12/2018 3:25 PM: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for > phones) to a remote site that was around 6 miles away, what would you > use? We currently are just extending a T1 line to this site, but > 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site > on a federally protected wildlife preserve so we can't run any new > infrastructure (fiber etc) and it isn't in a geographical place where > point to point wireless is practical. We were thinking there is some > sort of network extender that uses some form of DSL for higher > bandwidth capacity. > > Any suggestions? Blackbox makes a variety of different types of " network extenders" (aka bridges) - https://www.blackbox.com/en-us/products/black-box-brand-products/networking/extenders As others have said, 6 miles might limit your bandwidth capacity. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. From baldur.norddahl at gmail.com Wed Dec 12 22:32:22 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 12 Dec 2018 23:32:22 +0100 Subject: Enterprise GPON / Zhone Questions In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 10:52 PM William Herrin wrote: > YOUR use of PON makes reasonably good sense. > > Features such as battery backup and ISDN is made for the explicit purpose of office buildings, not residential use. The flexibility that we enjoy will also work for office buildings. I do not disagree that in a office building the distances are short and you can get enough flexibility just by adding sufficient amount of dark fiber, and therefore a point to point network would work just as well. But what he got is a GPON network, so what else would also work is moot. Nobody has yet to come forth with a real problem with the GPON network, that would require to start all over with another approach. > > > One advantage of a fiber to the desktop solution is that you have > >fiber to every room. You just move a drop cable from the splitter > >and to a pair of backbone fibers. > > Did it read to you like Nick's installation had drop cables of > non-trivial length from easily accessed splitters? It didn't read that > way to me. > The length of the drop cables is irrelevant. You are not going to move the cables physically. You will unplug the drop cable from the splitter and connect it to the backbone cable. Both splitter and backbone cables will have APC/LC connectors in a small cabinet somewhere. You can literally convert a drop cable from being part of the GPON system, to being a point to point anywhere within a few minutes just by moving a few connectors. > > > >> I would demand the creation of comms closets and risers before the > >> building opened and I'd threaten to quit if they weren't. At least > >> then the inevitable modifications can be structured and planned > >> instead of turning in to an ad-hoc mess. > > > > This is out of line IMHO. Hopefully they did add in extra conduits so > > you could do some special cable runs (including some copper and > > coax), if needed. > > Nick said they did not create comms closets or a comms riser. > He did not say there was zero space to run any cables at all. Fiber does need very little space. And if all you need is that coax for the AV group, that also would not need much space. If you wanted to rewire the whole thing for copper, that would require a lot of space. Rewiring for point to point fiber would require very little space, if any at all (we do not know how much dark fiber they already have). > If they did the fiber build in anything reasonably close to the > recommended way there would be ducts connected to comms closets > holding the splitters. He's already told us there are no comms > closets. > > No in a fiber build you would not bother with comms closets. For copper you need to ensure no run is longer than 100 meters, and therefore you have risers and comm closets relatively close spaced. In a fiber roll out there is no point. Even with point to point ethernet over fiber, you would just have one closet for the whole building in the basement somewhere. Or even in a different building. The architect is going to want that space for something else in a heartbeat. This more than the saved cost could be the real reason for why they did it. This does not mean there will be zero space for running cables. You still have lots of stuff that needs to cross floors (power, water, sewer, fiber etc). Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Dec 12 22:33:35 2018 From: bill at herrin.us (William Herrin) Date: Wed, 12 Dec 2018 14:33:35 -0800 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On Wed, Dec 12, 2018 at 1:25 PM Nick Bogle wrote: > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? > We currently are just extending a T1 line to this site, but 1.5Mbps > isn't cutting it anymore. Unfortunately it's a research site on a federally > protected wildlife preserve so we can't run any new infrastructure > (fiber etc) Also, if there's power and dry pair copper to the site then there are utility poles to the site that are grandfathered under whatever the current regulations are. Since poles rot and trees take down wires there must also be provisions for maintaining them. A good lawyer can probably figure out how you can add a cable to those existing poles without running afoul of the regs, particularly since its in service to a research site. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From shawnl at up.net Wed Dec 12 23:05:00 2018 From: shawnl at up.net (Shawn L) Date: Wed, 12 Dec 2018 18:05:00 -0500 (EST) Subject: Extending network over a dry pair In-Reply-To: <1544650949.3386324.1607522856.542709C1@webmail.messagingengine.com> References: <1544650949.3386324.1607522856.542709C1@webmail.messagingengine.com> Message-ID: <1544655900.93881193@upnet.mymailsrvr.com> Actellis also makes some ethernet over dry pair gear. The only issue is that they require repeaters like a T1 (different spacing though). I'm guessing if you're doing T1 at that distance you already have repeater housings in the field at least. -----Original Message----- From: "Alfie Pates" Sent: Wednesday, December 12, 2018 4:42pm To: nanog at nanog.org Subject: Re: Extending network over a dry pair Six miles is probably pushing it, but Proscend make some interesting Long-Range Ethernet SFP transciever which are VDSL based. They're horrendously documented and they draw *way* more power than the SFP specification allows. They also make a version which is design to terminate VDSL broadband circuits - A couple of those found their way to my desk recently and it turns out that despite the horrendous documentation and sightly scary heat output (they come with a little paper note in the box which says something along the lines of "WARNING! MODULE GETS HOT - DO NOT TOUCH DURING OPERATION."), they do generally Just Work! ~a On Wed, Dec 12, 2018, at 9:25 PM, Nick Bogle wrote: A quick question for you guys; If you had a single dry pair (pair of copper wires originally for phones) to a remote site that was around 6 miles away, what would you use? We currently are just extending a T1 line to this site, but 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site on a federally protected wildlife preserve so we can't run any new infrastructure (fiber etc) and it isn't in a geographical place where point to point wireless is practical. We were thinking there is some sort of network extender that uses some form of DSL for higher bandwidth capacity. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed Dec 12 23:14:12 2018 From: mel at beckman.org (Mel Beckman) Date: Wed, 12 Dec 2018 23:14:12 +0000 Subject: Extending network over a dry pair In-Reply-To: References: , Message-ID: I’ve used the Patton copper link devices such as the one you mentioned Nick, and they work very well within the parameters they cover. Their tech-support is excellent also. -mel beckman On Dec 12, 2018, at 1:44 PM, Josh Luthman > wrote: Something LRE possibly. Could just do VDSL. Are you just looking at more than 1544 kbps or is there a particular threshold you need to meet (to support a camera, etc)? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Dec 12, 2018 at 4:26 PM Nick Bogle > wrote: A quick question for you guys; If you had a single dry pair (pair of copper wires originally for phones) to a remote site that was around 6 miles away, what would you use? We currently are just extending a T1 line to this site, but 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site on a federally protected wildlife preserve so we can't run any new infrastructure (fiber etc) and it isn't in a geographical place where point to point wireless is practical. We were thinking there is some sort of network extender that uses some form of DSL for higher bandwidth capacity. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Dec 12 23:19:21 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 13 Dec 2018 00:19:21 +0100 Subject: Extending network over a dry pair In-Reply-To: <1544655900.93881193@upnet.mymailsrvr.com> References: <1544650949.3386324.1607522856.542709C1@webmail.messagingengine.com> <1544655900.93881193@upnet.mymailsrvr.com> Message-ID: Rent a cable plow and make a quick run of fiber during the night. Nobody will notice. :-) 6 miles is too far to get any speed on a phone line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Jameson at tdstelecom.com Wed Dec 12 23:58:41 2018 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Wed, 12 Dec 2018 23:58:41 +0000 Subject: Extending network over a dry pair In-Reply-To: References: <1544650949.3386324.1607522856.542709C1@webmail.messagingengine.com> <1544655900.93881193@upnet.mymailsrvr.com>, Message-ID: Look at a Hatteras hn400 and lpu You can get about 5mbs/pair using g.shdsl. pairs can be bonded to add capacity (assuming at least 2 pair for t-1). The repeaters fit in a standard 248 closure. ________________________________ From: NANOG on behalf of Baldur Norddahl Sent: Wednesday, December 12, 2018 4:19:21 PM To: nanog at nanog.org Subject: Re: Extending network over a dry pair Rent a cable plow and make a quick run of fiber during the night. Nobody will notice. :-) 6 miles is too far to get any speed on a phone line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Quincy.Marshall at reged.com Thu Dec 13 00:29:26 2018 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Thu, 13 Dec 2018 00:29:26 +0000 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <3438B611A2B2C04495EF0E1B25729C46331F6ED6@mbx032-e1-va-8.exch032.serverpod.net> I used to take “dry pairs” or “alarm circuits” and take SDSL modems to create high bandwidth ( up to 10Mbps, relative to the time) circuits. They were very reliable and incredibly cheap (@$22-88/mo). Regional bell at the time (or at least in my area) would make it difficult to order. Had to find the order codes. Looks like these new units are updates to what was around, but they were very testy on line quality/distance. the first rule … ‘no load’. Suggest trying the water in the shallow end first. LQ Marshall From: NANOG [mailto:nanog-bounces+quincy.marshall=reged.com at nanog.org] On Behalf Of Jeremy Austin Sent: Wednesday, December 12, 2018 4:38 PM To: lathama at gmail.com Cc: NANOG list Subject: Re: Extending network over a dry pair For a comparison of distance to capacity on copper, see http://www.impulse-corp.co.uk/knowledge-base/transmission-distance-and-speed-differences-between-shdsl-and-vdsl2.htm You might be able to pair bond -- if you had more than one pair. If wireless isn't possible, you're likely needing satellite. On Wed, Dec 12, 2018 at 12:35 PM Andrew Latham > wrote: On Wed, Dec 12, 2018 at 3:27 PM Nick Bogle > wrote: A quick question for you guys; If you had a single dry pair (pair of copper wires originally for phones) to a remote site that was around 6 miles away, what would you use? We currently are just extending a T1 line to this site, but 1.5Mbps isn't cutting it anymore. Unfortunately it's a research site on a federally protected wildlife preserve so we can't run any new infrastructure (fiber etc) and it isn't in a geographical place where point to point wireless is practical. We were thinking there is some sort of network extender that uses some form of DSL for higher bandwidth capacity. Any suggestions? Look for an SHDSL Ethernet Extender -- - Andrew "lathama" Latham - -- Jeremy Austin jhaustin at gmail.com (907) 895-2311 office (907) 803-5422 cell --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemon at sasami.anime.net Thu Dec 13 01:00:23 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 12 Dec 2018 17:00:23 -0800 (PST) Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On Wed, 12 Dec 2018, Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? We > currently are just extending a T1 line to this site, but 1.5Mbps isn't > cutting it anymore. Unfortunately it's a research site on a federally > protected wildlife preserve so we can't run any new infrastructure (fiber > etc) and it isn't in a geographical place where point to point wireless is > practical. We were thinking there is some sort of network extender that > uses some form of DSL for higher bandwidth capacity. > > Any suggestions? If this is telco provided dry pair then the distance is probably longer than 6 miles as the endpoints are probably tied together through a telco CO. I have not heard of any equipment which will work over a 6 mile pair any faster than you're getting with T1. You might consider setting up wireless repeaters to bridge where there is no direct LOS. Look at what the hamwan guys have done. http://hamwan.org/ -Dan From goemon at sasami.anime.net Thu Dec 13 02:32:24 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 12 Dec 2018 18:32:24 -0800 (PST) Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: I doubt he will get >1.5mbps with those over a 6 mile long connection. I did a quick check and flowpoint 2200s seem to max out at 192kbps at 3 miles. -Dan On Wed, 12 Dec 2018, Tim Pozar wrote: > For dry pairs, I have used Flowpoint SDSL modems (see attached). I > picked these up for a sawbuck. > > Tim > > On 12/12/18 5:00 PM, Dan Hollis wrote: >> On Wed, 12 Dec 2018, Nick Bogle wrote: >>> A quick question for you guys; >>> >>> If you had a single dry pair (pair of copper wires originally for phones) >>> to a remote site that was around 6 miles away, what would you use? We >>> currently are just extending a T1 line to this site, but 1.5Mbps isn't >>> cutting it anymore. Unfortunately it's a research site on a federally >>> protected wildlife preserve so we can't run any new infrastructure (fiber >>> etc) and it isn't in a geographical place where point to point >>> wireless is >>> practical. We were thinking there is some sort of network extender that >>> uses some form of DSL for higher bandwidth capacity. >>> >>> Any suggestions? >> >> If this is telco provided dry pair then the distance is probably longer >> than 6 miles as the endpoints are probably tied together through a telco >> CO. >> >> I have not heard of any equipment which will work over a 6 mile pair any >> faster than you're getting with T1. >> >> You might consider setting up wireless repeaters to bridge where there >> is no direct LOS. Look at what the hamwan guys have done. >> http://hamwan.org/ >> >> -Dan > From mfidelman at meetinghouse.net Thu Dec 13 02:36:44 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 12 Dec 2018 21:36:44 -0500 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <7313e15a-a8e2-7ecf-dfdd-ceb6ea3085c0@meetinghouse.net> It really does seem like repeaters are a necessity.  If he can put power down the wires, and get to them to install repeaters, that would seem the obvious way to go. Miles On 12/12/18 9:32 PM, Dan Hollis wrote: > I doubt he will get >1.5mbps with those over a 6 mile long connection. > > I did a quick check and flowpoint 2200s seem to max out at 192kbps at > 3 miles. > > -Dan > > On Wed, 12 Dec 2018, Tim Pozar wrote: > >> For dry pairs, I have used Flowpoint SDSL modems (see attached).  I >> picked these up for a sawbuck. >> >> Tim >> >> On 12/12/18 5:00 PM, Dan Hollis wrote: >>> On Wed, 12 Dec 2018, Nick Bogle wrote: >>>> A quick question for you guys; >>>> >>>> If you had a single dry pair (pair of copper wires originally for >>>> phones) >>>> to a remote site that was around 6 miles away, what would you use? We >>>> currently are just extending a T1 line to this site, but 1.5Mbps isn't >>>> cutting it anymore. Unfortunately it's a research site on a federally >>>> protected wildlife preserve so we can't run any new infrastructure >>>> (fiber >>>> etc) and it isn't in a geographical place where point to point >>>> wireless is >>>> practical. We were thinking there is some sort of network extender >>>> that >>>> uses some form of DSL for higher bandwidth capacity. >>>> >>>> Any suggestions? >>> >>> If this is telco provided dry pair then the distance is probably longer >>> than 6 miles as the endpoints are probably tied together through a >>> telco >>> CO. >>> >>> I have not heard of any equipment which will work over a 6 mile pair >>> any >>> faster than you're getting with T1. >>> >>> You might consider setting up wireless repeaters to bridge where there >>> is no direct LOS. Look at what the hamwan guys have done. >>> http://hamwan.org/ >>> >>> -Dan >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nick at bogle.se Thu Dec 13 02:59:45 2018 From: nick at bogle.se (Nick Bogle) Date: Wed, 12 Dec 2018 18:59:45 -0800 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: The driving distance is 4 miles, we are leasing it from CenturyLink whose headend maybe adds a mile or less, it's on the route and about half way through. I made it 6 miles to be safe. We currently can pull a full 1.5Mbps off of that T1 we run there so perhaps CenturyLink is repeating at their CO and/or along the route? On Wed, Dec 12, 2018 at 6:32 PM Dan Hollis wrote: > I doubt he will get >1.5mbps with those over a 6 mile long connection. > > I did a quick check and flowpoint 2200s seem to max out at 192kbps at 3 > miles. > > -Dan > > On Wed, 12 Dec 2018, Tim Pozar wrote: > > > For dry pairs, I have used Flowpoint SDSL modems (see attached). I > > picked these up for a sawbuck. > > > > Tim > > > > On 12/12/18 5:00 PM, Dan Hollis wrote: > >> On Wed, 12 Dec 2018, Nick Bogle wrote: > >>> A quick question for you guys; > >>> > >>> If you had a single dry pair (pair of copper wires originally for > phones) > >>> to a remote site that was around 6 miles away, what would you use? We > >>> currently are just extending a T1 line to this site, but 1.5Mbps isn't > >>> cutting it anymore. Unfortunately it's a research site on a federally > >>> protected wildlife preserve so we can't run any new infrastructure > (fiber > >>> etc) and it isn't in a geographical place where point to point > >>> wireless is > >>> practical. We were thinking there is some sort of network extender that > >>> uses some form of DSL for higher bandwidth capacity. > >>> > >>> Any suggestions? > >> > >> If this is telco provided dry pair then the distance is probably longer > >> than 6 miles as the endpoints are probably tied together through a telco > >> CO. > >> > >> I have not heard of any equipment which will work over a 6 mile pair any > >> faster than you're getting with T1. > >> > >> You might consider setting up wireless repeaters to bridge where there > >> is no direct LOS. Look at what the hamwan guys have done. > >> http://hamwan.org/ > >> > >> -Dan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lprehn at inet.tu-berlin.de Thu Dec 13 11:44:30 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Thu, 13 Dec 2018 12:44:30 +0100 Subject: PCH BGP Collector Data - Contact Message-ID: <3622936e-db4f-6ae1-e987-29adcad6c78a@inet.tu-berlin.de> Hi everyone, I'm planning to download a significant amount of PCH's available MRT data. Is there anyone that could forward me (maybe off-list) contact information for one of the current maintainers? Thanks in advance! Best regards, Lars From mark.tinka at seacom.mu Thu Dec 13 12:55:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Dec 2018 14:55:06 +0200 Subject: Unsolicited LinkedIn requests In-Reply-To: References: <20181211224014.E3712200B5CC44@ary.qy> Message-ID: I see folk giving quite a bit of time and attention to this. By now, I know that 98% of Linkedin messages hitting my mail box are for connections from people I don't know. It's faster and simpler for me to delete the message and move on. A few times a month I'll get a digest of reminders for connections I haven't acted upon. Again, delete the e-mail and move on - I'm not obsessed with having "0 items to action". 2% of the time, I'll receive a request to connect from someone I know or someone I've met before, or a message that is actually useful which someone sent via Linkedin. After sometime, you achieve muscle memory as to what to catch and what to ignore, i.e., the 98% vs. the 2%. No point in trying to be more creative than that, if I'm honest. Linkedin and all other social media apps are so entrenched in our online lives, it's as guaranteed as catching a cold at some point every year. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Dec 13 13:55:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 13 Dec 2018 07:55:53 -0600 (CST) Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <1229551604.458.1544709349860.JavaMail.mhammett@ThunderFuck> You don't even need LOS to move more than 1.5 megabit/s over wireless. I think the best bet is to consult people that actually know wireless. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Dan Hollis" To: "Nick Bogle" Cc: nanog at nanog.org Sent: Wednesday, December 12, 2018 7:00:23 PM Subject: Re: Extending network over a dry pair On Wed, 12 Dec 2018, Nick Bogle wrote: > A quick question for you guys; > > If you had a single dry pair (pair of copper wires originally for phones) > to a remote site that was around 6 miles away, what would you use? We > currently are just extending a T1 line to this site, but 1.5Mbps isn't > cutting it anymore. Unfortunately it's a research site on a federally > protected wildlife preserve so we can't run any new infrastructure (fiber > etc) and it isn't in a geographical place where point to point wireless is > practical. We were thinking there is some sort of network extender that > uses some form of DSL for higher bandwidth capacity. > > Any suggestions? If this is telco provided dry pair then the distance is probably longer than 6 miles as the endpoints are probably tied together through a telco CO. I have not heard of any equipment which will work over a 6 mile pair any faster than you're getting with T1. You might consider setting up wireless repeaters to bridge where there is no direct LOS. Look at what the hamwan guys have done. http://hamwan.org/ -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Thu Dec 13 15:35:23 2018 From: woody at pch.net (Bill Woodcock) Date: Thu, 13 Dec 2018 07:35:23 -0800 Subject: PCH BGP Collector Data - Contact In-Reply-To: <3622936e-db4f-6ae1-e987-29adcad6c78a@inet.tu-berlin.de> References: <3622936e-db4f-6ae1-e987-29adcad6c78a@inet.tu-berlin.de> Message-ID: <9FE4C7F6-83F5-4D28-9C04-6CAF842AF545@pch.net> Introduced off-list. Thanks for getting in touch first, so we can make sure there’s a reasonable path for the data. -Bill > On Dec 13, 2018, at 03:45, Lars Prehn wrote: > > Hi everyone, > > I'm planning to download a significant amount of PCH's available MRT data. Is there anyone that could forward me (maybe off-list) contact information for one of the current maintainers? > > Thanks in advance! > > Best regards, > > Lars > From pozar at lns.com Thu Dec 13 01:50:57 2018 From: pozar at lns.com (Tim Pozar) Date: Wed, 12 Dec 2018 17:50:57 -0800 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: For dry pairs, I have used Flowpoint SDSL modems (see attached). I picked these up for a sawbuck. Tim On 12/12/18 5:00 PM, Dan Hollis wrote: > On Wed, 12 Dec 2018, Nick Bogle wrote: >> A quick question for you guys; >> >> If you had a single dry pair (pair of copper wires originally for phones) >> to a remote site that was around 6 miles away, what would you use? We >> currently are just extending a T1 line to this site, but 1.5Mbps isn't >> cutting it anymore. Unfortunately it's a research site on a federally >> protected wildlife preserve so we can't run any new infrastructure (fiber >> etc) and it isn't in a geographical place where point to point >> wireless is >> practical. We were thinking there is some sort of network extender that >> uses some form of DSL for higher bandwidth capacity. >> >> Any suggestions? > > If this is telco provided dry pair then the distance is probably longer > than 6 miles as the endpoints are probably tied together through a telco > CO. > > I have not heard of any equipment which will work over a 6 mile pair any > faster than you're getting with T1. > > You might consider setting up wireless repeaters to bridge where there > is no direct LOS. Look at what the hamwan guys have done. > http://hamwan.org/ > > -Dan From john at essenz.com Thu Dec 13 20:33:14 2018 From: john at essenz.com (John Von Essen) Date: Thu, 13 Dec 2018 15:33:14 -0500 Subject: Levle3's IRR db Message-ID: Whats the best way to get in contact with Level3 to make an IRR change... if your not a Level3 customer? I tried emailing rr at level3.net but that bounces back as an unmonitored mailbox. There are dup IRR entries in Level3's db for my prefixes (legacy from a carrier I used over 10 years ago). My prefixes are in Arin's IRR and I would like that to be the only source. -John From carl-lists at portnetworks.com Thu Dec 13 20:22:26 2018 From: carl-lists at portnetworks.com (Carl Peterson) Date: Thu, 13 Dec 2018 15:22:26 -0500 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: With CL in the middle, EoC might be an option. Personally, I'd find a local WISP and see what they can come up with for you. On Wed, Dec 12, 2018 at 10:01 PM Nick Bogle wrote: > The driving distance is 4 miles, we are leasing it from CenturyLink whose > headend maybe adds a mile or less, it's on the route and about half way > through. I made it 6 miles to be safe. We currently can pull a full 1.5Mbps > off of that T1 we run there so perhaps CenturyLink is repeating at their CO > and/or along the route? > > > On Wed, Dec 12, 2018 at 6:32 PM Dan Hollis > wrote: > >> I doubt he will get >1.5mbps with those over a 6 mile long connection. >> >> I did a quick check and flowpoint 2200s seem to max out at 192kbps at 3 >> miles. >> >> -Dan >> >> On Wed, 12 Dec 2018, Tim Pozar wrote: >> >> > For dry pairs, I have used Flowpoint SDSL modems (see attached). I >> > picked these up for a sawbuck. >> > >> > Tim >> > >> > On 12/12/18 5:00 PM, Dan Hollis wrote: >> >> On Wed, 12 Dec 2018, Nick Bogle wrote: >> >>> A quick question for you guys; >> >>> >> >>> If you had a single dry pair (pair of copper wires originally for >> phones) >> >>> to a remote site that was around 6 miles away, what would you use? We >> >>> currently are just extending a T1 line to this site, but 1.5Mbps isn't >> >>> cutting it anymore. Unfortunately it's a research site on a federally >> >>> protected wildlife preserve so we can't run any new infrastructure >> (fiber >> >>> etc) and it isn't in a geographical place where point to point >> >>> wireless is >> >>> practical. We were thinking there is some sort of network extender >> that >> >>> uses some form of DSL for higher bandwidth capacity. >> >>> >> >>> Any suggestions? >> >> >> >> If this is telco provided dry pair then the distance is probably longer >> >> than 6 miles as the endpoints are probably tied together through a >> telco >> >> CO. >> >> >> >> I have not heard of any equipment which will work over a 6 mile pair >> any >> >> faster than you're getting with T1. >> >> >> >> You might consider setting up wireless repeaters to bridge where there >> >> is no direct LOS. Look at what the hamwan guys have done. >> >> http://hamwan.org/ >> >> >> >> -Dan >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnford at uiowa.net Thu Dec 13 20:44:39 2018 From: jnford at uiowa.net (Jay Ford) Date: Thu, 13 Dec 2018 14:44:39 -0600 (CST) Subject: Levle3's IRR db In-Reply-To: References: Message-ID: On Thu, 13 Dec 2018, John Von Essen wrote: > Whats the best way to get in contact with Level3 to make an IRR change... if > your not a Level3 customer? > > I tried emailing rr at level3.net but that bounces back as an unmonitored > mailbox. There are dup IRR entries in Level3's db for my prefixes (legacy > from a carrier I used over 10 years ago). My prefixes are in Arin's IRR and I > would like that to be the only source. In Mar 2018 I had success sending such clean-up requests to the technical contact address in the AS3561 whois record. The address has changed since then, but maybe whoever gets that email is still interested in maintaining their IRR. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555 From goemon at sasami.anime.net Thu Dec 13 22:22:29 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 13 Dec 2018 14:22:29 -0800 (PST) Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: Repeaters are standard for T1s. I strongly suggest looking at wireless. There is almost guaranteed to be a spot you can put a repeater up to bridge you to your gateway. -Dan On Wed, 12 Dec 2018, Nick Bogle wrote: > The driving distance is 4 miles, we are leasing it from CenturyLink whose > headend maybe adds a mile or less, it's on the route and about half way > through. I made it 6 miles to be safe. We currently can pull a full 1.5Mbps > off of that T1 we run there so perhaps CenturyLink is repeating at their CO > and/or along the route? > > > On Wed, Dec 12, 2018 at 6:32 PM Dan Hollis wrote: > >> I doubt he will get >1.5mbps with those over a 6 mile long connection. >> >> I did a quick check and flowpoint 2200s seem to max out at 192kbps at 3 >> miles. >> >> -Dan >> >> On Wed, 12 Dec 2018, Tim Pozar wrote: >> >>> For dry pairs, I have used Flowpoint SDSL modems (see attached). I >>> picked these up for a sawbuck. >>> >>> Tim >>> >>> On 12/12/18 5:00 PM, Dan Hollis wrote: >>>> On Wed, 12 Dec 2018, Nick Bogle wrote: >>>>> A quick question for you guys; >>>>> >>>>> If you had a single dry pair (pair of copper wires originally for >> phones) >>>>> to a remote site that was around 6 miles away, what would you use? We >>>>> currently are just extending a T1 line to this site, but 1.5Mbps isn't >>>>> cutting it anymore. Unfortunately it's a research site on a federally >>>>> protected wildlife preserve so we can't run any new infrastructure >> (fiber >>>>> etc) and it isn't in a geographical place where point to point >>>>> wireless is >>>>> practical. We were thinking there is some sort of network extender that >>>>> uses some form of DSL for higher bandwidth capacity. >>>>> >>>>> Any suggestions? >>>> >>>> If this is telco provided dry pair then the distance is probably longer >>>> than 6 miles as the endpoints are probably tied together through a telco >>>> CO. >>>> >>>> I have not heard of any equipment which will work over a 6 mile pair any >>>> faster than you're getting with T1. >>>> >>>> You might consider setting up wireless repeaters to bridge where there >>>> is no direct LOS. Look at what the hamwan guys have done. >>>> http://hamwan.org/ >>>> >>>> -Dan >>> >> > From hf0002+nanog at uah.edu Thu Dec 13 22:27:39 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 13 Dec 2018 16:27:39 -0600 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: On Thu, Dec 13, 2018 at 4:22 PM Dan Hollis wrote: > Repeaters are standard for T1s. > > I strongly suggest looking at wireless. There is almost guaranteed to be a > spot you can put a repeater up to bridge you to your gateway. > > Maybe this has been mentioned, and I missed it, but: A hybrid solution could also be considered. You could use a shorter dry pair to get around whatever obstacle is preventing wireless, and then use wireless the rest of the way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Thu Dec 13 22:39:47 2018 From: andy at andyring.com (Andy Ringsmuth) Date: Thu, 13 Dec 2018 16:39:47 -0600 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: <775420C3-3375-4648-B2D4-BE49954F3A34@andyring.com> > On Dec 13, 2018, at 4:27 PM, Hunter Fuller wrote: > > On Thu, Dec 13, 2018 at 4:22 PM Dan Hollis wrote: > Repeaters are standard for T1s. > > I strongly suggest looking at wireless. There is almost guaranteed to be a > spot you can put a repeater up to bridge you to your gateway. > > Maybe this has been mentioned, and I missed it, but: A hybrid solution could also be considered. > You could use a shorter dry pair to get around whatever obstacle is preventing wireless, and then use wireless the rest of the way. Any chance the OP could show us on, say, Google Maps, where this is at? Maybe that will help generate some innovative solutions. -Andy From matthew at corp.crocker.com Fri Dec 14 02:11:37 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Fri, 14 Dec 2018 02:11:37 +0000 Subject: Extending network over a dry pair In-Reply-To: References: Message-ID: You can’t push a T1 through a load-coil which are normally placed every mile on copper. Typically the telco would cut the load-coil out of the 2 T1 pairs and install a repeater to push the T1 the next mile. That is with a traditional T1 circuit. Most T1s these days are 2 wire HDSL which has a max of about 12k feet. So for 6 miles you’ll need 3 repeaters in the span *if* you have good copper. From: NANOG on behalf of Nick Bogle Date: Wednesday, December 12, 2018 at 10:00 PM To: Dan Hollis Cc: "nanog at nanog.org" Subject: Re: Extending network over a dry pair The driving distance is 4 miles, we are leasing it from CenturyLink whose headend maybe adds a mile or less, it's on the route and about half way through. I made it 6 miles to be safe. We currently can pull a full 1.5Mbps off of that T1 we run there so perhaps CenturyLink is repeating at their CO and/or along the route? On Wed, Dec 12, 2018 at 6:32 PM Dan Hollis > wrote: I doubt he will get >1.5mbps with those over a 6 mile long connection. I did a quick check and flowpoint 2200s seem to max out at 192kbps at 3 miles. -Dan On Wed, 12 Dec 2018, Tim Pozar wrote: > For dry pairs, I have used Flowpoint SDSL modems (see attached). I > picked these up for a sawbuck. > > Tim > > On 12/12/18 5:00 PM, Dan Hollis wrote: >> On Wed, 12 Dec 2018, Nick Bogle wrote: >>> A quick question for you guys; >>> >>> If you had a single dry pair (pair of copper wires originally for phones) >>> to a remote site that was around 6 miles away, what would you use? We >>> currently are just extending a T1 line to this site, but 1.5Mbps isn't >>> cutting it anymore. Unfortunately it's a research site on a federally >>> protected wildlife preserve so we can't run any new infrastructure (fiber >>> etc) and it isn't in a geographical place where point to point >>> wireless is >>> practical. We were thinking there is some sort of network extender that >>> uses some form of DSL for higher bandwidth capacity. >>> >>> Any suggestions? >> >> If this is telco provided dry pair then the distance is probably longer >> than 6 miles as the endpoints are probably tied together through a telco >> CO. >> >> I have not heard of any equipment which will work over a 6 mile pair any >> faster than you're getting with T1. >> >> You might consider setting up wireless repeaters to bridge where there >> is no direct LOS. Look at what the hamwan guys have done. >> http://hamwan.org/ >> >> -Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Fri Dec 14 04:30:56 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 14 Dec 2018 02:30:56 -0200 Subject: Network Atlas End of Year 2018 Update In-Reply-To: References: Message-ID: Ok, I am just excited to share this so won't wait till January :) Time Machine is ready! What is time machine? Change the time in future, and see which cables will be still operational (aka run out of their life times of approximate 25 years!). https://dev.networkatlas.org check it out! by the way we are looking for people who can volunteer to demo few features like uploading kmzs, and creating custom fields like latency. If you have free time , please join our slack here . https://join.slack.com/t/networkatlas/shared_invite/enQtNDUwOTIzMDEwODM4LWE5NjNmOWRkMmQxYmYzYWU1YmI0ZmEwNWVlODllY2U1MGU5OTVhZDk4YjA1ZmFiN2VhYWI5ZWUyMGQ0YjU0OTc Coming soon, the feature that will make engineers life easy "buy now" :) watch this space.... :) On Sat, Dec 1, 2018 at 11:31 PM Mehmet Akcin wrote: > NANOG Friends, > > The final month of 2018 is going to be a busy one for Network Atlas, and > while I still have a few spare hours, I wanted to share some exciting > updates and address a few questions. > First, I would like to thank all the people who believe in Network Atlas > and have helped it get to where it is today. Network Atlas is at its heart > a community concept, and it is energizing to see so many of you excited > about its potential and interested in making it better. > To that end, the Network Atlas team will be spending the next month > working feverishly to improve the product and get it ready for 2019. I am > very excited to announce the following list of features that should come > online early next year: > > 1. > > Cable system operation status allows users to see which segments are > up/down/partial and their last outage, along with textual details of > previous outages with potential for links > 2. > > Cable system information - length, activation date, and estimated > end-of-life > 3. > > Fast page load time of <5 secs for users within the US > 4. > > 3D data center locations > 5. > > “Buy capacity” - a form that generates an email to a specified cable > owner > 6. > > Report-an-issue on routes for users to send feedback > 7. > > Ability for users to receive email notifications about cable status > changes ,Option to show subsea cables only , Option to show active cables > only, Option to show future cables only > 8. > > A Time Machine function that will show cables that will be active in > the future > 9. > > Ability to add custom fields in select or all cables to show > information such as latency3-tiered Network Atlas Cable > 10. > > Management UI: Users can:Add/Delete/Replace > > I can’t wait to share this next phase of Network Atlas with you all. Once > it’s complete, it will truly be “one map to rule them all.” > > Next up, let me address the elephant in the room. As many of you know, > Network Atlas’ Kickstarter for $100K for 2019 funding came up short of > meeting its goal(we cancelled it before the time because many of you > reached out wanting to support directly not via Kickstart). However, it was > an excellent learning experience, as it provided a chance to interact with > potential donors and hear their questions. One of those questions was if > Network Atlas could show its 3-year plan for the project. In the interest > of transparency, I would like to share with you Network Atlas’ proposed > 3-year operating budget as of today. > > You can see this as details in our blog - > https://www.networkatlas.org/blog/eoy2018 > > Month of December, we will freeze adding new fiber routes to Network > Atlas, this will allow us to focus on working the 10 feature we have > explained above. If you want to upload fiber routes you own and authorized, > feel free to go to https://kmzs.networkatlas.org > and upload them and please include your > email address in the file name (or create a colder with readme in it) so we > can reach back with questions. Our self-service portal will solve this > issue in January :) > > Now this is not the end. It is not even the beginning of the end. But it > is, perhaps, the end of the beginning. > > Have a wonderful December, and a happy new year! > > Mehmet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnstong at westmancom.com Fri Dec 14 14:19:10 2018 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 14 Dec 2018 14:19:10 +0000 Subject: IRR Cleanliness Message-ID: Hi, I'm in the middle of transitioning all of my IRR data from RADb to ARIN and as part of this I am trying to get old stale IRR data cleaned up that other providers have put in place in the past. While doing this I was using the nlnog IRR explorer website and found that a company that I peer with on a public exchange has my ASN listed in an as-macro that they control. The way the as-macro is named I am reasonably confident that they aren't using it for transit related activity, rather they are likely using it for controlling peering activity and filtering on the IX in question. Part of me is okay with this, but given that I've never seen this behavior from any other provider on the three reasonably large exchanges that we participate on I am curious what the community thinks about this. Is this uncommon but acceptable in the eyes of community? Thanks, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Fri Dec 14 15:21:59 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 14 Dec 2018 13:21:59 -0200 Subject: How to choose a transit provider? Message-ID: Hello there, I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... Thanks a lot for your help. I plan to write the blog this month and publish. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Fri Dec 14 16:16:58 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 14 Dec 2018 11:16:58 -0500 Subject: Auto-configuring IPv6 transition mechanisms on customer devices Message-ID: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof? I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly). -- Brandon Martin From baldur.norddahl at gmail.com Fri Dec 14 16:18:07 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 14 Dec 2018 17:18:07 +0100 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: Hi This depends a lot of who you are and where you are. For example apparently Cogent is better in the USA compared to Europe. This would make them mostly useful in Europe only if you have the traffic to be multi homed, while someone in USA might be able to use them as their only provider. If you are going to have only one provider, I would recommend to stay away from the so called Tier 1 providers. You want a smaller local provider, which has multiple upstreams and at least some local peering. Sometimes the tier 1 can get you the best quote and their sales people will certainly tell you all about their superior network and how many global connected customers. But more often than not, the interconnect between the various tier 1 providers is not good and you end up with bad connectivity to whoever they are at war with at the moment. If you have enough traffic to justify multiple upstreams, you can do the tier 1 game. But you still have to be careful to have good local peering. At least if your customers are close to your own physical location. In my country there are several of the big american transit providers. They only have good connectivity to other local companies, that happens to also buy directly from the same transit provider. The tier 1 will refuse to peer with just about anyone and this makes their local connectivity poor. Also consider the wildcard called HE.net. They are the opposite to the old tier 1 in that he.net peers with everyone locally. On the other hand, their global network might not be as good (although my experience is that they are pretty good). I am using he.net as an alternative to joining the too expensive local internet exchanges. It is cheaper to get he.net and he.net will be able to get all the peerings that I can't. Another interesting player is NL-IX. I know this is an european thing. I believe their concept could spread. They take distributed IX to the next level with a IX network that covers large part of Europe. If you are an eyeball ISP you also need to consider caches and direct peerings with the big content providers. Akamai, Google, Netflix, Apple, Microsoft etc. If you are hosting provider, those same peerings are completely irrelevant. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Fri Dec 14 16:31:41 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Fri, 14 Dec 2018 11:31:41 -0500 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: Tier 1s are just as succeptible to outages and peering issues as anyone else. Not to say they're any less, I work for one after all, but one shouldn't assume they're always the best for every application. As an example, Hurricane is decidedly not a Tier 1, but have one of the best peered networks out there. Well peered is a huge plus but that's hard to measure. Cogent, peers with Google in just a few spots so if you want to get to 8.8.8.8 from Dallas you're going to go via Atlanta even though they could peer right in TX. That's a bummer if you've hardcoded Google DNS into anything. But how would you know that unless you do a lot of testing with looking glasses? The choice also depends on what you're doing with the bandwidth: If you're a content provider, for example, you may want to buy transit from AT&T, Comcast, or Charter, not because they're the best, but because they have better access to the eyeballs. Voice guys may want a "performance optimized" blendwidth for lower latency. Etc. -M On Fri, Dec 14, 2018, 10:23 Mehmet Akcin Hello there, > > I have started writing a blog which I hope it would help buy transit > services from providers by doing various due diligences(technical) i wanted > to reach out and ask nanog community’s thoughts on this. > > What are some of your checklist items ? Price? Their directly peered > networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I > am sure list goes on and on on... > > Thanks a lot for your help. I plan to write the blog this month and > publish. > > Mehmet > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Dec 14 16:33:38 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 14 Dec 2018 17:33:38 +0100 Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Message-ID: <8CCD7186-82EE-4392-91C2-C7806A51983E@consulintel.es> Hi Brandon, This may help: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ It is in last call right now, I need to send a new version today/tomorrow, as the IESG review had some inputs, but nothing that change the document as you can read it now. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Brandon Martin Fecha: viernes, 14 de diciembre de 2018, 17:20 Para: "nanog at nanog.org" Asunto: Auto-configuring IPv6 transition mechanisms on customer devices Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof? I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly). -- Brandon Martin ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From swmike at swm.pp.se Fri Dec 14 16:51:50 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 14 Dec 2018 17:51:50 +0100 (CET) Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Message-ID: On Fri, 14 Dec 2018, Brandon Martin wrote: > Are there any (draft, standard, or otherwise) defined mechanisms for > indicating to customer-provided devices that they should configure IPv6 to > IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the > configuration details thereof? > > I'm not aware of any. It seems like this is something that, if defined, > would make deployment of such mechanisms a lot easier even if SPs provide the > customer edge router that implements said mechanisms. I guess they'd > probably be implemented as extensions to DHCPv6 or similar or embedded in RAs > (the latter seems ugly). We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. https://tools.ietf.org/html/rfc7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. -- Mikael Abrahamsson email: swmike at swm.pp.se From dfund at globalvision.net Fri Dec 14 11:30:08 2018 From: dfund at globalvision.net (David Funderburk) Date: Fri, 14 Dec 2018 06:30:08 -0500 Subject: email scannering / filtering Message-ID: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> What open source email filtering system is working well for you? Regards, David Funderburk GlobalVision 864-569-0703 For Technical Support, please email gv-support at globalvision.net. -- This message has been scanned by E.F.A. Project and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Fri Dec 14 15:08:32 2018 From: david at xtom.com (David Guo) Date: Fri, 14 Dec 2018 15:08:32 +0000 Subject: IRR Cleanliness In-Reply-To: References: Message-ID: Hi Graham, Maybe your ASN is not a virgin ASN, someone used it. You should notify every object's former owner or the current maintainer to remove it, or contact RADb or ARIN to help you remove them. But I think that RADb was easier to use than ARIN before, the current version of RADb is not user-friendly. Regards, David From: NANOG On Behalf Of Graham Johnston Sent: Friday, December 14, 2018 10:19 PM To: nanog at nanog.org Subject: IRR Cleanliness Hi, I'm in the middle of transitioning all of my IRR data from RADb to ARIN and as part of this I am trying to get old stale IRR data cleaned up that other providers have put in place in the past. While doing this I was using the nlnog IRR explorer website and found that a company that I peer with on a public exchange has my ASN listed in an as-macro that they control. The way the as-macro is named I am reasonably confident that they aren't using it for transit related activity, rather they are likely using it for controlling peering activity and filtering on the IX in question. Part of me is okay with this, but given that I've never seen this behavior from any other provider on the three reasonably large exchanges that we participate on I am curious what the community thinks about this. Is this uncommon but acceptable in the eyes of community? Thanks, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Fri Dec 14 16:07:08 2018 From: david at xtom.com (David Guo) Date: Fri, 14 Dec 2018 16:07:08 +0000 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: Hi Mehmet, We usually ask the sales director from a neutral datacenter to introduce a sales rep from Tier 1 - 2 ISPs to bargain. First of all, sign NDA if possible, then ask the following questions: 1. Price for 100 Mbps on 1 Gbps port to 1 Gbps unmetered or 1 Gbps on 10 Gbps or 10 Gbps unmetered 2. Contact term, from 12 months to 36 months, or even 60 months. 3. BGP community or RTBH for blackhole 4. AS-SET or LOA for BGP filter updating 5. SLA and network delay (latency) guarantee 6. Price for NRC and MRC and VAT or tax in some countries For their peering networks and IX, you can do research on different network using looking glass, mtr, traceroute, etc. And ask your friend if they are already using the service. Cheapest transit service will not always have good performance, but the most expensive one may not be the best choice. You should choose the suitable provider for your audience. Regards, David From: NANOG On Behalf Of Mehmet Akcin Sent: Friday, December 14, 2018 11:22 PM To: nanog Subject: How to choose a transit provider? Hello there, I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... Thanks a lot for your help. I plan to write the blog this month and publish. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Fri Dec 14 17:12:38 2018 From: Brian at ampr.org (Brian Kantor) Date: Fri, 14 Dec 2018 09:12:38 -0800 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: <20181214171238.GA24912@meow.BKantor.net> On Fri, Dec 14, 2018 at 04:07:08PM +0000, David Guo via NANOG wrote: > First of all, sign NDA if possible, then ask the following questions: Why in heaven's name would you *want* to sign an NDA? Aren't you better off without one? - Brian From mehmet at akcin.net Fri Dec 14 17:17:22 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 14 Dec 2018 15:17:22 -0200 Subject: How to choose a transport(terrestrial/subsea) Message-ID: Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at wholesaleinternet.net Fri Dec 14 17:20:52 2018 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 14 Dec 2018 11:20:52 -0600 Subject: How to choose a transit provider? In-Reply-To: <20181214171238.GA24912@meow.BKantor.net> References: <20181214171238.GA24912@meow.BKantor.net> Message-ID: I've never signed an NDA to receive a quote.  Some of my contracts have NDAs in them after the fact but I've never been asked to sign one before I received pricing from a transit provider. Aaron On 12/14/2018 11:12 AM, Brian Kantor wrote: > On Fri, Dec 14, 2018 at 04:07:08PM +0000, David Guo via NANOG wrote: >> First of all, sign NDA if possible, then ask the following questions: > Why in heaven's name would you *want* to sign an NDA? Aren't you better > off without one? > - Brian > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From david at xtom.com Fri Dec 14 17:22:45 2018 From: david at xtom.com (David Guo) Date: Fri, 14 Dec 2018 17:22:45 +0000 Subject: How to choose a transit provider? In-Reply-To: <20181214171238.GA24912@meow.BKantor.net> References: <20181214171238.GA24912@meow.BKantor.net> Message-ID: No provider wants you disclose the information. Hmm.... someone posted on LINX that he can get $500 for a 10 Gbps unmetered port from a Tier 1 ISP, do you believe it? -----Original Message----- From: NANOG On Behalf Of Brian Kantor Sent: Saturday, December 15, 2018 1:13 AM To: NANOG Subject: Re: How to choose a transit provider? On Fri, Dec 14, 2018 at 04:07:08PM +0000, David Guo via NANOG wrote: > First of all, sign NDA if possible, then ask the following questions: Why in heaven's name would you *want* to sign an NDA? Aren't you better off without one? - Brian From mehmet at akcin.net Fri Dec 14 17:26:56 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 14 Dec 2018 15:26:56 -0200 Subject: How to choose a transit provider? In-Reply-To: References: <20181214171238.GA24912@meow.BKantor.net> Message-ID: Probably you also have never got the best possible pricing ;-) On Fri, Dec 14, 2018 at 15:21 Aaron wrote: > I've never signed an NDA to receive a quote. Some of my contracts have > NDAs in them after the fact but I've never been asked to sign one before > I received pricing from a transit provider. > > Aaron > > On 12/14/2018 11:12 AM, Brian Kantor wrote: > > On Fri, Dec 14, 2018 at 04:07:08PM +0000, David Guo via NANOG wrote: > >> First of all, sign NDA if possible, then ask the following questions: > > Why in heaven's name would you *want* to sign an NDA? Aren't you better > > off without one? > > - Brian > > > > > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at ironie.org Fri Dec 14 17:35:20 2018 From: guillaume at ironie.org (Guillaume Tournat) Date: Fri, 14 Dec 2018 18:35:20 +0100 Subject: email scannering / filtering In-Reply-To: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> Message-ID: <67d9e37a-86da-45d5-1566-e06dc2d3414c@ironie.org> Hello, For MTA server, I use Postfix, with some blacklists (DNSBL). For filtering then: SpamAssassin + Clamav works well. Le 14/12/2018 à 12:30, David Funderburk a écrit : > > What open source email filtering system is working well for you? > > > Regards, > > David Funderburk > GlobalVision > 864-569-0703 > > For Technical Support, please email gv-support at globalvision.net > . > > > -- > This message has been scanned for viruses and dangerous content by > *E.F.A. Project* , and is believed to be > clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Fri Dec 14 17:36:17 2018 From: Brian at ampr.org (Brian Kantor) Date: Fri, 14 Dec 2018 09:36:17 -0800 Subject: How to choose a transit provider? In-Reply-To: References: <20181214171238.GA24912@meow.BKantor.net> Message-ID: <20181214173617.GA25058@meow.BKantor.net> On Fri, Dec 14, 2018 at 03:26:56PM -0200, Mehmet Akcin wrote: > Probably you also have never got the best possible pricing ;-) Ugh. Requiring an NDA to get best pricing is a business practice that makes me feel I need to wash my hands after dealing with them. - Brian From rsk at gsp.org Fri Dec 14 17:36:28 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 14 Dec 2018 12:36:28 -0500 Subject: email scannering / filtering In-Reply-To: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> Message-ID: <20181214173628.GA1130@gsp.org> On Fri, Dec 14, 2018 at 06:30:08AM -0500, David Funderburk wrote: > What open source email filtering system is working well for you? I've been studying email abuse for a very long time, and am writing a book about defending against it with open-source tools. One of the things that I've learned over those decades is that while some measures make sense for everyone, one size does not fit all, and that it's critical to understand the mail stream that's being presented before trying to design and build systems to deal with it. Everyone's legitimate email looks different. Everyone's abusive email looks different. It's not possible to figure out how to cope with these things until you measure them. Nor is it possible until you understand the operational requirements, which again, are different for everyone. Joe's Donuts in Dubuque probably isn't going to be receiving messages at its "orders" address from Peru or Pakistan, for example, so any incoming traffic like that is almost certainly misdirected (at best) or abusive. On the other hand, Michigan State University will probably receive legitimate traffic from all the world, including Peru and Pakistan. Unfortunately, lots of people skip these two steps -- especially the first one -- because they perceive them as onerous and unnecessary. They thus hamstring their own efforts. One of the other things I've learned is that there's a correct order in which to apply defensive measures, so that the probability of FP and FN (false positive and false negative) are both simultaneously minimized, so that each successive measure has less work to do than the one before, and so that those measures which consume the least resources are deployed up front. (For example: using the DROP list in a perimeter router, firewall or even in the MTA's configuration is a highly efficient/low-cost/low-resource measure that should be done before doing other things. This is, by the way, one of the measures that make sense for everyone, see above.) So while I could answer your question by telling you what I use, that doesn't mean that it would work for you. It *might*, and after a fashion, it probably would -- but it's highly unlikely that it's anything close to optimal for your environment. There's a fair amount of homework that needs to be done to figure that out. One more thing. There are a number of things that some people do in their email systems which are worst practices -- things that exacerbate the problem. For example, "quarantines" or "spam folders" are a profoundly horrible idea that should never be deployed. (Ask RSA how that's working out for them.) Avoid these. ---rsk From edugas at unknowndevice.ca Fri Dec 14 17:42:53 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 14 Dec 2018 12:42:53 -0500 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: Message-ID: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric On Dec 14 2018, at 12:17 pm, Mehmet Akcin wrote: > Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. > > How do you choose transport & backbone? > > Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? > > I will get both transport and transit as two seperate blogs. > > I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. > > Thank you for all your help. I will add your names to the thank you line ;-) > -- > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Dec 14 18:03:53 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Dec 2018 04:03:53 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181214180353.8B2B7C44B7@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 15 Dec, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 729792 Prefixes after maximum aggregation (per Origin AS): 280875 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 351369 Total ASes present in the Internet Routing Table: 62704 Prefixes per ASN: 11.64 Origin-only ASes present in the Internet Routing Table: 54098 Origin ASes announcing only one prefix: 23512 Transit ASes present in the Internet Routing Table: 8606 Transit-only ASes present in the Internet Routing Table: 257 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 39 Number of instances of unregistered ASNs: 39 Number of 32-bit ASNs allocated by the RIRs: 25220 Number of 32-bit ASNs visible in the Routing Table: 20431 Prefixes from 32-bit ASNs in the Routing Table: 88037 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 283 Number of addresses announced to Internet: 2838283681 Equivalent to 169 /8s, 44 /16s and 197 /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.1 Total number of prefixes smaller than registry allocations: 243329 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 199478 Total APNIC prefixes after maximum aggregation: 56775 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 196626 Unique aggregates announced from the APNIC address blocks: 80923 APNIC Region origin ASes present in the Internet Routing Table: 9308 APNIC Prefixes per ASN: 21.12 APNIC Region origin ASes announcing only one prefix: 2624 APNIC Region transit ASes present in the Internet Routing Table: 1396 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4301 Number of APNIC addresses announced to Internet: 768781696 Equivalent to 45 /8s, 210 /16s and 173 /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-139577 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: 216291 Total ARIN prefixes after maximum aggregation: 102837 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 215591 Unique aggregates announced from the ARIN address blocks: 103289 ARIN Region origin ASes present in the Internet Routing Table: 18300 ARIN Prefixes per ASN: 11.78 ARIN Region origin ASes announcing only one prefix: 6790 ARIN Region transit ASes present in the Internet Routing Table: 1837 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2521 Number of ARIN addresses announced to Internet: 1077171104 Equivalent to 64 /8s, 52 /16s and 83 /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, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 199126 Total RIPE prefixes after maximum aggregation: 95113 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 195494 Unique aggregates announced from the RIPE address blocks: 115857 RIPE Region origin ASes present in the Internet Routing Table: 25706 RIPE Prefixes per ASN: 7.60 RIPE Region origin ASes announcing only one prefix: 11495 RIPE Region transit ASes present in the Internet Routing Table: 3554 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7682 Number of RIPE addresses announced to Internet: 715951232 Equivalent to 42 /8s, 172 /16s and 140 /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: 94830 Total LACNIC prefixes after maximum aggregation: 21899 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 96211 Unique aggregates announced from the LACNIC address blocks: 41976 LACNIC Region origin ASes present in the Internet Routing Table: 7882 LACNIC Prefixes per ASN: 12.21 LACNIC Region origin ASes announcing only one prefix: 2183 LACNIC Region transit ASes present in the Internet Routing Table: 1485 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5427 Number of LACNIC addresses announced to Internet: 173176064 Equivalent to 10 /8s, 82 /16s and 117 /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: 20027 Total AfriNIC prefixes after maximum aggregation: 4219 AfriNIC Deaggregation factor: 4.75 Prefixes being announced from the AfriNIC address blocks: 25587 Unique aggregates announced from the AfriNIC address blocks: 9058 AfriNIC Region origin ASes present in the Internet Routing Table: 1229 AfriNIC Prefixes per ASN: 20.82 AfriNIC Region origin ASes announcing only one prefix: 420 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 500 Number of AfriNIC addresses announced to Internet: 102763264 Equivalent to 6 /8s, 32 /16s and 11 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4654 515 521 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4635 4192 74 ERX-CERNET-BKB China Education and Rese 45899 2989 1717 114 VNPT-AS-VN VNPT Corp, VN 7552 2969 1151 89 VIETEL-AS-AP Viettel Group, VN 4766 2824 11130 770 KIXS-AS-KR Korea Telecom, KR 9829 2748 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2480 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2410 4907 31 CTTNET China TieTong Telecommunications 17974 2257 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2142 438 176 TATACOMM-AS TATA Communications formerl 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 6327 3506 1326 91 SHAW - Shaw Communications Inc., CA 11492 3478 224 610 CABLEONE - CABLE ONE, INC., US 22773 3303 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2609 5246 972 AMAZON-02 - Amazon.com, Inc., US 16625 2182 1220 1678 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2752 535 CHARTER-20115 - Charter Communications, 18566 2145 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2090 349 129 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2081 5079 596 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5206 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3031 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2606 576 1924 AKAMAI-ASN1, US 12389 2225 2220 624 ROSTELECOM-AS, RU 34984 2032 336 534 TELLCOM-AS, TR 9121 1973 1691 17 TTNET, TR 13188 1604 100 38 TRIOLAN, UA 8402 1294 544 18 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, 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 5464 3320 599 Uninet S.A. de C.V., MX 10620 3145 476 898 Telmex Colombia S.A., CO 11830 2678 371 71 Instituto Costarricense de Electricidad 6503 1662 449 54 Axtel, S.A.B. de C.V., MX 7303 1435 961 220 Telecom Argentina S.A., AR 28573 1186 2241 179 CLARO S.A., BR 6147 1120 377 29 Telefonica del Peru S.A.A., PE 3816 1023 510 110 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 943 145 69 Alestra, S. de R.L. de C.V., MX 13999 924 536 267 Mega Cable, S.A. 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 1163 393 24 LINKdotNET-AS, EG 37611 897 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 783 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 636 1731 19 TE-AS TE-AS, EG 29571 474 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 415 45 11 WANANCHI-, KE 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 5464 3320 599 Uninet S.A. de C.V., MX 12479 5206 1628 138 UNI2-AS, ES 7545 4654 515 521 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4635 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3506 1326 91 SHAW - Shaw Communications Inc., CA 11492 3478 224 610 CABLEONE - CABLE ONE, INC., US 22773 3303 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3145 476 898 Telmex Colombia S.A., CO 8551 3031 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 5206 5068 UNI2-AS, ES 4538 4635 4561 ERX-CERNET-BKB China Education and Research Net 7545 4654 4133 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3506 3415 SHAW - Shaw Communications Inc., CA 22773 3303 3128 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3031 2988 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2969 2880 VIETEL-AS-AP Viettel Group, VN 45899 2989 2875 VNPT-AS-VN VNPT Corp, VN 11492 3478 2868 CABLEONE - CABLE ONE, INC., US 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 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65534 PRIVATE 46.46.17.0/24 15638 UTL Ussuriysk, RU 65534 PRIVATE 46.46.32.0/21 15638 UTL Ussuriysk, RU 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 80.93.96.0/21 15638 UTL Ussuriysk, RU 65534 PRIVATE 93.88.216.0/22 15638 UTL Ussuriysk, RU 65534 PRIVATE 93.88.220.0/24 15638 UTL Ussuriysk, RU 65599 UNALLOCATED 103.14.27.0/24 134813 CYBERCOMM-BD Cyber Communicati 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:12 /9:11 /10:36 /11:99 /12:291 /13:568 /14:1123 /15:1908 /16:13344 /17:7885 /18:13872 /19:25505 /20:39537 /21:46055 /22:90911 /23:74341 /24:411929 /25:824 /26:655 /27:634 /28:32 /29:19 /30:9 /31:2 /32:190 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4059 5206 UNI2-AS, ES 6327 3270 3506 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2764 3478 CABLEONE - CABLE ONE, INC., US 22773 2543 3303 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2487 3031 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2040 2145 MEGAPATH5-US - MegaPath Corporation, US 11830 2023 2678 Instituto Costarricense de Electricidad y Telec 30036 1839 2090 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1628 2:882 4:18 5:2741 6:43 7:1 8:1151 12:1880 13:302 14:1881 15:35 16:3 17:206 18:57 20:48 23:2542 24:2418 25:2 27:2549 31:2012 32:92 35:31 36:534 37:2977 38:1586 39:284 40:120 41:3078 42:730 43:1995 44:139 45:6374 46:3059 47:244 49:1325 50:1077 51:318 52:1103 54:363 55:1 56:6 57:41 58:1698 59:1072 60:457 61:2105 62:1941 63:1809 64:5066 65:2180 66:4789 67:2685 68:1154 69:3413 70:1145 71:601 72:2261 74:2725 75:412 76:526 77:1712 78:1713 79:2208 80:1608 81:1416 82:1060 83:822 84:1063 85:2155 86:561 87:1514 88:1007 89:2427 90:210 91:6490 92:1254 93:2352 94:2389 95:3148 96:905 97:347 98:942 99:169 100:88 101:1161 102:313 103:19497 104:3561 105:243 106:890 107:1834 108:705 109:3452 110:1635 111:1851 112:1408 113:1332 114:1142 115:1717 116:1610 117:1894 118:2210 119:1680 120:1126 121:1022 122:2353 123:1619 124:1439 125:1954 128:1207 129:688 130:520 131:1627 132:716 133:193 134:1043 135:232 136:540 137:672 138:1933 139:774 140:573 141:762 142:799 143:1009 144:848 145:503 146:1246 147:780 148:1698 149:776 150:800 151:989 152:920 153:325 154:2291 155:967 156:1632 157:851 158:657 159:1889 160:1483 161:897 162:2669 163:769 164:1126 165:1589 166:454 167:1356 168:3176 169:869 170:3995 171:499 172:1072 173:2133 174:990 175:873 176:2216 177:4059 178:2525 179:1324 180:2092 181:2370 182:2626 183:1334 184:1153 185:14445 186:3678 187:2527 188:2958 189:2075 190:8312 191:1414 192:9982 193:6452 194:5301 195:4033 196:3013 197:1759 198:5684 199:5977 200:7509 201:5000 202:10209 203:10226 204:4618 205:3015 206:3279 207:3271 208:3933 209:4193 210:3917 211:2027 212:3078 213:2813 214:1069 215:53 216:6021 217:2187 218:874 219:579 220:1832 221:999 222:976 223:1409 End of report From gtaylor at tnetconsulting.net Fri Dec 14 18:39:46 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 14 Dec 2018 11:39:46 -0700 Subject: email scannering / filtering In-Reply-To: <20181214173628.GA1130@gsp.org> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> <20181214173628.GA1130@gsp.org> Message-ID: <4953041c-0fcf-37ca-3320-0ce493966ba7@spamtrap.tnetconsulting.net> On 12/14/18 4:30 AM, David Funderburk wrote: > What open source email filtering system is working well for you? - Sendmail - SpamAssassin - ClamAV - OpenDKIM - OpenDMARC - SPFmilter - NoListing (a variant of Grey Listing that has worked exceedingly well for me.) - Junk Email Filter MX tricks (also works very well for me) - Reverse Path route filters Most of this is fairly stock configuration. I have put some custom rules in SpamAssassin for various reasons. Email me directly if you want particulars. On 12/14/18 10:36 AM, Rich Kulawiec wrote: > I've been studying email abuse for a very long time, and am writing a > book about defending against it with open-source tools. I'll be interested to learn more about your book. Will you share any details so that I can keep an eye out for it? - Title - Release date - Publisher > One of the things that I've learned over those decades is that while > some measures make sense for everyone, one size does not fit all, > and that it's critical to understand the mail stream that's being > presented before trying to design and build systems to deal with it. > Everyone's legitimate email looks different. Everyone's abusive email > looks different. It's not possible to figure out how to cope with these > things until you measure them. > > Nor is it possible until you understand the operational requirements, > which again, are different for everyone. Joe's Donuts in Dubuque > probably isn't going to be receiving messages at its "orders" address > from Peru or Pakistan, for example, so any incoming traffic like that is > almost certainly misdirected (at best) or abusive. On the other hand, > Michigan State University will probably receive legitimate traffic from > all the world, including Peru and Pakistan. I largely agree with both of those statements. > So while I could answer your question by telling you what I use, that > doesn't mean that it would work for you. It *might*, and after a fashion, > it probably would -- but it's highly unlikely that it's anything close > to optimal for your environment. There's a fair amount of homework that > needs to be done to figure that out. Sure. But sharing what you're using and your perceived Pros and Cons do provide data for someone to consume while pontificating what will likely suit them the best. > One more thing. There are a number of things that some people do in their > email systems which are worst practices -- things that exacerbate the > problem. For example, "quarantines" or "spam folders" are a profoundly > horrible idea that should never be deployed. (Ask RSA how that's working > out for them.) Avoid these. I think that there is a time and a place for both quarantining and spam folders. I use quarantining to gate email into and out of a lab / sandbox environment. I know that nothing will flow without me releasing a quarantine. This allows me to feel comfortable testing various MTAs without worrying that email will flow when I have not approved it. Devices on either side speak SMTP just like they want to and believe that the messages are the responsibility of an intermediate server. IMHO it works great. I also think that spam folders do have a use. They provide a way for messages that seem spammy to be isolated from the main inbox while still making them available to end users. (I'm talking about mail boxes accessed via IMAP where it's easy to see both Inbox and Junk.) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From ross at tajvar.io Fri Dec 14 18:44:57 2018 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 14 Dec 2018 13:44:57 -0500 Subject: How to choose a transit provider? In-Reply-To: <20181214173617.GA25058@meow.BKantor.net> References: <20181214171238.GA24912@meow.BKantor.net> <20181214173617.GA25058@meow.BKantor.net> Message-ID: Agreed. My biggest frustration buying carrier services is the lack of transparency in pricing. On Fri, Dec 14, 2018, 12:40 PM Brian Kantor On Fri, Dec 14, 2018 at 03:26:56PM -0200, Mehmet Akcin wrote: > > Probably you also have never got the best possible pricing ;-) > > Ugh. Requiring an NDA to get best pricing is a business practice > that makes me feel I need to wash my hands after dealing with them. > - Brian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Fri Dec 14 18:48:47 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 14 Dec 2018 11:48:47 -0700 Subject: Auto-reply from Yahoo... Message-ID: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Is anyone else receiving the "Your message to REDACTED (was: $oldSubject)" auto-responses to posts to NANOG? I've been seeing them for three or four days now. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From cma at cmadams.net Fri Dec 14 18:49:01 2018 From: cma at cmadams.net (Chris Adams) Date: Fri, 14 Dec 2018 12:49:01 -0600 Subject: email scannering / filtering In-Reply-To: <4953041c-0fcf-37ca-3320-0ce493966ba7@spamtrap.tnetconsulting.net> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> <20181214173628.GA1130@gsp.org> <4953041c-0fcf-37ca-3320-0ce493966ba7@spamtrap.tnetconsulting.net> Message-ID: <20181214184901.GB4524@cmadams.net> Once upon a time, Grant Taylor via NANOG said: > - ClamAV In my recent experience, ClamAV is basically useless against email viruses. On one setup I run that handles around half a million messages a day, ClamAV might flag 3-5 as viruses. I'm dubious that that's all the virus messages that came through. I'd be interested in hearing of other Linux software (free or paid) that can catch modern email viruses. -- Chris Adams From karsten.elfenbein at gmail.com Fri Dec 14 18:55:27 2018 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Fri, 14 Dec 2018 19:55:27 +0100 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: Some points I have not seen so far are: - how do you connect? local cc in the dc or several other fiber runs to reach a different dc/city? (affects price, setup time, maintenance and debugging) - where is your traffic going to/from? how many intermediate ASs or long transfers are involved? - bgp community support to influence routing (including the already mentioned blackhole) - flowspec support - additional services like ddos mitigation - how many ports/locations per committed bandwidth - your own experience with the company (sales/support) - I assume IPv6 support does not need to be mentioned anymore :) Karsten Am Fr., 14. Dez. 2018 um 16:24 Uhr schrieb Mehmet Akcin : > > Hello there, > > I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. > > What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... > > Thanks a lot for your help. I plan to write the blog this month and publish. > > Mehmet > -- > Mehmet > +1-424-298-1903 From goemon at sasami.anime.net Fri Dec 14 18:59:01 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Fri, 14 Dec 2018 10:59:01 -0800 (PST) Subject: Auto-reply from Yahoo... In-Reply-To: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: Yes, someone needs to forcefully remove this subscription: Subject: Re: Your message to lemanm at yahoo-inc.com (was: Re: Extending network over a dry pair) On Fri, 14 Dec 2018, Grant Taylor via NANOG wrote: > Is anyone else receiving the "Your message to REDACTED (was: $oldSubject)" > auto-responses to posts to NANOG? > > I've been seeing them for three or four days now. > > > > -- > Grant. . . . > unix || die > > From bryce at thenetworknerds.ca Fri Dec 14 19:07:01 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Fri, 14 Dec 2018 11:07:01 -0800 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: <8367D6FC-8714-4E35-9CE2-F54303102665@thenetworknerds.ca> I have also received these and I sent an email to the NANOG administrators about it. Thanks ~ Bryce Wilson, AS202313, EVIX AS137933 > On Dec 14, 2018, at 10:59 AM, Dan Hollis wrote: > > Yes, someone needs to forcefully remove this subscription: > > Subject: Re: Your message to lemanm at yahoo-inc.com (was: Re: Extending network over a dry pair) > > >> On Fri, 14 Dec 2018, Grant Taylor via NANOG wrote: >> >> Is anyone else receiving the "Your message to REDACTED (was: $oldSubject)" auto-responses to posts to NANOG? >> >> I've been seeing them for three or four days now. >> >> >> >> -- >> Grant. . . . >> unix || die >> >> From gtaylor at tnetconsulting.net Fri Dec 14 19:26:36 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 14 Dec 2018 12:26:36 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: On 12/14/18 11:59 AM, Dan Hollis wrote: > Yes, someone needs to forcefully remove this subscription: Agreed. > Subject: Re: Your message to lemanm at yahoo-inc.com (was:  Re: Extending > network over a dry pair) Yep. I've received multiple private replies from a number of people who have also stated that they are receiving them and have contacted nanog-owner asking them to do something about it. (Something I've also did myself days ago.) I brought it up on the list to confirm my suspicious and to test the temperature of the water. Here's trusting ~> hoping that the nanog-owner(s) will "do the needful" (with or without "reverting") as soon as time permits. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From josh at imaginenetworksllc.com Fri Dec 14 19:30:40 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 14 Dec 2018 14:30:40 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: Yes. Same email address. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Dec 14, 2018 at 1:59 PM Dan Hollis wrote: > Yes, someone needs to forcefully remove this subscription: > > Subject: Re: Your message to lemanm at yahoo-inc.com (was: Re: Extending > network over a dry pair) > > > On Fri, 14 Dec 2018, Grant Taylor via NANOG wrote: > > > Is anyone else receiving the "Your message to REDACTED (was: > $oldSubject)" > > auto-responses to posts to NANOG? > > > > I've been seeing them for three or four days now. > > > > > > > > -- > > Grant. . . . > > unix || die > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Fri Dec 14 20:00:30 2018 From: john at essenz.com (John Von Essen) Date: Fri, 14 Dec 2018 15:00:30 -0500 Subject: email scannering / filtering In-Reply-To: <67d9e37a-86da-45d5-1566-e06dc2d3414c@ironie.org> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> <67d9e37a-86da-45d5-1566-e06dc2d3414c@ironie.org> Message-ID: <7513bf40-49f6-6ede-04dc-96d9b2605a5b@essenz.com> I've used Sendmail + MIMEDefang + SpamAssassin w/clamav for over 15 years. And on the SA side I use all the bells and whistles available like DCC greylisting, all the public blacklists, there are some 3rd party rulesets you can subscribe to, etc.,. In the end its not as good as gmail, but pretty darn close. I block at SA score 4 and above, 4-8 score I dump into a separate quarantine account that I check every now and again for possible errors, and over 8 I drop - no log or bounce. -John On 12/14/18 12:35 PM, Guillaume Tournat wrote: > > Hello, > > For MTA server, I use Postfix, with some blacklists (DNSBL). > > For filtering then: SpamAssassin + Clamav works well. > > > Le 14/12/2018 à 12:30, David Funderburk a écrit : >> >> What open source email filtering system is working well for you? >> >> >> Regards, >> >> David Funderburk >> GlobalVision >> 864-569-0703 >> >> For Technical Support, please email gv-support at globalvision.net >> . >> >> >> -- >> This message has been scanned for viruses and dangerous content by >> *E.F.A. Project* , and is believed to be >> clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Fri Dec 14 20:18:39 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 14 Dec 2018 13:18:39 -0700 Subject: email scannering / filtering In-Reply-To: <7513bf40-49f6-6ede-04dc-96d9b2605a5b@essenz.com> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> <67d9e37a-86da-45d5-1566-e06dc2d3414c@ironie.org> <7513bf40-49f6-6ede-04dc-96d9b2605a5b@essenz.com> Message-ID: <18fde185-7d60-904a-de25-42d63560d4fb@2mbit.com> On 12/14/2018 1:00 PM, John Von Essen wrote: > I've used Sendmail + MIMEDefang + SpamAssassin w/clamav for over 15 > years. And on the SA side I use all the bells and whistles available > like DCC greylisting, all the public blacklists, there are some 3rd > party rulesets you can subscribe to, etc.,. In the end its not as good > as gmail, but pretty darn close. > > I block at SA score 4 and above, 4-8 score I dump into a separate > quarantine account that I check every now and again for possible errors, > and over 8 I drop - no log or bounce. > I've started using rspamd in place of SpamAssassin and have been having good results. Built in greylisting, support for spamassassin rules, nice statistics web based GUI. Only downside is that it can be quirky during the initial setup. It depends on redis for its key lookup backend. Not a big fan of redis, but it works, especially if you have to support multiple rspamd instances on different mail servers, and want to have one main backend to store all the spam/ham hashes in. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bryan at shout.net Fri Dec 14 20:32:35 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 14 Dec 2018 14:32:35 -0600 Subject: email scannering / filtering In-Reply-To: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> Message-ID: postfix + postscreen for MTA ... MailScanner + MailWatch for anti-____. I've heard good things about rspamd, but I haven't tried it. On 12/14/18 5:30 AM, David Funderburk wrote: > What open source email filtering system is working well for you? > > > Regards, > > David Funderburk > GlobalVision > 864-569-0703 > > For Technical Support, please email gv-support at globalvision.net > . > > > -- > This message has been scanned for viruses and dangerous content by > *E.F.A. Project* , and is believed to be clean. From lprehn at inet.tu-berlin.de Sat Dec 15 08:31:05 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Sat, 15 Dec 2018 09:31:05 +0100 Subject: historical Bogon lists Message-ID: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> Hi everyone, In order to sanitize historical BGP data I would like to use historical Bogon lists. The CIDR report generates those lists on a daily basis (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) but, as far as I know, it does not keep a history of those files - it only holds the most up-to-date file. Does anybody know of a repository that contains such bogon lists for historical data, or, did anybody continiously fecthed and saved CIDR report's bogon lists? Best regards, Lars From mel at beckman.org Sat Dec 15 08:47:54 2018 From: mel at beckman.org (Mel Beckman) Date: Sat, 15 Dec 2018 08:47:54 +0000 Subject: historical Bogon lists In-Reply-To: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> Message-ID: Lars, Archive.org has snapshots going back several year. Just feed in the URL you posted, ad you’ll get a history that lets you download each version of the list that archive.org noticed changed. In my experience, that is pretty comprehensive. -mel beckman > On Dec 15, 2018, at 12:31 AM, Lars Prehn wrote: > > Hi everyone, > > In order to sanitize historical BGP data I would like to use historical Bogon lists. The CIDR report generates those lists on a daily basis (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) but, as far as I know, it does not keep a history of those files - it only holds the most up-to-date file. Does anybody know of a repository that contains such bogon lists for historical data, or, did anybody continiously fecthed and saved CIDR report's bogon lists? > > Best regards, > > Lars > From nanog-post at rsuc.gweep.net Sat Dec 15 09:14:04 2018 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 15 Dec 2018 04:14:04 -0500 Subject: IRR Cleanliness In-Reply-To: References: Message-ID: <20181215091404.GA86684@gweep.net> On Fri, Dec 14, 2018 at 02:19:10PM +0000, Graham Johnston wrote: [snip] > While doing this I was using the nlnog IRR explorer website and > found that a company that I peer with on a public exchange has my > ASN listed in an as-macro that they control. The way the as-macro Being listed in an as-macro doesn't affect your use of the AS or use of it in any IRR. Many providers will list customers (for filter generation) without express consent. Some folks will lump peers in categories through IRR data. There's certainly nothing amiss in using as-macros even for non-neighbors in a number of cases, enumerting ASNs one will [de]preference from a certain set of peers or will drop entirely for example. Often such policies exist but aren't published. ;-) Cheers! Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From lprehn at inet.tu-berlin.de Sat Dec 15 09:30:16 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Sat, 15 Dec 2018 10:30:16 +0100 Subject: historical Bogon lists In-Reply-To: References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> Message-ID: <9a17e920-c743-4609-fc6d-cf36154eefe0@inet.tu-berlin.de> Hi Mel, I already checked Archive.org - it holds two previous copies. >> lets you download each version of the list that archive.org noticed changed According to Archive.org's own Note this seems to be inaccurate: This calendar view maps the number of times https://www.cidr-report.org/bogons/freespace-dec.txt was crawled by the Wayback Machine, not how many times the site was actually updated. , or am I missing something? Best regards, Lars Am 15.12.18 um 09:47 schrieb Mel Beckman: > Lars, > > Archive.org has snapshots going back several year. Just feed in the URL you posted, ad you’ll get a history that lets you download each version of the list that archive.org noticed changed. In my experience, that is pretty comprehensive. > > -mel beckman > >> On Dec 15, 2018, at 12:31 AM, Lars Prehn wrote: >> >> Hi everyone, >> >> In order to sanitize historical BGP data I would like to use historical Bogon lists. The CIDR report generates those lists on a daily basis (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) but, as far as I know, it does not keep a history of those files - it only holds the most up-to-date file. Does anybody know of a repository that contains such bogon lists for historical data, or, did anybody continiously fecthed and saved CIDR report's bogon lists? >> >> Best regards, >> >> Lars >> From nanog at ics-il.net Sat Dec 15 10:44:33 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 04:44:33 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> Message-ID: <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Dugas" To: "Mehmet Akcin" Cc: "nanog" Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric On Dec 14 2018, at 12:17 pm, Mehmet Akcin wrote: Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Dec 15 11:08:17 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 15 Dec 2018 13:08:17 +0200 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> Message-ID: <868c885a-96e3-a4dd-9592-8fec482aedd9@seacom.mu> On 15/Dec/18 12:44, Mike Hammett wrote: > heh, cross connects are indeed a major issue. I have a need for > 10G > transport. My equipment supports 40G. The carriers aren't terribly > interested in doing 40G transport (at least not at a reasonable price, > one quote was over 4x a 10G). 100G-capable switches cost too much. > Equinix charges as much for a pair of cross connects as a 10G wave. > Carriers aren't likely to be interested in using bidi optics or > passive WDM to overcome the ridiculous cross connect charges. > > This all complicates how one chooses transport. There's no easy path > forward. I think the Juniper MX204 is not a bad way to deliver reasonably inexpensive 100Gbps ports to customers. The box is reasonably priced and is, essentially, an MPC7 in a pizza jacket. If an operator is not overly religious about what box they hook high-capacity customers (40Gbps+) into, the MX204 is a good way to start offering affordable 40Gbps and 100Gbps services. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Dec 15 15:26:38 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 09:26:38 -0600 (CST) Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: <1841430070.2172.1544887596879.JavaMail.mhammett@ThunderFuck> I think it'll depend on your target customer. Residential eyeball? Being on an IX is more important at nearly any size than which transit you choose. Even a good-sized residential eyeball (say 10k and up subs) can be good with Cogent\IX\one other transit. Hosting and enterprise-focused ISPs will need to diversify their transit providers more. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "nanog" Sent: Friday, December 14, 2018 9:21:59 AM Subject: How to choose a transit provider? Hello there, I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... Thanks a lot for your help. I plan to write the blog this month and publish. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Sat Dec 15 15:48:30 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 15 Dec 2018 09:48:30 -0600 Subject: Pinging a Device Every Second Message-ID: How much compute and network resources does it take for a NMS to: 1. ICMP ping a device every second 2. Record these results. 3. Report an alarm after so many seconds of missed pings. We are looking for a system to in near real-time monitor if an end customers router is up or down. SNMP I assume would be too resource intensive, so ICMP pings seem like the only logical solution. The question is once a second pings too polling on an NMS and a consumer grade router? Does it take much network bandwidth and CPU resources from both the NMS and CPE side? Lets say this is for a 1,000 customer ISP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Sat Dec 15 15:49:21 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Sat, 15 Dec 2018 10:49:21 -0500 Subject: How to choose a transit provider? In-Reply-To: <1841430070.2172.1544887596879.JavaMail.mhammett@ThunderFuck> References: <1841430070.2172.1544887596879.JavaMail.mhammett@ThunderFuck> Message-ID: I would actually venture to say the contrary. An IX should be the last item on your list since it only really makes sense at a certain scale and if you can make use of the providers on it. Most of the networks you'll have trouble getting to via transit providers are that way because of how they do business, which also means hardly any of them peer at IXes. I'd say a network should have a least 3 good transits before considering an IX. Even then it's not so black and white. If after your first transit provider is installed and you set up your flow monitoring, you notice most of your traiffic is going to/coming from ASNs that peer on your local exchanges, then it absolutely makes sense to open a connection right then. IX links aren't a whole lot cheaper than transit (sometimes they cost more depending on how hard it is to get to them) and many networks will benefit from a more diverse blend of transits than IX peering regardless of what they're doing. IXes are extremely important to the internet at large, but they're not for everyone. -Matt On Dec 15, 2018 10:27, "Mike Hammett" wrote: I think it'll depend on your target customer. Residential eyeball? Being on an IX is more important at nearly any size than which transit you choose. Even a good-sized residential eyeball (say 10k and up subs) can be good with Cogent\IX\one other transit. Hosting and enterprise-focused ISPs will need to diversify their transit providers more. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ------------------------------ *From: *"Mehmet Akcin" *To: *"nanog" *Sent: *Friday, December 14, 2018 9:21:59 AM *Subject: *How to choose a transit provider? Hello there, I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... Thanks a lot for your help. I plan to write the blog this month and publish. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Dec 15 16:12:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 10:12:37 -0600 (CST) Subject: How to choose a transit provider? In-Reply-To: References: <1841430070.2172.1544887596879.JavaMail.mhammett@ThunderFuck> Message-ID: <1907200975.2331.1544890356606.JavaMail.mhammett@ThunderFuck> The type of customer on the network is important here. Most traffic on residential eyeball networks goes to IXes. I know guys pushing 85% of their traffic to IXes. Even small IXes like ours are capturing well over 50% of an ISP's traffic. Netflix, Google, Akamai, Cloudflare. That's what, 2/3rds of the traffic an eyeball has? Now if you're not predominately serving residential customers, then I agree and briefly stated so before. Flow monitoring is indeed important. Usually, DIA (as transit delivered to a customer) is more expensive than transport + transit + small colo (1U\2U stuff) + IX... at least as observed by many of my brethren. That's before you get to the fact that a lot of transit is sub-optimal. Most ISPs we've hooked to our IXes have seen an immediate increase in network utilization because upstream congestion and whatever latency is gone. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Erculiani" To: "Mike Hammett" Cc: "Mehmet Akcin" , "nanog at nanog.org list" Sent: Saturday, December 15, 2018 9:49:21 AM Subject: Re: How to choose a transit provider? I would actually venture to say the contrary. An IX should be the last item on your list since it only really makes sense at a certain scale and if you can make use of the providers on it. Most of the networks you'll have trouble getting to via transit providers are that way because of how they do business, which also means hardly any of them peer at IXes. I'd say a network should have a least 3 good transits before considering an IX. Even then it's not so black and white. If after your first transit provider is installed and you set up your flow monitoring, you notice most of your traiffic is going to/coming from ASNs that peer on your local exchanges, then it absolutely makes sense to open a connection right then. IX links aren't a whole lot cheaper than transit (sometimes they cost more depending on how hard it is to get to them) and many networks will benefit from a more diverse blend of transits than IX peering regardless of what they're doing. IXes are extremely important to the internet at large, but they're not for everyone. -Matt On Dec 15, 2018 10:27, "Mike Hammett" < nanog at ics-il.net > wrote: I think it'll depend on your target customer. Residential eyeball? Being on an IX is more important at nearly any size than which transit you choose. Even a good-sized residential eyeball (say 10k and up subs) can be good with Cogent\IX\one other transit. Hosting and enterprise-focused ISPs will need to diversify their transit providers more. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Mehmet Akcin" < mehmet at akcin.net > To: "nanog" < nanog at nanog.org > Sent: Friday, December 14, 2018 9:21:59 AM Subject: How to choose a transit provider? Hello there, I have started writing a blog which I hope it would help buy transit services from providers by doing various due diligences(technical) i wanted to reach out and ask nanog community’s thoughts on this. What are some of your checklist items ? Price? Their directly peered networks? If they are tier 2,3 who they use as tier 1-2? Are the onnet? I am sure list goes on and on on... Thanks a lot for your help. I plan to write the blog this month and publish. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Sat Dec 15 16:38:03 2018 From: mel at beckman.org (Mel Beckman) Date: Sat, 15 Dec 2018 16:38:03 +0000 Subject: historical Bogon lists In-Reply-To: <9a17e920-c743-4609-fc6d-cf36154eefe0@inet.tu-berlin.de> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> , <9a17e920-c743-4609-fc6d-cf36154eefe0@inet.tu-berlin.de> Message-ID: <1E30F1A5-1DCE-4099-85FD-FDEB12807F9A@beckman.org> My understanding is that the calendar, which in this case showed a dozen or so copies, lists only crawled instances that had changed since The previous crawl. Well it certainly true that time elapses between each crawl, so it's possible that some changes could be missed, my understanding is that the Internet the scroll frequently enough that changes would be detected at least every month or so. I think it's possible that the bogin list just doesn't change that frequently. -mel via cell > On Dec 15, 2018, at 1:30 AM, Lars Prehn wrote: > > Hi Mel, > > I already checked Archive.org - it holds two previous copies. > > >> lets you download each version of the list that archive.org noticed changed > > According to Archive.org's own Note this seems to be inaccurate: > This calendar view maps the number of times https://www.cidr-report.org/bogons/freespace-dec.txt was crawled by the Wayback Machine, not how many times the site was actually updated. > > , or am I missing something? > > Best regards, > Lars > >> Am 15.12.18 um 09:47 schrieb Mel Beckman: >> Lars, >> >> Archive.org has snapshots going back several year. Just feed in the URL you posted, ad you’ll get a history that lets you download each version of the list that archive.org noticed changed. In my experience, that is pretty comprehensive. >> >> -mel beckman >> >>> On Dec 15, 2018, at 12:31 AM, Lars Prehn wrote: >>> >>> Hi everyone, >>> >>> In order to sanitize historical BGP data I would like to use historical Bogon lists. The CIDR report generates those lists on a daily basis (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) but, as far as I know, it does not keep a history of those files - it only holds the most up-to-date file. Does anybody know of a repository that contains such bogon lists for historical data, or, did anybody continiously fecthed and saved CIDR report's bogon lists? >>> >>> Best regards, >>> >>> Lars >>> > From lprehn at inet.tu-berlin.de Sat Dec 15 16:47:10 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Sat, 15 Dec 2018 17:47:10 +0100 Subject: historical Bogon lists In-Reply-To: <1E30F1A5-1DCE-4099-85FD-FDEB12807F9A@beckman.org> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <9a17e920-c743-4609-fc6d-cf36154eefe0@inet.tu-berlin.de> <1E30F1A5-1DCE-4099-85FD-FDEB12807F9A@beckman.org> Message-ID: >> which in this case showed a dozen or so copies Yeah sorry, I should have said that I was only looking into the time frame 2017 till now. >> I think it's possible that the bogin list just doesn't change that frequently. I think I aggree that it is unlikely to change frequently, however, there is not a single snapshot in archive.org for 2018. Best regards, Lars Am 15.12.18 um 17:38 schrieb Mel Beckman: > My understanding is that the calendar, which in this case showed a dozen or so copies, lists only crawled instances that had changed since The previous crawl. Well it certainly true that time elapses between each crawl, so it's possible that some changes could be missed, my understanding is that the Internet the scroll frequently enough that changes would be detected at least every month or so. > > I think it's possible that the bogin list just doesn't change that frequently. > > -mel via cell > >> On Dec 15, 2018, at 1:30 AM, Lars Prehn wrote: >> >> Hi Mel, >> >> I already checked Archive.org - it holds two previous copies. >> >>>> lets you download each version of the list that archive.org noticed changed >> According to Archive.org's own Note this seems to be inaccurate: >> This calendar view maps the number of times https://www.cidr-report.org/bogons/freespace-dec.txt was crawled by the Wayback Machine, not how many times the site was actually updated. >> >> , or am I missing something? >> >> Best regards, >> Lars >> >>> Am 15.12.18 um 09:47 schrieb Mel Beckman: >>> Lars, >>> >>> Archive.org has snapshots going back several year. Just feed in the URL you posted, ad you’ll get a history that lets you download each version of the list that archive.org noticed changed. In my experience, that is pretty comprehensive. >>> >>> -mel beckman >>> >>>> On Dec 15, 2018, at 12:31 AM, Lars Prehn wrote: >>>> >>>> Hi everyone, >>>> >>>> In order to sanitize historical BGP data I would like to use historical Bogon lists. The CIDR report generates those lists on a daily basis (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) but, as far as I know, it does not keep a history of those files - it only holds the most up-to-date file. Does anybody know of a repository that contains such bogon lists for historical data, or, did anybody continiously fecthed and saved CIDR report's bogon lists? >>>> >>>> Best regards, >>>> >>>> Lars >>>> From list at satchell.net Sat Dec 15 16:48:50 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 15 Dec 2018 08:48:50 -0800 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> On 12/15/18 7:48 AM, Colton Conor wrote: > How much compute and network resources does it take for a NMS to: > > 1. ICMP ping a device every second > 2. Record these results. > 3. Report an alarm after so many seconds of missed pings. > > We are looking for a system to in near real-time monitor if an end > customers router is up or down. SNMP I assume would be too resource > intensive, so ICMP pings seem like the only logical solution. > > The question is once a second pings too polling on an NMS and a consumer > grade router? Does it take much network bandwidth and CPU resources from > both the NMS and CPE side? > > Lets say this is for a 1,000 customer ISP. What problem are you trying to solve, exactly? That more than anything will dictate what you do. Short answer: about 1500 bits of bandwidth, and the CPU loading on the remote device is almost invisible. Remember the only real difference between ping and SNMP monitoring (UDP) is the organization of the bits in the packet and the protocol number in the IP header. It's still one packet pair exchanged, unless you get really ambitious with your SNMP OID list. When I was in a medium-sized hosting company, I developed an SNMP-based monitoring system that would query a number of load parameters (CPU, disk, network, overall) on a once a minute schedule, and would keep history for hours on the monitoring server. The boss fretted about the load such monitoring would impose. He never saw any. For pure link monitoring, which is what I'm hearing you want to do, in my experience I found that a six-second ping cycle gives lots of early warning for link failures. Again, it depends on the specifications and detection targets. Some things to consider: 1. Router restarts take a while. Consumer-grade routers can take a minute or more to complete a restart to the point where it will respond to ping. Carrier-grade routers are more variable but in general have so many options built into them that it takes longer to complete a restart cycle. Since you are talking consumer-grade gear, you probably don't want to be sensitive to CP power sags. 2. Depending on the technology used on the link, you may get some short-term outages, on the order of seconds, so doing "rapid" pings do nothing for you. During my DSL time, ATM would drop out for short intervals -- so watch out for nuisance trips. 3. Some routers implement ping limiting, so you have to balance your monitoring sample rate against DoS susceptibility. Offhand, I don't know the granularity of consumer router ping limiting, as I've never had that question pop up. 4. How large a monitoring server are you willing to devote to such a system? My web host monitoring used a 400-MHz Pentium II box, and it didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had Linux, pulled from a junk pile.) I was monitoring about 150 web host servers. Extraolatuing the system load on that Cobalt box, I could have handled 1500 web host servers and more. From lguillory at reservetele.com Sat Dec 15 16:52:19 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 15 Dec 2018 16:52:19 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com>, <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> Message-ID: <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> No cost affective 10x10G to 100G muxponder? Sent from my iPad On Dec 15, 2018, at 4:46 AM, Mike Hammett > wrote: heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Eric Dugas" > To: "Mehmet Akcin" > Cc: "nanog" > Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric Luke Guillory Vice President – Technology and Innovation [cid:image16fa4c.JPG at 90b1ff03.44852df6] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Dec 14 2018, at 12:17 pm, Mehmet Akcin > wrote: Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Dec 15 16:53:41 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 10:53:41 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> Message-ID: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> FS had one, but it's not on their site anymore. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Luke Guillory" To: "Mike Hammett" Cc: "Eric Dugas" , "nanog" Sent: Saturday, December 15, 2018 10:52:19 AM Subject: Re: How to choose a transport(terrestrial/subsea) No cost affective 10x10G to 100G muxponder? Sent from my iPad On Dec 15, 2018, at 4:46 AM, Mike Hammett < nanog at ics-il.net > wrote: heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Dugas" < edugas at unknowndevice.ca > To: "Mehmet Akcin" < mehmet at akcin.net > Cc: "nanog" < nanog at nanog.org > Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Dec 14 2018, at 12:17 pm, Mehmet Akcin < mehmet at akcin.net > wrote:
Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903
-------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Dec 15 17:00:20 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 15 Dec 2018 10:00:20 -0700 Subject: historical Bogon lists In-Reply-To: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> Message-ID: <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> On 12/15/18 1:31 AM, Lars Prehn wrote: > Hi everyone, Hi, > In order to sanitize historical BGP data I would like to use historical > Bogon lists. The CIDR report generates those lists on a daily basis > (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) > but, as far as I know, it does not keep a history of those files - it > only holds the most up-to-date file. Does anybody know of a repository > that contains such bogon lists for historical data, or, did anybody > continiously fecthed and saved CIDR report's bogon lists? Have you tried reaching out to Team Cymru? They provide bogon feeds in a number of different formats. I would be surprised if they don't have the ability to provide historical versions of the bogon list. - It's probably worth asking. I have found them to be very responsive and quite helpful. > Best regards, Good luck. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From nanog-isp at mail.com Sat Dec 15 17:37:28 2018 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Sat, 15 Dec 2018 18:37:28 +0100 Subject: How to choose a transit provider? Message-ID: Mike Hammett wrote: > Usually, DIA (as transit delivered to a customer) is more expensive than transport + transit + small colo > (1U\2U stuff) + IX... at least as observed by many of my brethren. Is this really true in the general case? Adding colo and IX to transport and transit involves at least one additional cross connect and an IX port fee. This is likely to push the total above the pure DIA price. However, regardless of how the numbers pencil out, this isn't really a fair comparison. For small ISPs, the yardstick against which adding an IX to the mix is usually measured against is the marginal cost of IP transit. Given that the cost of transport is fixed, is it more economical to buy more IP transit or to join an IX? Transit being so cheap means that joining an IX isn't always so enticing from a financial perspective, although there are other non-monetary benefits. I certainly subscribe to the notion that transport + transit is usually less expensive than DIA, but this does depend on the market and location. Jared From baldur.norddahl at gmail.com Sat Dec 15 17:37:56 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 15 Dec 2018 18:37:56 +0100 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: You could configure BFD to send out a SNMP alert when three packets have been missed on a 50 ms cycle. Or instantly if the interface charges state to down. This way you would know that they are down within 150 ms. BFD is the hardware solution. A Linux box that has to ping 1000 addresses per second will be very taxed and likely unable to do that in a stable way. You will have seconds where it fails to do them all followed by seconds where it attempts to do them more than once. The result is that the statistics gathered is worthless. If you do something like this, it is much better to have a less ambitious 1 minute cycle. Take a look at Smokeping. If you want a graph to show the quality of the line, Smokeping makes some very good graphs for that. Regards Baldur 15. dec. 2018 16.49 skrev "Colton Conor" : How much compute and network resources does it take for a NMS to: 1. ICMP ping a device every second 2. Record these results. 3. Report an alarm after so many seconds of missed pings. We are looking for a system to in near real-time monitor if an end customers router is up or down. SNMP I assume would be too resource intensive, so ICMP pings seem like the only logical solution. The question is once a second pings too polling on an NMS and a consumer grade router? Does it take much network bandwidth and CPU resources from both the NMS and CPE side? Lets say this is for a 1,000 customer ISP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Dec 15 17:41:50 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 11:41:50 -0600 (CST) Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: <456044264.2480.1544895709815.JavaMail.mhammett@ThunderFuck> Of course YMMV. I'm speaking from the perspective of ISPs between say 300 and 10k customers. I'm knee deep in that community. I'm also generally speaking of facilities that don't have astronomical cross connect charges (so not Equinix, DRT, etc.). In some places, the cross connect cost is nominal, so we just cover it in the IX fee. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: nanog-isp at mail.com To: nanog at nanog.org Cc: "Mike Hammett" Sent: Saturday, December 15, 2018 11:37:28 AM Subject: Re: How to choose a transit provider? Mike Hammett wrote: > Usually, DIA (as transit delivered to a customer) is more expensive than transport + transit + small colo > (1U\2U stuff) + IX... at least as observed by many of my brethren. Is this really true in the general case? Adding colo and IX to transport and transit involves at least one additional cross connect and an IX port fee. This is likely to push the total above the pure DIA price. However, regardless of how the numbers pencil out, this isn't really a fair comparison. For small ISPs, the yardstick against which adding an IX to the mix is usually measured against is the marginal cost of IP transit. Given that the cost of transport is fixed, is it more economical to buy more IP transit or to join an IX? Transit being so cheap means that joining an IX isn't always so enticing from a financial perspective, although there are other non-monetary benefits. I certainly subscribe to the notion that transport + transit is usually less expensive than DIA, but this does depend on the market and location. Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Dec 15 17:44:48 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 15 Dec 2018 19:44:48 +0200 Subject: How to choose a transit provider? In-Reply-To: References: Message-ID: <4055a90d-6183-6498-f4aa-e9be7f4d6e40@seacom.mu> On 15/Dec/18 19:37, nanog-isp at mail.com wrote: > > I certainly subscribe to the notion that transport + transit is usually less expensive than DIA, but this does depend on the market and location. ... and the type of customer. DIA for a high-value "Enterprise" customer (think of a large conglomerate) is typically more costly than DIA for a low-value "Enterprise" customer (think of a family-owned travel & tour company). The large global ISP's are making more money from "enterprise" business than typical wholesale/transit services. This can support the idea that DIA can be pricier than transit. Mark. From mark.tinka at seacom.mu Sat Dec 15 17:46:19 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 15 Dec 2018 19:46:19 +0200 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: <1156b31b-07de-4de2-34cd-ee802e2fbc69@seacom.mu> On 15/Dec/18 19:37, Baldur Norddahl wrote: > > > BFD is the hardware solution. Don't remind me that Juniper currently don't support BFD in hardware for IS-IS- or OSPFv3-signaled IPv6 routing :-(. Mark. From pozar at lns.com Sat Dec 15 17:55:05 2018 From: pozar at lns.com (Tim Pozar) Date: Sat, 15 Dec 2018 09:55:05 -0800 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: <608ec728-e528-83e4-fa07-4f6f8d84a7ea@lns.com> In one of my client's company, we use LibreNMS. It is normally used to get SNMP data but we also have it configured to ping our more "high touch" cients routers. In that case we can record performance such as latency and packet loss. It will generate graphs that we can pass on to the client. It also can be set to alert us if a client's router is not pingable. LibreNMS can also integrate Smokeping if you want Smokeping-style graphs showing standard deviation, etc. Currently I am running LibreNMS on a VM on a Proxmox cluser with a couple of cores. It is probing 385 devices every 5 minutes and keeping up with that. In polling, SNMP is the real time and CPU hog where ping is pretty low impact. Tim On 12/15/18 9:37 AM, Baldur Norddahl wrote: > You could configure BFD to send out a SNMP alert when three packets have > been missed on a 50 ms cycle. Or instantly if the interface charges > state to down. This way you would know that they are down within 150 ms. > > BFD is the hardware solution. A Linux box that has to ping 1000 > addresses per second will be very taxed and likely unable to do that in > a stable way. You will have seconds where it fails to do them all > followed by seconds where it attempts to do them more than once. The > result is that the statistics gathered is worthless. If you do something > like this, it is much better to have a less ambitious 1 minute cycle. > > Take a look at Smokeping. If you want a graph to show the quality of the > line, Smokeping makes some very good graphs for that.  > > Regards  > Baldur  > > 15. dec. 2018 16.49 skrev "Colton Conor" >: > > How much compute and network resources does it take for a NMS to: > > 1. ICMP ping a device every second > 2. Record these results. > 3. Report an alarm after so many seconds of missed pings.  > > We are looking for a system to in near real-time monitor if an end > customers router is up or down. SNMP I assume would be too resource > intensive, so ICMP pings seem like the only logical solution. > > The question is once a second pings too polling on an NMS and a > consumer grade router? Does it take much network bandwidth and CPU > resources from both the NMS and CPE side? > > Lets say this is for a 1,000 customer ISP. > > > From colton.conor at gmail.com Sat Dec 15 18:32:19 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 15 Dec 2018 12:32:19 -0600 Subject: Pinging a Device Every Second In-Reply-To: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: The problem I am trying to solve is to accurately be able to tell a customer if their home internet connection was up or down. Example, customer calls in and says my internet was down for 2 minutes yesterday. We need to be able to verify that their internet connection was indeed down. Right now we have no easy way to do this. Getting metrics like packet loss and jitter would be great too, though I realize ICMP data path does not always equal customer experience as many network device prioritize ICMP traffic. However ICMP pings over the internet do usually accurately tell if a customers modem is indeed online or not. Most devices out in the field like ONT's and DSL modems do not support SNMP but rather use TR-069 for management. Most of these devices only check into the TR-069 ACS server once a day. If the consumer device does support SNMP, they usually have weak broadcom or qualcom SoC processors, outdated linux kernel embedded operating systems, limited ram, and storage. Most of these can't handle SNMP walks every minute let alone every 5. We are talking about sub $100 routers here not Juniper, Cisco, Arista, etc. Most all of these consumer devices are connected to an carrier aggregation device like a DSLAM, OLT, ethernet switch, or wireless access point. These access devices do support SNMP, but most manufactures recommend only 5 minute SNMP poling, so a 2 minute outage would not easily be detected. Plus its hard to correlate that consumer X is on port Y on access switch, and get that right for a tier 1 CSR. The only two ways I think I can accomplish this is: 1. ICMP pings to a device every so many seconds. Almost every device supports responding to WAN ICMP pings. or 2. IPFIX sampling at core router, and then drilling down by customer IP. I think this will tell me if any data was flowing to this customers IP on a second by second basis, but won't necessarily give us an up or down indicator. Requires nothing from the consumer's router. On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell wrote: > On 12/15/18 7:48 AM, Colton Conor wrote: > > How much compute and network resources does it take for a NMS to: > > > > 1. ICMP ping a device every second > > 2. Record these results. > > 3. Report an alarm after so many seconds of missed pings. > > > > We are looking for a system to in near real-time monitor if an end > > customers router is up or down. SNMP I assume would be too resource > > intensive, so ICMP pings seem like the only logical solution. > > > > The question is once a second pings too polling on an NMS and a consumer > > grade router? Does it take much network bandwidth and CPU resources from > > both the NMS and CPE side? > > > > Lets say this is for a 1,000 customer ISP. > > What problem are you trying to solve, exactly? That more than anything > will dictate what you do. > > Short answer: about 1500 bits of bandwidth, and the CPU loading on the > remote device is almost invisible. Remember the only real difference > between ping and SNMP monitoring (UDP) is the organization of the bits > in the packet and the protocol number in the IP header. It's still one > packet pair exchanged, unless you get really ambitious with your SNMP > OID list. > > When I was in a medium-sized hosting company, I developed an SNMP-based > monitoring system that would query a number of load parameters (CPU, > disk, network, overall) on a once a minute schedule, and would keep > history for hours on the monitoring server. The boss fretted about the > load such monitoring would impose. He never saw any. > > For pure link monitoring, which is what I'm hearing you want to do, in > my experience I found that a six-second ping cycle gives lots of early > warning for link failures. Again, it depends on the specifications and > detection targets. > > Some things to consider: > > 1. Router restarts take a while. Consumer-grade routers can take a > minute or more to complete a restart to the point where it will respond > to ping. Carrier-grade routers are more variable but in general have so > many options built into them that it takes longer to complete a restart > cycle. Since you are talking consumer-grade gear, you probably don't > want to be sensitive to CP power sags. > > 2. Depending on the technology used on the link, you may get some > short-term outages, on the order of seconds, so doing "rapid" pings do > nothing for you. During my DSL time, ATM would drop out for short > intervals -- so watch out for nuisance trips. > > 3. Some routers implement ping limiting, so you have to balance your > monitoring sample rate against DoS susceptibility. Offhand, I don't know > the granularity of consumer router ping limiting, as I've never had that > question pop up. > > 4. How large a monitoring server are you willing to devote to such a > system? My web host monitoring used a 400-MHz Pentium II box, and it > didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had > Linux, pulled from a junk pile.) I was monitoring about 150 web host > servers. Extraolatuing the system load on that Cobalt box, I could have > handled 1500 web host servers and more. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Sat Dec 15 18:39:00 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sat, 15 Dec 2018 12:39:00 -0600 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: <5D8FC96B-8EA8-4E4A-8BAB-7AC5FACD8405@gvtc.com> I think the guys in the NOC will add a customer CPE to Solarwinds monitoring and just have it continually run pings, and set up an alert so that we know as soon as the ping stop the alerts go to email or whererver Aaron > On Dec 15, 2018, at 12:32 PM, Colton Conor wrote: > > The problem I am trying to solve is to accurately be able to tell a customer if their home internet connection was up or down. Example, customer calls in and says my internet was down for 2 minutes yesterday. We need to be able to verify that their internet connection was indeed down. Right now we have no easy way to do this. Getting metrics like packet loss and jitter would be great too, though I realize ICMP data path does not always equal customer experience as many network device prioritize ICMP traffic. However ICMP pings over the internet do usually accurately tell if a customers modem is indeed online or not. > > Most devices out in the field like ONT's and DSL modems do not support SNMP but rather use TR-069 for management. Most of these devices only check into the TR-069 ACS server once a day. > If the consumer device does support SNMP, they usually have weak broadcom or qualcom SoC processors, outdated linux kernel embedded operating systems, limited ram, and storage. Most of these can't handle SNMP walks every minute let alone every 5. We are talking about sub $100 routers here not Juniper, Cisco, Arista, etc. > > Most all of these consumer devices are connected to an carrier aggregation device like a DSLAM, OLT, ethernet switch, or wireless access point. These access devices do support SNMP, but most manufactures recommend only 5 minute SNMP poling, so a 2 minute outage would not easily be detected. Plus its hard to correlate that consumer X is on port Y on access switch, and get that right for a tier 1 CSR. > > The only two ways I think I can accomplish this is: > 1. ICMP pings to a device every so many seconds. Almost every device supports responding to WAN ICMP pings. > or > 2. IPFIX sampling at core router, and then drilling down by customer IP. I think this will tell me if any data was flowing to this customers IP on a second by second basis, but won't necessarily give us an up or down indicator. Requires nothing from the consumer's router. > > > > > >> On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell wrote: >> On 12/15/18 7:48 AM, Colton Conor wrote: >> > How much compute and network resources does it take for a NMS to: >> > >> > 1. ICMP ping a device every second >> > 2. Record these results. >> > 3. Report an alarm after so many seconds of missed pings. >> > >> > We are looking for a system to in near real-time monitor if an end >> > customers router is up or down. SNMP I assume would be too resource >> > intensive, so ICMP pings seem like the only logical solution. >> > >> > The question is once a second pings too polling on an NMS and a consumer >> > grade router? Does it take much network bandwidth and CPU resources from >> > both the NMS and CPE side? >> > >> > Lets say this is for a 1,000 customer ISP. >> >> What problem are you trying to solve, exactly? That more than anything >> will dictate what you do. >> >> Short answer: about 1500 bits of bandwidth, and the CPU loading on the >> remote device is almost invisible. Remember the only real difference >> between ping and SNMP monitoring (UDP) is the organization of the bits >> in the packet and the protocol number in the IP header. It's still one >> packet pair exchanged, unless you get really ambitious with your SNMP >> OID list. >> >> When I was in a medium-sized hosting company, I developed an SNMP-based >> monitoring system that would query a number of load parameters (CPU, >> disk, network, overall) on a once a minute schedule, and would keep >> history for hours on the monitoring server. The boss fretted about the >> load such monitoring would impose. He never saw any. >> >> For pure link monitoring, which is what I'm hearing you want to do, in >> my experience I found that a six-second ping cycle gives lots of early >> warning for link failures. Again, it depends on the specifications and >> detection targets. >> >> Some things to consider: >> >> 1. Router restarts take a while. Consumer-grade routers can take a >> minute or more to complete a restart to the point where it will respond >> to ping. Carrier-grade routers are more variable but in general have so >> many options built into them that it takes longer to complete a restart >> cycle. Since you are talking consumer-grade gear, you probably don't >> want to be sensitive to CP power sags. >> >> 2. Depending on the technology used on the link, you may get some >> short-term outages, on the order of seconds, so doing "rapid" pings do >> nothing for you. During my DSL time, ATM would drop out for short >> intervals -- so watch out for nuisance trips. >> >> 3. Some routers implement ping limiting, so you have to balance your >> monitoring sample rate against DoS susceptibility. Offhand, I don't know >> the granularity of consumer router ping limiting, as I've never had that >> question pop up. >> >> 4. How large a monitoring server are you willing to devote to such a >> system? My web host monitoring used a 400-MHz Pentium II box, and it >> didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had >> Linux, pulled from a junk pile.) I was monitoring about 150 web host >> servers. Extraolatuing the system load on that Cobalt box, I could have >> handled 1500 web host servers and more. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at geordish.org Sat Dec 15 19:04:34 2018 From: me at geordish.org (Dave Bell) Date: Sat, 15 Dec 2018 19:04:34 +0000 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: Is RADIUS accounting an option here? Dave On Sat, 15 Dec 2018 at 18:32, Colton Conor wrote: > The problem I am trying to solve is to accurately be able to tell a > customer if their home internet connection was up or down. Example, > customer calls in and says my internet was down for 2 minutes yesterday. We > need to be able to verify that their internet connection was indeed down. > Right now we have no easy way to do this. Getting metrics like packet loss > and jitter would be great too, though I realize ICMP data path does not > always equal customer experience as many network device prioritize ICMP > traffic. However ICMP pings over the internet do usually accurately tell if > a customers modem is indeed online or not. > > Most devices out in the field like ONT's and DSL modems do not support > SNMP but rather use TR-069 for management. Most of these devices only check > into the TR-069 ACS server once a day. > If the consumer device does support SNMP, they usually have weak broadcom > or qualcom SoC processors, outdated linux kernel embedded operating > systems, limited ram, and storage. Most of these can't handle SNMP walks > every minute let alone every 5. We are talking about sub $100 routers here > not Juniper, Cisco, Arista, etc. > > Most all of these consumer devices are connected to an carrier aggregation > device like a DSLAM, OLT, ethernet switch, or wireless access point. These > access devices do support SNMP, but most manufactures recommend only 5 > minute SNMP poling, so a 2 minute outage would not easily be detected. Plus > its hard to correlate that consumer X is on port Y on access switch, and > get that right for a tier 1 CSR. > > The only two ways I think I can accomplish this is: > 1. ICMP pings to a device every so many seconds. Almost every device > supports responding to WAN ICMP pings. > or > 2. IPFIX sampling at core router, and then drilling down by customer IP. I > think this will tell me if any data was flowing to this customers IP on a > second by second basis, but won't necessarily give us an up or down > indicator. Requires nothing from the consumer's router. > > > > > > On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell > wrote: > >> On 12/15/18 7:48 AM, Colton Conor wrote: >> > How much compute and network resources does it take for a NMS to: >> > >> > 1. ICMP ping a device every second >> > 2. Record these results. >> > 3. Report an alarm after so many seconds of missed pings. >> > >> > We are looking for a system to in near real-time monitor if an end >> > customers router is up or down. SNMP I assume would be too resource >> > intensive, so ICMP pings seem like the only logical solution. >> > >> > The question is once a second pings too polling on an NMS and a consumer >> > grade router? Does it take much network bandwidth and CPU resources from >> > both the NMS and CPE side? >> > >> > Lets say this is for a 1,000 customer ISP. >> >> What problem are you trying to solve, exactly? That more than anything >> will dictate what you do. >> >> Short answer: about 1500 bits of bandwidth, and the CPU loading on the >> remote device is almost invisible. Remember the only real difference >> between ping and SNMP monitoring (UDP) is the organization of the bits >> in the packet and the protocol number in the IP header. It's still one >> packet pair exchanged, unless you get really ambitious with your SNMP >> OID list. >> >> When I was in a medium-sized hosting company, I developed an SNMP-based >> monitoring system that would query a number of load parameters (CPU, >> disk, network, overall) on a once a minute schedule, and would keep >> history for hours on the monitoring server. The boss fretted about the >> load such monitoring would impose. He never saw any. >> >> For pure link monitoring, which is what I'm hearing you want to do, in >> my experience I found that a six-second ping cycle gives lots of early >> warning for link failures. Again, it depends on the specifications and >> detection targets. >> >> Some things to consider: >> >> 1. Router restarts take a while. Consumer-grade routers can take a >> minute or more to complete a restart to the point where it will respond >> to ping. Carrier-grade routers are more variable but in general have so >> many options built into them that it takes longer to complete a restart >> cycle. Since you are talking consumer-grade gear, you probably don't >> want to be sensitive to CP power sags. >> >> 2. Depending on the technology used on the link, you may get some >> short-term outages, on the order of seconds, so doing "rapid" pings do >> nothing for you. During my DSL time, ATM would drop out for short >> intervals -- so watch out for nuisance trips. >> >> 3. Some routers implement ping limiting, so you have to balance your >> monitoring sample rate against DoS susceptibility. Offhand, I don't know >> the granularity of consumer router ping limiting, as I've never had that >> question pop up. >> >> 4. How large a monitoring server are you willing to devote to such a >> system? My web host monitoring used a 400-MHz Pentium II box, and it >> didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had >> Linux, pulled from a junk pile.) I was monitoring about 150 web host >> servers. Extraolatuing the system load on that Cobalt box, I could have >> handled 1500 web host servers and more. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ray at oneunified.net Sat Dec 15 19:20:01 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Sat, 15 Dec 2018 12:20:01 -0700 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: <3ecbcd6b-6b2c-6a9c-1a99-ef8adcef6cf9@oneunified.net> On 2018-12-15 11:32 a.m., Colton Conor wrote: > The problem I am trying to solve is to accurately be able to tell a > customer if their home internet connection was up or down.  Example, > customer calls in and says my internet was down for 2 minutes > yesterday. We need to be able to verify that their internet connection > was indeed down. Right now we have no easy way to do this. Getting > metrics like packet loss and jitter would be great too, though I > realize ICMP data path does not always equal customer experience as > many network device prioritize ICMP traffic. However ICMP pings over > the internet do usually accurately tell if a customers modem is indeed > online or not. I've found that this is a multi-faceted problem. Looking at pings or smokeping is part of the solution, but may cause false negatives themselves, when considering the next point -- Another aspect is congestion.  Large uploads or downloads can cause packet loss (including dropping the pings with which you are testing).  Therefore management packets such as these could be marked and processed, on your side at least, with a higher priority. Someone else mentioned radius (or similar authentication/authorization logging mechanism), which will provide an answer if the session did in fact drop or not, for those types of connections. DHCP address changeovers can cause outages. It has also been common to get the 'internet is out' call when DNS is unavailable for whatever reason.  With out name resolution, most eyeball functions will fail. Raymond. From ben at 6by7.net Sat Dec 15 19:27:21 2018 From: ben at 6by7.net (Ben Cannon) Date: Sat, 15 Dec 2018 11:27:21 -0800 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> Message-ID: <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> Mike have you looked at Packetlight? Long-haul is mostly jumping to 100 or even 400g coherent. -Ben > On Dec 15, 2018, at 8:53 AM, Mike Hammett wrote: > > FS had one, but it's not on their site anymore. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Luke Guillory" > To: "Mike Hammett" > Cc: "Eric Dugas" , "nanog" > Sent: Saturday, December 15, 2018 10:52:19 AM > Subject: Re: How to choose a transport(terrestrial/subsea) > > No cost affective 10x10G to 100G muxponder? > > > > Sent from my iPad > > On Dec 15, 2018, at 4:46 AM, Mike Hammett wrote: > > heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. > > This all complicates how one chooses transport. There's no easy path forward. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Eric Dugas" > To: "Mehmet Akcin" > Cc: "nanog" > Sent: Friday, December 14, 2018 11:42:53 AM > Subject: Re: How to choose a transport(terrestrial/subsea) > > I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). > > Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. > > Eric > > Luke Guillory > Vice President – Technology and Innovation > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. > > On Dec 14 2018, at 12:17 pm, Mehmet Akcin wrote: > Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. > > How do you choose transport & backbone? > > Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? > > I will get both transport and transit as two seperate blogs. > > I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. > > Thank you for all your help. I will add your names to the thank you line ;-) > -- > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Dec 15 19:30:05 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Dec 2018 13:30:05 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> Message-ID: <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> I haven't. Sure, but the equipment still does smaller channels. Going to 100G or 400G for just over 10G seems silly. If Equinix had reasonable cross connects, I'd just LAG 10Gs. The cost of a pair of Equinix cross connects isn't much less than the 10G wave. Thankfully I'm only in one datacenter with such a ridiculous model. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben Cannon" To: "Mike Hammett" Cc: "Luke Guillory" , "nanog" Sent: Saturday, December 15, 2018 1:27:21 PM Subject: Re: How to choose a transport(terrestrial/subsea) Mike have you looked at Packetlight? Long-haul is mostly jumping to 100 or even 400g coherent. -Ben On Dec 15, 2018, at 8:53 AM, Mike Hammett < nanog at ics-il.net > wrote: FS had one, but it's not on their site anymore. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Luke Guillory" < lguillory at reservetele.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Eric Dugas" < edugas at unknowndevice.ca >, "nanog" < nanog at nanog.org > Sent: Saturday, December 15, 2018 10:52:19 AM Subject: Re: How to choose a transport(terrestrial/subsea) No cost affective 10x10G to 100G muxponder? Sent from my iPad On Dec 15, 2018, at 4:46 AM, Mike Hammett < nanog at ics-il.net > wrote:
heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Dugas" < edugas at unknowndevice.ca > To: "Mehmet Akcin" < mehmet at akcin.net > Cc: "nanog" < nanog at nanog.org > Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Dec 14 2018, at 12:17 pm, Mehmet Akcin < mehmet at akcin.net > wrote:
Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903
-------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Sat Dec 15 20:03:42 2018 From: saku at ytti.fi (Saku Ytti) Date: Sat, 15 Dec 2018 22:03:42 +0200 Subject: Pinging a Device Every Second In-Reply-To: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: On Sat, 15 Dec 2018 at 18:52, Stephen Satchell wrote: > Short answer: about 1500 bits of bandwidth, and the CPU loading on the I can't parse this. 1000 hosts at 1 pps would be 672kbps on ethernetII encapulation with minimum size frames. -- ++ytti From keiths at neilltech.com Sat Dec 15 20:08:20 2018 From: keiths at neilltech.com (Keith Stokes) Date: Sat, 15 Dec 2018 20:08:20 +0000 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net>, Message-ID: I have a Nagios installation running on a PIII with maybe 512 MB of RAM. I ping a couple hundred devices 5 times per minute and have an alarm threshold of no response for 3 minutes which sends an e-mail. The same device also checks about 900 services among those 200 devices mostly every minute with some every 15 - 60 minutes. This machine happens to be on a backup measured circuit with one other small service. ISP measures my 90% bandwidth rate at < 20K for years. That includes the monitoring, the other low usage service, multiple machines hitting the web interface to check status and the outbound e-mails. -- Keith Stokes SalonBiz, Inc On Dec 15, 2018, at 12:33 PM, Colton Conor > wrote: CAUTION EXTERNAL EMAIL The problem I am trying to solve is to accurately be able to tell a customer if their home internet connection was up or down. Example, customer calls in and says my internet was down for 2 minutes yesterday. We need to be able to verify that their internet connection was indeed down. Right now we have no easy way to do this. Getting metrics like packet loss and jitter would be great too, though I realize ICMP data path does not always equal customer experience as many network device prioritize ICMP traffic. However ICMP pings over the internet do usually accurately tell if a customers modem is indeed online or not. Most devices out in the field like ONT's and DSL modems do not support SNMP but rather use TR-069 for management. Most of these devices only check into the TR-069 ACS server once a day. If the consumer device does support SNMP, they usually have weak broadcom or qualcom SoC processors, outdated linux kernel embedded operating systems, limited ram, and storage. Most of these can't handle SNMP walks every minute let alone every 5. We are talking about sub $100 routers here not Juniper, Cisco, Arista, etc. Most all of these consumer devices are connected to an carrier aggregation device like a DSLAM, OLT, ethernet switch, or wireless access point. These access devices do support SNMP, but most manufactures recommend only 5 minute SNMP poling, so a 2 minute outage would not easily be detected. Plus its hard to correlate that consumer X is on port Y on access switch, and get that right for a tier 1 CSR. The only two ways I think I can accomplish this is: 1. ICMP pings to a device every so many seconds. Almost every device supports responding to WAN ICMP pings. or 2. IPFIX sampling at core router, and then drilling down by customer IP. I think this will tell me if any data was flowing to this customers IP on a second by second basis, but won't necessarily give us an up or down indicator. Requires nothing from the consumer's router. On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell > wrote: On 12/15/18 7:48 AM, Colton Conor wrote: > How much compute and network resources does it take for a NMS to: > > 1. ICMP ping a device every second > 2. Record these results. > 3. Report an alarm after so many seconds of missed pings. > > We are looking for a system to in near real-time monitor if an end > customers router is up or down. SNMP I assume would be too resource > intensive, so ICMP pings seem like the only logical solution. > > The question is once a second pings too polling on an NMS and a consumer > grade router? Does it take much network bandwidth and CPU resources from > both the NMS and CPE side? > > Lets say this is for a 1,000 customer ISP. What problem are you trying to solve, exactly? That more than anything will dictate what you do. Short answer: about 1500 bits of bandwidth, and the CPU loading on the remote device is almost invisible. Remember the only real difference between ping and SNMP monitoring (UDP) is the organization of the bits in the packet and the protocol number in the IP header. It's still one packet pair exchanged, unless you get really ambitious with your SNMP OID list. When I was in a medium-sized hosting company, I developed an SNMP-based monitoring system that would query a number of load parameters (CPU, disk, network, overall) on a once a minute schedule, and would keep history for hours on the monitoring server. The boss fretted about the load such monitoring would impose. He never saw any. For pure link monitoring, which is what I'm hearing you want to do, in my experience I found that a six-second ping cycle gives lots of early warning for link failures. Again, it depends on the specifications and detection targets. Some things to consider: 1. Router restarts take a while. Consumer-grade routers can take a minute or more to complete a restart to the point where it will respond to ping. Carrier-grade routers are more variable but in general have so many options built into them that it takes longer to complete a restart cycle. Since you are talking consumer-grade gear, you probably don't want to be sensitive to CP power sags. 2. Depending on the technology used on the link, you may get some short-term outages, on the order of seconds, so doing "rapid" pings do nothing for you. During my DSL time, ATM would drop out for short intervals -- so watch out for nuisance trips. 3. Some routers implement ping limiting, so you have to balance your monitoring sample rate against DoS susceptibility. Offhand, I don't know the granularity of consumer router ping limiting, as I've never had that question pop up. 4. How large a monitoring server are you willing to devote to such a system? My web host monitoring used a 400-MHz Pentium II box, and it didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had Linux, pulled from a junk pile.) I was monitoring about 150 web host servers. Extraolatuing the system load on that Cobalt box, I could have handled 1500 web host servers and more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat Dec 15 22:26:00 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 15 Dec 2018 17:26:00 -0500 Subject: Pinging a Device Every Second In-Reply-To: <3ecbcd6b-6b2c-6a9c-1a99-ef8adcef6cf9@oneunified.net> References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> <3ecbcd6b-6b2c-6a9c-1a99-ef8adcef6cf9@oneunified.net> Message-ID: <22558.1544912760@turing-police.cc.vt.edu> On Sat, 15 Dec 2018 12:20:01 -0700, Raymond Burkholder said: > Another aspect is congestion.  Large uploads or downloads can cause > packet loss (including dropping the pings with which you are testing).  > Therefore management packets such as these could be marked and > processed, on your side at least, with a higher priority. How much depends on whether the CPE gear has software recent enough to avoid massive bufferbloat. From list at satchell.net Sat Dec 15 22:45:55 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 15 Dec 2018 14:45:55 -0800 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: <0732eda9-7e31-432c-4db3-a58dfcf0395b@satchell.net> On 12/15/18 12:03 PM, Saku Ytti wrote: > On Sat, 15 Dec 2018 at 18:52, Stephen Satchell wrote: > >> Short answer: about 1500 bits of bandwidth, and the CPU loading on the > > I can't parse this. > > 1000 hosts at 1 pps would be 672kbps on ethernetII encapulation with > minimum size frames. > The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits per ping cycle at the monitor server, but not on each leaf router. The designer would need to analyze the network topology to see if there are any possible choke points. In a cable internet system, 1000 customers on a single up/down channel pair would require 700 kilobits each way per ping cycle. Yes, this is payload bandwidth, it doesn't include packet overhead. From baldur.norddahl at gmail.com Sun Dec 16 01:21:13 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 16 Dec 2018 02:21:13 +0100 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: Hi Customers do not usually complain about 2 minutes of downtime unless it is a repeating event. We will therefore offer such customers to put their line on monitor mode, which means we will add them to smokeping. You could also start the ping once a second thing, which would be no problem if it is only a few customers on monitor mode. However 2 minutes of downtime is a symptom of bad wifi more often than the internet connection. Regards, Baldur On Sat, Dec 15, 2018 at 7:33 PM Colton Conor wrote: > The problem I am trying to solve is to accurately be able to tell a > customer if their home internet connection was up or down. Example, > customer calls in and says my internet was down for 2 minutes yesterday. We > need to be able to verify that their internet connection was indeed down. > Right now we have no easy way to do this. Getting metrics like packet loss > and jitter would be great too, though I realize ICMP data path does not > always equal customer experience as many network device prioritize ICMP > traffic. However ICMP pings over the internet do usually accurately tell if > a customers modem is indeed online or not. > > Most devices out in the field like ONT's and DSL modems do not support > SNMP but rather use TR-069 for management. Most of these devices only check > into the TR-069 ACS server once a day. > If the consumer device does support SNMP, they usually have weak broadcom > or qualcom SoC processors, outdated linux kernel embedded operating > systems, limited ram, and storage. Most of these can't handle SNMP walks > every minute let alone every 5. We are talking about sub $100 routers here > not Juniper, Cisco, Arista, etc. > > Most all of these consumer devices are connected to an carrier aggregation > device like a DSLAM, OLT, ethernet switch, or wireless access point. These > access devices do support SNMP, but most manufactures recommend only 5 > minute SNMP poling, so a 2 minute outage would not easily be detected. Plus > its hard to correlate that consumer X is on port Y on access switch, and > get that right for a tier 1 CSR. > > The only two ways I think I can accomplish this is: > 1. ICMP pings to a device every so many seconds. Almost every device > supports responding to WAN ICMP pings. > or > 2. IPFIX sampling at core router, and then drilling down by customer IP. I > think this will tell me if any data was flowing to this customers IP on a > second by second basis, but won't necessarily give us an up or down > indicator. Requires nothing from the consumer's router. > > > > > > On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell > wrote: > >> On 12/15/18 7:48 AM, Colton Conor wrote: >> > How much compute and network resources does it take for a NMS to: >> > >> > 1. ICMP ping a device every second >> > 2. Record these results. >> > 3. Report an alarm after so many seconds of missed pings. >> > >> > We are looking for a system to in near real-time monitor if an end >> > customers router is up or down. SNMP I assume would be too resource >> > intensive, so ICMP pings seem like the only logical solution. >> > >> > The question is once a second pings too polling on an NMS and a consumer >> > grade router? Does it take much network bandwidth and CPU resources from >> > both the NMS and CPE side? >> > >> > Lets say this is for a 1,000 customer ISP. >> >> What problem are you trying to solve, exactly? That more than anything >> will dictate what you do. >> >> Short answer: about 1500 bits of bandwidth, and the CPU loading on the >> remote device is almost invisible. Remember the only real difference >> between ping and SNMP monitoring (UDP) is the organization of the bits >> in the packet and the protocol number in the IP header. It's still one >> packet pair exchanged, unless you get really ambitious with your SNMP >> OID list. >> >> When I was in a medium-sized hosting company, I developed an SNMP-based >> monitoring system that would query a number of load parameters (CPU, >> disk, network, overall) on a once a minute schedule, and would keep >> history for hours on the monitoring server. The boss fretted about the >> load such monitoring would impose. He never saw any. >> >> For pure link monitoring, which is what I'm hearing you want to do, in >> my experience I found that a six-second ping cycle gives lots of early >> warning for link failures. Again, it depends on the specifications and >> detection targets. >> >> Some things to consider: >> >> 1. Router restarts take a while. Consumer-grade routers can take a >> minute or more to complete a restart to the point where it will respond >> to ping. Carrier-grade routers are more variable but in general have so >> many options built into them that it takes longer to complete a restart >> cycle. Since you are talking consumer-grade gear, you probably don't >> want to be sensitive to CP power sags. >> >> 2. Depending on the technology used on the link, you may get some >> short-term outages, on the order of seconds, so doing "rapid" pings do >> nothing for you. During my DSL time, ATM would drop out for short >> intervals -- so watch out for nuisance trips. >> >> 3. Some routers implement ping limiting, so you have to balance your >> monitoring sample rate against DoS susceptibility. Offhand, I don't know >> the granularity of consumer router ping limiting, as I've never had that >> question pop up. >> >> 4. How large a monitoring server are you willing to devote to such a >> system? My web host monitoring used a 400-MHz Pentium II box, and it >> didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had >> Linux, pulled from a junk pile.) I was monitoring about 150 web host >> servers. Extraolatuing the system load on that Cobalt box, I could have >> handled 1500 web host servers and more. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Sun Dec 16 08:07:06 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 16 Dec 2018 10:07:06 +0200 Subject: Pinging a Device Every Second In-Reply-To: <0732eda9-7e31-432c-4db3-a58dfcf0395b@satchell.net> References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> <0732eda9-7e31-432c-4db3-a58dfcf0395b@satchell.net> Message-ID: On Sun, 16 Dec 2018 at 00:48, Stephen Satchell wrote: > The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits Why? Why did you choose 1500b(it) ping, instead of minimum size or 1500B(ytes) IP packets? Minimum: 672kbps 1500B: 12.16Mbps -- ++ytti From list at satchell.net Sun Dec 16 15:56:39 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 16 Dec 2018 07:56:39 -0800 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> <0732eda9-7e31-432c-4db3-a58dfcf0395b@satchell.net> Message-ID: On 12/16/18 12:07 AM, Saku Ytti wrote: > On Sun, 16 Dec 2018 at 00:48, Stephen Satchell wrote: > >> The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits > > Why? Why did you choose 1500b(it) ping, instead of minimum size or > 1500B(ytes) IP packets? > > Minimum: 672kbps > 1500B: 12.16Mbps I was going from memory, and it is by no means perfect. But... A standard ping packet, with no IP options or additional payload, is 64 bytes or 512 bits. If an application wants to make an accurate round-trip-delay measurement, it can insert the output of a microsecond clock, and compare that value for when the answer packet comes back. Add at least 32 bits, perhaps 64. Even with this sensible amount of extra ping payload, there is still plenty of "bandwidth allocation" available to account for encapsulations: IPIP, VPN, MPLS, Ethernet framing, ATM framing, &c. I can see a network operator with a complex mesh network wanting to turn on Record Route (RFC791), which adds 24+(hops*32, max 536) bits to both ping and ping-response packets. So my 1500 bits for ping was not bad Tennessee windage for the application described by the original poster, plus comments added by others. In fact, it would overestimate the bandwidth required, but not by that much. As for how much the use of ping would affect the CPU loading of the device, that would depend a great deal on the implementation of the TCP/IP stack in the CPE. When I wrote _Linux IP Stacks Commentary_, the code to implement ping is packet receipt, a very small block of code to build the reply packet, and packet send the above mentioned 64 bytes of packet. Consider another service: Network Time Protocol. Unlike ping, there is quite a bit of CPU load to process the time information through the smoothing filters. (Counter argument: a properly implemented version of NTP will send time requests with separations of 60-1024 seconds.) From saku at ytti.fi Sun Dec 16 17:12:02 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 16 Dec 2018 19:12:02 +0200 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> <0732eda9-7e31-432c-4db3-a58dfcf0395b@satchell.net> Message-ID: On Sun, 16 Dec 2018 at 17:59, Stephen Satchell wrote: > A standard ping packet, with no IP options or additional payload, is 64 > bytes or 512 bits. If an application wants to make an accurate > round-trip-delay measurement, it can insert the output of a microsecond > clock, and compare that value for when the answer packet comes back. > Add at least 32 bits, perhaps 64. Unsure about standard, but Linux iputils ping does this: ╰─ ping -4 ftp.funet.fi PING ftp.funet.fi (193.166.3.2) 56(84) bytes of data. 64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=1 ttl=243 time=47.8 ms This means: 20B IPv4 Header 08B ICMP Header 56B ICMP data ------------------ 84B IPv4 packet Add to that EthernetII encapsulation, and you have: 122B or 976bits or 976kbps for 1k hosts. Vast majority of that ICMP data is unnecessary trash, if you use minimum size EthernetII payload you have 18bytes ICMP data, _free of charge_, which is plenty to add timestamping and what have you, without increasing link utilisation. i.e. 672kbps for 1k hosts will allow you to send 18B of arbitrary data, and there is no way to use less bps. > I can see a network operator with a complex mesh network wanting to turn > on Record Route (RFC791), which adds 24+(hops*32, max 536) bits to both > ping and ping-response packets. Be careful about what you intend to measure. I would try to measure customer experience as much as possible, IP options are punted for software processing and may forward differently and will forward with several orders of magnitude higher jitter and will experience larger packet loss. -- ++ytti From holbor at sonss.net Sun Dec 16 22:09:02 2018 From: holbor at sonss.net (Richard Holbo) Date: Sun, 16 Dec 2018 14:09:02 -0800 Subject: Pinging a Device Every Second In-Reply-To: References: <038fb072-0e7c-7b0d-17e5-e4ed0b88da0e@satchell.net> Message-ID: YMMV... but most of the CPE routers I've seen lately have icmp turned off by default, so you'll be messing with settings in the customer router. Do you provide the router? Also agree with Baldur, 2 minutes... is more than likely the customer router rebooting itself or something like that. If they support SNMP at ALL uptime is a VERY useful OID. I've finally given up an started to provide the customer CPE.. since we're going to get the blame anyway... might as well be able to monitor it in a fashion that we can choose and charge another $10 a month for managed router. TR-069 has settings to change the update frequency as well and it can be persuaded to provide SNMPish information. I also run a smokeping for _special_ customers. I've found that 20 rapid pings every 1 minute gives me pretty good stats on jitter and if they really are having an issue, I'll see it at that granularity. /rh On Sat, Dec 15, 2018 at 5:22 PM Baldur Norddahl wrote: > > Hi > > Customers do not usually complain about 2 minutes of downtime unless it is a repeating event. We will therefore offer such customers to put their line on monitor mode, which means we will add them to smokeping. You could also start the ping once a second thing, which would be no problem if it is only a few customers on monitor mode. > > However 2 minutes of downtime is a symptom of bad wifi more often than the internet connection. > > Regards, > > Baldur > > > On Sat, Dec 15, 2018 at 7:33 PM Colton Conor wrote: >> >> The problem I am trying to solve is to accurately be able to tell a customer if their home internet connection was up or down. Example, customer calls in and says my internet was down for 2 minutes yesterday. We need to be able to verify that their internet connection was indeed down. Right now we have no easy way to do this. Getting metrics like packet loss and jitter would be great too, though I realize ICMP data path does not always equal customer experience as many network device prioritize ICMP traffic. However ICMP pings over the internet do usually accurately tell if a customers modem is indeed online or not. >> >> Most devices out in the field like ONT's and DSL modems do not support SNMP but rather use TR-069 for management. Most of these devices only check into the TR-069 ACS server once a day. >> If the consumer device does support SNMP, they usually have weak broadcom or qualcom SoC processors, outdated linux kernel embedded operating systems, limited ram, and storage. Most of these can't handle SNMP walks every minute let alone every 5. We are talking about sub $100 routers here not Juniper, Cisco, Arista, etc. >> >> Most all of these consumer devices are connected to an carrier aggregation device like a DSLAM, OLT, ethernet switch, or wireless access point. These access devices do support SNMP, but most manufactures recommend only 5 minute SNMP poling, so a 2 minute outage would not easily be detected. Plus its hard to correlate that consumer X is on port Y on access switch, and get that right for a tier 1 CSR. >> >> The only two ways I think I can accomplish this is: >> 1. ICMP pings to a device every so many seconds. Almost every device supports responding to WAN ICMP pings. >> or >> 2. IPFIX sampling at core router, and then drilling down by customer IP. I think this will tell me if any data was flowing to this customers IP on a second by second basis, but won't necessarily give us an up or down indicator. Requires nothing from the consumer's router. >> >> >> >> >> >> On Sat, Dec 15, 2018 at 10:51 AM Stephen Satchell wrote: >>> >>> On 12/15/18 7:48 AM, Colton Conor wrote: >>> > How much compute and network resources does it take for a NMS to: >>> > >>> > 1. ICMP ping a device every second >>> > 2. Record these results. >>> > 3. Report an alarm after so many seconds of missed pings. >>> > >>> > We are looking for a system to in near real-time monitor if an end >>> > customers router is up or down. SNMP I assume would be too resource >>> > intensive, so ICMP pings seem like the only logical solution. >>> > >>> > The question is once a second pings too polling on an NMS and a consumer >>> > grade router? Does it take much network bandwidth and CPU resources from >>> > both the NMS and CPE side? >>> > >>> > Lets say this is for a 1,000 customer ISP. >>> >>> What problem are you trying to solve, exactly? That more than anything >>> will dictate what you do. >>> >>> Short answer: about 1500 bits of bandwidth, and the CPU loading on the >>> remote device is almost invisible. Remember the only real difference >>> between ping and SNMP monitoring (UDP) is the organization of the bits >>> in the packet and the protocol number in the IP header. It's still one >>> packet pair exchanged, unless you get really ambitious with your SNMP >>> OID list. >>> >>> When I was in a medium-sized hosting company, I developed an SNMP-based >>> monitoring system that would query a number of load parameters (CPU, >>> disk, network, overall) on a once a minute schedule, and would keep >>> history for hours on the monitoring server. The boss fretted about the >>> load such monitoring would impose. He never saw any. >>> >>> For pure link monitoring, which is what I'm hearing you want to do, in >>> my experience I found that a six-second ping cycle gives lots of early >>> warning for link failures. Again, it depends on the specifications and >>> detection targets. >>> >>> Some things to consider: >>> >>> 1. Router restarts take a while. Consumer-grade routers can take a >>> minute or more to complete a restart to the point where it will respond >>> to ping. Carrier-grade routers are more variable but in general have so >>> many options built into them that it takes longer to complete a restart >>> cycle. Since you are talking consumer-grade gear, you probably don't >>> want to be sensitive to CP power sags. >>> >>> 2. Depending on the technology used on the link, you may get some >>> short-term outages, on the order of seconds, so doing "rapid" pings do >>> nothing for you. During my DSL time, ATM would drop out for short >>> intervals -- so watch out for nuisance trips. >>> >>> 3. Some routers implement ping limiting, so you have to balance your >>> monitoring sample rate against DoS susceptibility. Offhand, I don't know >>> the granularity of consumer router ping limiting, as I've never had that >>> question pop up. >>> >>> 4. How large a monitoring server are you willing to devote to such a >>> system? My web host monitoring used a 400-MHz Pentium II box, and it >>> didn't even breathe hard. (A 1U Cobalt box, repurposed with Red Had >>> Linux, pulled from a junk pile.) I was monitoring about 150 web host >>> servers. Extraolatuing the system load on that Cobalt box, I could have >>> handled 1500 web host servers and more. >>> From beecher at beecher.cc Mon Dec 17 16:17:44 2018 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 17 Dec 2018 11:17:44 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: That email addy is from an employee that just left the company. For any of the administrators it should be safe to remove the subscription for that address. ( I can confirm directly from my company email account if that's required for confirmation. ) I can try and chase someone internally to see if I can get the auto-responder replied stopped to the list. On Fri, Dec 14, 2018 at 2:32 PM Josh Luthman wrote: > Yes. Same email address. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Fri, Dec 14, 2018 at 1:59 PM Dan Hollis > wrote: > >> Yes, someone needs to forcefully remove this subscription: >> >> Subject: Re: Your message to lemanm at yahoo-inc.com (was: Re: Extending >> network over a dry pair) >> >> >> On Fri, 14 Dec 2018, Grant Taylor via NANOG wrote: >> >> > Is anyone else receiving the "Your message to REDACTED (was: >> $oldSubject)" >> > auto-responses to posts to NANOG? >> > >> > I've been seeing them for three or four days now. >> > >> > >> > >> > -- >> > Grant. . . . >> > unix || die >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Mon Dec 17 16:33:50 2018 From: ccummings at coeur.com (Cummings, Chris) Date: Mon, 17 Dec 2018 16:33:50 +0000 Subject: Hostwinds LLC. (AS54290) Contact Message-ID: Good Morning, If anyone from Hostwinds LLC, AS54290 is on the list, can you please contact me at ccummings at coeur.com? Also, if anyone would like to send me contact info if you have it, it would be greatly appreciated. Thanks! Chris Cummings -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Mon Dec 17 16:48:26 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 17 Dec 2018 09:48:26 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: <682c8f26-9557-2a41-4577-6b20f05950c8@spamtrap.tnetconsulting.net> On 12/17/2018 09:17 AM, Tom Beecher wrote: > I can try and chase someone internally to see if I can get the > auto-responder replied stopped to the list. Can I request that the (any) auto-responder be enhanced to: 1) Not respond to emails with Precedence: List 2) Retain a list of source addresses that it has responded to such that it can respond only once to each source. 3) Possibly reply with the null reverse path (if systems will allow). The pedantic part of me would also like to see the Auto-Submitted: header with a value of auto-replied, or less accurate auto-generated. [1] [1] https://www.iana.org/assignments/auto-submitted-keywords/auto-submitted-keywords.xhtml -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From beecher at beecher.cc Mon Dec 17 17:21:15 2018 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 17 Dec 2018 12:21:15 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: <682c8f26-9557-2a41-4577-6b20f05950c8@spamtrap.tnetconsulting.net> References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> <682c8f26-9557-2a41-4577-6b20f05950c8@spamtrap.tnetconsulting.net> Message-ID: We got something in to fix the behavior of the auto-responder to not reply to things with a Precedence header present. I'm told something was already in the pipe on the auto-submitted header as well. On Mon, Dec 17, 2018 at 11:50 AM Grant Taylor via NANOG wrote: > On 12/17/2018 09:17 AM, Tom Beecher wrote: > > I can try and chase someone internally to see if I can get the > > auto-responder replied stopped to the list. > > Can I request that the (any) auto-responder be enhanced to: > > 1) Not respond to emails with Precedence: List > 2) Retain a list of source addresses that it has responded to such that > it can respond only once to each source. > 3) Possibly reply with the null reverse path (if systems will allow). > > The pedantic part of me would also like to see the Auto-Submitted: > header with a value of auto-replied, or less accurate auto-generated. [1] > > [1] > > https://www.iana.org/assignments/auto-submitted-keywords/auto-submitted-keywords.xhtml > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Dec 17 18:06:35 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 17 Dec 2018 10:06:35 -0800 Subject: JunOS Fusion Provider Edge Message-ID: Hey there Any ISP using Juniper Fusion Provider Edge? https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html I am trying to chat with an engineer besides Juniper engineers to understand how buggy (or not) this is to go on production for a medium size ISP. Any feedback good/bad appreciated. -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Mon Dec 17 18:26:11 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Mon, 17 Dec 2018 12:26:11 -0600 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: Fusion has made a lot more sense since Juniper changed the licensing model from every switch AND the MX to just the MX. We've deployed it in some of our sites. It is very cool from a forwarding plane perspective, but from a control plane standpoint it's very...meh. For example, you can't get SNMP oids for light levels or even read them right from the CLI. You have to log into the satellite switch like you would log into an FPC just to get light levels. That's probably the dumbest thing we've dealt with though. I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications. From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. Very interested in hearing about other's experiences with Fusion, good, bad, and ugly. -Matt On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin wrote: > Hey there > > Any ISP using Juniper Fusion Provider Edge? > > > https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html > > > I am trying to chat with an engineer besides Juniper engineers to > understand how buggy (or not) this is to go on production for a medium size > ISP. > > Any feedback good/bad appreciated. > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Mon Dec 17 19:00:07 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 17 Dec 2018 12:00:07 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> <682c8f26-9557-2a41-4577-6b20f05950c8@spamtrap.tnetconsulting.net> Message-ID: On 12/17/2018 10:21 AM, Tom Beecher wrote: > We got something in to fix the behavior of the auto-responder to not > reply to things with a Precedence header present. > > I'm told something was already in the pipe on the auto-submitted header > as well. Cool. Thank you for the update. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From ryangard at gmail.com Mon Dec 17 19:09:06 2018 From: ryangard at gmail.com (Ryan Gard) Date: Mon, 17 Dec 2018 14:09:06 -0500 Subject: Twitter (AS13414) Peering Contact Message-ID: Afternoon, If there's anybody on the list from Twitter AS13414, if they could contact me off list? Further, if you have contact info outside of the standard peering email, that would be fantastic. We've made a few attempts over the last year give or take to reach out, and unfortunately we've seen nothing but silence in response. Thanks! -- Ryan Gard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Dec 17 19:12:56 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 17 Dec 2018 11:12:56 -0800 Subject: Twitter (AS13414) Peering Contact In-Reply-To: References: Message-ID: i will make an intro offlist On Mon, Dec 17, 2018 at 11:09 AM Ryan Gard wrote: > Afternoon, > > If there's anybody on the list from Twitter AS13414, if they could contact > me off list? Further, if you have contact info outside of the standard > peering email, that would be fantastic. > > We've made a few attempts over the last year give or take to reach out, > and unfortunately we've seen nothing but silence in response. > > Thanks! > > -- > Ryan Gard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robt at cymru.com Mon Dec 17 20:28:50 2018 From: robt at cymru.com (Rabbi Rob Thomas) Date: Mon, 17 Dec 2018 15:28:50 -0500 Subject: historical Bogon lists In-Reply-To: <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> Message-ID: <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear team, > Have you tried reaching out to Team Cymru? They provide bogon > feeds in a number of different formats. I would be surprised if > they don't have the ability to provide historical versions of the > bogon list. - It's probably worth asking. I have found them to > be very responsive and quite helpful. Thank you for the kind words, Grant! Sadly, we don't keep an archive of prior bogon lists, so we can't help here. Sorry! Be well, Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwYBwEACgkQQ+hhYvqF 8o1yFw/+LqPEPlkhwvKc+W/ewZesdM1ubCNmFZcqtTqUqgNLPK6d9b/G2g1sLrSf 7VNenl2YdZc3qjWfPN7fBKc5onlwNI4lOomJ4bCiqVaGLU46fUVWB5HShiUTZhT9 a0WT+kuqHxUFVM2ILffBusWnuSST7vFONJae122ktcnODIdLfU9P1SmNaz2RzXo8 GBRXgqvP3OD6oDE5GWG4jN1AoSJze8d+GzF1fLPr4Ln4+9YBJKaE3CgH7Qfp5lN/ t6+6gdiqRbGcX0UnOi9JXpI7n6IsJeczkRISdzakiKFoznfVnUH3n7rOv/pDSi+H EBa31e2klCViKCxf+eBuQNWVMTLxzL93CtSlHMoJqOYqlPv4T1KlyovUPuGFA+FX fkkQN+bBh/4ihxdPs62e71XOkq1lOE77OwpDROPl+nQQgoe2e5AIo1V+4ls3Qz2N FJ9s01SLH6f3cTLbom3Rj2VaO6BvmjWjcj03yZ4MtnR1wNrcrZ+VBgJayNRba6yi dRtX2KilryR+nLoVpTMcnCpP8lVxiePtfjQFh21C0jj8Dodp4YvzTWI2PZ+Zf8N8 pdOeO3XyjFD0FnJl+dvGOo5ErAqzgzDKMpD1euy/w/jXZQtmoaPasMDBF+TvXKFx Ql4JoXQpE4V8ZAyu2cTh0NN/4ce1GpHhny8pjSC9hAs+pYCvkqo= =OAK0 -----END PGP SIGNATURE----- From mehmet at akcin.net Mon Dec 17 20:51:38 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 17 Dec 2018 12:51:38 -0800 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> Message-ID: Back to main discussion.... How do we choose the best transport? One question, how much people care about vendor diversity? I do and did care. I don’t want to put all my eggs in one basket. Do you care? Thank you Mehmet On Sat, Dec 15, 2018 at 11:30 Mike Hammett wrote: > I haven't. > > Sure, but the equipment still does smaller channels. Going to 100G or 400G > for just over 10G seems silly. > > If Equinix had reasonable cross connects, I'd just LAG 10Gs. The cost of a > pair of Equinix cross connects isn't much less than the 10G wave. > Thankfully I'm only in one datacenter with such a ridiculous model. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Ben Cannon" > *To: *"Mike Hammett" > *Cc: *"Luke Guillory" , "nanog" < > nanog at nanog.org> > *Sent: *Saturday, December 15, 2018 1:27:21 PM > > *Subject: *Re: How to choose a transport(terrestrial/subsea) > > Mike have you looked at Packetlight? Long-haul is mostly jumping to 100 > or even 400g coherent. > > -Ben > > On Dec 15, 2018, at 8:53 AM, Mike Hammett wrote: > > FS had one, but it's not on their site anymore. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Luke Guillory" > *To: *"Mike Hammett" > *Cc: *"Eric Dugas" , "nanog" > *Sent: *Saturday, December 15, 2018 10:52:19 AM > *Subject: *Re: How to choose a transport(terrestrial/subsea) > > No cost affective 10x10G to 100G muxponder? > > > > Sent from my iPad > > On Dec 15, 2018, at 4:46 AM, Mike Hammett wrote: > > heh, cross connects are indeed a major issue. I have a need for > 10G > transport. My equipment supports 40G. The carriers aren't terribly > interested in doing 40G transport (at least not at a reasonable price, one > quote was over 4x a 10G). 100G-capable switches cost too much. Equinix > charges as much for a pair of cross connects as a 10G wave. Carriers aren't > likely to be interested in using bidi optics or passive WDM to overcome the > ridiculous cross connect charges. > > This all complicates how one chooses transport. There's no easy path > forward. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Eric Dugas" > *To: *"Mehmet Akcin" > *Cc: *"nanog" > *Sent: *Friday, December 14, 2018 11:42:53 AM > *Subject: *Re: How to choose a transport(terrestrial/subsea) > > I also look at hand-off locations (as long as it doesn't compromise the > overall robustness of the design). > > Most providers will be able to hand-off in the BMMR of a carrier hotel and > some will have the flexibility to hand-off in particular suites within the > same building or other locations near where the cross-connects fees are > lower. I've seen cross-connect fees between $50 up to $750 MRC so if you > need multiple wavelengths (for capacity), the cross-connect fees are going > to make a huge difference on the total MRC. > > Eric > > > > Luke Guillory > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > Reserve Telecommunications > 100 RTC Dr > > Reserve, LA 70084 > > > > > > > > *Disclaimer:* > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore > does not accept liability for any errors or omissions in the contents of > this message, which arise as a result of e-mail transmission. > > On Dec 14 2018, at 12:17 pm, Mehmet Akcin wrote: > > Thank you everyone incredible amounts of responses for my how to choose a > transit provider smail earlier. > > How do you choose transport & backbone? > > Looking at key aspects like route information, diversity, aerial vs under > ground fiber, age of fiber, outage history, length, but what else? > > I will get both transport and transit as two seperate blogs. > > I will also submit as a nanog paper for the meeting after next, or maybe > next? I am probably too late by now. > > Thank you for all your help. I will add your names to the thank you line > ;-) > -- > Mehmet > +1-424-298-1903 > > > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Dec 17 22:56:48 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 17 Dec 2018 16:56:48 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> Message-ID: <1159613672.4254.1545087404111.JavaMail.mhammett@ThunderFuck> As long as you understand that vendor diversity doesn't imply route diversity. Diversity within a given vendor is still subject to the same chassis, the same automation platform, the same billing department, etc. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "Mike Hammett" Cc: "Ben Cannon" , "nanog" Sent: Monday, December 17, 2018 2:51:38 PM Subject: Re: How to choose a transport(terrestrial/subsea) Back to main discussion.... How do we choose the best transport? One question, how much people care about vendor diversity? I do and did care. I don’t want to put all my eggs in one basket. Do you care? Thank you Mehmet On Sat, Dec 15, 2018 at 11:30 Mike Hammett < nanog at ics-il.net > wrote: I haven't. Sure, but the equipment still does smaller channels. Going to 100G or 400G for just over 10G seems silly. If Equinix had reasonable cross connects, I'd just LAG 10Gs. The cost of a pair of Equinix cross connects isn't much less than the 10G wave. Thankfully I'm only in one datacenter with such a ridiculous model. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Ben Cannon" < ben at 6by7.net > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog" < nanog at nanog.org > Sent: Saturday, December 15, 2018 1:27:21 PM Subject: Re: How to choose a transport(terrestrial/subsea) Mike have you looked at Packetlight? Long-haul is mostly jumping to 100 or even 400g coherent. -Ben On Dec 15, 2018, at 8:53 AM, Mike Hammett < nanog at ics-il.net > wrote:
FS had one, but it's not on their site anymore. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Luke Guillory" < lguillory at reservetele.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Eric Dugas" < edugas at unknowndevice.ca >, "nanog" < nanog at nanog.org > Sent: Saturday, December 15, 2018 10:52:19 AM Subject: Re: How to choose a transport(terrestrial/subsea) No cost affective 10x10G to 100G muxponder? Sent from my iPad On Dec 15, 2018, at 4:46 AM, Mike Hammett < nanog at ics-il.net > wrote:
heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Eric Dugas" < edugas at unknowndevice.ca > To: "Mehmet Akcin" < mehmet at akcin.net > Cc: "nanog" < nanog at nanog.org > Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Dec 14 2018, at 12:17 pm, Mehmet Akcin < mehmet at akcin.net > wrote:
Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903
-- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Mon Dec 17 22:59:44 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 17 Dec 2018 17:59:44 -0500 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> Message-ID: <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > One question, how much people care about vendor diversity? I do and did > care. I don’t want to put all my eggs in one basket. Do you care? Thank you There are advantages and disadvantages to vendor diversity. As advantages, you won't be subject to complete loss of connection because of a single dispute or provisioning/control plane issue with that one vendor. You can also more easily pit vendors against each other for pricing if you are already vendor-diverse. As a disadvantage, not only does vendor diversity obviously not imply route diversity, but it will completely put the onus on you to ensure route diversity if you want it. With a single vendor, you can demand that your circuits have route diversity and, assuming you trust them, they have all the information they need to make that happen for you. -- Brandon Martin From jbfixurpc at gmail.com Tue Dec 18 05:36:14 2018 From: jbfixurpc at gmail.com (Joe) Date: Mon, 17 Dec 2018 23:36:14 -0600 Subject: Stupid Question maybe? Message-ID: Apologizes in advance for a simple question. I am finding conflicting definitions of Class networks. I was always under the impression that a class "A" network was a /8 a class "B" network was a /16 and a class "C" network was a /24. Recently, I was made aware that a class "A" was indeed a /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a class "C" is actually a /16. Is this different depending on the IP segment, i.e. if it is part of a RC1918 group it is classed differently (maybe a course I missed?) Or aren't all IP's classed the same. I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with 172.16/12 as one that just a VLSM between the two. Again, apologizes for the simple question, just can't seem to find a solid answer. Happy holidays all the same! -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhaustin at gmail.com Tue Dec 18 05:45:03 2018 From: jhaustin at gmail.com (Jeremy Austin) Date: Mon, 17 Dec 2018 20:45:03 -0900 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: You may find this helpful in your search for knowledge: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing "Classful" networking is rarely useful other than for understanding How We Got Here. There's a handy table in the linked article which expresses each IPv4 mask length in relation to how many A, B, or C networks it is. jermudgeon On Mon, Dec 17, 2018 at 8:37 PM Joe wrote: > > Apologizes in advance for a simple question. I am finding conflicting > definitions of Class networks. I was always under the impression that a > class "A" network was a /8 a class "B" network was a /16 and a class "C" > network was a /24. Recently, I was made aware that a class "A" was indeed a > /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a > class "C" is actually a /16. > > Is this different depending on the IP segment, i.e. if it is part of a > RC1918 group it is classed differently (maybe a course I missed?) Or aren't > all IP's classed the same. > I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or > wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with > 172.16/12 as one that just a VLSM between the two. > > Again, apologizes for the simple question, just can't seem to find a solid > answer. > > Happy holidays all the same! > -Joe > -- Jeremy Austin jhaustin at gmail.com (907) 895-2311 office (907) 803-5422 cell -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Dec 18 06:15:26 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Dec 2018 22:15:26 -0800 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: <8C499F2E-3B79-4140-AE87-5F1F8C1DF512@delong.com> Class A,B,C represent the position of the first 0 bit in the address and a corresponding natural netmask. A=1st bit (/8), B=2nd bit (10xxxxxx, /16), and C=3rd bit (110xxxxx, /24). The confusion you seem to be experiencing related to the number of A,B, and C networks defined in RFC-1918 (private address space). In this case, a ingle A (10.0.0.0/8), 16 Bs (172.16.0.0/12), and 256 Cs (192.168.0.0/16) were set aside for private networks. Later, an additional block was reserved for CGNAT intermediary space (100.64.0.0/10 IIRC). Owen > On Dec 17, 2018, at 21:36, Joe wrote: > > > Apologizes in advance for a simple question. I am finding conflicting definitions of Class networks. I was always under the impression that a class "A" network was a /8 a class "B" network was a /16 and a class "C" network was a /24. Recently, I was made aware that a class "A" was indeed a /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a class "C" is actually a /16. > > Is this different depending on the IP segment, i.e. if it is part of a RC1918 group it is classed differently (maybe a course I missed?) Or aren't all IP's classed the same. > I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with 172.16/12 as one that just a VLSM between the two. > > Again, apologizes for the simple question, just can't seem to find a solid answer. > > Happy holidays all the same! > -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Dec 18 06:33:02 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 18 Dec 2018 08:33:02 +0200 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: I've, generally, always been wary about these "satellite" systems since Cisco introduced them with the ASR9000v back in 2012. My whole thing is it being a closed system that requires the same vendor hardware from start to finish. Back then, wiring things up redundantly where all ports are in action was not possible, not sure where things stand now but I guess there are solutions to that. Ultimately, I didn't want to be in a position where I am no longer satisfied with the solution, but my only recourse is to either lose the investment or continue with the same vendor just to save face. Recently, we had to vote with our feet as Juniper behaved badly on their EX4550's and EX4600's. So we are now switching to Arista, including getting rid of the old gear as it can't scale anymore. If we had gone this satellite route, we'd have fewer options to maneuver. The vendors love to push these systems because they say it will simplify your life - and in essence, it probably will - but this is a proper lock-in of note, and no vendor hates that. Mark. On 17/Dec/18 20:26, Matt Erculiani wrote: > Fusion has made a lot more sense since Juniper changed the licensing > model from every switch AND the MX to just the MX. > > We've deployed it in some of our sites. It is very cool from a > forwarding plane perspective, but from a control plane standpoint it's > very...meh. For example, you can't get SNMP oids for light levels or > even read them right from the CLI. You have to log into the satellite > switch like you would log into an FPC just to get light levels. That's > probably the dumbest thing we've dealt with though. I've also heard > you can have them do local L2 forwarding, which can be nice for > latency and conserving uplink bandwidth, but we don't do any L2 that > way so I wouldn't know the implications. From what we can tell though, > it does give you Trio L3 performance and features with a MUCH cheaper > port cost which is exactly what we were looking for, the extended > reach of the chassis was just a fantastic bonus. > > We also REALLY like that we can have one pair of MX dists for a whole > data center with hundreds of thousands of square feet of raised floor > and deploy QFX5100 or EX4300 switches in every pod and haul back over > just a few pairs of fiber. Saves a lot of time because all that's > required to turn up a new connection is a cross connect in the pod. It > also allows us to offer copper ports very far away from the MX device, > which would normally require media converters. > > We've wanted to experiment with doing this over dark fiber in the > metro as well, but we want to feel out any kinks locally before we add > additional failure modes. > > Very interested in hearing about other's experiences with Fusion, > good, bad, and ugly. > > -Matt > > On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin > wrote: > > Hey there > > Any ISP using Juniper Fusion Provider Edge?  > > https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html > > > I am trying to chat with an engineer besides Juniper engineers to > understand how buggy (or not) this is to go on production for a > medium size ISP. > > Any feedback good/bad appreciated.  > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From streinerj at gmail.com Tue Dec 18 11:45:25 2018 From: streinerj at gmail.com (Justin M. Streiner) Date: Tue, 18 Dec 2018 06:45:25 -0500 (EST) Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: On Mon, 17 Dec 2018, Joe wrote: > Apologizes in advance for a simple question. I am finding conflicting > definitions of Class networks. I was always under the impression that a > class "A" network was a /8 a class "B" network was a /16 and a class "C" > network was a /24. Recently, I was made aware that a class "A" was indeed a > /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a class > "C" is actually a /16. As others have mentioned, IP address classes are no longer relevant, beyond understanding how things were done in the past. Address classes haven't been used for assignment or routing purposes for over 20 years, but the term lives on because it keeps getting undeserved new life in networking classes and training materials. Classfull address assignment/routing was horribly inefficient for two main reasons, both of which were corrected by a combination of CIDR and VLSM: 1. Assigning IP networks on byte boundaries (/8, /16, /24) was not granular enough to allow networks to be assigned as close as possible to actual need in many cases. If you only needed 25 addresses for a particular network, you had to request or assign a /24 (legacy class C), resulting in roughly 90% of those addresses being wasted. 2. Classfull routing was starting to bloat routing tables, both inside of and between networks. If a network had a little over 8,000 IPv4 addresses under its control, in the pre-CIDR days, that meant that they or their upstream provider would need to announce routes for 32 individual and/or contiguous /24s. In the post-CIDR world, under the the best circumstances (all of their address space is contiguous and falls on an appropriately maskable boundary like x.y.0.0 through x.y.31.0), that network could announce a single /19. When scaled up to a full Internet routing table, the possible efficiencies become much more obvious. The network operator community has has to continue to grapple with routing table bloat since then, but for different reasons. Had CIDR, VLSM, and NAT/PAT not been implemented, we (collectively) would have run out of IPv4 addresses many years before we actually did. Thank you jms > Is this different depending on the IP segment, i.e. if it is part of a > RC1918 group it is classed differently (maybe a course I missed?) Or aren't > all IP's classed the same. > I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or > wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with > 172.16/12 as one that just a VLSM between the two. > > Again, apologizes for the simple question, just can't seem to find a solid > answer. > > Happy holidays all the same! > -Joe > From beecher at beecher.cc Tue Dec 18 13:29:18 2018 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 18 Dec 2018 08:29:18 -0500 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: If you want the full historical definition, blow the dust off RFC791, and open your hymnals to section 2.3. "Addresses are fixed length of four octets (32 bits). An address begins with a network number, followed by local address (called the "rest" field). There are three formats or classes of internet addresses: in class a, the high order bit is zero, the next 7 bits are the network, and the last 24 bits are the local address; in class b, the high order two bits are one-zero, the next 14 bits are the network and the last 16 bits are the local address; in class c, the high order three bits are one-one-zero, the next 21 bits are the network and the last 8 bits are the local address." This is depicted visually if that's your deal in RFC796. Back in '81 this was totally fine, but times change, and CIDR / VLSM eventually made way more sense. It's good to have at least a passing understanding of the old terminology simply because documentation for newer stuff likes to reference it, but don't get too hung up on it. On Tue, Dec 18, 2018 at 6:47 AM Justin M. Streiner wrote: > On Mon, 17 Dec 2018, Joe wrote: > > > Apologizes in advance for a simple question. I am finding conflicting > > definitions of Class networks. I was always under the impression that a > > class "A" network was a /8 a class "B" network was a /16 and a class "C" > > network was a /24. Recently, I was made aware that a class "A" was > indeed a > > /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a > class > > "C" is actually a /16. > > As others have mentioned, IP address classes are no longer relevant, > beyond understanding how things were done in the past. Address classes > haven't been used for assignment or routing purposes for over 20 years, > but the term lives on because it keeps getting undeserved new life in > networking classes and training materials. > > Classfull address assignment/routing was horribly inefficient for two main > reasons, both of which were corrected by a combination of CIDR and VLSM: > > 1. Assigning IP networks on byte boundaries (/8, /16, /24) was not > granular enough to allow networks to be assigned as close as possible to > actual need in many cases. If you only needed 25 addresses for a > particular network, you had to request or assign a /24 (legacy class C), > resulting in roughly 90% of those addresses being wasted. > > 2. Classfull routing was starting to bloat routing tables, both inside of > and between networks. If a network had a little over 8,000 IPv4 addresses > under its control, in the pre-CIDR days, that meant that they or their > upstream provider would need to announce routes for 32 individual and/or > contiguous /24s. In the post-CIDR world, under the the best > circumstances (all of their address space is contiguous and falls on an > appropriately maskable boundary like x.y.0.0 through x.y.31.0), that > network could announce a single /19. When scaled up to a full Internet > routing table, the possible efficiencies become much more obvious. The > network operator community has has to continue to grapple with routing > table bloat since then, but for different reasons. > > Had CIDR, VLSM, and NAT/PAT not been implemented, we (collectively) would > have run out of IPv4 addresses many years before we actually did. > > Thank you > jms > > > Is this different depending on the IP segment, i.e. if it is part of a > > RC1918 group it is classed differently (maybe a course I missed?) Or > aren't > > all IP's classed the same. > > I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or > > wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with > > 172.16/12 as one that just a VLSM between the two. > > > > Again, apologizes for the simple question, just can't seem to find a > solid > > answer. > > > > Happy holidays all the same! > > -Joe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.herbert at gmail.com Tue Dec 18 13:32:13 2018 From: george.herbert at gmail.com (George William Herbert) Date: Tue, 18 Dec 2018 05:32:13 -0800 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: Sent from my iPhone > On Dec 17, 2018, at 9:36 PM, Joe wrote: > > Recently, I was made aware that a class "A" was indeed a /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a class "C" is actually a /16. You had it right to start with. A is (was) /8, B is /16, C is /24 All on human easily readable byte boundaries in IPv4 space. The RFC-1918 internal space was allocated from a /8, a /12, and a /16 sized block. Those aren't A, B, or C network sizes. Whoever corrected you is confused. Anyone who networked before and during the CIDR transition won't forget this... -george -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Dec 18 13:39:36 2018 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 18 Dec 2018 08:39:36 -0500 Subject: historical Bogon lists In-Reply-To: <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> Message-ID: I wonder if there's value in having the lists that Team Cymru generates auto pushed to a public Git repo. Covers historical changes for folks who want that, and also provides a more modern ingestion method for automation around that info. (Not that I'm hating on wget / curl ... :) ) On Mon, Dec 17, 2018 at 3:31 PM Rabbi Rob Thomas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear team, > > > Have you tried reaching out to Team Cymru? They provide bogon > > feeds in a number of different formats. I would be surprised if > > they don't have the ability to provide historical versions of the > > bogon list. - It's probably worth asking. I have found them to > > be very responsive and quite helpful. > > Thank you for the kind words, Grant! Sadly, we don't keep an archive > of prior bogon lists, so we can't help here. Sorry! > > Be well, > Rob. > - -- > Rabbi Rob Thomas Team Cymru > "It is easy to believe in freedom of speech for those with whom we > agree." - Leo McKern > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwYBwEACgkQQ+hhYvqF > 8o1yFw/+LqPEPlkhwvKc+W/ewZesdM1ubCNmFZcqtTqUqgNLPK6d9b/G2g1sLrSf > 7VNenl2YdZc3qjWfPN7fBKc5onlwNI4lOomJ4bCiqVaGLU46fUVWB5HShiUTZhT9 > a0WT+kuqHxUFVM2ILffBusWnuSST7vFONJae122ktcnODIdLfU9P1SmNaz2RzXo8 > GBRXgqvP3OD6oDE5GWG4jN1AoSJze8d+GzF1fLPr4Ln4+9YBJKaE3CgH7Qfp5lN/ > t6+6gdiqRbGcX0UnOi9JXpI7n6IsJeczkRISdzakiKFoznfVnUH3n7rOv/pDSi+H > EBa31e2klCViKCxf+eBuQNWVMTLxzL93CtSlHMoJqOYqlPv4T1KlyovUPuGFA+FX > fkkQN+bBh/4ihxdPs62e71XOkq1lOE77OwpDROPl+nQQgoe2e5AIo1V+4ls3Qz2N > FJ9s01SLH6f3cTLbom3Rj2VaO6BvmjWjcj03yZ4MtnR1wNrcrZ+VBgJayNRba6yi > dRtX2KilryR+nLoVpTMcnCpP8lVxiePtfjQFh21C0jj8Dodp4YvzTWI2PZ+Zf8N8 > pdOeO3XyjFD0FnJl+dvGOo5ErAqzgzDKMpD1euy/w/jXZQtmoaPasMDBF+TvXKFx > Ql4JoXQpE4V8ZAyu2cTh0NN/4ce1GpHhny8pjSC9hAs+pYCvkqo= > =OAK0 > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James at arenalgroup.co Tue Dec 18 14:48:49 2018 From: James at arenalgroup.co (James Breeden) Date: Tue, 18 Dec 2018 14:48:49 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> , <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> Message-ID: I can't stress enough the importance of controlling your own route and even cable diversity. Require KMZs of the routes for any services you take (especially single path Wave type services). Put them in the contracts if you can. I've had at least 1 situation where we had vendor diversity and what was supposed to be route diversity- 3 separate waves coming south and southeast out of a datacenter to 3 separate cities. Imagine my surprise when we took a outage one day that severed all 3 circuits. Yes all 3 circuits, going to 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to show up in the same sheath of cable at one location that happened to experience backhoe fade. Was not a good day.... James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG on behalf of Brandon Martin Sent: Monday, December 17, 2018 4:59:44 PM To: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > One question, how much people care about vendor diversity? I do and did > care. I don’t want to put all my eggs in one basket. Do you care? Thank you There are advantages and disadvantages to vendor diversity. As advantages, you won't be subject to complete loss of connection because of a single dispute or provisioning/control plane issue with that one vendor. You can also more easily pit vendors against each other for pricing if you are already vendor-diverse. As a disadvantage, not only does vendor diversity obviously not imply route diversity, but it will completely put the onus on you to ensure route diversity if you want it. With a single vendor, you can demand that your circuits have route diversity and, assuming you trust them, they have all the information they need to make that happen for you. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From robt at cymru.com Tue Dec 18 17:00:15 2018 From: robt at cymru.com (Rabbi Rob Thomas) Date: Tue, 18 Dec 2018 12:00:15 -0500 Subject: historical Bogon lists In-Reply-To: References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> Message-ID: <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Tom, > I wonder if there's value in having the lists that Team Cymru > generates auto pushed to a public Git repo. Covers historical > changes for folks who want that, and also provides a more modern > ingestion method for automation around that info. (Not that I'm > hating on wget / curl ... :) ) We'd be happy to make that happen, if folks are keen. We're fine with Git, as we use it regularly. Be well! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= =i27M -----END PGP SIGNATURE----- From randy at psg.com Tue Dec 18 17:40:01 2018 From: randy at psg.com (Randy Bush) Date: Tue, 18 Dec 2018 09:40:01 -0800 Subject: rfd Message-ID: do you have rfd on? with what parms? randy From job at instituut.net Tue Dec 18 17:43:15 2018 From: job at instituut.net (Job Snijders) Date: Tue, 18 Dec 2018 18:43:15 +0100 Subject: rfd In-Reply-To: References: Message-ID: On Tue, Dec 18, 2018 at 6:40 PM Randy Bush wrote: > > do you have rfd on? with what parms? I assume rfd in this context means "Route Flap Dampening". NTT / AS 2914 does *not* have Route Flap Dampening configured, as is documented here https://us.ntt.net/support/policy/routing.cfm#routedampening Kind regards, Job From lathama at gmail.com Tue Dec 18 17:45:49 2018 From: lathama at gmail.com (Andrew Latham) Date: Tue, 18 Dec 2018 11:45:49 -0600 Subject: rfd In-Reply-To: References: Message-ID: Route Flap Damping via https://tools.ietf.org/html/rfc2439 for everyone. On Tue, Dec 18, 2018 at 11:42 AM Randy Bush wrote: > do you have rfd on? with what parms? > > randy > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Dec 18 18:17:42 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 18 Dec 2018 10:17:42 -0800 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> Message-ID: That's a great example. Thank you James for sharing. I have done so many "GROUND TRUTH" visits where randomly selected certain physical points to validate physical diversity. Have seen several places where dual risers in the building were present or multiple building entries were available but not used. Ground truth events are certainly important and can be eye opening. It does not necessarily scale as you can't really walk all the fiber A-Z everywhere.. i know. On Tue, Dec 18, 2018 at 6:49 AM James Breeden wrote: > I can't stress enough the importance of controlling your own route and > even cable diversity. Require KMZs of the routes for any services you take > (especially single path Wave type services). Put them in the contracts if > you can. > > > I've had at least 1 situation where we had vendor diversity and what was > supposed to be route diversity- 3 separate waves coming south and southeast > out of a datacenter to 3 separate cities. Imagine my surprise when we took > a outage one day that severed all 3 circuits. Yes all 3 circuits, going to > 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to > show up in the same sheath of cable at one location that happened to > experience backhoe fade. Was not a good day.... > > > > *James W. Breeden* > > *Managing Partner* > > > > *[image: logo_transparent_background]* > > *Arenal Group:* Arenal Consulting Group | Acilis Telecom | Pines Media > > PO Box 1063 | Smithville, TX 78957 > > Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | > www.arenalgroup.co > ------------------------------ > *From:* NANOG on behalf of Brandon Martin < > lists.nanog at monmotha.net> > *Sent:* Monday, December 17, 2018 4:59:44 PM > *To:* nanog at nanog.org > *Subject:* Re: How to choose a transport(terrestrial/subsea) > > On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > > > One question, how much people care about vendor diversity? I do and did > > care. I don’t want to put all my eggs in one basket. Do you care? Thank > you > > There are advantages and disadvantages to vendor diversity. > > As advantages, you won't be subject to complete loss of connection > because of a single dispute or provisioning/control plane issue with > that one vendor. You can also more easily pit vendors against each > other for pricing if you are already vendor-diverse. > > As a disadvantage, not only does vendor diversity obviously not imply > route diversity, but it will completely put the onus on you to ensure > route diversity if you want it. With a single vendor, you can demand > that your circuits have route diversity and, assuming you trust them, > they have all the information they need to make that happen for you. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Dec 18 18:44:20 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 18 Dec 2018 10:44:20 -0800 Subject: Stupid Question maybe? Message-ID: <20181218104420.BD32417D@m0117568.ppops.net> --- beecher at beecher.cc wrote: From: Tom Beecher It's good to have at least a passing understanding of the old terminology simply because documentation for newer stuff likes to reference it... -------------------------------------- Plus it's fun (and informative about a netgeek's skill) when they call, say, 72.234.7.0/24 a Class C and you can say no it's not. Then you see if they can say why. If they can't, well...ummm... I really mess with them after that. It helps pass the work day. >;-) https://en.wikipedia.org/wiki/Classful_network#Classful_addressing_definition scott ps. Be sure to send Wikipedia a small Christmas gift. It's invaluable. From mark.tinka at seacom.mu Tue Dec 18 18:45:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 18 Dec 2018 20:45:29 +0200 Subject: rfd In-Reply-To: References: Message-ID: <285b5949-a028-f4ba-be1d-d10eeeedd944@seacom.mu> On 18/Dec/18 19:40, Randy Bush wrote: > do you have rfd on? with what parms? We don't do it (SEACOM, AS37100). Mark. From mark.tinka at seacom.mu Tue Dec 18 18:45:48 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 18 Dec 2018 20:45:48 +0200 Subject: rfd In-Reply-To: References: Message-ID: On 18/Dec/18 19:40, Randy Bush wrote: > do you have rfd on? with what parms? We don't do it (SEACOM, AS37100). Mark. From saku at ytti.fi Tue Dec 18 19:00:17 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 18 Dec 2018 21:00:17 +0200 Subject: rfd In-Reply-To: References: Message-ID: I always wondered why does it have to be so binary. I don't want to decide for my customers if partial visibility is better than busy CPU, but I do appreciate stability. Why can't we have local-pref penalty for flapping route. If it's only option, keep offering it, if there are other, more stable options, offer those. -- ++ytti From jared at puck.nether.net Tue Dec 18 19:01:20 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Dec 2018 14:01:20 -0500 Subject: rfd In-Reply-To: References: Message-ID: <2A102BAA-5956-4FA0-AB64-E81C0561B29C@puck.nether.net> > On Dec 18, 2018, at 1:45 PM, Mark Tinka wrote: > > > > On 18/Dec/18 19:40, Randy Bush wrote: > >> do you have rfd on? with what parms? > > We don't do it (SEACOM, AS37100). Similarly 20940 does not use it. I find it hard to see a case where we would turn it on. - jared From bill at herrin.us Tue Dec 18 19:10:50 2018 From: bill at herrin.us (William Herrin) Date: Tue, 18 Dec 2018 11:10:50 -0800 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: On Mon, Dec 17, 2018 at 9:36 PM Joe wrote: > Apologizes in advance for a simple question. I am finding conflicting > definitions of Class networks. I was always under the impression > that a class "A" network was a /8 a class "B" network was a /16 > and a class "C" network was a /24. Recently, I was made aware > that a class "A" was indeed a /8 and a class "B" was actually > a /12 (172.16/172.31.255.255) while a class "C" is actually a /16. Hi Joe, Take everything you've ever heard about classful networking, throw it away, and outside of trivia games never think about it again. Network address classes haven't been a valid part of TCP/IP for more than two decades now. For historical trivia purposes only, the CIDR /16 replaced class B. Had RFC 1918 come out before CIDR (RFC 1519), 172.16.0.0-172.31.255.255 would have described 16 contiguous class B's, not just one, while 192.168.0.0-192.168.255.255 would have described 256 contiguous class C's. In fact, this terminology is used in RFC 1918's predecessor, RFC 1597. And if you really like trivia, find the math error in RFC 1597. Class A started at 0.0.0.0, class B started at 128.0.0.0 and class C started at 192.0.0.0. There was also a class D (now the multicast address space) starting at 224.0.0.0 and a class E (still reserved) starting at 240.0.0.0. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From gtaylor at tnetconsulting.net Tue Dec 18 19:23:01 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 18 Dec 2018 12:23:01 -0700 Subject: historical Bogon lists In-Reply-To: <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> Message-ID: <8aebaa01-78bb-a385-6b45-7c8c22e405b5@spamtrap.tnetconsulting.net> On 12/18/2018 10:00 AM, Rabbi Rob Thomas wrote: > We'd be happy to make that happen, if folks are keen. I'm keen. > We're fine with Git, as we use it regularly. How big is the bogon list? (I can't look at the moment.) Is it something that you can store the entire list periodically, or as it changes? I'm wondering about long term space consumption. Particularly if I'd like to have a local copy. }:-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Tue Dec 18 19:31:36 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 18 Dec 2018 12:31:36 -0700 Subject: Stupid Question maybe? In-Reply-To: <20181218104420.BD32417D@m0117568.ppops.net> References: <20181218104420.BD32417D@m0117568.ppops.net> Message-ID: <9e7d5d1b-ef2f-d181-a42d-1f37d12664db@spamtrap.tnetconsulting.net> On 12/18/2018 11:44 AM, Scott Weeks wrote: > It's good to have at least a passing understanding of the old terminology > simply because documentation for newer stuff likes to reference it... Agreed. I seldom see people actually talking about class {A,B,C,D,E} networks as such. It's almost always a reference to the size ~> netmask ~> prefix of a network. > Plus it's fun (and informative about a netgeek's skill) when they call, > say, 72.234.7.0/24 a Class C and you can say no it's not. Then you see > if they can say why. If they can't, well...ummm... I really mess with > them after that. It helps pass the work day. >;-) You can safely say that 72.234.7.0/24 is a Class C /sized/ network. While it happens to be in the (former) Class A IP /range/. But it is most decidedly /not/ a Class A /network/. > ps. Be sure to send Wikipedia a small Christmas gift. It's invaluable. Agreed! -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From Brian at ampr.org Tue Dec 18 19:50:07 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 18 Dec 2018 11:50:07 -0800 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: <20181218195007.GB52359@meow.BKantor.net> /24 is certainly cleaner than 255.255.255.0. I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519. - Brian From surfer at mauigateway.com Tue Dec 18 19:58:06 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 18 Dec 2018 11:58:06 -0800 Subject: Stupid Question maybe? Message-ID: <20181218115806.BD3247FD@m0117568.ppops.net> --- nanog at nanog.org wrote: From: Grant Taylor via NANOG You can safely say that 72.234.7.0/24 is a Class C /sized/ network. -------------------------------------- But most don't say that. They just say it's a Class C, which it most assuredly is not. I heckle them until they can give the correct answer: leading bits are 110 or it's not a Class C subnet. scott From saku at ytti.fi Tue Dec 18 20:11:46 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 18 Dec 2018 22:11:46 +0200 Subject: Stupid Question maybe? In-Reply-To: <20181218195007.GB52359@meow.BKantor.net> References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: On Tue, 18 Dec 2018 at 21:52, Brian Kantor wrote: > of the address word was efficient, since subnet masks were always > a series of ones followd by zeros with no interspersing, which > was incorporated (or independently invented) about a decade later >From protocol POV there is no reason to make this assumption. It just seems to make more sense for humans and modern hardware make the assumption for forwarding, like it does make assumptions for the distribution of prefix sizes, anything to get more out of less. For ACL that assumption is still not true. It's optimisation which loses information which for the common case does not matter. -- ++ytti From SNaslund at medline.com Tue Dec 18 20:36:52 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 20:36:52 +0000 Subject: Stupid Question maybe? In-Reply-To: <20181218195007.GB52359@meow.BKantor.net> References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> It is a matter of machine readability vs human readability. Remember the IP was around when routers did not have a lot of horsepower. The dotted decimal notation was a compromise between pure binary (which the equipment used) and human readability. VLSM seems obvious now but in the beginning organizing various length routes into very expensive memory and low horsepower processors meant that it was much easier to break routes down along byte boundaries. This meant you only had four different lengths of route to deal with. It was intended to eliminate multiple passes sorting the tables. I am not quite sure what you mean about interspersing zeros, that would be meaningless. Remember that it is a mask. The address bits which are masked as 1s are significant to routing. The bits that are masked with 0s are the host portion and don't matter to the network routing table. Steven Naslund Chicago IL >/24 is certainly cleaner than 255.255.255.0. > >I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd >by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519. > - Brian From SNaslund at medline.com Tue Dec 18 20:55:14 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 20:55:14 +0000 Subject: rfd In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> Mainly because propagating a flapping route across the entire Internet is damaging to performance of things other your own equipment and that of your customer. It is just "bad manners" to propagate a flapping route to your peers and it helps maintain a minimum level of stability that it required to keep you "on the Internet". Imagine a table where 1000s of providers are each sending 100s of unstable routes and that those unstable routes might be redistributing into various IGPs that may not respond very gracefully to rapid table changes (like most distance vector IGPs). Also think of this scenario, your link to your customer might be flapping but that same customer might have other carriers advertising the same address space over a stable link. In that case you would be doing a dis-service by not withdrawing that route and having a local-pref does not help since you don't necessarily have visibility to all of your customers other carrier networks. You do have the ability to clear the RFD timers for a route if you need to manually intervene for example when you know for a fact that you fixed the problem. That means that if no one is watching or intervening the network will "do the safe thing". Steven Naslund Chicago IL > >I always wondered why does it have to be so binary. > >I don't want to decide for my customers if partial visibility is better than busy CPU, but I do appreciate stability. Why can't we have local-pref penalty for flapping route. If it's only option, keep offering it, if there are other, more >stable options, offer those. > >-- > ++ytti From job at instituut.net Tue Dec 18 20:59:45 2018 From: job at instituut.net (Job Snijders) Date: Tue, 18 Dec 2018 21:59:45 +0100 Subject: rfd In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> Message-ID: Hi Steve, Lowering the LP would achieve the outcome you desire, provided there are (stable) alternative paths. What you advocate results in absolute outages in what may already be precarious situations (natural disasters?) - what Saku Ytti suggests like a less painful alternative with desirable properties. Kind regards, Job On Tue, Dec 18, 2018 at 21:56 Naslund, Steve wrote: > Mainly because propagating a flapping route across the entire Internet is > damaging to performance of things other your own equipment and that of your > customer. It is just "bad manners" to propagate a flapping route to your > peers and it helps maintain a minimum level of stability that it required > to keep you "on the Internet". Imagine a table where 1000s of providers > are each sending 100s of unstable routes and that those unstable routes > might be redistributing into various IGPs that may not respond very > gracefully to rapid table changes (like most distance vector IGPs). Also > think of this scenario, your link to your customer might be flapping but > that same customer might have other carriers advertising the same address > space over a stable link. In that case you would be doing a dis-service by > not withdrawing that route and having a local-pref does not help since you > don't necessarily have visibility to all of your customers other carrier > networks. > > You do have the ability to clear the RFD timers for a route if you need to > manually intervene for example when you know for a fact that you fixed the > problem. That means that if no one is watching or intervening the network > will "do the safe thing". > > Steven Naslund > Chicago IL > > > > >I always wondered why does it have to be so binary. > > > >I don't want to decide for my customers if partial visibility is better > than busy CPU, but I do appreciate stability. Why can't we have local-pref > penalty for flapping route. If it's only option, keep offering it, if there > are other, more >stable options, offer those. > > > >-- > > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Tue Dec 18 21:13:06 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 18 Dec 2018 22:13:06 +0100 Subject: Stupid Question maybe? In-Reply-To: <20181218195007.GB52359@meow.BKantor.net> References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: Why do we still have network equipment, where half the configuration requires netmask notation, the other half requires CIDR and to throw you off, they also included inverse netmasks. tir. 18. dec. 2018 20.51 skrev Brian Kantor : > > /24 is certainly cleaner than 255.255.255.0. > > I seem to remember it was Phil Karn who in the early 80's suggested > that expressing subnet masks as the number of bits from the top end > of the address word was efficient, since subnet masks were always > a series of ones followd by zeros with no interspersing, which > was incorporated (or independently invented) about a decade later > as CIDR a.b.c.d/n notation in RFC1519. > - Brian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Tue Dec 18 21:24:09 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 21:24:09 +0000 Subject: rfd In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> Remember always that the local pref is just that, YOUR local preference. Sending that flapping route upstream does not give your peer the option to ignore it. In any case, the downside is that you have to process that route and then choose whether or not to use it. It’s like saying “now that you have processed this unstable route and burned your CPU cycles, I am now giving you to option not to install it into your table”. Remember also that we are only talking about default behavior here. You always have the option to override it by changing timer, penalties, or shutting down RFD all together. We are only talking about day-to-day operation here. Also, keep in mind that when we are talking about alterative stable paths we are only talking about what your network sees, not the entire Internet. If you as a service provider are experiencing major issues, you may see a route to me as stable or unstable but making global routing decisions based on that is not sound. What might be best for your customer or your business might not be best for the Internet community as a whole. It is a matter of scale, how many services providers can allow how many unstable routes before the entire network becomes regionally or globally unstable. It’s important to remember that flapping routes leave a certain amount of data in flight with no destination which is detrimental to overall performance. As we move into a V6 world we are again worried about the size of the global routing tables and pushing routing performance. Instability of routes is dangerous to system running near the limits. Propagating a known unstable route would be a major shift in routing policy. Today, you either say you can reach something or you don’t say anything. Using the suggested alternative adds the option of “I might be able to reach this but not reliably” which then brings about metrics of “how reliably?” and that is a huge shift in how global routing works. We have been struggling with a backbone routing protocol that does not really do a good job of understanding bandwidth and multiple paths so I would suggest that adding “maybe” routes is not a good idea. At least using RFD you can explain to your customer why they are not reachable rather than explaining how you made a manual decision to dump them for the “good of the Internet”. There is also a business penalty to the service provider that exposes instability to network. People don’t want to peer or send traffic through unstable network regions. Steve >Hi Steve, > >Lowering the LP would achieve the outcome you desire, provided there are (stable) alternative paths. > >What you advocate results in absolute outages in what may already be precarious situations (natural disasters?) - what Saku Ytti suggests like a less painful alternative with desirable properties. > >Kind regards, > >Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Dec 18 21:26:54 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 18 Dec 2018 13:26:54 -0800 Subject: rfd Message-ID: <20181218132654.BD324DAB@m0117568.ppops.net> --- SNaslund at medline.com wrote: From: "Naslund, Steve" Mainly because propagating a flapping route across the entire Internet is damaging... ------------------------------------------------ https://www.researchgate.net/publication/220850232_Route_Flap_Damping_Made_Usable scott From SNaslund at medline.com Tue Dec 18 21:29:52 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 21:29:52 +0000 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD2B2@WAUPRDMBXP1.medline.com> Two reasons : 1. Legacy configuration portability, people learned a certain way and all versions of code understand a certain way. The best way to correct that issue it to accept either of them. 2. The inverse mask is indeed a pain in the neck but is technically correct. The subnet mask is used where the equipment cares to work with the network portion of the address (ignoring the host). The inverse mask is important where the equipment cares more about the host we are referring to (ignoring the network). It’s a bit of a cheat to allow for code used in routing to be used for ACL and firewall without modification to the code. For example, the same code piece that routes a network toward an Ethernet interface can be reused to route a host toward a null interface. Steven Naslund Chicago IL >Why do we still have network equipment, where half the configuration requires netmask notation, the other half requires CIDR and to throw you off, they also included inverse netmasks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Dec 18 21:32:38 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 18 Dec 2018 23:32:38 +0200 Subject: rfd In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> Message-ID: What would really be of interest to me would be for those that run RFD to measure its impact to their network (positive or otherwise) so we have something scientific to base on. The theory (and practice of old) tells us that RFD is either very good, or very bad. There are probably more folk that have turned it off than run it, or vice versa. Ultimately, if we can get the state of RFD's performance in 2018 on an axis, our words will likely carry more weight. Mark. On 18/Dec/18 23:24, Naslund, Steve wrote: > > Remember always that the local pref is just that, YOUR local > preference.  Sending that flapping route upstream does not give your > peer the option to ignore it.  In any case, the downside is that you > have to process that route and then choose whether or not to use it.  > It’s like saying “now that you have processed this unstable route and > burned your CPU cycles, I am now giving you to option not to install > it into your table”.  Remember also that we are only talking about > default behavior here.  You always have the option to override it by > changing timer, penalties, or shutting down RFD all together.  We are > only talking about day-to-day operation here. > >   > > Also, keep in mind that when we are talking about alterative stable > paths we are only talking about what your network sees, not the entire > Internet.  If you as a service provider are experiencing major issues, > you may see a route to me as stable or unstable but making global > routing decisions based on that is not sound.  What might be best for > your customer or your business might not be best for the Internet > community as a whole.   It is a matter of scale, how many services > providers can allow how many unstable routes before the entire network > becomes regionally or globally unstable.  It’s important to remember > that flapping routes leave a certain amount of data in flight with no > destination which is detrimental to overall performance.  As we move > into a V6 world we are again worried about the size of the global > routing tables and pushing routing performance.  Instability of routes > is dangerous to system running near the limits.  Propagating a known > unstable route would be a major shift in routing policy.  Today, you > either say you can reach something or you don’t say anything.  Using > the suggested alternative adds the option of “I might be able to reach > this but not reliably” which then brings about metrics of “how > reliably?” and that is a huge shift in how global routing works.  We > have been struggling with a backbone routing protocol that does not > really do a good job of understanding bandwidth and multiple paths so > I would suggest that adding “maybe” routes is not a good idea. > > At least using RFD you can explain to your customer why they are not > reachable rather than explaining how you made a manual decision to > dump them for the “good of the Internet”.  There is also a business > penalty to the service provider that exposes instability to network.  > People don’t want to peer or send traffic through unstable network > regions. > >   > > Steve > >   > >   > > >Hi Steve, > > >  > > >Lowering the LP would achieve the outcome you desire, provided there > are (stable) alternative paths. > > >  > > >What you advocate results in absolute outages in what may already be > precarious situations (natural disasters?) - what Saku Ytti suggests > like a less painful alternative with desirable properties. > > >  > > >Kind regards, > > >  > > >Job > >   > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Tue Dec 18 21:39:52 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 21:39:52 +0000 Subject: rfd In-Reply-To: <20181218132654.BD324DAB@m0117568.ppops.net> References: <20181218132654.BD324DAB@m0117568.ppops.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD2D9@WAUPRDMBXP1.medline.com> It is an interesting article but confirms a few things to me. 1. There are only a very small percentage of flapping routes causing an inordinate amount of BGP processing. Would it be more effective to implement this route damping mechanism world wide or try to eliminate the source of the instability? 2. The paper does not suggest how you would implement this on a global basis and what the "some people have it and some don't" scenario looks like. The guy in the middle pays the price for your unstable customer. 3. This affects such a small subset of global routes that we should be spending our time solving more globally impactful changes to BGP (like path bandwidth awareness). Steven Naslund Chicago IL >Mainly because propagating a flapping route across the entire Internet is damaging... >------------------------------------------------ > >https://www.researchgate.net/publication/220850232_Route_Flap_Damping_Made_Usable > >scott From bill at herrin.us Tue Dec 18 21:44:16 2018 From: bill at herrin.us (William Herrin) Date: Tue, 18 Dec 2018 13:44:16 -0800 Subject: Stupid Question maybe? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD2B2@WAUPRDMBXP1.medline.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD2B2@WAUPRDMBXP1.medline.com> Message-ID: On Tue, Dec 18, 2018 at 1:30 PM Naslund, Steve wrote: > 2. The inverse mask is indeed a pain in the neck but is technically correct. Hi Steve, That's like saying the inverse mask is technically correct when the computer wants to decide whether to arp for the next hop. No sale man. A AND NETMASK ?= B AND NETMASK is exactly the same operation as A OR inverse NETMASK ?= B OR inverse NETMASK While A AND inverse NETMASK ?= B AND inverse NETMASK *never* yields useful knowledge. No sale. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From job at ntt.net Tue Dec 18 21:54:19 2018 From: job at ntt.net (Job Snijders) Date: Tue, 18 Dec 2018 22:54:19 +0100 Subject: rfd In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> Message-ID: <20181218215419.GL1566@hanna.meerval.net> Dear Steve, No worries, I have not forgotten the transitive properties of the LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF modifications (and the attribute itself), are local to the Autonomous System in which they were set, but the effects of such settings can percolate further into the routing system. A great example is the "BGP Graceful Shutdown" mechanism (science partially documented in https://tools.ietf.org/html/rfc6198, actual specification here https://tools.ietf.org/html/rfc8326). What is interesting is that by considering a path (any path, could be flapping) my network will propagate alternative paths to my neighboring networks, or possibly even *withdraw* my announcement in favor of alternative (stable?) paths via competitors. By attaching a lower LOCAL_PREF value to a given path for a period of time as a 'penalty' for flapping, I suspect the visiblity of that flapping will be greatly reduced. This of course doesn't hold true when the only origin of the path is flapping, but in many flapping cases I triaged it was clear that only one out of many links was the root of the flapping. I'm not sure I share your concerns about scale, it appears that so far we seem to be doing just fine without "route flap dampening, penalty type: suppress". No customers ask for it, in fact many are relieved we don't use it. None of our peering partners ask for it either. When we see oscillating paths we reach out to the offending party and ask them to fix it, or take unilateral action within a specific time frame. Kind regards, Job From SNaslund at medline.com Tue Dec 18 22:00:21 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 22:00:21 +0000 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD2B2@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD301@WAUPRDMBXP1.medline.com> I see it more used in terms of firewall operations on what are normally network routing devices. I suppose someone with Cisco IOS architecture inside knowledge could tell us why they use that notation with ACLs primarily. I have never seen a computer want or accept an inverse mask so it is irrelevant to ARP. The question with ARP is "are we on the same network". The naming of inverse net mask is really tragic. It should be called net mask and host mask because that is what they really are. In a net mask the 1s denote the network portion, in the host mask (nee inverse netmask) the 1s denote the host portion. That's all there is too it. The inverse mask could be used to figure out whether to ARP or not. You just have to decide if the 1s or 0s mean that something is significant or not significant to your calculation. Using the inverse mask I could decide to dump the portion = 1. Using the network mask I can dump the portion = 0. Nothing states how you have to use the information. Steve >Hi Steve, > >That's like saying the inverse mask is technically correct when the computer wants to decide whether to arp for the next hop. No sale man. > >A AND NETMASK ?= B AND NETMASK > >is exactly the same operation as > >A OR inverse NETMASK ?= B OR inverse NETMASK > >While A AND inverse NETMASK ?= B AND inverse NETMASK *never* yields useful knowledge. > >No sale. > >Regards, >Bill Herrin From SNaslund at medline.com Tue Dec 18 22:01:47 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 22:01:47 +0000 Subject: rfd In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD311@WAUPRDMBXP1.medline.com> I think you will find that very hard to evaluate since the value of RFD will be different in different network regions. For example, it is probably good practice to run RFD toward a customer on an unstable access link. It might not be a good idea to run it on a major backbone link that could possibly flap a large number of times in a very short period due to something like a maintenance activity. Also, in areas that are largely on a fiber infrastructure will see RFD in a much different light than a largely wireless infrastructure that might be subject to momentary interference or interruptions. I think it is most safe to say that RFD needs to be evaluated and tuned for what you want it to do. Penalties are never a pleasant thing but they prevent lawlessness. That is exactly what RFD does. You are the cop that decides how to enforce the laws. In fact in my experience people could also get much better network performance overall by properly tuning BGP timers but very few actually do it. I bet you could improve the Internet stability way more by doing that. Steven Naslund Chicago IL >What would really be of interest to me would be for those that run RFD to measure its impact to their network (positive or otherwise) so we have something scientific to base on. > >The theory (and practice of old) tells us that RFD is either very good, or very bad. There are probably more folk that have turned it off than run it, or vice versa. Ultimately, if we can get the state >of RFD's performance in 2018 on an axis, our words will likely carry more weight. >Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Tue Dec 18 22:10:33 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Dec 2018 22:10:33 +0000 Subject: rfd In-Reply-To: <20181218215419.GL1566@hanna.meerval.net> References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> <20181218215419.GL1566@hanna.meerval.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD34E@WAUPRDMBXP1.medline.com> I will grant you that no customer ever asked for route dampening. I also realize that RFD is much less important now than in the past. I come from the ARPANET/DDN ages of the Internet and can tell you that RFD was absolutely critical in the days of very under powered routers and very unstable data links. I remember when it was quite hard to maintain a 64k link to some locations at all. There might be less of a need for such a simple RFD but it did serve its purpose. In fact, my main argument on this whole topic is that RFD is not relevant enough to waste a lot of effort on a global accepted mechanism. It is just not the low hanging fruit of routing performance improvements. I see two major improvements to global routing...congestion avoidance (which goes a little bit with bandwidth awareness but not exactly) and multipath load balancing (which kind of requires a congestion avoidance awareness). Both of these are going to be extremely difficult issues on a global scale of adoption but that's what is needed. Steven Naslund Chicago IL >Dear Steve, > >No worries, I have not forgotten the transitive properties of the LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF modifications (and the attribute itself), are local to the Autonomous System in which they were >set, but the effects of such settings can percolate further into the routing system. > >A great example is the "BGP Graceful Shutdown" mechanism (science partially documented in https://tools.ietf.org/html/rfc6198, actual specification here https://tools.ietf.org/html/rfc8326). What is interesting is that by >considering a path (any path, could be flapping) my network will propagate alternative paths to my neighboring networks, or possibly even *withdraw* my announcement in favor of alternative >(stable?) paths via competitors. > >By attaching a lower LOCAL_PREF value to a given path for a period of time as a 'penalty' for flapping, I suspect the visiblity of that flapping will be greatly reduced. This of course doesn't hold true when the only origin of the path is >flapping, but in many flapping cases I triaged it was clear that only one out of many links was the root of the flapping. > >I'm not sure I share your concerns about scale, it appears that so far we seem to be doing just fine without "route flap dampening, penalty >type: suppress". No customers ask for it, in fact many are relieved we don't use it. None of our peering partners ask for it either. When we see oscillating paths we reach out to the offending party and ask them to fix it, or take >unilateral action within a specific time frame. > >Kind regards, > >Job From dedelman at iname.com Tue Dec 18 22:12:45 2018 From: dedelman at iname.com (David Edelman) Date: Tue, 18 Dec 2018 17:12:45 -0500 Subject: Stupid Question maybe? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> Message-ID: <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I seem to remember that before the advent of VLSM and CIDR there was no requirement for the 1 bits in the netmask to be contiguous with no intervening 0 bits and there was always someone who tested it out on a production network just to prove a point (usually only once) Dave - -----Original Message----- From: NANOG On Behalf Of Naslund, Steve Sent: Tuesday, December 18, 2018 3:37 PM To: nanog at nanog.org Subject: RE: Stupid Question maybe? It is a matter of machine readability vs human readability. Remember the IP was around when routers did not have a lot of horsepower. The dotted decimal notation was a compromise between pure binary (which the equipment used) and human readability. VLSM seems obvious now but in the beginning organizing various length routes into very expensive memory and low horsepower processors meant that it was much easier to break routes down along byte boundaries. This meant you only had four different lengths of route to deal with. It was intended to eliminate multiple passes sorting the tables. I am not quite sure what you mean about interspersing zeros, that would be meaningless. Remember that it is a mask. The address bits which are masked as 1s are significant to routing. The bits that are masked with 0s are the host portion and don't matter to the network routing table. Steven Naslund Chicago IL >/24 is certainly cleaner than 255.255.255.0. > >I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd >by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519. > - Brian -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo= =RimM -----END PGP SIGNATURE----- From lists.nanog at monmotha.net Tue Dec 18 22:43:43 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 18 Dec 2018 17:43:43 -0500 Subject: Stupid Question maybe? In-Reply-To: <20181218115806.BD3247FD@m0117568.ppops.net> References: <20181218115806.BD3247FD@m0117568.ppops.net> Message-ID: On 12/18/18 2:58 PM, Scott Weeks wrote: > You can safely say that 72.234.7.0/24 is a > Class C/sized/ network. > -------------------------------------- > > But most don't say that. They just say it's > a Class C, which it most assuredly is not. > I heckle them until they can give the correct > answer: leading bits are 110 or it's not a > Class C subnet. > > scott This is a favorite interview type question of mine, but I won't disqualify a candidate if they can't come up with the reason. It's more of a probe for historical domain knowledge (one of many I'll slip in). -- Brandon Martin From james.cutler at consultant.com Tue Dec 18 22:52:09 2018 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 18 Dec 2018 17:52:09 -0500 Subject: Stupid Question maybe? In-Reply-To: References: <20181218115806.BD3247FD@m0117568.ppops.net> Message-ID: <0B5FF633-46F5-47F4-8B98-4B3183CE2F84@consultant.com> > On Dec 18, 2018, at 5:43 PM, Brandon Martin wrote: > > On 12/18/18 2:58 PM, Scott Weeks wrote: >> You can safely say that 72.234.7.0/24 is a >> Class C/sized/ network. >> -------------------------------------- >> But most don't say that. They just say it's >> a Class C, which it most assuredly is not. >> I heckle them until they can give the correct >> answer: leading bits are 110 or it's not a >> Class C subnet. >> scott > I am certain that I read the RFC years ago, but I can’t remember it. Which RFC? > This is a favorite interview type question of mine, but I won't disqualify a candidate if they can't come up with the reason. It's more of a probe for historical domain knowledge (one of many I'll slip in). > -- > Brandon Martin From lists.nanog at monmotha.net Tue Dec 18 23:12:13 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 18 Dec 2018 18:12:13 -0500 Subject: Stupid Question maybe? In-Reply-To: <0B5FF633-46F5-47F4-8B98-4B3183CE2F84@consultant.com> References: <20181218115806.BD3247FD@m0117568.ppops.net> <0B5FF633-46F5-47F4-8B98-4B3183CE2F84@consultant.com> Message-ID: On 12/18/18 5:52 PM, James R Cutler wrote: > I am certain that I read the RFC years ago, but I can’t remember it. Which RFC? RFC796 defines the address formats for classes A, B, and C. A starts with a 0 bit, B starts with 10, and C starts with 110 according to said RFC. -- Brandon Martin From gtaylor at tnetconsulting.net Tue Dec 18 23:26:59 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 18 Dec 2018 16:26:59 -0700 Subject: Stupid Question maybe? In-Reply-To: <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On 12/18/2018 03:12 PM, David Edelman wrote: > I seem to remember that before the advent of VLSM and CIDR there was > no requirement for the 1 bits in the netmask to be contiguous with no > intervening 0 bits and there was always someone who tested it out on a > production network just to prove a point (usually only once) I would love to hear some confirmation of this, or even first hand experience. /Mainly/ for historical / trivial purposes. (Don't ask, don't tell.) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From Philip.Loenneker at tasmanet.com.au Wed Dec 19 00:51:54 2018 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Wed, 19 Dec 2018 00:51:54 +0000 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: I had a heck of a time a few years back trying to troubleshoot an issue where an upstream provider had an ACL with an incorrect mask along the lines of 255.252.255.0. That was really interesting to talk about once we discovered it, though it caused some loss of hair beforehand... -----Original Message----- From: NANOG On Behalf Of Grant Taylor via NANOG Sent: Wednesday, 19 December 2018 10:27 AM To: nanog at nanog.org Subject: Re: Stupid Question maybe? On 12/18/2018 03:12 PM, David Edelman wrote: > I seem to remember that before the advent of VLSM and CIDR there was > no requirement for the 1 bits in the netmask to be contiguous with no > intervening 0 bits and there was always someone who tested it out on a > production network just to prove a point (usually only once) I would love to hear some confirmation of this, or even first hand experience. /Mainly/ for historical / trivial purposes. (Don't ask, don't tell.) -- Grant. . . . unix || die From fredbaker.ietf at gmail.com Wed Dec 19 01:38:14 2018 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Wed, 19 Dec 2018 09:38:14 +0800 Subject: Stupid Question maybe? In-Reply-To: <20181218195007.GB52359@meow.BKantor.net> References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: On Dec 19, 2018, at 3:50 AM, Brian Kantor wrote: > /24 is certainly cleaner than 255.255.255.0. > > I seem to remember it was Phil Karn who in the early 80's suggested > that expressing subnet masks as the number of bits from the top end > of the address word was efficient, since subnet masks were always > a series of ones followd by zeros with no interspersing, which > was incorporated (or independently invented) about a decade later > as CIDR a.b.c.d/n notation in RFC1519. > - Brian Actually, not really. In the time frame, there was quite a bit of discussion about "discontiguous" subnet masks, which were masks that had at least one zero somewhere within the field of ones. There were some who thought they were pretty important. I don't recall whether it was Phil that suggested what we now call "prefixes" with a "prefix length", but it was not fait accompli. Going with prefixes as we now describe them certainly simplified a lot of things. Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for a history discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From stillwaxin at gmail.com Wed Dec 19 05:29:52 2018 From: stillwaxin at gmail.com (Michael Still) Date: Wed, 19 Dec 2018 00:29:52 -0500 Subject: rfd In-Reply-To: <20181218215419.GL1566@hanna.meerval.net> References: <9578293AE169674F9A048B2BC9A081B40318ECD21A@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ECD294@WAUPRDMBXP1.medline.com> <20181218215419.GL1566@hanna.meerval.net> Message-ID: In general I agree with the idea here but I would also be interested in the possibility of running the local route policy engine against routes that are locally detected to meet a damping condition (user configureable of course). This would potentially yield the ability to change local_pref as well as other attributes that may be useful such as MED/metric (which can be transitive) and/or communities. On Tue, Dec 18, 2018 at 4:55 PM Job Snijders wrote: > Dear Steve, > > No worries, I have not forgotten the transitive properties of the > LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF > modifications (and the attribute itself), are local to the Autonomous > System in which they were set, but the effects of such settings can > percolate further into the routing system. > > A great example is the "BGP Graceful Shutdown" mechanism (science > partially documented in https://tools.ietf.org/html/rfc6198, actual > specification here https://tools.ietf.org/html/rfc8326). What is > interesting is that by considering a path (any path, could be flapping) > my network will propagate alternative paths to my neighboring networks, > or possibly even *withdraw* my announcement in favor of alternative > (stable?) paths via competitors. > > By attaching a lower LOCAL_PREF value to a given path for a period of > time as a 'penalty' for flapping, I suspect the visiblity of that > flapping will be greatly reduced. This of course doesn't hold true when > the only origin of the path is flapping, but in many flapping cases I > triaged it was clear that only one out of many links was the root of the > flapping. > > I'm not sure I share your concerns about scale, it appears that so far > we seem to be doing just fine without "route flap dampening, penalty > type: suppress". No customers ask for it, in fact many are relieved we > don't use it. None of our peering partners ask for it either. When we > see oscillating paths we reach out to the offending party and ask them > to fix it, or take unilateral action within a specific time frame. > > Kind regards, > > Job > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Dec 19 07:32:29 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 19 Dec 2018 09:32:29 +0200 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On Wed, 19 Dec 2018 at 02:55, Philip Loenneker wrote: > I had a heck of a time a few years back trying to troubleshoot an issue where an upstream provider had an ACL with an incorrect mask along the lines of 255.252.255.0. That was really interesting to talk about once we discovered it, though it caused some loss of hair beforehand... Juniper originally didn't support them even in ACL use-case but were forced to add later due to customer demand, so people do have use-cases for them. If we'd still support them in forwarding, I'm sure someone would come up with solution which depends on it. I am not advocating we should, I'll rather take my extra PPS out of the HW. However there is one quite interesting use-case for discontinuous mask in ACL. If you have, like you should have, specific block for customer linknetworks, you can in iACL drop all packets to your side of the links while still allowing packets to customer side of the links, making attack surface against your network minimal. -- ++ytti From alessandro.improta at iit.cnr.it Wed Dec 19 09:20:39 2018 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Wed, 19 Dec 2018 10:20:39 +0100 Subject: historical Bogon lists In-Reply-To: <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> Message-ID: <139112a3b9b587bf888bcac636fe1316@iit.cnr.it> Hello Rob, IMHO another option is to set up a local BGP daemon (e.g. Quagga, ICE) peering with your bogon route server project and dump bogon information regularly in MRT like route collectors are doing. So folks can select the RIB snapshot they prefer in time and (in case) study the evolution of bogons via update collections in MRT files. The result is something like this http://data.ris.ripe.net/rrc00/ but containing only bogon information. We did it for our studies last months, so I'd be more than happy to help if you decide to follow this path! Alessandro Improta IIT-CNR, Isolario project Il 2018-12-18 18:00 Rabbi Rob Thomas ha scritto: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear Tom, > >> I wonder if there's value in having the lists that Team Cymru >> generates auto pushed to a public Git repo. Covers historical >> changes for folks who want that, and also provides a more modern >> ingestion method for automation around that info. (Not that I'm >> hating on wget / curl ... :) ) > > We'd be happy to make that happen, if folks are keen. We're fine with > Git, as we use it regularly. > > Be well! > Rob. > - -- > Rabbi Rob Thomas Team Cymru > "It is easy to believe in freedom of speech for those with whom we > agree." - Leo McKern > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF > 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS > AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 > XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k > wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm > 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ > k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI > ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 > h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 > Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 > Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp > M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= > =i27M > -----END PGP SIGNATURE----- From jwbensley at gmail.com Wed Dec 19 09:46:15 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 Dec 2018 09:46:15 +0000 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: Hi Mehmet, This has been discussed on the Juniper-NSP list several times, here's a couple of examples: https://puck.nether.net/pipermail/juniper-nsp/2018-November/036673.html https://puck.nether.net/pipermail/juniper-nsp/2018-April/035397.html https://puck.nether.net/pipermail/juniper-nsp/2016-June/032964.html Cheers, James. From tim at pelican.org Wed Dec 19 09:54:02 2018 From: tim at pelican.org (tim at pelican.org) Date: Wed, 19 Dec 2018 09:54:02 -0000 (GMT) Subject: =?utf-8?Q?Re=3A_Stupid_Question_maybe=3F?= In-Reply-To: References: <20181218115806.BD3247FD@m0117568.ppops.net> Message-ID: <1545213242.522913622@apps.rackspace.com> On Tuesday, 18 December, 2018 22:43, "Brandon Martin" said: > This is a favorite interview type question of mine, but I won't > disqualify a candidate if they can't come up with the reason. It's more > of a probe for historical domain knowledge (one of many I'll slip in). It's an interesting flag at interview for me, if it comes up, but I wouldn't normally talk about it unless the candidate does first. -If they don't know or mention classful networking at all, they're new (relatively, I'm old), and that's fine. -If they can get it right, they're either a long-timer or have done some network history. -If they try to use it, and get it wrong, or can't properly explain it, there's a warning that they've been cramming network skills from some old and/or low-quality sources. I'd start probing for other warning signs like /24s on point-to-point serial links, RIPv1, and the like. Regards, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Dec 19 14:12:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 19 Dec 2018 08:12:53 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> Message-ID: <1147228700.1064.1545228772769.JavaMail.mhammett@ThunderFuck> If people start spot-checking this stuff more regularly, perhaps the companies being verified will take delivering the correct product the first time more seriously. Some of it boils down to a lack of data quality about what they actually have. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "James Breeden" Cc: nanog at nanog.org Sent: Tuesday, December 18, 2018 12:17:42 PM Subject: Re: How to choose a transport(terrestrial/subsea) That's a great example. Thank you James for sharing. I have done so many "GROUND TRUTH" visits where randomly selected certain physical points to validate physical diversity. Have seen several places where dual risers in the building were present or multiple building entries were available but not used. Ground truth events are certainly important and can be eye opening. It does not necessarily scale as you can't really walk all the fiber A-Z everywhere.. i know. On Tue, Dec 18, 2018 at 6:49 AM James Breeden < James at arenalgroup.co > wrote: I can't stress enough the importance of controlling your own route and even cable diversity. Require KMZs of the routes for any services you take (especially single path Wave type services). Put them in the contracts if you can. I've had at least 1 situation where we had vendor diversity and what was supposed to be route diversity- 3 separate waves coming south and southeast out of a datacenter to 3 separate cities. Imagine my surprise when we took a outage one day that severed all 3 circuits. Yes all 3 circuits, going to 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to show up in the same sheath of cable at one location that happened to experience backhoe fade. Was not a good day.... James W. Breeden Managing Partner logo_transparent_background Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From: NANOG < nanog-bounces at nanog.org > on behalf of Brandon Martin < lists.nanog at monmotha.net > Sent: Monday, December 17, 2018 4:59:44 PM To: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > One question, how much people care about vendor diversity? I do and did > care. I don’t want to put all my eggs in one basket. Do you care? Thank you There are advantages and disadvantages to vendor diversity. As advantages, you won't be subject to complete loss of connection because of a single dispute or provisioning/control plane issue with that one vendor. You can also more easily pit vendors against each other for pricing if you are already vendor-diverse. As a disadvantage, not only does vendor diversity obviously not imply route diversity, but it will completely put the onus on you to ensure route diversity if you want it. With a single vendor, you can demand that your circuits have route diversity and, assuming you trust them, they have all the information they need to make that happen for you. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From izaac at setec.org Wed Dec 19 14:41:32 2018 From: izaac at setec.org (Izaac) Date: Wed, 19 Dec 2018 09:41:32 -0500 Subject: Salesmen: ARIN Records are NOT Leads Message-ID: <20181219T144040Z@localhost> Just a reminder. Grrr. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From SNaslund at medline.com Wed Dec 19 14:54:34 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 19 Dec 2018 14:54:34 +0000 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> I am wondering how a netmask could be not contiguous when the network portion of the address must be contiguous. I suppose a bit mask could certainly be anything you want but a netmask specifically identifies the network portion of an address. Steve > I seem to remember that before the advent of VLSM and CIDR there was > no requirement for the 1 bits in the netmask to be contiguous with no > intervening 0 bits and there was always someone who tested it out on a > production network just to prove a point (usually only once) From jcurran at arin.net Wed Dec 19 14:57:42 2018 From: jcurran at arin.net (John Curran) Date: Wed, 19 Dec 2018 14:57:42 +0000 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: <20181219T144040Z@localhost> References: <20181219T144040Z@localhost> Message-ID: <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> On 19 Dec 2018, at 10:41 AM, Izaac wrote: > > Just a reminder. Izaac - Feel free to note that companies involved and forward the message to me… ARIN does pursue misuse of Whois information for marketing purposes. Thanks! /John John Curran President and CEO American Registry for Internet Numbers From alberto at caida.org Wed Dec 19 15:07:28 2018 From: alberto at caida.org (Alberto Dainotti) Date: Wed, 19 Dec 2018 07:07:28 -0800 Subject: historical Bogon lists In-Reply-To: <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> Message-ID: <4B051F1C-C8CD-41DE-88D1-6D3E762C97EA@caida.org> Hi all, CAIDA has been collecting Team Cymru’s bogon list from 2013-09-18 to 2018-03-23. Unfortunately we just noticed the script hasn’t been working since then but we just fixed it and restarted it. We’re happy to share the data as long as Team Cymru’s is ok with it. Cheers, Alberto PS I think Rabbi+Randy also helped us in the past by recovering diffs for 2010-2013 data. Looking for the files. Stay tuned. > On Dec 18, 2018, at 9:00 AM, Rabbi Rob Thomas wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear Tom, > >> I wonder if there's value in having the lists that Team Cymru >> generates auto pushed to a public Git repo. Covers historical >> changes for folks who want that, and also provides a more modern >> ingestion method for automation around that info. (Not that I'm >> hating on wget / curl ... :) ) > > We'd be happy to make that happen, if folks are keen. We're fine with > Git, as we use it regularly. > > Be well! > Rob. > - -- > Rabbi Rob Thomas Team Cymru > "It is easy to believe in freedom of speech for those with whom we > agree." - Leo McKern > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF > 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS > AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 > XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k > wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm > 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ > k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI > ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 > h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 > Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 > Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp > M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= > =i27M > -----END PGP SIGNATURE----- > From william.allen.simpson at gmail.com Wed Dec 19 15:19:28 2018 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 19 Dec 2018 10:19:28 -0500 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: On 12/18/18 8:38 PM, Fred Baker wrote: > On Dec 19, 2018, at 3:50 AM, Brian Kantor wrote: >> /24 is certainly cleaner than 255.255.255.0. >> >> I seem to remember it was Phil Karn who in the early 80's suggested >> that expressing subnet masks as the number of bits from the top end >> of the address word was efficient, since subnet masks were always >> a series of ones followd by zeros with no interspersing, which >> was incorporated (or independently invented) about a decade later >> as CIDR a.b.c.d/n notation in RFC1519. >> - Brian > > Actually, not really. In the time frame, there was quite a bit of discussion about "discontiguous" subnet masks, which were masks that had at least one zero somewhere within the field of ones. There were some who thought they were pretty important. I don't recall whether it was Phil that suggested what we now call "prefixes" with a "prefix length", but it was not fait accompli. > Actually, Brian is correct. Phil was w-a-y ahead of the times. But I don't remember him talking about it until the late '80s. Brian probably knew him longer. Anyway, Fred is also correct. It took many years, and a lot of argument, before prefixes were common. Partly that was me, in PIPE/SIP/SIPP and CIDRD. Required longest prefix match in early Neighbor Discovery drafts. However, I was more of an advocate for suffixes, also known as host mask, wanting them to be common between IPv4 and IPv6. I still think it would have simplified setup for operators. Most don't care how long the network part, they know how many nodes are needed on the LAN. Cisco had adopted /n for network prefixes, so I'd proposed //h for host suffixes. Anyway, /n made it into RFCs. > Going with prefixes as we now describe them certainly simplified a lot of things. > > Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for a history discussion. > Didn't see anything ancient. Circa 2010 arguments.... Apparently, CIDRD archives aren't up anymore. From daknob.mac at gmail.com Wed Dec 19 15:21:00 2018 From: daknob.mac at gmail.com (Antonios Chariton) Date: Wed, 19 Dec 2018 17:21:00 +0200 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> Message-ID: There’s certainly a Tier-1 doing it for RIPE, every time a new AS is registered for example.. I imagine it’s the same in ARIN too.. > On 19 Dec 2018, at 16:57, John Curran wrote: > > On 19 Dec 2018, at 10:41 AM, Izaac wrote: >> >> Just a reminder. > > Izaac - > > Feel free to note that companies involved and forward the message to me… > > ARIN does pursue misuse of Whois information for marketing purposes. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > From davidbass570 at gmail.com Wed Dec 19 15:21:22 2018 From: davidbass570 at gmail.com (David Bass) Date: Wed, 19 Dec 2018 10:21:22 -0500 Subject: historical Bogon lists In-Reply-To: <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> Message-ID: I think Git would be the perfect solution...would definitely appreciate it. On Tue, Dec 18, 2018 at 12:01 PM Rabbi Rob Thomas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear Tom, > > > I wonder if there's value in having the lists that Team Cymru > > generates auto pushed to a public Git repo. Covers historical > > changes for folks who want that, and also provides a more modern > > ingestion method for automation around that info. (Not that I'm > > hating on wget / curl ... :) ) > > We'd be happy to make that happen, if folks are keen. We're fine with > Git, as we use it regularly. > > Be well! > Rob. > - -- > Rabbi Rob Thomas Team Cymru > "It is easy to believe in freedom of speech for those with whom we > agree." - Leo McKern > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF > 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS > AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 > XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k > wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm > 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ > k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI > ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 > h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 > Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 > Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp > M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= > =i27M > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at chronos.com.tr Wed Dec 19 15:35:10 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Wed, 19 Dec 2018 18:35:10 +0300 Subject: historical Bogon lists In-Reply-To: <4B051F1C-C8CD-41DE-88D1-6D3E762C97EA@caida.org> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> <4B051F1C-C8CD-41DE-88D1-6D3E762C97EA@caida.org> Message-ID: <1c3a87a473bbfaf0cab46dfcfe6afd3c@chronos.com.tr> I think Alessandro Isolario Project may be of help completing the missing data where you fell short. M. --- On 2018-12-19 18:07, Alberto Dainotti wrote: > Hi all, > > CAIDA has been collecting Team Cymru’s bogon list from 2013-09-18 to > 2018-03-23. Unfortunately we just noticed the script hasn’t been > working since then but we just fixed it and restarted it. > We’re happy to share the data as long as Team Cymru’s is ok with it. > > Cheers, > Alberto > > PS > I think Rabbi+Randy also helped us in the past by recovering diffs for > 2010-2013 data. Looking for the files. Stay tuned. > >> On Dec 18, 2018, at 9:00 AM, Rabbi Rob Thomas wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Dear Tom, >> >>> I wonder if there's value in having the lists that Team Cymru >>> generates auto pushed to a public Git repo. Covers historical >>> changes for folks who want that, and also provides a more modern >>> ingestion method for automation around that info. (Not that I'm >>> hating on wget / curl ... :) ) >> >> We'd be happy to make that happen, if folks are keen. We're fine with >> Git, as we use it regularly. >> >> Be well! >> Rob. >> - -- >> Rabbi Rob Thomas Team Cymru >> "It is easy to believe in freedom of speech for those with whom we >> agree." - Leo McKern >> -----BEGIN PGP SIGNATURE----- >> >> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF >> 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS >> AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 >> XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k >> wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm >> 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ >> k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI >> ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 >> h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 >> Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 >> Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp >> M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= >> =i27M >> -----END PGP SIGNATURE----- >> From kushal.r at h4g.co Wed Dec 19 15:53:26 2018 From: kushal.r at h4g.co (Kushal) Date: Wed, 19 Dec 2018 21:23:26 +0530 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> Message-ID: There are many Tier 1s doing it and they have moved to LinkedIn these days instead of emails. -- Kushal R Chief Executive | Host4Geeks site: host4geeks.com email: kushal.r at h4g.co skype: kush.raha On 19 December 2018 at 8:55:31 PM, Antonios Chariton (daknob.mac at gmail.com) wrote: There’s certainly a Tier-1 doing it for RIPE, every time a new AS is registered for example.. I imagine it’s the same in ARIN too.. > On 19 Dec 2018, at 16:57, John Curran wrote: > > On 19 Dec 2018, at 10:41 AM, Izaac wrote: >> >> Just a reminder. > > Izaac - > > Feel free to note that companies involved and forward the message to me… > > ARIN does pursue misuse of Whois information for marketing purposes. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.improta at iit.cnr.it Wed Dec 19 15:59:17 2018 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Wed, 19 Dec 2018 16:59:17 +0100 Subject: historical Bogon lists In-Reply-To: <1c3a87a473bbfaf0cab46dfcfe6afd3c@chronos.com.tr> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> <4B051F1C-C8CD-41DE-88D1-6D3E762C97EA@caida.org> <1c3a87a473bbfaf0cab46dfcfe6afd3c@chronos.com.tr> Message-ID: Yes, we got data from Jan 1st, 2018 to Oct 10th, 2018. Happy to share as long as Team Cymru’s is ok with it too! Ale Il 2018-12-19 16:35 M. Omer GOLGELI ha scritto: > I think Alessandro Isolario Project may be of help completing the > missing data where you fell short. > > > M. > --- > > > On 2018-12-19 18:07, Alberto Dainotti wrote: >> Hi all, >> >> CAIDA has been collecting Team Cymru’s bogon list from 2013-09-18 to >> 2018-03-23. Unfortunately we just noticed the script hasn’t been >> working since then but we just fixed it and restarted it. >> We’re happy to share the data as long as Team Cymru’s is ok with it. >> >> Cheers, >> Alberto >> >> PS >> I think Rabbi+Randy also helped us in the past by recovering diffs for >> 2010-2013 data. Looking for the files. Stay tuned. >> >>> On Dec 18, 2018, at 9:00 AM, Rabbi Rob Thomas wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Dear Tom, >>> >>>> I wonder if there's value in having the lists that Team Cymru >>>> generates auto pushed to a public Git repo. Covers historical >>>> changes for folks who want that, and also provides a more modern >>>> ingestion method for automation around that info. (Not that I'm >>>> hating on wget / curl ... :) ) >>> >>> We'd be happy to make that happen, if folks are keen. We're fine >>> with >>> Git, as we use it regularly. >>> >>> Be well! >>> Rob. >>> - -- >>> Rabbi Rob Thomas Team Cymru >>> "It is easy to believe in freedom of speech for those with whom we >>> agree." - Leo McKern >>> -----BEGIN PGP SIGNATURE----- >>> >>> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwZJ5wACgkQQ+hhYvqF >>> 8o2ULQ/+N++KAtZkfuYvzjnAwFQZGWvfTmFcmEwQKtbS+O53ymn2tGfMf/NjZKrS >>> AyJdiNby1PFjDd4X/4bKsm1k4pOcqIvWHrNuQfSCMnsAAVlWWZr1SWjkV+rD2o80 >>> XSrpz1nXYFH/Et3TMedc6fKLt6UgKlfua1t7xm4pBypjSHTBari601cvGMqa++4k >>> wqAB5KUoIC1Ni5GVff1i+NCQ+6kfuVvXvnTHBjq6q6O+rLC5KpQwI/9pY3J5LODm >>> 3nfqPYEo/otNRn/vX4lENMI/3lrMIXC4NO8fjYDgStVZ/1CZVWzxNFc4MgplpwKJ >>> k/VLYnkuai7o4yT5Ao4xhKIctGOO79v8Gmgv9NJUXkfcqrL+EVI6FGQoWB8PiHxI >>> ZWppA3kdiB7csG+zHG/+hliB5xI3SzlvNH/ywPzym06FLK5/1yKSI788qjyXBgZ4 >>> h/Vs14DSrtqw/VlgBAV0f25PPJllmZeJwrtgqGzgwakLKqrk9ByCHBA77Xhk3XN8 >>> Y5klq2uE8n2tYq5RHlUg1/+jdj6kQo2APHN7Q3H7FWv0CrW8JluHQdb7dLCnqFR8 >>> Obo4H/G1DtjR60ECXvnS7X/6Fzs0KZFhd0E+jAbb2ErKQ2ZL+6+XuzaCXkDJ3oEp >>> M+RftjLnwywE1MNf7q3Hmrpt3ku7HKjDQjvLZv2h8/f92rwy/1M= >>> =i27M >>> -----END PGP SIGNATURE----- >>> From patrick at ianai.net Wed Dec 19 16:10:29 2018 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 19 Dec 2018 11:10:29 -0500 Subject: Stupid Question maybe? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> Message-ID: <34545A5C-6F18-4011-B938-57BAEA2064DC@ianai.net> Why do you think the network portion needs to be contiguous? Well, it does now. But that was not always the case. https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid -- TTFN, patrick > On Dec 19, 2018, at 09:54, Naslund, Steve wrote: > > I am wondering how a netmask could be not contiguous when the network portion of the address must be contiguous. I suppose a bit mask could certainly be anything you want but a netmask specifically identifies the network portion of an address. > > Steve > >> I seem to remember that before the advent of VLSM and CIDR there was >> no requirement for the 1 bits in the netmask to be contiguous with no >> intervening 0 bits and there was always someone who tested it out on a >> production network just to prove a point (usually only once) -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Dec 19 16:24:33 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 19 Dec 2018 16:24:33 +0000 Subject: Stupid Question maybe? In-Reply-To: <34545A5C-6F18-4011-B938-57BAEA2064DC@ianai.net> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> <34545A5C-6F18-4011-B938-57BAEA2064DC@ianai.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ECDB28@WAUPRDMBXP1.medline.com> >Why do you think the network portion needs to be contiguous? Just because some equipment at one time let you configure a non-contiguous mask does not make it correct configuration. Please come up with any valid use case for a non-contiguous network (note NETWORK, not any other purpose) mask. >Well, it does now. But that was not always the case. It has ALWAYS been the only correct way to configure equipment and is a requirement under CIDR. Here were your commonly used netmasks before CIDR/VLSM : 255.0.0.0 255.255.0.0 255.255.255.0 Which one is not contiguous? >https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore In this example, the writer used it as a parlor trick to actually break a network. That's why you don't do it and it was never a good configuration. It just exploited a UI that did not validate the netmask. >https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid In the second cited link, they are talking about using a non-contiguous mask in an access control function. That is perfectly valid to do, it just is not a NETmask anymore. By definition a netmask identifies the network portion of an address. In the cited example they are defining a group of subnets to an ACL. Steven Naslund Chicago IL > >-- >TTFN, >patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed Dec 19 16:49:29 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 19 Dec 2018 09:49:29 -0700 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> Message-ID: <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> On 12/19/2018 8:53 AM, Kushal wrote: > There are many Tier 1s doing it and they have moved to LinkedIn these > days instead of emails. Can confirm that one. I've stopped being nice in my responses. Every time I post to NANOG, I get multiple LinkedIn link requests or e-mails about selling my excess gear. It's getting old real quick. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rsk at gsp.org Wed Dec 19 16:58:27 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 19 Dec 2018 11:58:27 -0500 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> Message-ID: <20181219165827.GA16686@gsp.org> On Wed, Dec 19, 2018 at 09:49:29AM -0700, Brielle Bruns wrote: > Every time I post to NANOG, I get multiple LinkedIn link requests or e-mails > about selling my excess gear. It's getting old real quick. I recommend: Connect:linkedin.com ERROR:5.7.1:"550 Mail refused" From:linkedin.com ERROR:5.7.1:"550 Mail refused" Salt to taste for your environment/MTA, but since the spammers running LinkedIn seem very unlikely to stop, this appears to be the optimal way to conserve bandwidth and time. ---rsk From rod.beck at unitedcablecompany.com Wed Dec 19 17:28:20 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 19 Dec 2018 17:28:20 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> , Message-ID: The Trans-Atlantic cables, particularly on the UK side, probably lack physical diversity. The landings at Bude probably share back haul. The cost of each cable digging its own trench was quite high. - R. ________________________________ From: NANOG on behalf of Mehmet Akcin Sent: Tuesday, December 18, 2018 7:17 PM To: James Breeden Cc: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) That's a great example. Thank you James for sharing. I have done so many "GROUND TRUTH" visits where randomly selected certain physical points to validate physical diversity. Have seen several places where dual risers in the building were present or multiple building entries were available but not used. Ground truth events are certainly important and can be eye opening. It does not necessarily scale as you can't really walk all the fiber A-Z everywhere.. i know. On Tue, Dec 18, 2018 at 6:49 AM James Breeden > wrote: I can't stress enough the importance of controlling your own route and even cable diversity. Require KMZs of the routes for any services you take (especially single path Wave type services). Put them in the contracts if you can. I've had at least 1 situation where we had vendor diversity and what was supposed to be route diversity- 3 separate waves coming south and southeast out of a datacenter to 3 separate cities. Imagine my surprise when we took a outage one day that severed all 3 circuits. Yes all 3 circuits, going to 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to show up in the same sheath of cable at one location that happened to experience backhoe fade. Was not a good day.... James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG > on behalf of Brandon Martin > Sent: Monday, December 17, 2018 4:59:44 PM To: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > One question, how much people care about vendor diversity? I do and did > care. I don’t want to put all my eggs in one basket. Do you care? Thank you There are advantages and disadvantages to vendor diversity. As advantages, you won't be subject to complete loss of connection because of a single dispute or provisioning/control plane issue with that one vendor. You can also more easily pit vendors against each other for pricing if you are already vendor-diverse. As a disadvantage, not only does vendor diversity obviously not imply route diversity, but it will completely put the onus on you to ensure route diversity if you want it. With a single vendor, you can demand that your circuits have route diversity and, assuming you trust them, they have all the information they need to make that happen for you. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rod.beck at unitedcablecompany.com Wed Dec 19 17:41:32 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 19 Dec 2018 17:41:32 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <1147228700.1064.1545228772769.JavaMail.mhammett@ThunderFuck> References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> , <1147228700.1064.1545228772769.JavaMail.mhammett@ThunderFuck> Message-ID: Some of it is due to lazy buyers purchasing two IP ports from distinct companies without considring that two ports both located at the site are vulnerable to shared risers or entrance facilities. - R. ________________________________ From: NANOG on behalf of Mike Hammett Sent: Wednesday, December 19, 2018 3:12 PM To: Mehmet Akcin Cc: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) If people start spot-checking this stuff more regularly, perhaps the companies being verified will take delivering the correct product the first time more seriously. Some of it boils down to a lack of data quality about what they actually have. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Mehmet Akcin" To: "James Breeden" Cc: nanog at nanog.org Sent: Tuesday, December 18, 2018 12:17:42 PM Subject: Re: How to choose a transport(terrestrial/subsea) That's a great example. Thank you James for sharing. I have done so many "GROUND TRUTH" visits where randomly selected certain physical points to validate physical diversity. Have seen several places where dual risers in the building were present or multiple building entries were available but not used. Ground truth events are certainly important and can be eye opening. It does not necessarily scale as you can't really walk all the fiber A-Z everywhere.. i know. On Tue, Dec 18, 2018 at 6:49 AM James Breeden > wrote: I can't stress enough the importance of controlling your own route and even cable diversity. Require KMZs of the routes for any services you take (especially single path Wave type services). Put them in the contracts if you can. I've had at least 1 situation where we had vendor diversity and what was supposed to be route diversity- 3 separate waves coming south and southeast out of a datacenter to 3 separate cities. Imagine my surprise when we took a outage one day that severed all 3 circuits. Yes all 3 circuits, going to 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to show up in the same sheath of cable at one location that happened to experience backhoe fade. Was not a good day.... James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG > on behalf of Brandon Martin > Sent: Monday, December 17, 2018 4:59:44 PM To: nanog at nanog.org Subject: Re: How to choose a transport(terrestrial/subsea) On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > One question, how much people care about vendor diversity? I do and did > care. I don’t want to put all my eggs in one basket. Do you care? Thank you There are advantages and disadvantages to vendor diversity. As advantages, you won't be subject to complete loss of connection because of a single dispute or provisioning/control plane issue with that one vendor. You can also more easily pit vendors against each other for pricing if you are already vendor-diverse. As a disadvantage, not only does vendor diversity obviously not imply route diversity, but it will completely put the onus on you to ensure route diversity if you want it. With a single vendor, you can demand that your circuits have route diversity and, assuming you trust them, they have all the information they need to make that happen for you. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Wed Dec 19 17:44:18 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 19 Dec 2018 09:44:18 -0800 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <222d2399-81d4-252a-258e-3fe706c7a3cb@monmotha.net> <1147228700.1064.1545228772769.JavaMail.mhammett@ThunderFuck> Message-ID: More likely everyone bought IRUs out of the same ILEC’s single cable. Or they just all go through the same single raceway to enter the building, etc. -Ben. - Ben Cannon, AS15206 > On Dec 19, 2018, at 9:41 AM, Rod Beck wrote: > > Some of it is due to lazy buyers purchasing two IP ports from distinct companies without considring that two ports both located at the site are vulnerable to shared risers or entrance facilities. > > - R. > > > From: NANOG > on behalf of Mike Hammett > > Sent: Wednesday, December 19, 2018 3:12 PM > To: Mehmet Akcin > Cc: nanog at nanog.org > Subject: Re: How to choose a transport(terrestrial/subsea) > > If people start spot-checking this stuff more regularly, perhaps the companies being verified will take delivering the correct product the first time more seriously. > > Some of it boils down to a lack of data quality about what they actually have. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Mehmet Akcin" > > To: "James Breeden" > > Cc: nanog at nanog.org > Sent: Tuesday, December 18, 2018 12:17:42 PM > Subject: Re: How to choose a transport(terrestrial/subsea) > > That's a great example. Thank you James for sharing. I have done so many "GROUND TRUTH" visits where randomly selected certain physical points to validate physical diversity. Have seen several places where dual risers in the building were present or multiple building entries were available but not used. Ground truth events are certainly important and can be eye opening. It does not necessarily scale as you can't really walk all the fiber A-Z everywhere.. i know. > > On Tue, Dec 18, 2018 at 6:49 AM James Breeden > wrote: > I can't stress enough the importance of controlling your own route and even cable diversity. Require KMZs of the routes for any services you take (especially single path Wave type services). Put them in the contracts if you can. > > I've had at least 1 situation where we had vendor diversity and what was supposed to be route diversity- 3 separate waves coming south and southeast out of a datacenter to 3 separate cities. Imagine my surprise when we took a outage one day that severed all 3 circuits. Yes all 3 circuits, going to 3 separate cities, on 3 separate carrier/s DWDM platforms, all happened to show up in the same sheath of cable at one location that happened to experience backhoe fade. Was not a good day.... > > > James W. Breeden > Managing Partner > > > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > PO Box 1063 | Smithville, TX 78957 > Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co > From: NANOG > on behalf of Brandon Martin > > Sent: Monday, December 17, 2018 4:59:44 PM > To: nanog at nanog.org > Subject: Re: How to choose a transport(terrestrial/subsea) > > On 12/17/18 3:51 PM, Mehmet Akcin wrote: > > > > One question, how much people care about vendor diversity? I do and did > > care. I don’t want to put all my eggs in one basket. Do you care? Thank you > > There are advantages and disadvantages to vendor diversity. > > As advantages, you won't be subject to complete loss of connection > because of a single dispute or provisioning/control plane issue with > that one vendor. You can also more easily pit vendors against each > other for pricing if you are already vendor-diverse. > > As a disadvantage, not only does vendor diversity obviously not imply > route diversity, but it will completely put the onus on you to ensure > route diversity if you want it. With a single vendor, you can demand > that your circuits have route diversity and, assuming you trust them, > they have all the information they need to make that happen for you. > -- > Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Wed Dec 19 17:56:03 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 19 Dec 2018 10:56:03 -0700 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: <20181219165827.GA16686@gsp.org> References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> <20181219165827.GA16686@gsp.org> Message-ID: <2572f39f-45b9-9115-5e37-308e687a170b@2mbit.com> On 12/19/2018 9:58 AM, Rich Kulawiec wrote: > On Wed, Dec 19, 2018 at 09:49:29AM -0700, Brielle Bruns wrote: >> Every time I post to NANOG, I get multiple LinkedIn link requests or e-mails >> about selling my excess gear. It's getting old real quick. > > I recommend: > > Connect:linkedin.com ERROR:5.7.1:"550 Mail refused" > From:linkedin.com ERROR:5.7.1:"550 Mail refused" > > Salt to taste for your environment/MTA, but since the spammers running > LinkedIn seem very unlikely to stop, this appears to be the optimal > way to conserve bandwidth and time. > > ---rsk > Except you know, those of us who actually use LinkedIn for professional contacts and all. I don't mind connecting with people as long as I've actually talked with you before on some professional level. It does have some nice features for connecting on a business level, just people are abusing the shit out of it. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mehmet at akcin.net Wed Dec 19 17:56:36 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 19 Dec 2018 09:56:36 -0800 Subject: Network Atlas End of Year 2018 Update In-Reply-To: References: Message-ID: Thank you everyone for following up offlist with their feedback and recommendations. I truly appreciate this. I am creating a FAQ section in www.networkatlas.org now as it seemed like several areas needed to be clarified. What is Network Atlas? it's a very good question and I want to open that little bit more and ask back to community, what should Network Atlas be? Obviously we are not yet another cable map. When I started Network Atlas, I had one goal and that was to visualize operational status to make it easy for non-tech folks to digest information as well as those who do not acquire backbone directly but suffer when there is an outage to have visibility to backbone outages. We've evolved from this point with great recommendations by you guys. One of the most recent recommendation is that we allow people who want to connect to sales people to be able to do that using our tool, but how? let's say you zoomed in a metro where you have an office or planning to get a colo space, you will be able to see who the onnet carriers are and connect sales people directly. I want to ask community's suggestion, is this something Network professionals (engineers mostly, not sales teams) find useful? Would you actually use this function if it was built? This is a very easy function for us to build and we have already included in our demo but the question is if you guys don't find it useful, then there is no point. We are also working on similar things like you select a building/pop address and you can hit click to get quote for space/power, all transit providers, and backbone providers at once. Obviously we need to make sure there is a sustainable way to run network atlas so we are not a bottleneck or single point of failure but definitely we are group of engineers not sales people so we do not really know what the best way to build this up. Our self service portal is working now, what does this mean? Soon, (Q1 2019) you will be able to go to www.networkatlas.org and register a username, upload your own kmzs. we are working on a feature where you can have company.networkatlas.org and custom map (public or private) for your own network where you only see what you care about ;) this was the most requested feature. We will be able to give you so many choices on customization here. It will be possible to build a map which you can embed to your website as well. Just wanted to ask feedback on these two features we are working on and see if you guys would find this useful , please feel free to tell me if not, some of the folks really have given me great feedback and i appreciate these. I know a lot of people prefer to deal with carriers/colo providers directly and with lots of mergers and acquisition it might be useful to have one place where you know globally who to contact for wholesale level pricing. mehmet On Thu, Dec 13, 2018 at 8:30 PM Mehmet Akcin wrote: > Ok, I am just excited to share this so won't wait till January :) Time > Machine is ready! What is time machine? Change the time in future, and see > which cables will be still operational (aka run out of their life times of > approximate 25 years!). > > https://dev.networkatlas.org check it out! by the way we are looking for > people who can volunteer to demo few features like uploading kmzs, and > creating custom fields like latency. If you have free time , please join > our slack here . > https://join.slack.com/t/networkatlas/shared_invite/enQtNDUwOTIzMDEwODM4LWE5NjNmOWRkMmQxYmYzYWU1YmI0ZmEwNWVlODllY2U1MGU5OTVhZDk4YjA1ZmFiN2VhYWI5ZWUyMGQ0YjU0OTc > > > Coming soon, the feature that will make engineers life easy "buy now" :) > watch this space.... :) > > On Sat, Dec 1, 2018 at 11:31 PM Mehmet Akcin wrote: > >> NANOG Friends, >> >> The final month of 2018 is going to be a busy one for Network Atlas, and >> while I still have a few spare hours, I wanted to share some exciting >> updates and address a few questions. >> First, I would like to thank all the people who believe in Network Atlas >> and have helped it get to where it is today. Network Atlas is at its heart >> a community concept, and it is energizing to see so many of you excited >> about its potential and interested in making it better. >> To that end, the Network Atlas team will be spending the next month >> working feverishly to improve the product and get it ready for 2019. I am >> very excited to announce the following list of features that should come >> online early next year: >> >> 1. >> >> Cable system operation status allows users to see which segments are >> up/down/partial and their last outage, along with textual details of >> previous outages with potential for links >> 2. >> >> Cable system information - length, activation date, and estimated >> end-of-life >> 3. >> >> Fast page load time of <5 secs for users within the US >> 4. >> >> 3D data center locations >> 5. >> >> “Buy capacity” - a form that generates an email to a specified cable >> owner >> 6. >> >> Report-an-issue on routes for users to send feedback >> 7. >> >> Ability for users to receive email notifications about cable status >> changes ,Option to show subsea cables only , Option to show active cables >> only, Option to show future cables only >> 8. >> >> A Time Machine function that will show cables that will be active in >> the future >> 9. >> >> Ability to add custom fields in select or all cables to show >> information such as latency3-tiered Network Atlas Cable >> 10. >> >> Management UI: Users can:Add/Delete/Replace >> >> I can’t wait to share this next phase of Network Atlas with you all. Once >> it’s complete, it will truly be “one map to rule them all.” >> >> Next up, let me address the elephant in the room. As many of you know, >> Network Atlas’ Kickstarter for $100K for 2019 funding came up short of >> meeting its goal(we cancelled it before the time because many of you >> reached out wanting to support directly not via Kickstart). However, it was >> an excellent learning experience, as it provided a chance to interact with >> potential donors and hear their questions. One of those questions was if >> Network Atlas could show its 3-year plan for the project. In the interest >> of transparency, I would like to share with you Network Atlas’ proposed >> 3-year operating budget as of today. >> >> You can see this as details in our blog - >> https://www.networkatlas.org/blog/eoy2018 >> >> Month of December, we will freeze adding new fiber routes to Network >> Atlas, this will allow us to focus on working the 10 feature we have >> explained above. If you want to upload fiber routes you own and authorized, >> feel free to go to https://kmzs.networkatlas.org >> and upload them and please include your >> email address in the file name (or create a colder with readme in it) so we >> can reach back with questions. Our self-service portal will solve this >> issue in January :) >> >> Now this is not the end. It is not even the beginning of the end. But it >> is, perhaps, the end of the beginning. >> >> Have a wonderful December, and a happy new year! >> >> Mehmet >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Dec 19 18:08:38 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 19 Dec 2018 13:08:38 -0500 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: <2572f39f-45b9-9115-5e37-308e687a170b@2mbit.com> References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> <20181219165827.GA16686@gsp.org> <2572f39f-45b9-9115-5e37-308e687a170b@2mbit.com> Message-ID: After setting up my ASN, I received unsolicited emails from NTT and calls from Cogent. Fortunately I haven't gotten anything (or at least anything that I noticed) on LinkedIn. On Wed, Dec 19, 2018, 12:58 PM Brielle Bruns On 12/19/2018 9:58 AM, Rich Kulawiec wrote: > > On Wed, Dec 19, 2018 at 09:49:29AM -0700, Brielle Bruns wrote: > >> Every time I post to NANOG, I get multiple LinkedIn link requests or > e-mails > >> about selling my excess gear. It's getting old real quick. > > > > I recommend: > > > > Connect:linkedin.com ERROR:5.7.1:"550 Mail refused" > > From:linkedin.com ERROR:5.7.1:"550 Mail refused" > > > > Salt to taste for your environment/MTA, but since the spammers running > > LinkedIn seem very unlikely to stop, this appears to be the optimal > > way to conserve bandwidth and time. > > > > ---rsk > > > > > Except you know, those of us who actually use LinkedIn for professional > contacts and all. I don't mind connecting with people as long as I've > actually talked with you before on some professional level. > > It does have some nice features for connecting on a business level, just > people are abusing the shit out of it. > -- > 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 omer at chronos.com.tr Wed Dec 19 18:20:17 2018 From: omer at chronos.com.tr (=?UTF-8?B?TS4gw5ZtZXIgR8OWTEdFTMSw?=) Date: Wed, 19 Dec 2018 21:20:17 +0300 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Dec 19 18:21:37 2018 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 19 Dec 2018 13:21:37 -0500 Subject: Salesmen: ARIN Records are NOT Leads In-Reply-To: References: <20181219T144040Z@localhost> <04D6E698-AC4E-4E54-BD62-58A62710A6D5@arin.net> <19afa1b2-00bb-dc6a-b0f5-7dd9a20751c0@2mbit.com> <20181219165827.GA16686@gsp.org> <2572f39f-45b9-9115-5e37-308e687a170b@2mbit.com> Message-ID: I got to a point a few years ago that anyone who finds my contact info anywhere on the internet and wants to sell me something is going to spam me, and there's nothing I can do about it. I just utilize the blocking / ignore functions of $platform and go about my day. At one time I did have a devious hold/transfer loop of doom setup on the company PBX that came in handy for trolling annoying sales calls, but I don't have access the company one now, and setting up my own for the same lulz is way too close to actual work for my tastes. On Wed, Dec 19, 2018 at 1:10 PM Ross Tajvar wrote: > After setting up my ASN, I received unsolicited emails from NTT and calls > from Cogent. Fortunately I haven't gotten anything (or at least anything > that I noticed) on LinkedIn. > > On Wed, Dec 19, 2018, 12:58 PM Brielle Bruns >> On 12/19/2018 9:58 AM, Rich Kulawiec wrote: >> > On Wed, Dec 19, 2018 at 09:49:29AM -0700, Brielle Bruns wrote: >> >> Every time I post to NANOG, I get multiple LinkedIn link requests or >> e-mails >> >> about selling my excess gear. It's getting old real quick. >> > >> > I recommend: >> > >> > Connect:linkedin.com ERROR:5.7.1:"550 Mail refused" >> > From:linkedin.com ERROR:5.7.1:"550 Mail refused" >> > >> > Salt to taste for your environment/MTA, but since the spammers running >> > LinkedIn seem very unlikely to stop, this appears to be the optimal >> > way to conserve bandwidth and time. >> > >> > ---rsk >> > >> >> >> Except you know, those of us who actually use LinkedIn for professional >> contacts and all. I don't mind connecting with people as long as I've >> actually talked with you before on some professional level. >> >> It does have some nice features for connecting on a business level, just >> people are abusing the shit out of it. >> -- >> 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 valdis.kletnieks at vt.edu Wed Dec 19 19:47:53 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 19 Dec 2018 14:47:53 -0500 Subject: Stupid Question maybe? In-Reply-To: <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: <13937.1545248873@turing-police.cc.vt.edu> On Tue, 18 Dec 2018 17:12:45 -0500, "David Edelman" said: > I seem to remember that before the advent of VLSM and CIDR there was no > requirement for the 1 bits in the netmask to be contiguous with no intervening > 0 bits and there was always someone who tested it out on a production network > just to prove a point (usually only once) So at one show, the Interop show network went to a 255.255.252.0 netmask, and of course a lot of vendors had issues and complained. The stock response was "Quit whining, or next show it's going to be 255.255.250.0". There was indeed a fairly long stretch of time (until the CIDR RFC came out and specifically said it wasn't at all canon) where we didn't have an RFC that specifically said that netmask bits had to be contiguous. From bellman at nsc.liu.se Wed Dec 19 20:11:39 2018 From: bellman at nsc.liu.se (Thomas Bellman) Date: Wed, 19 Dec 2018 21:11:39 +0100 Subject: Stupid Question maybe? In-Reply-To: <13937.1545248873@turing-police.cc.vt.edu> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: On 2018-12-19 20:47 MET, valdis.kletnieks at vt.edu wrote: > There was indeed a fairly long stretch of time (until the CIDR RFC came out and > specifically said it wasn't at all canon) where we didn't have an RFC that > specifically said that netmask bits had to be contiguous. How did routers select the best (most specific) route for an address? If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have the same number of matching bits. /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Wed Dec 19 20:28:36 2018 From: bill at herrin.us (William Herrin) Date: Wed, 19 Dec 2018 12:28:36 -0800 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: On Wed, Dec 19, 2018 at 12:12 PM Thomas Bellman wrote: > On 2018-12-19 20:47 MET, valdis.kletnieks at vt.edu wrote: > > There was indeed a fairly long stretch of time (until the CIDR RFC came out and > > specifically said it wasn't at all canon) where we didn't have an RFC that > > specifically said that netmask bits had to be contiguous. > > How did routers select the best (most specific) route for an address? > If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and > 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have > the same number of matching bits. Easy: .97 matches neither one because 64 & 97 !=0 and 32 & 97 != 0. That's a 0 that has to match at the end of the 10.20.30. The problem is 10.20.30.1 matches both, so which one takes precedence? Can't have a most-specific match when two matching routes have the same specificity. I'm guessing the answer was: the routing protocols didn't accept netmasks in the first place and you were a fool to intentionally create overlapping static routes. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bellman at nsc.liu.se Wed Dec 19 20:44:33 2018 From: bellman at nsc.liu.se (Thomas Bellman) Date: Wed, 19 Dec 2018 21:44:33 +0100 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: On 2018-12-19 21:28 MET, William Herrin wrote: > Easy: .97 matches neither one because 64 & 97 !=0 and 32 & 97 != 0. > That's a 0 that has to match at the end of the 10.20.30. D'oh! Sorry, I got that wrong. (Trying to battle 10+% packet loss at home and a just upgraded Thunderbird at the same time is bad for my ability to construct consistent email messages, it seems...) 10.20.30.1 is much better example. > The problem is 10.20.30.1 matches both, so which one takes precedence? > Can't have a most-specific match when two matching routes have the > same specificity. > > I'm guessing the answer was: the routing protocols didn't accept > netmasks in the first place and you were a fool to intentionally > create overlapping static routes. Agree that it would be foolish, but I was curious what implementations did when encountering such a fool. :-) /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Wed Dec 19 20:46:43 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Dec 2018 12:46:43 -0800 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: > On Dec 19, 2018, at 12:11 , Thomas Bellman wrote: > > On 2018-12-19 20:47 MET, valdis.kletnieks at vt.edu wrote: > >> There was indeed a fairly long stretch of time (until the CIDR RFC came out and >> specifically said it wasn't at all canon) where we didn't have an RFC that >> specifically said that netmask bits had to be contiguous. > > How did routers select the best (most specific) route for an address? > If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and > 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have > the same number of matching bits. > > /Bellman > The institution of the longest match rule came with the prohibition (deprecation) of discontiguous net masks. Owen From valdis.kletnieks at vt.edu Wed Dec 19 20:50:35 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 19 Dec 2018 15:50:35 -0500 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: <17028.1545252635@turing-police.cc.vt.edu> On Wed, 19 Dec 2018 21:11:39 +0100, Thomas Bellman said: > On 2018-12-19 20:47 MET, valdis.kletnieks at vt.edu wrote: > > There was indeed a fairly long stretch of time (until the CIDR RFC came out and > > specifically said it wasn't at all canon) where we didn't have an RFC that > > specifically said that netmask bits had to be contiguous. > > How did routers select the best (most specific) route for an address? > If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and > 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have > the same number of matching bits. That didn't stop sites getting creative with it on their internal networks, and I wouldn't be surprised if at least one router (Bay, Proteon, whatever) happened to have an implementation that Just Worked. Remember - there were enough ambiguities and odd implementations that RFC 1122/1123 had to be issued. *Lots* of "How the did that ever work?" back in those days - and often the answer was "By accident". From dedelman at iname.com Wed Dec 19 21:45:04 2018 From: dedelman at iname.com (David Edelman) Date: Wed, 19 Dec 2018 16:45:04 -0500 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: <000001d497e4$1bb8caa0$532a5fe0$@iname.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You could be sure of two things when there were ambiguities in the routing tables: 1- Every manufacturer knew how to handle them. 2 - Every manufacturer did it a different way. I suspect that in most cases where two conflicting route entries existed, the router selected the first one that it encountered unless they were advertised using different protocols, then the priority associated with the protocol was used as a tie breaker. Dave - -----Original Message----- From: NANOG On Behalf Of Owen DeLong Sent: Wednesday, December 19, 2018 3:47 PM To: Thomas Bellman Cc: nanog at nanog.org Subject: Re: Stupid Question maybe? > On Dec 19, 2018, at 12:11 , Thomas Bellman wrote: > > On 2018-12-19 20:47 MET, valdis.kletnieks at vt.edu wrote: > >> There was indeed a fairly long stretch of time (until the CIDR RFC >> came out and specifically said it wasn't at all canon) where we >> didn't have an RFC that specifically said that netmask bits had to be contiguous. > > How did routers select the best (most specific) route for an address? > If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and > 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have > the same number of matching bits. > > /Bellman > The institution of the longest match rule came with the prohibition (deprecation) of discontiguous net masks. Owen -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBq72AAKCRCXCCyZOY1F IVcSAKDwHTb8NranEYcejX1CJQwz0h318QCfSBzQMCiJ2uZwOxt3gvPTe3f38KE= =HMXc -----END PGP SIGNATURE----- From baldur.norddahl at gmail.com Thu Dec 20 00:21:12 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 20 Dec 2018 01:21:12 +0100 Subject: Stupid Question maybe? In-Reply-To: <000001d497e4$1bb8caa0$532a5fe0$@iname.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> <000001d497e4$1bb8caa0$532a5fe0$@iname.com> Message-ID: > > > I remember working on a SGI Unix workstation, where you simply could not specify netmask. It was implicated by the class of address. This meant that there were only three possible netmasks. If that was how the first IP implementations started out, we had contiguous netmasks at the beginning... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Dec 20 01:25:03 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 19 Dec 2018 17:25:03 -0800 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: thank you this is very useful to know Mehmet On Wed, Dec 19, 2018 at 1:46 AM James Bensley wrote: > Hi Mehmet, > > This has been discussed on the Juniper-NSP list several times, here's > a couple of examples: > > https://puck.nether.net/pipermail/juniper-nsp/2018-November/036673.html > https://puck.nether.net/pipermail/juniper-nsp/2018-April/035397.html > https://puck.nether.net/pipermail/juniper-nsp/2016-June/032964.html > > Cheers, > James. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbfixurpc at gmail.com Thu Dec 20 03:33:35 2018 From: jbfixurpc at gmail.com (Joe) Date: Wed, 19 Dec 2018 21:33:35 -0600 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> <000001d497e4$1bb8caa0$532a5fe0$@iname.com> Message-ID: Just wanted to say thanks to all for responses about the information on this! Extremely informative and helpful. Have a great holiday and happy new year! -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Thu Dec 20 09:47:12 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2018 11:47:12 +0200 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On Thu, 20 Dec 2018 at 10:32, Christian Meutes wrote: > And unfortunately is still not supported by IOS-XR for IPv6, which could mean not having a scaleable way on your edge to protect your internal network. Aye. I'd recommend not advertise your linknetworks at all, and let customers either opt-in or out-out from creating /128 and /32 static route towards interface. Achieving mostly same result, except for in local device where edge interfaces can reach customer and your side. -- ++ytti From gtaylor at tnetconsulting.net Thu Dec 20 16:18:50 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 20 Dec 2018 09:18:50 -0700 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On 12/20/2018 02:47 AM, Saku Ytti wrote: > Aye. I'd recommend not advertise your linknetworks at all, and let > customers either opt-in or out-out from creating /128 and /32 static > route towards interface. Achieving mostly same result, except for in > local device where edge interfaces can reach customer and your side. Are you advocating not advertising customer linknetworks within your own organization? I know of a use cases where linknetworks must be globally accessible. At least the customer's linknetwork IP address. So, not advertising them (or at least an aggregate for them) would be problematic. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Thu Dec 20 16:46:20 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 20 Dec 2018 09:46:20 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: On 12/14/2018 11:48 AM, Grant Taylor wrote: > I've been seeing them for three or four days now. BUMP This has been going on for more than a week now. I'm quite confident that there have been hundreds of auto-replies. (I'm seeing 285 incoming message from the NANOG mailing list since I became aware of the auto-reply.) I'm really surprised that there has not been any reply or action by the NANOG list owner(s). I would have hoped, if not expected, better, or any, response by now. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From mick at mickod.ie Sat Dec 15 09:54:38 2018 From: mick at mickod.ie (Mick O'Donovan) Date: Sat, 15 Dec 2018 09:54:38 +0000 Subject: IRR Cleanliness In-Reply-To: <20181215091404.GA86684@gweep.net> References: <20181215091404.GA86684@gweep.net> Message-ID: On Sat 15 Dec 2018 at 09:17, Joe Provo wrote: > Being listed in an as-macro doesn't affect your use of the AS > or use of it in any IRR. > > Many providers will list customers (for filter generation) without > express consent. Some folks will lump peers in categories through > IRR data. There's certainly nothing amiss in using as-macros even > for non-neighbors in a number of cases, enumerting ASNs one will > [de]preference from a certain set of peers or will drop entirely > for example. > > Often such policies exist but aren't published. ;-) > > Cheers! > > Joe > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling +1 I wouldn’t see this as odd behaviour either. Mick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jc at irbs.com Sat Dec 15 13:57:15 2018 From: jc at irbs.com (John Capo) Date: Sat, 15 Dec 2018 08:57:15 -0500 (EST) Subject: email scannering / filtering In-Reply-To: <20181214184901.GB4524@cmadams.net> References: <0f408f2143799fc2167a95d95b3776ad@globalvision.net> <20181214173628.GA1130@gsp.org> <4953041c-0fcf-37ca-3320-0ce493966ba7@spamtrap.tnetconsulting.net> <20181214184901.GB4524@cmadams.net> Message-ID: <41114.205.237.194.2.1544882235.squirrel@beta.mxes.net> On Fri, December 14, 2018 13:49, Chris Adams wrote: > Once upon a time, Grant Taylor via NANOG said: > >> - ClamAV >> > > In my recent experience, ClamAV is basically useless against email > viruses. On one setup I run that handles around half a million messages a day, ClamAV might flag > 3-5 as viruses. I'm dubious that that's all > the virus messages that came through. > > I'd be interested in hearing of other Linux software (free or paid) that > can catch modern email viruses. ClamAV addons. https://www.securiteinfo.com/services/anti-spam-anti-virus/improve-detection-rate-of-zero-day-malwares-for-clamav.shtml https://sanesecurity.com/ From jmcc at hosterstats.com Sat Dec 15 23:23:20 2018 From: jmcc at hosterstats.com (John McCormac) Date: Sat, 15 Dec 2018 23:23:20 +0000 Subject: historical Bogon lists In-Reply-To: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> Message-ID: On 15/12/2018 08:31, Lars Prehn wrote: > Hi everyone, > > In order to sanitize historical BGP data I would like to use historical > Bogon lists. The CIDR report generates those lists on a daily basis > (e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) > but, as far as I know, it does not keep a history of those files - it > only holds the most up-to-date file. Does anybody know of a repository > that contains such bogon lists for historical data, or, did anybody > continiously fecthed and saved CIDR report's bogon lists? > There does seem to be some historical data from the CIDR report here: http://thyme.rand.apnic.net/ Might have a few historical freespace-dec.txt files around from building periodic IP/country maps of all gTLD websites. Regards...jmcc From olav.kvittem at uninett.no Mon Dec 17 07:44:12 2018 From: olav.kvittem at uninett.no (Olav Kvittem) Date: Mon, 17 Dec 2018 07:44:12 +0000 Subject: Pinging a Device Every Second In-Reply-To: <608ec728-e528-83e4-fa07-4f6f8d84a7ea@lns.com> References: <608ec728-e528-83e4-fa07-4f6f8d84a7ea@lns.com> Message-ID: <47099023-7a68-5096-1e55-dbeb933c4228@uninett.no> Hi, The link is not the only component to fail - routers and routing protocols all contribute at least as much. If your customers would have redundant connections, you also would like to look at convergence times. So a measurement end to end by a probe in the customers network could give you a more true picture. Facing that even sub second outages can annoy a video meeting, it might be that you want to poll more often than a second. Realizing that your "internet service" depends on the behaviour of all all the other service providers quality and if you even start monitoring that - you understand that you are "in deep shit" ;-) I did a small scale global inter domain measurement and discovered that the sheer number of small outages is way too high. Many of them might be routing changeovers in multi-redundant networks. cheers Olav On 15.12.2018 18:55, Tim Pozar wrote: > In one of my client's company, we use LibreNMS. It is normally used > to get SNMP data but we also have it configured to ping our more > "high touch" cients routers. In that case we can record performance > such as latency and packet loss. It will generate graphs that we can > pass on to the client. It also can be set to alert us if a client's > router is not pingable. > > LibreNMS can also integrate Smokeping if you want Smokeping-style > graphs showing standard deviation, etc. > > Currently I am running LibreNMS on a VM on a Proxmox cluser with a > couple of cores. It is probing 385 devices every 5 minutes and > keeping up with that. In polling, SNMP is the real time and CPU hog > where ping is pretty low impact. > > Tim > > On 12/15/18 9:37 AM, Baldur Norddahl wrote: >> You could configure BFD to send out a SNMP alert when three packets >> have been missed on a 50 ms cycle. Or instantly if the interface >> charges state to down. This way you would know that they are down >> within 150 ms. >> >> BFD is the hardware solution. A Linux box that has to ping 1000 >> addresses per second will be very taxed and likely unable to do >> that in a stable way. You will have seconds where it fails to do >> them all followed by seconds where it attempts to do them more than >> once. The result is that the statistics gathered is worthless. If >> you do something like this, it is much better to have a less >> ambitious 1 minute cycle. >> >> Take a look at Smokeping. If you want a graph to show the quality >> of the line, Smokeping makes some very good graphs for that. >> >> Regards Baldur >> >> 15. dec. 2018 16.49 skrev "Colton Conor" > >: >> >> How much compute and network resources does it take for a NMS to: >> >> 1. ICMP ping a device every second 2. Record these results. 3. >> Report an alarm after so many seconds of missed pings. >> >> We are looking for a system to in near real-time monitor if an end >> customers router is up or down. SNMP I assume would be too >> resource intensive, so ICMP pings seem like the only logical >> solution. >> >> The question is once a second pings too polling on an NMS and a >> consumer grade router? Does it take much network bandwidth and CPU >> resources from both the NMS and CPE side? >> >> Lets say this is for a 1,000 customer ISP. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Mon Dec 17 12:34:18 2018 From: aveline at misaka.io (Siyuan Miao) Date: Mon, 17 Dec 2018 20:34:18 +0800 Subject: routeviews.org pending delete Message-ID: All, routeviews.org is pending delete now. Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T09:33:18Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Network Solutions LLC Registrant State/Province: FL Registrant Country: US Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/ ) >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. I was wondering if there is anyone here can contact them to renew it if this project is still alive. Regards, Siyuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at 00100100.net Mon Dec 17 18:42:19 2018 From: don at 00100100.net (Don Fanning) Date: Mon, 17 Dec 2018 10:42:19 -0800 Subject: [Request] Contact information for CenturyLink network operations Message-ID: Hi all, Got a network issue with a DoS'er originating from Comcast into CenturyLink but unable to find the right people to work on this from the CenturyLink side. Looking for a contact to reach me off-list to help solve this or insert a block in a upstream router. Thanks! -Don From vp at syseleven.de Mon Dec 17 19:35:04 2018 From: vp at syseleven.de (Vincentz Petzholtz) Date: Mon, 17 Dec 2018 20:35:04 +0100 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: <42EA3ED8-1F02-4BDE-A5DB-9851795F0F32@syseleven.de> Hi there, About Juniper Fusion PE and our experience with it. > For example, you can't get SNMP oids for light levels or even read them right from the CLI. Sure it’s possible but also with a big „meh“. Here is how: "show interfaces diagnostics optics satellite “ (<- on the MX) BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values are wrong by a pretty big offset. Juniper promised they already fixed it but we can’t confirm (at least not in MX Junos 16.1). Soon we will take a look at MX Junos 17.3 with aligned sat image. > I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications Same thing here … we don’t really need it. At least it’s on the roadmap and/or already implemented with higher Junos/SNOS versions. > From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. Yep, that is really amazing and the reason we use it on many MXes. You can get rid of almost all ports you want (restrictions apply tho). > We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. We use Junos PE NOT as a replacement for any switch and/or ip fabrics within a datacenter. We use it to get rid of many customer/client ports (mainly 1G and 10G ports) which were directly connected to our MXes before. Atm I would not recommend using any closed fabrics beyond that scope. If it works for you … ok. > We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. At the moment? Don’t do it. If you run mpls on so called „core router/dwdm/wan facing ports“ you have to know that this is totally not supported on extended satellite ports. It’s not even on the roadmap. I already started to „collect“ some other ISPs to push juniper towards this feature because technically there no real reason why fusion should NOT be capable of pushing some mpls labels on already tagged 802.1br packets. Best regards, Vincentz > Am 17.12.2018 um 19:26 schrieb Matt Erculiani >: > > Fusion has made a lot more sense since Juniper changed the licensing model from every switch AND the MX to just the MX. > > We've deployed it in some of our sites. It is very cool from a forwarding plane perspective, but from a control plane standpoint it's very...meh. For example, you can't get SNMP oids for light levels or even read them right from the CLI. You have to log into the satellite switch like you would log into an FPC just to get light levels. That's probably the dumbest thing we've dealt with though. I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications. From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. > > We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. > > We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. > > Very interested in hearing about other's experiences with Fusion, good, bad, and ugly. > > -Matt > > On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin > wrote: > Hey there > > Any ISP using Juniper Fusion Provider Edge? > > https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html > > I am trying to chat with an engineer besides Juniper engineers to understand how buggy (or not) this is to go on production for a medium size ISP. > > Any feedback good/bad appreciated. > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From brian at interlinx.bc.ca Mon Dec 17 20:01:39 2018 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 17 Dec 2018 15:01:39 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? Message-ID: I've been trying to figure out why I can reach an IPv6 address at Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet connections as well as via an HE IPv6 tunnel but not the other of my two ISP connections At one point in time a traceroute was dying inside of he.net: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 10. ??? But I think it getting that far time was an anomaly and frankly it usually dies even before exiting my ISP's (Cogeco) network like this: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 7. ??? When I asked the kind folks at he.net for some advice about the problem (i.e. in the first traceroute above) their diagnosis was that Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco IPv6 address. Trying to talk to my ISP (again, Cogeco) has been impossible. One simply cannot reach the people who know more than how to reset your router and configure your e-mail. I wonder how I could go any further with this to confirm the diagnosis that Facebook doesn't have a route to the Cogeco network's IPv6 address space given that I only have access to my end of the path. 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 cunha at dcc.ufmg.br Tue Dec 18 15:05:26 2018 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Tue, 18 Dec 2018 10:05:26 -0500 Subject: BGP Experiment Message-ID: NANOG, We would like to inform you of an experiment to evaluate alternatives for speeding up adoption of BGP route origin validation (research paper with details [A]). Our plan is to announce prefix 184.164.224.0/24 with a valid standards-compliant unassigned BGP attribute from routers operated by the PEERING testbed [B, C]. The attribute will have flags 0xe0 (optional transitive [rfc4271, S4.3]), type 0xff (reserved for development), and size 0x20 (256bits). Our collaborators recently ran an equivalent experiment with no complaints or known issues [A], and so we do not anticipate any arising. Back in 2010, an experiment using unassigned attributes by RIPE and Duke University caused disruption in Internet routing due to a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other similar bugs have been patched [e.g., CVE-2013-6051], and new BGP attributes have been assigned (BGPsec-path) and adopted (large communities). We have successfully tested propagation of the announcements on Cisco IOS-based routers running versions 12.2(33)SRA and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and 1.6.3. We plan to announce 184.164.224.0/24 from 8 PEERING locations for a predefined period of 15 minutes starting 14:30 GMT, from Monday to Thursday, between the 7th and 22nd of January, 2019 (full schedule and locations [E]). We will stop the experiment immediately in case any issues arise. Although we do not expect the experiment to cause disruption, we welcome feedback on its safety and especially on how to make it safer. We can be reached at disco-experiment at googlegroups.com. Amir Herzberg, University of Connecticut Ethan Katz-Bassett, Columbia University Haya Shulman, Fraunhofer SIT Ítalo Cunha, Universidade Federal de Minas Gerais Michael Schapira, Hebrew University of Jerusalem Tomas Hlavacek, Fraunhofer SIT Yossi Gilad, MIT [A] https://conferences.sigcomm.org/hotnets/2018/program.html [B] http://peering.usc.edu [C] https://goo.gl/AFR1Cn [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment [E] https://goo.gl/nJhmx1 From jmh at joelhalpern.com Tue Dec 18 22:30:15 2018 From: jmh at joelhalpern.com (Joel Halpern) Date: Tue, 18 Dec 2018 17:30:15 -0500 Subject: Stupid Question maybe? In-Reply-To: <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: <71cb2337-d9bc-34a8-c914-9bbb843f1e73@joelhalpern.com> History of non-contiguous network masks, as I observed it. The rules did not prohibit discontiguous network masks. But no one was sure how to make them work. In particular, how to allocate subnets from discontiguous networks in a sensible fashion. In the early 90s, during the efforts to solve the swamp and classful exhaustion problems, Paul Francis (then Tsuchia) and I each worked out table structures that would allow for discontiguous masks with well-defined "prefixes" / "parents". Both approaches were based on extensions of Knuth's Patricia trees. (It took some interesting analysis and extensions.) When we were done, other folks looked at the work (I don't know if the Internet Drafts are still in repositories, but they shoudl be.) And concluded that while this would work, no network operations staff would ever be able to do it correctly. So as a community we decided not to go down that path. Yours, Joel On 12/18/18 5:12 PM, David Edelman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I seem to remember that before the advent of VLSM and CIDR there was no requirement for the 1 bits in the netmask to be contiguous with no intervening 0 bits and there was always someone who tested it out on a production network just to prove a point (usually only once) > > Dave > > - -----Original Message----- > From: NANOG On Behalf Of Naslund, Steve > Sent: Tuesday, December 18, 2018 3:37 PM > To: nanog at nanog.org > Subject: RE: Stupid Question maybe? > > It is a matter of machine readability vs human readability. Remember the IP was around when routers did not have a lot of horsepower. The dotted decimal notation was a compromise between pure binary (which the equipment used) and human readability. VLSM seems obvious now but in the beginning organizing various length routes into very expensive memory and low horsepower processors meant that it was much easier to break routes down along byte boundaries. This meant you only had four different lengths of route to deal with. It was intended to eliminate multiple passes sorting the tables. I am not quite sure what you mean about interspersing zeros, that would be meaningless. Remember that it is a mask. The address bits which are masked as 1s are significant to routing. The bits that are masked with 0s are the host portion and don't matter to the network routing table. > > Steven Naslund > Chicago IL > > >> /24 is certainly cleaner than 255.255.255.0. >> >> I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd >by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519. >> - Brian > -----BEGIN PGP SIGNATURE----- > > iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F > IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo= > =RimM > -----END PGP SIGNATURE----- > > From v.petzholtz at syseleven.de Wed Dec 19 09:00:32 2018 From: v.petzholtz at syseleven.de (Vincentz Petzholtz) Date: Wed, 19 Dec 2018 10:00:32 +0100 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: Hi there, About Juniper Fusion PE and our experience with it. > For example, you can't get SNMP oids for light levels or even read them right from the CLI. Sure it’s possible but also with a big „meh“. Here is how: "show interfaces diagnostics optics satellite “ (<- on the MX) BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values are wrong by a pretty big offset. Juniper promised they already fixed it but we can’t confirm (at least not in MX Junos 16.1). Soon we will take a look at MX Junos 17.3 with aligned sat image. > I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications Same thing here … we don’t really need it. At least it’s on the roadmap and/or already implemented with higher Junos/SNOS versions. > From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. Yep, that is really amazing and the reason we use it on many MXes. You can get rid of almost all ports you want (restrictions apply tho). > We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. We use Junos PE NOT as a replacement for any switch and/or ip fabrics within a datacenter. We use it to get rid of many customer/client ports (mainly 1G and 10G ports) which were directly connected to our MXes before. Atm I would not recommend using any closed fabrics beyond that scope. If it works for you … ok. > We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. At the moment? Don’t do it. If you run mpls on so called „core router/dwdm/wan facing ports“ you have to know that this is totally not supported on extended satellite ports. It’s not even on the roadmap. I already started to „collect“ some other ISPs to push juniper towards this feature because technically there no real reason why fusion should NOT be capable of pushing some mpls labels on already tagged 802.1br packets. Best regards, Vincentz — PS: some have received this mail multiple times because I’ve send it from the wrong account … time for vacation I guess. > Am 17.12.2018 um 19:26 schrieb Matt Erculiani : > > Fusion has made a lot more sense since Juniper changed the licensing model from every switch AND the MX to just the MX. > > We've deployed it in some of our sites. It is very cool from a forwarding plane perspective, but from a control plane standpoint it's very...meh. For example, you can't get SNMP oids for light levels or even read them right from the CLI. You have to log into the satellite switch like you would log into an FPC just to get light levels. That's probably the dumbest thing we've dealt with though. I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications. From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. > > We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. > > We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. > > Very interested in hearing about other's experiences with Fusion, good, bad, and ugly. > > -Matt > > On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin > wrote: > Hey there > > Any ISP using Juniper Fusion Provider Edge? > > https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html > > I am trying to chat with an engineer besides Juniper engineers to understand how buggy (or not) this is to go on production for a medium size ISP. > > Any feedback good/bad appreciated. > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From ds at schallert.com Wed Dec 19 14:33:13 2018 From: ds at schallert.com (Dominic Schallert) Date: Wed, 19 Dec 2018 15:33:13 +0100 Subject: Announcing Peering-LAN prefixes to customers Message-ID: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Hi all, this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation. I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter? Thanks Dominic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From smoot at tic.com Wed Dec 19 15:24:08 2018 From: smoot at tic.com (Smoot Carl-Mitchell) Date: Wed, 19 Dec 2018 08:24:08 -0700 Subject: Stupid Question maybe? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> Message-ID: On Wed, 2018-12-19 at 14:54 +0000, Naslund, Steve wrote: > I am wondering how a netmask could be not contiguous when the network > portion of the address must be contiguous. I suppose a bit mask > could certainly be anything you want but a netmask specifically > identifies the network portion of an address. Before CIDR, subnets allowed further subdividing Classful addresses and the mask bits after the network part could be non-contiguous. For a class A network the first 8 bits covered the classful network, but the remaining subnet bits did not have to be contiguous. Most network admins made the subnet part contiguous, but allowing non-contiguous subnet masks simplified the actual implementation. There was no need to check if the bits were contiguous in the code. Also subnet masks had to be the exactly the same on all devices. You could not have variable length masks. A common practice if you could get a Class B network (16 bit network part) was to use a 24 bit mask to divide the network into 254 subnetworks which was adequate for most purposes at the time. -- Smoot Carl-Mitchell System/Network Architect voice: +1 480 922-7313 cell: +1 602 421-9005 smoot at tic.com From ghira at mistral.co.uk Wed Dec 19 18:17:27 2018 From: ghira at mistral.co.uk (Adam Atkinson) Date: Wed, 19 Dec 2018 18:17:27 +0000 Subject: Stupid Question maybe? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ECDB28@WAUPRDMBXP1.medline.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <9578293AE169674F9A048B2BC9A081B40318ECD999@WAUPRDMBXP1.medline.com> <34545A5C-6F18-4011-B938-57BAEA2064DC@ianai.net> <9578293AE169674F9A048B2BC9A081B40318ECDB28@WAUPRDMBXP1.medline.com> Message-ID: <4b1c051a-75d0-7506-542a-b39784def268@mistral.co.uk> On 19/12/2018 16:24, Naslund, Steve wrote: > It has ALWAYS been the only correct way to configure equipment and is > a requirement under CIDR. Here were your commonly used netmasks > before CIDR/VLSM : > > 255.0.0.0 255.255.0.0 255.255.255.0 > > Which one is not contiguous? There is an example in RFC950 on page 15. 3. A Class C Network Case (illustrating non-contiguous subnet bits) For this case, assume that the requesting host is on class C network 192.1.127.0, has address 192.1.127.19, that there is a gateway at 192.1.127.50, and that on network an 3-bit subnet field is in use (01011000), that is, the address mask is 255.255.255.88. Admittedly, page 6 contains: Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address. I have never seen noncontiguous network masks used in real life, but I may not be old enough. -- Adam Atkinson From dp at datasoftcomnet.com Thu Dec 20 03:28:12 2018 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Thu, 20 Dec 2018 08:58:12 +0530 Subject: godaddy contacts Message-ID: <003101d49814$0a3106a0$1e9313e0$@datasoftcomnet.com> Hi, Is anyone from godaddy in this list? We believe they are announcing our BGP pool. The IP in 17th hop IP pool is ours as a result some of our customers are not able to login to godaddy. C:\Users\DP>tracert sso.godaddy.com Tracing route to sso.godaddy.com [104.238.65.153] over a maximum of 30 hops: 1 2 ms 1 ms 3 ms 192.168.225.1 2 4 ms 2 ms 2 ms 10.24.0.1 3 4 ms 2 ms 3 ms 103.40.48.13 4 4 ms 2 ms 2 ms vbc-10g-ccr.vbctv.in [123.108.200.5] 5 4 ms 2 ms 2 ms vbc-10g-asr.vbctv.in [123.108.200.42] 6 5 ms 2 ms 2 ms 14.142.71.141.static-hydrabad.vsnl.net.in [14.142.71.141] 7 26 ms 32 ms 27 ms 172.25.81.134 8 46 ms 33 ms 35 ms ix-ae-0-4.tcore1.mlv-mumbai.as6453.net [180.87.38.5] 9 150 ms 148 ms 147 ms if-ae-5-2.tcore1.wyn-marseille.as6453.net [180.87.38.126] 10 147 ms 147 ms 146 ms if-ae-8-1600.tcore1.pye-paris.as6453.net [80.231.217.6] 11 147 ms 145 ms 145 ms if-ae-11-2.tcore1.pvu-paris.as6453.net [80.231.153.49] 12 * * 143 ms 80.231.153.66 13 * 318 ms * ae-1-11.bear1.Phoenix1.Level3.net [4.69.210.157] 14 274 ms 337 ms 305 ms THE-GO-DADD.bear1.Phoenix1.Level3.net [4.16.142.186] 15 329 ms 278 ms 340 ms ip-148-72-32-9.ip.secureserver.net [148.72.32.9] 16 269 ms 282 ms 315 ms ip-184-168-0-117.ip.secureserver.net [184.168.0.117] 17 333 ms 289 ms 288 ms 125.62.192.197 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 291 ms 275 ms 273 ms ip-104-238-65-153.ip.secureserver.net [104.238.65.153] Trace complete. Regards Durga Prasad --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at errxtx.net Thu Dec 20 08:32:34 2018 From: christian at errxtx.net (Christian Meutes) Date: Thu, 20 Dec 2018 09:32:34 +0100 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti wrote: > On Wed, 19 Dec 2018 at 02:55, Philip Loenneker > wrote: > > > I had a heck of a time a few years back trying to troubleshoot an issue > where an upstream provider had an ACL with an incorrect mask along the > lines of 255.252.255.0. That was really interesting to talk about once we > discovered it, though it caused some loss of hair beforehand... > > Juniper originally didn't support them even in ACL use-case but were > forced to add later due to customer demand, so people do have > use-cases for them. If we'd still support them in forwarding, I'm sure > someone would come up with solution which depends on it. I am not > advocating we should, I'll rather take my extra PPS out of the HW. > > However there is one quite interesting use-case for discontinuous mask > in ACL. If you have, like you should have, specific block for customer > linknetworks, you can in iACL drop all packets to your side of the > links while still allowing packets to customer side of the links, > making attack surface against your network minimal. And unfortunately is still not supported by IOS-XR for IPv6, which could mean not having a scaleable way on your edge to protect your internal network. -- Christian e-mail/xmpp: christian at errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at chronos.com.tr Thu Dec 20 17:17:20 2018 From: omer at chronos.com.tr (=?UTF-8?B?TS4gw5ZtZXIgR8OWTEdFTMSw?=) Date: Thu, 20 Dec 2018 20:17:20 +0300 Subject: Auto-reply from Yahoo... In-Reply-To: Message-ID: <0bfbf1bb-e1f4-4413-9f7b-e616cac3e5ed@email.android.com> An HTML attachment was scrubbed... URL: From william.allen.simpson at gmail.com Thu Dec 20 17:19:27 2018 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 20 Dec 2018 12:19:27 -0500 Subject: Stupid Question maybe? In-Reply-To: <13937.1545248873@turing-police.cc.vt.edu> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> Message-ID: <20cd8bea-b1a9-d386-dea3-9405b25e4d56@gmail.com> On 12/19/18 2:47 PM, valdis.kletnieks at vt.edu wrote: > So at one show, the Interop show network went to a 255.255.252.0 netmask, and > of course a lot of vendors had issues and complained. The stock response was > "Quit whining, or next show it's going to be 255.255.250.0". > Ha, I remember! Let us not forget Interop 91, where one vendor accidentally sent all its packets with an IP version field of 0. Nearly every router was shown to never check the IP version number! Moreover, it turned out later that major printer vendors weren't checking either.... No good way to update them in the field, ever. That was a serious worry as we designed PIPE/SIP/SIPP/IPv6, and the main reason that we had to get new link layer protocol numbers. Then there were the fine vendors that conflated the link and IP headers. That fell apart when IEEE started assigning OUIs that began with 0x4xxxxxxx. Interop really used to be a blessing, before it became just another show. From william.allen.simpson at gmail.com Thu Dec 20 17:22:51 2018 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 20 Dec 2018 12:22:51 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> Message-ID: <9b869f17-fa35-5c80-e1a3-33cbaa11babf@gmail.com> On 12/20/18 11:46 AM, Grant Taylor via NANOG wrote: > On 12/14/2018 11:48 AM, Grant Taylor wrote: >> I've been seeing them for three or four days now. > > BUMP > > This has been going on for more than a week now.  I'm quite confident that there have been hundreds of auto-replies.  (I'm seeing 285 incoming message from the NANOG mailing list since I became aware of the auto-reply.) > > I'm really surprised that there has not been any reply or action by the NANOG list owner(s).  I would have hoped, if not expected, better, or any, response by now. > Well, somebody who seemed to be from Yahoo claimed they were fixing their auto-responder. Obviously, that hasn't been deployed yet. From david at xtom.com Thu Dec 20 17:29:03 2018 From: david at xtom.com (David Guo) Date: Thu, 20 Dec 2018 17:29:03 +0000 Subject: routeviews.org pending delete In-Reply-To: References: Message-ID: It’s your cache resule root at server ~ # whois routeviews.org Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T18:54:32Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Registrant State/Province: OR Registrant Country: US Name Server: GUELAH.SHRUBBERY.NET Name Server: PHLOEM.UOREGON.EDU DNSSEC: unsigned From: NANOG On Behalf Of Siyuan Miao Sent: Monday, December 17, 2018 8:34 PM To: nanog at nanog.org Subject: routeviews.org pending delete All, routeviews.org is pending delete now. Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T09:33:18Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Network Solutions LLC Registrant State/Province: FL Registrant Country: US Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/) >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. I was wondering if there is anyone here can contact them to renew it if this project is still alive. Regards, Siyuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkotronis at ics.forth.gr Thu Dec 20 17:23:24 2018 From: vkotronis at ics.forth.gr (Vasileios Kotronis) Date: Thu, 20 Dec 2018 19:23:24 +0200 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released Message-ID: Dear operators, FORTH's INSPIRE group and CAIDA are delighted to announce the public release of the ARTEMIS BGP prefix hijacking detection tool, available as open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential hijacking attempts against its own prefixes. The system detects such attacks within seconds, enabling immediate mitigation. The current release has been tested at a major greek ISP, a dual-homed edge academic network, and a major US R&E backbone network. We would be happy if you'd give it a try and provide feedback. Feel free to make pull requests on GitHub and help us make this a true community project. ARTEMIS is funded by European Research Council (ERC) grant agreement no. 338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S&T contract HHSP233201600012C. Best regards, Vasileios -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From lesmith at ecsis.net Thu Dec 20 17:31:08 2018 From: lesmith at ecsis.net (Larry Smith) Date: Thu, 20 Dec 2018 11:31:08 -0600 Subject: routeviews.org pending delete In-Reply-To: References: Message-ID: <201812201131.08555.lesmith@ecsis.net> It has been updated it appears: Registry Expiry Date: 2019-12-14T23:05:47Z -- Larry Smith lesmith at ecsis.net On Mon December 17 2018 06:34, Siyuan Miao wrote: > All, > > routeviews.org is pending delete now. > > Domain Name: ROUTEVIEWS.ORG > Registry Domain ID: D48496876-LROR > Registrar WHOIS Server: whois.networksolutions.com > Registrar URL: http://www.networksolutions.com > Updated Date: 2018-12-17T09:33:18Z > Creation Date: 2000-12-14T23:05:47Z > Registry Expiry Date: 2019-12-14T23:05:47Z > Registrar Registration Expiration Date: > Registrar: Network Solutions, LLC > Registrar IANA ID: 2 > Registrar Abuse Contact Email: abuse at web.com > Registrar Abuse Contact Phone: +1.8003337680 > Reseller: > Domain Status: clientTransferProhibited > https://icann.org/epp#clientTransferProhibited > Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod > Registrant Organization: Network Solutions LLC > Registrant State/Province: FL > Registrant Country: US > Name Server: NS1.PENDINGRENEWALDELETION.COM > Name Server: NS2.PENDINGRENEWALDELETION.COM > DNSSEC: unsigned > URL of the ICANN Whois Inaccuracy Complaint Form > https://www.icann.org/wicf/ ) > > >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< > > routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. > routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. > > I was wondering if there is anyone here can contact them to renew it if > this project is still alive. > > Regards, > Siyuan From amitchell at isipp.com Thu Dec 20 17:35:17 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 20 Dec 2018 10:35:17 -0700 Subject: [Request] Contact information for CenturyLink network operations In-Reply-To: References: Message-ID: > On Dec 17, 2018, at 11:42 AM, Don Fanning wrote: > > Hi all, > > Got a network issue with a DoS'er originating from Comcast into > CenturyLink but unable to find the right people to work on this from > the CenturyLink side. Looking for a contact to reach me off-list to > help solve this or insert a block in a upstream router. Don, please email me offlist (amitchell at isipp.com); CenturyLink is now part of Level3...we can get you to the right person. Anne --- Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Board Member, Board of Directors, Denver Internet Exchange Board Member, Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Ret. Professor of Law, Lincoln Law School of San Jose From david at xtom.com Thu Dec 20 17:39:00 2018 From: david at xtom.com (David Guo) Date: Thu, 20 Dec 2018 17:39:00 +0000 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google -----Original Message----- From: NANOG On Behalf Of Brian J. Murrell Sent: Tuesday, December 18, 2018 4:02 AM To: nanog at nanog.org Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? I've been trying to figure out why I can reach an IPv6 address at Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet connections as well as via an HE IPv6 tunnel but not the other of my two ISP connections At one point in time a traceroute was dying inside of he.net: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 10. ??? But I think it getting that far time was an anomaly and frankly it usually dies even before exiting my ISP's (Cogeco) network like this: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 7. ??? When I asked the kind folks at he.net for some advice about the problem (i.e. in the first traceroute above) their diagnosis was that Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco IPv6 address. Trying to talk to my ISP (again, Cogeco) has been impossible. One simply cannot reach the people who know more than how to reset your router and configure your e-mail. I wonder how I could go any further with this to confirm the diagnosis that Facebook doesn't have a route to the Cogeco network's IPv6 address space given that I only have access to my end of the path. Cheers, b. From job at ntt.net Thu Dec 20 17:43:25 2018 From: job at ntt.net (Job Snijders) Date: Thu, 20 Dec 2018 18:43:25 +0100 Subject: BGP Experiment In-Reply-To: References: Message-ID: Dear Italo, Thanks for giving the community a heads-up on your plan! I think your announcement like these are the best anyone can do when trying legal but new BGP path attributes. I'll forward this message to other NOGs and make sure that our NOC adds it to their calendar. Kind regards, Job On Thu, Dec 20, 2018 at 6:39 PM Italo Cunha wrote: > > NANOG, > > We would like to inform you of an experiment to evaluate alternatives > for speeding up adoption of BGP route origin validation (research > paper with details [A]). > > Our plan is to announce prefix 184.164.224.0/24 with a valid > standards-compliant unassigned BGP attribute from routers operated by > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > development), and size 0x20 (256bits). > > Our collaborators recently ran an equivalent experiment with no > complaints or known issues [A], and so we do not anticipate any > arising. Back in 2010, an experiment using unassigned attributes by > RIPE and Duke University caused disruption in Internet routing due to > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > attributes have been assigned (BGPsec-path) and adopted (large > communities). We have successfully tested propagation of the > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > 1.6.3. > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > predefined period of 15 minutes starting 14:30 GMT, from Monday to > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > locations [E]). We will stop the experiment immediately in case any > issues arise. > > Although we do not expect the experiment to cause disruption, we > welcome feedback on its safety and especially on how to make it safer. > We can be reached at disco-experiment at googlegroups.com. > > Amir Herzberg, University of Connecticut > Ethan Katz-Bassett, Columbia University > Haya Shulman, Fraunhofer SIT > Ítalo Cunha, Universidade Federal de Minas Gerais > Michael Schapira, Hebrew University of Jerusalem > Tomas Hlavacek, Fraunhofer SIT > Yossi Gilad, MIT > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > [B] http://peering.usc.edu > [C] https://goo.gl/AFR1Cn > [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > [E] https://goo.gl/nJhmx1 From bryce at thenetworknerds.ca Thu Dec 20 17:51:00 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Thu, 20 Dec 2018 09:51:00 -0800 Subject: Auto-reply from Yahoo... In-Reply-To: <0bfbf1bb-e1f4-4413-9f7b-e616cac3e5ed@email.android.com> References: <0bfbf1bb-e1f4-4413-9f7b-e616cac3e5ed@email.android.com> Message-ID: <742502DE-96A0-452D-84BE-E88493CD533B@thenetworknerds.ca> I’m glad that the bounces are not sent to the list, but that means that the list does not know about them and therefore can’t do anything automatically. There is little we can do other than block the email individually until the list owners or Yahoo themselves manage to remove them. This should be a lesson to those running email auto-reply systems to set up some way to have them not make these auto-replies to mailing lists which should not be too hard to automate. Thanks ~ Bryce Wilson, AS202313, EVIX AS137933 > On Dec 20, 2018, at 9:17 AM, M. Ömer GÖLGELİ wrote: > > This can happen for many reasons. > Quitting employees, dropping domains, death whatever. > > They should be *somehow* auto removed after a certain number of bounces. > > > > M. > --- > > > > On 20 Dec 2018 19:46, Grant Taylor via NANOG wrote: > On 12/14/2018 11:48 AM, Grant Taylor wrote: > > I've been seeing them for three or four days now. > > BUMP > > This has been going on for more than a week now. I'm quite confident > that there have been hundreds of auto-replies. (I'm seeing 285 incoming > message from the NANOG mailing list since I became aware of the auto-reply.) > > I'm really surprised that there has not been any reply or action by the > NANOG list owner(s). I would have hoped, if not expected, better, or > any, response by now. > > > > -- > Grant. . . . > unix || die > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Dec 20 17:54:31 2018 From: job at ntt.net (Job Snijders) Date: Thu, 20 Dec 2018 18:54:31 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Dear Dominic, On Thu, Dec 20, 2018 at 6:49 PM Dominic Schallert wrote: > this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation. > > I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter? It is NTT's policy to reject Peering LAN prefixes (and any more-specifics) of any IXPs NTT is connected; on both our ingress EBGP and egress EBGP policies. We don't see a need for NTT to attempt to make such peering lan networks reachable for third parties. Such reachability may negatively impact operations, especially when more-specifics of Peering LAN prefixes are distributed through the default-free zone. As a consequence, for IXPs this policy suggests that it is a necessity to host their own infrastructure (IXP website, mail server, etc) outside the peering lan prefix. Kind regards, Job From saku at ytti.fi Thu Dec 20 17:55:08 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2018 19:55:08 +0200 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG wrote: > Are you advocating not advertising customer linknetworks within your own > organization? Correct. > I know of a use cases where linknetworks must be globally accessible. > At least the customer's linknetwork IP address. So, not advertising > them (or at least an aggregate for them) would be problematic. What is that use-case? Do notice that I propose opt-in static host/32 route pointing to the link, giving far-end INET reachability, if they so want, without adding attack surface on the near-end. -- ++ytti From dhubbard at dino.hostasaurus.com Thu Dec 20 18:00:30 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 20 Dec 2018 18:00:30 +0000 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Google and HE don't have IPv6 connectivity with Cogent because Cogent's CEO has been in some decades long pissing match with them about free settlement free peering. That's the unfortunate reality of the situation; nothing you can do other than have another route to HE/Google IPv6 targets. We have some Cogent circuits that are effectively useless for IPv6 as our customer base has heavy traffic to/from Google cloud services, so they can't be used for a backup / DR scenario; their only real value is an optimal route to other Cogent customers. I'm slowly replacing our Cogent circuits when feasible because the reality is our customers reaching Google over IPv6 via all our upstreams is more valuable than Cogent's cost savings. On 12/20/18, 12:37 PM, "NANOG on behalf of Brian J. Murrell" wrote: I've been trying to figure out why I can reach an IPv6 address at Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet connections as well as via an HE IPv6 tunnel but not the other of my two ISP connections At one point in time a traceroute was dying inside of he.net: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 10. ??? But I think it getting that far time was an anomaly and frankly it usually dies even before exiting my ISP's (Cogeco) network like this: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 7. ??? When I asked the kind folks at he.net for some advice about the problem (i.e. in the first traceroute above) their diagnosis was that Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco IPv6 address. Trying to talk to my ISP (again, Cogeco) has been impossible. One simply cannot reach the people who know more than how to reset your router and configure your e-mail. I wonder how I could go any further with this to confirm the diagnosis that Facebook doesn't have a route to the Cogeco network's IPv6 address space given that I only have access to my end of the path. Cheers, b. From ross at tajvar.io Thu Dec 20 18:00:26 2018 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 20 Dec 2018 13:00:26 -0500 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: This brings to mind the following (old) blog post from CloudFlare: https://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet/ Relevant excerpt here: > Beyond attacking CloudFlare's direct peers, the attackers also attacked > the core IX infrastructure on the London Internet Exchange (LINX), the > Amsterdam Internet Exchange (AMS-IX), the Frankfurt Internet Exchange > (DE-CIX), and the Hong Kong Internet Exchange (HKIX). From our perspective, > the attacks had the largest effect on LINX which caused impact over the > exchange and LINX's systems that monitor the exchange, as visible through > the drop in traffic recorded by their monitoring systems. (Corrected: see > below for original phrasing.) > The congestion impacted many of the networks on the IXs, including > CloudFlare's. As problems were detected on the IX, we would route traffic > around them. However, several London-based CloudFlare users reported > intermittent issues over the last several days. This is the root cause of > those problems. > The attacks also exposed some vulnerabilities in the architecture of some > IXs. We, along with many other network security experts, worked with the > team at LINX to better secure themselves. In doing so, we developed a list > of best practices for any IX in order to make them less vulnerable to > attacks. > Two specific suggestions to limit attacks like this involve making it more > difficult to attack the IP addresses that members of the IX use to > interchange traffic between each other. We are working with IXs to ensure > that: 1) these IP addresses should not be announced as routable across the > public Internet; and 2) packets destined to these IP addresses should only > be permitted from other IX IP addresses. We've been very impressed with the > team at LINX and how quickly they've worked to implement these changes and > add additional security to their IX and are hopeful other IXs will quickly > follow their lead. On Thu, Dec 20, 2018 at 12:51 PM Dominic Schallert wrote: > Hi all, > > this might be a stupid question but today I was discussing with a > colleague if Peering-LAN prefixes should be re-distributed/announced to > direct customers/peers. My standpoint is that in any case, Peering-LAN > prefixes should be filtered and not announced to peers/customers because a > Peering-LAN represents some sort of DMZ and there is simply no need for > them to be reachable by third-parties not being physically connected to an > IXP themselves. Also from a security point of view, a lot of new issues > might occur in this situation. > > I’ve been seeing a few transit providers lately announcing (even > reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their > customers. I’m wondering if there is any document or RFC particularly > describing this matter? > > Thanks > Dominic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Dec 20 18:00:46 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 20 Dec 2018 11:00:46 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: <0bfbf1bb-e1f4-4413-9f7b-e616cac3e5ed@email.android.com> References: <0bfbf1bb-e1f4-4413-9f7b-e616cac3e5ed@email.android.com> Message-ID: <61cb5d7f-5c52-4a67-2093-6551bee0ccc7@spamtrap.tnetconsulting.net> On 12/20/2018 10:17 AM, M. Ömer GÖLGELİ wrote: > This can happen for many reasons. > Quitting employees, dropping domains, death whatever. Yep. I get it. > They should be *somehow* auto removed after a certain number of bounces. The catch is, they aren't /bounces/. They are auto-responses to the sender of the email. Meaning I'll get one to me for this reply. You very likely got one to you for the message that I'm replying to. Delivery to the problematic recipient is very likely succeeding at an SMTP level. So, the mailing list manager doesn't see them and has no opportunity to do anything about them. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From stillwaxin at gmail.com Thu Dec 20 18:06:18 2018 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 20 Dec 2018 13:06:18 -0500 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: IXP LANs should not be announced via BGP (or your IGP either). See section 3.1: http://nabcop.org/index.php/BCOP-Exchange_Points_v2 On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert wrote: > Hi all, > > this might be a stupid question but today I was discussing with a > colleague if Peering-LAN prefixes should be re-distributed/announced to > direct customers/peers. My standpoint is that in any case, Peering-LAN > prefixes should be filtered and not announced to peers/customers because a > Peering-LAN represents some sort of DMZ and there is simply no need for > them to be reachable by third-parties not being physically connected to an > IXP themselves. Also from a security point of view, a lot of new issues > might occur in this situation. > > I’ve been seeing a few transit providers lately announcing (even > reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their > customers. I’m wondering if there is any document or RFC particularly > describing this matter? > > Thanks > Dominic > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Dec 20 18:09:48 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 20 Dec 2018 11:09:48 -0700 Subject: godaddy contacts In-Reply-To: <003101d49814$0a3106a0$1e9313e0$@datasoftcomnet.com> References: <003101d49814$0a3106a0$1e9313e0$@datasoftcomnet.com> Message-ID: <425CE28B-03D0-472A-ABD5-CF078C4DF3D7@isipp.com> > Is anyone from godaddy in this list? We believe they are announcing our BGP pool. The IP in 17th hop IP pool is ours as a result some of our customers are not able to login to godaddy. > > C:\Users\DP>tracert sso.godaddy.com > > Tracing route to sso.godaddy.com [104.238.65.153] > over a maximum of 30 hops: > > 1 2 ms 1 ms 3 ms 192.168.225.1 > 2 4 ms 2 ms 2 ms 10.24.0.1 > 3 4 ms 2 ms 3 ms 103.40.48.13 > 4 4 ms 2 ms 2 ms vbc-10g-ccr.vbctv.in [123.108.200.5] > 5 4 ms 2 ms 2 ms vbc-10g-asr.vbctv.in [123.108.200.42] > 6 5 ms 2 ms 2 ms 14.142.71.141.static-hydrabad.vsnl.net.in [14.142.71.141] > 7 26 ms 32 ms 27 ms 172.25.81.134 > 8 46 ms 33 ms 35 ms ix-ae-0-4.tcore1.mlv-mumbai.as6453.net [180.87.38.5] > 9 150 ms 148 ms 147 ms if-ae-5-2.tcore1.wyn-marseille.as6453.net [180.87.38.126] > 10 147 ms 147 ms 146 ms if-ae-8-1600.tcore1.pye-paris.as6453.net [80.231.217.6] > 11 147 ms 145 ms 145 ms if-ae-11-2.tcore1.pvu-paris.as6453.net [80.231.153.49] > 12 * * 143 ms 80.231.153.66 > 13 * 318 ms * ae-1-11.bear1.Phoenix1.Level3.net [4.69.210.157] > 14 274 ms 337 ms 305 ms THE-GO-DADD.bear1.Phoenix1.Level3.net [4.16.142.186] > 15 329 ms 278 ms 340 ms ip-148-72-32-9.ip.secureserver.net [148.72.32.9] > 16 269 ms 282 ms 315 ms ip-184-168-0-117.ip.secureserver.net [184.168.0.117] > 17 333 ms 289 ms 288 ms 125.62.192.197 > 18 * * * Request timed out. > 19 * * * Request timed out. > 20 * * * Request timed out. > 21 * * * Request timed out. > 22 * * * Request timed out. > 23 * * * Request timed out. > 24 291 ms 275 ms 273 ms ip-104-238-65-153.ip.secureserver.net [104.238.65.153] > > Trace complete. > Hi Durga - we can get this in front of the right person - may I have permission to forward this to GoDaddy? Anne --- Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From ds at schallert.com Thu Dec 20 18:15:46 2018 From: ds at schallert.com (Dominic Schallert) Date: Thu, 20 Dec 2018 19:15:46 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <5c1bdc54.1c69fb81.61661.e8c1SMTPIN_ADDED_MISSING@mx.google.com> Dear Job, Michael, Ross, thank you very much for sharing your opinion, the detailed info and references. That’s pretty much what I excpected. Just wondered because I couldn’t find any IXP Conection Agreement stating this „issue“ explicitly yet. Maybe MANRS IXP actions has some recommendations regarding this, checking that now. Best wishes and happy holidays Cheers Dominic > Am 20.12.2018 um 19:06 schrieb Michael Still : > > IXP LANs should not be announced via BGP (or your IGP either). See section 3.1: > http://nabcop.org/index.php/BCOP-Exchange_Points_v2 > > > > On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert > wrote: > Hi all, > > this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation. > > I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter? > > Thanks > Dominic > > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From saku at ytti.fi Thu Dec 20 18:15:45 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2018 20:15:45 +0200 Subject: Stupid Question maybe? In-Reply-To: <20cd8bea-b1a9-d386-dea3-9405b25e4d56@gmail.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <13937.1545248873@turing-police.cc.vt.edu> <20cd8bea-b1a9-d386-dea3-9405b25e4d56@gmail.com> Message-ID: On Thu, 20 Dec 2018 at 20:07, William Allen Simpson wrote: > Then there were the fine vendors that conflated the link and IP headers. > That fell apart when IEEE started assigning OUIs that began with 0x4xxxxxxx. There is no way to know in-transit what MPLS carries. Vendors have implemented heuristics of different complexities to try to guess what is being carried in effort to enable services like ECMP and netflow. In hindsight MPLS ethertype probably should tell what it carries MPLS-IP, MPLS-ETH, MPLS-OTHER. This is on-going problem with no obvious solution, the ECMP issue can be largely handled by disabling payload guessing and relying on having sufficient flow entropy in labels. But the services such as netflow still need transit guessing. -- ++ytti From nanog at ics-il.net Thu Dec 20 18:27:17 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 20 Dec 2018 12:27:17 -0600 (CST) Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: <34439026.2796.1545330436748.JavaMail.mhammett@ThunderFuck> Cogent != Cogeco ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "David Guo via NANOG" To: "Brian J. Murrell" , nanog at nanog.org Sent: Thursday, December 20, 2018 11:39:00 AM Subject: RE: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google -----Original Message----- From: NANOG On Behalf Of Brian J. Murrell Sent: Tuesday, December 18, 2018 4:02 AM To: nanog at nanog.org Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? I've been trying to figure out why I can reach an IPv6 address at Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet connections as well as via an HE IPv6 tunnel but not the other of my two ISP connections At one point in time a traceroute was dying inside of he.net: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 10. ??? But I think it getting that far time was an anomaly and frankly it usually dies even before exiting my ISP's (Cogeco) network like this: Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 7. ??? When I asked the kind folks at he.net for some advice about the problem (i.e. in the first traceroute above) their diagnosis was that Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco IPv6 address. Trying to talk to my ISP (again, Cogeco) has been impossible. One simply cannot reach the people who know more than how to reset your router and configure your e-mail. I wonder how I could go any further with this to confirm the diagnosis that Facebook doesn't have a route to the Cogeco network's IPv6 address space given that I only have access to my end of the path. Cheers, b. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nop at imap.cc Thu Dec 20 18:38:00 2018 From: nop at imap.cc (nop at imap.cc) Date: Thu, 20 Dec 2018 13:38:00 -0500 Subject: =?UTF-8?Q?Re=3A_Facebook_doesn=27t_have_a_route_to_my_ISP=27s_=28Cogeco=29?= =?UTF-8?Q?_IPv6_space=3F?= In-Reply-To: References: Message-ID: Cogeco is not related to Cogent On Thu, Dec 20, 2018, at 0:0.36666666666 AM, David Guo via NANOG写: > It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google From gtaylor at tnetconsulting.net Thu Dec 20 18:39:36 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 20 Dec 2018 11:39:36 -0700 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> Message-ID: <5b912bde-6e5f-8060-8128-880b410f325d@spamtrap.tnetconsulting.net> On 12/20/2018 10:55 AM, Saku Ytti wrote: > Correct. Do you have /24 cover prefixes advertised to the Internet? > What is that use-case? Do notice that I propose opt-in static host/32 > route pointing to the link, giving far-end INET reachability, if they > so want, without adding attack surface on the near-end. $EMPLOYER requires globally routable access to the link net IP on our equipment for specific configurations. Sorry, I can't go into details. I'm trying to ascertain if the configuration (as I understand it) that advocating for would work for us or not. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From matthew at matthew.at Thu Dec 20 18:50:53 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 20 Dec 2018 10:50:53 -0800 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Message-ID: In other words, they’re on The Internet and you (and your transit provider) are not. On Thu, Dec 20, 2018 at 10:40 AM David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Google and HE don't have IPv6 connectivity with Cogent because Cogent's > CEO has been in some decades long pissing match with them about free > settlement free peering. That's the unfortunate reality of the situation; > nothing you can do other than have another route to HE/Google IPv6 > targets. We have some Cogent circuits that are effectively useless for > IPv6 as our customer base has heavy traffic to/from Google cloud services, > so they can't be used for a backup / DR scenario; their only real value is > an optimal route to other Cogent customers. I'm slowly replacing our > Cogent circuits when feasible because the reality is our customers reaching > Google over IPv6 via all our upstreams is more valuable than Cogent's cost > savings. > > > > On 12/20/18, 12:37 PM, "NANOG on behalf of Brian J. Murrell" < > nanog-bounces at nanog.org on behalf of brian at interlinx.bc.ca> wrote: > > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host Loss% Snt Last Avg > Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 > 0.7 2.9 0.8 > 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 > 8.3 37.9 10.6 > 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 > 10.8 1031. 455.9 > 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 > 11.2 15.3 1.6 > 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 > 21.3 27.6 2.2 > 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 > 21.6 24.9 1.2 > 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 > 34.1 36.1 0.7 > 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 > 44.8 49.1 1.5 > 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 > 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host Loss% Snt Last Avg > Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 > 0.6 1.0 0.1 > 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 > 8.1 40.5 5.6 > 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 > 16.5 23.4 1.5 > 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 > 14.5 25.9 2.5 > 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 > 14.2 29.6 3.1 > 6. 2001:1978:203::45 0.0% 33 30.7 30.7 > 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the > problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Thu Dec 20 19:03:47 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 20 Dec 2018 14:03:47 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Message-ID: <1545332631_168109@surgemail.mnsi.net> Cogent != Cogeco Cogent - US Backbone Provider Cogeco - Canadian Cable TV & Internet provider At 01:00 PM 20/12/2018, David Hubbard wrote: >Google and HE don't have IPv6 connectivity with >Cogent because Cogent's CEO has been in some >decades long pissing match with them about free >settlement free peering. That's the unfortunate >reality of the situation; nothing you can do >other than have another route to HE/Google IPv6 >targets. We have some Cogent circuits that are >effectively useless for IPv6 as our customer >base has heavy traffic to/from Google cloud >services, so they can't be used for a backup / >DR scenario; their only real value is an optimal >route to other Cogent customers. I'm slowly >replacing our Cogent circuits when feasible >because the reality is our customers reaching >Google over IPv6 via all our upstreams is more >valuable than Cogent's cost savings. > > > >On 12/20/18, 12:37 PM, "NANOG on behalf of >Brian J. Murrell" behalf of brian at interlinx.bc.ca> wrote: > > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. > 2001:1970:5261:d600::1 0.0% > 7 2.1 1.3 0.7 2.9 0.8 > 2. > 2001:1970:4000:82::1 0.0% > 7 10.0 14.0 8.3 37.9 10.6 > 3. > 2001:1970:0:1a6::1 16.7% > 7 13.2 215.5 10.8 1031. 455.9 > 4. > he.ip6.torontointernetxchange.net 0.0% > 7 12.3 12.9 11.2 15.3 1.6 > 5. > 100ge9-2.core2.chi1.he.net 0.0% > 7 23.6 23.0 21.3 27.6 2.2 > 6. > 100ge15-2.core1.chi1.he.net 0.0% > 7 21.7 22.5 21.6 24.9 1.2 > 7. > 100ge12-1.core1.atl1.he.net 0.0% > 7 34.2 35.1 34.1 36.1 0.7 > 8. > 100ge5-1.core1.tpa1.he.net 0.0% > 7 49.1 46.6 44.8 49.1 1.5 > 9. > 100ge12-1.core1.mia1.he.net 0.0% > 7 51.6 54.5 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. > 2001:1970:5261:d600::1 0.0% > 33 0.6 0.7 0.6 1.0 0.1 > 2. > 2001:1970:4000:82::1 0.0% > 33 8.2 10.8 8.1 40.5 5.6 > 3. > 2001:1970:0:1a7::1 15.2% > 33 23.4 20.1 16.5 23.4 1.5 > 4. > 2001:1970:0:61::1 33.3% > 33 16.8 17.6 14.5 25.9 2.5 > 5. > 2001:1978:1300::1 0.0% > 33 16.0 17.5 14.2 29.6 3.1 > 6. > 2001:1978:203::45 0.0% > 33 30.7 30.7 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From dhubbard at dino.hostasaurus.com Thu Dec 20 19:04:58 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 20 Dec 2018 19:04:58 +0000 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <1545332631_168109@surgemail.mnsi.net> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> <1545332631_168109@surgemail.mnsi.net> Message-ID: <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> Yikes, they should change their name rather than be mistaken for Cogent lol On 12/20/18, 2:04 PM, "Clayton Zekelman" wrote: Cogent != Cogeco Cogent - US Backbone Provider Cogeco - Canadian Cable TV & Internet provider At 01:00 PM 20/12/2018, David Hubbard wrote: >Google and HE don't have IPv6 connectivity with >Cogent because Cogent's CEO has been in some >decades long pissing match with them about free >settlement free peering. That's the unfortunate >reality of the situation; nothing you can do >other than have another route to HE/Google IPv6 >targets. We have some Cogent circuits that are >effectively useless for IPv6 as our customer >base has heavy traffic to/from Google cloud >services, so they can't be used for a backup / >DR scenario; their only real value is an optimal >route to other Cogent customers. I'm slowly >replacing our Cogent circuits when feasible >because the reality is our customers reaching >Google over IPv6 via all our upstreams is more >valuable than Cogent's cost savings. > > > >On 12/20/18, 12:37 PM, "NANOG on behalf of >Brian J. Murrell" behalf of brian at interlinx.bc.ca> wrote: > > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. > 2001:1970:5261:d600::1 0.0% > 7 2.1 1.3 0.7 2.9 0.8 > 2. > 2001:1970:4000:82::1 0.0% > 7 10.0 14.0 8.3 37.9 10.6 > 3. > 2001:1970:0:1a6::1 16.7% > 7 13.2 215.5 10.8 1031. 455.9 > 4. > he.ip6.torontointernetxchange.net 0.0% > 7 12.3 12.9 11.2 15.3 1.6 > 5. > 100ge9-2.core2.chi1.he.net 0.0% > 7 23.6 23.0 21.3 27.6 2.2 > 6. > 100ge15-2.core1.chi1.he.net 0.0% > 7 21.7 22.5 21.6 24.9 1.2 > 7. > 100ge12-1.core1.atl1.he.net 0.0% > 7 34.2 35.1 34.1 36.1 0.7 > 8. > 100ge5-1.core1.tpa1.he.net 0.0% > 7 49.1 46.6 44.8 49.1 1.5 > 9. > 100ge12-1.core1.mia1.he.net 0.0% > 7 51.6 54.5 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. > 2001:1970:5261:d600::1 0.0% > 33 0.6 0.7 0.6 1.0 0.1 > 2. > 2001:1970:4000:82::1 0.0% > 33 8.2 10.8 8.1 40.5 5.6 > 3. > 2001:1970:0:1a7::1 15.2% > 33 23.4 20.1 16.5 23.4 1.5 > 4. > 2001:1970:0:61::1 33.3% > 33 16.8 17.6 14.5 25.9 2.5 > 5. > 2001:1978:1300::1 0.0% > 33 16.0 17.5 14.2 29.6 3.1 > 6. > 2001:1978:203::45 0.0% > 33 30.7 30.7 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From omer at chronos.com.tr Thu Dec 20 19:10:25 2018 From: omer at chronos.com.tr (=?UTF-8?B?TS4gw5ZtZXIgR8OWTEdFTMSw?=) Date: Thu, 20 Dec 2018 22:10:25 +0300 Subject: Auto-reply from Yahoo... In-Reply-To: <61cb5d7f-5c52-4a67-2093-6551bee0ccc7@spamtrap.tnetconsulting.net> Message-ID: <68431d10-03a9-48c7-8ef6-47757cc31163@email.android.com> An HTML attachment was scrubbed... URL: From job at instituut.net Thu Dec 20 19:11:05 2018 From: job at instituut.net (Job Snijders) Date: Thu, 20 Dec 2018 20:11:05 +0100 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Message-ID: At this moment it appears there are multiple rifts in the IPv6 default-free zone (that don’t exist in the IPv4 realm), between various organizations. Focusing on one particular partitioning may not help address the other issues. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Dec 20 19:20:10 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 20 Dec 2018 12:20:10 -0700 Subject: Auto-reply from Yahoo... In-Reply-To: <68431d10-03a9-48c7-8ef6-47757cc31163@email.android.com> References: <68431d10-03a9-48c7-8ef6-47757cc31163@email.android.com> Message-ID: <0dbb34c5-5b24-8934-342a-77658b0f52e8@spamtrap.tnetconsulting.net> On 12/20/2018 12:10 PM, M. Ömer GÖLGELİ wrote: > Here, I have added the admins to this mail to let them know what bugs us... Okay.... (See below.) > Maybe there should be a reporting address listed on NANOG page just for > this purposes. I would have thought (read: expected) that the nanog-owner at nanog.com email address would have gone to the list owners. I agree that there should be an easy way to contact list owners. Hence the standard convention of $LIST-owner address / alias. I don't know. Maybe something got broken during an upgrade. I'll stop harping. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From mureninc at gmail.com Thu Dec 20 19:36:22 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 20 Dec 2018 13:36:22 -0600 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> <1545332631_168109@surgemail.mnsi.net> <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> Message-ID: They should probably just rebrand to CoGeCo, but that does look kinda silly, so, they probably won't. https://en.wikipedia.org/wiki/Cogeco > Cogeco is an acronym for Compagnie Générale de Communication ("General Communications Company"). Both Cogent Communications and Cogeco are in pretty different market segments (for anyone in the know), so, they each probably don't really care about the confusion in their respective target markets. C. On Thu, 20 Dec 2018 at 13:13, David Hubbard wrote: > > Yikes, they should change their name rather than be mistaken for Cogent lol > > On 12/20/18, 2:04 PM, "Clayton Zekelman" wrote: > > > Cogent != Cogeco > > Cogent - US Backbone Provider > Cogeco - Canadian Cable TV & Internet provider > > At 01:00 PM 20/12/2018, David Hubbard wrote: > >Google and HE don't have IPv6 connectivity with > >Cogent because Cogent's CEO has been in some > >decades long pissing match with them about free > >settlement free peering. That's the unfortunate > >reality of the situation; nothing you can do > >other than have another route to HE/Google IPv6 > >targets. We have some Cogent circuits that are > >effectively useless for IPv6 as our customer > >base has heavy traffic to/from Google cloud > >services, so they can't be used for a backup / > >DR scenario; their only real value is an optimal > >route to other Cogent customers. I'm slowly > >replacing our Cogent circuits when feasible > >because the reality is our customers reaching > >Google over IPv6 via all our upstreams is more > >valuable than Cogent's cost savings. > > > > > > > >On 12/20/18, 12:37 PM, "NANOG on behalf of > >Brian J. Murrell" >behalf of brian at interlinx.bc.ca> wrote: > > > > I've been trying to figure out why I can reach an IPv6 address at > > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > > Internet connections as well as via an HE IPv6 tunnel but not the other > > of my two ISP connections > > > > At one point in time a traceroute was dying inside of he.net: > > > > Host > > Loss% Snt Last Avg Best Wrst StDev > > 1. > > 2001:1970:5261:d600::1 0.0% > > 7 2.1 1.3 0.7 2.9 0.8 > > 2. > > 2001:1970:4000:82::1 0.0% > > 7 10.0 14.0 8.3 37.9 10.6 > > 3. > > 2001:1970:0:1a6::1 16.7% > > 7 13.2 215.5 10.8 1031. 455.9 > > 4. > > he.ip6.torontointernetxchange.net 0.0% > > 7 12.3 12.9 11.2 15.3 1.6 > > 5. > > 100ge9-2.core2.chi1.he.net 0.0% > > 7 23.6 23.0 21.3 27.6 2.2 > > 6. > > 100ge15-2.core1.chi1.he.net 0.0% > > 7 21.7 22.5 21.6 24.9 1.2 > > 7. > > 100ge12-1.core1.atl1.he.net 0.0% > > 7 34.2 35.1 34.1 36.1 0.7 > > 8. > > 100ge5-1.core1.tpa1.he.net 0.0% > > 7 49.1 46.6 44.8 49.1 1.5 > > 9. > > 100ge12-1.core1.mia1.he.net 0.0% > > 7 51.6 54.5 50.5 73.3 8.3 > > 10. ??? > > > > But I think it getting that far time was an anomaly and frankly it > > usually dies even before exiting my ISP's (Cogeco) network like this: > > > > Host > > Loss% Snt Last Avg Best Wrst StDev > > 1. > > 2001:1970:5261:d600::1 0.0% > > 33 0.6 0.7 0.6 1.0 0.1 > > 2. > > 2001:1970:4000:82::1 0.0% > > 33 8.2 10.8 8.1 40.5 5.6 > > 3. > > 2001:1970:0:1a7::1 15.2% > > 33 23.4 20.1 16.5 23.4 1.5 > > 4. > > 2001:1970:0:61::1 33.3% > > 33 16.8 17.6 14.5 25.9 2.5 > > 5. > > 2001:1978:1300::1 0.0% > > 33 16.0 17.5 14.2 29.6 3.1 > > 6. > > 2001:1978:203::45 0.0% > > 33 30.7 30.7 28.4 35.1 1.7 > > 7. ??? > > > > When I asked the kind folks at he.net for some advice about the problem > > (i.e. in the first traceroute above) their diagnosis was that > > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > > IPv6 address. > > > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > > simply cannot reach the people who know more than how to reset your > > router and configure your e-mail. > > > > I wonder how I could go any further with this to confirm the diagnosis > > that Facebook doesn't have a route to the Cogeco network's IPv6 address > > space given that I only have access to my end of the path. > > > > Cheers, > > b. > > > > > > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > > > From amitchell at isipp.com Thu Dec 20 19:36:51 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 20 Dec 2018 12:36:51 -0700 Subject: [Request] Contact information for CenturyLink network operations In-Reply-To: References: Message-ID: >> Hi all, >> >> Got a network issue with a DoS'er originating from Comcast into >> CenturyLink but unable to find the right people to work on this from >> the CenturyLink side. Looking for a contact to reach me off-list to >> help solve this or insert a block in a upstream router. > > Don, please email me offlist (amitchell at isipp.com); CenturyLink is now part of Level3...we can get you to the right person. Oops, as was just pointed out to me offlist, I reversed that (too much blood in my caffeine stream)...I should have said that CenturyLink *borged* Level3. Anne From nanog at ics-il.net Thu Dec 20 19:31:33 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 20 Dec 2018 13:31:33 -0600 (CST) Subject: Non-profit IX vs. neutral for-profit IX Message-ID: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> What are your thoughts on why a network would join a non-profit IX, but not a neutral, for-profit IX? Let's assume that traffic levels are similar. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Thu Dec 20 19:48:12 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 20 Dec 2018 21:48:12 +0200 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: Well known problem. You can use our tunnel broker connection (tb.netassist.ua) as a workaround. 17.12.18 22:01, Brian J. Murrell пише: > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 > 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 > 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 > 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 > 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 > 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 > 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 > 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 > 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 > 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 > 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 > 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 > 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 > 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. > From aaron at wholesaleinternet.net Thu Dec 20 19:51:43 2018 From: aaron at wholesaleinternet.net (Aaron) Date: Thu, 20 Dec 2018 13:51:43 -0600 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> Message-ID: <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> Probably price.  Also perception of value.  If you're a for profit enterprise then they're paying for interconnection plus your bump.  If you're non-profit the perception is that there is a larger value because there's no bump.  Whether that's true or not, who knows but that's the perception I've heard. On 12/20/2018 1:31 PM, Mike Hammett wrote: > What are your thoughts on why a network would join a non-profit IX, > but not a neutral, for-profit IX? Let's assume that traffic levels are > similar. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From mureninc at gmail.com Thu Dec 20 19:53:03 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 20 Dec 2018 13:53:03 -0600 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, 20 Dec 2018 at 13:44, Mike Hammett wrote: > What are your thoughts on why a network would join a non-profit IX, but not a neutral, for-profit IX? Let's assume that traffic levels are similar. But are traffic levels actually similar? Most areas have one or the other dominating the field, so, which one you join usually depends on other (more pressing) factors. C. From bruns at 2mbit.com Thu Dec 20 19:58:23 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 20 Dec 2018 12:58:23 -0700 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> Message-ID: <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> On 12/20/2018 12:51 PM, Aaron wrote: > Probably price.  Also perception of value.  If you're a for profit > enterprise then they're paying for interconnection plus your bump.  If > you're non-profit the perception is that there is a larger value because > there's no bump.  Whether that's true or not, who knows but that's the > perception I've heard. Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From brian at interlinx.bc.ca Thu Dec 20 20:13:09 2018 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 20 Dec 2018 15:13:09 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: On Thu, 2018-12-20 at 21:48 +0200, Max Tulyev wrote: > Well known problem. Interesting. As in a general problem across the Internet or a well known problem with Cogeco specifically? > You can use our tunnel broker connection (tb.netassist.ua) as a > workaround. Thanks. But I actually already have a tunnel as well as a(nother) native IPv6 ISP (yes, I have two consumer ISP connections) which routes to Facebook properly. The problem is that for the clients behind this router receiving RAs for all three upstream connections and plumbing IPv6 addresses on each of those networks, I know of no way to prevent them from choosing their Cogeco IP address among the 3 and thus trying to use the Cogeco route. I can (and have) put a rule into that router to refuse connections to Facebook when using the Cogeco source address which sends TCP clients a TCP reset with the hope that (good at least) clients/IPv6 stacks will try a different source address but the results on that seem spotty at best. 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 omer at chronos.com.tr Thu Dec 20 20:40:07 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Thu, 20 Dec 2018 23:40:07 +0300 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: References: Message-ID: Hi Vasileios, Congratulations of building this. Wanted to try it out as a VM but frankly... The "docker" part put me off... M. --- On 2018-12-20 20:23, Vasileios Kotronis wrote: > Dear operators, > > FORTH's INSPIRE group and CAIDA are delighted to announce the public > release of the ARTEMIS BGP prefix hijacking detection tool, available > as open-source software at > https://github.com/FORTH-ICS-INSPIRE/artemis > > ARTEMIS is designed to be operated by an AS in order to monitor BGP > for potential hijacking attempts against its own prefixes. The system > detects such attacks within seconds, enabling immediate mitigation. > The current release has been tested at a major greek ISP, a dual-homed > edge academic network, and a major US R&E backbone network. > > We would be happy if you'd give it a try and provide feedback. Feel > free to make pull requests on GitHub and help us make this a true > community project. > > ARTEMIS is funded by European Research Council (ERC) grant agreement > no. 338402 (NetVolution Project), the RIPE NCC Community Projects > 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and > CNS-1423659 and US DHS S&T contract HHSP233201600012C. > > Best regards, > Vasileios From beecher at beecher.cc Thu Dec 20 20:48:21 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 20 Dec 2018 15:48:21 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: <9b869f17-fa35-5c80-e1a3-33cbaa11babf@gmail.com> References: <26762343-7e5e-8225-1ce2-d5336f4f9703@spamtrap.tnetconsulting.net> <9b869f17-fa35-5c80-e1a3-33cbaa11babf@gmail.com> Message-ID: To be clear, I got this reported to the team internally that handles the auto responder stuff. I’m a network guy, not a mail guy. If the list admins can unsubscribe the address it’s probably going to be faster, especially around the holidays here. On Thu, Dec 20, 2018 at 13:09 William Allen Simpson < william.allen.simpson at gmail.com> wrote: > On 12/20/18 11:46 AM, Grant Taylor via NANOG wrote: > > On 12/14/2018 11:48 AM, Grant Taylor wrote: > >> I've been seeing them for three or four days now. > > > > BUMP > > > > This has been going on for more than a week now. I'm quite confident > that there have been hundreds of auto-replies. (I'm seeing 285 incoming > message from the NANOG mailing list since I became aware of the auto-reply.) > > > > I'm really surprised that there has not been any reply or action by the > NANOG list owner(s). I would have hoped, if not expected, better, or any, > response by now. > > > Well, somebody who seemed to be from Yahoo claimed they were fixing > their auto-responder. Obviously, that hasn't been deployed yet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Thu Dec 20 20:49:48 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2018 22:49:48 +0200 Subject: Stupid Question maybe? In-Reply-To: <5b912bde-6e5f-8060-8128-880b410f325d@spamtrap.tnetconsulting.net> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <5b912bde-6e5f-8060-8128-880b410f325d@spamtrap.tnetconsulting.net> Message-ID: On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG wrote: > Do you have /24 cover prefixes advertised to the Internet? Yes, just it drops at the peering edge as more specific is not found. > $EMPLOYER requires globally routable access to the link net IP on our > equipment for specific configurations. Sorry, I can't go into details. > > I'm trying to ascertain if the configuration (as I understand it) that > advocating for would work for us or not. Would require details, but I believe the host/32 pointing to interface (no next-hop IP) ought to do the trick. -- ++ytti From Jacques.Latour at cira.ca Thu Dec 20 21:01:14 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Thu, 20 Dec 2018 21:01:14 +0000 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Message-ID: Job, What other partitioning like this exists? Jack From: NANOG On Behalf Of Job Snijders Sent: December 20, 2018 2:11 PM To: Matthew Kaufman Cc: nanog at nanog.org Subject: Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? At this moment it appears there are multiple rifts in the IPv6 default-free zone (that don’t exist in the IPv4 realm), between various organizations. Focusing on one particular partitioning may not help address the other issues. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From robt at cymru.com Thu Dec 20 21:11:49 2018 From: robt at cymru.com (Rabbi Rob Thomas) Date: Thu, 20 Dec 2018 16:11:49 -0500 Subject: historical Bogon lists In-Reply-To: <8aebaa01-78bb-a385-6b45-7c8c22e405b5@spamtrap.tnetconsulting.net> References: <49157730-644a-3f65-2164-20cfa6da9a4b@inet.tu-berlin.de> <54b44195-fda6-9b43-fabc-27c8e3c2dc5c@spamtrap.tnetconsulting.net> <9ac9ed95-0ae3-5b38-9d8b-e2446b96bf53@cymru.com> <4b02b409-ca3c-7102-9589-d48eb2e8596b@cymru.com> <8aebaa01-78bb-a385-6b45-7c8c22e405b5@spamtrap.tnetconsulting.net> Message-ID: <5b3e11e8-4daf-c9cf-7f11-9f0ee44095b8@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear team, The fine folks at CAIDA have maintained a repository of the bogon lists we've produced, going back to 18 SEP 2013. http://data.caida.org/datasets/bogon/ They are integrating the 2018 data provided by Alessandro Improta, and will have that in place after the new year. Will that work for folks, or would a git repository be useful in different ways? My thanks to Paul Hick, CAIDA, and Alessandro Improta for the assistance here! Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwcBZEACgkQQ+hhYvqF 8o0gRA/7BbZt05/FEMXyTXXDhjB5pbgZVX33EbP+s2M/8EwcriKhHg9vLTqiILS+ 3Gq+6N3GboarEqgDBNamEm150H34e536+7+jknAu229P0xe44Wku57WlYYA0GOn+ oCfn0tOjjJzIA4pzf4IXWt7n4I99Er6SD5+LhkSOqBQADqnELDRsb/43dhKtIZvL eCqkYvPBxHmuuOvrQfASBK9jRYqmuaDeMeemrgeKPsPC26gfG+hmNPWRH6nbZxof o3OTCE/XQABioHj6XXJwoUVMguYVFwi9XaKa1+wvc3JxbQL5WiS/LZATgnp0PSci EgklBefGWOyWK+TCWK4Uz72828+wfPdduQx3EHhtxcau+JlmwVaBXSyDxcWb1NpK dhYdz9y2xkNo/2Mu0A/mVdnn/cayHu1PpOyQIUxltx24xDGjOfmGWwTWaHrYmmX4 LTsy5L0HMJInr0SsPpQVyiysJQlBDB9BWMk/Yi18HZWPMor0q8lvJXu7rroU1rZL qD86py+CaiJ/T9fhuIPWrQN4mjFhDvZg/jLbb5z4FVwLxmKQP/QuHVwCPhpLNOIe wVggDQ8XIAEA16NzvP5GOzTlsWekfrqAacHQ9k8z1zvfPShFvK8AlEW18+sQdskO BsQz+NR0sngTeZh/4re2SUdin2dQrTvcDyPjs+BFnwYGdXFAfrg= =MOKS -----END PGP SIGNATURE----- From rsk at gsp.org Thu Dec 20 21:14:04 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 20 Dec 2018 16:14:04 -0500 Subject: Auto-reply from Yahoo... In-Reply-To: <0dbb34c5-5b24-8934-342a-77658b0f52e8@spamtrap.tnetconsulting.net> References: <68431d10-03a9-48c7-8ef6-47757cc31163@email.android.com> <0dbb34c5-5b24-8934-342a-77658b0f52e8@spamtrap.tnetconsulting.net> Message-ID: <20181220211404.GA11188@gsp.org> On Thu, Dec 20, 2018 at 12:20:10PM -0700, Grant Taylor via NANOG wrote: > I would have thought (read: expected) that the nanog-owner at nanog.com email > address would have gone to the list owners. It should. If it doesn't, then the mail system is broken. Note that the -owner address is supported by Mailman (which runs these lists) and that it will generate an alias for that -- among others -- when the list is created. > I agree that there should be an easy way to contact list owners. Hence the > standard convention of $LIST-owner address / alias. Yes. Y'know, on my never-ending todo list there's an item to write an update to RFC 2142 with that in it. And possibly "listmaster" as the role address for the keeper-of-all-mailing-lists. ---rsk From mureninc at gmail.com Thu Dec 20 23:01:11 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 20 Dec 2018 17:01:11 -0600 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> Message-ID: The most famous lack of IPv6 connectivity is between AS6939 (Hurricane Electric LLC) and AS174 (Cogent Communication), not to be confused with AS7992 (Cogeco Cable), which actually does peer with both cogentco.com and he.net, including on IPv6. The HE/Cogent issue is so widely known that, apparently, nearly everyone in this thread is misattributing the well-known issue as the reason for the problems described by the OP, but they're very obviously not related, apart from the similarity in the brand names. C. On Thu, 20 Dec 2018 at 15:02, Jacques Latour wrote: > > Job, > > What other partitioning like this exists? > > Jack > > > > > > From: NANOG On Behalf Of Job Snijders > Sent: December 20, 2018 2:11 PM > To: Matthew Kaufman > Cc: nanog at nanog.org > Subject: Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? > > > > At this moment it appears there are multiple rifts in the IPv6 default-free zone (that don’t exist in the IPv4 realm), between various organizations. Focusing on one particular partitioning may not help address the other issues. > > > > Kind regards, > > > > Job From me at anuragbhatia.com Thu Dec 20 23:09:08 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 21 Dec 2018 04:39:08 +0530 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: Hi Brain Let's chat offlist to find why this is happening. The behaviour looks unusual and needs more troubleshooting. Thanks Anurag Bhatia (Hurricane Electric) On Thu, Dec 20, 2018 at 11:06 PM Brian J. Murrell wrote: > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host Loss% Snt Last Avg Best > Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 > 2.9 0.8 > 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 > 37.9 10.6 > 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 > 1031. 455.9 > 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 > 11.2 15.3 1.6 > 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 > 21.3 27.6 2.2 > 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 > 21.6 24.9 1.2 > 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 > 34.1 36.1 0.7 > 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 > 44.8 49.1 1.5 > 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 > 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host Loss% Snt Last Avg > Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 > 0.6 1.0 0.1 > 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 > 8.1 40.5 5.6 > 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 > 16.5 23.4 1.5 > 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 > 14.5 25.9 2.5 > 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 > 14.2 29.6 3.1 > 6. 2001:1978:203::45 0.0% 33 30.7 30.7 > 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. > > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Thu Dec 20 23:28:55 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 20 Dec 2018 17:28:55 -0600 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: Hi Brian, With all the CoGeCo 🇨🇦 vs. CogentCo 🇺🇸 confusion, I don't think anyone asked the obvious question yet… But what's exactly at 2a03:2880:f012:3:face:b00c:0:1? I've tried reaching it on port http, and it doesn't answer: % curl -6 -v --head --resolve "www.facebook.com:80:2a03:2880:f012:3:face:b00c:0:1" www.facebook.com * Added www.facebook.com:80:2a03:2880:f012:3:face:b00c:0:1 to DNS cache * About to connect() to www.facebook.com port 80 (#0) * Trying 2a03:2880:f012:3:face:b00c:0:1... * Connection refused * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host % Meanwhile, regular IPv6 connectivity to Facebook works just fine, over HE.net, no less. Cheers, Constantine. http://cm.su/ On Thu, 20 Dec 2018 at 11:36, Brian J. Murrell wrote: > > I've been trying to figure out why I can reach an IPv6 address at > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two > Internet connections as well as via an HE IPv6 tunnel but not the other > of my two ISP connections > > At one point in time a traceroute was dying inside of he.net: > > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 > 2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 > 3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 > 4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 > 5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 > 6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 > 7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 > 8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 > 9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 > 10. ??? > > But I think it getting that far time was an anomaly and frankly it > usually dies even before exiting my ISP's (Cogeco) network like this: > > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 > 2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 > 3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 > 4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 > 5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 > 6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 > 7. ??? > > When I asked the kind folks at he.net for some advice about the problem > (i.e. in the first traceroute above) their diagnosis was that > Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco > IPv6 address. > > Trying to talk to my ISP (again, Cogeco) has been impossible. One > simply cannot reach the people who know more than how to reset your > router and configure your e-mail. > > I wonder how I could go any further with this to confirm the diagnosis > that Facebook doesn't have a route to the Cogeco network's IPv6 address > space given that I only have access to my end of the path. > > Cheers, > b. From raphael.timothy at gmail.com Fri Dec 21 02:39:42 2018 From: raphael.timothy at gmail.com (Tim Raphael) Date: Fri, 21 Dec 2018 10:39:42 +0800 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> Message-ID: The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral” and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability. - Tim > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From chk at pobox.com Fri Dec 21 02:44:05 2018 From: chk at pobox.com (Harald Koch) Date: Thu, 20 Dec 2018 21:44:05 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> <1545332631_168109@surgemail.mnsi.net> <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> Message-ID: <1545360245.2936284.1615101640.793A7DBC@webmail.messagingengine.com> On Thu, Dec 20, 2018, at 14:04, David Hubbard wrote: > Yikes, they should change their name rather than be mistaken for Cogent lol Cogent started business in 1999 and Cogeco has been around since the 1950s. Who should change their name again? (To OP: I believe that every last-mile provider in Canda is still offering IPv6 as a best-effort, unsupported service. As a former Canadian networking guy, this ... angers me. Good luck ...) -- Harald Koch chk at pobox.com From brian at interlinx.bc.ca Fri Dec 21 03:57:28 2018 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 20 Dec 2018 22:57:28 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: <1545360245.2936284.1615101640.793A7DBC@webmail.messagingengine.com> References: <33F732E7-CEB4-456C-B719-2151098D4118@dino.hostasaurus.com> <1545332631_168109@surgemail.mnsi.net> <10A56D7E-328F-481F-930F-3A8D783BE4EF@dino.hostasaurus.com> <1545360245.2936284.1615101640.793A7DBC@webmail.messagingengine.com> Message-ID: On Thu, 2018-12-20 at 21:44 -0500, Harald Koch wrote: > > To OP: I believe that every last-mile provider in Canda is still > offering IPv6 as a best-effort, unsupported service. Yeah. I'm aware of this. But I want to give them the benefit of the doubt that this problem is simply ignorance and something they'd like to fix rather than any of the more depressing alternatives. 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 brian at interlinx.bc.ca Fri Dec 21 04:11:31 2018 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 20 Dec 2018 23:11:31 -0500 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: On Thu, 2018-12-20 at 17:28 -0600, Constantine A. Murenin wrote: > Hi Brian, Hi, > But what's exactly at 2a03:2880:f012:3:face:b00c:0:1? It's one of the endpoints involved in Facebook's Messenger service. IIRC it's "graph.facebook.com", although I note that that address is currently answering as: graph.facebook.com. 2068 IN CNAME api.facebook.com. api.facebook.com. 2068 IN CNAME star.c10r.facebook.com. star.c10r.facebook.com. 25 IN AAAA 2a03:2880:f00e:a:face:b00c:0:2 To be fair though, that one could just be what a load-balancing name service is responding at the moment. Notice that the two addresses are only off by one. But even more interesting is that it's now working: My traceroute [v0.92] pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 2018-12-20T23:07:14-0500 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 94 0.6 0.7 0.4 3.8 0.3 2. 2001:1970:4000:82::1 0.0% 94 9.0 20.2 7.3 889.2 91.0 3. 2001:1970:0:1a7::1 39.4% 94 19.8 19.5 17.9 26.3 1.8 4. 2001:1970:0:61::1 45.2% 93 18.1 16.5 14.3 22.5 1.9 5. ae7.pr03.yyz1.tfbnw.net 0.0% 93 19.6 19.4 14.9 76.8 9.4 6. po103.psw04.yyz1.tfbnw.net 0.0% 93 14.5 15.8 13.9 24.0 1.5 7. po4.msw1ab.01.yyz1.tfbnw.net 0.0% 93 15.3 15.7 14.2 24.0 1.3 8. 2a03:2880:f00e:a:face:b00c:0:1 0.0% 93 19.2 15.5 13.7 22.5 1.7 And even just a few minutes ago it was not as I was testing it for another (off-list) query: My traceroute [v0.92] pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 2018-12-20T22:47:51-0500 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2001:1970:5261:d600::1 0.0% 112 0.6 0.7 0.5 5.1 0.4 2. 2001:1970:4000:82::1 0.0% 112 9.2 15.8 7.3 374.4 36.2 3. 2001:1970:0:1a7::1 17.0% 112 18.3 19.1 17.6 21.9 0.8 4. 2001:1970:0:61::1 33.0% 112 15.9 16.0 14.8 27.9 1.8 5. 2001:1978:1300::1 0.0% 112 15.5 17.0 14.1 49.8 4.4 6. 2001:1978:203::45 0.0% 112 29.5 29.8 28.2 46.8 2.1 7. ??? Perhaps the bit of cage rattling that I have done here has knocked something loose. :-) 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 mureninc at gmail.com Fri Dec 21 05:01:14 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 20 Dec 2018 23:01:14 -0600 Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? In-Reply-To: References: Message-ID: On Thu, 20 Dec 2018 at 22:12, Brian J. Murrell wrote: > > On Thu, 2018-12-20 at 17:28 -0600, Constantine A. Murenin wrote: > > Hi Brian, > > Hi, > > > But what's exactly at 2a03:2880:f012:3:face:b00c:0:1? > > It's one of the endpoints involved in Facebook's Messenger service. > IIRC it's "graph.facebook.com", although I note that that address is > currently answering as: > > graph.facebook.com. 2068 IN CNAME api.facebook.com. > api.facebook.com. 2068 IN CNAME star.c10r.facebook.com. > star.c10r.facebook.com. 25 IN AAAA 2a03:2880:f00e:a:face:b00c:0:2 > > To be fair though, that one could just be what a load-balancing name > service is responding at the moment. Notice that the two addresses are > only off by one. > > But even more interesting is that it's now working: > > My traceroute [v0.92] > pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 2018-12-20T23:07:14-0500 > Keys: Help Display mode Restart statistics Order of fields quit > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 94 0.6 0.7 0.4 3.8 0.3 > 2. 2001:1970:4000:82::1 0.0% 94 9.0 20.2 7.3 889.2 91.0 > 3. 2001:1970:0:1a7::1 39.4% 94 19.8 19.5 17.9 26.3 1.8 > 4. 2001:1970:0:61::1 45.2% 93 18.1 16.5 14.3 22.5 1.9 > 5. ae7.pr03.yyz1.tfbnw.net 0.0% 93 19.6 19.4 14.9 76.8 9.4 > 6. po103.psw04.yyz1.tfbnw.net 0.0% 93 14.5 15.8 13.9 24.0 1.5 > 7. po4.msw1ab.01.yyz1.tfbnw.net 0.0% 93 15.3 15.7 14.2 24.0 1.3 > 8. 2a03:2880:f00e:a:face:b00c:0:1 0.0% 93 19.2 15.5 13.7 22.5 1.7 > > And even just a few minutes ago it was not as I was testing it for > another (off-list) query: > > My traceroute [v0.92] > pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 2018-12-20T22:47:51-0500 > Keys: Help Display mode Restart statistics Order of fields quit > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. 2001:1970:5261:d600::1 0.0% 112 0.6 0.7 0.5 5.1 0.4 > 2. 2001:1970:4000:82::1 0.0% 112 9.2 15.8 7.3 374.4 36.2 > 3. 2001:1970:0:1a7::1 17.0% 112 18.3 19.1 17.6 21.9 0.8 > 4. 2001:1970:0:61::1 33.0% 112 15.9 16.0 14.8 27.9 1.8 > 5. 2001:1978:1300::1 0.0% 112 15.5 17.0 14.1 49.8 4.4 > 6. 2001:1978:203::45 0.0% 112 29.5 29.8 28.2 46.8 2.1 > 7. ??? > > Perhaps the bit of cage rattling that I have done here has knocked > something loose. :-) > > Cheers, > b. I think TFBNW folks definitely read these lists, even if they never respond officially. Their whole network was apparently down via IPv6 for like at least a few days several years ago; they've then fixed it back in the day by simply removing the AAAA records. :-) https://puck.nether.net/pipermail/outages/2013-May/005570.html https://puck.nether.net/pipermail/outages/2013-May/005579.html It's kind of amazing that tech reporters never really pick up these stories, TBH. I guess these outages don't really sell, especially if noone but a few selected users can even detect it in the first place, even if they do last for days or even weeks/years for certain users in certain configurations. Cheers, Constantine. From christian at errxtx.net Fri Dec 21 13:41:23 2018 From: christian at errxtx.net (Christian Meutes) Date: Fri, 21 Dec 2018 14:41:23 +0100 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: Depending on your requirements and scale - but I read you want history - it's probably less a demand on CPU or network resources, but more on IOPS. If you cache all results before writing to disk, then it's not much of a problem, but by just going "let's use RRD/MRTG for this" your IOPS could become the first problem. So you might look into a proper timeseries backend or use a caching daemon for RRD. On Sat, Dec 15, 2018 at 4:48 PM Colton Conor wrote: > How much compute and network resources does it take for a NMS to: > > 1. ICMP ping a device every second > 2. Record these results. > 3. Report an alarm after so many seconds of missed pings. > > We are looking for a system to in near real-time monitor if an end > customers router is up or down. SNMP I assume would be too resource > intensive, so ICMP pings seem like the only logical solution. > > The question is once a second pings too polling on an NMS and a consumer > grade router? Does it take much network bandwidth and CPU resources from > both the NMS and CPE side? > > Lets say this is for a 1,000 customer ISP. > > > -- Christian Meutes e-mail/xmpp: christian at errxtx.net mobile: +49 176 32370305 PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 Toulouser Allee 21, 40211 Duesseldorf, Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Dec 21 14:03:28 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Dec 2018 08:03:28 -0600 (CST) Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> Message-ID: <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tim Raphael" To: "NANOG Mailing List" Sent: Thursday, December 20, 2018 8:39:42 PM Subject: Re: Non-profit IX vs. neutral for-profit IX The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral” and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability. - Tim > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > 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 clayton at MNSi.Net Fri Dec 21 14:14:04 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 21 Dec 2018 09:14:04 -0500 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck > References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> Message-ID: <1545401648_176804@surgemail.mnsi.net> TorIX is a great example of a not for profit IX that is very successful. https://www.torix.ca/ A very dedicated team of people provide an incredible level of service. Thave a very transparent process. Their pricing is listed up front on their website: https://www.torix.ca/peering/#pricing At 09:03 AM 21/12/2018, Mike Hammett wrote: >As far as neutral, I meant separate from the >datacenters in which they're housed. People in >NA seem to think there are only two kinds of >IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP > > >---------- >From: "Tim Raphael" >To: "NANOG Mailing List" >Sent: Thursday, December 20, 2018 8:39:42 PM >Subject: Re: Non-profit IX vs. neutral for-profit IX > >The other point to consider is that a NFP can >justify more locations and offer services (such >as extended reach) that don’t have the same >profit margins or ROI as for-profits. >This often leads to greater value to those with >smaller networks and fewer customers allowing >them to grow and expand without increased >aggregation or transit costs. This in-turn leads >to a richer array of providers and chips away at >the monopolies in niche markets. > >The NFP IXP I work for focuses on providing >value to the broader community and the Internet >as a whole - especially somewhere like Australia which has unique constraints. > >Additionally, “Neutral” and For-Profit >doesn’t always compute in my mind, there will >always be commercial alliances that lead to not-total neutrality. >When a NFP is owned by it’s members there has >to be 100% transparency in organisational >decisions around member funds and resources >which ensures accountability reliability. > >- Tim > > > > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: > > > > On 12/20/2018 12:51 PM, Aaron wrote: > >> Probably price. Also perception of > value. If you're a for profit enterprise then > they're paying for interconnection plus your > bump. If you're non-profit the perception is > that there is a larger value because there's no > bump. Whether that's true or not, who knows > but that's the perception I've heard. > > > > Depending on the size of the non-profit, I'd > almost compare it to how the hospitals are here in Boise. > > > > The non-profits are oversized, monopolistic, > price gouging, etc. Their care can be pretty > meh, esp since they bought up all the little > independent clinics (yay, ER pricing for a basic family clinic visit). > > > > The for-profit smaller clinics and hospitals > run a pretty tight ship, better value for their > money, service is very good, and compete with > one another for who has the best service. > > > > People think they are getting 'better' > because they are going to a place that is > supposed to be run to benefit people over > profit, but alas, you'd be very very wrong. > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Fri Dec 21 14:19:43 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 21 Dec 2018 08:19:43 -0600 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <1545401648_176804@surgemail.mnsi.net> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> Message-ID: Torix and Six are great examples. If you want to be for profit, make sure to publish port pricing and keep it fair. Transit is cheap and good quality On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman wrote: > > TorIX is a great example of a not for profit IX that is very successful. > > https://www.torix.ca/ > > A very dedicated team of people provide an incredible level of service. > > Thave a very transparent process. Their pricing is listed up front on > their website: > > https://www.torix.ca/peering/#pricing > > > > At 09:03 AM 21/12/2018, Mike Hammett wrote: > > As far as neutral, I meant separate from the datacenters in which they're > housed. People in NA seem to think there are only two kinds of IXes, > Equinix, DRT, Coresite types and NWAX, SIX, MICE types. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------ > *From: *"Tim Raphael" > *To: *"NANOG Mailing List" > *Sent: *Thursday, December 20, 2018 8:39:42 PM > *Subject: *Re: Non-profit IX vs. neutral for-profit IX > > The other point to consider is that a NFP can justify more locations and > offer services (such as extended reach) that don’t have the same profit > margins or ROI as for-profits. > This often leads to greater value to those with smaller networks and fewer > customers allowing them to grow and expand without increased aggregation or > transit costs. This in-turn leads to a richer array of providers and chips > away at the monopolies in niche markets. > > The NFP IXP I work for focuses on providing value to the broader community > and the Internet as a whole - especially somewhere like Australia which has > unique constraints. > > Additionally, “Neutral†and For-Profit doesn’t always compute in my > mind, there will always be commercial alliances that lead to not-total > neutrality. > When a NFP is owned by it’s members there has to be 100% transparency in > organisational decisions around member funds and resources which ensures > accountability reliability. > > > > - Tim > > > > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: > > > > On 12/20/2018 12:51 PM, Aaron wrote: > >> Probably price. Also perception of value. If you're a for profit > enterprise then they're paying for interconnection plus your bump. If > you're non-profit the perception is that there is a larger value because > there's no bump. Whether that's true or not, who knows but that's the > perception I've heard. > > > > Depending on the size of the non-profit, I'd almost compare it to how > the hospitals are here in Boise. > > > > The non-profits are oversized, monopolistic, price gouging, etc. Their > care can be pretty meh, esp since they bought up all the little independent > clinics (yay, ER pricing for a basic family clinic visit). > > > > The for-profit smaller clinics and hospitals run a pretty tight ship, > better value for their money, service is very good, and compete with one > another for who has the best service. > > > > People think they are getting 'better' because they are going to a place > that is supposed to be run to benefit people over profit, but alas, you'd > be very very wrong. > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > > Windsor, Ontario > > N8W 1H4 > > > tel. 519-985-8410 > fax. 519-985-8409 > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Fri Dec 21 14:20:31 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Fri, 21 Dec 2018 09:20:31 -0500 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <1545401648_176804@surgemail.mnsi.net> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> Message-ID: <058B6333-ED0A-43F5-8FFE-682B98684707@lixfeld.ca> New rates for 2019 just posted yesterday! Get yer ports while they’re hot! > On Dec 21, 2018, at 9:14 AM, Clayton Zekelman wrote: > > > TorIX is a great example of a not for profit IX that is very successful. > > https://www.torix.ca/ > > A very dedicated team of people provide an incredible level of service. > > Thave a very transparent process. Their pricing is listed up front on their website: > > https://www.torix.ca/peering/#pricing > > > > At 09:03 AM 21/12/2018, Mike Hammett wrote: >> As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> From: "Tim Raphael" >> To: "NANOG Mailing List" >> Sent: Thursday, December 20, 2018 8:39:42 PM >> Subject: Re: Non-profit IX vs. neutral for-profit IX >> >> The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. >> This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. >> >> The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. >> >> Additionally, “Neutral” and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. >> When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability. >> >> - Tim >> >> >> > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: >> > >> > On 12/20/2018 12:51 PM, Aaron wrote: >> >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. >> > >> > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. >> > >> > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). >> > >> > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. >> > >> > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. >> > -- >> > Brielle Bruns >> > The Summit Open Source Development Group >> > http://www.sosdg.org / http://www.ahbl.org >> > >> >> > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Dec 21 14:22:45 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Dec 2018 08:22:45 -0600 (CST) Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> Message-ID: <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> Not all transit is cheap and not all transit is good quality, regardless of what it costs. ;-) At our IX, we regularly see clients whose total network usage goes up once they're on the IX. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "Clayton Zekelman" Cc: "Mike Hammett" , "NANOG Mailing List" , "Tim Raphael" Sent: Friday, December 21, 2018 8:19:43 AM Subject: Re: Non-profit IX vs. neutral for-profit IX Torix and Six are great examples. If you want to be for profit, make sure to publish port pricing and keep it fair. Transit is cheap and good quality On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman < clayton at mnsi.net > wrote: TorIX is a great example of a not for profit IX that is very successful. https://www.torix.ca/ A very dedicated team of people provide an incredible level of service. Thave a very transparent process. Their pricing is listed up front on their website: https://www.torix.ca/peering/#pricing At 09:03 AM 21/12/2018, Mike Hammett wrote:
As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Tim Raphael" < raphael.timothy at gmail.com > To: "NANOG Mailing List" < nanog at nanog.org > Sent: Thursday, December 20, 2018 8:39:42 PM Subject: Re: Non-profit IX vs. neutral for-profit IX The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral†and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability.
- Tim > On 21 Dec 2018, at 3:58 am, Brielle Bruns < bruns at 2mbit.com > wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org >
-- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
-- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Fri Dec 21 14:34:32 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Fri, 21 Dec 2018 08:34:32 -0600 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <417f595f-83ba-dfc7-f590-c087db5565eb@wholesaleinternet.net> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> Message-ID: http://micemn.net/services.html MICE in Minneapolis is a great IX that we are on and their port fees are very reasonable. They used to be completely free up until this year. Even so, their fees are virtually nothing which encourages more operators to connect to it versus For-Profit IX's where sometimes the fees are almost as much as transit. For example Midwest-IX is $9,300 per year for a 10G port but MICE is only $250 per year. That's a HUGE difference and MICE also has way more peers and traffic overall due to how easy and cheap it is to join. On Fri, Dec 21, 2018 at 8:27 AM Mike Hammett wrote: > Not all transit is cheap and not all transit is good quality, regardless > of what it costs. ;-) > > At our IX, we regularly see clients whose total network usage goes up once > they're on the IX. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Mehmet Akcin" > *To: *"Clayton Zekelman" > *Cc: *"Mike Hammett" , "NANOG Mailing List" < > nanog at nanog.org>, "Tim Raphael" > *Sent: *Friday, December 21, 2018 8:19:43 AM > *Subject: *Re: Non-profit IX vs. neutral for-profit IX > > Torix and Six are great examples. > > If you want to be for profit, make sure to publish port pricing and keep > it fair. Transit is cheap and good quality > > On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman wrote: > >> >> TorIX is a great example of a not for profit IX that is very successful. >> >> https://www.torix.ca/ >> >> A very dedicated team of people provide an incredible level of service. >> >> Thave a very transparent process. Their pricing is listed up front on >> their website: >> >> https://www.torix.ca/peering/#pricing >> >> >> >> At 09:03 AM 21/12/2018, Mike Hammett wrote: >> >> As far as neutral, I meant separate from the datacenters in which they're >> housed. People in NA seem to think there are only two kinds of IXes, >> Equinix, DRT, Coresite types and NWAX, SIX, MICE types. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ------------------------------ >> *From: *"Tim Raphael" >> *To: *"NANOG Mailing List" >> *Sent: *Thursday, December 20, 2018 8:39:42 PM >> *Subject: *Re: Non-profit IX vs. neutral for-profit IX >> >> The other point to consider is that a NFP can justify more locations and >> offer services (such as extended reach) that don’t have the same profit >> margins or ROI as for-profits. >> This often leads to greater value to those with smaller networks and >> fewer customers allowing them to grow and expand without increased >> aggregation or transit costs. This in-turn leads to a richer array of >> providers and chips away at the monopolies in niche markets. >> >> The NFP IXP I work for focuses on providing value to the broader >> community and the Internet as a whole - especially somewhere like Australia >> which has unique constraints. >> >> Additionally, “Neutral†and For-Profit doesn’t always compute in my >> mind, there will always be commercial alliances that lead to not-total >> neutrality. >> When a NFP is owned by it’s members there has to be 100% transparency >> in organisational decisions around member funds and resources which ensures >> accountability reliability. >> >> >> >> - Tim >> >> >> > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: >> > >> > On 12/20/2018 12:51 PM, Aaron wrote: >> >> Probably price. Also perception of value. If you're a for profit >> enterprise then they're paying for interconnection plus your bump. If >> you're non-profit the perception is that there is a larger value because >> there's no bump. Whether that's true or not, who knows but that's the >> perception I've heard. >> > >> > Depending on the size of the non-profit, I'd almost compare it to how >> the hospitals are here in Boise. >> > >> > The non-profits are oversized, monopolistic, price gouging, etc. Their >> care can be pretty meh, esp since they bought up all the little independent >> clinics (yay, ER pricing for a basic family clinic visit). >> > >> > The for-profit smaller clinics and hospitals run a pretty tight ship, >> better value for their money, service is very good, and compete with one >> another for who has the best service. >> > >> > People think they are getting 'better' because they are going to a >> place that is supposed to be run to benefit people over profit, but alas, >> you'd be very very wrong. >> > -- >> > Brielle Bruns >> > The Summit Open Source Development Group >> > http://www.sosdg.org / http://www.ahbl.org >> > >> >> >> -- >> >> Clayton Zekelman >> Managed Network Systems Inc. (MNSi) >> 3363 Tecumseh Rd. E >> >> Windsor, Ontario >> >> N8W 1H4 >> >> >> tel. 519-985-8410 >> fax. 519-985-8409 >> > -- > Mehmet > +1-424-298-1903 > > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvicknair at reservetele.com Fri Dec 21 15:07:42 2018 From: kvicknair at reservetele.com (Kody Vicknair) Date: Fri, 21 Dec 2018 15:07:42 +0000 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: References: Message-ID: <3979AE529B56AB47942E2423B707F16E01E90B1D50@RTC-EXCH01.RESERVE.LDS> I'm curious, If the highjacked prefix is a /24 (subset of your much larger /22) and you can only tie the highjacked prefix, at that point how effective is the mitigation outside of a default bgp route selection process? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Vasileios Kotronis Sent: Thursday, December 20, 2018 11:23 AM To: nanog at nanog.org Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released Dear operators, FORTH's INSPIRE group and CAIDA are delighted to announce the public release of the ARTEMIS BGP prefix hijacking detection tool, available as open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential hijacking attempts against its own prefixes. The system detects such attacks within seconds, enabling immediate mitigation. The current release has been tested at a major greek ISP, a dual-homed edge academic network, and a major US R&E backbone network. We would be happy if you'd give it a try and provide feedback. Feel free to make pull requests on GitHub and help us make this a true community project. ARTEMIS is funded by European Research Council (ERC) grant agreement no. 338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S&T contract HHSP233201600012C. Best regards, Vasileios -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From jared at puck.nether.net Fri Dec 21 15:10:34 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Dec 2018 10:10:34 -0500 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: <3979AE529B56AB47942E2423B707F16E01E90B1D50@RTC-EXCH01.RESERVE.LDS> References: <3979AE529B56AB47942E2423B707F16E01E90B1D50@RTC-EXCH01.RESERVE.LDS> Message-ID: <353339A3-A337-48EB-84E6-6B37C887D17E@puck.nether.net> Folks have studied announcing a /25 etc.. and it can help because many providers will accept them.. it won’t get everyone, but longer than /24 prefixes do help. - Jared > On Dec 21, 2018, at 10:07 AM, Kody Vicknair wrote: > > I'm curious, If the highjacked prefix is a /24 (subset of your much larger /22) and you can only tie the highjacked prefix, at that point how effective is the mitigation outside of a default bgp route selection process? > > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Vasileios Kotronis > Sent: Thursday, December 20, 2018 11:23 AM > To: nanog at nanog.org > Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released > > Dear operators, > > FORTH's INSPIRE group and CAIDA are delighted to announce the public release of the ARTEMIS BGP prefix hijacking detection tool, available as open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis > > ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential hijacking attempts against its own prefixes. The system detects such attacks within seconds, enabling immediate mitigation. The current release has been tested at a major greek ISP, a dual-homed edge academic network, and a major US R&E backbone network. > > We would be happy if you'd give it a try and provide feedback. Feel free to make pull requests on GitHub and help us make this a true community project. > > ARTEMIS is funded by European Research Council (ERC) grant agreement no. > 338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S&T contract HHSP233201600012C. > > Best regards, > Vasileios > > -- > ======================================= > Vasileios Kotronis > Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotronis at ics.forth.gr > url: http://inspire.edu.gr > ======================================= > > > > > > From nanog at ics-il.net Fri Dec 21 15:11:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Dec 2018 09:11:15 -0600 (CST) Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> Message-ID: <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> Someone's typically paying the difference in a non-profit IX. Someone's donating piles of cash, free dark fiber, free colo, etc. You're either paying your own way, or you have a port subsidized by someone else. There's not necessarily anything wrong with that, but you have to make sure you count that when you talk about "cost". They're also over twice the size, and in half the number of buildings (per PeeringDB, anyway). They've also been around over twice as long. Scale helps with cost. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Darin Steffl" To: "Mike Hammett" Cc: "Mehmet Akcin" , "NANOG Mailing List" Sent: Friday, December 21, 2018 8:34:32 AM Subject: Re: Non-profit IX vs. neutral for-profit IX http://micemn.net/services.html MICE in Minneapolis is a great IX that we are on and their port fees are very reasonable. They used to be completely free up until this year. Even so, their fees are virtually nothing which encourages more operators to connect to it versus For-Profit IX's where sometimes the fees are almost as much as transit. For example Midwest-IX is $9,300 per year for a 10G port but MICE is only $250 per year. That's a HUGE difference and MICE also has way more peers and traffic overall due to how easy and cheap it is to join. On Fri, Dec 21, 2018 at 8:27 AM Mike Hammett < nanog at ics-il.net > wrote: Not all transit is cheap and not all transit is good quality, regardless of what it costs. ;-) At our IX, we regularly see clients whose total network usage goes up once they're on the IX. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Mehmet Akcin" < mehmet at akcin.net > To: "Clayton Zekelman" < clayton at mnsi.net > Cc: "Mike Hammett" < nanog at ics-il.net >, "NANOG Mailing List" < nanog at nanog.org >, "Tim Raphael" < raphael.timothy at gmail.com > Sent: Friday, December 21, 2018 8:19:43 AM Subject: Re: Non-profit IX vs. neutral for-profit IX Torix and Six are great examples. If you want to be for profit, make sure to publish port pricing and keep it fair. Transit is cheap and good quality On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman < clayton at mnsi.net > wrote:
TorIX is a great example of a not for profit IX that is very successful. https://www.torix.ca/ A very dedicated team of people provide an incredible level of service. Thave a very transparent process. Their pricing is listed up front on their website: https://www.torix.ca/peering/#pricing At 09:03 AM 21/12/2018, Mike Hammett wrote:
As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Tim Raphael" < raphael.timothy at gmail.com > To: "NANOG Mailing List" < nanog at nanog.org > Sent: Thursday, December 20, 2018 8:39:42 PM Subject: Re: Non-profit IX vs. neutral for-profit IX The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral†and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability.
- Tim > On 21 Dec 2018, at 3:58 am, Brielle Bruns < bruns at 2mbit.com > wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org >
-- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
-- Mehmet +1-424-298-1903
-- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Dec 21 15:40:48 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Dec 2018 09:40:48 -0600 (CST) Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> Message-ID: <480287470.3921.1545406847052.JavaMail.mhammett@ThunderFuck> I think anyone not Equinix, DRT, CoreSite, etc. is building into multiple datacenter providers in their markets, some just more aggressively than others. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Robert DeVita" To: "Mike Hammett" , "Darin Steffl" Cc: "NANOG Mailing List" Sent: Friday, December 21, 2018 9:37:52 AM Subject: RE: Non-profit IX vs. neutral for-profit IX The biggest difference we see is that the “non commercial” IX’s are now building metro fabrics across multiple different datacenter providers. When you look at the costs, you need to look at the colo as part of that cost also. Allowing datacenters to compete for space and power drives down the costs for end users while also allowing them to connect to the fabric. https://img1.wsimg.com/isteam/ip/c4ed298e-00ea-415c-8059-9ce09ac88788/logo/f3a10962-7bab-4600-a5fa-560682049597.jpg/:/rs=h:125 Robert DeVita Managing Director p: 214-305-2444 e: radevita at mejeticks.com http://cdn2.hubspot.net/hubfs/184235/dev_images/signature_app/linkedin_sig.png From: NANOG < nanog-bounces at nanog.org > On Behalf Of Mike Hammett Sent: Friday, December 21, 2018 9:11 AM To: Darin Steffl < darin.steffl at mnwifi.com > Cc: NANOG Mailing List < nanog at nanog.org > Subject: Re: Non-profit IX vs. neutral for-profit IX Someone's typically paying the difference in a non-profit IX. Someone's donating piles of cash, free dark fiber, free colo, etc. You're either paying your own way, or you have a port subsidized by someone else. There's not necessarily anything wrong with that, but you have to make sure you count that when you talk about "cost". They're also over twice the size, and in half the number of buildings (per PeeringDB, anyway). They've also been around over twice as long. Scale helps with cost. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Darin Steffl" < darin.steffl at mnwifi.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Mehmet Akcin" < mehmet at akcin.net >, "NANOG Mailing List" < nanog at nanog.org > Sent: Friday, December 21, 2018 8:34:32 AM Subject: Re: Non-profit IX vs. neutral for-profit IX http://micemn.net/services.html MICE in Minneapolis is a great IX that we are on and their port fees are very reasonable. They used to be completely free up until this year. Even so, their fees are virtually nothing which encourages more operators to connect to it versus For-Profit IX's where sometimes the fees are almost as much as transit. For example Midwest-IX is $9,300 per year for a 10G port but MICE is only $250 per year. That's a HUGE difference and MICE also has way more peers and traffic overall due to how easy and cheap it is to join. On Fri, Dec 21, 2018 at 8:27 AM Mike Hammett < nanog at ics-il.net > wrote: Not all transit is cheap and not all transit is good quality, regardless of what it costs. ;-) At our IX, we regularly see clients whose total network usage goes up once they're on the IX. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Mehmet Akcin" < mehmet at akcin.net > To: "Clayton Zekelman" < clayton at mnsi.net > Cc: "Mike Hammett" < nanog at ics-il.net >, "NANOG Mailing List" < nanog at nanog.org >, "Tim Raphael" < raphael.timothy at gmail.com > Sent: Friday, December 21, 2018 8:19:43 AM Subject: Re: Non-profit IX vs. neutral for-profit IX Torix and Six are great examples. If you want to be for profit, make sure to publish port pricing and keep it fair. Transit is cheap and good quality On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman < clayton at mnsi.net > wrote:
TorIX is a great example of a not for profit IX that is very successful. https://www.torix.ca/ A very dedicated team of people provide an incredible level of service. Thave a very transparent process. Their pricing is listed up front on their website: https://www.torix.ca/peering/#pricing At 09:03 AM 21/12/2018, Mike Hammett wrote:
As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Tim Raphael" < raphael.timothy at gmail.com > To: "NANOG Mailing List" < nanog at nanog.org > Sent: Thursday, December 20, 2018 8:39:42 PM Subject: Re: Non-profit IX vs. neutral for-profit IX The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral†and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability.
- Tim > On 21 Dec 2018 , at 3:58 am, Brielle Bruns < bruns at 2mbit.com > wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org >
-- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
-- Mehmet + 1-424-298-1903
-- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayhanke at gmail.com Fri Dec 21 16:12:03 2018 From: jayhanke at gmail.com (Jay Hanke) Date: Fri, 21 Dec 2018 10:12:03 -0600 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> Message-ID: MICE is technically a cooperative not a non-profit. The fees cover the costs and just the costs and the members are owners. Also MICE does not provide any transport. All transport to remote locations is provided by the network hosting the remote switch. Jay On Fri, Dec 21, 2018, 9:16 AM Mike Hammett Someone's typically paying the difference in a non-profit IX. Someone's > donating piles of cash, free dark fiber, free colo, etc. You're either > paying your own way, or you have a port subsidized by someone else. There's > not necessarily anything wrong with that, but you have to make sure you > count that when you talk about "cost". > > They're also over twice the size, and in half the number of buildings (per > PeeringDB, anyway). They've also been around over twice as long. Scale > helps with cost. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Darin Steffl" > *To: *"Mike Hammett" > *Cc: *"Mehmet Akcin" , "NANOG Mailing List" < > nanog at nanog.org> > *Sent: *Friday, December 21, 2018 8:34:32 AM > *Subject: *Re: Non-profit IX vs. neutral for-profit IX > > http://micemn.net/services.html > > MICE in Minneapolis is a great IX that we are on and their port fees are > very reasonable. They used to be completely free up until this year. Even > so, their fees are virtually nothing which encourages more operators to > connect to it versus For-Profit IX's where sometimes the fees are almost as > much as transit. > > For example Midwest-IX is $9,300 per year for a 10G port but MICE is only > $250 per year. That's a HUGE difference and MICE also has way more peers > and traffic overall due to how easy and cheap it is to join. > > On Fri, Dec 21, 2018 at 8:27 AM Mike Hammett wrote: > >> Not all transit is cheap and not all transit is good quality, regardless >> of what it costs. ;-) >> >> At our IX, we regularly see clients whose total network usage goes up >> once they're on the IX. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Mehmet Akcin" >> *To: *"Clayton Zekelman" >> *Cc: *"Mike Hammett" , "NANOG Mailing List" < >> nanog at nanog.org>, "Tim Raphael" >> *Sent: *Friday, December 21, 2018 8:19:43 AM >> *Subject: *Re: Non-profit IX vs. neutral for-profit IX >> >> Torix and Six are great examples. >> >> If you want to be for profit, make sure to publish port pricing and keep >> it fair. Transit is cheap and good quality >> >> On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman wrote: >> >>> >>> TorIX is a great example of a not for profit IX that is very successful. >>> >>> https://www.torix.ca/ >>> >>> A very dedicated team of people provide an incredible level of service. >>> >>> Thave a very transparent process. Their pricing is listed up front on >>> their website: >>> >>> https://www.torix.ca/peering/#pricing >>> >>> >>> >>> At 09:03 AM 21/12/2018, Mike Hammett wrote: >>> >>> As far as neutral, I meant separate from the datacenters in which >>> they're housed. People in NA seem to think there are only two kinds of >>> IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> Midwest Internet Exchange >>> >>> The Brothers WISP >>> >>> ------------------------------ >>> *From: *"Tim Raphael" >>> *To: *"NANOG Mailing List" >>> *Sent: *Thursday, December 20, 2018 8:39:42 PM >>> *Subject: *Re: Non-profit IX vs. neutral for-profit IX >>> >>> The other point to consider is that a NFP can justify more locations and >>> offer services (such as extended reach) that don’t have the same profit >>> margins or ROI as for-profits. >>> This often leads to greater value to those with smaller networks and >>> fewer customers allowing them to grow and expand without increased >>> aggregation or transit costs. This in-turn leads to a richer array of >>> providers and chips away at the monopolies in niche markets. >>> >>> The NFP IXP I work for focuses on providing value to the broader >>> community and the Internet as a whole - especially somewhere like Australia >>> which has unique constraints. >>> >>> Additionally, “Neutral†and For-Profit doesn’t always compute in my >>> mind, there will always be commercial alliances that lead to not-total >>> neutrality. >>> When a NFP is owned by it’s members there has to be 100% transparency >>> in organisational decisions around member funds and resources which ensures >>> accountability reliability. >>> >>> >>> >>> - Tim >>> >>> >>> > On 21 Dec 2018, at 3:58 am, Brielle Bruns wrote: >>> > >>> > On 12/20/2018 12:51 PM, Aaron wrote: >>> >> Probably price. Also perception of value. If you're a for profit >>> enterprise then they're paying for interconnection plus your bump. If >>> you're non-profit the perception is that there is a larger value because >>> there's no bump. Whether that's true or not, who knows but that's the >>> perception I've heard. >>> > >>> > Depending on the size of the non-profit, I'd almost compare it to how >>> the hospitals are here in Boise. >>> > >>> > The non-profits are oversized, monopolistic, price gouging, etc. >>> Their care can be pretty meh, esp since they bought up all the little >>> independent clinics (yay, ER pricing for a basic family clinic visit). >>> > >>> > The for-profit smaller clinics and hospitals run a pretty tight ship, >>> better value for their money, service is very good, and compete with one >>> another for who has the best service. >>> > >>> > People think they are getting 'better' because they are going to a >>> place that is supposed to be run to benefit people over profit, but alas, >>> you'd be very very wrong. >>> > -- >>> > Brielle Bruns >>> > The Summit Open Source Development Group >>> > http://www.sosdg.org / http://www.ahbl.org >>> > >>> >>> >>> -- >>> >>> Clayton Zekelman >>> Managed Network Systems Inc. (MNSi) >>> 3363 Tecumseh Rd. E >>> >>> Windsor, Ontario >>> >>> N8W 1H4 >>> >>> >>> tel. 519-985-8410 >>> fax. 519-985-8409 >>> >> -- >> Mehmet >> +1-424-298-1903 >> >> > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Dec 21 18:03:40 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Dec 2018 04:03:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181221180340.E74FEC44B7@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 22 Dec, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 731372 Prefixes after maximum aggregation (per Origin AS): 281422 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 352021 Total ASes present in the Internet Routing Table: 62796 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54191 Origin ASes announcing only one prefix: 23540 Transit ASes present in the Internet Routing Table: 8605 Transit-only ASes present in the Internet Routing Table: 257 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 36 Number of instances of unregistered ASNs: 38 Number of 32-bit ASNs allocated by the RIRs: 25275 Number of 32-bit ASNs visible in the Routing Table: 20537 Prefixes from 32-bit ASNs in the Routing Table: 88449 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 268 Number of addresses announced to Internet: 2838514337 Equivalent to 169 /8s, 48 /16s and 74 /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.1 Total number of prefixes smaller than registry allocations: 244208 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 199658 Total APNIC prefixes after maximum aggregation: 56861 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 196780 Unique aggregates announced from the APNIC address blocks: 81025 APNIC Region origin ASes present in the Internet Routing Table: 9333 APNIC Prefixes per ASN: 21.08 APNIC Region origin ASes announcing only one prefix: 2641 APNIC Region transit ASes present in the Internet Routing Table: 1395 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4329 Number of APNIC addresses announced to Internet: 768797056 Equivalent to 45 /8s, 210 /16s and 233 /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-139577 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: 216410 Total ARIN prefixes after maximum aggregation: 102834 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 215624 Unique aggregates announced from the ARIN address blocks: 103383 ARIN Region origin ASes present in the Internet Routing Table: 18304 ARIN Prefixes per ASN: 11.78 ARIN Region origin ASes announcing only one prefix: 6805 ARIN Region transit ASes present in the Internet Routing Table: 1837 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2530 Number of ARIN addresses announced to Internet: 1077222048 Equivalent to 64 /8s, 53 /16s and 26 /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, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 200083 Total RIPE prefixes after maximum aggregation: 95461 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 196486 Unique aggregates announced from the RIPE address blocks: 116177 RIPE Region origin ASes present in the Internet Routing Table: 25732 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 11493 RIPE Region transit ASes present in the Internet Routing Table: 3556 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7709 Number of RIPE addresses announced to Internet: 716063360 Equivalent to 42 /8s, 174 /16s and 66 /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: 95008 Total LACNIC prefixes after maximum aggregation: 22014 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 96404 Unique aggregates announced from the LACNIC address blocks: 42127 LACNIC Region origin ASes present in the Internet Routing Table: 7917 LACNIC Prefixes per ASN: 12.18 LACNIC Region origin ASes announcing only one prefix: 2181 LACNIC Region transit ASes present in the Internet Routing Table: 1488 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5466 Number of LACNIC addresses announced to Internet: 173172736 Equivalent to 10 /8s, 82 /16s and 104 /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: 20176 Total AfriNIC prefixes after maximum aggregation: 4221 AfriNIC Deaggregation factor: 4.78 Prefixes being announced from the AfriNIC address blocks: 25810 Unique aggregates announced from the AfriNIC address blocks: 9062 AfriNIC Region origin ASes present in the Internet Routing Table: 1232 AfriNIC Prefixes per ASN: 20.95 AfriNIC Region origin ASes announcing only one prefix: 420 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 503 Number of AfriNIC addresses announced to Internet: 102852352 Equivalent to 6 /8s, 33 /16s and 103 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4652 515 520 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4639 4192 74 ERX-CERNET-BKB China Education and Rese 7552 2995 1160 91 VIETEL-AS-AP Viettel Group, VN 45899 2982 1717 115 VNPT-AS-VN VNPT Corp, VN 4766 2819 11129 769 KIXS-AS-KR Korea Telecom, KR 9829 2750 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2511 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2400 4906 29 CTTNET China TieTong Telecommunications 17974 2258 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2141 438 177 TATACOMM-AS TATA Communications formerl 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 6327 3499 1326 91 SHAW - Shaw Communications Inc., CA 11492 3480 225 608 CABLEONE - CABLE ONE, INC., US 22773 3306 2980 176 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2603 5293 974 AMAZON-02 - Amazon.com, Inc., US 16625 2191 1224 1684 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2754 533 CHARTER-20115 - Charter Communications, 18566 2144 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2092 349 134 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2081 5079 593 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5240 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3244 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2614 576 1925 AKAMAI-ASN1, US 12389 2233 2221 626 ROSTELECOM-AS, RU 34984 2034 337 534 TELLCOM-AS, TR 9121 1672 1691 17 TTNET, TR 13188 1602 100 46 TRIOLAN, UA 8402 1298 544 17 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, 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 5465 3317 592 Uninet S.A. de C.V., MX 10620 3146 476 893 Telmex Colombia S.A., CO 11830 2679 371 71 Instituto Costarricense de Electricidad 6503 1649 449 54 Axtel, S.A.B. de C.V., MX 7303 1440 961 225 Telecom Argentina S.A., AR 28573 1185 2241 179 CLARO S.A., BR 6147 1074 377 29 Telefonica del Peru S.A.A., PE 3816 1023 510 110 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 943 145 69 Alestra, S. de R.L. de C.V., MX 13999 931 538 258 Mega Cable, S.A. 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 1165 393 24 LINKdotNET-AS, EG 37611 898 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 779 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 639 1731 19 TE-AS TE-AS, EG 29571 481 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 415 45 11 WANANCHI-, KE 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 5465 3317 592 Uninet S.A. de C.V., MX 12479 5240 1628 138 UNI2-AS, ES 7545 4652 515 520 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4639 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3499 1326 91 SHAW - Shaw Communications Inc., CA 11492 3480 225 608 CABLEONE - CABLE ONE, INC., US 22773 3306 2980 176 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3244 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3146 476 893 Telmex Colombia S.A., CO 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 5240 5102 UNI2-AS, ES 4538 4639 4565 ERX-CERNET-BKB China Education and Research Net 7545 4652 4132 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3499 3408 SHAW - Shaw Communications Inc., CA 8551 3244 3201 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3306 3130 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2995 2904 VIETEL-AS-AP Viettel Group, VN 11492 3480 2872 CABLEONE - CABLE ONE, INC., US 45899 2982 2867 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 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65534 PRIVATE 46.46.17.0/24 15638 UTL Ussuriysk, RU 65534 PRIVATE 46.46.32.0/21 15638 UTL Ussuriysk, RU 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 80.93.96.0/21 15638 UTL Ussuriysk, RU 65534 PRIVATE 93.88.216.0/22 15638 UTL Ussuriysk, RU 65534 PRIVATE 93.88.220.0/24 15638 UTL Ussuriysk, RU 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai 4200058511 PRIVATE 103.111.178.0/24 137522 OERL-AS-AP Origin Energy Retai Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:12 /9:11 /10:36 /11:99 /12:291 /13:568 /14:1125 /15:1909 /16:13349 /17:7882 /18:13863 /19:25505 /20:39676 /21:46116 /22:91180 /23:74538 /24:412844 /25:824 /26:656 /27:636 /28:32 /29:19 /30:9 /31:2 /32:190 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4093 5240 UNI2-AS, ES 6327 3263 3499 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2764 3480 CABLEONE - CABLE ONE, INC., US 8551 2700 3244 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2544 3306 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2039 2144 MEGAPATH5-US - MegaPath Corporation, US 11830 2024 2679 Instituto Costarricense de Electricidad y Telec 30036 1841 2092 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1629 2:884 4:18 5:2757 6:43 7:1 8:1148 12:1877 13:302 14:1884 15:36 16:2 17:207 18:59 20:48 23:2553 24:2419 25:2 27:2550 31:2011 32:91 35:31 36:539 37:2992 38:1593 39:309 40:120 41:3155 42:741 43:1993 44:137 45:6390 46:3095 47:243 49:1324 50:1075 51:319 52:1087 54:363 55:1 56:6 57:41 58:1713 59:1072 60:462 61:2080 62:1998 63:1812 64:5066 65:2184 66:4784 67:2681 68:1159 69:3412 70:1148 71:602 72:2258 74:2731 75:410 76:527 77:1725 78:1716 79:2285 80:1649 81:1413 82:1081 83:870 84:1067 85:2133 86:566 87:1518 88:988 89:2433 90:211 91:6496 92:1259 93:2358 94:2398 95:3128 96:906 97:346 98:936 99:169 100:88 101:1164 102:307 103:19556 104:3561 105:243 106:879 107:1834 108:703 109:3623 110:1634 111:1860 112:1395 113:1329 114:1147 115:1718 116:1615 117:1896 118:2205 119:1682 120:1136 121:1025 122:2357 123:1619 124:1440 125:1950 128:1208 129:689 130:519 131:1632 132:717 133:193 134:1043 135:230 136:541 137:675 138:1928 139:775 140:568 141:763 142:802 143:1010 144:849 145:504 146:1249 147:771 148:1701 149:790 150:799 151:997 152:931 153:326 154:2373 155:963 156:1635 157:851 158:656 159:1887 160:1489 161:902 162:2667 163:770 164:1121 165:1588 166:467 167:1366 168:3207 169:870 170:4003 171:497 172:1071 173:2138 174:988 175:879 176:2224 177:4073 178:2529 179:1318 180:2091 181:2362 182:2629 183:1337 184:1136 185:14512 186:3693 187:2536 188:2978 189:2101 190:8281 191:1405 192:9999 193:6473 194:5320 195:4041 196:3018 197:1761 198:5679 199:5986 200:7427 201:5003 202:10228 203:10233 204:4608 205:3009 206:3278 207:3263 208:3929 209:4203 210:3877 211:2019 212:3074 213:2824 214:1067 215:52 216:6008 217:2191 218:874 219:580 220:1835 221:997 222:976 223:1418 End of report From Nikos.Leontsinis at eu.equinix.com Thu Dec 20 19:25:15 2018 From: Nikos.Leontsinis at eu.equinix.com (Nikos Leontsinis) Date: Thu, 20 Dec 2018 19:25:15 +0000 Subject: [EXTERNAL] Re: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: There is a fundamental product limitation. CoS on Cascade port for MX is not officially supported as well QFX acting as AD. I agree with those who perceive all these approaches as proprietary lock-in (disguised as cheap). From: NANOG On Behalf Of Vincentz Petzholtz Sent: Wednesday, December 19, 2018 9:01 AM To: nanog Subject: [EXTERNAL] Re: JunOS Fusion Provider Edge Hi there, About Juniper Fusion PE and our experience with it. For example, you can't get SNMP oids for light levels or even read them right from the CLI. Sure it’s possible but also with a big „meh“. Here is how: "show interfaces diagnostics optics satellite “ (<- on the MX) BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values are wrong by a pretty big offset. Juniper promised they already fixed it but we can’t confirm (at least not in MX Junos 16.1). Soon we will take a look at MX Junos 17.3 with aligned sat image. I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications Same thing here … we don’t really need it. At least it’s on the roadmap and/or already implemented with higher Junos/SNOS versions. From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. Yep, that is really amazing and the reason we use it on many MXes. You can get rid of almost all ports you want (restrictions apply tho). We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. We use Junos PE NOT as a replacement for any switch and/or ip fabrics within a datacenter. We use it to get rid of many customer/client ports (mainly 1G and 10G ports) which were directly connected to our MXes before. Atm I would not recommend using any closed fabrics beyond that scope. If it works for you … ok. We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. At the moment? Don’t do it. If you run mpls on so called „core router/dwdm/wan facing ports“ you have to know that this is totally not supported on extended satellite ports. It’s not even on the roadmap. I already started to „collect“ some other ISPs to push juniper towards this feature because technically there no real reason why fusion should NOT be capable of pushing some mpls labels on already tagged 802.1br packets. Best regards, Vincentz — PS: some have received this mail multiple times because I’ve send it from the wrong account … time for vacation I guess. Am 17.12.2018 um 19:26 schrieb Matt Erculiani >: Fusion has made a lot more sense since Juniper changed the licensing model from every switch AND the MX to just the MX. We've deployed it in some of our sites. It is very cool from a forwarding plane perspective, but from a control plane standpoint it's very...meh. For example, you can't get SNMP oids for light levels or even read them right from the CLI. You have to log into the satellite switch like you would log into an FPC just to get light levels. That's probably the dumbest thing we've dealt with though. I've also heard you can have them do local L2 forwarding, which can be nice for latency and conserving uplink bandwidth, but we don't do any L2 that way so I wouldn't know the implications. From what we can tell though, it does give you Trio L3 performance and features with a MUCH cheaper port cost which is exactly what we were looking for, the extended reach of the chassis was just a fantastic bonus. We also REALLY like that we can have one pair of MX dists for a whole data center with hundreds of thousands of square feet of raised floor and deploy QFX5100 or EX4300 switches in every pod and haul back over just a few pairs of fiber. Saves a lot of time because all that's required to turn up a new connection is a cross connect in the pod. It also allows us to offer copper ports very far away from the MX device, which would normally require media converters. We've wanted to experiment with doing this over dark fiber in the metro as well, but we want to feel out any kinks locally before we add additional failure modes. Very interested in hearing about other's experiences with Fusion, good, bad, and ugly. -Matt On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin > wrote: Hey there Any ISP using Juniper Fusion Provider Edge? https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html I am trying to chat with an engineer besides Juniper engineers to understand how buggy (or not) this is to go on production for a medium size ISP. Any feedback good/bad appreciated. -- Mehmet +1-424-298-1903 This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emsmith at routeviews.org Thu Dec 20 19:45:56 2018 From: emsmith at routeviews.org (Eric Smith) Date: Thu, 20 Dec 2018 11:45:56 -0800 Subject: routeviews.org pending delete Message-ID: <6A608DE9-6A0B-4A3B-B822-9421E470C822@routeviews.org> Hey folks, Thanks for the heads-up, we've already been working through this with Network Solutions. The project has switched stewards recently and the renewal notification got lost in the transition. The NS records should point back to the correct routeviews.org address now. We're also working through the permanent transfer of ownership to avoid this in the future. Eric -------- Forwarded Message -------- Subject: RE: routeviews.org pending delete Date: Thu, 20 Dec 2018 17:29:03 +0000 From: David Guo via NANOG Reply-To: David Guo To: Siyuan Miao , nanog at nanog.org It’s your cache resule root at server ~ # whois routeviews.org Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T18:54:32Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Registrant State/Province: OR Registrant Country: US Name Server: GUELAH.SHRUBBERY.NET Name Server: PHLOEM.UOREGON.EDU DNSSEC: unsigned From: NANOG On Behalf Of Siyuan Miao Sent: Monday, December 17, 2018 8:34 PM To: nanog at nanog.org Subject: routeviews.org pending delete All, routeviews.org is pending delete now. Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T09:33:18Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Network Solutions LLC Registrant State/Province: FL Registrant Country: US Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/) >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. I was wondering if there is anyone here can contact them to renew it if this project is still alive. Regards, Siyuan From vkotronis at ics.forth.gr Thu Dec 20 20:46:39 2018 From: vkotronis at ics.forth.gr (Vasileios Kotronis) Date: Thu, 20 Dec 2018 22:46:39 +0200 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: References: Message-ID: <5ef8488f-68b9-1eee-b5b8-94997ff7d620@ics.forth.gr> Hello, it is quite easy to install on a VM, you will not need special infrastructure, but only two pieces of software to be able to run lightweight containers (docker-ce and docker-compose). In fact, this is how we test it ourselves :). We will consider publishing a standalone VM is this helps testing more (details to come in the project's' wiki pages). Best, Vasileios On 20/12/18 10:40 μ.μ., M. Omer GOLGELI wrote: > Hi Vasileios, > > Congratulations of building this. > > Wanted to try it out as a VM but frankly... > The "docker" part put me off... > > > M. > --- > > > On 2018-12-20 20:23, Vasileios Kotronis wrote: >> Dear operators, >> >> FORTH's INSPIRE group and CAIDA are delighted to announce the public >> release of the ARTEMIS BGP prefix hijacking detection tool, available >> as open-source software at >> https://github.com/FORTH-ICS-INSPIRE/artemis >> >> ARTEMIS is designed to be operated by an AS in order to monitor BGP >> for potential hijacking attempts against its own prefixes. The system >> detects such attacks within seconds, enabling immediate mitigation. >> The current release has been tested at a major greek ISP, a dual-homed >> edge academic network, and a major US R&E backbone network. >> >> We would be happy if you'd give it a try and provide feedback. Feel >> free to make pull requests on GitHub and help us make this a true >> community project. >> >> ARTEMIS is funded by European Research Council (ERC) grant agreement >> no. 338402 (NetVolution Project), the RIPE NCC Community Projects >> 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and >> CNS-1423659 and US DHS S&T contract HHSP233201600012C. >> >> Best regards, >> Vasileios -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece Tel: +302810391241 Office: G-060 e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From Steven.Bakker at ams-ix.net Fri Dec 21 10:45:57 2018 From: Steven.Bakker at ams-ix.net (Steven Bakker) Date: Fri, 21 Dec 2018 11:45:57 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <5c1bdc54.1c69fb81.61661.e8c1SMTPIN_ADDED_MISSING@mx.google.com> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <5c1bdc54.1c69fb81.61661.e8c1SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <31e2b8b85c689889f96d7235ff443da860b36889.camel@ams-ix.net> Hi Dominic, On Thu, 2018-12-20 at 19:15 +0100, Dominic Schallert wrote: > Dear Job, Michael, Ross, > thank you very much for sharing your opinion, the detailed info and > references. That’s pretty much what I excpected. > Just wondered because I couldn’t find any IXP Conection Agreement > stating this „issue“ explicitly yet. > > Maybe MANRS IXP actions has some recommendations regarding this, > checking that now. We don't have it in our connection agreement as such, but it is in section 3.2 of our (admittedly aged) Configuration Guide: https://ams-ix.net/technical/specifications-descriptions/config-guide#3.2 3.2. Peering LAN Prefix The IPv4 prefix for the AMS-IX peering LAN (80.249.208.0/21) is part of AS1200, and is not supposed to be globally routable. This means the following: 1. Do not configure "network 80.249.208.0/21" in your router's BGP configuration (seriously, we have seen this happen!). 2. Do not redistribute the route, a supernet, or a more specific outside of your AS. We (AS1200) announce it with a no-export attribute, please honour it. In short, you can take the view that the Peering LAN is a link-local address range and you may decide to not even redistribute it internally (but in that case you may want to set a static route for management access so you can troubleshoot peering, etc.). AFAIK, pretty much all IXP operators take this view. Cheers, Steven > Best wishes and happy holidays > > Cheers > Dominic > > > > Am 20.12.2018 um 19:06 schrieb Michael Still > > : > > > > IXP LANs should not be announced via BGP (or your IGP either). See > > section 3.1: > > http://nabcop.org/index.php/BCOP-Exchange_Points_v2 > > > > > > > > On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert < > > ds at schallert.com> wrote: > > > Hi all, > > > > > > this might be a stupid question but today I was discussing with a > > > colleague if Peering-LAN prefixes should be re- > > > distributed/announced to direct customers/peers. My standpoint is > > > that in any case, Peering-LAN prefixes should be filtered and not > > > announced to peers/customers because a Peering-LAN represents > > > some sort of DMZ and there is simply no need for them to be > > > reachable by third-parties not being physically connected to an > > > IXP themselves. Also from a security point of view, a lot of new > > > issues might occur in this situation. > > > > > > I’ve been seeing a few transit providers lately announcing (even > > > reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) > > > to their customers. I’m wondering if there is any document or RFC > > > particularly describing this matter? > > > > > > Thanks > > > Dominic > > > > > > -- > > [stillwaxin at gmail.com ~]$ cat .signature > > cat: .signature: No such file or directory > > [stillwaxin at gmail.com ~]$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part URL: From vkotronis at ics.forth.gr Fri Dec 21 15:27:31 2018 From: vkotronis at ics.forth.gr (Vasileios Kotronis) Date: Fri, 21 Dec 2018 17:27:31 +0200 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: <353339A3-A337-48EB-84E6-6B37C887D17E@puck.nether.net> Message-ID: An HTML attachment was scrubbed... URL: From radevita at mejeticks.com Fri Dec 21 15:37:52 2018 From: radevita at mejeticks.com (Robert DeVita) Date: Fri, 21 Dec 2018 15:37:52 +0000 Subject: Non-profit IX vs. neutral for-profit IX In-Reply-To: <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> References: <632158677.2881.1545334291231.JavaMail.mhammett@ThunderFuck> <6a592bff-c1ed-5760-e8e8-3aa3e99fa94b@2mbit.com> <379058715.3670.1545401006847.JavaMail.mhammett@ThunderFuck> <1545401648_176804@surgemail.mnsi.net> <1810103784.3771.1545402164847.JavaMail.mhammett@ThunderFuck> <702710036.3852.1545405070788.JavaMail.mhammett@ThunderFuck> Message-ID: The biggest difference we see is that the “non commercial” IX’s are now building metro fabrics across multiple different datacenter providers. When you look at the costs, you need to look at the colo as part of that cost also. Allowing datacenters to compete for space and power drives down the costs for end users while also allowing them to connect to the fabric. [https://img1.wsimg.com/isteam/ip/c4ed298e-00ea-415c-8059-9ce09ac88788/logo/f3a10962-7bab-4600-a5fa-560682049597.jpg/:/rs=h:125] Robert DeVita Managing Director p: 214-305-2444 e: radevita at mejeticks.com [http://cdn2.hubspot.net/hubfs/184235/dev_images/signature_app/linkedin_sig.png] From: NANOG On Behalf Of Mike Hammett Sent: Friday, December 21, 2018 9:11 AM To: Darin Steffl Cc: NANOG Mailing List Subject: Re: Non-profit IX vs. neutral for-profit IX Someone's typically paying the difference in a non-profit IX. Someone's donating piles of cash, free dark fiber, free colo, etc. You're either paying your own way, or you have a port subsidized by someone else. There's not necessarily anything wrong with that, but you have to make sure you count that when you talk about "cost". They're also over twice the size, and in half the number of buildings (per PeeringDB, anyway). They've also been around over twice as long. Scale helps with cost. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Darin Steffl" > To: "Mike Hammett" > Cc: "Mehmet Akcin" >, "NANOG Mailing List" > Sent: Friday, December 21, 2018 8:34:32 AM Subject: Re: Non-profit IX vs. neutral for-profit IX http://micemn.net/services.html MICE in Minneapolis is a great IX that we are on and their port fees are very reasonable. They used to be completely free up until this year. Even so, their fees are virtually nothing which encourages more operators to connect to it versus For-Profit IX's where sometimes the fees are almost as much as transit. For example Midwest-IX is $9,300 per year for a 10G port but MICE is only $250 per year. That's a HUGE difference and MICE also has way more peers and traffic overall due to how easy and cheap it is to join. On Fri, Dec 21, 2018 at 8:27 AM Mike Hammett > wrote: Not all transit is cheap and not all transit is good quality, regardless of what it costs. ;-) At our IX, we regularly see clients whose total network usage goes up once they're on the IX. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Mehmet Akcin" > To: "Clayton Zekelman" > Cc: "Mike Hammett" >, "NANOG Mailing List" >, "Tim Raphael" > Sent: Friday, December 21, 2018 8:19:43 AM Subject: Re: Non-profit IX vs. neutral for-profit IX Torix and Six are great examples. If you want to be for profit, make sure to publish port pricing and keep it fair. Transit is cheap and good quality On Fri, Dec 21, 2018 at 08:14 Clayton Zekelman > wrote: TorIX is a great example of a not for profit IX that is very successful. https://www.torix.ca/ A very dedicated team of people provide an incredible level of service. Thave a very transparent process. Their pricing is listed up front on their website: https://www.torix.ca/peering/#pricing At 09:03 AM 21/12/2018, Mike Hammett wrote: As far as neutral, I meant separate from the datacenters in which they're housed. People in NA seem to think there are only two kinds of IXes, Equinix, DRT, Coresite types and NWAX, SIX, MICE types. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ________________________________ From: "Tim Raphael" > To: "NANOG Mailing List" > Sent: Thursday, December 20, 2018 8:39:42 PM Subject: Re: Non-profit IX vs. neutral for-profit IX The other point to consider is that a NFP can justify more locations and offer services (such as extended reach) that don’t have the same profit margins or ROI as for-profits. This often leads to greater value to those with smaller networks and fewer customers allowing them to grow and expand without increased aggregation or transit costs. This in-turn leads to a richer array of providers and chips away at the monopolies in niche markets. The NFP IXP I work for focuses on providing value to the broader community and the Internet as a whole - especially somewhere like Australia which has unique constraints. Additionally, “Neutral†and For-Profit doesn’t always compute in my mind, there will always be commercial alliances that lead to not-total neutrality. When a NFP is owned by it’s members there has to be 100% transparency in organisational decisions around member funds and resources which ensures accountability reliability. - Tim > On 21 Dec 2018, at 3:58 am, Brielle Bruns > wrote: > > On 12/20/2018 12:51 PM, Aaron wrote: >> Probably price. Also perception of value. If you're a for profit enterprise then they're paying for interconnection plus your bump. If you're non-profit the perception is that there is a larger value because there's no bump. Whether that's true or not, who knows but that's the perception I've heard. > > Depending on the size of the non-profit, I'd almost compare it to how the hospitals are here in Boise. > > The non-profits are oversized, monopolistic, price gouging, etc. Their care can be pretty meh, esp since they bought up all the little independent clinics (yay, ER pricing for a basic family clinic visit). > > The for-profit smaller clinics and hospitals run a pretty tight ship, better value for their money, service is very good, and compete with one another for who has the best service. > > People think they are getting 'better' because they are going to a place that is supposed to be run to benefit people over profit, but alas, you'd be very very wrong. > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 -- Mehmet +1-424-298-1903 -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi [http://www.snoitulosten.com/wp-content/uploads/2010/01/facebook-small.jpg] Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricpatara at gmail.com Fri Dec 21 19:07:34 2018 From: ricpatara at gmail.com (Ricardo Patara) Date: Fri, 21 Dec 2018 17:07:34 -0200 Subject: contact from 7029 Message-ID: Any contact from asn 7029 in the list? It seems there is incorrect announcement being originated in that ASN. If anyone from that ASN in the list, fell free to contact me privately. thanks From jared at puck.nether.net Fri Dec 21 20:23:44 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Dec 2018 15:23:44 -0500 Subject: Network instability 12956 <=> 18881 Message-ID: Does anyone know what’s going on here? There’s a lot of BGP churn coming from this network edge. - Jared From rubensk at gmail.com Fri Dec 21 20:34:39 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 21 Dec 2018 18:34:39 -0200 Subject: Network instability 12956 <=> 18881 In-Reply-To: References: Message-ID: They are both Telefónica operations; 12956 is TIWS/Telxius, 18881 is a CLEC they bought a few years ago, previously known as GVT. Could be a cable cut in SAM-1, the submarine fiber system operated by Telxius (the cable is also known as Emergia). Rubens On Fri, Dec 21, 2018 at 6:24 PM Jared Mauch wrote: > Does anyone know what’s going on here? There’s a lot of BGP churn coming > from this network edge. > > - Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Fri Dec 21 20:37:06 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Dec 2018 15:37:06 -0500 Subject: Network instability 12956 <=> 18881 In-Reply-To: References: Message-ID: <9D5992C7-9D12-4142-9317-3ACFC15B9D5A@puck.nether.net> > On Dec 21, 2018, at 3:34 PM, Rubens Kuhl wrote: > > > They are both Telefónica operations; 12956 is TIWS/Telxius, 18881 is a CLEC they bought a few years ago, previously known as GVT. > Could be a cable cut in SAM-1, the submarine fiber system operated by Telxius (the cable is also known as Emergia). This is the 2nd time in the past month or so we saw this and at least last time when I posted to NANOG I got no reply but the route flapping stopped immediately :-) - Jared From fw at deneb.enyo.de Fri Dec 21 21:45:45 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 21 Dec 2018 22:45:45 +0100 Subject: Stupid Question maybe? In-Reply-To: (Baldur Norddahl's message of "Tue, 18 Dec 2018 22:13:06 +0100") References: <20181218195007.GB52359@meow.BKantor.net> Message-ID: <87h8f6lfjq.fsf@mid.deneb.enyo.de> * Baldur Norddahl: > Why do we still have network equipment, where half the configuration > requires netmask notation, the other half requires CIDR and to throw you > off, they also included inverse netmasks. Some also drop the prefix length in diagnostic output if it matches that of the address class. So you still need to know about address classes, unfortunately. From josh at imaginenetworksllc.com Fri Dec 21 21:51:10 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 21 Dec 2018 16:51:10 -0500 Subject: Spectrum technical contact Message-ID: We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. The farthest I got was them telling me they can't do route changes because we're not public safety. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Dec 21 21:55:59 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 21 Dec 2018 15:55:59 -0600 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: If you BGP neighbor with them you can send-community /32 advertisement to them, and the will remotely black hole it Aaron > On Dec 21, 2018, at 3:51 PM, Josh Luthman wrote: > > We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. > > The farthest I got was them telling me they can't do route changes because we're not public safety. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 From bryan at shout.net Fri Dec 21 22:01:37 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 21 Dec 2018 16:01:37 -0600 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: http://as11404.net/communities.html 11404:666 is probably what you want. On 12/21/18 3:55 PM, Aaron1 wrote: > If you BGP neighbor with them you can send-community /32 advertisement to them, and the will remotely black hole it > > Aaron > >> On Dec 21, 2018, at 3:51 PM, Josh Luthman wrote: >> >> We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. >> >> The farthest I got was them telling me they can't do route changes because we're not public safety. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 > From nop at imap.cc Fri Dec 21 23:40:41 2018 From: nop at imap.cc (nop at imap.cc) Date: Fri, 21 Dec 2018 18:40:41 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: <8d421f07-f55c-4257-a5c9-5b26dffc94e3@www.fastmail.com> Is this the right Spectrum? There's one that's aka Wave and are pretty good and incredibly responsive to abuse reports, and then there's Spectrum Cable/Charter, which is on par with residential Comcast service. On Fri, Dec 21, 2018, at 2:01 PM, Bryan Holloway wrote: > http://as11404.net/communities.html > > 11404:666 is probably what you want. From aaron1 at gvtc.com Sat Dec 22 01:25:59 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 21 Dec 2018 19:25:59 -0600 Subject: Spectrum technical contact In-Reply-To: <8d421f07-f55c-4257-a5c9-5b26dffc94e3@www.fastmail.com> References: <8d421f07-f55c-4257-a5c9-5b26dffc94e3@www.fastmail.com> Message-ID: well, my comment about ddos rtbh using /32 BGP community is with regard to my provider spectrum which was previously time warner cable/charter AS 11427 is who I peer with Aaron > On Dec 21, 2018, at 5:40 PM, nop at imap.cc wrote: > > Is this the right Spectrum? There's one that's aka Wave and are pretty good and incredibly responsive to abuse reports, and then there's Spectrum Cable/Charter, which is on par with residential Comcast service. > > >> On Fri, Dec 21, 2018, at 2:01 PM, Bryan Holloway wrote: >> http://as11404.net/communities.html >> >> 11404:666 is probably what you want. From hank at efes.iucc.ac.il Sat Dec 22 15:51:18 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 22 Dec 2018 17:51:18 +0200 Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released In-Reply-To: <353339A3-A337-48EB-84E6-6B37C887D17E@puck.nether.net> References: <3979AE529B56AB47942E2423B707F16E01E90B1D50@RTC-EXCH01.RESERVE.LDS> <353339A3-A337-48EB-84E6-6B37C887D17E@puck.nether.net> Message-ID: <532fd755-ed75-cbfc-d640-7415c4454c95@efes.iucc.ac.il> On 21/12/2018 17:10, Jared Mauch wrote: So expect now BGP hijackers to announce /25s from here on in.  They generally adopt BCPs faster than providers. -Hank > Folks have studied announcing a /25 etc.. and it can help because many providers will accept them.. it won’t get everyone, but longer than /24 prefixes do help. > > - Jared > >> On Dec 21, 2018, at 10:07 AM, Kody Vicknair wrote: >> >> I'm curious, If the highjacked prefix is a /24 (subset of your much larger /22) and you can only tie the highjacked prefix, at that point how effective is the mitigation outside of a default bgp route selection process? >> >> >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Vasileios Kotronis >> Sent: Thursday, December 20, 2018 11:23 AM >> To: nanog at nanog.org >> Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released >> >> Dear operators, >> >> FORTH's INSPIRE group and CAIDA are delighted to announce the public release of the ARTEMIS BGP prefix hijacking detection tool, available as open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis >> >> ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential hijacking attempts against its own prefixes. The system detects such attacks within seconds, enabling immediate mitigation. The current release has been tested at a major greek ISP, a dual-homed edge academic network, and a major US R&E backbone network. >> >> We would be happy if you'd give it a try and provide feedback. Feel free to make pull requests on GitHub and help us make this a true community project. >> >> ARTEMIS is funded by European Research Council (ERC) grant agreement no. >> 338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S&T contract HHSP233201600012C. >> >> Best regards, >> Vasileios >> >> -- >> ======================================= >> Vasileios Kotronis >> Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotronis at ics.forth.gr >> url: http://inspire.edu.gr >> ======================================= >> >> >> >> >> >> From josh at imaginenetworksllc.com Sat Dec 22 16:30:13 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 22 Dec 2018 11:30:13 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: I do BGP with them, but of course the issue is an IP that they route to me. My issue is with ASN 10796 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: > If you BGP neighbor with them you can send-community /32 advertisement to > them, and the will remotely black hole it > > Aaron > > > On Dec 21, 2018, at 3:51 PM, Josh Luthman > wrote: > > > > We have had a DOS attack for over 12 hours. I simply want them to null > route or black hole an address. The traffic is filling one of our circus > with them. > > > > The farthest I got was them telling me they can't do route changes > because we're not public safety. > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at unlimitednet.us Sat Dec 22 16:32:04 2018 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 22 Dec 2018 11:32:04 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: The /32 should override any static route they are sending you with a larger prefix. Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 12/22/18 11:30 AM, Josh Luthman wrote: > I do BGP with them, but of course the issue is an IP that they route > to me. > > My issue is with ASN 10796 > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Fri, Dec 21, 2018 at 4:55 PM Aaron1 > wrote: > > If you BGP neighbor with them you can send-community /32 > advertisement to them, and the will remotely black hole it > > Aaron > > > On Dec 21, 2018, at 3:51 PM, Josh Luthman > > > wrote: > > > > We have had a DOS attack for over 12 hours.  I simply want them > to null route or black hole an address.  The traffic is filling > one of our circus with them. > > > > The farthest I got was them telling me they can't do route > changes because we're not public safety. > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Dec 23 00:24:59 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 22 Dec 2018 19:24:59 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: But if they route it to me and I null it, the traffic is already fillimg my pipe (which is my issue). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Dec 22, 2018, 11:32 AM Jason Canady The /32 should override any static route they are sending you with a > larger prefix. > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure > > On 12/22/18 11:30 AM, Josh Luthman wrote: > > I do BGP with them, but of course the issue is an IP that they route to > me. > > My issue is with ASN 10796 > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: > >> If you BGP neighbor with them you can send-community /32 advertisement to >> them, and the will remotely black hole it >> >> Aaron >> >> > On Dec 21, 2018, at 3:51 PM, Josh Luthman >> wrote: >> > >> > We have had a DOS attack for over 12 hours. I simply want them to null >> route or black hole an address. The traffic is filling one of our circus >> with them. >> > >> > The farthest I got was them telling me they can't do route changes >> because we're not public safety. >> > >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at unlimitednet.us Sun Dec 23 00:51:47 2018 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 22 Dec 2018 19:51:47 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: Your upstream provider is null routing it when you send them the command via BGP, no longer filling your pipe. > On Dec 22, 2018, at 19:24, Josh Luthman wrote: > > But if they route it to me and I null it, the traffic is already fillimg my pipe (which is my issue). > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > >> On Sat, Dec 22, 2018, 11:32 AM Jason Canady > The /32 should override any static route they are sending you with a larger prefix. >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure >>> On 12/22/18 11:30 AM, Josh Luthman wrote: >>> I do BGP with them, but of course the issue is an IP that they route to me. >>> >>> My issue is with ASN 10796 >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >>> >>>> On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: >>>> If you BGP neighbor with them you can send-community /32 advertisement to them, and the will remotely black hole it >>>> >>>> Aaron >>>> >>>> > On Dec 21, 2018, at 3:51 PM, Josh Luthman wrote: >>>> > >>>> > We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. >>>> > >>>> > The farthest I got was them telling me they can't do route changes because we're not public safety. >>>> > >>>> > Josh Luthman >>>> > Office: 937-552-2340 >>>> > Direct: 937-552-2343 >>>> > 1100 Wayne St >>>> > Suite 1337 >>>> > Troy, OH 45373 >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahad at swiftelnetworks.com Sun Dec 23 00:56:23 2018 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Sun, 23 Dec 2018 11:56:23 +1100 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: Your upstream should have provided you with BGP backhole community where you tag your /32 and they propagate the BGP BH to all their upstream providers. On Sun, Dec 23, 2018 at 11:27 AM Josh Luthman wrote: > But if they route it to me and I null it, the traffic is already fillimg > my pipe (which is my issue). > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Sat, Dec 22, 2018, 11:32 AM Jason Canady >> The /32 should override any static route they are sending you with a >> larger prefix. >> >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure >> >> On 12/22/18 11:30 AM, Josh Luthman wrote: >> >> I do BGP with them, but of course the issue is an IP that they route to >> me. >> >> My issue is with ASN 10796 >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: >> >>> If you BGP neighbor with them you can send-community /32 advertisement >>> to them, and the will remotely black hole it >>> >>> Aaron >>> >>> > On Dec 21, 2018, at 3:51 PM, Josh Luthman >>> wrote: >>> > >>> > We have had a DOS attack for over 12 hours. I simply want them to >>> null route or black hole an address. The traffic is filling one of our >>> circus with them. >>> > >>> > The farthest I got was them telling me they can't do route changes >>> because we're not public safety. >>> > >>> > Josh Luthman >>> > Office: 937-552-2340 >>> > Direct: 937-552-2343 >>> > 1100 Wayne St >>> > Suite 1337 >>> > Troy, OH 45373 >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Dec 23 01:51:46 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 22 Dec 2018 20:51:46 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: The IP is their routing to me. It's not BGP. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Dec 22, 2018, 7:51 PM Jason Canady Your upstream provider is null routing it when you send them the command > via BGP, no longer filling your pipe. > > On Dec 22, 2018, at 19:24, Josh Luthman > wrote: > > But if they route it to me and I null it, the traffic is already fillimg > my pipe (which is my issue). > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Sat, Dec 22, 2018, 11:32 AM Jason Canady >> The /32 should override any static route they are sending you with a >> larger prefix. >> >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure >> >> On 12/22/18 11:30 AM, Josh Luthman wrote: >> >> I do BGP with them, but of course the issue is an IP that they route to >> me. >> >> My issue is with ASN 10796 >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: >> >>> If you BGP neighbor with them you can send-community /32 advertisement >>> to them, and the will remotely black hole it >>> >>> Aaron >>> >>> > On Dec 21, 2018, at 3:51 PM, Josh Luthman >>> wrote: >>> > >>> > We have had a DOS attack for over 12 hours. I simply want them to >>> null route or black hole an address. The traffic is filling one of our >>> circus with them. >>> > >>> > The farthest I got was them telling me they can't do route changes >>> because we're not public safety. >>> > >>> > Josh Luthman >>> > Office: 937-552-2340 >>> > Direct: 937-552-2343 >>> > 1100 Wayne St >>> > Suite 1337 >>> > Troy, OH 45373 >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Dec 23 01:52:30 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 22 Dec 2018 20:52:30 -0500 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: They don't do communities to my knowledge. At this point they won't do anything unless I'm public safety. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Dec 22, 2018, 7:56 PM Ahad Aboss Your upstream should have provided you with BGP backhole community where > you tag your /32 and they propagate the BGP BH to all their upstream > providers. > > On Sun, Dec 23, 2018 at 11:27 AM Josh Luthman > wrote: > >> But if they route it to me and I null it, the traffic is already fillimg >> my pipe (which is my issue). >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> On Sat, Dec 22, 2018, 11:32 AM Jason Canady > >>> The /32 should override any static route they are sending you with a >>> larger prefix. >>> >>> Jason Canady >>> Unlimited Net, LLC >>> Responsive, Reliable, Secure >>> >>> On 12/22/18 11:30 AM, Josh Luthman wrote: >>> >>> I do BGP with them, but of course the issue is an IP that they route to >>> me. >>> >>> My issue is with ASN 10796 >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >>> >>> On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: >>> >>>> If you BGP neighbor with them you can send-community /32 advertisement >>>> to them, and the will remotely black hole it >>>> >>>> Aaron >>>> >>>> > On Dec 21, 2018, at 3:51 PM, Josh Luthman < >>>> josh at imaginenetworksllc.com> wrote: >>>> > >>>> > We have had a DOS attack for over 12 hours. I simply want them to >>>> null route or black hole an address. The traffic is filling one of our >>>> circus with them. >>>> > >>>> > The farthest I got was them telling me they can't do route changes >>>> because we're not public safety. >>>> > >>>> > Josh Luthman >>>> > Office: 937-552-2340 >>>> > Direct: 937-552-2343 >>>> > 1100 Wayne St >>>> > Suite 1337 >>>> > Troy, OH 45373 >>>> >>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Dec 23 04:14:01 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 22 Dec 2018 22:14:01 -0600 (CST) Subject: Spectrum technical contact In-Reply-To: References: Message-ID: <1138067586.5334.1545538438745.JavaMail.mhammett@ThunderFuck> Did you try their NOC on their PeeringDB page? https://www.peeringdb.com/net/2144 ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Luthman" To: "NANOG list" Sent: Friday, December 21, 2018 3:51:10 PM Subject: Spectrum technical contact We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. The farthest I got was them telling me they can't do route changes because we're not public safety. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Sun Dec 23 05:03:57 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sat, 22 Dec 2018 23:03:57 -0600 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: That’s where you confuse me Josh, if you do BGP with them wouldn’t it be your advertisement to them that’s causing them to route to you. In other words, aren’t they only routing packets to you for prefixes that you advertise via BGP to them? Aaron > On Dec 22, 2018, at 7:51 PM, Josh Luthman wrote: > > The IP is their routing to me. It's not BGP. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > >> On Sat, Dec 22, 2018, 7:51 PM Jason Canady > Your upstream provider is null routing it when you send them the command via BGP, no longer filling your pipe. >> >>> On Dec 22, 2018, at 19:24, Josh Luthman wrote: >>> >>> But if they route it to me and I null it, the traffic is already fillimg my pipe (which is my issue). >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >>>> On Sat, Dec 22, 2018, 11:32 AM Jason Canady >>> The /32 should override any static route they are sending you with a larger prefix. >>>> >>>> Jason Canady >>>> Unlimited Net, LLC >>>> Responsive, Reliable, Secure >>>>> On 12/22/18 11:30 AM, Josh Luthman wrote: >>>>> I do BGP with them, but of course the issue is an IP that they route to me. >>>>> >>>>> My issue is with ASN 10796 >>>>> >>>>> Josh Luthman >>>>> Office: 937-552-2340 >>>>> Direct: 937-552-2343 >>>>> 1100 Wayne St >>>>> Suite 1337 >>>>> Troy, OH 45373 >>>>> >>>>> >>>>>> On Fri, Dec 21, 2018 at 4:55 PM Aaron1 wrote: >>>>>> If you BGP neighbor with them you can send-community /32 advertisement to them, and the will remotely black hole it >>>>>> >>>>>> Aaron >>>>>> >>>>>> > On Dec 21, 2018, at 3:51 PM, Josh Luthman wrote: >>>>>> > >>>>>> > We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. >>>>>> > >>>>>> > The farthest I got was them telling me they can't do route changes because we're not public safety. >>>>>> > >>>>>> > Josh Luthman >>>>>> > Office: 937-552-2340 >>>>>> > Direct: 937-552-2343 >>>>>> > 1100 Wayne St >>>>>> > Suite 1337 >>>>>> > Troy, OH 45373 >>>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From timoid at timoid.org Sun Dec 23 05:11:01 2018 From: timoid at timoid.org (Tim Warnock) Date: Sun, 23 Dec 2018 05:11:01 +0000 Subject: Spectrum technical contact In-Reply-To: References: Message-ID: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> > That’s where you confuse me Josh, if you do BGP with them wouldn’t it be > your advertisement to them that’s causing them to route to you. In other > words, aren’t they only routing packets to you for prefixes that you advertise > via BGP to them? Unless of course the point-to-point between spectrum and Josh is under attack...? From josh at imaginenetworksllc.com Sun Dec 23 05:53:59 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 23 Dec 2018 00:53:59 -0500 Subject: Spectrum technical contact In-Reply-To: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> References: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> Message-ID: Attack is back on. If there's anyone out there that works at Spectrum and can do a route change and hopefully share some info on BGP communities I would greatly appreciate hearing from you. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Dec 23, 2018, 12:12 AM Tim Warnock > That’s where you confuse me Josh, if you do BGP with them wouldn’t it be > > your advertisement to them that’s causing them to route to you. In other > > words, aren’t they only routing packets to you for prefixes that you > advertise > > via BGP to them? > > Unless of course the point-to-point between spectrum and Josh is under > attack...? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Dec 23 07:28:19 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 23 Dec 2018 02:28:19 -0500 Subject: Spectrum technical contact In-Reply-To: References: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> Message-ID: Got a hold of someone, finally! All you have to do, if it's done through BGP, is set a community to 10796:666 This was setup as Time Warner Cable but is Spectrum today. The people I spoke with had been with Time Warner Cable for years before the acquisition/name change. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Dec 23, 2018 at 12:53 AM Josh Luthman wrote: > Attack is back on. If there's anyone out there that works at Spectrum and > can do a route change and hopefully share some info on BGP communities I > would greatly appreciate hearing from you. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Sun, Dec 23, 2018, 12:12 AM Tim Warnock >> > That’s where you confuse me Josh, if you do BGP with them wouldn’t it be >> > your advertisement to them that’s causing them to route to you. In >> other >> > words, aren’t they only routing packets to you for prefixes that you >> advertise >> > via BGP to them? >> >> Unless of course the point-to-point between spectrum and Josh is under >> attack...? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Sun Dec 23 15:32:02 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 23 Dec 2018 07:32:02 -0800 Subject: Spectrum technical contact In-Reply-To: References: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> Message-ID: <1694d7da-09ab-b6c3-c915-aee78ab96d07@rollernet.us> On 12/22/18 11:28 PM, Josh Luthman wrote: > Got a hold of someone, finally!  All you have to do, if it's done > through BGP, is set a community to 10796:666 > > This was setup as Time Warner Cable but is Spectrum today.  The people I > spoke with had been with Time Warner Cable for years before the > acquisition/name change. > Yeah but you can't just call it "spectrum" because there's at least 3 totally different AS numbers that could be called that. Call them TWC or by their AS number for faster results. From aaron1 at gvtc.com Sun Dec 23 17:13:46 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sun, 23 Dec 2018 11:13:46 -0600 Subject: Spectrum technical contact In-Reply-To: References: <95ebcda6744a4477a52eb6011eb645e5@timoid.org> Message-ID: <8AD261B5-7B08-4076-941D-8ED2086956B6@gvtc.com> I’m glad you got it figured out with the right people at spectrum. When I was sitting up ddos rtbh with my 3 isp’s , I remember spectrum (fka twc/charter) was difficult to get the right person on the phone to help me understand what I needed to do. I had to go through layers of phone attendants and groups to get to someone who knew about ddos rtbh. Btw, I’ve wondered about using sp-neutral(agnostic) forms of ddos rtbh... maybe cymru utrs combined with fastnetmon for immediate mitigation without human intervention. I’d really like to get there. Aaron > On Dec 23, 2018, at 1:28 AM, Josh Luthman wrote: > > Got a hold of someone, finally! All you have to do, if it's done through BGP, is set a community to 10796:666 > > This was setup as Time Warner Cable but is Spectrum today. The people I spoke with had been with Time Warner Cable for years before the acquisition/name change. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > >> On Sun, Dec 23, 2018 at 12:53 AM Josh Luthman wrote: >> Attack is back on. If there's anyone out there that works at Spectrum and can do a route change and hopefully share some info on BGP communities I would greatly appreciate hearing from you. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >>> On Sun, Dec 23, 2018, 12:12 AM Tim Warnock >> > That’s where you confuse me Josh, if you do BGP with them wouldn’t it be >>> > your advertisement to them that’s causing them to route to you. In other >>> > words, aren’t they only routing packets to you for prefixes that you advertise >>> > via BGP to them? >>> >>> Unless of course the point-to-point between spectrum and Josh is under attack...? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Mon Dec 24 20:08:40 2018 From: dot at dotat.at (Tony Finch) Date: Mon, 24 Dec 2018 20:08:40 +0000 Subject: Stupid Question maybe? In-Reply-To: <71cb2337-d9bc-34a8-c914-9bbb843f1e73@joelhalpern.com> References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <71cb2337-d9bc-34a8-c914-9bbb843f1e73@joelhalpern.com> Message-ID: > On 18 Dec 2018, at 22:30, Joel Halpern wrote: > > History of non-contiguous network masks, as I observed it. [snip] > > When we were done, other folks looked at the work (I don't know if the Internet Drafts are still in repositories, but they shoudl be.) And concluded that while this would work, no network operations staff would ever be able to do it correctly. So as a community we decided not to go down that path. In the late 1990s I was doing web server things at Demon Internet. Our “Homepages” service provided an IP-based virtual host for each customer (it predated widespread support for HTTP Host: headers), and by the time I joined the service had two /18s and a /16 of web sites (if my memory is correct). We were allocating addresses to customers sequentially, so the /18s were full and the /16 was in progress. We had a small number of front-end Squid reverse proxy caches which owned all the IP addresses, using a BSD kernel hack (which I worked on to get published but it never got committed upstream https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071) The problem was that the entirely static load spreading relied on the routing config upstream from the reverse proxies, and IIRC it just divided the space into /18s and allocated them to proxies. So the load allocation was very uneven. I thought up a cunning hack, to divide the /16 by using a non-contiguous netmask of 0xffff0003 instead of 0xffffc000, so that successive customers would be allocated to front ends 0,1,2,3 cyclically. Fun :-) But I observed that one of my colleagues had a CIDR chart stuck on the side of his monitor, and that all the documentation in this area warned of dragons and bugs, and I realised that it would be unwise to do more than try it out experimentally :-) Tony. -- f.anthony.n.finch http://dotat.at -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuckchurch at gmail.com Wed Dec 26 13:56:26 2018 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 26 Dec 2018 08:56:26 -0500 Subject: Stupid Question maybe? In-Reply-To: References: <20181218195007.GB52359@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40318ECD189@WAUPRDMBXP1.medline.com> <026801d4971e$ce1e6ae0$6a5b40a0$@iname.com> <71cb2337-d9bc-34a8-c914-9bbb843f1e73@joelhalpern.com> Message-ID: When I first started working with Cisco products (around 1999) I came upon a router doing NAT for internet access that used a discontiguous mask to determine which address to PAT the hosts against as they were doing some creative load balancing. It worked really well, no matter what part of the 'block' the DHCP server gave inside addresses out to. I was stumped for the longest time trying to figure out what this did. Chuck On Mon, Dec 24, 2018 at 3:11 PM Tony Finch wrote: > > On 18 Dec 2018, at 22:30, Joel Halpern wrote: > > History of non-contiguous network masks, as I observed it. [snip] > > When we were done, other folks looked at the work (I don't know if the > Internet Drafts are still in repositories, but they shoudl be.) And > concluded that while this would work, no network operations staff would > ever be able to do it correctly. So as a community we decided not to go > down that path. > > > In the late 1990s I was doing web server things at Demon Internet. Our > “Homepages” service provided an IP-based virtual host for each customer (it > predated widespread support for HTTP Host: headers), and by the time I > joined the service had two /18s and a /16 of web sites (if my memory is > correct). We were allocating addresses to customers sequentially, so the > /18s were full and the /16 was in progress. > > We had a small number of front-end Squid reverse proxy caches which owned > all the IP addresses, using a BSD kernel hack (which I worked on to get > published but it never got committed upstream > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071) > > The problem was that the entirely static load spreading relied on the > routing config upstream from the reverse proxies, and IIRC it just divided > the space into /18s and allocated them to proxies. So the load allocation > was very uneven. > > I thought up a cunning hack, to divide the /16 by using a non-contiguous > netmask of 0xffff0003 instead of 0xffffc000, so that successive customers > would be allocated to front ends 0,1,2,3 cyclically. Fun :-) > > But I observed that one of my colleagues had a CIDR chart stuck on the > side of his monitor, and that all the documentation in this area warned of > dragons and bugs, and I realised that it would be unwise to do more than > try it out experimentally :-) > > Tony. > -- > f.anthony.n.finch http://dotat.at > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseemch at gmail.com Sun Dec 23 17:55:21 2018 From: aseemch at gmail.com (Aseem Choudhary) Date: Sun, 23 Dec 2018 09:55:21 -0800 Subject: Stupid Question maybe? Message-ID: Hi Christian, Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2. You can refer below link for details: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620 Regards, Aseem On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti > wrote: >* On Wed, 19 Dec 2018 at 02:55, Philip Loenneker *>* > wrote: *>>* > I had a heck of a time a few years back trying to troubleshoot an issue *>* where an upstream provider had an ACL with an incorrect mask along the *>* lines of 255.252.255.0. That was really interesting to talk about once we *>* discovered it, though it caused some loss of hair beforehand... *>>* Juniper originally didn't support them even in ACL use-case but were *>* forced to add later due to customer demand, so people do have *>* use-cases for them. If we'd still support them in forwarding, I'm sure *>* someone would come up with solution which depends on it. I am not *>* advocating we should, I'll rather take my extra PPS out of the HW. *>>* However there is one quite interesting use-case for discontinuous mask *>* in ACL. If you have, like you should have, specific block for customer *>* linknetworks, you can in iACL drop all packets to your side of the *>* links while still allowing packets to customer side of the links, *>* making attack surface against your network minimal. * And unfortunately is still not supported by IOS-XR for IPv6, which could mean not having a scaleable way on your edge to protect your internal network. -- Christian e-mail/xmpp: christian at errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ - Previous message (by thread): Stupid Question maybe? - Next message (by thread): Stupid Question maybe? - *Messages sorted by:* [ date ] [ thread ] [ subject ] [ author ] ------------------------------ More information about the NANOG mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From melchior at aelmans.eu Tue Dec 25 13:24:26 2018 From: melchior at aelmans.eu (Melchior Aelmans) Date: Tue, 25 Dec 2018 14:24:26 +0100 Subject: [EXTERNAL] Re: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: QFX10k is the AD in Fusion Datacenter. In a Fusion Edge setup it is MX. On Fri, Dec 21, 2018 at 8:21 PM Nikos Leontsinis < Nikos.Leontsinis at eu.equinix.com> wrote: > There is a fundamental product limitation. CoS on Cascade port for MX is > not officially supported as well QFX acting as AD. > > I agree with those who perceive all these approaches as > proprietary lock-in (disguised as cheap). > > > > *From:* NANOG *On Behalf Of *Vincentz Petzholtz > *Sent:* Wednesday, December 19, 2018 9:01 AM > *To:* nanog > *Subject:* [EXTERNAL] Re: JunOS Fusion Provider Edge > > > > Hi there, > > > > About Juniper Fusion PE and our experience with it. > > > > For example, you can't get SNMP oids for light levels or even read them > right from the CLI. > > Sure it’s possible but also with a big „meh“. Here is how: > > "show interfaces diagnostics optics satellite “ (<- on the MX) > > BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these > values are wrong > > by a pretty big offset. Juniper promised they already fixed it but we > can’t confirm (at least not in MX Junos 16.1). > > Soon we will take a look at MX Junos 17.3 with aligned sat image. > > > > I've also heard you can have them do local L2 forwarding, which can be > nice for latency and conserving uplink bandwidth, but we don't do any L2 > that way so I wouldn't know the implications > > Same thing here … we don’t really need it. At least it’s on the roadmap > and/or already implemented with higher Junos/SNOS versions. > > > > From what we can tell though, it does give you Trio L3 performance and > features with a MUCH cheaper port cost which is exactly what we were > looking for, the extended reach of the chassis was just a fantastic bonus. > > Yep, that is really amazing and the reason we use it on many MXes. You can > get rid of almost all ports you want (restrictions apply tho). > > > > We also REALLY like that we can have one pair of MX dists for a whole data > center with hundreds of thousands of square feet of raised floor and deploy > QFX5100 or EX4300 switches in every pod and haul back over just a few pairs > of fiber. Saves a lot of time because all that's required to turn up a new > connection is a cross connect in the pod. It also allows us to offer copper > ports very far away from the MX device, which would normally require media > converters. > > We use Junos PE NOT as a replacement for any switch and/or ip fabrics > within a datacenter. We use it to get rid of many customer/client ports > (mainly 1G and 10G ports) > > which were directly connected to our MXes before. Atm I would not > recommend using any closed fabrics beyond that scope. If it works for you … > ok. > > > > We've wanted to experiment with doing this over dark fiber in the metro as > well, but we want to feel out any kinks locally before we add additional > failure modes. > > At the moment? Don’t do it. If you run mpls on so called „core > router/dwdm/wan facing ports“ you have to know that this is totally not > supported on extended satellite ports. > > It’s not even on the roadmap. I already started to „collect“ some other > ISPs to push juniper towards this feature because technically there no > > real reason why fusion should NOT be capable of pushing some mpls labels > on already tagged 802.1br packets. > > > > Best regards, > > Vincentz > > — > > PS: some have received this mail multiple times because I’ve send it from > the wrong account … time for vacation I guess. > > > > Am 17.12.2018 um 19:26 schrieb Matt Erculiani : > > > > Fusion has made a lot more sense since Juniper changed the licensing model > from every switch AND the MX to just the MX. > > > > We've deployed it in some of our sites. It is very cool from a forwarding > plane perspective, but from a control plane standpoint it's very...meh. For > example, you can't get SNMP oids for light levels or even read them right > from the CLI. You have to log into the satellite switch like you would log > into an FPC just to get light levels. That's probably the dumbest thing > we've dealt with though. I've also heard you can have them do local L2 > forwarding, which can be nice for latency and conserving uplink bandwidth, > but we don't do any L2 that way so I wouldn't know the implications. From > what we can tell though, it does give you Trio L3 performance and features > with a MUCH cheaper port cost which is exactly what we were looking for, > the extended reach of the chassis was just a fantastic bonus. > > > > We also REALLY like that we can have one pair of MX dists for a whole data > center with hundreds of thousands of square feet of raised floor and deploy > QFX5100 or EX4300 switches in every pod and haul back over just a few pairs > of fiber. Saves a lot of time because all that's required to turn up a new > connection is a cross connect in the pod. It also allows us to offer copper > ports very far away from the MX device, which would normally require media > converters. > > > > We've wanted to experiment with doing this over dark fiber in the metro as > well, but we want to feel out any kinks locally before we add additional > failure modes. > > > > Very interested in hearing about other's experiences with Fusion, good, > bad, and ugly. > > > > -Matt > > > > On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin wrote: > > Hey there > > > > Any ISP using Juniper Fusion Provider Edge? > > > > > https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html > > > > > > I am trying to chat with an engineer besides Juniper engineers to > understand how buggy (or not) this is to go on production for a medium size > ISP. > > > > Any feedback good/bad appreciated. > > -- > > Mehmet > +1-424-298-1903 > > > This email is from Equinix (EMEA) B.V. or one of its associated companies > in the territory from where this email has been sent. This email, and any > files transmitted with it, contains information which is confidential, is > solely for the use of the intended recipient and may be legally privileged. > If you have received this email in error, please notify the sender and > delete this email immediately. Equinix (EMEA) B.V.. Registered Office: > Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The > Netherlands No. 57577889. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James at arenalgroup.co Wed Dec 26 18:17:01 2018 From: James at arenalgroup.co (James Breeden) Date: Wed, 26 Dec 2018 18:17:01 +0000 Subject: routeviews.org pending delete In-Reply-To: <6A608DE9-6A0B-4A3B-B822-9421E470C822@routeviews.org> References: <6A608DE9-6A0B-4A3B-B822-9421E470C822@routeviews.org> Message-ID: Eric Is this ownership /steward change why I haven't been able to reach anyone at Routeviews via the web or help addresses recently? I've been trying to set up some new multi hop sessions for a couple networks I operate. Thanks James Sent via the Samsung Galaxy Note9, an AT&T 4G LTE smartphone -------- Original message -------- From: Eric Smith Date: 12/21/18 1:25 PM (GMT-06:00) To: nanog at nanog.org Subject: RE: routeviews.org pending delete Hey folks, Thanks for the heads-up, we've already been working through this with Network Solutions. The project has switched stewards recently and the renewal notification got lost in the transition. The NS records should point back to the correct routeviews.org address now. We're also working through the permanent transfer of ownership to avoid this in the future. Eric -------- Forwarded Message -------- Subject: RE: routeviews.org pending delete Date: Thu, 20 Dec 2018 17:29:03 +0000 From: David Guo via NANOG Reply-To: David Guo To: Siyuan Miao , nanog at nanog.org It’s your cache resule root at server ~ # whois routeviews.org Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T18:54:32Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Registrant State/Province: OR Registrant Country: US Name Server: GUELAH.SHRUBBERY.NET Name Server: PHLOEM.UOREGON.EDU DNSSEC: unsigned From: NANOG On Behalf Of Siyuan Miao Sent: Monday, December 17, 2018 8:34 PM To: nanog at nanog.org Subject: routeviews.org pending delete All, routeviews.org is pending delete now. Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T09:33:18Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Network Solutions LLC Registrant State/Province: FL Registrant Country: US Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/) >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. I was wondering if there is anyone here can contact them to renew it if this project is still alive. Regards, Siyuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From James at arenalgroup.co Wed Dec 26 20:02:13 2018 From: James at arenalgroup.co (James Breeden) Date: Wed, 26 Dec 2018 20:02:13 +0000 Subject: routeviews.org pending delete In-Reply-To: References: <6A608DE9-6A0B-4A3B-B822-9421E470C822@routeviews.org> Message-ID: Kudos to Eric for finding my inquiry and getting us all up and running on Routeviews. Thanks! From: NANOG On Behalf Of James Breeden Sent: Wednesday, December 26, 2018 12:17 PM To: Eric Smith ; nanog at nanog.org Subject: Re: routeviews.org pending delete Eric Is this ownership /steward change why I haven't been able to reach anyone at Routeviews via the web or help addresses recently? I've been trying to set up some new multi hop sessions for a couple networks I operate. Thanks James Sent via the Samsung Galaxy Note9, an AT&T 4G LTE smartphone -------- Original message -------- From: Eric Smith > Date: 12/21/18 1:25 PM (GMT-06:00) To: nanog at nanog.org Subject: RE: routeviews.org pending delete Hey folks, Thanks for the heads-up, we've already been working through this with Network Solutions. The project has switched stewards recently and the renewal notification got lost in the transition. The NS records should point back to the correct routeviews.org address now. We're also working through the permanent transfer of ownership to avoid this in the future. Eric -------- Forwarded Message -------- Subject: RE: routeviews.org pending delete Date: Thu, 20 Dec 2018 17:29:03 +0000 From: David Guo via NANOG > Reply-To: David Guo > To: Siyuan Miao >, nanog at nanog.org > It's your cache resule root at server ~ # whois routeviews.org Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T18:54:32Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Registrant State/Province: OR Registrant Country: US Name Server: GUELAH.SHRUBBERY.NET Name Server: PHLOEM.UOREGON.EDU DNSSEC: unsigned From: NANOG > On Behalf Of Siyuan Miao Sent: Monday, December 17, 2018 8:34 PM To: nanog at nanog.org Subject: routeviews.org pending delete All, routeviews.org is pending delete now. Domain Name: ROUTEVIEWS.ORG Registry Domain ID: D48496876-LROR Registrar WHOIS Server: whois.networksolutions.com Registrar URL: http://www.networksolutions.com Updated Date: 2018-12-17T09:33:18Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2019-12-14T23:05:47Z Registrar Registration Expiration Date: Registrar: Network Solutions, LLC Registrar IANA ID: 2 Registrar Abuse Contact Email: abuse at web.com Registrar Abuse Contact Phone: +1.8003337680 Reseller: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant Organization: Network Solutions LLC Registrant State/Province: FL Registrant Country: US Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/) >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<< routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com. routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com. I was wondering if there is anyone here can contact them to renew it if this project is still alive. Regards, Siyuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From masoodnt10 at gmail.com Wed Dec 26 23:24:47 2018 From: masoodnt10 at gmail.com (Masood Ahmad Shah) Date: Wed, 26 Dec 2018 15:24:47 -0800 Subject: Comcast's business internet support Message-ID: Hi there - If someone from Comcast who is smarter than their business support team could contact me off list, that would be great. There appears to be very high consistent packet loss for last 3 to 4 days and that is affecting my internet, You business support team keep insisting on sending an onsite tech. I explained that I don't believe that will resolve this issue (There is no evidence of an issue with the lines or signal levels) and it's a packet loss inside Comcast network, most likely aggregation/backhaul. Thanks in advance. Cheers, Masood -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Wed Dec 26 23:35:47 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 26 Dec 2018 15:35:47 -0800 Subject: Comcast's business internet support In-Reply-To: References: Message-ID: On 12/26/18 15:24, Masood Ahmad Shah wrote: > > You business support team keep insisting on sending an onsite tech. I > explained that I don't believe that will resolve this issue (There is no > evidence of an issue with the lines or signal levels) and it's a packet > loss inside Comcast network, most likely aggregation/backhaul. The easiest way forward is to let them send the tech out. That's the script. From tknchris at gmail.com Wed Dec 26 23:57:18 2018 From: tknchris at gmail.com (chris) Date: Wed, 26 Dec 2018 18:57:18 -0500 Subject: Comcast's business internet support In-Reply-To: References: Message-ID: im guessing this is going to be one of those posts where mtr told him the ip of the CMTS or another inside hop has loss because it deprioritizes/rate limits ICMP :) On Wed, Dec 26, 2018 at 6:37 PM Seth Mattinen wrote: > On 12/26/18 15:24, Masood Ahmad Shah wrote: > > > > You business support team keep insisting on sending an onsite tech. I > > explained that I don't believe that will resolve this issue (There is no > > evidence of an issue with the lines or signal levels) and it's a packet > > loss inside Comcast network, most likely aggregation/backhaul. > > > The easiest way forward is to let them send the tech out. That's the > script. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masoodnt10 at gmail.com Wed Dec 26 23:57:26 2018 From: masoodnt10 at gmail.com (Masood Ahmad Shah) Date: Wed, 26 Dec 2018 15:57:26 -0800 Subject: Comcast's business internet support In-Reply-To: References: Message-ID: Thanks, Seth! I got a quick response from someone at Comcast. Cheers, On Wed, Dec 26, 2018 at 3:36 PM Seth Mattinen wrote: > On 12/26/18 15:24, Masood Ahmad Shah wrote: > > > > You business support team keep insisting on sending an onsite tech. I > > explained that I don't believe that will resolve this issue (There is no > > evidence of an issue with the lines or signal levels) and it's a packet > > loss inside Comcast network, most likely aggregation/backhaul. > > > The easiest way forward is to let them send the tech out. That's the > script. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masoodnt10 at gmail.com Thu Dec 27 00:22:46 2018 From: masoodnt10 at gmail.com (Masood Ahmad Shah) Date: Wed, 26 Dec 2018 16:22:46 -0800 Subject: Comcast's business internet support In-Reply-To: References: Message-ID: Nah this does not seem to be related to ICMP throttling. I do observe a significant service degradation when browsing/streaming various well known applications (feels like 56K modem :P) There is a packet loss which is leading to excessive TCP retrans/dup acks. Cheers, Masood On Wed, Dec 26, 2018 at 3:58 PM chris wrote: > im guessing this is going to be one of those posts where mtr told him the > ip of the CMTS or another inside hop has loss because it deprioritizes/rate > limits ICMP :) > > On Wed, Dec 26, 2018 at 6:37 PM Seth Mattinen wrote: > >> On 12/26/18 15:24, Masood Ahmad Shah wrote: >> > >> > You business support team keep insisting on sending an onsite tech. I >> > explained that I don't believe that will resolve this issue (There is >> no >> > evidence of an issue with the lines or signal levels) and it's a packet >> > loss inside Comcast network, most likely aggregation/backhaul. >> >> >> The easiest way forward is to let them send the tech out. That's the >> script. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Thu Dec 27 16:33:16 2018 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 27 Dec 2018 16:33:16 -0000 Subject: rfd In-Reply-To: References: Message-ID: <006601d49e01$de5cb300$9b161900$@netconsultings.com> > Randy Bush > Sent: Tuesday, December 18, 2018 5:40 PM > > do you have rfd on? with what parms? > > randy If I remember correctly the industry was back and forth on this several times now. First it was deemed good then some studies came out proving the penalty is worse than the crime couple years later another study came out suggesting that if correct parameters are used it should be alright, but I guess at that time no one could have cared less already switching it on and off and on again... With regards to the comments made here on the number of unstable routes till the whole system or significant parts collapse, I could easily revert that argument and ask how many badly configured rfd till the whole system shuts/dampens itself down... (positive vs negative feedback loop) I guess the ideal solution is somewhere in between. Personally I think rfd is just the aspirin, i.e. not treating the cause -but merely helping with the headaches. And I suspect that Interface State Dampening would address 80% of the route-flaps out there (it works exactly like rfd but treats the cause). With the reminder being true protocol flaps either by misconfiguration of max prefix limit (sessions should stay down) or BGP error handling -which again can be solved by the enhanced BGP error handling or genuine bugs. adam From mspring at nktelco.com Wed Dec 26 21:39:07 2018 From: mspring at nktelco.com (Mark Spring) Date: Wed, 26 Dec 2018 16:39:07 -0500 Subject: Hulu Location issues - Altering IP Locations per Subnet Message-ID: Does anybody have any advise on how to adjust the location for subnet ranges with Arin allocations? We have customers across a somewhat diverse area and Hulu is rejecting some of their requests saying they are essentially in another market for local channels. If anybody has dealt with this and came up with another solution, I am open to suggestions at this point! Thank you, Mark Spring Information Systems Manager -- NKTelco 301 W. South St.New Knoxville, OH 45871 Phone: 1-888-NKTELCO Fax: 419-753-2950 This message and the file(s) attached are confidential and proprietary information of NKTelco for the sole use of the intended recipient. Any  unauthorized review, distribution, disclosure, copying, use, or  dissemination, either whole or in part, is strictly prohibited. Do not  transmit these documents, in any form, to any third party without the  expressed written permission of NKTelco. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Thu Dec 27 17:36:44 2018 From: david at xtom.com (David Guo) Date: Thu, 27 Dec 2018 17:36:44 +0000 Subject: Hulu Location issues - Altering IP Locations per Subnet In-Reply-To: References: Message-ID: No idea about what IP database Hulu uses, you'd better contact them and update your location information on Maxmind, IPLocation, etc. David From: NANOG On Behalf Of Mark Spring Sent: Thursday, December 27, 2018 5:39 AM To: nanog at nanog.org Subject: Hulu Location issues - Altering IP Locations per Subnet Does anybody have any advise on how to adjust the location for subnet ranges with Arin allocations? We have customers across a somewhat diverse area and Hulu is rejecting some of their requests saying they are essentially in another market for local channels. If anybody has dealt with this and came up with another solution, I am open to suggestions at this point! Thank you, Mark Spring Information Systems Manager NKTelco 301 W. South St. New Knoxville, OH 45871 Phone: 1-888-NKTELCO Fax: 419-753-2950 This message and the file(s) attached are confidential and proprietary information of NKTelco for the sole use of the intended recipient. Any unauthorized review, distribution, disclosure, copying, use, or dissemination, either whole or in part, is strictly prohibited. Do not transmit these documents, in any form, to any third party without the expressed written permission of NKTelco. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu Dec 27 18:45:48 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 27 Dec 2018 18:45:48 +0000 Subject: CenturyLink Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrickboyle at protonmail.com Thu Dec 27 18:51:07 2018 From: patrickboyle at protonmail.com (Patrick Boyle) Date: Thu, 27 Dec 2018 18:51:07 +0000 Subject: CenturyLink In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> Message-ID: <4cdXCZn0Oe1SoFUEa26XPh9gdiMnhsv-iXbnn2oe4W6mk3FVAgo694i04Biuj38yr6NeULHglvh5m7aqD1l-mNvF9zUjCgGkM7X-WlnzK3Q=@protonmail.com> Seeing the same from here in Montana. Internet traffic is seeing routing issues through them on the circuits that are up. I’ve heard it’s a widespread DWDM issue. They have crews in Kansas City, New Orleans, and Atlanta Sent from ProtonMail Mobile On Thu, Dec 27, 2018 at 11:45 AM, Naslund, Steve wrote: > Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. > > Steven Naslund > > Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Dec 27 19:00:41 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 27 Dec 2018 12:00:41 -0700 Subject: CenturyLink In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> Message-ID: Seeing it in Colorado as well. > On Dec 27, 2018, at 11:45 AM, Naslund, Steve wrote: > > Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. > > Steven Naslund > Chicago IL From nanog at ics-il.net Thu Dec 27 19:34:04 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 27 Dec 2018 13:34:04 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> Message-ID: <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> I guess today shows how important vendor diversity can be. :-) ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "Mike Hammett" Cc: "Ben Cannon" , "nanog" Sent: Monday, December 17, 2018 2:51:38 PM Subject: Re: How to choose a transport(terrestrial/subsea) Back to main discussion.... How do we choose the best transport? One question, how much people care about vendor diversity? I do and did care. I don’t want to put all my eggs in one basket. Do you care? Thank you Mehmet On Sat, Dec 15, 2018 at 11:30 Mike Hammett < nanog at ics-il.net > wrote: I haven't. Sure, but the equipment still does smaller channels. Going to 100G or 400G for just over 10G seems silly. If Equinix had reasonable cross connects, I'd just LAG 10Gs. The cost of a pair of Equinix cross connects isn't much less than the 10G wave. Thankfully I'm only in one datacenter with such a ridiculous model. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Ben Cannon" < ben at 6by7.net > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog" < nanog at nanog.org > Sent: Saturday, December 15, 2018 1:27:21 PM Subject: Re: How to choose a transport(terrestrial/subsea) Mike have you looked at Packetlight? Long-haul is mostly jumping to 100 or even 400g coherent. -Ben On Dec 15, 2018, at 8:53 AM, Mike Hammett < nanog at ics-il.net > wrote:
FS had one, but it's not on their site anymore. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Luke Guillory" < lguillory at reservetele.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Eric Dugas" < edugas at unknowndevice.ca >, "nanog" < nanog at nanog.org > Sent: Saturday, December 15, 2018 10:52:19 AM Subject: Re: How to choose a transport(terrestrial/subsea) No cost affective 10x10G to 100G muxponder? Sent from my iPad On Dec 15, 2018, at 4:46 AM, Mike Hammett < nanog at ics-il.net > wrote:
heh, cross connects are indeed a major issue. I have a need for > 10G transport. My equipment supports 40G. The carriers aren't terribly interested in doing 40G transport (at least not at a reasonable price, one quote was over 4x a 10G). 100G-capable switches cost too much. Equinix charges as much for a pair of cross connects as a 10G wave. Carriers aren't likely to be interested in using bidi optics or passive WDM to overcome the ridiculous cross connect charges. This all complicates how one chooses transport. There's no easy path forward. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Eric Dugas" < edugas at unknowndevice.ca > To: "Mehmet Akcin" < mehmet at akcin.net > Cc: "nanog" < nanog at nanog.org > Sent: Friday, December 14, 2018 11:42:53 AM Subject: Re: How to choose a transport(terrestrial/subsea) I also look at hand-off locations (as long as it doesn't compromise the overall robustness of the design). Most providers will be able to hand-off in the BMMR of a carrier hotel and some will have the flexibility to hand-off in particular suites within the same building or other locations near where the cross-connects fees are lower. I've seen cross-connect fees between $50 up to $750 MRC so if you need multiple wavelengths (for capacity), the cross-connect fees are going to make a huge difference on the total MRC. Eric Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Dec 14 2018, at 12:17 pm, Mehmet Akcin < mehmet at akcin.net > wrote:
Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903
-- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmburgess at linktechs.net Thu Dec 27 20:00:08 2018 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 27 Dec 2018 20:00:08 +0000 Subject: CenturyLink In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> Message-ID: <95957661800c4817b5005d18db2bd85d@linktechs.net> National outage since 4:33 am this morning.. [LTI-Full_175px] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage's with www.towercoverage.com From: NANOG On Behalf Of Naslund, Steve Sent: Thursday, December 27, 2018 12:46 PM To: nanog at nanog.org Subject: CenturyLink Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Thu Dec 27 20:13:25 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 27 Dec 2018 20:13:25 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> Message-ID: The outage list already has a long thread on this. https://puck.nether.net/mailman/listinfo/outages From: NANOG > On Behalf Of Dennis Burgess via NANOG Sent: Thursday, December 27, 2018 2:00 PM To: Naslund, Steve >; nanog at nanog.org Subject: RE: CenturyLink National outage since 4:33 am this morning.. [LTI-Full_175px] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage's with www.towercoverage.com From: NANOG > On Behalf Of Naslund, Steve Sent: Thursday, December 27, 2018 12:46 PM To: nanog at nanog.org Subject: CenturyLink Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. Steven Naslund Chicago IL ________________________________ 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 Steve.Coker at flydenver.com Thu Dec 27 20:16:59 2018 From: Steve.Coker at flydenver.com (Coker, Steve - DEN) Date: Thu, 27 Dec 2018 20:16:59 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> Message-ID: Seems like things have stabilized as of about an hour ago for us. [DIA Logo] STEVE COKER Senior Manager of Network Infrastructure - Business Technologies Denver International Airport Technologies | Concourse A From: NANOG On Behalf Of Erik Sundberg Sent: Thursday, December 27, 2018 1:13 PM To: NANOG Subject: RE: CenturyLink The outage list already has a long thread on this. https://puck.nether.net/mailman/listinfo/outages From: NANOG > On Behalf Of Dennis Burgess via NANOG Sent: Thursday, December 27, 2018 2:00 PM To: Naslund, Steve >; nanog at nanog.org Subject: RE: CenturyLink National outage since 4:33 am this morning.. [LTI-Full_175px] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage's with www.towercoverage.com From: NANOG > On Behalf Of Naslund, Steve Sent: Thursday, December 27, 2018 12:46 PM To: nanog at nanog.org Subject: CenturyLink Anyone have any insight to the nationwide CenturyLink issues/outages today? Just wondering. Know for sure that our connections to them from Florida, Iowa, and Washington State are all affected. Voice and data. Steven Naslund Chicago IL ________________________________ 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 SNaslund at medline.com Thu Dec 27 20:24:07 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 27 Dec 2018 20:24:07 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED1F67@WAUPRDMBXP1.medline.com> We see slow recovery. Dallas data service came back up, Dubuque voice service still down. Steven Naslund Chicago IL > >Seems like things have stabilized as of about an hour ago for us. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Dec 27 21:39:07 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 28 Dec 2018 00:39:07 +0300 Subject: CenturyLink In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED1F67@WAUPRDMBXP1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <9578293AE169674F9A048B2BC9A081B40318ED1F67@WAUPRDMBXP1.medline.com> Message-ID: Today Level3/CenturyLink is having a major outage. This is a great example of how much diversity matter. How important to plan your network right. These type of outages can happen to anyone. this is time to understand better how important it is to plan your network resiliency and diversity. This is also time to unite as telecom industry to learn from this big outage that impacted many. I hope technical team will share their learnings in NANOG or blog so others will learn from it. Good luck Engineering/Ops teams who are working on restoration. Thank you On Thu, Dec 27, 2018 at 23:24 Naslund, Steve wrote: > We see slow recovery. Dallas data service came back up, Dubuque voice > service still down. > > > > Steven Naslund > > Chicago IL > > > > > > > >Seems like things have stabilized as of about an hour ago for us. > > > > > > > > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Fri Dec 28 02:35:04 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Dec 2018 13:35:04 +1100 Subject: ECN, DNS and Firewalls Message-ID: <2FCD64DB-CB9B-4C7C-B921-4946E6365ADE@isc.org> There are major operators that still have STUPID firewall settings in front of DNS servers that drop SYN packets with ECE and CWR set 17 years after ECN was specified. Do you really want to add a second to EVERY DNS lookup that needs to use TCP? Modern OS actually attempt to use ECN by default. DNS is time critical enough without introducing unnecessary delays. If you have signed zones then TCP requests are almost certainly being made to your servers. EVERYONE TEST YOUR SERVERS FROM OUTSIDE YOUR NETWORK AND FIX THE BROKEN FIREWALLS THAT ARE FOUND. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From valdis.kletnieks at vt.edu Fri Dec 28 03:49:53 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 27 Dec 2018 22:49:53 -0500 Subject: ECN, DNS and Firewalls In-Reply-To: <2FCD64DB-CB9B-4C7C-B921-4946E6365ADE@isc.org> References: <2FCD64DB-CB9B-4C7C-B921-4946E6365ADE@isc.org> Message-ID: <7454.1545968993@turing-police.cc.vt.edu> On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said: > There are major operators that still have STUPID firewall settings > in front of DNS servers that drop SYN packets with ECE and CWR set > 17 years after ECN was specified. Time to name-n-shame? From marka at isc.org Fri Dec 28 04:07:37 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Dec 2018 15:07:37 +1100 Subject: ECN, DNS and Firewalls In-Reply-To: <7454.1545968993@turing-police.cc.vt.edu> References: <2FCD64DB-CB9B-4C7C-B921-4946E6365ADE@isc.org> <7454.1545968993@turing-police.cc.vt.edu> Message-ID: <1CD5C5EF-76E4-4D0F-8C1D-B6862B6DBAAF@isc.org> > On 28 Dec 2018, at 2:49 pm, valdis.kletnieks at vt.edu wrote: > > On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said: >> There are major operators that still have STUPID firewall settings >> in front of DNS servers that drop SYN packets with ECE and CWR set >> 17 years after ECN was specified. > > Time to name-n-shame? No yet. Let people test and fix their firewalls first. A test machine should be sending [SEW] and getting back [S.E] or [S.] in the TCP flags using tcpdump depending upon whether the DNS server’s TCP stack supports ECN or not. e.g. 11:35:50.335713 IP6 2001:470:a001:3:f1f2:b12d:4b18:d934.50670 > 2001:7fe::53.53: Flags [SEW], seq 3764146938, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 522561237 ecr 0,sackOK,eol], length 0 11:35:50.745472 IP6 2001:7fe::53.53 > 2001:470:a001:3:f1f2:b12d:4b18:d934.50670: Flags [S.E], seq 1542147586, ack 3764146939, win 14280, options [mss 1440,sackOK,TS val 1392826170 ecr 522561237,nop,wscale 7], length 0 or 11:40:35.360655 IP6 2001:470:a001:3:f1f2:b12d:4b18:d934.50697 > 2001:502:8cc::30.53: Flags [SEW], seq 81498720, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 522845405 ecr 0,sackOK,eol], length 0 11:40:35.589420 IP6 2001:502:8cc::30.53 > 2001:470:a001:3:f1f2:b12d:4b18:d934.50697: Flags [S.], seq 987294478, ack 81498721, win 1220, options [mss 1220], length 0 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bruns at 2mbit.com Fri Dec 28 06:16:20 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 27 Dec 2018 23:16:20 -0700 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> Message-ID: <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> We have interwebs in Boise! At least, on the biz fiber w/ BGP. 720892 ipv4 routes, 62273 ipv6 routes. On 12/27/2018 1:16 PM, Coker, Steve - DEN wrote: > Seems like things have stabilized as of about an hour ago for us. > > DIA Logo > > > > *STEVE COKER*** > > /Senior Manager of Network Infrastructure - Business Technologies/ > > Denver International Airport > > Technologies | Concourse A > > *From:* NANOG *On Behalf Of *Erik Sundberg > *Sent:* Thursday, December 27, 2018 1:13 PM > *To:* NANOG > *Subject:* RE: CenturyLink > > The outage list already has a long thread on this. > > https://puck.nether.net/mailman/listinfo/outages > > ** > > ** > > ** > > *From:* NANOG > > *On Behalf Of *Dennis Burgess via NANOG > *Sent:* Thursday, December 27, 2018 2:00 PM > *To:* Naslund, Steve >; nanog at nanog.org > *Subject:* RE: CenturyLink > > National outage since 4:33 am this morning.. > > ** > > *LTI-Full_175px* > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition” > > *Link Technologies, Inc*-- Mikrotik & WISP Support Services > > *Office*: 314-735-0270  Website: http://www.linktechs.net > > > Create Wireless Coverage’s with www.towercoverage.com > > *From:* NANOG > > *On Behalf Of *Naslund, Steve > *Sent:* Thursday, December 27, 2018 12:46 PM > *To:* nanog at nanog.org > *Subject:* CenturyLink > > Anyone have any insight to the nationwide CenturyLink issues/outages > today?  Just wondering.  Know for sure that our connections to them from > Florida, Iowa, and Washington State are all affected.  Voice and data. > > Steven Naslund > > Chicago IL > > ------------------------------------------------------------------------ > > > 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. > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ESundberg at nitelusa.com Fri Dec 28 07:07:42 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 28 Dec 2018 07:07:42 +0000 Subject: CenturyLink In-Reply-To: <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> Message-ID: Maybe light at the end of the tunnel... latest we got from Centurylink was at 10:45pm CST. Our engineers and technicians have identified the network element that has affected our customer services. Services are restoring, and the current estimated time for full recovery is four hours. CenturyLink will be conducting an extensive post-incident investigation and root cause analysis to provide follow-up information to our customers impacted by this event. We will provide one more Sales Alert from this address once services are fully restored. -----Original Message----- From: NANOG On Behalf Of Brielle Bruns Sent: Friday, December 28, 2018 12:16 AM To: nanog at nanog.org Subject: Re: CenturyLink We have interwebs in Boise! At least, on the biz fiber w/ BGP. 720892 ipv4 routes, 62273 ipv6 routes. On 12/27/2018 1:16 PM, Coker, Steve - DEN wrote: > Seems like things have stabilized as of about an hour ago for us. > > DIA Logo > > > > *STEVE COKER*** > > /Senior Manager of Network Infrastructure - Business Technologies/ > > Denver International Airport > > Technologies | Concourse A > > *From:* NANOG *On Behalf Of *Erik Sundberg > *Sent:* Thursday, December 27, 2018 1:13 PM > *To:* NANOG > *Subject:* RE: CenturyLink > > The outage list already has a long thread on this. > > https://puck.nether.net/mailman/listinfo/outages > > ** > > ** > > ** > > *From:* NANOG > *On Behalf Of *Dennis Burgess via > NANOG > *Sent:* Thursday, December 27, 2018 2:00 PM > *To:* Naslund, Steve >; nanog at nanog.org > > *Subject:* RE: CenturyLink > > National outage since 4:33 am this morning.. > > ** > > *LTI-Full_175px* > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition" > > *Link Technologies, Inc*-- Mikrotik & WISP Support Services > > *Office*: 314-735-0270 Website: http://www.linktechs.net > > > Create Wireless Coverage's with www.towercoverage.com > > *From:* NANOG > *On Behalf Of *Naslund, Steve > *Sent:* Thursday, December 27, 2018 12:46 PM > *To:* nanog at nanog.org > *Subject:* CenturyLink > > Anyone have any insight to the nationwide CenturyLink issues/outages > today? Just wondering. Know for sure that our connections to them > from Florida, Iowa, and Washington State are all affected. Voice and data. > > Steven Naslund > > Chicago IL > > ---------------------------------------------------------------------- > -- > > > 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. > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ________________________________ 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. From bortzmeyer at nic.fr Fri Dec 28 08:03:53 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 28 Dec 2018 09:03:53 +0100 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> Message-ID: <20181228080353.ilp6ovvrq3eivijf@nic.fr> On Fri, Dec 28, 2018 at 07:07:42AM +0000, Erik Sundberg wrote a message of 131 lines which said: > CenturyLink will be conducting an extensive post-incident > investigation and root cause analysis to provide follow-up > information to our customers Is this problem also responsible for the 911 outage? If so, the post-mortem analysis is not useful only for CenturyLink customers but for everyone on the west coast. From dovid at telecurve.com Fri Dec 28 12:06:36 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 28 Dec 2018 07:06:36 -0500 Subject: Cellular backup connections Message-ID: Hi All, I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. Thanks and sorry in advance if this is off topic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Fri Dec 28 12:19:46 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 28 Dec 2018 12:19:46 +0000 Subject: Cellular backup connections In-Reply-To: References: Message-ID: <89C8926B-554C-4EE8-9F2D-FA98C113E810@dino.hostasaurus.com> I’ve found the antenna choice and placement can make a huge difference in a data center environment. In some cases it required going to a directional high gain antenna pointed towards a desirable tower, which we found by having someone monitor / reload the Opengear web interface while another person moved the antenna around, to figure out where the best signal strength was produced. Ours are all Verizon units, but in data centers near some VZ towers, the little omnidirectional paddle antennas that come with the Opengear boxes have been sufficient, even if the unit is mounted in a rack. Even with ping times being in the 150-300ms range, normally SSH isn’t too bad, but it’s certainly not snappy. I’d say it’s not quite as bad as trying to use SSH via Wifi on a Southwest flight, but not as good as a serial console connection. From: NANOG on behalf of Dovid Bender Date: Friday, December 28, 2018 at 7:08 AM To: NANOG Subject: Cellular backup connections Hi All, I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. Thanks and sorry in advance if this is off topic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Fri Dec 28 12:22:49 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 28 Dec 2018 07:22:49 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: On 12/28/18 7:06 AM, Dovid Bender wrote: > Hi All, > > I finally got around to setting up a cellular backup device in our new > POP. I am currently testing with T-Mobile where the cell signal strength > is at 80%. The connection is 4G. When SSH'ing in remotely the connection > seems rather slow. Ping times seem to be all over the place (for > instance now I am seeing: rtt min/avg/max/mdev = > 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that > more related to the provider and the location where I am? I could in > theory test with VZ and ATT as well. With Verizon they charge $500.00 > just to get a public IP and I want to avoid that if possible. > > Thanks and sorry in advance if this is off topic. LTE with a good connection on a lightly loaded cell should be significantly less than that in both absolute terms as well as jitter. I used LTE (Sprint) for a couple years as my primary connectivity when I moved out into an area with zero connectivity (fixing that now). I typically saw ~30-40ms to Chicago, which is the nearest major carrier PoP. Jitter was typically less than 10ms. VoIP was usable. Others in the area on other carriers have reported similar. Sprint gave me a public IP with no up front charges but did charge $5/mo for it. As you're probably aware, the "signal strength" ("bars") indicators that are presented to the consumer-facing interfaces are often very cooked. Depending on which RSSI you're looking at, a "very good" signal is probably in the realm of -70dBm to -110dBm (note that there are two RSSI metrics commonly used with LTE, and they tend to differ by ~20dB). -- Brandon Martin From dovid at telecurve.com Fri Dec 28 12:29:08 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 28 Dec 2018 07:29:08 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: It's strange. When we use T-Mo on an andriod device the ping times are 30-40 ms. When we try with the modem + raritn console box it jumps to min of 100+ ms (the modem is high up on top of the rack and we test with the phones we are on the floor) - Can 5 feet higher make it that much worse? On Fri, Dec 28, 2018 at 7:23 AM Brandon Martin wrote: > On 12/28/18 7:06 AM, Dovid Bender wrote: > > Hi All, > > > > I finally got around to setting up a cellular backup device in our new > > POP. I am currently testing with T-Mobile where the cell signal strength > > is at 80%. The connection is 4G. When SSH'ing in remotely the connection > > seems rather slow. Ping times seem to be all over the place (for > > instance now I am seeing: rtt min/avg/max/mdev = > > 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that > > more related to the provider and the location where I am? I could in > > theory test with VZ and ATT as well. With Verizon they charge $500.00 > > just to get a public IP and I want to avoid that if possible. > > > > Thanks and sorry in advance if this is off topic. > > LTE with a good connection on a lightly loaded cell should be > significantly less than that in both absolute terms as well as jitter. > > I used LTE (Sprint) for a couple years as my primary connectivity when I > moved out into an area with zero connectivity (fixing that now). I > typically saw ~30-40ms to Chicago, which is the nearest major carrier > PoP. Jitter was typically less than 10ms. VoIP was usable. Others in > the area on other carriers have reported similar. > > Sprint gave me a public IP with no up front charges but did charge $5/mo > for it. > > As you're probably aware, the "signal strength" ("bars") indicators that > are presented to the consumer-facing interfaces are often very cooked. > Depending on which RSSI you're looking at, a "very good" signal is > probably in the realm of -70dBm to -110dBm (note that there are two RSSI > metrics commonly used with LTE, and they tend to differ by ~20dB). > > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Fri Dec 28 13:30:38 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Dec 2018 08:30:38 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: <912B7E36-1F69-4201-A737-195133C250E6@puck.nether.net> > On Dec 28, 2018, at 7:29 AM, Dovid Bender wrote: > > It's strange. When we use T-Mo on an andriod device the ping times are 30-40 ms. When we try with the modem + raritn console box it jumps to min of 100+ ms (the modem is high up on top of the rack and we test with the phones we are on the floor) - Can 5 feet higher make it that much worse? In the world of RF of course. Are you on a v6v4 APN as well? Is your v4 taking a longer route to go via CGN while v6 goes native? - Jared From briansupport at hotmail.com Fri Dec 28 16:42:03 2018 From: briansupport at hotmail.com (Brian R) Date: Fri, 28 Dec 2018 16:42:03 +0000 Subject: Cellular backup connections In-Reply-To: References: , Message-ID: Check the route your taking when you use the cell phone as a hotspot and when you use the LTE modem. The carrier may be using different paths. You may want to engage the vendor of your modem as well to make sure everything in it is configured correctly. Depending on the device there are a lot of tricky things that can be done with them. I only have experience with Cradlepoints and have used AT&T and Verizon. I know VZW used to route their "business grade" modems differently than their cell phones and consumer hotspots. I've been told VZW fixed the issue of having to put different tower configurations into the Cradlepoints (I believe the last time I set one up they were able to provision it without me configuring anything). High pings and high latency (compared to dedicated connections) have always been normal from my experience but with a decent signal it should still be better than a traditional DSL connection for example. Brian ________________________________ From: NANOG on behalf of Dovid Bender Sent: Friday, December 28, 2018 4:29 AM To: Brandon Martin Cc: NANOG Subject: Re: Cellular backup connections It's strange. When we use T-Mo on an andriod device the ping times are 30-40 ms. When we try with the modem + raritn console box it jumps to min of 100+ ms (the modem is high up on top of the rack and we test with the phones we are on the floor) - Can 5 feet higher make it that much worse? On Fri, Dec 28, 2018 at 7:23 AM Brandon Martin > wrote: On 12/28/18 7:06 AM, Dovid Bender wrote: > Hi All, > > I finally got around to setting up a cellular backup device in our new > POP. I am currently testing with T-Mobile where the cell signal strength > is at 80%. The connection is 4G. When SSH'ing in remotely the connection > seems rather slow. Ping times seem to be all over the place (for > instance now I am seeing: rtt min/avg/max/mdev = > 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that > more related to the provider and the location where I am? I could in > theory test with VZ and ATT as well. With Verizon they charge $500.00 > just to get a public IP and I want to avoid that if possible. > > Thanks and sorry in advance if this is off topic. LTE with a good connection on a lightly loaded cell should be significantly less than that in both absolute terms as well as jitter. I used LTE (Sprint) for a couple years as my primary connectivity when I moved out into an area with zero connectivity (fixing that now). I typically saw ~30-40ms to Chicago, which is the nearest major carrier PoP. Jitter was typically less than 10ms. VoIP was usable. Others in the area on other carriers have reported similar. Sprint gave me a public IP with no up front charges but did charge $5/mo for it. As you're probably aware, the "signal strength" ("bars") indicators that are presented to the consumer-facing interfaces are often very cooked. Depending on which RSSI you're looking at, a "very good" signal is probably in the realm of -70dBm to -110dBm (note that there are two RSSI metrics commonly used with LTE, and they tend to differ by ~20dB). -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at deadfrog.net Fri Dec 28 16:51:45 2018 From: ryan at deadfrog.net (Ryan Wilkins) Date: Fri, 28 Dec 2018 11:51:45 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> You mention your connection is 4G. On T-Mobile 4G is UMTS whereas LTE is, well, LTE. Are you really on UMTS (which I would expect to have much crazier RTTs and jitter like you report) or did you mean LTE? Ryan > On Dec 28, 2018, at 7:06 AM, Dovid Bender wrote: > > Hi All, > > I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. > > Thanks and sorry in advance if this is off topic. > > From cscora at apnic.net Fri Dec 28 18:03:12 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Dec 2018 04:03:12 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181228180312.141CBC44B7@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 29 Dec, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 732568 Prefixes after maximum aggregation (per Origin AS): 281558 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 352396 Total ASes present in the Internet Routing Table: 62800 Prefixes per ASN: 11.67 Origin-only ASes present in the Internet Routing Table: 54121 Origin ASes announcing only one prefix: 23521 Transit ASes present in the Internet Routing Table: 8679 Transit-only ASes present in the Internet Routing Table: 267 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 23 Number of instances of unregistered ASNs: 25 Number of 32-bit ASNs allocated by the RIRs: 25337 Number of 32-bit ASNs visible in the Routing Table: 20536 Prefixes from 32-bit ASNs in the Routing Table: 88512 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 259 Number of addresses announced to Internet: 2839468257 Equivalent to 169 /8s, 62 /16s and 216 /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.1 Total number of prefixes smaller than registry allocations: 244625 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200435 Total APNIC prefixes after maximum aggregation: 56892 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 197466 Unique aggregates announced from the APNIC address blocks: 81144 APNIC Region origin ASes present in the Internet Routing Table: 9321 APNIC Prefixes per ASN: 21.19 APNIC Region origin ASes announcing only one prefix: 2630 APNIC Region transit ASes present in the Internet Routing Table: 1388 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4321 Number of APNIC addresses announced to Internet: 769522432 Equivalent to 45 /8s, 221 /16s and 251 /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-139577 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: 216519 Total ARIN prefixes after maximum aggregation: 102857 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 215874 Unique aggregates announced from the ARIN address blocks: 103478 ARIN Region origin ASes present in the Internet Routing Table: 18306 ARIN Prefixes per ASN: 11.79 ARIN Region origin ASes announcing only one prefix: 6808 ARIN Region transit ASes present in the Internet Routing Table: 1848 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2525 Number of ARIN addresses announced to Internet: 1077225376 Equivalent to 64 /8s, 53 /16s and 39 /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, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 200375 Total RIPE prefixes after maximum aggregation: 95545 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 196692 Unique aggregates announced from the RIPE address blocks: 116262 RIPE Region origin ASes present in the Internet Routing Table: 25722 RIPE Prefixes per ASN: 7.65 RIPE Region origin ASes announcing only one prefix: 11490 RIPE Region transit ASes present in the Internet Routing Table: 3605 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7702 Number of RIPE addresses announced to Internet: 716094016 Equivalent to 42 /8s, 174 /16s and 186 /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: 95041 Total LACNIC prefixes after maximum aggregation: 22021 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 96416 Unique aggregates announced from the LACNIC address blocks: 42165 LACNIC Region origin ASes present in the Internet Routing Table: 7933 LACNIC Prefixes per ASN: 12.15 LACNIC Region origin ASes announcing only one prefix: 2171 LACNIC Region transit ASes present in the Internet Routing Table: 1488 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5482 Number of LACNIC addresses announced to Internet: 173221888 Equivalent to 10 /8s, 83 /16s and 40 /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: 20174 Total AfriNIC prefixes after maximum aggregation: 4225 AfriNIC Deaggregation factor: 4.77 Prefixes being announced from the AfriNIC address blocks: 25861 Unique aggregates announced from the AfriNIC address blocks: 9108 AfriNIC Region origin ASes present in the Internet Routing Table: 1235 AfriNIC Prefixes per ASN: 20.94 AfriNIC Region origin ASes announcing only one prefix: 422 AfriNIC Region transit ASes present in the Internet Routing Table: 243 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 506 Number of AfriNIC addresses announced to Internet: 103003648 Equivalent to 6 /8s, 35 /16s and 182 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4642 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3019 1160 92 VIETEL-AS-AP Viettel Group, VN 45899 2982 1717 115 VNPT-AS-VN VNPT Corp, VN 4766 2815 11129 768 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2504 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2399 4906 29 CTTNET China TieTong Telecommunications 17974 2253 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2140 437 181 TATACOMM-AS TATA Communications formerl 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 6327 3502 1326 91 SHAW - Shaw Communications Inc., CA 11492 3481 225 607 CABLEONE - CABLE ONE, INC., US 22773 3305 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2594 5291 972 AMAZON-02 - Amazon.com, Inc., US 16625 2200 1229 1691 AKAMAI-AS - Akamai Technologies, Inc., 20115 2151 2754 534 CHARTER-20115 - Charter Communications, 18566 2143 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2088 349 169 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2074 5077 588 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5249 1629 139 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3247 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2622 576 1931 AKAMAI-ASN1, US 12389 2228 2221 626 ROSTELECOM-AS, RU 34984 2036 337 533 TELLCOM-AS, TR 9121 1676 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 8402 1299 544 17 CORBINA-AS OJSC "Vimpelcom", RU 9009 1201 129 675 M247, GB 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 5466 3317 591 Uninet S.A. de C.V., MX 10620 3148 476 896 Telmex Colombia S.A., CO 11830 2676 371 71 Instituto Costarricense de Electricidad 6503 1649 449 54 Axtel, S.A.B. de C.V., MX 7303 1440 961 228 Telecom Argentina S.A., AR 28573 1195 2237 181 CLARO S.A., BR 6147 1079 377 29 Telefonica del Peru S.A.A., PE 3816 1025 511 112 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 942 144 68 Alestra, S. de R.L. de C.V., MX 13999 934 538 258 Mega Cable, S.A. 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 1164 393 24 LINKdotNET-AS, EG 37611 898 107 9 Afrihost, ZA 36903 797 401 139 MT-MPLS, MA 36992 780 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 642 1731 19 TE-AS TE-AS, EG 29571 481 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 415 45 11 WANANCHI-, KE 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 5466 3317 591 Uninet S.A. de C.V., MX 12479 5249 1629 139 UNI2-AS, ES 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4642 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3502 1326 91 SHAW - Shaw Communications Inc., CA 11492 3481 225 607 CABLEONE - CABLE ONE, INC., US 22773 3305 2980 175 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3247 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3148 476 896 Telmex Colombia S.A., CO 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 5249 5110 UNI2-AS, ES 4538 4642 4568 ERX-CERNET-BKB China Education and Research Net 7545 4656 4134 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3502 3411 SHAW - Shaw Communications Inc., CA 8551 3247 3204 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3305 3130 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3019 2927 VIETEL-AS-AP Viettel Group, VN 11492 3481 2874 CABLEONE - CABLE ONE, INC., US 45899 2982 2867 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 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai 4200058511 PRIVATE 103.111.178.0/24 137522 OERL-AS-AP Origin Energy Retai 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& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:12 /9:11 /10:36 /11:99 /12:291 /13:568 /14:1127 /15:1912 /16:13351 /17:7872 /18:13853 /19:25519 /20:39687 /21:46137 /22:91161 /23:74541 /24:413536 /25:925 /26:813 /27:868 /28:32 /29:19 /30:7 /31:2 /32:189 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4101 5249 UNI2-AS, ES 6327 3266 3502 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2764 3481 CABLEONE - CABLE ONE, INC., US 8551 2703 3247 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2544 3305 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2038 2143 MEGAPATH5-US - MegaPath Corporation, US 11830 2021 2676 Instituto Costarricense de Electricidad y Telec 30036 1837 2088 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1614 2:888 3:1 4:23 5:2769 6:43 7:1 8:1173 12:1877 13:302 14:1886 15:36 16:2 17:209 18:59 20:48 23:2551 24:2416 25:2 27:2550 31:2019 32:92 35:31 36:828 37:3000 38:1599 39:279 40:119 41:3148 42:728 43:2000 44:137 45:6425 46:3105 47:244 49:1333 50:1076 51:319 52:1085 54:363 55:1 56:6 57:41 58:1713 59:1071 60:461 61:2091 62:2157 63:1812 64:5077 65:2183 66:4803 67:2684 68:1160 69:3432 70:1144 71:603 72:2264 74:2740 75:406 76:526 77:1715 78:1710 79:2283 80:1636 81:1384 82:1080 83:876 84:1064 85:2127 86:563 87:1501 88:988 89:2417 90:211 91:6525 92:1261 93:2358 94:2360 95:3142 96:906 97:349 98:936 99:169 100:88 101:1166 102:337 103:19574 104:3559 105:242 106:888 107:1835 108:702 109:3644 110:1635 111:1904 112:1395 113:1382 114:1142 115:1721 116:1617 117:1928 118:2202 119:1690 120:1140 121:1029 122:2356 123:1628 124:1446 125:1948 128:1192 129:690 130:523 131:1650 132:716 133:193 134:1043 135:229 136:537 137:675 138:1958 139:777 140:568 141:763 142:797 143:995 144:855 145:504 146:1249 147:770 148:1703 149:790 150:787 151:994 152:933 153:326 154:2399 155:963 156:1635 157:851 158:656 159:1889 160:1490 161:904 162:2660 163:770 164:1123 165:1590 166:466 167:1358 168:3219 169:868 170:3989 171:497 172:1069 173:2144 174:997 175:879 176:2228 177:4063 178:2531 179:1289 180:2091 181:2361 182:2674 183:1352 184:1137 185:14506 186:3660 187:2485 188:2965 189:2097 190:8264 191:1428 192:10011 193:6488 194:5329 195:4049 196:3032 197:1719 198:5677 199:5973 200:7407 201:5015 202:10247 203:10233 204:4595 205:3021 206:3274 207:3262 208:3937 209:4193 210:3890 211:2006 212:3116 213:2828 214:1069 215:52 216:5962 217:2189 218:881 219:576 220:1835 221:997 222:976 223:1419 End of report From jared at compuwizz.net Fri Dec 28 18:32:17 2018 From: jared at compuwizz.net (Jared Geiger) Date: Fri, 28 Dec 2018 13:32:17 -0500 Subject: Cellular backup connections In-Reply-To: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> References: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> Message-ID: I found horrible routing with a static IP setup with T-Mobile. The device was located in Ashburn, outbound routing would go out via Dallas and inbound would come in via Seattle. So ping times and usability was rough. Tried it on the west coast and the same problem. T-Mobile support said this was by design and they couldn’t change it. I decided to switch to a regular consumer AT&T data sim without a static IP and set up a small router to initiate a VPN tunnel out to wherever I need it. It turns out to be cheaper and reliable for us. ~Jared Geiger On Fri, Dec 28, 2018 at 11:53 AM Ryan Wilkins wrote: > You mention your connection is 4G. On T-Mobile 4G is UMTS whereas LTE is, > well, LTE. Are you really on UMTS (which I would expect to have much > crazier RTTs and jitter like you report) or did you mean LTE? > > Ryan > > > On Dec 28, 2018, at 7:06 AM, Dovid Bender wrote: > > > > Hi All, > > > > I finally got around to setting up a cellular backup device in our new > POP. I am currently testing with T-Mobile where the cell signal strength is > at 80%. The connection is 4G. When SSH'ing in remotely the connection seems > rather slow. Ping times seem to be all over the place (for instance now I > am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is > that just cellular or is that more related to the provider and the location > where I am? I could in theory test with VZ and ATT as well. With Verizon > they charge $500.00 just to get a public IP and I want to avoid that if > possible. > > > > Thanks and sorry in advance if this is off topic. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Dec 28 19:28:36 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 28 Dec 2018 13:28:36 -0600 Subject: Cellular backup connections In-Reply-To: References: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> Message-ID: <8E24E5C1-88BC-4698-8222-2A24D9AC703E@gvtc.com> On the topic of static ip... as a Net Eng of an ISP, and seeing the pains that we have to endure with our static ip customers , I wonder if static ip customers actually inadvertently get less optimal treatment than more flexible, agile and dynamic ip customers ? I’m saying that since over the years as I have migrated from one router to another, from one technology Ethernet/IP, mpls/ip, it’s more difficult to move those static customers subnets around, and sometimes easier just to leave them on an old router where they’ve been for years. Aaron > On Dec 28, 2018, at 12:32 PM, Jared Geiger wrote: > > I found horrible routing with a static IP setup with T-Mobile. The device was located in Ashburn, outbound routing would go out via Dallas and inbound would come in via Seattle. So ping times and usability was rough. Tried it on the west coast and the same problem. T-Mobile support said this was by design and they couldn’t change it. > > I decided to switch to a regular consumer AT&T data sim without a static IP and set up a small router to initiate a VPN tunnel out to wherever I need it. It turns out to be cheaper and reliable for us. > > ~Jared Geiger > >> On Fri, Dec 28, 2018 at 11:53 AM Ryan Wilkins wrote: >> You mention your connection is 4G. On T-Mobile 4G is UMTS whereas LTE is, well, LTE. Are you really on UMTS (which I would expect to have much crazier RTTs and jitter like you report) or did you mean LTE? >> >> Ryan >> >> > On Dec 28, 2018, at 7:06 AM, Dovid Bender wrote: >> > >> > Hi All, >> > >> > I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. >> > >> > Thanks and sorry in advance if this is off topic. >> > >> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Fri Dec 28 19:34:00 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Fri, 28 Dec 2018 14:34:00 -0500 Subject: Cellular backup connections In-Reply-To: <8E24E5C1-88BC-4698-8222-2A24D9AC703E@gvtc.com> References: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> <8E24E5C1-88BC-4698-8222-2A24D9AC703E@gvtc.com> Message-ID: I really can't believe I'm going to say this, but this has been a good SD-WAN use case for us. Scott Helms On Fri, Dec 28, 2018 at 2:30 PM Aaron1 wrote: > On the topic of static ip... as a Net Eng of an ISP, and seeing the pains > that we have to endure with our static ip customers , I wonder if static ip > customers actually inadvertently get less optimal treatment than more > flexible, agile and dynamic ip customers ? > > I’m saying that since over the years as I have migrated from one router to > another, from one technology Ethernet/IP, mpls/ip, it’s more difficult to > move those static customers subnets around, and sometimes easier just to > leave them on an old router where they’ve been for years. > > Aaron > > On Dec 28, 2018, at 12:32 PM, Jared Geiger wrote: > > I found horrible routing with a static IP setup with T-Mobile. The device > was located in Ashburn, outbound routing would go out via Dallas and > inbound would come in via Seattle. So ping times and usability was rough. > Tried it on the west coast and the same problem. T-Mobile support said this > was by design and they couldn’t change it. > > I decided to switch to a regular consumer AT&T data sim without a static > IP and set up a small router to initiate a VPN tunnel out to wherever I > need it. It turns out to be cheaper and reliable for us. > > ~Jared Geiger > > On Fri, Dec 28, 2018 at 11:53 AM Ryan Wilkins wrote: > >> You mention your connection is 4G. On T-Mobile 4G is UMTS whereas LTE >> is, well, LTE. Are you really on UMTS (which I would expect to have much >> crazier RTTs and jitter like you report) or did you mean LTE? >> >> Ryan >> >> > On Dec 28, 2018, at 7:06 AM, Dovid Bender wrote: >> > >> > Hi All, >> > >> > I finally got around to setting up a cellular backup device in our new >> POP. I am currently testing with T-Mobile where the cell signal strength is >> at 80%. The connection is 4G. When SSH'ing in remotely the connection seems >> rather slow. Ping times seem to be all over the place (for instance now I >> am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is >> that just cellular or is that more related to the provider and the location >> where I am? I could in theory test with VZ and ATT as well. With Verizon >> they charge $500.00 just to get a public IP and I want to avoid that if >> possible. >> > >> > Thanks and sorry in advance if this is off topic. >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Fri Dec 28 19:35:43 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 28 Dec 2018 11:35:43 -0800 Subject: Cellular backup connections In-Reply-To: References: <4CD9F01A-7D47-4396-9C63-5E41AFDC429F@deadfrog.net> <8E24E5C1-88BC-4698-8222-2A24D9AC703E@gvtc.com> Message-ID: > leave them on an old router where they’ve been for years. I can’t name names obviously, but you’d be astonished how often I see this and who the big names are. - Ben Cannon, AS15206 From dwcarder at es.net Fri Dec 28 22:04:34 2018 From: dwcarder at es.net (Dale W. Carder) Date: Fri, 28 Dec 2018 16:04:34 -0600 Subject: Pinging a Device Every Second In-Reply-To: References: Message-ID: <20181228220434.GB65916@dwc-laptop.local> Thus spake Christian Meutes (christian at errxtx.net) on Fri, Dec 21, 2018 at 02:41:23PM +0100: > Depending on your requirements and scale - but I read you want history - > it's probably less a demand on CPU or network resources, but more on IOPS. > > If you cache all results before writing to disk, then it's not much of a > problem, but by just going "let's use RRD/MRTG for this" your IOPS could > become the first problem. So you might look into a proper timeseries > backend or use a caching daemon for RRD. Having once written a caching daemon for mrtg/rrdtool, the advent of SSD arrays has made iops largely irrelevant. (I had ~ 1.2M targets in mrtg on that machine) Dale > On Sat, Dec 15, 2018 at 4:48 PM Colton Conor wrote: > > > How much compute and network resources does it take for a NMS to: > > > > 1. ICMP ping a device every second > > 2. Record these results. > > 3. Report an alarm after so many seconds of missed pings. > > > > We are looking for a system to in near real-time monitor if an end > > customers router is up or down. SNMP I assume would be too resource > > intensive, so ICMP pings seem like the only logical solution. > > > > The question is once a second pings too polling on an NMS and a consumer > > grade router? Does it take much network bandwidth and CPU resources from > > both the NMS and CPE side? > > > > Lets say this is for a 1,000 customer ISP. > > > > > > > > -- > Christian Meutes > > e-mail/xmpp: christian at errxtx.net > mobile: +49 176 32370305 > PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 > Toulouser Allee 21, 40211 Duesseldorf, Germany From patrickboyle at protonmail.com Fri Dec 28 22:11:41 2018 From: patrickboyle at protonmail.com (Patrick Boyle) Date: Fri, 28 Dec 2018 22:11:41 +0000 Subject: CenturyLink In-Reply-To: <20181228080353.ilp6ovvrq3eivijf@nic.fr> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: Yes, there were 911 services affected. The latest word from C-link as of 1:46PM mountain is that all 911 services are restored where they are the provider. I'm not 100% sure if that's system-wide, or just my area in the northwest, however. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer wrote: > On Fri, Dec 28, 2018 at 07:07:42AM +0000, > Erik Sundberg ESundberg at nitelusa.com wrote > a message of 131 lines which said: > > > CenturyLink will be conducting an extensive post-incident > > investigation and root cause analysis to provide follow-up > > information to our customers > > Is this problem also responsible for the 911 outage? If so, the > post-mortem analysis is not useful only for CenturyLink customers but > for everyone on the west coast. From amitchell at isipp.com Fri Dec 28 22:17:03 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 28 Dec 2018 15:17:03 -0700 Subject: CenturyLink...is being investigated by the FCC In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: <1A0B40DB-39A9-44EB-8C14-4B1F423AB59B@isipp.com> And the other latest news is that the FCC is investigating the CenturyLink outage: https://www.theinternetpatrol.com/fcc-investigating-centurylink-outage-says-unacceptable/ > On Dec 28, 2018, at 3:11 PM, Patrick Boyle via NANOG wrote: > > Yes, there were 911 services affected. The latest word from C-link as of 1:46PM mountain is that all 911 services are restored where they are the provider. I'm not 100% sure if that's system-wide, or just my area in the northwest, however. > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer wrote: > >> On Fri, Dec 28, 2018 at 07:07:42AM +0000, >> Erik Sundberg ESundberg at nitelusa.com wrote >> a message of 131 lines which said: >> >>> CenturyLink will be conducting an extensive post-incident >>> investigation and root cause analysis to provide follow-up >>> information to our customers >> >> Is this problem also responsible for the 911 outage? If so, the >> post-mortem analysis is not useful only for CenturyLink customers but >> for everyone on the west coast. > > From patrickboyle at protonmail.com Fri Dec 28 22:21:34 2018 From: patrickboyle at protonmail.com (Patrick Boyle) Date: Fri, 28 Dec 2018 22:21:34 +0000 Subject: CenturyLink...is being investigated by the FCC In-Reply-To: <1A0B40DB-39A9-44EB-8C14-4B1F423AB59B@isipp.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <1A0B40DB-39A9-44EB-8C14-4B1F423AB59B@isipp.com> Message-ID: Ouch. Feel bad for the guys on the ground at C-link. Not a fun 24 hours. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 28, 2018 3:17 PM, Anne P. Mitchell, Esq. wrote: > And the other latest news is that the FCC is investigating the CenturyLink outage: > > https://www.theinternetpatrol.com/fcc-investigating-centurylink-outage-says-unacceptable/ > > > On Dec 28, 2018, at 3:11 PM, Patrick Boyle via NANOG nanog at nanog.org wrote: > > Yes, there were 911 services affected. The latest word from C-link as of 1:46PM mountain is that all 911 services are restored where they are the provider. I'm not 100% sure if that's system-wide, or just my area in the northwest, however. > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer bortzmeyer at nic.fr wrote: > > > > > On Fri, Dec 28, 2018 at 07:07:42AM +0000, > > > Erik Sundberg ESundberg at nitelusa.com wrote > > > a message of 131 lines which said: > > > > > > > CenturyLink will be conducting an extensive post-incident > > > > investigation and root cause analysis to provide follow-up > > > > information to our customers > > > > > > Is this problem also responsible for the 911 outage? If so, the > > > post-mortem analysis is not useful only for CenturyLink customers but > > > for everyone on the west coast. From yang.yu.list at gmail.com Fri Dec 28 23:23:09 2018 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 28 Dec 2018 15:23:09 -0800 Subject: CenturyLink In-Reply-To: <20181228080353.ilp6ovvrq3eivijf@nic.fr> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer wrote: > Is this problem also responsible for the 911 outage? If so, the > post-mortem analysis is not useful only for CenturyLink customers but > for everyone on the west coast. Looks like most time.nist.gov servers (3 x NIST sites on AS49) are single homed on CenturyLink, anyone noticed NTP issues yesterday? https://tf.nist.gov/tf-cgi/servers.cgi From patrickboyle at protonmail.com Fri Dec 28 23:33:10 2018 From: patrickboyle at protonmail.com (Patrick Boyle) Date: Fri, 28 Dec 2018 23:33:10 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: <58GvB14Qjax5C4YeL3B3Xa0cTbVUajMKF30EMJ6xlS4rGZU4j4Lq98drzrBjQhVZ20blilO0m1QyBGlBUlXUmvFgyGzkovT-ipRAieLFSD4=@protonmail.com> Looks like we lost sync intermittently across several of their servers last night. Cleared up around midnight mountain for me. Let's chip in and get some carrier diversity for those guys :) Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 28, 2018 4:23 PM, Yang Yu wrote: > On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer bortzmeyer at nic.fr wrote: > > > Is this problem also responsible for the 911 outage? If so, the > > post-mortem analysis is not useful only for CenturyLink customers but > > for everyone on the west coast. > > Looks like mosttime.nist.gov servers (3 x NIST sites on AS49) are > single homed on CenturyLink, anyone noticed NTP issues yesterday? > > https://tf.nist.gov/tf-cgi/servers.cgi From mhuff at ox.com Sat Dec 29 12:55:49 2018 From: mhuff at ox.com (Matthew Huff) Date: Sat, 29 Dec 2018 12:55:49 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: <69cdeaf562704c729f69cb471b2b1b6d@ox.com> Yep. We are required by FINRA to verify that our clocks on our trading systems are within a certain tolerance of NIST time. We are still seeing issues with 3 of the NIST servers this morning. Since NIST is on a skeleton crew anyway due to the government shutdown, I don't expect any resolution shortly. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Yang Yu Sent: Friday, December 28, 2018 6:23 PM To: Stephane Bortzmeyer Cc: nanog at nanog.org Subject: Re: CenturyLink On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer wrote: > Is this problem also responsible for the 911 outage? If so, the > post-mortem analysis is not useful only for CenturyLink customers but > for everyone on the west coast. Looks like most time.nist.gov servers (3 x NIST sites on AS49) are single homed on CenturyLink, anyone noticed NTP issues yesterday? https://tf.nist.gov/tf-cgi/servers.cgi From list at satchell.net Sat Dec 29 14:34:19 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 29 Dec 2018 06:34:19 -0800 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: On 12/28/18 3:23 PM, Yang Yu wrote: > On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer wrote: >> Is this problem also responsible for the 911 outage? If so, the >> post-mortem analysis is not useful only for CenturyLink customers but >> for everyone on the west coast. > > Looks like most time.nist.gov servers (3 x NIST sites on AS49) are > single homed on CenturyLink, anyone noticed NTP issues yesterday? > > https://tf.nist.gov/tf-cgi/servers.cgi > I have GPS-based Stratum 1 NTP appliances in my network, so I wouldn't see any issues. I suspect many other operators are in the same situation. From mhuff at ox.com Sat Dec 29 14:51:51 2018 From: mhuff at ox.com (Matthew Huff) Date: Sat, 29 Dec 2018 14:51:51 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: <3d01a1b601354b3f971e213e0107e5b8@ox.com> We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Saturday, December 29, 2018 9:34 AM To: nanog at nanog.org Subject: Re: CenturyLink On 12/28/18 3:23 PM, Yang Yu wrote: > On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer wrote: >> Is this problem also responsible for the 911 outage? If so, the >> post-mortem analysis is not useful only for CenturyLink customers but >> for everyone on the west coast. > > Looks like most time.nist.gov servers (3 x NIST sites on AS49) are > single homed on CenturyLink, anyone noticed NTP issues yesterday? > > https://tf.nist.gov/tf-cgi/servers.cgi > I have GPS-based Stratum 1 NTP appliances in my network, so I wouldn't see any issues. I suspect many other operators are in the same situation. From list at satchell.net Sat Dec 29 14:54:32 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 29 Dec 2018 06:54:32 -0800 Subject: CenturyLink...is being investigated by the FCC In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <1A0B40DB-39A9-44EB-8C14-4B1F423AB59B@isipp.com> Message-ID: The telephone companies (I'm looking at YOU Verizon!) are bringing this situation onto the community. I can see the FCC NPRM now: "What percentage of E911 terminations is being serviced over VoIP with carrier-based network switching, or third-party network switching, interfaced to the PSTN? "How many emergency service areas terminate E911 VoIP into an on-premises device like a Cisco voice router with outward-facing T1/E1 cards, or even outward-facing DS0 ports?" This is just the flip side of the problem with VoIP on the consumer side, not being able to easily associated a location with a 911 call without significant help from the calling device. Think cell phones on the one hand, and the ubiquitous Cisco VoIP desk set on the other. (Personal note: I have two copper-based DS0 lines here at my home office. And I'll keep them until Nevada Bell pries them out of my cold, dead hands. Now, those lines do terminate at a neighborhood SONET ring fiber terminal with a battery, but it's not my worry. Fax works fine -- which you can't say for VoIP connections.) On 12/28/18 2:21 PM, Patrick Boyle via NANOG wrote: > Ouch. Feel bad for the guys on the ground at C-link. Not a fun 24 hours. > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, December 28, 2018 3:17 PM, Anne P. Mitchell, Esq. wrote: > >> And the other latest news is that the FCC is investigating the CenturyLink outage: >> >> https://www.theinternetpatrol.com/fcc-investigating-centurylink-outage-says-unacceptable/ >> >>> On Dec 28, 2018, at 3:11 PM, Patrick Boyle via NANOG nanog at nanog.org wrote: >>> Yes, there were 911 services affected. The latest word from C-link as of 1:46PM mountain is that all 911 services are restored where they are the provider. I'm not 100% sure if that's system-wide, or just my area in the northwest, however. >>> Sent with ProtonMail Secure Email. >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer bortzmeyer at nic.fr wrote: >>> >>>> On Fri, Dec 28, 2018 at 07:07:42AM +0000, >>>> Erik Sundberg ESundberg at nitelusa.com wrote >>>> a message of 131 lines which said: >>>> >>>>> CenturyLink will be conducting an extensive post-incident >>>>> investigation and root cause analysis to provide follow-up >>>>> information to our customers >>>> >>>> Is this problem also responsible for the 911 outage? If so, the >>>> post-mortem analysis is not useful only for CenturyLink customers but >>>> for everyone on the west coast. > > From list at satchell.net Sat Dec 29 15:00:52 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 29 Dec 2018 07:00:52 -0800 Subject: CenturyLink In-Reply-To: <3d01a1b601354b3f971e213e0107e5b8@ox.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> Message-ID: On 12/29/18 6:51 AM, Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. Having been a participant on Standards Working Groups, I understand completely. Regulations, like Standards, need to be written to apply to as wide a population as possible. Do those regulations dictate how you monitor drift? For example, can you have a system (I would use CentOS) that syncs to the appliance as well as NIST and your inside NTP sources, and use ntpq(8) to read the drift directly? From rubensk at gmail.com Sat Dec 29 16:05:18 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 29 Dec 2018 14:05:18 -0200 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> Message-ID: On Fri, Dec 28, 2018 at 9:24 PM Yang Yu wrote: > On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer > wrote: > > Is this problem also responsible for the 911 outage? If so, the > > post-mortem analysis is not useful only for CenturyLink customers but > > for everyone on the west coast. > > Looks like most time.nist.gov servers (3 x NIST sites on AS49) are > single homed on CenturyLink, anyone noticed NTP issues yesterday? > > https://tf.nist.gov/tf-cgi/servers.cgi NIST could take a hint from the ntp.br project: pool.ntp.br has address 200.186.125.195 => CenturyLink pool.ntp.br has address 200.20.186.76 => RNP (Local academic network) pool.ntp.br has address 200.160.7.193 => NIC.br (Local ccTLD, IX, NTP and other services) pool.ntp.br has address 200.160.7.186 => NIC.br pool.ntp.br has address 200.160.7.209 => NIC.br pool.ntp.br has address 200.160.0.8 => NIC.br (distributed in different buildings, rack clusters, NTP hierarchy) pool.ntp.br has IPv6 address 2001:12ff::8 pool.ntp.br has IPv6 address 2001:12ff:0:7::186 pool.ntp.br has IPv6 address 2001:12ff:0:7::193 (unfortunately there is lack of IPv6 diversity at this point) a.st1.ntp.br 200.160.7.186 2001:12ff:0:7::186 => NIC.br b.st1.ntp.br 201.49.148.135 => STF (Local Supreme Court) c.st1.ntp.br 200.186.125.195 => CenturyLink d.st1.ntp.br 200.20.186.76 => RNP (Rio) a.ntp.br 200.160.0.8 e 2001:12ff::8 => NIC.br b.ntp.br 200.189.40.8 => Globenet Fortaleza (Cable Landing Station) c.ntp.br 200.192.232.8 => RNP (Brasilia) gps.ntp.br 200.160.7.193 e 2001:12ff:0:7::193 => NIC.br Perhaps what happened in NIST was a bad governmental RFP not requiring diversity ? Rubens -------------- next part -------------- An HTML attachment was scrubbed... URL: From ray at oneunified.net Sat Dec 29 17:01:16 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Sat, 29 Dec 2018 10:01:16 -0700 Subject: CenturyLink In-Reply-To: <3d01a1b601354b3f971e213e0107e5b8@ox.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> Message-ID: <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> On 2018-12-29 7:51 a.m., Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. > On one occasion, due to bad firmware or a configuration issue, I have seen GPS stratum 1 diverge from NTP.  It was somewhat eye brow raising to the company.  My NTP monitored servers were shown to be diverging their GPS/NTP, but after looking at twice or thrice, it was the other way around. From mlm at pixelgate.net Sat Dec 29 17:16:17 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Sat, 29 Dec 2018 09:16:17 -0800 (PST) Subject: Cellular backup connections In-Reply-To: References: Message-ID: On Fri, 28 Dec 2018, Dovid Bender wrote: >I finally got around to setting up a cellular backup device in our new POP. >When SSH'ing in remotely the connection seems rather slow. Perhaps using MOSH can help make the interactive CLI session less annoying. >Verizon they charge $500.00 just to get a public IP and I want to avoid >that if possible. You might look into have it call out / maintain a connection back to your infrastructure. /mark From mhuff at ox.com Sun Dec 30 11:58:19 2018 From: mhuff at ox.com (Matthew Huff) Date: Sun, 30 Dec 2018 11:58:19 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> Message-ID: Actually, on all our trading systems, our times are synced via PTP instead of ntpd for at least 50 microsecond accuracy. The stratum 1 clocks as well as NIST time are only used as comparison to verify compliance and reality. We use ntpq to determine the offset from NIST for reporting. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Saturday, December 29, 2018 10:01 AM To: nanog at nanog.org Subject: Re: CenturyLink On 12/29/18 6:51 AM, Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. Having been a participant on Standards Working Groups, I understand completely. Regulations, like Standards, need to be written to apply to as wide a population as possible. Do those regulations dictate how you monitor drift? For example, can you have a system (I would use CentOS) that syncs to the appliance as well as NIST and your inside NTP sources, and use ntpq(8) to read the drift directly? From saku at ytti.fi Sun Dec 30 13:42:49 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Dec 2018 15:42:49 +0200 Subject: CenturyLink RCA? Message-ID: Apologies for the URL, I do not know official source and I do not share the URLs sentiment. https://fuckingcenturylink.com/ Can someone translate this to IP engineer? What did actually happen? >From my own history, I rarely recognise the problem I fixed from reading the public RCA. I hope CenturyLink will do better. Best guess so far that I've heard is a) CenturyLink runs global L2 DCN/OOB b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, I've had this failure mode) c) DCN had direct access to control-plane, and L2 congested control-plane resources causing it to deprovision waves Now of course this is entirely speculation, but intended to show what type of explanation is acceptable and can be used to fix things. Hopefully CenturyLink does come out with IP-engineering readable explanation, so that we may use it as leverage to support work in our own domains to remove such risks. a) do not run L2 DCN/OOB b) do not connect MGMT ETH (it is unprotected access to control-plane, it cannot be protected by CoPP/lo0 filter/LPTS ec) c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) d) do fail optical network up -- ++ytti From shawnl at up.net Sun Dec 30 14:39:53 2018 From: shawnl at up.net (Shawn L) Date: Sun, 30 Dec 2018 09:39:53 -0500 (EST) Subject: CenturyLink In-Reply-To: <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> Message-ID: <1546180793.98522472@upnet.mymailsrvr.com> Speaking of GPS-enabled NTP appliances, etc. wondering what hardware people are using for this. thanks -----Original Message----- From: "Raymond Burkholder" Sent: Saturday, December 29, 2018 12:01pm To: "Matthew Huff" , "list at satchell.net" , "nanog at nanog.org" Subject: Re: CenturyLink On 2018-12-29 7:51 a.m., Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. > On one occasion, due to bad firmware or a configuration issue, I have seen GPS stratum 1 diverge from NTP. It was somewhat eye brow raising to the company. My NTP monitored servers were shown to be diverging their GPS/NTP, but after looking at twice or thrice, it was the other way around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Dec 30 15:42:22 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 30 Dec 2018 09:42:22 -0600 (CST) Subject: CenturyLink RCA? In-Reply-To: References: Message-ID: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> It's technical enough so that laypeople immediately lose interest, yet completely useless to anyone that works with this stuff. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Saku Ytti" To: "nanog list" Sent: Sunday, December 30, 2018 7:42:49 AM Subject: CenturyLink RCA? Apologies for the URL, I do not know official source and I do not share the URLs sentiment. https://fuckingcenturylink.com/ Can someone translate this to IP engineer? What did actually happen? >From my own history, I rarely recognise the problem I fixed from reading the public RCA. I hope CenturyLink will do better. Best guess so far that I've heard is a) CenturyLink runs global L2 DCN/OOB b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, I've had this failure mode) c) DCN had direct access to control-plane, and L2 congested control-plane resources causing it to deprovision waves Now of course this is entirely speculation, but intended to show what type of explanation is acceptable and can be used to fix things. Hopefully CenturyLink does come out with IP-engineering readable explanation, so that we may use it as leverage to support work in our own domains to remove such risks. a) do not run L2 DCN/OOB b) do not connect MGMT ETH (it is unprotected access to control-plane, it cannot be protected by CoPP/lo0 filter/LPTS ec) c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) d) do fail optical network up -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Sun Dec 30 16:24:55 2018 From: john at essenz.com (John Von Essen) Date: Sun, 30 Dec 2018 11:24:55 -0500 Subject: CenturyLink RCA? In-Reply-To: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> Message-ID: One thing that is troubling when reading that URL is that it appears several steps of restoration required teams to go onsite for local login, etc.,. Granted, to troubleshoot hardware you need to be physically present to pop a line card in and out, but CTL/LVL3 should have full out-of-band console and power control to all core devices, we shouldn't be waiting for someone to drive to a location to get console or do power cycling. And I would imagine the first step to alot of the troubleshooting was power cycling and local console logs. -John On 12/30/18 10:42 AM, Mike Hammett wrote: > It's technical enough so that laypeople immediately lose interest, yet > completely useless to anyone that works with this stuff. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------------------------------------------------ > *From: *"Saku Ytti" > *To: *"nanog list" > *Sent: *Sunday, December 30, 2018 7:42:49 AM > *Subject: *CenturyLink RCA? > > Apologies for the URL, I do not know official source and I do not > share the URLs sentiment. > https://fuckingcenturylink.com/ > > Can someone translate this to IP engineer? What did actually happen? > From my own history, I rarely recognise the problem I fixed from > reading the public RCA. I hope CenturyLink will do better. > > Best guess so far that I've heard is > > a) CenturyLink runs global L2 DCN/OOB > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > I've had this failure mode) > c) DCN had direct access to control-plane, and L2 congested > control-plane resources causing it to deprovision waves > > Now of course this is entirely speculation, but intended to show what > type of explanation is acceptable and can be used to fix things. > Hopefully CenturyLink does come out with IP-engineering readable > explanation, so that we may use it as leverage to support work in our > own domains to remove such risks. > > a) do not run L2 DCN/OOB > b) do not connect MGMT ETH (it is unprotected access to control-plane, > it  cannot be protected by CoPP/lo0 filter/LPTS ec) > c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) > d) do fail optical network up > > -- >   ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Sun Dec 30 16:38:31 2018 From: mel at beckman.org (Mel Beckman) Date: Sun, 30 Dec 2018 16:38:31 +0000 Subject: CenturyLink In-Reply-To: <1546180793.98522472@upnet.mymailsrvr.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net>, <1546180793.98522472@upnet.mymailsrvr.com> Message-ID: We have had great success with the TimeMachines TM1001A. Simple, robust, and over several years we’ve had zero outages on more than 40 installations. And unlike most of the competition, not ridiculously overpriced. https://timemachinescorp.com/product/gps-time-server-tm1000a -mel beckman On Dec 30, 2018, at 6:40 AM, Shawn L via NANOG > wrote: Speaking of GPS-enabled NTP appliances, etc. wondering what hardware people are using for this. thanks -----Original Message----- From: "Raymond Burkholder" > Sent: Saturday, December 29, 2018 12:01pm To: "Matthew Huff" >, "list at satchell.net" >, "nanog at nanog.org" > Subject: Re: CenturyLink On 2018-12-29 7:51 a.m., Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. > On one occasion, due to bad firmware or a configuration issue, I have seen GPS stratum 1 diverge from NTP. It was somewhat eye brow raising to the company. My NTP monitored servers were shown to be diverging their GPS/NTP, but after looking at twice or thrice, it was the other way around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Sun Dec 30 17:17:32 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Dec 2018 19:17:32 +0200 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> Message-ID: Hey John, Your criticism is warranted, but would also be addressed by explanation DCN/OOB being the source of the problem. At any rate, I am looking forward to stop speculating and start reading post-mortem written by someone who knows how networks work. On Sun, 30 Dec 2018 at 18:28, John Von Essen wrote: > > One thing that is troubling when reading that URL is that it appears several steps of restoration required teams to go onsite for local login, etc.,. Granted, to troubleshoot hardware you need to be physically present to pop a line card in and out, but CTL/LVL3 should have full out-of-band console and power control to all core devices, we shouldn't be waiting for someone to drive to a location to get console or do power cycling. And I would imagine the first step to alot of the troubleshooting was power cycling and local console logs. > > > -John > > > > On 12/30/18 10:42 AM, Mike Hammett wrote: > > It's technical enough so that laypeople immediately lose interest, yet completely useless to anyone that works with this stuff. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ________________________________ > From: "Saku Ytti" > To: "nanog list" > Sent: Sunday, December 30, 2018 7:42:49 AM > Subject: CenturyLink RCA? > > Apologies for the URL, I do not know official source and I do not > share the URLs sentiment. > https://fuckingcenturylink.com/ > > Can someone translate this to IP engineer? What did actually happen? > From my own history, I rarely recognise the problem I fixed from > reading the public RCA. I hope CenturyLink will do better. > > Best guess so far that I've heard is > > a) CenturyLink runs global L2 DCN/OOB > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > I've had this failure mode) > c) DCN had direct access to control-plane, and L2 congested > control-plane resources causing it to deprovision waves > > Now of course this is entirely speculation, but intended to show what > type of explanation is acceptable and can be used to fix things. > Hopefully CenturyLink does come out with IP-engineering readable > explanation, so that we may use it as leverage to support work in our > own domains to remove such risks. > > a) do not run L2 DCN/OOB > b) do not connect MGMT ETH (it is unprotected access to control-plane, > it cannot be protected by CoPP/lo0 filter/LPTS ec) > c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) > d) do fail optical network up > > -- > ++ytti > -- ++ytti From mhuff at ox.com Sun Dec 30 17:18:53 2018 From: mhuff at ox.com (Matthew Huff) Date: Sun, 30 Dec 2018 17:18:53 +0000 Subject: CenturyLink In-Reply-To: <1546180793.98522472@upnet.mymailsrvr.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> Message-ID: <6b00b11fbf704d3e814011d916527fd8@ox.com> We use an older model of https://www.microsemi.com/product-directory/enterprise-network-time-servers/4117-syncserver-s600 with rubidium oscillator. Not cheap, but hardened and extremely accurate. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 From: Shawn L [mailto:shawnl at up.net] Sent: Sunday, December 30, 2018 9:40 AM To: nanog at nanog.org Cc: Matthew Huff ; list at satchell.net Subject: Re: CenturyLink Speaking of GPS-enabled NTP appliances, etc. wondering what hardware people are using for this. thanks -----Original Message----- From: "Raymond Burkholder" > Sent: Saturday, December 29, 2018 12:01pm To: "Matthew Huff" >, "list at satchell.net" >, "nanog at nanog.org" > Subject: Re: CenturyLink On 2018-12-29 7:51 a.m., Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. > On one occasion, due to bad firmware or a configuration issue, I have seen GPS stratum 1 diverge from NTP. It was somewhat eye brow raising to the company. My NTP monitored servers were shown to be diverging their GPS/NTP, but after looking at twice or thrice, it was the other way around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Sun Dec 30 17:29:37 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Dec 2018 19:29:37 +0200 Subject: CenturyLink In-Reply-To: <6b00b11fbf704d3e814011d916527fd8@ox.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> Message-ID: Hey Matthew, > We use an older model of https://www.microsemi.com/product-directory/enterprise-network-time-servers/4117-syncserver-s600 with rubidium oscillator. Not cheap, but hardened and extremely accurate. Out of interest why rubidium? For short term stability oscillator choice isn't much of a matter for free running even rubidium will be off good +-1us per day or +-30us per week. I've always wondered what niche rubidium covers that isn't handled by much cheaper crystal ovens or actually precise oscillators. -- ++ytti From lguillory at reservetele.com Sun Dec 30 17:53:09 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Sun, 30 Dec 2018 17:53:09 +0000 Subject: CenturyLink In-Reply-To: <6b00b11fbf704d3e814011d916527fd8@ox.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com>, <6b00b11fbf704d3e814011d916527fd8@ox.com> Message-ID: <359C497A-920B-488D-BD7E-B15B9F895FD8@reservetele.com> We have a few s600’s deployed as well, rock solid and van handle 10k+ queries a second. ns Sent from my iPhone On Dec 30, 2018, at 11:22 AM, Matthew Huff > wrote: We use an older model of https://www.microsemi.com/product-directory/enterprise-network-time-servers/4117-syncserver-s600 with rubidium oscillator. Not cheap, but hardened and extremely accurate. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 From: Shawn L [mailto:shawnl at up.net] Sent: Sunday, December 30, 2018 9:40 AM To: nanog at nanog.org Cc: Matthew Huff >; list at satchell.net Subject: Re: CenturyLink Speaking of GPS-enabled NTP appliances, etc. wondering what hardware people are using for this. thanks -----Original Message----- From: "Raymond Burkholder" > Sent: Saturday, December 29, 2018 12:01pm To: "Matthew Huff" >, "list at satchell.net" >, "nanog at nanog.org" > Subject: Re: CenturyLink On 2018-12-29 7:51 a.m., Matthew Huff wrote: > We have two stratum-1 servers synced with GPS and a PTP feed from a provider that also provides PTP to market data systems, but we still have to monitor drift between system time and NIST time. Don't ask for the logic behind it, it's a regulation, not a technical requirement. > On one occasion, due to bad firmware or a configuration issue, I have seen GPS stratum 1 diverge from NTP. It was somewhat eye brow raising to the company. My NTP monitored servers were shown to be diverging their GPS/NTP, but after looking at twice or thrice, it was the other way around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhuff at ox.com Sun Dec 30 18:04:56 2018 From: mhuff at ox.com (Matthew Huff) Date: Sun, 30 Dec 2018 18:04:56 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> Message-ID: Regulatory. If we were to lose the GPS signal (antenna failure, etc...) then our stratum 1 time sources wouldn't drift as much and as quickly. For telco and general usage, the cost may not be worthwhile, but when you have auditors looking over your shoulder.... ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: Saku Ytti [mailto:saku at ytti.fi] Sent: Sunday, December 30, 2018 12:30 PM To: Matthew Huff Cc: Shawn L ; nanog at nanog.org Subject: Re: CenturyLink Hey Matthew, > We use an older model of https://www.microsemi.com/product-directory/enterprise-network-time-servers/4117-syncserver-s600 with rubidium oscillator. Not cheap, but hardened and extremely accurate. Out of interest why rubidium? For short term stability oscillator choice isn't much of a matter for free running even rubidium will be off good +-1us per day or +-30us per week. I've always wondered what niche rubidium covers that isn't handled by much cheaper crystal ovens or actually precise oscillators. -- ++ytti From saku at ytti.fi Sun Dec 30 18:39:55 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Dec 2018 20:39:55 +0200 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> Message-ID: On Sun, 30 Dec 2018 at 20:04, Matthew Huff wrote: > Regulatory. > If we were to lose the GPS signal (antenna failure, etc...) then our stratum 1 time sources wouldn't drift as much and as quickly. For telco and general usage, the cost may not be worthwhile, but when you have auditors looking over your shoulder.... Do you happen to recall specifics? What type of accuracy do you have to retain GPS free and for how long and who does fall under the regulatory requirements? Thanks! -- ++ytti From gem at rellim.com Mon Dec 31 02:58:54 2018 From: gem at rellim.com (Gary E. Miller) Date: Sun, 30 Dec 2018 18:58:54 -0800 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> Message-ID: <20181230185854.678a278d@spidey.rellim.com> Yo Saku! On Sun, 30 Dec 2018 19:29:37 +0200 Saku Ytti wrote: > I've always wondered what > niche rubidium covers that isn't handled by much cheaper crystal ovens > or actually precise oscillators. The Rb frequency reference will be two or three orders of magnitude more stable than an expensive ovenized crystal. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From ESundberg at nitelusa.com Mon Dec 31 03:29:21 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 31 Dec 2018 03:29:21 +0000 Subject: Service Provider NetFlow Collectors Message-ID: Hi Nanog.... We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons... What to watch out for any info would help. We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. We are looking at ManageEngine Netflow Analyzer PRTG Plixer - Scrutinizer PeakFlow Kentik Solarwinds NTA Thanks in advance... Erik ________________________________ 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 mgehrmann at atlassian.com Mon Dec 31 04:44:38 2018 From: mgehrmann at atlassian.com (Michael Gehrmann) Date: Mon, 31 Dec 2018 15:44:38 +1100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: Add Flowtraq to your list. Cheers Mike On Mon, 31 Dec 2018 at 14:30, Erik Sundberg wrote: > Hi Nanog…. > > > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > > > We are looking at > > ManageEngine Netflow Analyzer > > PRTG > > Plixer – Scrutinizer > > PeakFlow > > Kentik > > Solarwinds NTA > > > > > > Thanks in advance… > > > > Erik > > > > ------------------------------ > > 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 aaron1 at gvtc.com Mon Dec 31 05:47:13 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sun, 30 Dec 2018 23:47:13 -0600 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: I’m still using nfsen/nfdump Been looking at manageengine netflow analyzer lately and liking it, we might be buying some time on Calix flowanalyze which might be an improved version of xangati Aaron > On Dec 30, 2018, at 10:44 PM, Michael Gehrmann wrote: > > > Add Flowtraq to your list. > > Cheers > Mike > > >> On Mon, 31 Dec 2018 at 14:30, Erik Sundberg wrote: >> Hi Nanog…. >> >> >> >> We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. >> >> >> >> We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. >> >> >> >> We are looking at >> >> ManageEngine Netflow Analyzer >> >> PRTG >> >> Plixer – Scrutinizer >> >> PeakFlow >> >> Kentik >> >> Solarwinds NTA >> >> >> >> >> >> Thanks in advance… >> >> >> >> Erik >> >> >> >> >> >> 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 saku at ytti.fi Mon Dec 31 08:28:25 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 31 Dec 2018 10:28:25 +0200 Subject: CenturyLink In-Reply-To: <20181230185854.678a278d@spidey.rellim.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> <20181230185854.678a278d@spidey.rellim.com> Message-ID: Hey Gary, On Mon, 31 Dec 2018 at 05:02, Gary E. Miller wrote: > The Rb frequency reference will be two or three orders of magnitude > more stable than an expensive ovenized crystal. Perhaps, but not supported by this: https://www.meinbergglobal.com/english/specs/gpsopt.htm For the tl;dr folk, crystal drifts +-4.5us per day, Rb +-1.1us (both seem like unsatisfactorily high numbers to me, i.e. you don't want to be free-running 24h with Rb). Luckily today we have GPS, Glonass, BeiDou, Galileo and couple smaller ones, so there should be somewhat reasonable amount of redundancy. Unsure which commercially available NTP or PPP master clocks support all four. But I of course readily accept Rb is objectively more accurate than crystal, I'm just curious where it matters and I'm curious which regulation applies, who fall under the regulation and what specifically does the regulation require about free-running accuracy. -- ++ytti From lists at benappy.com Mon Dec 31 09:40:40 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Mon, 31 Dec 2018 10:40:40 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: Don’t underestimate good old ELK https://www.elastic.co/guide/en/logstash/current/netflow-module.html + https://github.com/robcowart/elastiflow BR, ic > On 31 Dec 2018, at 04:29, Erik Sundberg wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > > 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 eric at emj.se Mon Dec 31 09:52:27 2018 From: eric at emj.se (=?UTF-8?Q?Eric_Lindsj=c3=b6?=) Date: Mon, 31 Dec 2018 10:52:27 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> Hi, We use kentik and we're very happy. Works great, tons of new features coming along all the time. Going to start looking into ddos detection and mitigation soon. Would recommend. Kind regards, Eric Lindsjö On 12/31/2018 04:29 AM, Erik Sundberg wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what > other service providers are using to collect netflow data off their > Core and Edge Routers. Pros/Cons… What to watch out for any info would > help. > > We are mainly looking to analyze the netflow data. Bonus if it does > ddos detection and mitigation. > > We are looking at > > ManageEngine Netflow Analyzer > > PRTG > > Plixer – Scrutinizer > > PeakFlow > > Kentik > > Solarwinds NTA > > Thanks in advance… > > Erik > > > ------------------------------------------------------------------------ > > 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 mhuff at ox.com Mon Dec 31 09:52:47 2018 From: mhuff at ox.com (Matthew Huff) Date: Mon, 31 Dec 2018 09:52:47 +0000 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> <20181230185854.678a278d@spidey.rellim.com> Message-ID: <934ddde1c0bc44e1b484e7787ffbc134@ox.com> There isn't a specific regulation on free-running GPS, just "due diligence". I work at a algorithmic program trading company (and have been for 20 years). We have a high ROI, the cost differential for the rubidium OC versus having to drop everything to conform to regulatory requirements due to a short GPS outage, makes this a no-brainer. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Saku Ytti Sent: Monday, December 31, 2018 3:28 AM To: Gary E. Miller Cc: nanog at nanog.org Subject: Re: CenturyLink Hey Gary, On Mon, 31 Dec 2018 at 05:02, Gary E. Miller wrote: > The Rb frequency reference will be two or three orders of magnitude > more stable than an expensive ovenized crystal. Perhaps, but not supported by this: https://www.meinbergglobal.com/english/specs/gpsopt.htm For the tl;dr folk, crystal drifts +-4.5us per day, Rb +-1.1us (both seem like unsatisfactorily high numbers to me, i.e. you don't want to be free-running 24h with Rb). Luckily today we have GPS, Glonass, BeiDou, Galileo and couple smaller ones, so there should be somewhat reasonable amount of redundancy. Unsure which commercially available NTP or PPP master clocks support all four. But I of course readily accept Rb is objectively more accurate than crystal, I'm just curious where it matters and I'm curious which regulation applies, who fall under the regulation and what specifically does the regulation require about free-running accuracy. -- ++ytti From jk at ip-clear.de Mon Dec 31 09:59:12 2018 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Mon, 31 Dec 2018 10:59:12 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: <1CEFBBD5-E7CE-484C-8155-F9FDB7C5B048@ip-clear.de> Hi, I am always peeking at this OSS project for new installations https://github.com/VerizonDigital/vflow - but did not try it out myself so far. Jörg On 31 Dec 2018, at 4:29, Erik Sundberg wrote: > Hi Nanog.... > > We are looking at replacing our Netflow collector. I am wonder what > other service providers are using to collect netflow data off their > Core and Edge Routers. Pros/Cons... What to watch out for any info > would help. > > We are mainly looking to analyze the netflow data. Bonus if it does > ddos detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer - Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance... > > Erik From karsten.elfenbein at gmail.com Mon Dec 31 10:35:23 2018 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Mon, 31 Dec 2018 11:35:23 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: An other tool worth looking into is Traffic Sentinel from inMon. Karsten Am Mo., 31. Dez. 2018 um 04:31 Uhr schrieb Erik Sundberg : > > Hi Nanog…. > > > > We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. > > > > We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. > > > > We are looking at > > ManageEngine Netflow Analyzer > > PRTG > > Plixer – Scrutinizer > > PeakFlow > > Kentik > > Solarwinds NTA > > > > > > Thanks in advance… > > > > Erik > > > > > ________________________________ > > 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. From SNaslund at medline.com Mon Dec 31 14:53:26 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 31 Dec 2018 14:53:26 +0000 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Not buying this explanation for a number of reasons : 1. Are you telling me that several line cards failed in multiple cities in the same way at the same time? Don't think so unless the same software fault was propagated to all of them. If the problem was that they needed to be reset, couldn't that be accomplished by simply reseating them? 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. Steven Naslund Chicago IL > > One thing that is troubling when reading that URL is that it appears several steps of restoration required teams to go onsite for local login, etc.,. Granted, to troubleshoot hardware you need to be physically present to pop a line card in and out, but CTL/LVL3 should have full out-of-band console and power control to all core devices, we shouldn't be waiting for someone to drive to a location to get console or do power cycling. And I would imagine the first step to alot of the troubleshooting was power cycling and local console logs. > > > -John > > > > On 12/30/18 10:42 AM, Mike Hammett wrote: > > It's technical enough so that laypeople immediately lose interest, yet completely useless to anyone that works with this stuff. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ________________________________ > From: "Saku Ytti" > To: "nanog list" > Sent: Sunday, December 30, 2018 7:42:49 AM > Subject: CenturyLink RCA? > > Apologies for the URL, I do not know official source and I do not > share the URLs sentiment. > https://fuckingcenturylink.com/ > > Can someone translate this to IP engineer? What did actually happen? > From my own history, I rarely recognise the problem I fixed from > reading the public RCA. I hope CenturyLink will do better. > > Best guess so far that I've heard is > > a) CenturyLink runs global L2 DCN/OOB > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > I've had this failure mode) > c) DCN had direct access to control-plane, and L2 congested > control-plane resources causing it to deprovision waves > > Now of course this is entirely speculation, but intended to show what > type of explanation is acceptable and can be used to fix things. > Hopefully CenturyLink does come out with IP-engineering readable > explanation, so that we may use it as leverage to support work in our > own domains to remove such risks. > > a) do not run L2 DCN/OOB > b) do not connect MGMT ETH (it is unprotected access to control-plane, > it cannot be protected by CoPP/lo0 filter/LPTS ec) > c) do add in your RFP scoring item for proper OOB port (Like Cisco > CMP) > d) do fail optical network up > > -- > ++ytti > -- ++ytti From saku at ytti.fi Mon Dec 31 15:06:35 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 31 Dec 2018 17:06:35 +0200 Subject: CenturyLink RCA? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Message-ID: Hey Steve, I will continue to speculate, as that's all we have. > 1. Are you telling me that several line cards failed in multiple cities in the same way at the same time? Don't think so unless the same software fault was propagated to all of them. If the problem was that they needed to be reset, couldn't that be accomplished by simply reseating them? L2 DCN/OOB, whole network shares single broadcast domain > 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. L2 loop. You will kill your JNPR/CSCO with enough trash on MGMT ETH. However I can be argued that optical network should fail up in absence of control-plane, IP network has to fail down. > 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? BPDU > My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. Lot of possible reasons, I choose to believe what they've communicated is what the writer of the communication thought that happened, but as they likely are not SME it's broken radio communication. BCAST storm on L2 DCN would plausibly fit the very ambiguous reason offered and is something people actually are doing. -- ++ytti From bruns at 2mbit.com Mon Dec 31 15:20:52 2018 From: bruns at 2mbit.com (Brielle) Date: Mon, 31 Dec 2018 08:20:52 -0700 Subject: CenturyLink RCA? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Message-ID: <4AB2DE86-53D2-4E74-A676-A0A7528519EA@2mbit.com> (Forgive my top posting, not on my desktop as I’m out of town) Wild guess, based on my own experience as a NOC admin/head of operations at a large ISP - they have an automated deployment system for new firmware for a (mission critical) piece of backbone hardware. They may have tested said firmware on a chassis with cards that did not exactly match the hardware they had in actual deployment (ie: card was older hw revision in deployed hardware), and while it worked fine there, it proceeded shit the bed in the production. Or, they missed a mandatory low level hardware firmware upgrade that has to be applied separately before the other main upgrade. Kinda picturing in my mind that they staged all the updates, set a timer, staggered reboot, and after the first hit the fan, they couldn’t stop the rest as it fell apart as each upgraded unit fell on its own sword on reboot. I’ve been bit by the ‘this card revision is not supported under this platform/release’ bug more often then I’d like to admit. And, yes, my eyes did start to get glossy and hazy the more I read their explanation as well. It’s exactly the kind of useless post I’d write when I want to get (stupid) people off my back about a problem. Sent from my iPad > On Dec 31, 2018, at 7:53 AM, Naslund, Steve wrote: > > Not buying this explanation for a number of reasons : > > 1. Are you telling me that several line cards failed in multiple cities in the same way at the same time? Don't think so unless the same software fault was propagated to all of them. If the problem was that they needed to be reset, couldn't that be accomplished by simply reseating them? > > 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. > > 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? > > My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. > > Steven Naslund > Chicago IL > >> >> One thing that is troubling when reading that URL is that it appears several steps of restoration required teams to go onsite for local login, etc.,. Granted, to troubleshoot hardware you need to be physically present to pop a line card in and out, but CTL/LVL3 should have full out-of-band console and power control to all core devices, we shouldn't be waiting for someone to drive to a location to get console or do power cycling. And I would imagine the first step to alot of the troubleshooting was power cycling and local console logs. >> >> >> -John >> >> >> >> On 12/30/18 10:42 AM, Mike Hammett wrote: >> >> It's technical enough so that laypeople immediately lose interest, yet completely useless to anyone that works with this stuff. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ________________________________ >> From: "Saku Ytti" >> To: "nanog list" >> Sent: Sunday, December 30, 2018 7:42:49 AM >> Subject: CenturyLink RCA? >> >> Apologies for the URL, I do not know official source and I do not >> share the URLs sentiment. >> https://fuckingcenturylink.com/ >> >> Can someone translate this to IP engineer? What did actually happen? >> From my own history, I rarely recognise the problem I fixed from >> reading the public RCA. I hope CenturyLink will do better. >> >> Best guess so far that I've heard is >> >> a) CenturyLink runs global L2 DCN/OOB >> b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, >> I've had this failure mode) >> c) DCN had direct access to control-plane, and L2 congested >> control-plane resources causing it to deprovision waves >> >> Now of course this is entirely speculation, but intended to show what >> type of explanation is acceptable and can be used to fix things. >> Hopefully CenturyLink does come out with IP-engineering readable >> explanation, so that we may use it as leverage to support work in our >> own domains to remove such risks. >> >> a) do not run L2 DCN/OOB >> b) do not connect MGMT ETH (it is unprotected access to control-plane, >> it cannot be protected by CoPP/lo0 filter/LPTS ec) >> c) do add in your RFP scoring item for proper OOB port (Like Cisco >> CMP) >> d) do fail optical network up >> >> -- >> ++ytti >> > > > -- > ++ytti From SNaslund at medline.com Mon Dec 31 15:23:52 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 31 Dec 2018 15:23:52 +0000 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED3982@WAUPRDMBXP1.medline.com> See my comments in line. Steve >Hey Steve, >I will continue to speculate, as that's all we have. > 1. Are you telling me that several line cards failed in multiple cities in the same way at the same time? Don't think so unless the same software fault was propagated to all of them. If the problem was that they needed to be reset, >couldn't that be accomplished by simply reseating them? >L2 DCN/OOB, whole network shares single broadcast domain. Bad design if that’s the case, that would be a huge subnet. However even if that was the case, you would not need to replace hardware in multiple places. You might have to reset it but not replace it. Also being an ILEC it seems hard to believe how long their dispatches to their own central office took. It might have taken awhile to locate the original problem but they should have been able to send a corrective procedure to CO personnel who are a lot closer to the equipment. In my region (Northern Illinois) we can typically get access to a CO in under 30 minutes 24/7. They are essentially smart hands technicians that can reseat or replace line cards. > 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid >frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. >L2 loop. You will kill your JNPR/CSCO with enough trash on MGMT ETH. >However I can be argued that optical network should fail up in absence of control-plane, IP network has to fail down. Most of the optical muxes I have worked with will run without any management card or control plane at all. Usually the line cards keep forwarding according to the existing configuration even in the absence of all management functions. It would help if we knew what gear this was. True optical muxes do not require much care and feeding once they have a configuration loaded. If they are truly dependent on that control plane, then it needs to be redundant enough with watch dogs to reset them if they become non responsive and they need policers and rate limiter on their interfaces. Seems they would be vulnerable to a DoS if a bad BPDU can wipe them out. > 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? >BPDU Maybe, it would be strange that it was invalid but valid enough to continue forwarding. In any case loss of the management network should not interrupt forwarding. I also would not be happy with an optical network that relies on spanning tree to remain operational. > My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. >Lot of possible reasons, I choose to believe what they've communicated is what the writer of the communication thought that happened, but as they likely are not SME it's broken radio communication. BCAST storm on L2 DCN >would plausibly fit the very ambiguous reason offered and is something people actually are doing. My biggest problem with their explanation is the replacement of line cards in multiple cities. The only way that happens is when bad code gets pushed to them. If it took them that long to fix an L2 broadcast storm, something is seriously wrong with their engineering. Resetting the management interfaces should be sufficient once the offending line card is removed. That is why I think this was a software update failure or a configuration push. Either way, they should be jumping up and down on their vendor as to why this caused such large scale effects. From SNaslund at medline.com Mon Dec 31 15:26:52 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 31 Dec 2018 15:26:52 +0000 Subject: CenturyLink RCA? In-Reply-To: <4AB2DE86-53D2-4E74-A676-A0A7528519EA@2mbit.com> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <4AB2DE86-53D2-4E74-A676-A0A7528519EA@2mbit.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED3999@WAUPRDMBXP1.medline.com> I agree 100%. Now they need to figure out why bricking the management network stopped forwarding on the optical side. > (Forgive my top posting, not on my desktop as I’m out of town) Steven Naslund Chicago IL > >Wild guess, based on my own experience as a NOC admin/head of operations at a large ISP - they have an automated deployment system for new firmware for a (mission critical) piece of backbone hardware. > >They may have tested said firmware on a chassis with cards that did not exactly match the hardware they had in actual deployment (ie: card was older hw revision in deployed hardware), and while it worked fine there, it proceeded >shit the bed in the production. > >Or, they missed a mandatory low level hardware firmware upgrade that has to be applied separately before the other main upgrade. > >Kinda picturing in my mind that they staged all the updates, set a timer, staggered reboot, and after the first hit the fan, they couldn’t stop the rest as it fell apart as each upgraded unit fell on its own sword on reboot. > >I’ve been bit by the ‘this card revision is not supported under this platform/release’ bug more often then I’d like to admit. > >And, yes, my eyes did start to get glossy and hazy the more I read their explanation as well. It’s exactly the kind of useless post I’d write when I want to get (stupid) people off my back about a problem. From SNaslund at medline.com Mon Dec 31 15:31:51 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 31 Dec 2018 15:31:51 +0000 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> They shouldn’t need OOB to operate existing lambdas just to configure new ones. One possibility is that the management interface also handles master timing which would be a really bad idea but possible (should be redundant and it should be able to free run for a reasonable amount of time). The main issue exposed is that obviously the management interface is critical and is not redundant enough. That is if we believe the OOB explanation in the first place (which by the way is obviously not OOB since it wiped out the in band network when it failed). Steven Naslund Chicago IL >This seems entirely plausible given that DWDM amplifiers and lasers being a complex analog system, they need OOB to align. >-- >Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Mon Dec 31 16:36:36 2018 From: bryan at shout.net (Bryan Holloway) Date: Mon, 31 Dec 2018 10:36:36 -0600 Subject: Service Provider NetFlow Collectors In-Reply-To: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> Message-ID: <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> +1 Kentik ... We've been using their DDoS/RTBH mitigation with good success. On 12/31/18 3:52 AM, Eric Lindsjö wrote: > Hi, > > We use kentik and we're very happy. Works great, tons of new features > coming along all the time. Going to start looking into ddos detection > and mitigation soon. > > Would recommend. > > Kind regards, > Eric Lindsjö > > > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >> >> Hi Nanog…. >> >> We are looking at replacing our Netflow collector. I am wonder what >> other service providers are using to collect netflow data off their >> Core and Edge Routers. Pros/Cons… What to watch out for any info would >> help. >> >> We are mainly looking to analyze the netflow data. Bonus if it does >> ddos detection and mitigation. >> >> We are looking at >> >> ManageEngine Netflow Analyzer >> >> PRTG >> >> Plixer – Scrutinizer >> >> PeakFlow >> >> Kentik >> >> Solarwinds NTA >> >> Thanks in advance… >> >> Erik >> >> >> ------------------------------------------------------------------------ >> >> 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. > From nanog at ics-il.net Mon Dec 31 16:40:45 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 31 Dec 2018 10:40:45 -0600 (CST) Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: <2066108599.2244.1546274442993.JavaMail.mhammett@ThunderFuck> I just recently rolled out Elastiflow. Lots of great information. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Michel 'ic' Luczak" To: "Erik Sundberg" Cc: nanog at nanog.org Sent: Monday, December 31, 2018 3:40:40 AM Subject: Re: Service Provider NetFlow Collectors Don’t underestimate good old ELK https://www.elastic.co/guide/en/logstash/current/netflow-module.html + https://github.com/robcowart/elastiflow BR, ic On 31 Dec 2018, at 04:29, Erik Sundberg < ESundberg at nitelusa.com > wrote: Hi Nanog…. We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. We are looking at ManageEngine Netflow Analyzer PRTG Plixer – Scrutinizer PeakFlow Kentik Solarwinds NTA Thanks in advance… Erik 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 Romeo.Czumbil at tierpoint.com Mon Dec 31 17:19:13 2018 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Mon, 31 Dec 2018 17:19:13 +0000 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: <5d56f30da9e442ac8ce0788afd742b7a@hwt01-ex01.tierpoint.net> I personally recommend Kentik. We mainly got it for DDoS detection which so far been 100% reliable for us Now we also use it for other traffic analysis. Query is extremely fast. Support is also fantastic. If you're looking for a feature that they may not have, just ask... From: NANOG On Behalf Of Erik Sundberg Sent: Sunday, December 30, 2018 10:29 PM To: nanog at nanog.org Subject: Service Provider NetFlow Collectors Hi Nanog.... We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons... What to watch out for any info would help. We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. We are looking at ManageEngine Netflow Analyzer PRTG Plixer - Scrutinizer PeakFlow Kentik Solarwinds NTA Thanks in advance... Erik ________________________________________ 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. From dave at temk.in Mon Dec 31 17:41:46 2018 From: dave at temk.in (Dave Temkin) Date: Mon, 31 Dec 2018 13:41:46 -0400 Subject: CenturyLink RCA? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> Message-ID: On Mon, Dec 31, 2018 at 11:33 AM Naslund, Steve wrote: > They shouldn’t need OOB to operate existing lambdas just to configure new > ones. One possibility is that the management interface also handles master > timing which would be a really bad idea but possible (should be redundant > and it should be able to free run for a reasonable amount of time). The > main issue exposed is that obviously the management interface is critical > and is not redundant enough. That is if we believe the OOB explanation in > the first place (which by the way is obviously not OOB since it wiped out > the in band network when it failed). > > > > Steven Naslund > > Chicago IL > > > A theory, and only a theory, is that they decided to, in order to troubleshoot a much smaller problem (OOB/etc.), deploy an optical configuration change that, when faced with inaccessibility to multiple nodes, ended up causing a significant inconsistency in their optical network, wreaking havoc on all sorts of other systems. With the OOB network already in chaos, card reseats were required to stabilize things on that network and then they could rebuild the optical network from a fully reachable state. Again, only a theory. -Dave > > > >This seems entirely plausible given that DWDM amplifiers and lasers > being a complex analog system, they need OOB to align. > > >-- > > >Eric > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at corp.crocker.com Mon Dec 31 17:56:18 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Mon, 31 Dec 2018 17:56:18 +0000 Subject: Service Provider NetFlow Collectors In-Reply-To: <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> Message-ID: <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to worry about it. On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" wrote: +1 Kentik ... We've been using their DDoS/RTBH mitigation with good success. On 12/31/18 3:52 AM, Eric Lindsjö wrote: > Hi, > > We use kentik and we're very happy. Works great, tons of new features > coming along all the time. Going to start looking into ddos detection > and mitigation soon. > > Would recommend. > > Kind regards, > Eric Lindsjö > > > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >> >> Hi Nanog…. >> >> We are looking at replacing our Netflow collector. I am wonder what >> other service providers are using to collect netflow data off their >> Core and Edge Routers. Pros/Cons… What to watch out for any info would >> help. >> >> We are mainly looking to analyze the netflow data. Bonus if it does >> ddos detection and mitigation. >> >> We are looking at >> >> ManageEngine Netflow Analyzer >> >> PRTG >> >> Plixer – Scrutinizer >> >> PeakFlow >> >> Kentik >> >> Solarwinds NTA >> >> Thanks in advance… >> >> Erik >> >> >> ------------------------------------------------------------------------ >> >> 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. > From saku at ytti.fi Mon Dec 31 18:00:04 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 31 Dec 2018 20:00:04 +0200 Subject: CenturyLink In-Reply-To: <934ddde1c0bc44e1b484e7787ffbc134@ox.com> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> <20181230185854.678a278d@spidey.rellim.com> <934ddde1c0bc44e1b484e7787ffbc134@ox.com> Message-ID: Hey Matthew, Thi > There isn't a specific regulation on free-running GPS, just "due diligence". I work at a algorithmic program trading company (and have been for 20 years). We have a high ROI, the cost differential for the rubidium OC versus having to drop everything to conform to regulatory requirements due to a short GPS outage, makes this a no-brainer. Thanks, this makes sense to me. CAPEX on networking, systems etc does not matter to bottom line, so no point knowing or figuring out if thing NEEDS to be better, because objectively it is better and cost is irrelevant. -- ++ytti From aaron1 at gvtc.com Mon Dec 31 18:49:38 2018 From: aaron1 at gvtc.com (Aaron1) Date: Mon, 31 Dec 2018 12:49:38 -0600 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> Message-ID: Yeah, could have been one of those...gone from bad to worse things like Dave mentioned... initial problem and course of action perhaps led to a worse problem. I’ve had DWDM issues that have taken down multiple locations far apart from each other due to how the transport guys hauled stuff A few years back I had about 15 routers all reboot suddenly... they were all far apart from each other, turned out to be one of the dual bgp sessions to rr cluster flapped and all 15 routers crash rebooted. But ~50 hours of downtime !? Aaron > On Dec 31, 2018, at 11:41 AM, Dave Temkin wrote: > >> On Mon, Dec 31, 2018 at 11:33 AM Naslund, Steve wrote: > >> They shouldn’t need OOB to operate existing lambdas just to configure new ones. One possibility is that the management interface also handles master timing which would be a really bad idea but possible (should be redundant and it should be able to free run for a reasonable amount of time). The main issue exposed is that obviously the management interface is critical and is not redundant enough. That is if we believe the OOB explanation in the first place (which by the way is obviously not OOB since it wiped out the in band network when it failed). >> >> >> >> Steven Naslund >> >> Chicago IL >> >> >> > > A theory, and only a theory, is that they decided to, in order to troubleshoot a much smaller problem (OOB/etc.), deploy an optical configuration change that, when faced with inaccessibility to multiple nodes, ended up causing a significant inconsistency in their optical network, wreaking havoc on all sorts of other systems. With the OOB network already in chaos, card reseats were required to stabilize things on that network and then they could rebuild the optical network from a fully reachable state. > > Again, only a theory. > > -Dave > > >> >> >> >This seems entirely plausible given that DWDM amplifiers and lasers being a complex analog system, they need OOB to align. >> >> >-- >> >> >Eric >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ler762 at gmail.com Mon Dec 31 19:02:00 2018 From: ler762 at gmail.com (Lee) Date: Mon, 31 Dec 2018 14:02:00 -0500 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> Message-ID: On 12/31/18, Aaron1 wrote: > Yeah, could have been one of those...gone from bad to worse things like Dave > mentioned... initial problem and course of action perhaps led to a worse > problem. > > I’ve had DWDM issues that have taken down multiple locations far apart from > each other due to how the transport guys hauled stuff > > A few years back I had about 15 routers all reboot suddenly... they were all > far apart from each other, turned out to be one of the dual bgp sessions to > rr cluster flapped and all 15 routers crash rebooted. > > But ~50 hours of downtime !? It could have been worse: https://www.cio.com.au/article/65115/all_systems_down/ From nick.z.edwards at gmail.com Sat Dec 29 01:36:26 2018 From: nick.z.edwards at gmail.com (Nick Edwards) Date: Sat, 29 Dec 2018 11:36:26 +1000 Subject: IP Dslams Message-ID: Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag2400 at gmail.com Sun Dec 30 01:21:36 2018 From: ag2400 at gmail.com (Aaron Graves) Date: Sat, 29 Dec 2018 19:21:36 -0600 Subject: Disney+ CDN Message-ID: Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.carroll at telplicity.com Sun Dec 30 15:46:06 2018 From: joe.carroll at telplicity.com (Joe Carroll) Date: Sun, 30 Dec 2018 10:46:06 -0500 Subject: CenturyLink RCA? In-Reply-To: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> Message-ID: Technical obscurity... managed perception. On Sun, Dec 30, 2018 at 10:43 Mike Hammett wrote: > It's technical enough so that laypeople immediately lose interest, yet > completely useless to anyone that works with this stuff. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Saku Ytti" > *To: *"nanog list" > *Sent: *Sunday, December 30, 2018 7:42:49 AM > *Subject: *CenturyLink RCA? > > Apologies for the URL, I do not know official source and I do not > share the URLs sentiment. > https://fuckingcenturylink.com/ > > Can someone translate this to IP engineer? What did actually happen? > From my own history, I rarely recognise the problem I fixed from > reading the public RCA. I hope CenturyLink will do better. > > Best guess so far that I've heard is > > a) CenturyLink runs global L2 DCN/OOB > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > I've had this failure mode) > c) DCN had direct access to control-plane, and L2 congested > control-plane resources causing it to deprovision waves > > Now of course this is entirely speculation, but intended to show what > type of explanation is acceptable and can be used to fix things. > Hopefully CenturyLink does come out with IP-engineering readable > explanation, so that we may use it as leverage to support work in our > own domains to remove such risks. > > a) do not run L2 DCN/OOB > b) do not connect MGMT ETH (it is unprotected access to control-plane, > it cannot be protected by CoPP/lo0 filter/LPTS ec) > c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) > d) do fail optical network up > > > -- > ++ytti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Sun Dec 30 17:46:05 2018 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sun, 30 Dec 2018 20:46:05 +0300 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> Message-ID: There's a Reddit user claiming he works at CL who says the reason were some faulty Infinera DTN-X instances. https://www.reddit.com/r/centurylink/comments/aa2qa4/comment/ecovgab (dunno though why the user posted that to Reddit and not here) 30 Dec. 2018 г., 20:19 Saku Ytti : > Hey John, > > Your criticism is warranted, but would also be addressed by > explanation DCN/OOB being the source of the problem. > > At any rate, I am looking forward to stop speculating and start > reading post-mortem written by someone who knows how networks work. > > On Sun, 30 Dec 2018 at 18:28, John Von Essen wrote: > > > > One thing that is troubling when reading that URL is that it appears > several steps of restoration required teams to go onsite for local login, > etc.,. Granted, to troubleshoot hardware you need to be physically present > to pop a line card in and out, but CTL/LVL3 should have full out-of-band > console and power control to all core devices, we shouldn't be waiting for > someone to drive to a location to get console or do power cycling. And I > would imagine the first step to alot of the troubleshooting was power > cycling and local console logs. > > > > > > -John > > > > > > > > On 12/30/18 10:42 AM, Mike Hammett wrote: > > > > It's technical enough so that laypeople immediately lose interest, yet > completely useless to anyone that works with this stuff. > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ________________________________ > > From: "Saku Ytti" > > To: "nanog list" > > Sent: Sunday, December 30, 2018 7:42:49 AM > > Subject: CenturyLink RCA? > > > > Apologies for the URL, I do not know official source and I do not > > share the URLs sentiment. > > https://fuckingcenturylink.com/ > > > > Can someone translate this to IP engineer? What did actually happen? > > From my own history, I rarely recognise the problem I fixed from > > reading the public RCA. I hope CenturyLink will do better. > > > > Best guess so far that I've heard is > > > > a) CenturyLink runs global L2 DCN/OOB > > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > > I've had this failure mode) > > c) DCN had direct access to control-plane, and L2 congested > > control-plane resources causing it to deprovision waves > > > > Now of course this is entirely speculation, but intended to show what > > type of explanation is acceptable and can be used to fix things. > > Hopefully CenturyLink does come out with IP-engineering readable > > explanation, so that we may use it as leverage to support work in our > > own domains to remove such risks. > > > > a) do not run L2 DCN/OOB > > b) do not connect MGMT ETH (it is unprotected access to control-plane, > > it cannot be protected by CoPP/lo0 filter/LPTS ec) > > c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) > > d) do fail optical network up > > > > -- > > ++ytti > > > > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roland.Dobbins at netscout.com Mon Dec 31 03:59:33 2018 From: Roland.Dobbins at netscout.com (Dobbins, Roland) Date: Mon, 31 Dec 2018 03:59:33 +0000 Subject: Larry Roberts, RIP. Message-ID: <33F4C89F-F05B-470F-B2D4-6254EA75421A@netscout.com> -------------------------------------------- Roland Dobbins From eric at ipergy.net Mon Dec 31 15:23:31 2018 From: eric at ipergy.net (Eric Loos) Date: Mon, 31 Dec 2018 16:23:31 +0100 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> Message-ID: This seems entirely plausible given that DWDM amplifiers and lasers being a complex analog system, they need OOB to align. -- Eric > On 31 Dec 2018, at 16:06, Saku Ytti wrote: > > Hey Steve, > > I will continue to speculate, as that's all we have. > >> 1. Are you telling me that several line cards failed in multiple cities in the same way at the same time? Don't think so unless the same software fault was propagated to all of them. If the problem was that they needed to be reset, couldn't that be accomplished by simply reseating them? > > L2 DCN/OOB, whole network shares single broadcast domain > >> 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. > > L2 loop. You will kill your JNPR/CSCO with enough trash on MGMT ETH. > However I can be argued that optical network should fail up in absence > of control-plane, IP network has to fail down. > >> 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? > > BPDU > >> My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. > > Lot of possible reasons, I choose to believe what they've communicated > is what the writer of the communication thought that happened, but as > they likely are not SME it's broken radio communication. BCAST storm > on L2 DCN would plausibly fit the very ambiguous reason offered and is > something people actually are doing. > > -- > ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Mon Dec 31 19:23:04 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 31 Dec 2018 19:23:04 +0000 Subject: IP Dslams In-Reply-To: References: Message-ID: I haven’t used any of theses… Check out Adtran Total Access 5000 Platform…. Used by a lot of EoC / EoDS1 carriers Google: Ethernet Extender DSLAM https://enableit.com/rackmount-extender/ From: NANOG On Behalf Of Nick Edwards Sent: Friday, December 28, 2018 7:36 PM To: nanog at nanog.org Subject: IP Dslams Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason) ________________________________ 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 briansupport at hotmail.com Mon Dec 31 19:43:29 2018 From: briansupport at hotmail.com (Brian R) Date: Mon, 31 Dec 2018 19:43:29 +0000 Subject: Disney+ CDN In-Reply-To: References: Message-ID: I would guess they are using the Hulu platform as the backend for their streaming services going forward. They are now the primary stakeholders in Hulu (purchase of Fox). I don't know if they do cache servers however. Brian ________________________________ From: NANOG on behalf of Aaron Graves Sent: Saturday, December 29, 2018 5:21 PM To: nanog at nanog.org Subject: Disney+ CDN Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Mon Dec 31 20:11:17 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 31 Dec 2018 20:11:17 +0000 Subject: CenturyLink RCA? In-Reply-To: References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ED39AD@WAUPRDMBXP1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED3BBE@WAUPRDMBXP1.medline.com> A note for the guys hanging on to those POTS lines…It won’t really help. One of our sites in Dubuque Iowa had ten CenturyLink PRIs (they are the LEC there) homed off of a 5ESS switch. These all were unable to process calls during the CenturyLink problem. The ISDN messaging returned indicated that the CL phone switch had no routes. This tells me that either their inter-switch trunking or SS7 network or both are being transported over the same optical network as the Internet services. So, even if your local line is POTS or traditional TDM it won’t matter if all of their transport is dependent on the IP world. Looking at the Reddit comments on the Infinera devices being a problem, that makes more sense because that device blurs the line between optical mux and IP enabled devices with its Ethernet mapping functions. One advantage of the pure optical mux is that it does not need, care, or understand L2 and L3 network protocols and are largely unaffected by those layers. Convergence in devices moving across more network layers exposes it to more potential bugs. Convergence can easily lead to more single points of failure and the traffic capacity of these devices kind of encourages carriers to put more stuff in one basket than they traditionally did. I understand the motivation to build a single high speed IP centric backbone but it makes everything dependent on that backbone. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Dec 31 20:19:31 2018 From: mel at beckman.org (Mel Beckman) Date: Mon, 31 Dec 2018 20:19:31 +0000 Subject: Larry Roberts, RIP. In-Reply-To: <33F4C89F-F05B-470F-B2D4-6254EA75421A@netscout.com> References: <33F4C89F-F05B-470F-B2D4-6254EA75421A@netscout.com> Message-ID: <1E58CD60-748B-4187-89F5-304891990F7C@beckman.org> Such irony that Roberts’ NYTimes article is behind a paywall :) Here’s a more informative, much more entertaining, and totally free article: https://www.i-programmer.info/news/82-heritage/12414-internet-pioneer-lawrence-roberts-dies-aged-81.html On Dec 30, 2018, at 7:59 PM, Dobbins, Roland > wrote: -------------------------------------------- Roland Dobbins > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at paulstewart.org Mon Dec 31 20:22:25 2018 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 31 Dec 2018 20:22:25 +0000 Subject: IP Dslams In-Reply-To: References: Message-ID: +1 for Adtran TA5000 .. we use them, my former employer uses them with great success. There’s also the Calix series of gear that is quite good too … From: NANOG on behalf of Erik Sundberg Date: Monday, December 31, 2018 at 2:31 PM To: Nick Edwards Cc: "nanog at nanog.org" Subject: RE: IP Dslams I haven’t used any of theses… Check out Adtran Total Access 5000 Platform…. Used by a lot of EoC / EoDS1 carriers Google: Ethernet Extender DSLAM https://enableit.com/rackmount-extender/ From: NANOG On Behalf Of Nick Edwards Sent: Friday, December 28, 2018 7:36 PM To: nanog at nanog.org Subject: IP Dslams Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason) ________________________________ 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 kmedcalf at dessus.com Mon Dec 31 20:31:24 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 31 Dec 2018 13:31:24 -0700 Subject: CenturyLink RCA? In-Reply-To: Message-ID: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> > It could have been worse: > https://www.cio.com.au/article/65115/all_systems_down/ "Make network changes only between 2am and 5am on weekends." Wow. Just wow. I suppose the IT types are considerably different than Process Operations. Our rule is to only make changes scheduled at 09:00 (or no later than will permit a complete backout and restore by 15:00) Local Time on "Full Staff" day that is not immediately preceded or followed by a reduced staff day, holiday, or weekend-day. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From bill at herrin.us Mon Dec 31 21:30:53 2018 From: bill at herrin.us (William Herrin) Date: Mon, 31 Dec 2018 13:30:53 -0800 Subject: CenturyLink RCA? In-Reply-To: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> References: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> Message-ID: On Mon, Dec 31, 2018 at 12:31 PM Keith Medcalf wrote: > > It could have been worse: > > https://www.cio.com.au/article/65115/all_systems_down/ > > "Make network changes only between 2am and 5am on weekends." > > Wow. Just wow. I suppose the IT types are considerably different > than Process Operations. Our rule is to only make changes > scheduled at 09:00 (or no later than will permit a complete backout > and restore by 15:00) Local Time on "Full Staff" day that is not > immediately preceded or followed by a reduced staff day, > holiday, or weekend-day. It depends on your system architecture. If you've built your redundancy well so that you have a continuously maintainable system then you do the work during normal staffing and only when followed by days when folks will be around to notice and fix any mistakes. If you require a disruptive maintenance window then you schedule it for minimum usage times instead. Other conclusions from the article are dubious as well: * Retire legacy network gear faster and create overall life cycle management for networking gear. Retire equipment when it ceases to be cost-effective, not merely because it was manufactured too many years ago. Just don't forget to factor risk in to the cost. * Document all changes, including keeping up-to-date physical and logical network diagrams. "Good intentions never work, you need good mechanisms to make anything happen." - Jeff Bezos Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Mon Dec 31 21:32:06 2018 From: bill at herrin.us (William Herrin) Date: Mon, 31 Dec 2018 13:32:06 -0800 Subject: CenturyLink RCA? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED3982@WAUPRDMBXP1.medline.com> References: <543548599.1639.1546184537220.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40318ED372E@WAUPRDMBXP1.medline.com> <9578293AE169674F9A048B2BC9A081B40318ED3982@WAUPRDMBXP1.medline.com> Message-ID: On Mon, Dec 31, 2018 at 7:24 AM Naslund, Steve wrote: > Bad design if that’s the case, that would be a huge subnet. According to the notes at the URL Saku shared, they suffered a cascade failure from which they needed the equipment vendor's help to recover. That indicates at least two grave design errors: 1. Vendor monoculture is a single point of failure. Same equipment running the same software triggers the same bug. It all kabooms at once. Different vendors running different implementations have compatibility issues but when one has a bug it's much less likely to take down all the rest. 2. Failure to implement system boundaries. When you automate systems it's important to restrict the reach of that automation. Whether it's a regional boundary or independent backbones, a critical system like this one should be structurally segmented so that malfunctioning automation can bring down only one piece of it. Regards, Bill Herrin However even if that was the case, you would not need to replace hardware in multiple places. You might have to reset it but not replace it. Also being an ILEC it seems hard to believe how long their dispatches to their own central office took. It might have taken awhile to locate the original problem but they should have been able to send a corrective procedure to CO personnel who are a lot closer to the equipment. In my region (Northern Illinois) we can typically get access to a CO in under 30 minutes 24/7. They are essentially smart hands technicians that can reseat or replace line cards. > > > 2. Do we believe that an OOB management card was able to generate so much traffic as to bring down the optical switching? Very doubtful which means that the systems were actually broken due to trying to PROCESS the "invalid >frames". Seems like very poor control plane management if the system is attempting to process invalid data and bringing down the forwarding plane. > > >L2 loop. You will kill your JNPR/CSCO with enough trash on MGMT ETH. > >However I can be argued that optical network should fail up in absence of control-plane, IP network has to fail down. > > Most of the optical muxes I have worked with will run without any management card or control plane at all. Usually the line cards keep forwarding according to the existing configuration even in the absence of all management functions. It would help if we knew what gear this was. True optical muxes do not require much care and feeding once they have a configuration loaded. If they are truly dependent on that control plane, then it needs to be redundant enough with watch dogs to reset them if they become non responsive and they need policers and rate limiter on their interfaces. Seems they would be vulnerable to a DoS if a bad > BPDU can wipe them out. > > > 3. In the cited document it was stated that the offending packet did not have source or destination information. If so, how did it get propagated throughout the network? > > >BPDU > > Maybe, it would be strange that it was invalid but valid enough to continue forwarding. In any case loss of the management network should not interrupt forwarding. I also would not be happy with an optical network that relies on spanning tree to remain operational. > > > My guess at the time and my current opinion (which has no real factual basis, just years of experience) is that a bad software package was propagated through their network. > > >Lot of possible reasons, I choose to believe what they've communicated is what the writer of the communication thought that happened, but as they likely are not SME it's broken radio communication. BCAST storm on L2 DCN >would plausibly fit the very ambiguous reason offered and is something people actually are doing. > > My biggest problem with their explanation is the replacement of line cards in multiple cities. The only way that happens is when bad code gets pushed to them. If it took them that long to fix an L2 broadcast storm, something is seriously wrong with their engineering. Resetting the management interfaces should be sufficient once the offending line card is removed. That is why I think this was a software update failure or a configuration push. Either way, they should be jumping up and down on their vendor as to why this caused such large scale effects. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From carl-lists at portnetworks.com Mon Dec 31 21:45:57 2018 From: carl-lists at portnetworks.com (Carl Peterson) Date: Mon, 31 Dec 2018 15:45:57 -0600 Subject: IP Dslams In-Reply-To: References: Message-ID: I'd consider breaking down the two functions. Set up your customer connections using ADSL Ethernet, etc and put each unit in the building on its own CVLAN. This should never change even when the subscribers in the unit change. This way you can configure it once and never touch it again. I'd use Calix G.fast but I have no idea what your budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are in general availability. Then hand the SVLAN with all the CVLANs off to the BNG and authenticate the circuits using IPoE. Waystream has an ASR6000 switch with BNG functionalities (I've never used it, just came across it when looking for other options to replace my MX BNG. On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards wrote: > Howdy, > We have a requirement for an aged care facility to provide voice and data, > we have the voice worked out, but data, WiFi is out of the question, so are > looking for IP-Dslams, preferably a system that is all-in-one, or self > contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has > a property managment API, or even just a webpage manager where admin can > add in new residents when they arive, or delete when they depart I know > these used to be available many years ago, but that vendor has like many > vanished, only requirement is for ADSL2+, prefer units with either 48 ports > or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 > etc) > > If anyone knows of such units, would appreciate some details on them, > brand/model suppliers if known, etc, we can try get out google fu back if > we have some steering:) > > Thank Y'all > > (resent - original never made it to the list for some gremlin reason) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Mon Dec 31 22:12:42 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 31 Dec 2018 16:12:42 -0600 Subject: IP Dslams In-Reply-To: References: Message-ID: Carl, What did you select to replace your MX BNG? To Nick, we use Adtran Total Access 5000's today. They work fine, but if I was doing a new install I would do Calix with their newer lines that have SDN BNG functions. Calix just has better CPE to go along with it, but they are just G.Fast and ethernet only CPE's. Why only ADSL2+? What are you doing for voice? Do you have access to Coax cable? If so I would do a small 32x10 CMTS with cable modem. Much cheaper and future proof. On Mon, Dec 31, 2018 at 3:47 PM Carl Peterson wrote: > I'd consider breaking down the two functions. > Set up your customer connections using ADSL Ethernet, etc and put each > unit in the building on its own CVLAN. This should never change even when > the subscribers in the unit change. This way you can configure it once and > never touch it again. I'd use Calix G.fast but I have no idea what your > budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are > in general availability. > > Then hand the SVLAN with all the CVLANs off to the BNG and authenticate > the circuits using IPoE. Waystream has an ASR6000 switch with BNG > functionalities (I've never used it, just came across it when looking for > other options to replace my MX BNG. > > On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards > wrote: > >> Howdy, >> We have a requirement for an aged care facility to provide voice and >> data, we have the voice worked out, but data, WiFi is out of the question, >> so are looking for IP-Dslams, preferably a system that is all-in-one, or >> self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as >> has a property managment API, or even just a webpage manager where admin >> can add in new residents when they arive, or delete when they depart I know >> these used to be available many years ago, but that vendor has like many >> vanished, only requirement is for ADSL2+, prefer units with either 48 ports >> or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 >> etc) >> >> If anyone knows of such units, would appreciate some details on them, >> brand/model suppliers if known, etc, we can try get out google fu back if >> we have some steering:) >> >> Thank Y'all >> >> (resent - original never made it to the list for some gremlin reason) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Mon Dec 31 22:14:26 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 31 Dec 2018 16:14:26 -0600 Subject: Service Provider NetFlow Collectors In-Reply-To: <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> Message-ID: Doesn't Kentik cost like $2000 a month minimum? On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker wrote: > +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to > worry about it. > > On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < > nanog-bounces at nanog.org on behalf of bryan at shout.net> wrote: > > +1 Kentik ... > > We've been using their DDoS/RTBH mitigation with good success. > > > On 12/31/18 3:52 AM, Eric Lindsjö wrote: > > Hi, > > > > We use kentik and we're very happy. Works great, tons of new > features > > coming along all the time. Going to start looking into ddos > detection > > and mitigation soon. > > > > Would recommend. > > > > Kind regards, > > Eric Lindsjö > > > > > > On 12/31/2018 04:29 AM, Erik Sundberg wrote: > >> > >> Hi Nanog…. > >> > >> We are looking at replacing our Netflow collector. I am wonder what > >> other service providers are using to collect netflow data off their > >> Core and Edge Routers. Pros/Cons… What to watch out for any info > would > >> help. > >> > >> We are mainly looking to analyze the netflow data. Bonus if it does > >> ddos detection and mitigation. > >> > >> We are looking at > >> > >> ManageEngine Netflow Analyzer > >> > >> PRTG > >> > >> Plixer – Scrutinizer > >> > >> PeakFlow > >> > >> Kentik > >> > >> Solarwinds NTA > >> > >> Thanks in advance… > >> > >> Erik > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> 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: