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.
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?
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
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?
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
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
If you've ever done a traceroute from one IOS box to another, you've undoubtedly seen output like this:
R8# traceroute 192.168.100.7
Tracing the route to 192.168.100.7
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.0.1 4 msec 3 msec 4 msec
2 192.168.100.7 4 msec * 0 msec
That msec * msec output. Why is the middle packet always lost?? And why only on the last hop??
cumulus@wbench:~$ curl http://leaf1:8080/ptmReturns the result:
{
"links": {
"L1": {
"node1": "leaf1",
"node2": "spine1",
"port1": "swp1s0",
"port2": "swp49"
},
...
}
}