RPF (Reverse Path Forwarding)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:52, 2 июня 2017.

Reverse Path Forwarding (RPF) — это проверка, которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без петель. Различают также uRPF (unicast RPF) — это функция, которая используется для предотвращения спуфинга unicast IP-адресов. На этой странице рассматривается RPF для multicast. RPF это одна из основ маршрутизации multicast трафика. Именно эта проверка позволяет маршрутизаторам передавать пакеты вниз по дереву для передачи мультикаст трафика и избегать при этом петель.

Процедура RPF

Проверка RPF:

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

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

Multicast BGP (MBGP)

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

Multicast RPF, как правило, обозначается просто как RPF, используется в сочетании с многоадресной маршрутизации протоколами MSDP, PIM-SM и PIM-DM в обеспечении петель переадресацию multicast-пакетов. В multicast, решение направить трафик на основе адреса источника, а не по адресу назначения, как при одноадресной маршрутизации. Это достигается за счет использовании специальной таблицы маршрутизации многоадресной или же одноадресной таблицы маршрутизации маршрутизатора.

В IP multicast, маршрутизатор пересылает пакеты от источника, чтобы добиться прогресса по дереву распространения и предотвращения петель маршрутизации. Маршрутизатор пересылает государственной мультикаст работает более логично, организуя таблицы, основанные на обратный путь, от приемника обратно к корню дерева распространения. Этот процесс называется обратный путь пересылки (RPF).

Когда многоадресного пакета входит интерфейс маршрутизатора, он будет выглядеть список сетей, доступных через этот интерфейс, т. е. он проверяет обратный путь пакета. Если маршрутизатор находит соответствующую запись маршрутизации в IP-адресе источника mulicast, проверка RPF проходит, и пакет пересылается на все другие интерфейсы, которые участвуют в многоадресной передачи для группы многоадресной рассылки. Если ОПП не удается, пакет отбрасывается. В результате пересылки пакета определяется на основании обратного пути пакета, а не путь вперед. RPF только маршрутизаторы пересылают пакеты, которые приходят на интерфейс, который также проводит запись маршрутизации для исходного пакета, тем самым нарушая цикл.

Это критически важно в избыточной топологии рассылки multicast. Потому что тот же пакет многоадресной рассылки может достичь того же маршрутизатора через несколько интерфейсов, проверка RPF, является неотъемлемой частью в решении пересылать пакеты или нет. Если маршрутизатор пересылаются все пакеты, которые приходят на интерфейс на интерфейс b, а также пересылаются все пакеты, приходящие на интерфейс B, чтобы интерфейс и обе интерфейсы получают тот же пакет, это создаст классический маршрутизации цикл, в котором пакеты будут пересылаться в обоих направлениях, пока их IP TTL истекает. Даже с учетом окончания срока жизни, все типы петель маршрутизации лучше избегать, поскольку они предполагают по крайней мере временную деградацию сети.

Базовые посылки можно проверить в RPF:

  • в одноадресной таблицы маршрутизации должны быть корректными и сошелся.
  • путь от отправителя к маршрутизатору и обратный путь от маршрутизатора обратно отправителю симметричны.

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

В случаях, когда ссылки являются однонаправленными, на обратном пути может произойти сбой.

Unicast RPF (uRPF)

uRPF, как определено в RFC 3704 является развитием концепции о том, что трафик от известных поврежденных сетей не должны приниматься на интерфейсы, от которых они никогда не должны происходить. Оригинальная идея, как видно в RFC 2827 было блокировать трафик на интерфейсе, если он получен из поддельных IP-адресов. Это разумное предположение для многих организаций просто запретить распространение личных адресов в сети, если только они явно используются. Это большая польза для магистральной сети в качестве блокирующих пакетов с заведомо поддельным адресом источника позволяет сократить подмены IP-адреса, который обычно используется в DOS, DDoS-атаке и сканирование сети, чтобы скрыть источник сканирования.

uRPF расширяет эту идею, используя знания все маршрутизаторы должны выполнять свою работу, используя свою информационную базу маршрутизации (RIB) или передача информационной базы (FIB), чтобы помочь ограничить возможные источники адресов, которые должны быть видны в интерфейсе. Пакеты поступают, если они исходят от лучший маршрутизатор по маршруту к источнику пакета, гарантируя, что:

