From job at ntt.net Sat Jul 1 15:02:26 2017 From: job at ntt.net (Job Snijders) Date: Sat, 1 Jul 2017 17:02:26 +0200 Subject: RFC 8195 "Use of Large Communities" Message-ID: <20170701150226.bx5d3sxomavxguns@Vurt.local> Dear all, RFC 8195 "Use of BGP Large Communities" was just now published: https://tools.ietf.org/html/rfc8195 RFC 8195 presents examples and inspiration for the operational application of Large Communities. The document suggests logical categories of Large Communities and demonstrates an orderly manner of organizing community values within those categories to achieve typical goals in routing policy. Any network or route server operator can consider using the concepts presented as the basis for their own Large Communities repertoire. RFC 8195 is meant as a companion document in the same way that RFC 1998 provided a concrete real-world application for RFC1997 BGP Communities. The RFC draws on the experience of operator communities such as NANOG and NLNOG. A ton of open source implementations [1] with Large support are already available. And with more traditional vendors like IOS XR, Junos, Arista & Nokia having releases around the corner, I hope this will be useful when planning your Large Communities deployment later this year. Kind regards, Job [1]: http://largebgpcommunities.net/implementations/ From jcurran at arin.net Sun Jul 2 17:28:34 2017 From: jcurran at arin.net (John Curran) Date: Sun, 2 Jul 2017 17:28:34 +0000 Subject: IPv4 Hijacking For Idiots In-Reply-To: <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> Message-ID: On 6 Jun 2017, at 9:25 PM, Bryan Fields wrote: > > On 6/6/17 9:13 PM, Mark Andrews wrote: >> Getting to that stage requires several companies to simultaneously >> say "we will no longer accept as valid mechanisms to verify >> routes announcements. You need to use X or else we won't accept >> the announcement". Yes, this requires guts to do. > > And what of legacy address holders? ARIN will not permit RPKI use of their > blocks. Note that ARIN does provide RPKI services for legacy blocks, but it is true that we require more legalisms than other RIRs… You can caulk this up to the abundance of legacy resources of questionable provenance in this region, to the colorful US legal environment, and/or to a desire not to endanger the services we’re already providing to thousands of customers. (Interestingly enough, parties in the other regions agree to very similar terms and conditions when they use the respective RPKI services, only the binding is implicit and thus somewhat unseen to the user… ) Thanks! /John John Curran President and CEO ARIN From Bryan at bryanfields.net Sun Jul 2 18:22:43 2017 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 2 Jul 2017 14:22:43 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> Message-ID: <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> On 7/2/17 1:28 PM, John Curran wrote: > Note that ARIN does provide RPKI services for legacy blocks, but it is true that we > require more legalisms than other RIRs… You can caulk this up to the abundance > of legacy resources of questionable provenance in this region, to the colorful US > legal environment, and/or to a desire not to endanger the services we’re already > providing to thousands of customers. Only if you sign the RSA and give up certain legal rights to your legacy blocks/property. I can't speak for everyone, but those I do know are not willing to do this. I'd propose there must be a better way that doesn't require legacy holders sign the RSA. RPKI is important enough that something should be possible. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From ggiesen+nanog at giesen.me Mon Jul 3 12:36:45 2017 From: ggiesen+nanog at giesen.me (=?utf-8?q?Gary_T=2E_Giesen?=) Date: Mon, 03 Jul 2017 08:36:45 -0400 Subject: =?utf-8?q?Re=3A?= Transit Providers in =?utf-8?q?Bracknell=2C?= UK In-Reply-To: Message-ID: <61d4-595a3a80-3-61901300@70328327> Thanks all for the on- and off-list suggestions. I've joined the UKNOF list and will seriously look at Vodafone (former C&W). Cheers, GTG On Sunday, July 02, 2017 13:58 EDT, Stuart Howlette wrote:  I don't know personally, but have you tried asking on the UKNOF mailing list? Regards, Stuart Howlette stuart at stuarthowlette.me.uk  On Fri, Jun 30, 2017 at 11:31 pm, Gary T. Giesen via NANOG wrote:Can anyone recommend a transit provider in Bracknell, UK? Not too picky on requirements, but IPv6 is a must;  RTBH and good peering are a very good to have. We're looking to replace one of our current providers (Virgin Media - AS5089). I have no problem naming them as they treat prefix list updates like service changes (and charge £250 for the privilege). We gave in and paid it and and 2 weeks later they have still not processed the change. Cheers, GTG   From simon at slimey.org Mon Jul 3 13:15:14 2017 From: simon at slimey.org (Simon Lockhart) Date: Mon, 3 Jul 2017 14:15:14 +0100 Subject: Transit Providers in Bracknell, UK In-Reply-To: <61d4-595a3a80-3-61901300@70328327> References: <61d4-595a3a80-3-61901300@70328327> Message-ID: <20170703131513.GU15390@dilbert.slimey.org> On Mon Jul 03, 2017 at 08:36:45AM -0400, Gary T. Giesen via NANOG wrote: > Thanks all for the on- and off-list suggestions. I've joined the UKNOF list > and will seriously look at Vodafone (former C&W). You could also look at A&A - www.aaisp.net.uk - very clueful and based in Bracknell. Simon From randy at psg.com Mon Jul 3 14:18:14 2017 From: randy at psg.com (Randy Bush) Date: Mon, 03 Jul 2017 16:18:14 +0200 Subject: IPv4 Hijacking For Idiots In-Reply-To: <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> Message-ID: > Only if you sign the RSA and give up certain legal rights to your legacy > blocks/property. the word 'certain' is not apt given that the LRSA Ts&Cs may be arbitrarily changed by ARIN From stuart at stuarthowlette.me.uk Sun Jul 2 17:58:19 2017 From: stuart at stuarthowlette.me.uk (Stuart Howlette) Date: Sun, 02 Jul 2017 13:58:19 -0400 Subject: Transit Providers in Bracknell, UK In-Reply-To: <7d4f-5956d100-1-6ff39000@94221956> References: <7d4f-5956d100-1-6ff39000@94221956> Message-ID: I don't know personally, but have you tried asking on the UKNOF mailing list? Regards, Stuart Howlette stuart at stuarthowlette.me.uk On Fri, Jun 30, 2017 at 11:31 pm, Gary T. Giesen via NANOG wrote: > Can anyone recommend a transit provider in Bracknell, UK? Not too picky on requirements, but IPv6 is a must; RTBH and good peering are a very good to have. We're looking to replace one of our current providers (Virgin Media - AS5089). I have no problem naming them as they treat prefix list updates like service changes (and charge £250 for the privilege). We gave in and paid it and and 2 weeks later they have still not processed the change. Cheers, GTG From jcurran at istaff.org Mon Jul 3 17:23:56 2017 From: jcurran at istaff.org (John Curran) Date: Mon, 3 Jul 2017 13:23:56 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> Message-ID: On 2 Jul 2017, at 2:22 PM, Bryan Fields wrote: > > On 7/2/17 1:28 PM, John Curran wrote: >> Note that ARIN does provide RPKI services for legacy blocks, but it is true that we >> require more legalisms than other RIRs… You can caulk this up to the abundance >> of legacy resources of questionable provenance in this region, to the colorful US >> legal environment, and/or to a desire not to endanger the services we’re already >> providing to thousands of customers. > > Only if you sign the RSA and give up certain legal rights to your legacy > blocks/property. I can't speak for everyone, but those I do know are not > willing to do this. And they may choose to do so. Others have no problem signing the LRSA/RSA (which are effectively the same T&C’s now aside from fee schedule), and like having a very clear statement of their rights to the number resources, such as right to transfer, access to arbitration, etc. (These rights weren’t well spelt out in the earlier versions of the LRSA or RSA, but we eventually got their in the current form.) Of course, the other little detail isn’t whether they’re willing to sign, it is whether they are entitled to sign, since the only parties that can enter an LRSA is the recipient or their legal successor to the rights. (It can be amusing when recently created entities attempt to explain why they are the legal rights holder to a legacy number block…) > I'd propose there must be a better way that doesn't require legacy holders > sign the RSA. RPKI is important enough that something should be possible. RPKI is quite important, but it also requires a solid legal foundation – Resource certification absent the proper legal details as to who has the rights and what rights that they have) is likely worse than no RPKI at all. Thanks, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Jul 3 17:29:14 2017 From: jcurran at arin.net (John Curran) Date: Mon, 3 Jul 2017 17:29:14 +0000 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> <7f6264e8-6385-dcc7-f70c-ef540b2f5ea2@bryanfields.net> Message-ID: On 3 Jul 2017, at 10:18 AM, Randy Bush > wrote: Only if you sign the RSA and give up certain legal rights to your legacy blocks/property. the word 'certain' is not apt given that the LRSA Ts&Cs may be arbitrarily changed by ARIN Randy - Not quite arbitrarily - ARIN can change it because of a change in the applicable caselaw, but otherwise RSA changes happen only with the consent of the Members - "(e) ARIN may only modify the terms of this Agreement under the following circumstances: (1) The Board finds an immediate and compelling need to amend the Agreement due to a definable, discrete, identifiable change in relevant statute or caselaw; or (2) Upon recommendation of the Board and ratification by Member vote.” (Yes, this is one the changes that rolled out with the most recent RSA/LRSA, so you might not have been aware of same.) Thanks! /John John Curran President and CEO ARIN From job at instituut.net Mon Jul 3 19:07:28 2017 From: job at instituut.net (Job Snijders) Date: Mon, 03 Jul 2017 19:07:28 +0000 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? Message-ID: Dear NANOG, Some friends of mine are operating a nonprofit (on shoe string) and looking to connect some CDN caches to an IX fabric. A BGP speaking device is needed between the caches and the BGP peers connected to the fabric. The BGP speaker is needed to present the peers on the IX with a unified view of the assemblage of CDN nodes. I was wondering whether anyone was experience with the "EdgeRouter Infinity XG" device, specifically in the role of a simple peering router for a couple of tens of thousands of routes. (I'd point default to the left and take just the on-net routes on the right to reduce the table size requirement). I hope the device can do at least 2xLACP trunks, has a sizable FIB, is automatable (supports idempotency), can forward IMIX at line-rate, *flow, and exposes some telemetry via SNMP. Any note sharing would be appreciated! Kind regards, Job From benno at NLnetLabs.nl Mon Jul 3 20:11:13 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 3 Jul 2017 22:11:13 +0200 Subject: Call for presentations RIPE 75 and DCTM info Message-ID: <9c180e25-5f3e-903e-a57d-c66cadbe7b88@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 75 below or at: https://ripe75.ripe.net/submit-topic/cfp/. The deadline for submissions is *20 August 2017*. Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.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 75 will take place from 22-26 October in Dubai, UAE. 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 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. 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 Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions 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 - 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://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.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 [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From nanog at ics-il.net Mon Jul 3 22:38:40 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 3 Jul 2017 17:38:40 -0500 (CDT) Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: <166881427.466.1499121517644.JavaMail.mhammett@ThunderFuck> I'm Ubiquiti's biggest critic. I'll check with my colleagues. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" To: nanog at nanog.org Sent: Monday, July 3, 2017 2:07:28 PM Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? Dear NANOG, Some friends of mine are operating a nonprofit (on shoe string) and looking to connect some CDN caches to an IX fabric. A BGP speaking device is needed between the caches and the BGP peers connected to the fabric. The BGP speaker is needed to present the peers on the IX with a unified view of the assemblage of CDN nodes. I was wondering whether anyone was experience with the "EdgeRouter Infinity XG" device, specifically in the role of a simple peering router for a couple of tens of thousands of routes. (I'd point default to the left and take just the on-net routes on the right to reduce the table size requirement). I hope the device can do at least 2xLACP trunks, has a sizable FIB, is automatable (supports idempotency), can forward IMIX at line-rate, *flow, and exposes some telemetry via SNMP. Any note sharing would be appreciated! Kind regards, Job From sethm at rollernet.us Mon Jul 3 22:44:22 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 3 Jul 2017 15:44:22 -0700 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: <44023ecd-2812-e8c0-126e-f89da5edce78@rollernet.us> On 7/3/17 12:07 PM, Job Snijders wrote: > I was wondering whether anyone was experience with the "EdgeRouter Infinity > XG" device, specifically in the role of a simple peering router for a > couple of tens of thousands of routes. (I'd point default to the left and > take just the on-net routes on the right to reduce the table size > requirement). EdgeRouter is... meh. If I was looking at that class of gear I'd go with a Mikrotik. ~Seth From jhaustin at gmail.com Mon Jul 3 23:10:31 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Mon, 3 Jul 2017 15:10:31 -0800 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: <44023ecd-2812-e8c0-126e-f89da5edce78@rollernet.us> References: <44023ecd-2812-e8c0-126e-f89da5edce78@rollernet.us> Message-ID: On Mon, Jul 3, 2017 at 2:44 PM, Seth Mattinen wrote: > > EdgeRouter is... meh. If I was looking at that class of gear I'd go with a > Mikrotik. Job, There is a bit of a price differential here, depending on whether you need SFP+; the Infinity is "dead cheap", and has fairly opaque BGP daemon+debugging tools. Also still technically a beta product. Not sure if it meets your automation requirements. I wouldn't want to be deploying them in a redundant pair, myself, but just when you say something can't be done… Mikrotik's CCR1072: 10-gig router (shipping, not anything that's just been announced) has an API, can certainly handle a few tens of thousands of routes fine (single core BGP though), but I can't vouch for its ability to do IMIX or *flow at line rate. This has probably been stress tested by somebody. I doubt the sampling is in hardware. If you don't need 10G ports then your options expand considerably. Do you have a target throughput? -- Jeremy Austin (907) 895-2311 office (907) 803-5422 cell jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC From josh at kyneticwifi.com Tue Jul 4 00:26:17 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 3 Jul 2017 19:26:17 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: - Josh On Jul 3, 2017 7:23 PM, "Josh Reynolds" wrote: > Specs... > > > - MIPS64 16 Core 1.8 GHz > - 16 GB DDR4 RAM > - 8 MB NOR Flash 4 GB eMMC NAND Flash > - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit > Ethernet Port > - 2 hotswap power supplies > > > No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not > done in hardware - this may eventually change. As far as the other stuff, > "telemetry" etc - no. > > As far as BGP crunching, plenty of routes, etc - it would easily and > happily be fine with that. > > As far as automation, it's a JunOS-like CLI originally based on vyatta, > which AT&T now owns - and one of the main reasons is it's scriptability, > use of Ansible and other tools right on the device, python, etc. > > - Josh > > On Jul 3, 2017 2:09 PM, "Job Snijders" wrote: > >> Dear NANOG, >> >> Some friends of mine are operating a nonprofit (on shoe string) and >> looking >> to connect some CDN caches to an IX fabric. A BGP speaking device is >> needed >> between the caches and the BGP peers connected to the fabric. The BGP >> speaker is needed to present the peers on the IX with a unified view of >> the >> assemblage of CDN nodes. >> >> I was wondering whether anyone was experience with the "EdgeRouter >> Infinity >> XG" device, specifically in the role of a simple peering router for a >> couple of tens of thousands of routes. (I'd point default to the left and >> take just the on-net routes on the right to reduce the table size >> requirement). >> >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >> and exposes some telemetry via SNMP. >> >> Any note sharing would be appreciated! >> >> Kind regards, >> >> Job >> > From hugo at slabnet.com Tue Jul 4 02:28:30 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 3 Jul 2017 19:28:30 -0700 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: <20170704022830.GE7539@bamboo.slabnet.com> On Mon 2017-Jul-03 19:26:17 -0500, Josh Reynolds wrote: >On Jul 3, 2017 7:23 PM, "Josh Reynolds" wrote: > >> Specs... >> >> >> - MIPS64 16 Core 1.8 GHz >> - 16 GB DDR4 RAM >> - 8 MB NOR Flash 4 GB eMMC NAND Flash >> - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit >> Ethernet Port >> - 2 hotswap power supplies >> >> >> No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not >> done in hardware - this may eventually change. As far as the other stuff, >> "telemetry" etc - no. >> >> As far as BGP crunching, plenty of routes, etc - it would easily and >> happily be fine with that. >> >> As far as automation, it's a JunOS-like CLI originally based on vyatta, >> which AT&T now owns - and one of the main reasons is it's scriptability, >> use of Ansible and other tools right on the device, python, etc. Technically I believe it's based on VyOS rather than Vyatta. Same base, but just delineating that VyOS is open source and I don't believe AT&T wields any control over it. >> >> - Josh >> -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal >> On Jul 3, 2017 2:09 PM, "Job Snijders" wrote: >> >>> Dear NANOG, >>> >>> Some friends of mine are operating a nonprofit (on shoe string) and >>> looking >>> to connect some CDN caches to an IX fabric. A BGP speaking device is >>> needed >>> between the caches and the BGP peers connected to the fabric. The BGP >>> speaker is needed to present the peers on the IX with a unified view of >>> the >>> assemblage of CDN nodes. >>> >>> I was wondering whether anyone was experience with the "EdgeRouter >>> Infinity >>> XG" device, specifically in the role of a simple peering router for a >>> couple of tens of thousands of routes. (I'd point default to the left and >>> take just the on-net routes on the right to reduce the table size >>> requirement). >>> >>> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >>> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >>> and exposes some telemetry via SNMP. >>> >>> Any note sharing would be appreciated! >>> >>> Kind regards, >>> >>> Job >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From josh at kyneticwifi.com Tue Jul 4 02:47:35 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 3 Jul 2017 21:47:35 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: <20170704022830.GE7539@bamboo.slabnet.com> References: <20170704022830.GE7539@bamboo.slabnet.com> Message-ID: EdgeOS was forked and employees were poached from Vyatta before it was purchased by Broadcom, when it was open source. I think a few things came down from VyOS after that, but not many. On Mon, Jul 3, 2017 at 9:28 PM, Hugo Slabbert wrote: > > On Mon 2017-Jul-03 19:26:17 -0500, Josh Reynolds > wrote: > >> On Jul 3, 2017 7:23 PM, "Josh Reynolds" wrote: >> >>> Specs... >>> >>> >>> - MIPS64 16 Core 1.8 GHz >>> - 16 GB DDR4 RAM >>> - 8 MB NOR Flash 4 GB eMMC NAND Flash >>> - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit >>> Ethernet Port >>> - 2 hotswap power supplies >>> >>> >>> No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not >>> done in hardware - this may eventually change. As far as the other stuff, >>> "telemetry" etc - no. >>> >>> As far as BGP crunching, plenty of routes, etc - it would easily and >>> happily be fine with that. >>> >>> As far as automation, it's a JunOS-like CLI originally based on vyatta, >>> which AT&T now owns - and one of the main reasons is it's scriptability, >>> use of Ansible and other tools right on the device, python, etc. > > > Technically I believe it's based on VyOS rather than Vyatta. Same base, but > just delineating that VyOS is open source and I don't believe AT&T wields > any control over it. > >>> >>> - Josh >>> > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > >>> On Jul 3, 2017 2:09 PM, "Job Snijders" wrote: >>> >>>> Dear NANOG, >>>> >>>> Some friends of mine are operating a nonprofit (on shoe string) and >>>> looking >>>> to connect some CDN caches to an IX fabric. A BGP speaking device is >>>> needed >>>> between the caches and the BGP peers connected to the fabric. The BGP >>>> speaker is needed to present the peers on the IX with a unified view of >>>> the >>>> assemblage of CDN nodes. >>>> >>>> I was wondering whether anyone was experience with the "EdgeRouter >>>> Infinity >>>> XG" device, specifically in the role of a simple peering router for a >>>> couple of tens of thousands of routes. (I'd point default to the left >>>> and >>>> take just the on-net routes on the right to reduce the table size >>>> requirement). >>>> >>>> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >>>> automatable (supports idempotency), can forward IMIX at line-rate, >>>> *flow, >>>> and exposes some telemetry via SNMP. >>>> >>>> Any note sharing would be appreciated! >>>> >>>> Kind regards, >>>> >>>> Job >>>> >>> > From baldur.norddahl at gmail.com Tue Jul 4 03:21:59 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 4 Jul 2017 05:21:59 +0200 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: Why not use a Linux or BSD computer for this? It is cheap and you know exactly what you are getting. It will forward 10 gig at line rate at least for normal traffic. Regards Baldur Den 3. jul. 2017 21.08 skrev "Job Snijders" : > Dear NANOG, > > Some friends of mine are operating a nonprofit (on shoe string) and looking > to connect some CDN caches to an IX fabric. A BGP speaking device is needed > between the caches and the BGP peers connected to the fabric. The BGP > speaker is needed to present the peers on the IX with a unified view of the > assemblage of CDN nodes. > > I was wondering whether anyone was experience with the "EdgeRouter Infinity > XG" device, specifically in the role of a simple peering router for a > couple of tens of thousands of routes. (I'd point default to the left and > take just the on-net routes on the right to reduce the table size > requirement). > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > and exposes some telemetry via SNMP. > > Any note sharing would be appreciated! > > Kind regards, > > Job > From josh at kyneticwifi.com Tue Jul 4 03:28:07 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 3 Jul 2017 22:28:07 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: I kinda feel the same way. I wish FRR was a big more mature at this point though. On Mon, Jul 3, 2017 at 10:21 PM, Baldur Norddahl wrote: > Why not use a Linux or BSD computer for this? It is cheap and you know > exactly what you are getting. It will forward 10 gig at line rate at least > for normal traffic. > > Regards > > Baldur > > Den 3. jul. 2017 21.08 skrev "Job Snijders" : > >> Dear NANOG, >> >> Some friends of mine are operating a nonprofit (on shoe string) and looking >> to connect some CDN caches to an IX fabric. A BGP speaking device is needed >> between the caches and the BGP peers connected to the fabric. The BGP >> speaker is needed to present the peers on the IX with a unified view of the >> assemblage of CDN nodes. >> >> I was wondering whether anyone was experience with the "EdgeRouter Infinity >> XG" device, specifically in the role of a simple peering router for a >> couple of tens of thousands of routes. (I'd point default to the left and >> take just the on-net routes on the right to reduce the table size >> requirement). >> >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >> and exposes some telemetry via SNMP. >> >> Any note sharing would be appreciated! >> >> Kind regards, >> >> Job >> From arnold at nipper.de Wed Jul 5 12:39:02 2017 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 5 Jul 2017 14:39:02 +0200 Subject: Call for presentations EPF12, 18th - 20th September, Lisbon sent to NANOG In-Reply-To: References: Message-ID: Dear all Just a quick reminder that we still have some presentation slots available. Have a nice summer and see you in Lisbon Arnold On 10.04.2017 10:21, Arnold Nipper wrote: > Dear all, > > AMS-IX, DE-CIX, LINX, Netnod are happy to host the 12th European > Peering Forum (EPF) in Lisbon, Portugal from the 18th - 20st September > 2017. The event will welcome up to 300 peering managers and > coordinators from networks connected to the host Internet exchanges. > Besides an interesting topical agenda, the three-day event > accommodates room for attendees to meet on a one-to-one basis to > discuss bilateral peering business opportunities. > > The programme committee will be looking for presentations and > lightning talks related to peering and technical topics of > interconnection. Your presentation should address > > * Interconnection Automation > * Regional Peering > * Interconnection and Peering Internet Governance and Regulatory TopicS > * Economic and Product Trends > * Peering/Interconnection Strategy > * Interesting findings about peering > * 100GE and beyond > > > Submissions > =========== > > Presentations must be of a non-commercial nature. Product or > marketing heavy talks are strongly discouraged. > > Submissions of presentations should be made to the programme > committee . Please include: > > * Author's name and e-mail > * Presentation title > * Abstract > * Slides (if available) > * Time requested > > > Deadlines > ========= > > Presentation Abstract Deadline 17/07/2017 12:00 UTC > Final Selection of Speakers 28/07/2017 > Presentation Slides Submission Deadline 04/09/2017 12:00 UTC > > > More information about the event and other activities around EPF12 > may be found at https://peering-forum.eu/ > > Best regards, > Arnold > > On behalf of the EPF hosts > -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From jacques.latour at cira.ca Wed Jul 5 12:54:42 2017 From: jacques.latour at cira.ca (Jacques Latour) Date: Wed, 5 Jul 2017 12:54:42 +0000 Subject: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017 In-Reply-To: References: Message-ID: Hi All! > DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017 Seems like a good time to send a reminder that we still have some presentation slots available. > https://indico.dns-oarc.net/event/27/call-for-abstracts/ Jacques > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jacques > Latour > Sent: Friday, May 26, 2017 9:43 AM > To: nanog at nanog.org > Subject: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, > 29-30 September 2017 > > [with apologies to those who see this on multiple lists] > > Call For Presentations > > The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on > September 29th and 30th 2017, the Friday and Saturday preceding NANOG > 71.  The Workshop's Program Committee is now requesting proposals for > presentations.  All DNS-related subjects are welcome. > > If you are an OARC member, and have a sensitive topic you would like to > present for members-only, we can accommodate those talks during the > Members Only session on the morning of September 29th.  A timeslot will > also be available for lightning talks (5-10 minutes) on Saturday September > 30th, for which submissions will be accepted during Friday 29th. > > Workshop Milestones: > >   26 May 2017, Call for Presentations posted and open for submissions >   28 July 2017, Deadline for submission >   11 August 2017, Draft Programme published >   01 September 2017, Final Program published >   15 September 2017, Final deadline for slideset submission > > Details for presentation submission will be published here: > >     https://indico.dns-oarc.net/event/27/call-for-abstracts/ > > The workshop presentations will be organized by common themes, > depending on the topics and the timing of each presentation. There are 30- > minute and 15-minute slots, let us know your preference in your submission. > > To allow the Programme Committee to make objective assessments of > submissions, so as to ensure the quality of the workshop, submissions > SHOULD include slides.  Draft slides are acceptable on submission. > > If you have questions or concerns you can contact the Programme > Committee: > >     https://www.dns-oarc.net/oarc/programme > > via > > Ray Bellis, for the OARC Programme Committee > > OARC depends on sponorship to fund its workshops and associated social > events.  Please contact if your organization is > interested in becoming a sponsor. > > (Please note that OARC is run on a non-profit basis, and is not in a position to > reimburse expenses or time for speakers at its meetings.) From jra at baylink.com Wed Jul 5 13:28:11 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 5 Jul 2017 13:28:11 +0000 (UTC) Subject: Big Spam Burst Message-ID: <2013235235.709130.1499261291871.JavaMail.zimbra@baylink.com> Am I the only person who got a big burst of spam -- 30 or 40 in about 5 minutes -- on Sunday night, from France? All forged with NANOG participant From names? I'm pretty sure Steve Bellovin and Rob Seastrom aren't sending me spam. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at compuwizz.net Tue Jul 4 20:43:43 2017 From: jared at compuwizz.net (Jared Geiger) Date: Tue, 4 Jul 2017 13:43:43 -0700 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: The RAM is upgradeable but it can support quite a few full tables out of the box. The routing software under the hood got upgraded by Ubiquiti to ZebOS https://www.ipinfusion.com/products/zebos/ from the VyOS code. There is a Cavium bug regarding UDP packets though that can be nasty if you hit it. https://community.ubnt.com/t5/EdgeMAX/UDP-packet-loss-with-EdgeRouter-Lite/m-p/1343012 Even though the thread starts by talking about the Lite, all of the Cavium EdgeRouters currently have the problem. The beta work around is to restrict packet forwarding to only use one of the CPU cores. This is with or without hardware offloading enabled. Hopefully Cavium will have a real fix soon. I have two of these I'm itching to put into production once the bugs are worked out. On Mon, Jul 3, 2017 at 8:28 PM, Josh Reynolds wrote: > I kinda feel the same way. I wish FRR was a big more mature at this > point though. > > On Mon, Jul 3, 2017 at 10:21 PM, Baldur Norddahl > wrote: > > Why not use a Linux or BSD computer for this? It is cheap and you know > > exactly what you are getting. It will forward 10 gig at line rate at > least > > for normal traffic. > > > > Regards > > > > Baldur > > > > Den 3. jul. 2017 21.08 skrev "Job Snijders" : > > > >> Dear NANOG, > >> > >> Some friends of mine are operating a nonprofit (on shoe string) and > looking > >> to connect some CDN caches to an IX fabric. A BGP speaking device is > needed > >> between the caches and the BGP peers connected to the fabric. The BGP > >> speaker is needed to present the peers on the IX with a unified view of > the > >> assemblage of CDN nodes. > >> > >> I was wondering whether anyone was experience with the "EdgeRouter > Infinity > >> XG" device, specifically in the role of a simple peering router for a > >> couple of tens of thousands of routes. (I'd point default to the left > and > >> take just the on-net routes on the right to reduce the table size > >> requirement). > >> > >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > >> automatable (supports idempotency), can forward IMIX at line-rate, > *flow, > >> and exposes some telemetry via SNMP. > >> > >> Any note sharing would be appreciated! > >> > >> Kind regards, > >> > >> Job > >> > From paul at gear.dyndns.org Tue Jul 4 02:39:02 2017 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 4 Jul 2017 12:39:02 +1000 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: <20170704022830.GE7539@bamboo.slabnet.com> References: <20170704022830.GE7539@bamboo.slabnet.com> Message-ID: On 04/07/17 12:28, Hugo Slabbert wrote: > > ... >>> >>> As far as automation, it's a JunOS-like CLI originally based on vyatta, >>> which AT&T now owns - and one of the main reasons is it's scriptability, >>> use of Ansible and other tools right on the device, python, etc. > > Technically I believe it's based on VyOS rather than Vyatta. Same base, > but just delineating that VyOS is open source and I don't believe AT&T > wields any control over it. EdgeOS was forked from Vyatta well before (around Vyatta Core 6.2?) VyOS took up the last public Vyatta release. It has therefore diverged somewhat from current VyOS releases, but the two are still mostly-compatible. Paul From dveit at microsoft.com Wed Jul 5 22:39:35 2017 From: dveit at microsoft.com (Darrin Veit) Date: Wed, 5 Jul 2017 22:39:35 +0000 Subject: Armstrong Cable Services/AS27364 networking contact needed Message-ID: I'm hoping to find a networking contact at Armstrong that can ping me off list. We're investigating connectivity issues for some Armstrong customers when they are trying to connect to servers in AS8075. Thanks! -Darrin Veit, Xbox Platform Networking dveit at microsoft.com From josh at kyneticwifi.com Wed Jul 5 23:15:16 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 5 Jul 2017 18:15:16 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <20170704022830.GE7539@bamboo.slabnet.com> Message-ID: 6.3 ;) - Josh On Jul 5, 2017 2:10 PM, "Paul Gear" wrote: > On 04/07/17 12:28, Hugo Slabbert wrote: > > > > ... > >>> > >>> As far as automation, it's a JunOS-like CLI originally based on vyatta, > >>> which AT&T now owns - and one of the main reasons is it's > scriptability, > >>> use of Ansible and other tools right on the device, python, etc. > > > > Technically I believe it's based on VyOS rather than Vyatta. Same base, > > but just delineating that VyOS is open source and I don't believe AT&T > > wields any control over it. > > EdgeOS was forked from Vyatta well before (around Vyatta Core 6.2?) VyOS > took up the last public Vyatta release. It has therefore diverged > somewhat from current VyOS releases, but the two are still > mostly-compatible. > > Paul > > From pozar at lns.com Thu Jul 6 00:03:49 2017 From: pozar at lns.com (Tim Pozar) Date: Wed, 5 Jul 2017 17:03:49 -0700 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <20170704022830.GE7539@bamboo.slabnet.com> Message-ID: <2bff4a43-6010-75a3-e7f8-66ee16584204@lns.com> BTW... At Fandor (before I left) we got one of the last /24s that ARIN had. Our transit providers at the office were Monkey Brains (wireless) and Zayo (fiber). We purchased a ER Pro, upgraded the memory and were peering v4 with both on this box. MB didn't have V6 at that point. We did nail up our V6 announcement with Zayo and got it that way. If folks need config examples. Tim From job at ntt.net Thu Jul 6 12:34:45 2017 From: job at ntt.net (Job Snijders) Date: Thu, 6 Jul 2017 14:34:45 +0200 Subject: Heads-up: RFC 8212 on default EBGP route handling behavior Message-ID: <20170706123445.32mvoxvphhukdye5@Vurt.local> Dear NANOG, After a bit of tug-of-war common sense prevailed and RFC 8212 "External BGP (EBGP) Route Propagation Behavior without Policies" was published: https://tools.ietf.org/html/rfc8212 This industry has a long history of improving default behavior: DEC MOP is no longer enabled by default, telnet was swapped out in favor of SSH, and SHA-1 is now deprecated, so I'm confident we can manage this one too. TL;DR This mail offers advice on test scenarios to add to your evaluation checklist and a call to action to ask your vendor to implement RFC 8212. Please share this message with other communities. Background ---------- Prior to RFC 8212, the default behavior of BGP implementations (when no policy is configured on an EBGP session) was undefined, this resulted in a myriad of vendor defaults: some implementations not accepting routes and not advertising anything; some would accept anything, but announce nothing; some would announce only internal routes and accept anything; and some would indiscriminately accept everything and announce everything. The latter mode of operation is of course the most harmful one. An example minimal configuration: ! router bgp 15562 neighbor 192.0.2.1 remote-as 174 neighbor 192.0.2.5 remote-as 2914 ! Most of us have learned (the hard way) that on many platforms the above configuration will not only bring up two BGP sessions, but also immediately result in a "Lateral ISP-ISP-ISP Leak" [2], simply because no routing policy was associated with these EBGP sessions and an implicit 'permit-any' is assumed. The above configuration is of course an oversimplification of what happens in real life: operators may attempt to change a BGP peer to a peer-group which has missing configuration, or a copy+paste of a snippet of configuration only partially succeeds, or in an attempt to debug a BGP session some configuration is removed without realizing the full ramifications of doing so (until you see smoke coming off the circuit ;-). RFC 8212 updates the core BGP specification (RFC 4271) to specify that the above behavior is _incorrect_, and an implicit deny-all must be associated with the EBGP session. In other words: "fail closed" rather then "fail open and oops you tripped max-prefix all over the place (or worse [3])". The document purposefully does not cover IBGP, nor does it proscribe what the contents of configured policy on EBGP sessions should be. If an operator explicitly configures a 'permit-any' style policy, that is perfectly fine, it was a conscious choice to do so. Evaluation checklist -------------------- Going forward when you evaluate a BGP implementation or a new software release, it is advisable to take note of the default behavior of that specific release. As vendors come into compliance with RFC 8212 it may be beneficial to track this. I also strongly recommend to audit your network configurations for instances which depend on implicit 'permit-any' behavior and reconfigure those instances to be an explicit 'permit-any'. This way software upgrades are less likely to cause surprises, and as a bonus the readability of the device's configuration is improved! Call to action -------------- Some vendors will need encouragement to take their implementation from EBGP "fail open" to "fail closed", we are keeping track of the industry's current state of affairs here: https://github.com/bgp/RFC8212 Please contact your account management team and express your interest in them supporting RFC 8212. Also, make sure to include RFC 8212 in your next round of "Request for Proposals" (RFPs) as a 'must have'. Purchasing usually is an excellent opportunity to have meaningful dialogue with the vendor. Some vendors may argue "but our customers depend on our unsafe behavior!", but this only holds true if we don't speak up collectively and show them otherwise. EBGP is an internet-wide shared resource, we all benefit from sane defaults. Hat tip to Jared Mauch for initiating this project and to Greg Hankins for demonstrating change is possible [4]. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/idr/mqPltvvgEhpxBgAXET1y1Xow6t8 [2]: https://tools.ietf.org/html/rfc7908#section-3.2 [3]: https://bgpmon.net/massive-route-leak-cause-internet-slowdown/ [4]: https://mailarchive.ietf.org/arch/msg/idr/kgl6etbjUuR3jLHVeDSi4LLIs50 From erica at eff.org Wed Jul 5 22:59:37 2017 From: erica at eff.org (Erica Portnoy) Date: Wed, 5 Jul 2017 15:59:37 -0700 Subject: Sign onto EFF's comment to the FCC on their net neutrality proposal Message-ID: <832e2997-669d-3ea3-95e1-eb3ea43a3a81@eff.org> Dear colleagues, As many of you know, the FCC is currently engaging in the process of repealing its network neutrality rules and eliminating its Title II authority over broadband providers. I'm writing you today to ask you to sign on to a letter that EFF has prepared for filing, which explains several key engineering concepts that are vital to understanding how the Internet actually operates given that the FCC's own findings misinterpret how the Internet works. The letter stays away from legal arguments, and instead focuses on technical statements on the design and operation of the Internet. It is meant to establish a factual record for the FCC about the Internet and it is necessary because its initial findings in its Notice of Proposed Rulemaking are just wrong. For one, the FCC thinks that broadband Internet providers are the ones providing end users with the services of the entire Internet, from search engines to online newspapers to language translation tools. /*If you're willing to sign on and help, please email engineers-nn-comments at eff.org (off-list) by Friday, July 14 */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely the FCC is to take notice as well as the courts should they move forward. All it takes is an email. Please help us make sure the FCC gets the facts from an engineer's standpoint. Thank you for your support, Erica Portnoy Staff Technologist Electronic Frontier Foundation From jerome at ceriz.fr Fri Jul 7 09:10:00 2017 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Fri, 7 Jul 2017 11:10:00 +0200 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <44023ecd-2812-e8c0-126e-f89da5edce78@rollernet.us> Message-ID: <9e6f9f47-ac28-4f40-4aa2-5d8a19a2ca25@ceriz.fr> Hello Jeremy, Le 04/07/2017 à 01:10, Jeremy Austin a écrit : > can certainly handle a few tens of thousands of > routes fine (single core BGP though), It can take multiple full views. It's also faster than an MX104. > but I can't vouch for its ability to > do IMIX or *flow at line rate I wouldn't load one to 80g, but at 10-20G, it creates no bottleneck. The entire packet-pipeline is in software. IPFIX is not sampled, it's 1:1 only AFAIK. It's also lacking some features, meaning you'd need to filter through pmacct to add BGP informations. Best regards, -- Jérôme Nicolle From oliver.oboyle at gmail.com Fri Jul 7 17:07:54 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Fri, 7 Jul 2017 13:07:54 -0400 Subject: Some advice on IPv6 planning and ARIN request, please Message-ID: Hello, If anyone out there could provide some input or advice on how to best handle our upcoming leap into IPv6, it would be much appreciated. I want to make sure we're playing nicely and not causing anyone any unnecessary grief before we deploy. We're currently in the planning stage and can make whatever changes we need to. Situation: We're an end-user org and qualify for a /40 assignment because we operate over 60 sites and some of those are/will be multihomed. We manage hotels in Canada only, but from coast to coast to coast and everywhere in between. Our corporate network and org structure is optimized for three regions. We also have, and continue to grow into, cloud infrastructure and foresee wanting to bring our own addresses (.e.g., to AWS VPC when that option becomes available). As such, an obvious design strategy would be to break the /40 into 4 x /42's. However, due to an imbalance in national site distribution, 50% of our sites are located in one region (Region A). Additionally, historical and forecasted growth indicates that it's perfectly reasonable for us to expect growth of an additional 16 sites in that same region over the next 3-5 years. We would prefer to summarize at the /42 level, announced from our last-mile providers. There are 3 primary last-mile providers so this strategy would help significantly reduce the number of global routes being injected. If we split regions evenly at /42 and if we follow the /48-per-site best practice (which I believe is justifiable in our situation - see below), Region A will be at 50% usage immediately. Adding 16 more sites brings it to 75% usage in only a few years. The other regions would be at ~33% usage (Region B) and 15% usage (Region C) and will see moderate growth in 3-5 years. Cloud will initially be at 2-4% usage (Region D) but will also grow quickly within 3-5 years. Ideal situation: ARIN assigns us a /36 and we don't need to worry about re-addressing. Even if they can offer us contiguous space with a second request to increase our assignment, we would likely need to re-address a significant portion of our sites which would be painful and time-consuming. Less ideal situation #1: Split the first level of subnets unevenly at 1 x /41 and 2 x /42 and hope we can carve out some of that space for use in our cloud infrastructure. This strategy would solve our Region A problem and would keep Regions B and C from going to 68% and 34% utilization immediately but it would mess up Region D and impact Regions B and C. Less ideal situation #2: Split the first level of subnets unevenly at 1 x /41, 1 x /42, and 2 x /43. This strategy would solve our Region A and Region B problems but would constrain Region C and Region D future growth options somewhat. Less ideal situation #3: Drop the /48 per site default to somewhere between a /49 and /53 and hope we don't bust out of those. This strategy would allow us to keep top-level aggregation at /42's but would move the site assignments off the nibble boundaries. Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of them in Region A. This strategy would imply we don't wish for our business to grow and is pretty risky. I feel the /48 site default is justifiable because of the various applications and services that are currently, or could likely be offered at hotels. E.g., each room gets a /64 for all guest-internet devices registered to that room. + IoT could result in the same rule (each room gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64 or each IoT vendor is on a /64. There will also be new applications that come out with similar possible needs. With some of our hotels in the 500-1000 room range, we're looking at as many as 2000 /64's per site in the next 5 or so years. Plus backoffice/admin subnets. I think the ideal situation is out as ARIN policy wouldn't allow them to assign us a /36 at this time. Unless someone knows something that can help us here. Assuming we can't get a /36, my feeling is that less ideal situation #2 is better than #3 is better than #1 is better than #4, assuming we're following the following design best-practices: a) assign top-level aggregations evenly (which we'd be breaking a bit with option #2) b) reduce global routes as much as possible c) stay on the nibble boundary as much as possible d) default to /48 per site Any thoughts or advice would be much appreciated. Thanks in advance, Oliver From math at sizone.org Fri Jul 7 17:15:00 2017 From: math at sizone.org (Ken Chase) Date: Fri, 7 Jul 2017 13:15:00 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: <20170707171500.GA29857@sizone.org> 60 sites? Just ask for a /32. /kc On Fri, Jul 07, 2017 at 01:07:54PM -0400, Oliver O'Boyle said: >Hello, > >If anyone out there could provide some input or advice on how to best >handle our upcoming leap into IPv6, it would be much appreciated. I want to >make sure we're playing nicely and not causing anyone any unnecessary grief >before we deploy. We're currently in the planning stage and can make >whatever changes we need to. > >Situation: > >We're an end-user org and qualify for a /40 assignment because we operate >over 60 sites and some of those are/will be multihomed. We manage hotels in >Canada only, but from coast to coast to coast and everywhere in between. >Our corporate network and org structure is optimized for three regions. We >also have, and continue to grow into, cloud infrastructure and foresee >wanting to bring our own addresses (.e.g., to AWS VPC when that option >becomes available). As such, an obvious design strategy would be to break >the /40 into 4 x /42's. However, due to an imbalance in national site >distribution, 50% of our sites are located in one region (Region A). >Additionally, historical and forecasted growth indicates that it's >perfectly reasonable for us to expect growth of an additional 16 sites in >that same region over the next 3-5 years. > >We would prefer to summarize at the /42 level, announced from our last-mile >providers. There are 3 primary last-mile providers so this strategy would >help significantly reduce the number of global routes being injected. If we >split regions evenly at /42 and if we follow the /48-per-site best practice >(which I believe is justifiable in our situation - see below), Region A >will be at 50% usage immediately. Adding 16 more sites brings it to 75% >usage in only a few years. The other regions would be at ~33% usage (Region >B) and 15% usage (Region C) and will see moderate growth in 3-5 years. >Cloud will initially be at 2-4% usage (Region D) but will also grow quickly >within 3-5 years. > >Ideal situation: ARIN assigns us a /36 and we don't need to worry about >re-addressing. Even if they can offer us contiguous space with a second >request to increase our assignment, we would likely need to re-address a >significant portion of our sites which would be painful and time-consuming. >Less ideal situation #1: Split the first level of subnets unevenly at 1 x >/41 and 2 x /42 and hope we can carve out some of that space for use in our >cloud infrastructure. This strategy would solve our Region A problem and >would keep Regions B and C from going to 68% and 34% utilization >immediately but it would mess up Region D and impact Regions B and C. >Less ideal situation #2: Split the first level of subnets unevenly at 1 x >/41, 1 x /42, and 2 x /43. This strategy would solve our Region A and >Region B problems but would constrain Region C and Region D future growth >options somewhat. >Less ideal situation #3: Drop the /48 per site default to somewhere between >a /49 and /53 and hope we don't bust out of those. This strategy would >allow us to keep top-level aggregation at /42's but would move the site >assignments off the nibble boundaries. >Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of >them in Region A. This strategy would imply we don't wish for our business >to grow and is pretty risky. > >I feel the /48 site default is justifiable because of the various >applications and services that are currently, or could likely be offered at >hotels. E.g., each room gets a /64 for all guest-internet devices >registered to that room. + IoT could result in the same rule (each room >gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64 >or each IoT vendor is on a /64. There will also be new applications that >come out with similar possible needs. With some of our hotels in the >500-1000 room range, we're looking at as many as 2000 /64's per site in the >next 5 or so years. Plus backoffice/admin subnets. > >I think the ideal situation is out as ARIN policy wouldn't allow them to >assign us a /36 at this time. Unless someone knows something that can help >us here. > >Assuming we can't get a /36, my feeling is that less ideal situation #2 is >better than #3 is better than #1 is better than #4, assuming we're >following the following design best-practices: > >a) assign top-level aggregations evenly (which we'd be breaking a bit with >option #2) >b) reduce global routes as much as possible >c) stay on the nibble boundary as much as possible >d) default to /48 per site > >Any thoughts or advice would be much appreciated. > >Thanks in advance, >Oliver -- Ken Chase - math at sizone.org Guelph Canada From nanog at jima.us Fri Jul 7 17:33:49 2017 From: nanog at jima.us (Jima) Date: Fri, 7 Jul 2017 11:33:49 -0600 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: <58c65726-ae9e-3e3d-921a-9fa27275c967@jima.us> On 2017-07-07 11:07, Oliver O'Boyle wrote: > We would prefer to summarize at the /42 level, announced from our last-mile > providers. There are 3 primary last-mile providers so this strategy would > help significantly reduce the number of global routes being injected. If we > split regions evenly at /42 and if we follow the /48-per-site best practice > (which I believe is justifiable in our situation - see below), Region A > will be at 50% usage immediately. Adding 16 more sites brings it to 75% > usage in only a few years. The other regions would be at ~33% usage (Region > B) and 15% usage (Region C) and will see moderate growth in 3-5 years. > Cloud will initially be at 2-4% usage (Region D) but will also grow quickly > within 3-5 years. If you're backhauling each region (even effectively via your upstream), I'd take a look/listen to these two slides: https://www.youtube.com/watch?v=rWJZfShWE6g&t=12m46s (Honestly, that entire video is worth watching if you're preparing to make your initial IPv6 PI space request -- it's a very informative presentation, and is fairly authoritative.) Net-net, if "hub 1" is supporting 30-ish sites, with projected growth to 46-ish, you could possibly make the case for allocating a /40 per hub, and a /38 (or maybe even /36) overall. (There's only one /38 assignment in ARIN region, FWIW.) > I feel the /48 site default is justifiable because of the various > applications and services that are currently, or could likely be offered at > hotels. If it's a site, /48 is justified as per ARIN requirements, period. > I think the ideal situation is out as ARIN policy wouldn't allow them to > assign us a /36 at this time. Unless someone knows something that can help > us here. Might. I'd file the request, as long as you have a logical addressing plan to justify it. Jima From cscora at apnic.net Fri Jul 7 18:02:44 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Jul 2017 04:02:44 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170707180244.2FE4DE17@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 653872 Prefixes after maximum aggregation (per Origin AS): 254333 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 315298 Total ASes present in the Internet Routing Table: 57740 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49962 Origin ASes announcing only one prefix: 22072 Transit ASes present in the Internet Routing Table: 7778 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 60 Numnber of instances of unregistered ASNs: 64 Number of 32-bit ASNs allocated by the RIRs: 19359 Number of 32-bit ASNs visible in the Routing Table: 15061 Prefixes from 32-bit ASNs in the Routing Table: 61319 Number of bogon 32-bit ASNs visible in the Routing Table: 64 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 349 Number of addresses announced to Internet: 2848140388 Equivalent to 169 /8s, 195 /16s and 44 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 217691 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179377 Total APNIC prefixes after maximum aggregation: 51366 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 178434 Unique aggregates announced from the APNIC address blocks: 73877 APNIC Region origin ASes present in the Internet Routing Table: 8227 APNIC Prefixes per ASN: 21.69 APNIC Region origin ASes announcing only one prefix: 2309 APNIC Region transit ASes present in the Internet Routing Table: 1163 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 54 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3071 Number of APNIC addresses announced to Internet: 763514212 Equivalent to 45 /8s, 130 /16s and 77 /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: 199057 Total ARIN prefixes after maximum aggregation: 94804 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201014 Unique aggregates announced from the ARIN address blocks: 92372 ARIN Region origin ASes present in the Internet Routing Table: 17915 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6631 ARIN Region transit ASes present in the Internet Routing Table: 1765 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: 2073 Number of ARIN addresses announced to Internet: 1108484768 Equivalent to 66 /8s, 18 /16s and 34 /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: 175353 Total RIPE prefixes after maximum aggregation: 85837 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171163 Unique aggregates announced from the RIPE address blocks: 102995 RIPE Region origin ASes present in the Internet Routing Table: 24179 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11138 RIPE Region transit ASes present in the Internet Routing Table: 3406 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5978 Number of RIPE addresses announced to Internet: 712318592 Equivalent to 42 /8s, 117 /16s and 30 /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: 83011 Total LACNIC prefixes after maximum aggregation: 18472 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 84275 Unique aggregates announced from the LACNIC address blocks: 38801 LACNIC Region origin ASes present in the Internet Routing Table: 6112 LACNIC Prefixes per ASN: 13.79 LACNIC Region origin ASes announcing only one prefix: 1664 LACNIC Region transit ASes present in the Internet Routing Table: 1140 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3620 Number of LACNIC addresses announced to Internet: 170696160 Equivalent to 10 /8s, 44 /16s and 157 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16966 Total AfriNIC prefixes after maximum aggregation: 3800 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 18637 Unique aggregates announced from the AfriNIC address blocks: 6939 AfriNIC Region origin ASes present in the Internet Routing Table: 1052 AfriNIC Prefixes per ASN: 17.72 AfriNIC Region origin ASes announcing only one prefix: 329 AfriNIC Region transit ASes present in the Internet Routing Table: 208 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 319 Number of AfriNIC addresses announced to Internet: 92717568 Equivalent to 5 /8s, 134 /16s and 194 /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 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR 9829 2744 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2167 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2089 422 222 TATACOMM-AS TATA Communications formerl 45899 2053 1424 111 VNPT-AS-VN VNPT Corp, VN 7552 1639 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1598 361 141 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 18566 2179 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2064 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2011 2172 418 CHARTER-NET-HKY-NC - Charter Communicat 209 1825 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1823 3697 591 AMAZON-02 - Amazon.com, Inc., US 30036 1805 326 297 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1695 854 231 ITCDELTA - Earthlink, Inc., US 701 1561 10559 630 UUNET - MCI Communications Services, In 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 3388 190 24 ALJAWWALSTC-AS, SA 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 34984 2015 329 410 TELLCOM-AS, TR 9121 1930 1691 17 TTNET, TR 12479 1605 1044 53 UNI2-AS, ES 13188 1603 100 55 TRIOLAN, UA 12389 1521 1408 626 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1093 544 15 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 10620 3532 543 205 Telmex Colombia S.A., CO 8151 2472 3404 572 Uninet S.A. de C.V., MX 11830 2090 369 57 Instituto Costarricense de Electricidad 7303 1552 1012 243 Telecom Argentina S.A., AR 6503 1538 437 53 Axtel, S.A.B. de C.V., MX 6147 1296 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 968 2301 177 CLARO S.A., BR 11172 915 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 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 1237 398 51 LINKdotNET-AS, EG 37611 724 91 8 Afrihost, ZA 36903 711 357 129 MT-MPLS, MA 36992 644 1375 26 ETISALAT-MISR, EG 24835 478 786 17 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 348 35 7 WANANCHI-, KE 8452 327 1730 17 TE-AS TE-AS, EG 2018 304 327 74 TENET-1, ZA 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 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3532 543 205 Telmex Colombia S.A., CO 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 39891 3388 190 24 ALJAWWALSTC-AS, SA 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3817 3657 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3982 3599 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3388 3364 ALJAWWALSTC-AS, SA 6327 3423 3340 SHAW - Shaw Communications Inc., CA 10620 3532 3327 Telmex Colombia S.A., CO 8551 2974 2934 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2976 2903 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2744 2204 BSNL-NIB National Internet Backbone, IN 9808 2167 2135 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2179 2070 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, 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 Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 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:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1047 /15:1847 /16:13467 /17:7640 /18:13422 /19:24664 /20:38616 /21:41255 /22:77663 /23:64411 /24:366633 /25:864 /26:607 /27:642 /28:34 /29:22 /30:17 /31:2 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3224 3423 SHAW - Shaw Communications Inc., CA 22773 2979 3817 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3388 ALJAWWALSTC-AS, SA 8551 2439 2974 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2072 2179 MEGAPATH5-US - MegaPath Corporation, US 30036 1595 1805 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1480 2090 Instituto Costarricense de Electricidad y Telec 10620 1469 3532 Telmex Colombia S.A., CO 11492 1390 1541 CABLEONE - CABLE ONE, INC., US 6389 1371 2064 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1603 2:803 4:18 5:2435 6:34 8:1045 12:1833 13:123 14:1737 15:28 16:2 17:159 18:90 20:61 23:2395 24:1881 25:2 27:2459 31:1928 32:84 33:13 35:21 36:386 37:2349 38:1313 39:64 40:98 41:2947 42:472 43:1943 44:73 45:2892 46:2802 47:157 49:1239 50:987 51:19 52:833 54:364 55:6 56:4 57:42 58:1573 59:1053 60:388 61:1959 62:1601 63:1914 64:4602 65:2223 66:4547 67:2262 68:1238 69:3373 70:1150 71:586 72:2224 74:2684 75:388 76:426 77:1536 78:1436 79:2387 80:1401 81:1385 82:1002 83:723 84:932 85:1745 86:482 87:1165 88:754 89:2114 90:175 91:6199 92:977 93:2368 94:2383 95:2699 96:625 97:353 98:1062 99:86 100:154 101:1193 103:15324 104:2983 105:178 106:510 107:1719 108:823 109:2874 110:1453 111:1730 112:1198 113:1254 114:1036 115:1723 116:1792 117:1710 118:2198 119:1611 120:1055 121:1113 122:2259 123:1815 124:1482 125:1902 128:782 129:662 130:434 131:1428 132:526 133:199 134:659 135:223 136:448 137:435 138:1953 139:490 140:398 141:606 142:767 143:900 144:792 145:179 146:1046 147:694 148:1459 149:583 150:711 151:973 152:695 153:304 154:767 155:759 156:613 157:655 158:462 159:1522 160:694 161:740 162:2520 163:530 164:806 165:1396 166:380 167:1253 168:2988 169:821 170:3419 171:319 172:1022 173:1951 174:811 175:748 176:1870 177:4135 178:2529 179:1162 180:2203 181:1903 182:2361 183:996 184:862 185:10052 186:3254 187:2195 188:2602 189:1794 190:8296 191:1365 192:9506 193:5772 194:4684 195:3923 196:2081 197:1267 198:5503 199:5897 200:7430 201:4335 202:10333 203:9996 204:4479 205:2807 206:3014 207:3136 208:3972 209:3989 210:4015 211:2145 212:2844 213:2512 214:869 215:66 216:5800 217:2113 218:864 219:599 220:1694 221:932 222:762 223:1180 End of report From oliver.oboyle at gmail.com Fri Jul 7 19:38:06 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Fri, 7 Jul 2017 15:38:06 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <58c65726-ae9e-3e3d-921a-9fa27275c967@jima.us> References: <58c65726-ae9e-3e3d-921a-9fa27275c967@jima.us> Message-ID: Thanks, Jima. I'll review the slides. Without complicating the issue, we're trying to address a number of challenges at the same time. There's no regional backhauling at this time. Each site will be reachable via the internal network but will also independently announce it's assignment to its ISP(s). There are many reasons for this model, some of which I like and others I don't! We do plan to coordinate address assignments/aggregations with the ISPs to reduce global routes and unwanted conflicts/overlap.Unfortunately, there's no real hub in each region and the ISPs are not region-specific. We inherit a bunch of stuff and then need to find a way to jam it into something that isn't completely broken... we've done a lot of cleanup and re-org of services but there's still a long way to go. IPv6 should help us get there, however. Agreed with the /48 but ARIN doesn't appear to agree with our justification for a /36 thus far. On Fri, Jul 7, 2017 at 1:33 PM, Jima wrote: > On 2017-07-07 11:07, Oliver O'Boyle wrote: > >> We would prefer to summarize at the /42 level, announced from our >> last-mile >> providers. There are 3 primary last-mile providers so this strategy would >> help significantly reduce the number of global routes being injected. If >> we >> split regions evenly at /42 and if we follow the /48-per-site best >> practice >> (which I believe is justifiable in our situation - see below), Region A >> will be at 50% usage immediately. Adding 16 more sites brings it to 75% >> usage in only a few years. The other regions would be at ~33% usage >> (Region >> B) and 15% usage (Region C) and will see moderate growth in 3-5 years. >> Cloud will initially be at 2-4% usage (Region D) but will also grow >> quickly >> within 3-5 years. >> > > If you're backhauling each region (even effectively via your upstream), > I'd take a look/listen to these two slides: https://www.youtube.com/watch? > v=rWJZfShWE6g&t=12m46s (Honestly, that entire video is worth watching if > you're preparing to make your initial IPv6 PI space request -- it's a very > informative presentation, and is fairly authoritative.) > > Net-net, if "hub 1" is supporting 30-ish sites, with projected growth to > 46-ish, you could possibly make the case for allocating a /40 per hub, and > a /38 (or maybe even /36) overall. (There's only one /38 assignment in ARIN > region, FWIW.) > > I feel the /48 site default is justifiable because of the various >> applications and services that are currently, or could likely be offered >> at >> hotels. >> > > If it's a site, /48 is justified as per ARIN requirements, period. > > I think the ideal situation is out as ARIN policy wouldn't allow them to >> assign us a /36 at this time. Unless someone knows something that can help >> us here. >> > > Might. I'd file the request, as long as you have a logical addressing plan > to justify it. > > Jima > -- :o@> From bill at herrin.us Fri Jul 7 22:17:43 2017 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jul 2017 18:17:43 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle wrote: > We're an end-user org and qualify for a /40 assignment because we operate > over 60 sites and some of those are/will be multihomed. Hi Oliver, I second Ken's notion. You're trying to be an ISP under the end-user rules. However transient, your users are mostly customers rather than staff. Just register as an ISP and get the default /32. IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses there is a high probability they'll just increase your netmask. Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like collecting all of a guest's devices behind his personal firewall but it doesn't work if you've only assigned a /64. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From oliver.oboyle at gmail.com Sat Jul 8 00:39:00 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Fri, 7 Jul 2017 20:39:00 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: Bill, Thanks for the input. I don't consider us an isp, though i suppose i can see how that argument could me made. Hotels are both simple and complicated. There is a mix of our staff and equipment, guests and their equipment, and brands with their equipment. But really it's just one operating entity that ultimayely isn't that much different than any other enterprise out there. Now multiply that by 60-65 sites spread across the country and we need to manage our 6000 staff and networks accordingly. We operate 100% of the hotel, top to bottom, not just the technology. I wouldn't want ARIN or anyone else thinking we were an ISP if we aren't. Particulary if that creates problems in the future as rules (and possibly costs) change. However, if what you are saying is that registerong as an ISP is actually the correct way to go about this in ARIN's eyes as well, then that's a different story. Thanks for the tip on IoT sizing. That's precisely the kind of thing i am concerned about being constrained with in the future if we size sites too small. Oliver On Jul 7, 2017 6:18 PM, "William Herrin" wrote: On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle wrote: > We're an end-user org and qualify for a /40 assignment because we operate > over 60 sites and some of those are/will be multihomed. Hi Oliver, I second Ken's notion. You're trying to be an ISP under the end-user rules. However transient, your users are mostly customers rather than staff. Just register as an ISP and get the default /32. IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses there is a high probability they'll just increase your netmask. Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like collecting all of a guest's devices behind his personal firewall but it doesn't work if you've only assigned a /64. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From owen at delong.com Sat Jul 8 01:06:04 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jul 2017 18:06:04 -0700 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> Oliver, I’ll mostly second what Bill has said here. However, I encourage you to actually consider a /48 per guest room as well as a /48 per hotel for the hotel itself. Yes, this is excessive, but IPv6 was designed with these types of excesses in mind. We don’t yet know the scope and breadth of what will come out of IoT development, but one thing we do know for sure… Development tends to get stymied by whatever turns into the lowest common denominator among available technologies out there, so if 10 hotel chains give their guests /48s and 2 give out /60s and one gives out /64s, development may well lock everyone into nothing better than what can be done with a /64 even if better is available. We’ve seen this time and again with products that depend on autodiscovery processes that rely on everything being on the same LAN and assume that they can just trust the NAT router to protect that LAN from anything else. This is clearly a very bad strategy to anyone who understands networking, yet if you walk into your local Best Buy, more of the “internet enabled” products on the shelf have this behavior than don’t… Far more. Owen > On Jul 7, 2017, at 17:39 , Oliver O'Boyle wrote: > > Bill, > > Thanks for the input. I don't consider us an isp, though i suppose i can > see how that argument could me made. Hotels are both simple and > complicated. There is a mix of our staff and equipment, guests and their > equipment, and brands with their equipment. But really it's just one > operating entity that ultimayely isn't that much different than any other > enterprise out there. Now multiply that by 60-65 sites spread across the > country and we need to manage our 6000 staff and networks accordingly. We > operate 100% of the hotel, top to bottom, not just the technology. > > I wouldn't want ARIN or anyone else thinking we were an ISP if we aren't. > Particulary if that creates problems in the future as rules (and possibly > costs) change. > > However, if what you are saying is that registerong as an ISP is actually > the correct way to go about this in ARIN's eyes as well, then that's a > different story. > > Thanks for the tip on IoT sizing. That's precisely the kind of thing i am > concerned about being constrained with in the future if we size sites too > small. > > Oliver > > On Jul 7, 2017 6:18 PM, "William Herrin" wrote: > > On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle > wrote: > >> We're an end-user org and qualify for a /40 assignment because we operate >> over 60 sites and some of those are/will be multihomed. > > > Hi Oliver, > > I second Ken's notion. You're trying to be an ISP under the end-user rules. > However transient, your users are mostly customers rather than staff. Just > register as an ISP and get the default /32. > > IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses > there is a high probability they'll just increase your netmask. > > Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like > collecting all of a guest's devices behind his personal firewall but it > doesn't work if you've only assigned a /64. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From lee at asgard.org Sat Jul 8 16:01:30 2017 From: lee at asgard.org (Lee Howard) Date: Sat, 08 Jul 2017 12:01:30 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: On 7/7/17, 1:07 PM, "NANOG on behalf of Oliver O'Boyle" wrote: > We're currently in the planning stage and can make >whatever changes we need to. I always say to just expect you’ll change your address plan three times. Some people say, “I’ve only changed the address plan twice. . . so far.” > >Situation: > >We're an end-user org and qualify for a /40 assignment because we operate >over 60 sites and some of those are/will be multihomed. We manage hotels >in >Canada only, but from coast to coast to coast and everywhere in between. >Our corporate network and org structure is optimized for three regions. We >also have, and continue to grow into, cloud infrastructure and foresee >wanting to bring our own addresses (.e.g., to AWS VPC when that option >becomes available). As such, an obvious design strategy would be to break >the /40 into 4 x /42's. However, due to an imbalance in national site >distribution, 50% of our sites are located in one region (Region A). >Additionally, historical and forecasted growth indicates that it's >perfectly reasonable for us to expect growth of an additional 16 sites in >that same region over the next 3-5 years. Even assuming, as you said: a /48 per hotel, it sounds like you’re planning for: Region A, 45 sites, minimum /42 Region B, <20 sites, minimum /44 Region C, <20 sites, minimum /44 Cloud stuff, minimum /48, but that might need more However, as others have suggested, you might want to start from the bottom, deciding the allocations within each hotel. It may be that you need multiple /48s for HotelGuest, HotelLobby, HotelConference, and HotelStaff SSIDs. A /64 per WiFi AP is an aboslute minimum, but a prefix per room (or guest) would be better, and there are reasons to consider /56 and /48 per “end user” in the hotel. Even if you can’t assign it with current WiFi technology, your address plan should allow for an evolution to a better way of doing things. If my math works right, and you have between 127 and 255 rooms in a hotel: 255 * /56 = /48 just for HotelGuest. You may need a /44 per hotel, if there are four separate networks. Or: 255 * /48 = /40 just for HotelGuest. You may need a /36 per hotel. As others have said, I’m assuming you treat guests to whom you provide Internet service as customers. > >I think the ideal situation is out as ARIN policy wouldn't allow them to >assign us a /36 at this time. Unless someone knows something that can help >us here. Try calling ARIN. Ask a hostmaster whether the End User or ISP category makes more sense in your case. It’s also possible they’ll say “slow start” and give you a /40 for your first hotel, and tell you to return in a week when you need more. But also, take into account [NRPM 6.5.8.2] "Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization’s network and the number of subnets needed to support any extra-large sites defined below.” There’s a lot of room within policy to do sensible things with IPv6. > >Assuming we can't get a /36, my feeling is that less ideal situation #2 is >better than #3 is better than #1 is better than #4, assuming we're >following the following design best-practices: > >a) assign top-level aggregations evenly (which we'd be breaking a bit with >option #2) >b) reduce global routes as much as possible >c) stay on the nibble boundary as much as possible >d) default to /48 per site Yes, all good goals. But none is critical to the success of your network (except c, only if you plan to delegate reverse DNS). “As much as possible” also implies “and no more than is possible.” > >Thanks in advance, >Oliver btw, I can’t wait to stay in your hotels once they have IPv6! I hope you’ll be able to tweet or post here when it’s deployed, so we can congratulate you, and maybe get some conferences to consider you as a venue. Lee From nanog at radu-adrian.feurdean.net Sat Jul 8 16:59:36 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 08 Jul 2017 18:59:36 +0200 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> Message-ID: <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> On Sat, Jul 8, 2017, at 03:06, Owen DeLong wrote: > consider a /48 per guest room as well as a /48 per hotel for the hotel > itself. I think the classfull madness of "/48 everywhere" should stop at some point; the "every subnet is a /64" is enough already. A /48 is 65536 *subnets*, with each subnet having space for what can be considered "unlimited" number of devices. A /56 already is 256 *subnets*. Now please show be a hotel room that has close to 65536 items in it (also tell me how much does a night in such a room cost). Then how many rooms may host close to 256 devices that can transmit and receive data ? And then again, at the end of the day a hotel is *NOT* and ISP, a hotel is a hotel. Internet access is just an extra service that became mandatory lately in order to remain "competitive". From mel at beckman.org Sat Jul 8 17:13:15 2017 From: mel at beckman.org (Mel Beckman) Date: Sat, 8 Jul 2017 17:13:15 +0000 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com>, <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> Message-ID: Radu, Are you assuming that a goal of IPv6 is to efficiently fill subsets? I submit that it is not. There are advantages to sparse address spaces, among them easy mapping of MAC addresses for transition purposes and the security that discourages malefactors from quickly enumerating active devices in a subnet. But that's not the main reason for /64 basic subsets. One of the guiding principles of IPv6 was to not make the mistake of underestimating the future applications of IP addresses. Thus your question "what hotel room has 65536 items in it?" has no meaning in terms of future applications. As you point out, we're not talking about hotel rooms. We don't, by definition, know what we're talking about for future applications. I tell people in my IPv6 classes that we have to stop thinking of ourselves in a spacesuit with a limited air supply that must be rationed, and instead recognize that we're now in a wide-open planet-sized atmosphere where we can breathe freely, and without apportionment. That open atmosphere was by design. It's why IPv6 uses 128-bit addresses, and not 48- or 64-bit. In the exponential space of integers, IPv6 selected a maximum integer that was many orders of magnitude greater than we could ever imagine needing at the time. They're just integers. Not lumps of gold. And there's more where those came from :) -mel beckman > On Jul 8, 2017, at 10:00 AM, Radu-Adrian Feurdean wrote: > >> On Sat, Jul 8, 2017, at 03:06, Owen DeLong wrote: >> consider a /48 per guest room as well as a /48 per hotel for the hotel >> itself. > > I think the classfull madness of "/48 everywhere" should stop at some > point; the "every subnet is a /64" is enough already. > > A /48 is 65536 *subnets*, with each subnet having space for what can be > considered "unlimited" number of devices. > A /56 already is 256 *subnets*. > Now please show be a hotel room that has close to 65536 items in it > (also tell me how much does a night in such a room cost). > Then how many rooms may host close to 256 devices that can transmit and > receive data ? > And then again, at the end of the day a hotel is *NOT* and ISP, a hotel > is a hotel. Internet access is just an extra service that became > mandatory lately in order to remain "competitive". From aaron1 at gvtc.com Sat Jul 8 18:30:56 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Sat, 8 Jul 2017 13:30:56 -0500 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: <001c01d2f818$573f5e80$05be1b80$@gvtc.com> Hi Oliver, et al, I recall from when I attended an ARIN on the Road meeting in Austin last year ( https://www.arin.net/ontheroad/ ), that the folks at ARIN seemed to be open to discussing with you about getting the right size address space into your hands for what you needed to accomplish....within reason...and within justification. I won't speak for ARIN, but I just seem to remember that they were open to talking about it. I don't recall if you said you have actually had dialogue with ARIN about getting the "right" amount of address space to accomplish what you are looking to do. If not, please reach out to them. They've always been helpful and responsive when I've discussed IPv4 and also now, v6 with them. Also, I recall in a v6 online class I did that one point that was made was to not take too much time analyzing, but to get moving with v6. I think Lee just said you should plan on readdressing a few times. Ok, fine. I see that as being possible. You live and you learn. I did find myself last year and earlier this year spending A LOT of time going over and over and over again, the "best" way to carve up my /32 of v6 addresses with fellow engineers. We stopped talking about it for a while... then I came back recently and said guys we gotta settle on something and go for it ! Well, we did and I'm glad. I'm not saying be willy nilly about your v6 space, but settle on something sensible and go for it... then be open to course correcting along the way, and readdress where you must. I've dual staked a few of my cdn public caches, and am talking about dual-stacking 7,000 DSL customers that are currently doing NAT444. v6 is fairly early in my deployment and going fine so far. Btw, I will add that I love my 6VPE. Dang MPLS xVPN's make my life so nice and manageable. You geniuses out there that invent technology are incredible. Keep it up. -Aaron Gould From joly at punkcast.com Sat Jul 8 20:43:51 2017 From: joly at punkcast.com (Joly MacFie) Date: Sat, 8 Jul 2017 16:43:51 -0400 Subject: loc.gov Message-ID: (sorry I'm not on the outage list) Any clues as to what the problem is at the Library of Congress? Appears to be DNS. Is it a DDOS? http://www.loc.gov/ -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From joly at punkcast.com Sat Jul 8 20:47:04 2017 From: joly at punkcast.com (Joly MacFie) Date: Sat, 8 Jul 2017 16:47:04 -0400 Subject: loc.gov In-Reply-To: References: Message-ID: I see http://congress.gov/ is out too. On Sat, Jul 8, 2017 at 4:43 PM, Joly MacFie wrote: > (sorry I'm not on the outage list) > > Any clues as to what the problem is at the Library of Congress? Appears to > be DNS. Is it a DDOS? > > http://www.loc.gov/ > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 <(218)%20565-9365> Skype:punkcast > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From justin at cloudflare.com Sat Jul 8 20:52:51 2017 From: justin at cloudflare.com (Justin Paine) Date: Sat, 8 Jul 2017 20:52:51 +0000 (UTC) Subject: loc.gov In-Reply-To: References: Message-ID: Both loading in SF over Comcast without  issue   _________________________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Sat, Jul 8, 2017 at 1:49 PM -0700, "Joly MacFie" wrote: I see http://congress.gov/ is out too. On Sat, Jul 8, 2017 at 4:43 PM, Joly MacFie wrote: > (sorry I'm not on the outage list) > > Any clues as to what the problem is at the Library of Congress? Appears to > be DNS. Is it a DDOS? > > http://www.loc.gov/ > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 <(218)%20565-9365> Skype:punkcast > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From amitchell at isipp.com Sat Jul 8 20:53:39 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Sat, 8 Jul 2017 14:53:39 -0600 Subject: loc.gov In-Reply-To: References: Message-ID: <79C1C2FB-A22B-4967-AC11-A2E097C922A9@isipp.com> > I see http://congress.gov/ is out too. > > > > On Sat, Jul 8, 2017 at 4:43 PM, Joly MacFie wrote: > >> (sorry I'm not on the outage list) >> >> Any clues as to what the problem is at the Library of Congress? Appears to >> be DNS. Is it a DDOS? >> >> http://www.loc.gov/ These both load for me. Anne Anne P. Mitchell, Esq. 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 Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation 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 nanog at radu-adrian.feurdean.net Sat Jul 8 21:00:33 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 08 Jul 2017 23:00:33 +0200 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> Message-ID: <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> On Sat, Jul 8, 2017, at 19:13, Mel Beckman wrote: > Radu, > > Are you assuming that a goal of IPv6 is to efficiently fill subsets? I No, but I assume IPv6 is still subject to common-sense. > among them easy mapping of MAC addresses for transition purposes and the > security that discourages malefactors from quickly enumerating active > devices in a subnet. I do get all those points. And by the way, try to explain the same to security people. > But that's not the main reason for /64 basic subsets. One of the guiding > principles of IPv6 was to not make the mistake of underestimating the > future applications of IP addresses. Thus your question "what hotel room ... so it went directly to over-estimating .... > has 65536 items in it?" has no meaning in terms of future applications. > As you point out, we're not talking about hotel rooms. We don't, by > definition, know what we're talking about for future applications. All this by forgetting today's applications. And no, you can't possibly treat the same way a hotel room and a 4 floor site with a server room. > I tell people in my IPv6 classes that we have to stop thinking of > ourselves in a spacesuit with a limited air supply that must be rationed, > and instead recognize that we're now in a wide-open planet-sized > atmosphere where we can breathe freely, and without apportionment. Well, by having 64 bits for each subnet, I start lacking bits for other things (like inter-devices connections, ....). I'm not in a space-suit, but I'm on top of Kilimanjaro, where air pressure is only half of what we're used to. > That open atmosphere was by design. It's why IPv6 uses 128-bit addresses, That's for hosts. When you care more about subnets, it's shortened to 64 bits. > They're just integers. Not lumps of gold. Be careful, IPv4 got upgraded from numbers to gold a number of years ago. > And there's more where those came from :) Hopefully. I'm just curious if 8000::/4 will obey today's rules or not. Back to the original question, I find it delirious to treat a small entity the same as a big one, especially when the size difference between the two is several orders of magnitude. Even if we consider "future applications", there's still a very high chance that the size will still matter. Get "the IT guy" of a small company to get used with a /48 for his 20 people, 5 printers and 2-3 servers set-up, then imagine what happens with a design of a "site" 10 or 100 times bigger. This is something that you already see with VLAN ids and RFC1918 space. Even if you think you gave people "as much as they will ever need", they will still end up needing more. From johnl at iecc.com Sat Jul 8 21:55:56 2017 From: johnl at iecc.com (John Levine) Date: 8 Jul 2017 21:55:56 -0000 Subject: loc.gov In-Reply-To: Message-ID: <20170708215556.86356.qmail@ary.lan> In article you write: >http://www.loc.gov/ Works fine for me on Roadrunner in central NY. From mfidelman at meetinghouse.net Sat Jul 8 22:21:08 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 8 Jul 2017 18:21:08 -0400 Subject: loc.gov In-Reply-To: <20170708215556.86356.qmail@ary.lan> References: <20170708215556.86356.qmail@ary.lan> Message-ID: Both work for me in Boston. On 7/8/17 5:55 PM, John Levine wrote: > In article you write: >> http://www.loc.gov/ > Works fine for me on Roadrunner in central NY. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From dougb at dougbarton.us Sat Jul 8 22:47:13 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 8 Jul 2017 15:47:13 -0700 Subject: loc.gov In-Reply-To: References: Message-ID: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Isn't that a problem that suggests its own solution? On 7/8/2017 1:43 PM, Joly MacFie wrote: > (sorry I'm not on the outage list) From joly at punkcast.com Sat Jul 8 22:56:55 2017 From: joly at punkcast.com (Joly MacFie) Date: Sat, 8 Jul 2017 18:56:55 -0400 Subject: loc.gov In-Reply-To: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> References: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Message-ID: Actually, now I go to https://www.nanog.org/list/faq/other I don't see any such thing, just http://www.outages.org/ where the latest report is 2013. Also "See *http://www.isp-lists.com/* for many other topic-specific lists." takes one somewhere else entirely! j On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton wrote: > Isn't that a problem that suggests its own solution? > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > >> (sorry I'm not on the outage list) >> >> -- >> --------------------------------------------------------------- >> Joly MacFie 218 565 9365 Skype:punkcast >> -------------------------------------------------------------- >> - >> > From valdis.kletnieks at vt.edu Sun Jul 9 01:40:01 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 08 Jul 2017 21:40:01 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> Message-ID: <87014.1499564401@turing-police.cc.vt.edu> On Sat, 08 Jul 2017 18:59:36 +0200, "Radu-Adrian Feurdean" said: > Now please show be a hotel room that has close to 65536 items in it > (also tell me how much does a night in such a room cost). > Then how many rooms may host close to 256 devices that can transmit and > receive data ? Well, as I sit here, my apartment edge router gets a /60 from Comcast, and burns through them pretty quick. A subnet for the 4 wired devices, another for the 2.4Ghz wireless, another for 5ghz wireless, and if I enabled them another 2 guest wireless subnets.. and then more for any VLAN I might set up. If I lived in a large enough house, I'm *already* out of enough address space to easily prefix-delegate to a second router at the far end of the house. And yes, this *is* a setup where there's only 1 or 2 devices per most subnets. So no, the idea is *not at all* to see how we can cram as many devices as possible onto a subnet. The idea is to set up a networking environment where it's as easy as possible for even fairly stupid devices to be able to auto-configure and join in. And there's *really* good security reasons for your FizzBin 5000 that wants to be a IoT device but you don't really trust, to end up on a different subnet from your laptop.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nicholas.oas at gmail.com Sun Jul 9 01:41:29 2017 From: nicholas.oas at gmail.com (Nicholas Oas) Date: Sat, 8 Jul 2017 21:41:29 -0400 Subject: loc.gov In-Reply-To: References: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Message-ID: I'd be interested to know the answer to this one as well, as I've gone looking for the outages list in the past and found the same result. Have isitdownorjustme sites simply superceded the need for such lists? On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: > Actually, now I go to https://www.nanog.org/list/faq/other > > I don't see any such thing, just http://www.outages.org/ where the latest > report is 2013. > > Also "See *http://www.isp-lists.com/* for many > other topic-specific lists." takes one somewhere else entirely! > > j > > > > On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton wrote: > > > Isn't that a problem that suggests its own solution? > > > > > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > > > >> (sorry I'm not on the outage list) > >> > >> -- > >> --------------------------------------------------------------- > >> Joly MacFie 218 565 9365 Skype:punkcast > >> -------------------------------------------------------------- > >> - > >> > > > From bill at herrin.us Sun Jul 9 04:38:43 2017 From: bill at herrin.us (William Herrin) Date: Sun, 9 Jul 2017 00:38:43 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: Message-ID: On Fri, Jul 7, 2017 at 8:39 PM, Oliver O'Boyle wrote: > Thanks for the input. I don't consider us an isp, though i suppose i can > see how that argument could me made. Hotels are both simple and > complicated. There is a mix of our staff and equipment, guests and their > equipment, and brands with their equipment. But really it's just one > operating entity that ultimayely isn't that much different than any other > enterprise out there. Now multiply that by 60-65 sites spread across the > country and we need to manage our 6000 staff and networks accordingly. We > operate 100% of the hotel, top to bottom, not just the technology. > > I wouldn't want ARIN or anyone else thinking we were an ISP if we aren't. > Particulary if that creates problems in the future as rules (and possibly > costs) change. > > However, if what you are saying is that registerong as an ISP is actually > the correct way to go about this in ARIN's eyes as well, then that's a > different story. > Hi Oliver, You read to me like a borderline case. It comes up a lot with universities: are they end users or ISPs to their students? ARIN will generally accept either explanation. You'll get the larger number of IPv6 addresses you want if you tell them you're an ISP. The cost difference is likely to remain minimal. The major issue is that as an ISP you'll be expected to enter SWIP records so read up on that. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bortzmeyer at nic.fr Sun Jul 9 13:41:25 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 9 Jul 2017 15:41:25 +0200 Subject: loc.gov In-Reply-To: References: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Message-ID: <20170709134125.GA5358@sources.org> On Sat, Jul 08, 2017 at 09:41:29PM -0400, Nicholas Oas wrote a message of 37 lines which said: > Have isitdownorjustme sites simply superceded the need for such > lists? isitdownorjustme-type sites are very limited: one vantage point, and few (or none) indication of the methodology they use. And there is not only the Web! Networks must be tested with more focused tools, from many places. For exemple RIPE Atlas probes From bjorn at mork.no Sun Jul 9 16:52:43 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 09 Jul 2017 18:52:43 +0200 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> (Radu-Adrian Feurdean's message of "Sat, 08 Jul 2017 23:00:33 +0200") References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> Message-ID: <87d199een8.fsf@miraculix.mork.no> "Radu-Adrian Feurdean" writes: > No, but I assume IPv6 is still subject to common-sense. I don't see how you can make that assumption. If common sense had been applied, then people would have realized that there are more important parameters than address conservation to consider when it comes to IPv6 planning/design/discussions/whatever. Bjørn From damian at google.com Mon Jul 10 02:28:52 2017 From: damian at google.com (Damian Menscher) Date: Sun, 9 Jul 2017 19:28:52 -0700 Subject: loc.gov In-Reply-To: References: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Message-ID: There are two lists, depending on whether you're reporting an ongoing outage, or just talking about one: https://puck.nether.net/mailman/listinfo/outages https://puck.nether.net/mailman/listinfo/outages-discussion Damian On Sat, Jul 8, 2017 at 6:41 PM, Nicholas Oas wrote: > I'd be interested to know the answer to this one as well, as I've gone > looking for the outages list in the past and found the same result. > > Have isitdownorjustme sites simply superceded the need for such lists? > > On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: > > > Actually, now I go to https://www.nanog.org/list/faq/other > > > > I don't see any such thing, just http://www.outages.org/ where the > latest > > report is 2013. > > > > Also "See *http://www.isp-lists.com/* for > many > > other topic-specific lists." takes one somewhere else entirely! > > > > j > > > > > > > > On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton wrote: > > > > > Isn't that a problem that suggests its own solution? > > > > > > > > > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > > > > > >> (sorry I'm not on the outage list) > > >> > > >> -- > > >> --------------------------------------------------------------- > > >> Joly MacFie 218 565 9365 Skype:punkcast > > >> -------------------------------------------------------------- > > >> - > > >> > > > > > > From joly at punkcast.com Mon Jul 10 03:59:30 2017 From: joly at punkcast.com (Joly MacFie) Date: Sun, 9 Jul 2017 23:59:30 -0400 Subject: loc.gov Message-ID: I also noticed an outages-announce - is that for people who don't sub to the other two, or should one do all 3 to be fully notified? j On Sun, Jul 9, 2017 at 10:28 PM, Damian Menscher via NANOG wrote: > There are two lists, depending on whether you're reporting an ongoing > outage, or just talking about one: > > https://puck.nether.net/mailman/listinfo/outages > https://puck.nether.net/mailman/listinfo/outages-discussion > > Damian > > On Sat, Jul 8, 2017 at 6:41 PM, Nicholas Oas > wrote: > > > I'd be interested to know the answer to this one as well, as I've gone > > looking for the outages list in the past and found the same result. > > > > Have isitdownorjustme sites simply superceded the need for such lists? > > > > On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: > > > > > Actually, now I go to https://www.nanog.org/list/faq/other > > > > > > I don't see any such thing, just http://www.outages.org/ where the > > latest > > > report is 2013. > > > > > > Also "See *http://www.isp-lists.com/* for > > many > > > other topic-specific lists." takes one somewhere else entirely! > > > > > > j > > > > > > > > > > > > On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton > wrote: > > > > > > > Isn't that a problem that suggests its own solution? > > > > > > > > > > > > > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > > > > > > > >> (sorry I'm not on the outage list) > > > >> > > > >> -- > > > >> --------------------------------------------------------------- > > > >> Joly MacFie 218 565 9365 Skype:punkcast > > > >> -------------------------------------------------------------- > > > >> - > > > >> > > > > > > > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From virendra.rode at gmail.com Mon Jul 10 05:18:59 2017 From: virendra.rode at gmail.com (virendra rode) Date: Sun, 9 Jul 2017 22:18:59 -0700 Subject: loc.gov In-Reply-To: References: Message-ID: Hi, No, that's for changes and updates related to the list. I would stick with w/ outages@ and outages-discussion@ as mentioned below. outages at outages.org - Warnings of (un)planned outages and reports of observed current outages outages-discussion at outages.org - Discussion about post outages (troubleshooting, analysis, post-mortem, venting, etc). outages-announce at outages.org - Change management and future updates related to the lists. --- regards, /vrode > On Jul 9, 2017, at 8:59 PM, Joly MacFie wrote: > > I also noticed an outages-announce - is that for people who don't sub to > the other two, or should one do all 3 to be fully notified? > > j > > > > On Sun, Jul 9, 2017 at 10:28 PM, Damian Menscher via NANOG > wrote: > >> There are two lists, depending on whether you're reporting an ongoing >> outage, or just talking about one: >> >> https://puck.nether.net/mailman/listinfo/outages >> https://puck.nether.net/mailman/listinfo/outages-discussion >> >> Damian >> >> On Sat, Jul 8, 2017 at 6:41 PM, Nicholas Oas >> wrote: >> >>> I'd be interested to know the answer to this one as well, as I've gone >>> looking for the outages list in the past and found the same result. >>> >>> Have isitdownorjustme sites simply superceded the need for such lists? >>> >>>> On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: >>>> >>>> Actually, now I go to https://www.nanog.org/list/faq/other >>>> >>>> I don't see any such thing, just http://www.outages.org/ where the >>> latest >>>> report is 2013. >>>> >>>> Also "See *http://www.isp-lists.com/* for >>> many >>>> other topic-specific lists." takes one somewhere else entirely! >>>> >>>> j >>>> >>>> >>>> >>>> On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton >> wrote: >>>> >>>>> Isn't that a problem that suggests its own solution? >>>>> >>>>> >>>>> >>>>>> On 7/8/2017 1:43 PM, Joly MacFie wrote: >>>>>> >>>>>> (sorry I'm not on the outage list) >>>>>> >>>>>> -- >>>>>> --------------------------------------------------------------- >>>>>> Joly MacFie 218 565 9365 Skype:punkcast >>>>>> -------------------------------------------------------------- >>>>>> - >>>>>> >>>>> >>>> >>> >> > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > -------------------------------------------------------------- > - From faisal at snappytelecom.net Mon Jul 10 05:35:01 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 10 Jul 2017 05:35:01 +0000 (GMT) Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: References: <58c65726-ae9e-3e3d-921a-9fa27275c967@jima.us> Message-ID: <1673753992.2748647.1499664901690.JavaMail.zimbra@snappytelecom.net> > Agreed with the /48 but ARIN doesn't appear to agree with our justification > for a /36 thus far. > > I am not sure how you have been communicating with ARIN, my experience with them strongly suggest that after you put in your request, pickup the phone and call them, speak to the analyst assigned to your request.. Have a polite conversation with them, and ask them .. how to go about accomplishing what you are needing... You are going to be in for a very pleasant surprise. Regards. Faisal Imtiaz Snappy Internet & Telecom From bellman at nsc.liu.se Mon Jul 10 09:33:03 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Mon, 10 Jul 2017 11:33:03 +0200 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> Message-ID: <596349CF.9000709@nsc.liu.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2017-07-08 23:00, Radu-Adrian Feurdean wrote: > On Sat, Jul 8, 2017, at 19:13, Mel Beckman wrote: >> That open atmosphere was by design. It's why IPv6 uses 128-bit addresses, > > That's for hosts. When you care more about subnets, it's shortened to 64 > bits. Indeed. Especielly if you do hierarchical delegation within your organization, you will often have sparse allocations at several levels. A /48 for an organization might seem like reasonably lots with 65536 subnets, but if that organization in turn delegates to departments, and they have more than 16 departments, each department might only get a /56 (256 subnets). Try to delegate that one step further, and you can't do any reasonable allocation strategy, but have to allocate subnet by subnet. I managed to get a full /52 from our host university, but they initially wanted to give us only a /56. Of course, they can only give out a few /52:s; other departments will have less structured address plans than us. - -- Thomas Bellman, National Supercomputer Centre, Linköping Univ., Sweden "Life IS pain, highness. Anyone who tells ! bellman @ nsc . liu . se differently is selling something." ! Make Love -- Nicht Wahr! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZY0nPAAoJEGqUdKqa3HTs7GoQAKK0EmX/p/FO+TEIf8d2p1jL yNM1awpOwa3EyulVhtSFNY/vROrXny5IhY1ikKmWftvDF54629KM1G72ZGtfgsWd I6is2jUef7ZA5KLjkEd2UUVc2y/PPZ/KDG6aLABFIGPDYMSzXnVLJwTi8HWZrhWw XoV1IN+xQkp1bAWTVEmWiPyL+y4ee0pfgvJm3GjgHJwFIusJX5+ia6UXcPTZKNFL tBMNJDx8hq2d28V9oJ7dIIjgWeHgKxpyuMcRNyG1Bn5AJ5rF+mQvllEq4ea+um6z IkHF4c7Atfi9p4ueY66uAMLuzt2tAkuIKqct8K8KHwDtcKcHHdK03+717V6KBQGS tLKdAoOUEGEFumUujkE39CJyVMUapY6njX5aObmH4hBm6H1Nk8kZFje0IlEvfMU+ uY5FuEC6VNBWwmHN6g25izsRC+DynA2kA/vlCNsT9eZkQ91KW3HRoFTutGr9qs14 7nGdxVWV6azkFR3gJIHH8epIYqisMiQS5uquJmUBkFLhxfz+6zI5p6QJe+kIakyc GkyP7oAps8HbT3YcPcRRKhyhVvhx9yWjkP1emXZD7mgENriANFrawIVb5719dsAV QkYV7SfvDZQJCN7TR3u4se5Zd3XcdmnkQhoVAyjesUDFc1Krbhi8aVkUGv/3Aznu 5GwFW7AH9iuAUVP3XfkV =HKC1 -----END PGP SIGNATURE----- From president at isoc-ny.org Sat Jul 8 20:58:48 2017 From: president at isoc-ny.org (Joly MacFie) Date: Sat, 8 Jul 2017 16:58:48 -0400 Subject: loc.gov In-Reply-To: <79C1C2FB-A22B-4967-AC11-A2E097C922A9@isipp.com> References: <79C1C2FB-A22B-4967-AC11-A2E097C922A9@isipp.com> Message-ID: Oh yes, seems to be fixed. It was a fairly lengthy outage. On Sat, Jul 8, 2017 at 4:53 PM, Anne P. Mitchell Esq. wrote: > > > > > I see http://congress.gov/ is out too. > > > > > > > > On Sat, Jul 8, 2017 at 4:43 PM, Joly MacFie wrote: > > > >> (sorry I'm not on the outage list) > >> > >> Any clues as to what the problem is at the Library of Congress? Appears > to > >> be DNS. Is it a DDOS? > >> > >> http://www.loc.gov/ > > These both load for me. > > Anne > > Anne P. Mitchell, Esq. > 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 > Member, California Bar Cyberspace Law Committee > Member, Colorado Cybersecurity Consortium > Member, Elevations Credit Union Member Council > Member, Board of Directors, Asilomar Microcomputer Workshop > Member, Board of Directors, Greenwood Wildlife Rehabilitation > 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 > > > -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From president at isoc-ny.org Sat Jul 8 22:13:30 2017 From: president at isoc-ny.org (Joly MacFie) Date: Sat, 8 Jul 2017 18:13:30 -0400 Subject: loc.gov In-Reply-To: <20170708215556.86356.qmail@ary.lan> References: <20170708215556.86356.qmail@ary.lan> Message-ID: http://www.isitdownrightnow.com/loc.gov.html It was out for about 45 mins AFAICT On Sat, Jul 8, 2017 at 5:55 PM, John Levine wrote: > In article mail.gmail.com> you write: > >http://www.loc.gov/ > > Works fine for me on Roadrunner in central NY. > > -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From nanog at shat.net Sun Jul 9 02:06:59 2017 From: nanog at shat.net (Shaun) Date: Sat, 08 Jul 2017 21:06:59 -0500 Subject: loc.gov In-Reply-To: References: Message-ID: <20170708210657.75E9.B2447BB2@shat.net> The outages.org website appears to be stale, but the mailing list is alive and well. Subscription and archives are at: -s On Sat, 8 Jul 2017 21:41:29 -0400 Nicholas Oas wrote: > I'd be interested to know the answer to this one as well, as I've gone > looking for the outages list in the past and found the same result. > > Have isitdownorjustme sites simply superceded the need for such lists? > > On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: > > > Actually, now I go to https://www.nanog.org/list/faq/other > > > > I don't see any such thing, just http://www.outages.org/ where the latest > > report is 2013. > > > > Also "See *http://www.isp-lists.com/* for many > > other topic-specific lists." takes one somewhere else entirely! > > > > j > > > > > > > > On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton wrote: > > > > > Isn't that a problem that suggests its own solution? > > > > > > > > > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > > > > > >> (sorry I'm not on the outage list) > > >> > > >> -- > > >> --------------------------------------------------------------- > > >> Joly MacFie 218 565 9365 Skype:punkcast > > >> -------------------------------------------------------------- > > >> - > > >> > > > > > From mitch at basejp.com Sun Jul 9 02:52:25 2017 From: mitch at basejp.com (Mitchell Kuch) Date: Sat, 8 Jul 2017 22:52:25 -0400 Subject: loc.gov In-Reply-To: References: <77898c17-0091-c2bc-a511-b184869f4709@dougbarton.us> Message-ID: <5CB248C5-ED45-4CFA-8EA4-96BEE28C38B1@basejp.com> https://puck.nether.net/mailman/listinfo/outages https://puck.nether.net/mailman/listinfo/outages-discussion - - Mitchell (sent mobile) > On Jul 8, 2017, at 21:44, Nicholas Oas wrote: > > I'd be interested to know the answer to this one as well, as I've gone > looking for the outages list in the past and found the same result. > > Have isitdownorjustme sites simply superceded the need for such lists? > >> On Jul 8, 2017 6:59 PM, "Joly MacFie" wrote: >> >> Actually, now I go to https://www.nanog.org/list/faq/other >> >> I don't see any such thing, just http://www.outages.org/ where the latest >> report is 2013. >> >> Also "See *http://www.isp-lists.com/* for many >> other topic-specific lists." takes one somewhere else entirely! >> >> j >> >> >> >>> On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton wrote: >>> >>> Isn't that a problem that suggests its own solution? >>> >>> >>> >>>> On 7/8/2017 1:43 PM, Joly MacFie wrote: >>>> >>>> (sorry I'm not on the outage list) >>>> >>>> -- >>>> --------------------------------------------------------------- >>>> Joly MacFie 218 565 9365 Skype:punkcast >>>> -------------------------------------------------------------- From marka at isc.org Tue Jul 11 03:09:39 2017 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Jul 2017 13:09:39 +1000 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: Your message of "Mon, 10 Jul 2017 11:33:03 +0200." <596349CF.9000709@nsc.liu.se> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> <596349CF.9000709@nsc.liu.se> Message-ID: <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> In message <596349CF.9000709 at nsc.liu.se>, Thomas Bellman writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2017-07-08 23:00, Radu-Adrian Feurdean wrote: > > > On Sat, Jul 8, 2017, at 19:13, Mel Beckman wrote: > > >> That open atmosphere was by design. It's why IPv6 uses 128-bit addresses, > > > > That's for hosts. When you care more about subnets, it's shortened to 64 > > bits. > > Indeed. Especielly if you do hierarchical delegation within your > organization, you will often have sparse allocations at several > levels. A /48 for an organization might seem like reasonably lots > with 65536 subnets, but if that organization in turn delegates to > departments, and they have more than 16 departments, each department > might only get a /56 (256 subnets). If I had 32 departments and were wanting to give them equal sized allocations then I'd give them a /53 each which is 2064 subnets each. It isn't that hard to do 8 delegations in the reverse tree for each of the 32 departments. Delegation on nibble boundaries is for convience and nothing else. Or you could start with a /56 each and reserve the next 7 /56s for each department to grow into. > Try to delegate that one step > further, and you can't do any reasonable allocation strategy, but > have to allocate subnet by subnet. Of which the only downside is that it is harder to do internal firewalls between departments or if you want to do cost recovery of external traffic to departments. The DHCPv6 servers also need to learn where to get additional subnets from to fulfill PD requests. Remember a site can have more than one /48. Thats just the recommended starting point. > I managed to get a full /52 from our host university, but they > initially wanted to give us only a /56. Of course, they can only > give out a few /52:s; other departments will have less structured > address plans than us. > > > - -- > Thomas Bellman, National Supercomputer Centre, Linköping Univ., Sweden > "Life IS pain, highness. Anyone who tells ! bellman @ nsc . liu . se > differently is selling something." ! Make Love -- Nicht Wahr! > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJZY0nPAAoJEGqUdKqa3HTs7GoQAKK0EmX/p/FO+TEIf8d2p1jL > yNM1awpOwa3EyulVhtSFNY/vROrXny5IhY1ikKmWftvDF54629KM1G72ZGtfgsWd > I6is2jUef7ZA5KLjkEd2UUVc2y/PPZ/KDG6aLABFIGPDYMSzXnVLJwTi8HWZrhWw > XoV1IN+xQkp1bAWTVEmWiPyL+y4ee0pfgvJm3GjgHJwFIusJX5+ia6UXcPTZKNFL > tBMNJDx8hq2d28V9oJ7dIIjgWeHgKxpyuMcRNyG1Bn5AJ5rF+mQvllEq4ea+um6z > IkHF4c7Atfi9p4ueY66uAMLuzt2tAkuIKqct8K8KHwDtcKcHHdK03+717V6KBQGS > tLKdAoOUEGEFumUujkE39CJyVMUapY6njX5aObmH4hBm6H1Nk8kZFje0IlEvfMU+ > uY5FuEC6VNBWwmHN6g25izsRC+DynA2kA/vlCNsT9eZkQ91KW3HRoFTutGr9qs14 > 7nGdxVWV6azkFR3gJIHH8epIYqisMiQS5uquJmUBkFLhxfz+6zI5p6QJe+kIakyc > GkyP7oAps8HbT3YcPcRRKhyhVvhx9yWjkP1emXZD7mgENriANFrawIVb5719dsAV > QkYV7SfvDZQJCN7TR3u4se5Zd3XcdmnkQhoVAyjesUDFc1Krbhi8aVkUGv/3Aznu > 5GwFW7AH9iuAUVP3XfkV > =HKC1 > -----END PGP SIGNATURE----- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bjorn at mork.no Tue Jul 11 11:01:01 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 11 Jul 2017 13:01:01 +0200 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> (Mark Andrews's message of "Tue, 11 Jul 2017 13:09:39 +1000") References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> <596349CF.9000709@nsc.liu.se> <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> Message-ID: <87inizb5le.fsf@miraculix.mork.no> Mark Andrews writes: > If I had 32 departments and were wanting to give them equal sized > allocations then I'd give them a /53 each which is 2064 subnets > each. It isn't that hard to do 8 delegations in the reverse tree > for each of the 32 departments. Delegation on nibble boundaries > is for convience and nothing else. I believe you under-estimate the importance of sysadmin convenience... Yes, you *can* do 8 delegations. And you are of course right - it's not even hard. But it does come with a "less convenient" price tag, so you'd better get something back. What was that, exactly? Right, you saved a /48. Big deal. Bjørn From bill at herrin.us Tue Jul 11 13:55:00 2017 From: bill at herrin.us (William Herrin) Date: Tue, 11 Jul 2017 09:55:00 -0400 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> <596349CF.9000709@nsc.liu.se> <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> Message-ID: On Mon, Jul 10, 2017 at 11:09 PM, Mark Andrews wrote: > If I had 32 departments and were wanting to give them equal sized > allocations then I'd give them a /53 each which is 2064 subnets > each. It isn't that hard to do 8 delegations in the reverse tree > for each of the 32 departments. Delegation on nibble boundaries > is for convience and nothing else. > For comprehensibility which nets convenience. Consistently delegate on nibble boundaries and your power users don't have to understand Boolean algebra to make sense of the network. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Tue Jul 11 14:25:17 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 12 Jul 2017 00:25:17 +1000 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: Your message of "Tue, 11 Jul 2017 09:55:00 -0400." References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> <596349CF.9000709@nsc.liu.se> <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> Message-ID: <20170711142517.676307E64536@rock.dv.isc.org> In message , William Herrin writes: > On Mon, Jul 10, 2017 at 11:09 PM, Mark Andrews wrote: > > > If I had 32 departments and were wanting to give them equal sized > > allocations then I'd give them a /53 each which is 2064 subnets > > each. It isn't that hard to do 8 delegations in the reverse tree > > for each of the 32 departments. Delegation on nibble boundaries > > is for convience and nothing else. > > For comprehensibility which nets convenience. Consistently delegate on > nibble boundaries and your power users don't have to understand Boolean > algebra to make sense of the network. Hexadecimal is much much simpler than decimal to work with on non nibble/octet boundaries. I think most people are applying IPv4 non octet experience to non nibble IPv6 addressing. The two are nowhere near comparable having had to work with both. > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From craigwashington01 at hotmail.com Mon Jul 10 20:12:05 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Mon, 10 Jul 2017 20:12:05 +0000 Subject: BGP peering question Message-ID: Hello, Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someone from an ISP point of view. Thanks. From patrick at ianai.net Tue Jul 11 16:52:03 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 Jul 2017 12:52:03 -0400 Subject: BGP peering question In-Reply-To: References: Message-ID: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> 1) Are they present an IX where I am present? 2) Can they configure BGP correctly? 3) … Beer? Private interconnect requires actual thinking. Putting a procedure in around public peering is just overhead we don’t need. -- TTFN, patrick > On Jul 10, 2017, at 4:12 PM, craig washington wrote: > > Hello, > > > Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someone from an ISP point of view. > > > Thanks. > > From bryan at shout.net Tue Jul 11 17:28:11 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 11 Jul 2017 12:28:11 -0500 Subject: BGP peering question In-Reply-To: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> Message-ID: Also worth looking at your telemetries to see if it makes sense from an inbound/outbound point of view. That is, you'll get more bang for your buck if you're eyeballs and peering with a content provider (or vice versa), as opposed to eyeballs <-> eyeballs or content <-> content. On 7/11/17 11:52 AM, Patrick W. Gilmore wrote: > 1) Are they present an IX where I am present? > > 2) Can they configure BGP correctly? > > 3) … Beer? > > Private interconnect requires actual thinking. Putting a procedure in around public peering is just overhead we don’t need. > From bill at herrin.us Tue Jul 11 17:33:54 2017 From: bill at herrin.us (William Herrin) Date: Tue, 11 Jul 2017 13:33:54 -0400 Subject: BGP peering question In-Reply-To: References: Message-ID: On Mon, Jul 10, 2017 at 4:12 PM, craig washington < craigwashington01 at hotmail.com> wrote: > Newbie question, what criteria do you look for when you decide that you > want to peer with someone or if you will accept peering with someone from > an ISP point of view. I assume you mean "reciprocal peering" in the sense of shortcut from your customers to their customers rather than the more generic sense that any BGP neighbor is a "peer". 1. What does it cost? If you and they are already on an IX peering switch or you're both at a relaxed location where running another cable carries no monthly fee, there's not much down side. 2. Is the improvement to your service worth the cost? It's not worth buying a data circuit or cross-connect to support a 100kbps trickle. 3. Do you have the technical acumen to stay on top of it? Some kinds of breakage in the peering link could jam traffic between your customers and theirs. If you're not able to notice and respond, you'd be better off sending the traffic up to your ISPs and letting them worry about it. If the three of those add up to "yes" instead of "no" then peering may be smart. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From niels=nanog at bakker.net Tue Jul 11 17:48:30 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 11 Jul 2017 19:48:30 +0200 Subject: BGP peering question In-Reply-To: References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> Message-ID: <20170711174830.GN86663@excession.tpb.net> * bryan at shout.net (Bryan Holloway) [Tue 11 Jul 2017, 19:28 CEST]: >Also worth looking at your telemetries to see if it makes sense from >an inbound/outbound point of view. > >That is, you'll get more bang for your buck if you're eyeballs and >peering with a content provider (or vice versa), as opposed to >eyeballs <-> eyeballs or content <-> content. Luckily these are not exclusionary so you can peer with all networks present at an Internet exchange with no repercussions. -- Niels. From bob at FiberInternetCenter.com Tue Jul 11 18:17:03 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 11 Jul 2017 11:17:03 -0700 Subject: BGP peering question In-Reply-To: References: Message-ID: There is one more thing to consider based on your app or content latency criteria needs. Do you provide a service that performs better with low latency - such as live desktop, live video/voice. You may wish to peer to have more control and more direct path to your customer base. If you identify your customer base in a specific region - then explore the best peering exchange points to utilize in that region. This can help you reduce your packet hop count/ deliver time, etc. etc.. Thank You Bob Evans CTO > On Mon, Jul 10, 2017 at 4:12 PM, craig washington < > craigwashington01 at hotmail.com> wrote: > >> Newbie question, what criteria do you look for when you decide that you >> want to peer with someone or if you will accept peering with someone >> from >> an ISP point of view. > > > I assume you mean "reciprocal peering" in the sense of shortcut from your > customers to their customers rather than the more generic sense that any > BGP neighbor is a "peer". > > 1. What does it cost? If you and they are already on an IX peering switch > or you're both at a relaxed location where running another cable carries > no > monthly fee, there's not much down side. > > 2. Is the improvement to your service worth the cost? It's not worth > buying > a data circuit or cross-connect to support a 100kbps trickle. > > 3. Do you have the technical acumen to stay on top of it? Some kinds of > breakage in the peering link could jam traffic between your customers and > theirs. If you're not able to notice and respond, you'd be better off > sending the traffic up to your ISPs and letting them worry about it. > > If the three of those add up to "yes" instead of "no" then peering may be > smart. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From edee at globalvision.net Tue Jul 11 18:40:55 2017 From: edee at globalvision.net (Ethan E. Dee) Date: Tue, 11 Jul 2017 14:40:55 -0400 Subject: BGP peering question In-Reply-To: References: Message-ID: <1d29ab62-db05-2a89-1426-4f9360cfebc0@globalvision.net> Considering the wording you use, I would include this, 'Peering' is not always necessary. If you can get an upstream provider to give you a pack of IP's and it is sufficient to just use them as a gateway instead of setting up peering that would be preferred. If you decide you want to have multiple upstream providers or hit some kind of speed cap is when I would probably peer with someone else. So that you can keep your IP space but share it across a redundant connection from a different provider. Then you need to decide if you want to be a hop between those two peers or if you want them to serve you only. You can change your routing so that both providers know of your routes but you are not sharing routes between the two providers. BGP is an enormous protocol and extremely scalable so there is alot to consider before you even decide if you want to peer. Because it can sometimes be a headache to setup. On 07/11/2017 02:17 PM, Bob Evans wrote: > There is one more thing to consider based on your app or content latency > criteria needs. Do you provide a service that performs better with low > latency - such as live desktop, live video/voice. You may wish to peer to > have more control and more direct path to your customer base. If you > identify your customer base in a specific region - then explore the best > peering exchange points to utilize in that region. This can help you > reduce your packet hop count/ deliver time, etc. etc.. > > Thank You > Bob Evans > CTO > > > > >> On Mon, Jul 10, 2017 at 4:12 PM, craig washington < >> craigwashington01 at hotmail.com> wrote: >> >>> Newbie question, what criteria do you look for when you decide that you >>> want to peer with someone or if you will accept peering with someone >>> from >>> an ISP point of view. >> >> I assume you mean "reciprocal peering" in the sense of shortcut from your >> customers to their customers rather than the more generic sense that any >> BGP neighbor is a "peer". >> >> 1. What does it cost? If you and they are already on an IX peering switch >> or you're both at a relaxed location where running another cable carries >> no >> monthly fee, there's not much down side. >> >> 2. Is the improvement to your service worth the cost? It's not worth >> buying >> a data circuit or cross-connect to support a 100kbps trickle. >> >> 3. Do you have the technical acumen to stay on top of it? Some kinds of >> breakage in the peering link could jam traffic between your customers and >> theirs. If you're not able to notice and respond, you'd be better off >> sending the traffic up to your ISPs and letting them worry about it. >> >> If the three of those add up to "yes" instead of "no" then peering may be >> smart. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > -- Ethan Dee Network Admin Globalvision 864 704 3600 edee at globalvision.net For Support: Gv-support at globalvision.net 864 467 1333 For Sales: Sales at globalvision.net 864 467 1333 From nick at foobar.org Tue Jul 11 19:19:11 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 Jul 2017 20:19:11 +0100 Subject: BGP peering question In-Reply-To: References: Message-ID: <596524AF.90001@foobar.org> craig washington wrote: > Newbie question, what criteria do you look for when you decide that > you want to peer with someone or if you will accept peering with > someone from an ISP point of view. If you're new to the game, peer with everyone you can and use route servers aggressively. You have nothing to lose and everything to gain. At the point at which you have a medium sized network, in the sense of maintaining multiple peering points, PNIs, transit customers, and tens to hundreds of gigs of traffic (i.e. the stage at which you actually have to think a bit about your traffic routing policies), you might want to consider whether it's worth your while peering with smaller players and also whether whether route servers are still a good fit for your business requirements. If you are very large, the rules are completely different and will depend entirely on your business model. Some organisations thrive on open interconnection models; others prefer to be highly selective. Nick From patrick at ianai.net Tue Jul 11 19:24:05 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 Jul 2017 15:24:05 -0400 Subject: BGP peering question In-Reply-To: <1d29ab62-db05-2a89-1426-4f9360cfebc0@globalvision.net> References: <1d29ab62-db05-2a89-1426-4f9360cfebc0@globalvision.net> Message-ID: <8380838D-E7CC-490B-8011-8AA3476C0253@ianai.net> > Then you need to decide if you want to be a hop between those two peers or if you want them to serve you only. You can change your routing so that both providers know of your routes but you are not sharing routes between the two providers. The definition of “peering” to most ISPs would definitely not include becoming a “hop” between two peers. Most networks would de-peer you if you sent their prefixes to another peer. -- TTFN, patrick > On Jul 11, 2017, at 2:40 PM, Ethan E. Dee wrote: > > Considering the wording you use, I would include this, > > 'Peering' is not always necessary. If you can get an upstream provider to give you a pack of IP's and it is sufficient to just use them as a gateway instead of setting up peering that would be preferred. > > If you decide you want to have multiple upstream providers or hit some kind of speed cap is when I would probably peer with someone else. So that you can keep your IP space but share it across a redundant connection from a different provider. > > Then you need to decide if you want to be a hop between those two peers or if you want them to serve you only. You can change your routing so that both providers know of your routes but you are not sharing routes between the two providers. > > BGP is an enormous protocol and extremely scalable so there is alot to consider before you even decide if you want to peer. > > Because it can sometimes be a headache to setup. > > > On 07/11/2017 02:17 PM, Bob Evans wrote: >> There is one more thing to consider based on your app or content latency >> criteria needs. Do you provide a service that performs better with low >> latency - such as live desktop, live video/voice. You may wish to peer to >> have more control and more direct path to your customer base. If you >> identify your customer base in a specific region - then explore the best >> peering exchange points to utilize in that region. This can help you >> reduce your packet hop count/ deliver time, etc. etc.. >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> On Mon, Jul 10, 2017 at 4:12 PM, craig washington < >>> craigwashington01 at hotmail.com> wrote: >>> >>>> Newbie question, what criteria do you look for when you decide that you >>>> want to peer with someone or if you will accept peering with someone >>>> from >>>> an ISP point of view. >>> >>> I assume you mean "reciprocal peering" in the sense of shortcut from your >>> customers to their customers rather than the more generic sense that any >>> BGP neighbor is a "peer". >>> >>> 1. What does it cost? If you and they are already on an IX peering switch >>> or you're both at a relaxed location where running another cable carries >>> no >>> monthly fee, there's not much down side. >>> >>> 2. Is the improvement to your service worth the cost? It's not worth >>> buying >>> a data circuit or cross-connect to support a 100kbps trickle. >>> >>> 3. Do you have the technical acumen to stay on top of it? Some kinds of >>> breakage in the peering link could jam traffic between your customers and >>> theirs. If you're not able to notice and respond, you'd be better off >>> sending the traffic up to your ISPs and letting them worry about it. >>> >>> If the three of those add up to "yes" instead of "no" then peering may be >>> smart. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>> Dirtside Systems ......... Web: >>> >> > > -- > Ethan Dee > Network Admin > Globalvision > 864 704 3600 > edee at globalvision.net > > For Support: > Gv-support at globalvision.net > 864 467 1333 > > For Sales: > Sales at globalvision.net > 864 467 1333 From bill at herrin.us Tue Jul 11 19:37:26 2017 From: bill at herrin.us (William Herrin) Date: Tue, 11 Jul 2017 15:37:26 -0400 Subject: BGP peering question In-Reply-To: <8380838D-E7CC-490B-8011-8AA3476C0253@ianai.net> References: <1d29ab62-db05-2a89-1426-4f9360cfebc0@globalvision.net> <8380838D-E7CC-490B-8011-8AA3476C0253@ianai.net> Message-ID: On Tue, Jul 11, 2017 at 3:24 PM, Patrick W. Gilmore wrote: > > Then you need to decide if you want to be a hop between those two peers > or if you want them to serve you only. You can change your routing so that > both providers know of your routes but you are not sharing routes between > the two providers. > > The definition of “peering” to most ISPs would definitely not include > becoming a “hop” between two peers. Most networks would de-peer you if you > sent their prefixes to another peer. > Hi Patrick, I'm given to understand this practice is common in service providers connecting academia. Three or more service providers serving schools will agree to pass packets even if neither school terminates at the current ISP. This comes up in the discussion of "valley free" inter-domain routing because it's one of the cases that forms a valley where the participating organization is not paid for or directly donating the transiting packets. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nick at foobar.org Tue Jul 11 19:43:47 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 Jul 2017 20:43:47 +0100 Subject: BGP peering question In-Reply-To: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> Message-ID: <59652A73.8000602@foobar.org> Patrick W. Gilmore wrote: > 1) Are they present an IX where I am present? > > 2) Can they configure BGP correctly? > > 3) … Beer? Naah, way overthought. I prefer the traditional: 1) do they have a pulse? Nick From aaron1 at gvtc.com Wed Jul 12 02:21:31 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 11 Jul 2017 21:21:31 -0500 Subject: Some advice on IPv6 planning and ARIN request, please In-Reply-To: <20170711142517.676307E64536@rock.dv.isc.org> References: <7AC5F42F-560B-478B-920A-7260444613A9@delong.com> <1499533176.1218123.1034510496.04DD50F1@webmail.messagingengine.com> <1499547633.1276091.1034540536.04D82DA7@webmail.messagingengine.com> <596349CF.9000709@nsc.liu.se> <20170711030939.C7DC37E4D5A9@rock.dv.isc.org> <20170711142517.676307E64536@rock.dv.isc.org> Message-ID: <000101d2fab5$93b01220$bb103660$@gvtc.com> Hence my mention of thinking it was a "sin" to subnet on the bit boundary in v6... again, I will do my best to never go back to bit boundary subnetting math in my v6 deployment. Actually, you folks are giving me bad flashbacks to my ATM H-PNNI days of pnni peer group nsap address subnetting. Oh how nice it was to view the atm switch nsap prefix in hex and view the peer group level's at the hex boundary until we got to a place where we needed to get a 4th level from 96-104.... I recall going with 98... we had to do bit boundary pnni level 98... I don't want to have to do that with v6 if I can avoid it -Aaron From large.hadron.collider at gmx.com Wed Jul 12 02:57:22 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Tue, 11 Jul 2017 19:57:22 -0700 Subject: Hacked DVRs again?! (Probably the wrong forum, but probably of interest nonetheless) Message-ID: <838a7912-0661-0297-5a8e-eb6092c7f288@gmx.com> So, I run a small chat service and it has attracted abuse from multiple kinds of open device. Most recently, I've found DVRs being spammed through. This is the kind of "default password"/"open Cisco" abuse that is very hard to detect with an open proxy scanner without, well, logging in and seeing if you get a shell. Has anyone ever seen this? What can I do to prevent it? From wolfgang.tremmel at de-cix.net Wed Jul 12 07:13:17 2017 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Wed, 12 Jul 2017 07:13:17 +0000 Subject: BGP peering question In-Reply-To: <59652A73.8000602@foobar.org> References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> <59652A73.8000602@foobar.org> Message-ID: <0ED3AF25-E50C-4303-B26D-95E6D041D7CF@de-cix.net> > On 11. Jul 2017, at 21:43, Nick Hilliard wrote: > > Patrick W. Gilmore wrote: >> 1) Are they present an IX where I am present? >> >> 2) Can they configure BGP correctly? >> >> 3) … Beer? > > > 1) do they have a pulse? 4 ) are they in PeeringDB and keep their entry up to date? (especially the contact information) cheers, Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From tore at fud.no Wed Jul 12 18:13:56 2017 From: tore at fud.no (Tore Anderson) Date: Wed, 12 Jul 2017 20:13:56 +0200 Subject: BGP peering question In-Reply-To: References: Message-ID: <06d52f2c-d1ed-0fa3-70f8-33abc180b916@fud.no> * craig washington > Newbie question, what criteria do you look for when you decide that > you want to peer with someone or if you will accept peering with > someone from an ISP point of view. Routing hygiene. I expect the would-be peer to keep the number of advertised routes that are either 1) not registered in RIPE/RADB, 2) disaggregated, or 3) redundant (i.e., more-specifics of larger advertisements) to an absolute minimum. Tore From opentext.dhofstee at gmail.com Wed Jul 12 10:18:47 2017 From: opentext.dhofstee at gmail.com (David Hofstee) Date: Wed, 12 Jul 2017 12:18:47 +0200 Subject: BGP peering question In-Reply-To: <0ED3AF25-E50C-4303-B26D-95E6D041D7CF@de-cix.net> References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> <59652A73.8000602@foobar.org> <0ED3AF25-E50C-4303-B26D-95E6D041D7CF@de-cix.net> Message-ID: I would state that peering gives more control over the traffic you handle (since it is not going over someone else's network). Every hop is a possible problem to your operations, I guess. David On 12 July 2017 at 09:13, Wolfgang Tremmel wrote: > > > On 11. Jul 2017, at 21:43, Nick Hilliard wrote: > > > > Patrick W. Gilmore wrote: > >> 1) Are they present an IX where I am present? > >> > >> 2) Can they configure BGP correctly? > >> > >> 3) … Beer? > > > > > > 1) do they have a pulse? > > 4 ) are they in PeeringDB and keep their entry up to date? (especially the > contact information) > > cheers, > Wolfgang > > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 > | wolfgang.tremmel at de-cix.net > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | > Germany | www.de-cix.net > > > -- -- My opinion is mine. From shacolby at gmail.com Wed Jul 12 18:03:50 2017 From: shacolby at gmail.com (ShaColby Jackson) Date: Wed, 12 Jul 2017 11:03:50 -0700 Subject: noction vs border6 vs kentik vs fcp vs ? Message-ID: I know this topic has gone around a couple times but wondering if there are any new strong opinions on inbound+outbound traffic analysis with a bonus for excellence in traffic engineering at the edge. A typical use case would be finding an AS or prefix representing a large volume of inbound and/or outbound traffic via provider A that could just as well or better be moved via provider B. I know solutions like Kentik do a lot more but I’m focusing on just the above use case. Also ignoring the cloud vs. on-prem difference, assume that doesn’t matter. Will reward any helpful advice with a picture of me give you a virtual high-five or 2 thumbs up. Your choice. From valdis.kletnieks at vt.edu Wed Jul 12 19:37:40 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 12 Jul 2017 15:37:40 -0400 Subject: noction vs border6 vs kentik vs fcp vs ? In-Reply-To: References: Message-ID: <50855.1499888260@turing-police.cc.vt.edu> On Wed, 12 Jul 2017 11:03:50 -0700, ShaColby Jackson said: > I know solutions like Kentik do a lot more but I���m focusing on just the > above use case. Also ignoring the cloud vs. on-prem difference, assume that > doesn���t matter. Might want to re-think that. In a world where some eyeball networks are reporting that 60%+ of the traffic is Netflix, there's a big difference between the Netflix CDN cloud and having a local Netflix cache box on the local net. Akamai is another company making coin assuming it does matter. (I'm assuming you don't actually know what percent of your traffic is Netflix/Akamai - if you already had that breakout, you'd not be asking for suggestions as you have already have an in-house solution...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From ramirezcyrus at yahoo.com Wed Jul 12 20:43:21 2017 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Wed, 12 Jul 2017 20:43:21 +0000 (UTC) Subject: BGP peering question In-Reply-To: References: <0F9D2B02-C1AF-4F7B-975F-5B5DD8A946B5@ianai.net> <59652A73.8000602@foobar.org> <0ED3AF25-E50C-4303-B26D-95E6D041D7CF@de-cix.net> Message-ID: <1734254499.4753486.1499892201896@mail.yahoo.com> Is your AS registered with ARIN?2 byte or 4 byte ASN number?How many devices are you peering with?Dual homed, multi homed?Bandwidth?Type of traffic? There are alot more... Regards,Cyrus Ramirez   On Wednesday, July 12, 2017, 3:11:38 PM EDT, David Hofstee wrote: I would state that peering gives more control over the traffic you handle (since it is not going over someone else's network). Every hop is a possible problem to your operations, I guess. David On 12 July 2017 at 09:13, Wolfgang Tremmel wrote: > > > On 11. Jul 2017, at 21:43, Nick Hilliard wrote: > > > > Patrick W. Gilmore wrote: > >> 1) Are they present an IX where I am present? > >> > >> 2) Can they configure BGP correctly? > >> > >> 3) … Beer? > > > > > > 1) do they have a pulse? > > 4 ) are they in PeeringDB and keep their entry up to date? (especially the > contact information) > > cheers, > Wolfgang > > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 > | wolfgang.tremmel at de-cix.net > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | > Germany | www.de-cix.net > > > -- -- My opinion is mine. From Romeo.Czumbil at tierpoint.com Wed Jul 12 21:14:02 2017 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Wed, 12 Jul 2017 21:14:02 +0000 Subject: noction vs border6 vs kentik vs fcp vs ? In-Reply-To: References: Message-ID: <24ffb2d6d6be473889a93ccfa9a4c313@hwt01-ex01.tierpoint.net> Kentik has been great for us on notification and analysis. They are pretty much accurate and you can set-up tons of alerts and even action. For example Automatic blackhole for DDoS I wouldn’t use them to shift your traffic around (aka traffic engineering) but I'm sure you can set that up as well. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of ShaColby Jackson Sent: Wednesday, July 12, 2017 2:04 PM To: nanog at nanog.org Subject: noction vs border6 vs kentik vs fcp vs ? I know this topic has gone around a couple times but wondering if there are any new strong opinions on inbound+outbound traffic analysis with a bonus for excellence in traffic engineering at the edge. A typical use case would be finding an AS or prefix representing a large volume of inbound and/or outbound traffic via provider A that could just as well or better be moved via provider B. I know solutions like Kentik do a lot more but I’m focusing on just the above use case. Also ignoring the cloud vs. on-prem difference, assume that doesn’t matter. Will reward any helpful advice with a picture of me give you a virtual high-five or 2 thumbs up. Your choice. From shacolby at gmail.com Wed Jul 12 20:04:42 2017 From: shacolby at gmail.com (ShaColby Jackson) Date: Wed, 12 Jul 2017 13:04:42 -0700 Subject: noction vs border6 vs kentik vs fcp vs ? In-Reply-To: <50855.1499888260@turing-police.cc.vt.edu> References: <50855.1499888260@turing-police.cc.vt.edu> Message-ID: If my servers are watching Netflix all day I’ve got another problem way beyond traffic visibility. On July 12, 2017 at 12:37:48 PM, valdis.kletnieks at vt.edu ( valdis.kletnieks at vt.edu) wrote: On Wed, 12 Jul 2017 11:03:50 -0700, ShaColby Jackson said: > I know solutions like Kentik do a lot more but I’m focusing on just the > above use case. Also ignoring the cloud vs. on-prem difference, assume that > doesn’t matter. Might want to re-think that. In a world where some eyeball networks are reporting that 60%+ of the traffic is Netflix, there's a big difference between the Netflix CDN cloud and having a local Netflix cache box on the local net. Akamai is another company making coin assuming it does matter. (I'm assuming you don't actually know what percent of your traffic is Netflix/Akamai - if you already had that breakout, you'd not be asking for suggestions as you have already have an in-house solution...) From woody at pch.net Thu Jul 13 16:57:37 2017 From: woody at pch.net (Bill Woodcock) Date: Thu, 13 Jul 2017 09:57:37 -0700 Subject: Testing methodology for the Chinese quantum satellite link? Message-ID: <43AF6ED7-6EA3-4ABF-9330-B5C71528DDFE@pch.net> Does anyone who understands quantum networking better than I do have an opinion on the testing methodology that the Chinese team used to confirm entanglement? I guess, more specifically, my question is: when they say that they got 911 positive results out of “millions” of attempts, does this significantly exceed any expected false-positive rate for the confirmation methodology? If so, by what margin? Obviously, if you were just flipping coins, and measured the results once, you’d get 50% positive correlation, twice and you’d get 25% correlation, ten times and you’d get 0.1% correlation, and you’d be at 911 out of a million. So, how much better than that are we talking about? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From hannigan at gmail.com Thu Jul 13 17:41:17 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 13 Jul 2017 13:41:17 -0400 Subject: BGP peering question In-Reply-To: References: Message-ID: On Mon, Jul 10, 2017 at 4:12 PM, craig washington < craigwashington01 at hotmail.com> wrote: > Hello, > > > Newbie question, what criteria do you look for when you decide that you > want to peer with someone or if you will accept peering with someone from > an ISP point of view. > You didn't say what kind of 'peering'. That could mean over an IXP or to be directly connected. You do not need to be a member of an IX to peer. There are at least three types of criteria to evaluate. Technical, business and legal. Take a look here for a few ideas on technical and business criteria: http://bit.ly/2ue2t0P "Me too" with the rest of the thread. If peering serves your mutual interests (or just yours even), its an easy decision. The Dr Peering http://drpeering.net/ website is also a resource for folks new to peering. http://drpeering.net/ Best Regards, -M< From aaron1 at gvtc.com Thu Jul 13 17:57:03 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Jul 2017 12:57:03 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A623E@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000d01d2b4a7$182d8460$48888d20$@gvtc.com> <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> <000001d2b51c$4cb94e10$e62bea30$@gvtc.com> <495D0934DA46854A9CA758393724D590754A623E@NI-MAIL02.nii.ads> Message-ID: <000b01d2fc01$6f101ee0$4d305ca0$@gvtc.com> Hi Erik, as a follow-up to this email from back in April...previously I hadn't yet tested any qos things on the ACX5048. Now I have tested some policing and seems to be working thus far in the lab. I am policing at the unit (subinterface) level to I can accomplish per-vlan/per-unit policers. I have 5 policers like this.... {master:0} agould at eng-lab-5048-2> show configuration firewall | display set | grep policer set firewall policer test-policer-1000 if-exceeding bandwidth-limit 100k set firewall policer test-policer-1000 if-exceeding burst-size-limit 3125 set firewall policer test-policer-1000 then discard set firewall policer test-policer-1001 if-exceeding bandwidth-limit 100k set firewall policer test-policer-1001 if-exceeding burst-size-limit 3125 set firewall policer test-policer-1001 then discard set firewall policer test-policer-1002 if-exceeding bandwidth-limit 100k set firewall policer test-policer-1002 if-exceeding burst-size-limit 3125 set firewall policer test-policer-1002 then discard set firewall policer test-policer-1003 if-exceeding bandwidth-limit 100k set firewall policer test-policer-1003 if-exceeding burst-size-limit 3125 set firewall policer test-policer-1003 then discard set firewall policer test-policer-1004 if-exceeding bandwidth-limit 100k set firewall policer test-policer-1004 if-exceeding burst-size-limit 3125 set firewall policer test-policer-1004 then discard {master:0} agould at eng-lab-5048-2> show configuration interfaces ge-0/0/19 | display set set interfaces ge-0/0/19 flexible-vlan-tagging set interfaces ge-0/0/19 mtu 9216 set interfaces ge-0/0/19 encapsulation flexible-ethernet-services set interfaces ge-0/0/19 unit 1000 description "TEST att mtso - tower 98 Drain 1 - vlan 1000" set interfaces ge-0/0/19 unit 1000 encapsulation vlan-vpls set interfaces ge-0/0/19 unit 1000 vlan-id 1000 set interfaces ge-0/0/19 unit 1000 input-vlan-map pop set interfaces ge-0/0/19 unit 1000 output-vlan-map push set interfaces ge-0/0/19 unit 1000 statistics set interfaces ge-0/0/19 unit 1000 family vpls policer input test-policer-1000 set interfaces ge-0/0/19 unit 1001 description "TEST att mtso - tower 99 Drain 1 - vlan 1001" set interfaces ge-0/0/19 unit 1001 encapsulation vlan-vpls set interfaces ge-0/0/19 unit 1001 vlan-id 1001 set interfaces ge-0/0/19 unit 1001 input-vlan-map pop set interfaces ge-0/0/19 unit 1001 output-vlan-map push set interfaces ge-0/0/19 unit 1001 statistics set interfaces ge-0/0/19 unit 1001 family vpls policer input test-policer-1001 set interfaces ge-0/0/19 unit 1002 description "TEST att mtso - tower 100 Drain 1 - vlan 1002" set interfaces ge-0/0/19 unit 1002 encapsulation vlan-vpls set interfaces ge-0/0/19 unit 1002 vlan-id 1002 set interfaces ge-0/0/19 unit 1002 input-vlan-map pop set interfaces ge-0/0/19 unit 1002 output-vlan-map push set interfaces ge-0/0/19 unit 1002 statistics set interfaces ge-0/0/19 unit 1002 family vpls policer input test-policer-1002 set interfaces ge-0/0/19 unit 1003 description "TEST att mtso - tower 101 Drain 1 - vlan 1003" set interfaces ge-0/0/19 unit 1003 encapsulation vlan-vpls set interfaces ge-0/0/19 unit 1003 vlan-id 1003 set interfaces ge-0/0/19 unit 1003 input-vlan-map pop set interfaces ge-0/0/19 unit 1003 output-vlan-map push set interfaces ge-0/0/19 unit 1003 statistics set interfaces ge-0/0/19 unit 1003 family vpls policer input test-policer-1003 set interfaces ge-0/0/19 unit 1004 description "TEST att mtso - tower 102 Drain 1 - vlan 1004" set interfaces ge-0/0/19 unit 1004 encapsulation vlan-vpls set interfaces ge-0/0/19 unit 1004 vlan-id 1004 set interfaces ge-0/0/19 unit 1004 input-vlan-map pop set interfaces ge-0/0/19 unit 1004 output-vlan-map push set interfaces ge-0/0/19 unit 1004 statistics set interfaces ge-0/0/19 unit 1004 family vpls policer input test-policer-1004 -----Original Message----- From: Erik Sundberg [mailto:ESundberg at nitelusa.com] Sent: Friday, April 14, 2017 10:30 AM To: Aaron Gould ; nanog at nanog.org Subject: RE: 10G MetroE 1-2U Switch Aaron, Do you know if the ACS5048 has any QOS limitations on this platform? Is each EVC on a ENNI able to have a separate QOS policy or is it port based? Just wondering how it would compare to the Cisco NCS5001\NCS5501 Thanks Erik Erik Sundberg Sr. Network Engineering Network Engineering Department p: 773.661.5532 c: 708.710.7419 e: esundberg at nitelusa.com Main: 888.450.2100 NOC 24/7: 866.892.0915 350 North Orleans Street, Suite 1300N Chicago, IL 60654 www.nitelusa.com Managed Telecom Services MPLS | Ethernet | Private Line | Internet | Voice | Security From aaron1 at gvtc.com Thu Jul 13 18:03:45 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Jul 2017 13:03:45 -0500 Subject: noction vs border6 vs kentik vs fcp vs ? In-Reply-To: References: <50855.1499888260@turing-police.cc.vt.edu> Message-ID: <000d01d2fc02$5f115030$1d33f090$@gvtc.com> I have 3 different well-known caches local to my network... 45% of my subscriber traffic hits the caches 55% of my subscriber traffic hits the internet uplinks I love my caches, but I REALLY love the Netflix cache. It's a huge savings on my internet uplinks. -Aaron From baldur.norddahl at gmail.com Thu Jul 13 18:04:26 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 13 Jul 2017 20:04:26 +0200 Subject: BGP peering question In-Reply-To: References: Message-ID: Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy inbound as a pure eyeball network. We use the route servers. We only maintain direct BGP sessions with a few large peers. Think Google, Netflix, Akamai etc. The reason for this is simply administrative overhead. Every BGP session has to be configured and monitored. We know that it will not move a large percentage of our traffic. We simply do not have the ressources currently when the gain is so little. Anyone who wants to pass traffic efficiently to us can either use the route server or they can peer with Hurricane Electric. The later option will get the traffic to us almost as efficiently as peering directly with us. In this sense we outsourced the peering to them. Regards Baldur Den 11. jul. 2017 18.42 skrev "craig washington" < craigwashington01 at hotmail.com>: > Hello, > > > Newbie question, what criteria do you look for when you decide that you > want to peer with someone or if you will accept peering with someone from > an ISP point of view. > > > Thanks. > > > > From owen at delong.com Thu Jul 13 19:27:56 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jul 2017 12:27:56 -0700 Subject: BGP peering question In-Reply-To: References: Message-ID: <24462E15-C0C2-4CB5-B854-75B97511F64C@delong.com> If you develop a well tuned process for creating BGP sessions and even a moderate system for monitoring not the individual sessions, but meaningful traffic events on your network, then, maintaining a large number of peers and a promiscuous peering policy is not such a daunting process. As a general rule, promiscuous peering improves efficiency and keeps your options for traffic delivery open. Restrictive peering generally has the opposite effect. Route servers are a lazy form of promiscuous peering, with an attendant fate sharing which can produce suboptimal results. YMMV. I’ve worked for several networks of various sizes and observed the industry in general for many years. As a general rule, a restrictive peering policy is a great way to lose momentum in the market and convert a major ISP into a bit-player (e.g. SPRINT), whereas promiscuous peering can be a key component in moving a trivial ISP into a major player in the industry (e.g. HE). Again, YMMV. Owen > On Jul 13, 2017, at 11:04 , Baldur Norddahl wrote: > > Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy > inbound as a pure eyeball network. > > We use the route servers. We only maintain direct BGP sessions with a few > large peers. Think Google, Netflix, Akamai etc. > > The reason for this is simply administrative overhead. Every BGP session > has to be configured and monitored. We know that it will not move a large > percentage of our traffic. We simply do not have the ressources currently > when the gain is so little. > > Anyone who wants to pass traffic efficiently to us can either use the route > server or they can peer with Hurricane Electric. The later option will get > the traffic to us almost as efficiently as peering directly with us. In > this sense we outsourced the peering to them. > > Regards > > Baldur > > Den 11. jul. 2017 18.42 skrev "craig washington" < > craigwashington01 at hotmail.com>: > >> Hello, >> >> >> Newbie question, what criteria do you look for when you decide that you >> want to peer with someone or if you will accept peering with someone from >> an ISP point of view. >> >> >> Thanks. >> >> >> >> From marshall.eubanks at gmail.com Fri Jul 14 00:04:52 2017 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 13 Jul 2017 20:04:52 -0400 Subject: Testing methodology for the Chinese quantum satellite link? In-Reply-To: <43AF6ED7-6EA3-4ABF-9330-B5C71528DDFE@pch.net> References: <43AF6ED7-6EA3-4ABF-9330-B5C71528DDFE@pch.net> Message-ID: On Thu, Jul 13, 2017 at 12:57 PM, Bill Woodcock wrote: > Does anyone who understands quantum networking better than I do have an > opinion on the testing methodology that the Chinese team used to confirm > entanglement? Their paper https://arxiv.org/abs/1707.01339 This is somewhat higher level http://vcq.quantum.at/fileadmin/Publications/Entanglement-based%20quantum%20communication%20over%20144km.pdf More math https://arxiv.org/pdf/1410.1319.pdf > I guess, more specifically, my question is: when they say that they got > 911 positive results out of “millions” of attempts, does this significantly > exceed any expected false-positive rate for the confirmation methodology? > If so, by what margin? Obviously, if you were just flipping coins, and > measured the results once, you’d get 50% positive correlation, twice and > you’d get 25% correlation, ten times and you’d get 0.1% correlation, and > you’d be at 911 out of a million. So, how much better than that are we > talking about? > Look at Figure 2b in the Ursin paper. You are always doing this against some background, looking for a statistically significant peak. Regards Marshall > > -Bill > > > > > > From dovid at telecurve.com Fri Jul 14 02:33:22 2017 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 13 Jul 2017 22:33:22 -0400 Subject: Temperature monitoring Message-ID: All, We had an issue with a DC where temps were elevated. The one bit of hardware that wasn't watched much was the one that sent out the initial alert. Looking for recommendations on hardware that I can mount/hang in each cabinet that is easy to set up and will alert us if temps go beyond a certain point. TIA. Dovid From gem at rellim.com Fri Jul 14 02:43:56 2017 From: gem at rellim.com (Gary E. Miller) Date: Thu, 13 Jul 2017 19:43:56 -0700 Subject: Temperature monitoring In-Reply-To: References: Message-ID: <20170713194013.0ec51246@spidey.rellim.com> Yo Dovid! On Thu, 13 Jul 2017 22:33:22 -0400 Dovid Bender wrote: > Looking for recommendations on hardware that I can > mount/hang in each cabinet that is easy to set up and will alert us > if temps go beyond a certain point. I use a lot of TEMPer USB Thermometers. Cheap, small, easy to poll. It is easy to use from many programing languages and lots of open source software supports it dierctly or indirectly. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lathama at gmail.com Fri Jul 14 02:55:37 2017 From: lathama at gmail.com (Andrew Latham) Date: Thu, 13 Jul 2017 21:55:37 -0500 Subject: Temperature monitoring In-Reply-To: References: Message-ID: On Thu, Jul 13, 2017 at 9:33 PM, Dovid Bender wrote: > All, > > We had an issue with a DC where temps were elevated. The one bit of > hardware that wasn't watched much was the one that sent out the initial > alert. Looking for recommendations on hardware that I can mount/hang in > each cabinet that is easy to set up and will alert us if temps go beyond a > certain point. > > TIA. > > Dovid > Most everything has temperature sensors from switches, servers and most modern PDUs. A dedicated solution is just creating the problem again in the future. Monitor the temps on everything and gain knowledge related to failure rates. Most companies with physical infrastructure could pay for another engineer to discover these unexpected expenses. Also note that modern air conditioning and refrigeration have SNMP or BACNET protocol support, just download the manual. -- - Andrew "lathama" Latham - From stenn at nwtime.org Fri Jul 14 03:16:31 2017 From: stenn at nwtime.org (Harlan Stenn) Date: Thu, 13 Jul 2017 20:16:31 -0700 Subject: Temperature monitoring In-Reply-To: References: Message-ID: <23cee168-3cb2-91c8-4001-31e9eaa3aac2@nwtime.org> On 7/13/17 7:33 PM, Dovid Bender wrote: > All, > > We had an issue with a DC where temps were elevated. The one bit of > hardware that wasn't watched much was the one that sent out the initial > alert. Looking for recommendations on hardware that I can mount/hang in > each cabinet that is easy to set up and will alert us if temps go beyond a > certain point. > > TIA. > > Dovid Are you running ntpd on your boxes? See what happens when you plot its drift against other temperature sensors, the closer to the clock chip the better. If you do this on enough boxes, you should have an easy time seeing what happens on boxes where you have an easier time watching ntpd's drift value than you have watching a nearby dedicated temperature sensor. -- Harlan Stenn http://networktimefoundation.org - be a member! From pete at tccmail.ca Fri Jul 14 04:26:29 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Fri, 14 Jul 2017 00:26:29 -0400 Subject: Temperature monitoring In-Reply-To: References: Message-ID: <8EE7BBA6-F50B-4157-A305-7CC804C2A094@tccmail.ca> We have Sensaphones (sensaphone.com) in remote offices. We use IMS-4000s. They are a 1RU box with RJ45 jacks on the front. You can run CAT-5 to where you want to monitor something, and stick a module on the end of the cable. They have temp, humidity, generic NO/NC sensors, power sensors to graph voltage and alert on voltage swings etc. They can send emails, SNMP traps, or dial out with a modem. They also have a built in mic that can alert on noise increases. Some models allow you to dial in and listen to the room. On July 13, 2017 10:33:22 PM EDT, Dovid Bender wrote: >All, > >We had an issue with a DC where temps were elevated. The one bit of >hardware that wasn't watched much was the one that sent out the initial >alert. Looking for recommendations on hardware that I can mount/hang in >each cabinet that is easy to set up and will alert us if temps go >beyond a >certain point. > >TIA. > >Dovid From mel at beckman.org Fri Jul 14 05:27:51 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 14 Jul 2017 05:27:51 +0000 Subject: Temperature monitoring In-Reply-To: <8EE7BBA6-F50B-4157-A305-7CC804C2A094@tccmail.ca> References: , <8EE7BBA6-F50B-4157-A305-7CC804C2A094@tccmail.ca> Message-ID: Weathergoose by IT watchdogs. 1U rackmount devices with very shallow depth of about an inch or two. Sensors are cheap, varied, and you can daisychain dozens of them together. So one server box can monitor entire row of racks. Loads of other features too for notification, escalation, and SNMP manageable. -mel via cell > On Jul 13, 2017, at 9:27 PM, Pete Baldwin wrote: > > We have Sensaphones (sensaphone.com) in remote offices. We use IMS-4000s. They are a 1RU box with RJ45 jacks on the front. You can run CAT-5 to where you want to monitor something, and stick a module on the end of the cable. They have temp, humidity, generic NO/NC sensors, power sensors to graph voltage and alert on voltage swings etc. They can send emails, SNMP traps, or dial out with a modem. They also have a built in mic that can alert on noise increases. Some models allow you to dial in and listen to the room. > > > >> On July 13, 2017 10:33:22 PM EDT, Dovid Bender wrote: >> All, >> >> We had an issue with a DC where temps were elevated. The one bit of >> hardware that wasn't watched much was the one that sent out the initial >> alert. Looking for recommendations on hardware that I can mount/hang in >> each cabinet that is easy to set up and will alert us if temps go >> beyond a >> certain point. >> >> TIA. >> >> Dovid From holbor at sonss.net Fri Jul 14 05:45:30 2017 From: holbor at sonss.net (Richard Holbo) Date: Thu, 13 Jul 2017 22:45:30 -0700 Subject: Temperature monitoring In-Reply-To: References: Message-ID: http://tyconsystems.com/index.php/products/tycon-power/tpdin-monitor-web/751-tpdin-monitor-web2 Is what I use in my cabinets. Has two temp sensors, one internal and one external. I put the external near the AC cold air output so I can get a diff and know if the AC is on. SNMP cacti graphs them nicely. I use one of the voltage sensors to monitor the cabinet doors via reed switches. In remote mountain sites also use for battery/solar voltages and to monitor wall warts for Utility power loss. /rh On Thu, Jul 13, 2017 at 7:33 PM, Dovid Bender wrote: > All, > > We had an issue with a DC where temps were elevated. The one bit of > hardware that wasn't watched much was the one that sent out the initial > alert. Looking for recommendations on hardware that I can mount/hang in > each cabinet that is easy to set up and will alert us if temps go beyond a > certain point. > > TIA. > > Dovid > From eric.kuhnke at gmail.com Fri Jul 14 06:02:30 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 13 Jul 2017 23:02:30 -0700 Subject: Temperature monitoring In-Reply-To: References: Message-ID: If all that you require is temperature monitoring, I recommend going through the SNMP MIBs and doing an snmpwalk of your devices to identify the sensors at the air intake... Unfortunately there are some devices which do not have air intake sensors, but only a sensor somewhere generally in the center of the motherboard. But other devices have temperature diodes nearly everywhere. This chart example from an Arista 1U switch is a device which is really good about identifying the location of the individual sensors in the MIB. http://imgur.com/a/4CfpK When purchasing a temperature monitoring standalone device, I highly recommend something that is capable of not only temperature sensors but also highly useful things like relay controls, wire contacts for other equipment alarms, contacts for things like door/cabinet opening sensors, etc. With the right high-frequency snmp polling and trap setup you can use such a thing for a great deal more than just temperature. I have seen examples of the Tinycontrol v3 used by NOCs to grant third parties access to POPs via remotely triggered relays and magnetic strike door locks. Here's a couple of good examples: http://tinycontrol.pl/en/lan-controller/ http://tinycontrol.pl/en/accessories-lk-3-sensor/ http://www.controlbyweb.com/x332/ On Thu, Jul 13, 2017 at 10:45 PM, Richard Holbo wrote: > http://tyconsystems.com/index.php/products/tycon-power/ > tpdin-monitor-web/751-tpdin-monitor-web2 > > Is what I use in my cabinets. Has two temp sensors, one internal and one > external. I put the external near the AC cold air output so I can get a > diff and know if the AC is on. SNMP cacti graphs them nicely. I use one > of the voltage sensors to monitor the cabinet doors via reed switches. In > remote mountain sites also use for battery/solar voltages and to monitor > wall warts for Utility power loss. > > /rh > > On Thu, Jul 13, 2017 at 7:33 PM, Dovid Bender wrote: > > > All, > > > > We had an issue with a DC where temps were elevated. The one bit of > > hardware that wasn't watched much was the one that sent out the initial > > alert. Looking for recommendations on hardware that I can mount/hang in > > each cabinet that is easy to set up and will alert us if temps go beyond > a > > certain point. > > > > TIA. > > > > Dovid > > > From nick at foobar.org Fri Jul 14 11:26:56 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Jul 2017 12:26:56 +0100 Subject: Temperature monitoring In-Reply-To: <23cee168-3cb2-91c8-4001-31e9eaa3aac2@nwtime.org> References: <23cee168-3cb2-91c8-4001-31e9eaa3aac2@nwtime.org> Message-ID: <5968AA80.6040704@foobar.org> Harlan Stenn wrote: > If you do this on enough boxes, you should have an easy time seeing what > happens on boxes where you have an easier time watching ntpd's drift > value than you have watching a nearby dedicated temperature sensor. sweet from a technical point of view, but if you have elevated temperatures in a DC (happens all the time with CRACs tripping out), and you need to report this to the DC operations centre and the conversation would be hilarious if you started talking about ntpd drift customer: ohai, we're seeing the sort of clock drift from ntp monitoring that suggests there is a temperature issue near cabinet X. datacentre: huh, what's ntp? customer: it's a time control protocol. datacentre: the time is 12:23. Closing the ticket now. customer: but you have a temperature problem! Our clocks said so! datacentre: ticket is closed. please open a new ticket. Repeat until customer gives up in despair. Three weeks later, the customer is billed for 14 smart hands tickets relating to asking what the time was. Nick From dwhite at olp.net Fri Jul 14 12:31:30 2017 From: dwhite at olp.net (Dan White) Date: Fri, 14 Jul 2017 07:31:30 -0500 Subject: Temperature monitoring In-Reply-To: References: Message-ID: <20170714123125.2ndya33t4y22q3vg@dan.olp.net> We use Asentria. On 07/13/17 22:33 -0400, Dovid Bender wrote: >All, > >We had an issue with a DC where temps were elevated. The one bit of >hardware that wasn't watched much was the one that sent out the initial >alert. Looking for recommendations on hardware that I can mount/hang in >each cabinet that is easy to set up and will alert us if temps go beyond a >certain point. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From hibaysal at gmail.com Fri Jul 14 14:46:12 2017 From: hibaysal at gmail.com (H I Baysal) Date: Fri, 14 Jul 2017 16:46:12 +0200 Subject: BGP peering question In-Reply-To: <24462E15-C0C2-4CB5-B854-75B97511F64C@delong.com> References: <24462E15-C0C2-4CB5-B854-75B97511F64C@delong.com> Message-ID: Hi, I'm not sure if this is mentioned already but here goes, You need to understand the difference between peering and a direct interconnect. with an interconnect you have to think about is the traffic enough to "dedicate" a port for that connection on your edge. ( cost of port vs cost if you would send the traffic over an IX or transit) peering it does not matter that much, as in someone mentioned to peer as much as you can, this will give you more control over announcements per peer and the announcement to the IX. for example you could not advertise the prefixes that attract alot of traffic through the IX RR but to individual members. basically it gives you more control over your announcement to different isps/network over an IX. however you do have to think about the load on your router on the edge, the more sessions the more "power" it needs and more processing when things go wrong or flap. I hope i didn't give redundant information and it helps. good luck!!! Regards, Halil 2017-07-13 21:27 GMT+02:00 Owen DeLong : > If you develop a well tuned process for creating BGP sessions and even a > moderate > system for monitoring not the individual sessions, but meaningful traffic > events on > your network, then, maintaining a large number of peers and a promiscuous > peering > policy is not such a daunting process. > > As a general rule, promiscuous peering improves efficiency and keeps your > options for > traffic delivery open. Restrictive peering generally has the opposite > effect. > > Route servers are a lazy form of promiscuous peering, with an attendant > fate sharing > which can produce suboptimal results. YMMV. > > I’ve worked for several networks of various sizes and observed the > industry in general > for many years. As a general rule, a restrictive peering policy is a great > way to lose > momentum in the market and convert a major ISP into a bit-player (e.g. > SPRINT), whereas > promiscuous peering can be a key component in moving a trivial ISP into a > major player > in the industry (e.g. HE). > > Again, YMMV. > > Owen > > > On Jul 13, 2017, at 11:04 , Baldur Norddahl > wrote: > > > > Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy > > inbound as a pure eyeball network. > > > > We use the route servers. We only maintain direct BGP sessions with a few > > large peers. Think Google, Netflix, Akamai etc. > > > > The reason for this is simply administrative overhead. Every BGP session > > has to be configured and monitored. We know that it will not move a large > > percentage of our traffic. We simply do not have the ressources currently > > when the gain is so little. > > > > Anyone who wants to pass traffic efficiently to us can either use the > route > > server or they can peer with Hurricane Electric. The later option will > get > > the traffic to us almost as efficiently as peering directly with us. In > > this sense we outsourced the peering to them. > > > > Regards > > > > Baldur > > > > Den 11. jul. 2017 18.42 skrev "craig washington" < > > craigwashington01 at hotmail.com>: > > > >> Hello, > >> > >> > >> Newbie question, what criteria do you look for when you decide that you > >> want to peer with someone or if you will accept peering with someone > from > >> an ISP point of view. > >> > >> > >> Thanks. > >> > >> > >> > >> > > -- Met vriendelijke groet / kind regards, Halil Ibrahim Baysal T: +31 (0)6 20 14 20 79 E: hibaysal at gmail.com From craigwashington01 at hotmail.com Thu Jul 13 18:57:27 2017 From: craigwashington01 at hotmail.com (craig washington) Date: Thu, 13 Jul 2017 18:57:27 +0000 Subject: BGP peering question In-Reply-To: References: , Message-ID: Awesome! Thanks for all of the feedback. I am going through the links you sent me and I think they will be of very good help. I guess it was a general question but that was kinda the point, get feed back from all the pro's 😉 thank you very much again. ________________________________ From: Martin Hannigan Sent: Thursday, July 13, 2017 5:41 PM To: craig washington Cc: nanog at nanog.org Subject: Re: BGP peering question On Mon, Jul 10, 2017 at 4:12 PM, craig washington > wrote: Hello, Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someone from an ISP point of view. You didn't say what kind of 'peering'. That could mean over an IXP or to be directly connected. You do not need to be a member of an IX to peer. There are at least three types of criteria to evaluate. Technical, business and legal. Take a look here for a few ideas on technical and business criteria: http://bit.ly/2ue2t0P "Me too" with the rest of the thread. If peering serves your mutual interests (or just yours even), its an easy decision. The Dr Peering http://drpeering.net/ website is also a resource for folks new to peering. http://drpeering.net/ Best Regards, -M< From eric.kuhnke at gmail.com Fri Jul 14 05:59:24 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 13 Jul 2017 22:59:24 -0700 Subject: Temperature monitoring In-Reply-To: References: Message-ID: If all that you require is temperature monitoring, I recommend going through the SNMP MIBs and doing an snmpwalk of your devices to identify the sensors at the air intake... Unfortunately there are some devices which do not have air intake sensors, but only a sensor somewhere generally in the center of the motherboard. But other devices have temperature diodes nearly everywhere. The attached chart example from an Arista 1U switch is a device which is really good about identifying the location of the individual sensors in the MIB. When purchasing a temperature monitoring standalone device, I highly recommend something that is capable of not only temperature sensors but also highly useful things like relay controls, wire contacts for other equipment alarms, contacts for things like door/cabinet opening sensors, etc. With the right high-frequency snmp polling and trap setup you can use such a thing for a great deal more than just temperature. I have seen examples of the Tinycontrol v3 used by NOCs to grant third parties access to POPs via remotely triggered relays and magnetic strike door locks. Here's a couple of good examples: http://tinycontrol.pl/en/lan-controller/ http://tinycontrol.pl/en/accessories-lk-3-sensor/ http://www.controlbyweb.com/x332/ On Thu, Jul 13, 2017 at 10:45 PM, Richard Holbo wrote: > http://tyconsystems.com/index.php/products/tycon-power/ > tpdin-monitor-web/751-tpdin-monitor-web2 > > Is what I use in my cabinets. Has two temp sensors, one internal and one > external. I put the external near the AC cold air output so I can get a > diff and know if the AC is on. SNMP cacti graphs them nicely. I use one > of the voltage sensors to monitor the cabinet doors via reed switches. In > remote mountain sites also use for battery/solar voltages and to monitor > wall warts for Utility power loss. > > /rh > > On Thu, Jul 13, 2017 at 7:33 PM, Dovid Bender wrote: > > > All, > > > > We had an issue with a DC where temps were elevated. The one bit of > > hardware that wasn't watched much was the one that sent out the initial > > alert. Looking for recommendations on hardware that I can mount/hang in > > each cabinet that is easy to set up and will alert us if temps go beyond > a > > certain point. > > > > TIA. > > > > Dovid > > > From jritchie at churchcommunitybuilder.com Thu Jul 13 18:11:17 2017 From: jritchie at churchcommunitybuilder.com (Josiah Ritchie) Date: Thu, 13 Jul 2017 12:11:17 -0600 Subject: Yahoo Mail Delivery Problems Message-ID: We're seeing our deferred queues fill up with mail to Yahoo. Some mail appears to be delivering, but many are not. Is anyone else experiencing problems delivering mail to Yahoo? The Internet suggests that this error has been a result of Yahoo stability in the past. The following message is coming back: host mta5.am0.yahoodns.net[98.136.217.203] said: 451 4.3.2 Internal error > reading data (in reply to MAIL FROM command) > lost connection with mta5.am0.yahoodns.net[98.136.217.203] while sending > RCPT TO ​Thanks, Josiah​ From opeolomola at yahoo.co.uk Thu Jul 13 18:18:10 2017 From: opeolomola at yahoo.co.uk (Opeyemi) Date: Thu, 13 Jul 2017 14:18:10 -0400 Subject: BGP peering question In-Reply-To: References: Message-ID: Okay I will just throw this, in addition to what the others have said. From an ISP point of view, assuming the neighbor is able to provision their end of the cross-connect, you need to check the common POP cost requirements, and also consider if the neighbor is willing to either pay for the peering or provide a mutual benefit. Payment is straight forward. Mutual benefit will depend on what you desire from the neighbor-ship; secure IPv6, Transit services, latency and capacity thresholds, route and path attribute requirements, responsiveness to collaboration over issues (abuse, outages, and instability), internetwork politics, and other BGP controls. Opeyemi Olomola > On Jul 10, 2017, at 4:12 PM, craig washington wrote: > > > Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someone from an ISP point of view. From pozar at lns.com Fri Jul 14 17:28:06 2017 From: pozar at lns.com (Tim Pozar) Date: Fri, 14 Jul 2017 10:28:06 -0700 Subject: So long as we are talking infrastructure... Message-ID: <066eb38f-79c3-ab67-f190-9ea708f6c58c@lns.com> Anyone have experience with Gripple's seismic bracing vs Unistrut's? Looking at putting something in on the Farallons for a rack there and Gripple's system looks lighter and possibly easier to install... http://grippleseismic.com/wp-content/uploads/downloads/2017/03/BROC-SEISMIC-US-10_16-web.pdf You can reply directly back to me as I don't know if the rest of the list wants to see this thread. Thanks... Tim From cscora at apnic.net Fri Jul 14 18:02:38 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Jul 2017 04:02:38 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170714180238.E36E71784@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 654847 Prefixes after maximum aggregation (per Origin AS): 254687 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 315827 Total ASes present in the Internet Routing Table: 57784 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 49994 Origin ASes announcing only one prefix: 22094 Transit ASes present in the Internet Routing Table: 7790 Transit-only ASes present in the Internet Routing Table: 227 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 103 Numnber of instances of unregistered ASNs: 107 Number of 32-bit ASNs allocated by the RIRs: 19455 Number of 32-bit ASNs visible in the Routing Table: 15125 Prefixes from 32-bit ASNs in the Routing Table: 61489 Number of bogon 32-bit ASNs visible in the Routing Table: 64 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 449 Number of addresses announced to Internet: 2848853092 Equivalent to 169 /8s, 206 /16s and 12 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 218082 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179419 Total APNIC prefixes after maximum aggregation: 51490 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 178463 Unique aggregates announced from the APNIC address blocks: 73928 APNIC Region origin ASes present in the Internet Routing Table: 8234 APNIC Prefixes per ASN: 21.67 APNIC Region origin ASes announcing only one prefix: 2307 APNIC Region transit ASes present in the Internet Routing Table: 1169 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3079 Number of APNIC addresses announced to Internet: 763526756 Equivalent to 45 /8s, 130 /16s and 126 /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: 199397 Total ARIN prefixes after maximum aggregation: 94990 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201288 Unique aggregates announced from the ARIN address blocks: 92639 ARIN Region origin ASes present in the Internet Routing Table: 17926 ARIN Prefixes per ASN: 11.23 ARIN Region origin ASes announcing only one prefix: 6646 ARIN Region transit ASes present in the Internet Routing Table: 1767 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: 2091 Number of ARIN addresses announced to Internet: 1108935584 Equivalent to 66 /8s, 25 /16s and 3 /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: 175704 Total RIPE prefixes after maximum aggregation: 85943 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171448 Unique aggregates announced from the RIPE address blocks: 103121 RIPE Region origin ASes present in the Internet Routing Table: 24189 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11133 RIPE Region transit ASes present in the Internet Routing Table: 3406 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5996 Number of RIPE addresses announced to Internet: 712565120 Equivalent to 42 /8s, 120 /16s and 225 /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: 83068 Total LACNIC prefixes after maximum aggregation: 18437 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 84305 Unique aggregates announced from the LACNIC address blocks: 38878 LACNIC Region origin ASes present in the Internet Routing Table: 6124 LACNIC Prefixes per ASN: 13.77 LACNIC Region origin ASes announcing only one prefix: 1678 LACNIC Region transit ASes present in the Internet Routing Table: 1144 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3637 Number of LACNIC addresses announced to Internet: 170821600 Equivalent to 10 /8s, 46 /16s and 135 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17154 Total AfriNIC prefixes after maximum aggregation: 3773 AfriNIC Deaggregation factor: 4.55 Prefixes being announced from the AfriNIC address blocks: 18894 Unique aggregates announced from the AfriNIC address blocks: 6930 AfriNIC Region origin ASes present in the Internet Routing Table: 1052 AfriNIC Prefixes per ASN: 17.96 AfriNIC Region origin ASes announcing only one prefix: 329 AfriNIC Region transit ASes present in the Internet Routing Table: 207 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 322 Number of AfriNIC addresses announced to Internet: 92379904 Equivalent to 5 /8s, 129 /16s and 155 /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 5549 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3985 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2972 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2795 11134 754 KIXS-AS-KR Korea Telecom, KR 9829 2753 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2172 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2090 423 223 TATACOMM-AS TATA Communications formerl 45899 2055 1428 111 VNPT-AS-VN VNPT Corp, VN 7552 1641 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1598 361 141 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3814 2953 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3436 1325 84 SHAW - Shaw Communications Inc., CA 18566 2178 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2011 2172 418 CHARTER-NET-HKY-NC - Charter Communicat 209 1841 5067 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1829 3698 599 AMAZON-02 - Amazon.com, Inc., US 30036 1803 326 292 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1694 854 231 ITCDELTA - Earthlink, Inc., US 701 1560 10559 630 UUNET - MCI Communications Services, In 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 3387 186 23 ALJAWWALSTC-AS, SA 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2927 970 2113 AKAMAI-ASN1, US 34984 2023 330 413 TELLCOM-AS, TR 9121 1967 1691 17 TTNET, TR 13188 1603 100 55 TRIOLAN, UA 12479 1590 1046 54 UNI2-AS, ES 12389 1514 1408 625 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1073 544 15 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 10620 3538 543 194 Telmex Colombia S.A., CO 8151 2503 3398 585 Uninet S.A. de C.V., MX 11830 2090 369 57 Instituto Costarricense de Electricidad 6503 1554 437 53 Axtel, S.A.B. de C.V., MX 7303 1552 1012 243 Telecom Argentina S.A., AR 6147 1282 377 27 Telefonica del Peru S.A.A., PE 3816 1024 501 93 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 966 2299 182 CLARO S.A., BR 11172 914 126 81 Alestra, S. de R.L. de C.V., MX 18881 894 1052 23 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 1230 398 51 LINKdotNET-AS, EG 37611 736 91 8 Afrihost, ZA 36903 711 357 129 MT-MPLS, MA 36992 648 1375 26 ETISALAT-MISR, EG 24835 501 850 15 RAYA-AS, EG 37492 405 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 354 35 7 WANANCHI-, KE 8452 335 1730 17 TE-AS TE-AS, EG 2018 304 327 74 TENET-1, ZA 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 5549 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3985 406 384 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3814 2953 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3538 543 194 Telmex Colombia S.A., CO 6327 3436 1325 84 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2972 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2927 970 2113 AKAMAI-ASN1, US 4766 2795 11134 754 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3814 3656 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3985 3601 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3436 3352 SHAW - Shaw Communications Inc., CA 10620 3538 3344 Telmex Colombia S.A., CO 8551 2974 2934 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2972 2899 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2753 2213 BSNL-NIB National Internet Backbone, IN 9808 2172 2140 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2178 2069 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 4294901876 PRIVATE 59.101.19.0/24 2764 AAPT AAPT Limited, AU 4294902000 PRIVATE 59.101.45.0/24 2764 AAPT AAPT Limited, AU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 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:15 /9:13 /10:36 /11:104 /12:284 /13:552 /14:1048 /15:1847 /16:13458 /17:7643 /18:13423 /19:24663 /20:38644 /21:41266 /22:77851 /23:64618 /24:367168 /25:866 /26:605 /27:641 /28:34 /29:22 /30:18 /31:2 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3236 3436 SHAW - Shaw Communications Inc., CA 22773 2984 3814 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 8551 2439 2974 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2071 2178 MEGAPATH5-US - MegaPath Corporation, US 30036 1594 1803 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1480 2090 Instituto Costarricense de Electricidad y Telec 10620 1474 3538 Telmex Colombia S.A., CO 11492 1403 1559 CABLEONE - CABLE ONE, INC., US 6389 1372 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1583 2:803 4:18 5:2427 6:34 8:1052 12:1809 13:126 14:1736 15:28 16:2 17:159 18:90 20:61 23:2411 24:1889 25:2 27:2450 31:1933 32:84 33:15 35:21 36:384 37:2361 38:1332 39:67 40:98 41:3003 42:471 43:1946 44:74 45:2891 46:2800 47:158 49:1236 50:992 51:19 52:835 54:365 55:6 56:4 57:43 58:1559 59:1049 60:389 61:1959 62:1681 63:1903 64:4588 65:2222 66:4558 67:2272 68:1242 69:3357 70:1151 71:586 72:2226 74:2677 75:387 76:426 77:1545 78:1438 79:2369 80:1407 81:1389 82:1000 83:723 84:941 85:1793 86:460 87:1165 88:756 89:2116 90:172 91:6190 92:987 93:2376 94:2394 95:2678 96:630 97:352 98:1062 99:90 100:154 101:1191 103:15349 104:2995 105:180 106:508 107:1769 108:830 109:2878 110:1457 111:1724 112:1194 113:1259 114:1044 115:1724 116:1805 117:1720 118:2143 119:1607 120:1057 121:1109 122:2265 123:1822 124:1482 125:1906 128:788 129:647 130:434 131:1404 132:537 133:200 134:666 135:223 136:447 137:427 138:1939 139:491 140:399 141:610 142:774 143:914 144:804 145:179 146:1045 147:700 148:1464 149:583 150:717 151:977 152:701 153:299 154:847 155:757 156:621 157:655 158:461 159:1524 160:699 161:737 162:2515 163:539 164:877 165:1400 166:380 167:1242 168:2969 169:824 170:3428 171:319 172:1022 173:1958 174:805 175:745 176:1862 177:4041 178:2539 179:1135 180:2195 181:1894 182:2361 183:996 184:866 185:10099 186:3258 187:2214 188:2605 189:1824 190:8327 191:1352 192:9514 193:5775 194:4677 195:3921 196:2096 197:1375 198:5506 199:5893 200:7476 201:4346 202:10366 203:10014 204:4486 205:2817 206:3023 207:3134 208:3954 209:3959 210:3936 211:2121 212:2847 213:2534 214:868 215:66 216:5802 217:2111 218:865 219:598 220:1691 221:933 222:759 223:1189 End of report From ahebert at pubnix.net Fri Jul 14 18:05:15 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 14 Jul 2017 14:05:15 -0400 Subject: Friday musing - Long distance fiber deployment resources In-Reply-To: <066eb38f-79c3-ab67-f190-9ea708f6c58c@lns.com> References: <066eb38f-79c3-ab67-f190-9ea708f6c58c@lns.com> Message-ID: Warning: For just plain curiosity at the moment. I was looking for publicly accessible feasibility studies, white papers, etc, about long distance fiber deployment. (> 400km, aka >250 miles) The interest comes from documenting myself about how poorly deserved are the northern communities in Canada. And how "freakn a shame it is to get pwned" by France telecom wise =D. At this point my Goolge Fu is hardly getting thru the pointless clutter search engines accumulated over the years... From the numerous input so far: A lot of the attempts where made to use facilities like rail or electrical grid distribution, but it always ended squashed by a massive push back from the telecom industries, and in one case, maybe the FMI. I'm thinking: If people can invest millions into DOTCOM that put fitbits on cows... There must be a way to help those communities. And ourself, from under the telecom giants. Thanks. ----- 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 From rod.beck at unitedcablecompany.com Fri Jul 14 18:15:50 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 14 Jul 2017 18:15:50 +0000 Subject: Friday musing - Long distance fiber deployment resources In-Reply-To: References: <066eb38f-79c3-ab67-f190-9ea708f6c58c@lns.com>, Message-ID: I think the Artic Fiber project is designed to alleviate that problem in the Northwest. It was incorporated into a larger project to connect the three continents. I know one of the founders, Mike Cunningham. http://www.submarinenetworks.com/systems/asia-europe-africa/arctic-fiber/arctic-fibre-acquired-by-quintillion-networks ________________________________ From: NANOG on behalf of Alain Hebert Sent: Friday, July 14, 2017 8:05 PM To: nanog at nanog.org Subject: Friday musing - Long distance fiber deployment resources Warning: For just plain curiosity at the moment. I was looking for publicly accessible feasibility studies, white papers, etc, about long distance fiber deployment. (> 400km, aka >250 miles) The interest comes from documenting myself about how poorly deserved are the northern communities in Canada. And how "freakn a shame it is to get pwned" by France telecom wise =D. At this point my Goolge Fu is hardly getting thru the pointless clutter search engines accumulated over the years... From the numerous input so far: A lot of the attempts where made to use facilities like rail or electrical grid distribution, but it always ended squashed by a massive push back from the telecom industries, and in one case, maybe the FMI. I'm thinking: If people can invest millions into DOTCOM that put fitbits on cows... There must be a way to help those communities. And ourself, from under the telecom giants. Thanks. ----- 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... From spedersen.lists at gmail.com Fri Jul 14 18:40:47 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Fri, 14 Jul 2017 11:40:47 -0700 Subject: ISP billing - data collection, correlation, and billing Message-ID: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks! From lguillory at reservetele.com Fri Jul 14 18:47:49 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 14 Jul 2017 18:47:49 +0000 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS> On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though. 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 Sean Pedersen Sent: Friday, July 14, 2017 1:41 PM To: nanog at nanog.org Subject: ISP billing - data collection, correlation, and billing I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks! From morrowc.lists at gmail.com Fri Jul 14 20:33:23 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Jul 2017 16:33:23 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? Message-ID: Was there a list of folks collecting to provide fix actions for hotel/airport/etc? Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the internet? 173.194.205.129 for instance, ping, traceroute, http but no https :( https works just fine from lots of other places on the tubes... just not the dulles wifi. -chris From eric.kuhnke at gmail.com Fri Jul 14 20:43:21 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 14 Jul 2017 13:43:21 -0700 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: References: Message-ID: I've found many times it's the other way around, with highly restrictive captive portals that only allow traffic to 80 and 443. This is exactly the reason why I have an OpenVPN server running in tcp mode (not udp) on 443. On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow wrote: > Was there a list of folks collecting to provide fix actions for > hotel/airport/etc? > > Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the > internet? 173.194.205.129 > > for instance, ping, traceroute, http but no https :( > https works just fine from lots of other places on the tubes... just not > the dulles wifi. > > -chris > From morrowc.lists at gmail.com Fri Jul 14 20:52:05 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Jul 2017 16:52:05 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: References: Message-ID: Yea, I was able to get around the broken-ness with openvpn, but.. that's sad :( and not everyone has that capability. On Fri, Jul 14, 2017 at 4:43 PM, Eric Kuhnke wrote: > I've found many times it's the other way around, with highly restrictive > captive portals that only allow traffic to 80 and 443. This is exactly the > reason why I have an OpenVPN server running in tcp mode (not udp) on 443. > > > On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> Was there a list of folks collecting to provide fix actions for >> hotel/airport/etc? >> >> Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on >> the >> internet? 173.194.205.129 >> >> for instance, ping, traceroute, http but no https :( >> https works just fine from lots of other places on the tubes... just not >> the dulles wifi. >> >> -chris >> > > From randy at psg.com Fri Jul 14 20:54:36 2017 From: randy at psg.com (Randy Bush) Date: Fri, 14 Jul 2017 22:54:36 +0200 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: References: Message-ID: some years back, narita blocked 443 not 80, blocked 465 & 587 not 25, etc. i actually found a clue receptacle and it was fixed some weeks later. i suspect the number of things they can do wrongly may be bounded but is quite large. randy From math at sizone.org Fri Jul 14 21:04:53 2017 From: math at sizone.org (Ken Chase) Date: Fri, 14 Jul 2017 17:04:53 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: References: Message-ID: <20170714210453.GN3506@sizone.org> This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once I got SSH sky's the limit on what I can fix/setup/tunnel. /kc On Fri, Jul 14, 2017 at 01:43:21PM -0700, Eric Kuhnke said: >I've found many times it's the other way around, with highly restrictive >captive portals that only allow traffic to 80 and 443. This is exactly the >reason why I have an OpenVPN server running in tcp mode (not udp) on 443. > > >On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow > wrote: > >> Was there a list of folks collecting to provide fix actions for >> hotel/airport/etc? >> >> Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the >> internet? 173.194.205.129 >> >> for instance, ping, traceroute, http but no https :( >> https works just fine from lots of other places on the tubes... just not >> the dulles wifi. >> >> -chris >> -- Ken Chase - math at sizone.org Guelph Canada From ahebert at pubnix.net Fri Jul 14 21:18:48 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 14 Jul 2017 17:18:48 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: <20170714210453.GN3506@sizone.org> References: <20170714210453.GN3506@sizone.org> Message-ID: <9aa9fbec-31e7-70bd-76e4-ee8e1cacdf9f@pubnix.net> Could also do: OpenVPN, with a proxy in front, that listen to all the ports in case they're using a gateway that transparent proxy some protocol. 2017 version of wack-a-mole. ----- 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 07/14/17 17:04, Ken Chase wrote: > This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once > I got SSH sky's the limit on what I can fix/setup/tunnel. > > /kc > > On Fri, Jul 14, 2017 at 01:43:21PM -0700, Eric Kuhnke said: > >I've found many times it's the other way around, with highly restrictive > >captive portals that only allow traffic to 80 and 443. This is exactly the > >reason why I have an OpenVPN server running in tcp mode (not udp) on 443. > > > > > >On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow >> wrote: > > > >> Was there a list of folks collecting to provide fix actions for > >> hotel/airport/etc? > >> > >> Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the > >> internet? 173.194.205.129 > >> > >> for instance, ping, traceroute, http but no https :( > >> https works just fine from lots of other places on the tubes... just not > >> the dulles wifi. > >> > >> -chris > >> > > -- > Ken Chase - math at sizone.org Guelph Canada > From eric-list at truenet.com Fri Jul 14 22:02:10 2017 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 14 Jul 2017 18:02:10 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: <20170714210453.GN3506@sizone.org> References: <20170714210453.GN3506@sizone.org> Message-ID: <66F089C0-328C-4EA2-B635-8D7CE2ECA715@truenet.com> > On Jul 14, 2017, at 5:04 PM, Ken Chase wrote: > > > This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once > I got SSH sky's the limit on what I can fix/setup/tunnel. > > /kc > -- > Ken Chase - math at sizone.org Guelph Canada This is my usual workaround as well. Props to Avery Pennarun: http://sshuttle.readthedocs.io/en/stable/index.html for making my life even easier. From guillaume at ironie.org Fri Jul 14 22:10:56 2017 From: guillaume at ironie.org (Guillaume Tournat) Date: Sat, 15 Jul 2017 00:10:56 +0200 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: <20170714210453.GN3506@sizone.org> References: <20170714210453.GN3506@sizone.org> Message-ID: <2A86E516-D36F-46DF-B517-BEAAFE86DBB3@ironie.org> Using sshd on port 443, I can ssh my box with a tunnel to a local squid. My browser then use this tunneled proxy to go to internet. Private and secure. > Le 14 juil. 2017 à 23:04, Ken Chase a écrit : > > > This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once > I got SSH sky's the limit on what I can fix/setup/tunnel. > > /kc > > On Fri, Jul 14, 2017 at 01:43:21PM -0700, Eric Kuhnke said: >> I've found many times it's the other way around, with highly restrictive >> captive portals that only allow traffic to 80 and 443. This is exactly the >> reason why I have an OpenVPN server running in tcp mode (not udp) on 443. >> >> >> On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow >> wrote: >> >>> Was there a list of folks collecting to provide fix actions for >>> hotel/airport/etc? >>> >>> Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the >>> internet? 173.194.205.129 >>> >>> for instance, ping, traceroute, http but no https :( >>> https works just fine from lots of other places on the tubes... just not >>> the dulles wifi. >>> >>> -chris >>> > > -- > Ken Chase - math at sizone.org Guelph Canada From math at sizone.org Fri Jul 14 22:13:13 2017 From: math at sizone.org (Ken Chase) Date: Fri, 14 Jul 2017 18:13:13 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: <66F089C0-328C-4EA2-B635-8D7CE2ECA715@truenet.com> References: <20170714210453.GN3506@sizone.org> <66F089C0-328C-4EA2-B635-8D7CE2ECA715@truenet.com> Message-ID: <20170714221313.GQ3506@sizone.org> port 53 seems to be the biggest hole available, no one figures that anyone will send actual data over port 53, other than DNS! (and they [have to] leave TCP open, because of the nice handywavy implimentations of dns lookups :) some captive portals intercept all IP traffic regardless of dns, others intercept the DNS first and give some captive IP target instead for your cnn.com lookup. The former are easy to send data over. (the latter sometimes you can put your targets into your HOSTS[.txt] file and get there, though today most webpages are 250 urls from 45 different domains, so have fun.) $ apt-cache search iodine iodine - tool for tunneling IPv4 data through a DNS server http://code.kryo.se/iodine/ Sshuttle looks great thanks /kc On Fri, Jul 14, 2017 at 06:02:10PM -0400, Eric Tykwinski said: > >> On Jul 14, 2017, at 5:04 PM, Ken Chase wrote: >> >> >> This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once >> I got SSH sky's the limit on what I can fix/setup/tunnel. >> >> /kc >> -- >> Ken Chase - math at sizone.org Guelph Canada > >This is my usual workaround as well. >Props to Avery Pennarun: http://sshuttle.readthedocs.io/en/stable/index.html >for making my life even easier. > -- Ken Chase - math at sizone.org Guelph Canada From morrowc.lists at gmail.com Sat Jul 15 08:05:14 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 15 Jul 2017 04:05:14 -0400 Subject: Reporting/fixing broken airport/hotel/etc wifi? In-Reply-To: <20170714221313.GQ3506@sizone.org> References: <20170714210453.GN3506@sizone.org> <66F089C0-328C-4EA2-B635-8D7CE2ECA715@truenet.com> <20170714221313.GQ3506@sizone.org> Message-ID: there are a lot of options for techsavvy folk with an ip they control, but... for the rest of the rubles, fixing the wifi to be sane really is the only path forward. On Fri, Jul 14, 2017 at 6:13 PM, Ken Chase wrote: > port 53 seems to be the biggest hole available, no one figures that anyone > will send actual data over port 53, other than DNS! (and they [have to] > leave > TCP open, because of the nice handywavy implimentations of dns lookups :) > > some captive portals intercept all IP traffic regardless of dns, others > intercept the DNS first and give some captive IP target instead for your > cnn.com > lookup. The former are easy to send data over. > > (the latter sometimes you can put your targets into your HOSTS[.txt] file > and > get there, though today most webpages are 250 urls from 45 different > domains, > so have fun.) > > $ apt-cache search iodine > iodine - tool for tunneling IPv4 data through a DNS server > > http://code.kryo.se/iodine/ > > Sshuttle looks great thanks > > /kc > > > On Fri, Jul 14, 2017 at 06:02:10PM -0400, Eric Tykwinski said: > > > >> On Jul 14, 2017, at 5:04 PM, Ken Chase wrote: > >> > >> > >> This is exactly why i have SSHd on port 443 and 53 on one of my > boxes/IPs. Once > >> I got SSH sky's the limit on what I can fix/setup/tunnel. > >> > >> /kc > >> -- > >> Ken Chase - math at sizone.org Guelph Canada > > > >This is my usual workaround as well. > >Props to Avery Pennarun: http://sshuttle.readthedocs. > io/en/stable/index.html > >for making my life even easier. > > > > -- > Ken Chase - math at sizone.org Guelph Canada > From lee at asgard.org Sat Jul 15 14:47:08 2017 From: lee at asgard.org (Lee Howard) Date: Sat, 15 Jul 2017 10:47:08 -0400 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS> References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS> Message-ID: On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" wrote: >On the HFC / CMTS side of things we have IPDR which I believe has some >open source collectors out there. I'm not sure that IPDR is used much >outside of the HFC world though. IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee From lguillory at reservetele.com Sat Jul 15 16:16:09 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 15 Jul 2017 16:16:09 +0000 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS>, Message-ID: <0E24F5D5-DE2C-4A81-814C-9824C27C3AAF@reservetele.com> To be honest we don't do usage billing so I've never used it. I'd like to think it is since it uses a verification between the collector and source. Sent from my iPhone On Jul 15, 2017, at 3:47 AM, Lee Howard > wrote: On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" on behalf of lguillory at reservetele.com> wrote: On the HFC / CMTS side of things we have IPDR which I believe has some open source collectors out there. I'm not sure that IPDR is used much outside of the HFC world though. IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee Luke Guillory Vice President – Technology and Innovation [cid:image3856cc.JPG at d6320433.44ae2e87] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From dcharlebois at gmail.com Mon Jul 17 02:01:33 2017 From: dcharlebois at gmail.com (David Charlebois) Date: Sun, 16 Jul 2017 22:01:33 -0400 Subject: Temperature monitoring In-Reply-To: <20170714123125.2ndya33t4y22q3vg@dan.olp.net> References: <20170714123125.2ndya33t4y22q3vg@dan.olp.net> Message-ID: we use: https://serverscheck.com/sensors/ - simple setup, graph nicely in Cacti. I went with ServerCheck wired based units + external temp+humidity probe. The base unit displays the temperature which is a nice quick reference if you are in the room. On Fri, Jul 14, 2017 at 8:31 AM, Dan White wrote: > We use Asentria. > > On 07/13/17 22:33 -0400, Dovid Bender wrote: > >> All, >> >> We had an issue with a DC where temps were elevated. The one bit of >> hardware that wasn't watched much was the one that sent out the initial >> alert. Looking for recommendations on hardware that I can mount/hang in >> each cabinet that is easy to set up and will alert us if temps go beyond a >> certain point. >> > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 (direct) main: (918)366-8000 > Fax 918.366.6610 email: dwhite at olp.net > http://www.btcbroadband.com > From nanog-isp at mail.com Mon Jul 17 06:50:26 2017 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Mon, 17 Jul 2017 08:50:26 +0200 Subject: Friday musing - Long distance fiber deployment resources Message-ID: There are a lot more cows than people with money in rural/remote areas. Getting fiber to remote unserved areas is not a technical problem, it's a money/political problem. On a good day, deploying 400 km of fiber costs in the ballpark of $10M. To that you then have to add the recurring costs of operations, maintenance and fees for the use of the right of way. If the community can pay for that, all is good and well, just have at it. If not, somebody has to subsidize it and then it becomes a political problem. Jared ________________________________ From: NANOG on behalf of Alain Hebert Sent: Friday, July 14, 2017 8:05 PM To: nanog at nanog.org Subject: Friday musing - Long distance fiber deployment resources Warning: For just plain curiosity at the moment. I was looking for publicly accessible feasibility studies, white papers, etc, about long distance fiber deployment. (> 400km, aka >250 miles) The interest comes from documenting myself about how poorly deserved are the northern communities in Canada. And how "freakn a shame it is to get pwned" by France telecom wise =D. At this point my Goolge Fu is hardly getting thru the pointless clutter search engines accumulated over the years... From the numerous input so far: A lot of the attempts where made to use facilities like rail or electrical grid distribution, but it always ended squashed by a massive push back from the telecom industries, and in one case, maybe the FMI. I'm thinking: If people can invest millions into DOTCOM that put fitbits on cows... There must be a way to help those communities. And ourself, from under the telecom giants. Thanks. ----- 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you From rod.beck at unitedcablecompany.com Mon Jul 17 11:22:26 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 17 Jul 2017 11:22:26 +0000 Subject: Friday musing - Long distance fiber deployment resources In-Reply-To: References: Message-ID: Agreed, however over the next 50 to 100 years you might see a big migration North as temperature continue rising and continuous shipping via the Northern passage. The Quintillion cable is really being built to link Asia and Europe via an ultra low latency path. Attaching fiber spurs to those Northern Communities is a way of getting Canadian government support and money. ________________________________ From: NANOG on behalf of nanog-isp at mail.com Sent: Monday, July 17, 2017 8:50 AM To: Nanog at nanog.org Subject: Friday musing - Long distance fiber deployment resources There are a lot more cows than people with money in rural/remote areas. Getting fiber to remote unserved areas is not a technical problem, it's a money/political problem. On a good day, deploying 400 km of fiber costs in the ballpark of $10M. To that you then have to add the recurring costs of operations, maintenance and fees for the use of the right of way. If the community can pay for that, all is good and well, just have at it. If not, somebody has to subsidize it and then it becomes a political problem. Jared ________________________________ From: NANOG on behalf of Alain Hebert Sent: Friday, July 14, 2017 8:05 PM To: nanog at nanog.org Subject: Friday musing - Long distance fiber deployment resources Warning: For just plain curiosity at the moment. I was looking for publicly accessible feasibility studies, white papers, etc, about long distance fiber deployment. (> 400km, aka >250 miles) The interest comes from documenting myself about how poorly deserved are the northern communities in Canada. And how "freakn a shame it is to get pwned" by France telecom wise =D. At this point my Goolge Fu is hardly getting thru the pointless clutter search engines accumulated over the years... From the numerous input so far: A lot of the attempts where made to use facilities like rail or electrical grid distribution, but it always ended squashed by a massive push back from the telecom industries, and in one case, maybe the FMI. I'm thinking: If people can invest millions into DOTCOM that put fitbits on cows... There must be a way to help those communities. And ourself, from under the telecom giants. Thanks. ----- 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... PubNIX Inc. – Branché sur le monde – Connected to the World PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... www.pubnix.net PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you From gerardo.perales at axtel.com.mx Mon Jul 17 14:39:48 2017 From: gerardo.perales at axtel.com.mx (Jose Gerardo Perales Soto) Date: Mon, 17 Jul 2017 14:39:48 +0000 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> Message-ID: Hi, we use the same approach as you. When provisioning services they’re identified by a label in the interface description so data is collected and delivered to our billing systems. Gerardo El 14/07/17 13:43, "NANOG en nombre de Sean Pedersen" escribió: I went back a few years in the archives and found a few odd references, but not much discussion. I'm curious what some other approaches are to usage-based billing, both the practice of generating/correlating data and the billing itself. We bill based on use/95th percentile and our system is rudimentary on its best day. We use SNMP and interface descriptions to generate data and correlate it with customers. This works for the most part, but leaves a lot to be desired. Ours is one method, and I've seen others who use NetFlow data in a similar fashion, with the assumption that the NetFlow data is correlated either via IP address or source interface. Most of the systems I've seen are full-fledged CRM, billing, and OSS, which is a little overkill for us at the moment. I think we would have issues trying to integrate such a multi-headed beast into our organization at this time. What methods do you use to collect and correlate data? What systems, if any, do you use? I'm a little in the dark as the billing/OSS side of things is outside of my normal scope and would appreciate any recommendations. Thanks! ________________________________ NOTA: La información de este correo es de propiedad exclusiva y confidencial. Este mensaje es sólo para el destinatario señalado, si usted no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que esté libre de virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus empleados aceptan responsabilidad alguna. NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by AXTEL, S.A.B. de C.V, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their employees accept any responsibility. From spedersen.lists at gmail.com Mon Jul 17 16:17:23 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Mon, 17 Jul 2017 09:17:23 -0700 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS> Message-ID: <003801d2ff18$2d029e50$8707daf0$@gmail.com> Flexible NetFlow is the best option for us. I haven’t seen a lot of products outside of open source that work with telemetry at the moment, and nothing that has billing functions. We’re far too lean to be able to rely on open source / devops at this point. That’s been a hard lesson to teach the company. It’s definitely on our internal roadmap, though. From: Michael Krygeris [mailto:me at krygerism.com] Sent: Sunday, July 16, 2017 9:35 AM To: Lee Howard ; Luke Guillory ; Sean Pedersen ; nanog at nanog.org Subject: Re: ISP billing - data collection, correlation, and billing On Sat, Jul 15, 2017 at 4:48 AM Lee Howard > wrote: Depending on the capability of the exporter, you don't need to export full flow information. With Cisco's Flexible Netflow you can define the aggregation in the flow cache you are monitoring. You are not required to use a 7-tuple. An aggregation could be something basic like this: Source interface Destination interface Octets Packets This would give you SNMP equivalent for byte accounting on interfaces without requiring full flow accounting IF you're not forced to do sampling and IF you have flexible netflow. Another much more recent method around SNMP (sorry SNMP, I'm over you) is streaming telemetry, which is part of Netconf/YANG/OpenConfig. This is more of a push method for these yang data models(the relevent one here being snmp interfaces table). It already exists on some Juniper and Cisco platforms. Mike Krygeris On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" on behalf of lguillory at reservetele.com > wrote: >On the HFC / CMTS side of things we have IPDR which I believe has some >open source collectors out there. I'm not sure that IPDR is used much >outside of the HFC world though. IPDR was my first thought as an alternative to SNMP. Is its accuracy comparable? It’s been included into TR-069, so it’s theoretically available to telcos, too. And usage-based billing is part of it’s purpose. Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, not bits, and I don’t want to record flows. But I’d be interested in hearing others’ experience. Lee From mark.tinka at seacom.mu Mon Jul 17 21:44:59 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 17 Jul 2017 23:44:59 +0200 Subject: SAFNOG-3: Registration Now Open! Message-ID: Hello all. It gives me great pleasure to announce that the SAFNOG-3 Registration is now open! Please note that registration for SAFNOG-3 is free of charge. I'd like to extend my thanks to the SAFNOG and iWeek teams for making this possible for our community. You may register your attendance at the link below: http://safnog.org/ When you begin to input your registration details into the system, you will notice a drop-down menu called "Session Interest". Please select the "SAFNOG-3 (Tuesday and Wednesday)" option to confirm your registration to the SAFNOG-3 meeting. We look forward to seeing you in Durban. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From jbothe at me.com Tue Jul 18 14:25:15 2017 From: jbothe at me.com (JASON BOTHE) Date: Tue, 18 Jul 2017 09:25:15 -0500 Subject: PCCW contact Message-ID: <7CC08C15-61D6-403D-835D-39D9A13DD58D@me.com> Hey NANOGers, I'm hoping to find a contact for PCCW in Hong Kong to assist with a BGP announcement issue. Not having any luck through the front door. Thanks! Jason Sent from my iPhone From johnstong at westmancom.com Tue Jul 18 14:33:19 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 18 Jul 2017 14:33:19 +0000 Subject: Zabbix IT Services feature set Message-ID: <82C0CE81789FE64D8F4D1526319182972F8CA724@MSG6.westman.int> Hi, We have the Zabbix IT Services (running on Zabbix 3.2) configured for some test groups.  It usually returns good data but occasionally it seems that one service group or trigger will get stuck in an alerting state and provide an incorrect SLA.  This can occur if the trigger has changed to a problem state and then back to OK but the IT services doesn't reflect that change.  It will occur where the top level group will show as having 100% problem time and the sub groups and items either have no problem time or such a small amount that it wouldn't indicate 100% problem time. We have it built with some groups under root, some sub groups and items and the items will have a trigger associated with those items.  We followed this article to the best of our knowledge: https://www.zabbix.com/documentation/3.2/manual/it_services   For Example:  |Data Center  |-Core1 |--Core1 - ICMP - Trigger |-Core2 |--Core2 - ICMP - Trigger Each subitem is a child of the item above it.  We haven't configured any dependencies to any other groups or items. My question is, has anyone gotten the Zabbix IT Services to work correctly?  Is there a trick to getting it to work, some configuration we are doing incorrectly? Thanks, Graham From rod.beck at unitedcablecompany.com Tue Jul 18 14:38:10 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 18 Jul 2017 14:38:10 +0000 Subject: Dark Fiber Ring - IRU Message-ID: Looking for vendors who can do a ring from Hamilton to Toronto. 15 years. Only IRUs. I assume Zayo and Beanstalk can do it. Any other parties? Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From valdis.kletnieks at vt.edu Tue Jul 18 16:13:03 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 18 Jul 2017 12:13:03 -0400 Subject: Zabbix IT Services feature set In-Reply-To: <82C0CE81789FE64D8F4D1526319182972F8CA724@MSG6.westman.int> References: <82C0CE81789FE64D8F4D1526319182972F8CA724@MSG6.westman.int> Message-ID: <27361.1500394383@turing-police.cc.vt.edu> On Tue, 18 Jul 2017 14:33:19 -0000, Graham Johnston said: > My question is, has anyone gotten the Zabbix IT Services to work correctly?   > Is there a trick to getting it to work, some configuration we are doing incorrectly? We're a Zabbix shop, with a large number of boxes being monitored. This may or may not be your problem, but it bit me big time when were were first getting it up and running. There's a "gotcha" with triggers, in that they may have *TWO* values to provide hysteresis. So if you have a trigger set to go off at 25 wombats/second, and your system hits 32 wps, the trigger will flag a problem. It will *continue* doing so *not* until it drops below 25 wps, but until it drops down to the "clear" value (for example 10 wombats/sec). SO you can be sitting at 11 or 13 or 12 for a long time, but it won't go to OK until till it's below 10 when Zabbix checks. (A side effect is if it manages to have a very short dip to 9.8 wps, and back up to 13, you'll be scratching your head wondering how it went to OK. :) (And then of course there's the "somebody had a wild hair" cases where the trigger into trouble state is one hand-coded expression checking one thing, and the "OK" trigger checks something entirely different. :) Hope that helps. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From EPers at ansencorp.com Tue Jul 18 20:39:25 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Tue, 18 Jul 2017 20:39:25 +0000 Subject: Temperature monitoring In-Reply-To: References: <20170714123125.2ndya33t4y22q3vg@dan.olp.net> Message-ID: +1 for the serverscheck.com gear. Been running it as a humidity monitor in the plant for a year or so now and it's been rock solid. If you're the kind of shop that requires calibration for that sort of equipment they'll handle that as well. Great company to work with. Pair it with Cacti + thold plugin or whatever other snmp monitoring you like - or the base units can handle alerting on their own. FYI for those interested - the stated max length of connecting cable between the base station and the sensor units (30ft iirc) is way under what it'll do in the real world - I've got at least one sensor unit that's a good 500ft away from the base station and it's been working just fine Ed Pers -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Charlebois Sent: Sunday, July 16, 2017 10:02 PM To: NANOG Subject: Re: Temperature monitoring we use: https://serverscheck.com/sensors/ - simple setup, graph nicely in Cacti. I went with ServerCheck wired based units + external temp+humidity probe. The base unit displays the temperature which is a nice quick reference if you are in the room. On Fri, Jul 14, 2017 at 8:31 AM, Dan White wrote: > We use Asentria. > > On 07/13/17 22:33 -0400, Dovid Bender wrote: > >> All, >> >> We had an issue with a DC where temps were elevated. The one bit of >> hardware that wasn't watched much was the one that sent out the >> initial alert. Looking for recommendations on hardware that I can >> mount/hang in each cabinet that is easy to set up and will alert us >> if temps go beyond a certain point. >> > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 (direct) main: (918)366-8000 > Fax 918.366.6610 email: dwhite at olp.net > http://www.btcbroadband.com > From beckman at angryox.com Wed Jul 19 02:33:16 2017 From: beckman at angryox.com (Peter Beckman) Date: Tue, 18 Jul 2017 22:33:16 -0400 Subject: Temperature monitoring In-Reply-To: References: Message-ID: Agreed -- there are already tons of temp sensors throughout old and new hardware. I've used SCSI drive queries via sdparm and more recently hddtemp to get the current temperature of the drives. No need for SNMP or ILO, though that can give you a more detailed picture where possible. You first monitor and record for 24 hours to get your baseline temp for a given rack or server, then set your threshold, then let your monitoring platform do the rest. Since I use hosted dedicated servers, I don't want to pay for yet another device. In monitoring only those disk temps I've caught two cooling issues before they became a crisis, one of which my hosting provider was not aware of. If you control the hardware, or at least have access to it, there should be enough sensors to let you know at least something is causing a problem. Beckman On Thu, 13 Jul 2017, Andrew Latham wrote: > On Thu, Jul 13, 2017 at 9:33 PM, Dovid Bender wrote: > >> All, >> >> We had an issue with a DC where temps were elevated. The one bit of >> hardware that wasn't watched much was the one that sent out the initial >> alert. Looking for recommendations on hardware that I can mount/hang in >> each cabinet that is easy to set up and will alert us if temps go beyond a >> certain point. >> >> TIA. >> >> Dovid >> > > Most everything has temperature sensors from switches, servers and most > modern PDUs. A dedicated solution is just creating the problem again in the > future. Monitor the temps on everything and gain knowledge related to > failure rates. Most companies with physical infrastructure could pay for > another engineer to discover these unexpected expenses. Also note that > modern air conditioning and refrigeration have SNMP or BACNET protocol > support, just download the manual. > > -- > - Andrew "lathama" Latham - > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From simon at slimey.org Thu Jul 20 09:12:19 2017 From: simon at slimey.org (Simon Lockhart) Date: Thu, 20 Jul 2017 10:12:19 +0100 Subject: VXLAN for WAN Pseudowires? Message-ID: <20170720091219.GO15390@dilbert.slimey.org> All, I'm currently going through a network design for an upgrade for one of the networks I run. Much of the wide-area traffic on the network is used purely to transport Ethernet tail circuits back from an edge PoP to a core PoP. Currently we're using Extreme X460 and X670 switches to achieve this, carrying the tail circuits within VPLS. Two things are making me look at a change of solution for this - firstly Extreme have stated that they're not interested in the service provider market any more (and reflected this in significant reductions in discounts), and secondly we need to look at higher bandwidth port options (40G + 100G, particularly for backhaul circuits). As we're primarily a Cisco house, I've been looking at suitable replacements, and the Nexus 9k range looks good - 92160YC and 9236C in particular. However, this would mean a shift from VPLS to VXLAN. We're also looking at Cisco-like products, such as the Arista range. We've been doing some testing in the lab, and so far, things look good - it's easy to configure, and appears to do the job of getting packets from A to B. We do have two concerns, though: 1) Cisco are strongly advising against using the Nexus switches in a WAN scenario - as they're designed for "datacentre" use. They've so far said they can't find anyone who can help validate designs using Nexus, and instead are pushing us towards the NCS-5000 series switches. Same chipset, but 2-3 times the price! NCS does, however, support VPLS, so would be an easier drop-in to our existing network. 2) Traffic engineering - we don't have a lot of requirement for this, but do have a small number of customers who buy A and B circuits, and require them to be routed across different paths on our network. This is easy with MPLS using explicit LSPs, but we've not yet worked out how to achieve the same thing in VXLAN. So, my question to the community is - have any of you used VXLAN as a wide-area layer 2 transport technology? Any pros or cons? Gotchas? Scare stories? Recommendations? Am I trying to shoot myself in the foot? Many thanks, Simon From spedersen.lists at gmail.com Thu Jul 20 16:14:37 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Thu, 20 Jul 2017 09:14:37 -0700 Subject: VXLAN for WAN Pseudowires? In-Reply-To: <20170720091219.GO15390@dilbert.slimey.org> References: <20170720091219.GO15390@dilbert.slimey.org> Message-ID: <000601d30173$4946cd40$dbd467c0$@gmail.com> Been there, got the t-shirt ... VXLAN was not designed to be a direct replacement for L2VPN. It was built to scale L2 broadcast domains. With Cisco, L2 control protocols like STP are not supported. Can't speak for other vendors. So what someone would typically expect from EoMPLS and L2 protocol tunneling, they're not going to get with a VXLAN substitute. If all you're looking to do is create a virtual Ethernet cable between two L3 interfaces with absolutely no L2 protocol tunneling involved, it works like a champ. We use them for that purpose, building virtual cross-connects between routers, as well as in a few virtual environments to overlay L2 networks across a BGP CLOS. I would not recommend VXLAN to replace L2VPNs unless you plan to wait for / hope for L2 protocol tunneling support. You would not get a direct replacement for your current VPLS circuits. Segment routing is in the same boat - no L2VPN support until next year, and then it's supposed to be limited to -EX and -FX Nexus chassis. I can't speak on the subject of using it across a WAN; we dump our VXLAN tunnels to ASR9Ks at the edge where traditional MPLS takes over. Generally, it's not recommended to try and extend a LAN-based protocol across a WAN. While it's L3 traffic once the VXLAN overlay takes over, I would look into the control plane requirements, overhead, etc. before even considering it. NCS is what Cisco currently recommends for a scalable MPLS fabric. There's also the ASR9000V, which acts as a satellite / remote line card of larger ASR9K routers, but you'd still want some kind of aggregation in there to scale or your ASR9K port cost is going to start to hurt. Hit me up off-list if you want to know a little more in detail. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Simon Lockhart Sent: Thursday, July 20, 2017 2:12 AM To: nanog at nanog.org Subject: VXLAN for WAN Pseudowires? All, I'm currently going through a network design for an upgrade for one of the networks I run. Much of the wide-area traffic on the network is used purely to transport Ethernet tail circuits back from an edge PoP to a core PoP. Currently we're using Extreme X460 and X670 switches to achieve this, carrying the tail circuits within VPLS. Two things are making me look at a change of solution for this - firstly Extreme have stated that they're not interested in the service provider market any more (and reflected this in significant reductions in discounts), and secondly we need to look at higher bandwidth port options (40G + 100G, particularly for backhaul circuits). As we're primarily a Cisco house, I've been looking at suitable replacements, and the Nexus 9k range looks good - 92160YC and 9236C in particular. However, this would mean a shift from VPLS to VXLAN. We're also looking at Cisco-like products, such as the Arista range. We've been doing some testing in the lab, and so far, things look good - it's easy to configure, and appears to do the job of getting packets from A to B. We do have two concerns, though: 1) Cisco are strongly advising against using the Nexus switches in a WAN scenario - as they're designed for "datacentre" use. They've so far said they can't find anyone who can help validate designs using Nexus, and instead are pushing us towards the NCS-5000 series switches. Same chipset, but 2-3 times the price! NCS does, however, support VPLS, so would be an easier drop-in to our existing network. 2) Traffic engineering - we don't have a lot of requirement for this, but do have a small number of customers who buy A and B circuits, and require them to be routed across different paths on our network. This is easy with MPLS using explicit LSPs, but we've not yet worked out how to achieve the same thing in VXLAN. So, my question to the community is - have any of you used VXLAN as a wide-area layer 2 transport technology? Any pros or cons? Gotchas? Scare stories? Recommendations? Am I trying to shoot myself in the foot? Many thanks, Simon From aftab.siddiqui at gmail.com Fri Jul 21 02:29:15 2017 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Fri, 21 Jul 2017 02:29:15 +0000 Subject: VXLAN for WAN Pseudowires? In-Reply-To: <20170720091219.GO15390@dilbert.slimey.org> References: <20170720091219.GO15390@dilbert.slimey.org> Message-ID: Hi Simon, In the previous job, we used it in a similar scenario and from that experience × × What works fine across end points: Routing protocols (OSPF, BGP), VLAN, QinQ, Multicast What doesn't' work across end points: LLDP, LACP, CoS preservation (you can remark), 802.1x So, test your requirements in the lab (as you are already doing it), its not a VPLS replacement in many ways but it worked like a charm in our requirement. We used Open-network boxes (Dell, HP, etc) along with CumulusLinux (Dell OS9 also has VXLAN support). Arista (Trident II/II+) also works fine with EOS. All these switches were and still are for DC but they are extremely cheaper than NCS5000 series and works fine. On Thu, 20 Jul 2017 at 19:14 Simon Lockhart wrote: > All, > > I'm currently going through a network design for an upgrade for one of the > networks I run. Much of the wide-area traffic on the network is used purely > to transport Ethernet tail circuits back from an edge PoP to a core PoP. > Currently we're using Extreme X460 and X670 switches to achieve this, > carrying > the tail circuits within VPLS. > > Two things are making me look at a change of solution for this - firstly > Extreme have stated that they're not interested in the service provider > market any more (and reflected this in significant reductions in > discounts), > and secondly we need to look at higher bandwidth port options (40G + 100G, > particularly for backhaul circuits). > > As we're primarily a Cisco house, I've been looking at suitable > replacements, > and the Nexus 9k range looks good - 92160YC and 9236C in particular. > However, > this would mean a shift from VPLS to VXLAN. We're also looking at > Cisco-like > products, such as the Arista range. > > We've been doing some testing in the lab, and so far, things look good - > it's > easy to configure, and appears to do the job of getting packets from A to > B. > > We do have two concerns, though: > > 1) Cisco are strongly advising against using the Nexus switches in a WAN > scenario - as they're designed for "datacentre" use. They've so far said > they can't find anyone who can help validate designs using Nexus, and > instead are pushing us towards the NCS-5000 series switches. Same > chipset, > but 2-3 times the price! NCS does, however, support VPLS, so would be an > easier drop-in to our existing network. > > 2) Traffic engineering - we don't have a lot of requirement for this, but > do > have a small number of customers who buy A and B circuits, and require > them > to be routed across different paths on our network. This is easy with > MPLS > using explicit LSPs, but we've not yet worked out how to achieve the > same > thing in VXLAN. > > So, my question to the community is - have any of you used VXLAN as a > wide-area > layer 2 transport technology? Any pros or cons? Gotchas? Scare stories? > Recommendations? Am I trying to shoot myself in the foot? > > Many thanks, > > Simon > -- Best Wishes, Aftab A. Siddiqui From sabri at cluecentral.net Fri Jul 21 17:38:50 2017 From: sabri at cluecentral.net (Sabri Berisha) Date: Fri, 21 Jul 2017 10:38:50 -0700 (PDT) Subject: VXLAN for WAN Pseudowires? In-Reply-To: <20170720091219.GO15390@dilbert.slimey.org> References: <20170720091219.GO15390@dilbert.slimey.org> Message-ID: <354447531.22112.1500658730629.JavaMail.zimbra@cluecentral.net> > From: "Simon Lockhart" Hi, > 2) Traffic engineering - we don't have a lot of requirement for this, but do > have a small number of customers who buy A and B circuits, and require them > to be routed across different paths on our network. This is easy with MPLS > using explicit LSPs, but we've not yet worked out how to achieve the same > thing in VXLAN. You may be able to achieve this by using a second loopback for the B circuit VTEP IP address, and use either PBR or *cough* a static *cough* route *cough* towards a different path. Not pretty, but will probably work. Thanks, Sabri From jackson.tim at gmail.com Fri Jul 21 17:45:54 2017 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 21 Jul 2017 12:45:54 -0500 Subject: VXLAN for WAN Pseudowires? In-Reply-To: <354447531.22112.1500658730629.JavaMail.zimbra@cluecentral.net> References: <20170720091219.GO15390@dilbert.slimey.org> <354447531.22112.1500658730629.JavaMail.zimbra@cluecentral.net> Message-ID: On Fri, Jul 21, 2017 at 12:38 PM, Sabri Berisha wrote: > > From: "Simon Lockhart" > > Hi, > > > 2) Traffic engineering - we don't have a lot of requirement for this, > but do > > have a small number of customers who buy A and B circuits, and require > them > > to be routed across different paths on our network. This is easy with > MPLS > > using explicit LSPs, but we've not yet worked out how to achieve the > same > > thing in VXLAN. > > You may be able to achieve this by using a second loopback for the B > circuit VTEP IP address, and use either PBR or *cough* a static *cough* > route *cough* towards a different path. Not pretty, but will probably work. > > Thanks, > > Sabri > Or just use RSVP-TE... It's just IP.. T2 can do a MPLS lookup after encapsulating in VXLAN.. -- Tim From cscora at apnic.net Fri Jul 21 18:02:41 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Jul 2017 04:02:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170721180241.72A15BACB4@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 655763 Prefixes after maximum aggregation (per Origin AS): 255011 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 316184 Total ASes present in the Internet Routing Table: 57855 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 50046 Origin ASes announcing only one prefix: 22132 Transit ASes present in the Internet Routing Table: 7809 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN ( 55644) 26 Prefixes from unregistered ASNs in the Routing Table: 104 Numnber of instances of unregistered ASNs: 105 Number of 32-bit ASNs allocated by the RIRs: 19527 Number of 32-bit ASNs visible in the Routing Table: 15217 Prefixes from 32-bit ASNs in the Routing Table: 61847 Number of bogon 32-bit ASNs visible in the Routing Table: 59 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 343 Number of addresses announced to Internet: 2849795300 Equivalent to 169 /8s, 220 /16s and 108 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 218193 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 180011 Total APNIC prefixes after maximum aggregation: 51471 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 178999 Unique aggregates announced from the APNIC address blocks: 73959 APNIC Region origin ASes present in the Internet Routing Table: 8249 APNIC Prefixes per ASN: 21.70 APNIC Region origin ASes announcing only one prefix: 2316 APNIC Region transit ASes present in the Internet Routing Table: 1180 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 33 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3100 Number of APNIC addresses announced to Internet: 763447780 Equivalent to 45 /8s, 129 /16s and 73 /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: 199647 Total ARIN prefixes after maximum aggregation: 95101 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201649 Unique aggregates announced from the ARIN address blocks: 92742 ARIN Region origin ASes present in the Internet Routing Table: 17935 ARIN Prefixes per ASN: 11.24 ARIN Region origin ASes announcing only one prefix: 6647 ARIN Region transit ASes present in the Internet Routing Table: 1770 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: 2104 Number of ARIN addresses announced to Internet: 1109722784 Equivalent to 66 /8s, 37 /16s and 6 /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: 175510 Total RIPE prefixes after maximum aggregation: 86041 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171309 Unique aggregates announced from the RIPE address blocks: 103216 RIPE Region origin ASes present in the Internet Routing Table: 24194 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11129 RIPE Region transit ASes present in the Internet Routing Table: 3408 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6012 Number of RIPE addresses announced to Internet: 712705664 Equivalent to 42 /8s, 123 /16s and 6 /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: 83316 Total LACNIC prefixes after maximum aggregation: 18565 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 84534 Unique aggregates announced from the LACNIC address blocks: 39072 LACNIC Region origin ASes present in the Internet Routing Table: 6159 LACNIC Prefixes per ASN: 13.73 LACNIC Region origin ASes announcing only one prefix: 1707 LACNIC Region transit ASes present in the Internet Routing Table: 1137 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3671 Number of LACNIC addresses announced to Internet: 170767072 Equivalent to 10 /8s, 45 /16s and 178 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17173 Total AfriNIC prefixes after maximum aggregation: 3777 AfriNIC Deaggregation factor: 4.55 Prefixes being announced from the AfriNIC address blocks: 18929 Unique aggregates announced from the AfriNIC address blocks: 6883 AfriNIC Region origin ASes present in the Internet Routing Table: 1061 AfriNIC Prefixes per ASN: 17.84 AfriNIC Region origin ASes announcing only one prefix: 332 AfriNIC Region transit ASes present in the Internet Routing Table: 211 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 330 Number of AfriNIC addresses announced to Internet: 92743424 Equivalent to 5 /8s, 135 /16s and 39 /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 5471 4190 75 ERX-CERNET-BKB China Education and Rese 7545 3981 407 386 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2803 11133 747 KIXS-AS-KR Korea Telecom, KR 9829 2753 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2294 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2259 1433 107 VNPT-AS-VN VNPT Corp, VN 4755 2097 423 223 TATACOMM-AS TATA Communications formerl 7552 1651 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1598 361 142 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3818 2953 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3453 1341 86 SHAW - Shaw Communications Inc., CA 18566 2178 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2013 2182 424 CHARTER-NET-HKY-NC - Charter Communicat 16509 1834 3794 602 AMAZON-02 - Amazon.com, Inc., US 209 1825 5065 636 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1813 327 293 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1697 854 231 ITCDELTA - Earthlink, Inc., US 11492 1563 245 504 CABLEONE - CABLE ONE, 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2924 964 2113 AKAMAI-ASN1, US 8551 2761 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2032 331 417 TELLCOM-AS, TR 9121 1946 1691 17 TTNET, TR 12479 1595 1046 54 UNI2-AS, ES 13188 1593 100 55 TRIOLAN, UA 12389 1518 1408 629 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1083 544 15 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 10620 3533 541 232 Telmex Colombia S.A., CO 8151 2502 3398 585 Uninet S.A. de C.V., MX 11830 2087 369 57 Instituto Costarricense de Electricidad 6503 1556 437 53 Axtel, S.A.B. de C.V., MX 7303 1554 1013 244 Telecom Argentina S.A., AR 6147 1236 377 27 Telefonica del Peru S.A.A., PE 3816 1024 501 93 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 957 2294 192 CLARO S.A., BR 11172 916 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 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 1243 398 51 LINKdotNET-AS, EG 37611 738 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 649 1375 26 ETISALAT-MISR, EG 24835 501 850 15 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 355 35 7 WANANCHI-, KE 8452 307 1730 17 TE-AS TE-AS, EG 2018 303 327 74 TENET-1, ZA 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 5471 4190 75 ERX-CERNET-BKB China Education and Rese 7545 3981 407 386 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3818 2953 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 541 232 Telmex Colombia S.A., CO 6327 3453 1341 86 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2924 964 2113 AKAMAI-ASN1, US 4766 2803 11133 747 KIXS-AS-KR Korea Telecom, KR 8551 2761 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3818 3660 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3981 3595 TPG-INTERNET-AP TPG Telecom Limited, AU 6327 3453 3367 SHAW - Shaw Communications Inc., CA 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3533 3301 Telmex Colombia S.A., CO 17974 2967 2894 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2761 2721 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2294 2262 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2753 2204 BSNL-NIB National Internet Backbone, IN 45899 2259 2152 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65532 PRIVATE 14.192.19.0/24 132717 NDCTPL-IN NxtGen Datacenter & 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 4294901876 PRIVATE 59.101.19.0/24 2764 AAPT AAPT Limited, AU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 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:15 /9:13 /10:36 /11:104 /12:284 /13:553 /14:1047 /15:1850 /16:13465 /17:7641 /18:13421 /19:24655 /20:38654 /21:41261 /22:78064 /23:65004 /24:367480 /25:868 /26:607 /27:638 /28:34 /29:23 /30:18 /31:2 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3251 3453 SHAW - Shaw Communications Inc., CA 22773 2987 3818 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 8551 2226 2761 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2071 2178 MEGAPATH5-US - MegaPath Corporation, US 30036 1601 1813 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1477 2087 Instituto Costarricense de Electricidad y Telec 10620 1476 3533 Telmex Colombia S.A., CO 11492 1406 1563 CABLEONE - CABLE ONE, INC., US 6389 1372 2066 BELLSOUTH-NET-BLK - BellSouth.net 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:824 4:18 5:2418 6:34 8:1048 12:1838 13:130 14:1729 15:28 16:2 17:160 18:90 20:61 23:2420 24:1909 25:2 27:2471 29:1 31:1917 32:84 33:16 35:21 36:385 37:2341 38:1344 39:64 40:98 41:2975 42:462 43:1942 44:71 45:2931 46:2795 47:156 49:1214 50:994 51:19 52:836 54:365 55:6 56:4 57:43 58:1562 59:1050 60:381 61:1961 62:1695 63:1903 64:4618 65:2216 66:4570 67:2280 68:1244 69:3372 70:1151 71:585 72:2208 74:2693 75:389 76:427 77:1525 78:1422 79:1951 80:1412 81:1388 82:995 83:723 84:942 85:1790 86:456 87:1182 88:756 89:2119 90:170 91:6196 92:983 93:2366 94:2378 95:2670 96:635 97:350 98:1063 99:90 100:155 101:1228 103:15377 104:3007 105:190 106:512 107:1768 108:830 109:3079 110:1442 111:1740 112:1191 113:1253 114:1037 115:1721 116:1803 117:1714 118:2140 119:1659 120:1073 121:1110 122:2263 123:1820 124:1478 125:1903 128:810 129:640 130:434 131:1400 132:526 133:201 134:665 135:223 136:448 137:430 138:1939 139:494 140:389 141:609 142:774 143:915 144:803 145:180 146:1035 147:697 148:1465 149:585 150:706 151:980 152:703 153:299 154:864 155:747 156:629 157:659 158:469 159:1525 160:719 161:740 162:2516 163:536 164:896 165:1380 166:378 167:1240 168:2976 169:829 170:3432 171:328 172:1023 173:1963 174:806 175:741 176:1893 177:4094 178:2557 179:1126 180:2205 181:1877 182:2344 183:1001 184:873 185:10184 186:3257 187:2221 188:2607 189:1829 190:8315 191:1360 192:9521 193:5775 194:4681 195:3928 196:2067 197:1393 198:5497 199:5889 200:7504 201:4326 202:10368 203:10000 204:4487 205:2824 206:3023 207:3145 208:3936 209:3969 210:3964 211:2145 212:2862 213:2525 214:856 215:66 216:5876 217:2098 218:900 219:599 220:1696 221:932 222:744 223:1190 End of report From nanog at ics-il.net Mon Jul 24 13:37:43 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 24 Jul 2017 08:37:43 -0500 (CDT) Subject: XO Provisioning in St. Louis Message-ID: <1570721742.1830.1500903462257.JavaMail.mhammett@ThunderFuck> So far my attempts to reach someone at XO Communications have been fruitless. I'm looking for someone that deals with provisioning in St. Louis. We've (officially our partner, but we need it as well) been waiting months for a cross connect and when they finally deliver, it didn't connect A to Z. HELP! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Mon Jul 24 14:38:24 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 24 Jul 2017 09:38:24 -0500 (CDT) Subject: XO Provisioning in St. Louis In-Reply-To: <1570721742.1830.1500903462257.JavaMail.mhammett@ThunderFuck> References: <1570721742.1830.1500903462257.JavaMail.mhammett@ThunderFuck> Message-ID: <1685128643.1862.1500907102307.JavaMail.mhammett@ThunderFuck> This e-mail was of a sufficient poke to the original contact I reached out to and the ball is now rolling. You will now be returned to your regularly scheduled programming. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Monday, July 24, 2017 8:37:43 AM Subject: XO Provisioning in St. Louis So far my attempts to reach someone at XO Communications have been fruitless. I'm looking for someone that deals with provisioning in St. Louis. We've (officially our partner, but we need it as well) been waiting months for a cross connect and when they finally deliver, it didn't connect A to Z. HELP! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From josh at kyneticwifi.com Mon Jul 24 14:49:54 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 24 Jul 2017 09:49:54 -0500 Subject: XO Provisioning in St. Louis In-Reply-To: <1685128643.1862.1500907102307.JavaMail.mhammett@ThunderFuck> References: <1570721742.1830.1500903462257.JavaMail.mhammett@ThunderFuck> <1685128643.1862.1500907102307.JavaMail.mhammett@ThunderFuck> Message-ID: 😁 On Jul 24, 2017 9:40 AM, "Mike Hammett" wrote: > This e-mail was of a sufficient poke to the original contact I reached out > to and the ball is now rolling. > > You will now be returned to your regularly scheduled programming. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "NANOG" > Sent: Monday, July 24, 2017 8:37:43 AM > Subject: XO Provisioning in St. Louis > > > So far my attempts to reach someone at XO Communications have been > fruitless. I'm looking for someone that deals with provisioning in St. > Louis. We've (officially our partner, but we need it as well) been waiting > months for a cross connect and when they finally deliver, it didn't connect > A to Z. > > > HELP! > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From james.braunegg at micron21.com Wed Jul 26 02:25:22 2017 From: james.braunegg at micron21.com (James Braunegg) Date: Wed, 26 Jul 2017 02:25:22 +0000 Subject: Cisco Nexus 93180YC Switch Feedback Message-ID: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> Dear Nanog Just wondering if anyone is using the Cisco Nexus 93180YC with the LAN enterprise license and has any honest feedback about this platform, especially if you are using VXLAN routing and eVPN, would love to hear from you. For those that don't know the Cisco Nexus 93180YC is a 1RU switch with 48 x 25gbit ports SFP+ ports (1G, 10G or 25G) + 6 x 100gbit QSFP uplink ports. (40G, 50G or 100G) Kindest Regards James Braunegg [cid:image001.png at 01D280A4.01865B60] 1300 769 972 / 0488 997 207 james at micron21.com www.micron21.com/ [cid:image002.png at 01D280A4.01865B60] [cid:image003.png at 01D280A4.01865B60] [cid:image004.png at 01D280A4.01865B60] Follow us on Twitter for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. From colton.conor at gmail.com Wed Jul 26 02:28:34 2017 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 25 Jul 2017 21:28:34 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> Message-ID: Besides FS.com and http://www.beetlefiberoptics.com, do you have any more recommendations for passive muxes? I usually stick to and like FiberStore, but I am wondering if there is anything out there better/cheaper. One of the things I am noticing is the CWDM and DWDM SFP+ optics are quite expensive at $250 for CWDM and $350 for DWDM. I guess it shouldn't be cheap to send 10G around a ring, but I am wondering what transponders cost. On Tue, Jun 20, 2017 at 3:55 AM, Jeroen Wunnink wrote: > Another alternative is to ask the http://www.beetlefiberoptics.com guys. > They build muxes on spec and they can also provide a 1310nm wide-band port > on their units which allows a 40/100G-LR4 aside from the 1550nm DWDM band. > > We’ve used some simple splitters (line/1310nm LR4/1550nm DWDM ports on a > unit) and full passive DWDM muxes with a 40/100G-LR4 port on there and > these work pretty good. > > > > > Jeroen Wunnink > IP Engineering manager > office: +31.208.200.622 ext. 1011 > Amsterdam Office > www.gtt.net > > > > > On 20/06/2017, 01:14, "NANOG on behalf of Colton Conor" < > nanog-bounces at nanog.org on behalf of colton.conor at gmail.com> wrote: > > Do you have any idea if fiberstore has one with both a monitor and 1310 > wideband port? I would want both. > > Seeing as how they don't charge extra for an expansion port, but do for > other special ports I am thinking of just using the expansion port. > > On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz < > faisal at snappytelecom.net> > wrote: > > > > > >>From the sounds of it, no one knows the real difference between the > > expansion port, 1310 port, and 1550 port > > > > Hmm.. not sure how you are reading this... > > I believe that there is no 'standard' and as such the actual filter > on the > > mux/demux you are using may vary by mfg. > > I can confirm what is an expansion port... (pass everything thru > that is > > not being filtered by the mux/demux ) > > I can also confirm that Fiberstore 1310nm port (not to be confused > with > > the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics. > > I don't have experience with the 1550nm port. > > > > >>For real world applications, I would assume the monitor port would > be to > > plug in a handheld meter, and see which channels are coming through > that > > node without breaking the ring. > > > > Correct that is what it is designed for..... it allows a fraction of > > light (I am guessing would also cause an increase in insertion loss > > figure). > > > > >> Not sure if their would be a monitor port for both directions is > you > > were using a OADM? > > If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor > ports, > > you will see that they are on both sides east & west. > > > > > > Regards. > > > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > 7266 SW 48 Street > > Miami, FL 33155 > > Tel: 305 663 5518 x 232 <(305)%20663-5518> > > > > Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: > > Support at Snappytelecom.net > > > > ------------------------------ > > > > *From: *"Colton Conor" > > *To: *"Faisal Imtiaz" > > *Cc: *"Mike Hammett" , "Luke Guillory" < > > lguillory at reservetele.com>, "nanog list" > > *Sent: *Monday, June 19, 2017 4:14:19 PM > > > > *Subject: *Re: DWDM Mux/Demux using 40G Optics > > > > Thanks for the answers. From the sounds of it, no one knows the real > > difference between the expansion port, 1310 port, and 1550 port. For > real > > world applications, I would assume the monitor port would be to plug > in a > > handheld meter, and see which channels are coming through that node > without > > breaking the ring. Not sure if their would be a monitor port for both > > directions is you were using a OADM? > > > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < > faisal at snappytelecom.net> > > wrote: > > > >> Answers in-line ... > >> > >> Faisal Imtiaz > >> Snappy Internet & Telecom > >> 7266 SW 48 Street > >> Miami, FL 33155 > >> Tel: 305 663 5518 x 232 <(305)%20663-5518> > >> > >> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: > >> Support at Snappytelecom.net > >> ------------------------------ > >> > >> *From: *"Colton Conor" > >> *To: *"Mike Hammett" > >> *Cc: *"Luke Guillory" , "nanog list" < > >> nanog at nanog.org>, "Faisal Imtiaz" > >> *Sent: *Monday, June 19, 2017 3:30:37 PM > >> *Subject: *Re: DWDM Mux/Demux using 40G Optics > >> > >> I guess that is the real question. Besides the client ports that are > >> clearly identified by channel number on Muxes, what channels can the > >> special ports handle? > >> http://www.fs.com/products/43723.html It has 4 special service port > >> options: > >> > >> 1. Expansion Port (Based on what I am seeing, I think this would be > to > >> stack another mux if you needed more channels. So I assume it > allows all > >> channels to be added besides the client channels?) > >> > >> > >> Exactly... this is basically a pass thru port, i.e. what is not > getting > >> mux/demux should get passed thru (keep the insertion loss in mind). > >> > >> 2. Monitor Port (I think this is just a tap that you would hook a > monitor > >> up to, and be able to see all channels coming through with a meter. > I > >> assume not a good idea to add/drop channels through this port)? > >> > >> I don't use this port, but supposedly it will pass a fraction 5% > of the > >> light from the main port so that it can be monitored. May be > someone else > >> can offer some practical use for this port. > >> > >> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just > 1310 > >> since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, > so what > >> range does it really support or is there no a range?) > >> > >> Not sure about the range question, but this is the port for having > the > >> 40g/100g QSFP+ pass thru > >> > >> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the > 1330nm?) > >> > >> I have not had the need to explore this in detail, but from my > initial > >> understanding, this can be used for ZR (long range optics) and or > to stack > >> a DWDM Mux > >> > >> Would you recommend a monitor port on every mux you buy? > >> > >> As I shared above, I don't. > >> > >> > >> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett > wrote: > >> > >>> Verify pass-through frequencies for the 1310 (or equivalent) for > the > >>> passive mux in question. This would only work for a single channel. > >>> > >>> > >>> > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> > >>> Midwest-IX > >>> http://www.midwest-ix.com > >>> > >>> ------------------------------ > >>> *From: *"Luke Guillory" > >>> *To: *"Faisal Imtiaz" , "Colton Conor" < > >>> colton.conor at gmail.com> > >>> *Cc: *"nanog list" > >>> *Sent: *Monday, June 19, 2017 2:13:10 PM > >>> *Subject: *RE: DWDM Mux/Demux using 40G Optics > >>> > >>> > >>> Faisal, > >>> > >>> How would he inject his current 4x10 40g into the mux which is > currently > >>> on a single LC cable? > >>> > >>> > >>> > >>> > >>> > >>> Luke Guillory > >>> Network Operations Manager > >>> > >>> Tel: 985.536.1212 <(985)%20536-1212> > >>> Fax: 985.536.0300 <(985)%20536-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 Faisal > Imtiaz > >>> Sent: Monday, June 19, 2017 2:02 PM > >>> To: Colton Conor > >>> Cc: nanog list > >>> Subject: Re: DWDM Mux/Demux using 40G Optics > >>> > >>> Answers in-line below. > >>> > >>> > >>> > >>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a > common > >>> configuration of > >>> > >>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > >>> > >>> in the DWDM muxes you will see them listed as # of Port + > 1310 pass > >>> thru channel. > >>> > >>> These are exactly what you are looking for ..... :) > >>> > >>> > >>> > >> > > > > > From woody at pch.net Wed Jul 26 02:39:36 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 25 Jul 2017 19:39:36 -0700 Subject: Cisco Nexus 93180YC Switch Feedback In-Reply-To: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> References: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> Message-ID: > On Jul 25, 2017, at 7:25 PM, James Braunegg wrote: > > Dear Nanog > > Just wondering if anyone is using the Cisco Nexus 93180YC with the LAN enterprise license and has any honest feedback about this platform, especially if you are using VXLAN routing and eVPN, would love to hear from you. > > For those that don't know the Cisco Nexus 93180YC is a 1RU switch with 48 x 25gbit ports SFP+ ports (1G, 10G or 25G) + 6 x 100gbit QSFP uplink ports. (40G, 50G or 100G) We’ve started testing them, as well as the 92160YCX and C92300YC, for IXP use. Notably only four of the six 100G ports on the 92160YCX will run at 100G, leaving two at 40G. Anybody had any luck sourcing 2x25G NICs for Cisco UCS servers? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From bengelly at gmail.com Wed Jul 26 05:48:59 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 26 Jul 2017 07:48:59 +0200 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> Message-ID: <7E6247E9-76CD-490E-968C-725B07EC12EB@gmail.com> Hi, Ex CubeOptics (now Huber Schuner) are just great. Been using them for years, rock solid. I highly recommend them. Best regards. > Le 26 juil. 2017 à 04:28, Colton Conor a écrit : > > Besides FS.com and http://www.beetlefiberoptics.com, do you have any more > recommendations for passive muxes? I usually stick to and like FiberStore, > but I am wondering if there is anything out there better/cheaper. > > One of the things I am noticing is the CWDM and DWDM SFP+ optics are quite > expensive at $250 for CWDM and $350 for DWDM. I guess it shouldn't be > cheap to send 10G around a ring, but I am wondering what transponders cost. > > On Tue, Jun 20, 2017 at 3:55 AM, Jeroen Wunnink > wrote: > >> Another alternative is to ask the http://www.beetlefiberoptics.com guys. >> They build muxes on spec and they can also provide a 1310nm wide-band port >> on their units which allows a 40/100G-LR4 aside from the 1550nm DWDM band. >> >> We’ve used some simple splitters (line/1310nm LR4/1550nm DWDM ports on a >> unit) and full passive DWDM muxes with a 40/100G-LR4 port on there and >> these work pretty good. >> >> >> >> >> Jeroen Wunnink >> IP Engineering manager >> office: +31.208.200.622 ext. 1011 >> Amsterdam Office >> www.gtt.net >> >> >> >> >> On 20/06/2017, 01:14, "NANOG on behalf of Colton Conor" < >> nanog-bounces at nanog.org on behalf of colton.conor at gmail.com> wrote: >> >> Do you have any idea if fiberstore has one with both a monitor and 1310 >> wideband port? I would want both. >> >> Seeing as how they don't charge extra for an expansion port, but do for >> other special ports I am thinking of just using the expansion port. >> >> On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz < >> faisal at snappytelecom.net> >> wrote: >> >>> >>>>> From the sounds of it, no one knows the real difference between the >>> expansion port, 1310 port, and 1550 port >>> >>> Hmm.. not sure how you are reading this... >>> I believe that there is no 'standard' and as such the actual filter >> on the >>> mux/demux you are using may vary by mfg. >>> I can confirm what is an expansion port... (pass everything thru >> that is >>> not being filtered by the mux/demux ) >>> I can also confirm that Fiberstore 1310nm port (not to be confused >> with >>> the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics. >>> I don't have experience with the 1550nm port. >>> >>>>> For real world applications, I would assume the monitor port would >> be to >>> plug in a handheld meter, and see which channels are coming through >> that >>> node without breaking the ring. >>> >>> Correct that is what it is designed for..... it allows a fraction of >>> light (I am guessing would also cause an increase in insertion loss >>> figure). >>> >>>>> Not sure if their would be a monitor port for both directions is >> you >>> were using a OADM? >>> If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor >> ports, >>> you will see that they are on both sides east & west. >>> >>> >>> Regards. >>> >>> >>> Faisal Imtiaz >>> Snappy Internet & Telecom >>> 7266 SW 48 Street >>> Miami, FL 33155 >>> Tel: 305 663 5518 x 232 <(305)%20663-5518> >>> >>> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: >>> Support at Snappytelecom.net >>> >>> ------------------------------ >>> >>> *From: *"Colton Conor" >>> *To: *"Faisal Imtiaz" >>> *Cc: *"Mike Hammett" , "Luke Guillory" < >>> lguillory at reservetele.com>, "nanog list" >>> *Sent: *Monday, June 19, 2017 4:14:19 PM >>> >>> *Subject: *Re: DWDM Mux/Demux using 40G Optics >>> >>> Thanks for the answers. From the sounds of it, no one knows the real >>> difference between the expansion port, 1310 port, and 1550 port. For >> real >>> world applications, I would assume the monitor port would be to plug >> in a >>> handheld meter, and see which channels are coming through that node >> without >>> breaking the ring. Not sure if their would be a monitor port for both >>> directions is you were using a OADM? >>> >>> On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < >> faisal at snappytelecom.net> >>> wrote: >>> >>>> Answers in-line ... >>>> >>>> Faisal Imtiaz >>>> Snappy Internet & Telecom >>>> 7266 SW 48 Street >>>> Miami, FL 33155 >>>> Tel: 305 663 5518 x 232 <(305)%20663-5518> >>>> >>>> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: >>>> Support at Snappytelecom.net >>>> ------------------------------ >>>> >>>> *From: *"Colton Conor" >>>> *To: *"Mike Hammett" >>>> *Cc: *"Luke Guillory" , "nanog list" < >>>> nanog at nanog.org>, "Faisal Imtiaz" >>>> *Sent: *Monday, June 19, 2017 3:30:37 PM >>>> *Subject: *Re: DWDM Mux/Demux using 40G Optics >>>> >>>> I guess that is the real question. Besides the client ports that are >>>> clearly identified by channel number on Muxes, what channels can the >>>> special ports handle? >>>> http://www.fs.com/products/43723.html It has 4 special service port >>>> options: >>>> >>>> 1. Expansion Port (Based on what I am seeing, I think this would be >> to >>>> stack another mux if you needed more channels. So I assume it >> allows all >>>> channels to be added besides the client channels?) >>>> >>>> >>>> Exactly... this is basically a pass thru port, i.e. what is not >> getting >>>> mux/demux should get passed thru (keep the insertion loss in mind). >>>> >>>> 2. Monitor Port (I think this is just a tap that you would hook a >> monitor >>>> up to, and be able to see all channels coming through with a meter. >> I >>>> assume not a good idea to add/drop channels through this port)? >>>> >>>> I don't use this port, but supposedly it will pass a fraction 5% >> of the >>>> light from the main port so that it can be monitored. May be >> someone else >>>> can offer some practical use for this port. >>>> >>>> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just >> 1310 >>>> since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, >> so what >>>> range does it really support or is there no a range?) >>>> >>>> Not sure about the range question, but this is the port for having >> the >>>> 40g/100g QSFP+ pass thru >>>> >>>> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the >> 1330nm?) >>>> >>>> I have not had the need to explore this in detail, but from my >> initial >>>> understanding, this can be used for ZR (long range optics) and or >> to stack >>>> a DWDM Mux >>>> >>>> Would you recommend a monitor port on every mux you buy? >>>> >>>> As I shared above, I don't. >>>> >>>> >>>> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett >> wrote: >>>> >>>>> Verify pass-through frequencies for the 1310 (or equivalent) for >> the >>>>> passive mux in question. This would only work for a single channel. >>>>> >>>>> >>>>> >>>>> ----- >>>>> Mike Hammett >>>>> Intelligent Computing Solutions >>>>> http://www.ics-il.com >>>>> >>>>> Midwest-IX >>>>> http://www.midwest-ix.com >>>>> >>>>> ------------------------------ >>>>> *From: *"Luke Guillory" >>>>> *To: *"Faisal Imtiaz" , "Colton Conor" < >>>>> colton.conor at gmail.com> >>>>> *Cc: *"nanog list" >>>>> *Sent: *Monday, June 19, 2017 2:13:10 PM >>>>> *Subject: *RE: DWDM Mux/Demux using 40G Optics >>>>> >>>>> >>>>> Faisal, >>>>> >>>>> How would he inject his current 4x10 40g into the mux which is >> currently >>>>> on a single LC cable? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Luke Guillory >>>>> Network Operations Manager >>>>> >>>>> Tel: 985.536.1212 <(985)%20536-1212> >>>>> Fax: 985.536.0300 <(985)%20536-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 Faisal >> Imtiaz >>>>> Sent: Monday, June 19, 2017 2:02 PM >>>>> To: Colton Conor >>>>> Cc: nanog list >>>>> Subject: Re: DWDM Mux/Demux using 40G Optics >>>>> >>>>> Answers in-line below. >>>>> >>>>> >>>>> >>>>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a >> common >>>>> configuration of >>>>> >>>>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>>>> >>>>> in the DWDM muxes you will see them listed as # of Port + >> 1310 pass >>>>> thru channel. >>>>> >>>>> These are exactly what you are looking for ..... :) >>>>> >>>>> >>>>> >>>> >>> >> >> >> From johnstong at westmancom.com Wed Jul 26 14:04:16 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 26 Jul 2017 14:04:16 +0000 Subject: Datacenter powering Message-ID: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> Anybody out there willing to provide a brief description of the power configuration in your datacenter today and further comment on if there are ways you would reconfigure it given the chance? To provide context, I am asking from the standpoint of a datacenter operated for your own use, not part of a co-location type environment. Total power draw in my situation is ~100kW. graham From lists at mtin.net Wed Jul 26 15:24:13 2017 From: lists at mtin.net (Justin Wilson) Date: Wed, 26 Jul 2017 11:24:13 -0400 Subject: Datacenter powering In-Reply-To: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> Message-ID: We have our exchange in these facilities. Some info on their web-site about power. https://lifelinedatacenters.com/data-center-infographics/ Justin > On Jul 26, 2017, at 10:04 AM, Graham Johnston wrote: > > Anybody out there willing to provide a brief description of the power configuration in your datacenter today and further comment on if there are ways you would reconfigure it given the chance? > > To provide context, I am asking from the standpoint of a datacenter operated for your own use, not part of a co-location type environment. Total power draw in my situation is ~100kW. > > graham > From james.braunegg at micron21.com Thu Jul 27 03:13:10 2017 From: james.braunegg at micron21.com (James Braunegg) Date: Thu, 27 Jul 2017 03:13:10 +0000 Subject: Datacenter powering In-Reply-To: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> Message-ID: <025ad08bc28d49dd899502cb70a2fbc4@EX-01.m21.local> Dear Graham Happy to provide information as I love datacentre infrastructure along with the fact our design was awarded Uptime Institute Tier IV Accreditation. At a very high level we have 3 switch rooms (R1, R2 and R3) Switch Room 1 Has two ATS (one primary one backup) both ATS are feed directly from street power Room 1 ATS A is connected to Generator A (Active) Room 1 ATS B is connected to Generator B (Standby) Downstream from Room 1 ATS A and B is distribution board R1-A, R1-B and R1-C Switch board R1-A and R1-B is IT load, switch board R1-C is mechanical load Both switch boards R1-A and R1-B have their own dedicated UPS and provider power to all racks (Feeds R1-UPS-A and R1-UPS-B) Switch Room 2 Has two ATS (one primary one backup) both ATS are feed directly from street power Room 2 ATS A is connected to Generator A (Standby) Room 2 ATS B is connected to Generator B (Active) Downstream from Room 2 ATS A and B is distribution board R2-A, R2-B and R2-C Switch board R2-A and R2-B is IT load, switch board R2-C is mechanical load Both switch boards R2-A and R2-B have their own dedicated UPS and provider power to all racks (Feeds R2-UPS-A and R2-UPS-B) How it all works The end result is each rack within the facility has four 32 amp PDU rails, where each rail is feed from an independent UPS via 4 independent and isolated cable paths. Each PDU rail within each rack has 24 x c13 sockets where each C13 socket is metered, monitored (Web, API, Email and SNMP) & alarmed (Min / Max on each socket) (amps, kwh, PF etc) so we know the exact power consumption on each socket on each PDU in each rack. Each dual corded devices within any rack the device must be connected to both Room 1 and Room 2 to provide correct power redundancy. For single corded devices we have a 1RU STS devices in each rack which takes protected power from both Room 1 and Room 2 to provide STS protected power to single corded devices if required. Switch Room 3 Switch Room 3 has two ATS (one primary one backup) both ATS are feed directly from street power Room 3 ATS A is connected to Generator C (Active) Room 3 ATS B is connected to Generator C (Standby) Switch room 3 provides a third independent source of protected power to the datacentre if required for additional mission critical applications, and fully independent power to support backup cooling infrastructure. If you want to know more we have some info graphics and more information on our website here - https://www.micron21.com/about-us/the-micron21-datacentre/ As for what would I change in our design, at this stage nothing... Planning and designing a datacentre infrastructure which meets your high availability requirements day one is key before you build. Hope this helps provide you some information to review. If you have any more questions please just ask. Kindest Regards, James Braunegg [cid:image001.png at 01D280A4.01865B60] 1300 769 972 / 0488 997 207 james at micron21.com www.micron21.com/ [cid:image002.png at 01D280A4.01865B60] [cid:image003.png at 01D280A4.01865B60] [cid:image004.png at 01D280A4.01865B60] Follow us on Twitter for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Graham Johnston Sent: Thursday, 27 July 2017 12:04 AM To: 'nanog at nanog.org' Subject: Datacenter powering Anybody out there willing to provide a brief description of the power configuration in your datacenter today and further comment on if there are ways you would reconfigure it given the chance? To provide context, I am asking from the standpoint of a datacenter operated for your own use, not part of a co-location type environment. Total power draw in my situation is ~100kW. graham From coyo at darkdna.net Thu Jul 27 05:15:30 2017 From: coyo at darkdna.net (Coyo Stormcaller) Date: Thu, 27 Jul 2017 00:15:30 -0500 Subject: Datacenter powering In-Reply-To: <025ad08bc28d49dd899502cb70a2fbc4@EX-01.m21.local> References: <82C0CE81789FE64D8F4D15263191829733ADE464@MSG6.westman.int> <025ad08bc28d49dd899502cb70a2fbc4@EX-01.m21.local> Message-ID: <1501132530.25373.1.camel@darkdna.net> On Thu, 2017-07-27 at 03:13 +0000, James Braunegg wrote: > If you want to know more we have some info graphics and more > information on our website here - https://www.micron21.com/about-us/t > he-micron21-datacentre/ An amazing read, thank you! From rod.beck at unitedcablecompany.com Thu Jul 27 12:08:46 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 27 Jul 2017 12:08:46 +0000 Subject: Hillsborough/Portland/Seattle Message-ID: Hi, I am interested in knowing if there is strong Layer 1 and Layer 2 demand on this route. Just want your market observations. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From bryan at shout.net Thu Jul 27 16:18:03 2017 From: bryan at shout.net (Bryan Holloway) Date: Thu, 27 Jul 2017 11:18:03 -0500 Subject: Vonage (AS22343) Network Engineer lurking? Message-ID: We have a mutual customer with what appears to be a routing issue between us and you. Could someone ping me off-list? The web-site support channels are really more for end-users ... Thanks!! From bryan at shout.net Thu Jul 27 17:28:22 2017 From: bryan at shout.net (Bryan Holloway) Date: Thu, 27 Jul 2017 12:28:22 -0500 Subject: traceroute from XO network? Message-ID: <78d10b4d-cec3-79a7-9b29-f54def88ec66@shout.net> Hello all, If there's someone out there on XO's network, preferably in the Dallas area, could you send me a traceroute to the following IP: 153.33.12.1 XO's Looking Glass seems to be broken. It'll do BGP, but pings and traceroutes come back with an empty display. Off-list is fine ... Thanks! From bryan at shout.net Thu Jul 27 18:08:19 2017 From: bryan at shout.net (Bryan Holloway) Date: Thu, 27 Jul 2017 13:08:19 -0500 Subject: traceroute from XO network? In-Reply-To: <78d10b4d-cec3-79a7-9b29-f54def88ec66@shout.net> References: <78d10b4d-cec3-79a7-9b29-f54def88ec66@shout.net> Message-ID: An XO dude got back to me ... thanks, all! On 7/27/17 12:28 PM, Bryan Holloway wrote: > Hello all, > > If there's someone out there on XO's network, preferably in the Dallas > area, could you send me a traceroute to the following IP: > > 153.33.12.1 > > XO's Looking Glass seems to be broken. It'll do BGP, but pings and > traceroutes come back with an empty display. > > Off-list is fine ... > > Thanks! From nanog at wayne47.com Thu Jul 27 19:54:01 2017 From: nanog at wayne47.com (Michael Wayne) Date: Thu, 27 Jul 2017 15:54:01 -0400 Subject: Admiral Hosting in London Message-ID: <20170727195401.GI7311@manor.msen.com> We were contacted by Admiral Hosting in London to rent some our unused IP space. While they insist that they're not spammers, we can not find out much about them. Has anyone had any dealings with this company? Legit? Scam? We are not interested in contributing to the Scam/Spam problem and figured I would ask here. As this is not, technically, NA-related, private replies are preferred. I'll summarize to the list. From randy at psg.com Fri Jul 28 04:22:11 2017 From: randy at psg.com (Randy Bush) Date: Fri, 28 Jul 2017 13:22:11 +0900 Subject: Admiral Hosting in London In-Reply-To: <20170727195401.GI7311@manor.msen.com> References: <20170727195401.GI7311@manor.msen.com> Message-ID: > We were contacted by Admiral Hosting in London to rent some our > unused IP space. anyone wanting to rent/lease space is 99% sure to be not nice folk. if you get your space back, it will be radioactive with an amazingly long half life. if you are willing to let go of the space, just tell them the price for which you are willing to sell it. randy From tknchris at gmail.com Fri Jul 28 04:31:14 2017 From: tknchris at gmail.com (chris) Date: Fri, 28 Jul 2017 00:31:14 -0400 Subject: Admiral Hosting in London In-Reply-To: References: <20170727195401.GI7311@manor.msen.com> Message-ID: https://www.youtube.com/watch?v=7MQ356o5nCk On Fri, Jul 28, 2017 at 12:22 AM, Randy Bush wrote: > > We were contacted by Admiral Hosting in London to rent some our > > unused IP space. > > anyone wanting to rent/lease space is 99% sure to be not nice folk. > if you get your space back, it will be radioactive with an amazingly > long half life. > > if you are willing to let go of the space, just tell them the price > for which you are willing to sell it. > > randy > From cscora at apnic.net Fri Jul 28 18:02:37 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Jul 2017 04:02:37 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170728180237.5DA88BACB4@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 656283 Prefixes after maximum aggregation (per Origin AS): 255445 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 316497 Total ASes present in the Internet Routing Table: 57870 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 50062 Origin ASes announcing only one prefix: 22111 Transit ASes present in the Internet Routing Table: 7808 Transit-only ASes present in the Internet Routing Table: 220 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 109 Numnber of instances of unregistered ASNs: 113 Number of 32-bit ASNs allocated by the RIRs: 19595 Number of 32-bit ASNs visible in the Routing Table: 15249 Prefixes from 32-bit ASNs in the Routing Table: 62208 Number of bogon 32-bit ASNs visible in the Routing Table: 62 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 335 Number of addresses announced to Internet: 2850653156 Equivalent to 169 /8s, 233 /16s and 131 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 218235 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179818 Total APNIC prefixes after maximum aggregation: 51619 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 178843 Unique aggregates announced from the APNIC address blocks: 74040 APNIC Region origin ASes present in the Internet Routing Table: 8246 APNIC Prefixes per ASN: 21.69 APNIC Region origin ASes announcing only one prefix: 2298 APNIC Region transit ASes present in the Internet Routing Table: 1173 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 36 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3100 Number of APNIC addresses announced to Internet: 763610596 Equivalent to 45 /8s, 131 /16s and 197 /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: 200082 Total ARIN prefixes after maximum aggregation: 95218 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201993 Unique aggregates announced from the ARIN address blocks: 92842 ARIN Region origin ASes present in the Internet Routing Table: 17937 ARIN Prefixes per ASN: 11.26 ARIN Region origin ASes announcing only one prefix: 6649 ARIN Region transit ASes present in the Internet Routing Table: 1768 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: 2117 Number of ARIN addresses announced to Internet: 1110017696 Equivalent to 66 /8s, 41 /16s and 134 /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: 175626 Total RIPE prefixes after maximum aggregation: 86230 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171445 Unique aggregates announced from the RIPE address blocks: 103380 RIPE Region origin ASes present in the Internet Routing Table: 24230 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11135 RIPE Region transit ASes present in the Internet Routing Table: 3416 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6035 Number of RIPE addresses announced to Internet: 712884352 Equivalent to 42 /8s, 125 /16s and 192 /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: 83448 Total LACNIC prefixes after maximum aggregation: 18518 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 84697 Unique aggregates announced from the LACNIC address blocks: 39005 LACNIC Region origin ASes present in the Internet Routing Table: 6139 LACNIC Prefixes per ASN: 13.80 LACNIC Region origin ASes announcing only one prefix: 1696 LACNIC Region transit ASes present in the Internet Routing Table: 1138 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3666 Number of LACNIC addresses announced to Internet: 170886624 Equivalent to 10 /8s, 47 /16s and 133 /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: 17198 Total AfriNIC prefixes after maximum aggregation: 3803 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 18970 Unique aggregates announced from the AfriNIC address blocks: 6925 AfriNIC Region origin ASes present in the Internet Routing Table: 1063 AfriNIC Prefixes per ASN: 17.85 AfriNIC Region origin ASes announcing only one prefix: 332 AfriNIC Region transit ASes present in the Internet Routing Table: 212 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 331 Number of AfriNIC addresses announced to Internet: 92850944 Equivalent to 5 /8s, 136 /16s and 203 /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 5342 4191 76 ERX-CERNET-BKB China Education and Rese 7545 4019 407 388 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2797 11125 745 KIXS-AS-KR Korea Telecom, KR 9829 2752 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2318 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2209 1435 138 VNPT-AS-VN VNPT Corp, VN 4755 2101 423 223 TATACOMM-AS TATA Communications formerl 7552 1652 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1611 361 143 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3820 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3443 1341 86 SHAW - Shaw Communications Inc., CA 18566 2177 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2015 2186 425 CHARTER-NET-HKY-NC - Charter Communicat 209 1846 5066 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1822 3859 574 AMAZON-02 - Amazon.com, Inc., US 30036 1814 327 292 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1696 854 231 ITCDELTA - Earthlink, Inc., US 701 1562 10559 631 UUNET - MCI Communications Services, In 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2942 968 2127 AKAMAI-ASN1, US 8551 2560 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2050 332 423 TELLCOM-AS, TR 9121 1939 1691 17 TTNET, TR 12479 1634 1048 59 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 12389 1523 1422 641 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1068 544 15 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 10620 3542 543 210 Telmex Colombia S.A., CO 8151 2650 3401 578 Uninet S.A. de C.V., MX 11830 2087 369 57 Instituto Costarricense de Electricidad 6503 1556 437 53 Axtel, S.A.B. de C.V., MX 7303 1555 1015 244 Telecom Argentina S.A., AR 6147 1235 377 27 Telefonica del Peru S.A.A., PE 3816 1024 501 93 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 956 2293 195 CLARO S.A., BR 11172 917 126 83 Alestra, S. de R.L. de C.V., MX 18881 897 1052 23 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 1243 398 51 LINKdotNET-AS, EG 37611 742 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 650 1375 26 ETISALAT-MISR, EG 24835 501 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 406 320 75 ORANGE-, TN 15399 356 35 7 WANANCHI-, KE 8452 313 1730 17 TE-AS TE-AS, EG 2018 303 327 74 TENET-1, ZA 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 5342 4191 76 ERX-CERNET-BKB China Education and Rese 7545 4019 407 388 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3820 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3542 543 210 Telmex Colombia S.A., CO 6327 3443 1341 86 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2942 968 2127 AKAMAI-ASN1, US 4766 2797 11125 745 KIXS-AS-KR Korea Telecom, KR 9829 2752 1498 549 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 22773 3820 3663 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 4019 3631 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3443 3357 SHAW - Shaw Communications Inc., CA 10620 3542 3332 Telmex Colombia S.A., CO 17974 2967 2894 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2560 2520 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2318 2286 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2752 2203 BSNL-NIB National Internet Backbone, IN 8151 2650 2072 Uninet S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65532 PRIVATE 14.192.19.0/24 132717 NDCTPL-IN NxtGen Datacenter & 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 4294901876 PRIVATE 59.101.19.0/24 2764 AAPT AAPT Limited, AU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.131.64.0/24 7247 MOJO - Mojo Networks, US 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:105 /12:284 /13:553 /14:1049 /15:1849 /16:13464 /17:7631 /18:13418 /19:24677 /20:38620 /21:41455 /22:78255 /23:64997 /24:367611 /25:875 /26:622 /27:645 /28:36 /29:25 /30:18 /31:2 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3241 3443 SHAW - Shaw Communications Inc., CA 22773 2990 3820 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 18566 2070 2177 MEGAPATH5-US - MegaPath Corporation, US 8551 2025 2560 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1602 1814 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1481 3542 Telmex Colombia S.A., CO 11830 1477 2087 Instituto Costarricense de Electricidad y Telec 11492 1389 1548 CABLEONE - CABLE ONE, INC., US 6389 1372 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:818 4:18 5:2435 6:34 8:1049 12:1835 13:130 14:1723 15:28 16:2 17:159 18:90 20:61 23:2448 24:1910 25:2 27:2459 29:1 31:1913 32:84 33:18 35:21 36:388 37:2350 38:1344 39:65 40:101 41:3005 42:461 43:1951 44:72 45:2977 46:2813 47:156 49:1217 50:994 51:19 52:823 54:363 55:7 56:4 57:44 58:1551 59:1023 60:347 61:1958 62:1697 63:1918 64:4634 65:2214 66:4571 67:2283 68:1245 69:3372 70:1156 71:585 72:2202 74:2693 75:389 76:427 77:1515 78:1416 79:1952 80:1416 81:1386 82:1002 83:719 84:943 85:1788 86:458 87:1181 88:754 89:2127 90:165 91:6198 92:994 93:2373 94:2389 95:2661 96:639 97:350 98:1061 99:90 100:154 101:1224 103:15459 104:3007 105:189 106:546 107:1771 108:825 109:2900 110:1457 111:1731 112:1213 113:1246 114:1036 115:1723 116:1755 117:1723 118:2136 119:1658 120:1075 121:1105 122:2270 123:1821 124:1483 125:1843 128:800 129:645 130:435 131:1425 132:552 133:201 134:667 135:225 136:451 137:458 138:1919 139:504 140:399 141:600 142:776 143:887 144:804 145:183 146:1087 147:684 148:1492 149:585 150:709 151:981 152:697 153:298 154:853 155:748 156:637 157:654 158:471 159:1518 160:728 161:739 162:2513 163:537 164:927 165:1376 166:371 167:1230 168:2972 169:837 170:3427 171:328 172:1024 173:1989 174:806 175:743 176:1895 177:3944 178:2553 179:1148 180:2206 181:1884 182:2363 183:1007 184:870 185:10256 186:3244 187:2218 188:2616 189:1803 190:8342 191:1364 192:9527 193:5787 194:4679 195:3915 196:2083 197:1335 198:5509 199:5899 200:7547 201:4345 202:10347 203:9970 204:4491 205:2824 206:3036 207:3145 208:3954 209:3968 210:3948 211:2145 212:2865 213:2523 214:856 215:66 216:5885 217:2123 218:906 219:601 220:1703 221:931 222:742 223:1189 End of report From nickdwhite at gmail.com Fri Jul 21 03:55:31 2017 From: nickdwhite at gmail.com (Nick W) Date: Fri, 21 Jul 2017 03:55:31 -0000 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them all, sitting in my homelab for now. Multiple full tables, nothing fancy for firewall or QOS, but ran into issues with random ribd/bgpd crashes and kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would personally stay away from them until they are out of beta, and possibly even another 6-12 months after that. The current stable EdgeMax version (1.9.1.1) is relatively stable, but using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) - nothing too major, but can be annoying. Probably okay for what you described. Depending on how much throughput you need, an ERPro, or Mikrotik would probably be fine. If you need 10G, load up VyOS on some cheap servers with an Intel or Solarflare card... probably cheaper than a beta Infinity or Mikrotik. On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders wrote: > Dear NANOG, > > Some friends of mine are operating a nonprofit (on shoe string) and looking > to connect some CDN caches to an IX fabric. A BGP speaking device is needed > between the caches and the BGP peers connected to the fabric. The BGP > speaker is needed to present the peers on the IX with a unified view of the > assemblage of CDN nodes. > > I was wondering whether anyone was experience with the "EdgeRouter Infinity > XG" device, specifically in the role of a simple peering router for a > couple of tens of thousands of routes. (I'd point default to the left and > take just the on-net routes on the right to reduce the table size > requirement). > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > and exposes some telemetry via SNMP. > > Any note sharing would be appreciated! > > Kind regards, > > Job > From tstevens at cisco.com Wed Jul 26 03:31:54 2017 From: tstevens at cisco.com (Tim Stevenson) Date: Tue, 25 Jul 2017 20:31:54 -0700 Subject: Cisco Nexus 93180YC Switch Feedback In-Reply-To: References: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> Message-ID: <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> At 07:39 PM 7/25/2017 Tuesday, Bill Woodcock opined: > > On Jul 25, 2017, at 7:25 PM, James Braunegg > wrote: > > > > Dear Nanog > > > > Just wondering if anyone is using the Cisco > Nexus 93180YC with the LAN enterprise license > and has any honest feedback about this > platform, especially if you are using VXLAN > routing and eVPN, would love to hear from you. > > > > For those that don't know the Cisco Nexus > 93180YC is a 1RU switch with 48 x 25gbit ports > SFP+ ports (1G, 10G or 25G) + 6 x 100gbit QSFP uplink ports. (40G, 50G or 100G) > >We’ve started testing them, as well as the >92160YCX and C92300YC, for IXP use. Notably >only four of the six 100G ports on the 92160YCX >will run at 100G, leaving two at 40G. Actually, only two. tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed Ethernet1/49 Speed: 40000 Ethernet1/50 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/51 Speed: 40000 Ethernet1/52 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/53 Speed: 40000 Ethernet1/54 Speed: 40000 tstevens-92160yc-1# All 6 on 93180YC EX/FX are 100G capable. Tim >Anybody had any luck sourcing 2x25G NICs for Cisco UCS servers? > > -Bill > > > > > Tim Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 From me at krygerism.com Sun Jul 16 16:35:34 2017 From: me at krygerism.com (Michael Krygeris) Date: Sun, 16 Jul 2017 16:35:34 -0000 Subject: ISP billing - data collection, correlation, and billing In-Reply-To: References: <048d01d2fcd0$b64889d0$22d99d70$@gmail.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB236F85@RTC-EXCH01.RESERVE.LDS> Message-ID: On Sat, Jul 15, 2017 at 4:48 AM Lee Howard wrote: > > Depending on the capability of the exporter, you don't need to export full flow information. With Cisco's Flexible Netflow you can define the aggregation in the flow cache you are monitoring. You are not required to use a 7-tuple. An aggregation could be something basic like this: Source interface Destination interface Octets Packets This would give you SNMP equivalent for byte accounting on interfaces without requiring full flow accounting IF you're not forced to do sampling and IF you have flexible netflow. Another much more recent method around SNMP (sorry SNMP, I'm over you) is streaming telemetry, which is part of Netconf/YANG/OpenConfig. This is more of a push method for these yang data models(the relevent one here being snmp interfaces table). It already exists on some Juniper and Cisco platforms. Mike Krygeris > > On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory" > wrote: > > >On the HFC / CMTS side of things we have IPDR which I believe has some > >open source collectors out there. I'm not sure that IPDR is used much > >outside of the HFC world though. > > IPDR was my first thought as an alternative to SNMP. Is its accuracy > comparable? It’s been included into TR-069, so it’s theoretically > available to telcos, too. And usage-based billing is part of it’s purpose. > > > Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows, > not bits, and I don’t want to record flows. But I’d be interested in > hearing others’ experience. > > > Lee > > > > From jhellenthal at dataix.net Tue Jul 18 21:35:23 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Tue, 18 Jul 2017 21:35:23 -0000 Subject: Temperature monitoring In-Reply-To: References: <20170714123125.2ndya33t4y22q3vg@dan.olp.net> Message-ID: <89A2FB88-20BB-4CF0-8F5F-437E9A4E90D0@DataIX.net> Would be pretty great if mobile worked... 😎 -------------- next part -------------- -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Jul 18, 2017, at 15:39, Edwin Pers wrote: +1 for the serverscheck.com gear. Been running it as a humidity monitor in the plant for a year or so now and it's been rock solid. If you're the kind of shop that requires calibration for that sort of equipment they'll handle that as well. Great company to work with. Pair it with Cacti + thold plugin or whatever other snmp monitoring you like - or the base units can handle alerting on their own. FYI for those interested - the stated max length of connecting cable between the base station and the sensor units (30ft iirc) is way under what it'll do in the real world - I've got at least one sensor unit that's a good 500ft away from the base station and it's been working just fine Ed Pers -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Charlebois Sent: Sunday, July 16, 2017 10:02 PM To: NANOG Subject: Re: Temperature monitoring we use: https://serverscheck.com/sensors/ - simple setup, graph nicely in Cacti. I went with ServerCheck wired based units + external temp+humidity probe. The base unit displays the temperature which is a nice quick reference if you are in the room. > On Fri, Jul 14, 2017 at 8:31 AM, Dan White wrote: > > We use Asentria. > >> On 07/13/17 22:33 -0400, Dovid Bender wrote: >> >> All, >> >> We had an issue with a DC where temps were elevated. The one bit of >> hardware that wasn't watched much was the one that sent out the >> initial alert. Looking for recommendations on hardware that I can >> mount/hang in each cabinet that is easy to set up and will alert us >> if temps go beyond a certain point. >> > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 (direct) main: (918)366-8000 > Fax 918.366.6610 email: dwhite at olp.net > http://www.btcbroadband.com > From ibagdona.nog at gmail.com Thu Jul 20 13:14:22 2017 From: ibagdona.nog at gmail.com (Ignas Bagdonas) Date: Thu, 20 Jul 2017 13:14:22 -0000 Subject: VXLAN for WAN Pseudowires? In-Reply-To: <20170720091219.GO15390@dilbert.slimey.org> References: <20170720091219.GO15390@dilbert.slimey.org> Message-ID: <33411825-4cf8-2546-6839-4d0ec1a34d99@gmail.com> Hi there, > However, > this would mean a shift from VPLS to VXLAN. On this particular sentence - it is incorrect to compare VPLS and VXLAN. One is a set of control plane mechanisms for discovery and tunnel setup and data plane encapsulations and multipoint reachability model, while the other is just a data plane encapsulation. VXLAN is equivalent to a (point to point) pseudowire used as a data plane component in VPLS. > 2) Traffic engineering - we don't have a lot of requirement for this, but do > have a small number of customers who buy A and B circuits, and require them > to be routed across different paths on our network. This is easy with MPLS > using explicit LSPs, but we've not yet worked out how to achieve the same > thing in VXLAN. VXLAN is a tunnel over a routed IP network. The path to reach the tunnel endpoint will define how VXLAN encapsulated payload is traversing over your network. If tunnel endpoint is reachable via explicitly routed LSP, the payload will follow that path. VXLAN by itself does nothing to influence the underlay path. > So, my question to the community is - have any of you used VXLAN as a wide-area > layer 2 transport technology? Yes, there are such deployments. The number of such deployments is increasing. > Any pros or cons? Gotchas? Scare stories? > Recommendations? Am I trying to shoot myself in the foot? VXLAN is a tunnelling mechanism. You seem to be looking for a end to end solution, for which VXLAN is a (rather small) component. You need to start from the requirements. What is the underlay technology being used? How much of traffic engineering functionality will be required, and how the particular underlay technology can implement it? What about ECMP support and requirements for its use - flow mapping to VXLAN tunnel is the same problem as flow mapping to any other tunnel in underlay ECMP environment. To build all of this is one thing, but to operate is quite the other - what about OAM requirements? VXLAN has no OAM support, and will not get one. If your operations systems rely on MPLS based OAM for service layer (eg, an MPLS based PW) - that will not be available. How the tunnels will be set up - is there a need to do discovery, or will all of it be orchestrated? Two main limiting factors in VXLAN applicability are lack of payload type indicator - the tunnel can carry only a single type of payload (ethernet in the canonic definition, no possibility to use single tunnel for multiple user payload types without additional encapsulation), and no ability to indicate that the payload is not a user payload but some other special type like OAM (pseudowire control word would be an example of such indicator). This leaves VXLAN as a solution of limited applicability for anything else than original intended one - ethernet tunnel over IP underlay. For other uses VXLAN is of limited applicability, there may be (and in fact are) vendor specific extensions but there is no point in talking about interoperability then. This problem space is well understood and there are successors to VXLAN - Geneve is getting into good shape (there are vendor specific early implementations but it is too early to talk about interoperability at this time), plus different vendors have their own tunnel encapsulation mechanisms (VXLAN-GPE being a more visible one, however it is not going to be standardized soon). The other interesting part to solve is the control plane. BGP based one will likely be the most practical option here. Combined with ability to tunnel multiple payload types this gives you a single control plane for L3VPN and point to point and multipoint L2VPN built on the same underlay with the single tunnelling mechanism. Your operations team will thank you violently for doing this. Ignas From wilson.chu at zoom.us Tue Jul 25 22:44:28 2017 From: wilson.chu at zoom.us (Wilson Chu) Date: Tue, 25 Jul 2017 15:44:28 -0700 Subject: Leaked routes earlier Message-ID: For about two minutes from Tue Jul 25 21:09:42 2017 GMT to 21:11:30 2017, routes to AWS were routed to stream-internet.net and got blackholed. for example, route to 50.18.x.x at the time: 5. sd-cr01-te3-4.161.nyc.stream 0.0% 3 350.9 249.9 173.9 350.9 91.2 6. anc-cr03-xe-5-0-1.149.ff.str 33.3% 3 174.7 195.8 174.7 216.8 29.8 7. radio-cr01-ae4.135.hel.strea 33.3% 3 213.4 213.6 213.4 213.7 0.2 8. mmon-cr01-be3.78.spb.stream- 66.7% 3 204.6 204.6 204.6 204.6 0.0 9. a433-cr01-be1.78.msk.stream- 33.3% 3 214.4 212.9 211.5 214.4 2.1 10. m9-cr05-ae9.77.msk.stream-in 66.7% 3 213.6 213.6 213.6 213.6 0.0 11. m9-cr03-ae1.199.msk.stream-i 33.3% 3 197.5 206.4 197.5 215.3 12.6 12. s-bb3-link.telia.net 66.7% 3 206.8 206.8 206.8 206.8 0.0 13. kbn-bb3-link.telia.net 66.7% 3 214.9 214.9 214.9 214.9 0.0 14. 54.240.242.130 66.7% 3 614.2 614.2 614.2 614.2 0.0 15. 54.240.242.147 66.7% 3 204.4 204.4 204.4 204.4 0.0 16. m9-cr05-ae3.77.msk.stream-in 66.7% 3 262.0 262.0 262.0 262.0 0.0 17. 54.240.242.132 66.7% 3 606.2 606.2 606.2 606.2 0.0 18. 54.240.242.147 33.3% 3 205.5 203.6 201.6 205.5 2.7 19. 205.251.229.158 66.7% 3 200.8 200.8 200.8 200.8 0.0 20. ??? 100.0 3 0.0 0.0 0.0 0.0 0.0 21. ??? 100.0 2 0.0 0.0 0.0 0.0 0.0 22. ??? 100.0 2 0.0 0.0 0.0 0.0 0.0 23. ??? 100.0 2 0.0 0.0 0.0 0.0 0.0 Anyone saw the same issue? Thanks, --Wilson From wilson.chu at zoom.us Wed Jul 26 20:57:20 2017 From: wilson.chu at zoom.us (Wilson Chu) Date: Wed, 26 Jul 2017 13:57:20 -0700 Subject: Leaked routes earlier In-Reply-To: References: Message-ID: It was AS12389 who leaked for few minutes. >From my view, AS7922, 16059, 4134, 6805, 13649, 29562, 31334, 9116 were all affected. For example 50.18.174.0/18 from AWS AS16509, right before: [image: Inline image 1] Duration: [image: Inline image 2] After: [image: Inline image 3] --Wilson On Tue, Jul 25, 2017 at 3:44 PM, Wilson Chu wrote: > For about two minutes from Tue Jul 25 21:09:42 2017 GMT to 21:11:30 2017, > routes to AWS were routed to stream-internet.net and got blackholed. > > for example, route to 50.18.x.x at the time: > > > 5. sd-cr01-te3-4.161.nyc.stream 0.0% 3 350.9 249.9 173.9 350.9 > 91.2 > 6. anc-cr03-xe-5-0-1.149.ff.str 33.3% 3 174.7 195.8 174.7 216.8 > 29.8 > 7. radio-cr01-ae4.135.hel.strea 33.3% 3 213.4 213.6 213.4 213.7 > 0.2 > 8. mmon-cr01-be3.78.spb.stream- 66.7% 3 204.6 204.6 204.6 204.6 > 0.0 > 9. a433-cr01-be1.78.msk.stream- 33.3% 3 214.4 212.9 211.5 214.4 > 2.1 > 10. m9-cr05-ae9.77.msk.stream-in 66.7% 3 213.6 213.6 213.6 213.6 > 0.0 > 11. m9-cr03-ae1.199.msk.stream-i 33.3% 3 197.5 206.4 197.5 215.3 > 12.6 > 12. s-bb3-link.telia.net 66.7% 3 206.8 206.8 206.8 206.8 > 0.0 > 13. kbn-bb3-link.telia.net 66.7% 3 214.9 214.9 214.9 214.9 > 0.0 > 14. 54.240.242.130 66.7% 3 614.2 614.2 614.2 614.2 > 0.0 > 15. 54.240.242.147 66.7% 3 204.4 204.4 204.4 204.4 > 0.0 > 16. m9-cr05-ae3.77.msk.stream-in 66.7% 3 262.0 262.0 262.0 262.0 > 0.0 > 17. 54.240.242.132 66.7% 3 606.2 606.2 606.2 606.2 > 0.0 > 18. 54.240.242.147 33.3% 3 205.5 203.6 201.6 205.5 > 2.7 > 19. 205.251.229.158 66.7% 3 200.8 200.8 200.8 200.8 > 0.0 > 20. ??? 100.0 3 0.0 0.0 0.0 0.0 > 0.0 > 21. ??? 100.0 2 0.0 0.0 0.0 0.0 > 0.0 > 22. ??? 100.0 2 0.0 0.0 0.0 0.0 > 0.0 > 23. ??? 100.0 2 0.0 0.0 0.0 0.0 > 0.0 > > Anyone saw the same issue? > > Thanks, > > --Wilson > From chris at semihuman.com Mon Jul 31 16:31:47 2017 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 31 Jul 2017 09:31:47 -0700 Subject: Admiral Hosting in London In-Reply-To: References: <20170727195401.GI7311@manor.msen.com> Message-ID: <0B2D86A2-2DF4-45B7-ADEF-578B2745A300@semihuman.com> And I’d *love* to hear the story they come up with when you ask why they only want to rent space vs buy it… -C > On Jul 27, 2017, at 9:22 PM, Randy Bush wrote: > >> We were contacted by Admiral Hosting in London to rent some our >> unused IP space. > > anyone wanting to rent/lease space is 99% sure to be not nice folk. > if you get your space back, it will be radioactive with an amazingly > long half life. > > if you are willing to let go of the space, just tell them the price > for which you are willing to sell it. > > randy > From David.Hiers at cdk.com Thu Jul 20 14:01:20 2017 From: David.Hiers at cdk.com (Hiers, David) Date: Thu, 20 Jul 2017 14:01:20 -0000 Subject: US/Canada International border concerns for routing Message-ID: Hi, We're looking to extend some services into Canada. While our lawyers dig into it, I thought that I'd ask the hive mind about border restrictions. For traffic routing, is anyone constraining cross-border routing between Canada and the US? IOW, if you are routing from Toronto to Montreal, do you have to guarantee that the path cannot go through, say, Syracuse, New York? I'm asking network operators about packet routing; data storage is a very different matter, of course. Thanks, David ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. From jason at remotelylocated.com Fri Jul 21 04:42:01 2017 From: jason at remotelylocated.com (Jason Wilson) Date: Fri, 21 Jul 2017 04:42:01 -0000 Subject: Looking for a AT&T MIS engineer to help with a Circuit Message-ID: Message off list please Jason Wilson Remotely Located Providing High Speed Internet to out of the way places. 530-651-1736 530-748-9608 Cell www.remotelylocated.com From DSpencer at pvt.com Thu Jul 20 23:52:49 2017 From: DSpencer at pvt.com (Dan Spencer) Date: Thu, 20 Jul 2017 23:52:49 -0000 Subject: cable modem provisioning servers Message-ID: All, I am at a point where I need to update our servers that provision our customer cable modems. I would like to see what other options are out there that people like. If anyone in the community has any recommendations it would be appreciated. Thank you, Dan Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived. From bfawzi at noor.net Thu Jul 27 09:03:30 2017 From: bfawzi at noor.net (Bassem Fawzi) Date: Thu, 27 Jul 2017 09:03:30 -0000 Subject: Comparing Backbone providers from support POV In-Reply-To: <813307713.73178382.1501145672883.JavaMail.zimbra@noor.net> Message-ID: <131777996.73187322.1501146533310.JavaMail.zimbra@noor.net> Hello All, This is Bassem and this is my first participation in nanog. We are planning to get a new 10G circuit and we are comparing the IPT service of three backbone providers that met our technical and financial requirements, Now to take all aspects into consideration we need to compare them from the support point of view. The three providers are NTT,GTT and Telia so if any one have dealt with them before and can help us rate their support it would be Great. Many thanks. -- Best regards, Bassem Fawzy Network engineer – Core Team City Stars Capital 5 A4 Omar Ibn El Khattab St. Heliopolis, Cairo, Egypt Mobile GSM: +2 01006580139 Land Line: +2 02 16700 EXT:139 FAX: +2 02 37482816 Email: bfawzi at noor.net