Author Archives: Admin

Nice-to-Explore Python URLs

 

It is not easy to start and make when learning and mastering a programming language – even these days with “Mr. Google” who knows is all. The main challenge is to dig up the adequate information for you to learn, understand and assimilate depending on your level of need.

Many of us have some URLs you tend to frequently visit and have them as bookmarks in your mini-URL library. These serve you as your main reference material when needed. Well, below are my top 2 URLs that I have found very useful and which are part of my Python URL library:

Python.org:

By far an without a doubt, this is the main site to keep in your Python bookmarks. It is very extensive, clear and has plenty of “to-the-point” information that all Python programmers need at some point in time.

Python For Fun:

This is Chris Meyers’ URL and I enjoy the clarity and explanations that Chris has put into his Python programming examples. It is a good site for initial and intermediate level challenges.

 

 

…So, seriously… what is a “flow” again ?

Leave a reply

In this new networking era, characterized by the dissemination of concepts such as SDN, automation, X-ops (e.g. DevOps, NetOps, SecOps, etc), it is always good, in fact, critical I would argue, to take time and ponder what some of these commonly used concepts really mean.

Once you start peeling these concepts, you may find that some of those are either old concepts “with new wrapping paper” or incremental variations from old concepts and only occasionally, you are lucky to really find a totally new definition. Those of you who are not new in networking must be nodding your heads in agreement.

However, there are other concepts or definitions which can easily trigger “silent” confusions – those confusions when speakers both believe understand the concept – when in reality, their understandings are different or too general. One of these concepts on top of my list is the definition of flow in networking.

Do you know what a flow is ? — Ohh…that question can make many network engineers, security engineers, system administrators, software engineers, and SDN engineers nod their heads affirmatively and quickly say yes – probably all at once.

Well, a flow is exactly one of those concepts that is ideal for causing undetected confusions. In this blog, I’ll review a few of the different meanings and their applicable context as well as some of the potential “silent” confusions which can derive from these.

Let’s start by checking what “Mr. Google” find for us as answers to the: what is a flow? question:

In Network security, often a flow is defined as the set of packets which satisfies a 5-tuple matching of the packet header fields: Source IP address, Destination IP address, Protocol (these in the IP header), Source Port, and Destination Port (these last two at the TCP or UDP header).

In Ethernet, Network engineers often leverage the IEEE 802.3ad (now IEEE 802.1ax) standard to bundle multiple physical ethernet links and load balance traffic across them. In this context, a flow could mean a set of frames whose following 5-tuple header fields match: SA, DA, protocol, TCP/UDP SA and TCP/UDP DA.

In the RSVP RFC  (RFC 2205), a flow is defined as part of an “RSVP session” which; subsequently, is defined by a set of packets with the following matching triple header fields: IP Destination Address, IP header Protocol ID, and a “generalized” Destination Port. The generalized destination port can be either a UDP/TCP destination port field or another “application-specific” information.

Also in RSVP, there is this concept of “Flowspec” which, along with a filter spec, define a “flow descriptor”. It is this flow descriptor which, along with a session specification, defines a common set of data packets — yes… it defines “the flow” in RSVP.

When using netflow, there definition of flow data can be rather specific. Cisco, as the creator of net flow, originally defined a flow as a unidirectional set of packets matching a set of 7-tuple header fields: Ingress Interface (SNMP ifIndex), Source-IP address, Destination IP address, IP protocol, Source UDP/TCP port, Destination UDP/TCP port, and IP Type of service.  As netflow had additional releases and other versions (e.g. IPFIX) came to the market place, the original concept of a 7-tuple flow definition was abandoned and it gave users freedom to assign the matching fields defining a flow.

When dealing with IPv6 packets, it is entirely possible to define a flow in a unique way given that the IPv6 header field includes a field called: “flow label”. This label technically provides the flexibility to define any set of IPv6 packets to be part of the same “flow” by simply assigning a common value in their IPv6 flow label.
In an SDN Openflow, the matching field of a given flow can technically be any combination from 1-15 fields. An interesting remark is that the ONF’s Openflow standard uses the word “flow” frequently even though it does not explicitly provide its definition.