пакеты, приходящие на интерфейс приходят из (потенциально) действительных хозяев, на что указывает соответствующая запись в таблице маршрутизации. пакеты с адресами источника, который не может быть достигнут через входной интерфейс может быть удален без нарушения нормального использования, так как они, вероятно, из-за неправильной настройки или злонамеренного источника. В случае симметричной маршрутизации, маршрутизации исходящих пакетов потоков вперед и назад по тому же пути, и терминальные сети только одна ссылка, это безопасное предположение, и uRPF могут быть реализованы без ожидаемой многими проблемами. Это особенно полезно для реализации ОПП на интерфейсах маршрутизаторов, подключенных к одиночно размещенных сетей и терминальных подсетей в качестве симметричной маршрутизации гарантировано. Как можно ближе, используя uRPF на реальный источник трафика также предотвращает их подделку, прежде чем он имеет шанс использования пропускной способности или достижения роутер не настроен для RPF и при этом ненадо пересылать.

К сожалению, это часто бывает на крупных интернет-магистралях, что маршрутизация является асимметричной и на таблицы маршрутизации нельзя полагаться, чтобы указать на лучший маршрут к источнику, чтобы добраться до маршрутизатора. В Таблице маршрутизации можно указать лучший путь и только в симметричном случае это приравнивают к лучшему обратный путь. Из-за этой асимметрии важно при реализации uRPF, чтобы быть в курсе потенциал асимметрии существовать для предотвращения случайного фильтрации легитимного трафика.

В RFC 3704 дает более подробную информацию о том, как продлить самое основное "этот адрес источника должно быть видно в таблице маршрутизации входного интерфейса" концепция, известная как строгий обратный путь пересылки, чтобы включить некоторые более расслабленной случаях, которые еще могут быть полезны, позволяя, по крайней мере, некоторая асимметричность.

Строгий режим

В строгом режиме каждый входящий пакет проверяется на соответствие FIB и если входящий интерфейс не самый лучший обратный путь, проверить пакет не удастся. По умолчанию пакеты не отбрасываются.

  • команды на Cisco устройствах - с IP-проверка источника можно добраться-через {rx} - строгий режим, {any}- свободный режим

Средний режи

FIB поддерживает альтернативный маршрут к заданному IP-адресу. Если входящий интерфейс совпадает с любым из маршрутов, связанных с IP-адресом, то пакет пересылается. В противном случае пакет отбрасывается.

Свободный режим

В свободном режиме-адрес каждого входящего пакета источника проверяется на FIB. Он отбрасывается только если адрес источника не доступен через любой из интерфейсов маршрутизатора.

Unicast RPF confusion

RPF часто неправильно определяется как Reverse Path Filtering, особенно когда дело доходит до unicast routing. Это вполне понятное толкование аббревиатуры в том, что когда RPF используется с unicast routing как в RFC 3704 будет разрешен или запрещен проход на основе RPF. Мысль о том, что трафик запрещен, если он не прошел проверку RPF и, следовательно, фильтруются, однако согласно RFC 3704 правильной интерпретацей заключается в том, что трафик передается, если он прошел проверку RPF. Несколько примеров правильного использования можно увидеть в документах компании Juniper, Сіѕсо, OpenBSD и самое главное в RFC 3704 которое определяет порядок использования RPFс одноадресными.

Хотя uRPF используется в качестве механизма фильтрации, зависит от пересылки на обратном пути. [Источник 1].

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

[Источник 2].

Примечания

Конечно же в реальной жизни не стоит использовать команду debug ip mpacket. Или использовать с большой осторожностью и когда сеть не загружена. Здесь она показана для демонстрации того, что служебные сообщения PIM также проходят проверку RPF.

Источники

  1. Reverse path forwarding - Wikipedia [2015-2017] Дата обновления: 25 марта 2017 URL: https://en.wikipedia.org/wiki/Reverse_path_forwarding (дата обращения: 04.05.2017).
  2. RPF — Xgu.ru [2013-2017] Дата обновления: 20 января 2014 URL: http://xgu.ru/wiki/RPF (дата обращения: 04.05.2017).