Internet of things

Internet of Things Access Technologies

by Blog

Internet of Things Access Technologies

The Internet of Things (IoT) has evolved from a collection of connected devices into a distributed technology ecosystem spanning homes, enterprises, industrial environments, vehicles, healthcare, utilities, and smart infrastructure.

At the foundation of every IoT deployment is connectivity. Sensors and devices need a way to communicate with gateways, edge platforms, applications, and cloud services. The appropriate access technology depends on factors such as range, bandwidth, power consumption, mobility, reliability, device density, deployment environment, and security requirements.

There is therefore no single IoT connectivity technology that fits every deployment.

Understanding IoT Access Technologies

IoT access technologies provide the communications layer between devices and the systems that consume their data.

A simplified IoT architecture can involve several stages:

Device → Access Network → Gateway or Edge → IoT Platform → Application

In some architectures, a device may communicate directly with an IP network or cloud service. In others, a gateway aggregates data from hundreds or thousands of sensors before forwarding selected information upstream.

IoT connectivity can broadly be divided into wired, short-range wireless, low-power wide-area, cellular, and specialised industrial technologies.

Wired Connectivity

Wired connectivity remains important where predictable performance, physical security, power delivery, or high bandwidth are required.

Ethernet is widely used in industrial, enterprise, building automation, and infrastructure environments. It provides reliable IP connectivity and can support high data rates with relatively predictable performance.

Power over Ethernet (PoE) combines network connectivity and electrical power over Ethernet cabling. This can simplify deployments for devices such as cameras, access points, sensors, controllers, and other powered endpoints.

Wired technologies are particularly useful where devices are stationary and cabling is practical, but installation costs and physical deployment constraints can make wireless alternatives more attractive.

Short-Range Wireless Connectivity

Short-range wireless technologies are widely used for devices operating within homes, buildings, industrial sites, and personal environments.

Wi-Fi provides relatively high bandwidth and integrates easily with existing IP networks. It is useful for cameras, appliances, industrial devices, gateways, and applications that require greater throughput.

Bluetooth Low Energy (BLE) is designed for low-power short-range communication and is commonly used for sensors, wearables, beacons, medical devices, and device provisioning.

Zigbee and Thread are designed around low-power mesh networking and can support large numbers of constrained devices.

Thread is particularly important in modern smart-home environments because it is based on IPv6 and is designed for low-power mesh connectivity. Matter operates at the application layer and can use technologies such as Wi-Fi, Ethernet, and Thread as its underlying network connectivity.

The distinction is important: connectivity technology and application protocol are not necessarily the same thing.

Low-Power Wide-Area Networking

Many IoT devices do not require high bandwidth. A remote sensor may only need to transmit a small amount of information every few minutes or hours.

This is where Low-Power Wide-Area Networking (LPWAN) technologies become valuable.

LoRaWAN is designed for long-range, low-power communications and is particularly useful for distributed sensors such as environmental monitoring, agriculture, metering, and smart-city deployments.

Cellular IoT technologies such as NB-IoT and LTE-M provide another approach, using mobile network infrastructure to connect devices over wide geographic areas.

These technologies prioritise characteristics such as long battery life, wide coverage, device density, and relatively low data requirements rather than raw bandwidth.

Cellular IoT

Cellular connectivity is particularly useful when devices are geographically distributed, mobile, or located where local network infrastructure is unavailable.

Traditional generations of mobile technology have supported IoT connectivity, but modern deployments increasingly focus on technologies such as LTE-M, NB-IoT, and 5G.

5G also introduces capabilities relevant to more demanding IoT scenarios, including high bandwidth, lower latency, greater device density, and support for specialised industrial and private-network deployments.

However, 5G should not automatically be considered the answer for every IoT deployment. A low-power environmental sensor transmitting a few bytes of telemetry does not necessarily require the capabilities or cost structure of a high-performance 5G connection.

Edge Connectivity

Modern IoT architectures increasingly move processing closer to the devices.

An edge gateway can aggregate sensor traffic, translate between protocols, filter data, perform local analytics, enforce security policies, and continue operating when connectivity to the cloud is unavailable.

This is particularly valuable in industrial environments where latency, bandwidth, resilience, and local decision-making are important.

For example, an industrial sensor might send raw telemetry to a local edge platform. The edge system can detect an abnormal condition immediately while sending only the relevant event or aggregated telemetry to a central cloud platform.

This approach reduces unnecessary data transmission and can improve response times.

Security Must Begin at the Access Layer

Connectivity also introduces an attack surface.

IoT devices can be physically accessible, resource constrained, widely distributed, and difficult to update. Security therefore needs to be considered throughout the device and connectivity lifecycle.

Important controls include:

Device identity: each device should have a verifiable identity rather than relying on shared credentials.

Authentication: devices and services should authenticate before exchanging sensitive information.

Encryption: communications should be protected against interception and manipulation.

Secure onboarding: devices should be provisioned securely before they become trusted members of the environment.

Network segmentation: IoT devices should be isolated from systems that do not require direct access to them.

Secure updates: firmware and software need mechanisms for authenticated and controlled updates.

Lifecycle management: devices should be monitored, maintained, rotated, and securely decommissioned when they reach the end of their operational life.

This is increasingly aligned with a zero-trust approach, where network location alone does not establish trust.

Choosing the Right IoT Connectivity

Selecting an IoT access technology is therefore an engineering decision rather than simply a choice between wired and wireless.

Key questions include:

How far must the device communicate?

How much data does it need to transmit?

How frequently does it communicate?

Does the device need to operate for years on battery power?

Is the device stationary or mobile?

What level of latency and reliability is required?

Is local edge processing required?

What security and lifecycle controls are necessary?

What existing infrastructure can be reused?

The answers determine whether Ethernet, Wi-Fi, Thread, Bluetooth, LoRaWAN, cellular IoT, 5G, or another connectivity technology is appropriate.

IoT connectivity is therefore best understood as a layered architecture rather than a single access technology. The right combination of device connectivity, networking, edge computing, cloud services, and security allows IoT deployments to scale from a handful of sensors to millions of distributed devices.

As IoT continues to move toward edge computing, autonomous systems, industrial automation, and AI-driven operations, understanding the characteristics and trade-offs of these access technologies becomes increasingly important.

IoT Connectivity Explorer

Which Access Technology Fits the IoT Use Case?

IoT devices do not all have the same connectivity requirements. Choose a deployment scenario and explore which access technology best matches its range, power, bandwidth and mobility needs.

Learning Objective Understand why Wi-Fi, cellular, Bluetooth, Zigbee and LoRaWAN are suited to different IoT connectivity requirements.

1. Choose an IoT Scenario

Select the environment you are designing connectivity for.

2. Explore Technologies
Select a scenario
Recommended Access Technology
—
Choose an IoT scenario to see the recommended connectivity approach.
Range
Power
Bandwidth
Mobility
Technology insight
Select a scenario or technology to explore its role in IoT connectivity.
Engineering Takeaway There is no single best IoT access technology. Connectivity should be selected according to the application's range, power, bandwidth, mobility and deployment requirements.

Highlights: Internet of Things Access Technologies

A practitioner in the tech industry should be familiar with the term Internet of Things (IoT). IoT continues to grow due to industries’ increasing reliance on the internet. Even though we sometimes don’t realize it, it is everywhere.

The Internet of Things plays an important role in the development of smart cities through its various implementations, such as real-time sensor data retrieval and automated task execution. The Internet of Things’ profound impact on our urban landscape, which is increasingly evident, means that these systems, equipped with numerous sensors, take action when specific thresholds are reached.

The Internet of Things, coined by computer scientist Kevin Ashton in 1999, is a network of connected physical objects that send and receive data. Smart fridges and mobile phones are examples of everyday objects, as are smart agriculture and smart cities, which span entire towns and industries.

IoT has revolutionized how we live and interact with our environment in just a few years. Households can benefit from IoT in the following ways:

  • Convenience: Devices can be programmed and controlled remotely. Think about being able to adjust your home’s lighting or heating even when you’re miles away using your smartphone.
  • Efficiency: Smart thermostats and lighting systems can optimize operations based on your usage patterns, saving energy and lowering utility bills.
  • Security: In terms of security, IoT-enabled security systems and cameras can alert homeowners of potential breaches, and smart locks can recognize and grant access based on recognized users.
  • Monitoring health metrics: Smart wearables can track health metrics and provide real-time feedback, potentially alerting users or medical professionals to concerning changes.
  • Improved user experience: Devices can learn and adapt to users’ preferences, ensuring tailored and improved interactions over time.

IoT Access Technologies:

Wi-Fi:

One of the most widely used IoT access technologies is Wi-Fi. With high data transfer speeds and widespread availability, Wi-Fi enables devices to connect effortlessly to the internet. Wi-Fi allows for convenient and reliable connectivity, whether controlling your thermostat remotely or monitoring security cameras. However, its range limitations and power consumption can be challenging in specific IoT applications.

Cellular Networks:

Cellular networks, such as 3G, 4G, and now the emerging 5G technology, play a vital role in IoT connectivity. These networks offer broad coverage areas, making them ideal for IoT deployments in remote or rural areas. With the advent of 5G, IoT devices can now benefit from ultra-low latency and high bandwidth, paving the way for real-time applications like autonomous vehicles and remote robotic surgery.

Bluetooth:

Bluetooth technology has long been synonymous with wireless audio streaming, but it also plays a significant role in IoT connectivity. Bluetooth Low Energy (BLE) is designed for IoT devices, offering low power consumption and short-range communication. This makes it perfect for applications like wearable devices, healthcare monitoring, and intelligent home automation, where battery life and proximity are crucial.

Zigbee:

Zigbee is a low-power wireless communication standard designed for IoT devices. It operates on the IEEE 802.15.4 standard and offers low data rates and long battery life. Zigbee is commonly used for home automation systems, such as smart lighting, temperature control, and security systems. Its mesh networking capabilities allow devices to form a network and communicate with each other, extending the overall range and reliability.

LoRaWAN:

LoRaWAN (Long Range Wide Area Network) is a low-power, wide-area network technology for long-range communication. It enables IoT devices to transmit data over long distances, making it suitable for applications like smart agriculture, asset tracking, and environmental monitoring. LoRaWAN operates on unlicensed frequency bands, enabling cost-effective and scalable IoT deployments.

Example Product: Cisco IoT Operations Dashboard

### Streamlined Device Management

One of the standout features of the Cisco IoT Operations Dashboard is its capability to streamline device management. With a user-friendly interface, you can quickly onboard, monitor, and manage a wide array of IoT devices. The dashboard provides real-time visibility into device status, performance metrics, and potential issues, allowing for proactive maintenance and swift troubleshooting.

### Enhanced Security Measures

Security is a top priority when it comes to IoT devices, and the Cisco IoT Operations Dashboard excels in this area. It offers robust security protocols to protect your devices from vulnerabilities and cyber threats. Features such as encrypted communications, device authentication, and regular security updates ensure that your IoT ecosystem remains secure and resilient against attacks.

### Scalability for Growing IoT Networks

As your IoT network expands, managing an increasing number of devices can become challenging. The Cisco IoT Operations Dashboard is designed to scale effortlessly with your network. Whether you have a small deployment or a vast array of interconnected devices, the dashboard’s scalable architecture ensures that you can manage your IoT operations effectively, regardless of size.

### Integration and Interoperability

The Cisco IoT Operations Dashboard is built with integration and interoperability in mind. It seamlessly integrates with other Cisco products and third-party solutions, providing a cohesive and unified management experience. This interoperability allows for the aggregation of data from various sources, enabling comprehensive analytics and informed decision-making.

 

1. Define the Requirements
Move the sliders toward the requirement you want to prioritise.
Transmission Range Medium
Local Long range
Low Power Requirement Medium
Less important Critical
Bandwidth Requirement Medium
Low High
Mobility Requirement Medium
Stationary Highly mobile
Engineering Principle

IoT connectivity is a trade-off. The best technology depends on the workload and constraints rather than a single performance metric.

1 Define the workload
What data must be moved, and how often?
2 Identify the constraints
Consider range, power, bandwidth and mobility.
3 Select the technology
Choose the option that best fits the complete requirement.
2. Compare the Technologies
The ranking updates as the requirements change.
Current Engineering Recommendation

Wi-Fi

Balanced requirements currently favour a technology with strong local connectivity and useful bandwidth.

Engineering Insight: There is no universally "best" IoT access technology. The correct choice depends on the combination of range, energy constraints, bandwidth and mobility.

Internet of Things Access Technologies

The Internet of Things consists of a network of several devices, including a range of digital and mechanical objects, with separate access to transfer information over a network. The word “thing” can also represent an individual with a heart- monitor implant or even a pet with an IoT-based collar.

The term “thing” reflects the association of “internet” to devices previously disconnected with internet access. For example, the alarm clock was never meant to be internet-enabled, but now you can connect it to the Internet. With IoT, the options are endless.

Examples: IoT Access Technologies

Then, we have IoT access technologies. The three major network access technologies for IoT Connectivity are Standard Wireless Access – WiFi, 2G, 3G, and standard LTE. We also have Private Long Range – LoRA-based platforms, Zigbee and SigFox. Mobile IoT Technologies – LTE-M, NB-IoT, and EC-GSM-IoT

The origins of the Internet, which started in the 1960s, look entirely different from our current map. It is now no longer a luxury but more of a necessity. It started with areas such as basic messaging, which grew to hold the elasticity and dynamic nature of the cloud, to a significant technological shift into the world of the Internet of Things (IoT): Internet of Things theory.

It’s not about buying and selling computers and connecting them anymore; it’s all about data, analytics, and new solutions, such as event stream processing.

Internet of Things Access Technologies: A New World

A World with the Right Connections

IoT represents a new world where previously unconnected devices have new communication paths and reachability points. This marks IoT as the next evolutionary phase of the Internet, building better customer solutions.

The revolutionary phase is not just a technical phase; ethical challenges now face organizations, society, and governments. In the past, computers relied on input from humans. We entered keystrokes, and the machine would perform an action based on the input.

The computer had no sensors that could automatically detect the world around it and perform a specific action based on that. IoT ties these functions together. The function could be behavioral, making the object carry out a particular task or provide other information. IoT brings a human element to technology, connecting physically to logic.

 It’s all about data and analytics.

The Internet of Things is not just about connectivity. The power of IoT comes from how all these objects are connected and the analytics they provide. New analytics lead to new use cases that will lead to revolutionary ideas enhancing our lives. Sensors are not just put on machines and objects but also on living things. Have you heard of the connected cow? Maybe we should start calling this “cow computing” instead of “cloud computing.” For example, an agricultural firm called Chitale Group uses IoT technologies to keep tabs on herds to monitor their thirst.

These solutions will formulate a new type of culture, intertwining various connected objects and dramatically shifting how we interact with our surroundings. This new type of connectivity will undoubtedly formulate how we live and form the base of a new culture of connectivity and communication.

 IoT Access Technologies: Data management – Edge, fog, and cloud computing

