Application Person: Hey Chris, what's up with the network? My application isn't receiving any traffic.In the end, it turns out that the network was operating perfectly fine. The requested traffic was being delivered to the server, on the interface that requested it. It was the routing table within the Linux host that was screwed up.
Me: Um... The routers indicate they're sending it to you. The L3 forwarding counters are clicking. The L2 gear indicates it has un-filtered all of the ports between the router and your access port. Are you sure?
Application Person: My application says it's not arriving.
Me: I now have tcpdump running on your server. The traffic is arriving. Here are the packets. Do they look okay?
You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case.
Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept – because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline. “You mean I can program my network device directly?” Network programmability.
I was inspired by a thread that my friend Josh kicked off with this tweet:
I am far from being a dev but I am no longer scared to learn to code. Thanks to the folks helping me start to get it.
— joshobrien77 (@joshobrien77) April 23, 2015
An interesting dialogue followed, and I felt compelled to address the problem caused by marketing departments muddying the waters of what would otherwise be a very simple idea.
Now obviously it’s too late to “right the wrong” that resulted from marketing and journalism engines chugging at full steam trying Continue reading
You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case.
Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept - because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline. “You mean I can program my network device directly?” Network programmability.
I was inspired by a thread that my friend Josh kicked off with this tweet:
I am far from being a dev but I am no longer scared to learn to code. Thanks to the folks helping me start to get it.
— joshobrien77 (@joshobrien77) April 23, 2015
An interesting dialogue followed, and I felt compelled to address the problem caused by marketing departments muddying the waters of what would otherwise be a very simple idea.
Now obviously it’s too late to “right the wrong” that resulted from marketing and journalism engines chugging at full steam trying to make every technical term and phrase utterly useless. However, I would like Continue reading
HP Networking's Juliano Forti & Chris Young talk with Greg Ferro and Ethan Banks about how HP handles BYOD through integration with HP's Intelligent Management Center platform.
The post Show 235 – HP IMC BYOD Solution – Sponsored appeared first on Packet Pushers Podcast and was written by Ethan Banks.
I got caught out by Check Point’s “Install On” column recently. Most people don’t need this setting any more, but it’s still there for legacy reasons. Time to re-evaluate.
When you create a firewall policy using Check Point, you define the set of possible installation targets. That is, the firewalls that this policy may be installed on. When you compile & install policy, you can choose from this list of targets, and only this list.
Most organisations will only have one installation target per policy. But sometimes you want to have the same policy on multiple firewalls. This is pretty easy to do, and might make sense if you have many common rules.
But then you say “What if I had 30 common rules, 50 that only applied to firewall A, and another 50 that only applied to firewall B?” That’s where people start using the “Install On” column. This lets you define at a Continue reading
One of the topics I discussed in the IPv6 High Availability webinar is the problem of dual-stack deployments – what do you do when the end-to-end path for one of the protocol stacks breaks down. Happy eyeballs is one of the solutions, as is IPv6-only data center (Facebook is moving in that direction really fast). For more details, watch the short End-to-End High Availability in Dual Stack Networks demo video.
Software Defined Wide Area Networking (SD-WAN) is bubbling up to be one of the prime use cases of SDN. The vendors that fall into the SD-WAN bucket often include Glue Networks, Nuage, Viptela, CloudGenix, VeloCloud, etc. As you dive into each of the solutions from the vendors, you may realize that some are truly unique technologically and some may just be offering a better way to manage existing wide area networking equipment (which is still a huge value add).
In this post, I’m going to give some background on what is driving me to deploy an SD-WAN solution. Follow up posts will cover the deployment a bit more technically.
Since I now have equipment in a colo, moved into a new office, and of course, have the home office, I figured it may be a good idea to look at some of these SD-WAN technologies. In reality, my requirements have a mobile 4th site too that will be used when doing consulting and training onsite at customers to give dynamic site to site access just back to the colo.
To be perfectly honest, I didn’t have strict requirements – they are probably equivalent to those of a small IT Continue reading