- NLNOG - NLNOG

Call for presentations RIPE 74
by Benno Overeinder 24 Jan '17

24 Jan '17

Dear colleagues, Please find the CFP for RIPE 74 below or at https://ripe74.ripe.net/submit-topic/cfp/. The deadline for submissions is *12 March 2017*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/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 74 will take place from 8-12 May 2017 in Budapest, Hungary. 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 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 12 March 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) 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://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) 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. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. 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/

1 0

Nog 2 weken! (en 1 dag)
by Nathalie Trenaman 05 Jan '17

05 Jan '17

Beste NLNOGers, Allereerst de beste wensen allemaal. Zoals Job in November al aankondigde, is er ook dit jaar weer een traditionele en altijd gezellige NLNOG Nieuwjaarsborrel. We hebben al 99 (!) aanmeldingen! Word jij de 100e borrelaar? Nog even: Details: -------- Tijd: vanaf 19:00 Datum: 20 januari 2017 Plaats: Stairway to Heaven, Mariaplaats 11/12 in Utrecht (vlakbij Utrecht CS) http://www.stairway.nl/ <http://www.stairway.nl/> De nieuwjaarsborrel word dit jaar mede mogelijk gemaakt door PowerDNS, NTT Communications, Cybersprint en SIDN. Aanmelden: ---------- Hoe meer zielen, hoe meer vreugd, dus neem ook eens een collega mee die nog nooit van NLNOG heeft gehoord ;-) Vergeet je niet even aan te melden: http://nlnog.com/nieuwjaarsborrel2017/ <http://nlnog.com/nieuwjaarsborrel2017/> Tot de 20e! Job, Niels, Sander, Thomas en Nathalie

1 0

FW: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)
by Job Snijders 05 Dec '16

05 Dec '16

Alloah, TL;DR: Cisco Nexus 92160 switches kunnen packets met bepaalde specifieke payloads niet forwarden. Er komt geen software fix, de ASIC is niet goed gedesigned. Stel je hebt twee routers aan elkaar geknoopt via een VLAN over zo'n Nexus 9000 switch, en je doet VPLS tussen deze routers, dan kan het zijn dat packets waarbij de payload een ethernet frame binnen die VPLS instance is, waarbij het destination MAC begint met een 4 of een 6, gedropped worden. Als je precies weet wat voor payloads je stuurt over deze switches dan kun je er wel omheen werken (in een enterprise omgeving bijvoorbeeld), maar als je als service provider VLANs van A naar B verkoopt dan weet je natuurlijk niet wat de klant over het circuit gaat sturen, en dan kan dit flink bijten. Met vriendelijke groeten, Job ----- Forwarded message from Job Snijders <job(a)instituut.net> ----- Date: Fri, 2 Dec 2016 15:32:13 +0100 From: Job Snijders <job(a)instituut.net> To: nanog(a)nanog.org Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) Hi all, Ever since the IEEE started allocating OUIs (MAC address ranges) in a randomly distributed fashion rather then sequentially, the operator community has suffered enormously. Time after time issues pop up related to MAC addresses that start with a 4 or a 6. I believe IEEE changed their strategy to attempt to purposefully higher the chance of collisions with MAC squatters, to encourage people to register and pay the fee. The forwarded email at the bottom is yet another example of a widely deployed, but fundamentally broken ASIC. The switch can't forward VPLS frames which contain a payload where the inner packet is destined to a MAC starting with a 4 or a 6. This is with the switch operating in pure layer-2 mode, it doesn't know what MPLS or VPLS even are. The switch is dropping packets on the floor, based on their _payload_. Try selling such circuits to customers "discounted layer-2 service, some flows might not be forwarded". Had IEEE continued the sequential OUI allocations, it probably would've taken many years before we ever reached MACs starting with a 4 or a 6, but instead, in 2012 the first linecards started rolling out of factories with MACs burned in which start with a 4 or a 6, and this took some vendors by surpise. There have been quite some issues, both in hardware and software: Brocade produced a 24x10GE linecard to the market in 2013/2014, with limited FIB scale, meant for a BGP-free MPLS core, but the card can't keep flows together on LACP bundles if the inner packets in a pseudowire were destined for a 4 or 6 MAC. The result: out of order delivery, hurting performance. Cisco ASR 9k's had a bug where if a payload started with a 6, it assumed it would be an IPv6 packet, compare the calculated packet-length with the packet-length in the packet and obviously fail because an ethernet packet is not an IPv6 packet. The result: packets dropped on the floor. (Fixed in 4.3(0.32)I) The Nexus 9000 issue described at the top of this mail. Brocade IronWare had an issue related to packet reordering for flows inside pseudowires, fixed in 2013/2014. There are probably many more examples out there in the wild, slowly driving operators insane. At this moment, some issues related to MACs starting with a 4 or a 6 can be mitigated if you enable Pseudowire Control-Word (RFC 4385) _AND_ Flow-Aware Transport (RFC 6391). You need both to mitigate certain issues in multi-vendor networks (for instance if you have Cisco edge + Juniper core). But what to do when the ASIC won't forward the payload? As ISP you often don't control the payload. Unfortunatly, I don't think we've seen the end of this. The linecards bought in 2012 will trickle down to the grey/second-hand market about now, often without accompanying support contracts. In a world with increased complexity in our interconnectedness, and lack of visibility into the underlaying infrastructure (think remote peering, cloud connectivity, resellers reselling layer-2) it will hurt when some flows inexplicably fail to arrive. Dear IEEE, please pause assigning MAC addresses that start with a 4 or a 6 for the next 6 years. Or at least, next time you change the policy, consult the operational community. This 4/6 MAC issue was well documented in BCP128 back in 2007. The control-word drafts mentioned that there would be dragons related to 4 and 6 back in 2004. Dear Vendors, take this issue more serious. Realise that for operators these issues are _extremely_ hard to debug, this is an expensive time sink. Some of these issues are only visible under very specific, rare circumstances, much like chasing phantoms. So take every vague report of "mysterious" packetloss, or packet reordering at face value and immediately dispatch smart people to delve into whether your software or hardware makes wrong assumptions based on encountering a 4 or a 6 somewhere in the frame. And you, my fellow operators, please continue to publicly document these issues and possible workarounds. Kind regards, Job resources: c-nsp thread "Wierd MPLS/VPLS issue": https://puck.nether.net/pipermail/cisco-nsp/2016-December/thread.html https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.S… BCP128: https://tools.ietf.org/html/bcp128 ----- Forwarded message from Simon Lockhart <simon(a)slimey.org> ----- Date: Fri, 2 Dec 2016 11:44:21 +0000 From: Simon Lockhart <simon(a)slimey.org> To: cisco-nsp(a)puck.nether.net Subject: Re: [c-nsp] Wierd MPLS/VPLS issue On Wed Nov 23, 2016 at 12:01:20PM +0000, Simon Lockhart wrote: > On Fri Nov 04, 2016 at 03:40:05PM +0000, Simon Lockhart wrote: > > To me, everything *looks* right, it's just that some VPLS traffic traversing > > the new link gets lost. > > For those who are interested... > > Well, I finally got to the bottom of this, and have pushed it to Cisco TAC > for a fix... Cisco TAC finally accepted the issue. Bug CSCvc33783 has been logged. Nexus BU has investigated. Response is... "[...] unfortunately this is an ASIC limitation on the Nexus 9000 switches and is therefore not fixable." If you want a Layer 2 switch that will forward all valid Ethernet frames, I'd suggest avoiding the Nexus 9000 range... Simon _______________________________________________ cisco-nsp mailing list cisco-nsp(a)puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ----- End forwarded message ----- ----- End forwarded message -----