In the traditional world of I.T. networks, data management is straightforward. It is based on I.P. with a client/server model, and the data is in a central location. IoT brings new data management concepts such as Edge, Cloud, and Fog computing. However, the sheer scale of IoT data management presents many challenges. Low bandwidth of the last mile leads to high latency, and new IoT architectural concepts such as Fog computing, where you analyze data close to where it’s connected, are needed. 

Like the cloud in Skype, Fog is on the ground and best suited for constrained networks that need contextual awareness and quick reaction. Edge computing is another term where the processing is carried out at the furthest point – the IoT device itself. Edge computing is often called Mist computing.

IoT Access Technologies
Diagram: IoT Access Technologies. Source Cisco.

Cloud computing is not everything.

IoT brings highlights the concept that “cloud computing is not everything.” IoT will require onsite data processing; some data must be analyzed in real-time. This form of edge computing is essential when you need near-time results and when there isn’t time to send visual, speed, and location information to the cloud for instructions on what to do next. For example, if a dog runs out in front of your car, the application does not have the time for several round trips to the cloud. 

Services like iCloud have had a rough few years. Businesses are worried about how secure their data will be when using one of the many cloud-based services available, especially after the iCloud data breach in 2014. However, with the rise of cloud security solutions, many businesses are starting to see the benefits of cloud technology, as they no longer have to worry about their data security.

The Internet is prone to latency, and we cannot fix it unless we shorten the links or change the speed of light. Connected cars require the capability to “think” and make decisions on the ground without additional hops to the cloud.

Fog Computing – Distributed Infrastructure 

Fog computing is a distributed computing infrastructure between a network’s edge and the cloud. It is a distributed computing architecture designed to address the challenges of latency and bandwidth constraints introduced by traditional cloud computing. Fog computing decentralizes the computing process rather than relying on a single, centralized data center to store and process data. It enables data to be processed closer to the network’s edge.

Fog computing performs better than cloud computing in meeting the demands of emerging paradigms. However, batch processing is still preferred for high-end jobs in the business world, so it can only partially replace cloud computing. In conclusion, fog computing and cloud computing complement one another while having their advantages and disadvantages. Edge computing is crucial in the Internet of Things (IoT).

Security, confidentiality, and system reliability are research topics in the fog computing platform. Cloud computing will meet the needs of business communities with its lower cost based on a utility pricing model. In contrast, fog computing is expected to serve the emerging network paradigms that require faster processing with less delay and delay jitter. Fog computing will grow by supporting the emerging network paradigms that require faster processing with less delay and delay jitter.

Internet of Things Access Technologies: Architectural Standpoint

A ) From an architectural point of view, one must determine the technologies used to allow these “things” to communicate with each other. And the technologies chosen are determined by how the object is classified. I.T. network architecture has matured over the last decade, but IoT architectures bring new paradigms and a fresh approach. For example, traditional security designs consist of physical devices with well-designed modules.

B ) Although new technologies such as VM NIC Firewalls and other distributed firewalls other than IoT have dissolved the perimeter, IoT brings dispersed sensors outside the protected network, completely dissolving the perimeter to a new level. 

C) When evaluating the type of network needed to connect IoT smart objects, one needs to address transmission range, frequency bands, power consumption, topology, and constrained devices and networks. The technologies used for these topologies include IEEE 802.15.4, IEEE 802.15.4g and IEEE 802.15.4e, IEEE 1901.2a, IEEE 802.11ah, LoRaWAN, and NB-IoT. The majority of them are wireless. Similar to I.T. networks, IoT networks follow Layer 1 (PHY), Layer 2 (MAC), Layer 3 (I.P.), etc. layers. And some of these layers require optimizations to support IoT intelligent objects.

IP/TCP/UDP in an IoT world

– The Internet Protocol (I.P.) is an integral part of IoT due to its versatility in dealing with the large array of changes in Layer 1 and Layer 2 to suit the last-mile IoT access technologies. I.P. is the Internet protocol that connects billions of networks with a well-understood knowledge base. Everyone understands I.P. and knows how to troubleshoot it.

– It has proven robust and scalable, providing a solid framework for bi-directional or unidirectional communication between IoT devices. Sometimes, the full I.P. stack may not be necessary as protocol overhead may exceed device data. 

– More importantly, IPv6. Using I.P. for the last mile of constrained networks requires introducing a new mechanism and routing protocols, such as RLP and adaptation layers, to handle the constrained environments. In addition, routing protocol optimizations must occur for constrained devices and networks. This is where we see the introduction of the IPv6 RPL protocol. IPv6 RPL protocol is a distance-vector routing protocol specifically designed for IoT intelligent objects.

– Optimizations are needed at various levels, and control plane traffic must be kept to a minimum, leading to new algorithms such as On-Demand Distance Vector. Standard routing algorithms learn the paths and store the information for future use. This works compared to AODV, which does not send a message until a route is needed.

Both TCP and UDP have their place in IoT:

TCP and UDP will play a significant role in the IoT transport layer. TCP for guaranteed delivery or UDP to leave the handling to a higher layer. The additional activities TCP brings to make it a reliable transport protocol come at the overhead cost per packet and session.

On the other hand, UDP is connectionless and often used for performance, which is more critical than packet retransmission. Therefore, a low-power and Lossy network (LLN) may be better suited than UDP and a more robust cellular network for TCP.

Session overhead may not be a problem on everyday I.T. infrastructures. Still, it can cause stress on IoT-constrained networks and devices, especially when a device needs only to send a few bytes per bytes of data per transaction. IoT Class 0 devices that only send a few bytes do not need to implement a full network protocol stack. For example, small payloads can be transported on top of the MAC layer without TCP or UDP.

**Ethical Challenges**

What are the ethical ramifications of IoT? In the Cold War, everyone was freaked out about nuclear war; now, it’s all about data science. We are creating billions of connected “things,” and we don’t know what’s to come. The responsibilities around the ethical framework for IoT and the data it generates fall broadly on individual governments and society.

These are not technical choices; they are socially driven. This might scare people and hold them back with IoT, but if you look at technology, it’s been a fantastic force for good. One should not resist IoT and the use cases it will offer our lives. However, I don’t think it will work out well for you if you do.

New technologies will always have risks and challenges. But if you reflect on and look at original technologies, such as the wheel, they created new jobs rather than destroyed old ones. IoT is the same. It’s about being on the right side of history and accepting it.

Example Product: Cisco Edge Device Manager

### What is Cisco Edge Device Manager?

Cisco Edge Device Manager is a cutting-edge platform designed to simplify the management of edge devices. It provides a unified interface for monitoring, configuring, and troubleshooting devices located at the edge of the network. By leveraging Cisco EDM, businesses can ensure optimal performance, reduce downtime, and enhance security across their edge infrastructure.

### Key Features and Benefits

#### Seamless Integration

One of the standout features of Cisco Edge Device Manager is its seamless integration with the Cisco IoT Operations Dashboard. This synergy allows for a centralized view of all IoT devices, enabling efficient management and streamlined operations.

#### Enhanced Security

Cisco EDM prioritizes security, offering advanced features such as automated firmware updates, real-time threat detection, and secure communication channels. These measures ensure that your edge devices are protected against potential cyber threats.

#### Scalability

Whether you have a handful of devices or thousands, Cisco Edge Device Manager scales effortlessly to meet your needs. Its flexible architecture supports the growth of your IoT infrastructure without compromising performance or reliability.

### Practical Applications

Cisco Edge Device Manager is not just a tool; it’s a game-changer for various industries. Here are a few practical applications:

– **Manufacturing**: Monitor and manage factory equipment in real-time to enhance productivity and reduce maintenance costs.

– **Retail**: Ensure seamless operation of point-of-sale systems and inventory tracking devices, improving customer experience.

– **Healthcare**: Maintain the performance and security of medical devices, ensuring patient safety and data integrity.

### Getting Started with Cisco Edge Device Manager

Setting up Cisco Edge Device Manager is straightforward. Begin by integrating it with your existing Cisco IoT Operations Dashboard. Next, configure your edge devices through the intuitive interface, and start monitoring their performance and security. Cisco provides detailed documentation and support to guide you through each step.

Cisco and IoT

One technology that has significantly advanced IoT is Cisco’s LoRaWAN. LoRaWAN, short for Long Range Wide Area Network, is a low-power, wide-area network protocol for long-range communication between IoT devices.

It operates in the sub-gigahertz frequency bands, providing an extended communication range while consuming minimal power. This makes it ideal for applications that require long-distance connectivity, such as smart cities, agriculture, asset tracking, and industrial automation.

Cisco’s Contribution: Cisco, a global leader in networking solutions, has embraced LoRaWAN technology and has been at the forefront of driving its adoption. The company has developed a comprehensive suite of LoRaWAN solutions, including gateways, sensors, and network infrastructure, enabling businesses to leverage the power of IoT.

Example Use Case: Cisco’s LoRaWAN-compliant solution.

With Cisco’s LoRaWAN-compliant solution, IoT sensors and endpoints can be connected cheaply across cities and rural areas. Low power consumption also extends battery life up to several years. The solution operates in the 800–900 MHz ISM band around the globe as part of Cisco’s LoRaWAN (long-range wide-area network) solution.

The Cisco Industrial Asset Vision solution includes it and a stand-alone component. Monitoring equipment, people, and facilities with LoRaWAN sensors improve business resilience, safety, and efficiency.

Cisco IoT Solution
Diagram: Cisco IoT Solution. Source Cisco.

Benefits of Cisco’s LoRaWAN:

1. Extended Range: With its long-range capabilities, Cisco’s LoRaWAN enables devices to communicate over several kilometers, surpassing the limitations of traditional wireless networks.

2. Low Power Consumption: LoRaWAN devices consume minimal power, allowing them to operate on batteries for an extended period. This makes them ideal for applications where the power supply is limited or impractical to install.

3. Scalability: Cisco’s LoRaWAN solutions are highly scalable, accommodating thousands of devices and ensuring seamless communication between them. This scalability makes it suitable for large-scale deployments, such as smart cities or industrial IoT applications.

4. Secure Connectivity: Security is a top priority in any IoT deployment. Cisco’s LoRaWAN solutions incorporate robust security measures, ensuring data integrity and protection against unauthorized access.

Cisco’s LoRaWAN Use Cases:

1. Smart Agriculture: LoRaWAN allows farmers to monitor soil moisture, temperature, and humidity, optimize irrigation, and reduce water consumption. Cisco’s LoRaWAN solutions provide reliable connectivity to enable efficient farming practices.

2. Asset Tracking: From logistics to supply chain management, tracking assets in real-time is crucial. Cisco’s LoRaWAN solutions enable accurate and cost-effective asset tracking, enhancing operational efficiency.

3. Smart Cities: LoRaWAN is vital in building smart cities. It allows municipalities to monitor and manage various aspects, such as parking, waste management, and street lighting. Cisco’s LoRaWAN solutions provide the necessary infrastructure to support these initiatives.

As the IoT ecosystem expands, the choice of access technologies becomes critical to ensure seamless connectivity and efficient data exchange. Wi-Fi, cellular networks, Bluetooth, Zigbee, and LoRaWAN are examples of today’s diverse IoT access technologies.

By understanding the strengths and limitations of each technology, businesses and individuals can make informed decisions about which access technology best suits their IoT applications. As we embrace the connected future, IoT access technologies will continue to evolve, enabling us to unlock the full potential of the Internet of Things.

IoT Access Technologies Closing Points

Wi-Fi is one of the most widely used access technologies in IoT. It offers high data rates, making it ideal for applications that require significant bandwidth, such as video streaming from security cameras or data transfers from smart appliances. However, Wi-Fi networks typically have limited range, which may necessitate additional infrastructure for widespread IoT deployments. Its widespread adoption in residential and commercial settings makes Wi-Fi a popular choice for many IoT applications

Cellular networks provide a robust solution for IoT devices that require mobility and extensive coverage. Technologies like 4G LTE and the emerging 5G networks offer high-speed data connections over large distances, making them perfect for applications such as connected vehicles and remote monitoring systems. The ability to maintain connectivity while moving and the potential for low-latency communication with 5G make cellular networks a pivotal component in the IoT landscape.

Low Power Wide Area Networks (LPWAN) are designed specifically for IoT applications that require long-range connectivity with minimal power consumption. Technologies such as LoRaWAN and Sigfox excel in scenarios where devices need to operate for extended periods without frequent battery replacements, such as in environmental monitoring or smart agriculture. These networks typically offer lower data rates, but their energy efficiency and extensive coverage make them ideal for specific IoT use cases.

For IoT applications that require short-range communication, Bluetooth and Zigbee are popular choices. Bluetooth is widely used in personal devices like wearables and health monitors due to its low power consumption and ease of integration. Zigbee, on the other hand, is often employed in smart home ecosystems, providing reliable mesh networking capabilities that enhance device-to-device communication within a limited area. Both technologies offer solutions for specific IoT scenarios where proximity and power efficiency are priorities.

Interactive IoT Deployment Challenge

Choose the Right Connectivity Architecture

Apply the engineering trade-offs from this article to a realistic deployment scenario.

1. Read the Scenario
Identify the dominant requirements before selecting a connectivity technology.
Scenario

A logistics company needs to deploy battery-powered sensors across a large agricultural site. The sensors transmit small amounts of telemetry several times per hour and must operate for years without frequent battery replacement.

Coverage Very high
Power budget Very low
Bandwidth Low
Mobility Moderate
Which connectivity technology is the strongest fit?
2. Engineering Assessment
Make your decision first. The assessment explains why the technology fits — or does not fit — the workload.
Select a technology and evaluate your choice.
Challenge Progress 0 / 1
rsz_199362bc73d551930019b45770c60b76

ACUNETIX – Web Application Security

by Blog

Web Application Security

Hello, I did a tailored package for ACUNETIX. We split a number of standard blogs into smaller ones for SEO. There are lots of ways to improve web application security so we covered quite a lot of bases in the package.

“So why is there a need for true multi-cloud capacity? The upsurge of the latest applications demands multi-cloud scenarios. Firstly, organizations require application portability amongst multiple cloud providers. Application uptime is a necessity and I.T organizations cannot rely on a single cloud provider to host the critical applications. Besides, lock-in I.T organizations don’t want to have their application locked into specific cloud frameworks. Hardware vendors have been doing this since the beginning of time, thereby, locking you to their specific life cycles. Within a cloud environment that has been locked into one provider means, you cannot easily move your application from one provider to another.

Thirdly, cost is one of the dominant factors. Clouds are not a cheap resource and the pricing models vary among providers, even for the same instance size and type. With a multi-cloud strategy in place, you are in a much better position to negotiate the price.”

The World Wide Web (WWW) has transformed from simple static content to serving the dynamic world of today. The remodel has essentially changed the way we communicate and do business. However, now we are experiencing another wave of innovation in the technologies. The cloud is becoming an even more diverse technology compared to the former framework. The cloud has evolved into its second decade of existence, which formulates and drives a new world of cloud computing and application security. After all, it has to overtake the traditional I.T by offering an on-demand elastic environment. It largely affects how the organizations operate and have become a critical component for new technologies.

