метка маршрута службы Cisco SD-WAN
-
Здравствуйте, У меня есть сомнения относительно того, как маршрутизатор WAN Edge, к которому напрямую подключена сетевая служба, пересылает пакеты, имеющие метку службы, указывающую на такую службу. Рассмотрим следующий сценарий, взятый из отличного поста о маршрутах служб в CLN (
Cisco SD-WAN Service Chaining)
![:disappointed_face:] ![JUANNN_0-1757124862631.png] Когда маршрутизатор CHI начинает отправлять пакеты на маршрутизатор BOS, после того как сетевая служба (FW) была введена и таблица маршрутизации OMP на контроллере SD-WAN диктует, что следующим прыжком TLOC для префиксов VPN 100 является маршрутизатор NNJ TLOC (а маршрутизаторы WAN Edge отражают обновления на своей плоскости данных), метка MPLS (метка службы) вставляется как обычно (но в этом случае она помогает NNJ определить, что для этих пакетов не следует выполнять поиск IP, поскольку они должны быть перенаправлены на брандмауэр, и по возвращении с брандмауэра будет выполнен поиск IP, поскольку метка службы указывает на сетевую службу, а не на службу VPN). Я предполагаю, что маршрутизатор NNJ пересылает трафик, используя MAC-адрес FW, как только пакеты от CHI поступают с установленной меткой службы FW, но
будет ли возможно разместить сетевую службу в подсети, не подключенной напрямую к маршрутизатору NNJ
? Я не вижу причин, по которым это было бы невозможно, но в
OMP Overview | NetworkAcademy.io
говорится, что между сетевой службой и маршрутизатором WAN Edge не должно быть устройств L3. Спасибо, пожалуйста, поправьте меня, если я что-то не так понял. Хуан

-
Здравствуйте, брандмауэр должен находиться на уровне L2 (непосредственно или через туннель), поскольку брандмауэр и промежуточное устройство L3 не понимают, что маршрутизатор выполняет «вставку брандмауэра». Как маршрутизатор может перенаправлять трафик на брандмауэр, если между маршрутизатором и брандмауэром находится другое устройство L3? Можно использовать только туннелирование. Туннелирование должно поддерживаться в Cisco SD-WAN. HTH,
Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной. -
Я не могу говорить о конкретных технических ограничениях, которые создают требование к соседству L2, но при необходимости вы можете использовать туннель GRE для достижения соседства L2 между границей WAN и устройством службы брандмауэра, если оно находится в другой подсети. Рад помочь! Пожалуйста, отметьте как полезное/решение, если применимо.
Свяжитесь с нами: https://torbjorn.dev -
Спасибо, вы правы. Пакеты переключаются с маршрутизатора Wan Edge на FW, когда у них есть метка, указывающая на службу, и из-за этого не нужно выполнять поиск IP-адреса на пути к FW, поскольку IP-заголовок указывает на исходный пункт назначения, а не на FW. Как только пакет достигает FW, именно FW выполняет поиск IP-адреса и отправляет пакет к исходному месту назначения через шлюз по умолчанию FW, которым снова будет маршрутизатор Wan Edge, но на этот раз без метки службы, поэтому поиск IP-адреса выполняется на маршрутизаторе Wan Edge, и все работает нормально.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти