Re: Open Letter to D-Link about their NTP vandalism
Two concrete technical suggestions to mitigate the volunteered NTP server's usage issues at the DIX: (1) Have someone else anycast the DIX block, and NAT the incoming NTP requests to another NTP stratum-1 server (eg pool address(es)). Or a much better idea: (2) Renumber into a new /24, which is announced only at the DIX with no-export, so that only DIX members are able to reach the server - as was the intended usage of this NTP server in the first place. (The announcment can be made by anyone at the DIX, it is not strictly necessary that the NTP server be the announcer of the /24. And in fact, it need not be a /24, as the server should be the only occupant of the block - but it should not be covered by any globally visible aggregate, at least not one contiguous to the connectivity at the DIX.) As to the liability issue, it is easy enough to envision that someone, somewhere, is relying on time results from NTP for a life-or-death application, like a medical device, and is innocently an impacted third party in this. Sending bad NTP values could in theory be responsible for killing someone's scratch monkey... -- Brian Dickson Email: [EMAIL PROTECTED] http://www.chateau-briand.net Tel : +1 647 234 7282
Re: Cross-country shipping of large network/computer gear?
Various war-story authors wrote: > > My experience is a 40% damage rate when shipping Cisco 7507 > > and 7513 routers via FedEx Heavy. Here are some pictures from back > > when I was at AboveNet: http://www.seastrom.com/fedex/ > > > >You aren't alone: > >http://www.16paws.com/FedEx/ > > Although this is a small item, I believe it wins the contest for "Most thoroughly > damaged shipment". > http://colofinder.net/gallery/view_album.php?set_albumName=album18 While I sadly no longer have the image, sometimes words paint a more vivid picture... We had a 7505 which could have won, simultaneously, awards for: "Most Blantant Disregard For Shipment Contents" "Least Excusible or Fathomable Damage Mode" "Failure To Note Packing Material Damage - Outstand Achievement" "Shipper Rules Weaseling - Special Mention" "Vendor Sudden Observance Of Fine Print" "One *Tough* Box" We shipped the 7507 in its original packing material, including crimped straps, to a colo site. The site contact received it, signed for it, and discarded the packing material, all without noticing the damage. What damage, you ask? UPS had driven a forklift tine through its side. As in, straight in, through packing material, and *pierced* the chassis, right in the center of the side, ie into the card cage. Without the packing material, UPS wouldn't pay damages. Cisco wouldn't RMA the chassis. Not a pleasant situation at all. However, the router only had a couple of cards, which were installed (luckily) next to the power supplies, and at the opposite end from the gaping 3/4" x 2.5" hole. The site tech suggested seeing if it would boot. Sure enough, it did. And ran fine. And to the best of my knowledge, is still in service. It's a good thing the airflow wasn't too badly disrupted by the hole. It's the last time we used UPS... -- Brian Dickson Email: [EMAIL PROTECTED] http://www.cineclix.comTel : +1 604 688 2339
Re: Lazy Engineers and Viable Excuses
Joe wrote: >>Haesu wrote: >>You ARE correct. If everyone employs IRR and put explicit filters everywhere, >>it'd be the perfect world.. > >... if everybody used the IRR to build explicit filters everywhere, if everybody kept >their objects in the IRR up-to-date, and if there was some appropriate authorisation >scheme in place to allow you to trust the data in the IRR implicitly, it'd be a >perfect world. There is this widely percieved notion that the IRR is a single, unadministered database. This is incorrect. The "Source:" field tells the whole story - there are multiple databases, with varying degrees of trust-worthiness, varying content, and varying uses. > >The IRR is currently a reasonable tool to use to avoid listening to routes which are >advertised by mistake from peers who populate the IRR accurately. It's not a >reasonable tool for avoiding maliciously bogus routes, since sticking maliciously >bogus information in the IRR is trivial. The IRR is the correct tool; what is missing is a little application of the available capabilities of the tool. Here's an example: You have a lot of address space to manage. Some BGP customers, some not. Some worthy of trust, some not. So, you operate your *own* routing registry, and tell the world about it. But, you, and only you, have update access. You mirror the routing registries of only the customers you trust. Your peers operate likewise. Your filter-building accesses the rr's of your peers, either directly, or via a reasonably well-located and well-trusted mirror. Or better yet, you mirror (possibly privately) them, yourself. Any problems with the content of any RR, you know who to contact (and blame). You also now have a mechanism to persuade your peers with, which is the peering agreement you both signed. Update it to include this, if you need to. No cruft, secure enough, no bogons, scalable. Technology that is already well understood, and for which tools have been built. Clear chain of trust, and straightforward means to sever problem servers. I don't see where (other than perhaps attitudes and erroneous assumptions) the problem is. And running a route-registry is *really* no more difficult than querying one, in most cases less so. Certainly less effort than even a small name server serving authoritative data... -- Brian Dickson Email: [EMAIL PROTECTED] http://www.cineclix.comTel : +1 604 688 2339
