RPF
Материал из Xgu.ru
Reverse Path Forwarding (RPF) — это проверка, которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без петель.
Различают также uRPF (unicast RPF) — это функция, которая используется для предотвращения спуфинга unicast IP-адресов.
На этой странице рассматривается RPF для multicast.
RPF это одна из основ маршрутизации multicast трафика. Именно эта проверка позволяет маршрутизаторам передавать пакеты вниз по дереву для передачи мультикаст трафика и избегать при этом петель.
Содержание |
[править] Процедура RPF
Проверка RPF:
- Маршрутизатор ищет IP-адрес отправителя, который находится в пришедшем пакете multicast, в unicast таблице маршрутизации
- Если маршрутизатор находит IP-адрес отправителя (источника трафика) в таблице маршрутизации:
- Если пакет от источника вошел в тот же интерфейс, который используется в маршруте к источнику, то проверка пройдена и multicast трафик передается дальше
- Если пакет от источника вошел не в тот интерфейс, который используется в маршруте к источнику, то проверка НЕ пройдена и multicast пакет отбрасывается
- Если маршрутизатор НЕ находит IP-адрес отправителя (источника трафика) в таблице маршрутизации, то проверка НЕ пройдена и multicast пакет отбрасывается
|
|
Проверка 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
Проверку 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
|
|
Конечно же в реальной жизни не стоит использовать команду debug ip mpacket. Или использовать с большой осторожностью и когда сеть не загружена. Здесь она показана для демонстрации того, что служебные сообщения PIM также проходят проверку RPF. |
[править] Дополнительная информация
- Cisco:
