Обратился клиент с жалобой на то, что суммарный OSPFv2 маршрут (LSA Type 3) не анонсировался между непосредственно подключенным соседями: от роутера A к роутеру B. Особенностью этой топологии было то, что на роутере B был прописан vpn-instance (VRF).
Роутер A принадлежал backbone арии 0 и был ABR роутером. Роутер B принадлежал non-backbone арии. Правило OSPF, при котором все non-backbone арии должны быть непосредственно смежными с backbone арией, так как LSA Type 3, полученные из backbone арии, создаются только для non-backbone арий, соблюдалось.
Чтобы понять почему маршрут не анонсировался, нужно вспомнить два двугих правила:
1.LSA Type 3, полученные из non-backbone арии, помещаются в LSDВ только для арии источника. ABR не создают LSA Type 3 для других арии (включая сегментированную арию 0 - сценарий несмежной сети или discontiguous network).
2.OSPF vpn-instance процесс «видит» себя как ABR.
Строго говоря, маршрут анонсировался от одного соседа к другому, так как он присутствовал в LSDB роутера B, но он не анонсировался в таблицу маршрутизации роутера B. Суммарный LSA Type 3, созданный в арии 0, попадал в LSDB арии 7, но не мог быть помещен/создан в vpn-instance, поскольку OSPF роутера B считал его другой арией. Иными словами, роутер B стал ABR роутером в силу правила 2, и не создавал суммарный маршрут в силу правила 1.
Решения:
Команда vpn-capability-simple “отменяет” правило 2.
Сделать арию 7 транзитной арией (vlink-peer <ip peer>).
Проверить то, что OSPF vpn-instance процесс, действительно, «видит» себя как ABR, можно командой display ospf <process> brief. Смотреть значение Border Router.
Такое поведение не является особенностью реализации Huawei. Тест Cisco IOS в GNS3 показал то же самое поведение.