Xgu.ru теперь в Контакте  — приходите и подключайтесь.
Пока мы работаем над следующими видео, вы можете подключиться в Контакте. Познакомимся и обсудим новые страницы и ролики.

Vk-big.pngYoutube-big.jpeg

RPF

Материал из Xgu.ru

Перейти к: навигация, поиск
stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.


Reverse Path Forwarding (RPF) — это проверка, которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без петель.

Различают также uRPF (unicast RPF) — это функция, которая используется для предотвращения спуфинга unicast IP-адресов.

На этой странице рассматривается RPF для multicast.

RPF это одна из основ маршрутизации multicast трафика. Именно эта проверка позволяет маршрутизаторам передавать пакеты вниз по дереву для передачи мультикаст трафика и избегать при этом петель.

Содержание

[править] Процедура RPF

Проверка RPF:

  1. Маршрутизатор ищет IP-адрес отправителя, который находится в пришедшем пакете multicast, в unicast таблице маршрутизации
  2. Если маршрутизатор находит IP-адрес отправителя (источника трафика) в таблице маршрутизации:
    1. Если пакет от источника вошел в тот же интерфейс, который используется в маршруте к источнику, то проверка пройдена и multicast трафик передается дальше
    2. Если пакет от источника вошел не в тот интерфейс, который используется в маршруте к источнику, то проверка НЕ пройдена и multicast пакет отбрасывается
  3. Если маршрутизатор НЕ находит IP-адрес отправителя (источника трафика) в таблице маршрутизации, то проверка НЕ пройдена и multicast пакет отбрасывается

Note-icon.gif

Проверка RPF выполняется не только для самих данных (multicast-трафика), но и для некоторых служебных сообщений.

[править] RPF и балансировка

[править] Варианты влияния на проверку RPF

[править] Статический маршрут для multicast трафика

[править] Multicast BGP (MBGP)

Multicast BGP это расширение BGP, которое позволяет влиять на проверку BGP. Маршруты, которые передаются в MBGP не используются для маршрутизации, а используются для проверки RPF.

[править] RPF в Cisco

Просмотр информации RPF:

dyn2# sh ip rpf 192.168.1.1
RPF information for ? (192.168.1.1)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (192.168.1.1) - directly connected
  RPF route/mask: 192.168.1.0/24
  RPF type: unicast (connected)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
dyn2# sh ip rpf 192.168.1.1 metric 
RPF information for ? (192.168.1.1)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (192.168.1.1) - directly connected
  RPF route/mask: 192.168.1.0/24
  RPF type: unicast (connected)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
  Metric preference: 0
  Metric: 0

[править] Изменение параметров RPF

RPF зависит от unicast таблицы маршрутизации. Можно поменять таймеры, которые отвечают за время реагирования RPF на изменения в таблице маршрутизации:

dyn(config)# ip multicast rpf backoff <min-delay> <max-delay>

Значение min-delay указывает сколько миллисекунд маршрутизатор ждет после изменения unicast таблицы маршрутизации, прежде чем пересчитает интерфейсы RPF. Эта задержка удваивается после каждого последующего изменения топологии, которое происходит во время max-delay. Задержка никогда не превышает max-delay.

Интервал выполнения проверки RPF (по умолчанию 10 секунд (или 5)):

dyn2(config)# ip multicast rpf interval 15 

Интервал можно изменить и только для определенных групп. Для этого к предыдущей команде добавляется параметр list с указанием ACL:

dyn2(config)# ip multicast rpf interval 15 list 1

или параметр route-map:

dyn2(config)# ip multicast rpf interval 15 route-map RPF_map


Проверка счетчиков и событий:

dyn#sh ip rpf events 
Last 15 triggered multicast RPF check events

RPF backoff delay: 20 msec
RPF maximum delay: 200 msec

