WeOS
5.29.0

# Policy-Based Routing (PBR)

## About

This document aims to provide some example use cases and example scenarios how Policy-Based Routing (PBR) could be utilised to solve specific routing situations.

Related Documentation

- Policy-Based Routing (PBR) Configuration Guide

## Introduction

Utilisation of PBR allows an operator to configure routing setups that can perform decisions on additional criteria, rather than it just being based on the destination address, as with regular routes. This can allow for more agile routing solutions and a toolkit to solve specific situations.

The examples presented in this document are intended to provide ideas and inspiration as to how PBR can be applied and utilised, not necessarily general solutions applicable in every situation.

Use cases presented in this document

- Case 1: Source-Based Routing
- Case 2: Protocol-Based Routing
- Case 3: Locally Originated Traffic

## Case 1: Source-Based Routing

In regular routing the next hop is decided based on the destination IP address of a specific frame. However, situations may arise where it could be beneficial to base routing decisions on the source IP instead, performing source-based routing. There exist several reasons why this could be beneficial in different situations, here are just a few examples:

- Having specific ISPs handle frames from a select group of hosts
- Load-balancing of traffic towards different ISPs
- Prioritize traffic originating from specific hosts on higher-bandwidth links

In this use case scenario, policy-base routing will be utilised in order to direct traffic from different hosts towards different ISPs depending on their source IP, resulting in source-based routing.

Tip

