Re: Secure Tunneling. Only with more Control!!!
On Sat, Jul 13, 2013 at 8:36 AM, Nick Khamis sym...@gmail.com wrote: This just got very interesting. Given that we do not own any Microsoft products here, and still able to function like any other corporation, I am more interested in a solution that you have more control over secured connections. We currently are using OpenVPN and PKI, coupled with a company policy of key updates every 3 months this will only get incrementally more complex as the number of clients increase. Not to mention one only needs a 3 minutes Question: What other options do we have to maintain a secure connection between client and server that gives us more control over traditional OpenVPN+PKI. It would be nice to be able to deploy private keys automatically to the different clients however, seems like a disaster waiting to happen. I would really appreciate some of your takes on this matter, what types of technology, policies are being employed out there for secure connections. Your current solutions sounds entirely reasonable... except your clients still surf the web, don't they? That is the biggest attack vector: browser and other client program exploits are rampant on *all platforms*. Witness the multitudes of image library bugs on Linux, which basically have allowed remote execution via webpage with a crafted image since the early 1990s. Every browser and OS combo, yes even Firefox on Linux, gets popped in each year's P0wn2Own contest. If you can execute code on the client, you can usually find one of the hundreds of local privilege escalation bugs stil there. Then you can compromise any private keys and certs on it, as well as any user credentials stored or entered on the machine. This makes it easy to pivot into the core of the target's network without being noticed, and is in fact how many penetration tests and APT or watering hole hacks succeed. They attack clients and pivot into the target network. So the solution would be: don't let your clients ever touch anything outside your private walled garden. Which is exactly what high-security installations in the defense and government sectors do: they are air-gapped from the Internet. Tough to get a lot of work done that way, and function as a business. -- RPM
Re: PRISM: NSA/FBI Internet data mining project
On Jun 9, 2013, at 7:20 AM, R. Benjamin Kessler ben.kess...@zenetra.com wrote: I see that there is actually a beast that will do encryption of multiple 10G waves between Cisco ONS boxes - https://www.cisco.com/en/US/prod/collateral/optical/ps5724/ps2006/at_a_glance_c45-728015.pdf How many people are actually doing this? Not sure why you would want the massive fail that is layer-2 DCI in the first place, but you certainly don't need this sort of ridiculously expensive gear. Packet encryption is embarrassingly parallel when you have lots of flows, and best distributed throughout the infrastructure to many endpoints. One big expensive box is one big bottleneck and one big SPOF. We actually use cluster-to-cluster and even host-to-host IPsec SAs in certain cases.
Re: PRISM: NSA/FBI Internet data mining project
On Jun 7, 2013, at 12:25 AM, jamie rishaw j...@arpa.com wrote: tinfoilhat Just wait until we find out dark and lit private fiber is getting vampired. /tinfoilhat Speaking from the content provider dide here, but we've always run IPsec on DCIs and even private T1s/DS3s back in the day. Doesn't everyone do the same these days? I find it hard to imagine passing any audit/compliance process without doing so. Private lines or dedicated fiber always pass through much public, unmanaged, and unmonitored space infrastructure. And we know better than to trust our providers to never screw up and mis-route traffic.
Re: CDN server log
Djamel, If you are looking for a CDN log trace to do academic research work on say, caching algorithms, please be straightforward about your needs and someone (including myself) might be able to help. If your purposes are commercial, asking for free data won't likely get you far. If you're trying to turn the data into money expect to pay someone for it. On May 16, 2013, at 10:33 AM, Michal Krsek mic...@krsek.cz wrote: Hi Djamel, I'm not sure what you are looking for. There is variety of CDN content and popularity is being driven by users and designers. If you have CDN that serves pictures, you get most hits on design pictures, for paid VoD, you get most hits on free trailers. For CatchTV tup you get most hits on new arrivals of popular content. It also depends on geo distribution. Global CDNs get different coverage than regional ones. For live transmissions, you get a lot of content when covering big sports events. For adult based content CDN ... you can imagine ... Just talking in general, having no permission to provide any log. With kind regards Michal Dne 16.5.2013 15:16, Djamel Sadok napsal(a): Hi Pete, I do not use a CDN I am only interested in analyzing content popularity in logs. These could be anonymized. Djamel On Wed, May 15, 2013 at 3:55 PM, Pete Mastin pmas...@internap.com wrote: Hi djamel. If I understand your question - you should take a look at what sawmill offers. Many of our clients use this product to analyze our cdn produced logs. http://www.sawmill.net/ Sent from my iPhone On May 15, 2013, at 10:30 AM, Djamel Sadok ja...@cin.ufpe.br wrote: Hi, Anyone knows of any public CDN server log trace. I am looking for object popularity, hit rate information, ... Thanks, Djamel
Re: The 100 Gbit/s problem in your network
On Feb 9, 2013, at 6:45 AM, fredrik danerklint fredan-na...@fredan.se wrote: No. Streaming from services, like Netflix, HBO, etc..., is what's coming. We need to prepare for the bandwidth they are going to be using. Then work on your HTTP caching infrastructure. All these services already use a proprietary form of HTTP adaptive streaming, either MSFT, Adobe, or Apple. These technologies are being unified by DASH in the MPEG/ISO standards bodies. Adaptive HTTP chunk streaming gives you the best of multicast-like and cached VoD behavior, exploiting the temporal locality of popularity in content while not requiring multicast. As a content publisher, I must say it works wonders for us so far, even with just two bitrates. There is a huge HTTP caching infrastructure out there in businesses, schools, and other orgs that is unused by other video transports; even plain HTTP downloads usually overrun cache object size limits. The Olympic streaming in particular showed how well HTTP chunk video can scale; dozen of screens in my org showed the same content all day from local cache, with no noticeable spikes on our transit links. Is HTTP as efficient a protocol as possible for transporting video? No, but 1K of headers per 1M of content chunk puts it within 0.1% of netcat. And working now with widely deployed infrastructure beats stuck in Internet Draft forever.
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 9, 2012, at 2:58 AM, Randy Bush ra...@psg.com wrote: reliable tunnel bzzzt! oxymoron alert!!! Intellectually I want to agree with you, but after some reflection... We use lots of tunnels at my org - the IPsec variety. A quick non-scientific query of our monitoring logs reveals that our tunnels are exactly as reliable as the circuits and routers which underneath them. MTU issues aren't really a problem for us either, but then again we do control all the devices at at least one end if the tunnel. I defer to your experience and reputation Randy, and im syre you're right. But where are all these horrifically unreliable tunnels?
Re: NTP Issues Today
On Nov 19, 2012, at 6:12 PM, Scott Weeks sur...@mauigateway.com wrote: wbai...@satelliteintelligencegroup.com Or you could just concede the fact that the navy is playing with time travel again. -- To finish this thread off for the archives... Apparently something was up with the navy stuff as a post on the outages shows.
Re: NTP Issues Today
On Nov 19, 2012, at 6:12 PM, Scott Weeks sur...@mauigateway.com wrote: Lesson learned: Use more than one NTP source. The lesson is: use MORE THAN TWO diverse NTP sources. A man with two watches has no idea what the time it actually is.
Re: Network scan tool/appliance horror stories
On Oct 29, 2012, at 3:55 PM, Rutis, Cameron 6) large stacks of 3750s (six or more members) have issues around CPU during certain SNMP commands (I want to say some sort of getbulk type of command) The first four were pretty minor although #3 could generate a lot of calls to the support center. #5 was a big deal due to the nature of the application. #6 was impactful because we dropped routing neighbors for about 10 seconds but this was a couple of years ago so may have been an old IOS bug. Saw the same. All of our 3750 stacks (which are small) committed suicide during a trial of Foglight. We had discovery timings turned way down, but it still caused a reload on a mix of the last supposedly really stable releases of 12.x. Not confidence inspiring. TAC was useless and suggested a v15 upgrade despite no known fix. The proposed v15 upgrade sent our lab boxes into continuous reload unless you broke the stack and manually wiped each switch. Oh, and port 28 was invisible on each switch after upgrade, and Gi2/0/28 would throw a syntax error. Wait for new releases, lather, rinse, repeat. Total time to resolution in production was several man-weeks on our side, and a few months calendar time, all because the discovery scan revealed how great a software company Cisco has become.
Re: Attacking on Source Port 0 (ZERO)
On Oct 14, 2012, at 9:02 PM, Dobbins, Roland rdobb...@arbor.net wrote: Hopefully, you have hardware-based edge devices, not just software-based devices and (awful) stateful firewalls - the days of software-based devices on the Internet were over years ago. Software forwarding is usually only a problem if you have the $5 CPU that Cisco puts in their $30K boxes. The overwhelming majority of edge connections are =1Gbps. A modern x86 can handle several of these connections *per core* at minimum packet sizes with stock Linux/BSD, including ACLs. 10G+ forwarding with minimum packet sizes is possible on a single core using optimized kernels (see Intel DPDK and PF_RING DNA). You don't need to handle more packets than you can possibly receive over your interfaces.
Re: Big Temporary Networks (Dreamforce)
Anyone from nanog currently at the wheel of the conference network at Dreamforce in San Francisco (nearly 7 attendees)? It appears that all of the suggestions posted to this nanog thread so far were thoroughly ignored. Conference WiFi is effectively unusable, despite the very visible, expensive-looking enterprisey APs on temporary stands sprinkled throughout the conference. As far as I can tell, they're doing NAT, using a /16 per AP (which could amount to 5,000 or more devices in one broadcast domain depending on the location!), and are using what appear to be omnidirectional antennas at full blast power instead of zoning with tight directionals. Wifi is nearly unusable; even Sprint's crappy 3G coverage is faster and more reliable inside the conference halls.. -- RPM
Re: Does anyone use anycast DHCP service?
From: Leo Bicknell bicknell () ufp org Assuming your DHCP servers are properly clustered, simply have your routers relay all requests to both servers. Here's instructions on setting up ISC DHCPD for redundant (pooled) servers: http://www.madboa.com/geek/dhcp-failover/ .. Works great, no single point of failure, no anycast. It may very well work *most* of the time, or during controlled failover, but it looks pretty creaky to me. Some thoughts: 1) No third-party witness service for the cluster, making split-brain scenarios a very real possibility. 2) Multi-master databases are quite challenging in practice. This one appears to rely on timestamps from the system clock for conflict detection, which has been shown to be unreliable time and again in the application space. 3) There are single points of failure. You've traded hardware as a single point of failure for bug-free implementation of clustering code on both DHCP servers as a single point of failure. In general, software is far less reliable than hardware. I think it would be far more reliable to simply have two independent DHCP servers with mutually exclusive address ranges, and have one system be secondary and delay its responses by 2s so it always loses when the primary is up and running well. Yes, you lose the ability for clients to get the same IP during a lease refresh if the primary is down, but that is a small price to pay for simplicity and robustness. -- RPM
Re: Does anyone use anycast DHCP service?
On Mon, Aug 13, 2012 at 9:10 AM, Leo Bicknell bickn...@ufp.org wrote: The ISC implementation is designed to continue to work with a split brain. I believe the Microsoft solution is as well, but I know ... You are incorrect. The ISC implementation divides the free addresses between the two servers. The client will only interact with the first to respond (literally, no timestamps involved). Clients talking to each half of a split brain can continue to receive addresses from the shared range, no timestamps are needed to resolve conflicts, because the pool was split prior to the loss of server-to-server communication. There is a down-side to this design, in that if half the brain goes away half of the free addresses become unusable with it until it resynchronizes. This can be mitigated by oversizing the pools. Glad to hear it is a better design than my first skimming of the documentation indicated. Essentially,an ISC DHCPD cluster is basically two independent servers, with the added optimization of replicating reservations from one system to the other so it can answer renewals when possible. I still wonder what happens when a renewal happens during failover, and then the original server comes back on-line, and a renewal of the same address happens during startup. Hopefully any node joining a cluster waits until it is fully synchronized before answering queries. I've seen so many two-node HA pair setups go horribly sideways during my IT career, I usually assume the worst. Firewalls, load balancers, stackable switches, databases, SANs, you name it. They all usually survive the pull the plug on one node test during QA, but that's about it. -- RPM
Re: IPV6 Anycast for streaming
From: Voice of the Blind ™ Network Operation noc () vobradio org Hello, is a anycasted Prefix a good idea for Streaming? Maybe. I've used TCP anycast-based CDNs (CacheFly and MaxCDN/NetDNA), and they work very well. I observe they generally work something like this: 1. DNS resolution with long TTLs returning anycasted IPs. 2. Smaller HTTP requests served directly from anycast IP with http keepalives enabled. 3. Large objects and streams do an application layer redirect (HTTP or whatever stream protocol) to a DNS name that returns unicast IPs for the node you initially reached via anycast. I would recommend looking at CDNs however, as this is an area where scale does matter and you will find it very difficult to do this better or cheaper yourself.
RE: raging bulls
Naslund, Steve SNaslund () medline com wrote: It seems to me that all the markets have been doing this the wrong way. Would it now be more fair to use some kind of signed timestamp and process all transactions in the order that they originated? Perhaps each trade could have a signed GPS tag with the absolute time on it. It would keep everyone's trades in order no matter how latent their connection to the market was. All you would have to do is introduce a couple of seconds delay to account for the longest circuit and then take them in order. They could certainly use less expensive connections and ensure that international traders get a fair shake. I can't see any incentive for any *influential* party involved (the big firms or the exchanges) to make the process fair. The exchange gets more money for low-latency network access and expensive co-location. The moneyed firms with HFT capability of course do not want anyone else to have their advantage. Even governments don't want long-distance traders to have fair access, as that reduces the advantage of local tax-paying firms, thereby reducing tax revenue, jobs, etc. HFT is not just a US phenomenon; all major exchanges have basically the same sort of phenomenon. So UK-based trading firms with HFT setups very close to the FTSE exchanges have advantage over US-based firms that don't have HFT setups in London. -- RPM
Re: FYI Netflix is down
On Jul 8, 2012, at 7:27 PM, steve pirk [egrep] st...@pirk.com wrote: I am pretty sure Netflix and others were trying to do it right, as they all had graceful fail-over to a secondary AWS zone defined. Having a single company as an infrastructure supplier is not trying to do it right from an engineering OR business perspective. It's lazy. No matter how many availability zones the vendor claims.
RE: FYI Netflix is down
James Downs wrote: For Netflix (and all other similar services) downtime is money and money is downtime. There is a quantifiable cost for customer acquisition and a quantifiable churn during each minute of downtime. Mature organizations actually calculate and track this. The trick is to ensure that you have balanced the cost of greater redundancy vs the cost of churn/customer acquisition. If you are spending too much on redundancy, it's as big of mistake as spending too little. Actually, for Netflix, so long as downtime is infrequent or short enough that users don't cancel, it actually saves them money. They're not paying royalties for movies being streamed during downtime, but they're still collecting their $8/month. There is no meaningful SLA for the end user to my knowledge. I imagine the threshold for *any* user churn based on downtime is very high for Netflix. So long as they are about as good as cable/sattelite TV in terms of uptime Netflix will do fine. You would have to get into 98% uptime or lower before people would really start getting irritated enough to cancel. Of course multiple short outages would be more painful than a few longer ones from a customer's perspective. I imagine Netflix is mature enough to track this data as you suggest, and that's why they use AWS - downtime isn't a big deal for their business unless it gets really, really bad.
Re: FYI Netflix is down
Jon Lewis wrote: It seems like if you're going to outsource your mission critical infrastructure to cloud you should probably pick at least 2 unrelated cloud providers and if at all possible, not outsource the systems that balance/direct traffic...and if you're really serious about it, have at least two of these setup at different facilities such that if the primary goes offline, the secondary takes over. If a cloud provider fails, you redirect to another. Really, you need at least three independent providers. One primary (A), one backup (B), and one witness to monitor the others for failure. The witness site can of course be low-powered, as it is not in the data plane of the applications, but just participates in the control plane. In the event of a loss of communication, the majority clique wins, and the isolated environments shut themselves down. This is of course how any sane clustering setup has protected against split brain scenarios for decades. Doing it the right way makes the cloud far less cost-effective and far less agile. Once you get it all set up just so, change becomes very difficult. All the monitoring and fail-over/fail-back operations are generally application-specific and provider-specific, so there's a lot of lock-in. Tools like RightScale are a step in the right direction, but don't really touch the application layer. You also have to worry about the availability of yet another provider! -- RPM
Re: strat-1 gps
+1 on the freesd-or-linux. with say a Garmin GPS-18x or whatever timing puck. Have an intern or junior tech tackle it as a learning exercise. The time geeks on comp.protocols.time.ntp seem to favor low-power Soekris hardware (http://soekris.com/) for stratum-1s. You need RS232 serial to get decent PPS; USB introduces tons of jitter. If you have to have something pre-integrated and soon, I'd look at Meinberg: http://www.meinberg.de/english/products/index.htm#network_sync -- RPM
SunGard contact in Boston datacenter?
Anybody from SunGard lurking? We're observing major packet loss on an ATT link to SunGard router 74.205.255.246 in Boston. We have a SaaS vendor behind that router, and the application is all but unusable. The SaaS vendor's support staff aren't able to address the issue with SunGard (or don't know how). Thanks for any help, -- Ryan Malayter
Re: dell switch config export
On Friday, March 16, 2012 2:04:04 PM UTC-5, Jeroen van Aart wrote: Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working... Thanks, Jeroen We have a few 6248s, and as I recall the web UI is confusing and clearly not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. It's a bit more sane from the cli (which is actually decent in the recent firmware for the 6248s at least). It is of course possible the software is entirely different on the 3400-series though. Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 2:21 am, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: William Herrin wrote: When I ran the numbers a few years ago, a route had a global cost impact in the neighborhood of $8000/year. It's tough to make a case that folks who need multihoming's reliability can't afford to put that much into the system. The cost for bloated DFZ routing table is not so small and is paid by all the players, including those who use DFZ but do not multihome. Hi, http://bill.herrin.us/network/bgpcost.html If you believe there's an error in my methodology, feel free to take issue with it. Your estimate on the number of routers in DFZ: somewhere between 120,000 and 180,000 with the consensus number near 150,000 is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry. Because DFZ capable routers are so expensive, the actual number of routers is so limited. If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. The reason current routers in the core are so expensive is because of the 40 gigabit interfaces, custom ASICs to handle billions of PPS, esoteric features, and lack of competition. The fact that long-haul fiber is very expensive to run limits the number of DFZ routers more than anything else. Why not take a default route and simplify life when you're at the end of a single coax link? If your lucky enough to have access to fiber from multiple providers, the cost of a router which can handle a full table is not a major concern compared with your monthly recurring charges. -- RPM
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 2:18 pm, Owen DeLong o...@delong.com wrote: On Mar 13, 2012, at 6:03 AM, Masataka Ohta wrote: Ryan Malayter wrote: If the number of routes in DFZ is, say, 100, many routers and hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. What if, you run windows? Why would you want to run windows on a box you're trying to use as a router? That's like trying to invade Fort Knox with a bag of plastic soldiers. Check your quoting depth... you're attributing Masataka Ohta's comments to me, he brought up running windows. I am the one who brought put forward the notion of a sub-$2000 DFZ router.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 13, 8:03 am, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: The point of http://bill.herrin.us/network/bgpcost.html was that routers are more expensive because of bloated routing table. If you deny it, you must deny its conclusion. Bill's analysis is quite interesting, but my initial take is that it is somehwat flawed. It assumes that the difference between what Cisco charges for a 7606 and a 3750G bears some resemblance to the actual bill of materials needed to support the larger routing table. That simply isn't the case: Cisco rightly charges what they think the market will bear for their routers and switches. I think a more realistic approach would be to use the cost differential between a router model X that supports 1M routes the same model configured to support 2M routes. Or perhaps we could look at the street prices for TCAM expansion modules. Either would be a better indicator of the incremental cost attributable to routing table size. The majority of costs in a mid-to-high-end Cisco/Juniper chassis are sunk and have nothing to do with the size of the routing table. The expensive routers currently used by providers are expensive because the market isn't that big in quantity, so they are not commodity items. They are designed to maximize the utility of very expensive long-haul fibers and facilities to a service provider. This means providing a high density of high-speed interfaces which can handle millions to billions of packets per second. They also provide lots of features that service providers and large enterprises want, sometimes in custom ASICs. These are features which have nothing to do with the size of the DFZ routing table, but significantly impact the cost of the device. Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. I suppose smaller multi-homed sites can and often do take a full table, but they don't *need* to do so. What they do need is their routes advertised to the rest of the internet, which means they must be in the fancy-and-currently-expensive routers somewhere upstream. This is where the cost of long-haul fiber becomes relevant: Until we can figure out how dig cheaper ditches and negotiate cheaper rights-of- way, there will not be an explosion of the number of full-table provider edge routers, because there are only so many interconnection points where they are needed. Incremental growth, perhaps, but physical infrastructure cannot follow an exponential growth curve. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. For consumer connections, a sub-$1000 PC would serve you fine with a full table given the level of over-subscription involved. Even something like Quagga or Vyatta running in a virutal machine would suffice. Or a Linksys with more RAM. Getting your providers to speak BGP with you on such a connection for that same $100/month will be quite a feat. Even in your contrived case, however, the monthly recurring charges exceed a $1000 router cost after a few months. Enterprises pay several thousand dollars per month per link for quality IP transit at Gigabit rates.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 12, 10:07 am, Robert E. Seastrom r...@seastrom.com wrote: It didn't help that there was initially no implementation of shim6 whatsoever. That later turned into a single prototype implementation of shim6 for linux. As much as I tried to keep an open mind about shim6, eventually it became clear that this was a Gedankenexperiment in protocol design. Somewhere along the line I started publicly referring to it as sham6. I'm sure I'm not the only person who came to that conclusion. I thought the IETF required two inter-operable implementations for protocols. Or was that just for standards-track stuff? Anyway, the effort involved in getting Shim6 implemented globally on all devices would have been nearly as large as switching over all applications from TCP to a protocol with a proper session layer, like SCTP. I believe there are libraries that wrap SCTP and make it look like TCP to legacy applications; wouldn't that have been a better approach?
Re: Fwd: VLAN Troubles
On Mar 6, 11:53 am, david peahi davidpe...@gmail.com wrote: Why don't you replace the Dell switches with Cisco 3560s, and that way you are working with a single implementation of the IEEE 802.1q trunking standard? I think the very existence of this email thread proves that much time and effort is wasted in the attempt to seamlessly interoperate devices from multiple vendors. In this email thread alone I counted 2 CLI's to be learned, 2 tech support organizations to call, and 2 hardware types to spare. David Funny, it's always the Cisco devices that seem to be the cause of interop problems in my network. They're the only vendor that seems to think defaulting proprietary protocols is reasonable. Cat 3ks default to proprietary Rapid-PVST+, proprietary VTP, proprietary DTP, proprietary HSRP, and proprietary ISL tagging. And Cisco documentation generally recommends these proprietary protocols or at least documents them *before* the standard equivalents (wonder why?). Cisco does of course generally support the IEEE or IETF protocols, but not without configuration that often requires downtime or at least a spanning-tree/ OSPF event if it was missed before deployment. We can lash together Dell/HP/other switches all day long with near- default configurations, but every time we have a new Cisco box to configure it's required to wade though IOS release notes to see what new proprietary protocol we have to disable. Cisco makes good gear with lots of features, but can be a royal pain if you use *anything* non-Cisco. It's not prudent to rely on a single vendor for anything, and it's not as though IOS is a magically bug- free bit of code. I've been told that in at least some high-frequency trading networks, the redundant switches/routers at each tier are intentionally from different vendors, so that a software issue in one won't take everything down. That seems like a good idea at first, but it wouldn't surprise me to have an interop issue or mis-configuration caused by unfamiliarity take down both devices. Does anybody out there do this?
Iran blocking essentially all encyrpted protocols
Haven't seen this come through on NANOG yet: http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars Can anyone with the ability confirm that TCP/443 traffic from Iran has stopped?
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
On Feb 10, 12:01 pm, Leo Bicknell bickn...@ufp.org wrote: OSX at least has a central certificate store (Keychain), although it's not up to the tasks of the world I wish to have. Other OS's provide no central store, so each application maintains their own key store. Windows has had its own centralized certificate store and APIs since NT 4.0's release in 1996. Firefox and Java are the only mainstream software can think of on Windows that insists on using their own certificate stores (really just a pile of world-readable files) instead of the built-in per- machine+per-user certificate store on Windows.
Re: subnet prefix length 64 breaks IPv6?
On Dec 28, 7:10 am, sth...@nethelp.no wrote: On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on /64 is somewhat less efficient. Can you please name names for the somewhat less efficient part? I've seen this and similar claims several times, but the lack of specific information is rather astounding. Well, I do know if you look at the specs for most newer L3 switches, they will often say something like max IPv4 routes 8192, max IPv6 routes 4096. This leads one to believe that the TCAMs/hash tables are only using 64 bits for IPv6 forwarding, and therefores longer prefixes must be handled in software. This may very well not be true under the hood at all, but the fact that vendors publish so little IPv6 specification and benchmarking information doesn't help matters.
Re: subnet prefix length 64 breaks IPv6?
On Dec 28, 8:50 am, sth...@nethelp.no wrote: It might lead you to believe so - however, I believe this would be commercial suicide for hardware forwarding boxes because they would no longer be able to handle IPv6 at line rate for prefixes needing more than 64 bit lookups. It would also be an easy way to DoS such boxes... That's just what I'm arguing here: no vendor info I've seen positively says they *can* handle line-rate with longer IPv6 prefixes. The other information available leads one to believe that all the published specs are based on /64 prefixes. Even a third-party test reports don't mention IPv6 or prefix length at all: http://www.aristanetworks.com/media/system/pdf/LippisTestReportMay2011.pdf Cisco actually has published quite a bit of info, e.g. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod... Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and 200 Mpps IPv6 with dCEF They have also published EANTC tests which include IPv6 forwarding rates. Except nowhere in there is the prefix length for the test indicated, and the exact halving of forwarding rate for IPv6 leads one to believe that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups) versus one for IPv4. For example, what is the forwarding rate for IPv6 when the tables are filled with /124 IPv6 routes that differ only in the last 60 bits? Even then EANTC test results you reference make no mention of the prefix length for IPv4 or IPv6, or even the number of routes in the lookup table during the testing: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd800c958a.pdf
Re: subnet prefix length 64 breaks IPv6?
On Dec 28, 9:44 am, Ray Soucy r...@maine.edu wrote: For what its worth I haven't stress tested it or anything, but I haven't seen any evidence on any of our RSP/SUP 720 boxes that would have caused me to think that routing and forwarding isn't being done in hardware, and we make liberal use of prefixes longer than 64 (including 126 for every link network). They might just be under capacity to the point that I haven't noticed, though. I have no problem getting muti-gigabit IPv6 throughput. You can get 10GbE *throughput* from a Linux box doing all forwarding in software as well. That's easy when the packets are big and the routing tables are small, and the hash tables all fit in high-speed processor cache. The general lack of deep information about how the switching and routing hardware really works for IPv6 is my main problem. It's not enough to make informed buying or design decisions. Unfortunately, I have over the course of my career learned that a trust but verify policy is required when managing vendors. Especially vendors that have a near-monopoly market position. The problem, of course, is that verifying this sort of thing with realistic worst-case benchmarks requires some very expensive equipment and a lot of time, which is why the lack of solid information from vendors and 3rd-party testing labs is worrying. Surely some engineers from the major switch/router vendors read the NANOG list. Anybody care to chime in with we forward all IPv6 prefix lengths in hardware for these product families?
Re: Broadband providers in downtown Chicago
On Dec 1, 11:30 am, Ishmael Rufus sakam...@gmail.com wrote: Our company is in a building at 200 w. Monroe and we have difficulty finding an internet service provider that could at least provide 1Mbps+ Upload bandwidth that is not Cogent Communications. Is it really this difficult finding a decent internet service provider in downtown Chicago? No, it isn't. Unless your building management has an exclusive deal with Cogent. We have our choice of basically every national Tier-1 and all the larger regional players around the corner on Monroe.
Re: Question on 95th percentile and Over-usage transit pricing
On Sep 22, 12:54 am, PC paul4...@gmail.com wrote: An optimal solution would be a tiered system where the adjusted price only applies to traffic units over the price tier threshold and not retroactively to all traffic units. I have seen a more optimal scheme about 15 years ago. Pricing was a smooth function, but it was for software licensing, not networking. As I recall, their scheme went something like: invoice_amount = some_constant * (quantity)^0.75 This seemed smart to me. It gave the customer incentives to invest more, but also got rid of silly discontinuities that would cause irrational customer and salesperson behavior. Has anyone seen something similar in the service provider world? All I ever see are arbitrary step functions.
Re: IPv6 end user addressing
On Aug 8, 6:24 pm, Jonathon Exley jonathon.ex...@kordia.co.nz wrote: Silly confidentiality notices are usually enforced by silly corporate IT departments Oh, no, it's the *legal* department (or maybe HR) that is to blame. I actually had a guardhouse lawyer kick and scream about us not putting disclaimers on our emails. I told him, You do realize that email disclaimers have no legal standing, have never been successfully used in any litigation, do nothing to prevent loss of corporate assets, and actually increase our liability by outlining a corporate policy that may not be followed 100% internally by all employees, right? It took a long while and an embarrassing number of meetings with senior management, but we eventually put a stop to the whole thing.
Re: Strange TCP connection behavior 2.0 RC2 (+3)
On Jun 28, 3:35 pm, Cameron Byrne cb.li...@gmail.com wrote: AFAIK, Verizon and all the other 4 largest mobile networks in the USA have transparent TCP proxies in place. Do you have a reference for that information? Neither ATT nor Sprint seem to have transparent *HTTP* proxies according to http://www.lagado.com/tools/cache-test. I would have thought that would be the first and most important optimization a mobile carrier could make. I used to see mobile-optimized images and HTTP compression for sites that weren't using it at the origin on Verizon's 3G network a few years ago, so Verizon clearly had some form of HTTP proxy in effect. Aside from that, how would one check for a transparent *TCP* proxy? By looking at IP or TCP option fingerprints at the receiver? Or comparing TCP ACK RTT versus ICMP ping RTT?
IPv6 Availability on XO
We have 45 Mbps from XO in our downtown Chicago location in the financial district. We have asked for IPv6 every month for a while, and keep hearing maybe soon and not much else. Unfortunately, if we can't get it in that very competitive and dense market location, I doubt they offer it anywhere. Note to anyone clueful from XO listening: the RFP is going out next month, and IPv6 transit is a MUST.
Re: Amazon diagnosis
On May 5, 3:51 pm, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ryan Malayter malay...@gmail.com I like to bag on my developers for not knowing anything about the infrastructure, but sometimes you just can't do it right because of physics. Or you can't do it right without writing your own OS, networking stacks, file systems, etc., which means it is essentially impossible in the real world. Physics? Isn't that an entirely inadequate substitute for desire? Not really. For some applications, it is physics: 1) You need two or more locations separated by say 500km for disaster protection (think Katrina, or Japan Tsunami). 2) Those two locations need to be 100% consistent, with in-order serializable ACID semantics for a particular database entity. An example would be some sort of financial account - the order of transactions against that account must be such that an account cannot go below a certain value, and debits to and from different accounts must always happen together or not at all. The above implies a two-phase commit protocol. This, in turn, implies *at least* two network round-trips. Given a perfect dedicated fiber network and no switch/router/CPU/disk latency, this means at least 10.8 ms per transaction, or at most 92 transactions per second per affected database entity. The reality of real networks, disks, databases, and servers makes this perfect scenario unachievable - often by an order of magnitude. I don't have inside knowledge, but I suspect this is why Wall Street firms have DR sites across the river in New Jersey, rather than somewhere safer. Amazon's EBS service is network-based block storage, with semantics similar to the financial account scenario: data writes to the volume must happen in-order at all replicas. Which is why EBS volumes cannot have a replica a great distance away from the primary. So any application which used the EBS abstraction for keeping consistent state were screwed during this Amazon outage. The fact that Amazon's availability zones were not, in fact, very isolated from each other for this particular failure scenario compounded the problem.
Re: Amazon diagnosis
On May 1, 2:29 pm, Jeff Wheeler j...@inconcepts.biz wrote: What it really boils down to is this: if application developers are doing their jobs, a given service can be easy and inexpensive to distribute to unrelated systems/networks without a huge infrastructure expense. If the developers are not, you end up spending a lot of money on infrastructure to make up for code, databases, and APIs which were not designed with this in mind. Umm... see the CAP theorem. There are certain things, such as ACID transactions, which are *impossible* to geographically distribute with redundancy in a performant and scalable way because of speed of light constraints. Of course web-startups like Reddit have no excuse in this area: they don't even *need* ACID transactions for anything they do, as what they are storing is utterly unimportant in the financial sense and can be handled with eventually-consistent semantics. But asynchronous replication doesn't cut it for something like stock trades, or even B2C order taking. I like to bag on my developers for not knowing anything about the infrastructure, but sometimes you just can't do it right because of physics. Or you can't do it right without writing your own OS, networking stacks, file systems, etc., which means it is essentially impossible in the real world.
Re: Syngenta space
On Apr 13, 2:44 pm, Randy Bush ra...@psg.com wrote: sorry for the noise, but my contact at Syngenta says they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, and pigs fly And to think, Google manages to get by with the equivalents of a few / 16 or smaller.