DATE/TIME             BACKOFF    PROTOCOL   EVENT         RPF CHANGES
Mar 1 03:48:22.719    500 msec   PIM        Nbr UP          0
Mar 1 02:15:51.515    500 msec   EIGRP      Route UP        0
Mar 1 02:15:49.815    500 msec   EIGRP      Route Down      0
Mar 1 02:15:43.259    500 msec   EIGRP      Route UP        0
Mar 1 02:14:08.059    500 msec   EIGRP      Route UP        0
Mar 1 02:13:16.711    500 msec   EIGRP      Route Down      0
Mar 1 02:13:09.959    500 msec   EIGRP      Route UP        0
Mar 1 02:13:03.411    500 msec   EIGRP      Route Down      0
Mar 1 02:08:16.207    500 msec   EIGRP      Route UP        0
Mar 1 02:08:13.507    500 msec   EIGRP      Route Down      0
Mar 1 01:51:19.335    1 sec      OSPF       Route UP        0
Mar 1 01:51:18.343    500 msec   EIGRP      Route Down      0
Mar 1 01:51:10.835    500 msec   EIGRP      Route Down      0
Mar 1 01:40:01.723    500 msec   PIM        Nbr UP          0
Mar 1 01:39:03.175    500 msec   PIM        Nbr UP          0

[править] Варианты влияния на проверку RPF в Cisco

[править] Статический маршрут для multicast трафика

Когда multicast трафик передается по сети, каждый маршрутизатор выполняет проверку RPF (проверяет получен ли трафик через тот интерфейс, который ведет к отправителю multicast трафика в таблице маршрутизации для unicast трафика). Если проверка не пройдена, то трафик отбрасывается.

Существует возможность повлиять на проверку RPF не меняя настройки протоколов маршрутизации unicast трафика. Для этого настраивается статический маршрут для multicast трафика. Несмотря на название, фактически это не маршрут, а возможность указать дополнительный путь позволяющий пройти проверку RPF.

Настройка статического маршрута:

dyn3(config)# ip mroute 192.168.1.1 255.255.255.255 192.168.3.2

По умолчанию AD для маршрутов mroute равно 0, поэтому они выигрывают у любых динамических маршрутов и проверяются в первую очередь.

[править] Примеры

Так как, когда проверка RPF не пройдена, multicast-трафик не передается, необходимо знать как определить есть ли обратный путь к источнику с локального маршрутизатора.


[править] RPF для Register

PIM-SM cisco dr .png

Проверку RPF проходят не только мультикаст пакеты, но и служебные сообщения.

Например, на схеме изображенной на рисунке, источник трафика маршрутизатор R10. Маршрутизатор R2 - RP.

К источнику непосредственно присоединены два маршрутизатора: R8 и R9. R9 стал DR, значит он должен отправлять сообщение Register на RP.

Но, если на RPF-интерфейсе R9 не включен PIM, то регистрация не будет работать.

В данном случае, для R9 RPF-интерфейс, то есть, интерфейс, который в unicast таблице маршрутизации используется как исходящий по пути к RP, интерфейс f1/0.

На f1/0 отключен PIM. И тогда mtrace не отрабатывает:

R9#mtrace 2.2.2.2
Type escape sequence to abort.
Mtrace from 2.2.2.2 to 10.1.69.9 via RPF
From source (?) to destination (?)
Querying full reverse path... 
 0  10.1.69.9
-1  10.1.69.9 None No route
R9#sh ip rpf 2.2.2.2
RPF information for ? (2.2.2.2) failed, no route exists
R9#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.1.69.6 on FastEthernet1/0, 00:17:27 ago
  Routing Descriptor Blocks:
  * 10.1.69.6, from 192.168.13.2, 00:17:27 ago, via FastEthernet1/0
      Route metric is 3, traffic share count is 1

Вывод debug ip pim на маршрутизаторе R9 не показывает явно проблемы с регистрацией источника:

PIM(0): Check RP 2.2.2.2 into the (*, 237.1.1.1) entry

Проблемы с проверкой RPF видны в выводе debug ip mpacket:

s=10.1.89.10 (Fa0/0) d=237.1.1.1 id=1454, ttl=254, prot=1, len=114(100), RPF lookup failed for source or RP
s=10.1.89.10 (Fa0/0) d=237.1.1.1 id=1455, ttl=254, prot=1, len=114(100), RPF lookup failed for source or RP

Icon-caution.gif

Конечно же в реальной жизни не стоит использовать команду debug ip mpacket. Или использовать с большой осторожностью и когда сеть не загружена.

Здесь она показана для демонстрации того, что служебные сообщения PIM также проходят проверку RPF.

[править] Дополнительная информация

Источник — «http://871460.xgu.ru/wiki/RPF»