SDN Terminology from Layered Models
Even though we don’t build networks with OSI products, we still use terms from the OSI model. What terms will we end up using for SDN, once the dust settles?
The previous post introduced one document that attempts to define terms and architecture, and today’s post introduces another: the ITU-T Y.3300 document. But how do these documents fit in with our fast-changing networking landscape – and what words should we use? Today’s post looks at the Y.3300 doc, and explores a few of the terms.
Other posts in this series:
Big Picture First: ITU-T Y-Series
Most of us don’t have a reason to read docs from standards bodies unless we’re looking for a particular standard or fact. But as long as we’re talking about one doc from the ITU-T Y-series, it’s worth a minute to set the context of what these documents are.
First off, the topic area for the Y-series is broad, but it’s all networking! The title for the ITU-T’s Y-series of documents spells out the big items:
Global information infrastructure, Internet protocol aspects and next-generation networks
Great, so the topic is global network, IP, including next-generation networks. It’s networking! Continue reading
Diving into the DNS
The turning of the DNS from a distributed database query tool into a malicious weapon in the cyber warfare arena has had profound impacts on the thinking about the DNS. I remember hearing the rallying cry some years back: “Lets all work together to find all these open resolvers and shut them down!” These days I don't hear that any more. It seems that, like SPAM in email, we’ve quietly given up on eradication, and are now focusing on how to preserve service in a toxic world. I suppose that this is yet another clear case of markets in action – there is no money in eradication, but there is money in meeting a customer’s requirement to allow their service to work under any circumstances. We’ve changed our self-perception from being the public DNS police to private mercenaries who work diligently to protect the interests of our paying customers. We are being paid to care about the victim, not to catch the attacker or even to prevent the attack.Reinventing CLNS with L3-only Forwarding
Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:
What you describe is literally intra-area routing in CLNS.
He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).
Read more ...Connecting NXOS VIRL instance to Arista vEoS
In this blog, I will cover the steps that I did to connect Cisco NXOS VIRL switch instance to Arista vEoS switch instance. We can connect any Cisco switch simulated in VIRL, I just picked the NXOS switch type. CML/VIRL supports majority of Cisco switches as VM as well as few external switches from Juniper, … Continue reading Connecting NXOS VIRL instance to Arista vEoS
Cisco NXAPI with VIRL
In this blog, I will cover the steps to get NXAPI working with NXOS image in VIRL. For more details on CML/VIRL, please refer to my earlier blog series. Running NXAPI with VIRL image makes it easy to write automation scripts without needing a physical switch. Earlier, I had installed VIRL February release(0.9.17) which included … Continue reading Cisco NXAPI with VIRL
Vapor IO Takes Data Center Disaggregation a Step Further
Everything else is getting opened up — how about rack management?
SDN: Integration over Manipulation
I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.SDN: Integration over Manipulation
I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.ONUG Spring 2015
I’ll continue to update this throughout the next two days. Feel free to issue a pull request if you’re also here at the conference and want to add to this post.
General
Location: Open Networking User Group (ONUG) at Columbia University
ONUG currently has 6 working groups:
- NSV
- SD-WAN
- Virtual Network Overlays
- Common Management tools across network, compute, and storage
- Network State Collection, correlation, and analytics
- Traffic Monitoring and Visibility
It is interesting and awesome to see that half of the working groups are all about Day 2 operations and management of networks. This is exactly what’s needed in the industry.
Sessions
Creating Business Value with Cloud Infrastructure
Speaker: Adrian Cockcroft
- Developers don’t need any of that referring to NSV/NFV.
- 2009 developed the Cloudicorn, took knowledge gained to Battery
- Docker wasn’t on anyone’s roadmap for 2014. It’s on everyone’s roadmap for 2015
- 2014 was the year that Enterpises finally embraced cloud and DevOps
- Optimizing from IT cost to delivery and speed - Nordstrom - ended up yielding lower costs
- Product IT reports into the business
- Director is the highest Corp IT title
- Immutable microservice deployments scales
- If your QA team is saying there are too many bugs in a release, Continue reading
Ansible Tower Now Available with Vagrant
Ansible is about simple, yet powerful automation. We want to make automation easy for everyone to learn, use, and deploy, for developers, system administrators, and operators of every skill level.
Every day we hear the success stories of people who have been able to take Ansible’s powerful automation and use it to cut their IT costs, stabilize their deployments, and allow them to get back to their focus of their job rather than continually grinding through manual tasks.
On top of that, we’ve built Ansible Tower, a web interface and API that brings those same simple principles to applying command, control, and delegation to an Ansible deployment. Customers like Nike, Splunk, Grainger, and others use Tower to centralize their Ansible deployment, delegate credentials and tasks to users in a controlled manner, and allow easy self-service access to users without them knowing the specifics of those automation.
We’re always interested in making things simpler for our users, and this extends to deploying and trying Tower as well. That’s why we’ve decided to make Tower available for use with Vagrant - what’s simpler than that?
You can try out Ansible Tower in Vagrant with just a few commands.
$ vagrant init tower
F5 APM, SRX and DTLS NAT Timeout
I have been having issues using the F5 APM client behind a Juniper SRX-110 using hide NAT. I believe I’ve tracked it down to the default timeout settings used for UDP services. Here’s what I did to resolve it.
Constant Connection Timeouts
The laptop client was behind the SRX-110, using hide NAT. The initial client connection would work, and things would look good for a while. The the client would stop receiving packets. Traffic graphs would show a little bit of outbound traffic, and nothing inbound. Eventually, the client might decide it needed to reconnect. But usually, it would sit there for a few minutes doing nothing. Then I would force a disconnect, which would take a while, and then reconnect. Exceedingly frustrating.
Connecting the client to a different network – e.g. using a phone hotspot – worked fine. No dropouts. Using a wired connection behind the SRX had the same issue. So clearly the problem was related to the SRX.
TLS & DTLS
I dug into the traffic flows to better understand what was going on. This SSL VPN solution makes an initial TLS connection using TCP 443. It then switches over to DTLS using UDP 4433 for ongoing encrypted Continue reading