# Isolating request paths in routers

**URL:** <https://openziti.discourse.group/t/isolating-request-paths-in-routers/3847>\
**Category:** Ziti Overlay\
**Created:** [January 29, 2025, 5:42pm UTC](https://openziti.discourse.group/t/isolating-request-paths-in-routers/3847 "2025-01-29T17:42:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sadath-12](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sadath-12/32/2043_2.png) [@sadath-12](https://openziti.discourse.group/u/sadath-12)\
**Post date:** [January 29, 2025, 5:42pm UTC](https://openziti.discourse.group/t/isolating-request-paths-in-routers/3847/1 "2025-01-29T17:42:50Z")

</div>

Lets say we have multiple routers and clients in our ziti network.  
I want to define one group of routers as "red group" and another group of routers as "blue group".  
I have clients that can be in either "red group" or "blue group".

Is there a way to define policies such that, when a client part of "blue group" makes a request to a ziti service. His traffic only travels through routers that are also part of the "blue group".

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [January 29, 2025, 6:03pm UTC](https://openziti.discourse.group/t/isolating-request-paths-in-routers/3847/2 "2025-01-29T18:03:01Z")

</div>

Hello again, @sadath-12. Yes, it's done by placing each router's link listeners or dialers or both into distinct "link groups" ([reference](https://openziti.io/docs/reference/configuration/router/#link)) in each router's configuration YAML file.

Then, you must partition the edge policies by identities or services or both, granting them permission to use routers known by roles attributes.

In summary, identities will select a router for services' data path by matching an edge router policy, and routers will find a data path by "link group."

Using your example, let's assume there are four routers:

1. red1 with role `#red-routers`
2. red2 with role `#red-routers`
3. blue3 with role `#blue-routers`
4. blue4 with role `#blue-routers`

You'll need two edge router policies:

1. `#red-identities` / `#red-routers`
2. `#blue-identities` / `#blue-routers`

If you're "steering" the traffic by edge router policy (ERP), then you may have a global service edge router policy (SERP) like `#all` / `#all`, or you may also wish to partition by services, in which case you must have a SERP for each:

1. `#red-services` / `#red-routers`
2. `#blue-services` / `#blue-routers`

Here's the links snippet from red1's config YAML.

```yaml
link:
  dialers:
    - binding: transport
      groups:
        - red-routers
  listeners:
    - binding: transport
      bind: tls:0.0.0.0:3022
      advertise: tls:red1.ziti.example.com:3022
      groups:
        - red-routers

```

Here's the links snippet from blue3's config YAML.

```yaml
link:
  dialers:
    - binding: transport
      groups:
        - blue-routers
  listeners:
    - binding: transport
      bind: tls:0.0.0.0:3022
      advertise: tls:blue3.ziti.example.com:3022
      groups:
        - blue-routers

```

This will partition the data plane at both layers: identity-to-router edge (or service-to-router edge), and router-to-router fabric links.