We’ve just published the slides from Pavel Odintsov’s TWNOG7 talk, “Challenges of DDoS Detection on Terabit Scale.”

The presentation walks through a real terabit‑scale deployment in West Asia with more than 750,000 mobile and fixed broadband customers and over 1 Tbps of total capacity, built on Juniper gear. It covers what actually breaks when you try to do near real‑time DDoS detection at that scale: inline monitoring quirks on PTX, double and triple‑tagged VLANs, Linux kernel edge cases, and dealing with UDP telemetry at around 50 kpps.

A big focus is Juniper inline monitoring services and IPFIX: how packet header sampling is structured, what information elements you get (ingress/egress interfaces, direction, frame size, partial payload), and why this approach makes one‑second DDoS detection and live graphs possible when it’s implemented correctly. The deck also shows some fun surprises, like moving from “one flow per UDP packet” to “multiple flows per packet” on PTX and what that did to parsing assumptions in FastNetMon until a full RFC‑compliant implementation was in place.

If you’re working with terabit‑scale traffic, IPFIX/NetFlow, or Juniper inline monitoring, you might find this useful both as a design reference and as a list of gotchas to watch out for.

Slides (PDF): https://fastnetmon.com/wp-content/uploads/2026/04/Challenges-of-DDoS-Detection-on-Terabit-scale-2026-.pdf

What parts of terabit‑scale DDoS detection are the biggest pain points in your network right now: telemetry, detection logic, or mitigation capacity?

As we move through 2026, IPv6 adoption continues to increase steadily across service provider networks, enterprise backbones, and mobile infrastructures. However, IPv4 is still far from disappearing in practice. A large portion of global internet traffic, applications, and legacy services continues to rely on IPv4 connectivity, which means operators must still maintain mechanisms to bridge IPv4 and IPv6 environments.

This has led to continued interest in transition technologies that allow operators to simplify their core networks while still supporting IPv4 access. One of these mechanisms is MAP-T (Mapping of Address and Port using Translation), which is designed to support IPv4 connectivity over an IPv6-only infrastructure without requiring per-connection state in the core.

In this article, we will first take a closer look at how MAP-T actually works in practical terms. After that, we will shift the focus to something more relevant to 2026 operator discussions: how MAP-T behaves in real deployments, what trade-offs engineers report, and why many of the interesting questions are operational rather than protocol-level.

Understanding MAP-T: how IPv4 works over an IPv6-only core

MAP-T, defined in RFC 7599, is a stateless mechanism for transporting IPv4 traffic across an IPv6-only network using deterministic translation rules.

At a high level, MAP-T exists to solve a specific problem: how to allow IPv4 communication to continue working when the provider network itself has removed IPv4 from its internal infrastructure.

Instead of maintaining large state tables like Carrier-Grade NAT systems, MAP-T relies on a pre-defined mapping function. This function allows both the customer-side device and the provider-side gateway to independently calculate how IPv4 addresses and port ranges correspond to IPv6 addressing.

The key idea: shared IPv4 + port partitioning

In a typical MAP-T deployment, multiple customers share a single IPv4 address. What distinguishes one customer from another is not the IPv4 address itself, but the range of ports assigned to them.

Each subscriber is given:

• a shared IPv4 address
• a specific subset of transport-layer ports, defined by a Port Set ID (PSID)

This means that IPv4 addressing becomes less about unique addresses and more about structured sharing of both address and port space.

These parameters are then embedded into the IPv6 address structure using what are known as Embedded Address (EA) bits. This embedding allows the network to carry enough information within IPv6 packets to reconstruct the original IPv4 context when needed.

A simplified way to think about this mapping is:

IPv6 address = IPv6 prefix + embedded IPv4 + port-set identifier + interface identifier

This is not a literal packet format, but it is a useful conceptual model for understanding how MAP-T preserves IPv4 semantics inside an IPv6-native environment.

The role of Customer Edge and Border Relay

MAP-T deployments are typically built around two functional components.

The first is the Customer Edge (CE), which is usually the subscriber’s home or enterprise router. The CE is responsible for applying local translation rules and ensuring that outgoing traffic conforms to the assigned IPv4 address and port range.

The second is the Border Relay (BR), which sits at the edge of the service provider network. The BR is responsible for translating traffic between the IPv6-only core and the external IPv4 Internet.

Because both sides use the same deterministic mapping rules, the system does not require per-session state. Instead, it relies entirely on address structure and rule consistency.

Packet flow in practice

When a device sends traffic, the Customer Edge first translates private IPv4 traffic into the assigned shared IPv4 space using NAT44. After this step, the packet is translated into IPv6 using MAP-T rules and forwarded into the provider’s IPv6-only core network.

Within the core, the traffic is treated as native IPv6 and does not require any IPv4 routing capability.

When return traffic arrives, the Border Relay uses the destination IPv4 address and port combination to determine which subscriber the traffic belongs to. It then applies the same mapping logic in reverse, reconstructing the correct IPv6 destination and forwarding the packet to the appropriate Customer Edge device.

