Comments 8
спасибо за статью
но мне не понятно, зачем для работы vrf cef?
(или это фигура речи такая?)
я понимаю что cef нужен для sla,track но не для vrf
если я не прав, поясните пожалуйста
Попробую объяснить так:
no ip cef

R1(config-if)#ip vrf forwarding test
% Enable CEF globally before configuring VRF on any interface
Для полноценных VRF (с использованием BGP и MPLS) CEF нужен, потому что MPLS циска (насколько мне известно) умеет только через CEF. Насчет VRF-lite не уверен.
Тут вопрос в другом: зачем вообще VRF в этом случае? На мой взгляд, получается наркоманско-шизофренический конфиг, который никто кроме автора поддерживать не сможет. Хотя job-security, да, хороший.
Единственное, что этот конфиг дает — разграничение доступа, но в лоб, с использованием ACL, получится проще и понятнее.
Насчет «кроме автора никто не сможет поддерживать» не согласен. Я основывался на статье автора которую указал. Я разобрался — ничего сложного. По поводу ACL — вы правы, но статья не о том, и то что в данном случае, в определенных ситуациях ACL не нужен это скорее фича.
Как раз для IP SLA технология CEF не нужна. Пакеты генерирует само устройство (используется process switching).

А вот VRF в качестве пререквизита требует CEF. Изначально VRF появился для работы MPLS VPN. При этом MPLS опирается на логику CEF и обязательно требует его включения. VRF обеспечивает изоляцию за счёт разных таблиц RIB и FIB для каждого инстанса.
Если кто-то знает как очищать таблицу трансляций частично — буду благодарен.

Можно поробовать так: clear ip nat translation vrf isp1 *

Из-за этого, уже установленные пользовательские соединения зависнут до того момента пока трансляции NAT не очистится по тайм-ауту.

Я бы не согласился с этим утверждением. Действительно, соединения подвисают, так как пакеты в рамках открытой сессии используют текущие записи NAT, которые ссылаются на адреса отказавшего провайдера. Но таймаут NAT для TCP равен 24 часа. Ждать его окончания было бы слишком долго.

Обычно клиентская сторона намного раньше разрывает соединение. Например, может использоваться механизм TCP Keep-alive. Или пользователь самостоятельно инициирует установку нового соединения (например, принудительно обновив страницу в браузере).

Магия «clear ip nat translation» заключается в том, что как только вы вводите эту команду, маршрутизатор отправляет пакет с флагом RST для всех TCP сессий. Из-за чего внутренние ПК завершают текущую сессию и при необходимости открывают новую. А новая уже прекрасно работает, так как создаются новые NAT записи, использующие адреса второго провайдера.
В голове не укладывается, зачем в дизайне SMB нужна такая сложная конфигурация…
Only those users with full accounts are able to leave comments. Log in, please.