Last December I described the technologies that could be used to implement Infrastructure-as-a-Service (IaaS) clouds in the Cloud Computing Networking: Under the Hood webinar. In the meantime, I focused on the scalability aspects of these technologies and the need for virtual/physical separation. These topics are described in a sequel to December’s webinar: Cloud Computing Networking: Will It Scale? (register here).
A while ago I wrote that the hypervisor vendors should consider turning the virtual switches into PE-routers. We all know that’s never going to happen due to religious objections from everyone who thinks VLANs are the greatest thing ever invented and MP-BGP is pure evil, but there are at least two good technical reasons why putting MPLS/VPN (as we know it today) in the hypervisors might not be the best idea in very large data centers.
March 2007 was clearly the “local usernames” month. I wrote about Configuring local authentication with AAA, One-time passwords on Cisco routers, Local usernames with no password and Enhanced password security for local usernames.
March 2009 had a mixture of DSL and BGP topics. DSL topics included ADSL overhead and Rate-limiting inbound traffic; BGP ones AS-path prepending: technical details, BGP Local-AS feature: the basics and EBGP load balancing with a multihop EBGP session.
The first question everyone asked after Nicira had published yet another MAC-over-IP tunneling draft was probably “do we really need yet another encapsulation scheme? Aren’t VXLAN or NVGRE enough?” Bruce Davie tried to answer that question in his blog post (and provided more details in another one), and I’ll try to make the answer a bit more graphical.
Wim (@fracske) De Smet sent me a whole set of very good VXLAN- and EVB-related questions that might be relevant to a wider audience.
If I understand you correctly, you think that VXLAN will win over EVB?
I wouldn’t say they are competing directly from the technology perspective. There are two ways you can design your virtual networks: (a) smart core with simple edge (see also: voice and Frame Relay switches) or (b) smart edge with simple core (see also: Internet). EVB makes option (a) more viable, VXLAN is an early attempt at implementing option (b).
In almost every field of IT lots of people try to do their job relying on uncle Google and his friends (bloggers, forum wizards and other content producers) and cut-and-paste solutions found on the web into their programs, server- or device configurations. Here’s my theory why that might be the case; please feel free to shoot it down in flames.
My regular readers probably know that I’m running a 4-month course in scalable web application design at University of Ljubljana (everyone else will find more details here). I was extremely surprised when we started – I’d expected to see about a dozen students, and suddenly realized I was standing in front of a totally crowded classroom. The next amazing surprise was the students’ level of motivation, commitment, knowledge, and the quality of their questions. It’s definitely fun to have an audience like that.
HP has recently released OpenFlow support on a few more switches and some people think it’s a big deal. It just might be if you’re a researcher with limited grant budget (which seems to be one of the major OpenFlow use cases today); for everyone else, it’s a meh. Lacking a commercial-grade OpenFlow controller supported by HP (or at least tested with HP switches), OpenFlow on HP switches remains a shiny new toy.
When I was writing about the NEC+IBM OpenFlow trials, I figured out a perfect use case for OpenFlow-controlled network forwarding: SMB data centers that need less than a few hundred physical servers – be it bare-metal servers or hypervisor hosts (hat tip to Brad Hedlund for nudging me in the right direction a while ago)
As I wrote before, OpenFlow-controlled network forwarding (example: NEC, BigSwitch) experiences a totally different set of problems than OpenFlow-controlled edge (example: Nicira or XenServer vSwitch Controller).
Instead of drinking beer and lab-testing vodka during the PLNOG party I enjoyed DHCPv6 discussions with Tomasz Mrugalski, the “master-of-last-resort” for the ISC’s DHCPv6 server. I mentioned my favorite DHCPv6 relay problem (relay redundancy) and while we immediately agreed I’m right (from the academic perspective), he brought up an interesting question – is this really an operational problem?
One of the few presentations I could understand @ PLNOG meeting yesterday (most of them were in Polish) was the fantastic “Guide To Building Secure Network Infrastructures” by Merike Kaeo, during which she revealed an obvious but oft forgotten fact: by deploying IPv6 in your router, you’ve actually created a parallel entry into the management plane that has to be secured using the same (or similar) mechanisms as its IPv4 counterpart.
As you know, I’m back in Poland, this time attending PLNOG. Meeting the wonderful team of the PLNOG organizers brought back old memories and I figured out I haven’t blogged about the Euronog videos they started publishing late last year. The last time I checked their web site only a few videos were available. Imagine my surprise when I figured out almost all the presentations they recorded are now available for download.
I decided it was high time to start using some of the cloud services I'm writing about in production. Haven't jumped into EC2 yet, but the DNS server for ioshints.info has been moved to Amazon Route 53 and the static parts of the blog are served from Amazon S3.
This should result in somewhat faster web site for my largest audience - US readers. Next step: CloudFront. And as always - if you find something is broken, please write a comment or contact me directly.
While I was discussing the intricacies of Cisco’s IPv6 implementation with Gunter Van de Velde a while ago, he suddenly changed hats and asked me whether I would be willing to contribute to a BGP filtering best practices draft. I’m still too young to realize it’s not a good idea to say YES every time you see something interesting and immediately accepted the challenge.
Till a few weeks ago, you could get provider-independent (PI) IPv6 address space in RIPE region only if you “demonstrated that you’ll be multihomed” ... which usually required having nothing more than an AS number. With the recent policy change, anyone can get PI address space (and this is why you should get it) as long as they have a sponsoring LIR, and the yearly fee for an independent resource (RIPE-to-LIR) is €50.
The 8th PLNOG meeting starts in less than a week and the fantastic Andrzej Targosz has yet again kindly invited me to talk about cloud networking and data center fabrics (the first session is on Monday afternoon, the second one on Tuesday morning). I’ll be in Warsaw from Sunday evening to late Wednesday morning, so if you’d like to meet me, ask me a really tough question (layer-2 DCI is off-limits), discuss your network design, or just drink a cup of coffee or a beer with me (please don’t mention vodka), send me an e-mail and we’ll figure out where and when to meet.
Posts
