- Test - lists.nanog.org

AWS internal networking team contact?
by Robbie Trencheny 24 Aug '17

24 Aug '17

Hey all, We are seeing major packet loss and high latency at a Level3 node just before the hop into AWS us-west-2. We had a go live planned for today which has now been scrapped because T-Mobile customers (a significant chunk of our customer base) nationwide are unable to login to our app. AWS Support is dragging their feet waiting to hear back from their internal networking team and didn't even believe they peered with Level3 at us-west-2 and we just don't have the time. CEO is talking about pulling the plug entirely on us-west-2 if not all of AWS and re-deploying to us-east-X or GCP. If someone from AWS could reach out off list to help expedite my ticket and get in contact with Level3 to fix their Seattle nodes i'd really appreciate it. It's already 740 on the west coast and I don't think i'm going home anytime soon. :( For those interested, failing nodes i'm seeing are ae-1-51.ear2.Seattle1.Level3.net <http://ae-1-51.ear2.seattle1.level3.net/> and ae-2-52.ear2.Seattle1.Level3.net <http://ae-2-52.ear2.seattle1.level3.net/>. Confirmed that T-Mobile is routing through those nodes from both SF and NYC. Apple also rejected our app during review this morning because of network failures while on wifi which I have to assume are the same ones we've been seeing for the last 96 hours. Thanks

1 0

Frontier SoCal FIOS contact? - gateway proxy arp issue
by Paul B. Henson 24 Aug '17

24 Aug '17

So yesterday I started seeing some arp warnings in my server logs: Aug 23 16:09:29 lisa /bsd: arp info overwritten for 96.251.22.154 by f0:1c:2d:8d:0e:cf on em2 Aug 23 16:12:24 lisa /bsd: arp info overwritten for 96.251.22.154 by f0:1c:2d:8d:0e:cf on em2 Aug 23 16:21:28 lisa /bsd: arp info overwritten for 96.251.22.154 by 00:25:90:da:ea:f9 on em2 f0:1c:2d:8d:0e:cf is the MAC address of 96.251.22.1, L100.LSANCA-VFTTP-55.gni.frontiernet.net, my FIOS gateway. It seems that for some reason proxy arp has been enabled on the router providing my gateway, and it is arp'ing for my static IP addresses as shown below: 0c:c4:7a:b3:ca:54 - MAC of lisa.pbhware.com (96.251.22.156) 00:25:90:da:ea:f9 - MAC of bart.pbhware.com (96.251.22.154) f0:1c:2d:8d:0e:cf - MAC of L100.LSANCA-VFTTP-55.gni.frontiernet.net (96.251.22.1) On 96.251.22.156: $ ping 96.251.22.154 16:12:24.416146 0c:c4:7a:b3:ca:54 Broadcast arp 42: arp who-has bart.pbhware.com tell lisa.pbhware.com 16:12:24.416405 00:25:90:da:ea:f9 0c:c4:7a:b3:ca:54 arp 60: arp reply bart.pbhware.com is-at 00:25:90:da:ea:f9 16:12:24.419522 f0:1c:2d:8d:0e:cf 0c:c4:7a:b3:ca:54 arp 60: arp reply bart.pbhware.com is-at f0:1c:2d:8d:0e:cf Another example for an IP address (96.251.22.158/static-5.pbhware.com) not currently in use: $ ping 96.251.22.158 16:26:15.784494 0c:c4:7a:b3:ca:54 Broadcast arp 42: arp who-has static-5.pbhware.com tell lisa.pbhware.com 16:26:15.787624 f0:1c:2d:8d:0e:cf 0c:c4:7a:b3:ca:54 arp 60: arp reply static-5.pbhware.com is-at f0:1c:2d:8d:0e:cf 16:26:15.787677 0c:c4:7a:b3:ca:54 f0:1c:2d:8d:0e:cf ip 98: lisa.pbhware.com > static-5.pbhware.com: icmp: echo request The gateway starts arp'ing looking for the real owner of that IP so it can proxy the traffic: 16:28:07.074869 f0:1c:2d:8d:0e:cf Broadcast arp 60: arp who-has static-5.pbhware.com tell L100.LSANCA-VFTTP-55.gni.frontiernet.net When I googled it, I found a number of complaints about this dating back years regarding Verizon FIOS, where proxy arp deployments seemed to be a standard practice in some areas, but for the decade I have had business FIOS this has never happened before. So I contacted frontier technical support to ask about it; unfortunately, the interaction was less than successful :(. While the level 1 support person was very helpful and didn't take very long to convince to escalate the issue, the first level 2 support person didn't quite seem to understand the concept, as demonstrated by the following excerpts from the chat: "turning off the ARP is done from the device that is receiving the request" "that is something he would need to turn off on his router, because we do not support 3rd party equipment" "sorry but we cannot make the change that he is requesting, it needs to be done on his device" "I understand what you are saying but the ARP request needs to be turned off through his equipment it is what is allowing signal in, just like a Ping can be turned off in the router even if something else is requesting the OPING" Technically, that last comment is true - if my system did not make an arp request, the frontier router would indeed not respond with a proxy arp reply. Of course, my systems would have a really hard time talking to each other if they weren't running arp 8-/. The last thing he had to say was "its not, on a router if you turn off Ping requests it will not get pinged, same thing with ARP requests" and I decided to stop wasting my time on him. Sadly, the level 1 tech informed me that the level 2 tech was actually working with his lead while responding to my issue. As I mentioned, the level 1 tech was very helpful, he offered to try to reach a different level 2 tech. The second level 2 tech refused to have anything to do with me unless I hooked up the original actiontech router that came with the Fios service 10 years ago, so I wrote off the official tech-support channel for now. So, long story short, are there any fios employees hanging out here that could possibly get me in contact with someone who understands the concept of proxy arp and would be able to determine why it suddenly was enabled on the gateway for my service yesterday and hopefully get it turned back off? That would be much appreciated. In the worst case I suppose I can work around this mess with arp inspection on the switch or static arp entries on the servers s, but I'd rather avoid being kludgy. Thanks much.

1 0

Call for Participation -- ICANN DNSSEC Workshop at ICANN60 in Abu Dhabi, UAE
by Jacques Latour 23 Aug '17

23 Aug '17

Call for Participation -- ICANN DNSSEC Workshop at ICANN60 in Abu Dhabi, UAE The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN60 meeting held from 01 November 2017 in Abu Dhabi, UAE tentatively from 0900-1500 local time. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Policy Forum in Johannesburg, South Africa. The presentations and transcripts are available at: https://schedule.icann.org/event/B3zi/dnssec-workshop[schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__schedule.icann.org_eve…>. At ICANN60 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include: * Innovative uses of APIs to do something new and different using DNSSEC/DANE. * Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email. * DNSSEC automation and deployment using CDS, CDNSKey, and CSYNC. * DNSSEC signing solutions and innovation. * Tools for automating the generation of DNSSEC/DANE records. * Services for monitoring or managing DNSSEC signing or validation. * Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG. Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC activities in the Middle East Region For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Impact and Results of Root Key Rollover Following the Root Key Rollover, we would like to bring together a panel of people who can talk about the impacts to ISPs, equipment providers and end users, and also what was done to mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that may have been affected by distribution of new root keys. you have a specific concern about the Root Key Rollover we would like to hear from you. 3. Implementing next generation DNSSEC signing at Registries and DNS Operators Now that DNSSEC technology has matured many Registries and DNS Operators have upgraded their legacy DNSSEC signing services with innovative solutions. * Real world use cases of HSMs and key management. * Signing at the edge We would be interested in seeing presentations or demonstrations on those topics. 4. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around your local key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 5. DANE and DNSSEC application automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. 6. DNSSEC and DANE in the enterprise and in the enterprise tool set Enterprises and enterprise software can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises and enterprise software providers that have implemented DNSSEC on validation and/or signing processes and can address questions such as: * What enterprise software support or plan do you have to support DNSSEC? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to implement DNSSEC? * What enterprise tools and systems are available to assist enterprises in the deployment of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates? 7. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * Can you describe your experiences with negative Trust Anchors and operational realities? * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * Can you provide results and/or impacts of the impact of root key rollover? * What rollover technique do you use, i.e., RFC 5011 or other? In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-abudhabi(a)isoc.org<mailto:dnssec-abudhabi@isoc.org> by **08 September 2017** We hope that you can join us. Thank you, Julie Hedlund On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR

1 0

Urgent CISCO WebEX Tech Support Request
by Ilissa Miller 23 Aug '17

23 Aug '17

Hoping a Cisco WebEx Tech Support Expert can contact me offline ASAP on an urgent matter. Thank you. Before 10:45am ET today please. Thank you. -- *Ilissa Miller* CEO, *iMiller Public Relations* www.imillerpr.com email: ilissa(a)imillerpr.com

1 0

unsubscribe
by Steve Lerner 23 Aug '17

23 Aug '17

On Wed, Aug 23, 2017 at 8:00 AM, <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Creating a Circuit ID Format (Tassos Chatzithomaoglou) > 2. Re: Creating a Circuit ID Format (Jared Mauch) > 3. 2017 NANOG Elections General Information (Dave Temkin) > 4. Re: Creating a Circuit ID Format (Justin M. Streiner) > 5. Re: Creating a Circuit ID Format (Nick Hilliard) > 6. Spectrum web cache engineer (Andrew Kirch) > 7. RE: Creating a Circuit ID Format (Timothy Creswick) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Aug 2017 19:01:56 +0300 > From: Tassos Chatzithomaoglou <achatz(a)forthnet.gr> > To: NANOG <nanog(a)nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <6b76d308-1a55-af42-c7cd-195d77147a3b(a)forthnet.gr> > Content-Type: text/plain; charset=UTF-8 > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > Access node can be either a DSLAM, a switch, an OLT, etc. > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > -- > Tassos > > Colton Conor wrote on 21/8/17 23:26: > > We are building a new fiber network, and need help creating a circuit ID > > format to for new fiber circuits. Is there a guide or standard for fiber > > circuit formats? Does the circuit ID change when say a customer upgrades > > for 100Mbps to 1Gbps port? > > > > What do the larger carriers do? Any advice on creating a circuit ID > format > > for a brand new fiber network? > > > > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > > historically a telephone number for DSL circuits. The ILEC had a complex > > method for assigning circuit IDs. > > > > I am sure anything will work as long as you keep track of it, but any > > advice would be great! > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 22 Aug 2017 12:37:08 -0400 > From: Jared Mauch <jared(a)puck.nether.net> > To: Tassos Chatzithomaoglou <achatz(a)forthnet.gr> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <2AF810AB-E963-4CD4-867C-3D96B73A4C8C(a)puck.nether.net> > Content-Type: text/plain; charset=us-ascii > > > > On Aug 22, 2017, at 12:01 PM, Tassos Chatzithomaoglou < > achatz(a)forthnet.gr> wrote: > > > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > > Access node can be either a DSLAM, a switch, an OLT, etc. > > > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > > My favorite circuit-ids were those from MFS where it had the service type > (2 chars i think) + a pop-code + z pop-code + service count number. > > We could then tell what pop/facility everything was handed off at easily > enough. I think my house even got a MFS pop code at one time due to the T1 > which was there. > > - Jared > > ------------------------------ > > Message: 3 > Date: Tue, 22 Aug 2017 10:21:32 -0700 > From: Dave Temkin <dave(a)temk.in> > To: "North American Network Operators' Group" <nanog(a)nanog.org> > Subject: 2017 NANOG Elections General Information > Message-ID: > <CAFJiuFq5=iAiRBxjbaKmZDvG=04bgdbpnXM1H-7v=dP1vWNZEA@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hello NANOGers! > > We are once again approaching the annual NANOG election > <http://nanog.org/elections/2017/general> and appointment time. Board > candidate nominations open August 7th and the complete Election timeline > can be found here <http://nanog.org/elections/2017/general>. We encourage > those in the community who are not currently NANOG members to consider > becoming members of NANOG and to consider standing for a position in our > leadership. Through membership and voting, you will be an active > participant in directing all NANOG activities. > > Only NANOG members are eligible to nominate, be a candidate, vote, and > serve in the NANOG Board of Directors and Committees. Click here > <https://www.nanog.org/membership> to become a member today! **If you are > not a member and wish to vote in this election, your membership must be > received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** > > Why? > > NANOG is at its strongest and best when there is an engaged group of > members. If you care about NANOG and would like to take a turn at > volunteering your time, please consider becoming part of the team by taking > part in the nomination and election process. If you know someone else that > you believe would be interested in serving on the Board of Directors, > nominate them by completing the Online Process > <https://www.bigpulse.com/138028/signin> beginning August 7, 2017. Any > questions should be submitted to elections(a)nanog.org. > > As I spoke about during my opening at NANOG 70, diversity is key to the > viability of the NANOG community. Personally, it concerns me that our only > non-white, non-male elected member of the Board is leaving the board this > year, having served the maximum allowable number of terms. While everyone > is welcome, it is important that we represent our community well at all > levels and so if you or someone you know could help improve that > representation, please consider the nomination process. > > As NANOG continues to evolve, our Board of Directors and Committees will > continue to play an increasingly important role in our success. By joining > now, you can be an integral part of the process. > > For more information about the role of a Board of Director or any Committee > Member, or to find out more about what's involved in serving, please > consult the current NANOG Bylaws > <https://nanog.org/sites/default/files/sites/default/files/NANOG-Bylaws- > October2016.pdf> > or follow the links to the Board and Committee pages from the General 2017 > NANOG Elections Page <https://www.nanog.org/elections/2017/general>. > > > Best regards, > > Dave Temkin > On behalf of the NANOG Board of Directors > > > ------------------------------ > > Message: 4 > Date: Tue, 22 Aug 2017 16:50:40 -0400 (EDT) > From: "Justin M. Streiner" <streinerj(a)gmail.com> > To: James Bensley <jwbensley(a)gmail.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <Pine.LNX.4.64.1708221608470.25675(a)whammy.cluebyfour.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 22 Aug 2017, James Bensley wrote: > > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > > > For me, all the circuit ID should be is a record number/ID of a > > database entry and nothing more (or a search string). Some people like > > to have circuit IDs which include circuit types, or circuit speeds, or > > interface type, but as you asked, do you then change the circuit ID if > > the circuit speed changes, or the interface types changes, or the > > medium etc? > > Agreed. I designed something similar at a previous employer, and it just > used a date-coded ID with sequence number (ex: UOP 20170822.0001), and > then all of the cross-connect details were recorded in a place that was > better suited to capturing that sort of information. That would also > allow us to re-use fiber paths when we upgraded 1G links to 10G, etc. > > This also included IDs that could reference other circuit IDs - including > circuit IDs from other providers - so we could tie non-dark elements > together, such as waves through DWDM gear end up riding on separate dark > fiber paths on either side of the mux. > > The biggest obstacle was getting people to label fiber jumpers in the > field, but that obstacle went away as people get a better understanding of > it and having all of the cross-connects documented saved lots of time and > frustration when having to search through a large patch field at 3 AM... > > jms > > > ------------------------------ > > Message: 5 > Date: Tue, 22 Aug 2017 22:20:20 +0100 > From: Nick Hilliard <nick(a)foobar.org> > To: James Bensley <jwbensley(a)gmail.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <599CA014.5020704(a)foobar.org> > Content-Type: text/plain; charset=UTF-8 > > James Bensley wrote: > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > there are a lot of ways of handling this, which broadly speaking break > down into whether you want to encode data in your circuit ID or whether > you want it to act as nothing more than an index on a database table. > > Regardless of what way you go about things, there are some parallel > issues, including whether you want inline checksumming, whether you want > random value increases or +1 increases, and whether you want an > alphanumeric or strictly numeric ID. Alphanumeric can allow unique > prefixes or suffixes to help identify who owns a circuit ID or what type > it is, at the complexity of adding identifiers which can be > misinterpreted over the phone. > > There are differing opinions on whether other information such as > service type, node location, speed, etc should be encoded in the service > name. > > Things that most people generally agree on include: > > - carefully splitting out service types. E.g. a fibre cable to a > location is one ID; a wavelength on that service is another ID of > another type; an IP transit service on that wave is a third ID, etc. > > - don't reuse IDs, ever. There are plenty of numbers out there. > > - don't change from one ID mechanism to another, if possible. > > Otherwise, for every well-reasoned suggestion to use a specific format, > there are other well-reasoned arguments to do things in a different way. > Choose one and stick with it. > > Nick > > > ------------------------------ > > Message: 6 > Date: Tue, 22 Aug 2017 21:44:24 -0400 > From: Andrew Kirch <trelane(a)trelane.net> > To: NANOG list <nanog(a)nanog.org> > Subject: Spectrum web cache engineer > Message-ID: > <CALA5tJLpNQBpE0gJne6VrPy7FPLfQjm5GMYwSj9Zr+=ZgaEHzg@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Would a Spectrum engineer please contact me off list? It appears you're > caching an expired certificate for https://www.icei.org. > > The issue is tested/working everywhere else. > > Thanks! > > Andrew > > > ------------------------------ > > Message: 7 > Date: Wed, 23 Aug 2017 08:18:52 +0000 > From: Timothy Creswick <timothy(a)creswick.eu> > To: NANOG <nanog(a)nanog.org> > Subject: RE: Creating a Circuit ID Format > Message-ID: > <HE1PR05MB15644799780F432E10AC93ADAF850@HE1PR05MB1564. > eurprd05.prod.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > > Things that most people generally agree on include: > > > > - carefully splitting out service types. E.g. a fibre cable to a > > location is one ID; a wavelength on that service is another ID of > > another type; an IP transit service on that wave is a third ID, etc. > > Definitely. We have one digit in our circuit ID which denotes the type to > aid with quick identification. > > We also use a luhn-10 checksum digit at the end, which is optional on > re-entry. This is really helpful when getting references over the phone. > When written, it's with a hyphen so that it's clear that it's able to be > dropped. > > A few things we also decided on: > > - Circuit references are purely numerical (although we prefix them with > letters when written, those letters are not part of what makes the numbers > unique in our business). The main reason for this is that they can easily > be entered in a variety of *compact* barcode formats. Most label printers > support this, and it saves loads of time in the datacentre when you can > just scan the label on a circuit on a handheld PC. > > - Circuit references are always the same length. This way, if the checksum > digit is being dropped (e.g. because it's coming from a non-human source > like a barcode), we know that the checksum digit is missing. > > - The first digit is never a zero, to avoid silly mistakes if you're > sorting them in Excel etc. > > - The first four digits are a simple date code of YYMM that the ID was > generated. This is surprisingly handy when you're looking for a specific > circuit reference in a list, and it sort of helps to spread the dataset out > a bit. This is what ensures that it's a non-zero first digit for the next > 80 years or so. The date code isn't a *requirement* of our format, however. > Should we need more than 10,000 circuits per month, we'll just abandon the > date coding. > > For those interested, our system looks like this: > > VCI-150600019-7 > > Any non [0-9] characters (including symbols) can be omitted. > > VCI : denotes that this circuit identifier corresponds to our business > 1506 : date code > 0001 : sequence number, incremented per circuit, per month > 9 : circuit type > 7 : checksum (optional) > > T > > > End of NANOG Digest, Vol 115, Issue 21 > ************************************** > -- -Steve Lerner (m) 212-495-9212

1 0

Spectrum web cache engineer
by Andrew Kirch 23 Aug '17

23 Aug '17

Would a Spectrum engineer please contact me off list? It appears you're caching an expired certificate for https://www.icei.org. The issue is tested/working everywhere else. Thanks! Andrew

1 0

2017 NANOG Elections General Information
by Dave Temkin 22 Aug '17

22 Aug '17

Hello NANOGers! We are once again approaching the annual NANOG election <http://nanog.org/elections/2017/general> and appointment time. Board candidate nominations open August 7th and the complete Election timeline can be found here <http://nanog.org/elections/2017/general>. We encourage those in the community who are not currently NANOG members to consider becoming members of NANOG and to consider standing for a position in our leadership. Through membership and voting, you will be an active participant in directing all NANOG activities. Only NANOG members are eligible to nominate, be a candidate, vote, and serve in the NANOG Board of Directors and Committees. Click here <https://www.nanog.org/membership> to become a member today! **If you are not a member and wish to vote in this election, your membership must be received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** Why? NANOG is at its strongest and best when there is an engaged group of members. If you care about NANOG and would like to take a turn at volunteering your time, please consider becoming part of the team by taking part in the nomination and election process. If you know someone else that you believe would be interested in serving on the Board of Directors, nominate them by completing the Online Process <https://www.bigpulse.com/138028/signin> beginning August 7, 2017. Any questions should be submitted to elections(a)nanog.org. As I spoke about during my opening at NANOG 70, diversity is key to the viability of the NANOG community. Personally, it concerns me that our only non-white, non-male elected member of the Board is leaving the board this year, having served the maximum allowable number of terms. While everyone is welcome, it is important that we represent our community well at all levels and so if you or someone you know could help improve that representation, please consider the nomination process. As NANOG continues to evolve, our Board of Directors and Committees will continue to play an increasingly important role in our success. By joining now, you can be an integral part of the process. For more information about the role of a Board of Director or any Committee Member, or to find out more about what's involved in serving, please consult the current NANOG Bylaws <https://nanog.org/sites/default/files/sites/default/files/NANOG-Bylaws-Octo…> or follow the links to the Board and Committee pages from the General 2017 NANOG Elections Page <https://www.nanog.org/elections/2017/general>. Best regards, Dave Temkin On behalf of the NANOG Board of Directors

1 0

Virtual or Remote Peering
by Rod Beck 22 Aug '17

22 Aug '17

How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com<http://www.unitedcablecompany.com> 85 Király utca, 1077 Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

7 8

Re: US/Canada International border concerns for routing
by Dave Cohen 22 Aug '17

22 Aug '17

It seems to me the original question was asking about it more from a legal perspective, in other words does Canadian traffic have to stay in Canada. IANAL (or a Canadian), but the answer is "mostly, no, especially as related to publicly routed traffic" as should be evidenced based on what's already been discussed here. In other words, there is restricted traffic but unless you're making a play for MAN/WAN type service on owned infrastructure, those requirements are unlikely to arise. To support the macro point, there is some big-boy level peering in Toronto but not really much else outside that, but there are plenty of routes that don't cross the border if you don't have to jump networks to your destination, for example going to an AWS on ramp in Canada using a native partner network, especially in the Toronto-Ottawa-Montreal. Dave Cohen craetdave(a)gmail.com > On Aug 8, 2017, at 8:41 PM, Bill Woodcock <woody(a)pch.net> wrote: > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman <clayton(a)MNSi.Net> wrote: >> =20 >> =20 >> =20 >> With the peering policies of the major Canadian ISPs, you're virtually = > guaranteed to hairpin through the US on most paths. >> =20 >> Robellus (Rogers, Bell & Telus) will peer with you at any of their = > major Canadian peering points, such as NYC, Chicago or LA. > > To be fair, Rogers does peer in Toronto. Along with New York, Chicago, = > Seattle, and Ashburn. > > -Bill > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=signature.asc > Content-Type: application/pgp-signature; > name=signature.asc > Content-Description: Message signed with OpenPGP > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > btKUtEvrcU28g15nOhLG > =MTUG > -----END PGP SIGNATURE----- > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- >

4 4

Cox in Omaha blackhole routing to Level 3
by david peahi 21 Aug '17

21 Aug '17

Can someone from Cox reply to me offline regarding a Cox routing issue in Omaha? Both ends of connection are on Cox network, but a traceroute shows packets being routed into Level 3 at 4.35.186.61 24 msec 24 msec 24 msec, and blackholed in Level 3 network. David Holmes

1 0