Calculating burst size for class-of-service

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

Halloween Career Advice from the Damned

“Now, as you look through this document you’ll see that I’ve underlined all the major decisions I ever made to make them stand out. They’re all indexed and cross-referenced. See? All I can suggest is that if you take decisions that are exactly opposite to the sort of decisions that I’ve taken, then maybe you […]

Author information

Glen Kemp

Professional Services Consultant at Fortinet, Inc

Professional Services Consultant. Designing & deploying “keep the bad guys out” technologies. Delivering elephants and not hunting unicorns.

Please free to add me on , follow me on Twitter or check out my other blogs on Fortinet Blog, sslboy.net and SearchNetworking.

TwitterGoogle+

The post Halloween Career Advice from the Damned appeared first on Packet Pushers Podcast and was written by Glen Kemp.

PDU-12C

"After all, what's the best part of Halloween?" Jimmy pleaded over the phone. He was trying yet again to convince Tom to skip work for the night and head over to the party he was throwing. Tom and Jimmy were good friends, but he already knew how the conversation was going to end.

"I dunno, the candy?" Tom played dumb.

"No, the eye candy! I'm telling you bro, you don't want to miss it. Rachel will be there." Jimmy sang the last bit tauntingly.

"I told you," Tom countered. "I've got work." It was around 6pm now, and he was just pulling into the parking lot outside the data center where he planned to spend the night recabling several racks of equipment. The scariest part of his Halloween would be picking through years' worth of undressed patch cabling.

"I don't get why you have to do that shit at night anyway. Why can't you do it during the day when you're stuck at work anyway?" Jimmy prodded.

Tom parked across from the building's entrance and turned off his car. Other than a couple vehicle belonging to the operations staff, the parking lot was deserted. He Continue reading

Happy Tenth Anniversary Arista Networks!

Every year at Arista has been filled with milestones and enriching memories. I want to acknowledge and thank each and every Arista well-wisher for contributing to this incredible experience. So let’s take a walk together down memory lane and look back on our journey from start-up to a now public company. I think of Arista’s first decade as being comprised of three phases:

2004+ Our Humble Beginnings:

Funded in a unique fashion, without traditional venture capital investment, Arista (first called Arastra, located on Arastradero road in Palo Alto) was placed in a unique position. Our founders, Andy and David, were our funders, too, and they cared deeply about building the company with the right technology foundation. Ken Duda, also a founder and our EOS software genius, brought a radical, resilient and programmable network-OS for modern, disruptive applications. Bringing some of the best and brightest engineering minds together resulted in an innovative network-wide operating system that challenged legacy enterprise switching vendors. Andy Bechtolsheim and I launched the company officially in October 2008. With just 50 engineers we gained 50 customers by the end of 2008, proving what small focused teams could accomplish. Our early adopters welcomed us as a breath of Continue reading

Show 210 – SPB Implementation Fundamentals

Dominik and Ricki Cook join Packet Pushers Greg Ferro and Ethan Banks in a hands-on exploration of Shortest Path Bridging, IEEE 802.1aq. Most of us have had our hands on Avaya gear that does SPB — Ethan in the lab, and Dominik + Ricki in production environments. We go through the basic goals, setup, and commands […]

Author information

Ethan Banks

Co-host at Packet Pushers

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
TwitterGoogle+LinkedIn

The post Show 210 – SPB Implementation Fundamentals appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Ruckus Wireless User? Here’s your OS X Yosemite Warning.

A quick post today. As you may recall, I run two Ruckus Wireless APs at home – a Zoneflex 7982 AP and a Zoneflex 7363 AP managed by a Zone Director 1106. The ZF7982 and ZD1106 were provided courtesy of Ruckus … Continue reading →

If you liked this post, please do click through to the source at Ruckus Wireless User? Here’s your OS X Yosemite Warning. and give me a share/like. Thank you!

Take a break and watch two recent engineering talks

Recently, I spoke at the dotGo 2014 conference in Paris and my colleague (and creator of OpenResty) Yichun Zhang spoke at the first NGINX conference in San Francisco.

If you need to take a break, go grab a drink and enjoy one of these two talks.

The Latest and Greatest from ngx_lua: New Features & Tools

