- Test - lists.nanog.org

NANOG 75 Call For Presentations Update
by BRAD RAYMO 16 Nov '18

16 Nov '18

NANOG Community, The NANOG Program Committee (PC would like to remind you that we are now accepting proposals for all sessions at NANOG 75 in San Francisco, California, February 18-20, 2019. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at http://www.cvent.com/d/1bqspy/6K. *Due to the holidays, we have extended the deadline for slides to be submitted to December 17th.* The NANOG PC seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 75 program. We welcome suggestions of speakers or topic ideas. Presentations may cover current technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 75 submissions can be entered on the NANOG Program Committee Tool (PC Tool) at: https://pc.nanog.org The primary speaker, moderator, or author should submit a presentation proposal and an abstract in the PC Tool. -- Select “Propose Talk” from the Talks menu -- Select NANOG 75 from the Meeting menu -- Select the appropriate *Session* the talk will be presented in = General Session (30-45 minutes) = Tutorial (90-120 minutes) = Track (90-120 minutes) Timeline for submission and proposal review: -- Submitter enters abstract (and draft slides if possible) in PC Tool prior to deadline for slide submission -- PC performs initial review and assigns a “shepherd” to help develop the submission - within 2 weeks -- Submitter develops draft slides of talk if not already submitted with initial proposal. Please submit initial draft slides early -- Panel and Track submissions should provide topic list and intended/confirmed participants in the abstract -- PC reviews slides and continues to work with Submitter as needed to develop topic -- Draft presentation slides should be submitted prior to published deadline for slides -- PC accepts or declines submission -- Agenda assembled and posted -- Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee, and a representative will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the PC Tool without delay! We look forward to reviewing your submission. Key Dates for NANOG 75: Oct. 29, 2018: CFP Opens & Agenda Outline Posted *Dec. 17, 2018: CFP Deadline: Presentation Slides Due* Jan. 14, 2019: CFP Topic List & NANOG Meeting Highlights Page Jan. 22, 2019: NANOG 75 Agenda Published Feb. 11, 2019: Speaker FINAL presentations to PC tool or speaker-support Feb. 17, 2019: Lightning Talk Submissions Open (Abstracts Only) Feb. 17, 2019: Onsite Registration Final slides MUST be submitted by Monday, February 11, 2018, and no changes will be accepted between that date and the conference. Materials received after that date will be updated on the web site after the completion of the conference. We look forward to seeing you in February in San Francisco! Sincerely, Brad Raymo NANOG PC

1 0

Community-driven FAQ for RPKI
by Alex Band 16 Nov '18

16 Nov '18

We put together a Frequently Asked Questions document for the Resource Public Key Infrastructure (RPKI). The aim is to provide a comprehensive overview of common questions that network operators and interested parties ask about the technology itself and the deployment of it, along with peer reviewed answers. To make this truly inclusive, it is available as an open source project on Github, allowing you to fork, do a pull request with an edit or addition, or open an issue in case you have suggestion. The original content was written by David Monosov, Melchior Aelmans, Job Snijders and myself, along with contributions from network operators around the world. The Github project is available here: https://github.com/NLnetLabs/rpki-faq The contents are automatically published on the NLnet Labs website: https://nlnetlabs.nl/projects/rpki/faq/ Many thanks to the NLNOG community for getting this off the ground. Cheers, Alex

1 0

Tata Scenic routing in LAX area?
by Marcus Josephson 15 Nov '18

15 Nov '18

Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms MPLS Label=344269 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms MPLS Label=609315 CoS=0 TTL=1 S=1 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms [cid:image002.jpg@01D47CE9.3122B790] Marcus Josephson IP Operations mjosephson(a)inap.com This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

9 10

Cisco IOS BGP Graceful-Restart Implementation query
by Florin Vlad Olariu 15 Nov '18

15 Nov '18

Hey there! In our environment we generally have ASR-1000X-2s everywhere peering via iBGP/eBGP. These routers have no redundant RPs, hence cannot keep forwarding traffic while the router reboots or crashes. As such, this is a clear example of a router that's only NSF-aware (or graceful-restart-aware) but not capable. The reason I enabled this is because, from RFC 4724: In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart Capability to its peer (as mentioned before *this is done by not including any <AFI, SAFI> in the advertised capability*). There are two reasons for doing this. The first is to indicate its intention of generating the End-of-RIB marker upon the completion of its initial routing updates, as doing this would be useful for routing convergence in general. The second is to indicate its support for a peer which wishes to perform a graceful restart. So what I would expect to see in the "show ip bgp neighbor <ip>" command, regarding Graceful Restart, would be something like the following: BGP neighbor is <IP>, remote AS <AS>, internal link [...] Neighbor capabilities: [...] Graceful Restart Capability: advertised and received Remote Restart timer is 120 seconds Address families advertised by peer: *none* Basically, GR is negotiated, but no address family is specified, effectively only using the EOR marker for routing convergence improvements. Instead, here's what the router specifies: BGP neighbor is <IP>, remote AS <AS>, internal link [...] Neighbor capabilities: [...] Graceful Restart Capability: advertised and received Remote Restart timer is 120 seconds Address families advertised by peer: *IPv4 Unicast (was not preserved, VPNv4 Unicast (was not preserved* My assumption is that the 'was not preserved' in the parentesis refers to the most recent restart of the neighbor, and it means that when the neighbor re-established the BGP connection, the GR Capability for IPv4 and VPNv4 AFIs did not set the "Forwarding bit" as specified by the GR-RFC: Once the session is re-established, if the "Forwarding State" bit for a specific address family is not set in the newly received Graceful Restart Capability, or if a specific address family is not included in the newly received Graceful Restart Capability, or if the Graceful Restart Capability is not received in the re-established session at all, then the Receiving Speaker MUST immediately remove all the stale routes from the peer that it is retaining for that address family. Clearly the Forwarding State bit is never going to be set by this type of router, due to hardware limitations. Here's my concern though: What happens when the router reboots, and the neighboring routers keep forwarding packets to this router because the GR-capabily did specify IPv4 and VPNv4 AFI/SAFI? This would clearly cause impact as traffic would be blackholed. I will try to simulate this and see how it behaves, I'll report back, but any info you have it would be greatly appreciated. -- Florin Vlad Olariu

1 0

Re: China ’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’ s BGP Hijacking
by Scott Weeks 14 Nov '18

14 Nov '18

--- alfie(a)fdx.services wrote: From: Alfie Pates <alfie(a)fdx.services> Never attribute to malice that which can be adequately explained by apathy. ------------------------------------------- Especially when they can do it without being seen as was discussed here years ago. I believe this was one of the discussions? https://www.nanog.org/meetings/nanog44/presentations/Tuesday/Kapela_steal_i… scott

1 0

Re: China ’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’ s BGP Hijacking
by Alfie Pates 14 Nov '18

14 Nov '18

Never attribute to malice that which can be adequately explained by apathy. ~A

1 0

verizon AS701 looking glass sever
by Roy Hockett 14 Nov '18

14 Nov '18

Does anyone have a bookmark for a looking glass server for Verizon/UUnet (AS701)? If someone from Verizon/UUnet noc can contact me offline, that would also be helpful.

2 1

Fitbit network contact
by Michael Crapse 13 Nov '18

13 Nov '18

Hoping to see if an network engineer from fitbit is on list. Our customers are having trouble logging into your app on our network. Perhaps an IP filtering/routing issue. Thanks

1 0

China ’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’ s BGP Hijacking
by Harley H 13 Nov '18

13 Nov '18

Curious to hear others' thoughts on this. https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca This paper presents the view that several BGP hijacks performed by China Telecom had malicious intent. The incidents are: * Canada to Korea - 2016 * US to Italy - Oct 2016 * Scandinavia to Japan - April-May 2017 * Italy to Thailand - April-July 2017 The authors claim this is enabled by China Telecom's presence in North America.

6 6

Oracle abuse contact
by David Shaw 13 Nov '18

13 Nov '18

Hi, I could really use some help reaching someone at Oracle for a spam problem coming from 129.145.16.122. I've sent countless emails to their abuse contact with no response, tried their tech support chat system and even calling several times without any reaction beyond confusion. It's been almost two weeks now, and while I don't like asking on NANOG, I'm out of options. Any pointers would be very welcomed. David

3 2