# Практика

Немного практики для закрепления

Имеем вот такую топологию:

![](http://img-fotki.yandex.ru/get/6716/83739833.2b/0_c0950_6b7e5d1_XXL.png)

В данный момент трафик R1-R5 и обратно идет по маршруту R1-R2-R4-R5, для удобства, адреса присвоены так, чтобы последняя цифра адреса была номером маршрутизатора:

> R1#traceroute 192.168.100.5\
> 1 192.168.0.2 20 msec 36 msec 20 msec\
> 2 192.168.2.4 40 msec 44 msec 16 msec\
> 3 192.168.100.5 56 msec \* 84 msec
>
> R5#traceroute 192.168.0.1\
> 1 192.168.100.4 56 msec 40 msec 8 msec\
> 2 192.168.2.2 20 msec 24 msec 16 msec\
> 3 192.168.0.1 64 msec \* 84 msec

Для примера, предположим, что нам нужно, чтобы обратно трафик от R5 (с его адресом в источнике) шел по маршруту R5-R4-**R3**-R1. По схеме очевидно, что решение об этом должен принимать R4. На нем сначала создаем ACL, который отбирает нужные нам пакеты:

```
R4(config)#access-list 100 permit ip host 192.168.100.5 any
```

Затем создаем политику маршрутизации с именем “BACK”:

```
R4(config)#route-map BACK
```

Внутри нее говорим, какой трафик нас интересует:

```
R4(config-route-map)#match ip address 100
```

И что с ним делать:

```
R4(config-route-map)#set ip next-hop 192.168.3.3
```

После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:

```
R4(config)#int fa1/0
R4(config-if)#ip policy route-map BACK
```

Проверяем:

> R5#traceroute 192.168.0.1\
> 1 192.168.100.4 40 msec 40 msec 16 msec\
> 2 192.168.3.3 52 msec 52 msec 44 msec\
> 3 192.168.1.1 56 msec \* 68 msec

Работает! А теперь посмотрим внимательно на схему и подумаем: все ли хорошо?

А вот и нет!\
Следуя данному ACL, у нас заворачивается на R3 весь трафик с источником R5. А это значит, что если, например, R5 захочет попасть на R2, он, вместо короткого и очевидного маршрута R5-R4-R2, будет послан по маршруту R5-R4-R3-R1-R2. Поэтому, нужно очень аккуратно и вдумчиво составлять ACL для PBR, делая его максимально специфичным.

В этом примере мы в качестве действия, применяемого к трафику, выбрали переопределение некстхопа (узла сети, куда дальше отправится пакет). А что еще можно сделать с помощью PBR? Имеются в наличие команды:

* set ip next-hop
* set interface
* set ip default next-hop
* set default interface

С первыми двумя все относительно понятно – они переопределяют некстхоп и интерфейс, из которого пакет будет выходить (чаще всего set interface применяется для point-to-point линков). А в случае, если мы применяем команды set ip **default** next-hop или set **default** interface, роутер сначала смотрит таблицу маршрутизации, и, если там имеется маршрут для проверяемого пакет, отправляет его соответственно таблице. Если маршрута нет, пакет отправляется, как сказано в политике. К примеру, если бы мы в нашей топологии вместо set ip next-hop 192.168.3.3 скомандовали set ip default next-hop 192.168.3.3, ничего бы не поменялось, так как у R4 есть маршрут к R1 (через R2). Но если бы он отсутствовал, трафик направлялся бы к R3.

> Вообще говоря, с помощью команды **set** можно изменять очень много в подопытном пакете: начиная от меток QoS или MPLS и заканчивая атрибутами BGP


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://linkmeup.gitbook.io/sdsm/8.-bgp-i-ip-sla/3.-pbr/1.-praktika.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.