The new shift in cloud technologies is the move to ‘multi-cloud designs’, which is a big game-changer for application security. Undoubtedly, multi-cloud will become a necessity for the future but unfortunately, at this time, it is miles apart from a simple move. It is a fact, that not many have started their multi-cloud journey. As a result, there are a few lessons learned, which can expose your application stack to security risks unless you were to hire a professional Web Application Company that will develop and maintain the security of your new application within the cloud for you and your business, opting for this method can mean having a dedicated IT specialist company that can be of service should anything go awry.

Reference architecture guides are a great starting point, however, there are many unknowns when it comes to multi-cloud environments. To take advantage of these technologies, you need to move with application safety in mind. Applications don’t care what cloud technology they lay in. What is significant is, that they need to be operational and hardened with appropriate security.”

“In the early 2000s, we had simple shell scripts created to take down a single web page. Usually, one attacking signature was used from one single source IP address. This was known as a classical Bot based attack, which was effective in taking down a single web page. However, this type of threat needed a human to launch every single attack. For example, if you wanted to bring ten web applications to a halt, you would need to hit “enter” on the keyboard ten times.

We then started to encounter the introduction of simple scripts compiled with loops. Under this improved attack, instead of hitting the keyboard every time they wanted to bring down a web page, the bad actor would simply add the loop to the script. The attack still used only one source IP address and was known as the classical denial of service (DoS).

Thus, the cat and mouse game continued between the web application developers and the bad actors. The patches were quickly released. If you patched the web application and web servers in time, and as long as a good design was in place, then you could prevent these types of known attacks.”

“The speed at which cybersecurity has evolved over the last decade has taken everyone by surprise. Different types of threats and methods of attack have been surfacing consistently, hitting the web applications at an alarming rate. Unfortunately, the foundations of web application design were not laid with security in mind. Therefore, the dispersed design and web servers continue to pose challenges to security professionals.

If the correct security measures are not in place, the existing well-known threats that have been around for years will infuse application downtime and data breaches. Here the prime concern is that if security professionals are unable to protect themselves against today’s web application attacks, how would they fortify against the unknown threats of tomorrow?

The challenges that we see today are compounded by the use of Artificial Intelligence (AI) by cybercriminals. Cybercriminals already have an extensive arsenal at their disposal but to make matters worse, they now have the capability to combine their existing toolkits with the unknown power of AI.”

“The cloud API management plane is one of the most significant differences between traditional computing and cloud computing. It offers an interface, which is often public, to connect the cloud assets. In the past, we followed the box-by-box configuration mentality, where we configured the physical hardware stringed by the wires. However, now, our infrastructure is controlled with an application programming interface (API) calls.

The abstraction of virtualization is aided by the use of APIs, which are the underlying communication methods for assets within a cloud. As a result of this shift of management paradigm, compromising the management plane is like winning unfiltered access to your data center, unless proper security controls to the application level are in place.”

“As we delve deeper into the digital world of communication, from the perspective of privacy, the impact of personal data changes in proportion to the way we examine security. As organizations chime in this world, the normal methods that were employed to protect data have now become obsolete. This forces the security professionals to shift their thinking from protecting the infrastructure to protecting the actual data. Also, the magnitude at which we are engaged in digital business makes the traditional security tools outdated. Security teams must be equipped with real-time visibility to fathom what’s happening all the way up at the web application layer. It is a constant challenge to map all the connections we are building and the personal data that is spreading literally everywhere. This challenge must be addressed not just from the technical standpoint but also from the legal and legislative context.

With the arrival of new General Data Protection Regulation (GDPR) legislation, security professionals must become data-centric. As a result, they no longer rely on traditional practices to monitor and protect data along with the web applications that act as a front door to the user’s personal data. GDPR is the beginning of wisdom when it comes to data governance and has more far-reaching implications than one might think of. It has been predicted that by the end of 2018, more than 50% of the organizations affected by GDPR, will not be in full compliance with its requirements.”

“Cloud computing is the technology that equips the organizations to fabricate products and services for both internal and external usage. It is one of the exceptional shifts in the I.T industry that many of us are likely to witness in our lifetimes. However, to align both; the business and operational goals, cloud security issues must be addressed by governance and not just treated as a technical issues. Essentially, the cloud combines resources such as central processing unit (CPU), Memory, and Hard Drives and places them into a virtualized pool. Consumers of the cloud can access the virtualized pool of resources and can allocate them in accordance to the requirement. Upon completion of the task, the assets are released back into the pool for future use.

Cloud computing represents a shift from a server-service-based approach, eventually, offering significant gains to businesses. However, these gains are often eroded when the business’s valuable assets, such as web applications, become vulnerable to the plethora of cloud security threats, which are like a fly in the ointment.”

“Firewall Designs & the Evolving Security Paradigm The firewall has weathered through a number of design changes. Initially, we started with a single chunky physical firewall and prayed that it wouldn’t fail. We then moved to a variety of firewall design models such as active-active and active-backup mode. The design of active-active really isn’t a true active-active due to certain limitations. However, the active-backup leaves one device, which is possibly quite expensive, left idle sitting there, waiting to take over in the event of primary firewall failover.

We now have the ability to put firewalls in containers. At the same time, some vendors claim that they can cluster up to eight firewalls creating one big active firewall. While these introductions are technically remarkable, nevertheless, they are complex as well. Anything complexity involved in security is certainly a volatile place to dock a critical business application.”

“Introduction Internet Protocol (IP) networks provide services to customers and businesses across the sphere. Everything and everyone is practically connected in some form or another. As a result, the stability and security of the network and the services that ride on top of IP are of paramount importance for successful service delivery. The connected world banks on IP networks and as the reliance mushrooms so does the level of network and web application attacks. Although the new technologies may offer services that simplify life and facilitate businesses to function more efficiently but in certain scenarios, they change the security paradigms which introduce oodles of complexities.

Alloying complexity with security is like stirring the water in oil which would eventually result in a crash. We operate in a world where we need multiple layers of security and updated security paradigms in order to meet the latest application requirements. Here, the significant questions to be pondered over are, can we trust the new security paradigms? Are we comfortable withdrawing from the traditional security model of well-defined component tiers? How does the security paradigm appear from a security auditor’s perspective?”

“Part One in this two-part series looked at the evolution of network architecture and how it affects security. Here we will take a deeper look at the security tools needed to deal with these changes. The Firewall is not enough Firewalls in three-tier or leaf and spine designs are not lacking features; this is not the actual problem. They are fully-featured rich. The problem is with the management of Firewall policies that leave the door wide open. This might invite a bad actor to infiltrate the network and laterally move throughout searching to compromise valuable assets on a silver platter. The central Firewall is often referred to as a “holy cow” as it contains so many unknown configured policies that no one knows what are they used for what. Have you ever heard of the 20-year-old computer that can be pingable but no one knows where it is or has there been any security patches in the last decade?

Having a poorly configured Firewall, no matter how feature-rich it is, it poses the exact same threat as a 20-year-old unpatched computer. It is nothing less than a fly in the ointment. Over the years, the physical Firewall will have had many different security administrators. The security professionals leave jobs every couple of years. And each year the number of configured policies on the Firewall increase. When the security administrator leaves his or her post, the Firewall policy stays configured but is often undocumented. Yet the rule may not even be active anymore. Therefore, we are left with central security devices with thousands of rules that no one fully understands but are still parked like deadwood.”

“The History of Network Architecture The goal of any network and its underlying infrastructure is simple. It is to securely transport the end user’s traffic to support an application of some kind without any packet drops which may trigger application performance problems. Here a key point to consider is that the metrics engaged to achieve this goal and the design of the underlying infrastructure derives in many different forms. Therefore, it is crucial to tread carefully and fortify the many types of web applications comfortably under an umbrella of hardened security. The network design has evolved over the last 10 years to support the new web application types and the ever-changing connectivity models such as remote workers and Bring Your Own Device (BYOD).”

“Part 1 in this series looked at Online Security and the flawed protocols it lays upon. Online Security is complex and its underlying fabric was built without security in mind. Here we shall be exploring aspects of Application Security Testing. We live in a world of complicated application architecture compounds with poor visibility leaving the door wide open for compromise. Web Applications Are Complex The application has transformed from a single server app design to a multi-tiered architecture, which has rather opened Pandora’s Box.

To complicate application security testing further, multiple tiers have both firewalling and load balancing between tiers, implemented with either virtualized or physical appliances. Containers and microservices introduce an entirely new wave of application complexity. Individual microservices require cross-communication, yet potentially located in geographically dispersed data centers.”

“A plethora of valuable solutions now run on web-based applications. One could argue that web applications are at the forefront of the world. More importantly, we must equip them with appropriate online security tools to barricade against the rising web vulnerabilities. With the right toolset at hand, any website can shock-absorb known and unknown attacks. Today the average volume of encrypted internet traffic is greater than the average volume of unencrypted traffic. Hypertext Transfer Protocol (HTTPS) is good but it’s not invulnerable. We see evidence of its shortcoming in the Heartbleed Bug where the compromise of secret keys was made possible. Users may assume that they see HTTPS in the web browser and that the website is secured.”

CacheFly-Logo-5x3

Cachefly CDN

by Blog

I recently completed a few guest posts for Cachefly CDN. Kindly follow the link – Post 1 – Matt Conran & Cachefly, Post 2 – Matt Conran & Anycast and Post 3 – Matt Conran & TCP Anycast.

“We are witnessing a hyperconnectivity era with everything and anything pushed to the Internet to take advantage of its broad footprint. Users are scattered everywhere and they all want consistent service independent of connected device or medium. Everyone has high expectations and no one is willing to wait for a slow page load or buffered video. Nowadays, service performance is critical but are today’s protocols prepared for this new age of connectivity?”

 

 

corsalogo

Corsa Technologies DDoS White Paper

by Blog

I recently completed a white paper for Corsa Technologies on DDoS Mitigation. Kindly visit the link and register to download – Matt Conran & Corsa Technologies.

“This white paper addresses some of the key concerns of today’s approach and technologies used to deal with the increasing volume of DDoS attacks. It introduces a radically simplified, yet high-performance approach to network security that shuts down even the most intense attacks. Today’s threat landscape is intensifying, and it’s not going away anytime soon. The number of infected Internet of Things (IoT) devices continues to surge with the release of the Mirai source code and appearance of the Leet Botnet. Multi-vector sophisticated attacks are targeting popular domains and new Android malware is swallowing the mobile world. The ubiquitous nature of the always on cell phone introduces a lot of scary things.”

 

 

 

 

 

 

 

multipath tcp

Multipath TCP

by Blog

Multipath TCP

In a world where devices routinely have access to multiple networks, relying on a single network path can introduce unnecessary limitations. A smartphone may have both Wi-Fi and cellular connectivity. A server may have multiple interfaces or upstream paths. Edge and cloud environments may also have several available network connections.

Traditional TCP establishes a connection using a single end-to-end path. Multipath TCP (MPTCP) extends TCP so that a single logical connection can use multiple TCP subflows across different network paths.

Rather than creating separate application connections for each interface, MPTCP allows the endpoints to coordinate multiple paths as part of the same logical transport connection.

How MPTCP Works

An MPTCP connection begins with a normal TCP-style connection establishment, but the endpoints negotiate MPTCP capability.

Once MPTCP is established, additional subflows can be created. Each subflow behaves as an individual TCP flow while remaining associated with the same overall MPTCP connection.

For example, a mobile device might have:

Wi-Fi → Subflow 1

5G → Subflow 2

Both subflows can contribute to the same application-level connection.

The MPTCP implementation can then determine how traffic should be distributed across the available paths.

This separation between the logical connection and the underlying subflows is one of the key concepts behind MPTCP.

More Than Simple Load Balancing

It is tempting to think of MPTCP as simply combining the bandwidth of multiple interfaces. In reality, path selection and packet scheduling are more complex.

Different paths can have different:

  • Latency

  • Bandwidth

  • Packet loss

  • Congestion levels

  • Costs

  • Reliability

  • Available capacity

An MPTCP implementation can use this information when deciding how to schedule traffic across its subflows.

A fast Wi-Fi connection might carry most of the traffic while a cellular path provides additional capacity or acts as a backup. Alternatively, both paths may actively carry traffic depending on the implementation and network conditions.

Resilience and Connection Continuity

One of the strongest advantages of MPTCP is path resilience.

Consider a mobile device transferring data over Wi-Fi while also maintaining an available cellular path. If the Wi-Fi connection becomes unavailable, the MPTCP connection can continue using the cellular subflow rather than requiring the application to establish an entirely new transport connection.

This can be particularly valuable for mobile applications where network conditions change frequently.

The important distinction is that MPTCP can preserve the logical transport connection while individual network paths appear and disappear underneath it.

Congestion Control and Fairness

Using multiple paths introduces another challenge: congestion control.

If multiple subflows were allowed to behave as completely independent TCP connections, an MPTCP connection could potentially consume more than its fair share of capacity when competing with conventional TCP traffic.

MPTCP therefore uses multipath congestion-control mechanisms designed to coordinate the behaviour of its subflows.

This allows the protocol to consider the combined connection while still responding to congestion on individual paths.

Consequently, MPTCP is not simply “TCP multiplied by the number of interfaces.” It requires coordination between path management, congestion control, packet scheduling, and connection state.

Mobile and Heterogeneous Networks

MPTCP is particularly interesting in environments where connectivity changes dynamically.

A mobile device may move between different wireless environments while retaining access to cellular connectivity. Instead of treating each network transition as an entirely new connection, MPTCP can maintain multiple subflows and adapt as paths become available or unavailable.

This makes MPTCP useful for scenarios involving:

Mobile connectivity: combining or switching between Wi-Fi and cellular networks.

Multi-homed servers: using multiple network interfaces or upstream connections.

Data centres and cloud platforms: exploiting multiple network paths where the underlying architecture supports them.

Edge computing: maintaining connectivity across heterogeneous access networks.

Resilient applications: reducing the impact of individual path failures.

MPTCP and Modern Networking

MPTCP also illustrates an important principle in modern networking: the application does not necessarily need to understand the physical network paths being used underneath it.

The application can maintain a single logical connection while the transport layer manages multiple underlying paths.

This can simplify application design while allowing the network stack to make decisions about path availability and performance.

However, MPTCP is not universally applicable. Both endpoints need appropriate MPTCP support, and middleboxes, firewalls, NAT devices, network policies, and infrastructure configurations can affect how successfully multipath connections operate.

There can also be trade-offs involving additional signalling, packet scheduling, congestion control, energy consumption, and the cost of using multiple networks simultaneously.

The Future of Multipath Connectivity

The importance of multipath networking is increasing as devices and infrastructure become more heterogeneous.

Users and applications increasingly operate across Wi-Fi, cellular, wired, cloud, and edge environments simultaneously. MPTCP provides a transport-layer mechanism for taking advantage of that diversity while maintaining a single logical connection.

Its most important contribution is therefore not simply additional bandwidth.

MPTCP provides a mechanism for combining multiple network paths while improving resilience, maintaining connection continuity, and allowing transport decisions to adapt to changing network conditions.

