Mellanox Introduces Advanced Network Telemetry Technology

Mellanox today announced an advanced Network Telemetry technology that provides visibility into Data Plane Anomalies – for public cloud, private cloud and enterprise computing.

What Just Happened (WJH) is a new intelligent monitoring technology that goes well beyond conventional streaming telemetry and Inband Network Telemetry (INT) offerings. These conventional telemetry offerings generate enormous amounts of data that is mined from network port counters and statistical packet sampling and hop-by-hop INT data. This type of telemetry data lacks any context or actionable details on abnormal network behavior, forcing the network admin or monitoring tool to perform time consuming analysis to find the root cause of network issues. WJH event-based telemetry delivers direct and actionable information and thus eliminates the guesswork from network troubleshooting.

In Mellanox based switch systems, WJH inspects packets across all ports at line-rate, at speeds that would overwhelm traditional Deep Packet Inspection solutions. WJH then identifies anomalous behavior, consolidates this into concise, specific, and actionable data that enables rapid remediation and recovery of cloud applications and critical business operations.

http://www.mellanox.com/related-docs/solutions/SB_Mellanox_WJH.pdf?ls=pr&lsd=190513-WJH-1

How Mellanox ConnectX and BlueField Empower Cyber Security Solutions

News from Mellanox

  1. Mellanox Turns Zero-Trust to HERO-Trust
    A Mellanox blog discussing the zero-trust security model, and how Mellanox BlueField SmartNIC empowers zero-trust security solutions
  2. ConnectX & BlueField Empower Cloud Security SolutionsEye on Mellanox YouTube VideoA short video clip discussing how ConnectX & BlueField empower cloud security solutions
  3. Guardicore and Mellanox Deliver Agentless and High-Performance Micro-Segmentation in Hybrid Cloud
    Guardicore is a cyber security solution provider which offers a complete micro-segmentation solution for enforcing security policies in data-center networks. Micro-segmentation is considered a priority for CISO’s in 2019 and beyond. We have recently partnered with Guardicore to have their software run on top of BlueField, enabling agentless and high-performant micro-segmentation solution. The attached solution brief describes the key benefits of applying BlueField for micro-segmentation and key benefits of the joint solution. 

White Paper on Mellanox seamless integration with OpenStack

Mellanox’s Ethernet solutions enable cloud data centers to achieve the highest efficiency through a high-performance, low latency cloud network with rich network offload with acceleration and automation features.
Check out the attached Whitepaper from Mellanox and see how we can help you get it there!

See Mellanox Seamlessly Integrates with OpenStack, Increasing Efficiency and Reducing Operational Costs

 

Mellanox SN2100 Ethernet Bundle Configurator

Mellanox has a Ethernet Configurator which you can even use for other model.

Here’s how it works:
Choose the following:
1. Choose the setup

  • 1 switch
  • 2 switches connected with mLAG
  • 5 switches: testing both mLAG as well as leaf spine (BGP/ECMP) – simple L3/VTEP/VXLAN Routing (VXLAN on Cumulus only for now)

2. Choose the speed of the host/NIC

  • 10/25/100GbE

3. Choose the operating system

  • ONYX
  • Cumulus Linux

What you get is:
1. Topology: how to connect, which specific ports should be used

2. Solution brief for the selected scenario

3. One Click Configuration files:

  • For the CLI guys: running config
  • For the Ansible guys: Ansible playbooks (ONYX Ansible for mLAG and L3 will be added soon)

Able to ping IPoIB for selected existing nodes when adding new nodes

When I add in new nodes, install the MLNX_OFED drivers from Mellanox. Strangely I was only able to randomly ping to selected existing or new nodes on the Cluster. This was quite a curious problem.

When I do a ibstat, but when you do a ibping test (Installing Voltaire QDR Infiniband Drivers for CentOS 5.4), the test will failed for selected nodes in the cluster, but others will be able to ping back.

Yes, both openibd and opensmd services are started for all nodes on the cluster,

After some troubleshooting, the only way was to stop all the opensmd service for all the nodes (existing and new) and restart it again

# service openibd restart
# service opensmd restart

Registering sufficent memory for OpenIB when using Mellanox HCA

If you encountered errors like “error registering openib memory” similar to what is written below. You may want to take a look at the OpenMPI FAQ – I’m getting errors about “error registering openib memory”; what do I do? .

WARNING: It appears that your OpenFabrics subsystem is configured to only
allow registering part of your physical memory.  This can cause MPI jobs to
run with erratic performance, hang, and/or crash.

This may be caused by your OpenFabrics vendor limiting the amount of
physical memory that can be registered.  You should investigate the
relevant Linux kernel module parameters that control how much physical
memory can be registered, and increase them to allow registering all
physical memory on your machine.

See this Open MPI FAQ item for more information on these Linux kernel module
parameters:

    http://www.open-mpi.org/faq/?category=openfabrics#ib-locked-pages

  Local host:              node02
  Registerable memory:     32768 MiB
  Total memory:            65476 MiB

Your MPI job will continue, but may be behave poorly and/or hang.

The explanation solution can be found at How to increase MTT Size in Mellanox HCA.

In summary, the error occurred when applications which consumed a large amount of memory, application might fail when not enough memory can be registered with RDMA. There is a need to increase MTT size. But increasing MTT size hasve the downside of increasing the number of “cache misses” and increases latency.

1. To check your value of log_num_mtt

# cat /sys/module/mlx4_core/parameters/log_num_mtt

2. To check your value of log_mtts_per_seg

# cat /sys/module/mlx4_core/parameters/log_mtts_per_seg

There are 2 parameters that affect registered memory. This can be taken from http://www.open-mpi.org/faq/?category=openfabrics#ib-low-reg-mem

With Mellanox hardware, two parameters are provided to control the size of this table:

  • log_num_mtt (on some older Mellanox hardware, the parameter may benum_mtt, not log_num_mtt): number of memory translation tables
  • log_mtts_per_seg:

The amount of memory that can be registered is calculated using this formula:

In newer hardware:
    max_reg_mem = (2^log_num_mtt) * (2^log_mtts_per_seg) * PAGE_SIZE

In older hardware: 
    max_reg_mem = num_mtt * (2^log_mtts_per_seg) * PAGE_SIZE

For example if your server’s Physical Memory is 64GB RAM. You will need to registered 2 times the Memory (2x64GB=128GB) for the max_reg_mem. You will also need to get the PAGE_SIZE (See Virtual Memory PAGESIZE on CentOS)

max_reg_mem = (2^ log_num_mtt) * (2^3) * (4 kB)
128GB = (2^ log_num_mtt) * (2^3) * (4 kB)
2^37 = (2^ log_num_mtt) * (2^3) * (2^12)
2^22 = (2^ log_num_mtt)
22 = log_num_mtt

The setting is found in /etc/modprobe.d/mlx4_mtt.conf for every nodes.

References:

  1. OpenMPI FAQ – 15. I’m getting errors about “error registering openib memory”; what do I do?
  2. How to increase MTT Size in Mellanox HCA
  3. OpenMPI FAQ – 18. Open MPI is warning me about limited registered memory; what does this mean?
  4. Virtual Memory PAGESIZE on CentOS