воскресенье, августа 28, 2016

Специфика работы протокола RIP в Cisco Packet Tracer


Всем привет! Сегодня мне бы хотелось рассказать Вам о некоторых расхождения в реализации работы протокола RIP в GNS3 и Cisco Packet Tracer. Именно из за этих расхождений у меня возникли проблемы при написании предыдущей статьи о работе таймера Holddown протокола RIP. В принципе, в этом нет ничего странного, ведь Packet Tracer это всего лишь эмулятор, а GNS3 использует реальные IOS и является полноценным симулятором.
И так, какую же странность я заметил.

Пусть у нас есть вот такая сеть в GNS3:
Тестовая сеть в GNS3
Тестовая сеть в GNS3
Конфиги устройств следующие:

Маршрутизатор 1:

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
router rip
 version 2
 network 192.168.1.0

Маршрутизатор 2:

interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
interface FastEthernet0/1
 ip address 192.168.2.1 255.255.255.0
router rip
 version 2
 network 192.168.1.0
 network 192.168.2.0

Маршрутизатор 3:

interface FastEthernet0/0
 ip address 192.168.2.2 255.255.255.0
router rip
 version 2
 network 192.168.2.0

Что мы делаем далее. Запускаем дебаг debug ip rip на маршрутизаторах 1 и 2. Далее гасим интерфейс FastEthernet0/1 на маршрутизаторе 2. Смотрим что мы имеем в дебагах через 1-2 секунды, после отключения интерфейса:

Маршрутизатор 2:
*Mar  1 00:11:14.595: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (192.168.1.2)
*Mar  1 00:11:14.595: RIP: build flash update entries
*Mar  1 00:11:14.595:   192.168.2.0/24 via 0.0.0.0, metric 16, tag 0

Маршрутизатор 1:
*Mar  1 00:12:15.935: RIP: received v2 update from 192.168.1.2 on FastEthernet0/0
*Mar  1 00:12:15.935:      192.168.2.0/24 via 0.0.0.0 in 16 hops  (inaccessible)

При получении данного обновления маршрутизатор 1 сразу же удаляет маршрут к сети 192.168.2.0 из своей таблицы маршрутизации, не запуская таймеры invalid, flushe и т.д.:

Маршрутизатор 1:
Gateway of last resort is not set
C    192.168.1.0/24 is directly connected, FastEthernet0/0

Если же мы поднимем интерфейс FastEthernet0/1 на маршрутизаторе 2. То увидим вот такую картину в дебагах:

Маршрутизатор 2:
*Mar  1 00:19:12.655: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (192.168.1.2)
*Mar  1 00:19:12.655: RIP: build flash update entries
*Mar  1 00:19:12.655:   192.168.2.0/24 via 0.0.0.0, metric 1, tag 0

Маршрутизатор 1:
*Mar  1 00:20:13.971: RIP: received v2 update from 192.168.1.2 on FastEthernet0/0
*Mar  1 00:20:13.971:      192.168.2.0/24 via 0.0.0.0 in 1 hops

Какой мы отсюда делаем вывод. Маршрутизаторы, основываясь на изменении состояния своих интерфейсов, способны, сразу же после изменения состояния интерфейса, рассылать flash update (Triggered update) ,  другим маршрутизаторам, указывая на изменения произошедшие в маршрутной информации. Маршрутизаторы получившие данные обновления сразу же вносят изменения в свои таблицы маршрутизации, не запуская в работу таймер flushe протокола RIP. Этот принцип работы является верным.







Теперь, давайте посмотрим, что мы имеем в Cisco Packet Tracer.Собираем туже самую сеть:

Конфигурации маршрутизаторов аналогичные. Запускаем аналогичные дебаги на маршрутизаторах 1 и 0, гасим интерфейс FastEthernet0/1 на маршрутизаторе 1 и что мы видим? Да ничего, собственно не видим, пока не отработает таймер update. flash update отсутствуют. Маршрут к сети 192.168.2.0 присутствует в таблице маршрутизатора 0. И он пропадет из нее только тогда отработают таймеры invalid и flushe. 

Вот такие у меня наблюдения о работе протокола RIP в GNS3 и Cisco Packet Tracer. Если у вас есть какие либо соображения по данному поводу, буду рад их выслушать.





0 коммент.:

Отправить комментарий