Earlier this month, I attended Networking Field Day 13, where we heard from VeloCloud on their SD-WAN solution. Their presentation and case study got me thinking about how most businesses will consume SD-WAN and where business customers may fall on the “Buy” vs. “Build” spectrum.
Herding Packets
Days in the life of a professional packet shepherd.
Category Archives: Uncategorized
Performing Ping Sweeps with IOS TclSh
It’s been a while since I’ve gotten a blog post up, but with my CCIE recertification out of the way I’m hoping to ramp some volume back up. We’re talking about some sexy stuff today… Ping sweeps! First off, let’s cover why you’d need to sweep up your pings. Some people use the ping sweep as a means to “find” hosts on the network. The problem with this is, devices with host-based firewalls active may not respond to an ICMP ping. If you’re pinging from off the local subnet, there are other reasons you might not get a response back as well, like a host having a mis-programmed default gateway or subnet mask, or an interface ACL on the routing device. That said, ping sweeps are still incredibly useful for helping to find vacant IP addresses on a LAN. Or, at least, IP addresses that are not currently active. Always consult your properly maintained IP documentation to find IPs you can safely use for new deployments (yes, I’m laughing at that one too…).
Using EEM to Remotely Change a WAN IP – Part 2
In my last EEM post I provided a simple means to change an IP address and default route of a Cisco router using a script that makes the change without requiring interactive user input. This is helpful if you are remotely changing a device’s WAN/Internet IP and waiting for some on-site hands to move a cable over to a new ISP or WAN SP connection. That first script, however, would make the change and then exit. What would happen if the new Internet connection had a problem, or the on-site help couldn’t move the cable for some reason? Proper testing and preparation should help you avoid most of those issues but you just never know.
Dell Aims for the Clouds with Z9500 Spine
While at Networking Field Day 7, we got a small preview of a new switch Dell Networking has just announced, the Z9500. At some point I’ll have another post coming discussing more of Dell’s presentation at NFD7, but I wanted to briefly talk about this new product and what it brings to the table for Dell.
Goodbye Snowpocalypse, Hello Networking Field Day 7!
It’s been a long winter here in Pennsylvania. Near record-breaking for snowfall. But yesterday I traveled to beautiful and temperate San Jose to attend Networking Field Day 7!
I’m honored to have been selected as a delegate for another Tech Field Day event, as these events are a fantastic opportunity to engage with vendors and industry peers. I use the term “peers” only because we work in the same industry. Everyone else is smarter than me.
I’m excited to rub elbows and network with the exceptional delegate list. I have met nearly all of this event’s delegates before and I respect the expertise and experience of every single participant. I feel I have learned so much and made so many valuable connections through TFD events and I’m grateful to Gestalt IT and the TFD community for another opportunity to participate.
Most of all, I’m excited for the opportunity to represent you, the networking/IT community at large. Asking the questions you would ask. I will be live Tweeting during the presentations, so direct your questions my way and I’ll do my best to ask your questions if I miss something you want to know about.
Sponsors
I was going to mention each of the presenting vendors and what of theirs I was interested in learning more about, but after reviewing the list I realized I’m very exited to hear from each of them. Some of these vendors hadn’t struck me as big SDN players, but really each of the “traditional” network equipment vendors (that includes Avaya, Brocade, Dell, Extreme, and Juniper) touts a complete SDN strategy on their website. I’m looking forward to learning more about each vendor’s strategy and what differentiates their approaches.
There will also be a couple of the startup vendors, Plexxi which is on the leading edge of cloud-scale data center networks and automation, and Pluribus Networks who will be giving us detail on their NetVisor network virtualization platform and their Freedom Server-Switch product line. Both should prove very interesting.
Finally, we’ll hear from Tail-F Systems about their vendor-agnostic network controller product, and the recently re-branded LiveAction to talk to us about network monitoring and quality measurement.
I do hope to see at least some discussion of non-datacenter networking as well. SDN can have applicability outside the datacenter, and I build more general enterprise networks with small/medium data center blocks than I do large-scale data centers that fully implement an end-to-end automated, SDN architecture.
My Perspective
Like many in the networking field, I’m looking toward the future (SDN, cloud, automation, and the like) but I’m also mindful of the gap we need to bridge to get there. I work on real networks every day, most of which are not greenfield, pie-in-the-sky SDN datacenters, so I want to learn how the new technologies these vendors are bringing forward are applicable to the real world of grey-field operational networks.
I work on mostly small to mid-sized enterprise networks with anything from very simplistic to moderately complex data center needs. I don’t build cloud-scale data centers or work on huge Internet property environments so my focus is on using technology to help businesses of all sizes gain a competitive advantage whether it’s through new feature/function or reduced operational burden. I’ll be considering the sponsor presentations through that lens all week.
Overall, I’m looking forward to a great and exhausting week. Please be sure to tune into the live streams of the NFD presentations and watch the #NFD7 hashtag on Twitter to join in the conversation.
TCP Toddlers and Protocol Evolution
Just the other day, I quipped on Twitter that my children’s behavior reminded me of TCP:
My children are an excellent demonstration of TCP. They just keep retransmitting until I acknowledge them.
— Bob McCouch (@BobMcCouch) March 2, 2013
Specifically my 3-year old daughter will just keep “retransmitting” her message until she’s acknowledged, even if her message isn’t a query that requires response. Moreover, both my children, around that 3 year-old range, seemed to practically require a full echo for acknowledgement. For example:
Daughter: “I see an airplane!”
Me:[no response] (After all, I’m a classic introvert and don’t feel that every statement requires explicit response)
Daughter: “I see an airplane!”
Me: “Cool!”
Daughter: “I see an airplane!”
Me: “OK, you see an airplane.”
And finally, that moves us past the airplane incident. She will just keep retransmitting until I acknowledge not only that I received a message from her, but until I confirm that I received the specific message she sent.
This behavior must be common, because in response to my tweet, @Ryan_Frantz linked me to his blog post from last year noting the exact same thing. Additionally, my tweet received some 45 retweets from other network goons (I mean the term “goons” in the nicest possible way).
As both Ryan and I noted, this behavior is very reminiscent of TCP’s reliable transmission mechanism where data is sent by one TCP stack, and must be acknowledged (including an indicator of just which data was received) by the other or else the data will be repeatedly resent until the sender receives acknowledgement from it (or a connection termination which might be equivalent to me barking “HUSH!” at my daughter). TCP doesn’t fully echo the sent data, of course, but you get the idea…
OK, so cute observation, Twitter gets a chuckle, that’s it, right? Maybe not. I got thinking about it. Why does my 3 year-old behave that way, while my 5 year-old no longer does? I think the answer is probably development of the human communications protocols. As children grow, they learn that not every message needs explicit, positive acknowledgment. Sometimes the acknowledgement is more subtle, based on some other response like an “mmmhmm” or a chuckle. These reactions still indicate the message was received and the response, evaluated in context of the original statement, helps us determine whether our original message was correctly received or requires retransmission. Perhaps this can be thought of as providing a periodic checksum of received data rather than a full echo.
When we really expect a response to our statement, we intone it as a question, which we then anticipate the our receiver will correctly understand and provide us our response. Does this sometimes fail? Of course. But if it works 99% of the time, we are saving communications overhead 99% of the time.
I started Googling around to see if I was on to something and the best thing I found was SCTP, a protocol I’d heard of before but knew was not in wide use. It does incorporate the idea of blending reliable, ordered, TCP-like transmission with an option for less-ordered, un-reliable UDP-like transmission. That’s a start, but might it be possible to further extend/enhance protocols like these to actually be able to signal whether or not message confirmation is required on a per-message or per-window basis? Or add predictive capability based on expected responses at the protocol or application layer? Or add the protocol equivalent of inflection to easily frame a message as a query which requires response, a statement for which a acknowledgement is optional or perhaps occasional, aggregated ACK is appreciated, or an exclamation for which quick action is more important than a response (“DUCK!”)?
Elements of all of these ideas exist in currently deployed protocols, but I am interested to see what happens with protocol design over the next decade or two as rapid advancements in artificial intelligence, computer learning, and neural networks might allow computers to think more like humans and even make their conversations more human-like.
Like many highly technical, introverted people, I have always thought tricky interaction with other humans would be a lot less error-prone if it adhered to rigid rules like a network transmission protocol (and it would be), but this little observation has gotten also me wondering if perhaps computer communication could be made more efficient and ultimately more effective if it were modeled more closely against human communication.
Herding Packets 