3 2

FW: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)
by Job Snijders 02 Dec '16

02 Dec '16

Hoera, het bleek toch geen ASIC probleem te zijn, initiele diagnose was verkeerd. Dat scheelt toch maar weer :-) ----- Forwarded message from "Sukumar Subburayan (sukumars)" <sukumars(a)cisco.com> ----- Date: Fri, 2 Dec 2016 21:23:24 +0000 From: "Sukumar Subburayan (sukumars)" <sukumars(a)cisco.com> To: Job Snijders <job(a)instituut.net>, Leo Bicknell <bicknell(a)ufp.org>, Nick Hilliard <nick(a)foobar.org>, "nanog(a)nanog.org" <nanog(a)nanog.org> Subject: Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) All, I just want to come back on behalf of Cisco on this. We just investigated this issue and the issue is not an ASIC bug, but a flag set wrong by SW. We will reach out to the original customer through TAC who posted this in NSP to resolve this issue. sukumar

1 0

NLNOG New Years Drink 2017
by Job Snijders 21 Nov '16

21 Nov '16

Ohai NLNOG community! [ English TL;DR: Friday January 20th, 2017 we'll congregate in Utrecht to celebrate the new year! Please register at the below URL. ] Het is weer bijna zover! De immer legendarische NLNOG Nieuwjaarsborrel komt eraan. Een prima traditie om met vrienden en collega's het nieuwe jaar in te luiden met een biertje en een bittergarnituur. Details: -------- Tijd: vanaf 19:00 Datum: 20 januari 2017 Plaats: Stairway to Heaven, Mariaplaats 11/12 in Utrecht (vlakbij Utrecht CS) http://www.stairway.nl/ De nieuwjaarsborrel word dit jaar mede mogelijk gemaakt door PowerDNS en NTT Communications! Aanmelden: ---------- Hoe meer zielen, hoe meer vreugd, dus neem ook eens een collega mee die nog nooit van NLNOG heeft gehoord ;-) Vergeet je niet even aan te melden: http://nlnog.com/nieuwjaarsborrel2017/ Alvast hele fijne dagen en we hopen jullie allemaal te zien op 20 januari. Namens het bestuur, Job

1 0

PeeringDB Product Committee Charter Survey / NLNOG
by Arnold Nipper 18 Oct '16

18 Oct '16

Hello PeeringDB users / Hi NLNOGers, the PeeringDB Product Committee (PC, [0]) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. We're looking for feedback and input from the community on our charter proposal. Please take this short survey [1]. Your input and comments are appreciated! [0] http://docs.peeringdb.com/gov/ [1] https://www.surveymonkey.com/r/JN36DT2 Groeten, Arnold -- Arnold Nipper email: arnold(a)nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9

2 2

[job@ntt.net: [routing-wg] Large BGP Communities beacon in the wild]
by Job Snijders 11 Oct '16

11 Oct '16

FYI ----- Forwarded message from Job Snijders <job(a)ntt.net> ----- Date: Tue, 11 Oct 2016 17:01:56 +0200 From: Job Snijders <job(a)ntt.net> To: nanog(a)nanog.org, routing-wg(a)ripe.net, Jared Mauch <jmauch(a)us.ntt.net> Subject: [routing-wg] Large BGP Communities beacon in the wild Dear all, Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80. Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced. IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group. The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/ Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$ Both these prefixes have a Large BGP Community attached: 2001:67c:208c::/48 192.147.168.0/24 Large BGP Community - 15562:1:1 The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute. IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48 In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG. Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route: IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes. IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0 IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A note about router Configurations: Ensure you are not fitlering the path attributes, eg: JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30 XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! ! Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562. Kind regards, Job ----- End forwarded message -----

1 0

Wat voor weekdag voor de NLNOG-dag 2017 ?
by Job Snijders 28 Sep '16

28 Sep '16

Hi NLNOGers, We hebben jullie feedback nodig voor de NLNOG-dag 2017! Hier een héééééle korte survey om uit te vogelen of de volgende NLNOG dag op een dinsdag of op een vrijdag zal plaats vinden: https://nl.surveymonkey.com/r/JWGKFMX Groeten, Job

1 0

Fwd: New Content on RIPE Labs
by Job Snijders 23 Sep '16

23 Sep '16

Vrijmibo leesvoer! :-) Job ---------- Forwarded message ---------- From: *MENOG Secertariat* <menog(a)ripe.net> Date: Friday, 23 September 2016 Subject: [menog] New Content on RIPE Labs To: menog(a)menog.org Dear colleagues, Here are the links to some recent RIPE Labs articles 1. Philipp Richter, PhD student at the Technical University in Berlin, did some research about how "active" IPv4 addresses are on the Internet: https://labs.ripe.net/Members/philipp_richter/all-quiet-in-the-ipv4-internet 2. Uta Meier-Hahn, researcher at the Humboldt Institute for Internet and Society in Berlin, is looking at the interconnection market: https://labs.ripe.net/Members/uta_meier_hahn/what-do- network-operators-sell-to-each-other 3.Vesna Manojlovic, RIPE NCC, wrote down her impressions from NLNOG: https://labs.ripe.net/Members/becha/impressions-from-nlnog-day-2016 4. Annika Wickert, engineer at a gaming company used RIPE Atlas to measure game service connectivity: https://labs.ripe.net/Members/annika_wickert/using-ripe- atlas-to-monitor-game-service-connectivity 5. Jason Read, research analyst at Gartner, used RIPE Atlas to measure cloud connectivity: https://labs.ripe.net/Members/jason_read/using-ripe-atlas- to-measure-cloud-connectivity 6. Lia Hestina, RIPE NCC, participated in the Indonesian Network Operators meeting and wrote a nice report: https://labs.ripe.net/Members/lia_hestina/measuring-the- Internet-in-indonesia-one-probe-at-a-time Maybe you will be the next one to publish an article on RIPE labs. If interested please mail us and we can help you write it.

1 0

importance of fiber cleaning
by Job Snijders 21 Sep '16

21 Sep '16

----- Forwarded message from Mikael Abrahamsson <swmike(a)swm.pp.se> ----- Date: Wed, 21 Sep 2016 07:56:43 +0200 (CEST) From: Mikael Abrahamsson <swmike(a)swm.pp.se> To: nanog(a)nanog.org Subject: importance of fiber cleaning https://www.sunet.se/blogg/long-read-cleanliness-is-a-virtue/ This is an excellent article regarding fiber cleaning and its importance. Please do share with other people in our business. I'm sure lack of proper fiber cleaning causes a lot of unneccessary outages and operational problems worldwide, partly because people aren't aware of its importance. -- Mikael Abrahamsson email: swmike(a)swm.pp.se ----- End forwarded message -----

1 0