The important property here is determinism: both sides independently arrive at the same mapping decision without exchanging state information.

What operators actually talk about in 2026 MAP-T deployments

While the mechanism itself is relatively straightforward, most operator discussions in 2026 are not focused on the protocol design. Instead, they revolve around operational trade-offs, deployment constraints, and real-world behaviour under scale.

In practice, MAP-T is less of a theoretical design discussion and more of a “how does this behave in my environment” topic.

1. Stateless forwarding vs operational state reality

One of the first clarifications that often appears in operator conversations is that “stateless” refers only to packet forwarding behaviour in the core network.

In reality, operators still maintain a significant operational state, including:

• Port Set ID allocations per subscriber
• Mapping rule consistency across provisioning systems
• Coordination between DHCP, BNG, and translation systems
• Troubleshooting metadata for support and engineering teams

This leads to a subtle but important distinction that is frequently discussed in ISP engineering groups:

MAP-T removes per-flow state from the forwarding plane, but it does not remove the need for structured state in the operational and provisioning layers.

In other words, the network becomes simpler in one dimension, but more structured in another.

2. Port allocation becomes a design constraint, not just a detail

In operator discussions, port allocation is one of the most practical constraints in MAP-T design.

Because each subscriber receives only a subset of the available port space, operators must carefully balance:

• IPv4 address efficiency
• expected user behaviour
• application requirements
• support overhead

In real deployments, issues rarely come from steady-state traffic. Instead, they tend to emerge from burst behaviour, where a user temporarily exceeds expected connection patterns.

This leads to a recurring engineering question in operator forums:

>

MAP-T does not remove this constraint; it makes it explicit and structurally enforced.

3. Customer equipment remains a persistent operational limitation

Another consistent theme in 2026 deployment discussions is customer-premises equipment compatibility.

Even though MAP-T is conceptually clean in the core network, it requires correct implementation at the edge device. In practice, operators frequently encounter challenges such as:

• inconsistent vendor support across router firmware versions
• limited availability of MAP-T-capable consumer devices
• difficulties supporting customer-owned hardware
• operational overhead in managing firmware fragmentation

As a result, MAP-T deployments tend to work best in environments where operators control the customer edge device, or where equipment is tightly standardised.

This is one of the reasons MAP-T is not universally deployed, even when it is architecturally attractive.

4. MAP-T vs MAP-E: an ongoing operational preference debate

Although MAP-T and MAP-E are closely related in design, operators often prefer one over the other based on operational experience rather than theoretical efficiency.

MAP-T is typically described as more “native” to IPv6 networks, since it avoids encapsulation and operates through translation alone. However, this also means that packet reconstruction and debugging require deeper awareness of mapping rules.

MAP-E, by contrast, uses encapsulation, which some operators find easier to troubleshoot because IPv4 packets remain intact inside IPv6 transport.

A common summary from engineering discussions is:

MAP-T tends to be preferred for architectural cleanliness, while MAP-E is often preferred for operational simplicity.

5. Observability is more complex than the stateless model suggests

One of the more subtle findings from operator discussions in 2026 is that stateless forwarding does not automatically translate into simpler observability.

Because IPv4 headers are translated and partially embedded into IPv6 structure, troubleshooting often requires:

• access to mapping rule definitions
• correlation between IPv4 and IPv6 address spaces
• understanding of Port Set ID allocation logic

This means that packet-level debugging can be less intuitive than in either pure IPv4 or dual-stack environments.

To address this, operators often implement additional tooling around MAP-T deployments, including enhanced telemetry at Border Relays and internal systems that reconstruct subscriber identity from flow data.

6. MAP-T is typically a later-stage transition mechanism

In most 2026 deployments, MAP-T is not the first step in IPv6 transition strategy.

Instead, operators typically progress through stages such as dual-stack deployment, CGNAT introduction, and gradual exploration of IPv6-only core designs using different transition technologies.

MAP-T is usually considered when operators are explicitly trying to reduce IPv4 dependency in the core while maintaining deterministic control over address sharing and port allocation.

This positions MAP-T as a refinement stage rather than an initial adoption tool.

Final thoughts

MAP-T is best understood not simply as a translation mechanism, but as part of a broader operational shift in 2026 network design. It replaces per-flow state with deterministic mapping rules, enabling IPv6-only core architectures while preserving IPv4 connectivity.

However, the real-world experience of MAP-T is shaped less by its protocol design and more by operational realities: port allocation strategy, customer equipment constraints, observability requirements, and the complexity of large-scale ISP environments.

In that sense, MAP-T does not eliminate complexity — it redistributes it. And in 2026 operator discussions, that redistribution is exactly where the most interesting engineering debates continue to happen.

This is a guest contribution from Brian Wilson (BGP Brian), creator of the BGP Black Belt community and educator focused on BGP operations.

Border Gateway Protocol (BGP) is the routing protocol of the Internet. It determines how traffic moves between autonomous systems and ultimately decides where packets go.

