Gaining full visibility into overlay and underlay networks while maintaining data integrity. With the rapid expansion of NFV deployments and the use of VXLAN for building overlay networks comes increased complexity in getting accurate visibility into both the overlay and the underlay network. Traditional monitoring tools are typically unable to handle encapsulated network traffic nor can they handle the correlation necessary to differentiate the overlay networks. Organizations will often rely on Endpoint Visibility solutions in these cases, which have their strong points, but are also increasingly costly, require vendor lock-in, and are inefficient for troubleshooting. They also infer the network performance parameters rather than measure them directly from the actual network traffic.
Cubro offers three design solutions for this issue:
Now that applications and hosts impacted by physical network outages are identified, an SDDC administrator can select end nodes to view where VM to VM traffic is encapsulated, and can see specifically which physical network devices the traffic went through.
Now SDDC administrators can pinpoint which of the network devices in the path are a cause of application performance problems.
The following image shows network device interfaces involved in VM to CM communication.
For interfaces relaying a traced communication the following information is presented:
The Path information is available not only for VM to VM (East-West traffic) within the date center, but also for VM to gateways (North-South traffic). This capability is useful in identifying network congestion and abnormal activity such as data exfiltration.
The other possible option is dynamic VXLAN filtering. This solution is not as perfect as solution 1, but can reuse “old” monitoring gear. Old equipment can be repurposed because dynamic VXLAN filtering would assure that only the traffic from the relevant overlay is filtered out and sent to legacy monitoring tools.
The challenge is that only a few NPBs are capable of VXLAN filtering. The second issue is that this must be done dynamically. For that reason, some signalling protocols must be decoded by the packet broker or an external appliance. This leads us to our third solution - Cubro Cloud Switch (CCS).
The most advanced solution would be to use the Cubro Cloud Switch because the CCS combines an advanced switching fabric with a visibility fabric. Below image shows the transformation if you use the CCS.
The Cubro Cloud switch provides switching functions in layer 2 to 7 and at the same time visibility. This is possible because the packet forwarding is done in HW, the switch infrastructure knows where the micro service is running, and can copy the relevant traffic and send it over the switch infrastructure to the probing system (virtual/real).