As networking continues to evolve toward multi-access, edge computing, cloud connectivity, and highly mobile environments, multipath transport provides an important foundation for building applications that can operate across increasingly diverse network paths.

Interactive MPTCP Architecture

One Connection. Multiple Paths.

Compare how conventional TCP uses a single path while MPTCP can maintain multiple TCP subflows within one logical connection.

💻
Client Application
Single TCP path
☁️
Server Application
Traditional TCP A TCP connection normally follows one selected network path. If that path becomes congested or unavailable, the connection is affected.
MPTCP MPTCP can create additional subflows across different paths while maintaining one logical connection to the application.
Key idea: MPTCP does not require the application to manage each path independently. The transport layer abstracts the multiple subflows into a single connection.

Highlights: Multipath TCP

At its core, MPTCP is an extension of the conventional Transmission Control Protocol (TCP), designed to improve network resource utilization and increase resilience by allowing multiple paths for data transmission. This means data packets can be sent over several network interfaces simultaneously, optimizing speed and reliability.

The traditional TCP protocol uses a single network path for communication, which can lead to bottlenecks and inefficiencies, especially in environments with fluctuating network conditions. Multipath TCP, on the other hand, breaks away from this limitation by enabling a session to split across multiple paths. This is particularly useful in mobile environments, where devices often switch between different networks such as Wi-Fi and cellular data. By leveraging multiple paths, MPTCP ensures that if one path fails or becomes congested, others can take over seamlessly, maintaining a stable connection.

Adopting MPTCP

– MPTCP is an extension of the traditional Transmission Control Protocol (TCP) that enables the establishment of multiple sub-flows within a single TCP connection. This means that data can be simultaneously transmitted over different network paths, such as Wi-Fi and cellular networks, providing increased throughput and improved resilience against network failures.

– One of the primary advantages of MPTCP is its ability to utilize the combined bandwidth of multiple network paths, resulting in faster data transfer rates. Additionally, MPTCP offers enhanced reliability by dynamically adapting to network conditions and rerouting data if a path becomes congested or fails. This makes it particularly useful in scenarios with a stable and high-bandwidth connection, such as streaming multimedia content or real-time applications, which is crucial.

How Multipath TCP Works:

A) MPTCP operates by establishing a regular TCP connection between two endpoints, known as the initial subflow. It then negotiates with the remote endpoint to create additional subflows over different network paths.

B) These subflows are managed by a central entity called the MPTCP scheduler, which ensures efficient data distribution across the available paths. By splitting the data into smaller chunks and assigning them to different subflows, MPTCP enables parallel transmission and optimal resource utilization.

C) The versatility of MPTCP opens up exciting possibilities for various applications. MPTCP can seamlessly switch between different networks in mobile devices, providing uninterrupted connectivity and improved user experience. It also holds great potential in cloud computing, where it can enable efficient data transfers across multiple data centers, reducing latency and enhancing overall performance.

Critical Benefits of Multipath TCP:

1. Improved Performance: MPTCP can distribute the data traffic using multiple paths, enabling faster transmission rates and reducing latency. This enhanced performance is particularly beneficial for bandwidth-intensive applications such as streaming, file transfers, and video conferencing, where higher throughput and reduced latency are crucial.

2. Increased Resilience: MPTCP enhances network resilience by providing seamless failover capabilities. In traditional TCP, if a network path fails, the connection is disrupted, resulting in a delay or even a complete loss of service. However, with MPTCP, if one path becomes unavailable, the connection can automatically switch to an alternative path, ensuring uninterrupted communication.

3. Efficient Resource Utilization: MPTCP allows for better utilization of available network resources. Distributing traffic across multiple paths prevents congestion on a single path and optimizes the usage of available bandwidth. This results in more efficient utilization of network resources and improved overall performance.

4. Seamless Transition between Networks: MPTCP is particularly useful in scenarios where devices need to switch between different networks seamlessly. For example, when a mobile device moves from a Wi-Fi network to a cellular network, MPTCP can maintain the connection and seamlessly transfer the ongoing data traffic to the new network without interruption.

5. Compatibility with Existing Infrastructure: MPTCP is designed to be backward compatible with traditional TCP, making it easy to deploy and integrate into existing network infrastructure. It can coexist with legacy TCP connections and gradually adapt to MPTCP capabilities as more devices and networks support the protocol.

**TCP restricts communication**

Multiple paths connect hosts, but TCP restricts communications to a single path per transport connection. Multiple paths could be used concurrently within the network to maximize resource usage. Improved resilience to network failures and higher throughput should enhance the user experience.

Due to protocol constraints both on the end systems and within the network, Internet resources (particularly bandwidth) are often not fully utilized as the Internet evolves. The end-user experience could be significantly improved if these resources were used simultaneously.

A similar improvement in user experience could also be achieved without as much expenditure on network infrastructure. In resource pooling, these available resources are ‘pooled’ into one logical resource for the user.

**The goal of resource pooling**

As part of multipath transport, disjoint (or partially disjoint) paths across a network are simultaneously used to achieve some of the goals of resource pooling. In addition to increasing resilience, multipath transport protects end hosts from failures on one path. As a result, network capacity can be increased by improving resource utilization efficiency. In a multipath TCP connection, multiple paths are pooled transparently within a transport connection to achieve multipath TCP goals.

When one or both hosts are multihomed, multipath TCP uses multiple paths end-to-end. A host can also manipulate the network path by changing port numbers with Equal Cost MultiPath (ECMP), for example, to create multiple paths within the network.

**Multipath TCP and TCP**

Multipath TCP (MPTCP) is a protocol extension that allows for the simultaneous use of multiple network paths between two endpoints. Traditionally, TCP (Transmission Control Protocol) relies on a single path for data transmission, which can limit performance and reliability. With MPTCP, multiple paths can be established between the sender and receiver, enabling the distribution of traffic across these paths. This offers several advantages, including increased throughput, better load balancing, and improved resilience against network failures.

**Automatically Set Up Multiple Paths**

It is designed to automatically set up multiple paths between two endpoints and use those paths to send and receive data efficiently. It also provides a mechanism for detecting and recovering from packet loss and for providing low-latency communication. MPTCP is used in applications that require high throughput and low latency, such as streaming media, virtual private networks (VPNs), and networked gaming. MPTCP is an extension to the standard TCP protocol and is supported by most modern operating systems, including Windows, macOS, iOS, and Linux.

**High Throughput & Low Latency**

MPTCP is an attractive option for applications that require high throughput and low latency, as it can provide both. Additionally, it can provide fault tolerance and redundancy, allowing an application to remain operational even if one or more of its paths fail. This makes it useful for applications such as streaming media, where high throughput and low latency are essential, and reliability is critical.

Understanding TCP Performance Parameters

TCP performance parameters are settings that can be tweaked to fine-tune the behavior of the TCP protocol. These parameters dictate how TCP handles congestion control, window size, retransmission, and more. By understanding the impact of each parameter, network administrators can optimize TCP for specific use cases and network conditions.

Congestion Control and Window Size: Congestion control is vital to TCP performance. It ensures that the network does not become overwhelmed with excessive data. Network engineers can balance throughput and network utilization by adjusting TCP congestion control algorithms and window sizes. 

Retransmission and Timeout: TCP retransmission and timeout mechanisms ensure reliable data delivery. By fine-tuning retransmission parameters such as RTO (Retransmission Timeout), SRTT (Smoothed Round Trip Time), and RTO Min/Max, network administrators can optimize TCP’s ability to recover from lost packets efficiently. There are a number of trade-offs between aggressive and conservative retransmission strategies and examine how different timeout values impact overall performance.

Buffer Sizes and Burstiness: Buffers are temporary storage areas that hold data during transmission. Properly sizing TCP buffers is essential for maximizing performance. Oversized buffers can lead to increased latency and buffer bloat, while undersized buffers can cause packet loss. There are a number of intricacies of buffer sizing and techniques like Active Queue Management (AQM) to mitigate buffer-related issues.

What is TCP MSS?

TCP MSS, or Maximum Segment Size, refers to the maximum amount of data encapsulated in a single TCP segment. It determines the payload size sent within a TCP packet, excluding the TCP header. The MSS value is negotiated during the TCP handshake process, allowing both the sender and receiver to agree upon an optimal segment size for communication.

The TCP MSS value directly affects network performance and efficiency. It impacts the amount of data that can be transmitted in a single packet, affecting a network connection’s overall throughput and latency. Understanding and optimizing the TCP MSS value can significantly improve application performance and reduce unnecessary overhead.

Several factors can influence the TCP MSS value used in a network connection. One primary factor is the underlying network infrastructure’s Maximum Transmission Unit (MTU). The TCP MSS is typically set to match the MTU to avoid fragmentation and improve efficiency. Additionally, network devices, such as routers and firewalls, can enforce specific MSS values, leading to further variations.

It is crucial to consider the network environment and characteristics to optimize TCP MSS for better performance. Understanding the MTU limitations and adjusting the MSS value accordingly can prevent fragmentation and enhance data transmission. Network administrators can also employ Path MTU Discovery techniques to dynamically adjust the MSS value based on the path characteristics between the communicating devices.

 

Interactive Failure Simulation

Break a Path — Keep the Connection Alive

Disable individual MPTCP subflows and observe how the logical connection responds.

1. Control the Subflows
Simulate a path failure. MPTCP can continue using the remaining available subflows.
MPTCP Session Established
Subflow 1 — Wi-Fi Active
Subflow 2 — Cellular Active
Subflow 3 — Secondary Active
2. Observe the Connection
The application sees one logical MPTCP connection even though traffic may be moving across several subflows.
💻
Client Application
☁️
Server Application
All three subflows are carrying traffic. The MPTCP session has multiple available paths and can distribute traffic between them.

Multipath TCP

Reliable byte streams

To start the discussion on multipath TCP, we must understand the basics of Transmission Control Protocol (TCP) and its effect on IP Forwarding. TCP applications offer reliable byte streams with congestion control mechanisms that adjust flows to the current network load. Designed in the 1970s, TCP is the most widely used protocol and remains unchanged, unlike the networks it operates within. In those days, the designers understood there could be link failure and decided to decouple the network layer (IP) from the transport layer (TCP).

Required: Multipath Routing

This enables the routing with IP around link failures without breaking the end-to-end TCP connection. Dynamic routing protocols such as BGP Multipath do this automatically without the need for transport layer knowledge. Even though it has wide adoption, it does not fully align with the multipath networking requirements of today’s networks, driving the need for MP-TCP.

Challenge: Default TCP Operation

TCP delivers reliability using distinct variations of the techniques. Because it provides a byte stream interface, TCP must convert a sending application’s stream of bytes into a set of packets that IP can carry. This is called packetization. These packets contain sequence numbers, which in TCP represent the byte offsets of the first byte in each packet in the overall data stream rather than packet numbers. This allows packets to be of variable size during a transfer and may also allow them to be combined, called repacketization.

Challenge: Single Path Connection Protocol

TCP’s main drawback is that it’s a single path per connection protocol. A single path means once the stream is placed on a path ( endpoints of the connection), it can not be moved to another path even though multiple paths may exist between peers. This characteristic is suboptimal as most of today’s networks and end hosts have multipath characteristics for better performance and robustness.

What is Multipath TCP?

A) Multipath TCP, also known as MPTCP, is an extension to the traditional TCP protocol that allows a single TCP connection to utilize multiple network paths simultaneously. Unlike conventional TCP, which operates on a single path, MPTCP offers the ability to distribute the traffic across multiple paths, enabling more efficient resource utilization and increased overall network capacity.

Multiple Paths for a Single TCP Session

B) Using multiple paths for a single TCP session increases resource usage and resilience for TCP optimization. Additional extensions added to regular TCP simultaneously enable connection transport across multiple links.

C) The core aim of Multipath TCP (MP-TCP) is to allow a single TCP connection to use multiple paths simultaneously by using abstractions at the transport layer. As it operates at the transport layer, the upper and lower layers are transparent to its operation. No network or link-layer modifications are needed.

D) There is no need to change the network or the end hosts. The end hosts use the same socket API call, and the network continues to operate as before. No unique configurations are required as it’s a capability exchange between hosts. Multipath TCP enabling multipath networking is 100% backward compatible with regular TCP.

Multipath TCP
Diagram: Multipath TCP. Source is Cisco

TCP sub flows

MPTCP achieves its goals through sub-flows of individual TCP connections forming an MPTCP session. These sub-flows can be established over different network paths, allowing for parallel data transmission. MPTCP also includes mechanisms for congestion control and data sequencing across the sub-flows, ensuring reliable packet delivery.

MP-TCP binds a TCP connection between two hosts, not two interfaces, like regular TCP. Regular TCP connects two IP endpoints by establishing a source/destination by IP address and port number. The application has to choose a single link for the connection. However, MPTCP creates new TCP connections known as sub-flows, allowing the application to take different links for each subflow. 

Subflows are set up the same as regular TCP connections. They consist of a flow of TCP segments operating over individual paths but are still part of the overall MPTCP connection. Subflows are never fixed and may fluctuate in number during the lifetime of the parent Multipath TCP connection.

Multipath TCP uses cases.

The deployment of MPTCP has the potential to benefit various applications and use cases. For example, MPTCP can enable seamless handovers between cellular towers or Wi-Fi access points in mobile networks, providing uninterrupted connectivity. MPTCP can improve server-to-server communications in data centers by utilizing multiple links and avoiding congestion.

Multipath TCP is beneficial in multipath data centers and mobile phone environments. All mobiles allow you to connect via wifi and a 3G network. MP-TCP enables the combined throughput and the switching of interfaces (wifi / 3G ) without disrupting the end-to-end TCP connection.

For example, if you are currently on a 3G network with an active TCP stream, the TCP stream is bound to that interface. If you want to move to the wifi network, you need to reset the connection, and all ongoing TCP connections will reset. With MP-TCP, the swapping of interfaces is transparent.

Multipath networking: leaf-spine data center

Leaf and spine data centers are a revolutionary networking architecture that has revolutionized connectivity in modern data centers. Unlike traditional hierarchical designs, leaf and spine networks are based on a non-blocking, fully meshed structure. The leaf switches act as access points, connecting directly to the spine switches, creating a flat network topology.

Critical Characteristics of Leaf and Spine Data Centers

One key characteristic of leaf and spine data centers is their scalability. With their non-blocking architecture, leaf and spine networks can easily accommodate the increasing demands of modern data centers without sacrificing performance. Additionally, they offer low latency, high bandwidth, and improved resiliency compared to traditional designs.

Next-generation leaf and spine data center networks are built with Equal-Cost Multipath (ECMP). Within the data center, any two endpoints are equidistant. For one endpoint to communicate with another, a TCP flow is placed on a single link, not spread over multiple links. As a result, single-path TCP collisions may occur, reducing the throughput available to that flow.

This is commonly seen for large flows and not small mice flows. When a server starts a TCP connection in a data center, it gets placed on a path and stays there. With MP-TCP, you could use many sub-flows per connection instead of a single path per connection. Then, if some of those sub-flows get congested, you don’t send over that subflow, improving traffic fairness and bandwidth optimizations.

