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

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

И так, какую же странность я заметил.

Пусть у нас есть вот такая сеть в 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. Если у вас есть какие либо соображения по данному поводу, буду рад их выслушать.