Network protection and edge filtering

Prepare IPv4 and IPv6 prefixes for BGP scrubbing, understand Orbitel Shield’s filtering pipeline, and review attack guards and mitigation modes.

Orbitel Shield announces your prefixes over BGP so traffic for every address reaches its scrubbing edge before your network. This guide covers routing requirements, the filtering pipeline, supported attack guards, and the difference between always-on and on-demand mitigation.

​

Prefix and routing requirements

Requirement	Documented support
IPv4 prefixes	/24
IPv6 prefixes	/48
Larger address blocks	Added one /24 or /48 at a time
Authorization	You must be allowed to use the prefixes
RPKI	A ROA that allows Orbitel Shield’s announcement
IRR	Route objects that allow the announcement
Private or reserved ranges	Cannot be announced
Clean traffic delivery	GRE or WireGuard to your router

A smaller range is protected as part of the /24 or /48 that contains it. Other networks do not accept the longer announcements described in the website’s prefix FAQ.

Review routing authorizations with the onboarding team before production traffic moves. The public website does not publish the announcing ASN or exact ROA and IRR object values to use. Do not substitute guessed values.

​

From announcement to protected traffic

1. Add authorized prefixes

   Add each IPv4 /24 or IPv6 /48 in the panel. Work with the team to check your ROA and IRR records.

2. Announce from the scrubbing network

   Orbitel Shield announces the prefixes over BGP. Incoming traffic for the addresses reaches the edge first.

3. Filter incoming traffic

   Packets are inspected at the edge closest to their source. Attack traffic is dropped before it can saturate your access links.

4. Deliver clean traffic

   Filtered traffic travels to your routers over GRE or WireGuard, and replies return through the tunnel. Use the generated routing configuration for your service.

Your workloads, server addresses, and DNS stay unchanged for this prefix-based deployment. The local configuration change is the tunnel and associated routing that delivers traffic to your network. See protected tunnels.

​

The four-stage filtering pipeline

Every packet passes the documented pipeline. Earlier stages discard obvious unwanted traffic so later stages can focus on traffic that needs closer inspection.

1. Hardware filters: Drop and permit rules, unused protocols, and malformed packets are handled at line rate.
2. FPGA meters: Per-source rate limits and flood meters apply configured rates to the remaining traffic.
3. Stateful inspection: Handshakes, queries, and payloads are checked to identify attacks that resemble legitimate traffic.
4. Machine learning: Classifiers score remaining flows and tighten when probing is detected.

This explorer describes the published stages, not a live traffic view or performance benchmark. The website’s traffic-volume illustrations are examples of an attack, not guaranteed capacity for your plan.

​

Attack guards

Each guard watches a particular attack pattern. Guards can run in observe mode first, counting what they would drop without dropping it.

Reflection and amplification

Drop responses your servers did not request. Seventeen reflection vectors are known out of the box, including DNS, NTP, memcached, CLDAP, and SSDP. Additional vectors can be added for your needs.

SYN floods

Once a flood starts, opening SYN packets from sources without a connection are held back. Legitimate clients that retry can still get through.

ACK and state floods

Drop TCP traffic that does not belong to a connection. The guard learns your servers’ traffic first so established sessions can continue flowing.

Fragment floods

Fragmented TCP and ICMP are dropped by default. UDP fragments remain open for games that use them unless you close them too. Review this distinction before changing fragmentation controls for gaming traffic.

ICMP floods

Rate-limit pings, catch smurf replies, and drop errors that do not quote a packet you sent. The website states that path MTU discovery continues working.

Crafted packets

Drop malformed headers, land attacks, martian sources, and SYN packets shaped like SACK Panic before later inspection stages.

Unused IP protocols

Drop protocols your addresses do not receive. GRE, ESP, SCTP, and other protocols are opened where needed. Review required protocols with your engineer rather than allowing everything by default.

Pulse waves

Recognize short repeating bursts by their shape. Filtering holds through the gaps rather than immediately stepping aside between bursts.

Carpet bombing

Judge a flood distributed across a whole address range together. Filtering can engage without waiting for one individual address to exceed a threshold.

​

Always-on and on-demand mitigation

Always on

This is the documented default for network filtering. Every packet is filtered continuously, so filtering does not wait for attack detection before handling incoming traffic. Nothing needs to switch on when an attack starts.

On demand

Traffic passes without filtering until it crosses the packet-rate or bit-rate threshold you set. Filtering then engages and holds longer each time the same attack returns. The website states engagement occurs in under a second after the threshold is crossed; confirm requirements with the team rather than treating that statement as a contractual SLA.

Observe mode is a guard-level setting that counts matching traffic without dropping it. It is not another name for on-demand mitigation. Review both the overall mitigation mode and individual guard modes during onboarding or a rule change.

​

Protocols and address coverage