Hash-based distribution

The default behavior of spreading traffic through a LAG or ECMP next hops is based on the hash-based distribution of packets. First, an array of buckets is created, and each outbound link is assigned to one or more. Next, fields such as source-destination IP address / MAC address are taken from the outgoing packet header and hashed based on this endpoint identification. Finally, the hash selects a bucket, and the packet is queued to the interface assigned to that bucket. 

redundant links
Diagram: Redundant links with EtherChannel. Source is jmcritobal

The issue is that the load-balancing algorithm does not consider interface congestions or packet drops. With all mice flows, this is fine, but once you mix mice and elephant flows together, your performance will suffer. An algorithm is needed to identify congested links and then reshuffle the traffic.

A good use for MPTCP is a mix of mice and elephant flows. Generally, MP-TCP does not improve performance for environments with only mice flows.

Small files, say 50 KB, perform similarly to regular TCP. Multipath networking usually has the same results as link bonding as the file size increases. The benefits of MP-TCP come into play when files are enormous (300 KB ). MP-TCP outperforms link bonding at this level as the congestion control can better balance the load over the links.

MP-TCP connection setup

The connection aims to have a single TCP connection with many sub-flows. The two endpoints using MPTCP are synchronized and have connection identifiers for each sub-flow. MPTCP starts the same as regular TCP. Additional TCP subflow sessions are combined into the existing TCP session if different paths are available. The original TCP and other subflow sessions appear as one to the application, and the primary Multipath TCP connection seems like a regular TCP connection. Identifying additional paths boils down to the number of IP addresses on the hosts. 

The TCP handshake starts as expected, but within the first SYN is a new MP_CAPABLE option ( value 0x0 ) and a unique connection identifier. This allows the client to indicate that they want to do MPTCP. At this stage, the application layer creates a standard TCP socket with additional variables telling it intends to do MPTCP.

If the receiving server end is MP_CAPABLE, it will reply with the SYN/ACK MP_CAPABLE and its connection identifier. Once the connection is agreed upon, the client and server will set up the upstate. Inside the kernel, a Meta socket is the layer between the application and all the TCP sub-flows.

Under a multipath condition and when multiple paths are detected (based on IP addresses), the client starts a regular TCP handshake with the MP_JOIN option (value 0x1) and uses the connection identifier for the server. The server then replies with a subflow setup. New sub-flows are created, and the scheduler will schedule over each sub-flow as the data is sent from the application to the meta socket. 

TCP sequence numbers 

Regular TCP uses sequence numbers, enabling the receiving side to return packets in the correct order before sending them to the application. The sender can determine which packets are lost by looking at the ACK.

For MP-TCP, packets must travel multiple paths, so sequence numbers are needed to restore packet order before they are passed to the application. The sequence numbers also inform the sender of any packet loss on a path. When an application sends a packet, the segment is assigned a data sequence number.

TCP looks at the sub-flows to see where to send this segment. When it ships on a subflow, it uses a sequence number and puts it in the TCP header, and the other data sequence number gets set in the TCP options. 

The sequence number on the TCP header informs the client of any packet loss. The recipient also uses the data sequence number to reorder packets before sending them to the application.

Congestion control

Congestion control was never a problem in circuit switching. Resources are reserved at call setup to prevent congestion during data transfer, resulting in a lot of bandwidth underutilization due to the reservation of circuits. We then moved to packet switching, where we had a single link with no reservation, but the flows could use as much of the link as they wanted. This increases the utilization of the link and also the possibility of congestion.

To help this situation, congestion control mechanisms were added to TCP. Similar TCP congestion control mechanisms are employed for MP-TCP. Standard TCP congestion control maintains a congestion window for each connection, and you increase the window size on each ACK. With a drop, you half the window. 

MP-TCP operates similarly. You maintain one congestion window for each subflow path. Similar to standard TCP, when you have a drop on a subflow, you have half the window for that subflow. However, the increased rules are different from expected TCP behavior.

It gives more of an increase for sub-flows with a larger window. A larger window means it has a lower loss. As a result, traffic moves from congested to uncongested links dynamically.

Closing Points on MP-TCP

At its core, Multipath TCP operates by distributing data packets across multiple paths between a client and server. This process, known as multipath routing, allows for simultaneous use of various network interfaces, such as Wi-Fi and cellular data. By dynamically managing these paths, MPTCP can reroute traffic in response to network congestion or failures, ensuring a seamless and uninterrupted connection. This section delves into the technical intricacies of MPTCP, exploring how it negotiates paths, manages data packets, and maintains connection stability.

The adoption of Multipath TCP brings a plethora of benefits to both consumers and enterprises. For end-users, it means faster download speeds and a more stable internet connection, even in challenging environments. Businesses can leverage MPTCP to enhance the performance of their network applications, ensuring high availability and improved user experiences. Additionally, MPTCP contributes to better load balancing and resource utilization across network infrastructures. This section highlights the key advantages of integrating MPTCP into modern networking solutions.

Multipath TCP is not just a theoretical concept; it has practical applications in various fields. From enhancing mobile networks to optimizing cloud services, MPTCP is making its mark. In mobile devices, MPTCP allows for the simultaneous use of Wi-Fi and cellular networks, providing a more robust connection. In cloud computing, it facilitates efficient resource distribution and redundancy. This section explores real-world use cases, demonstrating how MPTCP is transforming networking across industries.

MPTCP Engineering Decision Lab

When Should You Actually Use MPTCP?

More paths are not automatically better. Evaluate the application, network and failure requirements before choosing a multipath design.

1. Analyse the Deployment
Read the engineering scenario and select the approach you would recommend.
Scenario

A mobile application maintains a long-running TCP session while users move between Wi-Fi and cellular networks. The application should avoid session resets when Wi-Fi becomes unavailable, and additional bandwidth would also be useful when both interfaces are healthy.

Mobility High
Path diversity Wi-Fi + Cellular
Session lifetime Long-lived
Resilience Critical
Which architecture best addresses the requirement?
2. Engineering Assessment
The assessment focuses on the actual requirement rather than simply choosing the technology with the most features.
Select an architecture and evaluate your decision.
Decision Score 0 / 1
Packet loss as a binary code 3D illustration

Dropped Packet Test

by Blog

Dropped Packet Test

In modern networks, reliable packet delivery is fundamental to application performance, voice and video quality, cloud connectivity, and user experience. When packets are dropped, the impact can range from minor retransmissions and increased latency to severe application degradation, unstable sessions, and service outages. The challenge for network engineers is not simply detecting packet loss, but determining where it occurs, under what conditions, and why.

Packet loss occurs when packets transmitted across a network fail to reach their intended destination. The cause may be network congestion, interface errors, overloaded devices, faulty cabling or optics, wireless interference, routing changes, policing, queue drops, MTU problems, or failures elsewhere along the forwarding path. Importantly, an apparent loss observed at one endpoint does not automatically mean that the network is dropping packets; the test method and location of the measurement must also be considered.

A dropped packet test measures packet delivery between a source and destination and can be performed using tools such as ping, traceroute, mtr, pathping, and platform-specific telemetry. Different tests provide different levels of visibility. ICMP echo testing can establish reachability and loss, while traceroute and MTR can help identify where latency or loss appears along a path. For application-specific troubleshooting, TCP or UDP-based tests may provide a more representative view because firewall policies, QoS, load balancing, and security controls can treat different traffic types differently.

The quality of a packet-loss test depends heavily on how it is performed. Engineers should consider packet size, transmission rate, test duration, protocol, source and destination, routing path, and traffic conditions. A short test sending a small number of packets may miss intermittent loss, while an aggressive test can create conditions that do not represent normal application traffic. Testing at different times and from multiple locations can help distinguish persistent faults from congestion or transient network conditions.

Packet loss should also be analysed alongside other measurements rather than treated as an isolated percentage. Latency, jitter, interface error counters, retransmissions, queue drops, CPU utilisation, bandwidth utilisation, routing changes, and application telemetry can provide important context. For example, loss accompanied by increasing interface errors may indicate a physical or Layer 2 problem, while loss during periods of sustained utilisation may point toward congestion or queueing.

Interpreting packet loss therefore requires understanding where the loss begins and whether it continues downstream. A device may legitimately deprioritise or rate-limit ICMP responses without dropping transit traffic, meaning that apparent loss at an intermediate hop does not necessarily indicate a forwarding failure. Comparing results across subsequent hops and examining device telemetry helps distinguish control-plane response behaviour from genuine packet loss affecting the forwarding path.

Once the location and cause of packet loss have been established, engineers can apply targeted remediation. Depending on the evidence, this may involve replacing faulty optics or cabling, correcting interface configuration, addressing congestion, adjusting QoS or queueing policies, resolving MTU inconsistencies, correcting routing behaviour, or increasing capacity. The dropped packet test is therefore most valuable not as a simple pass-or-fail measurement, but as part of a structured network fault-isolation process.

The modern approach is straightforward: measure the path, correlate the evidence, identify where loss begins, determine the underlying cause, and validate the remediation. Used correctly, packet-loss testing provides a practical foundation for troubleshooting network reliability and understanding how real traffic behaves across the infrastructure.

Interactive Packet Loss Lab

Measure the Health of a Network Path

Change the test conditions, run a packet-loss test, and see how loss and latency affect the observed path. The goal is not simply to find a percentage — it is to understand what that percentage means.

Test Parameters
Configure a simplified network test. The simulation generates packets and applies the selected loss and latency conditions.
Packets to send 50
10 100
Packet loss rate 2%
0% 20%
Average latency 30 ms
5 ms 250 ms
Jitter 5 ms
0 ms 100 ms
Test Results
Results are calculated from the simulated packet stream. Try increasing loss or latency and run the test again.
Sent
—
Received
—
Packet Loss
—
Avg Latency
—
Packet stream Waiting for test
Run the test to generate traffic.
Engineering Interpretation
Configure the test and run it to see how packet loss and latency interact.
Key principle: packet loss is only one part of network performance. A path can have zero loss but still deliver poor application performance because of high latency or jitter. Conversely, a small amount of loss may have very different consequences depending on the workload.

Highlights: Dropped Packet Test

**Understanding Packet Loss**

Packet loss occurs when data packets traveling across a network fail to reach their destination. This can happen due to network congestion, hardware failures, software bugs, or even environmental factors. The consequences of packet loss can be severe, leading to slower data transmission, corrupted files, and degraded voice and video communication. For businesses and individuals relying on robust internet connections, minimizing packet loss is essential for maintaining productivity and satisfaction.

**Tools and Techniques for Testing Packet Loss**

Testing for packet loss is a proactive step toward maintaining network health. Several tools and techniques can help identify and quantify packet loss. Ping tests, for example, are a straightforward method where small data packets are sent to a target and any loss is recorded. More advanced tools like Wireshark offer deeper insights by capturing and analyzing network traffic in real-time. These tools help network administrators pinpoint issues, understand the scope of packet loss, and devise strategies for mitigation.

**Interpreting Test Results**

Once testing is complete, interpreting the results is crucial for taking corrective action. A small percentage of packet loss over a short period might be negligible, but sustained or high levels of loss demand attention. Understanding the pattern and frequency of packet loss can guide troubleshooting efforts, whether it’s adjusting network configurations, upgrading hardware, or addressing software issues. Recognizing the symptoms early allows for quicker resolution and less impact on network performance.

Understanding Dropped Packets

1. Dropped packets occur when data fails to reach its intended destination within a network. These packets carry vital information, and any loss or delay can hamper the overall performance of a network. Understanding the causes and consequences of dropped packets is fundamental to optimizing network performance

2. The dropped packet test is an essential diagnostic tool that network administrators and engineers employ to assess the health and efficiency of a network. By intentionally creating scenarios where packets are dropped, it becomes possible to measure the impact on network performance and identify potential weaknesses or areas for improvement.

3. To perform the dropped packet test, various methodologies and tools are available. One commonly used approach involves using network traffic generators to simulate network traffic and intentionally dropping packets at specific points. This allows administrators to evaluate how different network components and configurations handle packet loss and its subsequent impact on overall performance.

4. Once the dropped packet test is completed, it is crucial to analyze the results effectively. Network monitoring tools and packet analyzers can provide detailed insights into packet loss, latency, and other performance metrics. By carefully examining these results, administrators can pinpoint potential bottlenecks, identify problematic network segments, and make informed decisions to optimize performance.

Knowledge Check: Understanding Traceroute

Traceroute basics:

Traceroute, also known as tracert on Windows, is a command-line tool that tracks the route data packets take from one point to another. By sending a series of packets with increasing Time to Live (TTL) values, traceroute reveals the path these packets follow, hopping from one network node to another.

TTL and ICMP:

Traceroute exploits the Time to Live (TTL) field in IP packets and utilizes Internet Control Message Protocol (ICMP) to gather information about the network path. As each packet encounters a node in its journey, if the TTL expires, an ICMP time exceeded message is sent back to the traceroute tool, allowing it to determine the IP address and round-trip time to reach each node.

Network troubleshooting: Traceroute is an invaluable tool for administrators to diagnose and troubleshoot connectivity issues. By identifying the exact network hop where a delay or failure occurs, administrators can pinpoint the problem and take appropriate action to resolve it swiftly.

Identifying potential bottlenecks: Traceroute assists in identifying potential bottlenecks and points of congestion in network paths. This information allows network administrators to optimize their infrastructure, reroute traffic, or negotiate better peering agreements to improve network performance.

Example Product: Cisco ThousandEyes

**Why Network Visibility Matters**

Network visibility is the cornerstone of efficient IT operations. With the proliferation of cloud services, remote work, and global connectivity, traditional network monitoring tools often fall short. They lack the insights needed to understand the entire digital supply chain. This is where ThousandEyes excels. By offering a comprehensive view of network paths, internet health, and application performance, it helps organizations identify and resolve issues before they impact end-users. This proactive approach not only enhances user satisfaction but also ensures business continuity.

**Key Features of Cisco ThousandEyes**

1. **Global Monitoring**: ThousandEyes leverages a vast network of vantage points across the globe to monitor the performance of internet-dependent services. This global reach ensures that businesses can track performance from virtually anywhere in the world.

2. **End-to-End Visibility**: By providing insights into every segment of the network path—from the data center to the end user—ThousandEyes enables businesses to pinpoint where issues occur, whether it’s within their own infrastructure or an external service provider.

3. **Cloud and SaaS Monitoring**: As more businesses migrate to cloud-based services, monitoring these environments becomes crucial. ThousandEyes offers robust monitoring capabilities for cloud platforms and SaaS applications, ensuring they perform optimally.

4. **BGP Route Visualization**: Understanding the routing of data across the internet is essential for troubleshooting and optimizing network performance. ThousandEyes provides detailed BGP route visualizations, helping businesses understand how their data travels and where potential issues might arise.

5. **Alerting and Reporting**: ThousandEyes offers customizable alerting and reporting features, allowing businesses to stay informed about performance issues and trends. This ensures that IT teams can respond quickly to potential problems and maintain high service levels.

