Протокол IP : Протоколы IP-маршрутизации

Использование статический маршрута для интерфейса Null0 с целью предотвращения зацикливания

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Интерфейс NULL, как правило, используется для предотвращения кольцевых маршрутов. Например, расширенный протокол маршрутизации внутреннего шлюза (EIGRP) при суммировании группы маршрутов всегда создает маршрут на интерфейс Null0. Каждое суммирование маршрутов протоколом маршрутизации означает, что маршрутизатор получает возможность принимать трафик для любого IP-адреса из этой суммарной выборки. Поскольку не все IP-адреса всегда находятся в использовании, существует риск зацикливания пакетов в случае использования маршрутов по умолчанию на маршрутизаторе, который получает трафик для суммарной выборки.

Предварительные условия

Требования

Для данного документа отсутствуют предварительные условия.

Используемые компоненты

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

  • Cisco выпуск ПО IOS� 12.3.

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

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Синтаксис команды

Статический маршрут к Null0 является обычным статическим маршрутом, за исключением того, что это указывает к интерфейсу Null0, который является действительным интерфейсом IOS. См. Команды Протоколов IP-маршрутизации: Я разделяю Справочника по командам IP Cisco IOS, Громкость 2 из 4: Протоколы маршрутизации, релиз 12.3 для получения дополнительной информации о команде ip route. Следующий раздел представляет пример того, как использовать команду ip route для создания статического маршрута к Null0.

Пример

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

Рассмотрим следующий пример:

/image/gif/paws/14956/route_to_null_interface_01.gif

Небольшой интернет-провайдер (ISP-R1) дает одному из его клиентов сетевой блок 192.168.0.0/16. В данном примере клиент разделил 192.168.0.0/16 на/24 сети и только использует 192.168.1.0/24 и 192.168.2.0/24 в данный момент. На маршрутизаторе ISP-R1 интернет-провайдер настраивает статический маршрут для 192.168.0.0/16 к маршрутизатору клиента (cust-R2). Интернет-провайдер тогда соединяется с магистральным интернет-провайдером, представленным R3 BB маршрутизатора. R3 BB маршрутизатора передает маршрут по умолчанию к ISP-R1 и получает сеть 192.168.0.0/16 через BGP от ISP-R1.

Достижимость теперь гарантируется из Интернета (магистральный R3 BB маршрутизатора ISP) к cust-R2 маршрутизатора клиента, потому что cust-R2 настроили маршрут по умолчанию для обращения к ISP-R1. Однако, если пакеты предназначены к сетевым блокам, которые не используются из диапазона 192.168.0.0/16, тогда маршрутизатор cust-R2 использует маршрут по умолчанию для ISP-R1 для передачи тех пакетов. Пакеты тогда петля между ISP-R1 и cust-R2 до TTL истекают. Это может оказать огромное влияние на процессор маршрутизатора и использование соединения. Примером того, куда этот трафик к неиспользованным IP-адресам мог бы прибыть из, могли быть атаки "отказ в обслуживании", сканирование IP - блоков для обнаружения уязвимых узлов, и т.д.

Соответствующие конфигурации:

cust-R2
version 12.3
!
hostname cust-R2
!
ip subnet-zero
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!         
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.2.1 255.255.255.0
!
interface Serial2/0
 ip address 10.0.0.2 255.255.255.252

!--- This interface leads to ISP-R1.

!
ip classless
ip route 0.0.0.0 0.0.0.0 10.0.0.1

!--- Default route going to ISP-R1.

!
end

ISP-R1
version 12.3
!
hostname ISP-R1
!
ip subnet-zero
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252

!--- Interface to cust-R2.

!
interface Serial1/0
 ip unnumbered Loopback0

!--- Interface going to BB-R3.

!
router bgp 65501
 no synchronization
 network 192.168.0.0 mask 255.255.0.0

!--- ISP-R1 injects 192.168.0.0/16 into BGP to 
!--- advertise it to BB-R3.

 neighbor 10.3.3.3 remote-as 65503
 neighbor 10.3.3.3 ebgp-multihop 255
 no auto-summary
!
ip classless
ip route 10.3.3.3 255.255.255.255 Serial1/0
ip route 192.168.0.0 255.255.0.0 Serial0/0

!--- The first route is necessary for the eBGP 
!--- session to BB-R3 to come up.


!--- The route to 192.168.0.0/16 points towards cust-R2.

!
!
end

R3 BB
version 12.3
!
hostname BB-R3
!
ip subnet-zero
!
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.255
!
interface Serial2/0
 ip unnumbered Loopback0

