Сюрпризы с маршрутизацией и VRF на Cisco 7201

[alibek]

Сегодня случился сюрприз, который я вообще не понял.

 

Есть Cisco 7201.

На ней есть такая конфигурация:

int gi0/0
ip address aa.bb.cc.242 255.255.255.248
int gi0/1
no ip address
int gi0/1.xxx
encapsulation dot1Q xxx
ip address xx.xx.xx.xx 255.255.255.252
...
ip route 0.0.0.0 0.0.0.0 aa.bb.cc.241

Дает интернет клиентам, подключенным по выделенной линии (ЮЛ), все прописано статикой.

Работает без каких-либо проблем.

 

На нее также заведено IPTV, примерно так:

int gi0/2
ip address 10.1.127.254 255.255.255.0
ip pim sparse-mode
ip igmp query-interval 125
int gi0/3
no ip address
int gi0/3.100
encapsulation dot1Q 100
ip address nn.nn.nn.92 255.255.255.192
int gi0/3.101
encapsulation dot1Q 101
ip address nn.nn.nn.129 255.255.255.252
ip pim sparse-mode
ip multicast boundary IPTV-NTV filter-autorp
router bgp AAAAA
neighbor nn.nn.nn.65 remote-as NNNNN
neighbor nn.nn.nn.130 remote-as NNNNN
address-family ipv4
 neighbor nn.nn.nn.65 activate
 neighbor nn.nn.nn.130 activate
address-family ipv4 multicast
 neighbor nn.nn.nn.130 activate
ip route nn.nn.nn.173 255.255.255.255 Null0 254
ip pim rp-address nn.nn.nn.173 IPTV-NTV override

В gi0/3 стык с контент-провайдером, в gi0/2 подключен igmp querier на ядре.

По gi0/3.100 получаю маршруты на Middleware (3-4 префикса), по gi0/3.101 получаю мультикаст и мультикаст-маршруты.

Так тоже все работает.

 

Теперь появилась необходимость добавить в gi0/3 еще одного контент-провайдера.

Схема похожая, только к mBGP+PIM добавляется еще MSDP.

По этой схеме соединение с пиром устанавливается, мультикаст-маршруты принимаю, RP вижу, но трафик не ходит.

Второй контент-провайдер заподозрил, что где-то случается пересечение по маршрутам или подсетям, предложил загнать линк в VRF.

Создали VRF, перенесли в него линки и маршруты, мультикаст пошел через стык, IPTV второго поставщика заработало.

 

И тут внезапно оказалось, что все сервисы на gi0/1 перестали работать, т.е. отключился интернет у ЮЛ.

Если точнее, то связность клиентов сохранилась, но почему-то пропала связь с aa.bb.cc.241 (аплинк на gi0/0).

Хотя казалось бы, VRF никак не должен влиять на глобальную таблицу маршрутизации.

 

Смотрел маршруты, логи, причину пропадания аплинка не понял.

Время поджимало, поэтому удалил VRF, отменил все настройки, с ним связанные, отключил интерфейсы gi0/2 и gi0/3, очистил таблицу маршрутов, arp-таблицу. Вообщем, чего я только не делал, но связи с аплинком не появлялось.

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

А из-за чего не работало до перезагрузки?

[mikezzzz]

а с маршрутом ip route 0.0.0.0 0.0.0.0 aa.bb.cc.241 во время аварии пробовали играться? удалить/добавить?

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

[alibek]

Маршрут удалять не пробовал, пробовал выключить/включить L3-интерфейс.

Это не рекурсивный маршрут (шлюз aa.bb.cc.241 в одном сегменте с интерфейсом gi0/0 aa.bb.cc.242), а direct connected.

И несмотря на это, aa.bb.cc.241 не пинговался.

[mikezzzz]

Это не рекурсивный маршрут (шлюз aa.bb.cc.241 в одном сегменте с интерфейсом gi0/0 aa.bb.cc.242), а direct connected.

show ip cef 0.0.0.0 0.0.0.0 detail

 

по факту, больше не знаю что предположить, "романтический момент" утерян

[alibek]

Вывод CEF я делал, вроде бы скопировал в буфер обмена, но спешил и не проверил. А оказалось, что не скопировал.

Но насколько помню, криминала там не было. Да и ведь у меня не было рекурсивных маршрутов, чтобы в CEF что-то сломалось.

[vurd]

А какой смысл искать причину бага, если это был именно баг?

На первый пост я бы ответил "у вас не работало до перезагрузки из-за vrf, который вы создали".

Повторите эксперимент, только в 5 утра или перекинув клиентов на другой шлюз. 99% просто словили багу.

[alibek]

Ладно если это баг.

А если ошибка в конфигурации?

На этой неделе буду снова IPTV настраивать, не хотелось бы снова ЮЛ без интернета оставить.