SDN is an increasingly popular means of managing your network, but software-defined networking alone is not a complete answer to streamlining your management.
Many network engineers have made the mistake of implementing SDN without understanding the impact of an incomplete network design. While it offers many benefits, software-defined networking can cloud your network visibility and mitigate the advantages of implementing it in the first place.
While SDN offers many advantages, the added layers of network abstraction veil your visibility into the traffic on your network. Complete network visibility is critical to your ability to secure, protect, and analyze your network. Whether you’re employing SDN or a physical network and application monitoring tools, you must have complete transparency.
These applications and functions include:
Especially in faster and faster environments, capturing, filtering, aggregating, and balancing your network traffic is paramount to achieving complete visibility. Without these functions, you have holes in your data and are more susceptible to data breaches and network intrusion.
The key to ensuring complete data and visibility is creating a visibility plane. Most network engineers fail to be proactive about developing a plane of visibility, and after a solution is implemented, their data access is limited and visibility is impaired.
In order to reap the benefits of an SDN solution, you must also implement a visibility plane in parallel. Implementing software-defined networking doesn’t negate the need for a visibility plane, and you still need a means of connecting to your network.
The traditional means of connecting applications to a network is through network packet brokers. They control the flow of traffic and make it possible to capture data as well as leverage monitoring tools and applications in a 40/100Gbps environment. But, there is often question as to whether these physical brokers will be effective in a virtual environment such as SDN. In addition, industry analysts wonder whether the functionalities of network packet brokers can be virtualized.
There are many variables that go into the ability of a packet broker to manage a visibility plane for an SDN solution, including individual protocols. As a Network World article points out:
“More important than any single protocol (especially with the ecosystem of protocols growing constantly) is the ability to inspect and identify packets from Layers 2 through 7, combined with the flexibility to configure and program the [network packet broker] to strip and slice packets to optimize monitoring applications, and to support emerging protocols, such as VXLAN.”
Packet brokers must have supreme flexibility to be able to manage the many different application programming interfaces (APIs) that you or another company might implement. Because virtualized networks supplement your physical network, it’s also important to provide physical Link Layer visibility, especially when it comes to security, monitoring, and analysis tools.
While there are many points to take away, the most important is the need for proactive design. Software-defined networking should never be implemented hastily. It must be a cohesive component of your overall network. Ensure your network visibility to ensure the success of SDN and your network management.
If you want to learn more about the promises of SDN, NFV and the importance of maintaining 100% network visibility as you make the transition, download our free white paper, Architecting Data Centers for SDN and NFV - In 40G and 100G Environments
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.