**Use Cases and Benefits**

ThousandEyes caters to a wide range of use cases, each offering distinct benefits:

– **Optimizing User Experience**: By monitoring user interactions with applications, businesses can ensure a smooth and responsive experience, which is crucial for customer satisfaction and retention.

– **Enhancing Cloud Performance**: With detailed insights into cloud service performance, organizations can optimize their cloud environments, ensuring reliable and efficient service delivery.

– **Troubleshooting Network Issues**: ThousandEyes’ comprehensive visibility allows IT teams to quickly identify and resolve network issues, minimizing downtime and maintaining productivity.

– **Supporting Remote Work**: As remote work becomes the norm, ThousandEyes helps businesses monitor and optimize the remote user experience, ensuring employees can work efficiently from any location.

Testing For Packet Loss

How do you test for packet loss on a network? The following post provides information on testing packet loss and network packet loss tests. Today’s data center performance has to factor in various applications and workloads with different consistency requirements.

Understanding what is best per application/workload requires a dropped packet test from different network parts. Some applications require predictable latency, while others sustain throughput. The slowest flow is usually the ultimate determining factor affecting end-to-end performance.

The consequences of packet loss can be far-reaching. In real-time communication applications, even a slight loss of packets can lead to distorted audio, pixelated video, or delayed responses. In data-intensive tasks such as cloud computing or online backups, packet loss can result in corrupted files or incomplete transfers. Businesses relying on efficient data transmission can suffer from reduced productivity and customer dissatisfaction.

What is Network Monitoring?

Network monitoring refers to the continuous surveillance and analysis of network infrastructure, devices, and traffic. It involves observing network performance, identifying issues or anomalies, and proactively addressing them to minimize downtime and optimize network efficiency. By monitoring various parameters such as bandwidth usage, latency, packet loss, and device health, organizations can detect and resolve potential problems before they escalate.

a) Proactive Issue Detection: Network monitoring allows IT teams to identify and address potential problems before they impact users or cause significant disruptions. By setting up alerts and notifications, administrators can stay informed about network issues and take prompt action to mitigate them.

b) Improved Network Performance: Continuous monitoring provides valuable insights into network performance metrics, allowing organizations to identify bottlenecks, optimize resource allocation, and ensure smooth data flow. This leads to enhanced user experience and increased productivity.

Understanding Network Scanning

A: Network scanning is a proactive security measure that identifies vulnerabilities, discovers active hosts, and assesses a network’s overall health. It plays a vital role in fortifying the digital fortress by systematically examining the network infrastructure, including computers, servers, and connected devices.

B: Various techniques are employed in network scanning, each serving a unique purpose. Port scanning, for instance, involves scanning for open ports on target devices, providing insights into potential entry points for malicious actors. On the other hand, vulnerability scanning focuses on identifying weaknesses in software, operating systems, or configurations that may be exploited. Other techniques, such as ping scanning, OS fingerprinting, and service enumeration, further enhance the scanning process.

C: Network scanning offers numerous benefits contributing to an organization’s or individual’s security posture. First, it enables proactive identification of vulnerabilities, allowing for timely patching and mitigation. Moreover, regular network scanning aids in compliance with security standards and regulations. Network scanning helps maintain a controlled and secure environment by identifying unauthorized devices or rogue access points.

 What is ICMP?

ICMP is a network-layer protocol that operates on top of the Internet Protocol (IP). It is primarily designed to report errors, exchange control information, and provide feedback about network conditions. ICMP messages are encapsulated within IP packets, allowing them to traverse the network and reach their destinations.

ICMP encompasses a range of message types, each serving a specific purpose. Some common message types include Echo Request (Ping), Echo Reply, Destination Unreachable, Time Exceeded, Redirect, and Address Mask Request/Reply. Each message type carries valuable information about the network and aids in network troubleshooting and management.

Ping and Echo Requests

One of the most well-known uses of ICMP is the Ping utility, which is based on the Echo Request and Echo Reply message types. Ping allows us to test a host’s reachability and round-trip time on the network. Network administrators can assess network connectivity and measure response times by sending an Echo Request and waiting for an Echo Reply.

ICMP plays a vital role in network troubleshooting and diagnostics. When a packet encounters an issue across the network, ICMP helps identify and report the problem. Destination Unreachable messages, for example, inform the sender that the intended destination is unreachable due to various reasons, such as network congestion, firewall rules, or routing issues.

Testing Methods for Packet Loss

To ensure a robust and reliable network infrastructure, it is vital to perform regular testing for packet loss. Here are some effective methods to carry out such tests:

1. Ping and Traceroute: These command-line utilities can provide valuable insights into network connectivity and latency. Packet loss can be detected by sending test packets and analyzing their round-trip time.

2. Network Monitoring Tools: Specialized network monitoring software can offer comprehensive visibility into network performance. These tools can monitor packet loss in real-time, provide detailed reports, and even alert administrators of potential issues.

3. Load Testing: Simulating heavy network traffic can help identify how the network handles data under stress. By monitoring packet loss during these tests, administrators can pinpoint weak spots and take necessary measures to mitigate the impact.

Example: Identifying and Mapping Networks

To troubleshoot the network effectively, you can use a range of tools. Some are built into the operating system, while others must be downloaded and run. Depending on your experience, you may choose a top-down or a bottom-up approach.

Required: Consistent Bandwidth & Unified Latency

We must focus on consistent bandwidth and unified latency for ALL flow types and workloads to satisfy varied conditions and achieve predictable application performance for a low latency network design. Poor performance is due to many factors that can be controlled. 

Bandwidth refers to the maximum data transfer rate of an internet connection. It determines how quickly information can be sent and received. Consistent bandwidth ensures that data flows seamlessly, minimizing interruptions and delays. It is the foundation for an enjoyable and productive online experience.

To identify bandwidth limitations, it is crucial to conduct thorough testing. Bandwidth tests measure the speed and stability of your internet connection. They provide valuable insights into potential bottlenecks or network issues affecting browsing, streaming, or downloading activities. By knowing your bandwidth limitations, you can take appropriate steps to optimize your online experience.

Choosing the Right Bandwidth Testing Tools

Several bandwidth testing tools are available, both online and offline. These tools accurately measure your internet speed and provide detailed reports on download and upload speeds, latency, and packet loss. Some popular options include Ookla’s Speedtest, Fast.com, and DSLReports. Choose a tool that suits your needs and provides comprehensive results.

**Start With A Baseline**

So, at the start, you must find the baseline and work from there. Baseline engineering is a critical approach to determining the definitive performance of software and hardware. Once you have a baseline, you can work from there, testing packet loss.

Depending on your environment, such tests may include chaos engineering kubernetes, which intentionally brake systems in a controlled environment to learn and optimize performance. To fully understand a system or service, you must deliberately break it. An example of some Chaos engineering tests include:

Example – Chaos Engineering:

  • Simulating the failure of a micro-component and dependency.
  • Simulating a high CPU load and sudden increase in traffic.
  • Simulating failure of the entire AZ ( Availability Zone ) or region.
  • Injecting latency and byzantine shortcomings in services.
Interactive Troubleshooting Lab

Find Where the Packets Are Dropping

A packet-loss result tells you that something is wrong. It does not automatically tell you where the fault is. Run different tests and correlate the evidence before identifying the failing segment.

Choose a Diagnostic Test
Each test gives you a different view of the same path. Use them together rather than treating one measurement as proof.
◉
Client
Healthy
◇
Access
Healthy
◇
Leaf
Healthy
◇
Spine
Healthy
◇
WAN
Healthy
▣
Server
Healthy
Diagnostic conclusion
Choose a test to begin
The path currently has no simulated fault selected. Run Ping, Traceroute, or Interface Diagnostics.
Evidence
Compare what each measurement actually tells you. Good troubleshooting correlates multiple observations.
End-to-end reachability —
Observed loss —
Path visibility —
Interface counters —
Most likely location —
Troubleshooting Principle
Never equate an unresponsive traceroute hop with packet loss at that router. Some devices deliberately rate-limit or filter control-plane responses while continuing to forward transit traffic. Correlate end-to-end tests with interface counters and application behaviour.

Dropped Packet Test

Reasons for packet loss

Packet loss can occur for several reasons. It describes lost packets of data that do not reach their destination after being transmitted across a network. Packet loss occurs when network congestion, hardware issues, software bugs, and other factors cause dropped packets during data transmission.

The best way to measure packet loss using ping is to send a series of pings to the destination and look for failed responses. For instance, if you ping something 50 times and get only 49 ICMP replies, you can estimate packet loss at roughly 2%. There is no specific value of what would be a concern. It depends on the application. For example, voice applications are susceptible to latency and loss, but other web-based applications have a lot of tolerance.

However, if I were going to put my finger in the air with some packet loss guidelines, generally, a packet loss rate of 1 to 2.5 percent is acceptable. This is because packet loss rates are typically higher with WiFi networks than with wired systems.

Significance of Dropped Packet Test:

1. Identifying Network Issues: By intentionally dropping packets, network administrators can identify potential bottlenecks, congestion, or misconfigurations in the network infrastructure. This test helps pinpoint the specific areas where packet loss occurs, enabling targeted troubleshooting and optimization.

2. Evaluating Network Performance: The Dropped Packet Test provides valuable insights into the network’s performance by measuring the packet loss rate. Network administrators can use this information to analyze the impact of packet loss on application performance, user experience, and overall network efficiency.

3. Testing Network Resilience: By intentionally creating packet loss scenarios, network administrators can assess the resilience of their network infrastructure. This test helps determine if the network can handle packet loss without significant degradation and whether backup mechanisms, such as redundant links or failover systems, function as intended.

Network administrators utilize specialized tools or software to conduct the Dropped Packet Test. These tools generate artificial packet loss by dropping a certain percentage of packets during data transmission. The test can be performed on specific network segments, individual devices, or the entire network infrastructure.

Best Practices for Dropped Packet Testing:

1. Define Test Parameters: Before conducting the test, it is crucial to define the desired packet loss rate, test duration, and the specific network segments or devices to be tested. Having clear objectives ensures that the test yields accurate and actionable results.

2. Conduct Regular Testing: Regularly performing the Dropped Packet Test allows network administrators to detect and resolve network issues before they impact critical operations. It also helps monitor the effectiveness of implemented solutions over time.

3. Analyze Test Results: After completing the test, careful analysis of the test results is essential. Network administrators should examine the impact of packet loss on latency, throughput, and overall network performance. This analysis will guide them in making informed decisions to optimize the network infrastructure.

**General performance and packet loss testing**

The following screenshot is taken from a Cisco ISR router. Several IOS commands can be used to check essential performance. The command shows interface gi1 stats and generic packet in and out information. I would also monitor input and output errors with the command: show interface gi1. Finally, for additional packet loss testing, you can opt for an extended ping that gives you more options than a standard ping. It would be helpful to test from different source interfaces or vary the datagram size to determine any MTU issues causing packet loss.

packet loss testing
Diagram: Packet loss testing.

What Is Packet Loss? Testing Packet Loss

Packet loss results from a packet being sent and somehow lost before it reaches its intended destination. This can happen because of several reasons. Sometimes, a router, switch, or firewall has more traffic coming at it than it can handle and becomes overloaded.

This is known as congestion, and one way to deal with it is to drop packets so you can focus capacity on the rest of the traffic. Here is a quick tip before we get into the details: Keep an eye on buffers!

So, to start testing packet loss, one factor that can be monitored is buffer sizes in the network devices that interconnect source and destination points. Poor buffers cause bandwidth to be unfairly allocated among different types of flows. If some flows do not receive adequate bandwidth, they will exhibit long tails and completion times, degrading performance and resulting in packet drops in the network.

Application Performance

The speed of a network is all about how fast you can move and complete a data file from one location to another. Some factors are easy to influence, and others are impossible, such as the physical distance from one point to the next.

This is why we see a lot of content distributed closer to the source, with intelligent caching, for example, improving user response latency and reducing the cost of data transmission. The TCP’s connection-oriented procedure will affect application performance for different distance endpoints than for source-destination pairs internal to the data center.

We can’t change the laws of physics, and distance will always be a factor, but there are ways to optimize networking devices to improve application performance. One way is to optimize the buffer sizes and select the exemplary architecture to support applications that send burst traffic. There is considerable debate about whether big or small buffers are best or whether we need lossless transport or drop packets.

TCP congestion control

The TCP congestion control and network device buffer significantly affect the time it takes for the flow to complete. TCP, invented over 35 years ago, ensures that sent data blocks are received intact. It also creates a logical connection between source-destination pairs and endpoints at the lower IP layer.

The congestion control element was added later to ensure that data transfers can be accelerated or slowed down based on current network conditions. Congestion control is a mechanism that prevents congestion from occurring or relieves it once it appears. For example, the TCP congestion window limits how much data a sender can send into a network before receiving an acknowledgment.

In the following lab guide, I have attached a host and a web server with a packet sniffer. All ports are in the default VLAN, and the server runs the HTTP service. Once we open the web browser on the host to access the server, we can see the operations of TCP with the 3-way handshake. We have captured the traffic between the client PC and a web server.

TCP uses a three-way handshake to connect the client and server (SYN, SYN-ACK, ACK). First things first: Why is a three-way handshake called a three-way handshake? Three segments are exchanged between the client and server to establish a TCP connection.

Big buffers vs. small buffers

Both small and large buffer sizes have different effects on application flow types. Some sources claim that small buffer sizes optimize performance, while others claim that larger buffers are better.

Many web giants, including Facebook, Amazon, and Microsoft, use small buffer switches. It depends on your environment. Understanding your application traffic pattern and testing optimization techniques are essential to finding the sweet spot. Most out-of-the-box applications will not be fine-tuned for your environment; the only rule of thumb is to lab test.  

**TCP interaction**

Complications arise when TCP congestion control interacts with the network device buffer. The two have different purposes. TCP congestion control continuously monitors network bandwidth using packet drops as a metric, while buffering is used to avoid packet loss.

In a congestion scenario, the TCP is buffered, but the sender and receiver cannot know there is congestion, and the TCP congestion behavior is never initiated. So, the two mechanisms used to improve application performance don’t complement each other and require careful packet loss testing for your environment.

Dropped Packet Test: The Approac

Ping and Traceroute: Where is the packet loss?

At a fundamental level, we have ping and traceroute. Ping measures round-trip times between your computer and an internet destination. Traceroute measures the routers’ response times along the path between your computer and an internet destination.

These will tell you where the packet loss occurs and how severe it is. The next step with the dropped packet test is to find your network’s threshold for packet drop. Here, we have more advanced tools to understand protocol behavior, which we will discuss now.

IPEF3, TCP dump, TCP probe: Understanding protocol behavior. 

A: Tools such as iperf3, TCP dump, and TCP probe can be used to test and understand the effects of TCP. There is no point looking at a vendor’s reports and concluding that their “real-world” testing characteristics fit your environment. They are only guides, and “real-world” traffic tests are misleading. Usually, no standard RFC is used for vendor testing, and they will always try to make their products appear better by tailoring the test ( packet size, etc.) to suit their environment.