It is possible to configure a policy-based route to perform source-based routing only for specific destination addresses. This can be done by combining the various match options when configuring the PBR instance, see this for all match options.

                          .--.-.
                         ( (    )__
                        (_,  \ ) ,_)  Internet
                          '-'--`--'
                           |     |
                           |     |
                   .-------'     '-------.
                   |                     |
                   |                     |
              .----+----.           .----+----.
              |         |           |         |
              |  ISP1   |           |  ISP2   |
              |         |           |         |
              '----+----'           '----+----'
               .99 |                     | .99
                   |                     |
     172.16.1.0/24 '-------.     .-------' 172.16.2.0/24
                           |     |
                        .1 |     | .1
                         .-+-----+-.
                         |         |
                         |   R1    |
                         |         |
                         '----+----'
                              | vlan1
                              |
                              |
                         .----+----.
     192.168.1.0/24      |         |      192.168.2.0/24
      .------+------+----+ Switch  +----+------+------.
      |      |      |    |         |    |      |      |
      |      |      |    '---------'    |      |      |
      |      |      |                   |      |      |
    .-+--. .-+--. .-+--.             .--+-. .--+-. .--+-.
    | H1 | | H2 | | H3 |             | H4 | | H5 | | H6 |
    '----' '----' '----'             '----' '----' '----'

Figure 1: Example of a setup with two different ISPs connected to the router R1. In addition, R1 is also connected to a switch with a number of hosts connected on two different VLANs.

The example topology presented in Figure 1, show a setup that have two different ISPs `ISP1` and `ISP2` that are both connected to the router `R1`, on the networks `172.16.1.0/24` and `172.16.2.0/24` respectively. Also connected to `R1` is a switch with a number of different hosts connected to it.

The main focus for this HowTo will be the configuration of router `R1`. The intent is to configure it so that any traffic originating from the network `192.168.1.0/24` is routed towards `ISP1` and any traffic originating from `192.168.2.0/24` is routed towards `ISP2`.

When this has been configured it should result in traffic originating from the hosts `H1`, `H2` and `H3` to be routed through `ISP1`. Similarly, the hosts `H4`, `H5` and `H6` should be routed through `ISP2`.

### Configuration

The policy-based routes are configured on router `R1`. We assume that all the interfaces have already been configured in a suitable manner. The important thing for the sake of the example, is that vlan1 have been configured as the interface connected to the downstream switch.

First we configure the policy-based route responsible for routing the frames with a source within `192.168.1.0/24` towards `ISP1` located at `172.16.1.99`:

    R1:/#> configure
    R1:/config/#> ip
    R1:/config/ip/#> policy-route 1
    R1:/config/ip/policy-route-1/#> match saddr 192.168.1.0/24
    R1:/config/ip/policy-route-1/#> in-iface vlan1
    R1:/config/ip/policy-route-1/#> next-hop 172.16.1.99
    R1:/config/ip/policy-route-1/#> end
    R1:/config/ip/#>

Next we configure the second policy route, responsible for handling routing of frames with sources within `192.168.2.0/24` towards `ISP2` located at `172.16.2.99`:

    R1:/config/ip/#> policy-route 2
    R1:/config/ip/policy-route-2/#> match saddr 192.168.2.0/24
    R1:/config/ip/policy-route-2/#> in-iface vlan1
    R1:/config/ip/policy-route-2/#> next-hop 172.16.2.99
    R1:/config/ip/policy-route-2/#> end
    R1:/config/ip/#>

If we check the overall policy routing configuration it should now look something like the following:

    R1:/config/ip/#> show policy-route
    ID   ENA  PREF  IN-IFACES   MATCH     VALUE                 NEXT-HOP
    1    Yes  Auto  vlan1       saddr:    192.168.1.0/24        172.16.1.99
    2    Yes  Auto  vlan1       saddr:    192.168.2.0/24        172.16.2.99

If everything looks like expected, leave the configuration context to apply to configuration:

    R1:/config/ip/#> leave
    Applying configuration.
    Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
    R1:/#>

### Status

When the policy routes have been configured they should be observable using the following command:

    R1:/#> show ip policy-route
    PRIO  SADDR           DADDR  SPORT  DPORT  IN-IFACE  NEXT-HOP
    300   192.168.1.0/24  -      -      -      vlan1     172.16.1.99
    301   192.168.2.0/24  -      -      -      vlan1     172.16.2.99

If the `NEXT-HOP` is reports `Unreachable` the link towards the next-hop may be down. It could also be the case that the network have not been configured correctly, since if there is no network in the same subnet as the next hop, the route will not be active.

Note

The status of the policy routes should be viewed using the `show ip policy-route` command, they will not be presented when using the regular `show ip route` command.

## Case 2: Protocol-Based Routing

Imagine in this specific scenario that we want to route all WEB related traffic in direction towards a particular ISP, while all the other traffic is routed to another. We can achieve this by utilising PBR and perform matching on the port numbers used by the protocols.

                               .--.-.
                              ( (    )__
                             (_,  \ ) ,_)  Internet
                               '-'--`--'
                                |     |
                                |     |
                        .-------'     '-------.
               .-->     |                     |     <--.
               |        |                     |        |
       Other   |   .----+----.           .----+----.   | HTTP/HTTPS
       Traffic |   |         |           |         |   | Traffic
               |   |  ISP1   |           |  ISP2   |   |
               |   |         |           |         |   |
               |   '----+----'           '----+----'   |
                    .99 |                     | .99
                        |                     |
          172.16.1.0/24 '-------.     .-------' 172.16.2.0/24
                                |     |
                             .1 |     | .1
                              .-+-----+-.
                              |         |
                              |   R1    |
                              |         |
                              '----+----'
                                   | vlan1
                                   |
                                   |
                               .--.-.
                              ( (    )__
                             (_,  \ ) ,_)  LAN
                               '-'--`--'

Figure 2: Example of a setup with two different ISPs connected to the router R1. Where R1 is configured to send all the HTTP/HTTPS request traffic towards ISP2 and the rest towards ISP1.

The example scenario presented in Figure 2 shows two different ISPs, `ISP1` and `ISP2`, connected to the router `R1`. The goal is that we want any HTTP and HTTPS traffic originating from the LAN network to be routed towards `ISP2`, located on next hop `172.16.2.99`. Any other traffic from the LAN should be sent towards `ISP1` located at the next hop `172.16.1.99`.

To achieve this desired behaviour a regular default gateway is configured on `R1` directing traffic towards `ISP1`. Afterwards, a policy-based route is configured on `R1` that matches on the destination ports, 80 for HTTP and 443 for HTTPS, with `ISP2` as the next hop address located at `172.16.2.99`.

This specific example focuses on requests originating somewhere on the LAN, for a web server located somewhere on the internet.

Note

Configuring the PBR in this way would only enforce outgoing traffic, as in trying to access a WEB page from the LAN located on the internet, since we are matching on the destination port.

Say we would want to access a web server on the LAN from the internet, but retain the same routing, we would also need to add a similar rule that matches on source port instead of destination.

### Configuration

The policy-based routes are configured on router `R1`. We assume that all the interfaces have already been configured in a suitable manner.

First we configure a regular default route towards `ISP1` that should handle all the other traffic:

    R1:/#> configure
    R1:/config/#> ip
    R1:/config/ip/#> route default 172.16.1.99
    R1:/config/ip/#>

Now we can configure the policy-based routes. In this case we will need to configure two separate instances, one to handle HTTP (port 80), and another to handle HTTPS (port 443). We start with the configuration of the HTTP matching route:

    R1:/config/ip/#> policy-route 1
    R1:/config/ip/policy-route-1/#> match dport 80
    R1:/config/ip/policy-route-1/#> in-iface vlan1
    R1:/config/ip/policy-route-1/#> next-hop 172.16.2.99
    R1:/config/ip/policy-route-1/#> end
    R1:/config/ip/#>

Now we configure a second policy-based route instance for covering HTTPS traffic:

    R1:/config/ip/#> policy-route 2
    R1:/config/ip/policy-route-2/#> match dport 443
    R1:/config/ip/policy-route-2/#> in-iface vlan1
    R1:/config/ip/policy-route-2/#> next-hop 172.16.2.99
    R1:/config/ip/policy-route-2/#> end
    R1:/config/ip/#>

The configuration should now look something like this:

    R1:/config/ip/#> show policy-route
    ID   ENA  PREF  IN-IFACES   MATCH     VALUE                 NEXT-HOP
    1    Yes  Auto  vlan1       dport:    80                    172.16.2.99
    2    Yes  Auto  vlan1       dport:    443                   172.16.2.99
    R1:/config/ip/#>

If everything looks okay we can leave the configuration context, in order to apply the configuration:

    R1:/config/ip/#> leave
    Applying configuration.
    Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
    R1:/#>

### Status

If everything has been set up correctly, the policy routes should now be active on the device:

    R1:/#> show ip policy-route
    PRIO  SADDR  DADDR  SPORT  DPORT  IN-IFACE  NEXT-HOP
    300   -      -      -      80     vlan1     172.16.2.99
    301   -      -      -      443    vlan1     172.16.2.99

If the `NEXT-HOP` reports `Unreachable`, the link towards the next-hop may be down. It could also be the case that the network have not been configured correctly, since if there is no network in the same subnet as the next hop, the route will not be active.

## Case 3: Locally Originated Traffic

The scenario presented in this case serve to provide an example how a policy route can be setup to apply only on frames originating from the device itself, essentially direct access to the router itself.

               .---------.                      .---------.
               |         |     172.16.1.0/24    |         |
               |   R1    +----------------------+   R2    |
               |         | .10              .20 |         |
               '----+----'                      '----+----'
                    | .10                        .20 |
    192.168.10.0/24 |                                | 192.168.20.0/24
                    | .1                          .2 |
                  .-+--.                           .-+--.
                  | H1 |                           | H2 |
                  '----'                           '----'

             GW: 192.168.10.10               GW: 192.168.20.20

Figure 3: Basic setup with two routers and two hosts.

Based on the topology presented in Figure 3, imagine that we for some reason would like both hosts to be able to reach both of the routers, but not each other. In order to achieve this we could use a simple policy-based route configuration, one on each of the routers.

However, first it is good to note why we may not be able to achieve this behaviour using regular static routes. For instance, if we want `H1` to be able to reach `R2` using regular static routes, we could configure `172.16.1.10` as the next hop for `192.168.10.0/24` on `R2`. Doing this would ensure that we could reach the net of host `H1` from `R2`.

In addition, we also want `H2` to be able to reach `R1`, so we add corresponding routes on `R1`, with `172.16.1.20` being the next hop for `192.168.20.0/24`.

At this point we would be able to reach `R2` from `H1` and correspondingly, `R1` from `H2`. However, the two hosts would also be able to reach each other, but we only wanted them to be able to reach the routers themselves.

Now, instead of adding static routes we want to configure policy-based routes on each of the routers, in a way that only allow the route to be utilised for traffic originating from the router itself. It will be setup so that `H2` can reach `R1` on `172.16.1.10` and so that `H1` can reach `R2` on `172.16.1.20`.

### Configuration

Each of the two routers, `R1` and `R2`, needs to be configured with a policy route each. We also assume for this scenario that all the relevant interfaces have already been configured.

Each of the policy routes are intended to be usable for frames originating from the device itself. This can be achieved by specifying the interface `lo` as the `in-iface` for the policy route. In addition, the match rule itself will be configured to be the `saddr` of the device itself. So for `R1` the `saddr` will be set to 172.16.1.10 and for `R2` it will be set to 172.16.1.20.

#### R1

The policy-based route instance is configured on the device in the following manner:

    R1:/#> configure
    R1:/config/#> ip
    R1:/config/ip/#> policy-route 1
    R1:/config/ip/policy-route-1/#> match saddr 172.16.1.10
    R1:/config/ip/policy-route-1/#> in-iface lo
    R1:/config/ip/policy-route-1/#> next-hop 172.16.1.20
    R1:/config/ip/policy-route-1/#> end
    R1:/config/ip/#> leave
    Applying configuration.
    Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
    R1:/#>

This policy-based route will ensure that any traffic directed towards `R1` on `172.16.1.10`, will have the response routed towards `172.16.1.20`.

#### R2

The policy-based route instance is configured on the device in the following manner:

    R2:/#> configure
    R2:/config/#> ip
    R2:/config/ip/#> policy-route 1
    R2:/config/ip/policy-route-1/#> match saddr 172.16.1.20
    R2:/config/ip/policy-route-1/#> in-iface lo
    R2:/config/ip/policy-route-1/#> next-hop 172.16.1.10
    R2:/config/ip/policy-route-1/#> end
    R2:/config/ip/#> leave
    Applying configuration.
    Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
    R2:/#>

This policy-based route will ensure that any traffic directed towards `R2` on `172.16.1.20`, will have the response routed towards `172.16.1.10`.

### Status

If both the routers have been configured correctly, the active policy-based routes should look something like this, starting with `R1`:

    R1:/#> show ip policy-route
    PRIO  SADDR           DADDR  SPORT  DPORT  IN-IFACE  NEXT-HOP
    300   172.16.1.10/32  -      -      -      lo        172.16.1.20

For `R2` it should look something like this:

    R2:/#> show ip policy-route
    PRIO  SADDR           DADDR  SPORT  DPORT  IN-IFACE  NEXT-HOP
    300   172.16.1.20/32  -      -      -      lo        172.16.1.10

### Verify the Behaviour

At this point it should be possible for `H1` to reach `R2` on 172.16.1.20. We can test this by simply using ping:

    H1:/#> ping count 3 172.16.1.20
    Press Ctrl-C to abort PING 172.16.1.20 (172.16.1.20): 56 data bytes
    64 bytes from 172.16.1.20: seq=0 ttl=63 time=3.379 ms
    64 bytes from 172.16.1.20: seq=1 ttl=63 time=3.731 ms
    64 bytes from 172.16.1.20: seq=2 ttl=63 time=3.655 ms

    --- 172.16.1.20 ping statistics ---
    3 packets transmitted, 3 packets received, 0% packet loss
    round-trip min/avg/max = 3.379/3.588/3.731 ms
    H1:/#>

However, we should not be able to reach anything in the 192.168.20.0/24 subnet, this includes `R2` on that address and `H2`:

    H1:/#> ping count 3 192.168.20.20
    Press Ctrl-C to abort PING 192.168.20.20 (192.168.20.20): 56 data bytes

    --- 192.168.20.20 ping statistics ---
    3 packets transmitted, 0 packets received, 100% packet loss
    H1:/#>
    H1:/#> ping count 3 192.168.20.2
    Press Ctrl-C to abort PING 192.168.20.2 (192.168.20.2): 56 data bytes

    --- 192.168.20.2 ping statistics ---
    3 packets transmitted, 0 packets received, 100% packet loss
    H1:/#>

The same verification could be done from `H1`, checking that `R1` on 172.16.1.10.

« Previous Next »