June 2017 - Test - lists.nanog.org

Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general
by Eric Dugas 22 Jun '17

22 Jun '17

Hello, We're planning to phase out some 10G link-aggregations in favor of 100G interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and Fiberstore CFPs. I've been told that CFPs (in general) weren't that reliable. They were kinda "replaced" almost a year and a half or so after its introduction by CFP2 and then by CFP4 and so on. Size and power consumption aside, are the MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of the 100GBase? Eric

2 1

Re: Long AS Path
by Jakob Heitz (jheitz) 22 Jun '17

22 Jun '17

23456 is AS_TRANS. Either your router does not support 4 byte AS or there is a bug at AS 12956 or AS 12956 is intentionally prepending 23456. Thanks, Jakob. > > Date: Tue, 20 Jun 2017 23:12:45 +0000 > From: James Braunegg <james.braunegg(a)micron21.com> > To: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Long AS Path > Message-ID: <e679487be750411a874b7376a7037aa9(a)EX-01.m21.local> > Content-Type: text/plain; charset="us-ascii" > > Dear All > > Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT > > Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (568) More than configured MAXAS-LIMIT > > Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers. > > Kindest Regards, > > James Braunegg > >

1 0

Re: PCIe adapters supporting long distance 10GB fiber?
by Jason Alderfer 21 Jun '17

21 Jun '17

On Tue, Jun 20, 2017 at 11:15 AM, Baldur Norddahl <baldur.norddahl(a)gmail.com > wrote: > The real question here is: will my NIC support other SFP+ modules than the > few options carried by the NIC vendor? Has anyone tried changing the vendor ID of an SFP+ with one of these? https://sfptotal.com/ I am highly intrigued and skeptical. Jason

1 0

Re: Vendors spamming NANOG attendees
by Anne P. Mitchell Esq. 21 Jun '17

21 Jun '17

> On 6/13/17 10:28 PM, Mel Beckman wrote: >> But as I said, harvesting emails is not illegal under can spam. But it is illegal under the laws of nearly every other technology-enabled developed country. And there are at least a few people on this list who are in those countries. And once GDPR goes into effect there will be even more available remedies. Anne* *Dictated due to broken wrist, please forgive top posting and any weird grammar or typos. Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop

1 0

Why the internal network delays, Gmail?
by Nate Metheny 21 Jun '17

21 Jun '17

Help (and hi)! I work in higher education and we've been experiencing problems with Google delaying or queuing email for delivery to our domain. Here's some truncated email headers: ** Example 1: X-Received: by 10.237.55.65 with SMTP id i59mr10986018qtb.62.1472137448952; Thu, 25 Aug 2016 08:04:08 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id u25so27419242qtb.1 for <@***>; Thu, 25 Aug 2016 12:05:46 -0700 (PDT) ** Example 2: X-Received: by 10.36.1.75 with SMTP id 72mr5275579itk.40.1472130531887; Thu, 25 Aug 2016 06:08:51 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id x131so289116132ite.0 for <@***>; Thu, 25 Aug 2016 11:50:42 -0700 (PDT) In both of these examples, these emails haven't even left Google's internal network yet; I'm getting blamed for these delays, however there is no delay in receiving these emails after they leave Google's network. Are other people having this same problem? I've tested delivery to my network from many outside sources and all SMTP requests go through without delay; this issue seems be exclusive to Google-hosted and Gmail accounts and domains. -- Nate <natemetheny(a)gmail.com>nate(a)dopedesign.com

14 21

Google Cloud and IX - Traffic behavior
by Alain Hebert 21 Jun '17

21 Jun '17

Hi, Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; PS: Wireshark capture show nothing abnormal; PS: Links aren't congested, and so on... Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access -- ----- Alain Hebert ahebert(a)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

4 7

Re: PCIe adapters supporting long distance 10GB fiber?
by Baldur Norddahl 21 Jun '17

21 Jun '17