B: As an engineer, you must understand the scenarios you anticipate. Be careful of what you read. Recently, there were conflicting buffer testing results from Arista 7124S and Cisco Nexus 5000.

C: The Nexus 5000 works best when most ports are congested simultaneously, while the Arista 7100 performs best when some ports are congested but not all. These platforms have different buffer architectures regarding buffer sizes, disciplines, and management, influencing how you test.

TCP congestion control: Bandwidth capture effect

The discrepancy and uneven bandwidth allocation for flow boil down to the natural behavior of how TCP reacts and interacts with insufficient packet buffers and the resulting packet drops. The behavior is known as the TCP/IP bandwidth capture effect.

The TCP/IP bandwidth capture effect does not affect the overall bandwidth but more individual Query Completion Times and Flow Completion Times (FCT) for applications. Therefore, the QCT and FCT are prime metrics for measuring TCP-based application performance.

packet drop test
Diagram: Packet Drop Test and TCP.

A TCP stream’s transmission pace is based on a built-in feedback mechanism. The ACK packets from the receiver adjust the sender’s bandwidth to match the available network bandwidth. With each ACK received, the sender’s TCP increases the pace of sending packets to use all available bandwidth. On the other hand, TCP takes three duplicate ACK messages to conclude packet loss on the connection and start the retransmission process.

TCP-dropped flows

So, in the case of inadequate buffers, packets are dropped to signal the sender to ease the transmission rate. TCP-dropped flows start to back off and naturally receive less bandwidth than the other flows that do not back off.

The flows that don’t back off get hungry and take more bandwidth. This causes some flows to get more bandwidth than others unfairly. By default, the decision to drop some flows and leave others alone is not controlled and is made purely by chance.

This conceptually resembles the Ethernet CSMA/CD bandwidth capture effect in shared Ethernet. Stations colliding with other stations on a shared LAN would back off and receive less bandwidth. This is not too much of a problem because all switches support full-duplex.

DCTP & Explicit Congestion Notification (ECN)

There is a new variant of TCP called DCTP, which improves congestion behavior. When used with commodity, shallow-buffered switches, DCTCP uses 90% less buffer space within the network infrastructure than TCP. Unlike TCP, the protocol is also burst-tolerant and provides low short-flow latency. DCTCP relies on ECN to enhance the TCP congestion control algorithms.

DCTP tries to measure how often you experience congestion and use that to determine how fast it should reduce or increase its offered load based on the congestion level. DCTP certainly reduces latency and provides more appropriate behavior between streams. The recommended approach is to use DCTP with both ECN and Priority Flow control (pause environments).

Dropped packet test with Microbursts

Microbursts are a type of small bursty traffic pattern lasting only for a few microseconds, commonly seen in Web 2 environments. This traffic is the opposite of what we see with storage traffic, which always has large bursts.

Bursts only become a problem and cause packet loss when there is oversubscription; many communicate with one. This results in what is known as fan-in, which causes packet loss. Fan-in could be a communication pattern consisting of 23-to-1 or 47-to-1, n-to-many unicast, or multicast. All these sources send packets to one destination, causing congestion and packet drops. One way to overcome this is to have sufficient buffering.

Network devices need sufficient packet memory bandwidth to handle these types of bursts. Fan-in can increase end-to-end latency-critical application performance if they don’t have the required buffers. Of course, latency is never good for application performance, but it’s still not as bad as packet loss. When the switch can buffer traffic correctly, packet loss is eliminated, and the TCP window can scale to its maximum size.

Mice & elephant flows.

For the dropped packet test, you must consider two flow types in data center environments. First, we have a large elephant and smaller mice flow. Elephant flows might only represent a low proportion of the total flows but consume most of the total data volume.

Mice flow, for example, control and alarm/control messages, are usually pretty significant. As a result, they should be given priority over more significant elephant flows, but this is sometimes not the case with simple buffer types that don’t distinguish between flow types.

Properly regulating the elephant flows with intelligent switch buffers can be given priority. Mice flow is often bursty flow where one query is sent to many servers.

Many small queries are sent back to the single originating host. These messages are often small, only requiring 3 to 5 TCP packets. As a result, the TCP congestion control mechanism may not even be evoked as the congestion mechanisms take three duplicate ACK messages. However, due to the size of elephant flows, they will invoke the TCP congestion control mechanism (mice flows don’t as they are too small).

Testing packet loss: Reactions to buffer sizes

When combined in a shared buffer, mice and elephant flows react differently. Small, deep buffers operate on a first-come, first-served basis and do not distinguish between different flow sizes; everyone is treated equally. Elephants can fill out the buffers and starve mice’s flow, adding to their latency.

On the other hand, bandwidth-aggressive elephant flows can quickly fill up the buffer and impact sensitive mice flows. Longer latency results in longer flow completion time, a prime measuring metric for application performance.

On the other hand, intelligent buffers understand the types of flows and schedule accordingly. With intelligent buffers, elephant flows are given early congestion notification, and the mice flow is expedited under stress. This offers a better living arrangement for both mice and elephant flows.

First, you need to be able to measure your application performance and understand your scenarios. Small buffer switches are used for the most critical applications and do very well. You are unlikely to make a wrong decision with small buffers, so it’s better to start by tuning your application. Out-of-the-box behavior is generic and doesn’t consider failures or packet drops.

The way forward is understanding the application and tuning of host and network devices in an optimized leaf and spine fabric. If you have a lot of incest traffic, having large buffers on the leaf will benefit you more than having large buffers on the Spine.

Closing Points on Dropped Packet Test

Understanding the reasons behind packet drops is essential for any network troubleshooting endeavor. Common causes include network congestion, hardware issues, or misconfigured network devices. Congestion happens when the network is overwhelmed by too much traffic, leading to packet loss. Faulty hardware, such as a bad router or switch, can also contribute to this problem. Additionally, incorrect network settings or protocols can lead to packets being misrouted or lost altogether.

**The Dropped Packet Test: A Diagnostic Tool**

The dropped packet test is a fundamental diagnostic approach used by network administrators to identify and address packet loss issues. This test typically involves using tools like ping or traceroute to send packets to a specific destination and measure the percentage of packets that successfully make the trip. Through this process, administrators can pinpoint where in the network the packets are being dropped and take corrective actions.

Once the dropped packet test is performed, the results need to be carefully analyzed. A high percentage of packet loss indicates a significant problem that requires immediate attention. It could be a sign of a failing network component or a need for increased bandwidth. On the other hand, occasional packet drops might be normal in a busy network but should be monitored to ensure they do not escalate.

Addressing packet loss involves a combination of hardware upgrades, network optimization, and configuration adjustments. Replacing outdated or faulty equipment, increasing bandwidth, and optimizing network settings can significantly reduce packet drops. Regular network monitoring and maintenance are also critical in preventing packet loss from becoming a recurring issue.

Interactive Congestion Lab

Buffers, Microbursts and TCP Reaction

Packet loss is often a symptom of congestion. Experiment with offered load, buffer capacity, burstiness and ECN to see how queues affect drops, latency and flow completion.

Network Conditions
Increase traffic pressure or reduce available buffering. Then observe how the queue and flows respond.
Traffic load 60%
20% 140%
Buffer capacity 60%
10% 120%
Burst intensity 35%
0% 100%
Enable ECN
Mark congestion before relying solely on packet drops.
Live Network Behaviour
These values represent a simplified model of a congested queue. The purpose is to expose the relationships, not reproduce a particular switch ASIC.
Queue utilisation —
Packet drop pressure —
Application latency —
Flow behaviour —
Mice
—
Elephant
—
Engineering Interpretation
Adjust the network conditions to see how congestion changes queue behaviour.
ipv6 filtering

IPFIX Big Data

by Blog

IPFIX Big Data

Modern networks generate enormous volumes of telemetry, and understanding that telemetry is essential for performance, capacity planning, security, and operational visibility. IPFIX (Internet Protocol Flow Information Export) provides a standardised way for network devices to export information about observed traffic flows. When these records are collected at scale and combined with modern analytics platforms, they become a powerful source of network intelligence.

IPFIX is designed to describe traffic flows rather than capture complete packet payloads. An exporter can report information such as source and destination addresses, transport ports, protocol, timestamps, packet and byte counts, interfaces, and other flow attributes. The exact fields depend on the device and configured IPFIX templates. This makes IPFIX particularly useful for understanding who is communicating with whom, how much traffic is being exchanged, which applications or services are involved, and how traffic changes over time.

The value of large-scale IPFIX analysis comes from combining flow records with other operational data. Flow telemetry can be enriched with routing information, device and interface metadata, identity, application context, cloud information, DNS data, security events, and infrastructure telemetry. Streaming and historical analytics can then identify traffic patterns, unusual behaviour, capacity trends, and operational anomalies that would be difficult to see from individual devices alone.

Network Performance and Observability: IPFIX provides visibility into traffic volumes, top applications and destinations, interface utilisation, traffic direction, and changes in network behaviour. Engineers can use this information alongside interface counters, latency, errors, logs, and other telemetry to investigate congestion, unexpected traffic flows, and service-impacting events.

Security Analytics: Flow records can provide valuable network-level evidence for security operations. Large traffic spikes, unusual external destinations, unexpected east-west communication, scanning behaviour, data-transfer patterns, and changes in normal communication relationships can all provide signals for investigation. IPFIX is not a replacement for packet inspection or endpoint security, but it can provide broad visibility across large environments with significantly less data than full packet capture.

Capacity Planning: Historical flow data provides a foundation for understanding how bandwidth and network resources are being consumed. Engineers can identify sustained growth, recurring utilisation patterns, heavily used links, and changing application behaviour. This supports capacity forecasting and helps determine where additional bandwidth, infrastructure, or architectural changes may be required.

Application and Business Visibility: Flow analytics can also help organisations understand how applications and services consume network resources. When flow records are enriched with application, identity, site, cloud, or business context, network teams can move beyond raw bandwidth measurements and investigate the operational impact of specific services and traffic patterns.

Large-scale IPFIX environments introduce their own engineering challenges. Data volume and cardinality can grow rapidly as the number of exporters, interfaces, endpoints, applications, and flow records increases. Collectors and analytics platforms therefore need appropriate ingestion, filtering, aggregation, retention, indexing, and storage strategies. Streaming pipelines may be used for near-real-time detection, while longer-term data stores support historical analysis and capacity planning.

Data quality also matters. Different vendors and platforms may expose different IPFIX information elements, sampling behaviours, template configurations, and application classifications. Analysts therefore need to understand what the exporter is actually measuring before drawing conclusions from the resulting dataset. Sampling can reduce collection overhead, but it also affects the accuracy of some traffic measurements and security analyses.

Privacy and security must also be considered. Flow records can reveal communication relationships, user activity, destinations, application usage, and other sensitive operational information even when packet payloads are not captured. Appropriate access controls, retention policies, encryption, data minimisation, and regulatory controls should therefore be applied to the collection and analysis pipeline.

The modern approach is to treat IPFIX as one component of a broader network telemetry and observability architecture. IPFIX flow records provide traffic context; metrics, logs, traces, routing information, security events, and application telemetry provide additional evidence. When these sources are correlated, organisations can build a much more complete understanding of network behaviour.

IPFIX therefore remains valuable not because it is simply “Big Data for networking”, but because it provides a structured and scalable source of network flow intelligence. Combined with modern streaming analytics, observability platforms, security analytics, and historical data analysis, IPFIX can help organisations detect anomalies, understand application behaviour, plan capacity, investigate incidents, and make better infrastructure decisions.

IPFIX Big Data • Interactive Lab

IPFIX Flow Explorer

A network device sees packets. IPFIX turns related packets into structured flow records that can be exported to a collector and analysed at scale. Click a field below to see what it contributes to the flow record.

PKT
Packets Individual packets traverse the network.
→
FLOW
Flow Related packets are grouped into a flow.
→
EXP
Exporter Flow information is formatted and exported.
→
COL
Collector Records are received and stored.
→
AI
Analytics Traffic patterns become operational insight.

Explore the Flow Record

Select a field to understand why it matters when analysing network traffic.

Source IP Origin of the traffic
10.20.10.25
Destination IP Traffic destination
10.40.20.80
Ports Application endpoints
51542 → 443
Protocol Transport / network protocol
TCP
Traffic Volume Packets and bytes observed
842 pkts / 1.2 MB
Time When the traffic occurred
12:04:31–12:04:36
Interface Where traffic was observed
Gi0/1

Example IPFIX Record

Think of this as one structured observation exported from the network.

srcAddr: 10.20.10.25
dstAddr: 10.40.20.80
srcPort: 51542
dstPort: 443
protocol: TCP
packets: 842
bytes: 1,204,812
interface: Gi0/1
startTime: 12:04:31
endTime: 12:04:36
Source IP: identifies where the observed flow originated. When correlated with routing and identity information, this can become much more useful than a simple packet counter.
Why this matters

A single flow record is only one observation. The real value appears when large numbers of flow records are correlated over time — revealing traffic trends, unusual sources, application behaviour, capacity pressure and potential security events.

Highlights: IPFIX Big Data

Understanding IPFIX and Big Data

IPFIX, which stands for Internet Protocol Flow Information Export, is a flexible and extensible protocol that allows for the collection and export of network flow data. It provides essential information about network traffic, including source and destination IP addresses, ports, protocols, and more. By capturing and analyzing this data, organizations can gain deep visibility into their network infrastructure and identify potential bottlenecks, anomalies, or security threats.

Big data analytics has revolutionized decision-making processes across industries, and IPFIX is no exception. By applying advanced analytics techniques to IPFIX data, organizations can uncover hidden patterns, detect anomalies, and derive actionable insights. Whether it is monitoring network performance, optimizing resource allocation, or identifying potential security breaches, IPFIX big data analytics empowers businesses to make data-driven decisions and stay ahead of the curve.

IPFIX Big Data Considerations: 

1. Network Performance Optimization:

IPFIX big data enables organizations to monitor and analyze network traffic in real-time, providing valuable insights into bandwidth utilization, latency, and packet loss. By identifying performance bottlenecks and optimizing network resources, businesses can enhance user experience, streamline operations, and reduce costs.

2. Security Threat Detection:

The richness of IPFIX data allows for effective detection and prevention of security threats. By analyzing network flow data, organizations can identify suspicious activities, detect malware infections, and mitigate potential cyber-attacks. IPFIX big data analytics serves as a powerful tool in ensuring network security and safeguarding sensitive information.

3. Capacity Planning:

IPFIX big data analytics provides organizations with the ability to forecast future network demands and plan capacity accordingly. By analyzing historical traffic patterns, businesses can accurately predict resource requirements, optimize infrastructure investments, and ensure scalability to meet growing demands.

4. Quality of Service Enhancement:

With IPFIX big data, organizations can gain insights into network traffic patterns and prioritize critical applications or services. By implementing Quality of Service (QoS) measures based on IPFIX analytics, businesses can optimize network performance, reduce latency, and improve overall user experience.

The Role of Big Data

