Выгнать трафик через физическую петлю из порта А в порт Б

[ThreeDHead]

Подключена SCE между коммутатором ядра и NAS'ами (через другой коммутатор).

[ Subscribers ] => [ SWITCH1 ] -> [ SCE ] -> [ SWITCH2 ] => [ NAS's ] -> ...

 

Возникла задача подключить NAS'ы напрямую в SWITCH1. SCE - "прозрачна", фактически это простой лупбэк.

Поэтому вопрос появился как выгнать трафик, через физическую петлю из порта А в порт Б, коммутатора SWITCH1?

SWITCH1 - D-LINK DES-7210, имеет cisco-like интерфейс.

[Alex/AT]

Да в общем 0 проблем 0 копеек. Разделите VLAN'ами - с SCE в одном VLAN (для ясности - VLAN "1") трафик уходит со свитча, возвращается на тот же свитч во VLAN "2". Далее VLAN "2" с того же свитча уходит туда, куда Вам необходимо. Единственное, что нужно понимать - если SCE прозрачна, то заполнение CAM-таблицы свитча MAC'ами, проходящими через SCE, вырастет вдвое (набор во VLAN "1", и такой же во VLAN "2").

Edited November 14, 2012 by Alex/AT

[ThreeDHead]

Alex/ATСпасибо, действительно так вполне получится. По L2 получится такая изоляция портов.

 

Но есть еще один нюанс, трафик на 80 порт, необходимо так-же "прогнать" через другой лупбэк, при этом этим-же коммутатором и принять обратно! (подключение системы кэширования).

Сейчас работает так: матчатся пакеты с локала на 80 порт интернета, PBR'ом указывается nexthop p2p адреса SWITCH2, потом пакеты возвращаются со SWITCH2 на SWITCH1 и идут обычным путем, как и не на 80 порт.

 

Так вот - как тут избавиться от SWITCH2?

Если указать обе стороны p2p в одной железяке, то я не заставлю пакеты пробежать через внешний лупбэк. Тут, возможно VRF понадобится.

[Alex/AT]

А есть возможность матчить по VLAN, порту или хопу (IP входящего интерфейса)? Если да - теоретически тоже просто: на одном свитче трафик по PBR выгоняете на кеш, а с кеша гоните в специфичном VLAN, или через специфичный хоп, или через специфичный порт, на данном хопе/порту/влане - PBR не матчите. Тут конечно попасть труднее - надо видеть специфику, но общая идея должна быть видна.

Edited November 14, 2012 by Alex/AT

[ThreeDHead]

А есть возможность матчить по VLAN, порту или хопу (IP входящего интерфейса)? Если да - теоретически тоже просто: на одном свитче трафик по PBR выгоняете на кеш, а с кеша гоните в специфичном VLAN, или через специфичный хоп, или через специфичный порт, на данном хопе/порту/влане - PBR не матчите. Тут конечно попасть труднее - надо видеть специфику, но общая идея должна быть видна.

Вопрос о том как матчить, не стоит.

Если использовать два коммутатора, то все решается элементарно - на первом p2p:1 на втором p2p:2, между ними система кеширования (или "тупо" патчкорд). Нужным нам пакетам указываем некстхопом p2p:2 и все готово - трафик полетел как надо.

 

Но если использовать _один_ коммутатор, то p2p:2 надо как-то "изолировать", иначе трафик на него пойдет не через лупбэк, а напрямую, внутри ядра коммутатора. Вот как это сделать?

 

Еще раз повторюсь, система кэширования - абсолютно прозрачна, читай лупбэк/патчкорд (никаких IP-адресов не имеет, работает только по L2).

[Alex/AT]

Собственно о чем и речь - однозначно надо видеть специфику текущей схемы: номера портов, VLAN, IP-адресацию, маршруты, имеющееся и требуемое направления следования трафика. Без специфики что-то конкретное предложить трудно.

[ThreeDHead]

Собственно о чем и речь - однозначно надо видеть специфику текущей схемы: номера портов, VLAN, IP-адресацию, маршруты, имеющееся и требуемое направления следования трафика. Без специфики что-то конкретное предложить трудно.

Вот работающая схема:

[ Subscribers ] => [ SWITCH1, VLAN111 native, 10.0.0.1/30 ] -> [ Patchcord ] -> [ SWITCH2, VLAN111 native, 10.0.0.2/30 ]

На SWITCH1 матчим нужные пакеты и им nexthop 10.0.0.2 - всё, пакеты пройдут через "Patchcord".

 

Вот схема с одним коммутатором:

[ Subscribers ] => [ SWITCH1, VLAN111 native, 10.0.0.1/30 ] -> [ Patchcord ] -> [ SWITCH1, VLAN222 native, 10.0.0.2/30 ]

На SWITCH1 матчим нужные пакеты и им nexthop 10.0.0.2 - пакеты пойдут напрямую на "10.0.0.2".

Для того чтобы пакет прошел через "Patchcord", я думаю что 10.0.0.2 надо вынести в VRF, а в VRF указать def gw на SWITCH1. Просто я VRF еще не совсем освоил, не пойму с какой стороны к нему подойти.

[Alex/AT]

вообще тема интересная, как уже говорил - можно поглядеть. но нужна бы полная схема _текущего_ включения - с конкретными устройствами, номерами портов, VLAN, IP-адресацией (подсети можно замазать, "пронумеровав" как A, B, C, ..., но хостовые адреса - обязательны), правилами PBR и таблицей роутинга, текущей схемой работы, и желаемой схемой работы. в принципе, думается, ничего сложного - но надо видеть картину полностью

Edited November 19, 2012 by Alex/AT

[ThreeDHead]

вообще тема интересная, как уже говорил - можно поглядеть. но нужна бы полная схема _текущего_ включения - с конкретными устройствами, номерами портов, VLAN, IP-адресацией (подсети можно замазать, "пронумеровав" как A, B, C, ..., но хостовые адреса - обязательны), правилами PBR и таблицей роутинга, текущей схемой работы, и желаемой схемой работы. в принципе, думается, ничего сложного - но надо видеть картину полностью

Для теоритического решения я дал достаточно информации. К сожалению, больше добавить нечего.

Буду изучать как работает VRF.

[Alex/AT]

А зачем там VRF?

Не совсем понятно, зачем понадобилось перетаскивать 10.0.0.2 на первый свитч. Какая вообще необходимость пакеты на второй свитч забрасывать, что там?

Или между 10.0.0.1 и 10.0.0.2 - прозрачная по L2 железка?

 

Upd.

 

А, вижу, там SCE... Туда забрасываются определенные пакеты, сматченные в 111 VLAN, правильно? Или через SCE проходит весь трафик до NAS'ов?

 

Если весь - всё просто. Никаких IP-интерфейсов. Всё, что в 111 - выгоняем в порт SCE. С SCE загоняем в 222, в который подключены NAS. Собственно, и всё.

Edited November 19, 2012 by Alex/AT

[ThreeDHead]

А зачем там VRF?

Не совсем понятно, зачем понадобилось перетаскивать 10.0.0.2 на первый свитч. Какая вообще необходимость пакеты на второй свитч забрасывать, что там?

Или между 10.0.0.1 и 10.0.0.2 - прозрачная по L2 железка?

 

Upd.

 

А, вижу, там SCE... Туда забрасываются определенные пакеты, сматченные в 111 VLAN, правильно? Или через SCE проходит весь трафик до NAS'ов?

 

Если весь - всё просто. Никаких IP-интерфейсов. Всё, что в 111 - выгоняем в порт SCE. С SCE загоняем в 222, в который подключены NAS. Собственно, и всё.

1) Между 10.0.0.1 и 10.0.0.2 - прозрачная по L2 железка;