But while BGP makes routing decisions, it doesn’t provide an easy way to observe those decisions at scale.

To solve this visibility problem, a protocol called the BGP Monitoring Protocol (BMP) was developed.

In this post, we’ll examine what BMP is and how it can be used for troubleshooting, visibility, and control-plane monitoring in modern networks.

What is BMP?

The BGP Monitoring Protocol (BMP) is a standardized protocol (RFC 7854) that allows routers to export detailed BGP control-plane information to an external monitoring system.

Unlike BGP itself, BMP does not influence routing decisions. It is strictly observational.

BMP streams routing updates and other BGP statistics from a router to a centralized collector in real time, giving engineers full visibility into what the router is seeing and doing.

The Visibility Challenge with BGP

Traditionally, engineers troubleshoot BGP using CLI commands such as:

show ip bgp

show ip bgp neighbors [ip address]

This works well on individual routers.

But in large enterprise or service provider networks, you might have hundreds of BGP peers, millions of prefixes, and complex route policies.

If a prefix is missing or behaving unexpectedly, we might typically ask the following questions:

• Did the peer send it?
• Did inbound policy filter it?
• Was it rejected due to AS path?
• Was it withdrawn?

Answering these questions by logging into each router individually does not scale. In large networks, it is far more efficient to maintain a centralized repository of BGP control-plane data.

BMP enables this by continuously exporting BGP information from each router to a central data collector.

How BMP Works

BMP establishes a separate TCP session from a router to a monitoring station, known as a BMP collector. 

The collector’s IP address and port are configured under the BGP process on the router, and then activated per neighbor. For example:

router bgp 65000

bmp server 1 address 10.10.10.100 port 5000

neighbor 192.0.2.1 remote-as 65001
neighbor 192.0.2.1 bmp-activate server 1

The BMP collector does not send any messages to the router but simply listens for incoming messages.

Once the session is established, the router sends:

• Initiation / Termination messages
• Peer Up / Peer Down messages
• Route Monitoring messages (initial BGP table dump + incremental route updates)
• Statistics Reports (number of prefixes sent and received, etc)
• Route Mirroring messages (allows exact duplication of a BGP session)

One of BMP’s most powerful capabilities is its ability to export both:

Pre-Policy Routes

Routes exactly as received from a peer, before any route maps or filters are applied.

Post-Policy Routes

Routes after inbound policies have been applied, showing what was actually accepted into the BGP table.

This distinction is critical.

If a route disappears, BMP allows you to determine whether:

• The peer never sent it
• Your policy filtered it
• It failed validation
• It was withdrawn

Key Advantages of BMP

BMP provides several major advantages.

1. Scalable Troubleshooting

In networks with route reflectors and layered policies, control-plane visibility is essential. BMP provides centralized insight across all routers and peers.

Instead of logging into devices individually, you analyze a unified stream of BGP activity.

2. Security Monitoring

BMP enables detection of:

• Route leaks
• Prefix hijacks
• Unexpected mass withdrawals
• Abnormal update churn

Security teams can monitor routing behavior in near real time and correlate anomalies across the network.

3. Historical Analysis

Unlike CLI commands, BMP feeds collectors that store data over time.

This enables:

• Trend analysis
• Churn measurement
• Peer stability tracking
• Capacity planning

When something breaks, you can rewind and see exactly when and why it happened.

BMP in Route Reflector Environments

BMP is particularly valuable in route reflector architectures.

Route reflectors simplify iBGP scaling, but they can obscure routing differences between clients. If one client is missing a route, troubleshooting can become difficult.

With BMP enabled on route reflectors (or clients), you can see:

• What each peer advertised
• What policies accepted or rejected
• What was reflected
• What was installed

For large-scale networks, this level of visibility is transformative.

Deployment Considerations

Before enabling BMP, keep a few factors in mind:

• CPU impact – exporting full routing tables can be resource-intensive
• Bandwidth usage – initial table dumps are large
• Storage requirements – historical BGP data grows quickly
• Collector security – control-plane data should be protected

A best practice is to:

• Start with route reflectors
• Monitor system performance
• Scale collectors appropriately

Because BMP is observational and does not alter routing decisions, it can generally be deployed with low operational risk.

Final Thoughts

BMP offers advanced telemetry and diagnostic capabilities for BGP.

In modern networks where many systems are centrally managed and software-driven, network-wide visibility into the BGP control plane is a significant operational advantage.

BMP delivers continuous, real-time insight into BGP behavior, including which prefixes were received, filtered, and installed.

It allows a full audit of BGP anomalies from a centralized location.

And in large networks, that audit log can help resolve BGP issues in a fraction of the time it would take to manually troubleshoot via CLI.

About the Author

BGP Brian (Brian Wilson) runs a BGP training community on Discord called BGP Black Belt. He also regularly posts about BGP topics on LinkedIn. You can find him at www.linkedin.com/in/brianwilson-bgp.