From randy at psg.com Thu Mar 1 00:57:46 2018 From: randy at psg.com (Randy Bush) Date: Thu, 01 Mar 2018 09:57:46 +0900 Subject: Removing the four stale TAL from the APNIC RPKI validation set. In-Reply-To: <64163AA3-B6FD-447F-9DC0-A05AF0B9A290@apnic.net> References: <64163AA3-B6FD-447F-9DC0-A05AF0B9A290@apnic.net> Message-ID: thanks for this, ggm. the one TA to rule them all seems to stay the same. but i have removed the pretenders. randy From job at ntt.net Thu Mar 1 01:52:48 2018 From: job at ntt.net (Job Snijders) Date: Thu, 1 Mar 2018 01:52:48 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180227215253.GA694@piranha.2bit.co> References: <20180227215253.GA694@piranha.2bit.co> Message-ID: <20180301015247.GA6721@vurt.meerval.net> On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: > On 2018-02-27, Ca By sent: > > Please do take a look at the cloudflare blog specifically as they > > name and shame OVH and Digital Ocean for being the primary sources > > of mega crap traffic > > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > Hi, DigitalOcean here. We've taken steps to mitigate this attack on > our network. NTT too has deployed rate limiters on all external facing interfaces on the GIN backbone - for UDP/11211 traffic - to dampen the negative impact of open memcached instances on peers and customers. The toxic combination of 'one spoofed packet can yield multiple reponse packets' and 'one small packet can yield a very big response' makes the memcached UDP protocol a fine example of double trouble with potential for severe operational impact. Kind regards, Job From cb.list6 at gmail.com Thu Mar 1 02:12:13 2018 From: cb.list6 at gmail.com (Ca By) Date: Thu, 01 Mar 2018 02:12:13 +0000 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180301015247.GA6721@vurt.meerval.net> References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> Message-ID: On Wed, Feb 28, 2018 at 5:54 PM Job Snijders wrote: > On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: > > On 2018-02-27, Ca By sent: > > > Please do take a look at the cloudflare blog specifically as they > > > name and shame OVH and Digital Ocean for being the primary sources > > > of mega crap traffic > > > > > > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > > > > > Also, policer all UDP all the time... UDP is unsafe at any speed. > > > > Hi, DigitalOcean here. We've taken steps to mitigate this attack on > > our network. > > NTT too has deployed rate limiters on all external facing interfaces on > the GIN backbone - for UDP/11211 traffic - to dampen the negative impact > of open memcached instances on peers and customers. > > The toxic combination of 'one spoofed packet can yield multiple reponse > packets' and 'one small packet can yield a very big response' makes the > memcached UDP protocol a fine example of double trouble with potential > for severe operational impact. > > Kind regards, > > Job Thanks Job. NTT is a very good internet steward, making common sense calls .... not just sling bits by the kilo for $ > From eric.kuhnke at gmail.com Thu Mar 1 18:32:12 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 1 Mar 2018 10:32:12 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <20180228123111.GF5969@hanna.meerval.net> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> Message-ID: On the other side: VM/VPS providers have a template based image that they use for every type and subtype of operating system it's possible to auto-provision. For example Ubuntu Server Xenial AMD64 or Debian Jessie or Stretch AMD64. It's important that VM/VPS providers don't push fresh images that have anything vulnerable, abusable or exploitable enabled by default. Not all VM/VPS providers do this. Standard sane configuration choices apply such as bind9 not being a recursive resolver by default. If individual Debian, CentOS, Ubuntu or whatever other distro packages for memcached or any other daemon have "listen on all interfaces = yes" or "listen on non-RFC1918 IP ranges = yes" turned on in their respective configurations, that would be an issue to take up with the package maintainers for the daemons. On Wed, Feb 28, 2018 at 4:31 AM, Job Snijders wrote: > Dear all, > > Before the group takes on the pitchforks and torches and travels down to > the hosting providers' headquarters - let's take a step back and look at > the root of this issue: the memcached software has failed both the > Internet community and its own memcached users. > > It is INSANE that memcached is/was[1] shipping with default settings > that make the daemon listen and respond on UDP on INADDR_ANY. Did nobody > take notes during the protocol wars where we were fodder for all the > CHARGEN & NTP ordnance? > > The memcached software shipped with a crazy default that required no > authentication - allowing everyone to interact with the daemon. This is > an incredibly risky proposition for memcached users from a > confidentiality perspective; and on top of that the amplification factor > is up to 15,000x. WHAT?! > > And this isn't even new information, open key/value stores have been a > security research topic for a number of years, these folks reported that > in the 2015/2016 time frame they observed more than 100,000 open > memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf > > Vendors need to ensure that a default installation of their software > does not pose an immediate liability to the user itself and those around > them. No software is deployed in a vacuum. > > A great example of how to approach things is the behavior of the > PowerDNS DNS recursor: this recursor - out of the box - binds to only > 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to > consciously perform multiple steps to make it into the danger zone. > This is how things should be. > > Kind regards, > > Job > > [1]: https://github.com/memcached/memcached/commit/ > dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 > > ps. promiscuous defaults are bad, mmkay? > Ask your BGP vendor for RFC 8212 support today! :-) > From ryan at nanog.org Thu Mar 1 20:02:53 2018 From: ryan at nanog.org (Ryan Donnelly) Date: Thu, 1 Mar 2018 15:02:53 -0500 Subject: [NANOG-announce] Program Committee appointments Message-ID: *Greetings, fellow NANOG enthusiasts,I’m pleased to announce that the board has appointed 11 individuals to the Program Committee. As always, making these appointments is an exercise in difficult choices; and these appointments were made especially challenging by this cycle’s 18 highly-qualified applicants.We are, at our core, a volunteer organization. It is through the interest and commitment of volunteers like these that we are able to deliver the exceptional program quality expected by our members, attendees and sponsors. We’d like to thank each of the 18 individuals that applied, and for those not selected, we would be delighted to entertain your candidacy during the next appointment cycle.The 11 members appointed to the Program Committee are:Vincent Celindro, Michaela Clifford, Michael Costello, Philippe Couture, Tom Kacprzynski, Ognian Mitev, Chris Pennisi, Steven Schechter, Benson Schliesser, Edward Winstead, Chris WoodfieldPlease join me in congratulating them.We’d also like to thank and recognize the contributions of Kevin Blumberg, Anna Claiborne, Allison Feese-Strickland, Steve Plote, Dani Roisman, Michael K. Smith, and Jesse Sowell for their service on the Program Committee.In the coming weeks, the new Program Committee will hold its first meeting and select a chair and a vice chair.I know I speak for the rest of the board when I say that we can’t wait to experience the output of our new PC in Denver for NANOG 73.See you in June!Best Regards,--ryan(for the NANOG Board of Directors)* -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From owen at delong.com Thu Mar 1 20:18:54 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2018 12:18:54 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> Message-ID: <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> I don’t agree that making RFC-1918 limitations a default in any daemon makes any sense whatsoever. First, there are plenty of LANs out there that don’t use RFC-1918. Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone uses ULA (the IPv6 analogue to RFC-1918). I do agree that listening on all addresses might not be the best default, but building assumptions about RFC-1918 into anything (other than the assumption that they’re generally a pretty bogus way to do IP) makes little sense to me. Owen > On Mar 1, 2018, at 10:32 AM, Eric Kuhnke wrote: > > On the other side: VM/VPS providers have a template based image that they > use for every type and subtype of operating system it's possible to > auto-provision. For example Ubuntu Server Xenial AMD64 or Debian Jessie or > Stretch AMD64. > > It's important that VM/VPS providers don't push fresh images that have > anything vulnerable, abusable or exploitable enabled by default. Not all > VM/VPS providers do this. Standard sane configuration choices apply such as > bind9 not being a recursive resolver by default. > > If individual Debian, CentOS, Ubuntu or whatever other distro packages for > memcached or any other daemon have "listen on all interfaces = yes" or > "listen on non-RFC1918 IP ranges = yes" turned on in their respective > configurations, that would be an issue to take up with the package > maintainers for the daemons. > > > > On Wed, Feb 28, 2018 at 4:31 AM, Job Snijders wrote: > >> Dear all, >> >> Before the group takes on the pitchforks and torches and travels down to >> the hosting providers' headquarters - let's take a step back and look at >> the root of this issue: the memcached software has failed both the >> Internet community and its own memcached users. >> >> It is INSANE that memcached is/was[1] shipping with default settings >> that make the daemon listen and respond on UDP on INADDR_ANY. Did nobody >> take notes during the protocol wars where we were fodder for all the >> CHARGEN & NTP ordnance? >> >> The memcached software shipped with a crazy default that required no >> authentication - allowing everyone to interact with the daemon. This is >> an incredibly risky proposition for memcached users from a >> confidentiality perspective; and on top of that the amplification factor >> is up to 15,000x. WHAT?! >> >> And this isn't even new information, open key/value stores have been a >> security research topic for a number of years, these folks reported that >> in the 2015/2016 time frame they observed more than 100,000 open >> memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf >> >> Vendors need to ensure that a default installation of their software >> does not pose an immediate liability to the user itself and those around >> them. No software is deployed in a vacuum. >> >> A great example of how to approach things is the behavior of the >> PowerDNS DNS recursor: this recursor - out of the box - binds to only >> 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to >> consciously perform multiple steps to make it into the danger zone. >> This is how things should be. >> >> Kind regards, >> >> Job >> >> [1]: https://github.com/memcached/memcached/commit/ >> dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 >> >> ps. promiscuous defaults are bad, mmkay? >> Ask your BGP vendor for RFC 8212 support today! :-) >> From morrowc.lists at gmail.com Thu Mar 1 20:24:35 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Mar 2018 15:24:35 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: On Thu, Mar 1, 2018 at 3:18 PM, Owen DeLong wrote: > I don’t agree that making RFC-1918 limitations a default in any daemon > makes any > sense whatsoever. > > First, there are plenty of LANs out there that don’t use RFC-1918. > > Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly > anyone > uses ULA (the IPv6 analogue to RFC-1918). > > I do agree that listening on all addresses might not be the best default, > but > building assumptions about RFC-1918 into anything (other than the > assumption > that they’re generally a pretty bogus way to do IP) makes little sense to > me. > > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, right? it's the only sane choice for 'fresh out of the box' network daemons: "Yes, it's running, yes I can healthcheck it locally to prove it's running" > Owen > > > On Mar 1, 2018, at 10:32 AM, Eric Kuhnke wrote: > > > > On the other side: VM/VPS providers have a template based image that they > > use for every type and subtype of operating system it's possible to > > auto-provision. For example Ubuntu Server Xenial AMD64 or Debian Jessie > or > > Stretch AMD64. > > > > It's important that VM/VPS providers don't push fresh images that have > > anything vulnerable, abusable or exploitable enabled by default. Not all > > VM/VPS providers do this. Standard sane configuration choices apply such > as > > bind9 not being a recursive resolver by default. > > > > If individual Debian, CentOS, Ubuntu or whatever other distro packages > for > > memcached or any other daemon have "listen on all interfaces = yes" or > > "listen on non-RFC1918 IP ranges = yes" turned on in their respective > > configurations, that would be an issue to take up with the package > > maintainers for the daemons. > > > > > > > > On Wed, Feb 28, 2018 at 4:31 AM, Job Snijders wrote: > > > >> Dear all, > >> > >> Before the group takes on the pitchforks and torches and travels down to > >> the hosting providers' headquarters - let's take a step back and look at > >> the root of this issue: the memcached software has failed both the > >> Internet community and its own memcached users. > >> > >> It is INSANE that memcached is/was[1] shipping with default settings > >> that make the daemon listen and respond on UDP on INADDR_ANY. Did nobody > >> take notes during the protocol wars where we were fodder for all the > >> CHARGEN & NTP ordnance? > >> > >> The memcached software shipped with a crazy default that required no > >> authentication - allowing everyone to interact with the daemon. This is > >> an incredibly risky proposition for memcached users from a > >> confidentiality perspective; and on top of that the amplification factor > >> is up to 15,000x. WHAT?! > >> > >> And this isn't even new information, open key/value stores have been a > >> security research topic for a number of years, these folks reported that > >> in the 2015/2016 time frame they observed more than 100,000 open > >> memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf > >> > >> Vendors need to ensure that a default installation of their software > >> does not pose an immediate liability to the user itself and those around > >> them. No software is deployed in a vacuum. > >> > >> A great example of how to approach things is the behavior of the > >> PowerDNS DNS recursor: this recursor - out of the box - binds to only > >> 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to > >> consciously perform multiple steps to make it into the danger zone. > >> This is how things should be. > >> > >> Kind regards, > >> > >> Job > >> > >> [1]: https://github.com/memcached/memcached/commit/ > >> dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 > >> > >> ps. promiscuous defaults are bad, mmkay? > >> Ask your BGP vendor for RFC 8212 support today! :-) > >> > > From chk at pobox.com Thu Mar 1 21:20:18 2018 From: chk at pobox.com (Harald Koch) Date: Thu, 1 Mar 2018 16:20:18 -0500 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) Message-ID: On 1 March 2018 at 15:18, Owen DeLong wrote: > Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly > anyone > uses ULA (the IPv6 analogue to RFC-1918). > Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? -- Harald From owen at delong.com Thu Mar 1 22:28:21 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2018 14:28:21 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: Message-ID: > On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: > > On 1 March 2018 at 15:18, Owen DeLong > wrote: > Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone > uses ULA (the IPv6 analogue to RFC-1918). > > Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? No particular objection, but I don’t see the point. What can you do with ULA that GUA isn’t suitable for? Owen From randy at psg.com Thu Mar 1 22:38:05 2018 From: randy at psg.com (Randy Bush) Date: Fri, 02 Mar 2018 07:38:05 +0900 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, > right? it's the only sane choice for 'fresh out of the box' network > daemons: "Yes, it's running, yes I can healthcheck it locally to prove > it's running" amidst all the hysterical pontification, i am having trouble finding any release which has, by default, a port 11211 listener on any interface. randy From morrowc.lists at gmail.com Thu Mar 1 22:50:45 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Mar 2018 17:50:45 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: pre install of memcache on a (debianXXX) Abort. morrowc at build:~$ netstat -anA inet | grep LIST tcp 0 0 192.110.255.61:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN run: apt-get install memcached now: morrowc at build:~$ netstat -anA inet | grep LIST tcp 0 0 192.110.255.61:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN fargh. On Thu, Mar 1, 2018 at 5:38 PM, Randy Bush wrote: > > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, > > right? it's the only sane choice for 'fresh out of the box' network > > daemons: "Yes, it's running, yes I can healthcheck it locally to prove > > it's running" > > amidst all the hysterical pontification, i am having trouble finding any > release which has, by default, a port 11211 listener on any interface. > > randy > From morrowc.lists at gmail.com Thu Mar 1 22:51:35 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Mar 2018 17:51:35 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: On Thu, Mar 1, 2018 at 5:50 PM, Christopher Morrow wrote: > pre install of memcache on a (debianXXX) > $ cat /etc/debian_version 9.3 (cut/paste fail before click-submit) > Abort. > morrowc at build:~$ netstat -anA inet | grep LIST > tcp 0 0 192.110.255.61:53 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:53 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:22 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:5432 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:953 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:25 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:5433 0.0.0.0:* > LISTEN > > > run: > apt-get install memcached > > now: > morrowc at build:~$ netstat -anA inet | grep LIST > tcp 0 0 192.110.255.61:53 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:53 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:22 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:5432 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:953 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:25 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:5433 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:11211 0.0.0.0:* > LISTEN > > > fargh. > > On Thu, Mar 1, 2018 at 5:38 PM, Randy Bush wrote: > >> > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, >> > right? it's the only sane choice for 'fresh out of the box' network >> > daemons: "Yes, it's running, yes I can healthcheck it locally to prove >> > it's running" >> >> amidst all the hysterical pontification, i am having trouble finding any >> release which has, by default, a port 11211 listener on any interface. >> >> randy >> > > From nanog at ics-il.net Thu Mar 1 22:52:36 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 1 Mar 2018 16:52:36 -0600 (CST) Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: <941404612.1945.1519944752029.JavaMail.mhammett@ThunderFuck> The defaults for Zimbra seem to be to listen everywhere all the time. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Randy Bush" To: "Christopher Morrow" Cc: "North American Network Operators' Group" Sent: Thursday, March 1, 2018 4:38:05 PM Subject: Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, > right? it's the only sane choice for 'fresh out of the box' network > daemons: "Yes, it's running, yes I can healthcheck it locally to prove > it's running" amidst all the hysterical pontification, i am having trouble finding any release which has, by default, a port 11211 listener on any interface. randy From royce at techsolvency.com Thu Mar 1 22:55:16 2018 From: royce at techsolvency.com (Royce Williams) Date: Thu, 1 Mar 2018 13:55:16 -0900 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: On Thu, Mar 1, 2018 at 1:38 PM, Randy Bush wrote: > > > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, > > right? it's the only sane choice for 'fresh out of the box' network > > daemons: "Yes, it's running, yes I can healthcheck it locally to prove > > it's running" > > amidst all the hysterical pontification, i am having trouble finding any > release which has, by default, a port 11211 listener on any interface. ... for people using the OS package, and not compiling from source. Upstream, until two days ago, the default was to listen on all interfaces. https://github.com/memcached/memcached/wiki/ReleaseNotes156 The package maintainers were (thankfully) injecting additional sanity. Royce From marka at isc.org Thu Mar 1 23:48:26 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 2 Mar 2018 10:48:26 +1100 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: Message-ID: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> > On 2 Mar 2018, at 9:28 am, Owen DeLong wrote: > > >> On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: >> >> On 1 March 2018 at 15:18, Owen DeLong > wrote: >> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone >> uses ULA (the IPv6 analogue to RFC-1918). >> >> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? > > No particular objection, but I don’t see the point. > > What can you do with ULA that GUA isn’t suitable for? > > Owen ULA provide stable internal addresses which survive changing ISP for the average home user. Now, I know you can do the same thing by going to a RIR and getting a prefix but the RIR’s aren’t setup to supply prefixes like that to 10 billion of us. They are also in a specific range which makes setting filtering rules easier for everyone else. Now I would love it if we could support 100 billion routes in the DFZ but we aren’t anywhere near being able to do that which would be a requirement for abandoning ULA. Until them they have there place. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Thu Mar 1 23:51:41 2018 From: randy at psg.com (Randy Bush) Date: Fri, 02 Mar 2018 08:51:41 +0900 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <941404612.1945.1519944752029.JavaMail.mhammett@ThunderFuck> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <941404612.1945.1519944752029.JavaMail.mhammett@ThunderFuck> Message-ID: > The defaults for Zimbra seem to be to listen everywhere all the time. > amidst all the hysterical pontification, i am having trouble finding any > release which has, by default, a port 11211 listener on any interface. sorry, i should have said "any operating system release" yes, you can install memcached yes, you can install some j random container which has memcached yes, you can shoot yourself in the foot; welcome to the internet my point was merely that the hysteria and grandstanding can cost a lot of ops a bunch of time. and folk should be aware that normal, simple, vanilla environments will not be a source of reflection. of course, they might be a target :) randy From randy at psg.com Thu Mar 1 23:55:59 2018 From: randy at psg.com (Randy Bush) Date: Fri, 02 Mar 2018 08:55:59 +0900 Subject: dnswl.org contact Message-ID: anyone have contact with the dnswl.org folk? my calendar says that it is the time of year i owe them some money, and i can not seem to pay them. randy From cheetahmorph at gmail.com Fri Mar 2 00:43:26 2018 From: cheetahmorph at gmail.com (Jippen) Date: Thu, 1 Mar 2018 16:43:26 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <941404612.1945.1519944752029.JavaMail.mhammett@ThunderFuck> Message-ID: The problem here is that you're not being shot in the foot, you're moving a semi full of ammo and parking it in front of my building. Collateral damage from other people being lazy with their servers is a pain. Oh, and this was used to set a new high water mark for 'Biggest DDoS' against github. 1.5 Tbps. So, its a pretty big deal. And that ignoring the additional vulnurability from just getting everything useful out of the memcached server, or continuously clearing the server to damage performance of the app relying on it. If your gun's default aiming position is at your foot, then there's a good argument to change the default. It doesn't solve the problem, but it helps. On Thu, Mar 1, 2018 at 3:51 PM, Randy Bush wrote: > > The defaults for Zimbra seem to be to listen everywhere all the time. > > amidst all the hysterical pontification, i am having trouble finding any > > release which has, by default, a port 11211 listener on any interface. > > sorry, i should have said "any operating system release" > > yes, you can install memcached > > yes, you can install some j random container which has memcached > > yes, you can shoot yourself in the foot; welcome to the internet > > my point was merely that the hysteria and grandstanding can cost a lot > of ops a bunch of time. and folk should be aware that normal, simple, > vanilla environments will not be a source of reflection. > > of course, they might be a target :) > > randy > From randy at psg.com Fri Mar 2 00:49:08 2018 From: randy at psg.com (Randy Bush) Date: Fri, 02 Mar 2018 09:49:08 +0900 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <941404612.1945.1519944752029.JavaMail.mhammett@ThunderFuck> Message-ID: <6128FED6-C9A0-4181-8797-7685514E585F@psg.com> hyperbole. sad and embarrassing to say, but it’s just another damned day of the internet security rolling disaster. there will be more. there will be worse. and screaming wolf will only make folk inured (excuse the american idiom). randy From marka at isc.org Fri Mar 2 01:30:03 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 2 Mar 2018 12:30:03 +1100 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: <499A7795-C87A-4426-9370-247924B812FA@isc.org> > On 2 Mar 2018, at 11:48 am, Matt Erculiani wrote: > > Not sure if this is the common thought, but if anyone has a network > which requires static IP assignments, they can probably justify a > request for a /48 from an RIR. After all, ARIN's requirement for an > end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from > an ISP or other LIR are unsuitable". I would think that ISP > portability would satisfy this requirement, but If I'm wrong, I'm > absolutely open to being corrected on this. But most home users have > no need for static IPs, so the dynamic ISP assignment is perfectly > fine. ISP assigned addresses are perfectly fine for TALKING TO THE REST OF THE WORLD. ISP assigned addresses are not perfectly fine for internal communication. With IPv6 you use ULA along side ISP assigned addresses. With IPv4 RFC 1918 address + NAT the home user has STATIC local addresses for devices that need them. Go look at your home router’s web pages. You will be able to assign static addresses to your internal machines via DHCP. Are YOU going to tell everyone that sets values there that they no longer can do the same thing for IPv6. That they need to fully renumber all their devices just because the ISP gave them a different prefix this morning? > I think the tech will advance fast enough that keeping up with an IPv6 > route table will be a non-issue. IPv6 adoption is, unfortunately, slow > enough that there will be no issues keeping up, even assuming a "slow" > hardware refresh cycle. > > -M > > On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews wrote: >> >>> On 2 Mar 2018, at 9:28 am, Owen DeLong wrote: >>> >>> >>>> On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: >>>> >>>> On 1 March 2018 at 15:18, Owen DeLong > wrote: >>>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone >>>> uses ULA (the IPv6 analogue to RFC-1918). >>>> >>>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? >>> >>> No particular objection, but I don’t see the point. >>> >>> What can you do with ULA that GUA isn’t suitable for? >>> >>> Owen >> >> ULA provide stable internal addresses which survive changing ISP >> for the average home user. Now, I know you can do the same thing >> by going to a RIR and getting a prefix but the RIR’s aren’t setup >> to supply prefixes like that to 10 billion of us. >> >> They are also in a specific range which makes setting filtering >> rules easier for everyone else. >> >> Now I would love it if we could support 100 billion routes in the >> DFZ but we aren’t anywhere near being able to do that which would >> be a requirement for abandoning ULA. Until them they have there >> place. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chk at pobox.com Fri Mar 2 02:30:32 2018 From: chk at pobox.com (Harald Koch) Date: Thu, 1 Mar 2018 21:30:32 -0500 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: On 1 March 2018 at 18:48, Mark Andrews wrote: > ULA provide stable internal addresses which survive changing ISP > for the average home user. Yeah this is pretty much what I'm doing. ULA for stable, internal addresses that I can put into the (internal) DNS: ISP prefixes for global routing. Renumbering is hard. All of the objections I've seen to ULA are actually objections to (IPv6) NAT, which is why I was confused. (As it turns out my ISP prefix has been static for years, but I'm too lazy to undo all of the work...) -- Harald From erey at ernw.de Fri Mar 2 09:39:12 2018 From: erey at ernw.de (Enno Rey) Date: Fri, 2 Mar 2018 10:39:12 +0100 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: <20180302093912.GA63756@ernw.de> Hi, On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote: > On 1 March 2018 at 18:48, Mark Andrews wrote: > > > ULA provide stable internal addresses which survive changing ISP > > for the average home user. > > > Yeah this is pretty much what I'm doing. ULA for stable, internal addresses > that I can put into the (internal) DNS: ISP prefixes for global routing. > Renumbering is hard. as is proper (source|destination) address selection in a sufficiently complex environment. for interest: for a system which must be both globally and internally reachable, which address do you put into which DNS? > > All of the objections I've seen to ULA are actually objections to (IPv6) > NAT, which is why I was confused. the main objection against ULAs is avoidance of complexity in environments where at least some systems need global reach(ability), which applies to pretty much all environments nowadays. best Enno > > (As it turns out my ISP prefix has been static for years, but I'm too lazy > to undo all of the work...) > > -- > Harald -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From saku at ytti.fi Fri Mar 2 09:50:13 2018 From: saku at ytti.fi (Saku Ytti) Date: Fri, 2 Mar 2018 11:50:13 +0200 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <20180302093912.GA63756@ernw.de> References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> <20180302093912.GA63756@ernw.de> Message-ID: Enno et al ULA fans I could not agree more. Either you provide your enterprise customers transportable address or ULA. If you assign and promote them to use your 'PA' address, they will take your PA address with them when they change operator 10 years from now, and if you reuse it, these two customers cannot reach each other. Why? Because anyone who has worked at non-trivial size enterprise knows that even just finding out what needs to be done, to renumber internal networks is massively long, expensive and error prone proposal, there will be tons of documents and scripts in non-standard locations containing IP addresses punched in. No matter how well you do your job, you cannot impact how others do, and you must expect them to continue working as they have in the past, and you must realise when that poses risk to yourself and protect yourself from that. ULA at inside and 1:1 to operator address in the edge is what I've been recommending to my enterprise customers since we started to offer IPv6 commercially. Fits their existing processes and protects me from creating tainted unusable addresses. On 2 March 2018 at 11:39, Enno Rey wrote: > Hi, > > On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote: >> On 1 March 2018 at 18:48, Mark Andrews wrote: >> >> > ULA provide stable internal addresses which survive changing ISP >> > for the average home user. >> >> >> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses >> that I can put into the (internal) DNS: ISP prefixes for global routing. >> Renumbering is hard. > > as is proper (source|destination) address selection in a sufficiently complex environment. > for interest: for a system which must be both globally and internally reachable, which address do you put into which DNS? > > >> >> All of the objections I've seen to ULA are actually objections to (IPv6) >> NAT, which is why I was confused. > > the main objection against ULAs is avoidance of complexity in environments where at least some systems need global reach(ability), which applies to pretty much all environments nowadays. > > best > > Enno > > > > > > >> >> (As it turns out my ISP prefix has been static for years, but I'm too lazy >> to undo all of the work...) >> >> -- >> Harald > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Matthias Luft, Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= -- ++ytti From bjorn at mork.no Fri Mar 2 11:17:04 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 02 Mar 2018 12:17:04 +0100 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: (Owen DeLong's message of "Thu, 1 Mar 2018 14:28:21 -0800") References: Message-ID: <87inae4thr.fsf@miraculix.mork.no> Owen DeLong writes: > What can you do with ULA that GUA isn’t suitable for? 1) get 2) keep 3) move Granted, many of us can do that with GUAs too. But with ULA those features are avaible to everyone everywhere. Which is useful for a number of applications where you care mostly about the local environment and not so much about global connectivity. Bjørn From owen at delong.com Fri Mar 2 11:34:05 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 03:34:05 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> <20180302093912.GA63756@ernw.de> Message-ID: <21DCA08B-FD06-4552-ABEC-C9E4309196DD@delong.com> > On Mar 2, 2018, at 1:50 AM, Saku Ytti wrote: > > Enno et al ULA fans > > I could not agree more. > > Either you provide your enterprise customers transportable address or > ULA. If you assign and promote them to use your 'PA' address, they > will take your PA address with them when they change operator 10 years > from now, and if you reuse it, these two customers cannot reach each > other. Why? Because anyone who has worked at non-trivial size > enterprise knows that even just finding out what needs to be done, to > renumber internal networks is massively long, expensive and error > prone proposal, there will be tons of documents and scripts in > non-standard locations containing IP addresses punched in. This, right here, is inherently the a very good reason NOT to use ULA IMHO. See, no matter how widely you deploy ULA, those same scripts are still going to use the provider assigned public addresses that work for all the things they care about and not just local connectivity. Instead, you adopted a false sense of security and made it more confusing when things do get renumbered. I completely agree that PI is the way to go and that PA was a silly idea whose time is long past. For home users, perhaps PA is OK for a little while longer (wouldn’t make me happy in my home, but I’ve got PI, so whatever other folks want to do isn’t my problem here). > No matter how well you do your job, you cannot impact how others do, > and you must expect them to continue working as they have in the past, > and you must realise when that poses risk to yourself and protect > yourself from that. Which won’t happen with ULA. > ULA at inside and 1:1 to operator address in the edge is what I've > been recommending to my enterprise customers since we started to offer > IPv6 commercially. Fits their existing processes and protects me from > creating tainted unusable addresses. Oh, please. NAT all over again? That’s another inherently very good reason NOT to use ULA. Owen > > > On 2 March 2018 at 11:39, Enno Rey wrote: >> Hi, >> >> On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote: >>> On 1 March 2018 at 18:48, Mark Andrews wrote: >>> >>>> ULA provide stable internal addresses which survive changing ISP >>>> for the average home user. >>> >>> >>> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses >>> that I can put into the (internal) DNS: ISP prefixes for global routing. >>> Renumbering is hard. >> >> as is proper (source|destination) address selection in a sufficiently complex environment. >> for interest: for a system which must be both globally and internally reachable, which address do you put into which DNS? >> >> >>> >>> All of the objections I've seen to ULA are actually objections to (IPv6) >>> NAT, which is why I was confused. >> >> the main objection against ULAs is avoidance of complexity in environments where at least some systems need global reach(ability), which applies to pretty much all environments nowadays. >> >> best >> >> Enno >> >> >> >> >> >> >>> >>> (As it turns out my ISP prefix has been static for years, but I'm too lazy >>> to undo all of the work...) >>> >>> -- >>> Harald >> >> -- >> Enno Rey >> >> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 >> >> Handelsregister Mannheim: HRB 337135 >> Geschaeftsfuehrer: Matthias Luft, Enno Rey >> >> ======================================================= >> Blog: www.insinuator.net || Conference: www.troopers.de >> Twitter: @Enno_Insinuator >> ======================================================= > > > > -- > ++ytti From bjorn at mork.no Fri Mar 2 11:49:13 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 02 Mar 2018 12:49:13 +0100 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> (Owen DeLong's message of "Thu, 1 Mar 2018 12:18:54 -0800") References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: <87efl24s06.fsf@miraculix.mork.no> Owen DeLong writes: > I don’t agree that making RFC-1918 limitations a default in any daemon makes any > sense whatsoever. +1 One of the more annoying anti-features I know of in this regard is the dnsmasq rebind "protection". It claims to protect web browsers on the LAN against DNS rebind attacks. But the implementation does not consider which adresses are used on the LAN at all. It simply blocks any A record pointing to an RFC1918 address, making a few bogus assumptions: - IPv4 LAN addresses are selected from RFC1918 - RFC1918 addresses are never used on the WAN side of a CPE - Noone use IPv6 on their LAN It's hard to know how many users have been bitten by the first one. You'd have to depend on this rebind "protection" in the first place, and that would be.... stupid. But the second assumption regularily bites end users when their ISP provides some ISP internal service using RFC1918 addresses. Which of course is fine. The anti-feature has been enabled by default in OpenWrt for a long time, ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that there is a large user base having this enabled without knowing. > First, there are plenty of LANs out there that don’t use RFC-1918. > > Second, RFC-1918 doesn’t apply to IPv6 at all, Could you try to explain that to the OpenWrt guys? Thanks Bjørn From sthaug at nethelp.no Fri Mar 2 11:50:00 2018 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 02 Mar 2018 12:50:00 +0100 (CET) Subject: IPv6 Unique Local Addresses In-Reply-To: <21DCA08B-FD06-4552-ABEC-C9E4309196DD@delong.com> References: <20180302093912.GA63756@ernw.de> <21DCA08B-FD06-4552-ABEC-C9E4309196DD@delong.com> Message-ID: <20180302.125000.74730824.sthaug@nethelp.no> > > ULA at inside and 1:1 to operator address in the edge is what I've > > been recommending to my enterprise customers since we started to offer > > IPv6 commercially. Fits their existing processes and protects me from > > creating tainted unusable addresses. > > Oh, please. NAT all over again? That's another inherently very good reason > NOT to use ULA. You don't have to like it, but IPv6 NAT is already happening. Wishing it would go away won't make it happen... We're using ULA for our lab here, with the very explicit goal that the boxes in question should *not* connect to the Internet. We're not using IPv6 NAT, but I can certainly see the point of what Saku Ytti suggested. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From owen at delong.com Fri Mar 2 11:53:45 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 03:53:45 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: > On Mar 1, 2018, at 6:30 PM, Harald Koch wrote: > > On 1 March 2018 at 18:48, Mark Andrews wrote: > >> ULA provide stable internal addresses which survive changing ISP >> for the average home user. > > > Yeah this is pretty much what I'm doing. ULA for stable, internal addresses > that I can put into the (internal) DNS: ISP prefixes for global routing. > Renumbering is hard. > > All of the objections I've seen to ULA are actually objections to (IPv6) > NAT, which is why I was confused. I object to NAT more strongly than ULA, but IMHO, even if you aren’t going to route it, a block of GUA PI makes more sense than ULA for virtually any installation I can imagine. Owen From owen at delong.com Fri Mar 2 11:59:57 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 03:59:57 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <499A7795-C87A-4426-9370-247924B812FA@isc.org> References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> <499A7795-C87A-4426-9370-247924B812FA@isc.org> Message-ID: <5A957E3B-2911-4072-BCD3-F3210B20CEE2@delong.com> > On Mar 1, 2018, at 5:30 PM, Mark Andrews wrote: > > >> On 2 Mar 2018, at 11:48 am, Matt Erculiani wrote: >> >> Not sure if this is the common thought, but if anyone has a network >> which requires static IP assignments, they can probably justify a >> request for a /48 from an RIR. After all, ARIN's requirement for an >> end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from >> an ISP or other LIR are unsuitable". I would think that ISP >> portability would satisfy this requirement, but If I'm wrong, I'm >> absolutely open to being corrected on this. But most home users have >> no need for static IPs, so the dynamic ISP assignment is perfectly >> fine. > > ISP assigned addresses are perfectly fine for TALKING TO THE REST OF THE WORLD. > ISP assigned addresses are not perfectly fine for internal communication. Meh. ISP assigned addresses _CAN_ be used to talk to the rest of the world. PI addresses are also perfectly fine for this where supported. > With IPv6 you use ULA along side ISP assigned addresses. With IPv6 you _CAN_ use ULA along PA. or you can use PI. or you can use PI along side PA. IMHO, either of the latter two are better than the former. > With IPv4 RFC 1918 address + NAT the home user has STATIC local addresses > for devices that need them. Go look at your home router’s web pages. You > will be able to assign static addresses to your internal machines via DHCP. My home router doesn’t have web pages since I turned off J-web. It also doesn’t run DHCP as a server. (It does run a DHCP client to talk to Comcast). I do, however, have some static DHCP entries in my dhcpd.conf file on my dhcp server. > Are YOU going to tell everyone that sets values there that they no longer > can do the same thing for IPv6. That they need to fully renumber all their > devices just because the ISP gave them a different prefix this morning? Nope… But there’s _NO_ reason that can’t do that equally well with a PI block (or a free /48 from HE that they just don’t bother to really connect to a tunnel) instead of ULA. So… I stand by my point… ULA offers no… ZERO advantages over GUA. All the defense of ULA makes strange assumptions about the nature of GUA. I did not. Any form of GUA that suits the purpose is fine with me. If you’re comfortable with PA, great. If you prefer PI, great. If you need something free, get a /48 from HE, they hand them out on a simple web form. If you’re using it locally, nothing says you _HAVE_ to actually turn on the tunnel. OTOH, if you want, you’re certainly free to do so and it will solve certain address selection oddities that happen with some systems when ULA is used and greatly simplify your DNS life. Owen >> I think the tech will advance fast enough that keeping up with an IPv6 >> route table will be a non-issue. IPv6 adoption is, unfortunately, slow >> enough that there will be no issues keeping up, even assuming a "slow" >> hardware refresh cycle. >> >> -M >> >> On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews wrote: >>> >>>> On 2 Mar 2018, at 9:28 am, Owen DeLong wrote: >>>> >>>> >>>>> On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: >>>>> >>>>> On 1 March 2018 at 15:18, Owen DeLong > wrote: >>>>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone >>>>> uses ULA (the IPv6 analogue to RFC-1918). >>>>> >>>>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? >>>> >>>> No particular objection, but I don’t see the point. >>>> >>>> What can you do with ULA that GUA isn’t suitable for? >>>> >>>> Owen >>> >>> ULA provide stable internal addresses which survive changing ISP >>> for the average home user. Now, I know you can do the same thing >>> by going to a RIR and getting a prefix but the RIR’s aren’t setup >>> to supply prefixes like that to 10 billion of us. >>> >>> They are also in a specific range which makes setting filtering >>> rules easier for everyone else. >>> >>> Now I would love it if we could support 100 billion routes in the >>> DFZ but we aren’t anywhere near being able to do that which would >>> be a requirement for abandoning ULA. Until them they have there >>> place. >>> >>> Mark >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From owen at delong.com Fri Mar 2 12:01:30 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 04:01:30 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: <8D4B9F5A-D913-4498-B989-CEBCDE85E968@delong.com> For that matter, if we can kill IPv4, we have plenty of headroom for a LOT of IPv6 PI space. Owen > On Mar 1, 2018, at 4:48 PM, Matt Erculiani wrote: > > Not sure if this is the common thought, but if anyone has a network > which requires static IP assignments, they can probably justify a > request for a /48 from an RIR. After all, ARIN's requirement for an > end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from > an ISP or other LIR are unsuitable". I would think that ISP > portability would satisfy this requirement, but If I'm wrong, I'm > absolutely open to being corrected on this. But most home users have > no need for static IPs, so the dynamic ISP assignment is perfectly > fine. > > I think the tech will advance fast enough that keeping up with an IPv6 > route table will be a non-issue. IPv6 adoption is, unfortunately, slow > enough that there will be no issues keeping up, even assuming a "slow" > hardware refresh cycle. > > -M > > On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews wrote: >> >>> On 2 Mar 2018, at 9:28 am, Owen DeLong wrote: >>> >>> >>>> On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: >>>> >>>> On 1 March 2018 at 15:18, Owen DeLong > wrote: >>>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone >>>> uses ULA (the IPv6 analogue to RFC-1918). >>>> >>>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? >>> >>> No particular objection, but I don’t see the point. >>> >>> What can you do with ULA that GUA isn’t suitable for? >>> >>> Owen >> >> ULA provide stable internal addresses which survive changing ISP >> for the average home user. Now, I know you can do the same thing >> by going to a RIR and getting a prefix but the RIR’s aren’t setup >> to supply prefixes like that to 10 billion of us. >> >> They are also in a specific range which makes setting filtering >> rules easier for everyone else. >> >> Now I would love it if we could support 100 billion routes in the >> DFZ but we aren’t anywhere near being able to do that which would >> be a requirement for abandoning ULA. Until them they have there >> place. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> From owen at delong.com Fri Mar 2 12:09:33 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 04:09:33 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: <20180302.125000.74730824.sthaug@nethelp.no> References: <20180302093912.GA63756@ernw.de> <21DCA08B-FD06-4552-ABEC-C9E4309196DD@delong.com> <20180302.125000.74730824.sthaug@nethelp.no> Message-ID: > On Mar 2, 2018, at 3:50 AM, sthaug at nethelp.no wrote: > >>> ULA at inside and 1:1 to operator address in the edge is what I've >>> been recommending to my enterprise customers since we started to offer >>> IPv6 commercially. Fits their existing processes and protects me from >>> creating tainted unusable addresses. >> >> Oh, please. NAT all over again? That's another inherently very good reason >> NOT to use ULA. > > You don't have to like it, but IPv6 NAT is already happening. Wishing > it would go away won't make it happen… Truth. Just like I can’t cure AIDS just by wishing, but I’m pretty sure that without people talking about it, it wouldn’t go away either. > We're using ULA for our lab here, with the very explicit goal that the > boxes in question should *not* connect to the Internet. We're not using > IPv6 NAT, but I can certainly see the point of what Saku Ytti suggested. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no We can agree to disagree. It’s not even unusual at this point. Owen From owen at delong.com Fri Mar 2 12:12:15 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 04:12:15 -0800 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <87inae4thr.fsf@miraculix.mork.no> References: <87inae4thr.fsf@miraculix.mork.no> Message-ID: <34C1D995-133F-4C70-AA3C-4E133D72B747@delong.com> > On Mar 2, 2018, at 3:17 AM, Bjørn Mork wrote: > > Owen DeLong writes: > >> What can you do with ULA that GUA isn’t suitable for? > > 1) get > 2) keep > 3) move Wrong. 1) get Easy as going to http://tunnelbroker.net and filling out a form. Remember to check the box for your /48. 2) keep Admittedly, you might have to connect to your tunnel every once in a while to keep it alive, but that’s hardly a high bar. 3) move If you’re not talking to the internet with it (which you can’t with ULA, theoretically), you can move that same HE /48 anywhere you want, with the additional advantage that you can, if you need to, connect your tunnel and actually make it work on the internet too. > Granted, many of us can do that with GUAs too. But with ULA those > features are avaible to everyone everywhere. Which is useful for a You really think that doing ULA according to the RFCs (collision avoidance algorithm and all) is easier than filling out a form at HE? REALLY? > number of applications where you care mostly about the local environment > and not so much about global connectivity. I hear you, but I’m not convinced about the ease. Owen From bjorn at mork.no Fri Mar 2 13:40:37 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 02 Mar 2018 14:40:37 +0100 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <34C1D995-133F-4C70-AA3C-4E133D72B747@delong.com> (Owen DeLong's message of "Fri, 2 Mar 2018 04:12:15 -0800") References: <87inae4thr.fsf@miraculix.mork.no> <34C1D995-133F-4C70-AA3C-4E133D72B747@delong.com> Message-ID: <87a7vq4mui.fsf@miraculix.mork.no> Owen DeLong writes: >> On Mar 2, 2018, at 3:17 AM, Bjørn Mork wrote: >> >> Owen DeLong writes: >> >>> What can you do with ULA that GUA isn’t suitable for? >> >> 1) get >> 2) keep >> 3) move > > Wrong. > > 1) get > Easy as going to http://tunnelbroker.net and filling out a form. Remember to check the box for your /48. Provided you have IPv4 connectivity and an email address you can and will associate with the tunnel/prefix. You are limiting the scope here. > 2) keep > Admittedly, you might have to connect to your tunnel every once in a while to keep it alive, but that’s > hardly a high bar. Depends. How about preconfigured devices in storage? There are a number of use cases where outside connectivity does not matter, and where depending on regular connections will complicate stuff. > 3) move > If you’re not talking to the internet with it (which you can’t with ULA, theoretically), you can move that same > HE /48 anywhere you want, with the additional advantage that you can, if you need to, connect your tunnel > and actually make it work on the internet too. Sure. There is also a long tradition in IPv4 for "borrowing" someone elses addresses. It is never a good idea. You or anyone else cannot make any guarantee about HE address availability at any point in time or space. You may also want to consider https://www.tunnelbroker.net/tos.php >> Granted, many of us can do that with GUAs too. But with ULA those >> features are avaible to everyone everywhere. Which is useful for a > > You really think that doing ULA according to the RFCs (collision > avoidance algorithm and all) is easier than filling out a form at HE? > REALLY? Yes. You are comparing apples and orange seeds. If you don't want to construct your tunnel from the RFCs, then you cannot require ULA users to start there either, The ULA equivalent of the HE tunnel form is an ULA calculator. E.g http://www.kame.net/~suz/gen-ula.html Which is much simpler. At least it looks simpler to me. But it doesn't really matter. The main point is that ULAs are usable in many cases where HE (or other ISP allocated) GUAs are not. If you don't care about Internet connectivity, then ULAs are as good as PI GUA space. Believe it or not, but there are still devices and networks where Internet connectivity is either optional or even unwanted. These devices and networks still need addresses for their internal communcation. >> number of applications where you care mostly about the local environment >> and not so much about global connectivity. > > I hear you, but I’m not convinced about the ease. When was the last time you saw a non RFC1918 address in a consumer equipment setup guide? If we consider the distant future where IPv4 is long dead and buried, what is default configuration URL is going to replace http://192.168.1.1/ and similar? IoT might be a thing for a while until people start worrying about where they store their data. I'm sure local sensor networks will become popular again once the hype is over. Many ISPs make more money on providing network accesses which are isolated from the Internet than actually providing Internet access More and more systems are made up of networked subsystems. Take a look at your average core router for example. These susbsystems need addresses. But you rarely want them to connect to the Internet. One can easily imagine future PC or handheld systems where internal buses like I2C and USB (when used to connect *internal* lowspeed components like fingerprint readers etc) have been replaced by IP over ethernet. Just to name a few applications I can think of here and now. There are many many more. I'm not claiming that ULAs are the answers to all these. There are certainly reasons why you might want GUAs instead. But these are cases where the main disadvantage of the ULAs - The lack of Internet connectivity - does not matter, or is even turned into an advantage. Bjørn From owen at delong.com Fri Mar 2 14:55:26 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 17:55:26 +0300 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <87a7vq4mui.fsf@miraculix.mork.no> References: <87inae4thr.fsf@miraculix.mork.no> <34C1D995-133F-4C70-AA3C-4E133D72B747@delong.com> <87a7vq4mui.fsf@miraculix.mork.no> Message-ID: <42FCF2B9-0F5C-415C-BA39-D631FA063841@delong.com> > On Mar 2, 2018, at 19:25, Bjørn Mork wrote: > > Owen DeLong writes: > >>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork wrote: >>> >>> Owen DeLong writes: >>> >>>> What can you do with ULA that GUA isn’t suitable for? >>> >>> 1) get >>> 2) keep >>> 3) move >> >> Wrong. >> >> 1) get >> Easy as going to http://tunnelbroker.net and filling out a form. Remember to check the box for your /48. > > Provided you have IPv4 connectivity and an email address you can and > will associate with the tunnel/prefix. You are limiting the scope here. > Having an email address is a pretty low bar. You don’t need to actually set up the tunnel, so all you need is an ipv4 address that answers Icmp echo. Also not hard to come by. >> 2) keep >> Admittedly, you might have to connect to your tunnel every once in a while to keep it alive, but that’s >> hardly a high bar. > > Depends. How about preconfigured devices in storage? There are a > number of use cases where outside connectivity does not matter, and > where depending on regular connections will complicate stuff. You don’t have to connect from the devices using the addresses, you just need to connect. A simple laptop will do. > >> 3) move >> If you’re not talking to the internet with it (which you can’t with ULA, theoretically), you can move that same >> HE /48 anywhere you want, with the additional advantage that you can, if you need to, connect your tunnel >> and actually make it work on the internet too. > > Sure. There is also a long tradition in IPv4 for "borrowing" someone > elses addresses. It is never a good idea. You or anyone else cannot > make any guarantee about HE address availability at any point in time or > space. Meh... if you’re concerned about that, get the addresses from an RIR. Some people think $100/year is a barrier, so I proposed a free alternative. > > You may also want to consider https://www.tunnelbroker.net/tos.php Last time I read it, it didn’t preclude what I’m suggesting. It may have been updated, but if it was, I bet there are still workarounds within the TOS. > > >>> Granted, many of us can do that with GUAs too. But with ULA those >>> features are avaible to everyone everywhere. Which is useful for a >> >> You really think that doing ULA according to the RFCs (collision >> avoidance algorithm and all) is easier than filling out a form at HE? >> REALLY? > > Yes. > > You are comparing apples and orange seeds. If you don't want to > construct your tunnel from the RFCs, then you cannot require ULA users > to start there either, I wasn’t proposing actually constructing a tunnel at all. Merely using the tunnel as a way to get a /48 for free. I wasn’t requiring the Ilan user to start from the RFCs, but specifying that the had to comply with them. The calculator is a slightly shorter form, I’ll grant you, but it doesn’t strike me as substantially easier. > > The ULA equivalent of the HE tunnel form is an ULA calculator. E.g > http://www.kame.net/~suz/gen-ula.html > > Which is much simpler. At least it looks simpler to me. > > But it doesn't really matter. The main point is that ULAs are usable in > many cases where HE (or other ISP allocated) GUAs are not. If you don't > care about Internet connectivity, then ULAs are as good as PI GUA space. My point is that in that case GUA is as good as ULA too. ULA offers no advantage. It’s just a waste of a /7. > > Believe it or not, but there are still devices and networks where > Internet connectivity is either optional or even unwanted. These > devices and networks still need addresses for their internal > communcation. Never denied that. I have some at home. They have /64s carved out of my /48 and work just fine. > >>> number of applications where you care mostly about the local environment >>> and not so much about global connectivity. >> >> I hear you, but I’m not convinced about the ease. > > When was the last time you saw a non RFC1918 address in a consumer > equipment setup guide? If we consider the distant future where IPv4 is > long dead and buried, what is default configuration URL is going to > replace http://192.168.1.1/ and similar? One would home something less brain-dead like http://config.local If your asking about what prefix should be used in examples, well, that’s what we have 2001:db8::/32 for. > > IoT might be a thing for a while until people start worrying about where > they store their data. I'm sure local sensor networks will become > popular again once the hype is over. > > Many ISPs make more money on providing network accesses which are > isolated from the Internet than actually providing Internet access > > More and more systems are made up of networked subsystems. Take a look > at your average core router for example. These susbsystems need > addresses. But you rarely want them to connect to the Internet. > > One can easily imagine future PC or handheld systems where internal > buses like I2C and USB (when used to connect *internal* lowspeed > components like fingerprint readers etc) have been replaced by IP over > ethernet. > > Just to name a few applications I can think of here and now. There are > many many more. Sure, and there’s no disadvantage whatsoever from using GUA to address these. > > I'm not claiming that ULAs are the answers to all these. There are > certainly reasons why you might want GUAs instead. But these are cases > where the main disadvantage of the ULAs - The lack of Internet > connectivity - does not matter, or is even turned into an advantage. I don’t see it ever being an advantage, but I agree there are situations where that particular property isn’t a disadvantage. I never denied that. Still there’s no actual advantage to ULA... it’s just a convenient way to completely waste a /8 and mostly waste another /8. Owen > > > > > Bjørn From rwebb at ropeguru.com Fri Mar 2 15:52:43 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 2 Mar 2018 15:52:43 +0000 Subject: Comcast NOC Contact Message-ID: I know Virginia is having wind issues today. But can anyone from Comcast comment on intermittent routing issues between Charlottesville, VA and Ashburn, VA on their backbone? Issue appears to be between 69.139.206.9 ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 be-21508-cr02.ashburn.va.ibone.comcast.net Off list is fine. From nwarren at barryelectric.com Fri Mar 2 15:55:54 2018 From: nwarren at barryelectric.com (Nicholas Warren) Date: Fri, 2 Mar 2018 15:55:54 +0000 Subject: IPv6 Unique Local Addresses Message-ID: Please don't take away ULA. >> You really think that doing ULA according to the RFCs (collision >> avoidance algorithm and all) is easier than filling out a form at HE? >> REALLY? > > Yes. It's hard enough to sell ipv6 for LAN without adding having to get a tunnel, register with a RIR, whatever else. ULA gives us the option to spin up ipv6 networks without anyone else being involved. We have to be able to make private networks without contacting anyone, and we will go back to ipv4 if that's our only option. From list at satchell.net Fri Mar 2 16:01:29 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 2 Mar 2018 08:01:29 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks Message-ID: <3d88af81-657b-16cf-f339-cc7624020f7d@satchell.net> Testing on a recently-load VM of CentOS 7.3: [root at localhost odd]# netstat -tan | grep 11211 [root at localhost odd]# netstat -uan | grep 11211 [root at localhost odd]# yum install memcached [root at localhost odd]# systemctl start memcached.service [root at localhost odd]# netstat -tan | grep 11211 tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN tcp6 0 0 :::11211 :::* LISTEN [root at localhost odd]# netstat -uan | grep 11211 udp 0 0 0.0.0.0:11211 0.0.0.0:* udp6 0 0 :::11211 :::* Since CentOS is supposed to be a near bit-by-bit copy of Red Hat Enterprise, this shows that when one loads memcached without modifying the configuration, plus expose 11211/udp to the world, one is now part of the problem. It also suggests that other near-clones of RHEL may also exhibit the problem. So I pulled the memcached repository from GitHub, and looked through the commits. NOTHING about updates to prevent DDoS. So I started looking around for the config file in the maintainer GIT project. Here is what I found: > # These defaults will be used by every memcached instance, unless overridden > # by values in /etc/sysconfig/memcached. > USER="nobody" > MAXCONN="1024" > CACHESIZE="64" > OPTIONS="" > > # The PORT variable will only be used by memcached.service, not by > # memcached at xxxxx services, which will use the xxxxx > PORT="11211" Here is what CentOS has: > PORT="11211" > USER="memcached" > MAXCONN="1024" > CACHESIZE="64" > OPTIONS="" What's missing from both of these system configuration files? OPTIONS="-U 0" From the memcached man page: > -U > Listen on UDP port , the default is port 11211, 0 is off. So this answers the question about how anyone loading memcached fresh from a distribution can be a major player in the DDoS game. Now, in a lame defense of Red Hat, when one turns on the firewalld daemon, that daemon implements a mostly-closed access policy. "memcached" is not listed in the named services. Furthermore, looking at the output of 'iptables -vnL' I saw no way that a 11211/udp packet would make its way through the firewall. The policy of "defense in depth" would argue that setting the default to disable 11211/udp is still the right thing(r) to do. From list at satchell.net Fri Mar 2 16:15:42 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 2 Mar 2018 08:15:42 -0800 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> Message-ID: <345597a8-febb-4fb8-4868-7479912c423f@satchell.net> On 03/01/2018 02:55 PM, Royce Williams wrote: > pstream, until two days ago, the default was to listen on all interfaces. > > https://github.com/memcached/memcached/wiki/ReleaseNotes156 > > The package maintainers were (thankfully) injecting additional sanity. Yes, they did, in commit dbb7a8af. Here is the commit comment: > disable UDP port by default > > As reported, UDP amplification attacks have started to use insecure > internet-exposed memcached instances. UDP used to be a lot more popular as a > transport for memcached many years ago, but I'm not aware of many recent > users. > > Ten years ago, the TCP connection overhead from many clients was relatively > high (dozens or hundreds per client server), but these days many clients are > batched, or user fewer processes, or simply anre't worried about it. > > While changing the default to listen on localhost only would also help, the > true culprit is UDP. There are many more use cases for using memcached over > the network than there are for using the UDP protocol. > > --------------------------------- memcached.c --------------------------------- > index 88a5f2e..7178666 100644 But then you look at the changes in that commit: what makes this a less-than-ideal change is that they didn't modify the default configuration file to include "-U 0". By defaulting their settings.udpport to zero in the C code, they stop-punch the astonishment factor. By not changing the distribution sysconfig file, though, they open a pitfall for those people who use UDP. The problem? They could have put a warning in the default file so that people who add OPTIONS="U 11211" would be told to firewall that UDP port from the public internet at large. (Then there is the case of people deploying memcached in the cloud, which would incur additional difficulties. But that's another argument...) From owen at delong.com Fri Mar 2 17:08:43 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 09:08:43 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: Message-ID: > On Mar 2, 2018, at 7:55 AM, Nicholas Warren wrote: > > Please don't take away ULA. > >>> You really think that doing ULA according to the RFCs (collision >>> avoidance algorithm and all) is easier than filling out a form at HE? >>> REALLY? >> >> Yes. > > It's hard enough to sell ipv6 for LAN without adding having to get a tunnel, register with a RIR, whatever else. > > ULA gives us the option to spin up ipv6 networks without anyone else being involved. We have to be able to make private networks without contacting anyone, and we will go back to ipv4 if that's our only option. I doubt anyone is taking it away, pointless and useless as it is. Owen From rwebb at ropeguru.com Fri Mar 2 17:37:47 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 2 Mar 2018 17:37:47 +0000 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: Thanks to all off list replies. Comcast rep was able to help out getting info over to the NOC. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Robert Webb Sent: Friday, March 2, 2018 10:53 AM To: nanog at nanog.org Subject: Comcast NOC Contact I know Virginia is having wind issues today. But can anyone from Comcast comment on intermittent routing issues between Charlottesville, VA and Ashburn, VA on their backbone? Issue appears to be between 69.139.206.9 ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 be-21508-cr02.ashburn.va.ibone.comcast.net Off list is fine. From cscora at apnic.net Fri Mar 2 18:03:10 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Mar 2018 04:03:10 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180302180310.A7FC7C450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 03 Mar, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 687961 Prefixes after maximum aggregation (per Origin AS): 266895 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 331711 Total ASes present in the Internet Routing Table: 59983 Prefixes per ASN: 11.47 Origin-only ASes present in the Internet Routing Table: 51808 Origin ASes announcing only one prefix: 22740 Transit ASes present in the Internet Routing Table: 8175 Transit-only ASes present in the Internet Routing Table: 257 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 37 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 58 Number of instances of unregistered ASNs: 58 Number of 32-bit ASNs allocated by the RIRs: 21677 Number of 32-bit ASNs visible in the Routing Table: 17438 Prefixes from 32-bit ASNs in the Routing Table: 72349 Number of bogon 32-bit ASNs visible in the Routing Table: 10 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 326 Number of addresses announced to Internet: 2855228258 Equivalent to 170 /8s, 47 /16s and 83 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 228105 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 189669 Total APNIC prefixes after maximum aggregation: 54076 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 188647 Unique aggregates announced from the APNIC address blocks: 77563 APNIC Region origin ASes present in the Internet Routing Table: 8675 APNIC Prefixes per ASN: 21.75 APNIC Region origin ASes announcing only one prefix: 2459 APNIC Region transit ASes present in the Internet Routing Table: 1284 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3589 Number of APNIC addresses announced to Internet: 768016418 Equivalent to 45 /8s, 199 /16s and 0 /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-137529 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: 205098 Total ARIN prefixes after maximum aggregation: 98253 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 205932 Unique aggregates announced from the ARIN address blocks: 97158 ARIN Region origin ASes present in the Internet Routing Table: 18084 ARIN Prefixes per ASN: 11.39 ARIN Region origin ASes announcing only one prefix: 6690 ARIN Region transit ASes present in the Internet Routing Table: 1797 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2314 Number of ARIN addresses announced to Internet: 1104806432 Equivalent to 65 /8s, 218 /16s and 2 /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-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 186339 Total RIPE prefixes after maximum aggregation: 90949 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 182630 Unique aggregates announced from the RIPE address blocks: 109299 RIPE Region origin ASes present in the Internet Routing Table: 24943 RIPE Prefixes per ASN: 7.32 RIPE Region origin ASes announcing only one prefix: 11325 RIPE Region transit ASes present in the Internet Routing Table: 3499 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: 6729 Number of RIPE addresses announced to Internet: 714026880 Equivalent to 42 /8s, 143 /16s and 47 /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-207259 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: 88435 Total LACNIC prefixes after maximum aggregation: 19571 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 89797 Unique aggregates announced from the LACNIC address blocks: 40020 LACNIC Region origin ASes present in the Internet Routing Table: 6880 LACNIC Prefixes per ASN: 13.05 LACNIC Region origin ASes announcing only one prefix: 1899 LACNIC Region transit ASes present in the Internet Routing Table: 1262 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 37 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4413 Number of LACNIC addresses announced to Internet: 172137888 Equivalent to 10 /8s, 66 /16s and 157 /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: 18360 Total AfriNIC prefixes after maximum aggregation: 4000 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 20629 Unique aggregates announced from the AfriNIC address blocks: 7410 AfriNIC Region origin ASes present in the Internet Routing Table: 1119 AfriNIC Prefixes per ASN: 18.44 AfriNIC Region origin ASes announcing only one prefix: 366 AfriNIC Region transit ASes present in the Internet Routing Table: 229 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 393 Number of AfriNIC addresses announced to Internet: 95837440 Equivalent to 5 /8s, 182 /16s and 93 /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 5442 4195 92 ERX-CERNET-BKB China Education and Rese 7545 4057 408 415 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2858 11132 774 KIXS-AS-KR Korea Telecom, KR 9829 2802 1499 540 BSNL-NIB National Internet Backbone, IN 17974 2710 934 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 7552 2638 1161 59 VIETEL-AS-AP Viettel Group, VN 9394 2630 4923 29 CTTNET China TieTong Telecommunications 45899 2561 1561 160 VNPT-AS-VN VNPT Corp, VN 9808 2180 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2083 417 215 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 3383 1323 84 SHAW - Shaw Communications Inc., CA 22773 3276 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2095 2483 435 CHARTER-NET-HKY-NC - Charter Communicat 16509 2027 4371 603 AMAZON-02 - Amazon.com, Inc., US 30036 1928 338 196 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1927 5055 619 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6389 1841 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 11492 1740 227 574 CABLEONE - CABLE ONE, INC., US 7018 1684 20187 1249 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 12479 3058 1316 804 UNI2-AS, ES 20940 2855 846 2071 AKAMAI-ASN1, US 8551 2066 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2037 1864 704 ROSTELECOM-AS, RU 34984 1992 332 474 TELLCOM-AS, TR 9121 1922 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1215 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 4161 3388 587 Uninet S.A. de C.V., MX 10620 3594 541 253 Telmex Colombia S.A., CO 11830 2639 370 66 Instituto Costarricense de Electricidad 6503 1625 437 53 Axtel, S.A.B. de C.V., MX 7303 1507 1026 191 Telecom Argentina S.A., AR 28573 1021 2246 189 CLARO S.A., BR 6147 1010 377 27 Telefonica del Peru S.A.A., PE 3816 1007 506 120 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 923 126 85 Alestra, S. de R.L. de C.V., MX 18881 907 1072 29 TELEF�NICA BRASIL S.A, BR 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 1162 398 49 LINKdotNET-AS, EG 37611 809 91 8 Afrihost, ZA 36903 739 371 135 MT-MPLS, MA 36992 681 1380 38 ETISALAT-MISR, EG 8452 615 1730 18 TE-AS TE-AS, EG 24835 557 850 15 RAYA-AS, EG 29571 466 68 12 ORANGE-COTE-IVOIRE, CI 37492 453 376 80 ORANGE-, TN 15399 361 35 7 WANANCHI-, KE 37342 360 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5442 4195 92 ERX-CERNET-BKB China Education and Rese 8151 4161 3388 587 Uninet S.A. de C.V., MX 7545 4057 408 415 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3594 541 253 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3383 1323 84 SHAW - Shaw Communications Inc., CA 22773 3276 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 12479 3058 1316 804 UNI2-AS, ES 4766 2858 11132 774 KIXS-AS-KR Korea Telecom, KR 20940 2855 846 2071 AKAMAI-ASN1, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4057 3642 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4161 3574 Uninet S.A. de C.V., MX 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3594 3341 Telmex Colombia S.A., CO 6327 3383 3299 SHAW - Shaw Communications Inc., CA 22773 3276 3127 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2710 2630 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2630 2601 CTTNET China TieTong Telecommunications Corpora 7552 2638 2579 VIETEL-AS-AP Viettel Group, VN 11830 2639 2573 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.92.0/24 65001 -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 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 37.44.224.0/20 48666 AS-MAROSNET Moscow, Russia, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:14 /9:11 /10:37 /11:100 /12:289 /13:563 /14:1094 /15:1896 /16:13317 /17:7834 /18:13616 /19:25232 /20:39103 /21:45091 /22:84770 /23:68868 /24:383905 /25:839 /26:597 /27:652 /28:35 /29:19 /30:17 /31:4 /32:58 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3175 3383 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2532 3276 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1986 2639 Instituto Costarricense de Electricidad y Telec 12479 1890 3058 UNI2-AS, ES 30036 1683 1928 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1594 3594 Telmex Colombia S.A., CO 8551 1529 2066 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1522 1740 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1569 2:831 4:19 5:2798 6:59 7:1 8:1100 9:1 12:1872 13:206 14:1755 15:26 16:3 17:187 18:69 20:48 21:3 23:2549 24:2175 25:2 27:2346 31:1950 32:88 35:25 36:497 37:2648 38:1463 39:247 40:103 41:3005 42:545 43:1951 44:100 45:3785 46:3029 47:198 49:1357 50:1043 51:48 52:978 54:353 55:3 56:8 57:42 58:1595 59:1023 60:427 61:2135 62:1800 63:1802 64:4694 65:2225 66:4542 67:2340 68:1169 69:3195 70:1193 71:557 72:2100 74:2670 75:401 76:424 77:1535 78:1669 79:1809 80:1486 81:1418 82:1080 83:778 84:1016 85:2035 86:559 87:1260 88:915 89:2299 90:190 91:6304 92:1186 93:2373 94:2403 95:2734 96:651 97:356 98:928 99:124 100:80 101:1474 102:28 103:17266 104:3274 105:221 106:563 107:1795 108:708 109:2691 110:1588 111:1775 112:1316 113:1379 114:1111 115:1650 116:1646 117:1707 118:2186 119:1674 120:967 121:1072 122:2458 123:1815 124:1460 125:1877 128:975 129:613 130:444 131:1602 132:647 133:194 134:999 135:225 136:440 137:491 138:1950 139:573 140:402 141:686 142:783 143:972 144:799 145:456 146:1159 147:745 148:1535 149:709 150:744 151:1046 152:750 153:308 154:1035 155:753 156:843 157:778 158:623 159:1629 160:869 161:730 162:2550 163:527 164:1025 165:1379 166:397 167:1386 168:3091 169:807 170:3689 171:416 172:1059 173:1925 174:879 175:755 176:1919 177:3927 178:2420 179:1176 180:2237 181:2138 182:2462 183:1132 184:910 185:12725 186:3482 187:2319 188:2702 189:1974 190:8118 191:1450 192:9768 193:5889 194:4774 195:3968 196:2439 197:1428 198:5520 199:5887 200:7311 201:4876 202:10391 203:10083 204:4535 205:2855 206:3062 207:3123 208:3988 209:3932 210:4038 211:2119 212:3010 213:2665 214:903 215:63 216:5852 217:2131 218:899 219:621 220:1735 221:996 222:1053 223:1242 End of report From matt at netfire.net Fri Mar 2 19:27:28 2018 From: matt at netfire.net (Matt Harris) Date: Fri, 2 Mar 2018 13:27:28 -0600 Subject: IPv6 Unique Local Addresses In-Reply-To: References: Message-ID: On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong wrote: > > I doubt anyone is taking it away, pointless and useless as it is. > > Owen > I'm not sure I'd say it's pointless and useless. It's free, which gives it at least some point/use case, versus IPv6 space obtained from an RIR where, at least in ARIN's case, you have fees associated with that. I'm lucky enough to have a /32 from ARIN for the networks I work on, so we're not stretched for space or worried about deploying ULA. For a small organization where even a /48 would be a luxury, and with no good native IPv6 carriers available locally (still plenty of places like that), deploying IPv6 on ULA space may be the stepping stone they need until other options become open to them. From todd at toddcrane.com Thu Mar 1 18:57:53 2018 From: todd at toddcrane.com (Todd Crane) Date: Thu, 1 Mar 2018 11:57:53 -0700 Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <20180301015247.GA6721@vurt.meerval.net> References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> Message-ID: Question: Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer’s BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can’t send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being. This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters. —Todd > On Feb 28, 2018, at 6:52 PM, Job Snijders wrote: > > On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: >> On 2018-02-27, Ca By sent: >>> Please do take a look at the cloudflare blog specifically as they >>> name and shame OVH and Digital Ocean for being the primary sources >>> of mega crap traffic >>> >>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >>> >>> Also, policer all UDP all the time... UDP is unsafe at any speed. >> >> Hi, DigitalOcean here. We've taken steps to mitigate this attack on >> our network. > > NTT too has deployed rate limiters on all external facing interfaces on > the GIN backbone - for UDP/11211 traffic - to dampen the negative impact > of open memcached instances on peers and customers. > > The toxic combination of 'one spoofed packet can yield multiple reponse > packets' and 'one small packet can yield a very big response' makes the > memcached UDP protocol a fine example of double trouble with potential > for severe operational impact. > > Kind regards, > > Job -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From merculiani at gmail.com Fri Mar 2 00:48:03 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Thu, 1 Mar 2018 18:48:03 -0600 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> References: <55DC30FD-3FBD-4C28-BB40-63D161B3917C@isc.org> Message-ID: Not sure if this is the common thought, but if anyone has a network which requires static IP assignments, they can probably justify a request for a /48 from an RIR. After all, ARIN's requirement for an end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from an ISP or other LIR are unsuitable". I would think that ISP portability would satisfy this requirement, but If I'm wrong, I'm absolutely open to being corrected on this. But most home users have no need for static IPs, so the dynamic ISP assignment is perfectly fine. I think the tech will advance fast enough that keeping up with an IPv6 route table will be a non-issue. IPv6 adoption is, unfortunately, slow enough that there will be no issues keeping up, even assuming a "slow" hardware refresh cycle. -M On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews wrote: > >> On 2 Mar 2018, at 9:28 am, Owen DeLong wrote: >> >> >>> On Mar 1, 2018, at 1:20 PM, Harald Koch wrote: >>> >>> On 1 March 2018 at 15:18, Owen DeLong > wrote: >>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone >>> uses ULA (the IPv6 analogue to RFC-1918). >>> >>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there something new? >> >> No particular objection, but I don’t see the point. >> >> What can you do with ULA that GUA isn’t suitable for? >> >> Owen > > ULA provide stable internal addresses which survive changing ISP > for the average home user. Now, I know you can do the same thing > by going to a RIR and getting a prefix but the RIR’s aren’t setup > to supply prefixes like that to 10 billion of us. > > They are also in a specific range which makes setting filtering > rules easier for everyone else. > > Now I would love it if we could support 100 billion routes in the > DFZ but we aren’t anywhere near being able to do that which would > be a requirement for abandoning ULA. Until them they have there > place. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From nanog at ics-il.net Fri Mar 2 20:18:33 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 2 Mar 2018 14:18:33 -0600 (CST) Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> Message-ID: <1890825435.2929.1520021910748.JavaMail.mhammett@ThunderFuck> https://en.wikipedia.org/wiki/Reverse_path_forwarding#Loose_mode towards transit. https://en.wikipedia.org/wiki/Reverse_path_forwarding#Strict_mode towards customers. Peers... *shrugs*. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Todd Crane" To: "NANOG list" Cc: "Job Snijders" Sent: Thursday, March 1, 2018 12:57:53 PM Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) Question: Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer’s BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can’t send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being. This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters. —Todd > On Feb 28, 2018, at 6:52 PM, Job Snijders wrote: > > On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: >> On 2018-02-27, Ca By sent: >>> Please do take a look at the cloudflare blog specifically as they >>> name and shame OVH and Digital Ocean for being the primary sources >>> of mega crap traffic >>> >>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >>> >>> Also, policer all UDP all the time... UDP is unsafe at any speed. >> >> Hi, DigitalOcean here. We've taken steps to mitigate this attack on >> our network. > > NTT too has deployed rate limiters on all external facing interfaces on > the GIN backbone - for UDP/11211 traffic - to dampen the negative impact > of open memcached instances on peers and customers. > > The toxic combination of 'one spoofed packet can yield multiple reponse > packets' and 'one small packet can yield a very big response' makes the > memcached UDP protocol a fine example of double trouble with potential > for severe operational impact. > > Kind regards, > > Job From joelja at bogus.com Fri Mar 2 20:34:54 2018 From: joelja at bogus.com (joel jaeggli) Date: Fri, 2 Mar 2018 12:34:54 -0800 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> Message-ID: <1da504f3-d544-10b7-87d7-88c44fae6945@bogus.com> On 3/1/18 10:57 AM, Todd Crane wrote: > Question: > Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. > > With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer’s BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can’t send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being. you can build ACLs from IRR objects  just like you can build prefix lists. for customers this is just as feasible as controlling what routes you accept from them. unlike URPF strict  this will not cause an outage every time a prefix is withdrawn but traffic continues to flow (which is a normal and healthy part of doing maintenance). on the other hand it means your prefix lists will have to be rather up to date and your peers will likely have to be very up to date with their customers. since failures for inclusion will cause black holes. you can't do this on on and MLPE exchange where you export routes unless you want to cause an outage everytime a new peer is added. there is also the problem of the number of cam slots these IP acls chew up. bgpq3 -P AS-FOO > This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters. The source addresses of attack traffic associated with for example memcached (and in fact virtually all reflection attacks) are not spoofed. > > —Todd > >> On Feb 28, 2018, at 6:52 PM, Job Snijders wrote: >> >> On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: >>> On 2018-02-27, Ca By sent: >>>> Please do take a look at the cloudflare blog specifically as they >>>> name and shame OVH and Digital Ocean for being the primary sources >>>> of mega crap traffic >>>> >>>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >>>> >>>> Also, policer all UDP all the time... UDP is unsafe at any speed. >>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on >>> our network. >> NTT too has deployed rate limiters on all external facing interfaces on >> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact >> of open memcached instances on peers and customers. >> >> The toxic combination of 'one spoofed packet can yield multiple reponse >> packets' and 'one small packet can yield a very big response' makes the >> memcached UDP protocol a fine example of double trouble with potential >> for severe operational impact. >> >> Kind regards, >> >> Job -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From matthew at matthew.at Fri Mar 2 20:40:20 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 02 Mar 2018 20:40:20 +0000 Subject: IPv6 Unique Local Addresses In-Reply-To: References: Message-ID: Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN is not. You want to discourage someone from doing the right thing, charge a lot for that. Matthew Kaufman On Fri, Mar 2, 2018 at 11:30 AM Matt Harris wrote: > On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong wrote: > > > > > I doubt anyone is taking it away, pointless and useless as it is. > > > > Owen > > > > I'm not sure I'd say it's pointless and useless. It's free, which gives it > at least some point/use case, versus IPv6 space obtained from an RIR where, > at least in ARIN's case, you have fees associated with that. I'm lucky > enough to have a /32 from ARIN for the networks I work on, so we're not > stretched for space or worried about deploying ULA. For a small > organization where even a /48 would be a luxury, and with no good native > IPv6 carriers available locally (still plenty of places like that), > deploying IPv6 on ULA space may be the stepping stone they need until other > options become open to them. > From matthias at leisi.net Fri Mar 2 20:42:44 2018 From: matthias at leisi.net (Matthias Leisi) Date: Fri, 2 Mar 2018 21:42:44 +0100 Subject: dnswl.org contact In-Reply-To: References: Message-ID: > Am 02.03.2018 um 00:55 schrieb Randy Bush : > > anyone have contact with the dnswl.org folk? replied off-list. — Matthias From owen at delong.com Fri Mar 2 20:45:27 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 12:45:27 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: Message-ID: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Space from tunnel brokers is also free. Owen > On Mar 2, 2018, at 12:40 PM, Matthew Kaufman wrote: > > Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN is not. You want to discourage someone from doing the right thing, charge a lot for that. > > Matthew Kaufman > > On Fri, Mar 2, 2018 at 11:30 AM Matt Harris > wrote: > On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong > wrote: > > > > > I doubt anyone is taking it away, pointless and useless as it is. > > > > Owen > > > > I'm not sure I'd say it's pointless and useless. It's free, which gives it > at least some point/use case, versus IPv6 space obtained from an RIR where, > at least in ARIN's case, you have fees associated with that. I'm lucky > enough to have a /32 from ARIN for the networks I work on, so we're not > stretched for space or worried about deploying ULA. For a small > organization where even a /48 would be a luxury, and with no good native > IPv6 carriers available locally (still plenty of places like that), > deploying IPv6 on ULA space may be the stepping stone they need until other > options become open to them. From matt at netfire.net Fri Mar 2 21:06:00 2018 From: matt at netfire.net (Matt Harris) Date: Fri, 2 Mar 2018 15:06:00 -0600 Subject: IPv6 Unique Local Addresses In-Reply-To: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong wrote: > Space from tunnel brokers is also free. > > Owen > For myriad reasons (added latency, reliability concerns related to relying on traffic over a connection which doesn't offer an SLA or recourse for downtime, lack of support on ISP-provided CPE, etc) a tunnel broker connection may not be a feasible choice for all organizations and networks. This brings us back to my previous point. From bgreene at senki.org Fri Mar 2 21:07:08 2018 From: bgreene at senki.org (Barry Raveendran Greene) Date: Fri, 2 Mar 2018 16:07:08 -0500 Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> Message-ID: <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> Hi Todd, What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. Russ White and I worked on it while at Cisco. Given that you are setting up prefix filters with your peers, you can add to the peering agreement that you will only accept packets whose source addresses matches the prefixes sent. You then take that BGP session, feed that into a VRF on the interface, and run uRPF against that VRF. If a source address does not match, drop. If the BGP session adds more routes, those automatically update the VRF “white list” for the uRPF. It was build to scale. Not sure where it is at in the code or the hardware. Ask Cisco. Barry PS - So yes, you can do uRPF on your peering sessions. It was coded and deployed back in 2006. > On Mar 1, 2018, at 13:57, Todd Crane wrote: > > Question: > Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. > > With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer’s BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can’t send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being. > > This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters. > > > —Todd > >> On Feb 28, 2018, at 6:52 PM, Job Snijders wrote: >> >> On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: >>> On 2018-02-27, Ca By sent: >>>> Please do take a look at the cloudflare blog specifically as they >>>> name and shame OVH and Digital Ocean for being the primary sources >>>> of mega crap traffic >>>> >>>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ >>>> >>>> Also, policer all UDP all the time... UDP is unsafe at any speed. >>> >>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on >>> our network. >> >> NTT too has deployed rate limiters on all external facing interfaces on >> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact >> of open memcached instances on peers and customers. >> >> The toxic combination of 'one spoofed packet can yield multiple reponse >> packets' and 'one small packet can yield a very big response' makes the >> memcached UDP protocol a fine example of double trouble with potential >> for severe operational impact. >> >> Kind regards, >> >> Job > From marka at isc.org Fri Mar 2 21:11:08 2018 From: marka at isc.org (Mark Andrews) Date: Sat, 3 Mar 2018 08:11:08 +1100 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <87efl24s06.fsf@miraculix.mork.no> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <87efl24s06.fsf@miraculix.mork.no> Message-ID: Are you insane. ISPs should never use RFC 1918 addresses for stuff that talks to their customers. They have no way of knowing which addresses the customers are using. Traffic from RFC 1918 addresses should be dropped by any sane border router which all routers connecting to a ISP are. -- Mark Andrews > On 2 Mar 2018, at 22:49, Bjørn Mork wrote: > > Owen DeLong writes: > >> I don’t agree that making RFC-1918 limitations a default in any daemon makes any >> sense whatsoever. > > +1 > > One of the more annoying anti-features I know of in this regard is the > dnsmasq rebind "protection". It claims to protect web browsers on the > LAN against DNS rebind attacks. But the implementation does not > consider which adresses are used on the LAN at all. It simply blocks > any A record pointing to an RFC1918 address, making a few bogus > assumptions: > - IPv4 LAN addresses are selected from RFC1918 > - RFC1918 addresses are never used on the WAN side of a CPE > - Noone use IPv6 on their LAN > > It's hard to know how many users have been bitten by the first > one. You'd have to depend on this rebind "protection" in the first > place, and that would be.... stupid. > > But the second assumption regularily bites end users when their ISP > provides some ISP internal service using RFC1918 addresses. Which of course > is fine. > > The anti-feature has been enabled by default in OpenWrt for a long time, > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that > there is a large user base having this enabled without knowing. > >> First, there are plenty of LANs out there that don’t use RFC-1918. >> >> Second, RFC-1918 doesn’t apply to IPv6 at all, > > Could you try to explain that to the OpenWrt guys? Thanks > > > > Bjørn From kscotthelms at gmail.com Fri Mar 2 21:18:37 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Fri, 2 Mar 2018 16:18:37 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <87efl24s06.fsf@miraculix.mork.no> Message-ID: I won't comment on the sanity of doing so, but _many_ service providers use EMTAs, ATAs, and other voice devices over RFC1918 space back to their core. On Fri, Mar 2, 2018 at 4:11 PM, Mark Andrews wrote: > Are you insane. ISPs should never use RFC 1918 addresses for stuff that > talks to their customers. They have no way of knowing which addresses the > customers are using. > > Traffic from RFC 1918 addresses should be dropped by any sane border > router which all routers connecting to a ISP are. > > -- > Mark Andrews > > > On 2 Mar 2018, at 22:49, Bjørn Mork wrote: > > > > Owen DeLong writes: > > > >> I don’t agree that making RFC-1918 limitations a default in any daemon > makes any > >> sense whatsoever. > > > > +1 > > > > One of the more annoying anti-features I know of in this regard is the > > dnsmasq rebind "protection". It claims to protect web browsers on the > > LAN against DNS rebind attacks. But the implementation does not > > consider which adresses are used on the LAN at all. It simply blocks > > any A record pointing to an RFC1918 address, making a few bogus > > assumptions: > > - IPv4 LAN addresses are selected from RFC1918 > > - RFC1918 addresses are never used on the WAN side of a CPE > > - Noone use IPv6 on their LAN > > > > It's hard to know how many users have been bitten by the first > > one. You'd have to depend on this rebind "protection" in the first > > place, and that would be.... stupid. > > > > But the second assumption regularily bites end users when their ISP > > provides some ISP internal service using RFC1918 addresses. Which of > course > > is fine. > > > > The anti-feature has been enabled by default in OpenWrt for a long time, > > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that > > there is a large user base having this enabled without knowing. > > > >> First, there are plenty of LANs out there that don’t use RFC-1918. > >> > >> Second, RFC-1918 doesn’t apply to IPv6 at all, > > > > Could you try to explain that to the OpenWrt guys? Thanks > > > > > > > > Bjørn > > From bryan at shout.net Fri Mar 2 21:29:08 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 2 Mar 2018 15:29:08 -0600 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: Another problem with tunnel brokers is that they are sometimes flagged by content providers as being some sort of "proxy", and consequently won't send you traffic. Notably, Netflix. On 3/2/18 3:06 PM, Matt Harris wrote: > On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong wrote: > >> Space from tunnel brokers is also free. >> >> Owen >> > > For myriad reasons (added latency, reliability concerns related to relying > on traffic over a connection which doesn't offer an SLA or recourse for > downtime, lack of support on ISP-provided CPE, etc) a tunnel broker > connection may not be a feasible choice for all organizations and > networks. This brings us back to my previous point. > From matthew at matthew.at Fri Mar 2 21:30:11 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 02 Mar 2018 21:30:11 +0000 Subject: IPv6 Unique Local Addresses In-Reply-To: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: Section 3 of https://tunnelbroker.net/tos.php It isn't "free". It may be included with a service that is currently available for free, but they aren't providing free address space for an unlimited period. Matthew Kaufman On Fri, Mar 2, 2018 at 12:45 PM Owen DeLong wrote: > Space from tunnel brokers is also free. > > Owen > > On Mar 2, 2018, at 12:40 PM, Matthew Kaufman wrote: > > Exactly what Matt Harris says here... ULA is free. Space obtained from > ARIN is not. You want to discourage someone from doing the right thing, > charge a lot for that. > > Matthew Kaufman > > On Fri, Mar 2, 2018 at 11:30 AM Matt Harris wrote: > >> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong wrote: >> >> > >> > I doubt anyone is taking it away, pointless and useless as it is. >> > >> > Owen >> > >> >> I'm not sure I'd say it's pointless and useless. It's free, which gives >> it >> at least some point/use case, versus IPv6 space obtained from an RIR >> where, >> at least in ARIN's case, you have fees associated with that. I'm lucky >> enough to have a /32 from ARIN for the networks I work on, so we're not >> stretched for space or worried about deploying ULA. For a small >> organization where even a /48 would be a luxury, and with no good native >> IPv6 carriers available locally (still plenty of places like that), >> deploying IPv6 on ULA space may be the stepping stone they need until >> other >> options become open to them. >> > > From kscotthelms at gmail.com Fri Mar 2 21:58:57 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Fri, 2 Mar 2018 16:58:57 -0500 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: <1B278945-929D-491A-A3BB-89450FE9528F@benappy.com> References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <87efl24s06.fsf@miraculix.mork.no> <1B278945-929D-491A-A3BB-89450FE9528F@benappy.com> Message-ID: They use separate service flows and layer 3 interfaces (usually) in DOCSIS networks but they often use the same DNS infrastructure which is why I piped up. Scott Helms On Mar 2, 2018 4:46 PM, "Michel 'ic' Luczak" wrote: The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway unrelated to any client’s address space. Also, french triple play ISPs use RFC1918 space for IPTV but again isolated of any customer network so doesn’t really matter. > On 2 Mar 2018, at 22:18, K. Scott Helms wrote: > > I won't comment on the sanity of doing so, but _many_ service providers use > EMTAs, ATAs, and other voice devices over RFC1918 space back to their core. > From mpetach at netflight.com Fri Mar 2 22:11:10 2018 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 2 Mar 2018 14:11:10 -0800 Subject: Peering with abusers...good or bad? Message-ID: On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis wrote: > OVH does not suprise me in the least. > > Maybe this is finally what it will take to get people to de-peer them. > If I de-peer them, I pay my upstream to carry the attack traffic. If I maintain peering with them, the attack traffic is free. It would seem the economics work the other way around. It would be more cost effective for me to identify the largest sources of attacks, and reach out to directly peer with them, to avoid paying an upstream to carry the traffic, if I'm going to end up throwing it away anyhow. From jfmezei_nanog at vaxination.ca Fri Mar 2 22:38:49 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 2 Mar 2018 17:38:49 -0500 Subject: Average number of ports on OLT cards Message-ID: <7b74405d-b2cd-fe7d-cfd8-8db608940996@vaxination.ca> Quick question: (sanity check). For a deployment happening now by an incumbent telco (aka: serving large number of homes), how many GPON ports would it want per each OLT card ? or more precisely, what sort of range is there for the number of ports for such a deployment? (The CRTC in Canada is asking for costing info for 4 port cards, so wondering if this could be squewing the cost per port if cards today are generally deployed with say 8 or 16 ports). As an example of where I am coming from: Bell Canada claimed that Juniper E320s costed $x and had 1 gbps of capacity, which means $x per gbps of capacity, when in fact, the actual real life capacity with PPPoE going to L2TP links was about 80gbps, which means $x/80 per gbps, so significant difference in cost per gbps. From johnl at iecc.com Fri Mar 2 23:07:45 2018 From: johnl at iecc.com (John Levine) Date: 2 Mar 2018 18:07:45 -0500 Subject: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) In-Reply-To: Message-ID: <20180302230745.9E6681F188F1@ary.qy> In article you write: >What can you do with ULA that GUA isn’t suitable for? I have a home network with two segments, one wired and one wireless. It has IPv6 addresses assigned by my ISP, Spectrum nee TWC, which probably won't change but who knows, they make no promises. I have some servers on my network, like printers, scanners, backup disks, and a phone TA. Getting my own /48 would be absurd. ULAs are just the ticket. From cb.list6 at gmail.com Fri Mar 2 23:29:03 2018 From: cb.list6 at gmail.com (Ca By) Date: Fri, 02 Mar 2018 23:29:03 +0000 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach wrote: > On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis > wrote: > > OVH does not suprise me in the least. > > > > Maybe this is finally what it will take to get people to de-peer them. > > > > If I de-peer them, I pay my upstream to carry the > attack traffic. > Your isp will do rtbh Your peers wont > If I maintain peering with them, the attack traffic is free. > > It would seem the economics work the other way around. > > It would be more cost effective for me to identify the largest sources > of attacks, and reach out to directly peer with them, to avoid paying > an upstream to carry the traffic, if I'm going to end up throwing it > away anyhow. > From bryan at shout.net Sat Mar 3 00:07:49 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 2 Mar 2018 18:07:49 -0600 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: On 3/2/18 5:29 PM, Ca By wrote: > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach wrote: > >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis >> wrote: >>> OVH does not suprise me in the least. >>> >>> Maybe this is finally what it will take to get people to de-peer them. >>> >> >> If I de-peer them, I pay my upstream to carry the >> attack traffic. >> > > Your isp will do rtbh > > Your peers wont Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs is a different story. > >> If I maintain peering with them, the attack traffic is free. >> >> It would seem the economics work the other way around. >> >> It would be more cost effective for me to identify the largest sources >> of attacks, and reach out to directly peer with them, to avoid paying >> an upstream to carry the traffic, if I'm going to end up throwing it >> away anyhow. >> From job at instituut.net Sat Mar 3 00:11:01 2018 From: job at instituut.net (Job Snijders) Date: Sat, 03 Mar 2018 00:11:01 +0000 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: On Sat, 3 Mar 2018 at 01:08, Bryan Holloway wrote: > > On 3/2/18 5:29 PM, Ca By wrote: > > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach > wrote: > > > >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis > >> wrote: > >>> OVH does not suprise me in the least. > >>> > >>> Maybe this is finally what it will take to get people to de-peer them. > >>> > >> > >> If I de-peer them, I pay my upstream to carry the > >> attack traffic. > >> > > > > Your isp will do rtbh > > > > Your peers wont > > > Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs > is a different story. Those IX “blackhole” mechanisms are a perverse ineffective method that exists solely for marketing reasons. If you aren’t blackholing in the fabric you aren’t blackholing. Kind regards, Job > From baldur.norddahl at gmail.com Sat Mar 3 00:22:45 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 3 Mar 2018 01:22:45 +0100 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: So I want to buy additional ports at each IX. The slowest speed they offer. If I am lucky they have a free 100 Mbps. And then I just announce the prefix I want to blackhole. Doesn't matter that the port overloads. I am just going to null route the traffic anyway... Regards Baldur Den 3. mar. 2018 01.12 skrev "Job Snijders" : On Sat, 3 Mar 2018 at 01:08, Bryan Holloway wrote: > > On 3/2/18 5:29 PM, Ca By wrote: > > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach > wrote: > > > >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis > >> wrote: > >>> OVH does not suprise me in the least. > >>> > >>> Maybe this is finally what it will take to get people to de-peer them. > >>> > >> > >> If I de-peer them, I pay my upstream to carry the > >> attack traffic. > >> > > > > Your isp will do rtbh > > > > Your peers wont > > > Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs > is a different story. Those IX “blackhole” mechanisms are a perverse ineffective method that exists solely for marketing reasons. If you aren’t blackholing in the fabric you aren’t blackholing. Kind regards, Job > From job at instituut.net Sat Mar 3 00:24:58 2018 From: job at instituut.net (Job Snijders) Date: Sat, 03 Mar 2018 00:24:58 +0000 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: On Sat, 3 Mar 2018 at 01:23, Baldur Norddahl wrote: > So I want to buy additional ports at each IX. The slowest speed they offer. > If I am lucky they have a free 100 Mbps. And then I just announce the > prefix I want to blackhole. Doesn't matter that the port overloads. I am > just going to null route the traffic anyway... Sure, that works. Those are called “choke ports”. Kind regards, Job > From owen at delong.com Sat Mar 3 06:30:36 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 22:30:36 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: Once again, you’re talking about usability of the addresses for internet connectivity. I don’t understand the relevance since we’re talking about a GUA based substitute for ULA. What am I missing? Owen > On Mar 2, 2018, at 1:29 PM, Bryan Holloway wrote: > > Another problem with tunnel brokers is that they are sometimes flagged by content providers as being some sort of "proxy", and consequently won't send you traffic. Notably, Netflix. > > > On 3/2/18 3:06 PM, Matt Harris wrote: >> On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong wrote: >>> Space from tunnel brokers is also free. >>> >>> Owen >>> >> For myriad reasons (added latency, reliability concerns related to relying >> on traffic over a connection which doesn't offer an SLA or recourse for >> downtime, lack of support on ISP-provided CPE, etc) a tunnel broker >> connection may not be a feasible choice for all organizations and >> networks. This brings us back to my previous point. From matt at netfire.net Sat Mar 3 06:38:58 2018 From: matt at netfire.net (Matt Harris) Date: Sat, 3 Mar 2018 00:38:58 -0600 Subject: IPv6 Unique Local Addresses In-Reply-To: <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> Message-ID: On Sat, Mar 3, 2018 at 12:33 AM, Owen DeLong wrote: > Sure… You have to maintain the tunnel or they may reassign/reallocate the > address. Here’s the reality of that, however: > > 1. Unless you care about reaching the customer they reassigned it to from > your network, you don’t care. > 2. Using it for ULA in addition to the tunnel isn’t really prohibited by > that. It’s a gray area, I’ll admit. > 3. Sure, they can cancel the service at any time, but you get what you > pay for. It saves you $100/year > while it lasts. > > Owen > I'm not sure where you're getting the $100 figure from, ARIN's minimum fee for an allocation is $250/year (for a /40 or smaller block) on top of membership fees of $500/yr, so that's $750/yr to get a /48 from the North American RIR (which is the only one I'm looking at today given that the context is the nanog list). Additionally, tunnel providers can and have shut down permanently at random - SixXS was among the largest providers, and they shut down operations entirely last year. So any folks using space from them had to renumber, either on to another tunnel provider's space, or to ULA. Re-numbering has associated costs, which in the case we're pointing to here, could've been saved had they deployed on ULA space instead. From owen at delong.com Sat Mar 3 06:34:46 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 22:34:46 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: <14AAE769-61CA-4ADC-807C-CB476A9799D9@delong.com> > On Mar 2, 2018, at 1:06 PM, Matt Harris wrote: > > On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong > wrote: > Space from tunnel brokers is also free. > > Owen > > For myriad reasons (added latency, reliability concerns related to relying on traffic over a connection which doesn't offer an SLA or recourse for downtime, lack of support on ISP-provided CPE, etc) a tunnel broker connection may not be a feasible choice for all organizations and networks. This brings us back to my previous point. > Again, how is this relevant if you are using the space as if it were ULA? Owen From owen at delong.com Sat Mar 3 06:33:25 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 22:33:25 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> Message-ID: <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> Sure… You have to maintain the tunnel or they may reassign/reallocate the address. Here’s the reality of that, however: 1. Unless you care about reaching the customer they reassigned it to from your network, you don’t care. 2. Using it for ULA in addition to the tunnel isn’t really prohibited by that. It’s a gray area, I’ll admit. 3. Sure, they can cancel the service at any time, but you get what you pay for. It saves you $100/year while it lasts. Owen > On Mar 2, 2018, at 1:30 PM, Matthew Kaufman wrote: > > Section 3 of https://tunnelbroker.net/tos.php > > It isn't "free". It may be included with a service that is currently available for free, but they aren't providing free address space for an unlimited period. > > Matthew Kaufman > > On Fri, Mar 2, 2018 at 12:45 PM Owen DeLong > wrote: > Space from tunnel brokers is also free. > > Owen > >> On Mar 2, 2018, at 12:40 PM, Matthew Kaufman > wrote: >> >> Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN is not. You want to discourage someone from doing the right thing, charge a lot for that. >> >> Matthew Kaufman >> >> On Fri, Mar 2, 2018 at 11:30 AM Matt Harris > wrote: >> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong > wrote: >> >> > >> > I doubt anyone is taking it away, pointless and useless as it is. >> > >> > Owen >> > >> >> I'm not sure I'd say it's pointless and useless. It's free, which gives it >> at least some point/use case, versus IPv6 space obtained from an RIR where, >> at least in ARIN's case, you have fees associated with that. I'm lucky >> enough to have a /32 from ARIN for the networks I work on, so we're not >> stretched for space or worried about deploying ULA. For a small >> organization where even a /48 would be a luxury, and with no good native >> IPv6 carriers available locally (still plenty of places like that), >> deploying IPv6 on ULA space may be the stepping stone they need until other >> options become open to them. > From josmon at rigozsaurus.com Sat Mar 3 07:08:08 2018 From: josmon at rigozsaurus.com (John Osmon) Date: Sat, 3 Mar 2018 00:08:08 -0700 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> Message-ID: <20180303070808.GA6719@jeeves.rigozsaurus.com> On Sat, Mar 03, 2018 at 12:38:58AM -0600, Matt Harris wrote: > I'm not sure where you're getting the $100 figure from, ARIN's minimum fee > for an allocation is $250/year [...] End Users have a different fee structure: Annual maintenance fees are $100 for each IPv4 address block, $100 for each IPv6 address block, and $100 USD for each ASN assigned to the organization. If you just have an IPv6 block, it's only $100/year. From owen at delong.com Sat Mar 3 07:02:16 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2018 23:02:16 -0800 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> Message-ID: > On Mar 2, 2018, at 10:38 PM, Matt Harris wrote: > > On Sat, Mar 3, 2018 at 12:33 AM, Owen DeLong > wrote: > Sure… You have to maintain the tunnel or they may reassign/reallocate the address. Here’s the reality of that, however: > > 1. Unless you care about reaching the customer they reassigned it to from your network, you don’t care. > 2. Using it for ULA in addition to the tunnel isn’t really prohibited by that. It’s a gray area, I’ll admit. > 3. Sure, they can cancel the service at any time, but you get what you pay for. It saves you $100/year > while it lasts. > > Owen > > I'm not sure where you're getting the $100 figure from, ARIN's minimum fee for an allocation is $250/year (for a /40 or smaller block) on top of membership fees of $500/yr, so that's $750/yr to get a /48 from the North American RIR (which is the only one I'm looking at today given that the context is the nanog list). Additionally, tunnel providers can and have shut down permanently at random - SixXS was among the largest providers, and they shut down operations entirely last year. So any folks using space from them had to renumber, either on to another tunnel provider's space, or to ULA. Re-numbering has associated costs, which in the case we're pointing to here, could've been saved had they deployed on ULA space instead. > You don’t need an allocation. Get an assignment. Owen From clayton at MNSi.Net Sat Mar 3 13:51:48 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 03 Mar 2018 08:51:48 -0500 Subject: Average number of ports on OLT cards In-Reply-To: <7b74405d-b2cd-fe7d-cfd8-8db608940996@vaxination.ca> References: <7b74405d-b2cd-fe7d-cfd8-8db608940996@vaxination.ca> Message-ID: <1520085111_76036@surgemail.mnsi.net> Ports typically range from 4 to 16 per card, depending on the model and vendor. Larger chassis typically have from 16 to 18 slots. You also have to take in to account oversubscription rates on the port to subscriber, port card to backplane and uplink card to network portions of the system. Some providers may be more conservative in their provisioning than others. At 05:38 PM 02/03/2018, Jean-Francois Mezei wrote: >Quick question: (sanity check). > >For a deployment happening now by an incumbent telco (aka: serving large >number of homes), how many GPON ports would it want per each OLT card ? > >or more precisely, what sort of range is there for the number of ports >for such a deployment? > >(The CRTC in Canada is asking for costing info for 4 port cards, so >wondering if this could be squewing the cost per port if cards today are >generally deployed with say 8 or 16 ports). > >As an example of where I am coming from: Bell Canada claimed that >Juniper E320s costed $x and had 1 gbps of capacity, which means $x per >gbps of capacity, when in fact, the actual real life capacity with PPPoE >going to L2TP links was about 80gbps, which means $x/80 per gbps, so >significant difference in cost per gbps. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From lists.nanog at monmotha.net Sat Mar 3 14:26:16 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 3 Mar 2018 09:26:16 -0500 Subject: Average number of ports on OLT cards In-Reply-To: <7b74405d-b2cd-fe7d-cfd8-8db608940996@vaxination.ca> References: <7b74405d-b2cd-fe7d-cfd8-8db608940996@vaxination.ca> Message-ID: <2eca5bbc-d8f2-4176-1f2b-b4a046acfcf3@monmotha.net> On 03/02/2018 05:38 PM, Jean-Francois Mezei wrote: > Quick question: (sanity check). > > For a deployment happening now by an incumbent telco (aka: serving large > number of homes), how many GPON ports would it want per each OLT card ? > > or more precisely, what sort of range is there for the number of ports > for such a deployment? I'm mostly seeing 8 or 16 ports per card for GPON these days. Chassis seem to be ranging from 4-16 slots of line cards (plus some other slots for management, uplink, etc.). EPON density seems comparable. XGS-PON and 10G-EPON seem to be 4-8 ports per card often in the same chassis with GPON/EPON. -- Brandon Martin From list-nanog at beufa.net Fri Mar 2 21:53:14 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Fri, 02 Mar 2018 22:53:14 +0100 Subject: BCP 38 addendum In-Reply-To: <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> Message-ID: <7fd80268f63624023f40153464f83e84@beufa.net> Le 2018-03-02 22:07, Barry Raveendran Greene a écrit : > Hi Todd, > > What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. Russ White and I worked on it while at Cisco. > > Given that you are setting up prefix filters with your peers, you can add to the peering agreement that you will only accept packets whose source addresses matches the prefixes sent. > > You then take that BGP session, feed that into a VRF on the interface, and run uRPF against that VRF. If a source address does not match, drop. > > If the BGP session adds more routes, those automatically update the VRF "white list" for the uRPF. > > It was build to scale. Not sure where it is at in the code or the hardware. Ask Cisco. > > Barry > > PS - So yes, you can do uRPF on your peering sessions. It was coded and deployed back in 2006. > > On Mar 1, 2018, at 13:57, Todd Crane wrote: > > Question: > Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers' networks. > > With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer's BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can't send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being. > > This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters. > > --Todd > > On Feb 28, 2018, at 6:52 PM, Job Snijders wrote: > > On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: On 2018-02-27, Ca By sent: Please do take a look at the cloudflare blog specifically as they > name and shame OVH and Digital Ocean for being the primary sources > of mega crap traffic > > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > Also, policer all UDP all the time... UDP is unsafe at any speed. > Hi, DigitalOcean here. We've taken steps to mitigate this attack on > our network. NTT too has deployed rate limiters on all external facing interfaces on the GIN backbone - for UDP/11211 traffic - to dampen the negative impact of open memcached instances on peers and customers. The toxic combination of 'one spoofed packet can yield multiple reponse packets' and 'one small packet can yield a very big response' makes the memcached UDP protocol a fine example of double trouble with potential for severe operational impact. Kind regards, Job Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;) -- FABIEN VINCENT _ at beufanet_ From list-nanog at beufa.net Fri Mar 2 22:20:57 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Fri, 02 Mar 2018 23:20:57 +0100 Subject: Peering with abusers...good or bad? In-Reply-To: References: Message-ID: Le 2018-03-02 23:11, Matthew Petach a écrit : > On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis wrote: > >> OVH does not suprise me in the least. >> >> Maybe this is finally what it will take to get people to de-peer them. > > If I de-peer them, I pay my upstream to carry the > attack traffic. > > If I maintain peering with them, the attack traffic is free. > > It would seem the economics work the other way around. > > It would be more cost effective for me to identify the largest sources > of attacks, and reach out to directly peer with them, to avoid paying > an upstream to carry the traffic, if I'm going to end up throwing it > away anyhow. We are always trying to reply asap on peering at ovh.net if it's network related (it's not abuse and I don't manage it ;). You're welcome to share anything wrong so we can mitigate attack with our own antiddos system, if automatic detection didn't catched it. We are obviously not responsible for the memcached issue, and we get the same type / volume of attacks than everyone on input. You should not have a one way thought, and think about network peering is done with at least 2 peers which have sometimes the same problem without any direct responsibility. -- FABIEN VINCENT _ at beufanet_ From code at joelwhitehouse.com Fri Mar 2 22:41:13 2018 From: code at joelwhitehouse.com (Joel Whitehouse) Date: Fri, 2 Mar 2018 16:41:13 -0600 Subject: IPv6 Unique Local Addresses In-Reply-To: References: Message-ID: On 03/02/2018 02:40 PM, Matthew Kaufman wrote: > Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN > is not. You want to discourage someone from doing the right thing, charge a > lot for that. > The ARIN fee schedule for an ASN and a /40 has an amortized annual cost approximately equal to a 2TB hard drive. Is that really too much to bear for a business running a critical network service? -- Joel Whitehouse From ldumont at fibrenoire.ca Sat Mar 3 23:51:24 2018 From: ldumont at fibrenoire.ca (Laurent Dumont) Date: Sat, 3 Mar 2018 18:51:24 -0500 Subject: XO - Memphis/Nasville - Circuit down 24 hours Message-ID: Hi everyone, This is a first for me but we have a circuit down for the past 24 hours in Memphis. We've escalated the issue as far as we could on the XO side but we've been stonewalled at every turn. I don't have anything agaisn't 3-6 hours outages as those have to be expected from time to time but 24 hours hard down is just a bit too crazy. If they would at least tell me if it's a fiber cut, I would understand but all they can tell me is that they see alarms. Anyone has seen anything like this before? Thank you From lists at benappy.com Fri Mar 2 21:48:56 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Fri, 2 Mar 2018 22:48:56 +0100 Subject: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks In-Reply-To: References: <20180228112842.GA30776@gsp.org> <20180228123111.GF5969@hanna.meerval.net> <49B9D6C8-5B0A-4C3F-AEC8-A943C63E0938@delong.com> <87efl24s06.fsf@miraculix.mork.no> Message-ID: <116CE456-9D02-432B-B213-C39E832A2D65@benappy.com> The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway unrelated to any client’s address space. Also, french triple play ISPs use RFC1918 space for IPTV but again isolated of any customer network so doesn’t really matter. > On 2 Mar 2018, at 22:18, K. Scott Helms wrote: > > I won't comment on the sanity of doing so, but _many_ service providers use > EMTAs, ATAs, and other voice devices over RFC1918 space back to their core. > From spike at zitomedia.net Sat Mar 3 13:50:06 2018 From: spike at zitomedia.net (daveb) Date: Sat, 03 Mar 2018 08:50:06 -0500 Subject: IPv6 Unique Local Addresses In-Reply-To: References: <1C331800-317F-4BD1-9C99-83DBF815E811@delong.com> <00436F32-C442-4FA6-B081-4E4025A7EC91@delong.com> Message-ID: <5a9aa810.c59d370a.61fa7.52fbSMTPIN_ADDED_MISSING@mx.google.com> At 02:02 AM 3/3/2018, Owen DeLong wrote: > > On Mar 2, 2018, at 10:38 PM, Matt Harris wrote: > > > > On Sat, Mar 3, 2018 at 12:33 AM, Owen DeLong > > wrote: > > Sure You have to maintain the tunnel or they > may reassign/reallocate the address. Here’s the reality of that, however: > > > > 1. Unless you care about reaching the > customer they reassigned it to from your network, you don’t care. > > 2. Using it for ULA in addition to the > tunnel isn’t really prohibited by that. It’s a gray area, I’ll admit. > > 3. Sure, they can cancel the service at > any time, but you get what you pay for. It saves you $100/year > > while it lasts. > > > > Owen > > > > I'm not sure where you're getting the $100 > figure from, ARIN's minimum fee for an > allocation is $250/year (for a /40 or smaller > block) on top of membership fees of $500/yr, so > that's $750/yr to get a /48 from the North > American RIR (which is the only one I'm looking > at today given that the context is the nanog > list). Additionally, tunnel providers can and > have shut down permanently at random - SixXS > was among the largest providers, and they shut > down operations entirely last year. So any > folks using space from them had to renumber, > either on to another tunnel provider's space, > or to ULA. Re-numbering has associated costs, > which in the case we're pointing to here, > could've been saved had they deployed on ULA space instead. > > > >You don’t need an allocation. Get an assignment. > >Owen Petition the RIR's (and IETF?) to set up a HE like service for 'micro' end-users? Self-registration and $4.99/year gets you a pseudo-GUA /48 to keep forever but currently understood as not accepted by your ISP. Some day maybe there will be an efficient way to provide global reachability. Dave B. From Brian at ampr.org Mon Mar 5 03:20:13 2018 From: Brian at ampr.org (Brian Kantor) Date: Sun, 4 Mar 2018 19:20:13 -0800 Subject: Contact info for AS1880 - STUPI.SE (Svensk Teleutveckling & Produktinnovation) Message-ID: <20180305032013.GA57904@meow.BKantor.net> Does anyone have contact info for the peering folks at AS1880, Svensk Teleutveckling & Produktinnovation in Sweden? They appear to be advertising a subnet of our network space without permission. Their WHOIS entry at RIPE does not list any contact email addresses. Any information would be appreciated. Off-list is fine. Thank you. - Brian From hugge at nordu.net Mon Mar 5 06:37:57 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Mon, 5 Mar 2018 07:37:57 +0100 Subject: Contact info for AS1880 - STUPI.SE (Svensk Teleutveckling & Produktinnovation) In-Reply-To: <20180305032013.GA57904@meow.BKantor.net> References: <20180305032013.GA57904@meow.BKantor.net> Message-ID: <6602663c-0cd8-91f8-4291-0ffd3077c35d@nordu.net> On 2018-03-05 04:20, Brian Kantor wrote: > Does anyone have contact info for the peering folks at > AS1880, Svensk Teleutveckling & Produktinnovation in Sweden? > > They appear to be advertising a subnet of our network > space without permission. Their WHOIS entry at RIPE does > not list any contact email addresses. > > Any information would be appreciated. Off-list is fine. > > Thank you. > - Brian > Thats Peter Lothbergs lab-asn. I turned on the bat-signal and put out the breadcrumbs - expect an answer shortly. I have limited commit in the network but is also one of the upstreams - feel free to send me the prefix offlist and ill make sure that atleast we dont transit the network. -- hugge @ 2603 From Brian at ampr.org Mon Mar 5 15:48:54 2018 From: Brian at ampr.org (Brian Kantor) Date: Mon, 5 Mar 2018 07:48:54 -0800 Subject: Contact info for AS1880 - STUPI.SE (Svensk Teleutveckling & Produktinnovation) In-Reply-To: <20180305032013.GA57904@meow.BKantor.net> References: <20180305032013.GA57904@meow.BKantor.net> Message-ID: <20180305154854.GA60732@meow.BKantor.net> Thank you all for your help. The matter has been satisfactorily resolved. - Brian On Sun, Mar 04, 2018 at 07:20:13PM -0800, Brian Kantor wrote: > Does anyone have contact info for the peering folks at > AS1880, Svensk Teleutveckling & Produktinnovation in Sweden? > > They appear to be advertising a subnet of our network > space without permission. Their WHOIS entry at RIPE does > not list any contact email addresses. > > Any information would be appreciated. Off-list is fine. > > Thank you. > - Brian From tspprmng at feec.vutbr.cz Mon Mar 5 08:54:39 2018 From: tspprmng at feec.vutbr.cz (IEEE Technically Co-Sponsored TSP 2018) Date: Mon, 5 Mar 2018 09:54:39 +0100 Subject: =?UTF-8?Q?TSP_2018_-_EXTENDED_DEADLINE:_March_13_=288_extra_days=29?= =?UTF-8?Q?_|_Athens=2c_Greece=2c_July_4-6=2c_2018_|_41st_Int._Conference_on?= =?UTF-8?Q?_Telecommunications_and_Signal_Processing_-_IEEE_Xplore=c2=ae_-_S?= =?UTF-8?Q?COPUS_-_Thomson_Reuters_ISI_Proceedings_-_DBLP_-_Google_Scholar?= Message-ID: <9564b7a6-3687-3c6f-c10f-726a7c03d32f@feec.vutbr.cz> *2018 41st International Conference on Telecommunications and Signal Processing (TSP) *July 4-6, 2018, Athens, Greece Web: http://tsp.vutbr.cz/ *Full Paper Submission*: March 13, 2018 (/extended deadline/) ************************************************************************************ Technically co-sponsored by *IEEE Region 8 (Europe, Middle East and Africa)*, *IEEE Greece Section*, *IEEE Czechoslovakia Section*, and *IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter*. The TSP 2018 Proceedings, containing presented papers at the Conference, will be submitted for indexing to the *IEEE Xplore® Digital Library* registered under /_IEEE Conference Record #43564_/, *SCOPUS*, *Conference Proceedings Citation Index (CPCI) of Thomson Reuters*, *DBLP*, and *Google Scholar databases*. Authors of the best rated and presented papers will be invited for publishing in special issues of international journals. ************************************************************************************ Dear Colleague, You are kindly invited to participate in the *2018 41st International Conference on Telecommunications and Signal Processing (TSP* - http://tsp.vutbr.cz/), which will be held on *July 4-6, 2018, inAthens, Greece*. The TSP Conference serves as a premier annual international forum to promote the exchange of the latest advances in telecommunication technology and signal processing. The aim of the Conference is to bring together both novice and experienced scientists, developers, and specialists, to meet new colleagues, collect new ideas, and establish new cooperation between research groups from universities, research centers, and private sectors from the whole Europe, America, Asia, Australia, and Africa. *INVITED KEYNOTE SPEAKERS: * We are glad to announce the following Keynote Speakers: - _Prof. Ozgur B. Akan, IEEE Fellow_ – Head of the Internet of Everything Group at the Department of Engineering, University of Cambridge, UK ... /Title: Internet of Everything – From Molecules to the Universe / - _Prof. Themis Prodromakis_ – Professor of Nanotechnology and Head of the Electronic Materials and Devices Research Group in the Zepler Institute, University of Southampton, UK ... /Title: Memristor-based Neuromorphic Computing Systems / *TOPICS: * TSP 2018 has opened *Call for Papers for Full Paper Submissions* with an /EXTENDED deadline set for March 13, 2018 (8 extra days)/. We look forward to your innovative contributions in any of the following areas: /AREA 1: Telecommunications / 1. Information Systems 2. Network Services 3. Network Technologies 4. Telecommunication Systems 5. Modelling, Simulation and Measurement /AREA 2: Signal Processing / 6. Analog Signal Processing 7. Audio, Speech and Language Processing 8. Biomedical Signal Processing 9. Digital Signal Processing 10. Image and Video Signal Processing For more details please visit the Conference website at http://tsp.vutbr.cz/?page_id=121 . *WORKSHOPS AND SPECIAL SESSIONS: * The following Workshops and Special Sessions will be organized during the Conference: - WS1: 2nd International Workshop on Recent Advances in Biometrics and its Applications organized by Assoc. Prof. Larbi Boubchir & Prof. Boubaker Daachi (both LIASD - University of Paris 8, France) - WS2: 8th SPLab Workshop of Signal Processing Laboratory organized by Prof. Zdenek Smekal, Assoc. Prof. Radim Burget, Dr. Jiri Mekyska, Assoc. Prof. Pavel Rajmic, Assoc. Prof. Kamil Riha, Assoc. Prof. Jiri Schimmel (all Brno University of Technology, Czech Republic) - SS1: Special Session on Signal Processing Techniques for Ground Penetrating Radar Applications (SPT4GPRA) organized by Prof. Dr. Francesco Benedetto, PhD (University of Roma Tre, Rome, Italy) and Dr. Fabio Tosti, PhD (University of West London (UWL), London, UK) - SS2: Special Session on Monitoring and Control Based on Image Processing organized by Prof.dr.ing. Dan Popescu and Dr. Loretta Ichim (both from the University POLITEHNICA of Bucharest, Romania) - SS3: Special Session on Photonic Networks and their Applications (Theory, Design, Modeling, Trials) organized by Dr. Josef Vojtech (CESNET a.l.e., Czech Republic) and Dr. Petr Munster (Brno University of Technology, Czech Republic) - SS4: Special Session on Multivariate Data Analysis and Knowledge Discovery – From Theory to Applications will be organized by Prof. Corneliu Burileanu and Dr. Anamaria Radoi (both with the University Politehnica of Bucharest, Romania) - SS5: Special Session on Robust Face and Emotion Recognition and Analysis will be organized by Ing. Dr. HDR. Hassene seddik – ENSIT, Tunisia, Dr. Zied Lachiri – ENIT, Tunisia, and Assoc. Prof. Nawres Khlifa – ISTMT, Tunisia Prospective Organizers are invited to submit LATE proposals for Workshops and Special Sessions held during the TSP 2018 Conference. Organizing guidelines are available at http://tsp.vutbr.cz/?page_id=3492 . *STUDENT BEST PAPER AWARD: * In cooperation with IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter, to recognize outstanding technical contributions by students, as evidenced by the quality of papers, their presentations, and their technical excellence, the authors of the Best 3 Student Papers will be awarded during the conference by the Technical Committee. The Best Student Paper Award consists in a Certificate of Appreciation Plaque and an IEEE Student or IEEE Graduate Student membership for 2019. *ORGANIZERS: * The TSP 2018 is IEEE technically co-sponsored Conference organized in cooperation with seventeen universities: - Brno University of Technology, Department of Telecommunications, Brno, Czech Republic - Budapest University of Technology and Economics, Department of Telecommunications and Media Informatics, Budapest, Hungary - Czech Technical University in Prague, Department of Telecommunication Engineering, Prague, Czech Republic - Isik University, Department of Electrical and Electronics Engineering, Sile/Istanbul, Turkey - Istanbul Technical University, Electronics and Communication Engineering Department, Istanbul, Turkey - Karadeniz Technical University, Department of Electrical and Electronics Engineering, Trabzon, Turkey - National Taiwan University of Science and Technology, Department of Electronic and Computer Engineering, Taipei, Taiwan - Seikei University, Graduate School and Faculty of Science and Technology, Information Networking Laboratory, Tokyo, Japan - Slovak University of Technology, Institute of Telecommunications, Bratislava, Slovak Republic - Tecnocampus, Escola Universitaria Politecnica de Mataro, Mataro, Spain - Technical University of Sofia, Faculty of Telecommunications, Sofia, Bulgaria - Universite Paris 8, UFR MITSIC, Laboratoire d'Informatique Avancee de Saint-Denis (LIASD), France - University of Ljubljana, Laboratory for Telecommunications, Ljubljana, Slovenia - University of Osijek, Faculty of Electrical Engineering, Computer Science and Information Technology Osijek, Osijek, Croatia - University of Patras, Physics Department, Patras, Greece - VSB - Technical University of Ostrava, Department of Telecommunications, Ostrava, Czech Republic - West Pomeranian University of Technology, Faculty of Electrical Engineering, Szczecin, Poland *COMMITTEES: * - Miloslav Filka, Brno University of Technology, Czech Republic - Full Professor, TSP Conference Founder - Honorary Chair - Norbert Herencsar, Brno University of Technology, Czech Republic - IEEE Czechoslovakia Section CAS/COM/SP Joint Chapter Chair, IEEE Senior Member - General Co-Chair - Costas Psychalinos, University of Patras, Greece - Full Professor, IEEE Senior Member - Jaroslav Koton, Brno University of Technology, Czech Republic, IEEE Senior Member - Publications Chair - Jiri Hosek, Brno University of Technology, Czech Republic, IEEE Member - Student Paper Contest Chair - Aslihan Kartci, Brno University of Technology, Czech Republic - Publicity & Social Media Chair - Nandor Matrai, Asszisztencia Congress Bureau, Hungary - Managing Director - Finance Chair - Csilla Fulop, Asszisztencia Congress Bureau, Hungary - Project Manager - Registrations Chair /Steering Committee: / - Larbi Boubchir, Universite Paris 8, France - Associate Professor, IEEE Senior Member - Marcos Faundez-Zanuy, Escola Universitaria Politecnica de Mataro, Tecnocampus, Spain - Dean - Izzet Cem Goknar, Isik University, Turkey - Institute of Science Director & Circuits and Systems (CAS) Society Turkey Chapter Chair, IEEE Life Fellow - Ray-Guang Cheng, National Taiwan University of Science and Technology (NTUST), Taiwan - Full Professor, IEEE Senior Member - Ismail Kaya, Karadeniz Technical University, Turkey - Sridhar Krishnan, Ryerson University, Canada - Associate Dean, IEEE Senior Member - Mario Kusek, University of Zagreb, Croatia, IEEE Member - IEEE Croatia Section Communications Chapter Chair - Antonio Luque, University of Seville, Spain - IEEE Region 8 Vice Chair Member Activities 2017, IEEE Spain Section Chair 2016-2017, IEEE Senior Member - Shahram Minaei, Dogus University, Turkey - Full Professor, IEEE Senior Member - Ram M. Narayanan, The Pennsylvania State University, USA - Full Professor, IEEE Fellow - Kimio Oguchi, Seikei University, Japan - Full Professor, IEEE Senior Member - Serdar Ozoguz, Istanbul Technical University, Turkey - Full Professor, Associate Chair - Jakub Peksinski, West Pomeranian University of Technology, Poland - Hector Perez-Meana, National Polytechnic Institute, Mexico - Full Professor, IEEE Senior Member - Vladimir Poulkov, Technical University of Sofia, Bulgaria - Dean, IEEE Senior Member - Markus Rupp, Vienna University of Technology, Austria - Dean, IEEE Fellow - Zdenek Smekal, Brno University of Technology, Czech Republic - Full Professor, IEEE Senior Member - Attila Vidacs, Budapest University of Technology and Economics, Hungary - Deputy Head of Department - Miroslav Voznak, VSB-Technical University of Ostrava, Czech Republic - Department Chair, IEEE Senior Member - Drago Zagar, University of Osijek, Croatia - Dean, IEEE Senior Member *IMPORTANT DATES: * *Full Paper Submission*: March 13, 2018 (/extended deadline/) *Notification of Paper Acceptance*: April 15, 2018 *Final Paper Submission*: April 30, 2018 *Authors' Early Registration and Payment*: May 10, 2018 *Authors' Late Registration and Payment*: May 20, 2018 *Listeners' Registration*: July 4, 2018 *Conference*: July 4-6, 2018 *CONTACTS: * For more information please visit the Conference website at http://tsp.vutbr.cz/. We are also ready to answer your questions emailed to tsp at feec.vutbr.cz. Looking forward to meeting you in Athens, Greece. With best regards, Norbert Herencsar and Costas Psychalinos TSP 2018 General Co-Chairs Web: http://tsp.vutbr.cz/ E-mail: tsp at feec.vutbr.cz Follow us on: - Facebook https://www.facebook.com/tspconf/ - Twitter https://twitter.com/tspconf/ =================================================== doc. Ing. Norbert Herencsar, Ph.D., IEEE Senior Member - IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter Chair Department of Telecommunications Faculty of Electrical Engineering and Communication Brno University of Technology Technicka 3082/12 616 00 Brno Czech Republic & Prof. Dr. Costas Psychalinos, IEEE Senior Member Physics Department University of Patras 26504 Rio Patras Greece ************************************************************************************ TSP Organizers reserve the right to exclude a paper from distribution after the Conference (e.g., non-indexing in IEEE Xplore® and other databases) if the paper is not presented at the Conference. However, this paper will be distributed as part of the Conference proceedings issued on an USB drive. ************************************************************************************ From rblayzor.bulk at inoc.net Tue Mar 6 15:37:28 2018 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 6 Mar 2018 10:37:28 -0500 Subject: NYC to Albany - Wavelength service Message-ID: Anyone know of any carriers offering DWDM wavelength paths between NYC and Albany, NY? (Not OTU2 or OTU4). Looking for carrier to carry color (alien wave). Please contact me off list. Thanks -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ From rubensk at gmail.com Tue Mar 6 17:51:44 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 6 Mar 2018 14:51:44 -0300 Subject: Nominum NS2 Reach Message-ID: Hi there. I found the available product information on NS2 Reach (Nominum) to not dive into real product behavior like if it requires every HTTP traffic to be PBR to the box, or possible deployment scenarios without intercepting all HTTP traffic. Anyone can shed a light on its workings, or point to a NetEng description of it ? Tks, Rubens From lists at as23738.net Tue Mar 6 18:23:10 2018 From: lists at as23738.net (lists at as23738.net) Date: Tue, 06 Mar 2018 10:23:10 -0800 Subject: Nominum NS2 Reach In-Reply-To: References: Message-ID: <1520360590.3177002.1293703712.66363527@webmail.messagingengine.com> I found this, if it helps. Reuploaded to imgur, since not sure if nanog-list takes attachments. https://i.imgur.com/waVW7zi.png On Tue, Mar 6, 2018, at 9:51 AM, Rubens Kuhl wrote: > Hi there. > > I found the available product information on NS2 Reach (Nominum) to not > dive into real product behavior like if it requires every HTTP traffic to > be PBR to the box, or possible deployment scenarios without intercepting > all HTTP traffic. > > Anyone can shed a light on its workings, or point to a NetEng description > of it ? > > > Tks, > Rubens From rubensk at gmail.com Tue Mar 6 19:10:51 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 6 Mar 2018 16:10:51 -0300 Subject: Nominum NS2 Reach In-Reply-To: <1520360590.3177002.1293703712.66363527@webmail.messagingengine.com> References: <1520360590.3177002.1293703712.66363527@webmail.messagingengine.com> Message-ID: Thanks for that. While it's still more into the "money is made here" arena, it actually confirm that it needs HTTP traffic. I wonder if they also suggest operators to redirect DNS traffic meant to other servers to them, hijacking all DNS traffic as well. Rubens On Tue, Mar 6, 2018 at 3:23 PM, wrote: > I found this, if it helps. Reuploaded to imgur, since not sure if > nanog-list takes attachments. > > https://i.imgur.com/waVW7zi.png > > On Tue, Mar 6, 2018, at 9:51 AM, Rubens Kuhl wrote: > > Hi there. > > > > I found the available product information on NS2 Reach (Nominum) to not > > dive into real product behavior like if it requires every HTTP traffic to > > be PBR to the box, or possible deployment scenarios without intercepting > > all HTTP traffic. > > > > Anyone can shed a light on its workings, or point to a NetEng description > > of it ? > > > > > > Tks, > > Rubens > From cboyd at gizmopartners.com Tue Mar 6 20:45:19 2018 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 6 Mar 2018 14:45:19 -0600 Subject: Someone from T-Mobile who can shake a ticket loose? Message-ID: <0075413A-EF1E-401E-B8AD-0A60F49ABCD9@gizmopartners.com> Sorry for using the white paging phone, but I have an IPv4 reachability ticket that I opened back in January that’s stuck in limbo. Ticket number is either 26088938 or 18444951. Users on T-Mobile data can’t reach services in 208.89.64.0/21, specifically 208.89.64.154. —Chris From amitchell at isipp.com Tue Mar 6 20:51:22 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 6 Mar 2018 13:51:22 -0700 Subject: Someone from T-Mobile who can shake a ticket loose? In-Reply-To: <0075413A-EF1E-401E-B8AD-0A60F49ABCD9@gizmopartners.com> References: <0075413A-EF1E-401E-B8AD-0A60F49ABCD9@gizmopartners.com> Message-ID: <843EA9E5-6C3D-49EF-B96E-7CC8184F0946@isipp.com> > > Sorry for using the white paging phone, but I have an IPv4 reachability ticket that I opened back in January that’s stuck in limbo. > > Ticket number is either 26088938 or 18444951. Users on T-Mobile data can’t reach services in 208.89.64.0/21, specifically 208.89.64.154. We have a T-mobile contact, would you like us to reach out to them on your behalf? If so, permission to include the above? Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance 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 Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From list-nanog at beufa.net Tue Mar 6 21:16:54 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Tue, 06 Mar 2018 22:16:54 +0100 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> <7fd80268f63624023f40153464f83e84@beufa.net> Message-ID: Le 2018-03-06 19:39, Barry Greene a écrit : >> On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) wrote: >> Hope one day the 3rd mode of uRPF will be something else than a plan ... >> uRPF is not very usefull when multi homed. And as far as I know, multi >> homed networks are increasing as fast as PNI development ;) > > This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling). Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;) In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf "A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP" That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? -- FABIEN VINCENT _ at beufanet_ From jamesl at mythostech.com Wed Mar 7 15:10:45 2018 From: jamesl at mythostech.com (James Laszko) Date: Wed, 7 Mar 2018 15:10:45 +0000 Subject: Zayo zColo Xcon Pricing Message-ID: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) Thanks! James Sent from my iPad From saku at ytti.fi Wed Mar 7 15:19:15 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 7 Mar 2018 17:19:15 +0200 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> <7fd80268f63624023f40153464f83e84@beufa.net> Message-ID: Hey, How would this work? ISP1--ISP2---ISP3 | | +-------ISP4-----+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4 ISP1 will receive traffic from ISP3 through ISP2, and that is not in the eBGP session, so prefix gets dropped. Internet is symmetric and people don't advertise consistently, so while maybe undesirable above stuff does happen. It's not obvious to me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use case does it address which is not addressed by existing tooling. There is much cheaper feature which has worked for decades which applies better to this problem. While you generate list of prefixes ISP2 COULD announce to you, that includes the prefix ISP3 is NOT announcing, but COULD. The same prefix-list you use for BGP announcements use in your ACL. On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG) wrote: > Le 2018-03-06 19:39, Barry Greene a écrit : > >>> On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) wrote: >>> Hope one day the 3rd mode of uRPF will be something else than a plan ... >>> uRPF is not very usefull when multi homed. And as far as I know, multi >>> homed networks are increasing as fast as PNI development ;) >> >> This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling). > > Yep, but saw only reference of it, but no real CLI implementation > (especially on Cisco), so I guess it's not a killer feature to sell > routers ;) > > In 2005 : > https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf > > "A third phase is currently under way that will create a way to have > strict enforcement of the uRPF check on individual ISP-ISP edges. Here, > external BGP (eBGP) peer sessions will send specific prefixes to a > dedicated Virtual routing and forwarding (VRF) table. This will allow > uRPF to query the VRF table that contains all the routes for that > specific eBGP peering session over the interface, thus verifying > (authorizing) the source addresses of packets matching the advertised > routes from the peered ISP" > > That's obviously not so sexy, but I guess the problem is on hardware > performance, as the prefer method should to have a look on BGP tables, > and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? > > -- > FABIEN VINCENT > _ at beufanet_ -- ++ytti From nanog at ics-il.net Wed Mar 7 15:27:51 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 7 Mar 2018 09:27:51 -0600 (CST) Subject: Zayo zColo Xcon Pricing In-Reply-To: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> Message-ID: <1847918127.6122.1520436468486.JavaMail.mhammett@ThunderFuck> Too much, whatever it is. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "James Laszko" To: "nanog" Sent: Wednesday, March 7, 2018 9:10:45 AM Subject: Zayo zColo Xcon Pricing One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) Thanks! James Sent from my iPad From merculiani at gmail.com Wed Mar 7 15:53:49 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Wed, 7 Mar 2018 09:53:49 -0600 Subject: Zayo zColo Xcon Pricing In-Reply-To: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> Message-ID: Depending on the location (x-conns carrier hotels are typically more expensive) I'd expect to pay anywhere from $100-$200 per month for copper. -Matt On Wed, Mar 7, 2018 at 9:10 AM, James Laszko wrote: > One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From Romeo.Czumbil at tierpoint.com Wed Mar 7 16:41:28 2018 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Wed, 7 Mar 2018 16:41:28 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> Message-ID: <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Wait till you ask for a disconnect. Then you get hit again for a hefty NRC -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko Sent: Wednesday, March 7, 2018 10:11 AM To: nanog Subject: Zayo zColo Xcon Pricing One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) Thanks! James Sent from my iPad From mel at beckman.org Wed Mar 7 16:55:32 2018 From: mel at beckman.org (Mel Beckman) Date: Wed, 7 Mar 2018 16:55:32 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: NRC? Do you mean ETC (early termination charge)? This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! I’ve been burned by this more than once. -mel > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil wrote: > > Wait till you ask for a disconnect. Then you get hit again for a hefty NRC > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > Sent: Wednesday, March 7, 2018 10:11 AM > To: nanog > Subject: Zayo zColo Xcon Pricing > > One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From clayton at MNSi.Net Wed Mar 7 17:04:26 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 07 Mar 2018 12:04:26 -0500 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: <1520442274_90785@surgemail.mnsi.net> Or the services you can only cancel once a year, may not give early notice of cancellation, and if you miss the window, you're on the hook another year. Any contract we do with our customers is always MCP - Minimum Contract Period with automatic month to month renewals at the end - unless we're buying the facility from another carrier, then we mirror their terms. Colo providers try to set it up so that the terms for all your different services with them expire on different intervals to try to make it impossible for you to ever cancel without lots of pain. At 11:55 AM 07/03/2018, Mel Beckman wrote: >NRC? Do you mean ETC (early termination charge)? > >This is a sore point with me in all telco >contracts. They want a one- or two-year term, or >even three, and in exchange give you a discount >on the installation and a tiny MRC reduction. >But if you cancel early, they demand full >payment for all the remaining months! I realize >that the contract is written this way, but why? >It doesn’t seem fair at all, and as a service >provider myself, I know this is actually a huge >unearned windfall for the provider. > >To make things worse, many providers subtly >plant an “auto-renew” clause in their >contracts. You miss canceling but the end of the >contract date, and BOOM, you’re on the hook for another two years! > > I’ve been burned by this more than once. > > -mel > > > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil > wrote: > > > > Wait till you ask for a disconnect. Then you get hit again for a hefty NRC > > > > > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > > Sent: Wednesday, March 7, 2018 10:11 AM > > To: nanog > > Subject: Zayo zColo Xcon Pricing > > > > One of our colo’s in San Diego was > purchased by Zayo recently and I requested a > new copper Ethernet xcon to be placed. After a > few days I received a quote from my new rep > quoting a MRC 3x what I’m currently paying > for existing xcon’s as well as a hefty NRC as > well. Anyone have any experience with this > kind of thing? Anyone care to share what an > average copper xcon, single floor, meet-me-room > to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > > > Thanks! > > > > James > > > > Sent from my iPad -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From aaron at wholesaleinternet.net Wed Mar 7 17:05:42 2018 From: aaron at wholesaleinternet.net (Aaron) Date: Wed, 7 Mar 2018 11:05:42 -0600 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: There are a couple reasons. You order service from me.  It costs me $X to build out that service.  I balance that against the value of your contract.  If you cancel early then my numbers may not work or I may lose money on the deal, or.... if I had to borrow money to do your build, then my bank is going to be angry when the value I told them I was getting for the build doesn't come through. Smaller providers may end up factoring your contract.  If that contract doesn't pay what they said it would they're liable for the balance of the factoring deal. On 3/7/2018 10:55 AM, Mel Beckman wrote: > NRC? Do you mean ETC (early termination charge)? > > This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. > > To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! > > I’ve been burned by this more than once. > > -mel > >> On Mar 7, 2018, at 8:41 AM, Romeo Czumbil wrote: >> >> Wait till you ask for a disconnect. Then you get hit again for a hefty NRC >> >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko >> Sent: Wednesday, March 7, 2018 10:11 AM >> To: nanog >> Subject: Zayo zColo Xcon Pricing >> >> One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) >> >> Thanks! >> >> James >> >> Sent from my iPad -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From nanog at ics-il.net Wed Mar 7 17:09:00 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 7 Mar 2018 11:09:00 -0600 (CST) Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: <219967191.6198.1520442538273.JavaMail.mhammett@ThunderFuck> I'm sure he means what he says. The cost to remove the cross connect when you're done with it. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" To: "Romeo Czumbil" Cc: "nanog" Sent: Wednesday, March 7, 2018 10:55:32 AM Subject: Re: Zayo zColo Xcon Pricing NRC? Do you mean ETC (early termination charge)? This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! I’ve been burned by this more than once. -mel > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil wrote: > > Wait till you ask for a disconnect. Then you get hit again for a hefty NRC > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > Sent: Wednesday, March 7, 2018 10:11 AM > To: nanog > Subject: Zayo zColo Xcon Pricing > > One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From jamesl at mythostech.com Wed Mar 7 17:18:05 2018 From: jamesl at mythostech.com (James Laszko) Date: Wed, 7 Mar 2018 17:18:05 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: <219967191.6198.1520442538273.JavaMail.mhammett@ThunderFuck> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <219967191.6198.1520442538273.JavaMail.mhammett@ThunderFuck> Message-ID: <8078ED370ADA824281219A7B5BADC39BB305BDF2@MBX023-W1-CA-4.exch023.domain.local> NRC = non-recurring fee - the setup fee. They are charging setup fee and monthly fees to run a piece of ethernet. The xcon fee monthly is 25% of the price of the ethernet service we're getting from the telco.... James -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Wednesday, March 7, 2018 9:09 AM Cc: nanog Subject: Re: Zayo zColo Xcon Pricing I'm sure he means what he says. The cost to remove the cross connect when you're done with it. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" To: "Romeo Czumbil" Cc: "nanog" Sent: Wednesday, March 7, 2018 10:55:32 AM Subject: Re: Zayo zColo Xcon Pricing NRC? Do you mean ETC (early termination charge)? This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! I’ve been burned by this more than once. -mel > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil wrote: > > Wait till you ask for a disconnect. Then you get hit again for a hefty NRC > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > Sent: Wednesday, March 7, 2018 10:11 AM > To: nanog > Subject: Zayo zColo Xcon Pricing > > One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From keiths at neilltech.com Wed Mar 7 17:20:35 2018 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 7 Mar 2018 17:20:35 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: <6EA05605-DD70-4E98-8F9A-AED18A01E17D@neilltech.com> In a previous life when I was on the other side of writing contracts and my boss demanded auto-renewals, I always told my customers to write me a cancellation letter when they signed the contract. The amazing thing was how few actually did it. On Mar 7, 2018, at 10:55 AM, Mel Beckman > wrote: NRC? Do you mean ETC (early termination charge)? This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! I’ve been burned by this more than once. -mel On Mar 7, 2018, at 8:41 AM, Romeo Czumbil > wrote: Wait till you ask for a disconnect. Then you get hit again for a hefty NRC -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko Sent: Wednesday, March 7, 2018 10:11 AM To: nanog > Subject: Zayo zColo Xcon Pricing One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) Thanks! James Sent from my iPad --- Keith Stokes [cid:71D8C5C8-00C4-4DF2-8EA2-9D534D8EB9A6 at neilltech.com] -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.tiff Type: image/tiff Size: 9582 bytes Desc: PastedGraphic-2.tiff URL: From tknchris at gmail.com Wed Mar 7 17:25:11 2018 From: tknchris at gmail.com (chris) Date: Wed, 7 Mar 2018 12:25:11 -0500 Subject: Zayo zColo Xcon Pricing In-Reply-To: <8078ED370ADA824281219A7B5BADC39BB305BDF2@MBX023-W1-CA-4.exch023.domain.local> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <219967191.6198.1520442538273.JavaMail.mhammett@ThunderFuck> <8078ED370ADA824281219A7B5BADC39BB305BDF2@MBX023-W1-CA-4.exch023.domain.local> Message-ID: reminds me of the days when you were forced to colo gear in the phone company's CO to get access to their cable plant and got gouged on power and the interconnection between the CO and then you had to buy your upstream connectivity from the ILEC a insane markup or for ptp to your closest pop :) not only did you pay a fortune for the privilege but then you had to wait 60-90 for the ILEC to "build" the circuit On Wed, Mar 7, 2018 at 12:18 PM, James Laszko wrote: > NRC = non-recurring fee - the setup fee. They are charging setup fee and > monthly fees to run a piece of ethernet. The xcon fee monthly is 25% of > the price of the ethernet service we're getting from the telco.... > > > James > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Wednesday, March 7, 2018 9:09 AM > Cc: nanog > Subject: Re: Zayo zColo Xcon Pricing > > I'm sure he means what he says. The cost to remove the cross connect when > you're done with it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Romeo Czumbil" > Cc: "nanog" > Sent: Wednesday, March 7, 2018 10:55:32 AM > Subject: Re: Zayo zColo Xcon Pricing > > NRC? Do you mean ETC (early termination charge)? > > This is a sore point with me in all telco contracts. They want a one- or > two-year term, or even three, and in exchange give you a discount on the > installation and a tiny MRC reduction. But if you cancel early, they demand > full payment for all the remaining months! I realize that the contract is > written this way, but why? It doesn’t seem fair at all, and as a service > provider myself, I know this is actually a huge unearned windfall for the > provider. > > To make things worse, many providers subtly plant an “auto-renew” clause > in their contracts. You miss canceling but the end of the contract date, > and BOOM, you’re on the hook for another two years! > > I’ve been burned by this more than once. > > -mel > > > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil > wrote: > > > > Wait till you ask for a disconnect. Then you get hit again for a hefty > NRC > > > > > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > > Sent: Wednesday, March 7, 2018 10:11 AM > > To: nanog > > Subject: Zayo zColo Xcon Pricing > > > > One of our colo’s in San Diego was purchased by Zayo recently and I > requested a new copper Ethernet xcon to be placed. After a few days I > received a quote from my new rep quoting a MRC 3x what I’m currently paying > for existing xcon’s as well as a hefty NRC as well. Anyone have any > experience with this kind of thing? Anyone care to share what an average > copper xcon, single floor, meet-me-room to cage, Ethernet from carrier > circuit costs? (This xcon is approx 30 feet..) > > > > Thanks! > > > > James > > > > Sent from my iPad > > > From paul at telcodata.us Wed Mar 7 17:41:52 2018 From: paul at telcodata.us (Paul Timmins) Date: Wed, 7 Mar 2018 12:41:52 -0500 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <219967191.6198.1520442538273.JavaMail.mhammett@ThunderFuck> <8078ED370ADA824281219A7B5BADC39BB305BDF2@MBX023-W1-CA-4.exch023.domain.local> Message-ID: <0476ccda-53d7-b82e-d459-d90a4225f7e5@telcodata.us> Those days are alive and well. And of course, it hasn't improved any. On 03/07/2018 12:25 PM, chris wrote: > reminds me of the days when you were forced to colo gear in the phone > company's CO to get access to their cable plant and got gouged on power and > the interconnection between the CO and then you had to buy your upstream > connectivity from the ILEC a insane markup or for ptp to your closest pop > :) not only did you pay a fortune for the privilege but then you had to > wait 60-90 for the ILEC to "build" the circuit > > On Wed, Mar 7, 2018 at 12:18 PM, James Laszko wrote: > >> NRC = non-recurring fee - the setup fee. They are charging setup fee and >> monthly fees to run a piece of ethernet. The xcon fee monthly is 25% of >> the price of the ethernet service we're getting from the telco.... >> >> >> James >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >> Sent: Wednesday, March 7, 2018 9:09 AM >> Cc: nanog >> Subject: Re: Zayo zColo Xcon Pricing >> >> I'm sure he means what he says. The cost to remove the cross connect when >> you're done with it. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Mel Beckman" >> To: "Romeo Czumbil" >> Cc: "nanog" >> Sent: Wednesday, March 7, 2018 10:55:32 AM >> Subject: Re: Zayo zColo Xcon Pricing >> >> NRC? Do you mean ETC (early termination charge)? >> >> This is a sore point with me in all telco contracts. They want a one- or >> two-year term, or even three, and in exchange give you a discount on the >> installation and a tiny MRC reduction. But if you cancel early, they demand >> full payment for all the remaining months! I realize that the contract is >> written this way, but why? It doesn’t seem fair at all, and as a service >> provider myself, I know this is actually a huge unearned windfall for the >> provider. >> >> To make things worse, many providers subtly plant an “auto-renew” clause >> in their contracts. You miss canceling but the end of the contract date, >> and BOOM, you’re on the hook for another two years! >> >> I’ve been burned by this more than once. >> >> -mel >> >>> On Mar 7, 2018, at 8:41 AM, Romeo Czumbil >> wrote: >>> Wait till you ask for a disconnect. Then you get hit again for a hefty >> NRC >>> >>> >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko >>> Sent: Wednesday, March 7, 2018 10:11 AM >>> To: nanog >>> Subject: Zayo zColo Xcon Pricing >>> >>> One of our colo’s in San Diego was purchased by Zayo recently and I >> requested a new copper Ethernet xcon to be placed. After a few days I >> received a quote from my new rep quoting a MRC 3x what I’m currently paying >> for existing xcon’s as well as a hefty NRC as well. Anyone have any >> experience with this kind of thing? Anyone care to share what an average >> copper xcon, single floor, meet-me-room to cage, Ethernet from carrier >> circuit costs? (This xcon is approx 30 feet..) >>> Thanks! >>> >>> James >>> >>> Sent from my iPad >> >> From Romeo.Czumbil at tierpoint.com Wed Mar 7 18:02:21 2018 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Wed, 7 Mar 2018 18:02:21 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> Message-ID: <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> Ohh no NRC. Reason = Somebody has to pull back the cables (aka cut the ends off) -----Original Message----- From: Mel Beckman [mailto:mel at beckman.org] Sent: Wednesday, March 7, 2018 11:56 AM To: Romeo Czumbil Cc: James Laszko ; nanog Subject: Re: Zayo zColo Xcon Pricing NRC? Do you mean ETC (early termination charge)? This is a sore point with me in all telco contracts. They want a one- or two-year term, or even three, and in exchange give you a discount on the installation and a tiny MRC reduction. But if you cancel early, they demand full payment for all the remaining months! I realize that the contract is written this way, but why? It doesn’t seem fair at all, and as a service provider myself, I know this is actually a huge unearned windfall for the provider. To make things worse, many providers subtly plant an “auto-renew” clause in their contracts. You miss canceling but the end of the contract date, and BOOM, you’re on the hook for another two years! I’ve been burned by this more than once. -mel > On Mar 7, 2018, at 8:41 AM, Romeo Czumbil wrote: > > Wait till you ask for a disconnect. Then you get hit again for a hefty NRC > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Laszko > Sent: Wednesday, March 7, 2018 10:11 AM > To: nanog > Subject: Zayo zColo Xcon Pricing > > One of our colo’s in San Diego was purchased by Zayo recently and I requested a new copper Ethernet xcon to be placed. After a few days I received a quote from my new rep quoting a MRC 3x what I’m currently paying for existing xcon’s as well as a hefty NRC as well. Anyone have any experience with this kind of thing? Anyone care to share what an average copper xcon, single floor, meet-me-room to cage, Ethernet from carrier circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From sethm at rollernet.us Wed Mar 7 18:17:01 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 7 Mar 2018 10:17:01 -0800 Subject: Zayo zColo Xcon Pricing In-Reply-To: <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> Message-ID: On 3/7/18 10:02 AM, Romeo Czumbil wrote: > Ohh no NRC. > Reason = Somebody has to pull back the cables (aka cut the ends off) > > You mean you're not supposed to let cables pile up indefinitely until they become an immovable tangled mass? From nanog at ics-il.net Wed Mar 7 18:31:42 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 7 Mar 2018 12:31:42 -0600 (CST) Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> Message-ID: <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Sure, but that's just a cost of doing business. There's not a line-item for cleaning the bathroom. Frankly, I don't know why there are trays full of hundreds of pairs instead of each cage having a patch panel and a 144 or some such trunk to another patch panel elsewhere. Seems like there's a lot of extra work being done. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Seth Mattinen" To: nanog at nanog.org Sent: Wednesday, March 7, 2018 12:17:01 PM Subject: Re: Zayo zColo Xcon Pricing On 3/7/18 10:02 AM, Romeo Czumbil wrote: > Ohh no NRC. > Reason = Somebody has to pull back the cables (aka cut the ends off) > > You mean you're not supposed to let cables pile up indefinitely until they become an immovable tangled mass? From telmnstr at 757.org Wed Mar 7 18:47:56 2018 From: telmnstr at 757.org (Ethan) Date: Wed, 7 Mar 2018 13:47:56 -0500 (EST) Subject: Zayo zColo Xcon Pricing In-Reply-To: <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Message-ID: > Frankly, I don't know why there are trays full of hundreds of pairs > instead of each cage having a patch panel and a 144 or some such trunk > to another patch panel elsewhere. Seems like there's a lot of extra work > being done. I have seen this in one facility. They just run 24 strand or whatever to patch panel in each customer cage. Then patch are done to those at the meet me room. When you exceed capacity they add another 24 strand. Seems smart (depending on cable cost and average utilization of the strands I suppose.) And of course you can get multiple feeds / entrances from them. -Ethan O'Toole From merculiani at gmail.com Wed Mar 7 18:51:03 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Wed, 7 Mar 2018 12:51:03 -0600 Subject: Zayo zColo Xcon Pricing In-Reply-To: <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Message-ID: Perhaps so, but if it's not charged at the end it would just be built into the MRC. Longer-term customers would end up paying substantially more. In some cases, it is more cost effective to install an entrance facility as you describe, but it's much more expensive than running individual x-conns as needed. Plus not everyone wants to go to the same place. The cost of an EF would be passed-through, making it far more expensive for the guy or gal who just needs a hand-full of x-conns. -Matt On Wed, Mar 7, 2018 at 12:31 PM, Mike Hammett wrote: > Sure, but that's just a cost of doing business. There's not a line-item for cleaning the bathroom. > > Frankly, I don't know why there are trays full of hundreds of pairs instead of each cage having a patch panel and a 144 or some such trunk to another patch panel elsewhere. Seems like there's a lot of extra work being done. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Seth Mattinen" > To: nanog at nanog.org > Sent: Wednesday, March 7, 2018 12:17:01 PM > Subject: Re: Zayo zColo Xcon Pricing > > On 3/7/18 10:02 AM, Romeo Czumbil wrote: >> Ohh no NRC. >> Reason = Somebody has to pull back the cables (aka cut the ends off) >> >> > > > You mean you're not supposed to let cables pile up indefinitely until > they become an immovable tangled mass? > From list at satchell.net Wed Mar 7 19:35:05 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 7 Mar 2018 11:35:05 -0800 Subject: Zayo zColo Xcon Pricing In-Reply-To: <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Message-ID: On 03/07/2018 10:31 AM, Mike Hammett wrote: > Frankly, I don't know why there are trays full of hundreds of pairs instead of each cage having a patch panel and a 144 or some such trunk to another patch panel elsewhere. Seems like there's a lot of extra work being done. Because it's a capital outlay up front, instead of a build-as-you-need-it with the capital investment spread over time. Ran into the money bug-a-boo when building a rack room -- the boss just didn't like the up-front cost. "We will use cable trays and run wire when we need it. Feh. From sethm at rollernet.us Wed Mar 7 19:50:59 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 7 Mar 2018 11:50:59 -0800 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Message-ID: <9520a851-a868-32e3-9219-1a80d6ef634f@rollernet.us> On 3/7/18 11:35 AM, Stephen Satchell wrote: > Because it's a capital outlay up front, instead of a > build-as-you-need-it with the capital investment spread over time. There's no cost if the customer is charged for it when they need it. From Romeo.Czumbil at tierpoint.com Wed Mar 7 22:13:13 2018 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Wed, 7 Mar 2018 22:13:13 +0000 Subject: Zayo zColo Xcon Pricing In-Reply-To: <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> <43dc17de0fe943ab81023102fc9af5f3@hwt01-ex01.tierpoint.net> <1729dfe99c2c4d6690c4e76fd0840121@hwt01-ex01.tierpoint.net> <765130551.6278.1520447499597.JavaMail.mhammett@ThunderFuck> Message-ID: Well the Westin POP and Netrality POPs model is the best in my opinion. You take your bundle to one central location and do the x-connects there. No need to pull single cables in the trays -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Wednesday, March 7, 2018 1:32 PM Cc: nanog at nanog.org Subject: Re: Zayo zColo Xcon Pricing Sure, but that's just a cost of doing business. There's not a line-item for cleaning the bathroom. Frankly, I don't know why there are trays full of hundreds of pairs instead of each cage having a patch panel and a 144 or some such trunk to another patch panel elsewhere. Seems like there's a lot of extra work being done. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Seth Mattinen" To: nanog at nanog.org Sent: Wednesday, March 7, 2018 12:17:01 PM Subject: Re: Zayo zColo Xcon Pricing On 3/7/18 10:02 AM, Romeo Czumbil wrote: > Ohh no NRC. > Reason = Somebody has to pull back the cables (aka cut the ends off) > > You mean you're not supposed to let cables pile up indefinitely until they become an immovable tangled mass? From saku at ytti.fi Wed Mar 7 23:12:11 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 8 Mar 2018 01:12:11 +0200 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> <7fd80268f63624023f40153464f83e84@beufa.net> Message-ID: Hey, > This is exactly my idea : why should I allowed uRPF passing traffic from > routes not learned on this port ?? Why if I have Cogent + Level3 and I > denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get > spoofed traffic from Level3 ranges over Cogent peering port ? That's just > silly this kind of mode doesn't exist in uRPF ... > > I'm aware it's due to hardware limitation, because uRPF look into FIB, not > BGP Table or RIB, but that could help denying spoofed traffic that comes > over transit tier 1 because the BCP38 to the downstreams are not in place, > or not automatic (I'm still thinking why Level3 as an IRR and do use it for > filtering downstreams ...) I'm not at all sure what you are trying to say, but in many platforms you can write 'hints' to HW based on BGP communities or AS PATH and then use these 'hints' in ACL. Simplified view could be that you're matching AS_PATH on ACL. However if I understood your scenario right, I don't think what you propose is fixing any spoofing issues in your scenario. Only antispooffing that makes sense towards your transit provider is dropping your own source addresses. Some vendors also support 'strict feasible' which is essentially RIB instead of FIB match (But technically obviously not RIB, it's just HW gets more information about 'feasible' paths). >> There is much cheaper feature which has worked for decades which >> applies better to this problem. While you generate list of prefixes >> ISP2 COULD announce to you, that includes the prefix ISP3 is NOT >> announcing, but COULD. The same prefix-list you use for BGP >> announcements use in your ACL. > > Yeah agreee, but not usable and programmable regarding huge upstreams values > (over 100, I know hw even for smaller values that will say "my ASIC is > limited man"). Similarly it's easy to find device which can't hold DFZ in FIB, but you wouldn't buy that device as your edge box. Usually the really cheap and dense boxes are not edge capable anyhow, due to poor control-plane protection, and all proper edge boxes have large ACLs, in what I view perfectly affordable prices from Juniper, Nokia, Huawei and Cisco. Maybe 20-30k for few 100GE and what have you, likely not significant 5 year TCO on the actual company wide bottom line. -- ++ytti From mike.lyon at gmail.com Thu Mar 8 03:19:51 2018 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 7 Mar 2018 19:19:51 -0800 Subject: Amazon peering peeps on the list? Message-ID: Anyone on the list from Amazon peering? Have sent multiple emails to peering at amazon.com over the past couple of weeks with no reply. Any help would be appreciated. Thank You, Mike -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From benno at NLnetLabs.nl Thu Mar 8 10:16:57 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Thu, 8 Mar 2018 11:16:57 +0100 Subject: 2nd call for presentations RIPE 76 Message-ID: Dear colleagues, Please note the approaching deadline of *11 March 2018* for RIPE 76 plenary programme submissions. You can find the CFP for RIPE 76 below or at https://ripe76.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe76.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 76 will take place from 14-18 May in Marseille, France. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *11 March 2018*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc at ripe.net. -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From clay584 at gmail.com Fri Mar 9 05:15:11 2018 From: clay584 at gmail.com (Clay Curtis) Date: Fri, 9 Mar 2018 00:15:11 -0500 Subject: Playstation Vue over IPv6 from Frontier Tampa Bay, FL Message-ID: Playstation Vue is basically unusable when viewing over IPv6 from Tampa Bay Frontier network. A little background first... Almost all traffic from my metro area (Tampa Bay, FL) routes to Miami first, and then continues on to the IPv4 Internet. Frontier does not have residential IPv6 yet, so I am tunneling to the Hurricane Electric Miami POP to get IPv6 connectivity. Point being, the tunneling does not really have an adverse affect on latency. That said, IPv4 streaming is great because I head down to Miami and jump right over to Akamai for the content. 1 4 ms 5 ms 5 ms 192.168.4.1 2 * 18 ms 6 ms 192.168.100.1 3 8 ms 6 ms 6 ms 47.199.160.1 4 8 ms 9 ms 7 ms 172.99.45.80 5 12 ms 13 ms 13 ms ae8---0.scr02.mias.fl.frontiernet.net [74.40.3.73] 6 13 ms 13 ms 13 ms ae1---0.cbr01.mias.fl.frontiernet.net [74.40.1.126] 7 12 ms 12 ms 12 ms lag-101.ear3.Miami2.Level3.net [4.15.156.29] 8 13 ms 13 ms 13 ms NTT-level3-80G.Miami.Level3.net [4.68.127.54] 9 14 ms 13 ms 13 ms ae-4.r05.miamfl02.us.bb.gin.ntt.net [129.250.3.40] 10 14 ms 14 ms 14 ms a204-2-178-194.deploy.akamaitechnologies.com [204.2.178.194] IPv6 on the other hand, goes down to Miami, up to Ashburn, and back to Miami. 1 clay584-1.tunnel.tserv12.mia1.ipv6.he.net (2001:470:4:4e5::1) 17.460 ms 17.231 ms 16.867 ms 2 10ge13-20.core1.mia1.he.net (2001:470:0:8c::1) 13.187 ms 13.446 ms 13.143 ms 3 100ge11-1.core1.atl1.he.net (2001:470:0:18d::1) 27.223 ms 31.532 ms 27.294 ms 4 100ge8-1.core1.ash1.he.net (2001:470:0:114::2) 45.364 ms 39.037 ms 38.893 ms 5 xe-0.equinix.asbnva01.us.bb.gin.ntt.net (2001:504:0:2::2914:1) 39.565 ms 39.485 ms 39.870 ms 6 ae-2.r23.asbnva02.us.bb.gin.ntt.net (2001:418:0:2000::115) 39.356 ms 39.249 ms 42.904 ms 7 ae-1.r20.miamfl02.us.bb.gin.ntt.net (2001:418:0:2000::f2) 64.380 ms 65.897 ms 64.124 ms 8 ae-1.r05.miamfl02.us.bb.gin.ntt.net (2001:418:0:2000::26a) 65.341 ms 65.324 ms 65.114 ms 9 ae-8.a00.miamfl02.us.bb.gin.ntt.net (2001:418:0:2000::166) 68.843 ms 68.839 ms 69.295 ms 10 2001:418:0:5000::929 (2001:418:0:5000::929) 135.368 ms 84.350 ms 219.402 ms 11 g2600-1403-0015-0000-0000-0000-48f7-f02b.deploy.static.akamaitechnologies.com (2600:1403:15::48f7:f02b) 68.629 ms 65.356 ms 65.352 ms >From what I can see it looks that Hurricane Electric only sees this prefix from Equinix and thus routes it up to Ashburn and back. I suppose there could be utilization issues along the path, but the path itself seems like it could be better and may improve streaming with PS Vue. Going halfway up the east coast just to come back to the same city (possibly the same facility) is not ideal. Is there anyone on list that can see if this can be improved? Thanks in advance, Clay From daniel at pyranah.com Wed Mar 7 15:43:42 2018 From: daniel at pyranah.com (Daniel Temple) Date: Wed, 7 Mar 2018 10:43:42 -0500 Subject: Google Message-ID: <000401d3b62b$125d4df0$3717e9d0$@pyranah.com> I'm having a problem with some Google services that seems to be related to our public IP block. Anyone have a contact there that could check the IP block against any sort of google black list? Thanks Daniel Temple WISP Administrator CMB Systems, Inc 92-1 Hwy 64 West Cashiers, NC 28717 Direct: 828-743-2470 ext.209 FAX: 828-743-3155 daniel at pyranah.com Confidentiality Notice This message is being sent by or on behalf of CMB Systems, Inc. It is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. From houdini+nanog at clanspum.net Thu Mar 8 01:26:02 2018 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Thu, 8 Mar 2018 01:26:02 +0000 Subject: Looking for a network abuse contact at CenturyLink Message-ID: <20180308012602.GF9729@clanspum.net> I know, it's a big place. I'd like to talk about something I'm seeing from your networks and see if you agree on what it could be. This includes legacy Qwest, CenturyTel, etc. I could list ASNs but it's kind of a long list, as you'd expect :) Thank you, and sorry for the noise. -- Bill Weiss From ian.mock at gmail.com Wed Mar 7 17:00:24 2018 From: ian.mock at gmail.com (Ian Mock) Date: Wed, 7 Mar 2018 11:00:24 -0600 Subject: Zayo zColo Xcon Pricing In-Reply-To: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> Message-ID: Everything is negotiable. NRC on a cross-connect is ridiculous. The cost to run should be made up with the amount they're charging monthly. I wouldn't pay more than $200/mo for copper. Ian Mock On Wed, Mar 7, 2018 at 9:10 AM, James Laszko wrote: > One of our colo’s in San Diego was purchased by Zayo recently and I > requested a new copper Ethernet xcon to be placed. After a few days I > received a quote from my new rep quoting a MRC 3x what I’m currently paying > for existing xcon’s as well as a hefty NRC as well. Anyone have any > experience with this kind of thing? Anyone care to share what an average > copper xcon, single floor, meet-me-room to cage, Ethernet from carrier > circuit costs? (This xcon is approx 30 feet..) > > Thanks! > > James > > Sent from my iPad From josephnelson at gmail.com Thu Mar 8 16:18:45 2018 From: josephnelson at gmail.com (Joe Nelson) Date: Thu, 8 Mar 2018 09:18:45 -0700 Subject: Amazon peering peeps on the list? In-Reply-To: References: Message-ID: I've all but given up on trying to get a response from peering at amazon.com. If you do end up getting a contact, please share. On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon wrote: > Anyone on the list from Amazon peering? Have sent multiple emails to > peering at amazon.com over the past couple of weeks with no reply. > > Any help would be appreciated. > > Thank You, > Mike > > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > From list-nanog at beufa.net Wed Mar 7 19:56:53 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Wed, 07 Mar 2018 20:56:53 +0100 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> <7fd80268f63624023f40153464f83e84@beufa.net> Message-ID: Le 2018-03-07 16:19, Saku Ytti a écrit : > Hey, > > How would this work? > > ISP1--ISP2---ISP3 > | | > +-------ISP4-----+ > > In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects > to ISP2, ISP4 > > - ISP3 receives ISP1 prefixes via ISP[24] > - ISP3 advertises its prefix out via ISP4 > > ISP1 will receive traffic from ISP3 through ISP2, and that is not in > the eBGP session, so prefix gets dropped. > > Internet is symmetric and people don't advertise consistently, so > while maybe undesirable above stuff does happen. It's not obvious to > me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use > case does it address which is not addressed by existing tooling. Internet is not symmetric ;) My problem is more simple : I'm multihomed, so I cannot use uRPF strict mode, because my traffic is not symetric. Prepend can help, but that obviously not the way of doing TE for inbound traffic, expect if you love crappy design or you multihomed is just under 10 peerings. Loose mode is not useful, because of so many parameters, default route, local-pref / med inside the network, which lead to asymetrical path. So routes not inserted in FIB. So uRPF strict mode not possible. But in loose mode, because even Tier1 are not doing any BCP 38 filters (tested and verified for all least 3 Tier1), ACL or prefix list (that's not the point of BGP hijack here), I received UDP spoofed traffic from routes I don't learned on this port. By in case my router has 2 ports, one with Level3, one with Cogent, uRPF loose mode will look at the FIB (so for all ports), not one where the packet is coming from and the BGP table facing this port + BGP table. This is exactly my idea : why should I allowed uRPF passing traffic from routes not learned on this port ?? Why if I have Cogent + Level3 and I denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get spoofed traffic from Level3 ranges over Cogent peering port ? That's just silly this kind of mode doesn't exist in uRPF ... I'm aware it's due to hardware limitation, because uRPF look into FIB, not BGP Table or RIB, but that could help denying spoofed traffic that comes over transit tier 1 because the BCP38 to the downstreams are not in place, or not automatic (I'm still thinking why Level3 as an IRR and do use it for filtering downstreams ...) > > There is much cheaper feature which has worked for decades which > applies better to this problem. While you generate list of prefixes > ISP2 COULD announce to you, that includes the prefix ISP3 is NOT > announcing, but COULD. The same prefix-list you use for BGP > announcements use in your ACL. Yeah agreee, but not usable and programmable regarding huge upstreams values (over 100, I know hw even for smaller values that will say "my ASIC is limited man"). > > On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG) > wrote: Le 2018-03-06 19:39, Barry Greene a écrit : > > On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) > wrote: > Hope one day the 3rd mode of uRPF will be something else than a plan > ... > uRPF is not very usefull when multi homed. And as far as I know, multi > homed networks are increasing as fast as PNI development ;) > This was working microcode code when I left in 2008. Several operators > tested, but none deployed (no pushing or pulling). Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;) In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf "A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP" That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? -- FABIEN VINCENT _ at beufanet_ -- FABIEN VINCENT _ at beufanet_ From jason.w.kuehl at gmail.com Fri Mar 9 14:14:58 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Fri, 9 Mar 2018 09:14:58 -0500 Subject: Amazon peering peeps on the list? In-Reply-To: References: Message-ID: The better way to go ahead and get a hold of Amazon for peering issues is to open a ticket with them via AWS account with business support. This is how I resolved issues with peering in the past. On Mar 9, 2018 8:27 AM, "Joe Nelson" wrote: > I've all but given up on trying to get a response from peering at amazon.com. > If you do end up getting a contact, please share. > > On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon wrote: > > > Anyone on the list from Amazon peering? Have sent multiple emails to > > peering at amazon.com over the past couple of weeks with no reply. > > > > Any help would be appreciated. > > > > Thank You, > > Mike > > > > > > -- > > Mike Lyon > > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > From cscora at apnic.net Fri Mar 9 18:03:24 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Mar 2018 04:03:24 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180309180324.875E3102F3@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, IRNOG 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 10 Mar, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 689505 Prefixes after maximum aggregation (per Origin AS): 267381 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 332013 Total ASes present in the Internet Routing Table: 60061 Prefixes per ASN: 11.48 Origin-only ASes present in the Internet Routing Table: 51878 Origin ASes announcing only one prefix: 22755 Transit ASes present in the Internet Routing Table: 8183 Transit-only ASes present in the Internet Routing Table: 255 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 37 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 61 Number of instances of unregistered ASNs: 61 Number of 32-bit ASNs allocated by the RIRs: 21745 Number of 32-bit ASNs visible in the Routing Table: 17492 Prefixes from 32-bit ASNs in the Routing Table: 72632 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 329 Number of addresses announced to Internet: 2855882594 Equivalent to 170 /8s, 57 /16s and 79 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 229062 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 189556 Total APNIC prefixes after maximum aggregation: 54236 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 188509 Unique aggregates announced from the APNIC address blocks: 77335 APNIC Region origin ASes present in the Internet Routing Table: 8697 APNIC Prefixes per ASN: 21.68 APNIC Region origin ASes announcing only one prefix: 2465 APNIC Region transit ASes present in the Internet Routing Table: 1285 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3609 Number of APNIC addresses announced to Internet: 767978658 Equivalent to 45 /8s, 198 /16s and 108 /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-137529 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: 205495 Total ARIN prefixes after maximum aggregation: 98454 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206400 Unique aggregates announced from the ARIN address blocks: 97400 ARIN Region origin ASes present in the Internet Routing Table: 18111 ARIN Prefixes per ASN: 11.40 ARIN Region origin ASes announcing only one prefix: 6713 ARIN Region transit ASes present in the Internet Routing Table: 1803 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2316 Number of ARIN addresses announced to Internet: 1104738912 Equivalent to 65 /8s, 216 /16s and 250 /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-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 187081 Total RIPE prefixes after maximum aggregation: 91044 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 183286 Unique aggregates announced from the RIPE address blocks: 109499 RIPE Region origin ASes present in the Internet Routing Table: 24958 RIPE Prefixes per ASN: 7.34 RIPE Region origin ASes announcing only one prefix: 11332 RIPE Region transit ASes present in the Internet Routing Table: 3497 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6747 Number of RIPE addresses announced to Internet: 714623104 Equivalent to 42 /8s, 152 /16s and 72 /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-207259 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: 88834 Total LACNIC prefixes after maximum aggregation: 19593 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 90204 Unique aggregates announced from the LACNIC address blocks: 40049 LACNIC Region origin ASes present in the Internet Routing Table: 6889 LACNIC Prefixes per ASN: 13.09 LACNIC Region origin ASes announcing only one prefix: 1879 LACNIC Region transit ASes present in the Internet Routing Table: 1267 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 37 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4422 Number of LACNIC addresses announced to Internet: 172158944 Equivalent to 10 /8s, 66 /16s and 239 /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: 18476 Total AfriNIC prefixes after maximum aggregation: 4005 AfriNIC Deaggregation factor: 4.61 Prefixes being announced from the AfriNIC address blocks: 20777 Unique aggregates announced from the AfriNIC address blocks: 7466 AfriNIC Region origin ASes present in the Internet Routing Table: 1123 AfriNIC Prefixes per ASN: 18.50 AfriNIC Region origin ASes announcing only one prefix: 365 AfriNIC Region transit ASes present in the Internet Routing Table: 227 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 398 Number of AfriNIC addresses announced to Internet: 95974144 Equivalent to 5 /8s, 184 /16s and 115 /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 5420 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3962 405 400 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2858 11132 776 KIXS-AS-KR Korea Telecom, KR 9829 2802 1499 540 BSNL-NIB National Internet Backbone, IN 7552 2667 1161 59 VIETEL-AS-AP Viettel Group, VN 9394 2630 4923 29 CTTNET China TieTong Telecommunications 45899 2530 1561 159 VNPT-AS-VN VNPT Corp, VN 17974 2331 930 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2179 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2086 417 215 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 3364 1323 86 SHAW - Shaw Communications Inc., CA 22773 3278 2988 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2094 2483 435 CHARTER-NET-HKY-NC - Charter Communicat 16509 2037 4372 605 AMAZON-02 - Amazon.com, Inc., US 30036 1932 338 189 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1929 5055 618 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6389 1776 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 11492 1750 228 577 CABLEONE - CABLE ONE, INC., US 7018 1682 20187 1248 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 12479 3447 1397 785 UNI2-AS, ES 20940 2821 820 2054 AKAMAI-ASN1, US 8551 2101 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2036 1864 704 ROSTELECOM-AS, RU 34984 1997 332 479 TELLCOM-AS, TR 9121 1926 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1210 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 4313 3386 588 Uninet S.A. de C.V., MX 10620 3599 541 252 Telmex Colombia S.A., CO 11830 2642 370 66 Instituto Costarricense de Electricidad 6503 1631 437 53 Axtel, S.A.B. de C.V., MX 7303 1505 1025 198 Telecom Argentina S.A., AR 28573 1022 2246 194 CLARO S.A., BR 6147 1017 377 27 Telefonica del Peru S.A.A., PE 3816 1006 506 120 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 925 126 85 Alestra, S. de R.L. de C.V., MX 18881 907 1072 29 TELEF�NICA BRASIL S.A, BR 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 1168 398 50 LINKdotNET-AS, EG 37611 813 91 8 Afrihost, ZA 36903 737 370 139 MT-MPLS, MA 36992 683 1380 38 ETISALAT-MISR, EG 8452 615 1730 18 TE-AS TE-AS, EG 24835 602 850 15 RAYA-AS, EG 29571 466 68 12 ORANGE-COTE-IVOIRE, CI 37492 444 376 80 ORANGE-, TN 15399 361 35 7 WANANCHI-, KE 37342 360 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5420 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4313 3386 588 Uninet S.A. de C.V., MX 7545 3962 405 400 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3599 541 252 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 12479 3447 1397 785 UNI2-AS, ES 6327 3364 1323 86 SHAW - Shaw Communications Inc., CA 22773 3278 2988 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2858 11132 776 KIXS-AS-KR Korea Telecom, KR 20940 2821 820 2054 AKAMAI-ASN1, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4313 3725 Uninet S.A. de C.V., MX 7545 3962 3562 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3599 3347 Telmex Colombia S.A., CO 6327 3364 3278 SHAW - Shaw Communications Inc., CA 22773 3278 3130 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 12479 3447 2662 UNI2-AS, ES 7552 2667 2608 VIETEL-AS-AP Viettel Group, VN 9394 2630 2601 CTTNET China TieTong Telecommunications Corpora 11830 2642 2576 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.92.0/24 65001 -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 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 37.44.224.0/20 48666 AS-MAROSNET Moscow, Russia, RU 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 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:14 /9:11 /10:37 /11:100 /12:289 /13:563 /14:1094 /15:1898 /16:13320 /17:7834 /18:13573 /19:25192 /20:39115 /21:45117 /22:85179 /23:69049 /24:384896 /25:837 /26:599 /27:654 /28:36 /29:20 /30:17 /31:4 /32:57 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3155 3364 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2534 3278 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 12479 2246 3447 UNI2-AS, ES 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2642 Instituto Costarricense de Electricidad y Telec 30036 1687 1932 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1599 3599 Telmex Colombia S.A., CO 8551 1564 2101 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1531 1750 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1567 2:829 4:19 5:2801 6:59 7:1 8:1104 9:1 12:1883 13:207 14:1752 15:26 16:3 17:188 18:68 20:48 21:2 23:2558 24:2176 25:2 27:2304 31:1940 32:89 35:25 36:502 37:2700 38:1458 39:247 40:103 41:3044 42:548 43:1946 44:98 45:3853 46:3046 47:199 49:1354 50:1045 51:48 52:982 54:356 55:5 56:10 57:41 58:1576 59:1019 60:428 61:2142 62:1803 63:1803 64:4708 65:2223 66:4572 67:2358 68:1172 69:3199 70:1183 71:556 72:2101 74:2674 75:410 76:426 77:1541 78:1668 79:1856 80:1488 81:1442 82:1076 83:775 84:1020 85:2038 86:575 87:1267 88:915 89:2315 90:194 91:6284 92:1195 93:2370 94:2386 95:2742 96:656 97:356 98:927 99:124 100:79 101:1426 102:28 103:17255 104:3286 105:221 106:588 107:1799 108:706 109:2702 110:1579 111:1777 112:1329 113:1377 114:1113 115:1649 116:1648 117:1721 118:2173 119:1674 120:967 121:1070 122:2464 123:1820 124:1458 125:1876 128:975 129:618 130:443 131:1586 132:653 133:194 134:996 135:225 136:440 137:495 138:1941 139:572 140:418 141:686 142:787 143:964 144:798 145:453 146:1161 147:740 148:1546 149:700 150:740 151:1045 152:755 153:308 154:1038 155:760 156:850 157:777 158:624 159:1632 160:884 161:745 162:2572 163:527 164:1258 165:1396 166:398 167:1412 168:3045 169:808 170:3707 171:418 172:1058 173:1927 174:879 175:747 176:1866 177:3975 178:2419 179:1185 180:2243 181:2171 182:2462 183:1132 184:907 185:12812 186:3481 187:2299 188:2709 189:1976 190:8114 191:1415 192:9777 193:5879 194:4778 195:3974 196:2450 197:1444 198:5521 199:5880 200:7383 201:5006 202:10378 203:10110 204:4540 205:2846 206:3070 207:3177 208:3993 209:3933 210:4032 211:2118 212:3008 213:2687 214:907 215:61 216:5837 217:2126 218:899 219:621 220:1733 221:996 222:1045 223:1235 End of report From nanog at shankland.org Fri Mar 9 18:21:56 2018 From: nanog at shankland.org (Jim Shankland) Date: Fri, 9 Mar 2018 10:21:56 -0800 Subject: Zayo zColo Xcon Pricing In-Reply-To: References: <58D7B2E6-B6A0-48FF-A02E-0C6A05C890D2@mythostech.com> Message-ID: On 3/7/18 9:00 AM, Ian Mock wrote: > Everything is negotiable. NRC on a cross-connect is ridiculous. The cost to > run should be made up with the amount they're charging monthly. I wouldn't > pay more than $200/mo for copper. > Actually, as a reflection of the provider's cost, NRC for a cross-connect makes more sense than a recurring cost. After all, there's labor involved in setting up the cross-connect, but once it's in, it pretty much just sits there. The fallacy here, though, is assuming that rational pricing bears some relation to the vendor's cost to provide the good or service. Actual price is based on what the market will bear. Sharing pricing information on NANOG likely helps consumers by increasing market transparency (which is why vendors love to block such sharing via NDA). Much as I sympathize with the sentiment, though, "ridiculous" is meaningless in this context. It may even be construed as positive, as in: "Awesome, we're making ridiculous profits on all these copper cross-connects." :-) Jim From cgrundemann at gmail.com Fri Mar 9 20:18:17 2018 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 9 Mar 2018 15:18:17 -0500 Subject: MANRS IXP Webinar: Tuesday, 13 March Message-ID: Hail NANOGers! If you operate an IX in North America, this message is for you. (I'm passing it along on behalf of my former colleagues at the Internet Society.) Hope to "see" you on the webinar this Tuesday! ——— Hi, The MANRS IXP Partnership program is designed to invite and encourage participation of IXPs in MANRS (Mutually Agreed Norms for Routing Security). In accordance with the principles of the initiative, the membership depends on the visible commitment to improve the routing security of the peering fabric and Internet infrastructure in general and demonstrated by the implementation of defined Actions. The Internet Society is looking for leading IXPs around the world that have a track record in contributing to routing security, already implement the majority of Actions and are willing to participate in the launch of this program, planned in early 2018. The set of Actions was developed by the development team consisting of IXP representatives around the world. It has been reviewed in by various IXP communities, such as EURO-IX, LAC-IX, Af-IX. I’d like to invite you to participate in a webinar on March 13 at 14:00 EDT (18:00 UTC) where we present the IXP Partnership Program and the Actions to the North-American IXP community and invite your feedback. Call details are below. We would also ask you to disseminate the information about the webinar to the NA IX community. MANRS (https://www.manrs.org) is a collaborative initiative, coordinated by the Internet Society. It was launched in November 2014 and has received much encouragement from all sections of the Internet industry. The key objective of MANRS is to gain industry-wide agreement on a minimum set of practices for secure routing across the Internet, through coordinated action by many parties. MANRS was designed for network operators, but other parties can play an important role in facilitating improvements in routing security such as Internet Exchange Points (IXPs). Many of them represent active communities with common operational objectives and already contribute to a more resilient and secure Internet infrastructure. Thanks! Mark Buell Regional Bureau Director, North America Internet Society Details: Topic: MANRS and IXPs Time: Mar 13, 2018 7:00 PM Amsterdam, Berlin, Rome, Stockholm, Vienna Join from PC, Mac, Linux, iOS or Android: https://isoc.zoom.us/j/288357813 Or iPhone one-tap : US: +16699006833,,288357813# or +16465588656,,288357813# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 558 8656 Meeting ID: 288 357 813 International numbers available: https://isoc.zoom. us/zoomconference?m=WXysPTqEpKm5ELZq6evhxxHUX43prdSf -- @ChrisGrundemann http://chrisgrundemann.com From cvuljanic at gmail.com Sat Mar 10 00:46:17 2018 From: cvuljanic at gmail.com (Craig) Date: Sat, 10 Mar 2018 00:46:17 +0000 Subject: Amazon peering peeps on the list? In-Reply-To: References: Message-ID: We had to do the same, a ticket and issue moved along quickly and a CO- worker had the peers up quickly. On Fri, Mar 9, 2018 at 9:16 AM Jason Kuehl wrote: > The better way to go ahead and get a hold of Amazon for peering issues is > to open a ticket with them via AWS account with business support. > > This is how I resolved issues with peering in the past. > > On Mar 9, 2018 8:27 AM, "Joe Nelson" wrote: > > > I've all but given up on trying to get a response from > peering at amazon.com. > > If you do end up getting a contact, please share. > > > > On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon wrote: > > > > > Anyone on the list from Amazon peering? Have sent multiple emails to > > > peering at amazon.com over the past couple of weeks with no reply. > > > > > > Any help would be appreciated. > > > > > > Thank You, > > > Mike > > > > > > > > > -- > > > Mike Lyon > > > mike.lyon at gmail.com > > > http://www.linkedin.com/in/mlyon > > > > > > From nanog at ics-il.net Sat Mar 10 16:26:32 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 10 Mar 2018 10:26:32 -0600 (CST) Subject: Amazon peering peeps on the list? In-Reply-To: References: Message-ID: <854681485.324.1520699188570.JavaMail.mhammett@ThunderFuck> *nods* I had a positive conversation with them at a NANOG and one follow-up e-mail, but their peering@ has largely been /dev/null. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joe Nelson" Cc: "NANOG" Sent: Thursday, March 8, 2018 10:18:45 AM Subject: Re: Amazon peering peeps on the list? I've all but given up on trying to get a response from peering at amazon.com. If you do end up getting a contact, please share. On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon wrote: > Anyone on the list from Amazon peering? Have sent multiple emails to > peering at amazon.com over the past couple of weeks with no reply. > > Any help would be appreciated. > > Thank You, > Mike > > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > From tnolen at internetpro.net Fri Mar 9 21:23:27 2018 From: tnolen at internetpro.net (Trey Nolen) Date: Fri, 9 Mar 2018 15:23:27 -0600 Subject: problems sending to prodigy.net hosted email Message-ID: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> We are having issues with domains hosted on prodigy.net email servers including att.net, bellsouth.net, and scbglobal.net. We are being rejected for bad reverse DNS, but DNS is setup correctly.  The error we are receiving is: Remote host said: 550 5.7.1 Connections not accepted from servers without a valid sender domain.flph829 Fix reverse DNS for 74.252.14.252 I leave it up to the reader to test the validity of 74.252.14.252, but every test we've done looks good. The MX records for these domains indicate this (identical on the three domains mentioned above): ;; ANSWER SECTION: att.net.        175    IN    MX    5 al-ip4-mx-vip1.prodigy.net. att.net.        175    IN    MX    5 ff-ip4-mx-vip2.prodigy.net. att.net.        175    IN    MX    5 ff-ip4-mx-vip1.prodigy.net. att.net.        175    IN    MX    5 al-ip4-mx-vip2.prodigy.net. Everything we can find on the postmaster pages, forums, etc. point to emailing abuse_rbl at abuse-att.net.  We have done this and received their autoresponder.  We've waited the requisite 48 hours and emailed again for an escalation only to receive another autoresponder with another ticket number attached (even though we emailed with a ticket number in the message).    This has now been ongoing since at least March 4, when we received our first complaint and we have yet to hear anything from AT&T.   We don't currently have any direct contacts for Prodigy.net. I will say that the 75.252.14.0/24 netblock is owned by AT&T and I'm wondering if that might be causing the issue.  For instance, they are trying to do a local lookup of the PTR record instead of contacting the delegated servers. I'm hoping someone here has a point of contact which I might reach out to in order to correct this issue.  Any help would be appreciated. Trey Nolen From joe at nethead.com Fri Mar 9 21:35:20 2018 From: joe at nethead.com (Joe Hamelin) Date: Fri, 9 Mar 2018 13:35:20 -0800 Subject: Amazon peering peeps on the list? In-Reply-To: References: Message-ID: On Mar 9, 2018 8:27 AM, "Joe Nelson" wrote: > I've all but given up on trying to get a response from peering at amazon.com. Heh, that was me 17 years ago. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 > From baldur.norddahl at gmail.com Sun Mar 11 21:25:42 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 11 Mar 2018 22:25:42 +0100 Subject: BCP 38 addendum In-Reply-To: References: <20180227215253.GA694@piranha.2bit.co> <20180301015247.GA6721@vurt.meerval.net> <675F2CEB-B9AC-40C5-A1F6-389531DEE14C@senki.org> <7fd80268f63624023f40153464f83e84@beufa.net> Message-ID: I have a router that takes a long time to converge after reboot. To fix that I do not want to advertise my prefixes until the router is fully ready. But I still want to establish the BGP sessions otherwise the router will never be ready. So we program in a delay until advertising after BGP session established. Now if my peers automatically converted BGP announced prefixes into ACLs, they would blackhole any traffic that might come to this router during startup. This is obviously not good. BGP announced prefixes tells you what I can receive but not what I can send. Interpreting that any other way is abusing the protocol. You would need a new BGP extension so we could announce what we might send independent of what we want to receive. IRR generated ACL filters might work if agreeable by the peer. Regards Baldur From list at satchell.net Sun Mar 11 22:57:32 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 11 Mar 2018 15:57:32 -0700 Subject: problems sending to prodigy.net hosted email In-Reply-To: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> References: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> Message-ID: <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> On 03/09/2018 01:23 PM, Trey Nolen wrote: > We are having issues with domains hosted on prodigy.net email servers > including att.net, bellsouth.net, and scbglobal.net. > > We are being rejected for bad reverse DNS, but DNS is setup correctly. > The error we are receiving is: > Remote host said: 550 5.7.1 Connections not accepted from servers > without a valid sender domain.flph829 Fix reverse DNS for 74.252.14.252 > > I leave it up to the reader to test the validity of 74.252.14.252, but > every test we've done looks good. > > > The MX records for these domains indicate this (identical on the three > domains mentioned above): > ;; ANSWER SECTION: > att.net.        175    IN    MX    5 al-ip4-mx-vip1.prodigy.net. > att.net.        175    IN    MX    5 ff-ip4-mx-vip2.prodigy.net. > att.net.        175    IN    MX    5 ff-ip4-mx-vip1.prodigy.net. > att.net.        175    IN    MX    5 al-ip4-mx-vip2.prodigy.net. (Cavaet: it's been a long, LONG time since I have sent ANY mail to prodigy.net, att.net, bellsouth.net, or sbcglobal.net. So I don't have any advice specific to sending mail to servers hosting domains on those services. Rather, I've concentrated on what I understand to be Best Practice for mail admins.) > [satch at c74-admin ~]$ dig +short -x 74.252.14.252 > mail.internetpro.net. > [satch at c74-admin ~]$ dig +short mail.internetpro.net. > 74.252.14.252 OK, forward and reverse match. One interesting point: When I did the full reverse lookup of the IP address (without the +short), this was part of the ADDITIONAL SECTION: > ns2.internetpro.net. 5999 IN A 74.252.14.252 I would suspect that some people would look at you oddly when your mail server is also one of your authoritative name servers. I know it's stupid, but mail admins have for years been trying to figure out behavioral habits and stigmata of spammers. Are you short of IP addresses, or stingy with servers? (I know in my consulting practice I strongly discourage having ANY other significant services on DNS servers. RADIUS and DHCP, ok, but not mail or web. For CPanel and PLESK web boxes, have the NS records point to a pair of DNS-dedicated servers, and sync the zone files with the ones on the Web boxes.) That said, I think I see a potential set of problems. The TTL on your PTR record is too short. Best Practices call for the TTL to be at least 86400, if not longer. Snowshoe spammers tend to have short TTLs on DNS records so that it's easy to shift to cleaner IP addresses when the current IP address' reputation is sullied by ne'er-do-well customers or hijackers. 6000 is only 1.5+ hours. In all the formulas I've seen published, the accepted TTL was NEVER less than 14400, or four hours. And your name server record TTLs should be MUCH longer, like 864000 (10 days). Too short a TTL for NS (and SOA) records can be a big red flag for some mail operators. What does SPF say for the domains in question? Also, what is the TTL on the TXT records? From mhuff at ox.com Mon Mar 12 17:56:07 2018 From: mhuff at ox.com (Matthew Huff) Date: Mon, 12 Mar 2018 17:56:07 +0000 Subject: LCD KVM console pullout that supports display port ??? Message-ID: Anyone have any recommendations for a 16-17" LCD keyboard/mouse combo pull-out tray that supports DisplayPort/USB as an input? ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 From spedersen.lists at gmail.com Mon Mar 12 18:46:31 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Mon, 12 Mar 2018 11:46:31 -0700 Subject: Proof of ownership; when someone demands you remove a prefix Message-ID: <004301d3ba32$70db0790$529116b0$@gmail.com> We recently received a demand to stop announcing a "fraudulent" prefix. Is there an industry best practice when handling these kind of requests? Do you have personal or company-specific preferences or requirements? To the best of my knowledge, we've rarely, if ever, received such a request. This is relatively new territory. In this case we have a signed LOA on file for that prefix and I've reached out to our customer to verify the validity of the sender's request. The sender claims to have proof that they are authorized to speak on behalf of the owner. I will wait until I hear from our customer before I consider a response to the sender. I don't get a real sense of legitimacy from the sender making the request. No one else announces the prefix. Nothing about the request appears to be legitimate, especially considering the sender. I thought about requesting they make changes to their RIR database objects to confirm ownership, but all that does is verify that person has access to the account tied to the ORG/resource, not ownership. Current entries in the database list the same ORG and contact that signed the LOA. When do you get to the point where things look "good enough" to believe someone? Has anyone gone so far as to make the requestor provide something like a notarized copy stating ownership? Have you ever gotten legal departments involved? The RIR? From SNaslund at medline.com Mon Mar 12 18:52:54 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 12 Mar 2018 18:52:54 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <004301d3ba32$70db0790$529116b0$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31DFB81@WAUPRDMBXP1.medline.com> I would personally reach out to the technical POC for the customer. Perhaps have your sales rep for the account resolve the issue. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen Sent: Monday, March 12, 2018 1:47 PM To: nanog at nanog.org Subject: Proof of ownership; when someone demands you remove a prefix We recently received a demand to stop announcing a "fraudulent" prefix. Is there an industry best practice when handling these kind of requests? Do you have personal or company-specific preferences or requirements? To the best of my knowledge, we've rarely, if ever, received such a request. This is relatively new territory. In this case we have a signed LOA on file for that prefix and I've reached out to our customer to verify the validity of the sender's request. The sender claims to have proof that they are authorized to speak on behalf of the owner. I will wait until I hear from our customer before I consider a response to the sender. I don't get a real sense of legitimacy from the sender making the request. No one else announces the prefix. Nothing about the request appears to be legitimate, especially considering the sender. I thought about requesting they make changes to their RIR database objects to confirm ownership, but all that does is verify that person has access to the account tied to the ORG/resource, not ownership. Current entries in the database list the same ORG and contact that signed the LOA. When do you get to the point where things look "good enough" to believe someone? Has anyone gone so far as to make the requestor provide something like a notarized copy stating ownership? Have you ever gotten legal departments involved? The RIR? From james.voip at gmail.com Mon Mar 12 18:56:44 2018 From: james.voip at gmail.com (james jones) Date: Mon, 12 Mar 2018 14:56:44 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31DFB81@WAUPRDMBXP1.medline.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <9578293AE169674F9A048B2BC9A081B402A31DFB81@WAUPRDMBXP1.medline.com> Message-ID: What about contacting ARIN? Does the customer have their own ASN? ETC ETC On Mon, Mar 12, 2018 at 2:52 PM, Naslund, Steve wrote: > I would personally reach out to the technical POC for the customer. > Perhaps have your sales rep for the account resolve the issue. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen > Sent: Monday, March 12, 2018 1:47 PM > To: nanog at nanog.org > Subject: Proof of ownership; when someone demands you remove a prefix > > We recently received a demand to stop announcing a "fraudulent" prefix. Is > there an industry best practice when handling these kind of requests? Do > you have personal or company-specific preferences or requirements? To the > best of my knowledge, we've rarely, if ever, received such a request. This > is relatively new territory. > > > > In this case we have a signed LOA on file for that prefix and I've reached > out to our customer to verify the validity of the sender's request. The > sender claims to have proof that they are authorized to speak on behalf of > the owner. I will wait until I hear from our customer before I consider a > response to the sender. I don't get a real sense of legitimacy from the > sender making the request. No one else announces the prefix. Nothing about > the request appears to be legitimate, especially considering the sender. > > > > I thought about requesting they make changes to their RIR database objects > to confirm ownership, but all that does is verify that person has access to > the account tied to the ORG/resource, not ownership. Current entries in the > database list the same ORG and contact that signed the LOA. When do you get > to the point where things look "good enough" to believe someone? > > > > Has anyone gone so far as to make the requestor provide something like a > notarized copy stating ownership? Have you ever gotten legal departments > involved? The RIR? > > > > From matt at netfire.net Mon Mar 12 18:57:26 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 12 Mar 2018 13:57:26 -0500 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <004301d3ba32$70db0790$529116b0$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: On Mon, Mar 12, 2018 at 1:46 PM, Sean Pedersen wrote: > We recently received a demand to stop announcing a "fraudulent" prefix. Is > there an industry best practice when handling these kind of requests? Do > you > have personal or company-specific preferences or requirements? To the best > of my knowledge, we've rarely, if ever, received such a request. This is > relatively new territory. > This could definitely be an attempt at a DoS attack, and wouldn't be the first time I've heard of something like this being done as such. I thought about requesting they make changes to their RIR database objects > to confirm ownership, but all that does is verify that person has access to > the account tied to the ORG/resource, not ownership. Current entries in the > database list the same ORG and contact that signed the LOA. When do you get > to the point where things look "good enough" to believe someone? > They may also be leasing one chunk of space from an organization without actually having access to the RIR db too - in that case, they could ask the org they are leasing from to put in a SWIP with the RIR, but if they don't choose to, then that's not a hard requirement. On the same token, having access to the org account at the RIR pretty much makes you as legitimate as you're going to be as far as any of us can really tell. If there's an issue where the RIR account has been compromised, then that issue lies between the RIR and their customer, and isn't really your business because you have no way to know whatsoever. > Has anyone gone so far as to make the requestor provide something like a > notarized copy stating ownership? Have you ever gotten legal departments > involved? The RIR? > A notarized copy stating *ownership* seems overboard. Lots of organizations lease IPv4 space, and lots more now since depletion in many regions, and their use of it is entirely legitimate in accordance with their contractual rights established in the lease agreement with the owner. I'd probably think about looking at the contact info in the RIR whois and ask them, if I had a situation like this myself. Ultimately, the RIR's contact which would be in their whois db should be authoritative more so than anyone else. I doubt the RIR would be able to say much if you contacted them beyond that everything that isn't in whois isn't something they'd share publicly. Take care, Matt From nop at imap.cc Mon Mar 12 19:07:37 2018 From: nop at imap.cc (nop at imap.cc) Date: Mon, 12 Mar 2018 12:07:37 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> I've seen this type of situation come up more than a few times with the shadier IP brokers that lease and don't care who they lease to, for example Logicweb, Cloudinnovation ( see bgp.he.net/search?search[search]=cloudinnovation+OR+%22cloud+innovation%22 ), Digital Energy-host1plus. The ranges get abused to hell and back for garbage traffic selling, rate limit bypassing, scraping, proxies, banned from youtube/google/etc for view and like farms, and then thrown away, and the leaser tries to get them unannounced quickly for further resale. On Mon, Mar 12, 2018, at 11:57 AM, Matt Harris wrote: > On Mon, Mar 12, 2018 at 1:46 PM, Sean Pedersen > wrote: > > > We recently received a demand to stop announcing a "fraudulent" prefix. Is > > there an industry best practice when handling these kind of requests? Do > > you > > have personal or company-specific preferences or requirements? To the best > > of my knowledge, we've rarely, if ever, received such a request. This is > > relatively new territory. > > > > This could definitely be an attempt at a DoS attack, and wouldn't be the > first time I've heard of something like this being done as such. > > I thought about requesting they make changes to their RIR database objects > > to confirm ownership, but all that does is verify that person has access to > > the account tied to the ORG/resource, not ownership. Current entries in the > > database list the same ORG and contact that signed the LOA. When do you get > > to the point where things look "good enough" to believe someone? > > > > They may also be leasing one chunk of space from an organization without > actually having access to the RIR db too - in that case, they could ask the > org they are leasing from to put in a SWIP with the RIR, but if they don't > choose to, then that's not a hard requirement. > > On the same token, having access to the org account at the RIR pretty much > makes you as legitimate as you're going to be as far as any of us can > really tell. If there's an issue where the RIR account has been > compromised, then that issue lies between the RIR and their customer, and > isn't really your business because you have no way to know whatsoever. > > > > Has anyone gone so far as to make the requestor provide something like a > > notarized copy stating ownership? Have you ever gotten legal departments > > involved? The RIR? > > > > A notarized copy stating *ownership* seems overboard. Lots of > organizations lease IPv4 space, and lots more now since depletion in many > regions, and their use of it is entirely legitimate in accordance with > their contractual rights established in the lease agreement with the > owner. I'd probably think about looking at the contact info in the RIR > whois and ask them, if I had a situation like this myself. Ultimately, the > RIR's contact which would be in their whois db should be authoritative more > so than anyone else. I doubt the RIR would be able to say much if you > contacted them beyond that everything that isn't in whois isn't something > they'd share publicly. > > Take care, > Matt From spedersen.lists at gmail.com Mon Mar 12 19:46:21 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Mon, 12 Mar 2018 12:46:21 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> Message-ID: <005401d3ba3a$ccb09370$6611ba50$@gmail.com> Without revealing too much identifying information, the prefix is allocated to a 3rd party that is a customer of our customer. We have a signed LOA on hand that matches the RIR database object details (names, prefix, etc.), and the request to stop announcing came from another 3rd party that does not appear to be related to either our customer or their customer. Both the individual making the demand as well as the 3rd party that "owns" the prefix are in industries that suggest things are not entirely above-board. The email came from a IP broker domain whose TLD is an eastern European country. At this point I'm going to have to rely on our customer's POC, whom I've already contacted, to verify whether or not this is true and err in their favor. I was just curious what others have experienced. Since so much of the Internet is "best effort" in terms of validation, I wasn't sure if there was much else that could be done. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of nop at imap.cc Sent: Monday, March 12, 2018 12:08 PM To: nanog at nanog.org Subject: Re: Proof of ownership; when someone demands you remove a prefix I've seen this type of situation come up more than a few times with the shadier IP brokers that lease and don't care who they lease to, for example Logicweb, Cloudinnovation ( see bgp.he.net/search?search[search]=cloudinnovation+OR+%22cloud+innovation%22 ), Digital Energy-host1plus. The ranges get abused to hell and back for garbage traffic selling, rate limit bypassing, scraping, proxies, banned from youtube/google/etc for view and like farms, and then thrown away, and the leaser tries to get them unannounced quickly for further resale. On Mon, Mar 12, 2018, at 11:57 AM, Matt Harris wrote: > On Mon, Mar 12, 2018 at 1:46 PM, Sean Pedersen > wrote: > > > We recently received a demand to stop announcing a "fraudulent" prefix. Is > > there an industry best practice when handling these kind of requests? Do > > you > > have personal or company-specific preferences or requirements? To the best > > of my knowledge, we've rarely, if ever, received such a request. This is > > relatively new territory. > > > > This could definitely be an attempt at a DoS attack, and wouldn't be the > first time I've heard of something like this being done as such. > > I thought about requesting they make changes to their RIR database objects > > to confirm ownership, but all that does is verify that person has access to > > the account tied to the ORG/resource, not ownership. Current entries in the > > database list the same ORG and contact that signed the LOA. When do you get > > to the point where things look "good enough" to believe someone? > > > > They may also be leasing one chunk of space from an organization without > actually having access to the RIR db too - in that case, they could ask the > org they are leasing from to put in a SWIP with the RIR, but if they don't > choose to, then that's not a hard requirement. > > On the same token, having access to the org account at the RIR pretty much > makes you as legitimate as you're going to be as far as any of us can > really tell. If there's an issue where the RIR account has been > compromised, then that issue lies between the RIR and their customer, and > isn't really your business because you have no way to know whatsoever. > > > > Has anyone gone so far as to make the requestor provide something like a > > notarized copy stating ownership? Have you ever gotten legal departments > > involved? The RIR? > > > > A notarized copy stating *ownership* seems overboard. Lots of > organizations lease IPv4 space, and lots more now since depletion in many > regions, and their use of it is entirely legitimate in accordance with > their contractual rights established in the lease agreement with the > owner. I'd probably think about looking at the contact info in the RIR > whois and ask them, if I had a situation like this myself. Ultimately, the > RIR's contact which would be in their whois db should be authoritative more > so than anyone else. I doubt the RIR would be able to say much if you > contacted them beyond that everything that isn't in whois isn't something > they'd share publicly. > > Take care, > Matt From SNaslund at medline.com Mon Mar 12 19:50:46 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 12 Mar 2018 19:50:46 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <005401d3ba3a$ccb09370$6611ba50$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> <005401d3ba3a$ccb09370$6611ba50$@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31DFBF5@WAUPRDMBXP1.medline.com> Sounds right to me. Unless someone else can prove ownership of the allocation beyond a doubt I would leave it up and running. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen Sent: Monday, March 12, 2018 2:46 PM To: nop at imap.cc; nanog at nanog.org Subject: RE: Proof of ownership; when someone demands you remove a prefix Without revealing too much identifying information, the prefix is allocated to a 3rd party that is a customer of our customer. We have a signed LOA on hand that matches the RIR database object details (names, prefix, etc.), and the request to stop announcing came from another 3rd party that does not appear to be related to either our customer or their customer. Both the individual making the demand as well as the 3rd party that "owns" the prefix are in industries that suggest things are not entirely above-board. The email came from a IP broker domain whose TLD is an eastern European country. At this point I'm going to have to rely on our customer's POC, whom I've already contacted, to verify whether or not this is true and err in their favor. I was just curious what others have experienced. Since so much of the Internet is "best effort" in terms of validation, I wasn't sure if there was much else that could be done. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of nop at imap.cc Sent: Monday, March 12, 2018 12:08 PM To: nanog at nanog.org Subject: Re: Proof of ownership; when someone demands you remove a prefix I've seen this type of situation come up more than a few times with the shadier IP brokers that lease and don't care who they lease to, for example Logicweb, Cloudinnovation ( see bgp.he.net/search?search[search]=cloudinnovation+OR+%22cloud+innovation%22 ), Digital Energy-host1plus. The ranges get abused to hell and back for garbage traffic selling, rate limit bypassing, scraping, proxies, banned from youtube/google/etc for view and like farms, and then thrown away, and the leaser tries to get them unannounced quickly for further resale. On Mon, Mar 12, 2018, at 11:57 AM, Matt Harris wrote: > On Mon, Mar 12, 2018 at 1:46 PM, Sean Pedersen > > wrote: > > > We recently received a demand to stop announcing a "fraudulent" > > prefix. Is there an industry best practice when handling these kind > > of requests? Do you have personal or company-specific preferences or > > requirements? To the best of my knowledge, we've rarely, if ever, > > received such a request. This is relatively new territory. > > > > This could definitely be an attempt at a DoS attack, and wouldn't be > the first time I've heard of something like this being done as such. > > I thought about requesting they make changes to their RIR database > objects > > to confirm ownership, but all that does is verify that person has > > access to the account tied to the ORG/resource, not ownership. > > Current entries in the database list the same ORG and contact that > > signed the LOA. When do you get to the point where things look "good enough" to believe someone? > > > > They may also be leasing one chunk of space from an organization > without actually having access to the RIR db too - in that case, they > could ask the org they are leasing from to put in a SWIP with the RIR, > but if they don't choose to, then that's not a hard requirement. > > On the same token, having access to the org account at the RIR pretty > much makes you as legitimate as you're going to be as far as any of us > can really tell. If there's an issue where the RIR account has been > compromised, then that issue lies between the RIR and their customer, > and isn't really your business because you have no way to know whatsoever. > > > > Has anyone gone so far as to make the requestor provide something > > like a notarized copy stating ownership? Have you ever gotten legal > > departments involved? The RIR? > > > > A notarized copy stating *ownership* seems overboard. Lots of > organizations lease IPv4 space, and lots more now since depletion in > many regions, and their use of it is entirely legitimate in accordance > with their contractual rights established in the lease agreement with > the owner. I'd probably think about looking at the contact info in > the RIR whois and ask them, if I had a situation like this myself. > Ultimately, the RIR's contact which would be in their whois db should > be authoritative more so than anyone else. I doubt the RIR would be > able to say much if you contacted them beyond that everything that > isn't in whois isn't something they'd share publicly. > > Take care, > Matt From bill at herrin.us Mon Mar 12 20:18:48 2018 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2018 16:18:48 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <005401d3ba3a$ccb09370$6611ba50$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> <005401d3ba3a$ccb09370$6611ba50$@gmail.com> Message-ID: On Mon, Mar 12, 2018 at 3:46 PM, Sean Pedersen wrote: > I was just curious what others have experienced. Since so much of the Internet is "best effort" in terms of validation, I wasn't sure if there was much else that could be done. Hi Sean, The best practice is to go for the status quo while you figure it out. How long have you been announcing the prefix? If only briefly, stop. If you've been announcing it for a long time, keep doing so. The RIR is the arbiter of who controls the address space. That's the purpose of a registry. Reach out to the published POC by email, by phone and if necessary by postal mail. Until you get a response to the query YOU initiated to the POC, stick with the status quo. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jim at reptiles.org Mon Mar 12 20:35:28 2018 From: jim at reptiles.org (Jim Mercer) Date: Mon, 12 Mar 2018 16:35:28 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> <1520881657.3416168.1300500936.72416E74@webmail.messagingengine.com> <005401d3ba3a$ccb09370$6611ba50$@gmail.com> Message-ID: <20180312203528.GA28357@reptiles.org> i have been the requestor of such actions before, and i generally sent the take-down request with a referral to the ARIN entry with the netblock, which shows the appropriate contacts. i always sent the request from the account listed as ADMIN contact for the netblock or OrgID. in the request i noted that ARIN is the ultimate arbitor of who "owns" a block, and as such you can validate my request for takedown by contacting me through the details listed on their site. (i then provide the arin.net link). anyone receiving such a request, who validated it through the ARIN data, should probably act on it. if the request is coming from anyone other than the ARIN ADMIN contact, the response should be "we only accept such requests from parties what we can authenticate through ARIN". if the renter, et al, have not updated the ARIN data, then, that is their problem, not yours, as you would have done your due diligence. if they are not authorized by ARIN to speak on behalf of the block, i would be very cautious about proceeding. if they are unable to get the request sent on behalf of the ARIN ADMINs, then, also, i would be very cautious about proceeding. (i suspect that all of this could also apply to RIPE/etc/etc, but i have not had to do so). --jim On Mon, Mar 12, 2018 at 04:18:48PM -0400, William Herrin wrote: > On Mon, Mar 12, 2018 at 3:46 PM, Sean Pedersen > wrote: > > I was just curious what others have experienced. Since so much of the Internet is "best effort" in terms of validation, I wasn't sure if there was much else that could be done. > > Hi Sean, > > The best practice is to go for the status quo while you figure it out. > How long have you been announcing the prefix? If only briefly, stop. > If you've been announcing it for a long time, keep doing so. > > The RIR is the arbiter of who controls the address space. That's the > purpose of a registry. Reach out to the published POC by email, by > phone and if necessary by postal mail. Until you get a response to the > query YOU initiated to the POC, stick with the status quo. > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From randy at psg.com Mon Mar 12 23:11:12 2018 From: randy at psg.com (Randy Bush) Date: Tue, 13 Mar 2018 08:11:12 +0900 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <004301d3ba32$70db0790$529116b0$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: it's a real shame there is no authorative cryptographically verifyable attestation of address ownership. From mike.lyon at gmail.com Mon Mar 12 23:24:51 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 12 Mar 2018 16:24:51 -0700 Subject: Spiffy Netflow tools? Message-ID: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Howdy! Checking out various Netflow tools and wanted to see what others are using? Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. Also curious about on-prem solutions as well. Thanks! Mike From drohan at gmail.com Mon Mar 12 23:28:29 2018 From: drohan at gmail.com (Daniel Rohan) Date: Mon, 12 Mar 2018 23:28:29 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: Hey Mike. Kentik does on-prem, too. Full disclosure: I work for Kentik and I’m glad you think we’re cool :-) Dan On Mon, Mar 12, 2018 at 4:26 PM wrote: > Howdy! > > Checking out various Netflow tools and wanted to see what others are using? > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem > to see any others. > > Also curious about on-prem solutions as well. > > Thanks! > Mike -- Thanks, Dan From merculiani at gmail.com Mon Mar 12 23:30:57 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Mon, 12 Mar 2018 18:30:57 -0500 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: I'm very fond of nfsen/nfdump for on-prem. Setup is not complicated at all and plugins are widely available. Also inbefore Solarwinds... -Matt On Mar 12, 2018 18:25, wrote: Howdy! Checking out various Netflow tools and wanted to see what others are using? Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. Also curious about on-prem solutions as well. Thanks! Mike From hugge at nordu.net Mon Mar 12 23:50:26 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 13 Mar 2018 00:50:26 +0100 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> On 2018-03-13 00:24, mike.lyon at gmail.com wrote: > Howdy! > > Checking out various Netflow tools and wanted to see what others are using? > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. > > Also curious about on-prem solutions as well. > > Thanks! > Mike > Kentik is probably top of the foodchain right now. But they are certainly not alone in the biz. Ontop of my head... * Flowmon * Talaia * Arbor Peakflow * Deepfield * Pmacct + supporting toolkit * NFsen/Nfdump/AS-stats * Put kibana/ES infront of any collector * Solarwinds something something * Different vendor toolkits -- hugge From george.herbert at gmail.com Tue Mar 13 01:20:21 2018 From: george.herbert at gmail.com (George William Herbert) Date: Mon, 12 Mar 2018 18:20:21 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> Ownership?... (Duck) -george Sent from my iPhone > On Mar 12, 2018, at 4:11 PM, Randy Bush wrote: > > it's a real shame there is no authorative cryptographically verifyable > attestation of address ownership. From jhellenthal at dataix.net Tue Mar 13 01:39:40 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 12 Mar 2018 21:39:40 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> Message-ID: <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> How about signed ownership ? (https://keybase.io) if you are able to update the record … and it is able to be signed then shouldn’t that be proof enough of ownership of the ASN ? If you can update a forward DNS record then you can have the reverse record updated in the same sort of fashion and signed by a third party to provide first party of authoritative ownership… Assuming you have an assigned ASN and the admin has taken the time to let alone understand the concept and properly prove the identity in the first place… (EV cert ?) Just a light opinion from … https://jhackenthal.keybase.pub Trust is a big issue these days and validation even worse given SSL trust. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 12, 2018, at 21:20, George William Herbert wrote: > > Ownership?... > > (Duck) > > -george > > Sent from my iPhone > >> On Mar 12, 2018, at 4:11 PM, Randy Bush wrote: >> >> it's a real shame there is no authorative cryptographically verifyable >> attestation of address ownership. From surfer at mauigateway.com Tue Mar 13 02:26:50 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 12 Mar 2018 19:26:50 -0700 Subject: Proof of ownership; when someone demands you remove a prefix Message-ID: <20180312192650.B47FCF9C@m0117457.ppops.net> >> On Mar 12, 2018, at 4:11 PM, Randy Bush wrote: >> >> it's a real shame there is no authorative cryptographically verifyable >> attestation of address ownership. > On Mar 12, 2018, at 21:20, George William Herbert wrote: > > Ownership?... > > (Duck) --- jhellenthal at dataix.net wrote: From: Jason Hellenthal : shouldn’t that be proof enough of ownership of the ASN ? ------------------------------------------------- You don't own the ASN. And that was a special, friendly poke at randy... :-) scott From jhellenthal at dataix.net Tue Mar 13 02:29:09 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 12 Mar 2018 22:29:09 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <20180312192650.B47FCF9C@m0117457.ppops.net> References: <20180312192650.B47FCF9C@m0117457.ppops.net> Message-ID: <7579DA77-BDF4-4147-8747-9423547514FE@dataix.net> haha. Sorry for the top posts. iOS what ya goin to do on a very long thread capability. :-) -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 12, 2018, at 22:26, Scott Weeks wrote: > > > >>> On Mar 12, 2018, at 4:11 PM, Randy Bush wrote: >>> >>> it's a real shame there is no authorative cryptographically verifyable >>> attestation of address ownership. > > >> On Mar 12, 2018, at 21:20, George William Herbert wrote: >> >> Ownership?... >> >> (Duck) > > > --- jhellenthal at dataix.net wrote: > From: Jason Hellenthal > > : shouldn’t that be proof enough of ownership of the ASN ? > ------------------------------------------------- > > > You don't own the ASN. And that was a special, friendly poke at randy... :-) > > scott From spedersen.lists at gmail.com Tue Mar 13 14:23:06 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Tue, 13 Mar 2018 07:23:06 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> Message-ID: <002401d3bad6$cf3dae10$6db90a30$@gmail.com> In this case we defaulted to trusting our customer and their LOA over a stranger on the Internet and asked our customer to review the request. Unfortunately, that doesn't necessarily mean a stranger on the Internet isn't the actual assignee. A means to definitively prove "ownership" from a technical angle would be great. In the example provided in my original e-mail, it appears that an IP broker or related scammer gained access to the assignee's RIR account and made some object updates (e-mail, country, etc.) that they could use to "prove" they had authority to make the request. I assume their offer of proof would have been to send us an email from the dubious @yahoo.com account they had listed as the admin contact. I agree with a private response that I received that at some point lawyers probably need to take over if a technical solution to verification is not reached. I'm not terribly current on resource certification, but would RPKI play a role here? It looks like its application is limited to authenticating the announcement of resources to prevent route hijacking. If you've authorized a 3rd party to announce your routes, could you assign a certificate to that 3rd party for a specific resource and then revoke it if they are no longer authorized? Would it matter if someone gains access to your RIR/LIR account and revokes the certificate? This would assume protocol compatibility, that everyone is using it, etc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Hellenthal Sent: Monday, March 12, 2018 6:40 PM To: George William Herbert Cc: nanog at nanog.org Subject: Re: Proof of ownership; when someone demands you remove a prefix How about signed ownership ? (https://keybase.io) if you are able to update the record … and it is able to be signed then shouldn’t that be proof enough of ownership of the ASN ? If you can update a forward DNS record then you can have the reverse record updated in the same sort of fashion and signed by a third party to provide first party of authoritative ownership… Assuming you have an assigned ASN and the admin has taken the time to let alone understand the concept and properly prove the identity in the first place… (EV cert ?) Just a light opinion from … https://jhackenthal.keybase.pub Trust is a big issue these days and validation even worse given SSL trust. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 12, 2018, at 21:20, George William Herbert wrote: > > Ownership?... > > (Duck) > > -george > > Sent from my iPhone > >> On Mar 12, 2018, at 4:11 PM, Randy Bush wrote: >> >> it's a real shame there is no authorative cryptographically verifyable >> attestation of address ownership. From bob at FiberInternetCenter.com Tue Mar 13 14:37:31 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 13 Mar 2018 07:37:31 -0700 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> That site you quoted looks like text that I created. For CloudIPv4.com (part of RentIPv4.com). To peer most networks require assigned IPv4 space. Most networks do not want to burn a /24 to peer. The local peering routers will propagate a /25... /30.. etc. from the peering platform to the rest of the their own network's routers but usually never beyond - keeps it internal within the network's own BGP sessions. However, you can not expect the /25.. /30 to be propagated beyond the network you have a BGP session with - I.E. transits will filter the subnets /25.../30. I have seen an exception locally or regionally it was agreed too propagate outside the network. Thank You Bob Evans CTO > Le 2018-01-04 20:16, Job Snijders a écrit : >> On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: >> >>> I have stumbled upon this site [1] which seems to offer /27 IPv4 >>> leasing. >>> They also claim "All of our IPv4 address space can be used on any >>> network >>> in any location." >>> >>> I thought that the smallest prefix size one could get routed globally >>> is >>> /24? >> >> >> Yes >> >> So how does this work? >>> >> Probably with GRE, IPIP or OpenVPN tunnels. >> >> Kind regards, >> >> Job > > IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) > neighbors. If I run a global (or regional) network, I may advertise this > /24 -- or rather an aggregate covering it -- over my diverse > interconnection with neighbors, your /27 being part of the chunk and > routed to you internally (if you're va customer)-- no need for > encapsulation efforts. Similar scenario may be multi-upstream, subject > to acceptance of "punching holes in aggregates"... Am I missing > something? What's the trigger for doing tunneling here? > > Happy New Year '18, by the way ! > > mh > From mysidia at gmail.com Tue Mar 13 14:46:57 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 13 Mar 2018 09:46:57 -0500 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <002401d3bad6$cf3dae10$6db90a30$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> Message-ID: On Tue, Mar 13, 2018 at 9:23 AM, Sean Pedersen wrote: > In this case we defaulted to trusting our customer and their LOA over a stranger on the > Internet and asked our customer to review the request. Unfortunately, that doesn't > necessarily mean a stranger on the Internet isn't the actual assignee. [......] I believe the suggested process would be.... submit the stranger's request to the administrative & technical contacts listed for the organization and IP resource in public WHOIS at the time the request is received, and in order to confirm: Request whether their organization approves that the announcements must be withdrawn, and if so: that they also submit to you a signed official form to either revise, rescind, or repudiate the existing LOA provided by that WHOIS contact. Then reply to the "stranger" that official documentation is required to cancel the announcement, and you are unable to verify you have the right to make the request, and you will forward their message to the IP Address registry and officially listed WHOIS and customer technical contacts who must approve of the request, before any further actions can be taken. -- -JH From nanog-post at rsuc.gweep.net Tue Mar 13 14:50:21 2018 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 13 Mar 2018 10:50:21 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <004301d3ba32$70db0790$529116b0$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: <20180313145021.GA18884@gweep.net> On Mon, Mar 12, 2018 at 11:46:31AM -0700, Sean Pedersen wrote: > We recently received a demand to stop announcing a "fraudulent" prefix. Is > there an industry best practice when handling these kind of requests? Do you > have personal or company-specific preferences or requirements? To the best > of my knowledge, we've rarely, if ever, received such a request. This is > relatively new territory. Best practice is for the prefix-user to have correct data of subdelegation in the correct RIR. LOA letters have been forged since well before runout, in the days when they were faxed. Issues with potential RIR haacks should be taken straight to that RIR; those hve also been unfortunately common. These days, ROAs would be nice to see for anyone up-to-date on methods. At the very least, the low bar of IRR data should be present. If there's only a private letter between two parties, no one a few hops away can validate that, so the user of the space flatly should expect poor propagation. If there's no data published that a remote party can use, there should be zero expectation any remote party will accept the prefix on that path. IME this is pretty old territory, and should be part of any providers' M&P for handling PI space. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From SNaslund at medline.com Tue Mar 13 14:56:45 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 14:56:45 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> Yes, exactly right. You would probably have to tunnel the /27 back to where the >/24 lives. That's the only way I can see of it working "anywhere". That's a technically valid solution but maybe not so hot if you are looking for high redundancy/availability since you are dependent on the tunnel being up and working. As always the reputation of the aggregate is going to be critical as to how well this works for you. It seems to me that increasingly these "portable" blocks have murky histories as spam and malware sources. I would rather have a block assigned by a reputable upstream provider than to do this. Steven Naslund Chicago IL > Le 2018-01-04 20:16, Job Snijders a écrit : >> On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: >> >>> I have stumbled upon this site [1] which seems to offer /27 IPv4 >>> leasing. >>> They also claim "All of our IPv4 address space can be used on any >>> network in any location." >>> >>> I thought that the smallest prefix size one could get routed >>> globally is /24? >> >> >> Yes >> >> So how does this work? >>> >> Probably with GRE, IPIP or OpenVPN tunnels. >> >> Kind regards, >> >> Job > > IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) > neighbors. If I run a global (or regional) network, I may advertise this > /24 -- or rather an aggregate covering it -- over my diverse > interconnection with neighbors, your /27 being part of the chunk and > routed to you internally (if you're va customer)-- no need for > encapsulation efforts. Similar scenario may be multi-upstream, subject > to acceptance of "punching holes in aggregates"... Am I missing > something? What's the trigger for doing tunneling here? > > Happy New Year '18, by the way ! > > mh > From SNaslund at medline.com Tue Mar 13 15:01:08 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 15:01:08 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <20180313145021.GA18884@gweep.net> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <20180313145021.GA18884@gweep.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E72D7@MUNPRDMBXA1.medline.com> Another thing that would affect me as a service provider would be the account history. I would probably be more skeptical if this was a long term customer who has been announcing this prefix for a long period of time vs a new customer that just began announcing it. i.e. If I just began announcing it and there is an ownership dispute right away, I might suspect my new customer misappropriated the block. If he had been announcing it for years and now someone wants it taken down, that is a higher burden of proof for me. As always bottom line is who has the block registered with RAR is the final authority. Steven Naslund Chicago IL On Mon, Mar 12, 2018 at 11:46:31AM -0700, Sean Pedersen wrote: > We recently received a demand to stop announcing a "fraudulent" > prefix. Is there an industry best practice when handling these kind of > requests? Do you have personal or company-specific preferences or > requirements? To the best of my knowledge, we've rarely, if ever, > received such a request. This is relatively new territory. From dovid at telecurve.com Tue Mar 13 15:09:12 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 13 Mar 2018 11:09:12 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: Finally a use for block chain :p On Mon, Mar 12, 2018 at 7:11 PM, Randy Bush wrote: > it's a real shame there is no authorative cryptographically verifyable > attestation of address ownership. > From SNaslund at medline.com Tue Mar 13 15:09:50 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 15:09:50 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <002401d3bad6$cf3dae10$6db90a30$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E72FF@MUNPRDMBXA1.medline.com> I would insist that this customer get with the RIR and resolve ownership of the account and prove that they did so. I would leave the burden on the RIR to figure out who is the rightful owner and not make any changes until that is done. Do you have a record of what the RIR account contact was when you began announcing the block? The fact that the requester has the RIR account and the email of the account contact makes me wonder if your customer did not renew with the RIR or something else that caused them to lose ownership of the net block. I could see this happen during an acquisition or change of ownership of a company or entity. I would give the customer a short period of time to open a dispute with the RIR and then hold the changes until the RIR makes a determination. I think that protects you from a legal perspective more than deciding on your own. Of course, keep a good record of all communications on this subject especially with the RIR, this could get ugly. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen >Sent: Tuesday, March 13, 2018 9:23 AM >To: nanog at nanog.org >Subject: RE: Proof of ownership; when someone demands you remove a prefix > >In this case we defaulted to trusting our customer and their LOA over a stranger on the Internet and asked our customer to review the request. >Unfortunately, that doesn't necessarily mean a stranger on the Internet isn't the actual assignee. A means to definitively prove "ownership" from a >technical angle would be great. > >In the example provided in my original e-mail, it appears that an IP broker or related scammer gained access to the assignee's RIR account and made >some object updates (e-mail, country, etc.) that they could use to "prove" they had authority to make the request. I assume their offer of proof would >have been to send us an email from the dubious @yahoo.com account they had listed as the admin contact. > >I agree with a private response that I received that at some point lawyers probably need to take over if a technical solution to verification is not >reached. > >I'm not terribly current on resource certification, but would RPKI play a role here? It looks like its application is limited to authenticating the >announcement of resources to prevent route hijacking. If you've authorized a 3rd party to announce your routes, could you assign a certificate to that >3rd party for a specific resource and then revoke it if they are no longer authorized? Would it matter if someone gains access to your RIR/LIR account >and revokes the certificate? This would assume protocol compatibility, that everyone is using it, etc. From bill at herrin.us Tue Mar 13 15:18:18 2018 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2018 11:18:18 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <002401d3bad6$cf3dae10$6db90a30$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> Message-ID: On Tue, Mar 13, 2018 at 10:23 AM, Sean Pedersen wrote: > In this case we defaulted to trusting our customer and their LOA over a stranger on the Internet and asked our customer to review the request. Unfortunately, that doesn't necessarily mean a stranger on the Internet isn't the actual assignee. A means to definitively prove "ownership" from a technical angle would be great. Hi Sean, There is a definitive technical means. It's called contact the POC published in WHOIS by the RIR and ask. It isn't flawless and you don't have to like it, but there it is. If you contacted the POC and the POC replied stop, you stop. If the POC was hijacked at the RIR, that's between your customer and the RIR. The RIR has a standard process and an expert team for dealing with these situations. It's their job. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Tue Mar 13 15:20:51 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 15:20:51 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E7333@MUNPRDMBXA1.medline.com> Biggest problems we had as a service provider is that the block is registered to a corporate entity which is then acquired or dissolves and then you have to figure out who actually has control. We always tried to push the dispute process to go between the customer and the RIR when this happens. It takes too many legal resources to get involved in figuring out who owns what during an acquisition or dissolution. Often this particular resources does not get called out specifically and can be a problem. Sometimes they get treated like corporate intellectual property and sometimes they get treated more like a utility. It’s a legal nightmare to get in the middle of it. I have had cases where it was so complex we forced one of the parties to get a court order one way or another. Steven Naslund Chicago IL > it's a real shame there is no authorative cryptographically verifyable > attestation of address ownership. > From SNaslund at medline.com Tue Mar 13 15:27:22 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 15:27:22 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> Yes, absolutely go with the RIR. Only thing I might adjust it whether I let the customer launch a dispute with the RIR before or after I make the change and to me that would depend on the preponderance of the evidence either way. I might give the long term customer the reasonable doubt. A new customer with a new advertisement not so much. Talk to your legal people of course but I would think if the RIR could verify a dispute in progress, you are covered until the dispute is resolved. Seems legally reasonable to me and shows due diligence on your part without you getting in the middle. Steven Naslund Chicago IL >Hi Sean, > >There is a definitive technical means. It's called contact the POC published in WHOIS by the RIR and ask. It isn't flawless and you don't have to like >it, but there it is. > >If you contacted the POC and the POC replied stop, you stop. If the POC was hijacked at the RIR, that's between your customer and the RIR. >The RIR has a standard process and an expert team for dealing with these situations. It's their job. > >Regards, >Bill Herrin From jloiacon at dxc.com Tue Mar 13 15:31:56 2018 From: jloiacon at dxc.com (Loiacono, Joe) Date: Tue, 13 Mar 2018 15:31:56 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: FlowViewer is a robust user interface complement to Carnegie Mellon's SiLK netflow capture and analysis tool suite. FlowViewer provides the user with text/graphical analysis tools, multiple dashboards, long-term tracking of filtered sets, automatic storage management, raw netflow packet analysis, etc.. All open-source. Easy install. Runs on Linux. FlowViewer: https://sourceforge.net/projects/flowviewer/ SiLK: https://tools.netsa.cert.org/silk/ Joe Loiacono -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of mike.lyon at gmail.com Sent: Monday, March 12, 2018 7:25 PM To: NANOG list Subject: Spiffy Netflow tools? Howdy! Checking out various Netflow tools and wanted to see what others are using? Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. Also curious about on-prem solutions as well. Thanks! Mike DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From hugo at slabnet.com Tue Mar 13 15:44:04 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 13 Mar 2018 08:44:04 -0700 Subject: Spiffy Netflow tools? In-Reply-To: <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> Message-ID: <20180313154404.GJ25899@bamboo.slabnet.com> On Tue 2018-Mar-13 00:50:26 +0100, Fredrik Korsbäck wrote: > >Kentik is probably top of the foodchain right now. > >But they are certainly not alone in the biz. Ontop of my head... > >* Flowmon >* Talaia >* Arbor Peakflow >* Deepfield >* Pmacct + supporting toolkit >* NFsen/Nfdump/AS-stats >* Put kibana/ES infront of any collector Logstash has a netflow plugin as of 5.x or something (https://www.elastic.co/guide/en/logstash/current/netflow-module.html) to act as a collector. A walkthrough: http://www.routereflector.com/2017/07/elk-as-a-free-netflow-ipfix-collector-and-visualizer/ Using the logstash module setup thing adds a whole bunch of pretty netflow graphs and visualizations and such into Kibana for you. Caveat: Supports netflow v5 and v9, but does not indicate support for IPFIX explicitly. It definitely does not support sFlow, though if you really want you can stick sflowtool in front of it to translate sFlow->netflow, e.g. http://blog.sflow.com/2011/12/sflowtool.html. >* Solarwinds something something >* Different vendor toolkits > >-- >hugge -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sam at coeosolutions.com Mon Mar 12 17:44:47 2018 From: sam at coeosolutions.com (Sam Kretchmer) Date: Mon, 12 Mar 2018 17:44:47 +0000 Subject: Websurfing trouble to .gov and .il.us Message-ID: Nanog, I am part of a small ISP based in Chicago. We have several clients complaining of an inability to hit a couple specific government websites, specifically http://tierii.iema.state.il.us/TIER2MANAGER/Account/Login.aspx and https://www.deadiversion.usdoj.gov/. It does seem to be related to the IP's they use, specifically parts of 213.159.132/22. They can surf any other site we can think of, do email, IPSec tunnels, anything apparently but surf these sites. The listed sites show "loading" then "connecting" then back to "loading" and so on. I have checked all the blacklist sites I can get out of google. and they all show all green. I am at a loss as to what else might be contributing to the issue. Is there anyone on list here from either of those sites who might be able to help who can hit me off list, or anyone at all who might have some advice? It would be appreciated. All I need to do is to assign different IP's to the client and it works fine (hopefully eliminating Layer 1 and Layer 2, i.e. routers, circuits, etc..) My apologies if this is not the correct forum for this kind of question. Thanks Sam From babak at farrokhi.net Tue Mar 13 07:16:17 2018 From: babak at farrokhi.net (Babak Farrokhi) Date: Tue, 13 Mar 2018 10:46:17 +0330 Subject: Spiffy Netflow tools? In-Reply-To: <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> Message-ID: <2A55570D-7163-4849-B7AC-041237735E19@farrokhi.net> Plixer is also interesting. nfdump works great with NetFlow but support for IPFIX is somehow limited to basics. -- Babak On 13 Mar 2018, at 3:20, Fredrik Korsbäck wrote: > On 2018-03-13 00:24, mike.lyon at gmail.com wrote: >> Howdy! >> >> Checking out various Netflow tools and wanted to see what others are >> using? >> >> Kentik is cool. Are they the only SaaS based flow digester? I don’t >> seem to see any others. >> >> Also curious about on-prem solutions as well. >> >> Thanks! >> Mike >> > > Kentik is probably top of the foodchain right now. > > But they are certainly not alone in the biz. Ontop of my head... > > * Flowmon > * Talaia > * Arbor Peakflow > * Deepfield > * Pmacct + supporting toolkit > * NFsen/Nfdump/AS-stats > * Put kibana/ES infront of any collector > * Solarwinds something something > * Different vendor toolkits > > > > -- > hugge From lguillory at reservetele.com Tue Mar 13 15:48:18 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 13 Mar 2018 15:48:18 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <20180313154404.GJ25899@bamboo.slabnet.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <20180313154404.GJ25899@bamboo.slabnet.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4E7FE5@RTC-EXCH01.RESERVE.LDS> There is also https://github.com/robcowart/elastiflow which uses the ELK stack. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.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. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hugo Slabbert Sent: Tuesday, March 13, 2018 10:44 AM To: Fredrik Korsbäck Cc: nanog at nanog.org Subject: Re: Spiffy Netflow tools? On Tue 2018-Mar-13 00:50:26 +0100, Fredrik Korsbäck wrote: > >Kentik is probably top of the foodchain right now. > >But they are certainly not alone in the biz. Ontop of my head... > >* Flowmon >* Talaia >* Arbor Peakflow >* Deepfield >* Pmacct + supporting toolkit >* NFsen/Nfdump/AS-stats >* Put kibana/ES infront of any collector Logstash has a netflow plugin as of 5.x or something (https://www.elastic.co/guide/en/logstash/current/netflow-module.html) to act as a collector. A walkthrough: http://www.routereflector.com/2017/07/elk-as-a-free-netflow-ipfix-collector-and-visualizer/ Using the logstash module setup thing adds a whole bunch of pretty netflow graphs and visualizations and such into Kibana for you. Caveat: Supports netflow v5 and v9, but does not indicate support for IPFIX explicitly. It definitely does not support sFlow, though if you really want you can stick sflowtool in front of it to translate sFlow->netflow, e.g. http://blog.sflow.com/2011/12/sflowtool.html. >* Solarwinds something something >* Different vendor toolkits > >-- >hugge -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal From bob at FiberInternetCenter.com Tue Mar 13 16:16:19 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 13 Mar 2018 09:16:19 -0700 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> Message-ID: Agreed, Reputation is everything. It is why we only work with well known Legacy IPv4 space at this time (hence, use anywhere statement). Our space rents for about 4x other space found on other sites. We don't do the volume business of our competitors. Those businesses with questionable address space will always be around as there are always customers for fast, cheap, without the good reputation. Most customers for that fast cheap space have no clue how to verify space until a problem arises. After the fact, they usually end up in trouble, spending much more money to not only educate themselves but also on the labor involved in re-numbering. About your second point - "would rather have a block assigned by a reputable upstream provider" - I agree, if it was for say a real estate office access, one could simply ask everyone to wait it out or send everyone home and ask them to use their DSL or cable operator when it's broke. We rent out /24s (and up) because some upstreams won't provide a full /24 and some of those networks send those customers to us. Do to the limited IPv4 availability, many no longer entertain portability for their assigned space. Multi-homing become issues of labor and they don't want to deal with it with their assigned space. With one ASN announcing your space, it means your down when they have maintenance or limited reach when they have other routing issues. Today, it makes sense to go with quality wholesale IPv4 space from a 3rd party. You can look at the IPs as an R.O.I opportunity as customers understand supply-demand and will pay 10x for space they need. It more than pays for itself in network reliability and labor saved. For those that don't need multi-home today, it's wise to consider expansion down the road and have already planned tomorrow's improved network ability to multi-home. As the cost later to re-number to multi-home. Or worse, discover you need to re-number because that network that provided you the space called it back to give to a bigger customer or won't let you announce it on other networks they specify where your cost for bandwidth would be lower. So, there are many reasons to obtain clean independent space - but most are related to future expansion abilities and future flexibility. "There is a market somewhere for just about anything." Hope this info helps, Thank You Bob Evans CTO > > Yes, exactly right. You would probably have to tunnel the /27 back to > where the >/24 lives. That's the only way I can see of it working > "anywhere". That's a technically valid solution but maybe not so hot if > you are looking for high redundancy/availability since you are dependent > on the tunnel being up and working. > > As always the reputation of the aggregate is going to be critical as to > how well this works for you. It seems to me that increasingly these > "portable" blocks have murky histories as spam and malware sources. I > would rather have a block assigned by a reputable upstream provider than > to do this. > > Steven Naslund > Chicago IL > >> Le 2018-01-04 20:16, Job Snijders a écrit : >>> On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: >>> >>>> I have stumbled upon this site [1] which seems to offer /27 IPv4 >>>> leasing. >>>> They also claim "All of our IPv4 address space can be used on any >>>> network in any location." >>>> >>>> I thought that the smallest prefix size one could get routed >>>> globally is /24? >>> >>> >>> Yes >>> >>> So how does this work? >>>> >>> Probably with GRE, IPIP or OpenVPN tunnels. >>> >>> Kind regards, >>> >>> Job >> >> IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) >> neighbors. If I run a global (or regional) network, I may advertise this >> /24 -- or rather an aggregate covering it -- over my diverse >> interconnection with neighbors, your /27 being part of the chunk and >> routed to you internally (if you're va customer)-- no need for >> encapsulation efforts. Similar scenario may be multi-upstream, subject >> to acceptance of "punching holes in aggregates"... Am I missing >> something? What's the trigger for doing tunneling here? >> >> Happy New Year '18, by the way ! >> >> mh >> > > > From netfortius at gmail.com Tue Mar 13 16:21:51 2018 From: netfortius at gmail.com (Stefan) Date: Tue, 13 Mar 2018 16:21:51 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: Not necessarily (only) for *flow, but very nice combo: Luca Deri's ntopng+nprobe (https://www.ntop.org/products/traffic-analysis/ntop/) ***Stefan On Mon, Mar 12, 2018, 6:26 PM wrote: > Howdy! > > Checking out various Netflow tools and wanted to see what others are using? > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem > to see any others. > > Also curious about on-prem solutions as well. > > Thanks! > Mike From lists at mtin.net Tue Mar 13 17:19:40 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 13 Mar 2018 13:19:40 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> Message-ID: <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> On the consulting side, I do smaller than /24 blocks to customers over tunnels. So far this is the only option we have found that works for the smaller ISP. We all know the routing table is bloated. We all know everyone *should* be moving toward IPV6. A whole different discussion. But, for now you have a subset of operators that are big enough to do BGP, maybe join an exchange, but not big enough to afford buying v4 space for each of their customers. So they are utilizing a full /24 just to utilize it. Things such as doing 1:many nat at each tower, doing Carrier Grade nat, and other things make it where they don’t necessarily need an IP per customer. We all know that is ideal, but it’s not practical for the small to medium ISP. Folks have brought up the argument that buying IPS is just the cost of doing business these days. I argue that it isn’t. I see networks with 2000 users and only a /24 running along very happy. I agree that the global routing table is pretty bloated as is. But what kind of a solution for providers who need to participate in BGP but only need a /25? I can’t see going below that. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Mar 13, 2018, at 10:56 AM, Naslund, Steve wrote: > > > Yes, exactly right. You would probably have to tunnel the /27 back to where the >/24 lives. That's the only way I can see of it working "anywhere". That's a technically valid solution but maybe not so hot if you are looking for high redundancy/availability since you are dependent on the tunnel being up and working. > > As always the reputation of the aggregate is going to be critical as to how well this works for you. It seems to me that increasingly these "portable" blocks have murky histories as spam and malware sources. I would rather have a block assigned by a reputable upstream provider than to do this. > > Steven Naslund > Chicago IL > >> Le 2018-01-04 20:16, Job Snijders a écrit : >>> On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: >>> >>>> I have stumbled upon this site [1] which seems to offer /27 IPv4 >>>> leasing. >>>> They also claim "All of our IPv4 address space can be used on any >>>> network in any location." >>>> >>>> I thought that the smallest prefix size one could get routed >>>> globally is /24? >>> >>> >>> Yes >>> >>> So how does this work? >>>> >>> Probably with GRE, IPIP or OpenVPN tunnels. >>> >>> Kind regards, >>> >>> Job >> >> IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) >> neighbors. If I run a global (or regional) network, I may advertise this >> /24 -- or rather an aggregate covering it -- over my diverse >> interconnection with neighbors, your /27 being part of the chunk and >> routed to you internally (if you're va customer)-- no need for >> encapsulation efforts. Similar scenario may be multi-upstream, subject >> to acceptance of "punching holes in aggregates"... Am I missing >> something? What's the trigger for doing tunneling here? >> >> Happy New Year '18, by the way ! >> >> mh >> > > From bill at herrin.us Tue Mar 13 17:28:38 2018 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2018 13:28:38 -0400 Subject: Websurfing trouble to .gov and .il.us In-Reply-To: References: Message-ID: On Mon, Mar 12, 2018 at 1:44 PM, Sam Kretchmer wrote: > We have several clients complaining of an inability to hit a couple specific government websites, Hi Sam, Some basic troubleshooting: 1. traceroute? TCP traceroute? 2. From an affected address, do you get a TCP connect to the site or not? e.g. "telnet tierii.iema.state.il.us 80" Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Tue Mar 13 17:37:27 2018 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2018 13:37:27 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: > I agree that the global routing table is pretty bloated as is. But what kind of a solution for providers who need to participate in BGP but only need a /25? Hi Justin, If you need a /25 and BGP for multihoming or anycasting, get a /24. The cost you impose on the system by using BGP *at all* is much higher than the cost you impose on the system by consuming less than 250 "unneeded" Ip addresses. I did a cost analysis on a BGP announcement a decade or so ago. The exact numbers have changed but the bottom line hasn't: it's ridiculously consumptive. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From spedersen.lists at gmail.com Tue Mar 13 17:38:49 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Tue, 13 Mar 2018 10:38:49 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> Message-ID: <006601d3baf2$2634e8d0$729eba70$@gmail.com> This is more or less the situation we're in. We contacted the customer and they informed us the matter is in dispute with the RIR and that their customer (the assignee) is in the process of resolving the issue. We have to allow them time to accomplish this. I've asked for additional information to help us understand the nature of the dispute. In that time we received another request to stop announcing the prefix(s) in addition to a new set of prefixes, and a threat to contact our upstream providers as well as ARIN - which is not the RIR the disputed resources are allocated to. This is a new(er) customer, so there is some merit to dropping the prefix and letting them sort it out based on the current RIR contact(s). However, there is obvious concern over customer service and dropping such a large block of IPs. I'm definitely leaning toward "let the customer (or customer's customer) and the RIR sort it out" if the POC validates the request weighed responsibly against customer age. However, from a customer service perspective, I think we owe it to our customers to make sure a request is legitimate before we knock them offline. With a limited toolset to validate that information, I can't help but feel conflicted. I appreciate all the feedback this thread has generated so far! -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Tuesday, March 13, 2018 8:27 AM To: nanog at nanog.org Subject: RE: Proof of ownership; when someone demands you remove a prefix Yes, absolutely go with the RIR. Only thing I might adjust it whether I let the customer launch a dispute with the RIR before or after I make the change and to me that would depend on the preponderance of the evidence either way. I might give the long term customer the reasonable doubt. A new customer with a new advertisement not so much. Talk to your legal people of course but I would think if the RIR could verify a dispute in progress, you are covered until the dispute is resolved. Seems legally reasonable to me and shows due diligence on your part without you getting in the middle. Steven Naslund Chicago IL >Hi Sean, > >There is a definitive technical means. It's called contact the POC published in WHOIS by the RIR and ask. It isn't flawless and you don't have to like >it, but there it is. > >If you contacted the POC and the POC replied stop, you stop. If the POC was hijacked at the RIR, that's between your customer and the RIR. >The RIR has a standard process and an expert team for dealing with these situations. It's their job. > >Regards, >Bill Herrin From list at satchell.net Tue Mar 13 17:44:04 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 13 Mar 2018 10:44:04 -0700 Subject: Websurfing trouble to .gov and .il.us In-Reply-To: References: Message-ID: On 03/12/2018 10:44 AM, Sam Kretchmer wrote: > specifically http://tierii.iema.state.il.us/TIER2MANAGER/Account/Login.aspx andhttps://www.deadiversion.usdoj.gov/. Wireshark? It could be a problem with the sides having an infinite referral loop. It doesn't necessarily have to be a network problem per se. From lists at mtin.net Tue Mar 13 17:47:16 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 13 Mar 2018 13:47:16 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: I am looking at it from an ARIN justification point. If you are a small operator and need a /24 you have justification if you give customer’s publics, but is it a great line if you are only giving out publics for people who need cameras or need to connect in from the outside world. If I need a /24 and I don’t really use it all am I being shady? It becomes a “how much of a grey area is there” kind of thing. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Mar 13, 2018, at 1:37 PM, William Herrin wrote: > > On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: >> I agree that the global routing table is pretty bloated as is. But what kind of a solution for providers who need to participate in BGP but only need a /25? > > Hi Justin, > > If you need a /25 and BGP for multihoming or anycasting, get a /24. > The cost you impose on the system by using BGP *at all* is much higher > than the cost you impose on the system by consuming less than 250 > "unneeded" Ip addresses. > > I did a cost analysis on a BGP announcement a decade or so ago. The > exact numbers have changed but the bottom line hasn't: it's > ridiculously consumptive. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From nanog-announce at nanog.org Tue Mar 13 17:54:08 2018 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Tue, 13 Mar 2018 17:54:08 +0000 (UTC) Subject: [NANOG-announce] NANOG 73 Call for Presentations is open Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: NANOG 73 Call for Presentations is open Date: Tue, 13 Mar 2018 13:54:05 -0400 Size: 8030 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From job at ntt.net Tue Mar 13 17:59:35 2018 From: job at ntt.net (Job Snijders) Date: Tue, 13 Mar 2018 18:59:35 +0100 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <006601d3baf2$2634e8d0$729eba70$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> <006601d3baf2$2634e8d0$729eba70$@gmail.com> Message-ID: <20180313175935.GC31822@hanna.meerval.net> Dear Sean, On Tue, Mar 13, 2018 at 10:38:49AM -0700, Sean Pedersen wrote: > This is more or less the situation we're in. We contacted the customer > and they informed us the matter is in dispute with the RIR and that > their customer (the assignee) is in the process of resolving the > issue. We have to allow them time to accomplish this. I've asked for > additional information to help us understand the nature of the > dispute. In that time we received another request to stop announcing > the prefix(s) in addition to a new set of prefixes, and a threat to > contact our upstream providers as well as ARIN - which is not the RIR > the disputed resources are allocated to. I've seen disputes too between end users and RIRs - usually this is due to non-payment. It can be helpful to do two things: set a reasonable deadline for the customer to resolve this, and verify with the RIR whether the dispute is actually ongoing or whether the RIR closed the case. Example case: customer said they were in dispute, but RIR indicated that the case was closed. If the RIR closed the case, I'd lean to dropping the announcement. > This is a new(er) customer, so there is some merit to dropping the > prefix and letting them sort it out based on the current RIR > contact(s). However, there is obvious concern over customer service > and dropping such a large block of IPs. Size of the block often is a poor indicator for legitimacy. Kind regards, Job From lists at as23738.net Tue Mar 13 18:01:24 2018 From: lists at as23738.net (lists at as23738.net) Date: Tue, 13 Mar 2018 11:01:24 -0700 Subject: Websurfing trouble to .gov and .il.us In-Reply-To: References: Message-ID: <1520964084.2860408.1301817376.1582D8D5@webmail.messagingengine.com> On Mon, Mar 12, 2018, at 10:44 AM, Sam Kretchmer wrote: > IP's they use, specifically parts of 213.159.132/22. They can surf any This block appears to have shifted over from RIPE into ARIN space. I've seen a few firewalls and filtering systems that block countries or block unallocated/weird/bogon ranges in broken ways (probably more so if it was an enterprise/government/finance situation). They could be locally terminating connections at the entry point or something in a browser, which might produce oddities like the loading/connecting/loading. Alternatively, I've also seen some crappy fw/transparent proxies have problems dealing with IPs that end in .0 and .255 and sometimes .254. From brak at gameservers.com Tue Mar 13 18:06:26 2018 From: brak at gameservers.com (Brian Rak) Date: Tue, 13 Mar 2018 14:06:26 -0400 Subject: Centurylink SOC contact? Message-ID: <74b1d65e-1dab-b932-a6fa-1bcde010f7bb@gameservers.com> Does anyone have a contact for the SOC at centurylink?  I've tried soc at centurylink and noc at centurylink, with no answer. For whatever reason, they're mangling IP address in abuse reports, which requires us to manually review every report.  We'd really like them to stop, and just include the IP address in the body of the report. They seem to be the only ones that do this, pretty much all the other reports we get list a normal IP address. From bob at FiberInternetCenter.com Tue Mar 13 18:08:09 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 13 Mar 2018 11:08:09 -0700 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: Marketplaces - supply and demand and costs to operate as Bill noted (never thought of that) will settle out the need. Thank You Bob Evans CTO > I am looking at it from an ARIN justification point. If you are a small > operator and need a /24 you have justification if you give customer’s > publics, but is it a great line if you are only giving out publics for > people who need cameras or need to connect in from the outside world. If I > need a /24 and I don’t really use it all am I being shady? It becomes a > “how much of a grey area is there” kind of thing. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Mar 13, 2018, at 1:37 PM, William Herrin wrote: >> >> On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: >>> I agree that the global routing table is pretty bloated as is. But >>> what kind of a solution for providers who need to participate in BGP >>> but only need a /25? >> >> Hi Justin, >> >> If you need a /25 and BGP for multihoming or anycasting, get a /24. >> The cost you impose on the system by using BGP *at all* is much higher >> than the cost you impose on the system by consuming less than 250 >> "unneeded" Ip addresses. >> >> I did a cost analysis on a BGP announcement a decade or so ago. The >> exact numbers have changed but the bottom line hasn't: it's >> ridiculously consumptive. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > > From lists at mtin.net Tue Mar 13 18:14:23 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 13 Mar 2018 14:14:23 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? It ARIN, or others for that matter, going to relax those requirements? If I am an ISP and need to do BGP, maybe because I have a big downstream customer, I have to have a /24 to participate in BGP. I see these scenarios more and more. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Mar 13, 2018, at 2:08 PM, Bob Evans wrote: > > Marketplaces - supply and demand and costs to operate as Bill noted (never > thought of that) will settle out the need. > > Thank You > Bob Evans > CTO > > > > >> I am looking at it from an ARIN justification point. If you are a small >> operator and need a /24 you have justification if you give customer’s >> publics, but is it a great line if you are only giving out publics for >> people who need cameras or need to connect in from the outside world. If I >> need a /24 and I don’t really use it all am I being shady? It becomes a >> “how much of a grey area is there” kind of thing. >> >> >> Justin Wilson >> j2sw at mtin.net >> >> www.mtin.net >> www.midwest-ix.com >> >>> On Mar 13, 2018, at 1:37 PM, William Herrin wrote: >>> >>> On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: >>>> I agree that the global routing table is pretty bloated as is. But >>>> what kind of a solution for providers who need to participate in BGP >>>> but only need a /25? >>> >>> Hi Justin, >>> >>> If you need a /25 and BGP for multihoming or anycasting, get a /24. >>> The cost you impose on the system by using BGP *at all* is much higher >>> than the cost you impose on the system by consuming less than 250 >>> "unneeded" Ip addresses. >>> >>> I did a cost analysis on a BGP announcement a decade or so ago. The >>> exact numbers have changed but the bottom line hasn't: it's >>> ridiculously consumptive. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> >>> -- >>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>> Dirtside Systems ......... Web: >>> >> >> > > From bill at herrin.us Tue Mar 13 18:20:39 2018 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2018 14:20:39 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <006601d3baf2$2634e8d0$729eba70$@gmail.com> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> <006601d3baf2$2634e8d0$729eba70$@gmail.com> Message-ID: On Tue, Mar 13, 2018 at 1:38 PM, Sean Pedersen wrote: > This is more or less the situation we're in. We contacted the customer and they informed us the matter is in dispute with the RIR and that their customer (the assignee) is in the process of resolving the issue. We have to allow them time to accomplish this. I've asked for additional information to help us understand the nature of the dispute. In that time we received another request to stop announcing the prefix(s) in addition to a new set of prefixes, and a threat to contact our upstream providers as well as ARIN - which is not the RIR the disputed resources are allocated to. Sean, If you've been announcing the route for the past year before this complaint came in then you are, of course, correct. It would be unconscionable to suddenly cut a customer over a paperwork problem. > This is a new(er) customer, so there is some merit to dropping the prefix and letting them sort it out based on the current RIR contact(s). However, there is obvious concern over customer service and dropping such a large block of IPs. If you've been announcing the route for the past week before this complaint came in then you are causing someone else a big operational headache. You must stop. Insist that the customer straighten out their problem with the RIR before you announce the route. You can ignore the threat to contact ARIN. ARIN does not involve itself in routing disputes. Your upstream (and their upstream, et cetera) will act to preserve their reputations. If that includes manually blocking some of your announcements, you'll have a devil of a time undoing it later. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From martin at airwire.ie Tue Mar 13 18:24:22 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 13 Mar 2018 18:24:22 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: Hi, needing a /24 to participate in BGP has always been sort of a world-wide standard. Even before the explosion of the IPv4 BGP full table (which has more than doubled in the last decade), that was the standard. Because ..... if carriers (and ISPs) accepted upstream < /24, then you'd have an entirely different animal at large. The issue here is not ARIN, or RIPE, or APNIC, or AfriNIC etc. The issue is, that the industry standard is to filter the upstream table and not to accept smaller than /24 ... so even if the policies were changed your Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? It ARIN, or others for that matter, going to relax those requirements? If I am an ISP and need to do BGP, maybe because I have a big downstream customer, I have to have a /24 to participate in BGP. I see these scenarios more and more. > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Mar 13, 2018, at 2:08 PM, Bob Evans wrote: >> >> Marketplaces - supply and demand and costs to operate as Bill noted (never >> thought of that) will settle out the need. >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> I am looking at it from an ARIN justification point. If you are a small >>> operator and need a /24 you have justification if you give customer’s >>> publics, but is it a great line if you are only giving out publics for >>> people who need cameras or need to connect in from the outside world. If I >>> need a /24 and I don’t really use it all am I being shady? It becomes a >>> “how much of a grey area is there” kind of thing. >>> >>> >>> Justin Wilson >>> j2sw at mtin.net >>> >>> www.mtin.net >>> www.midwest-ix.com >>> >>>> On Mar 13, 2018, at 1:37 PM, William Herrin wrote: >>>> >>>> On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: >>>>> I agree that the global routing table is pretty bloated as is. But >>>>> what kind of a solution for providers who need to participate in BGP >>>>> but only need a /25? >>>> >>>> Hi Justin, >>>> >>>> If you need a /25 and BGP for multihoming or anycasting, get a /24. >>>> The cost you impose on the system by using BGP *at all* is much higher >>>> than the cost you impose on the system by consuming less than 250 >>>> "unneeded" Ip addresses. >>>> >>>> I did a cost analysis on a BGP announcement a decade or so ago. The >>>> exact numbers have changed but the bottom line hasn't: it's >>>> ridiculously consumptive. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>>> Dirtside Systems ......... Web: >>>> >>> >>> >> >> > -- 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 valdis.kletnieks at vt.edu Tue Mar 13 18:27:37 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 13 Mar 2018 14:27:37 -0400 Subject: Websurfing trouble to .gov and .il.us In-Reply-To: References: Message-ID: <127858.1520965657@turing-police.cc.vt.edu> On Mon, 12 Mar 2018 17:44:47 -0000, Sam Kretchmer said: > I am part of a small ISP based in Chicago. We have several clients > complaining of an inability to hit a couple specific government websites, > specifically http://tierii.iema.state.il.us/TIER2MANAGER/Account/Login.aspx and > https://www.deadiversion.usdoj.gov/. It does seem to be related to the IP's > they use, specifically parts of 213.159.132/22 First thing that comes to mind: Fire up wireshark and see if anything pops out. Second thing: PMTU black hole or similar - the 3 packet handshake completes, and TLS fires up, and then comes to a screeching halt when something large causes a MTU-sized packet to happen. Double-check the pages, make sure they aren't doing something squirrelly like fetching CSS from some *other* site that's down or PMTU black holed. Oh, and 519 lashes with a wet noodle for the IL state division of IT for having a Login.aspx on an http: site. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From bill at herrin.us Tue Mar 13 18:40:48 2018 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2018 14:40:48 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: On Tue, Mar 13, 2018 at 2:14 PM, Justin Wilson wrote: > Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? Hi Justin, If you can't justify a /24 with a single hypervisor, you aren't being creative enough. Seriously. Optimize your network _plan_ for address consumption. You need a /29 (or two /30s) to connect each VM to the primary and backup router VMs and that's before you assign virtual IPs to web servers on the VMs. In your initial allocation, ARIN won't hold you to your plan. You just have to have a plan where the numbers add up to justified need. If you're not comfortable going it on your own, contract someone who's been through it before to shepherd you through the process. ARIN's process is convoluted and arcane, but if you're ready to pay the cost of multihoming you truly won't have any trouble justifying an ARIN /24. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Tue Mar 13 18:58:32 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 18:58:32 +0000 Subject: Proof of ownership; when someone demands you remove a prefix Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> The fact that it is a newer customer would make me talk to the RIR direct and verify that a dispute is really in progress. I would also look at some looking glasses and see if the prefix is being announced elsewhere, if so that might indicate that your customer is indeed stepping on a legit owner. I would also make it clear to the new customer that they are on thin ice here to light a fire under their process. Let them know that it is up to them to convince you that they are the legit owner. No one wants to lose a customer but they are threatening your business and putting you in legal jeopardy if they are not legit. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen >Sent: Tuesday, March 13, 2018 12:39 PM >To: nanog at nanog.org >Subject: RE: Proof of ownership; when someone demands you remove a prefix > >This is more or less the situation we're in. We contacted the customer and they informed us the matter is in dispute with the RIR and that their >customer (the assignee) is in the process of resolving the issue. We have to allow them time to accomplish this. I've asked for additional information >to help us understand the nature of the dispute. In that time we received another request to stop announcing the prefix(s) in addition to a new set of >prefixes, and a threat to contact our upstream providers as well as ARIN - which is not the RIR the disputed resources are allocated to. > >This is a new(er) customer, so there is some merit to dropping the prefix and letting them sort it out based on the current RIR contact(s). However, >there is obvious concern over customer service and dropping such a large block of IPs. > >I'm definitely leaning toward "let the customer (or customer's customer) and the RIR sort it out" if the POC validates the request weighed responsibly >against customer age. However, from a customer service perspective, I think we owe it to our customers to make sure a request is legitimate before we >knock them offline. With a limited toolset to validate that information, I can't help but feel conflicted. > >I appreciate all the feedback this thread has generated so far! From SNaslund at medline.com Tue Mar 13 19:04:51 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 19:04:51 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E757E@MUNPRDMBXA1.medline.com> It might be archaic thinking but back in the day routers were not all that powerful and table size was a concern so /24 was it. ARIN kind of figured if you were smaller than a /24 you were not really on their radar and you needed to talk to an upstream provider. It is a big system to manage and they had to draw a line somewhere. Today that is kind of painful but it will be really difficult to change on a global basis. I would work on finding an understanding upstream provider that would let you announce one of their blocks via multiple upstream providers. I might remind them that allowing me to do that kind of ties me to their service which is good for them. I have found that a lot of carriers don't mind doing that as long as you can justify the reasoning which it looks like you can. As far as justification for the RIR, it should be sufficient to say that you need redundant upstream carriers as a service provider and cannot make that work with less than a /24. It would also help to show an IPv6 strategy that really needs the IPv4 for infrastructure purposes. It is not all about utilization only. The RIRs know how that works. I know that ARIN for sure can look at a network architecture in addition to pure utilization which is why global entities can often get a larger allocation to allow for regionally based sub-allocations. I think you will find them cooperative. Feel free to talk to them about it. They really are reasonable people who get it. Steven Naslund Chicago IL >On Tue, Mar 13, 2018 at 2:14 PM, Justin Wilson wrote: > Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? From mdittmer at waverlyutilities.com Tue Mar 13 17:54:12 2018 From: mdittmer at waverlyutilities.com (Matthew Dittmer) Date: Tue, 13 Mar 2018 17:54:12 +0000 Subject: contact for www.upack.com (http 403) Message-ID: <9AE4E6EC1DA2464D88414A724F1DA56B155BD183@Mail.wlpnet.internal> Is there a contact at upack.com that can help us? All of our subscribers receive an error 403 access denied. Thank you, Matt Dittmer AS20298 From sfisher at cymru.com Tue Mar 13 16:44:36 2018 From: sfisher at cymru.com (Scott Fisher) Date: Tue, 13 Mar 2018 12:44:36 -0400 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: Mike, All of the architecture's listed are pretty good. Nfsen is great if you have multiple routers exporting various netflow versions with a single daemon, but its a bit older and not as pretty/quick as something using elastic. Team Cymru has a netflow analyzer that matches your netflow data to known 'bad IPs'. http://www.team-cymru.org/Flow-Sonar.html Thanks, Scott Thanks, Scott On 3/12/18 7:24 PM, mike.lyon at gmail.com wrote: > Howdy! > > Checking out various Netflow tools and wanted to see what others are using? > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. > > Also curious about on-prem solutions as well. > > Thanks! > Mike > From spedersen.lists at gmail.com Tue Mar 13 19:48:40 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Tue, 13 Mar 2018 12:48:40 -0700 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> Message-ID: <00a001d3bb04$49fa4c80$ddeee580$@gmail.com> I appreciate everyone's input and will incorporate it into our internal policies going forward. I also want to assure everyone who has taken the time to read or respond that we're going about this methodically; our customer is involved and is responding promptly and their customer is has opened a case with the RIR. We're in the process of following up with the RIR. Our goal is not to cause an 'operational headache' for anyone, but exactly the opposite. Thanks again for all of your feedback and responses. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Tuesday, March 13, 2018 11:59 AM To: nanog at nanog.org Subject: Re: Proof of ownership; when someone demands you remove a prefix The fact that it is a newer customer would make me talk to the RIR direct and verify that a dispute is really in progress. I would also look at some looking glasses and see if the prefix is being announced elsewhere, if so that might indicate that your customer is indeed stepping on a legit owner. I would also make it clear to the new customer that they are on thin ice here to light a fire under their process. Let them know that it is up to them to convince you that they are the legit owner. No one wants to lose a customer but they are threatening your business and putting you in legal jeopardy if they are not legit. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Pedersen >Sent: Tuesday, March 13, 2018 12:39 PM >To: nanog at nanog.org >Subject: RE: Proof of ownership; when someone demands you remove a prefix > >This is more or less the situation we're in. We contacted the customer and they informed us the matter is in dispute with the RIR and that their >customer (the assignee) is in the process of resolving the issue. We have to allow them time to accomplish this. I've asked for additional information >to help us understand the nature of the dispute. In that time we received another request to stop announcing the prefix(s) in addition to a new set of >prefixes, and a threat to contact our upstream providers as well as ARIN - which is not the RIR the disputed resources are allocated to. > >This is a new(er) customer, so there is some merit to dropping the prefix and letting them sort it out based on the current RIR contact(s). However, >there is obvious concern over customer service and dropping such a large block of IPs. > >I'm definitely leaning toward "let the customer (or customer's customer) and the RIR sort it out" if the POC validates the request weighed responsibly >against customer age. However, from a customer service perspective, I think we owe it to our customers to make sure a request is legitimate before we >knock them offline. With a limited toolset to validate that information, I can't help but feel conflicted. > >I appreciate all the feedback this thread has generated so far! From ttauber at 1-4-5.net Tue Mar 13 20:09:00 2018 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 13 Mar 2018 16:09:00 -0400 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <20180313175935.GC31822@hanna.meerval.net> References: <004301d3ba32$70db0790$529116b0$@gmail.com> <346E46FE-0E07-439E-88EE-DBC33FC447BC@gmail.com> <6743D3FD-88EC-4F60-8023-3D186243D984@dataix.net> <002401d3bad6$cf3dae10$6db90a30$@gmail.com> <9578293AE169674F9A048B2BC9A081B402A31E734C@MUNPRDMBXA1.medline.com> <006601d3baf2$2634e8d0$729eba70$@gmail.com> <20180313175935.GC31822@hanna.meerval.net> Message-ID: On Tue, Mar 13, 2018 at 1:59 PM, Job Snijders wrote: > Dear Sean, > > On Tue, Mar 13, 2018 at 10:38:49AM -0700, Sean Pedersen wrote: > > This is more or less the situation we're in. We contacted the customer > > and they informed us the matter is in dispute with the RIR and that > > their customer (the assignee) is in the process of resolving the > > issue. We have to allow them time to accomplish this. I've asked for > > additional information to help us understand the nature of the > > dispute. In that time we received another request to stop announcing > > the prefix(s) in addition to a new set of prefixes, and a threat to > > contact our upstream providers as well as ARIN - which is not the RIR > > the disputed resources are allocated to. > > I've seen disputes too between end users and RIRs - usually this is due > to non-payment. It can be helpful to do two things: set a reasonable > deadline for the customer to resolve this, and verify with the RIR > whether the dispute is actually ongoing or whether the RIR closed the > case. Example case: customer said they were in dispute, but RIR > indicated that the case was closed. If the RIR closed the case, I'd lean > to dropping the announcement. > What are people's experiences with the various RIRs discussion of these situations? I believe sometimes (though could be mistaken) they consider these matters confidential. Perhaps there are official RIR policies stated on how they handle such. It can be frustrating I'm sure. For the situation you describe, I'd be inclined to say that if the RIR's posted registration matches what you've got and has been so for a while, that ought to stand. Tony From lee.howard at retevia.net Tue Mar 13 20:38:20 2018 From: lee.howard at retevia.net (Lee Howard) Date: Tue, 13 Mar 2018 16:38:20 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <392fbd4b844f7bcb6e185c9d94527156.squirrel@66.201.44.180> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: <6cf9a363-b1d7-8c94-f908-3ad350f0c6d9@retevia.net> ARIN's fee for a /24 is $250 https://www.arin.net/fees/fee_schedule.html That's about 1/15th of the price of a /24 on the market. Of course, they don't have any /24s. Unless, of course, you're deploying IPv6 and just need the /24 for your NAT64 box, DS-Lite AFTR, or MAP-T BR. https://www.arin.net/policy/nrpm.html#four10 Lee PS: Let me know if you're considering this; I'll help. On 03/13/2018 01:19 PM, Justin Wilson wrote: > On the consulting side, I do smaller than /24 blocks to customers over tunnels. So far this is the only option we have found that works for the smaller ISP. We all know the routing table is bloated. We all know everyone *should* be moving toward IPV6. A whole different discussion. But, for now you have a subset of operators that are big enough to do BGP, maybe join an exchange, but not big enough to afford buying v4 space for each of their customers. So they are utilizing a full /24 just to utilize it. Things such as doing 1:many nat at each tower, doing Carrier Grade nat, and other things make it where they don’t necessarily need an IP per customer. We all know that is ideal, but it’s not practical for the small to medium ISP. Folks have brought up the argument that buying IPS is just the cost of doing business these days. I argue that it isn’t. I see networks with 2000 users and only a /24 running along very happy. > > I agree that the global routing table is pretty bloated as is. But what kind of a solution for providers who need to participate in BGP but only need a /25? I can’t see going below that. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Mar 13, 2018, at 10:56 AM, Naslund, Steve wrote: >> >> >> Yes, exactly right. You would probably have to tunnel the /27 back to where the >/24 lives. That's the only way I can see of it working "anywhere". That's a technically valid solution but maybe not so hot if you are looking for high redundancy/availability since you are dependent on the tunnel being up and working. >> >> As always the reputation of the aggregate is going to be critical as to how well this works for you. It seems to me that increasingly these "portable" blocks have murky histories as spam and malware sources. I would rather have a block assigned by a reputable upstream provider than to do this. >> >> Steven Naslund >> Chicago IL >> >>> Le 2018-01-04 20:16, Job Snijders a écrit : >>>> On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: >>>> >>>>> I have stumbled upon this site [1] which seems to offer /27 IPv4 >>>>> leasing. >>>>> They also claim "All of our IPv4 address space can be used on any >>>>> network in any location." >>>>> >>>>> I thought that the smallest prefix size one could get routed >>>>> globally is /24? >>>> >>>> Yes >>>> >>>> So how does this work? >>>> Probably with GRE, IPIP or OpenVPN tunnels. >>>> >>>> Kind regards, >>>> >>>> Job >>> IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) >>> neighbors. If I run a global (or regional) network, I may advertise this >>> /24 -- or rather an aggregate covering it -- over my diverse >>> interconnection with neighbors, your /27 being part of the chunk and >>> routed to you internally (if you're va customer)-- no need for >>> encapsulation efforts. Similar scenario may be multi-upstream, subject >>> to acceptance of "punching holes in aggregates"... Am I missing >>> something? What's the trigger for doing tunneling here? >>> >>> Happy New Year '18, by the way ! >>> >>> mh >>> >> > From mysidia at gmail.com Tue Mar 13 22:11:00 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 13 Mar 2018 17:11:00 -0500 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> Message-ID: On Tue, Mar 13, 2018 at 1:58 PM, Naslund, Steve wrote: I would consider that.... the RIR WHOIS records are currently the network's authoritative source of truth about IP number management. For 99% of situations there's no such proper thing as "delaying addressing abuse" so someone claims they can go dispute the RIR record. The rare exception would be you have documented the original contacts and LOAs, and a stranger who is a new WHOIS POC sends a request that you disrupt what has now been a long-established operational network, and your customer is objecting/claiming the WHOIS record has been hijacked. In that case: avoid disrupting the long-established announcement: to allow the customer 5 to 10 days to get it fixed with the RIR or show you a court order against the false WHOIS contacts. If you started announcing a newly setup prefix, and it immediately resulted in a phone call or e-mail within a few weeks from the resource holder organization's RIR-listed WHOIS contact, then obviously corrective actions are in order to pull that announcement quickly, after confirming with the org. listed in WHOIS.... That would mean your new announcement is credibly reported as abuse, AND "claim of dispute in progress with the RIR" does not hold water as any kind of basis to continue your AS causing harm to this resource holder. I would not blame a legitimate WHOIS contact for immediately escalating to upstreams and ARIN for emergency assistance: if they don't receive an adequate resolution and removal of the rogue announcement within 15 minutes or so....... While ARIN cannot do anything about the routing issues; they might be able to confirm the history of the resource.... the Rogue announcement might include the IP space of 1 or more DNS or SMTP Servers related to one or more domain names that are also listed WHOIS E-mail contacts. You know.... because ARIN stopped supporting using PGP/GPG keys with POCs and digitally signed e-mail templates to formally authorize modifications : "Wait while we dispute with the RIR" could very well truly mean: ----- "Please wait while we try to use our rogue IP space announcement to quickly setup some fake SMTP servers on hijacked IPs while we gear up our spamming campaign to maximum effectiveness and misuse ARIN's single-factor Email-based password recovery process to fraudulently gain account access and modify resource WHOIS POC details to make it look more like we're the plausible resource holder....." > The fact that it is a newer customer would make me talk to the RIR direct and verify > that a dispute is really in progress. [snip] > Steven Naslund > Chicago IL -- -JH From madsushi at gmail.com Tue Mar 13 22:18:33 2018 From: madsushi at gmail.com (Chase Christian) Date: Tue, 13 Mar 2018 15:18:33 -0700 Subject: Spiffy Netflow tools? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4E7FE5@RTC-EXCH01.RESERVE.LDS> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <20180313154404.GJ25899@bamboo.slabnet.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4E7FE5@RTC-EXCH01.RESERVE.LDS> Message-ID: +1 for ElastiFlow. Couldn't be easier to set up and run. Logstash has native support for netflow and sflow now via codecs. Kibana is an easy-to-use dashboard. I trimmed out a bunch of stuff in the ElastiFlow config that assumed a unidirectional network (like a corporate site). On Tue, Mar 13, 2018 at 8:48 AM, Luke Guillory wrote: > There is also https://github.com/robcowart/elastiflow which uses the ELK > stack. > > > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.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. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hugo Slabbert > Sent: Tuesday, March 13, 2018 10:44 AM > To: Fredrik Korsbäck > Cc: nanog at nanog.org > Subject: Re: Spiffy Netflow tools? > > > On Tue 2018-Mar-13 00:50:26 +0100, Fredrik Korsbäck > wrote: > > > >Kentik is probably top of the foodchain right now. > > > >But they are certainly not alone in the biz. Ontop of my head... > > > >* Flowmon > >* Talaia > >* Arbor Peakflow > >* Deepfield > >* Pmacct + supporting toolkit > >* NFsen/Nfdump/AS-stats > >* Put kibana/ES infront of any collector > > Logstash has a netflow plugin as of 5.x or something > (https://www.elastic.co/guide/en/logstash/current/netflow-module.html) to > act as a collector. > > A walkthrough: > http://www.routereflector.com/2017/07/elk-as-a-free-netflow- > ipfix-collector-and-visualizer/ > > Using the logstash module setup thing adds a whole bunch of pretty netflow > graphs and visualizations and such into Kibana for you. > > Caveat: > Supports netflow v5 and v9, but does not indicate support for IPFIX > explicitly. It definitely does not support sFlow, though if you really > want you can stick sflowtool in front of it to translate sFlow->netflow, > e.g. http://blog.sflow.com/2011/12/sflowtool.html. > > >* Solarwinds something something > >* Different vendor toolkits > > > >-- > >hugge > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From SNaslund at medline.com Tue Mar 13 22:22:23 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 13 Mar 2018 22:22:23 +0000 Subject: Proof of ownership; when someone demands you remove a prefix In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A31E756C@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A31E773D@MUNPRDMBXA1.medline.com> That is about like saying email from you is the authoritative source of truth about you....unless your account is hacked. Sorry but in the real business world we give long standing customers the benefit of the doubt. We all make judgments every day in our real lives about who we believe and who we don't believe. It is not rare to know who the original contact for your customer is if you have any kind of provisioning records at all. Nothing is automatic or a set procedure in this circumstance. It's about like proving a false credit card charge...does the claim make sense or not. At the end of the day the RIR has to determine who owns the account. Right now, this minute you have to make the call based on incomplete information about what is best for your business, your customer, the Internet community, and your professional reputation. Steven Naslund Chicago IL >-----Original Message----- >From: Jimmy Hess [mailto:mysidia at gmail.com] >Sent: Tuesday, March 13, 2018 5:11 PM >To: Naslund, Steve >Cc: nanog at nanog.org >Subject: Re: Proof of ownership; when someone demands you remove a prefix > >I would consider that.... the RIR WHOIS records are currently the network's authoritative source of truth about IP number management. > >For 99% of situations there's no such proper thing as "delaying addressing abuse" >so someone claims they can go dispute the RIR record. The rare exception >would be you have documented the original contacts and LOAs, and a stranger who is a new WHOIS POC sends a request that you disrupt what has now >been a long-established operational network, and your customer is objecting/claiming the WHOIS record has been hijacked. From nvitaly at gmail.com Wed Mar 14 01:21:48 2018 From: nvitaly at gmail.com (Vitaly Nikolaev) Date: Tue, 13 Mar 2018 21:21:48 -0400 Subject: Spiffy Netflow tools? In-Reply-To: References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <20180313154404.GJ25899@bamboo.slabnet.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4E7FE5@RTC-EXCH01.RESERVE.LDS> Message-ID: How scalable is ElastiFlow ? Let say I will dump 90kflow/s, how big elasticsearch farm do I need to comfortably store and work with at least couple weeks of data ? right now in NFSEN it takes about 3T in disk space and minutes for simple reports if it spans few time default time intervals. Thank you. On Tue, Mar 13, 2018 at 6:18 PM, Chase Christian wrote: > +1 for ElastiFlow. Couldn't be easier to set up and run. Logstash has > native support for netflow and sflow now via codecs. Kibana is an > easy-to-use dashboard. I trimmed out a bunch of stuff in the ElastiFlow > config that assumed a unidirectional network (like a corporate site). > > On Tue, Mar 13, 2018 at 8:48 AM, Luke Guillory > wrote: > > > There is also https://github.com/robcowart/elastiflow which uses the ELK > > stack. > > > > > > > > > > > > Luke Guillory > > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 > > Fax: 985.536.0300 > > Email: lguillory at reservetele.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. . > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hugo Slabbert > > Sent: Tuesday, March 13, 2018 10:44 AM > > To: Fredrik Korsbäck > > Cc: nanog at nanog.org > > Subject: Re: Spiffy Netflow tools? > > > > > > On Tue 2018-Mar-13 00:50:26 +0100, Fredrik Korsbäck > > wrote: > > > > > >Kentik is probably top of the foodchain right now. > > > > > >But they are certainly not alone in the biz. Ontop of my head... > > > > > >* Flowmon > > >* Talaia > > >* Arbor Peakflow > > >* Deepfield > > >* Pmacct + supporting toolkit > > >* NFsen/Nfdump/AS-stats > > >* Put kibana/ES infront of any collector > > > > Logstash has a netflow plugin as of 5.x or something > > (https://www.elastic.co/guide/en/logstash/current/netflow-module.html) > to > > act as a collector. > > > > A walkthrough: > > http://www.routereflector.com/2017/07/elk-as-a-free-netflow- > > ipfix-collector-and-visualizer/ > > > > Using the logstash module setup thing adds a whole bunch of pretty > netflow > > graphs and visualizations and such into Kibana for you. > > > > Caveat: > > Supports netflow v5 and v9, but does not indicate support for IPFIX > > explicitly. It definitely does not support sFlow, though if you really > > want you can stick sflowtool in front of it to translate sFlow->netflow, > > e.g. http://blog.sflow.com/2011/12/sflowtool.html. > > > > >* Solarwinds something something > > >* Different vendor toolkits > > > > > >-- > > >hugge > > > > -- > > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > > pgp key: B178313E | also on Signal > > > -- -- Vitaly Nikolaev From luuk.hendriks at utwente.nl Wed Mar 14 09:57:31 2018 From: luuk.hendriks at utwente.nl (Luuk Hendriks) Date: Wed, 14 Mar 2018 10:57:31 +0100 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: <20180314095730.f2jhcxbsi4rqog3r@corley.shackle.nl> IPFIXcol+fbitdump is what we use for our IPFIX measurements: https://github.com/CESNET/ipfixcol/ Can do NetFlow v5/v9 and sFlow as well. luuk On Mon 12 Mar 2018, 16:24, mike.lyon at gmail.com wrote: > Howdy! > > Checking out various Netflow tools and wanted to see what others are using? > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. > > Also curious about on-prem solutions as well. > > Thanks! > Mike From Brett.Wentworth at centurylink.com Tue Mar 13 21:02:54 2018 From: Brett.Wentworth at centurylink.com (Wentworth, Brett) Date: Tue, 13 Mar 2018 21:02:54 +0000 Subject: Centurylink SOC contact? In-Reply-To: References: <74b1d65e-1dab-b932-a6fa-1bcde010f7bb@gameservers.com> <7E920472-48D7-4805-8199-67C10072AA5E@level3.com> Message-ID: <24FAE12C-E2C8-419E-B6AC-12CC8C58E263@level3.com> I responded off list. Brett -----Original Message----- From: NANOG on behalf of Brian Rak Date: Tuesday, March 13, 2018 at 12:08 PM To: "nanog at nanog.org" Subject: Centurylink SOC contact? Does anyone have a contact for the SOC at centurylink? I've tried soc at centurylink and noc at centurylink, with no answer. For whatever reason, they're mangling IP address in abuse reports, which requires us to manually review every report. We'd really like them to stop, and just include the IP address in the body of the report. They seem to be the only ones that do this, pretty much all the other reports we get list a normal IP address. This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From paul_reichart at wiband.com Wed Mar 14 15:34:06 2018 From: paul_reichart at wiband.com (Paul Reichart) Date: Wed, 14 Mar 2018 15:34:06 +0000 Subject: Office365 and a new IP address Message-ID: Wondering if anyone on the list has ever set up a mail filtering appliance or server on new IP address and had to deal with 451 messages from Office 365. We're processing a large volume of mail and seem to be throttled by O365. Seeing something like this: 451 4.7.500 Server busy. Please try again later from [x.x.x.x]. (AS77713180) [.....outlook.com ]. We own the IP block and the address itself is not on any block lists. It's been going on for a few days now, pissing off a lot of our customers. As expected O365's front line support is totally useless. Any advice would be appreciated! From zvernhout at gmail.com Wed Mar 14 21:26:43 2018 From: zvernhout at gmail.com (Matt Vernhout) Date: Wed, 14 Mar 2018 17:26:43 -0400 Subject: Office365 and a new IP address In-Reply-To: References: Message-ID: Paul, Are you properly rate limiting and warming up the new IPs sending volumes or just sending at normal speeds? Are you properly authenticating your email with SPF, DKIM and SPF as per the Postmaster page suggestions for sending email? Are you properly enrolled in SNDS, Junk Mail Reporting etc... More self help tips and how to contact MSFT for support can be found here: https://postmaster.live.com/pm/troubleshooting.aspx Cheers, Matt On Wed, Mar 14, 2018 at 11:34 AM, Paul Reichart wrote: > Wondering if anyone on the list has ever set up a mail filtering appliance > or server on new IP address and had to deal with 451 messages from Office > 365. > > We're processing a large volume of mail and seem to be throttled by O365. > Seeing something like this: > 451 4.7.500 Server busy. Please try again later from [x.x.x.x]. > (AS77713180) [.....outlook.com ]. > > We own the IP block and the address itself is not on any block lists. > > It's been going on for a few days now, pissing off a lot of our customers. > As expected O365's front line support is totally useless. > > Any advice would be appreciated! > > > > From drew.weaver at thenap.com Thu Mar 15 12:48:00 2018 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 15 Mar 2018 12:48:00 +0000 Subject: Finding scale in Columbus, OH Message-ID: <2fb36bd91b1a4824a4222c177b4e0be8@EXCHANGE2K13.thenap.com> Hello, We've been running into some trouble finding Internet connectivity that will scale (100G) in Central Ohio. So we decided to try and find transport that would scale to other areas that have better Internet infrastructure (CLE, CIN, CHI, ATL, WDC/ASH), our success in this has been surprisngly limited. I know that AWS just put a facility in this area and Facebook is either building one or it is already completed so there must be someone either leasing fiber/transport or they built their own which means that somebody is still doing that kind of construction in this area. Has anyone completed any projects recently with any success at scale in Central Ohio? If so, could you share how you achieved this, either on-list or off-list? Thank you, -Drew From harry at harryreeder.co.uk Thu Mar 15 11:35:37 2018 From: harry at harryreeder.co.uk (Harry Reeder) Date: Thu, 15 Mar 2018 11:35:37 +0000 Subject: Google / GMail Geolocation Message-ID: Hi Folks, Wondering if anyone has a contact at Google who can help - I've a customer who's attempted to log in from one of our IPs (which comes from one of Cogent's /16 blocks) however they get an automated email response from Google saying that they're logging in from Hong Kong, and the login was prevented for security reasons (as someone may have their password). For reference, the whois response shows Washington DC, and refers to Cogent's rwhois which places us correctly at Telehouse London. Tools like Maxmind also have our location correct. Is there somewhere I can go to get this corrected for our leased IP ranges? (I am aware that the long term solution is to get our own IP space - I am working on that, I just don't have enough of a business case yet) Off-list replies also welcome. Thanks Harry From paul_reichart at wiband.com Wed Mar 14 22:04:37 2018 From: paul_reichart at wiband.com (Paul Reichart) Date: Wed, 14 Mar 2018 22:04:37 +0000 Subject: Office365 and a new IP address In-Reply-To: References: Message-ID: No, unfortunately my appliance doesn’t have a method for rate limiting. I’ve had to replace my old appliance and move it to a new IP. My incoming volume of mail to be filtered is far higher than the throttle anyway. For the most part my customer domains have SPF records that point to my outgoing hostname. Yep, enrolled in all those. However it seems the suggestions on postmaster.live.com site only apply to Outlook.com/Hotmail and not Office 365 tenants. What it boils down to is I’m looking for a method to speed up this IP reputation throttling. I appreciate the suggestions. Thanks From: Matt Vernhout [mailto:zvernhout at gmail.com] Sent: March 14, 2018 4:27 PM To: Paul Reichart Cc: nanog at nanog.org Subject: Re: Office365 and a new IP address Paul, Are you properly rate limiting and warming up the new IPs sending volumes or just sending at normal speeds? Are you properly authenticating your email with SPF, DKIM and SPF as per the Postmaster page suggestions for sending email? Are you properly enrolled in SNDS, Junk Mail Reporting etc... More self help tips and how to contact MSFT for support can be found here: https://postmaster.live.com/pm/troubleshooting.aspx Cheers, Matt On Wed, Mar 14, 2018 at 11:34 AM, Paul Reichart > wrote: Wondering if anyone on the list has ever set up a mail filtering appliance or server on new IP address and had to deal with 451 messages from Office 365. We're processing a large volume of mail and seem to be throttled by O365. Seeing something like this: 451 4.7.500 Server busy. Please try again later from [x.x.x.x]. (AS77713180) [.....outlook.com ]. We own the IP block and the address itself is not on any block lists. It's been going on for a few days now, pissing off a lot of our customers. As expected O365's front line support is totally useless. Any advice would be appreciated! From shefys at gmail.com Thu Mar 15 15:56:31 2018 From: shefys at gmail.com (Yury Shefer) Date: Thu, 15 Mar 2018 08:56:31 -0700 Subject: Google / GMail Geolocation In-Reply-To: References: Message-ID: Have you tried to contact G through the following form? https://support.google.com/websearch/contact/ip On Thu, Mar 15, 2018 at 4:35 AM, Harry Reeder wrote: > Hi Folks, > > Wondering if anyone has a contact at Google who can help - I've a customer > who's attempted to log in from one of our IPs (which comes from one of > Cogent's /16 blocks) however they get an automated email response from > Google saying that they're logging in from Hong Kong, and the login was > prevented for security reasons (as someone may have their password). For > reference, the whois response shows Washington DC, and refers to Cogent's > rwhois which places us correctly at Telehouse London. Tools like Maxmind > also have our location correct. > > Is there somewhere I can go to get this corrected for our leased IP ranges? > (I am aware that the long term solution is to get our own IP space - I am > working on that, I just don't have enough of a business case yet) > > Off-list replies also welcome. > > Thanks > Harry > From vstipo at gmail.com Thu Mar 15 21:22:08 2018 From: vstipo at gmail.com (Stipo) Date: Thu, 15 Mar 2018 14:22:08 -0700 Subject: Spiffy Netflow tools? In-Reply-To: <20180314095730.f2jhcxbsi4rqog3r@corley.shackle.nl> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <20180314095730.f2jhcxbsi4rqog3r@corley.shackle.nl> Message-ID: +1 ElastiFlow, the templates are great, a great quickstart to using netflow on elk stack. -Vinny Stipo On Wed, Mar 14, 2018 at 2:57 AM, Luuk Hendriks wrote: > IPFIXcol+fbitdump is what we use for our IPFIX measurements: > https://github.com/CESNET/ipfixcol/ > > Can do NetFlow v5/v9 and sFlow as well. > > luuk > > On Mon 12 Mar 2018, 16:24, mike.lyon at gmail.com wrote: > > Howdy! > > > > Checking out various Netflow tools and wanted to see what others are > using? > > > > Kentik is cool. Are they the only SaaS based flow digester? I don’t seem > to see any others. > > > > Also curious about on-prem solutions as well. > > > > Thanks! > > Mike > From nanog at ics-il.net Thu Mar 15 21:29:52 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 15 Mar 2018 16:29:52 -0500 (CDT) Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: <1110501105.2864.1521149387667.JavaMail.mhammett@ThunderFuck> (To the thread in general) Those of us using RouterOS have to suffer a bit longer to get ASN-usefulness out of these tools. Well, natively. I'm just about done with using pmacct to inject the ASN into into a local Flow Analyzer. Maybe I can figure out at some point how to get pmacct to spit out a new netflow with the ASN information so these other tools can work out of the box. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "mike lyon" To: "NANOG list" Sent: Monday, March 12, 2018 6:24:51 PM Subject: Spiffy Netflow tools? Howdy! Checking out various Netflow tools and wanted to see what others are using? Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. Also curious about on-prem solutions as well. Thanks! Mike From Alex.Lembesis at tevapharm.com Thu Mar 15 15:51:47 2018 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Thu, 15 Mar 2018 15:51:47 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> Message-ID: Netflow Auditor In-house solution. The interface takes some getting used to, but you can pull a-n-y-t-h-i-n-g from it. Easy setup, great support, highly scalable, priced well. Best regards, -Alex -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of mike.lyon at gmail.com Sent: Monday, March 12, 2018 7:25 PM To: NANOG list Subject: Spiffy Netflow tools? Howdy! Checking out various Netflow tools and wanted to see what others are using? Kentik is cool. Are they the only SaaS based flow digester? I don’t seem to see any others. Also curious about on-prem solutions as well. Thanks! Mike This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From harry at harryreeder.co.uk Thu Mar 15 16:08:37 2018 From: harry at harryreeder.co.uk (Harry Reeder) Date: Thu, 15 Mar 2018 16:08:37 +0000 Subject: Google / GMail Geolocation In-Reply-To: References: Message-ID: Yes, I believe I have tried that form at some point in the past but nothing came of it last time - I'll submit it for this instance as well. On Thu, Mar 15, 2018 at 3:56 PM Yury Shefer wrote: > Have you tried to contact G through the following form? > https://support.google.com/websearch/contact/ip > > > On Thu, Mar 15, 2018 at 4:35 AM, Harry Reeder > wrote: > >> Hi Folks, >> >> Wondering if anyone has a contact at Google who can help - I've a customer >> who's attempted to log in from one of our IPs (which comes from one of >> Cogent's /16 blocks) however they get an automated email response from >> Google saying that they're logging in from Hong Kong, and the login was >> prevented for security reasons (as someone may have their password). For >> reference, the whois response shows Washington DC, and refers to Cogent's >> rwhois which places us correctly at Telehouse London. Tools like Maxmind >> also have our location correct. >> >> Is there somewhere I can go to get this corrected for our leased IP >> ranges? >> (I am aware that the long term solution is to get our own IP space - I am >> working on that, I just don't have enough of a business case yet) >> >> Off-list replies also welcome. >> >> Thanks >> Harry >> > > From cscora at apnic.net Fri Mar 16 18:03:26 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Mar 2018 04:03:26 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180316180326.2DD4B102FD@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, IRNOG 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 17 Mar, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 690673 Prefixes after maximum aggregation (per Origin AS): 267882 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 332450 Total ASes present in the Internet Routing Table: 60129 Prefixes per ASN: 11.49 Origin-only ASes present in the Internet Routing Table: 51933 Origin ASes announcing only one prefix: 22773 Transit ASes present in the Internet Routing Table: 8196 Transit-only ASes present in the Internet Routing Table: 255 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN (262865) 25 Prefixes from unregistered ASNs in the Routing Table: 63 Number of instances of unregistered ASNs: 63 Number of 32-bit ASNs allocated by the RIRs: 21837 Number of 32-bit ASNs visible in the Routing Table: 17567 Prefixes from 32-bit ASNs in the Routing Table: 73049 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 338 Number of addresses announced to Internet: 2855059586 Equivalent to 170 /8s, 44 /16s and 192 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 229892 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 189758 Total APNIC prefixes after maximum aggregation: 54251 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 188659 Unique aggregates announced from the APNIC address blocks: 76998 APNIC Region origin ASes present in the Internet Routing Table: 8708 APNIC Prefixes per ASN: 21.67 APNIC Region origin ASes announcing only one prefix: 2470 APNIC Region transit ASes present in the Internet Routing Table: 1294 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3623 Number of APNIC addresses announced to Internet: 767297698 Equivalent to 45 /8s, 188 /16s and 8 /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-137529 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: 205948 Total ARIN prefixes after maximum aggregation: 98707 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206695 Unique aggregates announced from the ARIN address blocks: 97753 ARIN Region origin ASes present in the Internet Routing Table: 18110 ARIN Prefixes per ASN: 11.41 ARIN Region origin ASes announcing only one prefix: 6707 ARIN Region transit ASes present in the Internet Routing Table: 1800 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2323 Number of ARIN addresses announced to Internet: 1104486016 Equivalent to 65 /8s, 213 /16s and 30 /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-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 187538 Total RIPE prefixes after maximum aggregation: 91246 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 183828 Unique aggregates announced from the RIPE address blocks: 109868 RIPE Region origin ASes present in the Internet Routing Table: 24989 RIPE Prefixes per ASN: 7.36 RIPE Region origin ASes announcing only one prefix: 11341 RIPE Region transit ASes present in the Internet Routing Table: 3485 Average RIPE Region AS path length visible: 4.2 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6776 Number of RIPE addresses announced to Internet: 714742144 Equivalent to 42 /8s, 154 /16s and 25 /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-207259 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: 88911 Total LACNIC prefixes after maximum aggregation: 19649 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 90277 Unique aggregates announced from the LACNIC address blocks: 40074 LACNIC Region origin ASes present in the Internet Routing Table: 6915 LACNIC Prefixes per ASN: 13.06 LACNIC Region origin ASes announcing only one prefix: 1885 LACNIC Region transit ASes present in the Internet Routing Table: 1290 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4448 Number of LACNIC addresses announced to Internet: 172058848 Equivalent to 10 /8s, 65 /16s and 104 /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: 18453 Total AfriNIC prefixes after maximum aggregation: 3980 AfriNIC Deaggregation factor: 4.64 Prefixes being announced from the AfriNIC address blocks: 20876 Unique aggregates announced from the AfriNIC address blocks: 7506 AfriNIC Region origin ASes present in the Internet Routing Table: 1124 AfriNIC Prefixes per ASN: 18.57 AfriNIC Region origin ASes announcing only one prefix: 369 AfriNIC Region transit ASes present in the Internet Routing Table: 229 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 397 Number of AfriNIC addresses announced to Internet: 96067584 Equivalent to 5 /8s, 185 /16s and 224 /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 5421 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3919 406 402 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2865 11132 778 KIXS-AS-KR Korea Telecom, KR 9829 2803 1499 541 BSNL-NIB National Internet Backbone, IN 7552 2698 1161 58 VIETEL-AS-AP Viettel Group, VN 9394 2637 4923 29 CTTNET China TieTong Telecommunications 45899 2580 1561 162 VNPT-AS-VN VNPT Corp, VN 17974 2318 930 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2179 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2086 417 215 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 3369 1323 86 SHAW - Shaw Communications Inc., CA 22773 3283 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2096 2484 436 CHARTER-NET-HKY-NC - Charter Communicat 16509 2052 4374 611 AMAZON-02 - Amazon.com, Inc., US 30036 1939 339 186 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1938 5071 622 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6389 1776 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 11492 1760 228 558 CABLEONE - CABLE ONE, INC., US 7018 1689 20188 1251 ATT-INTERNET4 - AT&T Services, Inc., US 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 3696 1447 771 UNI2-AS, ES 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2793 805 2043 AKAMAI-ASN1, US 8551 2104 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2036 1864 704 ROSTELECOM-AS, RU 34984 2026 334 478 TELLCOM-AS, TR 9121 1930 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1223 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 4318 3384 583 Uninet S.A. de C.V., MX 10620 3597 540 259 Telmex Colombia S.A., CO 11830 2642 370 66 Instituto Costarricense de Electricidad 6503 1631 437 53 Axtel, S.A.B. de C.V., MX 7303 1507 1026 191 Telecom Argentina S.A., AR 28573 1024 2247 195 CLARO S.A., BR 6147 1016 377 27 Telefonica del Peru S.A.A., PE 3816 1006 506 120 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 927 126 83 Alestra, S. de R.L. de C.V., MX 18881 907 1072 29 TELEF�NICA BRASIL S.A, BR 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 1162 398 50 LINKdotNET-AS, EG 37611 815 91 8 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 678 1380 39 ETISALAT-MISR, EG 8452 625 1730 18 TE-AS TE-AS, EG 24835 602 850 15 RAYA-AS, EG 29571 466 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 376 81 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5421 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4318 3384 583 Uninet S.A. de C.V., MX 7545 3919 406 402 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 3696 1447 771 UNI2-AS, ES 10620 3597 540 259 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3369 1323 86 SHAW - Shaw Communications Inc., CA 22773 3283 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2865 11132 778 KIXS-AS-KR Korea Telecom, KR 9829 2803 1499 541 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4318 3735 Uninet S.A. de C.V., MX 7545 3919 3517 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3597 3338 Telmex Colombia S.A., CO 6327 3369 3283 SHAW - Shaw Communications Inc., CA 22773 3283 3134 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 12479 3696 2925 UNI2-AS, ES 7552 2698 2640 VIETEL-AS-AP Viettel Group, VN 9394 2637 2608 CTTNET China TieTong Telecommunications Corpora 11830 2642 2576 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 267285 UNALLOCATED 45.232.244.0/22 53087 TELY Ltda., BR 267285 UNALLOCATED 45.232.244.0/23 53087 TELY Ltda., BR 267285 UNALLOCATED 45.232.246.0/23 53087 TELY Ltda., BR 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65000 PRIVATE 95.179.2.0/24 65001 -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 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 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 37.44.224.0/20 48666 AS-MAROSNET Moscow, Russia, RU 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:289 /13:563 /14:1094 /15:1899 /16:13328 /17:7842 /18:13622 /19:25082 /20:39220 /21:45173 /22:85549 /23:69207 /24:385416 /25:837 /26:601 /27:656 /28:35 /29:20 /30:17 /31:4 /32:57 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3160 3369 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2538 3283 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 12479 2482 3696 UNI2-AS, ES 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2642 Instituto Costarricense de Electricidad y Telec 30036 1693 1939 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1601 3597 Telmex Colombia S.A., CO 8551 1567 2104 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1538 1760 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1567 2:832 4:19 5:2806 6:59 7:1 8:1118 9:1 12:1880 13:207 14:1749 15:27 16:3 17:191 18:68 20:47 21:3 23:2559 24:2157 25:2 27:2285 31:1958 32:89 35:27 36:504 37:2736 38:1462 39:247 40:103 41:3028 42:592 43:1949 44:98 45:3919 46:3035 47:199 49:1353 50:1050 51:48 52:989 54:357 55:5 56:10 57:42 58:1563 59:1020 60:428 61:2144 62:1804 63:1802 64:4722 65:2223 66:4594 67:2366 68:1173 69:3206 70:1181 71:558 72:2105 74:2718 75:410 76:426 77:1553 78:1698 79:1868 80:1484 81:1444 82:1078 83:779 84:1022 85:2069 86:578 87:1283 88:928 89:2316 90:200 91:6301 92:1172 93:2362 94:2393 95:2727 96:658 97:356 98:928 99:128 100:79 101:1378 102:31 103:17312 104:3298 105:223 106:588 107:1791 108:709 109:2714 110:1571 111:1756 112:1325 113:1367 114:1117 115:1650 116:1639 117:1717 118:2170 119:1677 120:969 121:1060 122:2450 123:1823 124:1451 125:1885 128:983 129:624 130:444 131:1601 132:656 133:195 134:1002 135:226 136:451 137:495 138:1951 139:573 140:419 141:696 142:790 143:943 144:801 145:452 146:1153 147:742 148:1545 149:697 150:738 151:1046 152:759 153:308 154:1021 155:754 156:847 157:779 158:627 159:1643 160:922 161:718 162:2579 163:526 164:1024 165:1399 166:408 167:1394 168:3062 169:810 170:3665 171:422 172:1052 173:1951 174:879 175:750 176:1876 177:3916 178:2424 179:1194 180:2238 181:2179 182:2466 183:1132 184:915 185:12926 186:3559 187:2326 188:2738 189:1989 190:8120 191:1425 192:9776 193:5893 194:4794 195:3981 196:2435 197:1443 198:5532 199:5908 200:7396 201:4999 202:10390 203:10129 204:4545 205:2848 206:3085 207:3194 208:3994 209:3938 210:4033 211:2118 212:3016 213:2693 214:901 215:61 216:5825 217:2130 218:898 219:621 220:1722 221:996 222:1044 223:1234 End of report From rod.beck at unitedcablecompany.com Fri Mar 16 19:42:02 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 16 Mar 2018 19:42:02 +0000 Subject: Finding scale in Columbus, OH In-Reply-To: <2fb36bd91b1a4824a4222c177b4e0be8@EXCHANGE2K13.thenap.com> References: <2fb36bd91b1a4824a4222c177b4e0be8@EXCHANGE2K13.thenap.com> Message-ID: AWS and Facebook probably lit dark. They are not buying waves between their big data centers. - R. ________________________________ From: NANOG on behalf of Drew Weaver Sent: Thursday, March 15, 2018 1:48 PM To: 'nanog at nanog.org' Subject: Finding scale in Columbus, OH Hello, We've been running into some trouble finding Internet connectivity that will scale (100G) in Central Ohio. So we decided to try and find transport that would scale to other areas that have better Internet infrastructure (CLE, CIN, CHI, ATL, WDC/ASH), our success in this has been surprisngly limited. I know that AWS just put a facility in this area and Facebook is either building one or it is already completed so there must be someone either leasing fiber/transport or they built their own which means that somebody is still doing that kind of construction in this area. Has anyone completed any projects recently with any success at scale in Central Ohio? If so, could you share how you achieved this, either on-list or off-list? Thank you, -Drew From rod.beck at unitedcablecompany.com Fri Mar 16 20:00:33 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 16 Mar 2018 20:00:33 +0000 Subject: New Jersey Telecom Lawyer Message-ID: Please contact offline. Best, 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] From ciscofreak at outlook.com Sat Mar 17 10:29:54 2018 From: ciscofreak at outlook.com (Hari .) Date: Sat, 17 Mar 2018 10:29:54 +0000 Subject: NSR / NSF Message-ID: Checking on best practice being followed with regards to enabling NSF or NSR or both on ASR 9k. Which option can be beneficial and considered to be a standard approach. Thanks! From brandon at burn.net Sat Mar 17 13:08:53 2018 From: brandon at burn.net (Brandon Applegate) Date: Sat, 17 Mar 2018 09:08:53 -0400 Subject: TWC/Charter/Spectrum contact off-list ? (Reverse DNS issue) In-Reply-To: <20180316220010.zch6drqmd7wsdu7i@vanvanmojo.kallisti.us> References: <20180316220010.zch6drqmd7wsdu7i@vanvanmojo.kallisti.us> Message-ID: <6AA0BB2C-A12F-4EDE-84F3-DA68E815DEE5@burn.net> > On Mar 16, 2018, at 6:00 PM, Ross Vandegrift wrote: > > On Thu, Oct 19, 2017 at 08:04:12AM -0400, Brandon Applegate wrote: >> I had success with this issue about 2 years ago when some TWC folks >> contacted me. I don’t know if those folks are still with TWC/Charter >> here in the end of 2017 - hence posting on NANOG. The tl;dr is IPv6 >> reverse DNS issues. It was broken, got fixed, and seems to have >> broken again recently. > > Did you ever get a response or make progress? I got a ticket escalated > to engineering in mid-December about 2606:6000::/32. Just learned from > support that it was closed without a resolution. I did and did (response and progress (fix actually)). I will shoot you who helped me offlist. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." -------------- 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 uwcableguy at gmail.com Sat Mar 17 14:25:10 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Sat, 17 Mar 2018 09:25:10 -0500 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS Message-ID: When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying to do the same thing on a Juniper MX 480/960 and it does not appear to be supported (for LDP at least - MP-BGP might be supported). We could do either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). JTAC has somewhat confirmed this is not supported for LDP, but they only do break/fix, not new config. We do not have professional services (we are broke). Any Juniper routerheads out there that have seen this done using LDP without having to hairpin on the MX? Thanks, y'all. -ben From jackson.tim at gmail.com Sat Mar 17 14:48:43 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 17 Mar 2018 14:48:43 +0000 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: References: Message-ID: You can either attach the end of the l2circuit to an LT interface, or a PS interface. https://www.google.com/amp/s/tgregory.org/2016/07/10/pseudowire-headend-termination-pwht-for-juniper-mx/amp/ https://www.juniper.net/documentation/en_US/junos/topics/concept/pseudowire-subscriber-interfaces-overview.html https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/services-configuring-logical-tunnel-interfaces.html On Sat, Mar 17, 2018, 9:27 AM Ben Bartsch wrote: > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying to do > the same thing on a Juniper MX 480/960 and it does not appear to be > supported (for LDP at least - MP-BGP might be supported). We could do > either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). > JTAC has somewhat confirmed this is not supported for LDP, but they only do > break/fix, not new config. We do not have professional services (we are > broke). > > Any Juniper routerheads out there that have seen this done using LDP > without having to hairpin on the MX? > > Thanks, y'all. > > -ben > From me at krygerism.com Sat Mar 17 22:42:55 2018 From: me at krygerism.com (Michael Krygeris) Date: Sat, 17 Mar 2018 22:42:55 +0000 Subject: Spiffy Netflow tools? In-Reply-To: <2A55570D-7163-4849-B7AC-041237735E19@farrokhi.net> References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <2A55570D-7163-4849-B7AC-041237735E19@farrokhi.net> Message-ID: Disclaimer: Am Plixer engineer. If you want to take it for a spin, you can download a fully functional OVA/QCOW2 30 day eval from the plixer website. I can also get you access to an AWS AMI as well. I don’t want to turn this into an Ad. So DM if you need any info/access. Mike Krygeris On Tue, Mar 13, 2018 at 11:52 AM Babak Farrokhi wrote: > Plixer is also interesting. > > nfdump works great with NetFlow but support for IPFIX is somehow limited > to basics. > > > -- > Babak > > > On 13 Mar 2018, at 3:20, Fredrik Korsbäck wrote: > > > On 2018-03-13 00:24, mike.lyon at gmail.com wrote: > >> Howdy! > >> > >> Checking out various Netflow tools and wanted to see what others are > >> using? > >> > >> Kentik is cool. Are they the only SaaS based flow digester? I don’t > >> seem to see any others. > >> > >> Also curious about on-prem solutions as well. > >> > >> Thanks! > >> Mike > >> > > > > Kentik is probably top of the foodchain right now. > > > > But they are certainly not alone in the biz. Ontop of my head... > > > > * Flowmon > > * Talaia > > * Arbor Peakflow > > * Deepfield > > * Pmacct + supporting toolkit > > * NFsen/Nfdump/AS-stats > > * Put kibana/ES infront of any collector > > * Solarwinds something something > > * Different vendor toolkits > > > > > > > > -- > > hugge > From randy at psg.com Sun Mar 18 09:38:44 2018 From: randy at psg.com (Randy Bush) Date: Sun, 18 Mar 2018 09:38:44 +0000 Subject: any contact at mycheckfree.com Message-ID: i am using both ffox 59.01 and chrome 65.0.3325.162 on latest macos high sierra. i am trying to connect to mycheckfree.com ffox and chrome are offering sha1 and then puking when the site selects it. clearly ffox and chrome should not do this. but also, mycheckfree should not be selecting sha1. and i can't see their web site to get a support contact. randy From cma at cmadams.net Sun Mar 18 14:56:01 2018 From: cma at cmadams.net (Chris Adams) Date: Sun, 18 Mar 2018 09:56:01 -0500 Subject: any contact at mycheckfree.com In-Reply-To: References: Message-ID: <20180318145601.GA14697@cmadams.net> Once upon a time, Randy Bush said: > i am using both ffox 59.01 and chrome 65.0.3325.162 on latest macos high > sierra. i am trying to connect to mycheckfree.com https://www.ssllabs.com/ssltest/analyze.html?d=mycheckfree.com -- Chris Adams From Brian at ampr.org Sun Mar 18 15:20:24 2018 From: Brian at ampr.org (Brian Kantor) Date: Sun, 18 Mar 2018 08:20:24 -0700 Subject: any contact at mycheckfree.com In-Reply-To: <20180318145601.GA14697@cmadams.net> References: <20180318145601.GA14697@cmadams.net> Message-ID: <20180318152024.GA44068@meow.BKantor.net> As is often the case, the Lynx text-only browser will connect successfully when other browsers won't, and did enable me to navigate to the 'contact us' page. "For inquiries, please contact us at 800-564-9184. Support hours are from 8:00 A.M. to 9:00 P.M., ET, Monday through Friday, and from 8:00 A.M. to 5:00 P.M., ET, on Saturday and Sunday." Sometimes the primitive mechanisms work better. - Brian On Sun, Mar 18, 2018 at 09:56:01AM -0500, Chris Adams wrote: > Once upon a time, Randy Bush said: > > i am using both ffox 59.01 and chrome 65.0.3325.162 on latest macos high > > sierra. i am trying to connect to mycheckfree.com > > https://www.ssllabs.com/ssltest/analyze.html?d=mycheckfree.com > > -- > Chris Adams From nanog at ics-il.net Sun Mar 18 15:57:11 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 18 Mar 2018 10:57:11 -0500 (CDT) Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: <1754029957.4551.1521388627318.JavaMail.mhammett@ThunderFuck> Arguing against less than /24s in the public routing table. That's not the point being made. The point being made is the relaxation of requirements to obtain /24s for ISPs. To that I point to a statement John Curran made in a keynote I attended several conferences ago. If you wish to change ARIN policy, a small room of people can change it to say whatever they want because no one participates in the process. https://www.arin.net/participate/how_to_participate.html ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" To: "Justin Wilson" , nanog at nanog.org Sent: Tuesday, March 13, 2018 1:24:22 PM Subject: Re: IPv4 smaller than /24 leasing? Hi, needing a /24 to participate in BGP has always been sort of a world-wide standard. Even before the explosion of the IPv4 BGP full table (which has more than doubled in the last decade), that was the standard. Because ..... if carriers (and ISPs) accepted upstream < /24, then you'd have an entirely different animal at large. The issue here is not ARIN, or RIPE, or APNIC, or AfriNIC etc. The issue is, that the industry standard is to filter the upstream table and not to accept smaller than /24 ... so even if the policies were changed your Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? It ARIN, or others for that matter, going to relax those requirements? If I am an ISP and need to do BGP, maybe because I have a big downstream customer, I have to have a /24 to participate in BGP. I see these scenarios more and more. > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Mar 13, 2018, at 2:08 PM, Bob Evans wrote: >> >> Marketplaces - supply and demand and costs to operate as Bill noted (never >> thought of that) will settle out the need. >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> I am looking at it from an ARIN justification point. If you are a small >>> operator and need a /24 you have justification if you give customer’s >>> publics, but is it a great line if you are only giving out publics for >>> people who need cameras or need to connect in from the outside world. If I >>> need a /24 and I don’t really use it all am I being shady? It becomes a >>> “how much of a grey area is there” kind of thing. >>> >>> >>> Justin Wilson >>> j2sw at mtin.net >>> >>> www.mtin.net >>> www.midwest-ix.com >>> >>>> On Mar 13, 2018, at 1:37 PM, William Herrin wrote: >>>> >>>> On Tue, Mar 13, 2018 at 1:19 PM, Justin Wilson wrote: >>>>> I agree that the global routing table is pretty bloated as is. But >>>>> what kind of a solution for providers who need to participate in BGP >>>>> but only need a /25? >>>> >>>> Hi Justin, >>>> >>>> If you need a /25 and BGP for multihoming or anycasting, get a /24. >>>> The cost you impose on the system by using BGP *at all* is much higher >>>> than the cost you impose on the system by consuming less than 250 >>>> "unneeded" Ip addresses. >>>> >>>> I did a cost analysis on a BGP announcement a decade or so ago. The >>>> exact numbers have changed but the bottom line hasn't: it's >>>> ridiculously consumptive. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>>> Dirtside Systems ......... Web: >>>> >>> >>> >> >> > -- 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 nanog at ics-il.net Sun Mar 18 15:58:27 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 18 Mar 2018 10:58:27 -0500 (CDT) Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> Message-ID: <1514453564.4554.1521388703183.JavaMail.mhammett@ThunderFuck> So the recommendation to get that /24 is to cheat or otherwise mislead in your justification? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "William Herrin" To: "Justin Wilson" Cc: nanog at nanog.org Sent: Tuesday, March 13, 2018 1:40:48 PM Subject: Re: IPv4 smaller than /24 leasing? On Tue, Mar 13, 2018 at 2:14 PM, Justin Wilson wrote: > Even to buy it on the secondary market you have to have justification and show usage. So if someone buys a /24 and really only needs a /25 then what? Hi Justin, If you can't justify a /24 with a single hypervisor, you aren't being creative enough. Seriously. Optimize your network _plan_ for address consumption. You need a /29 (or two /30s) to connect each VM to the primary and backup router VMs and that's before you assign virtual IPs to web servers on the VMs. In your initial allocation, ARIN won't hold you to your plan. You just have to have a plan where the numbers add up to justified need. If you're not comfortable going it on your own, contract someone who's been through it before to shepherd you through the process. ARIN's process is convoluted and arcane, but if you're ready to pay the cost of multihoming you truly won't have any trouble justifying an ARIN /24. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Sun Mar 18 17:08:57 2018 From: bill at herrin.us (William Herrin) Date: Sun, 18 Mar 2018 13:08:57 -0400 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <1514453564.4554.1521388703183.JavaMail.mhammett@ThunderFuck> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <9578293AE169674F9A048B2BC9A081B402A31E72BE@MUNPRDMBXA1.medline.com> <10264999-8D60-40C3-B195-06EF5C59B959@mtin.net> <1514453564.4554.1521388703183.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Mar 18, 2018 at 11:58 AM, Mike Hammett wrote: > So the recommendation to get that /24 is to cheat or otherwise mislead in your justification? I gave up on the credibility of ARIN's justified need policy when the organization decided it was OK to transfer ARIN addresses to China (which forbids transferring addresses back) as long as the recipient met the registry requirements... Not ARIN's registry requirements, China's. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ross at kallisti.us Fri Mar 16 22:00:10 2018 From: ross at kallisti.us (Ross Vandegrift) Date: Fri, 16 Mar 2018 15:00:10 -0700 Subject: TWC/Charter/Spectrum contact off-list ? (Reverse DNS issue) In-Reply-To: References: Message-ID: <20180316220010.zch6drqmd7wsdu7i@vanvanmojo.kallisti.us> On Thu, Oct 19, 2017 at 08:04:12AM -0400, Brandon Applegate wrote: > I had success with this issue about 2 years ago when some TWC folks > contacted me. I don’t know if those folks are still with TWC/Charter > here in the end of 2017 - hence posting on NANOG. The tl;dr is IPv6 > reverse DNS issues. It was broken, got fixed, and seems to have > broken again recently. Did you ever get a response or make progress? I got a ticket escalated to engineering in mid-December about 2606:6000::/32. Just learned from support that it was closed without a resolution. Thanks, Ross From chris2014 at postbox.xyz Sat Mar 17 21:04:05 2018 From: chris2014 at postbox.xyz (Chris) Date: Sat, 17 Mar 2018 22:04:05 +0100 Subject: problems sending to prodigy.net hosted email In-Reply-To: <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> References: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> Message-ID: <20180317220405.25083c02@cd> On Sun, 11 Mar 2018 15:57:32 -0700 Stephen Satchell wrote: > (I know in my consulting practice I strongly discourage having ANY > other significant services on DNS servers. RADIUS and DHCP, ok, but > not mail or web. For CPanel and PLESK web boxes, have the NS records > point to a pair of DNS-dedicated servers, and sync the zone files > with the ones on the Web boxes.) Why not? Never had a problem with multiple services on linux, in contrast to windows where every service requires its own box (or at least vm). -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From gustkiller at gmail.com Mon Mar 19 14:16:41 2018 From: gustkiller at gmail.com (Gustavo Santos) Date: Mon, 19 Mar 2018 11:16:41 -0300 Subject: Spiffy Netflow tools? In-Reply-To: References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <2A55570D-7163-4849-B7AC-041237735E19@farrokhi.net> Message-ID: +1 for Plixer Scrutinizer 2018-03-17 19:42 GMT-03:00 Michael Krygeris : > Disclaimer: Am Plixer engineer. > If you want to take it for a spin, you can download a fully functional > OVA/QCOW2 30 day eval from the plixer website. I can also get you access to > an AWS AMI as well. > I don’t want to turn this into an Ad. So DM if you need any info/access. > > Mike Krygeris > > On Tue, Mar 13, 2018 at 11:52 AM Babak Farrokhi > wrote: > > > Plixer is also interesting. > > > > nfdump works great with NetFlow but support for IPFIX is somehow limited > > to basics. > > > > > > -- > > Babak > > > > > > On 13 Mar 2018, at 3:20, Fredrik Korsbäck wrote: > > > > > On 2018-03-13 00:24, mike.lyon at gmail.com wrote: > > >> Howdy! > > >> > > >> Checking out various Netflow tools and wanted to see what others are > > >> using? > > >> > > >> Kentik is cool. Are they the only SaaS based flow digester? I don’t > > >> seem to see any others. > > >> > > >> Also curious about on-prem solutions as well. > > >> > > >> Thanks! > > >> Mike > > >> > > > > > > Kentik is probably top of the foodchain right now. > > > > > > But they are certainly not alone in the biz. Ontop of my head... > > > > > > * Flowmon > > > * Talaia > > > * Arbor Peakflow > > > * Deepfield > > > * Pmacct + supporting toolkit > > > * NFsen/Nfdump/AS-stats > > > * Put kibana/ES infront of any collector > > > * Solarwinds something something > > > * Different vendor toolkits > > > > > > > > > > > > -- > > > hugge > > > From jlarsen at richweb.com Mon Mar 19 15:56:16 2018 From: jlarsen at richweb.com (C. Jon Larsen) Date: Mon, 19 Mar 2018 11:56:16 -0400 (EDT) Subject: problems sending to prodigy.net hosted email In-Reply-To: <20180317220405.25083c02@cd> References: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> <20180317220405.25083c02@cd> Message-ID: > On Sun, 11 Mar 2018 15:57:32 -0700 > Stephen Satchell wrote: > >> (I know in my consulting practice I strongly discourage having ANY >> other significant services on DNS servers. RADIUS and DHCP, ok, but >> not mail or web. For CPanel and PLESK web boxes, have the NS records >> point to a pair of DNS-dedicated servers, and sync the zone files >> with the ones on the Web boxes.) > > Why not? Never had a problem with multiple services on linux, in > contrast to windows where every service requires its own box (or at > least vm). Go for it ! Failure is an awesome teacher :) From uwcableguy at gmail.com Mon Mar 19 16:51:36 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Mon, 19 Mar 2018 11:51:36 -0500 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: References: Message-ID: I want to thank everyone who contacted me on and off list on this request. I now have two methods to land a layer 3 endpoint on a layer 2 circuit to a remote PE. I very much appreciate the input, feedback, and assistance. I hope I personally get to meet all of you that reached out to me at a future NANOG meeting. Thanks again! -ben On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch wrote: > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying to do > the same thing on a Juniper MX 480/960 and it does not appear to be > supported (for LDP at least - MP-BGP might be supported). We could do > either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). > JTAC has somewhat confirmed this is not supported for LDP, but they only do > break/fix, not new config. We do not have professional services (we are > broke). > > Any Juniper routerheads out there that have seen this done using LDP > without having to hairpin on the MX? > > Thanks, y'all. > > -ben > From chris2014 at postbox.xyz Mon Mar 19 16:55:33 2018 From: chris2014 at postbox.xyz (Chris) Date: Mon, 19 Mar 2018 17:55:33 +0100 Subject: problems sending to prodigy.net hosted email In-Reply-To: References: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> <20180317220405.25083c02@cd> Message-ID: <20180319175533.49aaf7f2@cd> On Mon, 19 Mar 2018 11:56:16 -0400 (EDT) C. Jon Larsen wrote: > > Why not? Never had a problem with multiple services on linux, in > > contrast to windows where every service requires its own box (or at > > least vm). > > Go for it ! Failure is an awesome teacher :) Don't really see a problem, especially since you normally always have two DNS servers... -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From cra at WPI.EDU Mon Mar 19 20:25:36 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 19 Mar 2018 16:25:36 -0400 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: References: Message-ID: <20180319202536.GF1336@angus.ind.wpi.edu> Would you mind sharing the solution(s)? I've stiched a L2 PW using lt-interfaces. Thanks. On Mon, Mar 19, 2018 at 11:51:36AM -0500, Ben Bartsch wrote: > I want to thank everyone who contacted me on and off list on this request. > I now have two methods to land a layer 3 endpoint on a layer 2 circuit to a > remote PE. I very much appreciate the input, feedback, and assistance. I > hope I personally get to meet all of you that reached out to me at a future > NANOG meeting. Thanks again! > > -ben > > On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch wrote: > > > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 > > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying to do > > the same thing on a Juniper MX 480/960 and it does not appear to be > > supported (for LDP at least - MP-BGP might be supported). We could do > > either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). > > JTAC has somewhat confirmed this is not supported for LDP, but they only do > > break/fix, not new config. We do not have professional services (we are > > broke). > > > > Any Juniper routerheads out there that have seen this done using LDP > > without having to hairpin on the MX? > > > > Thanks, y'all. > > > > -ben From uwcableguy at gmail.com Mon Mar 19 21:15:48 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Mon, 19 Mar 2018 16:15:48 -0500 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: <20180319202536.GF1336@angus.ind.wpi.edu> References: <20180319202536.GF1336@angus.ind.wpi.edu> Message-ID: Absolutely! I'm running a eBGP session over this ATM. We are going to try to backhaul our customers through a Dell whitebox running IPI OcNOS configured with an 'LDP fabric' to a core MX. To use an IRB as a L3 endpoint you have to use VPLS on the MX (Junos version 15.1R6.7). I was missing a couple of key commands highlighted in red: show configuration interfaces irb.997 | display set set interfaces irb unit 997 description VLAN-997->PWHE->POD1-3550-S1_VLAN_997 set interfaces irb unit 997 bandwidth 10g set interfaces irb unit 997 family inet mtu 9178 set interfaces irb unit 997 family inet address 10.240.16.101/30 show configuration routing-instances VPLS-LAB-0997 | display set set routing-instances VPLS-LAB-0997 instance-type vpls set routing-instances VPLS-LAB-0997 vlan-id 997 set routing-instances VPLS-LAB-0997 routing-interface irb.997 set routing-instances VPLS-LAB-0997 protocols vpls encapsulation-type ethernet-vlan set routing-instances VPLS-LAB-0997 protocols vpls no-tunnel-services set routing-instances VPLS-LAB-0997 protocols vpls vpls-id 997 set routing-instances VPLS-LAB-0997 protocols vpls mtu 9100 set routing-instances VPLS-LAB-0997 protocols vpls neighbor 10.240.0.73 set routing-instances VPLS-LAB-0997 protocols vpls connectivity-type irb show vpls connections extensive Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not available BK -- Backup connection ST -- Standby connection PF -- Profile parse failure PB -- Profile busy RS -- remote site standby SN -- Static Neighbor LB -- Local site not best-site RB -- Remote site not best-site VM -- VLAN ID mismatch HS -- Hot-standby Connection Legend for interface status Up -- operational Dn -- down Instance: VPLS-LAB-0997 VPLS-id: 997 Number of local interfaces: 0 Number of local interfaces up: 0 lsi.1048592 Intf - vpls VPLS-LAB-0997 neighbor 10.240.0.73 vpls-id 997 Neighbor Type St Time last up # Up trans 10.240.0.73(vpls-id 997) rmt Up Mar 19 10:25:38 2018 1 Remote PE: 10.240.0.73, Negotiated control-word: No Incoming label: 262148, Outgoing label: 52786 Negotiated PW status TLV: No Local interface: lsi.1048592, Status: Up, Encapsulation: VLAN Description: Intf - vpls VPLS-LAB-0997 neighbor 10.240.0.73 vpls-id 997 Flow Label Transmit: No, Flow Label Receive: No Connection History: Mar 19 10:25:38 2018 status update timer Mar 19 10:25:38 2018 PE route changed Mar 19 10:25:38 2018 Out lbl Update 52786 Mar 19 10:25:38 2018 In lbl Update 262148 Mar 19 10:25:38 2018 loc intf up lsi.1048592 The other end of my VPLS circuit is a Dell S4048-ON running IP Infusion OcNOS (it is very Cisco IOS-ish) v1.3.3: sh run mpls mpls vpls VPLS-LAB-0997 997 redundancy-role primary signaling ldp vpls-type vlan vpls-peer 10.240.0.11 exit-signaling ! router ldp router-id 10.240.0.73 targeted-peer ipv4 10.240.0.11 exit-targeted-peer-mode transport-address ipv4 10.240.0.73 sh run int xe4 ! interface xe4 description XE4->POD1-3550-S1_GI0/2 speed 1g switchport load-interval 30 mtu 9100 mpls-vpls VPLS-LAB-0997 vlan 997 ac-admin-status up exit-if-vpls And the CE is just a simple L3 VLAN. We are using an old Cisco 3550 running 12.2(46)SE IPSERVICESK9 that we found laying around: POD1-3550-S1#sh run int gi0/2 Building configuration... Current configuration : 219 bytes ! interface GigabitEthernet0/2 description GI0/2->POD3-4048-S1_XE4 switchport trunk encapsulation dot1q switchport trunk allowed vlan 997 switchport mode trunk load-interval 30 speed nonegotiate end POD1-3550-S1#sh run int vlan 997 Building configuration... Current configuration : 115 bytes ! interface Vlan997 description VLAN_997_VLAN-BASED-VPWS-ROUTED-PW ip address 10.240.16.102 255.255.255.252 end Hope this helps. My head hurts from banging it my desk for the last couple of weeks. :) -ben On Mon, Mar 19, 2018 at 3:25 PM, Chuck Anderson wrote: > Would you mind sharing the solution(s)? I've stiched a L2 PW using > lt-interfaces. > > Thanks. > > On Mon, Mar 19, 2018 at 11:51:36AM -0500, Ben Bartsch wrote: > > I want to thank everyone who contacted me on and off list on this > request. > > I now have two methods to land a layer 3 endpoint on a layer 2 circuit > to a > > remote PE. I very much appreciate the input, feedback, and assistance. > I > > hope I personally get to meet all of you that reached out to me at a > future > > NANOG meeting. Thanks again! > > > > -ben > > > > On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch > wrote: > > > > > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 > > > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying > to do > > > the same thing on a Juniper MX 480/960 and it does not appear to be > > > supported (for LDP at least - MP-BGP might be supported). We could do > > > either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). > > > JTAC has somewhat confirmed this is not supported for LDP, but they > only do > > > break/fix, not new config. We do not have professional services (we > are > > > broke). > > > > > > Any Juniper routerheads out there that have seen this done using LDP > > > without having to hairpin on the MX? > > > > > > Thanks, y'all. > > > > > > -ben > From uwcableguy at gmail.com Mon Mar 19 21:27:43 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Mon, 19 Mar 2018 16:27:43 -0500 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: References: <20180319202536.GF1336@angus.ind.wpi.edu> Message-ID: The other solution is a stitched LT configuration. One LT is the L3 endpoint, the other is the PW endpoint. You use VPWS with this one. I suppose you might be able to do VPLS instead if you wanted to. I am running eBGP on this circuit too. It's a bit more complicated for troubleshooting. I'm not sure what benefit this has over the IRB method. Again, Junos 15.1R6.7: show configuration interfaces lt-0/0/10 | display set set interfaces lt-0/0/10 mtu 9192 set interfaces lt-0/0/10 unit 998 description LT-0/0/0.998->VLAN_998->PW set interfaces lt-0/0/10 unit 998 encapsulation vlan-ccc set interfaces lt-0/0/10 unit 998 vlan-id 998 set interfaces lt-0/0/10 unit 998 peer-unit 10998 set interfaces lt-0/0/10 unit 998 family ccc set interfaces lt-0/0/10 unit 10998 description LT-0/0/0.10998->VLAN_998->L3 set interfaces lt-0/0/10 unit 10998 encapsulation vlan set interfaces lt-0/0/10 unit 10998 vlan-id 998 set interfaces lt-0/0/10 unit 10998 peer-unit 998 set interfaces lt-0/0/10 unit 10998 family inet address 10.240.16.97/30 show configuration protocols l2circuit | display set set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 virtual-circuit-id 998 set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 mtu 9100 show l2circuit connections Layer-2 Circuit Connections: Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration BK -- Backup Connection ST -- Standby Connection CB -- rcvd cell-bundle size bad SP -- Static Pseudowire LD -- local site signaled down RS -- remote site standby RD -- remote site signaled down HS -- Hot-standby Connection XX -- unknown Legend for interface status Up -- operational Dn -- down Neighbor: 10.240.0.73 Interface Type St Time last up # Up trans lt-0/0/10.998(vc 998) rmt Up Mar 18 19:14:28 2018 1 Remote PE: 10.240.0.73, Negotiated control-word: No Incoming label: 347440, Outgoing label: 52785 Negotiated PW status TLV: No Local interface: lt-0/0/10.998, Status: Up, Encapsulation: VLAN Flow Label Transmit: No, Flow Label Receive: No The PE is again a Dell S4048-ON running IPI OcNOS v1.3.3 sh run mpls ! mpls l2-circuit VLAN_BASED_PW_0998 998 10.240.0.11 ! router ldp router-id 10.240.0.73 targeted-peer ipv4 10.240.0.11 exit-targeted-peer-mode transport-address ipv4 10.240.0.73 sh run int xe4 ! interface xe4 description XE4->POD1-3550-S1_GI0/2 speed 1g switchport load-interval 30 mtu 9100 mpls-l2-circuit VLAN_BASED_PW_0998 vlan 998 tpid 8100 sh ldp mpls-l2-circuit detail vcid: 998 type: vlan, local groupid: 0, remote groupid: 0 (vc is up) destination: 10.240.0.11, Peer LDP Ident: 10.240.0.11 Local label: 52785, remote label: 347440 Access IF: xe4, Network IF: xe2 Local MTU: 9100, Remote MTU: 9100 <--THIS IS SUPER HANDY - IT WILL SHOW YOUR REMOTE MTU EVEN IF THE CIRCUIT IS DOWN Local Control Word: disabled, Remote Control Word: disabled, Current use: disabled Local PW Status Capability : disabled Remote PW Status Capability : disabled Current PW Status TLV : disabled Local VCCV Capability: CC-Types: None CV-Types: None Remote VCCV Capability: CC-Types: Type 1 Type 2 Type 3 CV-Types: LSP ping BFD IP/UDP-encapsulated, for PW Fault Detection only BFD PW-ACH-encapsulated, for PW Fault Detection only sh ldp mpls-l2-circuit Transport Client VC VC Local Remote Destination VC ID Binding State Type VC Label VC Label Address 998 xe4 UP Ethernet VLAN 52785 347440 10.240.0.11 Finally the CE is the same old Cisco 3550 with a VLAN: POD1-FREY113-3550-S1#sh run int vlan 998 Building configuration... Current configuration : 114 bytes ! interface Vlan998 description VLAN_998_VLAN-BASED-VPWS-ROUTED-PW ip address 10.240.16.98 255.255.255.252 end POD1-FREY113-3550-S1#sh run int gi0/2 Building configuration... Current configuration : 219 bytes ! interface GigabitEthernet0/2 description GI0/2->POD3-4048-S1_XE4 switchport trunk encapsulation dot1q switchport trunk allowed vlan 998 switchport mode trunk load-interval 30 speed nonegotiate end I also forgot to show y'all what the VPLS circuit show commands look like on the OcNOS node for the VPLS solution: sh mpls vpls detail Virtual Private LAN Service Instance: VPLS-LAB-0997, ID: 997 SIG-Protocol: LDP Attachment-Circuit :UP Learning: Enabled Group ID: 0, VPLS Type: Ethernet VLAN, Configured MTU: 9100 Description: none service-tpid: dot1.q Operating mode: Tagged Svlan Id: 0 Svlan Tpid: 8100 Redundancy admin role: Primary Redundancy oper role: Primary Configured interfaces: Interface: xe4 Vlan Id: 997 oper-state UP Mesh Peers: 10.240.0.11 (Up), PW Status Local:0 Remote:0 sh mpls vpls mesh VPLS-ID Peer Addr Tunnel-Label In-Label Network-Intf Out-Label Lkps/St PW-INDEX SIG-Protocol Status 997 10.240.0.11 52496 52786 xe2 262148 2/Up 7 LDP Active On Mon, Mar 19, 2018 at 4:15 PM, Ben Bartsch wrote: > Absolutely! I'm running a eBGP session over this ATM. We are going to > try to backhaul our customers through a Dell whitebox running IPI OcNOS > configured with an 'LDP fabric' to a core MX. > > > To use an IRB as a L3 endpoint you have to use VPLS on the MX (Junos > version 15.1R6.7). I was missing a couple of key commands highlighted in > red: > > show configuration interfaces irb.997 | display set > set interfaces irb unit 997 description VLAN-997->PWHE->POD1-3550-S1_ > VLAN_997 > set interfaces irb unit 997 bandwidth 10g > set interfaces irb unit 997 family inet mtu 9178 > set interfaces irb unit 997 family inet address 10.240.16.101/30 > > show configuration routing-instances VPLS-LAB-0997 | display set > set routing-instances VPLS-LAB-0997 instance-type vpls > set routing-instances VPLS-LAB-0997 vlan-id 997 > set routing-instances VPLS-LAB-0997 routing-interface irb.997 > set routing-instances VPLS-LAB-0997 protocols vpls encapsulation-type > ethernet-vlan > set routing-instances VPLS-LAB-0997 protocols vpls no-tunnel-services > set routing-instances VPLS-LAB-0997 protocols vpls vpls-id 997 > set routing-instances VPLS-LAB-0997 protocols vpls mtu 9100 > set routing-instances VPLS-LAB-0997 protocols vpls neighbor 10.240.0.73 > set routing-instances VPLS-LAB-0997 protocols vpls connectivity-type irb > > show vpls connections extensive > Layer-2 VPN connections: > > Legend for connection status (St) > EI -- encapsulation invalid NC -- interface encapsulation not > CCC/TCC/VPLS > EM -- encapsulation mismatch WE -- interface and instance encaps not > same > VC-Dn -- Virtual circuit down NP -- interface hardware not present > CM -- control-word mismatch -> -- only outbound connection is up > CN -- circuit not provisioned <- -- only inbound connection is up > OR -- out of range Up -- operational > OL -- no outgoing label Dn -- down > LD -- local site signaled down CF -- call admission control failure > RD -- remote site signaled down SC -- local and remote site ID collision > LN -- local site not designated LM -- local site ID not minimum designated > RN -- remote site not designated RM -- remote site ID not minimum > designated > XX -- unknown connection status IL -- no incoming label > MM -- MTU mismatch MI -- Mesh-Group ID not available > BK -- Backup connection ST -- Standby connection > PF -- Profile parse failure PB -- Profile busy > RS -- remote site standby SN -- Static Neighbor > LB -- Local site not best-site RB -- Remote site not best-site > VM -- VLAN ID mismatch HS -- Hot-standby Connection > > Legend for interface status > Up -- operational > Dn -- down > > Instance: VPLS-LAB-0997 > VPLS-id: 997 > Number of local interfaces: 0 > Number of local interfaces up: 0 > lsi.1048592 Intf - vpls VPLS-LAB-0997 neighbor > 10.240.0.73 vpls-id 997 > Neighbor Type St Time last up # Up trans > 10.240.0.73(vpls-id 997) rmt Up Mar 19 10:25:38 2018 1 > Remote PE: 10.240.0.73, Negotiated control-word: No > Incoming label: 262148, Outgoing label: 52786 > Negotiated PW status TLV: No > Local interface: lsi.1048592, Status: Up, Encapsulation: VLAN > Description: Intf - vpls VPLS-LAB-0997 neighbor 10.240.0.73 > vpls-id 997 > Flow Label Transmit: No, Flow Label Receive: No > Connection History: > Mar 19 10:25:38 2018 status update timer > Mar 19 10:25:38 2018 PE route changed > Mar 19 10:25:38 2018 Out lbl Update 52786 > Mar 19 10:25:38 2018 In lbl Update 262148 > Mar 19 10:25:38 2018 loc intf up lsi.1048592 > > > > > The other end of my VPLS circuit is a Dell S4048-ON running IP Infusion > OcNOS (it is very Cisco IOS-ish) v1.3.3: > > sh run mpls > mpls vpls VPLS-LAB-0997 997 > redundancy-role primary > signaling ldp > vpls-type vlan > vpls-peer 10.240.0.11 > exit-signaling > ! > router ldp > router-id 10.240.0.73 > targeted-peer ipv4 10.240.0.11 > exit-targeted-peer-mode > transport-address ipv4 10.240.0.73 > > sh run int xe4 > ! > interface xe4 > description XE4->POD1-3550-S1_GI0/2 > speed 1g > switchport > load-interval 30 > mtu 9100 > mpls-vpls VPLS-LAB-0997 vlan 997 > ac-admin-status up > exit-if-vpls > > > > > And the CE is just a simple L3 VLAN. We are using an old Cisco 3550 > running 12.2(46)SE IPSERVICESK9 that we found laying around: > > POD1-3550-S1#sh run int gi0/2 > Building configuration... > > Current configuration : 219 bytes > ! > interface GigabitEthernet0/2 > description GI0/2->POD3-4048-S1_XE4 > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 997 > switchport mode trunk > load-interval 30 > speed nonegotiate > end > > POD1-3550-S1#sh run int vlan 997 > Building configuration... > > Current configuration : 115 bytes > ! > interface Vlan997 > description VLAN_997_VLAN-BASED-VPWS-ROUTED-PW > ip address 10.240.16.102 255.255.255.252 > end > > > > Hope this helps. My head hurts from banging it my desk for the last > couple of weeks. :) > > -ben > > On Mon, Mar 19, 2018 at 3:25 PM, Chuck Anderson wrote: > >> Would you mind sharing the solution(s)? I've stiched a L2 PW using >> lt-interfaces. >> >> Thanks. >> >> On Mon, Mar 19, 2018 at 11:51:36AM -0500, Ben Bartsch wrote: >> > I want to thank everyone who contacted me on and off list on this >> request. >> > I now have two methods to land a layer 3 endpoint on a layer 2 circuit >> to a >> > remote PE. I very much appreciate the input, feedback, and >> assistance. I >> > hope I personally get to meet all of you that reached out to me at a >> future >> > NANOG meeting. Thanks again! >> > >> > -ben >> > >> > On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch >> wrote: >> > >> > > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 >> > > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying >> to do >> > > the same thing on a Juniper MX 480/960 and it does not appear to be >> > > supported (for LDP at least - MP-BGP might be supported). We could do >> > > either VPWS or VPLS on the PE device handoff to the CE (layer 2 only). >> > > JTAC has somewhat confirmed this is not supported for LDP, but they >> only do >> > > break/fix, not new config. We do not have professional services (we >> are >> > > broke). >> > > >> > > Any Juniper routerheads out there that have seen this done using LDP >> > > without having to hairpin on the MX? >> > > >> > > Thanks, y'all. >> > > >> > > -ben >> > > From list at satchell.net Tue Mar 20 01:20:20 2018 From: list at satchell.net (Stephen Satchell) Date: Mon, 19 Mar 2018 18:20:20 -0700 Subject: problems sending to prodigy.net hosted email In-Reply-To: <20180317220405.25083c02@cd> References: <36609701-8ab2-c361-4bc3-84dbc5a43b52@internetpro.net> <31558920-9c22-b030-0708-183f5cbcd3dd@satchell.net> <20180317220405.25083c02@cd> Message-ID: <6f7b1ee8-6538-47d3-1a4d-d30d3c9f6d4e@satchell.net> On 03/17/2018 02:04 PM, Chris wrote: > Stephen Satchell wrote: > >> (I know in my consulting practice I strongly discourage having ANY >> other significant services on DNS servers. RADIUS and DHCP, ok, but >> not mail or web. For CPanel and PLESK web boxes, have the NS records >> point to a pair of DNS-dedicated servers, and sync the zone files >> with the ones on the Web boxes.) > Why not? Never had a problem with multiple services on linux, in > contrast to windows where every service requires its own box (or at > least vm). 1. Spreading the attack surface across multiple system. Just because someone is nailing your web server doesn't affect your DNS server, or mail, or authentication, or logging, or... 2. Robustness during maintenance. Browsers cache DNS responses, including NXDOMAIN responses. Just because your web server is inaccessible while you do something with it doesn't mean the browser is completely disconnect when you bring it back up. Ditto mail servers 3. Application-specifc attack mitigation on each type of server. It's far easier to lock down a DNS server if you don't have any other significant servers running. Ditto for mail, ditto for Web, ditto for syslog servers, and so forth. 4. Limit what an attacker can do if s/he "breaks through" your protections. I even go so far as to impose severe limits on the internet, nominally "trusted" network, to minimize cross-server attacks through the local network. In short, systems should *not* blindly trust neighboring systems. I don't like publicly facing VMs. They are find for internal functions that are *not* exposed to the world. (You can't help it with cloud-hosted objects, but just remember that cloud servers can be compromised just as easily as iron-hosted servers, perhaps even more easily.) About cloud: I prefer that any cloud-hosted servers not have mission-critical functions. The best use of cloud servers, in my opinion, is to host user interface tasks, and tunnel through to servers in my machine room for data. Depends on the application, but my critical data is in my machines. I still recall when I was working on APRAnet and the Morris worm first launched. I also recall when the IMPs were flipping bits so that packets would have addresses changed and start running forever until the entire ARPAnet was restarted. That's when TTL was introduced into the NCP implementation at the time. From list at satchell.net Tue Mar 20 01:30:44 2018 From: list at satchell.net (Stephen Satchell) Date: Mon, 19 Mar 2018 18:30:44 -0700 Subject: Fwd: Re: problems sending to prodigy.net hosted email In-Reply-To: <20180319175533.49aaf7f2@cd> References: <20180319175533.49aaf7f2@cd> Message-ID: <835c1064-cf4e-d8a8-8b7d-52129885e5f8@satchell.net> Two DNS servers hosted on one box (or VM object), even with two addresses, is easily compromised by DDoS amplification attacks. That's the norm for a number of "web control panel" systems like Plesk and CPanel. It depends on the scale of your operations. Last time I was in that situation, I had roughly 25,000 domains spread across 30 servers. Life became MUCH simpler when I put up dedicated, and high-power, physical systems running non-recursive BIND for DNS1 and DNS2, as well as another pair of boxes running recursive servers as DNS3 and DNS4. Getting QMail and Exim to "smart host" to my monster MX servers proved to be pretty easy, and I even was able to get the web servers to tell me when a mailbox was full so I could reject the SMTP exchange at the edge, instead of generating backscatter. And, with a pool of roughly 4,000 IP addresses, I got rid of ARP storms in our network by putting up a little server called "ackbar", that was configured to respond to all otherwise unused IP address in our pool. (Edge routers were Cisco 7000 class, with DS3 uplinks.) Lessons learned well. -------- Forwarded Message -------- Subject: Re: problems sending to prodigy.net hosted email Date: Mon, 19 Mar 2018 17:55:33 +0100 From: Chris To: C. Jon Larsen CC: nanog at nanog.org On Mon, 19 Mar 2018 11:56:16 -0400 (EDT) C. Jon Larsen wrote: > > Why not? Never had a problem with multiple services on linux, in > > contrast to windows where every service requires its own box (or at > > least vm). > > Go for it ! Failure is an awesome teacher :) Don't really see a problem, especially since you normally always have two DNS servers... -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From coloccia at geneseo.edu Mon Mar 19 15:50:56 2018 From: coloccia at geneseo.edu (Rick Coloccia) Date: Mon, 19 Mar 2018 11:50:56 -0400 Subject: Spiffy Netflow tools? In-Reply-To: References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <454d7b09-a727-b5af-a1c4-f1e8708bc333@nordu.net> <2A55570D-7163-4849-B7AC-041237735E19@farrokhi.net> Message-ID: Also +1 for plixer scrutinizer. On 3/19/2018 10:16 AM, Gustavo Santos wrote: > +1 for Plixer Scrutinizer > > 2018-03-17 19:42 GMT-03:00 Michael Krygeris : > >> Disclaimer: Am Plixer engineer. >> If you want to take it for a spin, you can download a fully functional >> OVA/QCOW2 30 day eval from the plixer website. I can also get you access to >> an AWS AMI as well. >> I don’t want to turn this into an Ad. So DM if you need any info/access. >> >> Mike Krygeris >> >> On Tue, Mar 13, 2018 at 11:52 AM Babak Farrokhi >> wrote: >> >>> Plixer is also interesting. >>> >>> nfdump works great with NetFlow but support for IPFIX is somehow limited >>> to basics. >>> >>> >>> -- >>> Babak >>> >>> >>> On 13 Mar 2018, at 3:20, Fredrik Korsbäck wrote: >>> >>>> On 2018-03-13 00:24, mike.lyon at gmail.com wrote: >>>>> Howdy! >>>>> >>>>> Checking out various Netflow tools and wanted to see what others are >>>>> using? >>>>> >>>>> Kentik is cool. Are they the only SaaS based flow digester? I don’t >>>>> seem to see any others. >>>>> >>>>> Also curious about on-prem solutions as well. >>>>> >>>>> Thanks! >>>>> Mike >>>>> >>>> Kentik is probably top of the foodchain right now. >>>> >>>> But they are certainly not alone in the biz. Ontop of my head... >>>> >>>> * Flowmon >>>> * Talaia >>>> * Arbor Peakflow >>>> * Deepfield >>>> * Pmacct + supporting toolkit >>>> * NFsen/Nfdump/AS-stats >>>> * Put kibana/ES infront of any collector >>>> * Solarwinds something something >>>> * Different vendor toolkits >>>> >>>> >>>> >>>> -- >>>> hugge -- Rick Coloccia, Jr. Network Manager State University of NY College at Geneseo 1 College Circle, 119 South Hall Geneseo, NY 14454 V: 585-245-5577 F: 585-245-5579 From cbronson at iec-electronics.com Tue Mar 20 17:15:25 2018 From: cbronson at iec-electronics.com (Charles Bronson) Date: Tue, 20 Mar 2018 17:15:25 +0000 Subject: [EXT] Fwd: Re: problems sending to prodigy.net hosted email In-Reply-To: <835c1064-cf4e-d8a8-8b7d-52129885e5f8@satchell.net> References: <20180319175533.49aaf7f2@cd> <835c1064-cf4e-d8a8-8b7d-52129885e5f8@satchell.net> Message-ID: If this isn't pertinent to the list, feel free to answer privately. How did you implement the server that got rid of ARP storms? Charles Bronson -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Monday, March 19, 2018 9:31 PM To: nanog at nanog.org Subject: [EXT] Fwd: Re: problems sending to prodigy.net hosted email Two DNS servers hosted on one box (or VM object), even with two addresses, is easily compromised by DDoS amplification attacks. That's the norm for a number of "web control panel" systems like Plesk and CPanel. It depends on the scale of your operations. Last time I was in that situation, I had roughly 25,000 domains spread across 30 servers. Life became MUCH simpler when I put up dedicated, and high-power, physical systems running non-recursive BIND for DNS1 and DNS2, as well as another pair of boxes running recursive servers as DNS3 and DNS4. Getting QMail and Exim to "smart host" to my monster MX servers proved to be pretty easy, and I even was able to get the web servers to tell me when a mailbox was full so I could reject the SMTP exchange at the edge, instead of generating backscatter. And, with a pool of roughly 4,000 IP addresses, I got rid of ARP storms in our network by putting up a little server called "ackbar", that was configured to respond to all otherwise unused IP address in our pool. (Edge routers were Cisco 7000 class, with DS3 uplinks.) Lessons learned well. -------- Forwarded Message -------- Subject: Re: problems sending to prodigy.net hosted email Date: Mon, 19 Mar 2018 17:55:33 +0100 From: Chris To: C. Jon Larsen CC: nanog at nanog.org On Mon, 19 Mar 2018 11:56:16 -0400 (EDT) C. Jon Larsen wrote: > > Why not? Never had a problem with multiple services on linux, in > > contrast to windows where every service requires its own box (or at > > least vm). > > Go for it ! Failure is an awesome teacher :) Don't really see a problem, especially since you normally always have two DNS servers... -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From jnford at uiowa.net Tue Mar 20 17:35:53 2018 From: jnford at uiowa.net (Jay Ford) Date: Tue, 20 Mar 2018 12:35:53 -0500 (CDT) Subject: hijacking of 128.255.192.0/22 Message-ID: Something apparently in Brazil is hijacking 128.255.192.0/22, part of 128.255.0.0/16 which is held by the University of Iowa. AS 263971 is announcing 128.255.192.0/22 which Hurricane Electric is accepting & propagating. None of that has any authorization. I can't find any decent contact information for the originating entity, so I have reported it to abuse at he.net, but it'd be fabulous if some HE folks listening here could whack the hijacking faster than the abuse channels will get to it. Also useful would be some functional contact for AS263971. Any help will be appreciated. ________________________________________________________________________ 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 alejandroacostaalamo at gmail.com Tue Mar 20 19:20:47 2018 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Tue, 20 Mar 2018 16:20:47 -0300 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: Message-ID: Hi Jay,   Please note that there is Lacnog mailing list.., I will forward your message. Not sure if it will work but worth giving it a try. Regards, Alejandro, El 20/3/18 a las 2:35 p. m., Jay Ford escribió: > Something apparently in Brazil is hijacking 128.255.192.0/22, part of > 128.255.0.0/16 which is held by the University of Iowa.  AS 263971 is > announcing 128.255.192.0/22 which Hurricane Electric is accepting & > propagating.  None of that has any authorization. > > I can't find any decent contact information for the originating > entity, so I have reported it to abuse at he.net, but it'd be fabulous if > some HE folks listening here could whack the hijacking faster than the > abuse channels will get to it.  Also useful would be some functional > contact for AS263971. > > Any help will be appreciated. > > ________________________________________________________________________ > 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 math at sizone.org Tue Mar 20 19:25:51 2018 From: math at sizone.org (Ken Chase) Date: Tue, 20 Mar 2018 15:25:51 -0400 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: Message-ID: <20180320192551.GA3785@sizone.org> A reason to de-aggregate down to /24s, to make hijacks more difficult/less effective? /kc On Tue, Mar 20, 2018 at 04:20:47PM -0300, Alejandro Acosta said: >Hi Jay, > >?? Please note that there is Lacnog mailing list.., I will forward your >message. Not sure if it will work but worth giving it a try. > > >Regards, > >Alejandro, > > > >El 20/3/18 a las 2:35 p. m., Jay Ford escribi??: >> Something apparently in Brazil is hijacking 128.255.192.0/22, part of >> 128.255.0.0/16 which is held by the University of Iowa.?? AS 263971 is >> announcing 128.255.192.0/22 which Hurricane Electric is accepting & >> propagating.?? None of that has any authorization. >> >> I can't find any decent contact information for the originating >> entity, so I have reported it to abuse at he.net, but it'd be fabulous if >> some HE folks listening here could whack the hijacking faster than the >> abuse channels will get to it.?? Also useful would be some functional >> contact for AS263971. >> >> Any help will be appreciated. >> >> ________________________________________________________________________ >> 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 > -- Ken Chase - math at sizone.org From job at instituut.net Tue Mar 20 19:32:04 2018 From: job at instituut.net (Job Snijders) Date: Tue, 20 Mar 2018 19:32:04 +0000 Subject: hijacking of 128.255.192.0/22 In-Reply-To: <20180320192551.GA3785@sizone.org> References: <20180320192551.GA3785@sizone.org> Message-ID: On Tue, 20 Mar 2018 at 19:26, Ken Chase wrote: > A reason to de-aggregate down to /24s, to make hijacks more difficult/less > effective? Or perhaps something less costly for everyone: a reason for HE to implement prefix-based EBGP filters? At any given moment there appear to be roughly 5500 prefixes in HE’s customer cone for which no attestation can be found in any of IRR, RPKI or WHOIS. I find this deeply concerning. Kind regards, Job > From lista-gter at tbonet.net.br Tue Mar 20 19:39:45 2018 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Tue, 20 Mar 2018 16:39:45 -0300 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: <20180320192551.GA3785@sizone.org> Message-ID: I contacted the company and forwarded this email to them. Best regards, João Butzke. Em 20/03/2018 16:32, Job Snijders escreveu: > On Tue, 20 Mar 2018 at 19:26, Ken Chase wrote: > >> A reason to de-aggregate down to /24s, to make hijacks more difficult/less >> effective? > > Or perhaps something less costly for everyone: a reason for HE to implement > prefix-based EBGP filters? > > At any given moment there appear to be roughly 5500 prefixes in HE’s > customer cone for which no attestation can be found in any of IRR, RPKI or > WHOIS. I find this deeply concerning. > > Kind regards, > > Job > From alejandroacostaalamo at gmail.com Tue Mar 20 19:40:31 2018 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Tue, 20 Mar 2018 16:40:31 -0300 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: Message-ID: Hello,   Someone in Lacnog privately told me this: aut-num: AS263971 owner: FaleMais Comunicações LTDA responsible: Paulo Henrique Mem Pereira owner-c: LEVAL5 routing-c: LEVAL5 abuse-c: LEVAL5 created: 20150831 changed: 20150831 inetnum: 138.255.192.0/22 inetnum: 2804:28a0::/32 inetnum: 170.254.76.0/22 Regards, Alejandro, El 20/3/18 a las 2:35 p. m., Jay Ford escribió: > Something apparently in Brazil is hijacking 128.255.192.0/22, part of > 128.255.0.0/16 which is held by the University of Iowa.  AS 263971 is > announcing 128.255.192.0/22 which Hurricane Electric is accepting & > propagating.  None of that has any authorization. > > I can't find any decent contact information for the originating > entity, so I have reported it to abuse at he.net, but it'd be fabulous if > some HE folks listening here could whack the hijacking faster than the > abuse channels will get to it.  Also useful would be some functional > contact for AS263971. > > Any help will be appreciated. > > ________________________________________________________________________ > 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 hugo at slabnet.com Tue Mar 20 19:57:00 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 20 Mar 2018 12:57:00 -0700 Subject: Managing ARP traffic [ was Re: [EXT] Fwd: Re: problems sending to prodigy.net hosted email ] In-Reply-To: References: <20180319175533.49aaf7f2@cd> <835c1064-cf4e-d8a8-8b7d-52129885e5f8@satchell.net> Message-ID: <20180320195700.GL25899@bamboo.slabnet.com> On Tue 2018-Mar-20 17:15:25 +0000, Charles Bronson wrote: >If this isn't pertinent to the list, feel free to answer privately. How did you implement the server that got rid of ARP storms? Perhaps something like an ARP sponge? https://ams-ix.net/technical/specifications-descriptions/controlling-arp-traffic-on-ams-ix-platform -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sandy at tislabs.com Tue Mar 20 20:32:33 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 20 Mar 2018 16:32:33 -0400 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: Message-ID: <07C3D00B-D3D4-430D-8810-23912D536D1B@tislabs.com> You are pointing out that 138.255.192.0/22 is the likely cause of the hijack of 128.255.192.0/22, right? (No need to be privately told - that’s straight from the LACNIC Whois) —Sandy > On Mar 20, 2018, at 3:40 PM, Alejandro Acosta wrote: > > Hello, > > Someone in Lacnog privately told me this: > > > aut-num: AS263971 owner: FaleMais Comunicações LTDA responsible: Paulo > Henrique Mem Pereira owner-c: LEVAL5 routing-c: LEVAL5 abuse-c: LEVAL5 > created: 20150831 changed: 20150831 inetnum: 138.255.192.0/22 inetnum: > 2804:28a0::/32 inetnum: 170.254.76.0/22 > Regards, Alejandro, > > > El 20/3/18 a las 2:35 p. m., Jay Ford escribió: >> Something apparently in Brazil is hijacking 128.255.192.0/22, part of >> 128.255.0.0/16 which is held by the University of Iowa. AS 263971 is >> announcing 128.255.192.0/22 which Hurricane Electric is accepting & >> propagating. None of that has any authorization. >> >> I can't find any decent contact information for the originating >> entity, so I have reported it to abuse at he.net, but it'd be fabulous if >> some HE folks listening here could whack the hijacking faster than the >> abuse channels will get to it. Also useful would be some functional >> contact for AS263971. >> >> Any help will be appreciated. >> >> ________________________________________________________________________ >> 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 tim at snas.io Tue Mar 20 20:53:21 2018 From: tim at snas.io (Tim Evens) Date: Tue, 20 Mar 2018 13:53:21 -0700 Subject: hijacking of 128.255.192.0/22 In-Reply-To: <07C3D00B-D3D4-430D-8810-23912D536D1B@tislabs.com> References: <07C3D00B-D3D4-430D-8810-23912D536D1B@tislabs.com> Message-ID: <400f9c6fb61d2fc5694b362dadd40ddb@evensweb.com> Looks like this incident didn't start today. I show it starting back on 2/22 at 00:31:38 UTC. It then persisted till 3/19 where it started to get withdrawn by most peers. It wasn't until 3/20 at 19:10:10 UTC when it was globally withdrawn from all peers that were advertising it. I'll be like Job and plug monitoring. Had FaleMais and/or University of Iowa been monitoring their own prefixes as well as what they advertised (originate in this case), this could have been stopped when it started almost a month ago. --Tim On 20.03.2018 13:32, Sandra Murphy wrote: > You are pointing out that 138.255.192.0/22 is the likely cause of the hijack of 128.255.192.0/22, right? > > (No need to be privately told - that's straight from the LACNIC Whois) > > --Sandy > On Mar 20, 2018, at 3:40 PM, Alejandro Acosta wrote: Hello, Someone in Lacnog privately told me this: aut-num: AS263971 owner: FaleMais Comunicações LTDA responsible: Paulo Henrique Mem Pereira owner-c: LEVAL5 routing-c: LEVAL5 abuse-c: LEVAL5 created: 20150831 changed: 20150831 inetnum: 138.255.192.0/22 inetnum: 2804:28a0::/32 inetnum: 170.254.76.0/22 Regards, Alejandro, El 20/3/18 a las 2:35 p. m., Jay Ford escribió: Something apparently in Brazil is hijacking 128.255.192.0/22, part of 128.255.0.0/16 which is held by the University of Iowa. AS 263971 is announcing 128.255.192.0/22 which Hurricane Electric is accepting & propagating. None of that has any authorization. I can't find any decent contact information for the originating entity, so I have reported it to abuse at he.net, but it'd be fabulous if some HE folks listening here could whack the hijacking faster than the abuse channels will get to it. Also useful would be some functional contact for AS263971. Any help will be appreciated. ________________________________________________________________________ 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 Links: ------ [1] http://170.254.76.0/22 From benno at NLnetLabs.nl Tue Mar 20 23:57:55 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 20 Mar 2018 23:57:55 +0000 Subject: Last call for presentations and Draft programme for RIPE 76 Message-ID: <33ce28ca-5fe5-ec31-215c-b384f359192a@NLnetLabs.nl> Colleagues, A list of currently accepted RIPE 76 presentations is now published at: https://ripe76.ripe.net/programme/meeting-plan/plenary/ There are still plenary, BoF, tutorial and workshop slots remaining for the final RIPE 76 programme and RIPE Programme Committee will accept new proposals until *8 April 2018*. This is our last call for you to submit your proposals. You can find the CFP for RIPE 76 below, or at https://ripe76.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe76.ripe.net/ripe-pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 76 will take place from 14-18 May in Marseille, France. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *8 April 2018*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc at ripe.net. -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From sp at iphh.net Wed Mar 21 00:43:52 2018 From: sp at iphh.net (Sascha Pollok) Date: Wed, 21 Mar 2018 01:43:52 +0100 Subject: Contacts at AS42624 Simple Carrier LLC ? In-Reply-To: <45209fb7-b835-aa82-7c24-9dcd6643d472@iphh.net> References: <45209fb7-b835-aa82-7c24-9dcd6643d472@iphh.net> Message-ID: <16246031d40.27df.0891eb2d685d091c0d1b837b0ec4f146@iphh.net> Hi people! Did anyone have any encounter with AS42624 Simple Carrier LLC? They send some abusive and spoofed traffic. Looking at the usual databases it seems a bit unclear to me where the actually come from and how to reach them. Thanks & buh bye Sascha From list at satchell.net Wed Mar 21 01:38:31 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 20 Mar 2018 18:38:31 -0700 Subject: Fwd: RE: [EXT] Fwd: Re: problems sending to prodigy.net hosted email In-Reply-To: References: Message-ID: <0a82e556-15ed-f473-31da-4f0802106920@satchell.net> Linux systems have the ability, given enough RAM, to associate almost any number of IP addresses to a given interface. Our IP allocation database kept track of who was using what IP address. I wrote some queries to collect all unassigned IP addresses, and to construct the appropriate shell commands to assign those IP addresses to Ackbar's interface. Part of the program would also remove any allocated IP addresses from the server automtically. Worked like a charm. Whenever someone would nmap our address space, there would be at most one ARP request for the address; the router would then remember the IP->MAC association for the subsequent scans for a period of time -- 30 minutes if we were renumbering, 12 hours otherwise. The Ackbar server lived attached to our main distribution switch, so that subsequent traffic to those unused IP addresses stayed out of the server farm. We had some, er, "interesting" denial of service attacks that didn't do as much damage as they could have. -------- Forwarded Message -------- Subject: RE: [EXT] Fwd: Re: problems sending to prodigy.net hosted email Date: Tue, 20 Mar 2018 17:15:25 +0000 From: Charles Bronson To: nanog at nanog.org If this isn't pertinent to the list, feel free to answer privately. How did you implement the server that got rid of ARP storms? Charles Bronson -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Monday, March 19, 2018 9:31 PM To: nanog at nanog.org Subject: [EXT] Fwd: Re: problems sending to prodigy.net hosted email Two DNS servers hosted on one box (or VM object), even with two addresses, is easily compromised by DDoS amplification attacks. That's the norm for a number of "web control panel" systems like Plesk and CPanel. It depends on the scale of your operations. Last time I was in that situation, I had roughly 25,000 domains spread across 30 servers. Life became MUCH simpler when I put up dedicated, and high-power, physical systems running non-recursive BIND for DNS1 and DNS2, as well as another pair of boxes running recursive servers as DNS3 and DNS4. Getting QMail and Exim to "smart host" to my monster MX servers proved to be pretty easy, and I even was able to get the web servers to tell me when a mailbox was full so I could reject the SMTP exchange at the edge, instead of generating backscatter. And, with a pool of roughly 4,000 IP addresses, I got rid of ARP storms in our network by putting up a little server called "ackbar", that was configured to respond to all otherwise unused IP address in our pool. (Edge routers were Cisco 7000 class, with DS3 uplinks.) Lessons learned well. -------- Forwarded Message -------- Subject: Re: problems sending to prodigy.net hosted email Date: Mon, 19 Mar 2018 17:55:33 +0100 From: Chris To: C. Jon Larsen CC: nanog at nanog.org On Mon, 19 Mar 2018 11:56:16 -0400 (EDT) C. Jon Larsen wrote: > > Why not? Never had a problem with multiple services on linux, in > > contrast to windows where every service requires its own box (or at > > least vm). > > Go for it ! Failure is an awesome teacher :) Don't really see a problem, especially since you normally always have two DNS servers... -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From jcurran at arin.net Wed Mar 21 11:57:33 2018 From: jcurran at arin.net (John Curran) Date: Wed, 21 Mar 2018 11:57:33 +0000 Subject: TIMELY - Fwd: RIPE NCC Global IPv6 Deployment Survey References: <04f85099-bcc7-ea89-a791-0e07e7502001@ripe.net> Message-ID: <885AA111-BE96-4C73-862C-00E64B82B009@arin.net> NANOGers - An important reminder: this Global IPv6 deployment survey is closing at the end of March. If you have a moment, please take the time to complete this survey so that the RIRs may collectively have a better understanding of the status of IPv6 deployment in the Internet. Thanks! /John John Curran President and CEO ARIN > Begin forwarded message: > > From: Massimiliano Stucchi > Subject: RIPE NCC Global IPv6 Deployment Survey > Date: 12 February 2018 at 9:14:57 AM EST > To: nanog at nanog.org > Reply-To: mstucchi at ripe.net > > > Dear colleagues, > > The RIPE NCC would like to invite you to participate in its Global IPv6 > Survey 2018. The goal of the survey is to get an overview IPv6 > deployment across the world, and to assess how this is seen from the > perspective of ISPs and Enterprise users. > > The 2018 survey is a follow up to similar surveys run between 2008 and > 2013, and will serve as a > comparison with the data acquired back then. > > You can find the survey at the following address: > > https://www.surveymonkey.com/r/GlobalIPv6survey2018 > > Responses can be submitted until 31 March 2018. > > We will then collect the data with the aim of presenting the preliminary > results during the upcoming RIPE 76 meeting in Marseille. > > If you have any question about the survey, please feel free to email us > at: ipv6survey2018 at ripe.net. > > Thank you very much in advance for your participation! > > -- > > Massimiliano Stucchi > IPv6 Programme Manager > RIPE NCC > mstucchi at ripe.net > > Follow us on Twitter for the fastest and latest RIPE NCC Training news! > @TrainingRIPENCC > -------------- 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 jason+nanog at lixfeld.ca Wed Mar 21 13:10:28 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 21 Mar 2018 09:10:28 -0400 Subject: How are you configuring BFD timers? Message-ID: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> Hey, For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial: Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable. But? From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear? We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments. I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? Thanks! From cra at WPI.EDU Wed Mar 21 14:46:02 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 21 Mar 2018 10:46:02 -0400 Subject: How are you configuring BFD timers? In-Reply-To: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> Message-ID: <20180321144602.wqbj26tbxf7nru7z@angus.ind.wpi.edu> In practice, the vendor's recommendations regarding Routing Engine HA provide a lower bound. I'm just starting out with 1000ms x 3 multiplier, but my network is not national or global. I believe I could go as low as 500ms to keep HA happy. On Wed, Mar 21, 2018 at 09:10:28AM -0400, Jason Lixfeld wrote: > For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. From Alex.Lembesis at tevapharm.com Wed Mar 21 15:11:47 2018 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Wed, 21 Mar 2018 15:11:47 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> Message-ID: <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Using 250ms x 3 on fiber connecting Pennsylvania to Florida... Best regards, Alex -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld (External) Sent: Wednesday, March 21, 2018 9:10 AM To: NANOG Subject: How are you configuring BFD timers? Hey, For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial: Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable. But? From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear? We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments. I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? Thanks! This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From bengelly at gmail.com Wed Mar 21 15:32:53 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 21 Mar 2018 16:32:53 +0100 Subject: How are you configuring BFD timers? In-Reply-To: <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: Using 200 ms / 200 ms / x3 on either metro dark fiber or longhaul waves (Paris / Frankfurt / Amsterdam) successfully. Best regards. Y. 2018-03-21 16:11 GMT+01:00 Alex Lembesis : > Using 250ms x 3 on fiber connecting Pennsylvania to Florida... > > Best regards, > > > > Alex > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld > (External) > Sent: Wednesday, March 21, 2018 9:10 AM > To: NANOG > Subject: How are you configuring BFD timers? > > Hey, > > For those running BFD on your land-based point-to-point links, I’m > interested in hearing about what factors you consider when deciding how to > configure your timers and multiplier. > > On paper, BFD between two devices over a local or metro dark fibre or wave > seems pretty trivial: Assuming your gear can a) support echo mode b) > hardware offloads echo processing c) automatically treats echos as vital > and puts them into the appropriate high priority queue, then setting the > timers down to their lowest possible values (3ms on some of the gear that > I’ve seen) and some low multiplier seems more than reasonable. But? > > From another angle, your link isn’t dark fibre or a wave but, for example, > ethernet over some sort of IP based L2 Transport, and is still a low (sub > 1ms) one-way latency local or metro link. How do you set your timers, and > what do you base that on? > > From yet another angle, what if your link is a long-haul wave, or for that > matter a wave of any distance that imposes a one-way latency that is higher > than the minimum tx and rx timers that are supported by your gear? We’ll > assume an unprotected wave, because I’m sure if it’s protected, you have no > choice but to consider the one-way latency of the longest of the two > segments. > > I made some assumptions above about support for echo mode and hardware > offload, but what if (some of) your gear doesn’t support some or all of > that stuff? How do you factor your configuration decisions? > > Thanks! > > This message is intended solely for the designated recipient(s). It may > contain confidential or proprietary information and may be subject to > attorney-client privilege or other confidentiality protections. If you are > not a designated recipient you may not review, copy or distribute this > message. If you receive this in error, please notify the sender by reply > e-mail and delete this message. Thank you. > From joe.carroll at telplicity.com Wed Mar 21 14:46:40 2018 From: joe.carroll at telplicity.com (Joe Carroll) Date: Wed, 21 Mar 2018 10:46:40 -0400 Subject: Telx Internet Exchange Atlanta Message-ID: Is there anyone on the list from TelX with visibility into the Atlanta TIE ? From job at instituut.net Wed Mar 21 16:24:47 2018 From: job at instituut.net (Job Snijders) Date: Wed, 21 Mar 2018 16:24:47 +0000 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: Silly question perhaps, but why would you do BFD on dark fiber? Kind regards, Job From Alex.Lembesis at tevapharm.com Wed Mar 21 16:31:27 2018 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Wed, 21 Mar 2018 16:31:27 +0000 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. Best regards, Alex -----Original Message----- From: Job Snijders (External) [mailto:job at instituut.net] Sent: Wednesday, March 21, 2018 12:25 PM To: Youssef Bengelloun-Zahr Cc: Alex Lembesis; NANOG Subject: Re: How are you configuring BFD timers? Silly question perhaps, but why would you do BFD on dark fiber? Kind regards, Job This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From bryan at shout.net Wed Mar 21 16:35:16 2018 From: bryan at shout.net (Bryan Holloway) Date: Wed, 21 Mar 2018 11:35:16 -0500 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> Wouldn't any tangible problem on a dark-fiber link result in an interface shutdown, ostensibly creating the trigger one would need to begin re-convergence? On 3/21/18 11:31 AM, Alex Lembesis wrote: > To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. > > Best regards, > > > > Alex > > > > -----Original Message----- > From: Job Snijders (External) [mailto:job at instituut.net] > Sent: Wednesday, March 21, 2018 12:25 PM > To: Youssef Bengelloun-Zahr > Cc: Alex Lembesis; NANOG > Subject: Re: How are you configuring BFD timers? > > Silly question perhaps, but why would you do BFD on dark fiber? > > Kind regards, > > Job > > This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. > From lguillory at reservetele.com Wed Mar 21 16:37:03 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 21 Mar 2018 16:37:03 +0000 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> He's asking because if it was dark the interface would go down when the link was lost and the router would pull routes. But PA to FL would lead me to believe it'll be a wave from some type of DWDM gear which brings us to BFD. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.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. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Lembesis Sent: Wednesday, March 21, 2018 11:31 AM To: Job Snijders (External); Youssef Bengelloun-Zahr Cc: NANOG Subject: RE: How are you configuring BFD timers? To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. Best regards, Alex -----Original Message----- From: Job Snijders (External) [mailto:job at instituut.net] Sent: Wednesday, March 21, 2018 12:25 PM To: Youssef Bengelloun-Zahr Cc: Alex Lembesis; NANOG Subject: Re: How are you configuring BFD timers? Silly question perhaps, but why would you do BFD on dark fiber? Kind regards, Job This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From Alex.Lembesis at tevapharm.com Wed Mar 21 16:44:14 2018 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Wed, 21 Mar 2018 16:44:14 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: <296d47917dd24e4e9164e780782fb5e2@USEXCAPP13.Teva.Corp> Correct, Luke. Best regards, Alex -----Original Message----- From: Luke Guillory (External) [mailto:lguillory at reservetele.com] Sent: Wednesday, March 21, 2018 12:37 PM To: Alex Lembesis; Job Snijders (External); Youssef Bengelloun-Zahr Cc: NANOG Subject: RE: How are you configuring BFD timers? He's asking because if it was dark the interface would go down when the link was lost and the router would pull routes. But PA to FL would lead me to believe it'll be a wave from some type of DWDM gear which brings us to BFD. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.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. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Lembesis Sent: Wednesday, March 21, 2018 11:31 AM To: Job Snijders (External); Youssef Bengelloun-Zahr Cc: NANOG Subject: RE: How are you configuring BFD timers? To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. Best regards, Alex -----Original Message----- From: Job Snijders (External) [mailto:job at instituut.net] Sent: Wednesday, March 21, 2018 12:25 PM To: Youssef Bengelloun-Zahr Cc: Alex Lembesis; NANOG Subject: Re: How are you configuring BFD timers? Silly question perhaps, but why would you do BFD on dark fiber? Kind regards, Job This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From matlockken at gmail.com Wed Mar 21 16:57:14 2018 From: matlockken at gmail.com (Ken Matlock) Date: Wed, 21 Mar 2018 10:57:14 -0600 Subject: How are you configuring BFD timers? In-Reply-To: <296d47917dd24e4e9164e780782fb5e2@USEXCAPP13.Teva.Corp> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> <296d47917dd24e4e9164e780782fb5e2@USEXCAPP13.Teva.Corp> Message-ID: Right, BFD on a dark fiber link (should) be immediately detected and the detecting end should send a cease/stop/whatever message to the remote peer to drop the neighbor relationship. BFD really comes into it's own in a derived circuit (such as metro-E or other type setup) where you can have an indirect failure (traffic does not pass, but the last mile link remains up). Ken On Wed, Mar 21, 2018 at 10:44 AM, Alex Lembesis wrote: > Correct, Luke. > > Best regards, > > Alex > > > > -----Original Message----- > From: Luke Guillory (External) [mailto:lguillory at reservetele.com] > Sent: Wednesday, March 21, 2018 12:37 PM > To: Alex Lembesis; Job Snijders (External); Youssef Bengelloun-Zahr > Cc: NANOG > Subject: RE: How are you configuring BFD timers? > > He's asking because if it was dark the interface would go down when the > link was lost and the router would pull routes. But PA to FL would lead me > to believe it'll be a wave from some type of DWDM gear which brings us to > BFD. > > > > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.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. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Lembesis > Sent: Wednesday, March 21, 2018 11:31 AM > To: Job Snijders (External); Youssef Bengelloun-Zahr > Cc: NANOG > Subject: RE: How are you configuring BFD timers? > > To speed up BGP routing convergence. The (2x) dark fiber links from PA to > FL are being used as Layer3 datacenter interconnects, where each datacenter > has its own AS. The DF is also carrying FCIP traffic, so we need failover > to be as fast as possible. > > Best regards, > > > > Alex > > > > -----Original Message----- > From: Job Snijders (External) [mailto:job at instituut.net] > Sent: Wednesday, March 21, 2018 12:25 PM > To: Youssef Bengelloun-Zahr > Cc: Alex Lembesis; NANOG > Subject: Re: How are you configuring BFD timers? > > Silly question perhaps, but why would you do BFD on dark fiber? > > Kind regards, > > Job > > This message is intended solely for the designated recipient(s). It may > contain confidential or proprietary information and may be subject to > attorney-client privilege or other confidentiality protections. If you are > not a designated recipient you may not review, copy or distribute this > message. If you receive this in error, please notify the sender by reply > e-mail and delete this message. Thank you. > > This message is intended solely for the designated recipient(s). It may > contain confidential or proprietary information and may be subject to > attorney-client privilege or other confidentiality protections. If you are > not a designated recipient you may not review, copy or distribute this > message. If you receive this in error, please notify the sender by reply > e-mail and delete this message. Thank you. > From kmedcalf at dessus.com Wed Mar 21 17:06:26 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 21 Mar 2018 11:06:26 -0600 Subject: [EXT] Fwd: Re: problems sending to prodigy.net hosted email In-Reply-To: <0a82e556-15ed-f473-31da-4f0802106920@satchell.net> Message-ID: <530274c7ebafb9418b872d4e653087a5@mail.dessus.com> LaBrea Tarpit http://labrea.sourceforge.net/ can do this as well, though perhaps only for IPv4. Basically it looks for unanswered ARP requests and answers them. What it does with the ensuing session data is configurable. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen >Satchell >Sent: Tuesday, 20 March, 2018 19:39 >To: nanog at nanog.org >Subject: Fwd: RE: [EXT] Fwd: Re: problems sending to prodigy.net >hosted email > >Linux systems have the ability, given enough RAM, to associate almost >any number of IP addresses to a given interface. Our IP allocation >database kept track of who was using what IP address. I wrote some >queries to collect all unassigned IP addresses, and to construct the >appropriate shell commands to assign those IP addresses to Ackbar's >interface. Part of the program would also remove any allocated IP >addresses from the server automtically. > >Worked like a charm. > >Whenever someone would nmap our address space, there would be at most >one ARP request for the address; the router would then remember the >IP->MAC association for the subsequent scans for a period of time -- >30 >minutes if we were renumbering, 12 hours otherwise. > >The Ackbar server lived attached to our main distribution switch, so >that subsequent traffic to those unused IP addresses stayed out of >the >server farm. We had some, er, "interesting" denial of service >attacks >that didn't do as much damage as they could have. > > >-------- Forwarded Message -------- >Subject: RE: [EXT] Fwd: Re: problems sending to prodigy.net hosted >email >Date: Tue, 20 Mar 2018 17:15:25 +0000 >From: Charles Bronson >To: nanog at nanog.org > >If this isn't pertinent to the list, feel free to answer privately. >How >did you implement the server that got rid of ARP storms? > > >Charles Bronson > > > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen >Satchell >Sent: Monday, March 19, 2018 9:31 PM >To: nanog at nanog.org >Subject: [EXT] Fwd: Re: problems sending to prodigy.net hosted email > >Two DNS servers hosted on one box (or VM object), even with two >addresses, is easily compromised by DDoS amplification attacks. >That's >the norm for a number of "web control panel" systems like Plesk and >CPanel. > >It depends on the scale of your operations. Last time I was in that >situation, I had roughly 25,000 domains spread across 30 servers. >Life >became MUCH simpler when I put up dedicated, and high-power, physical >systems running non-recursive BIND for DNS1 and DNS2, as well as >another >pair of boxes running recursive servers as DNS3 and DNS4. > >Getting QMail and Exim to "smart host" to my monster MX servers >proved >to be pretty easy, and I even was able to get the web servers to tell >me >when a mailbox was full so I could reject the SMTP exchange at the >edge, >instead of generating backscatter. > >And, with a pool of roughly 4,000 IP addresses, I got rid of ARP >storms >in our network by putting up a little server called "ackbar", that >was >configured to respond to all otherwise unused IP address in our pool. >(Edge routers were Cisco 7000 class, with DS3 uplinks.) > >Lessons learned well. > >-------- Forwarded Message -------- >Subject: Re: problems sending to prodigy.net hosted email >Date: Mon, 19 Mar 2018 17:55:33 +0100 >From: Chris >To: C. Jon Larsen >CC: nanog at nanog.org > >On Mon, 19 Mar 2018 11:56:16 -0400 (EDT) C. Jon Larsen wrote: > >> > Why not? Never had a problem with multiple services on linux, in >> > contrast to windows where every service requires its own box (or >at >> > least vm). >> >> Go for it ! Failure is an awesome teacher :) > >Don't really see a problem, especially since you normally always have >two DNS servers... > >-- >Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der >Mann, der sich als Stellvertreter Christi ausgibt, von dem er >behauptet, >dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser >gehen und selbiges in Wein verwandeln können, hat vollkommen recht. From jason+nanog at lixfeld.ca Wed Mar 21 17:10:53 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 21 Mar 2018 13:10:53 -0400 Subject: How are you configuring BFD timers? In-Reply-To: <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> Message-ID: <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> A few years ago I did some testing and found that the time between the transceiver detecting LOS and the routing protocol (ISIS in this case) being informed that the link was down (triggering the recalculation) took longer than it took BFD to signal ISIS to recalculate. > On Mar 21, 2018, at 12:35 PM, Bryan Holloway wrote: > > Wouldn't any tangible problem on a dark-fiber link result in an interface shutdown, ostensibly creating the trigger one would need to begin re-convergence? > > > On 3/21/18 11:31 AM, Alex Lembesis wrote: >> To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. >> Best regards, >> Alex >> -----Original Message----- >> From: Job Snijders (External) [mailto:job at instituut.net] >> Sent: Wednesday, March 21, 2018 12:25 PM >> To: Youssef Bengelloun-Zahr >> Cc: Alex Lembesis; NANOG >> Subject: Re: How are you configuring BFD timers? >> Silly question perhaps, but why would you do BFD on dark fiber? >> Kind regards, >> Job >> This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From bengelly at gmail.com Wed Mar 21 17:34:43 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 21 Mar 2018 18:34:43 +0100 Subject: How are you configuring BFD timers? In-Reply-To: <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> Message-ID: Which platform ? What context ? Best regards. > Le 21 mars 2018 à 18:10, Jason Lixfeld a écrit : > > A few years ago I did some testing and found that the time between the transceiver detecting LOS and the routing protocol (ISIS in this case) being informed that the link was down (triggering the recalculation) took longer than it took BFD to signal ISIS to recalculate. > >> On Mar 21, 2018, at 12:35 PM, Bryan Holloway wrote: >> >> Wouldn't any tangible problem on a dark-fiber link result in an interface shutdown, ostensibly creating the trigger one would need to begin re-convergence? >> >> >>> On 3/21/18 11:31 AM, Alex Lembesis wrote: >>> To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. >>> Best regards, >>> Alex >>> -----Original Message----- >>> From: Job Snijders (External) [mailto:job at instituut.net] >>> Sent: Wednesday, March 21, 2018 12:25 PM >>> To: Youssef Bengelloun-Zahr >>> Cc: Alex Lembesis; NANOG >>> Subject: Re: How are you configuring BFD timers? >>> Silly question perhaps, but why would you do BFD on dark fiber? >>> Kind regards, >>> Job >>> This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. > From jared at puck.nether.net Wed Mar 21 17:52:57 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 21 Mar 2018 17:52:57 +0000 Subject: hijacking of 128.255.192.0/22 In-Reply-To: References: Message-ID: <245DDF8A-69F4-49B4-8714-7E202A1F16A2@puck.nether.net> Can someone from HE comment on how they are doing their filtering? We often see our routes leaked by them or their customers and it’s quite the problem and significantly contributes to the pollution in the routing table. Often friends and smaller providers come to me for help and the lack of filtering as well as BGP communities poses significant operational issues for networks. Jared Mauch > On Mar 20, 2018, at 5:35 PM, Jay Ford wrote: > > Something apparently in Brazil is hijacking 128.255.192.0/22, part of 128.255.0.0/16 which is held by the University of Iowa. AS 263971 is announcing 128.255.192.0/22 which Hurricane Electric is accepting & propagating. None of that has any authorization. > > I can't find any decent contact information for the originating entity, so I have reported it to abuse at he.net, but it'd be fabulous if some HE folks listening here could whack the hijacking faster than the abuse channels will get to it. Also useful would be some functional contact for AS263971. > > Any help will be appreciated. > > ________________________________________________________________________ > 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 jason+nanog at lixfeld.ca Wed Mar 21 19:09:13 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 21 Mar 2018 15:09:13 -0400 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> Message-ID: <73EE3FCF-6E9A-4008-BFB9-6D78B02B241C@lixfeld.ca> They were ME3600s. AFAIR it was two of these things in a lab connected back to back with two links between them, one metric higher than the other. Some sort of traffic generator running between the two that would generate fixed size UDP frames at some tens of milliseconds interval, yanking the preferred link, counting how many packets were lost and doing some math, correlating with various logs debugs on the boxes. > On Mar 21, 2018, at 1:34 PM, Youssef Bengelloun-Zahr wrote: > > Which platform ? What context ? > > Best regards. > > > >> Le 21 mars 2018 à 18:10, Jason Lixfeld a écrit : >> >> A few years ago I did some testing and found that the time between the transceiver detecting LOS and the routing protocol (ISIS in this case) being informed that the link was down (triggering the recalculation) took longer than it took BFD to signal ISIS to recalculate. >> >>> On Mar 21, 2018, at 12:35 PM, Bryan Holloway wrote: >>> >>> Wouldn't any tangible problem on a dark-fiber link result in an interface shutdown, ostensibly creating the trigger one would need to begin re-convergence? >>> >>> >>>> On 3/21/18 11:31 AM, Alex Lembesis wrote: >>>> To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. >>>> Best regards, >>>> Alex >>>> -----Original Message----- >>>> From: Job Snijders (External) [mailto:job at instituut.net] >>>> Sent: Wednesday, March 21, 2018 12:25 PM >>>> To: Youssef Bengelloun-Zahr >>>> Cc: Alex Lembesis; NANOG >>>> Subject: Re: How are you configuring BFD timers? >>>> Silly question perhaps, but why would you do BFD on dark fiber? >>>> Kind regards, >>>> Job >>>> This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. >> From bellman at nsc.liu.se Wed Mar 21 20:00:53 2018 From: bellman at nsc.liu.se (Thomas Bellman) Date: Wed, 21 Mar 2018 21:00:53 +0100 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: <1a31a262-e0fc-4c9c-664f-7f5e08cd775e@nsc.liu.se> On 2018-03-21 17:24, Job Snijders wrote: > Silly question perhaps, but why would you do BFD on dark fiber? Simple paranoia perhaps? Just because you only have layer 1 equipment (transponders) right now, doesn't guarantee that you won't need to stick in a layer 2 switch in the path tomorrow, and if you already have BFD running, you won't forget to add it at that time. As a real-life example: we have dark fiber from our main campus to another campus in the neighbouring city, and from there we have dark fiber to a partner a few kilometers further away. We run wavelengths the entire way from the main campus to our partner (being demuxed and muxed back at the sub-campus). At one point, the fiber needed to be rerouted, and then the attenuation became to high for one of the CWDM wavelengths. Solution: put an ethernet switch at our sub-campus to act as a kind of amplifier for that wavelength. (This was using 120km CWDM gigabit transceivers directly in the routers at each end. We have since retired those and use 10 gigabit DWDM with transponders and EDFA amplifiers.) Yes, it was a duct-tape solution, but it was cheap and got the work done. :-) /Thomas 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 nanog at ics-il.net Wed Mar 21 20:18:28 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 21 Mar 2018 15:18:28 -0500 (CDT) Subject: Brocade unsupported transceiver? Message-ID: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Wed Mar 21 20:31:24 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 21 Mar 2018 15:31:24 -0500 (CDT) Subject: Brocade unsupported transceiver? In-Reply-To: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> Message-ID: <744823016.6918.1521664282124.JavaMail.mhammett@ThunderFuck> I've had a few offlist responses looking for the same or about coded optics. I've been able to use Brocade -coded optics from FiberStore, but a DAC which should be universal (and passes the muster for the Intel NICs it's plugged into) returns, " 2018/03/21-15:14:00, [NSM-1028], 2679, DCE, ERROR, sw0, Incompatible SFP transceiver for interface TenGigabitEthernet 54/0/16 is detected." Unfortunately, show media doesn't help because the interface is offline. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Wednesday, March 21, 2018 3:18:28 PM Subject: Brocade unsupported transceiver? Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From surfer at mauigateway.com Wed Mar 21 20:38:23 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 21 Mar 2018 13:38:23 -0700 Subject: How are you configuring BFD timers? Message-ID: <20180321133823.49AE6EDC@m0117460.ppops.net> :: For those running BFD on your land-based point-to-point links, :: I’m interested in hearing about what factors you consider when :: deciding how to configure your timers and multiplier. It has been a while since I used BFD, but I remember trying to get it as close to what I wanted and then fine tuning it over time. For example, sometimes it would take down the session when I didn't want it to and I had to turn the knobs a bit. So another thing to consider is your initial design choice is likely to change over time. scott --- jason+nanog at lixfeld.ca wrote: From: Jason Lixfeld For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial: Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable. But? From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear? We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments. I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? Thanks! From nanog at ics-il.net Wed Mar 21 20:56:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 21 Mar 2018 15:56:37 -0500 (CDT) Subject: Brocade unsupported transceiver? In-Reply-To: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> Message-ID: <645036797.6954.1521665792141.JavaMail.mhammett@ThunderFuck> More offlist messages I figured I'd address in one e-mail. VDX-6720 4.1.3b These are the ones that I know work: https://www.fs.com/products/36700.html https://www.fs.com/products/40120.html https://www.fs.com/products/36706.html ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Wednesday, March 21, 2018 3:18:28 PM Subject: Brocade unsupported transceiver? Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From bengelly at gmail.com Wed Mar 21 20:58:17 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 21 Mar 2018 21:58:17 +0100 Subject: Brocade unsupported transceiver? In-Reply-To: <744823016.6918.1521664282124.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> <744823016.6918.1521664282124.JavaMail.mhammett@ThunderFuck> Message-ID: Hi, We have been (and still) using all kinds of brocade hardware, including VDX from early NOS2.x AFAIK, I couldn’t find an equivalent command to « unsupported transceiver ». So you will always get a syslog message, but usually it won’t stop port from coming up. Regarding to optical transceivers, re-encoded 3rd party transceivers work very well. But when it comes to DAC, and we have tested a lot for them, usually we use « original » brocade DACs. We also tested successfully IBM an CISCO DACs, they work just fine but you’ll the usual syslog message. However, DOM information might be incomplete. Best regards. > Le 21 mars 2018 à 21:31, Mike Hammett a écrit : > > I've had a few offlist responses looking for the same or about coded optics. > > I've been able to use Brocade -coded optics from FiberStore, but a DAC which should be universal (and passes the muster for the Intel NICs it's plugged into) returns, " 2018/03/21-15:14:00, [NSM-1028], 2679, DCE, ERROR, sw0, Incompatible SFP transceiver for interface TenGigabitEthernet 54/0/16 is detected." > > Unfortunately, show media doesn't help because the interface is offline. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "NANOG list" > Sent: Wednesday, March 21, 2018 3:18:28 PM > Subject: Brocade unsupported transceiver? > > Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From nanog at ics-il.net Wed Mar 21 22:36:11 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 21 Mar 2018 17:36:11 -0500 (CDT) Subject: Brocade unsupported transceiver? In-Reply-To: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> Message-ID: <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> No one knows of such a command and apparently the VDX line is finicky with what passive DACs they'll work with. I just ordered more of the ones I know that work. Tangent: Is it normal for these guys to still transmit light even when the interface is shut? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Wednesday, March 21, 2018 3:18:28 PM Subject: Brocade unsupported transceiver? Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From bengelly at gmail.com Wed Mar 21 22:46:17 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 21 Mar 2018 23:46:17 +0100 Subject: Brocade unsupported transceiver? In-Reply-To: <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, and they (old hardware plateformes) support only passive DAC. I remember being bitten by this at the time. Tangent : hum 🤔... doesn’t seem normal to me. Maybe a bug ?!? Best regards. > Le 21 mars 2018 à 23:36, Mike Hammett a écrit : > > No one knows of such a command and apparently the VDX line is finicky with what passive DACs they'll work with. I just ordered more of the ones I know that work. > > > Tangent: Is it normal for these guys to still transmit light even when the interface is shut? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "NANOG list" > Sent: Wednesday, March 21, 2018 3:18:28 PM > Subject: Brocade unsupported transceiver? > > Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From eric at lumaoptics.net Wed Mar 21 22:58:49 2018 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 21 Mar 2018 15:58:49 -0700 Subject: Brocade unsupported transceiver? In-Reply-To: <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> Message-ID: <92E3AF4B-B84C-43ED-910C-22AF91C896F8@lumaoptics.net> You need to program the passive dac to look like an active dac. Brocade wants active. Ping me if you want help. Eric Sent from my iPhone > On Mar 21, 2018, at 3:36 PM, Mike Hammett wrote: > > No one knows of such a command and apparently the VDX line is finicky with what passive DACs they'll work with. I just ordered more of the ones I know that work. > > > Tangent: Is it normal for these guys to still transmit light even when the interface is shut? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "NANOG list" > Sent: Wednesday, March 21, 2018 3:18:28 PM > Subject: Brocade unsupported transceiver? > > Anyone know if there is a command in Brocade NOS (4.x) to force the use of an unsupported transceiver? If so, what is it? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From bengelly at gmail.com Thu Mar 22 08:01:41 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Thu, 22 Mar 2018 09:01:41 +0100 Subject: Brocade unsupported transceiver? In-Reply-To: <92E3AF4B-B84C-43ED-910C-22AF91C896F8@lumaoptics.net> References: <87066452.6901.1521663503429.JavaMail.mhammett@ThunderFuck> <2040568632.7025.1521671769038.JavaMail.mhammett@ThunderFuck> <92E3AF4B-B84C-43ED-910C-22AF91C896F8@lumaoptics.net> Message-ID: Hello Eric, I got confused, you are absolutely right. Here is a thread I started a few years ago when we bought our first units : https://community.brocade.com/t5/Ethernet-Fabric-VDX-CNA/Passive-Twinax-cables-not-recognized-in-VDX-switches/td-p/28978 Best regards. 2018-03-21 23:58 GMT+01:00 Eric Litvin : > You need to program the passive dac to look like an active dac. Brocade > wants active. > > Ping me if you want help. > > Eric > > Sent from my iPhone > > > On Mar 21, 2018, at 3:36 PM, Mike Hammett wrote: > > > > No one knows of such a command and apparently the VDX line is finicky > with what passive DACs they'll work with. I just ordered more of the ones I > know that work. > > > > > > Tangent: Is it normal for these guys to still transmit light even when > the interface is shut? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Mike Hammett" > > To: "NANOG list" > > Sent: Wednesday, March 21, 2018 3:18:28 PM > > Subject: Brocade unsupported transceiver? > > > > Anyone know if there is a command in Brocade NOS (4.x) to force the use > of an unsupported transceiver? If so, what is it? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > From jwbensley at gmail.com Thu Mar 22 08:47:32 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 22 Mar 2018 08:47:32 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: On 21 March 2018 at 16:37, Luke Guillory wrote: > He's asking because if it was dark the interface would go down when the link was lost and the router would pull routes. But PA to FL would lead me to believe it'll be a wave from some type of DWDM gear which brings us to BFD. Could it not also help with a unidirectional failure of the fibre? E.g. Loss of signal in only one direction might not bring the link down, but if one BFD peer stops receiving BFD packets it'll bring the link down. On 21 March 2018 at 17:10, Jason Lixfeld wrote: > A few years ago I did some testing and found that the time between the transceiver detecting LOS and the routing protocol (ISIS in this case) being informed that the link was down (triggering the recalculation) took longer than it took BFD to signal ISIS to recalculate. Have you looked at testing and adding this command to your IOS devices: ip routing protocol purge interface Also have you tried to set the carrier delay to zero? carrier-delay down 0 I haven't compared them to BFD explicitly, but I would expect the two commands together to have the same effect as you're seeing with BFD (the link down is signaled to the IGP ASAP). Cheers, James. From saku at ytti.fi Thu Mar 22 09:56:01 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 22 Mar 2018 11:56:01 +0200 Subject: How are you configuring BFD timers? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: Why does DWDM imply need of BFD? DWDM has no problem propagating loss-of-signal and asserting remote failure. It is of course possible to configure DWDM so that this does not happen, particularly if you buy protected circuit you might not want it to happen. But as per usual, you should test that vendor delivers what you buy. I think the problem probability of not detecting failure on waves, dark fibres and copper connections are smaller than the probability of having issue caused by presence of BFD. I think you need very unreliably failing link to capitalise on BFD. Radio is good candidate, switch masked liveliness is good candidate. Of course you also need to be sure you don't kill your BGP's fast external failover, by using eBGP multihop on your point-to-point circuit. On 21 March 2018 at 18:37, Luke Guillory wrote: > He's asking because if it was dark the interface would go down when the link was lost and the router would pull routes. But PA to FL would lead me to believe it'll be a wave from some type of DWDM gear which brings us to BFD. > > > > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.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. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Lembesis > Sent: Wednesday, March 21, 2018 11:31 AM > To: Job Snijders (External); Youssef Bengelloun-Zahr > Cc: NANOG > Subject: RE: How are you configuring BFD timers? > > To speed up BGP routing convergence. The (2x) dark fiber links from PA to FL are being used as Layer3 datacenter interconnects, where each datacenter has its own AS. The DF is also carrying FCIP traffic, so we need failover to be as fast as possible. > > Best regards, > > > > Alex > > > > -----Original Message----- > From: Job Snijders (External) [mailto:job at instituut.net] > Sent: Wednesday, March 21, 2018 12:25 PM > To: Youssef Bengelloun-Zahr > Cc: Alex Lembesis; NANOG > Subject: Re: How are you configuring BFD timers? > > Silly question perhaps, but why would you do BFD on dark fiber? > > Kind regards, > > Job > > This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. -- ++ytti From saku at ytti.fi Thu Mar 22 09:59:32 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 22 Mar 2018 11:59:32 +0200 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: On 22 March 2018 at 10:47, James Bensley wrote: > On 21 March 2018 at 16:37, Luke Guillory wrote: >> He's asking because if it was dark the interface would go down when the link was lost and the router would pull routes. But PA to FL would lead me to believe it'll be a wave from some type of DWDM gear which brings us to BFD. > > Could it not also help with a unidirectional failure of the fibre? > E.g. Loss of signal in only one direction might not bring the link > down, but if one BFD peer stops receiving BFD packets it'll bring the > link down. Ethernet handles unidirectional failure natively through autonego asserting RFI. A======B B sees loss-of signal A does not B asserts RFI A receives RFI and goes down Some devices, such as JunOS can also assert RFI for external factors, like you can ask JunOS to assert RFI to client port, when pseudowire goes down, so client experiences link down when you experience pseudowire down. -- ++ytti From jwbensley at gmail.com Thu Mar 22 09:59:53 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 22 Mar 2018 09:59:53 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> Message-ID: On 21 March 2018 at 13:10, Jason Lixfeld wrote: > Hey, > > For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. > > On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial: Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable. But? > > From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? > > From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear? We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments. > > I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? > > Thanks! Going back to the original question; > From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? Personally I don't care if it's a wavelength, dark fibre or L2 VPN service. I don't treat them differently based on the underlying connectivity type. The SLAs are probably more important. But if we are paying for say 10G of capacity on a link which is say a 10G pseudowire from another carrier, I treat it the same as a dark fibre connected to 10G transceivers at each end. Wave lengths are generally more stable in my opinion, we did have a 10G L2 Ethernet circuit from a carrier that was a pseudowire from them essentially, and their PE was under a DDoS attack so our L2 VPN service was affected (because the pseudowire was flapping up and down). But once the circuit is up and running for a while, if you're regularly pushing somewhere near the max circuit bandwidth and monitoring circuit latency, you'll get a feel for "how good" the carrier is and then adjust from there. Generally speaking though, if the carrier is "good" I treat DF/lamda/L2 circuits the same with regards the BFD/IGP tuning. > I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? Elsewhere in the thread you have mentioned that you are using Cisco ME3600 devices. If you disable BFD echo mode you will be able to get low timers on these devices. Echo mode is enabled by default on IOS when you enable BFD under an interface, which these devices don't support, so you need to explicitly disable it. See the min/max/avg BFD timers below between two ME devices when the interfaces are configured with "bfd interval 50 min_rx 50 multiplier 3": ME3600#show bfd neighbors interface te0/2 details ... Session state is UP and using echo function with 50 ms interval. Session Host: Software ... Rx Count: 72, Rx Interval (ms) min/max/avg: 1/4976/4323 last: 2348 ms ago Tx Count: 74, Tx Interval (ms) min/max/avg: 1/4968/4217 last: 1436 ms ago If you add the command "no bfd echo" to the interface you should see the following min/max/avg BFD timers: ME3600#show bfd neighbors interface te0/2 details ... Session state is UP and not using echo function. Session Host: Software ... Rx Count: 3314443, Rx Interval (ms) min/max/avg: 1/72/47 last: 36 ms ago Tx Count: 3310865, Tx Interval (ms) min/max/avg: 1/72/47 last: 40 ms ago We have a mixture of devices and they don't all support BFD echo mode. We have for example Cisco ASR9000s that support both echo / no echo mode, so it may have one interface towards a Juniper MX running BFD echo mode and one interface towards a Cisco ME which runs no echo mode. It's working fine for us. Cheers, James. From jwbensley at gmail.com Thu Mar 22 10:10:37 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 22 Mar 2018 10:10:37 +0000 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: On 22 March 2018 at 09:59, Saku Ytti wrote: > Ethernet handles unidirectional failure natively through autonego asserting RFI. I was thinking about this as I wrote that post. I've not had a chance to test this across our various devices types, I will have to try and find the time to test which devices support this and how effectively it works. For now we just use BFD because it's tested as working on all our device types. We've seen issues where LOS isn't working properly across third party DWDM platforms so for now, we have no BFD bugs and it catches these issues for us. I think it might also be worth testing Ethernet RFI to check the delays that Jason was talking about; which is quicker to signal link down and begin the re-convergence process, RFI / LOS / BFD? Cheers, James. From saku at ytti.fi Thu Mar 22 10:22:39 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 22 Mar 2018 12:22:39 +0200 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: RFI is corollary to LOS. Both are essentially speed of light limited, there in no uncertainty or detection margin. After one side sees LOS other side will see RFI, if it's not seeing LOS as well. I personally would consider BFD for: radio, pseudowire, L2 switch and equivalent poorly failing links. But I wouldn't run it on dark, copper or wave. Purely an anecdote, but I have far more BFD caused problems than BFD solved problems, spanning multiple vendors. (CAT7600, ASR9k, MX). Regarding BFD echo and control mode, neither is guaranteed to be HW or SW implementation, both can be both. Standard intends echo mode to be HW, but does not guarantee. On 22 March 2018 at 12:10, James Bensley wrote: > On 22 March 2018 at 09:59, Saku Ytti wrote: >> Ethernet handles unidirectional failure natively through autonego asserting RFI. > > I was thinking about this as I wrote that post. I've not had a chance > to test this across our various devices types, I will have to try and > find the time to test which devices support this and how effectively > it works. For now we just use BFD because it's tested as working on > all our device types. We've seen issues where LOS isn't working > properly across third party DWDM platforms so for now, we have no BFD > bugs and it catches these issues for us. > > I think it might also be worth testing Ethernet RFI to check the > delays that Jason was talking about; which is quicker to signal link > down and begin the re-convergence process, RFI / LOS / BFD? > > Cheers, > James. -- ++ytti From jason+nanog at lixfeld.ca Thu Mar 22 12:17:33 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 22 Mar 2018 08:17:33 -0400 Subject: How are you configuring BFD timers? In-Reply-To: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> Message-ID: Thanks to everyone who has responded so far. Enlightening! My understanding around the origins of BFD is that it was developed in part to try and bring SONET like switchover times to an Ethernet world. What I’m reading is for those who do run BFD, no one seems to be dialing it down to try and achieve those times. Some folks explained why they chose the values they did, but others didn’t. So my follow up question is “Why don’t you dial them down?”. Are achieving those switchover times not important for your use case? Do you not trust that it won’t be reliable based on the gear you’re using, or the quality/reliability of the underlying circuit you’re trying to protect? Something else? Also, interesting to read about why some folks don’t care much about BFD at all. > On Mar 21, 2018, at 9:10 AM, Jason Lixfeld wrote: > > Hey, > > For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier. > > On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial: Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable. But? > > From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link. How do you set your timers, and what do you base that on? > > From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear? We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments. > > I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff? How do you factor your configuration decisions? > > Thanks! From anthony at fms.io Wed Mar 21 16:54:28 2018 From: anthony at fms.io (Anthony Leto) Date: Wed, 21 Mar 2018 16:54:28 +0000 Subject: Looking for someone from Intuit to contact me. Message-ID: <60B394BA-B9CA-45FC-A450-FBEC4F427BAA@fms.io> I have a few users on my cloud that are not able to reach intuit.com or quickbooks.intuit.com. In addition my users are not able to eFile taxes from their terminal server with Quickbooks on it. We have checked and our firewalls are not blocking. From the trace route and other testing it looks like my IP ranges are being blocked. Thanks, Anthony Leto Founder Flying Man Studio, LLC. From deepak at ai.net Wed Mar 21 19:33:58 2018 From: deepak at ai.net (Deepak Jain) Date: Wed, 21 Mar 2018 19:33:58 +0000 Subject: COX BGP contact Message-ID: <9909abd426394614869d18d2b13c11ba@AiNET-EX13-S01.ainet.local> I know there should be a more reasonable way to do this. If someone has responsibility for COX BGP (AS 22773) would love to hear from you. Multiple days of getting the run around in various NOCs has lead to nowhere. Thanks in advance, Deepak From uwcableguy at gmail.com Thu Mar 22 15:00:00 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 22 Mar 2018 10:00:00 -0500 Subject: Juniper MX - Routed pseudowire using LDP - VPWS or VPLS In-Reply-To: References: <20180319202536.GF1336@angus.ind.wpi.edu> Message-ID: I do see one benefit to using the stitched LT VPWS solution - MAC learning. On the VPWS solution, your PE devices are not learning the MAC addresses. I also noticed that Juniper is a bit strange with VPLS attached to the IRB in that you never see the IRB MAC in the VPLS instance. But I think this has more to do with the behavior of IRB in general on Juniper as I don't see any of the IRB MAC addresses present in the table, even for IRBs not used on the VPLS circuit. It's entirely possible I'm using the wrong commands. :) -ben On Mon, Mar 19, 2018 at 4:27 PM, Ben Bartsch wrote: > The other solution is a stitched LT configuration. One LT is the L3 > endpoint, the other is the PW endpoint. You use VPWS with this one. I > suppose you might be able to do VPLS instead if you wanted to. I am > running eBGP on this circuit too. It's a bit more complicated for > troubleshooting. I'm not sure what benefit this has over the IRB method. > > Again, Junos 15.1R6.7: > > show configuration interfaces lt-0/0/10 | display set > set interfaces lt-0/0/10 mtu 9192 > set interfaces lt-0/0/10 unit 998 description LT-0/0/0.998->VLAN_998->PW > set interfaces lt-0/0/10 unit 998 encapsulation vlan-ccc > set interfaces lt-0/0/10 unit 998 vlan-id 998 > set interfaces lt-0/0/10 unit 998 peer-unit 10998 > set interfaces lt-0/0/10 unit 998 family ccc > set interfaces lt-0/0/10 unit 10998 description > LT-0/0/0.10998->VLAN_998->L3 > set interfaces lt-0/0/10 unit 10998 encapsulation vlan > set interfaces lt-0/0/10 unit 10998 vlan-id 998 > set interfaces lt-0/0/10 unit 10998 peer-unit 998 > set interfaces lt-0/0/10 unit 10998 family inet address 10.240.16.97/30 > > show configuration protocols l2circuit | display set > set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 > virtual-circuit-id 998 > set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 mtu > 9100 > > show l2circuit connections > Layer-2 Circuit Connections: > > Legend for connection status (St) > EI -- encapsulation invalid NP -- interface h/w not present > MM -- mtu mismatch Dn -- down > EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down > CM -- control-word mismatch Up -- operational > VM -- vlan id mismatch CF -- Call admission control failure > OL -- no outgoing label IB -- TDM incompatible bitrate > NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration > BK -- Backup Connection ST -- Standby Connection > CB -- rcvd cell-bundle size bad SP -- Static Pseudowire > LD -- local site signaled down RS -- remote site standby > RD -- remote site signaled down HS -- Hot-standby Connection > XX -- unknown > > Legend for interface status > Up -- operational > Dn -- down > Neighbor: 10.240.0.73 > Interface Type St Time last up # Up trans > lt-0/0/10.998(vc 998) rmt Up Mar 18 19:14:28 2018 1 > Remote PE: 10.240.0.73, Negotiated control-word: No > Incoming label: 347440, Outgoing label: 52785 > Negotiated PW status TLV: No > Local interface: lt-0/0/10.998, Status: Up, Encapsulation: VLAN > Flow Label Transmit: No, Flow Label Receive: No > > > > > The PE is again a Dell S4048-ON running IPI OcNOS v1.3.3 > > sh run mpls > ! > mpls l2-circuit VLAN_BASED_PW_0998 998 10.240.0.11 > ! > router ldp > router-id 10.240.0.73 > targeted-peer ipv4 10.240.0.11 > exit-targeted-peer-mode > transport-address ipv4 10.240.0.73 > > sh run int xe4 > ! > interface xe4 > description XE4->POD1-3550-S1_GI0/2 > speed 1g > switchport > load-interval 30 > mtu 9100 > mpls-l2-circuit VLAN_BASED_PW_0998 vlan 998 tpid 8100 > > sh ldp mpls-l2-circuit detail > vcid: 998 type: vlan, local groupid: 0, remote groupid: 0 (vc is up) > destination: 10.240.0.11, Peer LDP Ident: 10.240.0.11 > Local label: 52785, remote label: 347440 > Access IF: xe4, Network IF: xe2 > Local MTU: 9100, Remote MTU: 9100 <--THIS IS SUPER HANDY - IT WILL > SHOW YOUR REMOTE MTU EVEN IF THE CIRCUIT IS DOWN > Local Control Word: disabled, Remote Control Word: disabled, Current use: > disabled > Local PW Status Capability : disabled > Remote PW Status Capability : disabled > Current PW Status TLV : disabled > Local VCCV Capability: > CC-Types: None > CV-Types: None > Remote VCCV Capability: > CC-Types: Type 1 Type 2 Type 3 > CV-Types: > LSP ping > BFD IP/UDP-encapsulated, for PW Fault Detection only BFD > PW-ACH-encapsulated, for PW Fault Detection only > > sh ldp mpls-l2-circuit > Transport Client VC VC Local Remote > Destination > VC ID Binding State Type VC Label VC Label > Address > 998 xe4 UP Ethernet VLAN 52785 347440 > 10.240.0.11 > > > > > > Finally the CE is the same old Cisco 3550 with a VLAN: > > POD1-FREY113-3550-S1#sh run int vlan 998 > Building configuration... > > Current configuration : 114 bytes > ! > interface Vlan998 > description VLAN_998_VLAN-BASED-VPWS-ROUTED-PW > ip address 10.240.16.98 255.255.255.252 > end > > POD1-FREY113-3550-S1#sh run int gi0/2 > Building configuration... > > Current configuration : 219 bytes > ! > interface GigabitEthernet0/2 > description GI0/2->POD3-4048-S1_XE4 > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 998 > switchport mode trunk > load-interval 30 > speed nonegotiate > end > > > > > > I also forgot to show y'all what the VPLS circuit show commands look like > on the OcNOS node for the VPLS solution: > > sh mpls vpls detail > Virtual Private LAN Service Instance: VPLS-LAB-0997, ID: 997 > SIG-Protocol: LDP > Attachment-Circuit :UP > Learning: Enabled > Group ID: 0, VPLS Type: Ethernet VLAN, Configured MTU: 9100 > Description: none > service-tpid: dot1.q > Operating mode: Tagged > Svlan Id: 0 > Svlan Tpid: 8100 > Redundancy admin role: Primary > Redundancy oper role: Primary > Configured interfaces: > Interface: xe4 > Vlan Id: 997 > oper-state UP > Mesh Peers: > 10.240.0.11 (Up), PW Status Local:0 Remote:0 > > sh mpls vpls mesh > VPLS-ID Peer Addr Tunnel-Label In-Label Network-Intf > Out-Label Lkps/St PW-INDEX SIG-Protocol Status > 997 10.240.0.11 52496 52786 xe2 > 262148 2/Up 7 LDP Active > > > On Mon, Mar 19, 2018 at 4:15 PM, Ben Bartsch wrote: > >> Absolutely! I'm running a eBGP session over this ATM. We are going to >> try to backhaul our customers through a Dell whitebox running IPI OcNOS >> configured with an 'LDP fabric' to a core MX. >> >> >> To use an IRB as a L3 endpoint you have to use VPLS on the MX (Junos >> version 15.1R6.7). I was missing a couple of key commands highlighted in >> red: >> >> show configuration interfaces irb.997 | display set >> set interfaces irb unit 997 description VLAN-997->PWHE->POD1-3550-S1_V >> LAN_997 >> set interfaces irb unit 997 bandwidth 10g >> set interfaces irb unit 997 family inet mtu 9178 >> set interfaces irb unit 997 family inet address 10.240.16.101/30 >> >> show configuration routing-instances VPLS-LAB-0997 | display set >> set routing-instances VPLS-LAB-0997 instance-type vpls >> set routing-instances VPLS-LAB-0997 vlan-id 997 >> set routing-instances VPLS-LAB-0997 routing-interface irb.997 >> set routing-instances VPLS-LAB-0997 protocols vpls encapsulation-type >> ethernet-vlan >> set routing-instances VPLS-LAB-0997 protocols vpls no-tunnel-services >> set routing-instances VPLS-LAB-0997 protocols vpls vpls-id 997 >> set routing-instances VPLS-LAB-0997 protocols vpls mtu 9100 >> set routing-instances VPLS-LAB-0997 protocols vpls neighbor 10.240.0.73 >> set routing-instances VPLS-LAB-0997 protocols vpls connectivity-type irb >> >> show vpls connections extensive >> Layer-2 VPN connections: >> >> Legend for connection status (St) >> EI -- encapsulation invalid NC -- interface encapsulation not >> CCC/TCC/VPLS >> EM -- encapsulation mismatch WE -- interface and instance encaps not >> same >> VC-Dn -- Virtual circuit down NP -- interface hardware not present >> CM -- control-word mismatch -> -- only outbound connection is up >> CN -- circuit not provisioned <- -- only inbound connection is up >> OR -- out of range Up -- operational >> OL -- no outgoing label Dn -- down >> LD -- local site signaled down CF -- call admission control failure >> RD -- remote site signaled down SC -- local and remote site ID collision >> LN -- local site not designated LM -- local site ID not minimum >> designated >> RN -- remote site not designated RM -- remote site ID not minimum >> designated >> XX -- unknown connection status IL -- no incoming label >> MM -- MTU mismatch MI -- Mesh-Group ID not available >> BK -- Backup connection ST -- Standby connection >> PF -- Profile parse failure PB -- Profile busy >> RS -- remote site standby SN -- Static Neighbor >> LB -- Local site not best-site RB -- Remote site not best-site >> VM -- VLAN ID mismatch HS -- Hot-standby Connection >> >> Legend for interface status >> Up -- operational >> Dn -- down >> >> Instance: VPLS-LAB-0997 >> VPLS-id: 997 >> Number of local interfaces: 0 >> Number of local interfaces up: 0 >> lsi.1048592 Intf - vpls VPLS-LAB-0997 neighbor >> 10.240.0.73 vpls-id 997 >> Neighbor Type St Time last up # Up >> trans >> 10.240.0.73(vpls-id 997) rmt Up Mar 19 10:25:38 2018 >> 1 >> Remote PE: 10.240.0.73, Negotiated control-word: No >> Incoming label: 262148, Outgoing label: 52786 >> Negotiated PW status TLV: No >> Local interface: lsi.1048592, Status: Up, Encapsulation: VLAN >> Description: Intf - vpls VPLS-LAB-0997 neighbor 10.240.0.73 >> vpls-id 997 >> Flow Label Transmit: No, Flow Label Receive: No >> Connection History: >> Mar 19 10:25:38 2018 status update timer >> Mar 19 10:25:38 2018 PE route changed >> Mar 19 10:25:38 2018 Out lbl Update 52786 >> Mar 19 10:25:38 2018 In lbl Update 262148 >> Mar 19 10:25:38 2018 loc intf up lsi.1048592 >> >> >> >> >> The other end of my VPLS circuit is a Dell S4048-ON running IP Infusion >> OcNOS (it is very Cisco IOS-ish) v1.3.3: >> >> sh run mpls >> mpls vpls VPLS-LAB-0997 997 >> redundancy-role primary >> signaling ldp >> vpls-type vlan >> vpls-peer 10.240.0.11 >> exit-signaling >> ! >> router ldp >> router-id 10.240.0.73 >> targeted-peer ipv4 10.240.0.11 >> exit-targeted-peer-mode >> transport-address ipv4 10.240.0.73 >> >> sh run int xe4 >> ! >> interface xe4 >> description XE4->POD1-3550-S1_GI0/2 >> speed 1g >> switchport >> load-interval 30 >> mtu 9100 >> mpls-vpls VPLS-LAB-0997 vlan 997 >> ac-admin-status up >> exit-if-vpls >> >> >> >> >> And the CE is just a simple L3 VLAN. We are using an old Cisco 3550 >> running 12.2(46)SE IPSERVICESK9 that we found laying around: >> >> POD1-3550-S1#sh run int gi0/2 >> Building configuration... >> >> Current configuration : 219 bytes >> ! >> interface GigabitEthernet0/2 >> description GI0/2->POD3-4048-S1_XE4 >> switchport trunk encapsulation dot1q >> switchport trunk allowed vlan 997 >> switchport mode trunk >> load-interval 30 >> speed nonegotiate >> end >> >> POD1-3550-S1#sh run int vlan 997 >> Building configuration... >> >> Current configuration : 115 bytes >> ! >> interface Vlan997 >> description VLAN_997_VLAN-BASED-VPWS-ROUTED-PW >> ip address 10.240.16.102 255.255.255.252 >> end >> >> >> >> Hope this helps. My head hurts from banging it my desk for the last >> couple of weeks. :) >> >> -ben >> >> On Mon, Mar 19, 2018 at 3:25 PM, Chuck Anderson wrote: >> >>> Would you mind sharing the solution(s)? I've stiched a L2 PW using >>> lt-interfaces. >>> >>> Thanks. >>> >>> On Mon, Mar 19, 2018 at 11:51:36AM -0500, Ben Bartsch wrote: >>> > I want to thank everyone who contacted me on and off list on this >>> request. >>> > I now have two methods to land a layer 3 endpoint on a layer 2 circuit >>> to a >>> > remote PE. I very much appreciate the input, feedback, and >>> assistance. I >>> > hope I personally get to meet all of you that reached out to me at a >>> future >>> > NANOG meeting. Thanks again! >>> > >>> > -ben >>> > >>> > On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch >>> wrote: >>> > >>> > > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 >>> > > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying >>> to do >>> > > the same thing on a Juniper MX 480/960 and it does not appear to be >>> > > supported (for LDP at least - MP-BGP might be supported). We could >>> do >>> > > either VPWS or VPLS on the PE device handoff to the CE (layer 2 >>> only). >>> > > JTAC has somewhat confirmed this is not supported for LDP, but they >>> only do >>> > > break/fix, not new config. We do not have professional services (we >>> are >>> > > broke). >>> > > >>> > > Any Juniper routerheads out there that have seen this done using LDP >>> > > without having to hairpin on the MX? >>> > > >>> > > Thanks, y'all. >>> > > >>> > > -ben >>> >> >> > From surfer at mauigateway.com Thu Mar 22 20:16:43 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 22 Mar 2018 13:16:43 -0700 Subject: How are you configuring BFD timers? Message-ID: <20180322131643.49AEC60B@m0117459.ppops.net> --- saku at ytti.fi wrote: From: Saku Ytti ...but I have far more BFD caused problems than BFD solved problems, spanning multiple vendors. (CAT7600, ASR9k, MX). ---------------------------------------- Yes, that's for sure. Also, it's hard to scale when you're tweaking knobs on each session trying to get the time down w/o causing failure unnecessarily. scott From mansaxel at besserwisser.org Thu Mar 22 20:41:22 2018 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 22 Mar 2018 21:41:22 +0100 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> Message-ID: <20180322204121.GA26806@besserwisser.org> Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, 2018 at 04:24:47PM +0000 Quoting Job Snijders (job at instituut.net): > Silly question perhaps, but why would you do BFD on dark fiber? Because Ethernet lacks the PRDI that real WAN protocols have. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 If I am elected no one will ever have to do their laundry again! PS: Don't get me wrong. I'm all for Ethernet, it is cheap (or perhaps, SDH/SONET line cards were artificially expensive) and it makes networks faster more often, by virtue of interface cheapness. But one really needs to tack about half the signalling from SDH onto Ethernet (here, BFD) to get some predictability from it. Which is OK, it was made for NFS and Telnet on a LAN. It does really well considering that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From uwcableguy at gmail.com Thu Mar 22 20:44:16 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 22 Mar 2018 15:44:16 -0500 Subject: How are you configuring BFD timers? In-Reply-To: <20180322131643.49AEC60B@m0117459.ppops.net> References: <20180322131643.49AEC60B@m0117459.ppops.net> Message-ID: No sure if this link has been provided yet, but this is how I learned BFD - https://supportforums.cisco.com/t5/service-providers-documents/bfd-support-on-cisco-asr9000/ta-p/3153191 My only experience with BFD has been with short paths using grey optics and interstate DWDM spans. I found 3x50ms echo mode worked well, but you need to watch out for QoS on the remote side as the packet that hairpins back to the sender is subject to queuing. As the link becomes saturated, the BFD packet goes in the queue with everyone else as the far end router hairpins it and can cause a false link down condition if it goes in the bit bucket. I saw timers as low as 3x10ms echo mode with QoS work really well on a strictly ASR9k network. I never tried to run it on bundle links or over layer 2. I did try to run it on some Dell Z9100 and S4048 boxes running FTOS 9 and it failed miserably even with very conservative timers. I haven't had a chance to test it with IPI OcNOS 1.3.3 on the same boxes, or with JunOS. On Thu, Mar 22, 2018 at 3:16 PM, Scott Weeks wrote: > > > --- saku at ytti.fi wrote: > From: Saku Ytti > > ...but I have far more BFD caused problems than BFD solved > problems, spanning multiple vendors. (CAT7600, ASR9k, MX). > ---------------------------------------- > > > Yes, that's for sure. Also, it's hard to scale when you're > tweaking knobs on each session trying to get the time down > w/o causing failure unnecessarily. > > scott > From saku at ytti.fi Thu Mar 22 21:45:16 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 22 Mar 2018 23:45:16 +0200 Subject: How are you configuring BFD timers? In-Reply-To: <20180322204121.GA26806@besserwisser.org> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <20180322204121.GA26806@besserwisser.org> Message-ID: On 22 March 2018 at 22:41, Måns Nilsson wrote: > Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, 2018 at 04:24:47PM +0000 Quoting Job Snijders (job at instituut.net): >> Silly question perhaps, but why would you do BFD on dark fiber? > > Because Ethernet lacks the PRDI that real WAN protocols have. Indeed, RFI on ethernet is rather modern addition, turning 20 this year. -- ++ytti From mansaxel at besserwisser.org Fri Mar 23 05:10:22 2018 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Fri, 23 Mar 2018 06:10:22 +0100 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <20180322204121.GA26806@besserwisser.org> Message-ID: <4BEBF65216E3C15374380D61@treize.besserwisser.org> --On 22 mars 2018 23:45:16 +0200 Saku Ytti wrote: > On 22 March 2018 at 22:41, Måns Nilsson > wrote: > >> Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, 2018 >> at 04:24:47PM +0000 Quoting Job Snijders (job at instituut.net): >>> Silly question perhaps, but why would you do BFD on dark fiber? >> >> Because Ethernet lacks the PRDI that real WAN protocols have. > > Indeed, RFI on ethernet is rather modern addition, turning 20 this year. (You just reminded me I've been doing some sort of WAN network ops for about 20 years.) That does indeed solve the problem for dark fibre, and those lucky WDM systems that actually reflect input status to output. Not always true, I'm afraid (just look at the Ethernet switch mid-span that Thomas Bellman wrote about; a fitting metaphor for all "ethernet-over-other.." models..). Ethernet still regards "no frames seen on the yellow coax" as an opportunity to send traffic rather than an error, if we're talking old things ;-). BFD solves that, and it is worthwhile to have one setup regardless of technology, if possible. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 CHUBBY CHECKER just had a CHICKEN SANDWICH in downtown DULUTH! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jfmezei_nanog at vaxination.ca Fri Mar 23 07:28:59 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 23 Mar 2018 03:28:59 -0400 Subject: Question about great firewall of China Message-ID: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> Asking in a sanity check context. As you may have heard, Bell Canada has gathered a group called Fairplay Canada to force all ISPs in Canada to block web sites Fairplay has decided infringe on copyright. (ironically, Fairplay is copyright by Apple, and used without permission :-) Canada has hundreds of separate ISPs, each using a combination of one or more transit providers (and there are many that have POPs in Canada). (so the following question makes it relevant to the NA in NAnog). 1- Does anyone have "big picture" details on how China implements its website blocks? Is this implemented in major trunks that enter China from the outside world? Is there a governmenmt onwed transit provider to whom any/all ISPs must connect (and thus that provider can implemnent the blocks), or are the blocks performed closer to the edges with ISPs in charge of implementing them ? I assume they are some blocked ports, and fake authoritative DNS zone files to redirect sites like bbc.co.uk to something else? Would DPI, on a national scale work to look at HTTP and HTTPS transactions to kill TCP sessione to IPs where the HTTP transaction has a banned work (such as "Host: www.bbc.co.uk" 2- Bell Canada used to use DPI on 1gbps Ellacoya on its wireline Internet to detect and slow bittorrent flows down to dialup speeds. When it started to upgrade its core network to support FTTH in 2010, the upgrade of the BRAS routers to 10GBPS ports would have required Bell buy a totally new fleet of DPI boxes and keep buying whenever there were capacity upgrades. The math favoured increasing capacity instead of limiting use via DPI throttling, especially since traffic growth was with youtube and netflix , not bittorrent. fast forward 7-8 years to today: Is the deployment of dedicated DPI, capable of wire speed control of individual flows be economically feasable for wireline internet services? (DOCSIS and FTTH speeds). When Rogers and Comcast wanted to slow Netflix, underprovisioning links from the Netflix appliances/CDN is much cheaper than deploying DPI. Just curious if there is still an apetite for DPI for wireline ISPs that deploy at modern DOCSIS/FTTH speeds. Does the rapid move from HTTP to HTTPS render DPI for wire speed live control useless? ( I realise that blind collection of netflow data to be batch processed into billing systems to implement zero rating schemes is possible with normal routers and may not require dedicated DPI. 3- In the case of the USA with ISPs slated to become AOL-like information providers, is there an expectation of widespread deployment of DPI equipment to "manage" the provision of information, or is the expectation that the ISPs will focus more on using netflow to impact the billing system and usage limits? 4- Or is DPI being deployed anyways to protect the networks from DDOS attacks, so adding website blocking would be possible? From ryan at rkhtech.org Fri Mar 23 08:15:42 2018 From: ryan at rkhtech.org (Ryan Hamel) Date: Fri, 23 Mar 2018 01:15:42 -0700 Subject: Question about great firewall of China In-Reply-To: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> References: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> Message-ID: On Mar 23 2018, at 12:28 am, Jean-Francois Mezei wrote: > > Asking in a sanity check context. > > As you may have heard, Bell Canada has gathered a group called Fairplay > Canada to force all ISPs in Canada to block web sites Fairplay has > decided infringe on copyright. (ironically, Fairplay is copyright by > Apple, and used without permission :-) > > Canada has hundreds of separate ISPs, each using a combination of one or > more transit providers (and there are many that have POPs in Canada). > > (so the following question makes it relevant to the NA in NAnog). > 1- > Does anyone have "big picture" details on how China implements its > website blocks? > > Is this implemented in major trunks that enter China from the outside > world? Is there a governmenmt onwed transit provider to whom any/all > ISPs must connect (and thus that provider can implemnent the blocks), or > are the blocks performed closer to the edges with ISPs in charge of > implementing them ? > > I assume they are some blocked ports, and fake authoritative DNS zone > files to redirect sites like bbc.co.uk to something else? Would DPI, on > a national scale work to look at HTTP and HTTPS transactions to kill TCP > sessione to IPs where the HTTP transaction has a banned work (such as > "Host: www.bbc.co.uk" > The state owns China Unicom, China Telecom, and China Mobile, which is what everyone eventually connects into. PCCW is in Hong Kong and is not under the same scruitiny. A lot of your questions about the great firewall of China can be answered by reading: https://en.wikipedia.org/wiki/Great_Firewall (https://link.getmailspring.com/link/local-56496eae-d14e-v1.1.4-22d9f20d at RKHTech-Laptop/0?redirect=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGreat_Firewall&recipient=Nanog%40nanog.org) > > 2- > Bell Canada used to use DPI on 1gbps Ellacoya on its wireline Internet > to detect and slow bittorrent flows down to dialup speeds. When it > started to upgrade its core network to support FTTH in 2010, the upgrade > of the BRAS routers to 10GBPS ports would have required Bell buy a > totally new fleet of DPI boxes and keep buying whenever there were > capacity upgrades. The math favoured increasing capacity instead of > limiting use via DPI throttling, especially since traffic growth was > with youtube and netflix , not bittorrent. > > > fast forward 7-8 years to today: Is the deployment of dedicated DPI, > capable of wire speed control of individual flows be economically > feasable for wireline internet services? (DOCSIS and FTTH speeds). > > When Rogers and Comcast wanted to slow Netflix, underprovisioning links > from the Netflix appliances/CDN is much cheaper than deploying DPI. Just > curious if there is still an apetite for DPI for wireline ISPs that > deploy at modern DOCSIS/FTTH speeds. > > > Does the rapid move from HTTP to HTTPS render DPI for wire speed live > control useless? ( I realise that blind collection of netflow data to > be batch processed into billing systems to implement zero rating schemes > is possible with normal routers and may not require dedicated DPI. > > DPI will be useless, but that doesn't mean traffic patterns can be observed in other ways, resulting in QoS policies being applied at border routers. > 3- > In the case of the USA with ISPs slated to become AOL-like information > providers, is there an expectation of widespread deployment of DPI > equipment to "manage" the provision of information, or is the > expectation that the ISPs will focus more on using netflow to impact the > billing system and usage limits? > Netflow is not the only way to get usage stats, one can also measure the tx/rx bit differentiation at client facing interface with set intervals. > 4- > Or is DPI being deployed anyways to protect the networks from DDOS > attacks, so adding website blocking would be possible? > I am not sure of any ISP using DPI on inbound to block traffic outbound. From ddeutsch at tsicorp.net Thu Mar 22 21:48:14 2018 From: ddeutsch at tsicorp.net (David Deutsch) Date: Thu, 22 Mar 2018 17:48:14 -0400 Subject: Comcast / Level3 Peering Issues? Message-ID: Hey guys, VoIP provider here with primary connectivity through Level3 in LAX. For the past week+ we have seen dropped RTP packets between our Level3 connection and Comcast fiber customers located in Denver and Detroit Initially we worked under the assumption that something was occuring at the customer locations (such as localized packet loss), however we now suspect dropped packets between L3 and Comcast. Forcing traffic over to other carriers through community strings resulted in no packet loss. The issue appears to be in the evening and I was hoping either someone from L3 network ops or a list member in the know might have some useful information. Thanks, David From cb.list6 at gmail.com Fri Mar 23 12:46:56 2018 From: cb.list6 at gmail.com (Ca By) Date: Fri, 23 Mar 2018 12:46:56 +0000 Subject: Question about great firewall of China In-Reply-To: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> References: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> Message-ID: > 3- > > In the case of the USA with ISPs slated to become AOL-like information > providers, is there an expectation of widespread deployment of DPI > equipment to "manage" the provision of information, or is the > expectation that the ISPs will focus more on using netflow to impact the > billing system and usage limits? > No > 4- > > Or is DPI being deployed anyways to protect the networks from DDOS > attacks, so adding website blocking would be possible? > Also, no. > > > From hugo at slabnet.com Fri Mar 23 17:06:39 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 23 Mar 2018 10:06:39 -0700 Subject: Question about great firewall of China In-Reply-To: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> References: <809d2a9d-242f-5208-76ec-07585b40b1a0@vaxination.ca> Message-ID: <20180323170639.GM25899@bamboo.slabnet.com> re: Nation-level controls, the Sandvine report from Citizen Labs can add some context and real world examples: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ Also discusses http vs. https things. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Fri 2018-Mar-23 03:28:59 -0400, Jean-Francois Mezei wrote: >Asking in a sanity check context. > > >As you may have heard, Bell Canada has gathered a group called Fairplay >Canada to force all ISPs in Canada to block web sites Fairplay has >decided infringe on copyright. (ironically, Fairplay is copyright by >Apple, and used without permission :-) > >Canada has hundreds of separate ISPs, each using a combination of one or >more transit providers (and there are many that have POPs in Canada). > >(so the following question makes it relevant to the NA in NAnog). > >1- > >Does anyone have "big picture" details on how China implements its >website blocks? > >Is this implemented in major trunks that enter China from the outside >world? Is there a governmenmt onwed transit provider to whom any/all >ISPs must connect (and thus that provider can implemnent the blocks), or >are the blocks performed closer to the edges with ISPs in charge of >implementing them ? > >I assume they are some blocked ports, and fake authoritative DNS zone >files to redirect sites like bbc.co.uk to something else? Would DPI, on >a national scale work to look at HTTP and HTTPS transactions to kill TCP >sessione to IPs where the HTTP transaction has a banned work (such as >"Host: www.bbc.co.uk" > > > >2- > >Bell Canada used to use DPI on 1gbps Ellacoya on its wireline Internet >to detect and slow bittorrent flows down to dialup speeds. When it >started to upgrade its core network to support FTTH in 2010, the upgrade >of the BRAS routers to 10GBPS ports would have required Bell buy a >totally new fleet of DPI boxes and keep buying whenever there were >capacity upgrades. The math favoured increasing capacity instead of >limiting use via DPI throttling, especially since traffic growth was >with youtube and netflix , not bittorrent. > > >fast forward 7-8 years to today: Is the deployment of dedicated DPI, >capable of wire speed control of individual flows be economically >feasable for wireline internet services? (DOCSIS and FTTH speeds). > >When Rogers and Comcast wanted to slow Netflix, underprovisioning links >from the Netflix appliances/CDN is much cheaper than deploying DPI. Just >curious if there is still an apetite for DPI for wireline ISPs that >deploy at modern DOCSIS/FTTH speeds. > > >Does the rapid move from HTTP to HTTPS render DPI for wire speed live >control useless? ( I realise that blind collection of netflow data to >be batch processed into billing systems to implement zero rating schemes >is possible with normal routers and may not require dedicated DPI. > > >3- > >In the case of the USA with ISPs slated to become AOL-like information >providers, is there an expectation of widespread deployment of DPI >equipment to "manage" the provision of information, or is the >expectation that the ISPs will focus more on using netflow to impact the >billing system and usage limits? > >4- > >Or is DPI being deployed anyways to protect the networks from DDOS >attacks, so adding website blocking would be possible? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cscora at apnic.net Fri Mar 23 18:03:15 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Mar 2018 04:03:15 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180323180315.AA1BB102FD@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, IRNOG 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 24 Mar, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 691365 Prefixes after maximum aggregation (per Origin AS): 268010 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 333413 Total ASes present in the Internet Routing Table: 60242 Prefixes per ASN: 11.48 Origin-only ASes present in the Internet Routing Table: 52045 Origin ASes announcing only one prefix: 22825 Transit ASes present in the Internet Routing Table: 8197 Transit-only ASes present in the Internet Routing Table: 259 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 43 Number of instances of unregistered ASNs: 43 Number of 32-bit ASNs allocated by the RIRs: 21920 Number of 32-bit ASNs visible in the Routing Table: 17665 Prefixes from 32-bit ASNs in the Routing Table: 73424 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 327 Number of addresses announced to Internet: 2856515618 Equivalent to 170 /8s, 66 /16s and 248 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 229823 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 190139 Total APNIC prefixes after maximum aggregation: 54379 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 189044 Unique aggregates announced from the APNIC address blocks: 77220 APNIC Region origin ASes present in the Internet Routing Table: 8733 APNIC Prefixes per ASN: 21.65 APNIC Region origin ASes announcing only one prefix: 2463 APNIC Region transit ASes present in the Internet Routing Table: 1291 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3650 Number of APNIC addresses announced to Internet: 767306082 Equivalent to 45 /8s, 188 /16s and 41 /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-137529 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: 206125 Total ARIN prefixes after maximum aggregation: 98692 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206867 Unique aggregates announced from the ARIN address blocks: 97789 ARIN Region origin ASes present in the Internet Routing Table: 18121 ARIN Prefixes per ASN: 11.42 ARIN Region origin ASes announcing only one prefix: 6715 ARIN Region transit ASes present in the Internet Routing Table: 1807 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2326 Number of ARIN addresses announced to Internet: 1104262496 Equivalent to 65 /8s, 209 /16s and 181 /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-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 187594 Total RIPE prefixes after maximum aggregation: 91205 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 183855 Unique aggregates announced from the RIPE address blocks: 110088 RIPE Region origin ASes present in the Internet Routing Table: 25036 RIPE Prefixes per ASN: 7.34 RIPE Region origin ASes announcing only one prefix: 11374 RIPE Region transit ASes present in the Internet Routing Table: 3492 Average RIPE Region AS path length visible: 4.2 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6811 Number of RIPE addresses announced to Internet: 715655552 Equivalent to 42 /8s, 168 /16s and 9 /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-207259 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: 88947 Total LACNIC prefixes after maximum aggregation: 19690 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 90332 Unique aggregates announced from the LACNIC address blocks: 40521 LACNIC Region origin ASes present in the Internet Routing Table: 6946 LACNIC Prefixes per ASN: 13.00 LACNIC Region origin ASes announcing only one prefix: 1905 LACNIC Region transit ASes present in the Internet Routing Table: 1288 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4478 Number of LACNIC addresses announced to Internet: 172439008 Equivalent to 10 /8s, 71 /16s and 53 /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: 18515 Total AfriNIC prefixes after maximum aggregation: 4004 AfriNIC Deaggregation factor: 4.62 Prefixes being announced from the AfriNIC address blocks: 20940 Unique aggregates announced from the AfriNIC address blocks: 7532 AfriNIC Region origin ASes present in the Internet Routing Table: 1122 AfriNIC Prefixes per ASN: 18.66 AfriNIC Region origin ASes announcing only one prefix: 367 AfriNIC Region transit ASes present in the Internet Routing Table: 226 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 400 Number of AfriNIC addresses announced to Internet: 96439296 Equivalent to 5 /8s, 191 /16s and 140 /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 5417 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3928 407 407 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2877 11133 782 KIXS-AS-KR Korea Telecom, KR 9829 2804 1499 541 BSNL-NIB National Internet Backbone, IN 7552 2702 1161 58 VIETEL-AS-AP Viettel Group, VN 9394 2630 4923 29 CTTNET China TieTong Telecommunications 45899 2557 1561 165 VNPT-AS-VN VNPT Corp, VN 17974 2308 930 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2172 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2085 417 215 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 3375 1323 86 SHAW - Shaw Communications Inc., CA 22773 3285 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2098 2488 433 CHARTER-NET-HKY-NC - Charter Communicat 16509 2031 4372 651 AMAZON-02 - Amazon.com, Inc., US 30036 1947 341 176 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1919 5070 609 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 11492 1765 227 564 CABLEONE - CABLE ONE, INC., US 6389 1743 3671 36 BELLSOUTH-NET-BLK - BellSouth.net Inc., 16625 1698 827 1214 AKAMAI-AS - Akamai Technologies, Inc., Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 3885 1484 617 UNI2-AS, ES 39891 3327 179 20 ALJAWWALSTC-AS, SA 20940 2749 776 2010 AKAMAI-ASN1, US 12389 2035 1864 704 ROSTELECOM-AS, RU 34984 2024 334 482 TELLCOM-AS, TR 8551 2021 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 9121 1944 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 8402 1235 544 14 CORBINA-AS OJSC "Vimpelcom", RU 9198 1071 363 28 KAZTELECOM-AS, KZ 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 4324 3385 579 Uninet S.A. de C.V., MX 10620 3597 540 259 Telmex Colombia S.A., CO 11830 2641 369 86 Instituto Costarricense de Electricidad 6503 1634 437 53 Axtel, S.A.B. de C.V., MX 7303 1506 1022 191 Telecom Argentina S.A., AR 28573 1027 2251 181 CLARO S.A., BR 6147 1013 377 27 Telefonica del Peru S.A.A., PE 3816 1006 506 120 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 927 126 83 Alestra, S. de R.L. de C.V., MX 18881 907 1072 29 TELEF�NICA BRASIL S.A, BR 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 1161 398 50 LINKdotNET-AS, EG 37611 820 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 677 1396 39 ETISALAT-MISR, EG 8452 633 1730 18 TE-AS TE-AS, EG 24835 602 850 15 RAYA-AS, EG 29571 467 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 376 81 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5417 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4324 3385 579 Uninet S.A. de C.V., MX 7545 3928 407 407 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 3885 1484 617 UNI2-AS, ES 10620 3597 540 259 Telmex Colombia S.A., CO 6327 3375 1323 86 SHAW - Shaw Communications Inc., CA 39891 3327 179 20 ALJAWWALSTC-AS, SA 22773 3285 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2877 11133 782 KIXS-AS-KR Korea Telecom, KR 9829 2804 1499 541 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4324 3745 Uninet S.A. de C.V., MX 7545 3928 3521 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3597 3338 Telmex Colombia S.A., CO 39891 3327 3307 ALJAWWALSTC-AS, SA 6327 3375 3289 SHAW - Shaw Communications Inc., CA 12479 3885 3268 UNI2-AS, ES 22773 3285 3135 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2702 2644 VIETEL-AS-AP Viettel Group, VN 9394 2630 2601 CTTNET China TieTong Telecommunications Corpora 11830 2641 2555 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 37.44.224.0/20 48666 AS-MAROSNET Moscow, Russia, RU 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:288 /13:563 /14:1095 /15:1902 /16:13337 /17:7847 /18:13660 /19:25204 /20:39209 /21:45188 /22:85658 /23:69222 /24:385799 /25:839 /26:603 /27:659 /28:33 /29:20 /30:16 /31:4 /32:57 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3166 3375 SHAW - Shaw Communications Inc., CA 39891 2754 3327 ALJAWWALSTC-AS, SA 12479 2645 3885 UNI2-AS, ES 22773 2539 3285 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1988 2641 Instituto Costarricense de Electricidad y Telec 30036 1697 1947 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1601 3597 Telmex Colombia S.A., CO 11492 1536 1765 CABLEONE - CABLE ONE, INC., US 8551 1484 2021 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1577 2:821 4:19 5:2799 6:48 7:1 8:1118 9:1 12:1881 13:192 14:1740 15:27 16:3 17:194 18:68 20:47 21:3 23:2560 24:2148 25:2 27:2264 31:1950 32:89 35:27 36:509 37:2779 38:1459 39:249 40:107 41:3024 42:595 43:1956 44:103 45:3988 46:3040 47:199 49:1349 50:1051 51:48 52:996 54:363 55:5 56:12 57:42 58:1550 59:1017 60:429 61:2135 62:1813 63:1799 64:4729 65:2221 66:4614 67:2367 68:1170 69:3210 70:1141 71:559 72:2111 74:2721 75:412 76:427 77:1547 78:1726 79:1783 80:1482 81:1436 82:1074 83:775 84:1020 85:2078 86:580 87:1301 88:928 89:2323 90:199 91:6310 92:1171 93:2377 94:2398 95:2738 96:659 97:356 98:929 99:129 100:79 101:1427 102:31 103:17422 104:3308 105:224 106:602 107:1793 108:708 109:2724 110:1580 111:1770 112:1325 113:1351 114:1116 115:1649 116:1643 117:1715 118:2161 119:1675 120:969 121:1059 122:2459 123:1821 124:1460 125:1892 128:997 129:629 130:447 131:1556 132:683 133:195 134:995 135:228 136:449 137:499 138:1913 139:575 140:417 141:685 142:793 143:958 144:806 145:456 146:1170 147:750 148:1549 149:709 150:743 151:981 152:758 153:311 154:1013 155:765 156:848 157:784 158:624 159:1649 160:915 161:723 162:2575 163:524 164:1036 165:1412 166:414 167:1396 168:3060 169:814 170:3708 171:426 172:1071 173:1956 174:872 175:765 176:1745 177:3995 178:2416 179:1193 180:2242 181:2155 182:2462 183:1135 184:918 185:12989 186:3565 187:2339 188:2756 189:2004 190:8097 191:1384 192:9794 193:5890 194:4792 195:3960 196:2474 197:1444 198:5519 199:5875 200:7394 201:4990 202:10434 203:10152 204:4530 205:2849 206:3077 207:3204 208:3992 209:3925 210:4035 211:2112 212:2981 213:2722 214:911 215:61 216:5857 217:2151 218:899 219:621 220:1724 221:997 222:1040 223:1236 End of report From sean at donelan.com Fri Mar 23 20:39:08 2018 From: sean at donelan.com (Sean Donelan) Date: Fri, 23 Mar 2018 16:39:08 -0400 (EDT) Subject: FCC to Hold Workshop on April 13 on Critical Info During Disasters Message-ID: On Friday, April 13th, 2018, the Federal Communications Commission’s (FCC or Commission) Public Safety and Homeland Security Bureau (Bureau) will host a public workshop to identify communications information needs of government and consumers to improve preparation and response efforts during crises. Informed by input to a Bureau Public Notice seeking comment on the response to the 2017 Hurricane Season, this workshop is intended to ensure the Commission is collecting the critical information necessary to best support the preparedness and response activities of stakeholders to facilitate the availability and reliability of communications during emergencies, disasters, and significant events. https://www.fcc.gov/document/fcc-hold-workshop-april-13-critical-info-during-disasters From surfer at mauigateway.com Fri Mar 23 23:34:40 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 23 Mar 2018 16:34:40 -0700 Subject: Question about great firewall of China Message-ID: <20180323163440.49B0BB60@m0117567.ppops.net> > As you may have heard, Bell Canada has gathered a > group called Fairplay Canada to force all ISPs in > Canada to block web sites --- hugo at slabnet.com wrote: From: Hugo Slabbert re: Nation-level controls, the Sandvine report from Citizen Labs can add some context and real world examples: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/ Also discusses http vs. https things. ----------------------------------- Wow, that's a really interesting write up. It's long, though... It looks like a "Great Firewall of Canada" is going up. They should look at the dismal record of how Australia implemented theirs (all the while knowing how easy it is for the "criminals and terrorists" to bypass their blocks). https://en.wikipedia.org/wiki/Internet_censorship_in_Australia But,it really isn't about the "criminals and terrorists" is it? The people in positions of power worldwide are feverishly drooling over the ability to control what others can know, while not blocking the information from themselves. What a sad, sad life those people live! Sounds like the Dark Ages. scott From maxtul at netassist.ua Mon Mar 26 03:41:32 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 26 Mar 2018 06:41:32 +0300 Subject: Question about great firewall of China In-Reply-To: <20180323163440.49B0BB60@m0117567.ppops.net> References: <20180323163440.49B0BB60@m0117567.ppops.net> Message-ID: Hi, even in China it is not possible to block content from people proactively want to reach it (VPN, TOR, etc). So terrorists, child pornographers, drug dealer, copyright violators and other s*it are in safe. Only can really do the Internel Censorship is to decrease of circle of spreading information. It will not reach 100%, but reach say 5% of initial expected auditory. This system can ONLY be used to change MASS MIND of people, i.e. POLITICAL CENSORSHIP. Don't believe bastards say they protect you by censorship. ONLY can they really do with this system (not now of course, a bit later - look for history of raising Russian censorship system for example) - is to influence of the mass mind, i.e. results of elections. NOTHING ELSE. 24.03.18 01:34, Scott Weeks пише: > > > It looks like a "Great Firewall of Canada" is going up. > They should look at the dismal record of how Australia > implemented theirs (all the while knowing how easy it > is for the "criminals and terrorists" to bypass their > blocks). > > https://en.wikipedia.org/wiki/Internet_censorship_in_Australia > > But,it really isn't about the "criminals and terrorists" > is it? > > The people in positions of power worldwide are feverishly > drooling over the ability to control what others can know, > while not blocking the information from themselves. What > a sad, sad life those people live! Sounds like the Dark > Ages. > > scott > From dcorbe at hammerfiber.com Sat Mar 24 07:01:38 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sat, 24 Mar 2018 03:01:38 -0400 Subject: Comcast / Level3 Peering Issues? In-Reply-To: References: Message-ID: <1B971823-134F-4109-AB49-AD1457E2CF29@hammerfiber.com> > On Mar 22, 2018, at 5:48 PM, David Deutsch wrote: > > Hey guys, > > VoIP provider here with primary connectivity through Level3 in LAX. > > For the past week+ we have seen dropped RTP packets between our Level3 > connection and Comcast fiber customers located in Denver and Detroit > > Initially we worked under the assumption that something was occuring at the > customer locations (such as localized packet loss), however we now suspect > dropped packets between L3 and Comcast. Forcing traffic over to other > carriers through community strings resulted in no packet loss. > > The issue appears to be in the evening and I was hoping either someone from > L3 network ops or a list member in the know might have some useful > information. > > Thanks, > David > I’m no expert in the way Comcast run their network, so the following advice needs to be taken with a giant grain of salt. Historically, Comcast have a tendency to run their peering hot. It sounds like you’re trying to reach a Comcast wholesale customer. In which case, steering your traffic around the Level3<->Comcast Interconnect by filtering Comcast’s prefixes from your Level3 connection and manipulating your community strings is the right move. If you’re trying to reach Comcast broadband customers, steering the traffic away from their Level3 interconnect is still probably the correct thing to do but with the caveat that broadband cable access is and always has been a best-effort service. -Daniel From nick at foobar.org Tue Mar 27 11:22:28 2018 From: nick at foobar.org (Nick Hilliard) Date: Tue, 27 Mar 2018 12:22:28 +0100 Subject: Spiffy Netflow tools? In-Reply-To: References: <46031589-DDE7-4ED0-A65A-A4D1D563C42D@gmail.com> <20180314095730.f2jhcxbsi4rqog3r@corley.shackle.nl> Message-ID: <5ABA2974.90507@foobar.org> Stipo wrote: > +1 ElastiFlow, the templates are great, a great quickstart to using > netflow on elk stack. out of curiosity, I set up a test ElastiFlow installation on a small site recently. It's completely gorgeous from an eye candy point of view and it's pretty easy to see how you could tap into the ELK APIs to do interesting data mangling. On the down-side, it used ~40x the amount of disk space that nfsen used for the same accounting period, and even though it was only handling less than 1G traffic at a NF sample rate of 1:10, logstash and elastisearch managed to peg between 4-6 cores on the server which was handling it. Granted, these were only E5606 (2011-era Westmere Xeon) cpus, but even still there was an alarming mismatch between the amount of compute power required compared to the amount of netflow traffic being handled. It would be interesting to hear the sort of cpu requirements needed for larger installations. Obviously you can scale elkstack sideways, so it wouldn't be difficult to build out something which performed well. The issue is that burning cpu time can become an expensive proposition. Nick From igor.krneta at elta-kabel.com Tue Mar 27 11:46:29 2018 From: igor.krneta at elta-kabel.com (Igor Krneta) Date: Tue, 27 Mar 2018 13:46:29 +0200 Subject: Problems with Skype video - outgoing calls only Message-ID: Hi guys, last few days we have a several of our customers complaining about weird problem with skype video chat. When they try to initiate video call from their computer, call fails and receiving side gets notification that they were called. But when receiving side tries to call them, call gets through immediately, no problems. This affects only video calls. Audio calls, chat, file transfer, group conference all work without any problems during the same session. And we have sent our tech's to customer premises with our own equipment. They too have the same problem while on location while using our laptops/phones/tablets. After customers started complaining, we switched their IP address to some of our other IP ranges and problem was gone for some time. Now, we have started getting reports of skype video not working from our other IP ranges. What's most frustrating about this problem is that it's not a problem for all users in particular subnet, only a few of them at time. For others, everything works as usual. We have checked and double checked everything about our network, and all is well and in normal parameters. No new firewalls/rules/equipment change/updates.... Anyone having same issues maybe ? Sincerely, Igor Krneta Elta Kabel d.o.o. From werzacabak at gmail.com Tue Mar 27 07:16:31 2018 From: werzacabak at gmail.com (howard stearn) Date: Tue, 27 Mar 2018 01:16:31 -0600 Subject: How does ER Infinity Hold up? Message-ID: I've seen this list looking for inexpensive routers before, so i'm wondering. . . Since this was released rather recently, Is anyone using ER-8-XG to receive a full bgp table yet? (Yes BGP and are you neighbored with 1, 2, 10, 40 peers?) https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_ER-8-XG_DS.pdf How does it stack up against Cisco, or your other previous router? What's the lookup time on a new unknown destination? From berg at wins.net Tue Mar 27 02:26:24 2018 From: berg at wins.net (Russell Berg) Date: Tue, 27 Mar 2018 02:26:24 +0000 Subject: CDN-provided caching platforms? Message-ID: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> I work for a regional Midwestern US "Tier 2" ISP that provides both wholesale and enterprise Internet connectivity. We have caching platforms in place from the likes of Akamai, Google, Netflix, and Facebook; I was wondering if there are other CDN caching platforms out there we should be researching/deploying? PM me if more appropriate... TIA Russ Russell Berg Chief Technology Officer WIN / Airstream Communications (AS 11796) P: 715-832-3726 | C: 715-579-8227 www.wins.net From nanog at ics-il.net Tue Mar 27 13:40:59 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 27 Mar 2018 08:40:59 -0500 (CDT) Subject: CDN-provided caching platforms? In-Reply-To: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> Message-ID: <508597950.2181.1522158056822.JavaMail.mhammett@ThunderFuck> Wondering the same, but for IXes. There's an open caching server effort, but open seems to be relative. They still want you to spend a boatload of money for a box from one of their vendors. I forget its name at the moment. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Russell Berg" To: nanog at nanog.org Sent: Monday, March 26, 2018 9:26:24 PM Subject: CDN-provided caching platforms? I work for a regional Midwestern US "Tier 2" ISP that provides both wholesale and enterprise Internet connectivity. We have caching platforms in place from the likes of Akamai, Google, Netflix, and Facebook; I was wondering if there are other CDN caching platforms out there we should be researching/deploying? PM me if more appropriate... TIA Russ Russell Berg Chief Technology Officer WIN / Airstream Communications (AS 11796) P: 715-832-3726 | C: 715-579-8227 www.wins.net From dwhite at olp.net Tue Mar 27 13:49:31 2018 From: dwhite at olp.net (Dan White) Date: Tue, 27 Mar 2018 08:49:31 -0500 Subject: CDN-provided caching platforms? In-Reply-To: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> Message-ID: <20180327134931.GA25473@dan.olp.net> Valve/Steam. On 03/27/18 02:26 +0000, Russell Berg wrote: > I work for a regional Midwestern US "Tier 2" ISP that provides both > wholesale and enterprise Internet connectivity. We have caching platforms > in place from the likes of Akamai, Google, Netflix, and Facebook; I was > wondering if there are other CDN caching platforms out there we should be > researching/deploying? PM me if more appropriate... -- 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 From lguillory at reservetele.com Tue Mar 27 13:58:28 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 27 Mar 2018 13:58:28 +0000 Subject: CDN-provided caching platforms? In-Reply-To: <508597950.2181.1522158056822.JavaMail.mhammett@ThunderFuck> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <508597950.2181.1522158056822.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB510C66@RTC-EXCH01.RESERVE.LDS> Concurrent is one of them, we use Qwilt but that will get expensive really quick with their licensing. https://www.concurrent.com/laguna-cache/ Luke ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, March 27, 2018 8:41 AM Cc: nanog at nanog.org Subject: Re: CDN-provided caching platforms? Wondering the same, but for IXes. There's an open caching server effort, but open seems to be relative. They still want you to spend a boatload of money for a box from one of their vendors. I forget its name at the moment. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Russell Berg" To: nanog at nanog.org Sent: Monday, March 26, 2018 9:26:24 PM Subject: CDN-provided caching platforms? I work for a regional Midwestern US "Tier 2" ISP that provides both wholesale and enterprise Internet connectivity. We have caching platforms in place from the likes of Akamai, Google, Netflix, and Facebook; I was wondering if there are other CDN caching platforms out there we should be researching/deploying? PM me if more appropriate... TIA Russ Russell Berg Chief Technology Officer WIN / Airstream Communications (AS 11796) P: 715-832-3726 | C: 715-579-8227 www.wins.net From valdis.kletnieks at vt.edu Tue Mar 27 15:22:52 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 27 Mar 2018 11:22:52 -0400 Subject: CDN-provided caching platforms? In-Reply-To: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> Message-ID: <7149.1522164172@turing-police.cc.vt.edu> On Tue, 27 Mar 2018 02:26:24 -0000, Russell Berg said: > I was wondering if there are other CDN caching platforms out there we should > be researching/deploying? Does traffic analysis show any other destinations that have enough traffic that caching might help? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From owen at delong.com Tue Mar 27 15:59:45 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Mar 2018 08:59:45 -0700 Subject: How does ER Infinity Hold up? In-Reply-To: References: Message-ID: I don’t know about the device itself, but given UBNT’s recent hostility to the open source community, I won’t be buying their products anyway. Owen > On Mar 27, 2018, at 00:16 , howard stearn wrote: > > I've seen this list looking for inexpensive routers before, so i'm > wondering. . . Since this was released rather recently, Is anyone using > ER-8-XG to receive a full bgp table yet? (Yes BGP and are you neighbored > with 1, 2, 10, 40 peers?) > https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_ER-8-XG_DS.pdf > > How does it stack up against Cisco, or your other previous router? > > What's the lookup time on a new unknown destination? From lists at mtin.net Tue Mar 27 21:40:58 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 27 Mar 2018 17:40:58 -0400 Subject: How does ER Infinity Hold up? In-Reply-To: References: Message-ID: <1467A042-387C-4764-ADA4-530E9EA1EE29@mtin.net> My biggest issue with the ER Infinity is you can’t individually set the speed on ports. You have to set them in groups of 4, which is a major bummer. We are getting ready to put one into production as soon as I figure out some more details on communities. I am intrigued by Owen’s comments on their Open Source hostility. I need to look into this. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Mar 27, 2018, at 11:59 AM, Owen DeLong wrote: > > I don’t know about the device itself, but given UBNT’s recent hostility to the > open source community, I won’t be buying their products anyway. > > Owen > >> On Mar 27, 2018, at 00:16 , howard stearn wrote: >> >> I've seen this list looking for inexpensive routers before, so i'm >> wondering. . . Since this was released rather recently, Is anyone using >> ER-8-XG to receive a full bgp table yet? (Yes BGP and are you neighbored >> with 1, 2, 10, 40 peers?) >> https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_ER-8-XG_DS.pdf >> >> How does it stack up against Cisco, or your other previous router? >> >> What's the lookup time on a new unknown destination? > From jason.w.kuehl at gmail.com Tue Mar 27 21:59:26 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Tue, 27 Mar 2018 21:59:26 +0000 Subject: How does ER Infinity Hold up? In-Reply-To: References: Message-ID: UBNT’s recent hostility to the open source community What do you mean by that? On Tue, Mar 27, 2018, 12:02 PM Owen DeLong wrote: > I don’t know about the device itself, but given UBNT’s recent hostility to > the > open source community, I won’t be buying their products anyway. > > Owen > > > On Mar 27, 2018, at 00:16 , howard stearn wrote: > > > > I've seen this list looking for inexpensive routers before, so i'm > > wondering. . . Since this was released rather recently, Is anyone using > > ER-8-XG to receive a full bgp table yet? (Yes BGP and are you neighbored > > with 1, 2, 10, 40 peers?) > > https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_ER-8-XG_DS.pdf > > > > How does it stack up against Cisco, or your other previous router? > > > > What's the lookup time on a new unknown destination? > > From jfmezei_nanog at vaxination.ca Tue Mar 27 22:10:51 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 27 Mar 2018 18:10:51 -0400 Subject: =?UTF-8?Q?Qu=c3=a9bec_Sales_tax?= Message-ID: Not quite networking but probably relevant. The Canadian province of Québec just introduced a new budget with basically the intent to force foreign digital companies who sell services to Québekers to collect the local value added sales tax and remit those to the QC government. The goal is to capture tax from Netflix who has so far escaped taxation in Canada by having no legal/physical presence in Canada, no cache servers of its own etc. Netflix does not currently collect province information from customers (or any address info for that matter). They based many of their arguments on an OECD study (which ironically the Canadian federal government says is not completed yet (as excuse for not proceeding with similar tax). So foreign digital services will be required to require subscibers enter AND VALIDATE their address so that they have an accurate province field (validation remains to be finalized), and IF they sell more than $30,000 to Québec residents, will be required to self register with QC government to collect local sales tax (and remit to QC government). The Québec budget expects that validation of address will be based on IP address geolocation or custoemrs send paper bills to prove place of residence. (Although requiring full address/phone number and sendint this to credit card network for authorization might constitute a better means to validate address). I suspect the big winners will be VPN services in the USA :-) Because many ISPs span multiple provinces, IP geolocation generally points to their HQ address, not necessarily the province of the subscriber. (This is especially true for DSL in bell Canada wholesale where currently a single point of connection between Bell and ISP allows full reach of all of its DSL territory in QC/ON. For Cable, ISPs require different IP pools for Rogers in Ontario and Vidéotron in Ontario (with a couple of exceptions where Vidéotron has service in a couple fo Ontario towns). In Western Canada, things are harder as Shaw serves BC, AB, SASK and MB. From math at sizone.org Tue Mar 27 22:21:12 2018 From: math at sizone.org (Ken Chase) Date: Tue, 27 Mar 2018 18:21:12 -0400 Subject: Qu??bec Sales tax In-Reply-To: References: Message-ID: <20180327222112.GG9746@sizone.org> If Netflix has no physical presence in Quebec, what the lever are they going to use to force this? A lawsuit in in the US? What court is going to entertain a foreign jurisdiction's tax claim in their court? And how would that be then enforced? Canada has tried this before: https://www.ctvnews.ca/business/u-s-judge-puts-halt-to-canadian-court-order-for-google-to-delist-search-results-1.3663055 Court file: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/16701/index.do Im a big fan of Canada standing up for its sovereignty (I live here), but nice try. /kc On Tue, Mar 27, 2018 at 06:10:51PM -0400, Jean-Francois Mezei said: >Not quite networking but probably relevant. > >The Canadian province of Qu??bec just introduced a new budget with >basically the intent to force foreign digital companies who sell >services to Qu??bekers to collect the local value added sales tax and >remit those to the QC government. > >The goal is to capture tax from Netflix who has so far escaped taxation >in Canada by having no legal/physical presence in Canada, no cache >servers of its own etc. Netflix does not currently collect province >information from customers (or any address info for that matter). > >They based many of their arguments on an OECD study (which ironically >the Canadian federal government says is not completed yet (as excuse for >not proceeding with similar tax). > >So foreign digital services will be required to require subscibers enter >AND VALIDATE their address so that they have an accurate province field >(validation remains to be finalized), and IF they sell more than $30,000 >to Qu??bec residents, will be required to self register with QC >government to collect local sales tax (and remit to QC government). > >The Qu??bec budget expects that validation of address will be based on IP >address geolocation or custoemrs send paper bills to prove place of >residence. > >(Although requiring full address/phone number and sendint this to credit >card network for authorization might constitute a better means to >validate address). > >I suspect the big winners will be VPN services in the USA :-) > >Because many ISPs span multiple provinces, IP geolocation generally >points to their HQ address, not necessarily the province of the >subscriber. (This is especially true for DSL in bell Canada wholesale >where currently a single point of connection between Bell and ISP allows >full reach of all of its DSL territory in QC/ON. For Cable, ISPs require >different IP pools for Rogers in Ontario and Vid??otron in Ontario (with >a couple of exceptions where Vid??otron has service in a couple fo >Ontario towns). In Western Canada, things are harder as Shaw serves BC, >AB, SASK and MB. -- Ken Chase - math at sizone.org Guelph Canada From edugas at unknowndevice.ca Tue Mar 27 22:28:43 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 27 Mar 2018 18:28:43 -0400 Subject: =?utf-8?Q?Qu=C3=A9bec_?=Sales tax In-Reply-To: References: Message-ID: <1522188789.local-a12f1f76-de3d-v1.1.5-5834c99f@getmailspring.com> On the IP geoloc subject, we (EBOX) actually have multiple pools for QC-based and ON-based customers. When a customer is provisioned, his service address is validated in our system and it auto-populates the Radius profile with a different profile for each provinces e.g. fttn-on-50 or fttn-qc-50. I don't see why we couldn't do this on Telus in the west (we're currently only servicing QC and ON). On the TPIA side, it's a little bit less easy. I could automatically SWIP netblocks from reports we get from the operators to the POI they're configured in. I don't see this as a big issue. Eric On Mar 27 2018, at 6:10 pm, Jean-Francois Mezei wrote: > > Not quite networking but probably relevant. > The Canadian province of Québec just introduced a new budget with > basically the intent to force foreign digital companies who sell > services to Québekers to collect the local value added sales tax and > remit those to the QC government. > > The goal is to capture tax from Netflix who has so far escaped taxation > in Canada by having no legal/physical presence in Canada, no cache > servers of its own etc. Netflix does not currently collect province > information from customers (or any address info for that matter). > > They based many of their arguments on an OECD study (which ironically > the Canadian federal government says is not completed yet (as excuse for > not proceeding with similar tax). > > So foreign digital services will be required to require subscibers enter > AND VALIDATE their address so that they have an accurate province field > (validation remains to be finalized), and IF they sell more than $30,000 > to Québec residents, will be required to self register with QC > government to collect local sales tax (and remit to QC government). > > The Québec budget expects that validation of address will be based on IP > address geolocation or custoemrs send paper bills to prove place of > residence. > > (Although requiring full address/phone number and sendint this to credit > card network for authorization might constitute a better means to > validate address). > > I suspect the big winners will be VPN services in the USA :-) > Because many ISPs span multiple provinces, IP geolocation generally > points to their HQ address, not necessarily the province of the > subscriber. (This is especially true for DSL in bell Canada wholesale > where currently a single point of connection between Bell and ISP allows > full reach of all of its DSL territory in QC/ON. For Cable, ISPs require > different IP pools for Rogers in Ontario and Vidéotron in Ontario (with > a couple of exceptions where Vidéotron has service in a couple fo > Ontario towns). In Western Canada, things are harder as Shaw serves BC, > AB, SASK and MB. > From jfmezei_nanog at vaxination.ca Tue Mar 27 22:30:24 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 27 Mar 2018 18:30:24 -0400 Subject: Qu??bec Sales tax In-Reply-To: <20180327222112.GG9746@sizone.org> References: <20180327222112.GG9746@sizone.org> Message-ID: <91d787dc-c3f2-9cd1-88f6-f424902b4b4b@vaxination.ca> On 2018-03-27 18:21, Ken Chase wrote: > If Netflix has no physical presence in Quebec, what the lever are they going > to use to force this? A lawsuit in in the > US? What court is going to entertain a foreign jurisdiction's tax claim in > their court? And how would that be then enforced? Or Netflix could just call the QC govt's bluff and just stop serving QC customers and see QC voters rebel against the government if they lose Netflix. The "no presence in Canada" has had other impacts *Netflix refusing to comply to a CRTC request for infornation claiming CRTC doesn't regulate foreign companies with no presence in Canada). (Ironically, Netflix has hired lobysists who are quite active in Canada). The jurisdiction aspect is an important one. Basically, the current structure favour people buying services outside their own country to avoid tax. And it isn't just in Canada. (For instance, the small Canadian streaming services have to charge tax to their customers, but Netflix doesn't. (google/apple do because they have physical presence here). BTW, and this is a serious Orwelian thing, foreign providers who register will be required to give the QC government their customer lists so that the QC govt can find any tax cheaters who pretend to live in different province and charhe penalies of $100 or more to those individuals). So the QC govt will claim some fairly serious extra-territorial powers. From jfmezei_nanog at vaxination.ca Tue Mar 27 22:47:48 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 27 Mar 2018 18:47:48 -0400 Subject: =?UTF-8?Q?Re:_Qu=c3=a9bec_Sales_tax?= In-Reply-To: <1522188789.local-a12f1f76-de3d-v1.1.5-5834c99f@getmailspring.com> References: <1522188789.local-a12f1f76-de3d-v1.1.5-5834c99f@getmailspring.com> Message-ID: <1a2c15cb-2c09-342f-057a-cae440bc66be@vaxination.ca> On 2018-03-27 18:28, Eric Dugas wrote: > On the IP geoloc subject, we (EBOX) actually have multiple pools for QC-based and ON-based customers. You may all have different IP pools, but are they registered such that geolocation services show them with different provinces, or do they all point to your OrgName: EBOX OrgId: QUEBE-50 Address: 1225 St-Charles Ouest, Suite 1100 City: Longueuil StateProv: QC PostalCode: J4K 0B9 Country: CA address ? (there were complains in the past of some of your ON customers unable to access Sport Check and being directed to Sport Experts store web sites due to geolocation. From edugas at unknowndevice.ca Tue Mar 27 23:54:36 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 27 Mar 2018 19:54:36 -0400 Subject: =?utf-8?Q?Qu=C3=A9bec_?=Sales tax Message-ID: Replied off-list since it's a bit off-topic. On Tue, Mar 27, 2018, 18:47 Jean-Francois Mezei wrote: > On 2018-03-27 18:28, Eric Dugas wrote: > > On the IP geoloc subject, we (EBOX) actually have multiple pools for QC-based and ON-based customers. > > You may all have different IP pools, but are they registered such that > geolocation services show them with different provinces, or do they all > point to your > > OrgName: EBOX > OrgId: QUEBE-50 > Address: 1225 St-Charles Ouest, Suite 1100 > City: Longueuil > StateProv: QC > PostalCode: J4K 0B9 > Country: CA > > address ? > (there were complains in the past of some of your ON customers unable to > access Sport Check and being directed to Sport Experts store web sites > due to geolocation. From ariev at vayner.net Tue Mar 27 20:26:02 2018 From: ariev at vayner.net (Arie Vayner) Date: Tue, 27 Mar 2018 20:26:02 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <4BEBF65216E3C15374380D61@treize.besserwisser.org> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <20180322204121.GA26806@besserwisser.org> <4BEBF65216E3C15374380D61@treize.besserwisser.org> Message-ID: Not directly related, but I wonder: how common is micro-BFD for detecting bundle member failures? On Thu, Mar 22, 2018 at 10:12 PM Måns Nilsson wrote: > > > --On 22 mars 2018 23:45:16 +0200 Saku Ytti wrote: > > > On 22 March 2018 at 22:41, Måns Nilsson > > wrote: > > > >> Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, 2018 > >> at 04:24:47PM +0000 Quoting Job Snijders (job at instituut.net): > >>> Silly question perhaps, but why would you do BFD on dark fiber? > >> > >> Because Ethernet lacks the PRDI that real WAN protocols have. > > > > Indeed, RFI on ethernet is rather modern addition, turning 20 this year. > > (You just reminded me I've been doing some sort of WAN network ops for > about 20 years.) > > That does indeed solve the problem for dark fibre, and those lucky WDM > systems that actually reflect input status to output. Not always true, I'm > afraid (just look at the Ethernet switch mid-span that Thomas Bellman wrote > about; a fitting metaphor for all "ethernet-over-other.." models..). > Ethernet still regards "no frames seen on the yellow coax" as an > opportunity to send traffic rather than an error, if we're talking old > things ;-). BFD solves that, and it is worthwhile to have one setup > regardless of technology, if possible. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR +46 705 989668 > CHUBBY CHECKER just had a CHICKEN SANDWICH in downtown DULUTH! > From dcorbe at hammerfiber.com Tue Mar 27 23:57:53 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 27 Mar 2018 19:57:53 -0400 Subject: Firewall as a Service. Message-ID: Are there any vendors that have hardware firewalls and maintain their own Openstack nova/neutron driver set? I’m looking for something that I can offer to my VPS customers as a self-managed service. At the moment, I’m using the default firewall driver. Which is nothing but a wrapper for iptables; and while seamless, I can’t imagine it’s going to scale very well. I’m looking for something that has 10 gig client connectivity and either 100G or 40G uplinks. -Daniel From me at payam124.com Wed Mar 28 18:14:26 2018 From: me at payam124.com (Payam Poursaied) Date: Wed, 28 Mar 2018 11:14:26 -0700 Subject: Yet another Quadruple DNS? Message-ID: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> dig google.com @1.1.1.1 Cloudflare? Didn't find any news around it From woody at pch.net Wed Mar 28 20:06:27 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 28 Mar 2018 13:06:27 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> > On Mar 28, 2018, at 11:14 AM, Payam Poursaied wrote: > > dig google.com @1.1.1.1 > Cloudflare? Yeah, Cloudflare did a deal with Geoff Huston to use it. It’s reserved for “experimental use." -Bill -------------- 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 michael at wi-fiber.io Wed Mar 28 20:13:16 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Wed, 28 Mar 2018 14:13:16 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: Many providers filter out 1.1.1.1 because too many people use it in their examples/test code. I doubt that it's a usable IP/service. On 28 March 2018 at 12:14, Payam Poursaied wrote: > dig google.com @1.1.1.1 > > > > Cloudflare? > > Didn't find any news around it > > From daknob.mac at gmail.com Wed Mar 28 20:16:15 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Wed, 28 Mar 2018 23:16:15 +0300 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> Out of 1,000 RIPE Atlas Probes, only 34 report it as unreachable. Very good latency from those who can reach it.. https://atlas.ripe.net/measurements/11859210/#!general Antonis > On 28 Mar 2018, at 23:13, Michael Crapse wrote: > > Many providers filter out 1.1.1.1 because too many people use it in their > examples/test code. I doubt that it's a usable IP/service. > > On 28 March 2018 at 12:14, Payam Poursaied wrote: > >> dig google.com @1.1.1.1 >> >> >> >> Cloudflare? >> >> Didn't find any news around it >> >> From jared at puck.nether.net Wed Mar 28 20:17:15 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 28 Mar 2018 16:17:15 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: > On Mar 28, 2018, at 4:13 PM, Michael Crapse wrote: > > Many providers filter out 1.1.1.1 because too many people use it in their > examples/test code. I doubt that it's a usable IP/service. There’s at least one vendor *cough* cisco *cough* that has used it as captive portal IP. I’m not sure I would try to use it on a client machine because you don’t know if you’ll reach the internet. If you know you’re not on a closed network, you could use it instead of the list of usual suspects, like 8.8.8.8 4.2.2.1 9.9.9.9 etc. - Jared From morrowc.lists at gmail.com Wed Mar 28 20:21:19 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 28 Mar 2018 21:21:19 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: On Wed, Mar 28, 2018 at 9:13 PM, Michael Crapse wrote: > Many providers filter out 1.1.1.1 because too many people use it in their > examples/test code. I doubt that it's a usable IP/service. > > having previously globally announce 1.1.1.1 ... and some other of it's friends... not nearly enough people filter it. We regularly saw ~10gbps+ of traffic to those prefixes. > On 28 March 2018 at 12:14, Payam Poursaied wrote: > > > dig google.com @1.1.1.1 > > > > > > > > Cloudflare? > > > > Didn't find any news around it > > > > > From aftab.siddiqui at gmail.com Wed Mar 28 20:25:04 2018 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 28 Mar 2018 20:25:04 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: 1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, probably doing some more data gathering on 1.1.1.1 and doesn't want to be smashed with Gigs of traffic. Transit is still quite expensive in Aus :) https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt On Thu, 29 Mar 2018 at 07:08 Bill Woodcock wrote: > > > > On Mar 28, 2018, at 11:14 AM, Payam Poursaied wrote: > > > > dig google.com @1.1.1.1 > > Cloudflare? > > Yeah, Cloudflare did a deal with Geoff Huston to use it. It’s reserved > for “experimental use." > > -Bill > > -- Best Wishes, Aftab A. Siddiqui From jared at puck.nether.net Wed Mar 28 20:49:07 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 28 Mar 2018 16:49:07 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: <55B24E3A-829B-4BA5-A66F-D7C0B1A46F9B@puck.nether.net> A reminder to go back and watch the awesome talk from Nanog 49 about this: https://youtu.be/RBOPcLpQZ8w https://www.nanog.org/meetings/nanog49/presentations/Monday/karir-1slash8.pdf - Jared > On Mar 28, 2018, at 4:25 PM, Aftab Siddiqui wrote: > > 1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, > probably doing some more data gathering on 1.1.1.1 and doesn't want to be > smashed with Gigs of traffic. Transit is still quite expensive in Aus :) > > https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt > > > On Thu, 29 Mar 2018 at 07:08 Bill Woodcock wrote: > >> >> >>> On Mar 28, 2018, at 11:14 AM, Payam Poursaied wrote: >>> >>> dig google.com @1.1.1.1 >>> Cloudflare? >> >> Yeah, Cloudflare did a deal with Geoff Huston to use it. It’s reserved >> for “experimental use." >> >> -Bill >> >> -- > Best Wishes, > > Aftab A. Siddiqui From woody at pch.net Wed Mar 28 21:44:49 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 28 Mar 2018 14:44:49 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: <39776BE7-1A25-4AB3-97ED-FF3DD8DC6E3A@pch.net> > On Mar 28, 2018, at 2:39 PM, David Ulevitch wrote: > > On Wed, Mar 28, 2018 at 1:27 PM Aftab Siddiqui wrote: > 1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, > probably doing some more data gathering on 1.1.1.1 and doesn't want to be > smashed with Gigs of traffic. > > Doubtful. This is most assuredly going to be a commercial production recursive DNS service. Matthew (CEO) has said as much on Twitter. Yep, they’ve been trying to put something together in this space for several years. Sounds like it may be close now. I can’t say I envy them their task, as it will be very difficult for them to differentiate in that space, since they don’t have OpenDNS’s many years of experience and fine-tuning and security services, nor Google’s brand-recognition. Verisign have had a reasonably good commercial offering in this space for years, and hardly anyone’s heard of it, for instance. I believe even Neustar does. And they’re all DNS specialists, rather than web-content specialists. -Bill -------------- 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 ahebert at pubnix.net Wed Mar 28 21:45:26 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 28 Mar 2018 17:45:26 -0400 Subject: Qu??bec Sales tax In-Reply-To: <20180327222112.GG9746@sizone.org> References: <20180327222112.GG9746@sizone.org> Message-ID:     Same deal as Paypal and EBay.     Netflix dropping their services in CDN/QC only serve attempt at making yet another market grab.     At the end Netflix may just charge the Tax and funnel it to the govt.  They'll still be making a bundle.         ( And with all the hardware already deployed locally at the many exchanges ... )     Now if we can only break that damn 1930's licensing scheme so that we can gain access to more content...  Kinda annoyed that is hogging all the content with their vertical licensing agreements. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/27/18 18:21, Ken Chase wrote: > If Netflix has no physical presence in Quebec, what the lever are they going > to use to force this? A lawsuit in in the > US? What court is going to entertain a foreign jurisdiction's tax claim in > their court? And how would that be then enforced? > > Canada has tried this before: > > https://www.ctvnews.ca/business/u-s-judge-puts-halt-to-canadian-court-order-for-google-to-delist-search-results-1.3663055 > > Court file: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/16701/index.do > > Im a big fan of Canada standing up for its sovereignty (I live here), but nice > try. > > /kc > > > On Tue, Mar 27, 2018 at 06:10:51PM -0400, Jean-Francois Mezei said: > >Not quite networking but probably relevant. > > > >The Canadian province of Qu??bec just introduced a new budget with > >basically the intent to force foreign digital companies who sell > >services to Qu??bekers to collect the local value added sales tax and > >remit those to the QC government. > > > >The goal is to capture tax from Netflix who has so far escaped taxation > >in Canada by having no legal/physical presence in Canada, no cache > >servers of its own etc. Netflix does not currently collect province > >information from customers (or any address info for that matter). > > > >They based many of their arguments on an OECD study (which ironically > >the Canadian federal government says is not completed yet (as excuse for > >not proceeding with similar tax). > > > >So foreign digital services will be required to require subscibers enter > >AND VALIDATE their address so that they have an accurate province field > >(validation remains to be finalized), and IF they sell more than $30,000 > >to Qu??bec residents, will be required to self register with QC > >government to collect local sales tax (and remit to QC government). > > > >The Qu??bec budget expects that validation of address will be based on IP > >address geolocation or custoemrs send paper bills to prove place of > >residence. > > > >(Although requiring full address/phone number and sendint this to credit > >card network for authorization might constitute a better means to > >validate address). > > > >I suspect the big winners will be VPN services in the USA :-) > > > >Because many ISPs span multiple provinces, IP geolocation generally > >points to their HQ address, not necessarily the province of the > >subscriber. (This is especially true for DSL in bell Canada wholesale > >where currently a single point of connection between Bell and ISP allows > >full reach of all of its DSL territory in QC/ON. For Cable, ISPs require > >different IP pools for Rogers in Ontario and Vid??otron in Ontario (with > >a couple of exceptions where Vid??otron has service in a couple fo > >Ontario towns). In Western Canada, things are harder as Shaw serves BC, > >AB, SASK and MB. > > -- > Ken Chase - math at sizone.org Guelph Canada > From math at sizone.org Wed Mar 28 21:57:45 2018 From: math at sizone.org (Ken Chase) Date: Wed, 28 Mar 2018 17:57:45 -0400 Subject: Qu??bec Sales tax In-Reply-To: References: <20180327222112.GG9746@sizone.org> Message-ID: <20180328215745.GB11391@sizone.org> bell canada? /kc On Wed, Mar 28, 2018 at 05:45:26PM -0400, Alain Hebert said: >?????? Same deal as Paypal and EBay. > >?????? Netflix dropping their services in CDN/QC only serve >attempt at making yet another market grab. > > >?????? At the end Netflix may just charge the Tax and funnel it to the >govt.?? They'll still be making a bundle. > >?????? ?????? ( And with all the hardware already deployed locally at the >many exchanges ... ) > > >?????? Now if we can only break that damn 1930's licensing scheme so that >we can gain access to more content...?? Kinda annoyed that >is hogging all the content with their vertical licensing agreements. > >----- >Alain Hebert ahebert at pubnix.net >PubNIX Inc. >50 boul. St-Charles >P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > >On 03/27/18 18:21, Ken Chase wrote: >>If Netflix has no physical presence in Quebec, what the lever are they going >>to use to force this? A lawsuit in in the >>US? What court is going to entertain a foreign jurisdiction's tax claim in >>their court? And how would that be then enforced? >> >>Canada has tried this before: >> >>https://www.ctvnews.ca/business/u-s-judge-puts-halt-to-canadian-court-order-for-google-to-delist-search-results-1.3663055 >> >>Court file: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/16701/index.do >> >>Im a big fan of Canada standing up for its sovereignty (I live here), but nice >>try. >> >>/kc >> >> >>On Tue, Mar 27, 2018 at 06:10:51PM -0400, Jean-Francois Mezei said: >> >Not quite networking but probably relevant. >> > >> >The Canadian province of Qu??bec just introduced a new budget with >> >basically the intent to force foreign digital companies who sell >> >services to Qu??bekers to collect the local value added sales tax and >> >remit those to the QC government. >> > >> >The goal is to capture tax from Netflix who has so far escaped taxation >> >in Canada by having no legal/physical presence in Canada, no cache >> >servers of its own etc. Netflix does not currently collect province >> >information from customers (or any address info for that matter). >> > >> >They based many of their arguments on an OECD study (which ironically >> >the Canadian federal government says is not completed yet (as excuse for >> >not proceeding with similar tax). >> > >> >So foreign digital services will be required to require subscibers enter >> >AND VALIDATE their address so that they have an accurate province field >> >(validation remains to be finalized), and IF they sell more than $30,000 >> >to Qu??bec residents, will be required to self register with QC >> >government to collect local sales tax (and remit to QC government). >> > >> >The Qu??bec budget expects that validation of address will be based on IP >> >address geolocation or custoemrs send paper bills to prove place of >> >residence. >> > >> >(Although requiring full address/phone number and sendint this to credit >> >card network for authorization might constitute a better means to >> >validate address). >> > >> >I suspect the big winners will be VPN services in the USA :-) >> > >> >Because many ISPs span multiple provinces, IP geolocation generally >> >points to their HQ address, not necessarily the province of the >> >subscriber. (This is especially true for DSL in bell Canada wholesale >> >where currently a single point of connection between Bell and ISP allows >> >full reach of all of its DSL territory in QC/ON. For Cable, ISPs require >> >different IP pools for Rogers in Ontario and Vid??otron in Ontario (with >> >a couple of exceptions where Vid??otron has service in a couple fo >> >Ontario towns). In Western Canada, things are harder as Shaw serves BC, >> >AB, SASK and MB. >> >>-- >>Ken Chase - math at sizone.org Guelph Canada >> > -- Ken Chase - math at sizone.org Guelph Canada From izaac at setec.org Wed Mar 28 21:55:47 2018 From: izaac at setec.org (Izaac) Date: Wed, 28 Mar 2018 21:55:47 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: <38688E66-0C78-4E20-8111-AFD5BA5AD7B8@setec.org> On March 28, 2018 6:14:26 PM UTC, Payam Poursaied wrote: >dig google.com @1.1.1.1 Cute. I'm sure this engineering effort to centralize a distributed service will also go a long way to spur IPv6 adoption. -- Izaac From andy.litzinger.lists at gmail.com Wed Mar 28 23:22:55 2018 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Wed, 28 Mar 2018 16:22:55 -0700 Subject: validating reachability via an ISP Message-ID: Hi all, I have an enterprise network and do not provide transit. In one of our datacenters we have our own prefixes and rely on two ISPs as BGP neighbors to provide global reachability for our prefixes. One is a large regional provider and the other is a large global provider. Recently we took our link to the global provider offline to perform maintenance on our router. Nearly immediately we were hit with alerts that our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our route had been withdrawn. We were not unreachable from every AS, but we certainly were from some of the largest. The root cause is that the our prefix is not being adequately re-distributed globally by the regional ISP. This is unexpected and we are working through this with them now. My question is, how can I monitor global reachability for a prefix via this or any specific provider I use over time? Are there various route-servers I can programmatically query for my prefix and get results that include AS paths? Then I could verify that an "acceptable" number of paths exist that include the AS of the all the ISPs I rely upon. And what would an "acceptable" number of alternate paths be? thanks in advance, -andy From jfmezei_nanog at vaxination.ca Wed Mar 28 23:57:34 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 28 Mar 2018 19:57:34 -0400 Subject: Qu??bec Sales tax In-Reply-To: References: <20180327222112.GG9746@sizone.org> Message-ID: On 2018-03-28 17:45, Alain Hebert wrote: >     Same deal as Paypal and EBay. Paypal and EBay have not worked fevereshly to avoid a presence in Canada. They have presence and already handle the taxes. >     Netflix dropping their services in CDN/QC only serve > attempt at making yet another market grab. Netflix has worked VERY hard to avoid having a presence in Canada to avoid not only taxation, but also regulation from CRTC in broadcasting, having to contribute to various funds etc. The danger here is that it may feel that losing its QC customers is worth the price of maintaining the illusion it has no presence in Canada. There is also a class action lawsuit for Netflix because it did not follow the Québec Consumer procection law when it raised its rates a year or two ago. Class action lawsuits can be very expensive. And to bring his back to the network/ISP level: this is why it is very important that ISPs remain "common carriers" who do not control or have responsibility over content so that they don't get dragged into all those issues. >         ( And with all the hardware already deployed locally at the > many exchanges ... ) Netflix owns NO, NONE, NADA, ZERO hardware in Canada. It has no offices in Canada. Gifting the network appliances to ISPs means Netflix does not own the hardware and thus maintains its "no presence here". The second Netflix has physical presence here, the existing tax laws kicks in and Netflix must collect federal and provincial taxes. From david at ulevitch.com Wed Mar 28 21:39:21 2018 From: david at ulevitch.com (David Ulevitch) Date: Wed, 28 Mar 2018 21:39:21 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: On Wed, Mar 28, 2018 at 1:27 PM Aftab Siddiqui wrote: > 1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, > probably doing some more data gathering on 1.1.1.1 and doesn't want to be > smashed with Gigs of traffic. Doubtful. This is most assuredly going to be a commercial production recursive DNS service. Matthew (CEO) has said as much on Twitter: https://twitter.com/eastdakota/status/970214433598275584 and https://twitter.com/eastdakota/status/970359846548549632 -David Transit is still quite expensive in Aus :) > > https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt > > > On Thu, 29 Mar 2018 at 07:08 Bill Woodcock wrote: > > > > > > > > On Mar 28, 2018, at 11:14 AM, Payam Poursaied wrote: > > > > > > dig google.com @1.1.1.1 > > > Cloudflare? > > > > Yeah, Cloudflare did a deal with Geoff Huston to use it. It’s reserved > > for “experimental use." > > > > -Bill > > > > -- > Best Wishes, > > Aftab A. Siddiqui > From geier at geier.ne.tz Thu Mar 29 05:00:22 2018 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 29 Mar 2018 08:00:22 +0300 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: <73771a35-403d-7a6b-e6b4-cb55ff6c2f7d@geier.ne.tz> On 3/29/2018 2:22 AM, Andy Litzinger wrote: > Hi all, > I have an enterprise network and do not provide transit. In one of our > datacenters we have our own prefixes and rely on two ISPs as BGP neighbors > to provide global reachability for our prefixes. One is a large regional > provider and the other is a large global provider. > > Recently we took our link to the global provider offline to perform > maintenance on our router. Nearly immediately we were hit with alerts that > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our > route had been withdrawn. We were not unreachable from every AS, but we > certainly were from some of the largest. > > The root cause is that the our prefix is not being adequately > re-distributed globally by the regional ISP. This is unexpected and we are > working through this with them now. > > My question is, how can I monitor global reachability for a prefix via this > or any specific provider I use over time? Are there various route-servers > I can programmatically query for my prefix and get results that include AS > paths? Then I could verify that an "acceptable" number of paths exist that > include the AS of the all the ISPs I rely upon. And what would an > "acceptable" number of alternate paths be? If your global provider supports, you could send your announcements with a BGP community per RFC1998 telling them to not-prefer-so-much that advertisement, "use it as a backup". that would shift a lot of incoming traffic to the other link (regional provider). You'll still have the global provider link. this is a smaller change towards taking global provider offline, keeping some fallback. Frank From baldur.norddahl at gmail.com Thu Mar 29 08:41:45 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 29 Mar 2018 08:41:45 +0000 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: If your prefix is larger than /24 you can test with a more specific prefix such as a /24. Announce the test prefix on just one transit provider. Then check with BGP services such as the looking glass service provided by the NLNOG RING network. There will be no interruption in the traffic as it will follow the less specific prefix everywhere the test prefix was not picked up. If you only have a /24 you will need to test in a service window. Regards Baldur Den tor. 29. mar. 2018 01.24 skrev Andy Litzinger < andy.litzinger.lists at gmail.com>: > Hi all, > I have an enterprise network and do not provide transit. In one of our > datacenters we have our own prefixes and rely on two ISPs as BGP neighbors > to provide global reachability for our prefixes. One is a large regional > provider and the other is a large global provider. > > Recently we took our link to the global provider offline to perform > maintenance on our router. Nearly immediately we were hit with alerts that > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our > route had been withdrawn. We were not unreachable from every AS, but we > certainly were from some of the largest. > > The root cause is that the our prefix is not being adequately > re-distributed globally by the regional ISP. This is unexpected and we are > working through this with them now. > > My question is, how can I monitor global reachability for a prefix via this > or any specific provider I use over time? Are there various route-servers > I can programmatically query for my prefix and get results that include AS > paths? Then I could verify that an "acceptable" number of paths exist that > include the AS of the all the ISPs I rely upon. And what would an > "acceptable" number of alternate paths be? > > > thanks in advance, > -andy > From baldur.norddahl at gmail.com Thu Mar 29 08:53:45 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 29 Mar 2018 08:53:45 +0000 Subject: validating reachability via an ISP Message-ID: Also the only traffic you will be receiving on the other provider will be from parties that did not pick up the more specific prefix. It should therefore be really obvious. You should not receive any traffic at all, not even from the transit provider. Regards, Baldur Den tor. 29. mar. 2018 10.41 skrev Baldur Norddahl < baldur.norddahl at gmail.com>: > If your prefix is larger than /24 you can test with a more specific prefix > such as a /24. Announce the test prefix on just one transit provider. Then > check with BGP services such as the looking glass service provided by the > NLNOG RING network. > > There will be no interruption in the traffic as it will follow the less > specific prefix everywhere the test prefix was not picked up. > > If you only have a /24 you will need to test in a service window. > > Regards > > Baldur > > > Den tor. 29. mar. 2018 01.24 skrev Andy Litzinger < > andy.litzinger.lists at gmail.com>: > >> Hi all, >> I have an enterprise network and do not provide transit. In one of our >> datacenters we have our own prefixes and rely on two ISPs as BGP neighbors >> to provide global reachability for our prefixes. One is a large regional >> provider and the other is a large global provider. >> >> Recently we took our link to the global provider offline to perform >> maintenance on our router. Nearly immediately we were hit with alerts >> that >> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted >> our >> route had been withdrawn. We were not unreachable from every AS, but we >> certainly were from some of the largest. >> >> The root cause is that the our prefix is not being adequately >> re-distributed globally by the regional ISP. This is unexpected and we >> are >> working through this with them now. >> >> My question is, how can I monitor global reachability for a prefix via >> this >> or any specific provider I use over time? Are there various route-servers >> I can programmatically query for my prefix and get results that include AS >> paths? Then I could verify that an "acceptable" number of paths exist that >> include the AS of the all the ISPs I rely upon. And what would an >> "acceptable" number of alternate paths be? >> >> >> thanks in advance, >> -andy >> > From dot at dotat.at Thu Mar 29 11:16:48 2018 From: dot at dotat.at (Tony Finch) Date: Thu, 29 Mar 2018 12:16:48 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: David Ulevitch wrote: > https://twitter.com/eastdakota/status/970214433598275584 > https://twitter.com/eastdakota/status/970359846548549632 Also the very amusing https://twitter.com/eastdakota/status/970359846548549632 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey: East 5 to 7, occasionally gale 8 at first. Rough, occasionally very rough at first. Rain or showers. Good, occasionally moderate. From bortzmeyer at nic.fr Thu Mar 29 11:27:23 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 29 Mar 2018 13:27:23 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> Message-ID: <20180329112723.mc2sspxmbnkjlfrl@sources.org> On Wed, Mar 28, 2018 at 11:16:15PM +0300, DaKnOb wrote a message of 25 lines which said: > Out of 1,000 RIPE Atlas Probes, only 34 report it as unreachable. It's still a lot for IPv4. And it measures ony filtering, not hijacking (which seems to exist, some probes get a DNS reply without the AD bit, for instance). Because of the heavy use of 1.1.1.1 in documentation, you can expect a lot of networks to have trouble. Hey, 1.1.1.1 is even used in Cloudflare's own documentation! From mattlists at rivervalleyinternet.net Thu Mar 29 11:33:08 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Thu, 29 Mar 2018 07:33:08 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329112723.mc2sspxmbnkjlfrl@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> Message-ID: Why do we need this? We already have 8.8.8.8 and 8.8.4.4. And any reputable company or ISP should be running their own. What purpose would this serve? From bortzmeyer at nic.fr Thu Mar 29 11:38:49 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 29 Mar 2018 13:38:49 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <235C49B5-8ABB-473E-A10D-1BBCEF376A11@pch.net> Message-ID: <20180329113849.4o5zsdaw7pxpg75x@sources.org> On Thu, Mar 29, 2018 at 12:16:48PM +0100, Tony Finch wrote a message of 15 lines which said: > Also the very amusing > > https://twitter.com/eastdakota/status/970359846548549632 Less amusing, for a DNS service, the brokenness of reverse service: % dig -x 1.1.1.1 ; <<>> DiG 9.10.3-P4-Debian <<>> -x 1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24536 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR ;; Query time: 516 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Mar 29 13:37:54 CEST 2018 ;; MSG SIZE rcvd: 49 % dig @ns1.apnic.net. NS 1.1.1.in-addr.arpa ; <<>> DiG 9.10.3-P4-Debian <<>> @ns1.apnic.net. NS 1.1.1.in-addr.arpa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48493 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;1.1.1.in-addr.arpa. IN NS ;; AUTHORITY SECTION: 1.1.1.in-addr.arpa. 86400 IN NS ns7.cloudflare.com. 1.1.1.in-addr.arpa. 86400 IN NS ns3.cloudflare.com. 1.1.1.in-addr.arpa. 172800 IN NSEC 113.1.1.in-addr.arpa. NS RRSIG NSEC 1.1.1.in-addr.arpa. 172800 IN RRSIG NSEC 5 5 172800 ( 20180427150337 20180328140337 2371 1.in-addr.arpa. h44NAaTSpn5wvzTtddlUEKJ8+bikdaTDXnxh5M1bisO0 /NibM7iWfwcuaaWPvNeOutMdA0OBxGwbmErattfyXbRI KWrBWopBkr8+uVo7BgBYBa2SqY7PdUyYIt40PTjwnsrl lxBgaHMe1yz6qvQh2oljUJL45HkJnVWoHnuTRq8= ) ;; Query time: 317 msec ;; SERVER: 2001:dc0:2001:0:4608::25#53(2001:dc0:2001:0:4608::25) ;; WHEN: Thu Mar 29 13:38:05 CEST 2018 ;; MSG SIZE rcvd: 313 % dig @ns7.cloudflare.com -x 1.1.1.1 ; <<>> DiG 9.10.3-P4-Debian <<>> @ns7.cloudflare.com -x 1.1.1.1 ; (4 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10538 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR ;; Query time: 7 msec ;; SERVER: 2400:cb00:2049:1::a29f:606#53(2400:cb00:2049:1::a29f:606) ;; WHEN: Thu Mar 29 13:38:25 CEST 2018 ;; MSG SIZE rcvd: 49 % dig @ns3.cloudflare.com -x 1.1.1.1 ; <<>> DiG 9.10.3-P4-Debian <<>> @ns3.cloudflare.com -x 1.1.1.1 ; (4 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27962 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR ;; Query time: 6 msec ;; SERVER: 2400:cb00:2049:1::a29f:21#53(2400:cb00:2049:1::a29f:21) ;; WHEN: Thu Mar 29 13:38:33 CEST 2018 ;; MSG SIZE rcvd: 49 From nanog at ics-il.net Thu Mar 29 11:46:07 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Mar 2018 06:46:07 -0500 (CDT) Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> Message-ID: <611596605.3873.1522323962064.JavaMail.mhammett@ThunderFuck> Oddly, Matt, we agree again. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Hoppes" To: "Stephane Bortzmeyer" Cc: "NANOG list" Sent: Thursday, March 29, 2018 6:33:08 AM Subject: Re: Yet another Quadruple DNS? Why do we need this? We already have 8.8.8.8 and 8.8.4.4. And any reputable company or ISP should be running their own. What purpose would this serve? From bortzmeyer at nic.fr Thu Mar 29 11:46:30 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 29 Mar 2018 13:46:30 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> Message-ID: <20180329114630.mxqry552ymufsqku@sources.org> On Thu, Mar 29, 2018 at 07:33:08AM -0400, Matt Hoppes wrote a message of 7 lines which said: > We already have 8.8.8.8 and 8.8.4.4. And 9.9.9.9 and several others public DNS resolvers. > And any reputable company or ISP should be running their own. I fully agree. > What purpose would this serve? In Europe, the most common technique of censorship is through lying DNS resolvers. So, in order to go to forbidden Web sites (music and film sharing, for instance), many users switched from the ISP's resolver (which implements the censorship) to a public resolver. See my talk at NANOG From daknob.mac at gmail.com Thu Mar 29 12:41:12 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Thu, 29 Mar 2018 15:41:12 +0300 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329114630.mxqry552ymufsqku@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> Message-ID: <0A258F35-607F-424C-886E-2BE11E0B0E0A@gmail.com> Cloudflare’s website provides some more information: https://1.1.1.1/ According to Cloudflare’s CEO, we’ll have more news on 1/4, so in a few days. https://twitter.com/eastdakota/status/979257292938911744 From their website I can see that it is a low latency and privacy oriented service. Now whether it’s actually needed, I think there’s place for it in the market. Currently in Greece, 8.8.8.8 is ~65ms away. This is 11ms away. Antonis > On 29 Mar 2018, at 14:46, Stephane Bortzmeyer wrote: > > On Thu, Mar 29, 2018 at 07:33:08AM -0400, > Matt Hoppes wrote > a message of 7 lines which said: > >> We already have 8.8.8.8 and 8.8.4.4. > > And 9.9.9.9 and several others public DNS resolvers. > >> And any reputable company or ISP should be running their own. > > I fully agree. > >> What purpose would this serve? > > In Europe, the most common technique of censorship is through lying > DNS resolvers. So, in order to go to forbidden Web sites (music and > film sharing, for instance), many users switched from the ISP's > resolver (which implements the censorship) to a public resolver. See > my talk at NANOG > From chip at 2bithacker.net Thu Mar 29 13:07:58 2018 From: chip at 2bithacker.net (Chip Marshall) Date: Thu, 29 Mar 2018 13:07:58 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329114630.mxqry552ymufsqku@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> Message-ID: <20180329130758.GA58417@piranha.2bit.co> On 2018-03-29, Stephane Bortzmeyer sent: > On Thu, Mar 29, 2018 at 07:33:08AM -0400, > Matt Hoppes wrote > a message of 7 lines which said: > > > We already have 8.8.8.8 and 8.8.4.4. > > And 9.9.9.9 and several others public DNS resolvers. I think the real question is "when are we going to get some memorable IPv6 public recursive DNS servers?" 2001:4860:4860::8888 or 2620:fe::fe just aren't quite as catchy as 8.8.8.8 or 9.9.9.9. -- Chip Marshall http://2bithacker.net/ From dclements at gmail.com Thu Mar 29 13:13:06 2018 From: dclements at gmail.com (Doug Clements) Date: Thu, 29 Mar 2018 09:13:06 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329130758.GA58417@piranha.2bit.co> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> Message-ID: On Thu, Mar 29, 2018 at 9:07 AM, Chip Marshall wrote: > I think the real question is "when are we going to get some memorable > IPv6 public recursive DNS servers?" > > 2001:4860:4860::8888 or 2620:fe::fe just aren't quite as catchy as > 8.8.8.8 or 9.9.9.9. >From https://1.1.1.1/: For IPv6: *2001:2001::* and/or *2001:2001:2001::* Those are pretty catchy. --Doug From izaac at setec.org Thu Mar 29 13:38:09 2018 From: izaac at setec.org (Izaac) Date: Thu, 29 Mar 2018 09:38:09 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329130758.GA58417@piranha.2bit.co> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> Message-ID: <20180329T131245Z@localhost> On Thu, Mar 29, 2018 at 01:07:58PM +0000, Chip Marshall wrote: > I think the real question is "when are we going to get some memorable > IPv6 public recursive DNS servers?" No, the real question is: why do you find it desirable to centralize a distributed service? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From jlk at thrashyour.com Thu Mar 29 13:43:58 2018 From: jlk at thrashyour.com (John Kinsella) Date: Thu, 29 Mar 2018 06:43:58 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329T131245Z@localhost> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> Message-ID: > On Mar 29, 2018, at 6:38 AM, Izaac wrote: > > On Thu, Mar 29, 2018 at 01:07:58PM +0000, Chip Marshall wrote: >> I think the real question is "when are we going to get some memorable >> IPv6 public recursive DNS servers?" > > No, the real question is: why do you find it desirable to centralize a > distributed service? Any distributed service is made up of centralized services. This is one example. From aaron1 at gvtc.com Thu Mar 29 13:57:38 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 29 Mar 2018 08:57:38 -0500 Subject: aol login problems - my.screenname.aol.com Message-ID: <000301d3c765$e6643eb0$b32cbc10$@gvtc.com> When going to aol.com and click "login/join" in top-right corner, brings you to a login page. when I try to login, I get nothing. just tries and tries to take me to the next page, which seems to be my.screenname.aol.com. but it never gets there. If I try from different subnets in my network, it does work. But from other subnets it does not. Has anyone ever heard/seen this problem ? Anyone from aol here that can assist with this please ? You can contact me directly if you can assist. -Aaron From Brian at ampr.org Thu Mar 29 14:01:59 2018 From: Brian at ampr.org (Brian Kantor) Date: Thu, 29 Mar 2018 07:01:59 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329T131245Z@localhost> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> Message-ID: <20180329140159.GA72866@meow.BKantor.net> On Thu, Mar 29, 2018 at 09:38:09AM -0400, Izaac wrote: > No, the real question is: why do you find it desirable to centralize a > distributed service? I believe that centralized DNS resolvers such as 8.8.8.8 are of benefit to those folks who can't run their own recursive resolver because of OS, hardware, or skill limitations, and yet do not trust the ones provided by their ISPs. I use 9.9.9.9 for my home desktop to avoid the interception of my DNS queries by my cable company. I'd very much rather get an NXDOMAIN than a connection to some web server that wants to offer me a "helpful" web page, even when I'm running a non-web client like ssh or 'dig'. And I'd really like not to enrich my ISP's trove of information about my browsing habits by them recording all my DNS lookups. Of course, 9.9.9.9 could be collecting that information, but they're in less of a position to insert ads than my cableco is. - Brian From cma at cmadams.net Thu Mar 29 14:08:38 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 29 Mar 2018 09:08:38 -0500 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140159.GA72866@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> Message-ID: <20180329140838.GA27469@cmadams.net> Once upon a time, Brian Kantor said: > I believe that centralized DNS resolvers such as 8.8.8.8 are of > benefit to those folks who can't run their own recursive resolver > because of OS, hardware, or skill limitations, and yet do not trust > the ones provided by their ISPs. I've never really understood this - if you don't trust your ISP's DNS, why would you trust them not to transparently intercept any well-known third-party DNS? -- Chris Adams From izaac at setec.org Thu Mar 29 14:17:47 2018 From: izaac at setec.org (Izaac) Date: Thu, 29 Mar 2018 10:17:47 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140159.GA72866@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> Message-ID: <20180329T140628Z@localhost> On Thu, Mar 29, 2018 at 07:01:59AM -0700, Brian Kantor wrote: > do not trust the ones provided by their ISPs. Ohhh! Is that a thing? Network operators doing crazy shit like throwing A records to local machines instead of NXDOMAIN in order to splash advertising at users? Imagine users getting so frustrated at this broken behavior that they engage in another broken behavior. Whoever mentions "opt-out" gets a virtual smack on the back of the head. Correct behavior is not "opt-in." > And I'd really like not to enrich my ISP's trove of information about > my browsing habits by them recording all my DNS lookups. Of course, > 9.9.9.9 could be collecting that information, but they're in less > of a position to insert ads than my cableco is. Don't worry: they are. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From sethm at rollernet.us Thu Mar 29 14:19:46 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 29 Mar 2018 07:19:46 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329T140628Z@localhost> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329T140628Z@localhost> Message-ID: On 3/29/18 7:17 AM, Izaac wrote: >> And I'd really like not to enrich my ISP's trove of information about >> my browsing habits by them recording all my DNS lookups. Of course, >> 9.9.9.9 could be collecting that information, but they're in less >> of a position to insert ads than my cableco is. > Don't worry: they are. Needs more DNS over TLS. From jared at puck.nether.net Thu Mar 29 14:23:35 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 Mar 2018 10:23:35 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329T140628Z@localhost> Message-ID: > On Mar 29, 2018, at 10:19 AM, Seth Mattinen wrote: > > On 3/29/18 7:17 AM, Izaac wrote: >>> And I'd really like not to enrich my ISP's trove of information about >>> my browsing habits by them recording all my DNS lookups. Of course, >>> 9.9.9.9 could be collecting that information, but they're in less >>> of a position to insert ads than my cableco is. >> Don't worry: they are. > > > Needs more DNS over TLS. Good news everyone! https://datatracker.ietf.org/wg/doh/about/ - Jared From Brian at ampr.org Thu Mar 29 14:27:21 2018 From: Brian at ampr.org (Brian Kantor) Date: Thu, 29 Mar 2018 07:27:21 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140838.GA27469@cmadams.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> Message-ID: <20180329142721.GA73017@meow.BKantor.net> On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote: > I've never really understood this - if you don't trust your ISP's DNS, > why would you trust them not to transparently intercept any well-known > third-party DNS? Of course they could. But it's testable; experiments show that they aren't doing so currently. - Brian From bortzmeyer at nic.fr Thu Mar 29 14:24:41 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 29 Mar 2018 16:24:41 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140159.GA72866@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> Message-ID: <20180329142441.svo3qphnieukmljx@sources.org> On Thu, Mar 29, 2018 at 07:01:59AM -0700, Brian Kantor wrote a message of 20 lines which said: > I believe that centralized DNS resolvers such as 8.8.8.8 are of > benefit to those folks who can't run their own recursive resolver > because of OS, hardware, Hardware is not a real problem. A Raspberry Pi is more than enough to run a resolver for a typical home. > or skill limitations, That's certainly a more important issue. Even when someone has skills, he or she may not have the time and inclination to do system administration at home. The solution is proper packaging of this DNS function in ready-made boxes such as the Turris Omnia > and yet do not trust the ones provided by their ISPs. Unfortunately, the users are often right here :-( From bortzmeyer at nic.fr Thu Mar 29 14:32:18 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 29 Mar 2018 16:32:18 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140838.GA27469@cmadams.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> Message-ID: <20180329143218.3mzxldp7k2bfky3l@sources.org> On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote a message of 12 lines which said: > I've never really understood this - if you don't trust your ISP's > DNS, why would you trust them not to transparently intercept any > well-known third-party DNS? Technically, tweaking your DNS resolver to lie (and/or to log) is much easier and faster (and waaaaay less expensive) than setting up a packet interception and rewriting device at line rate. You're right, it is technically possible to "transparently intercept any well-known third-party DNS". Two main ways, a routing trick (like the one used in Turkey against Google Public DNS ) which is simple, and packet-level interception devices like in China , which is not for the ordinary ISP. That's why public DNS resolvers are not really a solution against strong adversaries *unless* you authenticate and encrypt the connection. Quad9 allows that . Public DNS resolvers still help against "ordinary" adversaries. (If your ennemy is the NSA, you have other problems, anyway.) From sethm at rollernet.us Thu Mar 29 14:45:53 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 29 Mar 2018 07:45:53 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329142441.svo3qphnieukmljx@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329142441.svo3qphnieukmljx@sources.org> Message-ID: <35e4b93e-ca01-0f6c-81fc-b19778ad66e3@rollernet.us> On 3/29/18 7:24 AM, Stephane Bortzmeyer wrote: > That's certainly a more important issue. Even when someone has skills, > he or she may not have the time and inclination to do system > administration at home. The solution is proper packaging of this > DNS function in ready-made boxes such as the Turris Omnia > I'm lazy and have been using 9.9.9.9 at home. From james.cutler at consultant.com Thu Mar 29 14:46:15 2018 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 29 Mar 2018 10:46:15 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329130758.GA58417@piranha.2bit.co> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> Message-ID: <919443E1-ABF9-407D-9140-A8AF23B8EE53@consultant.com> > On Mar 29, 2018, at 9:07 AM, Chip Marshall > wrote: > > ... > I think the real question is "when are we going to get some memorable > IPv6 public recursive DNS servers?" > > 2001:4860:4860::8888 or 2620:fe::fe just aren't quite as catchy as > 8.8.8.8 or 9.9.9.9. > > -- > Chip Marshall > > http://2bithacker.net/ Perhaps the real question is why is this important. The great mass of users simply does not even know what DNS is. And, supposedly, we wise NANOG people know how to cut and paste. - 75.75.75.75 James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu From awentzell at gmail.com Thu Mar 29 14:51:37 2018 From: awentzell at gmail.com (Andrew Wentzell) Date: Thu, 29 Mar 2018 10:51:37 -0400 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: On Wed, Mar 28, 2018 at 7:22 PM, Andy Litzinger wrote: > Hi all, > I have an enterprise network and do not provide transit. In one of our > datacenters we have our own prefixes and rely on two ISPs as BGP neighbors > to provide global reachability for our prefixes. One is a large regional > provider and the other is a large global provider. > > Recently we took our link to the global provider offline to perform > maintenance on our router. Nearly immediately we were hit with alerts that > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our > route had been withdrawn. We were not unreachable from every AS, but we > certainly were from some of the largest. > > The root cause is that the our prefix is not being adequately > re-distributed globally by the regional ISP. This is unexpected and we are > working through this with them now. > > My question is, how can I monitor global reachability for a prefix via this > or any specific provider I use over time? Are there various route-servers > I can programmatically query for my prefix and get results that include AS > paths? Then I could verify that an "acceptable" number of paths exist that > include the AS of the all the ISPs I rely upon. And what would an > "acceptable" number of alternate paths be? I did something similar a few years ago, by querying routeviews and validating AS paths using python and pexpect. You could adapt it for your use pretty easily. The code's here: https://github.com/awentzell/check-as-path From woody at pch.net Thu Mar 29 15:29:57 2018 From: woody at pch.net (Bill Woodcock) Date: Thu, 29 Mar 2018 08:29:57 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329142721.GA73017@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329142721.GA73017@meow.BKantor.net> Message-ID: > \On Mar 29, 2018, at 7:27 AM, Brian Kantor wrote: > > On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote: >> I've never really understood this - if you don't trust your ISP's DNS, >> why would you trust them not to transparently intercept any well-known >> third-party DNS? > > Of course they could. But it's testable; experiments show that they > aren't doing so currently. Experiments may show that in some tested cases they aren’t, but in the big picture, yes, there are ISPs who are internally capturing 8.8.8.8, and who try to do the same with 9.9.9.9. Which is why it’s so important to do cryptographic validation of the server and encryption of the transport, as well as DNSSEC validation. -Bill -------------- 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 michael at wi-fiber.io Thu Mar 29 15:44:29 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 29 Mar 2018 09:44:29 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329142721.GA73017@meow.BKantor.net> Message-ID: Along these same lines, we have a service that captures all DNS requests regardless the server(only non-TLS, albeit), that people pay $9.99/mo for, so they definitely want this.. We just NAT all requests to Open DNS servers to provide internet filtering as a service. It would be arbitrarily trivial to run our own DNS service and reply to any unencrypted DNS request to any DNS server with whatever A or AAAA record we want.. On 29 March 2018 at 09:29, Bill Woodcock wrote: > > \On Mar 29, 2018, at 7:27 AM, Brian Kantor wrote: > > > > On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote: > >> I've never really understood this - if you don't trust your ISP's DNS, > >> why would you trust them not to transparently intercept any well-known > >> third-party DNS? > > > > Of course they could. But it's testable; experiments show that they > > aren't doing so currently. > > Experiments may show that in some tested cases they aren’t, but in the big > picture, yes, there are ISPs who are internally capturing 8.8.8.8, and who > try to do the same with 9.9.9.9. Which is why it’s so important to do > cryptographic validation of the server and encryption of the transport, as > well as DNSSEC validation. > > -Bill > > From woody at pch.net Thu Mar 29 15:44:32 2018 From: woody at pch.net (Bill Woodcock) Date: Thu, 29 Mar 2018 08:44:32 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329140159.GA72866@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> Message-ID: <7CE9D073-0F1C-4C96-BC0D-C695C91FEAA7@pch.net> > On Mar 29, 2018, at 7:01 AM, Brian Kantor wrote: > > I use 9.9.9.9 for my home desktop to avoid the interception of my > DNS queries by my cable company. I'd very much rather get an > NXDOMAIN than a connection to some web server that wants to offer > me a "helpful" web page, even when I'm running a non-web client > like ssh or 'dig'. > > And I'd really like not to enrich my ISP's trove of information about > my browsing habits by them recording all my DNS lookups. Of course, > 9.9.9.9 could be collecting that information, but they're in less > of a position to insert ads than my cableco is. The only queries for which the query string is collected are those which match the malware block-lists. IP addresses are not collected for any queries, not even for ones which match the malware block-lists. https://quad9.net/privacy/ -Bill -------------- 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 alan.buxey at gmail.com Thu Mar 29 15:56:51 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Thu, 29 Mar 2018 16:56:51 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329142721.GA73017@meow.BKantor.net> Message-ID: exactly. intercept/inject? why. an ISP can just run its own standard DNS servers on 8.8.8.8 and 8.8.4.4 and point their customers to those - they own their routing space, they can just route to those locally....so anyone thinking they can avoid their ISP by choosing some other addresses are mistaken.... the only way to avoid is through encrypted lookups to a known/trusted/and signed endpoint etc From aa at qrator.net Thu Mar 29 15:09:02 2018 From: aa at qrator.net (Alexander Azimov) Date: Thu, 29 Mar 2018 18:09:02 +0300 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: Hi Andy, You can use Qrator.Radar API: https://api.radar.qrator.net/. The get-all-paths method will return the set of active paths for selected prefix. 2018-03-29 2:22 GMT+03:00 Andy Litzinger : > Hi all, > I have an enterprise network and do not provide transit. In one of our > datacenters we have our own prefixes and rely on two ISPs as BGP neighbors > to provide global reachability for our prefixes. One is a large regional > provider and the other is a large global provider. > > Recently we took our link to the global provider offline to perform > maintenance on our router. Nearly immediately we were hit with alerts that > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our > route had been withdrawn. We were not unreachable from every AS, but we > certainly were from some of the largest. > > The root cause is that the our prefix is not being adequately > re-distributed globally by the regional ISP. This is unexpected and we are > working through this with them now. > > My question is, how can I monitor global reachability for a prefix via this > or any specific provider I use over time? Are there various route-servers > I can programmatically query for my prefix and get results that include AS > paths? Then I could verify that an "acceptable" number of paths exist that > include the AS of the all the ISPs I rely upon. And what would an > "acceptable" number of alternate paths be? > > > thanks in advance, > -andy > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa at qrator.net | visit: www.qrator.net From mstucchi at ripe.net Thu Mar 29 14:01:55 2018 From: mstucchi at ripe.net (Massimiliano Stucchi) Date: Thu, 29 Mar 2018 16:01:55 +0200 Subject: RIPE NCC Global IPv6 Deployment Survey Message-ID: Hi, just a little reminder that there are a few days left to help the RIPE NCC by filling up our Global IPv6 Deployment Survey. We have already received a considerable amount of responses, but would like to hear from more people. The goal of the survey is to get an overview of IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up to similar surveys run between 2008 and 2013, and will serve as a comparison with the data acquired back then. You can find the survey at the following address: https://www.surveymonkey.com/r/GlobalIPv6survey2018 Responses can be submitted until 31 March 2018. We will then collect the data with the aim of presenting the preliminary results during the upcoming RIPE 76 meeting in Marseille. If you have any question about the survey, please feel free to email us at: ipv6survey2018 at ripe.net. Thank you very much in advance for your participation! -- Massimiliano Stucchi IPv6 Programme Manager RIPE NCC mstucchi at ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From warlord at teol.net Thu Mar 29 13:13:00 2018 From: warlord at teol.net (Igor Krneta) Date: Thu, 29 Mar 2018 15:13:00 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329130758.GA58417@piranha.2bit.co> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> Message-ID: <301b89d4-45e2-1a30-99ab-adbbc0667944@teol.net> From 1.1.1.1 website: Cloudflare DNS resolver: ** * For IPv4:*1.1.1.1*and/or*1.0.0.1* * For IPv6:*2001:2001::*and/or*2001:2001:2001::* Its catchy enough for IPV6 :). On 29.3.2018 15:07, Chip Marshall wrote: > I think the real question is "when are we going to get some memorable > IPv6 public recursive DNS servers?" > > 2001:4860:4860::8888 or 2620:fe::fe just aren't quite as catchy as > 8.8.8.8 or 9.9.9.9. > From mysidia at gmail.com Thu Mar 29 16:24:19 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 29 Mar 2018 11:24:19 -0500 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329142721.GA73017@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329142721.GA73017@meow.BKantor.net> Message-ID: On Thu, Mar 29, 2018 at 9:27 AM, Brian Kantor wrote: > Of course they could. But it's testable; experiments show that they > aren't doing so currently. Some of the recursive DNS providers support a protocol called DNSCrypt for authenticating data between the client and the recursive nameserver, to mutually authenticate client+server, and ensure data hasn't been modified by a man-in-the-middle. https://www.opendns.com/about/innovations/dnscrypt/ > - Brian -- -JH From baldur.norddahl at gmail.com Thu Mar 29 16:26:47 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 29 Mar 2018 16:26:47 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329143218.3mzxldp7k2bfky3l@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: > > > Technically, tweaking your DNS resolver to lie (and/or to log) is much > easier and faster (and waaaaay less expensive) than setting up a > packet interception and rewriting device at line rate. > It is just a static /32 route for well known DNS resolvers to the ISP resolver. It is free and trivial. To make your resolver reply with the correct IP you simply add all the well known /32 addresses to the localhost interface. To get any service instead of just well known ones, you can use source routing based on the port nummer 53. Direct this to a Linux server that will NAT the traffic towards the ISP DNS. This is also trivial and free, provided your routers support source routing (ours do). Detectable yes, but also hard to escape for the average user. They will need to go full VPN. Running your own resolver will not work. Regards Baldur From hank at efes.iucc.ac.il Thu Mar 29 16:31:34 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 29 Mar 2018 19:31:34 +0300 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329T140628Z@localhost> Message-ID: <376d63fa-e7be-08fa-1bc5-46df9eb08435@efes.iucc.ac.il> On 29/03/2018 17:23, Jared Mauch wrote: >> On Mar 29, 2018, at 10:19 AM, Seth Mattinen wrote: >> >> On 3/29/18 7:17 AM, Izaac wrote: >>>> And I'd really like not to enrich my ISP's trove of information about >>>> my browsing habits by them recording all my DNS lookups. Of course, >>>> 9.9.9.9 could be collecting that information, but they're in less >>>> of a position to insert ads than my cableco is. >>> Don't worry: they are. >>> >>> >>> Needs more DNS over TLS. > Good news everyone! > > https://datatracker.ietf.org/wg/doh/about/ Hmmmm.... https://threatpost.com/mozilla-tests-dns-over-https-meets-some-privacy-pushback/130765/ "Starting in the next several weeks, Mozilla plans to run tests using a developer version of its Firefox browser with the help of the Mozilla developer community and content management and delivery network firm Cloudflare. Developers will be testing a proposed standard called Trusted Recursive Resolver via DNS over HTTPS, or DoH for short." Cloudflare and DoH.  Cloudflare and 1.1.1.1.  Coincidence? -Hank From math at sizone.org Thu Mar 29 16:34:37 2018 From: math at sizone.org (Ken Chase) Date: Thu, 29 Mar 2018 12:34:37 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <20180329163437.GA18481@sizone.org> Who's got visible projects looking to detect this from various points/regimes on the internet? (University of Toronto's IXMaps group whom I advised a few times over the years did something similar for routes, not that BGPlay isnt out there, but they translated it into human as a sociology project - borne of the Carnivore era. https://www.ixmaps.ca/ ) Im glad no one said Namecoin yet. Oops. /kc On Thu, Mar 29, 2018 at 04:26:47PM +0000, Baldur Norddahl said: >> >> >> Technically, tweaking your DNS resolver to lie (and/or to log) is much >> easier and faster (and waaaaay less expensive) than setting up a >> packet interception and rewriting device at line rate. >> > >It is just a static /32 route for well known DNS resolvers to the ISP >resolver. It is free and trivial. To make your resolver reply with the >correct IP you simply add all the well known /32 addresses to the localhost >interface. > >To get any service instead of just well known ones, you can use source >routing based on the port nummer 53. Direct this to a Linux server that >will NAT the traffic towards the ISP DNS. This is also trivial and free, >provided your routers support source routing (ours do). > >Detectable yes, but also hard to escape for the average user. They will >need to go full VPN. Running your own resolver will not work. > >Regards > >Baldur -- Ken Chase - math at sizone.org Guelph Canada From list at satchell.net Thu Mar 29 17:59:02 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 29 Mar 2018 10:59:02 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <7066c933-f3cf-9a2c-ae6d-cd6390b73225@satchell.net> In regards to: spoofing DNS to 8.8.8.8 et al On 03/29/2018 09:26 AM, Baldur Norddahl wrote: > Running your own resolver will not work. Why won't it work? I run a Linux box with BIND 9 set up as a recursive resolver. Are you saying that the rogues will also capture requests to the root DNS servers, as described in the hints file? From joelja at bogus.com Thu Mar 29 18:27:09 2018 From: joelja at bogus.com (joel jaeggli) Date: Thu, 29 Mar 2018 11:27:09 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <7066c933-f3cf-9a2c-ae6d-cd6390b73225@satchell.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> <7066c933-f3cf-9a2c-ae6d-cd6390b73225@satchell.net> Message-ID: On 3/29/18 10:59 AM, Stephen Satchell wrote: > In regards to: spoofing DNS to 8.8.8.8 et al > > On 03/29/2018 09:26 AM, Baldur Norddahl wrote: >> Running your own resolver will not work. > > Why won't it work?  I run a Linux box with BIND 9 set up as a > recursive resolver.  Are you saying that the rogues will also capture > requests to the root DNS servers, as described in the hints file? All destination port 53 udp packets. From rsk at gsp.org Thu Mar 29 20:39:39 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 29 Mar 2018 16:39:39 -0400 Subject: Fwd: [vicky@isc.org: Planning to stop exporting BIND libraries] Message-ID: <20180329203939.GA30562@gsp.org> Forwarding here to expose it to a larger, possibly-interested audience. ---rsk ----- Forwarded message from Victoria Risk ----- > From: Victoria Risk > Date: Fri, 23 Mar 2018 12:30:26 +0000 > To: bind-announce at lists.isc.org > Subject: Planning to stop exporting BIND libraries > > BIND currently exports number of libraries, including libisc, libisccfg, libirs, libisccc, libdns and libbind9. > > We don???t know of any external projects that use these libraries. Keeping the ABI and API stable is big burden, and we are exploring the possibility of merging all the libraries into a tightly-coupled private library that wouldn't be used outside of BIND (and tools). This change would effectively make those libraries private. > > BIND 9.14 in 2019 would be the first release that would drop the libraries. > > The BIND 9.11 ESV would keep those libraries until 2022, so any external users would have enough time to migrate to other DNS libraries. > > Known external users of libisc and friends: > - ISC DHCP (will continue using BIND 9.11 libraries) > - dnsperf (either use BIND 9.11 libraries, or offer ISC project) > > Please let us know if you see a significant problem with this plan, including which library you are using and how you are using it. > > Thank you > > Vicky > > ------------- > Victoria Risk > Product Manager > Internet Systems Consortium > vicky at isc.org > > ----- End forwarded message ----- From fhr at fhrnet.eu Fri Mar 30 00:04:31 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Fri, 30 Mar 2018 00:04:31 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <0A258F35-607F-424C-886E-2BE11E0B0E0A@gmail.com> <20180329114630.mxqry552ymufsqku@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> Message-ID: <0102016274385381-9d57de74-32de-4b76-909d-1918233bfbdb-000000@eu-west-1.amazonses.com> Is it just me, or is there a problem with the website? I get a nginx 403 Forbidden error when trying to access it. Regards, Filip > > On 29 Mar 2018 at 2:41 pm, wrote: > > > Cloudflare’s website provides some more information: https://1.1.1.1/ According to Cloudflare’s CEO, we’ll have more news on 1/4, so in a few days. https://twitter.com/eastdakota/status/979257292938911744 From their website I can see that it is a low latency and privacy oriented service. Now whether it’s actually needed, I think there’s place for it in the market. Currently in Greece, 8.8.8.8 is ~65ms away. This is 11ms away. Antonis > On 29 Mar 2018, at 14:46, Stephane Bortzmeyer wrote: > > On Thu, Mar 29, 2018 at 07:33:08AM -0400, > Matt Hoppes wrote > a message of 7 lines which said: > >> We already have 8.8.8.8 and 8.8.4.4. > > And 9.9.9.9 and several others public DNS resolvers. > >> And any reputable company or ISP should be running their own. > > I fully agree. > >> What purpose would this serve? > > In Europe, the most common technique of censorship is through lying > DNS resolvers. So, in order to go to forbidden Web sites (music and > film sharing, for instance), many users switched from the ISP's > resolver (which implements the censorship) to a public resolver. See > my talk at NANOG > > From eric-list at truenet.com Fri Mar 30 00:10:30 2018 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 29 Mar 2018 20:10:30 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <0102016274385381-9d57de74-32de-4b76-909d-1918233bfbdb-000000@eu-west-1.amazonses.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <0102016274385381-9d57de74-32de-4b76-909d-1918233bfbdb-000000@eu-west-1.amazonses.com> Message-ID: > Is it just me, or is there a problem with the website? I get a nginx 403 Forbidden error when trying to access it. > > > > Regards, > Filip I can verify it was working, but they might have gotten hammered after this thread. Still curious how they got a SSL cert for an IP address, as that was definitely interesting to me. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 From niels=nanog at bakker.net Fri Mar 30 00:33:28 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 30 Mar 2018 02:33:28 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <0102016274385381-9d57de74-32de-4b76-909d-1918233bfbdb-000000@eu-west-1.amazonses.com> Message-ID: <20180330003328.GC30812@excession.tpb.net> * eric-list at truenet.com (Eric Tykwinski) [Fri 30 Mar 2018, 02:11 CEST]: >Still curious how they got a SSL cert for an IP address, as that was >definitely interesting to me. https://cabforum.org/guidance-ip-addresses-certificates/ -- Niels. -- From bortzmeyer at nic.fr Fri Mar 30 09:39:50 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 30 Mar 2018 11:39:50 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329142721.GA73017@meow.BKantor.net> Message-ID: <20180330093950.pge2vq5z6w4gfwex@nic.fr> On Thu, Mar 29, 2018 at 08:29:57AM -0700, Bill Woodcock wrote a message of 53 lines which said: > there are ISPs who are internally capturing 8.8.8.8, and who try to > do the same with 9.9.9.9. Which is why it’s so important to do > cryptographic validation of the server and encryption of the > transport, as well as DNSSEC validation. And the good thing is that RFC 8310 has been published one week ago. I'm waiting for its deployment in Quad9 :-) https://www.rfc-editor.org/info/rfc8310 From swmike at swm.pp.se Fri Mar 30 10:27:52 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 30 Mar 2018 12:27:52 +0200 (CEST) Subject: new diffserv code point LE PHB Message-ID: Hi, I would like to bring attention to the following IETF draft: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-04 I believe this is well under way through the IETF process, and if someone has strong opinions on it they should speak up. I am one of the proponents, as I posted to this list back in 2015: https://mailman.nanog.org/pipermail/nanog/2015-July/077040.html I think it's a great idea to have a diffserv code point that is supposed to be treated less than best effort (for backup traffic for instance), but it would be nice if someone would be willing to deploy support for it as well. Thoughts? -- Mikael Abrahamsson email: swmike at swm.pp.se From job at instituut.net Fri Mar 30 11:30:07 2018 From: job at instituut.net (Job Snijders) Date: Fri, 30 Mar 2018 13:30:07 +0200 Subject: new diffserv code point LE PHB In-Reply-To: References: Message-ID: <20180330113007.GA1193@hanna.meerval.net> Dear Mikael, On Fri, Mar 30, 2018 at 12:27:52PM +0200, Mikael Abrahamsson wrote: > I would like to bring attention to the following IETF draft: > > https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-04 > > I believe this is well under way through the IETF process, and if someone > has strong opinions on it they should speak up. I am one of the proponents, > as I posted to this list back in 2015: > > https://mailman.nanog.org/pipermail/nanog/2015-July/077040.html > > I think it's a great idea to have a diffserv code point that is supposed to > be treated less than best effort (for backup traffic for instance), but it > would be nice if someone would be willing to deploy support for it as well. > > Thoughts? Do you have configuration examples for common IP carrier platforms on how to deploy support? Or is support in CPE's, laptops, & CDN caches sufficient? Are you aware of any software distributors that have indicated interest in this approach? In cases where you have both 'normal' and 'bulk' content on the same webserver, are there any webservers that allow you to set a DSCP value per path or filename? Kind regards, Job From morrowc.lists at gmail.com Fri Mar 30 13:30:00 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Mar 2018 09:30:00 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180329143218.3mzxldp7k2bfky3l@sources.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: On Thu, Mar 29, 2018 at 10:32 AM, Stephane Bortzmeyer wrote: > > Public DNS resolvers still help against "ordinary" adversaries. (If > your ennemy is the NSA, you have other problems, anyway.) > I think there's ample evidence that everyone's enemy is 'the nsa' (or other nation-state-actors) isn't there? From royce at techsolvency.com Fri Mar 30 14:39:41 2018 From: royce at techsolvency.com (Royce Williams) Date: Fri, 30 Mar 2018 06:39:41 -0800 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: On Fri, Mar 30, 2018 at 5:30 AM, Christopher Morrow wrote: > > On Thu, Mar 29, 2018 at 10:32 AM, Stephane Bortzmeyer > wrote: > > > Public DNS resolvers still help against "ordinary" adversaries. (If > > your ennemy is the NSA, you have other problems, anyway.) If you're individually targeted by such an org, yes. If you want to raise the cost of slurping up everyone's traffic in bulk and then sifting/analytic-ing through it later, then some effort (encrypting/verifying everything feasible, using ciphers that support forward secrecy, MFA, etc.) is worthwhile. Bulk encryption is a reasonable response to bulk intercept. Raising the chances of *detecting* attempts at such interception is also warranted. I'm not aware of any browser extensions that incorporate the technique used by https://mitm.watch/ (or even if it's feasible at that layer), but that would be useful, too. > I think there's ample evidence that everyone's enemy is 'the nsa' (or other > nation-state-actors) isn't there? s/"nation-state"/"anyone who can intercept, alter, or inject traffic between you and your destination"/g. Of course, that neither solves the problem of manipulative use of your traffic *by* your destination (*cough*Facebook/everyone*cough*) nor the problem of compromise of the endpoint. Increasing intercept resistance does nothing for the former (only voting, or voting with your dollar, can impact that) ... but it can help with the latter (by making it harder for someone to compromise your endpoint by manipulating/mimicking traffic from your destination). (None of this is news to most of you, but IMO clarifying the breadth of the landscape has value). And of course, none of this is news to Stephane: https://tools.ietf.org/html/rfc7816 :) Royce From royce at techsolvency.com Fri Mar 30 14:46:19 2018 From: royce at techsolvency.com (Royce Williams) Date: Fri, 30 Mar 2018 06:46:19 -0800 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: And FWIW, there are currently a few other other same-quad open resolvers: # IP - desc | CIDR | recursion-yes 1.1.1.1 - APNIC-LABS - Research prefix for APNIC Labs (now Cloudflare distributed public recursive DNS) | 1/8 | recursion-yes 8.8.8.8 - Google LLC (public recursive DNS) | 8.8.8/24 | recursion-yes 9.9.9.9 - Quad9 (public recursive DNS) | 9.9.9/24 | recursion-yes 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | recursion-yes 80.80.80.80 - Freenom DNS CLoud IP Space | 80.80.80/23 | recursion-yes 114.114.114.114 - NanJing XinFeng Information Technologies, Inc. | 114.114/16 | recursion-yes Full survey - with owners of the largest bit-boundary-aligned blocks that contain them - here: https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 Royce From bortzmeyer at nic.fr Fri Mar 30 14:55:26 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 30 Mar 2018 16:55:26 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <20180330145526.utcfarh5tt3pjali@nic.fr> On Fri, Mar 30, 2018 at 06:46:19AM -0800, Royce Williams wrote a message of 19 lines which said: > Full survey - with owners of the largest bit-boundary-aligned blocks > that contain them - here: > > https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 Unlike what you say, 112.112.112.112 works (note for the humour-impaired: there is a trick): % dig @112.112.112.112 facebook.com ; <<>> DiG 9.10.3-P4-Debian <<>> @112.112.112.112 facebook.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41543 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;facebook.com. IN A ;; ANSWER SECTION: facebook.com. 126 IN A 31.13.74.1 ;; Query time: 218 msec ;; SERVER: 112.112.112.112#53(112.112.112.112) ;; WHEN: Fri Mar 30 16:54:12 CEST 2018 ;; MSG SIZE rcvd: 57 From wwaites at tardis.ed.ac.uk Fri Mar 30 14:57:24 2018 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 30 Mar 2018 15:57:24 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <20E43895-10AB-4119-ACB7-CC9A74DD9E6B@tardis.ed.ac.uk> > > On 30 Mar 2018, at 15:46, Royce Williams wrote: > > 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | > recursion-yes Well, that one's a little odd: % host news.bbc.co.uk 77.77.77.77 Using domain server: Name: 77.77.77.77 Address: 77.77.77.77#53 Aliases: news.bbc.co.uk has address 10.10.34.35 -------------- 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 cvuljanic at gmail.com Fri Mar 30 15:00:21 2018 From: cvuljanic at gmail.com (Craig) Date: Fri, 30 Mar 2018 11:00:21 -0400 Subject: Network Services Forms/methods for tracking Message-ID: Could anyone that operates in a ISP or large enterprise that deals with many different customers/clients discuss some methods you handle network service requests. - Do you have/use an online form? - How is it tracked, IE a service request #, circuit ID, etc? - Can the customer look up the info to see if their request is completed? - Can engineers reference this info when issues arrise, and customers call in for support? - Pros/cons about the method you are using now? once the information is gathered how is it verified? (sometimes clients/customers don't know what they need....) and finally what information does the engineer receive to complete the build of the network service? does the engineer update the information when the network service is build out so its tracked? I am looking to get some feedback on some better ways to handle network requests, service providers would probably have good feedback on this that can facilitate collecting all the info needed, adding to the info once the build is completed and then having something that can be accessed when any t-shooting is required, and also if the service is to be decommissioned. Any feedback is appreciated; craig From bortzmeyer at nic.fr Fri Mar 30 15:04:14 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 30 Mar 2018 17:04:14 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20E43895-10AB-4119-ACB7-CC9A74DD9E6B@tardis.ed.ac.uk> References: <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> <20E43895-10AB-4119-ACB7-CC9A74DD9E6B@tardis.ed.ac.uk> Message-ID: <20180330150414.b3pc2u2vptztu2gg@nic.fr> On Fri, Mar 30, 2018 at 03:57:24PM +0100, William Waites wrote a message of 48 lines which said: > > 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | > > recursion-yes > > Well, that one's a little odd: I think that, for the government of this country, it is seen as a feature, not a bug. From math at sizone.org Fri Mar 30 15:22:08 2018 From: math at sizone.org (Ken Chase) Date: Fri, 30 Mar 2018 11:22:08 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <20180330152207.GB3734@sizone.org> On Fri, Mar 30, 2018 at 09:30:00AM -0400, Christopher Morrow said: >I think there's ample evidence that everyone's enemy is 'the nsa' (or other >nation-state-actors) isn't there? Or yourself, after you flip the EU off. https://www.theregister.co.uk/2018/03/29/eu_dumps_300000_ukowned_domains_into_brexit_bin/ Time to spoof x.x.x.x and x.x.y.y port 53 to keep your infra running. /kc -- Ken Chase - math at sizone.org Guelph Canada From morrowc.lists at gmail.com Fri Mar 30 15:55:04 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Mar 2018 11:55:04 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180330152207.GB3734@sizone.org> References: <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> <20180330152207.GB3734@sizone.org> Message-ID: On Fri, Mar 30, 2018 at 11:22 AM, Ken Chase wrote: > On Fri, Mar 30, 2018 at 09:30:00AM -0400, Christopher Morrow said: > >I think there's ample evidence that everyone's enemy is 'the nsa' (or > other > >nation-state-actors) isn't there? > > Or yourself, after you flip the EU off. > > https://www.theregister.co.uk/2018/03/29/eu_dumps_300000_ > ukowned_domains_into_brexit_bin/ > > > pretty hilarious the places brexit is having effects. From Mark_Feldman at comcast.com Fri Mar 30 16:38:07 2018 From: Mark_Feldman at comcast.com (Feldman, Mark) Date: Fri, 30 Mar 2018 16:38:07 +0000 Subject: xtube.com/ultradns/dynect zone issues Message-ID: If folks from xtube.com/ultradns/dynect are on the list, it appears that there’s a discrepancy in the xtube.com zone being served by the some auths. At least one of the CNAMEs required for resolution is missing from the zone being served by at least some ultra instances. No idea where the breakdown is, but we’ve got customers telling the world that we’re blocking access to porn. I’ll also note that the SOA ttl and ncache are on the large side, so we’re caching those NXDOMAINs for quite a while. Flushing is just playing whack-a-mole at the moment. Also, if folks from any large auths want to provide me with contact info, we’ll happily reach out to you privately/directly should something similar occur in the future . Mark Comcast TPX Core Network Services From Mark_Feldman at comcast.com Fri Mar 30 17:02:27 2018 From: Mark_Feldman at comcast.com (Feldman, Mark) Date: Fri, 30 Mar 2018 17:02:27 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: Another one for the list... We're working on fielding our quad-255 (255.255.255.255) DNS. It's currently pingable but not yet providing resolution. We're aiming for an April 1st release. One of the most widley-distributed quads out there. We're thinking about calling it QUAdFF -- drink it up. Mark On 3/30/18, 10:48 AM, "NANOG on behalf of Royce Williams" wrote: And FWIW, there are currently a few other other same-quad open resolvers: # IP - desc | CIDR | recursion-yes 1.1.1.1 - APNIC-LABS - Research prefix for APNIC Labs (now Cloudflare distributed public recursive DNS) | 1/8 | recursion-yes 8.8.8.8 - Google LLC (public recursive DNS) | 8.8.8/24 | recursion-yes 9.9.9.9 - Quad9 (public recursive DNS) | 9.9.9/24 | recursion-yes 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | recursion-yes 80.80.80.80 - Freenom DNS CLoud IP Space | 80.80.80/23 | recursion-yes 114.114.114.114 - NanJing XinFeng Information Technologies, Inc. | 114.114/16 | recursion-yes Full survey - with owners of the largest bit-boundary-aligned blocks that contain them - here: https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 Royce From cscora at apnic.net Fri Mar 30 18:03:19 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Mar 2018 04:03:19 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180330180319.6CFB1102FF@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, IRNOG 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 31 Mar, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 692170 Prefixes after maximum aggregation (per Origin AS): 267487 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 333579 Total ASes present in the Internet Routing Table: 60264 Prefixes per ASN: 11.49 Origin-only ASes present in the Internet Routing Table: 52065 Origin ASes announcing only one prefix: 22789 Transit ASes present in the Internet Routing Table: 8199 Transit-only ASes present in the Internet Routing Table: 262 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 44 Number of instances of unregistered ASNs: 44 Number of 32-bit ASNs allocated by the RIRs: 22003 Number of 32-bit ASNs visible in the Routing Table: 17722 Prefixes from 32-bit ASNs in the Routing Table: 73797 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 295 Number of addresses announced to Internet: 2857155394 Equivalent to 170 /8s, 76 /16s and 187 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 230623 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 189779 Total APNIC prefixes after maximum aggregation: 53876 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 188701 Unique aggregates announced from the APNIC address blocks: 77097 APNIC Region origin ASes present in the Internet Routing Table: 8739 APNIC Prefixes per ASN: 21.59 APNIC Region origin ASes announcing only one prefix: 2464 APNIC Region transit ASes present in the Internet Routing Table: 1287 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3665 Number of APNIC addresses announced to Internet: 767373154 Equivalent to 45 /8s, 189 /16s and 47 /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-137529 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: 206257 Total ARIN prefixes after maximum aggregation: 98744 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206949 Unique aggregates announced from the ARIN address blocks: 97769 ARIN Region origin ASes present in the Internet Routing Table: 18130 ARIN Prefixes per ASN: 11.41 ARIN Region origin ASes announcing only one prefix: 6709 ARIN Region transit ASes present in the Internet Routing Table: 1807 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2334 Number of ARIN addresses announced to Internet: 1104557184 Equivalent to 65 /8s, 214 /16s and 52 /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-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 188296 Total RIPE prefixes after maximum aggregation: 91199 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 184577 Unique aggregates announced from the RIPE address blocks: 110233 RIPE Region origin ASes present in the Internet Routing Table: 25023 RIPE Prefixes per ASN: 7.38 RIPE Region origin ASes announcing only one prefix: 11348 RIPE Region transit ASes present in the Internet Routing Table: 3489 Average RIPE Region AS path length visible: 4.2 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6824 Number of RIPE addresses announced to Internet: 715842688 Equivalent to 42 /8s, 170 /16s and 228 /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-207259 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: 89312 Total LACNIC prefixes after maximum aggregation: 19652 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 90700 Unique aggregates announced from the LACNIC address blocks: 40695 LACNIC Region origin ASes present in the Internet Routing Table: 6968 LACNIC Prefixes per ASN: 13.02 LACNIC Region origin ASes announcing only one prefix: 1898 LACNIC Region transit ASes present in the Internet Routing Table: 1294 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4499 Number of LACNIC addresses announced to Internet: 172487904 Equivalent to 10 /8s, 71 /16s and 244 /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: 18480 Total AfriNIC prefixes after maximum aggregation: 3976 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 20948 Unique aggregates announced from the AfriNIC address blocks: 7549 AfriNIC Region origin ASes present in the Internet Routing Table: 1117 AfriNIC Prefixes per ASN: 18.75 AfriNIC Region origin ASes announcing only one prefix: 369 AfriNIC Region transit ASes present in the Internet Routing Table: 228 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 400 Number of AfriNIC addresses announced to Internet: 96509184 Equivalent to 5 /8s, 192 /16s and 157 /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 5416 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3709 410 426 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2849 11131 780 KIXS-AS-KR Korea Telecom, KR 9829 2808 1499 542 BSNL-NIB National Internet Backbone, IN 7552 2674 1158 62 VIETEL-AS-AP Viettel Group, VN 9394 2638 4923 29 CTTNET China TieTong Telecommunications 45899 2546 1569 165 VNPT-AS-VN VNPT Corp, VN 17974 2315 930 80 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2164 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2086 417 216 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 3375 1323 86 SHAW - Shaw Communications Inc., CA 22773 3290 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2092 2484 447 CHARTER-NET-HKY-NC - Charter Communicat 16509 2019 4372 670 AMAZON-02 - Amazon.com, Inc., US 30036 1947 341 181 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1920 5070 606 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 11492 1778 228 556 CABLEONE - CABLE ONE, INC., US 7018 1701 20189 1254 ATT-INTERNET4 - AT&T Services, Inc., US 16625 1695 825 1213 AKAMAI-AS - Akamai Technologies, Inc., Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 3974 1504 540 UNI2-AS, ES 39891 3522 203 20 ALJAWWALSTC-AS, SA 20940 2751 778 2008 AKAMAI-ASN1, US 8551 2093 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2039 1859 706 ROSTELECOM-AS, RU 34984 2020 334 481 TELLCOM-AS, TR 9121 1953 1692 19 TTNET, TR 13188 1606 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1228 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 4325 3385 575 Uninet S.A. de C.V., MX 10620 3599 540 261 Telmex Colombia S.A., CO 11830 2639 369 85 Instituto Costarricense de Electricidad 6503 1629 437 53 Axtel, S.A.B. de C.V., MX 7303 1508 1022 191 Telecom Argentina S.A., AR 28573 1033 2253 175 CLARO S.A., BR 6147 1010 377 27 Telefonica del Peru S.A.A., PE 3816 1006 506 120 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 928 126 84 Alestra, S. de R.L. de C.V., MX 18881 908 1074 29 TELEF�NICA BRASIL S.A, BR 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 1150 397 49 LINKdotNET-AS, EG 37611 821 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 707 1396 40 ETISALAT-MISR, EG 24835 637 850 15 RAYA-AS, EG 8452 625 1730 18 TE-AS TE-AS, EG 29571 466 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 376 81 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5416 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4325 3385 575 Uninet S.A. de C.V., MX 12479 3974 1504 540 UNI2-AS, ES 7545 3709 410 426 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3599 540 261 Telmex Colombia S.A., CO 39891 3522 203 20 ALJAWWALSTC-AS, SA 6327 3375 1323 86 SHAW - Shaw Communications Inc., CA 22773 3290 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2849 11131 780 KIXS-AS-KR Korea Telecom, KR 9829 2808 1499 542 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4325 3750 Uninet S.A. de C.V., MX 39891 3522 3502 ALJAWWALSTC-AS, SA 12479 3974 3434 UNI2-AS, ES 10620 3599 3338 Telmex Colombia S.A., CO 6327 3375 3289 SHAW - Shaw Communications Inc., CA 7545 3709 3283 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3290 3140 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2674 2612 VIETEL-AS-AP Viettel Group, VN 9394 2638 2609 CTTNET China TieTong Telecommunications Corpora 11830 2639 2554 Instituto Costarricense de Electricidad y Telec 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 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 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.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:288 /13:563 /14:1096 /15:1903 /16:13368 /17:7800 /18:13616 /19:25164 /20:39207 /21:45113 /22:85887 /23:69263 /24:386496 /25:844 /26:604 /27:664 /28:35 /29:20 /30:17 /31:4 /32:56 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3166 3375 SHAW - Shaw Communications Inc., CA 39891 2946 3522 ALJAWWALSTC-AS, SA 12479 2721 3974 UNI2-AS, ES 22773 2543 3290 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1987 2639 Instituto Costarricense de Electricidad y Telec 30036 1698 1947 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1603 3599 Telmex Colombia S.A., CO 8551 1556 2093 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1549 1778 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1579 2:823 4:19 5:2817 6:59 7:1 8:1118 9:1 12:1880 13:182 14:1733 15:29 16:3 17:197 18:68 20:47 21:4 23:2588 24:2153 25:2 27:2260 31:1970 32:89 35:26 36:501 37:2748 38:1446 39:251 40:119 41:3018 42:602 43:1958 44:100 45:4030 46:3049 47:203 49:1345 50:1052 51:49 52:998 54:370 55:5 56:12 57:42 58:1536 59:1008 60:428 61:2133 62:1812 63:1802 64:4736 65:2218 66:4584 67:2354 68:1148 69:3200 70:1144 71:559 72:2112 74:2717 75:411 76:425 77:1550 78:1693 79:1883 80:1485 81:1424 82:1080 83:783 84:1023 85:2079 86:589 87:1310 88:928 89:2324 90:201 91:6309 92:1176 93:2379 94:2400 95:2749 96:657 97:356 98:932 99:133 100:80 101:1430 102:40 103:17431 104:3306 105:225 106:644 107:1792 108:708 109:2701 110:1580 111:1780 112:1314 113:1340 114:1119 115:1635 116:1648 117:1713 118:2163 119:1672 120:958 121:1053 122:2463 123:1800 124:1450 125:1900 128:986 129:637 130:448 131:1592 132:670 133:196 134:1005 135:227 136:451 137:499 138:1950 139:578 140:424 141:688 142:795 143:963 144:798 145:456 146:1168 147:756 148:1566 149:720 150:722 151:1057 152:760 153:311 154:1012 155:764 156:855 157:786 158:625 159:1652 160:929 161:732 162:2581 163:528 164:1035 165:1402 166:419 167:1402 168:3043 169:815 170:3716 171:428 172:1074 173:1960 174:883 175:767 176:1870 177:3969 178:2421 179:1198 180:2244 181:2197 182:2454 183:1139 184:918 185:13114 186:3587 187:2354 188:2767 189:2009 190:8136 191:1443 192:9830 193:5865 194:4787 195:3934 196:2476 197:1405 198:5505 199:5895 200:7439 201:5007 202:10424 203:10124 204:4520 205:2843 206:3073 207:3196 208:3977 209:3934 210:4031 211:2112 212:3018 213:2739 214:907 215:60 216:5851 217:2117 218:899 219:621 220:1722 221:999 222:1041 223:1233 End of report From math at sizone.org Fri Mar 30 18:27:47 2018 From: math at sizone.org (Ken Chase) Date: Fri, 30 Mar 2018 14:27:47 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <20180330182747.GF3734@sizone.org> uh, quad the f do you think you're doing?! you think anything.255 is routable by COTS gear? :) maybe everyone who operates x.y/16 should be setting up their open resolvers on x.y.x.y (can i get an rfc up in the hizzy? apr 1 is rsn.) /kc On Fri, Mar 30, 2018 at 05:02:27PM +0000, Feldman, Mark said: >Another one for the list... We're working on fielding our quad-255 (255.255.255.255) DNS. It's currently pingable but not yet providing resolution. We're aiming for an April 1st release. One of the most widley-distributed quads out there. We're thinking about calling it QUAdFF -- drink it up. > > Mark -- Ken Chase - math at sizone.org Guelph Canada From valdis.kletnieks at vt.edu Fri Mar 30 18:45:30 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 30 Mar 2018 14:45:30 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180330182747.GF3734@sizone.org> References: <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> <20180330182747.GF3734@sizone.org> Message-ID: <38990.1522435530@turing-police.cc.vt.edu> On Fri, 30 Mar 2018 14:27:47 -0400, Ken Chase said: > uh, quad the f do you think you're doing?! > > you think anything.255 is routable by COTS gear? :) Obviously posted 48 hours early. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mlm at pixelgate.net Fri Mar 30 19:09:57 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 30 Mar 2018 12:09:57 -0700 (PDT) Subject: Yet another Quadruple DNS? In-Reply-To: <35e4b93e-ca01-0f6c-81fc-b19778ad66e3@rollernet.us> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329142441.svo3qphnieukmljx@sources.org> <35e4b93e-ca01-0f6c-81fc-b19778ad66e3@rollernet.us> Message-ID: On Thu, 29 Mar 2018, Seth Mattinen wrote: >I'm lazy and have been using 9.9.9.9 at home. nameserver 1.1 /mark From nanog at ics-il.net Fri Mar 30 19:12:04 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 30 Mar 2018 14:12:04 -0500 (CDT) Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: <266806114.4782.1522437120301.JavaMail.mhammett@ThunderFuck> I doubt most people could care less. If they should or not is not a discussion I'm willing to have. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Christopher Morrow" To: "Stephane Bortzmeyer" Cc: "nanog list" Sent: Friday, March 30, 2018 8:30:00 AM Subject: Re: Yet another Quadruple DNS? On Thu, Mar 29, 2018 at 10:32 AM, Stephane Bortzmeyer wrote: > > Public DNS resolvers still help against "ordinary" adversaries. (If > your ennemy is the NSA, you have other problems, anyway.) > I think there's ample evidence that everyone's enemy is 'the nsa' (or other nation-state-actors) isn't there? From surfer at mauigateway.com Fri Mar 30 20:04:05 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 30 Mar 2018 13:04:05 -0700 Subject: Yet another Quadruple DNS? Message-ID: <20180330130405.49AF35C5@m0117458.ppops.net> > Public DNS resolvers still help against "ordinary" > adversaries. (If your ennemy is the NSA, you have > other problems, anyway.) : I think there's ample evidence that everyone's enemy : is 'the nsa' (or other nation-state-actors) isn't : there? --- nanog at ics-il.net wrote: ------------- From: Mike Hammett :: I doubt most people could care less. ------------------------------------------- You have to wait, it's not april 1st yet! >8-\ scott From jjn at nuge.com Fri Mar 30 19:46:19 2018 From: jjn at nuge.com (Jay Nugent) Date: Fri, 30 Mar 2018 15:46:19 -0400 (EDT) Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <46243EB2-A1C3-42AD-9FFA-9AEA359D2643@gmail.com> <20180329112723.mc2sspxmbnkjlfrl@sources.org> <20180329114630.mxqry552ymufsqku@sources.org> <20180329130758.GA58417@piranha.2bit.co> <20180329T131245Z@localhost> <20180329140159.GA72866@meow.BKantor.net> <20180329140838.GA27469@cmadams.net> <20180329143218.3mzxldp7k2bfky3l@sources.org> Message-ID: Greetings, On Fri, 30 Mar 2018, Feldman, Mark wrote: > Another one for the list... We're working on fielding our quad-255 > (255.255.255.255) DNS. It's currently pingable but not yet providing > resolution. We're aiming for an April 1st release. One of the most > widley-distributed quads out there. We're thinking about calling it > QUAdFF -- drink it up. And serves as a combined DNS and DHCP server, too!!! --- Jay Nugent o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6. From mangawilly at gmail.com Sat Mar 31 11:58:52 2018 From: mangawilly at gmail.com (Willy MANGA) Date: Sat, 31 Mar 2018 12:58:52 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: Message-ID: Hi, Le 30/03/2018 à 13:00, nanog-request at nanog.org a écrit : > >Date: Thu, 29 Mar 2018 09:13:06 -0400 >From: Doug Clements > >>From https://1.1.1.1/: >For IPv6: *2001:2001::* and/or *2001:2001:2001::* No, it's 1dot1dot1dot1.cloudflare-dns.com (2606:4700:4700::1001 and 2606:4700:4700::1111 ) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mehmet at akcin.net Sat Mar 31 21:18:05 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 31 Mar 2018 21:18:05 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: Joining the party late. Very disappointing to see a popular prefix being allocated/reseved for research then being allocated to a company without public consultation. I am sure APNIC community will ask APNIC Sr. management for an explanation. This prefix , if it will be given to any business , should go thru a transparent bidding process OR regular APNIC allocation process transprently. Geoff? Paul? Any chance you can give insight? On Wed, Mar 28, 2018 at 1:04 PM Payam Poursaied wrote: > dig google.com @1.1.1.1 > > > > Cloudflare? > > Didn't find any news around it > > From rafalfitt at gmail.com Fri Mar 30 12:28:41 2018 From: rafalfitt at gmail.com (=?UTF-8?Q?Rafa=C5=82_Fitt?=) Date: Fri, 30 Mar 2018 14:28:41 +0200 Subject: new diffserv code point LE PHB In-Reply-To: <20180330113007.GA1193@hanna.meerval.net> References: <20180330113007.GA1193@hanna.meerval.net> Message-ID: Dear Job, > In cases where you have both 'normal' and 'bulk' content on the same webserver, are there any webservers that allow you to set a DSCP value per path or filename? please check http://techgenix.com/qos-windows-server-2012-part3/ You can assign DSCP per (outgoing) URL on Windows Server 2012 (and later). -- regards, Rafał Fitt From derrix at gmail.com Fri Mar 30 23:25:51 2018 From: derrix at gmail.com (Derrick Malilay) Date: Fri, 30 Mar 2018 16:25:51 -0700 Subject: Comcast engineer assistance Message-ID: Can a Comcast engineer please contact me off-list. derrix at gmail.com We are seeing some unusual behavior with one prefix that looks like it's stopping in the Comcast network. Thanks! Derrick