So, in a nutshell, keep in mind that the concept of flow can be a chameleon in the networking lexicon ecosystem.

 

A Network Engineer’s Hippocratic Oath…

 

Our Networking technology area does not have a widely-accepted, well-known hippocratic oath – and much less a homologous “Hippocrates” representing the moral compass and standard for each action taken.

However, we should consider having one with a good underlying moral fabric:

* Networks should keep clear documentation.

* Network should be designed to first and foremost serve its intended traffic  – not all traffic.

* Networks should be designed with scalability in mind.

* Networks should hold simplicity as one of its major requirements.

* Networks need to support sensible, relevant statistics.

…but how can I deploy OpenFlow in my current Network ?

 

OpenFlow… ahh… that controversial word that has plenty in the industry taking side on whether they are on the “fan” SDN camp or on the “not-important” SDN camp.

For those who are interested in knowing more about how you can get your current network to migrate towards an OpenFlow-driven network, it is important to consider how migrations can take place and who has already done it (so you are not on the “bleeding edge”).

The below is a solutions brief I worked on as part of an ONF team in which the main migration considerations are presented and some prominent use cases are highlighted. This is the link to the solutions brief.

 

Using Junos PyEZ with Xcode 5.1.1

Leave a reply

 

Python has become a sponsored language for automation and scripting for their products by two of the largest vendors: Cisco and Juniper – Kudos to Python! – it is definitely a clear, uncomplicated language to get your programming work done.

However, there is no consensus among Python programmers on what the most convenient Integrated Development Environments (IDE) for your Python needs. Tthere are plenty of of IDE options available – including the very effective option of writing your Python code in a text file, name the file with the .py extension and run it from your terminal using the command: python <filename>.py.

My preference is to leverage Apple’s Xcode as my Python IDE and to use it in my MacAir under MacOS 10.10.3 (Yosemite). So, this post’s purpose is to provide an example of how Xcode can be leverage for Python programming to remotely access a network device, in this case a Juniper Networks’ SRX210.

First, you need to have your Xcode environment installed. I have Xcode 5.1.1 installed in my MacAir. For a URL where the instructions to install Xcode in your Mac Air can be found, click here.

Once your Xcode version is installed, you need to setup Xcode to run Python. This procedure is often convoluted as presented by many sites, but I found the instructions found in this link very clear.

Once you are ready for your Python code, it is required to setup the network device (the SRX210 in this case), to accept remote python scripting. In the Juniper SRX we are using, this is done by activating the Netconf over ssh protocol as shown below:

yardiel@srx-210h-mint# set netconf ssh

[edit system services]

yardiel@srx-210h-mint# commit and-quit

commit complete

Exiting configuration mode

yardiel@srx-210h-mint>

At this point, your Xcode IDE should be ready to run your xcode python code.  Enjoy it.

Yardiel

The ABCs of SDN: A Conversation

Leave a reply

[This is a reproduction of a blog entry from 2013]

Ahh – technology hype can be exciting!

When a technology seems promising and looks like it could deliver a lot of benefits, it can exponentially gain momentum. This momentum can often be gauged by the attention it gets. There are so many tech talks, discussions, seminars panels, experts, forums, white papers and new acronyms (can’t live without them!) being mentioned that it can be a bit hard not to be overwhelmed trying to make sense of it all.

Software-Defined Networking is undoubtedly the latest craze in the networking world for both service providers and enterprises. It seems appropriate to succinctly review some basic concepts being thrown around “on the street” regarding SDN.

To keep it simple, I’ll use a conversation between two colleagues – one well-versed in SDN and one who is just hearing about it – to review the concept of SDN, how it changes the way your network functions and what it can do for your environment.

Here it goes:

J: Hi, Doug. I’m glad I ran into you. I’ve been meaning to start learning more about SDN but I have had no time lately to dedicate to it. So, maybe you can help me get going with a brief overview of SDN while we walk. Is that OK?

D: Hi, John. Certainly.

J: Great. Let me start with the main question: What is this SDN stuff everybody is talking about these days? Google reports plenty of links when searching for definitions of the SDN acronym.

D:  Not surprised. SDN in our field stands for Software-Defined Networking – three letters that represent the new “radical” change that networks are experiencing. You know how network vendors have roadmaps for their products, and they quote them often with new “incremental” features or improvements for their line of products?

J: Yep, I know those roadmaps. Quarterly reviews full of goodies and solutions to come…it is in the next release, etc. etc… Yep, I know.

D: Well, those could be considered “incremental changes” to a given product. SDN is not an incremental change – it is more like a disruptive or radical change. A departure from how networks have been deployed for the last few decades.

J: And what is so “radical” or “disruptive” about it?

D: The radical and disruptive part of SDN to current networks is this: SDN changes how networks have been “controlled” as well as how each “node” (like a router, a switch, a firewall, etc.) has been conceived ever since we can remember. It also changes how networks are to provide services. It still involves both software and hardware but, to use a sports analogy which might work, the software and hardware players on the SDN team are now changing the way they implement their role done given a different, more effective game strategy.

One critical component to the SDN recipe is network programmability. Other components include APIs and network protocols. And yet another is hardware. To achieve network programmability, APIs are needed. To move information across the network, protocols are needed. And even though there is plenty of virtualization going on, hardware in the form of physical nodes and interfaces is still needed.

J: It sounds like there are a lot more components to SDN than the current network designs use. Is it worth it?

D: True, there are more components to SDN which could potentially imply more moving parts and failure points. However, the promise of SDN is that networks can be simpler to use and manage from a user perspective. Keep in mind that users in this case referred mostly to applications – not only humans hacking away at the network – Applications are the “royal family” in the SDN society.

So, the SDN promise is that new services can be created, deleted or updated very quickly (within seconds) and with minimal complexity to the user requesting those services all while still preserving the benefits that networks need to offer – fast failure restoration and reliability and efficiency in moving packets from sources to destinations.

J: Network programmability, eh? How would a network be programmed? Aren’t we programming today via CLI when we configure routers and switches? And haven’t we been programming the network gear for years?

D: Well, yes…but not exactly. What we have been doing is configuring each network node in a network using the vendor’s own operating system for each particular node. Each of the nodes is configured to run available networking protocols. Each node is treated as an independent and standalone system that needs to interact with the other entities in the network. In order to speed up the configuration of each of these nodes, management systems have been used, but these have not been widely adopted for various reasons.

The main difference in the SDN network programmability is that fast, simple commands can be used at some central level and service deployments are successfully completed. This programming is to be flexible enough that it can actually be successfully accomplished by other systems or individuals who may be unfamiliar with networking protocols. To get to this point, the “hardware” involved in the network is being treated not like standalone entities but more like servers waiting for control commands from a higher controller system.

J: I see. So, SDN is not really a protocol but rather more like a systems programming architecture where the network hardware nodes are just one system. What about the API’s component of SDN? What are those for?

D: APIs are well known concepts to system programmers. They are software components defining the data and the conditions under which such data can be properly processed by a given system. Since SDN is a centralized architecture where the network control is now in a different system and outside each of the network nodes (routers, switches, etc.), these systems need to interact among themselves in a cohesive, harmonious manner. The way they interact and exchange information among themselves is via APIs.

J: What are some examples of APIs from SDN?

D: SDN is such an emerging technology in networks that many things are still in the exploration and evaluation phase. APIs are definitely one of the things that SDN adopters will experiment with in the near future. Three API protocols being used are NETCONF, REST and XMPP.