Tired of writing NGINX C-modules or setting-up back-end application servers? The ngx_lua module was created to save time and pain, while opening up new possibilities in the world of NGINX. The ngx_lua module embeds the Lua dynamic language into the NGINX core, turning NGINX into a highly scriptable proxy server. Many use it as a non-blocking full-stack web application server as well--also known as OpenResty.

Led by ngx_lua co-creator and sole-maintainer, CloudFlare’s Yichun Zhang, this presentation will introduce all the latest features implemented in the ngx_lua module as well as other new tools. Yichun will focus on features including: light threads, websockets, timers, NGINX worker initialization hooks, SSL/TLS coroutine-based sockets (or “cosockets”), full-duplex cosockets and more.

. .

The session wraps-up covering new advanced tools to troubleshoot and profile ngx_lua-based systems including dynamic tracing utilities based on Systemtap and GDB extension commands.

I came for the Continue reading

The Power of Correlated Visualization

I am sure our work environment is not all that different from many others. There are large whiteboards everywhere and you cannot find a meeting room that does not have circles, lines and squares drawn on them. Some of our favorite bloggers have written blogs about network drawing tools and aids. Probably not restricted to just networking folks, but we certainly love to visualize the things we do. Out of all the customers I have visited, the amount of them where one of us did not end up on a whiteboard can probably be counted on one hand.

It is not surprising that we are drawn to diagrams of the networks we have created. We build our network one device at a time, then use network links to connect the next and on we go until our network is complete. Which of course it never is. To track how we have connected all our devices we need diagrams. They tell us what devices we have, how they are attached to each other, how they are addressed and what protocols we have used to govern their connectivity. They are multi layered and the layers are semi independent.

I have previously said Continue reading

Overlay-to-Underlay Network Interactions: Document Your Hidden Assumptions

If you listen to the marketing departments of overlay virtual networking vendors, it looks like the world is a simple place: you deploy their solution on top of any IP fabric, and it all works.

You’ll hear a totally different story from the physical hardware vendors: they’ll happily serve you a healthy portion of FUD, hoping you swallow it whole, and describe in gory details all the mishaps you might encounter on your virtualization quest.

The funny thing is they’re all right (not to mention the really fun part when FUDders change sides ;).

Read more ...

Case Study: Tradesy and Ansible

tradesy-logo

We've just completed another new Ansible case study; Tradesy. Tradesy is an online consignment store where people can offer their fashion and accessories for resale. 

Tradesy had been doing everything by hand until making a move to use Ansible Tower in an effort to automate as many things as they could.

Continue reading

Junosphere Bugbears

I’ve always thought Junosphere was great, and it certainly makes setting up test scenarios really really easy.  However there are a few things that really niggle when using it.  They don’t seem to be getting much better, which makes me wonder if there’s much development work going on with the platform.  Messages to the “junosphere-contactme” email address given get no reply.

Anyway, here’s the list of niggles:

1. Sometimes MXes start up with their management IP address in the wrong place – see this post.

2. If you have a saved set of configs for Junosphere which you import from your hard disk, it doesn’t create a network diagram.

3. Topmost annoyance: every time you start up your topology the routers get different IP addresses.  Argh.

4. To edit a predefined config for a device, you have to stop the whole topology.   This makes setting up topologies for training courses quite a laborious process because the routers take such a long time to start up and shut down while you try to get the base config right.

5. It would be really nice to have the IP addresses and console addresses as hyperlinks you could Continue reading

MXes in Junosphere

MXes in Junosphere are unsupported, but I tend to use them because I want something a bit closer to the real thing somehow.  The VJX is ok, but I like the way the MX doesn’t come with any security-related stuff, and the interfaces start at ge-0/0/0 rather than ge-0/0/1!

The only downside with the virtual MX is that it is a non-supported image, unlike the VJX.

Sometimes when usign an VMX, you find that the topology starts up but you can’t SSH to one or two of the nodes.   So you console onto it and discover that (for some reason) the management IP address has been put onto em0 rather than being where it should be in the member0 group applied to fxp0:

root@S1> show configuration groups member0
system {
    host-name S1;
    backup-router 10.233.255.254;
}
interfaces {
    fxp0 {
        unit 0 {
            family inet;    <=== IP address missing!
        }
    }
}

root@S1> show configuration interfaces em0
unit 0 {
    family inet {
        address 10.233.248.46/20;  <== Here it is.
    }
}

The solution to this is to console onto the device and move Continue reading

1 … 3,651 3,652 3,653 3,654 3,655 … 3,807