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 to make every technical term and phrase utterly useless. However, I would like 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 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.