Just to review, NETCONF (Network Configuration Protocol), which surfaced in the mid-2000s, uses XML as its base and uses Remote Procedure Calls (RPCs) for data exchange between two systems. NETCONF runs on top of secured connection protocol such as SSH. REST (Representational State Transfer) uses the main HTTP methods at its core for exchanging information. Lastly, XMPP, also based on XML, is the same protocol used for multi-party chats and instant messaging apps such as Facebook chat and Jabber, and other popular applications such as Twitter also have XMPP-based APIs available for external developers . XML gives a lot of flexibility to APIs given that extensions allow new functionality to be easily created. XML can be mainly seen as a “southbound” API – if we were going to get into API details – which is a great topic to discuss regarding SDN. Also, keep in mind that extensions often mean a lot of flexibility. Remember BGP and MBGP in our networking industry and the value offered by BGP-with-extensions?

J: Yeah, great flexibility based on extending BGP’s attributes… by the way, what about OpenFlow. I usually hear it mentioned along with SDN? What is it?

D: Awesome question. OpenFlow definition has caused quite a bit of confusion in the past. In short, it is one protocol and a component with a specific role in the overall SDN architecture for networks. OpenFlow’s important role in the Open Networking Foundation’s SDN definition, which, in simple terms calls for the separation of control and management functions from the data plane functions. In short, it removes the control functionality from each of the nodes and places this control functionality in a more centralized “server”; arguably, playing a role of traffic director in network elements. Consequently, the network node roles (routers and switches) are essentially in charge of moving bits in and out of them as fast as possible while taking control orders from a higher authority – the controller. This abstraction is brought about by the implementation of the OpenFlow model.

J: Ahh…Got it. That makes OpenFlow like a set of protocols and APIs.

D: hmm… more like a Southbound API.. at least for now…who knows how it will evolve in a few years…

J: Where can I find more info on SDN to start getting deeper into this new… should I say… paradigm?

D: There is plenty of literature out there, and the first few books are starting to make their way to the marketplace. Take a look at Jeff Doyle and Doug Marschke’s book Software Defined Networking: Anatomy of an OpenFlow. They are well-known authors in the networking world, and their years of experience as engineers provide a unique perspective.

J: Thank you for this chat. It gave me a kick start to get me going with SDN.

D: Absolutely. Let me know when you want to get deeper into details.

SDN APIs: A New Vocabulary for Network Engineers ?

Leave a reply

[this is a reprint of a blog entry in 2013 — and it is still applicable ]

Whiteboards and slides have been instrumental for networking discussions for a long time! Color-coding markers and those fancy “glass whiteboards” are awesome tools to have around whenever networking design discussions among network engineers arise.

Most of us are accustomed to quickly convey an idea using rectangles, circles and lines. Cloud pictures, which are almost a must-have in today’s system designs, are great examples of how we abstract or, should I say, hide or assume some concepts in designs. SDN network design diagrams are definitely not an exception in this regard.

SDN whiteboarding sessions often reference APIs, which are usually represented with innocent looking lines. As these lines begin making their way onto network engineers’ whiteboards, so do a slew of API acronyms – ones programmers have been using for years.

SDN has expanded the Network Engineer’s vocabulary, making typical programmer and sys-admin terminology necessary as they begin describing how to support today’s networks. Words like CORBA, SOA, REST, XMPP,  JAVA, OSGI and OpenFlow are joining the must-know list of words in addition to more well-known terms like Ethernet, BGP, EIGRP, OSPF, IS-IS, RIPng, MPLS, IPv6, VPNs, Class-of-Service, Multicast, SNMP, GRES and NSR.

But wait… What on earth is an API these days? 

Great place to start! The acronym stands for Application Programming Interface (API). In practical terms, APIs define the software-driven interaction among “systems.”

Within the context of SDN, the term “systems” mainly refers to applications, network processes, router nodes, switching nodes, firewalls, load-balancers or service servers (e.g. DNS, DHCP, RADIUS, etc.).

A critical differentiator of an API is the middle word found in the acronym – the “programming” feature of APIs. It is this programmable functionality that distinguishes and gives APIs their flexibility in contrast to other systems information exchanges. APIs allow a “system” to essentially ask or send a request or reply to information queries.