Network protection covers TCP, UDP, and ICMP. GRE, ESP, AH, SCTP, and other protocols can be supported where your services need them. Because unused protocols are dropped, tell the engineers which ones you actually use.

Every address in the protected prefixes is covered without per-IP pricing. Plans charge a flat monthly price for clean bandwidth, not for attack traffic. Legitimate traffic above your plan’s clean speed is rate-limited to that speed rather than classified as an attack. See plans and onboarding.

​

Improve your network protection

Effective protection depends on correct routing, filters that match your services, and a delivery path that remains usable during an incident. Use this checklist to review an existing deployment with your network team and Orbitel Shield engineer.

​

1. Verify prefix coverage and routing

• Confirm that every production address range you intend to protect is included in the configured IPv4 /24 or IPv6 /48 prefixes.
• Review ROAs and IRR route objects with your engineer, especially after an ownership or routing change. Use the announcement values supplied for your deployment, not guessed ASN values.
• Check that clean traffic reaches your routers through the configured tunnels and that replies follow the generated return routing.
• Coordinate prefix removal carefully: withdrawing a prefix also removes Orbitel Shield filtering for that range.

​

2. Match guards to legitimate traffic

Document the TCP and UDP services, IP protocols, normal packet rates, and fragmentation behavior your applications need. Give this information to your engineer before tightening filters.

Review area	Recommended action
Unused protocols	Ask your engineer to close protocols your protected services do not need. Keep required protocols explicitly accounted for.
Reflection traffic	Review recorded vectors and whether the reflection guards match the services you actually run.
UDP fragments	Confirm application requirements before disabling them. Some games need fragmented UDP traffic.
Rate thresholds	Base proposed limits on observed legitimate peaks, not just average traffic or an attack’s peak rate.
Guard changes	Discuss observe mode first, then review would-be drops against legitimate activity before enforcement.

More restrictive filtering is not automatically better protection. A rule that blocks legitimate clients can cause an outage even when attack traffic is being dropped. Agree on how to revert a change with your engineer before enforcing it.

​

3. Review mitigation mode

Always-on filtering is the documented default and does not wait for an on-demand threshold to be crossed. If your service uses on-demand mitigation, review packet-rate and bit-rate thresholds with your engineer against normal traffic patterns and incident requirements.

Observe mode does not block matching traffic. Confirm which guards are observing and which are enforcing so you do not mistake visibility for active filtering.

​

4. Check clean traffic delivery and capacity

• Review tunnel state at each scrubbing node, not just whether the tunnel configuration exists.
• Check MTU, TCP MSS, and return routing against your service’s generated configuration. Do not reuse another deployment’s values.
• Compare legitimate peak demand with your plan’s clean bandwidth. Clean traffic above the plan speed is rate-limited; stronger attack filtering does not increase that allowance.

See tunnel configuration for delivery checks and plans and onboarding for clean bandwidth options.

​

5. Validate improvements with service health

Before changing a guard, record normal traffic and application behavior. After the change, compare the same measurements:

• Offered, dropped, and delivered traffic for the affected prefix.
• Attack vectors and peak rates in recorded events.
• Successful connections, application errors, and latency from your own service monitoring.
• Reports from legitimate users, including problems limited to a protocol or client group.

Configure alerts for attack starts and ends, mitigation changes, and tunnel-down events. A high drop count alone does not prove users can reach the service. See analytics and alerts.

​

Request a focused protection review

When opening a support ticket, include the service and affected prefixes, incident timestamps in UTC, expected legitimate protocols, observed symptoms, and any recent routing or filtering changes. Describe the outcome you need, such as preserving game traffic while reducing reflection traffic, rather than requesting an arbitrary rate limit.

For an active attack affecting availability, open an urgent request.

​

Monitor and review changes

After onboarding, use analytics to review offered, dropped, and delivered traffic for the relevant prefixes. Investigate recorded vectors rather than inferring the attack type from traffic volume alone.

If you need to change filtering, explain the expected legitimate traffic to your engineer and discuss observing the guard before enforcing a new setting. Check application availability as well as the traffic graphs after a change.

If you remove a prefix, Orbitel Shield stops announcing and filtering it. The website says traffic returns to normal transit within a few seconds. Coordinate removal with your network team; do not assume protection continues after withdrawal.

​

Frequently asked questions

Do my servers need new addresses?

No. Prefix protection is a routing change, not a workload migration. Your server addresses and DNS stay the same.

Can I protect only a smaller subnet?

The advertised units are IPv4 /24 and IPv6 /48. A smaller range is protected as part of its containing /24 or /48.

Is attack bandwidth billed?

No. The published plans charge for clean traffic at a flat monthly price. Attack traffic absorbed at the edge does not count toward it.

​

Continue your deployment

Protected tunnels

Configure the delivery path, generated router configuration, and MTU.

Analytics and alerts

Inspect recorded attacks, traffic windows, and alert channels.