Scaling Congress
(This post was written by Tim Hinrichs, Shawn Hargan, and Alex Yip.)
Policy is a topic that we’ve touched on before here at Network Heresy. In fact, policy was the focus of a series of blog posts: first describing the policy problem and why policy is so important, then describing the range of potential solutions, followed by a comparison of policy efforts within OpenStack, and finally culminating in a detailed description of Congress: a project aimed at providing “policy as a service” to OpenStack clouds. (Check out the OpenStack wiki page on Congress for more details on the Congress project itself.)
Like other OpenStack projects, Congress is moving very quickly. Recently, one of the lead developers of Congress summarized some of the performance improvements that have been realized in recent builds of Congress. These performance improvements include things like much faster query performance, massive reductions in data import speeds, and significant reductions in memory overhead.
If you’re interested in the full details on the performance improvements that the Congress team is seeing, go read the full post on scaling the performance of Congress over at ruleyourcloud.com. (You can also subscribe to the RSS feed Continue reading
Networking Basics – Test 1
There are 10 basic questions below. Most of them relatively basic networking questions. This test can be taken only one time, so take your time, provide your Name and Email so you can be in Leaderboard. If you like this networking basics test,please leave a comment, so I continue to prepare similar tests. After solving this test… Read More »
The post Networking Basics – Test 1 appeared first on Network Design and Architecture.
When SSL Certificates Go Wild
You’ve set up your website and secured it with an SSL certificate that you bought through your ISP. Everything works fine and the chain of trust is just fine in your browser, but when you try accessing your secured site using a command line tool, the connection fails. Why? There’s a good chance that you are not sending your intermediate certificate(s) along with the server certificate.
PKI Trust Review
As a quick reminder, the whole point of SSL certificates and the Public Key Infrastructure is to prove that the site you connected to is the one it says it is. How do we know? The server sends you a certificate with its name in it, digitally signed by an Issuer. If you choose to trust that Issuer’s honesty and believe that they made sure they issued to the right site, you implicitly trust that the end site is the right one; it’s a “Chain of Trust.”
In reality, we don’t typically trust many Issuers. Look in the Trusted Root certificates for your browser, or on a Mac, open Keychain Access and look in System Roots, and you’ll see that for Yosemite in this case, globally – to establish SSL Continue reading
What caused the Google service interruption?
This morning people on twitter reported that they were unable to reach Google services. Businessinsider followed up with a story in which they mentioned that the Google service interruption primarily involved European and Indian users.
In this blog we’ll take a quick look at what exactly happened by looking at our BGP data. The first clue comes from David Roy and Franck Klopfenstein on twitter who noticed traffic was re-routed towards AS9498 in India. Digging through our BGP data we are able to indeed confirm that routing paths for many google prefixes changed to a path that includes the Indian AS 9498 between 08:58 UTC and 09:14 UTC.
Let’s take a look at an example. In my case www.google.com resolves to the following addresses:
www.google.com has address 74.125.226.19
www.google.com has address 74.125.226.20
www.google.com has address 74.125.226.17
www.google.com has address 74.125.226.16
www.google.com has address 74.125.226.18
www.google.com has IPv6 address 2607:f8b0:4006:806::1014
The IPv4 addresses are all in the 74.125.226.0/24 range. If we now look at the BGP announcements for that Continue reading
Reducing BGP SNMP Traps in DMVPN Networks
One of my readers decided to build a large DMVPN network with BGP as the WAN routing protocol (good choice!) and configured BGP SNMP traps with snmp-server enable traps bgp command on the hub router to detect spoke router failures. Turns out that’s not exactly a good idea.
Read more ...What is your opinion about the new blog design ?
As you might notice I changed the blog design, and I want your feedback about the new design from all the points (speed, simplicity, look and feel,etc…). Your suggestion and feedback is highly appreciated to enhance the blog. Did you like it ? Was the old design better ? Based on the comments we will… Read More »
The post What is your opinion about the new blog design ? appeared first on Network Design and Architecture.
Networks! Now, With More DevOps!
TL;DR – buzzwords suck and I want to rant about that.
I’ve been doing a lot of posts lately on the skillsets and technologies needed to move networking into the same level of productivity that other disciplines have reached. During this process, I’ve had time to contemplate labels and buzzwords.
By itself, I don’t see much value in the term “DevOps”, whether it’s succeeded by the phrase “for networking” or not. These days, the person using this term might just mean “automation”, or be describing a technical position.
As in “We’re looking for an experienced DevOp.” I know, right?
Just today I heard yet another story that illustrated a total misuse of this term, undoubtedly confusing all involved. I say, what’s in a name?
DevOps For Networks
This leads me down the path of considering that the phrase “DevOps for networking” is just as useless. Although I’m sure this was certainly not intended, this phrase implies that there is a special sector of the DevOps movement that is specific to networking. Unless you’re focusing on specific tools (which you shouldn’t be) then this isn’t the case. The underlying business value is precisely the same.
The DevOps culture and tooling that came Continue reading
Networks! Now, With More DevOps!
TL;DR - buzzwords suck and I want to rant about that.
I’ve been doing a lot of posts lately on the skillsets and technologies needed to move networking into the same level of productivity that other disciplines have reached. During this process, I’ve had time to contemplate labels and buzzwords.
By itself, I don’t see much value in the term “DevOps”, whether it’s succeeded by the phrase “for networking” or not. These days, the person using this term might just mean “automation”, or be describing a technical position.
As in “We’re looking for an experienced DevOp.” I know, right?
Just today I heard yet another story that illustrated a total misuse of this term, undoubtedly confusing all involved. I say, what’s in a name?
DevOps For Networks
This leads me down the path of considering that the phrase “DevOps for networking” is just as useless. Although I’m sure this was certainly not intended, this phrase implies that there is a special sector of the DevOps movement that is specific to networking. Unless you’re focusing on specific tools (which you shouldn’t be) then this isn’t the case. The underlying business value is precisely the same.
The DevOps culture and tooling that came Continue reading
Introducing New VCE VxBlock Systems with Integrated VMware NSX
Last month, we outlined VMware’s vision for helping customers achieve one cloud for any application and any device. We believe the prevailing
The EMC Federation
model for cloud adoption will be the hybrid cloud, and the best architecture for achieving the hybrid cloud is through a software-defined data center architecture.
The fastest path to building reliable infrastructure for the hybrid cloud is through the use of converged infrastructure systems, and no company has been more successful at delivering on the promise of converged infrastructure than our partner VCE.
Now, the ability to procure and deploy the VMware NSX network virtualization platform with VCE converged infrastructure is about to get whole lot easier.
Today, VCE launched VCE VxBlock Systems, a new family of converged infrastructure systems that will factory-integrate VMware NSX for software-defined data center deployments. The new VxBlock Systems will include VCE pre-integration, pre-testing and pre-validation of VMware NSX, with seamless component-level updates, ongoing lifecycle assurance, and unified single-call support from VCE.
As I wrote previously, VMware NSX already runs great on existing Vblock Systems. Customers today are deploying VMware NSX with their existing Vblocks, and customers will be able to extend VMware NSX environments across their entire Continue reading