A huge benefit of an API is that it allows a querying system to “not care” about certain things like:

  • knowing a remote system’s query commands
  • how information is organized
  • cli structures or restrictions in order to obtain information

A“querying” system just needs to know “the programmable way” of how to ask the remote system for information and how to read it. It is intended to be simple (like we all like it). And this is really the huge plus behind APIs.

As a point of comparison, in the past, there were non-API methods used to obtained information from remote systems such as “screen scraping.” Screen scraping occurs when one system remotely logs into another remote system, pretending to be a human user. Then, by executing commands as a user would, the desired information is displayed on the monitor. Once the remote system presents the information on the screen, the querying system is able to “read” it via coordinates.

The emergence of APIs was a long leap forward due to their flexible programmable nature as well as their security, directionality – unidirectional or bi-directional – and tunable synchronicity. Now, these API benefits are coming to a network near you!

In short, if an SDN implementation defines objects and attributes, the way to “expose” these to querying systems is via APIs.

But more specifically, what would be an object or attribute in the context of SDN networks?

We can think of SDN objects as interfaces, policies, protocols, virtual-instances and the like. Attributes are like states or values of these objects such as inactive, administratively down, BGP neighbor IPs (an IP address being attributes of the BGP neighbor), etc.

The “rules of engagement” for fetching networking information via APIs from a system (such as a router or a switch), are usually defined by how a system decides to expose such information via its APIs.

OK. This is essentially the SDN API concept.

Now we can readily see why APIs are arguably the “doors” to the SDN benefits. These benefits being: flexibility, simplicity and efficiency.

To clarify this point, consider this: If a system – like an application, router, switch, firewall, etc. – is very effective as a stand-alone system in doing what it does best, but it has poorly defined APIs; then, it is limited by how remote systems can interact with it. Consequently, an SDN implementation will most likely be limited. The “you-are-as-good-as-your-weakest link” warning would apply. In short, those “lines” representing APIs in SDN designs are very important design components!

Let’s go over a few SDN API definitions being quoted these days:

  • SOAP: The Simple Object Access Protocol leverages XML structures for its message formats, HTTP and SMTP for message negotiations and exchanges, and RPCs (remote procedure calls) used for accessing remote procedures. SOAP APIs are common among languages that support web services, and since most operating systems support some form of web services, this makes SOAP a likely available API.
  • CORBA: The good ol’ Common Object Request Broker Architecture. Yes… I say “old” because it was introduced in 1991. The goal is to allow different software modules to work with each other even if written in different programming languages. This goal is accomplished via – yet another – “Interface Definition Language” (IDL), as well as the implementation of “object request brokers” for each programming module. Thus, IDL-mappings to the different programming languages such as Phyton, C, C++ and Java are needed. CORBA could very well be the first clear origin of how APIs work today.
  • REST: Called a Representational State Transfer API. The idea behind REST APIs is to “reuse and simplify” what is available in HTTP for client-server information exchange by using such definitions for system-to-system calls. This HTTP “re-use” simplifies the way REST APIs work given that HTTP is a proven and known protocol most programmers are familiar with.
  • XMPP: The extensible message and presence protocol is an open standard originally used for jabber applications in support of real-time online communication. If you used Google talk, you used it. It is also based on XML structures. XMPP can either establish TCP connections or HTTP connections over which XML messages are exchanged.
  • OSGi: It is an open standard framework intended to support java modules as a way to reduce complexity. An important benefit is that it allows for dynamic loading and unloading of Java modules supported by a series of Java interfaces. It was first conceived as an SDK and these days has expanded its extensibility.
  • OpenStack: This not an API – (almost got you ? lol ) but just to make a comparison at this point – Openstack is more an ecosystem under the Apache software foundation with its own Networking API modules for multiple attributes for network objects. The Openstack network module (called “Neutron”)  essentially provides management of overlay virtual Layer-2 (or Layer-3) domains (called “virtual networks”),. subnets (either IPv4 or IPv6 addresses) and ports (virtual switch port or logical network switch). Openstack has APIs which are REST-HTTP-based API focused on the manipulation of the state of four networking objects.