But what foundation do you have for asserting that switch hardware is any different in this regard? I can say that we are using 80 km modules in various hardware without any issues. I admittedly do not use any high power modules in servers, but I will need better evidence than this to assume that it would not work just fine. Den 20. jun. 2017 22.24 skrev "Denys Fedoryshchenko" <denys(a)visp.net.lb>: On 2017-06-20 22:07, Baldur Norddahl wrote: > I would expect anything mounted in a computer to have all the power you > could want. It is not like the ATX power supply cares about an extra watt > or two. > > As I understand the issue it is more about cooling than power and is > primarly a concern in high density switches were you could have 48 or more > to power and cool. > SFP needs 3.3V, it might be supplied from regulator on the card or directly PCI-Express, can't be absolutely sure, in reference design it is just 3.3V_NIA and then filter, also reference design SFP power circuit define max 750mA/3.3V max to SFP, thats only 2.475W. FTLX1471D3BCV (10km SM) - up to 285mA FTLX1671D3BCL (40km SM) - up to 400mA, and thumb rule in electronics it is better to not exceed 50% of max specs of designed max current, as for many parts it is stated for 25C & etc operating conditions. I expect it might work, but noone knows how long, and how reliable, if it is not cooled very well. And 82599 sensitive to cooling(it is very old card after all), as soon as it is not enough, it starts to glitch. > > Den 20. jun. 2017 18.09 skrev "Denys Fedoryshchenko" <denys(a)visp.net.lb>: > > I guess it depends on NIC, there is many spinoffs of Intel X520 with much >> weaker power supply circuitry. >> It might work with good NIC, but you can't rely on it on long term, IMHO. >> Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The typical >> power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W >> specified for the Power Level II transceivers" >> If we talk about 80km, Pdiss is 1.8W. >> While 10GBASE-LR is <1W >> >> On 2017-06-20 16:30, Max Tulyev wrote: >> >> We use Intel NICs with SFP+ holes. It works good with long and short >>> range SFP+ modules, including CWDM/DWDM. >>> >>> On 15.06.17 12:10, chiel wrote: >>> >>> Hello, >>>> >>>> We are deploying more and more server based routers (based on BSD). We >>>> have now come to the point where we need to have 10GB uplinks one these >>>> devices and I prefer to plug in a long range 10GB fiber straight into >>>> the server without it going first into a router/switch from vendor x. It >>>> seems to me that all the 10GB PCIe cards only support either copper >>>> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very >>>> few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I >>>> can't seem to find any. >>>> >>>> Chiel >>>> >>>> >>>>

3 2

Re: Vendors spamming NANOG attendees
by Scott Weeks 20 Jun '17

20 Jun '17

--- nanog(a)nanog.org wrote: From: i mawsog via NANOG <nanog(a)nanog.org> :: Agree, this thread has generated more "spam" or noise :: for all of us collectively. It's not spam. Look up the definition of spam. Also, just block the thread in your email client. :: Some amount of relevant "spam" has to be tolerated for :: vendor to continue supporting NANOG. No, that is absolutely wrong! :: Also relevant "spam" or sales call is a good way to find :: out about new technologies , that one may not have heard :: about otherwise. No, wrong again. One of the most attractive things about NANOG is learning these things from **peers**, not spam. :: Another tip, just ignore, the "spammer" will go away :: eventually. If they're not named-n-shamed they will continue. I have had quite a few go after me aggressively to sell me something after a NANOG post. They didn't stop until I named-n-shamed them. Their supervisors wrote me, personally apologized and, due to that, I put their companies back on my list of companies to do business with. I write this not just to you, but as an explanation to other new folks why the old schoolers name-n-shame. scott

1 0

Re: Vendors spamming NANOG attendees
by tim＠pelican.org 20 Jun '17

20 Jun '17

On Tuesday, 20 June, 2017 14:26, "Rod Beck" <rod.beck(a)unitedcablecompany.com> said: > And how do you tell if an address was scraped or not? There are databases and > zillions of other ways of gaining addresses. > > > I doubt you can distinguish the source with any real reliability. Depending on whether you're registered with personal or corporate email, and how much control you have over the platform in question, you can distinguish the source with fairly high reliability. Just generate a new 'bob+nanog70(a)bobsdomain.org' style address for every event you register for, every website that requires a contact address, every mailing list, ... If you're concerned that people will twig, and use the naked 'bob@' address, you could work with multiple names including a hash that look like internal nonsense, e.g. 'bob34adf@', or block the un-plussed 'bob@' entirely and use e.g. 'robert@' for people you trust to have your real, non-circumstance-specific email address. I know people who do this, it really depends how much you care about being able to trace and block people who are either scraping or re-selling your details. Regards, Tim.

4 4

Vendors spamming NANOG attendees
by Rodney Joffe 20 Jun '17

20 Jun '17

It seems that more than just a few of us were spammed by Glenn Stern (gstern(a)calient.net) an employee of Calient following NANOG 70. The spammer had the balls to say, in his email: > > We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter(a)calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! Rodney

38 67