2) Через этот лупбэк прогонять надо некоторые пакеты, для простоты - все, которые мы отматчим и развернем туда PBR-ом;

3) Принимающая сторона - это тот-же коммутатор с которого и отправили! Поэтому неизвестно что указывать в проутмапе в параметре NEXTHOP! А что-то указать надо, иначе туда пакет не полетит. Но и указывать айпи из основной таблицы маршрутизации - нельзя, т.е. это не даст желаемого результата. Выход один - вынести второй P2P "куда-то". Первое решение - на другой свитч, второе - в VRF...

[Alex/AT]

Тогда хитрее. Указывайте nexthop'ом NAS, если есть такая возможность. Получается так:

 

[traffic] -> [VLAN111] -> [switch] -> [special NAS nexthop in VLAN222] -> [VLAN222] -> [loopback] -> [VLAN333] -> [switch] -> [NAS in VLAN333]

 

То есть подсетка NAS'ов сидит во VLAN222 на свитче, соответственно некстхопы у вас - NAS'ы, только отдельные адреса, специально для 222. Трафик на NAS'ы выбежит в VLAN222, завернется, и войдёт в VLAN333, где реально и сидят NAS'ы. А то, что не надо гнать через VLAN222 - заворачивайте на нормальные некстхопы NAS'ов, которые априори в VLAN333.

Edited November 19, 2012 by Alex/AT

[ThreeDHead]

Мне нужно "упростить жизнь" NAS'ам и "усложнить" коммутатору ядра. Т.е. у NAS'ов должен быть всего один вилан и один айпи в сторону ядра.

Поэтому надо ситуацию разруливать на L3.