– Big Data is a field devoted to analyzing, processing, and storage of extensive collections of data that continually originate from disparate sources. Consequently, Big Data solutions and practices are typically required when more than traditional data analysis, processing, and storage technologies and techniques are needed. Mainly, Big Data addresses distinct requirements, such as combining multiple unrelated datasets, processing large amounts of unstructured data, and harvesting hidden information time-sensitively.

– IPFIX, short for IP Flow Information Export, is a protocol that allows for the collection and export of flow records from network devices. It provides valuable insights into network traffic patterns, including source and destination IP addresses, ports, and protocols. By capturing and analyzing IPFIX data, organizations gain a comprehensive understanding of their network infrastructure and can make data-driven decisions to optimize performance and security.

– The true power of IPFIX lies in its ability to handle big data. With the exponential growth of network traffic, traditional analysis methods fall short. IPFIX big data solutions, on the other hand, leverage advanced analytics and machine learning algorithms to process massive amounts of flow data in real time. This enables network administrators to identify anomalies, detect security threats, and troubleshoot performance issues with unmatched precision and speed.

Use Cases of IPFIX Big Data

1. Network Performance Optimization: By analyzing IPFIX data, organizations can identify bandwidth bottlenecks, optimize network configurations, and ensure efficient resource allocation. This leads to enhanced network performance, reduced latency, and improved user experience.

2. Security Threat Detection: With the help of IPFIX big data analytics, organizations can detect and mitigate security threats in real-time. By monitoring flow patterns, identifying suspicious behavior, and employing machine learning algorithms, IPFIX enables proactive threat detection and response, safeguarding networks from cyberattacks.

3. Capacity Planning and Traffic Engineering: IPFIX big data offers valuable insights into network traffic patterns, allowing organizations to plan for future capacity needs. Organizations can ensure smooth operations and avoid costly downtime by analyzing historical data, predicting traffic trends, and optimizing network infrastructure.

IP Flow Information Export

a) IPFIX is overseen by the Internet Engineering Task Force (IETF). Flow information can be exported from routers, switches, firewalls, and other infrastructure devices using IPFIX. Exporters and collectors use IPFIX to format and transfer flow information. Several RFCs, including 7011 through 7015 and RFC 503, describe IPFIX. Version 9 of NetFlow is the basis and primary reference for IPFIX. IPFIX is essentially the same as NetFlow Version 9, except for a few terminologies.

b) Push protocols are considered IPFIX protocols. IPFIX-enabled devices automatically send IPFIX messages to configured collectors (receivers) without user input. In most cases, the sender orchestrates IPFIX data messages. To construct these flow data messages, IPFIX introduces the concept of templates. User-defined data types can also be used in IPFIX messages. IPFIX prefers Stream Control Transmission Protocol (SCTP) as the transport layer protocol; however, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) can also be used.

c) UDP messages are usually used to export Cisco NetFlow records. On the sending device, the IP address of the NetFlow collector and the destination UDP port must be configured. The NetFlow standard does not specify a specific NetFlow listening port (RFC 3954). In addition to UDP port 2055, NetFlow can use ports such as 9555 or 9995, 9025, and 9026. IPFIX uses UDP port 4739 by default.

Attacking Tools are Readily Available

Attacker tools are readily available, making DDoS defense much harder than attack. It’s hard to blame anyone; the ISP is just transiting traffic, and end users don’t know if they are compromised and part of a BotNet farm. There is no service of abuse or license for the Internet, making tracking and detection between independent service provider locations difficult. Recently, there has been a shift in application footprints. We now have multi-tiered applications dispersed across various sites, all requiring cross-communication.

  • New Attack Surface

New application architecture results in new attacks, and with any application segment, you are only as strong as the weakest link, requiring a new set of network visibility. That can help you correlate disparate data points. The birth of the cloud and new technologies increased the attack surface, making quick and accurate DDoS detection using tools such as IPFIX Big data an enchantment to other DDoS solutions such as BGP Flowspec.

  • The Ability to Stop DDoS

Companies require mechanisms to stop and slow down DDoS attacks. The IETF introduced best practices with BCP38, and service providers started incorporating ingress filtering into their designs and cross-checking incoming frames. However, ISPs are not forced by contract to implement these features. The only way to adequately mitigate DDoS attacks is adequate detection. How long should this take? What timeframe is acceptable?

All this depends on the traffic analysis solution you have in place. Initially, traffic analysis began monitoring up/down interfaces with introductory statistics. They then moved to Syslog servers and single source basic flow capturing. We need a system that captures enriched flow data and groups infrastructure and application information together. Enriching data from all elements allows the network and its traffic to be viewed as one holistic entity.

 

IPFIX Big Data • Investigation

IPFIX Traffic Investigation Lab

Flow analytics becomes powerful when you stop looking at individual records and start looking for changes in behaviour. Run the investigation and look for the traffic pattern that deserves attention.

Traffic Volume Over Time

IPFIX records can be aggregated into time windows to reveal changes that are difficult to see from individual flows.

−60s −30s Now
Flows / sec 1,240
Packets / sec 84k
Bandwidth 6.8 Gbps

Investigation View

A useful investigation combines volume with additional context rather than relying on a single metric.

Traffic source Mixed
Dominant protocol TCP
Destination concentration Low
Traffic behaviour Normal
Investigation status Baseline
Analyst Observation

Traffic is relatively stable. No obvious volume anomaly is visible. This is your baseline for comparison.

IPFIX Big Data

The Rise of Big Data:

Big Data refers to the exponential growth and availability of structured and unstructured data. IPFIX Big Data refers to applying Big Data principles to IPFIX data. With the increasing volume, velocity, and variety of network traffic, traditional network monitoring tools struggle to keep up. IPFIX Big Data leverages advanced analytics and processing techniques to extract valuable insights from this massive data.

Benefits of IPFIX Big Data:

Advanced Network Monitoring: Organizations comprehensively understand their network behavior by analyzing IPFIX Big Data. This allows for proactive monitoring, rapid detection of anomalies, and improved security incident response. Additionally, IPFIX Big Data enables the identification of network bottlenecks, performance optimization, and capacity planning.

Enhanced Traffic Analysis: IPFIX Big Data allows for granular analysis of network traffic patterns, allowing organizations to identify trends, troubleshoot issues, and optimize network performance. By leveraging advanced analytics and machine learning algorithms, IPFIX Big Data can detect and classify different types of traffic, leading to a better quality of service and improved user experience.

Real-Time Insights: IPFIX Big Data provides near real-time insights into network traffic, allowing organizations to respond quickly to emerging threats or issues. By combining streaming analytics with historical data analysis, organizations can detect and respond to network incidents faster, minimizing downtime and maintaining service reliability.

Enhanced Network Security: IPFIX big data is pivotal in bolstering network security. By analyzing flow data, organizations can identify and mitigate potential threats in real time. Suspicious traffic patterns, anomalies, and known attack signatures can be detected promptly, enabling swift action to safeguard the network.

Network Performance Optimization: IPFIX big data offers valuable insights into network performance. Organizations can identify bottlenecks, optimize bandwidth allocation, and improve overall network efficiency by monitoring flow data. This enables them to provide a seamless user experience and maximize productivity.

Capacity Planning and Resource Allocation: With IPFIX big data, organizations can accurately forecast resource requirements and plan their network capacity accordingly. They gain insights into traffic patterns, peak usage times, and resource utilization trends through comprehensive flow analysis. This empowers them to allocate resources effectively and avoid potential network congestion.

Challenges and Considerations:

Implementing IPFIX Big Data comes with its own set of challenges. Organizations must ensure they have sufficient storage and processing capabilities to handle large volumes of data. They must also consider privacy and security concerns when collecting and storing IPFIX data. Additionally, the complexity of IPFIX data requires specialized skills and tools for practical analysis and interpretation.

IPFIX Big Data: Enhanced Data Sources

DDoS traffic analysis solutions extract various types of flow data from network devices. The flow record consists of fields from multiple data types, including NetFlow, IPFIX, and sFlow. In addition, DDoS Big Data solutions can enrich records at the ingest layer by performing a lookup of the source and destination in the flow, BGP table, and GeoIP database. These values are added as volumes and fields stored with the original flow. The extra information lets administrators slice the traffic at ingesting, enabling a fantastic multi-dimensional view of network traffic.

Tools like sFlOW and IPFIX variants like IPFIX BGP are critical in DDoS detection. Classic flow fields based on 5-tuples include IP address and source/destination port numbers, which are later expanded to include MAC address, MPLS, and application schematics like URLs, HTTP host headers, DNS queries, and responses.

The availability of advanced fields enables the detection of sophisticated attacks higher up the protocol stack. For example, access to the HTTP host header for each request allows precise identification down to the URL

A key point: Different attacking vectors.

Not all DDoS attacks and DNS reflection attacks are easily detected. Volumetric attacks, such as SynFlood, are more accessible to catch than SlowLoris and RUDY attacks. Layer 7 attacks usually don’t exceed the packet/sec threshold, a standard parameter for detecting volumetric-based attacks.

To combat this, we must go deeper than the standard 5-tuple with augmented flows. Augmented flows contain additional fields to include a variety of advanced metrics such as connection counts, congestion windows, and TCP RTT. Traditional flow data does not provide this level of detailed information.

IPFIX Big Data
Diagram: IPFIX Big Data.

Data source variations

Netflow and IPFIX, flow record creation, is based on packets sharing the same fields. Flow state is held, hitting system resources. To save system resources, flows are exported at predefined times. As a result, traffic measurement is accurate, but it might not hit the detector for up to one minute.

sFlow sends packet samples every 1 in N, streaming flows as soon as they are prepared. sFlOW draws fewer system resources than its Netflow counterpart. It is considered faster and has better accuracy, meaning it’s an excellent tool for DDoS detection.

sFlow is better at carrying the source MAC address than NetFlow and IPFIX. With NetFlow and IPFIX, the source MAC is possible but not usually implemented by all vendors. NetFlow is useful for some requirements, while IPFIX and sFlow are for others.

To get all the possible knobs, it’s better to extract them from all data sources and combine them into one database that can easily be viewed with a single portal. Combining all data sources into one unified store makes the protocol type less relevant.

IPFIX BGP

DDoS solution: Irregularities with ASN Information

DDoS solutions can peer EBGP with customers by giving them a copy of the BGP table. Customer route updates are reflected through the standard BGP propagation procedure. It’s a non-intrusive peering agreement; BGP’s next hops are not altered, meaning customers’ data plane traffic flows as usual. The contents of the BGP table provide access to customers’ control plane information, enabling complete visibility of the data source and destination.

The manual approach with BGP can be cumbersome. BGP offers a string of information about DDoS sources and destinations, but it can be hard to craft regular expressions to extract this information. Not everyone can craft regular expressions, a skill for senior engineers.

Netflow and BGP

Netflow does provide some BGP ASN information, but you only have access to the source and destination of the Peer or Origin ASN. Some high-end platforms do both, but it’s restricted to specific devices and vendor discretion. NetFlow should not hold all BGP-type information; this would be a suboptimal solution.

Also, Netflow does have drawbacks and inaccuracies when determining the source ASN. The destination ASN is never usually a problem. The BGP process/daemon performs a REVERSE BGP Lookup to determine the source ASN and populate the FIB.

However, this type of BGP lookup does not guarantee the correctness of results. A REVERSE BGP Lookup primarily determines how to route back to the source, but this does not correlate with how the source may route to you.

Most networks are asymmetric, meaning the source-destination path differs from the reverse direction. An IP packet traversing from source A to destination B will take a different return path. Due to the shared nature of asymmetric routing, traditional monitoring systems misrepresent the BGP table with inaccurate source ASNs.

Legacy traffic analysis systems that don’t peer EBGP with customers will report inaccurate source ASN. It is not very good when troubleshooting a DDoS attack, and the source ASN information is incorrect.

Most legacy systems don’t offer accurate, complete AS-Path information, leading to false positives and the inability to determine friend from foe. It’s far better for the solution to peer BGP with the customer, extract NetFlow / IPFIX BGP / sFlow locally, and then correlate the data to provide a unified source of truth.

A key point: IPFIX BGP

BGP data can be correlated with IPFIX data so that the paths available in the network are shown, what paths are being used, and the traffic volume on each path between autonomous systems. BGP IPFIX Analysis correlates IPFIX records with BGP routing info to visualize AS paths and how much traffic is traversing these paths in real-time. IPFIX BGP: Analysis correlates IPFIX records with BGP routing info to visualize AS paths and how much traffic is traversing these paths in real-time.

Origin ASN and Peer ASN provide the data flow endpoints, and NetFlow is used in the middle. We can utilize GeoIP Information to analyze the county, region, and city. Correlate this with the complete AS-Path list, and you now have a full view of the source and destination paths with all the details of the middle points.

Closing Points on IPFIX Big Data

IPFIX is a protocol developed for exporting flow information from routers, switches, and other network devices. It allows organizations to capture detailed information about IP traffic, thus providing a comprehensive view of network behavior. By exporting flow records to a collector, IPFIX facilitates real-time monitoring and analysis, making it an indispensable tool in network management.

In the realm of Big Data, the ability to process and analyze vast amounts of information quickly is crucial. IPFIX contributes significantly by providing structured, high-fidelity data that can be easily ingested into Big Data platforms. This integration allows organizations to conduct deeper network analysis, detect anomalies, and optimize traffic flow efficiently. The granularity of IPFIX data ensures that even the most minute details are available for scrutiny, enhancing the overall analytical capability.

1. **Enhanced Network Security:** By providing detailed insights into network traffic, IPFIX helps in identifying potential security threats and breaches, allowing for timely intervention.

2. **Optimized Network Performance:** With IPFIX data, organizations can monitor network performance in real-time, identifying bottlenecks and ensuring optimal operation.

3. **Cost Efficiency:** By enabling precise traffic analysis, IPFIX aids in resource allocation and bandwidth management, leading to reduced operational costs.

While the benefits are substantial, integrating IPFIX with Big Data analytics poses certain challenges. These include the need for robust data storage solutions to handle the volume of data generated and ensuring data privacy and security. Additionally, organizations must invest in skilled personnel to interpret and act on the insights provided by IPFIX data effectively.

 

IPFIX + BGP • Correlation Lab

Correlate Flow Data With BGP

Flow telemetry can tell you who is communicating and how much traffic is moving. BGP adds routing context. Correlating the two gives an analyst a much richer view of traffic across autonomous systems and available paths.

Routing Context

BGP provides the control-plane context needed to understand which autonomous systems and paths are available.

AS65010 Enterprise
AS64501 Transit A
AS64500 Provider
AS65020 Cloud
prefix: 203.0.113.0/24
asPath: 65010 64501 64500 65020
nextHop: 192.0.2.1

Correlated Flow

Now combine the routing information with the traffic actually observed by the network.

Origin ASN AS65010
Destination ASN AS65020
Observed Traffic 8.4 Gbps
Active AS Path 65010 → 64501 → 64500 → 65020
Correlation Status Correlated
Engineering Insight

Flow + BGP correlation: the traffic record tells us what is happening, while the BGP information provides routing context. Together they show both the traffic volume and the path available to that traffic.