> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbitelshield.com/llms.txt > Use this file to discover all available pages before exploring further. # 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. > [!WARNING] > > 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](https://docs.orbitelshield.com/protection/tunnels.md). ## 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. EXPLORE THE FILTERING PIPELINE > [!NOTE] > > 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. > [accordion] 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. > [accordion] 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. > [accordion] 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. > [accordion] 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. > [accordion] 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. > [accordion] Crafted packets > > Drop malformed headers, land attacks, martian sources, and SYN packets shaped like SACK Panic before later inspection stages. > [accordion] 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. > [accordion] Pulse waves > > Recognize short repeating bursts by their shape. Filtering holds through the gaps rather than immediately stepping aside between bursts. > [accordion] 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 > [tab] 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. > [tab] 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](https://docs.orbitelshield.com/quickstart.md). ## 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. | > [!WARNING] > > 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](https://docs.orbitelshield.com/protection/tunnels.md) for delivery checks and [plans and onboarding](https://docs.orbitelshield.com/quickstart.md) 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](https://docs.orbitelshield.com/operations/analytics.md). ### Request a focused protection review When opening a [support ticket](https://portal.orbitelshield.com/support/new), 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](https://portal.orbitelshield.com/support/new?urgent=true). ## Monitor and review changes After onboarding, use [analytics](https://docs.orbitelshield.com/operations/analytics.md) 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 > [accordion] 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. > [accordion] 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. > [accordion] 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 > [card] [Protected tunnels](https://docs.orbitelshield.com/protection/tunnels.md) > > Configure the delivery path, generated router configuration, and MTU. > [card] [Analytics and alerts](https://docs.orbitelshield.com/operations/analytics.md) > > Inspect recorded attacks, traffic windows, and alert channels. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.