This is a continuation from last week’s post on provider peering streams. Second Example: Customer to Noncustomer Assume traffic is coming in from A and is destined to M. How can AS64501 maximize revenue stream in this situation? There is only place to make money (the [A,C] link), and there is one place where its […]
It doesn’t make sense to build a new data center network to support legacy bare-metal server infrastructure. You’ll have to use relatively expensive 1G/10G ports to be able to connect the current and future servers, and once the server and virtualization engineers wake up and do hardware refresh you’ll end up with way too many ports (oh, and you do know that transceivers could cost more than the switching hardware, right?).
Read more ...BYOD policies sound alluring. No more forced use of a crappy old corporate laptop – “hey look, we’ll let you choose whatever you want!” But I think it is a way to shift the cost burden over to employees. It will be done slowly, over several years, and we’ll welcome it. But it will lead to employees carrying more costs. I guess we should be careful with what we wish for.
In my teens I spent many years working in the produce & butchery departments at a local supermarket. When I started out, the contracts still had the last vestiges of union-dominated times. So we got paid allowances for laundry, extra allowances if we’d passed some school exams, higher rates for overtime, meal allowances, etc. During the years I was there, these were eroded. Each year they gave us pay rises that were nominally higher than inflation, and yet another allowance was ‘incorporated’ into my wages. Sometimes allowances would remain for older employees. When I left, I was being paid significantly more than new employees, in part because I still had several extra allowances.
I think we’ll see the same thing with BYOD programs. I think it will go like this:
Someone recently asked me to be a professional mentor, an occurrence that becomes more surreal the longer I consider it in its implications and entirety. So far the recipient of my educational transgressions appears content, but the experience has reminded me of several ranty moments I’ve had over the years regarding what new network geeks […]
The post Helpful Concepts for the Fresh New Geek appeared first on Packet Pushers Podcast and was written by Keith Tokash.
About a week ago, I took my wife’s van to the shop. The main issue was it was making a popping noise in the front end. I only observed the noise when steering sharply and the vehicle was in motion. Typically this occurred when parking. Although I was nearly certain this was an issue with a CV joint, I only told the mechanic about the symptoms we had observed.
The reason I didn’t lead the conversation to the CV joint is that I wanted the mechanic to look at the problem objectively. I knew he was the expert and I wanted him to solve the problem instead of replacing a part. In order to shift the responsibility, I needed the mechanic to diagnose the problem and create a plan of action.
At this point in my career, I have worked in various areas of technology. Over the years, I’ve had customers that tell me exactly what they think they need. In some cases, they’re correct. However, there are times that their solution does not fully solve the problem they are observing. On the other hand, some customers take a smarter approach and explain the problem they are trying to solve.
When Continue reading
Today’s Secret Sunday is a shout out to the excellent Jeff Fry, aka @FryGuy_PA on Twitter. Jeff blogs at FryGuy.net where among other things he has previously broken the news on upcoming Cisco products a couple of times by close … Continue reading
If you liked this post, please do click through to the source at Secret Sunday – Jeff Fry and give me a share/like. Thank you!
If you’re just starting out working with ‘Enterprise’ products, you may not have come across Support Lifecycles. It’s important to know what these are, and how it affects you. They can have both a positive & a negative impact on when and why you choose to upgrade systems.
Developers would like to only support the latest version. But customers can’t/won’t always run the latest version. They need to know that they can expect a certain level of support for the version they’re running. As a compromise, software vendors will publish a support lifecycle policy. This will outline the levels of support a product gets, from new product introduction, through to being superceded, and finally moved to end of support. Typical phases include:
This stuff still totally blows my mind. I was at a restaurant for lunch recently with some colleagues. Service was slow, and as a result I was going to be late back to the office, and I had to join a … Continue reading
If you liked this post, please do click through to the source at Lync – This Still Blows My Mind and give me a share/like. Thank you!
Continuing our regular look at the news in Networking and Cloud.
The post Network Break 19 appeared first on Packet Pushers Podcast and was written by Greg Ferro.
Shellshock was released a little over a month ago, to wide predictions of doom & gloom. But somehow the Internet survived, and we lurch on towards the next crisis. I recently gave a talk about Shellshock, the fallout, and some thoughts on wider implications and the future. The talk wasn’t recorded, so here’s a summary of what was discussed.
Attend enough meetings, and sooner or later you’ll be called upon to present. I was ‘volunteered’ to speak on Shellshock, about a month after the exploit was made public. I didn’t talk about the technical aspects of the exploit itself – instead I explored some of the wider implications, and industry trends. I felt the talk went well, mainly because it wasn’t just me talking: everyone got involved and contributed to the discussion. It would be a bit Continue reading
.JPG)
package main
import ("fmt")
func HelloWorld() {
fmt.Println("Welcome to my blogn")
}
We are getting into the Halloween spirit here at Plexxi—check out this Plexxi pumpkin carved by our talented marketing manager, Khoa Ma!
Jack-o-lanterns aside, we know the thought of navigating trends like the Internet of Things and Big Data can be frightening, especially if you are unsure of how to approach them. As these trends gain popularity and deployments increase, IT architects often worry about increased activity on already taxed infrastructures. Our own Mike Bushong is our resident expert on this topic and he penned an interesting blog post this week on networking’s atomic unit and “going small to scale up.” Creating smaller units of capacity makes the network easier to manage, and most importantly, scale. It’s definitely worth a read before heading out to trick-or-treat.
In this week’s PlexxiTube of the week, Dan Backman explains failure scenarios in case of hardware or software outages in a Plexxi pod design.
Network architect Brian Heder contributed an article to Network World this week on the importance and challenges of simplicity in computer network design. While I think Heder’s list is solid, I would add an additional obstacle to network simplicity: customization. Avoid making your network environment Continue reading
The rise of software licensing in networking changes some of my assumptions about the 5 year cost of ownership of products. Roughly, lets assume that you are buying virtual appliances like firewalls, DNS/DHCP, IDS/IPS, proxy servers and load balancers and that you pay some type of yearly license to use the product. Capital Upfront The legacy […]
The post Musing: Subscription License Economics appeared first on EtherealMind.
Burst sizes need to be calculated if you are implementing policers or shapers on Junos devices so that the policer or shaper can control the flow of traffic appropriately. Too small a burst size and TCP applications will have terrible throughput. Too large a burst size and the policer won’t be very effective – the bursts are so large they cancel out the effect of the policing because as one burst ends another one is just about to begin.
The situation is described reasonably well on the Juniper site here, and also in O’Reilly’s excellent MX book. But in both places the mathematics of the calculation is hidden in a paragraph of text – not written out properly and showing the workings. That makes for confusion in my mind.
It’s actually a fairly easy calculation, but isn’t presented well. I finally sat down to work out what it meant.
The easy way to calculate burst size for low bandwidth (i.e. T1/E1 etc) interfaces is 10 times the MTU of the interface. The problem with this is (as you see in figure 3 in the Juniper link above) that on 1500-byte Ethernet this Continue reading