> For the complete documentation index, see [llms.txt](https://docs.link11.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.link11.com/welcome/system-overview/traffic-flow-with-link11-products.md).

# Traffic Flow with Link11 Products

There are two main ways to use Link11, depending on customer setup. The configuration will affect the flow of client traffic.

***

## 1. Split servers for dynamic and static content <a href="#whatistrafficflowwithlink11products-1.splitserversfordynamicandstaticcontent" id="whatistrafficflowwithlink11products-1.splitserversfordynamicandstaticcontent"></a>

In this configuration, the customer has separate servers for static vs. dynamic content.

Static content requests get redirected to the CDN. If the client is requesting content that has not yet been cached, the CDN will forward the request to the origin server for static content. Content will be cached for the amount of time that was configured.

Dynamic content requests will be forwarded to the Link11 proxies, which will filter out attacks and forward the clean traffic to the origin server for dynamic content. For more information, see [Traffic flow through Link11](#whatistrafficflowwithlink11products-trafficflowwithinfrastructureddos) below.

<figure><img src="/files/htBJOPMNQcDVDGbrgL0e" alt=""><figcaption></figcaption></figure>

***

## 2. Single backend configuration <a href="#whatistrafficflowwithlink11products-2.smallerbackendwithoutsplitcontent" id="whatistrafficflowwithlink11products-2.smallerbackendwithoutsplitcontent"></a>

If the content is not split across multiple servers, the Link11 setup is comparable to a serial connection where all products are linked sequentially.

Incoming content requests get redirected through the CDN, where if static content was cached, the CDN will answer with cached data. If the content was not cached or the request includes dynamic content, it will be redirected to the proxies, which will filter out attacks and forward the clean traffic to the origin. For more information, see [Traffic flow through Link11](#whatistrafficflowwithlink11products-trafficflowwithinfrastructureddos) below.

In this setup, a bit of performance is lost, but no split is needed.

<figure><img src="/files/wenNyBJfGXhbLFqaDnsF" alt=""><figcaption></figcaption></figure>

***

## Traffic flow through Link11 <a href="#whatistrafficflowwithlink11products-trafficflowwithinfrastructureddos" id="whatistrafficflowwithlink11products-trafficflowwithinfrastructureddos"></a>

<figure><img src="/files/W4gPy2R8rTds4I4qzEOY" alt=""><figcaption></figcaption></figure>

Link11 filtering begins with suspicious traffic being received on the Link11 infrastructure. (The discussion below assumes that a full Link11 setup is being used.)

Traffic arrives first at a Juniper router. Here, the firewall blocks easily-identified attacks.

Next, the traffic gets forwarded to a filter instance in front of the Network DDoS instance. (Usually 2 filters are installed on every router.) Here, UDP and other traffic gets scrubbed. \
At this point, [alarms](/administration/account/interface/alarming.md) will be triggered if anything unusual is detected. Filtered traffic is redirected back into the router, where it will be received on the clean internal side of the router.

Next, if Link11's web protection has been purchased, the traffic gets forwarded to the appropriate proxy (either [WebDDoS](/product-guides/web-ddos.md) or [WAAP](https://waap.docs.link11.com/)). HTTP/2 Traffic is sent to the nghttp instance which translates it into HTTP/1. The traffic then runs through the Link11 proxy, where malicious traffic is discarded.

Finally, the proxy sends the traffic back through the MX204 router, which forwards it to the backend.