!--- This interface goes to ISP-R1.

!
router bgp 65503
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 ebgp-multihop 255
 neighbor 10.1.1.1 default-originate 

!--- BB-R3 injects a default route into BGP and 
!--- sends it to ISP-R1.

 no auto-summary
!
ip classless
ip route 10.1.1.1 255.255.255.255 Serial2/0

!--- This route points to ISP-R1 and is 
!--- used to establish the eBGP peering.

!
end

Движение пакетов:

Примечание: Мы позволили некоторым командам отладки на маршрутизаторах лучше проиллюстрировать поток пакетов, особенно debug ip packet и debug ip icmp. Не выполняйте эти команды в производственной среде, пока вы полностью не понимаете последствий.

BB-R3# ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

*Oct  6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed via FIB
*Oct  6 09:36:45.355: IP: s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), len 100, sending.
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1

R3 BB передает одиночный запрос ICMP к IP-адресу в блоке 192.168.0.0/16, который не используется на cust-R2. R3 BB получает время ICMP, превышенное назад от ISP-R1.

На ISP-R1:

18:50:22: IP: tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB

Начальный пакет получен на serial1/0 от R3 BB и передан к cust-R2 от serial0/0 как ожидалось. Тот же пакет возвращается в ISP-R1 на serial0/0 и сразу отослан тот же интерфейс, к cust-R2, из-за этого маршрута:

ISP-R1# show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65501
  Routing Descriptor Blocks:
  * directly connected, via Serial0/0
      Route metric is 0, traffic share count is 1

Что происходит на cust-R2, который заставляет его передавать этот трафик обратно в ISP-R1?

На cust-R2:

*Oct  6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB
*Oct  6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB

Мы видим, что cust-R2 передает эти пакеты обратно в ISP-R1 из-за этого маршрута:

cust-R2# show ip route 192.168.20.1 longer-prefixes 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.0.0.1 to network 0.0.0.0

cust-R2#

Маршрутизатор cust-R2 не имеет маршрута к 192.168.20.1, потому что эта сеть не используется в сети заказчика, таким образом, лучший маршрут к 192.168.20.1 является маршрутом по умолчанию, который указывает к ISP-R1.

Результат состоит в том, что истекает пакетная петля между ISP-R1 и cust-R2 до TTL.

Обратите внимание на то, что, если запрос ICMP перешел к IP-адресу в сети, которая используется, этот результат не произошел бы. Например, если запрос ICMP был для 192.168.1.x, который напрямую подключается на cust-R2, никакое цикличное выполнение не произошло бы:

cust-R2# show ip rou 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1

Решение этой проблемы состоит в том, чтобы настроить статический маршрут к Null0 для 192.168.0.0/16 на cust-R2.

cust-R2# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
cust-R2(config)# ip route 192.168.0.0 255.255.0.0 Null0
cust-R2(config)# end
cust-R2#
*Oct  6 09:53:18.015: %SYS-5-CONFIG_I: Configured from console by console
cust-R2# show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

Если мы теперь повторно передаем запрос ICMP от R3 BB до 192.168.20.1, cust-R2 передает этот трафик к Null0, который инициирует сообщение о недоступности ICMP, которое будет генерироваться.

BB-R3# p ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
U
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2

Примечание: Могут быть ситуации, где использование итогового статического маршрута к Null0 не выполнимо. Например, если в предыдущем примере:

  • Блок 192.168.1.0/24 связан с другим маршрутизатором, который набирает в cust-R2 через ISDN

  • ISP-R1 не выделяет 192.168.0.0/16, но только 192.168.1.0/24

  • Разъединение соединения ISDN происходит

Примечание: Результат состоял бы в том, что пакеты в пути или приложения, которые пытаются достигнуть этого блока IP-адресов, создают тот же цикл маршрутизации, описанный ранее.

Примечание: Для решения проблемы этого цикла маршрутизации необходимо использовать команду ip route 192.168.1.0 255.255.255.0 Null0 200 для настройки плавающего статического маршрута к Null0 для 192.168.1.0/24. 200 в команде являются административным расстоянием. См. Какой Административное расстояние? дополнительные сведения.

Примечание: Поскольку мы используем более высокое административное расстояние, чем какой-либо протокол маршрутизации, если маршрут к 192.168.1.0/24 через соединение ISDN становится неактивным, cust-R2 устанавливает плавающий статический маршрут. Пакеты тогда переданы к Null0, пока соединение ISDN не становится активным.


Дополнительные сведения


Document ID: 14956