The above list is in no way comprehensive – just common APIs found in the marketplace. SDN continues to be in such an evolving state that open and proprietary API definitions are also evolving. Networking vendors and open source communities continue improving existing ways of implementing APIs. Also, the above APIs are not mutually exclusive, and in fact, some SDN implementations make multiple APIs available. It all depends on how flexible a system is intended to be.

So where is OpenFlow on this list? This seems like a big miss given that OpenFlow has been all over the SDN literature lately.

Great point. OpenFlow is a term that has been associated with a few different concepts (probably the reason for much confusion). I would argue that OpenFlow is a “southbound” API for SDN system components – yes, essentially a Southbound API from a controller as defined today but there is no reason that it has to be only a Southbound API exclusively from a controller.

Currently, there are a few versions of the standardized OpenFlow API. However, there is competition for the Openflow API – such as using XMPP for implementing Southbound APIs. Nonetheless, Openflow is certainly placing itself as a strong contender as the de-facto Southbound API role.

To expand the same point with another example, it is possible to consider the static flow pusher “API”, which is actually a Floodlight I/O module exposed via a REST API definition. The static flow API allows a user to manually configure network traffic flows in an SDN network. The manual traffic configuration via this API has been often configured via Python code.

So, it is worth being careful when drawing those innocent-looking lines during SDN whiteboarding. They’re often not as simple as they seem when it comes to API definitions, associated protocols and system I/O modules.

 

Is an EVPN really better than a VPLS .. or it is just hype ?

Leave a reply

 

Service providers are well familiar with VPLS as a way to leverage their MPLS infrastructure to effectively provide their customers with extending “Ethernet LANs across WANs”; effectively, creating Ethernet domain stretches. Service providers know that VPLS has its short comings; but overall, it has gained a place in their networks to support certain end customer services.

But EVPNs entered the service provider feature set more recently than VPLS and; the EVPN implementations have been maturing to the point that there are some advantages they bring to a network over VPLS implementations. What are those advantages? Are these significant advantages or not ? – these are the bottom-line questions that customers commonly raise.

Let me mention two main advantages of EVPNs over VPLS. There are others, yes… but, these two clearly fall in the “significant” category.

The first difference is that EVPNs use the control plane to communicate MAC+IP address reachability among PE devices while EVPN’s data plane is similar to VPLS data plane. What does this really mean in simple jargon?  In short, it implies that the multiple PE control planes communicate to each other to exchange the MAC+IP bindings and; since this is done at the control-plane level, there is more freedom for network engineers to filter what is imported or exported at each PE – thus, automatic PE-PE flooding, which is part of VPLS,  is consequently, avoided.

The second difference I like to highlight is that EVPNs allow for an active/active multi-homing scenario from a CE-PE perspective. Unlike VPLS which allows for an active/passive multihoming protection. This feature allows EVPN CE’s to actually run a Link-Aggregation protocol across two distinct PE’s which; consequently, permits the implementation of load balance hashing schemes – very nice.

The above two differences should be sufficient to make those service providers with no EVPNs plans yet to raise their eye brows, shake their heads and think: We need to evaluate EVPNs.

Yardiel

First Post’s Perspective

1 Reply

For some people, particularly those introverts involved in technology, blogging is a sure step towards loosing your privacy – more so, if it is done with no other ulterior motive or purpose (financial, etc) . In fact, in our uber-social-networked world, blogging is just a significant step toward sacrificing precious privacy of whatever remains.

On one hand, blogging is a very convenient way of sharing perspectives and engaging in discussions that may lead you towards new growth. But on the flip side, it implies a risk of willingly giving up a part of your private life.

I pondered on that for a bit while setting up this website — oh well…. Let’s get going blogging about many really captivating networking topics.

Welcome,

Techguane