Re: ARIN's RPKI Relying agreement
On 5 Dec 2014, at 18:00, Nick Hilliard n...@foobar.org wrote: On 05/12/2014 11:47, Randy Bush wrote: and the difference is? rpki might work at scale. ohhh noo! So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability. If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status Valid, would fall back to the state Unknown, as if they were never signed in the first place. The state would NOT be Invalid. What is the likelihood of Joe's Basement ISP being filtered by anyone because their BGP announcements are RPKI Unknown, as if they weren't participating in the opt-in system? It seems as if the argumentation is built around RIR messes up == ISPs go offline, but that isn't a realistic scenario IMO, because no operator in their right mind would drop prefixes with the state Unknown. You could only realistically do that if all 550,000 Announcements in the DFZ are covered by a ROA. Not soon, if ever. -Alex
Re: A case against vendor-locking optical modules
On (2014-11-17 19:11 +0100), Jérôme Nicolle wrote: What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Your points are valid, I actually prefer 3rd party, even if it's more expensive than 1st party, just to have simpler sparing reducing OPEX. On RFP all vendors consistently have replied that they won't forbid using 3rd party optics, and won't deny support contract because of them. They may add that if optic is suspected, we need to replace it to 1st party, before TAC continues to work on a case. 1st party does do more testing on the optics than what we typically do, so some obvious problems will be avoided by buying 1st party. But if you are somewhat careful at sourcing your 3rd party, you should be quite safe. I have two examples of major problems caused by 3rd party. a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed. b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage. If you source from bad broker, and you hit issue b), you're screwed, because the broker can't tell you which optic you have are impacted by this issue, because bad brokers don't keep tracks on where they source optics, what serial numbers they are, what parts are inside the optics etc. If you source from 1st party, and you hit issue b), 1st party will be able to tell exactly which serial number range is impacted. But this is also true if you use professional 3rd party. -- ++ytti
Re: ARIN's RPKI Relying agreement
On Dec 6, 2014, at 3:27 AM, Alex Band al...@ripe.net wrote: If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status Valid, would fall back to the state Unknown, as if they were never signed in the first place. The state would NOT be Invalid. Alex - Depends on the nature of the error... In cases of overclaiming, the current validation algorithm could result in Invalid. This could happen, for example, if major ISP were to initiate transfer of some number resources to their business unit in another region, and then fail locally to swing to certs with the reduced resource list in a timely manner... All of the remaining prefixes in the existing cert would be deemed invalid and that could easily result in some very significant disruption for those validating w/RPKI. (i.e. as noted in draft-ietf-sidr-rpki-validation-reconsidered-00) FYI, /John John Curran President and CEO ARIN
Re: vendor-locking optical modules (Question re: IBM G8124E)
Hello, Since we are on the topic of vendor locked optics. Does anyone know if the IBM G8124 TOR Switches have a hidden menu option to over-ride the vendor lock optics ? We are seeing something interesting... we have a couple of these in production networks, apparently one switch will accept only IBM Optics, while the other will accept any I am not able to find anything which can explain the different behavior on the two switches. If anyone can offer an insights that would be greatly appreciated. Many Thanks in advance. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Chuck Anderson c...@wpi.edu To: nanog@nanog.org Sent: Saturday, December 6, 2014 8:37:01 AM Subject: Re: A case against vendor-locking optical modules On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote: a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed. b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage. Who is Vendor2?
Re: 10Gb iPerf kit?
On 11/11/2014, at 1:35 PM, Randy Carpenter rcar...@network1.net wrote: I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html Or one of these ones for dual-10Gbit links (one for out of band management or internet?): http://www.sonnettech.com/product/twin10g.html I haven't tried one myself, but they're relatively cheap (for 10gig) so not that much outlay to grab one and try it (esp if you already have an Apple laptop you can test with). I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP. Pete smime.p7s Description: S/MIME cryptographic signature
