Можно ли использовать мост VLAN для замены байпасного переключателя устройством IPS?

Мне интересно, можно ли установить способ удаления необходимости обходного переключателя при использовании устройства IPS. Подводя итог, у меня будет устройство IPS, действующее как виртуальный провод в соединении, которое я контролирую. У меня также есть байпасный переключатель, чтобы сделать это, чтобы при сбое IPS сетевое соединение обходит устройство IPS и поддерживает соединение (я знаю о проблемах безопасности при сбое в открытии).

В мосте VLAN я имею в виду 2 порта доступа в 2 разных виртуальных портах, которые физически подключены. Итак, я думал, что устройство IPS действует как физический провод между двумя портами доступа. Кроме того, если бы у меня был еще один цикл между двумя разными портами доступа с более высокой стоимостью STP, я должен был бы эффективно обходить (если IPS опустится, STP позаботится об обходе, переключившись на другой цикл). Идея вообще работает, когда мои петли находятся между двумя разными переключателями.

Однако у меня были некоторые проблемы с тем, чтобы это работало на одном коммутаторе. Я тестировал это с помощью двух компьютеров в двух разных vlans, пинговавших друг друга. Так что, возможно, у меня просто проблемы с ARP, и это сработает, если я смогу обойти это, но пока не уверен.

Это слишком сумасшедшая идея, чтобы когда-либо работать, или я просто что-то упустил?

3 голоса | спросил Paul Kroon 30 Maypm13 2013, 17:14:24

4 ответа


1

Я не считаю, что это возможно на одном коммутаторе. Причина в том, что вы полагаетесь на STP, чтобы поймать сбой связи, но чтобы вернуться к одному коммутатору, вам придется приостановить нормальную операцию STP с помощью фильтрации BPDU или чего-то подобного.

ответил Odeonevets 30 Maypm13 2013, 20:20:16
2

Есть ли необходимость в двух различных VLAN? В зависимости от варианта STP, который вы используете, это может на самом деле усложнить ситуацию.

Другое дело, что вы предлагаете, это то, что вы не можете гарантировать, что отказ IPS приведет к потере обоих интерфейсов. Если, например, сбой программного обеспечения, но интерфейсы остаются включенными, spanning-tree может не правильно сходиться.

Настоящий тест будет - ваш IPS будет поглощать BPDU или передавать их прозрачно

ответил Benjamin Dale 30 Maypm13 2013, 17:52:30
1

Это, вероятно, будет работать, но я бы не использовал такое решение для обхода продукции. Правильно это сделать (даже если это не самая лучшая практика) - это иметь обход встроенного устройства IPS. Это означает, что если устройство выходит из строя, он будет действовать как кабель, даже если его нет.

Конечно, вы хотите, чтобы какой-то мониторинг на вашем устройстве обнаруживал сбои и отвечал соответственно.

Надеюсь, что это поможет.

ответил sergejv 30 Maypm13 2013, 17:22:42
0

Если IPS полностью прозрачна (ретрансляция BPDU, не выполняющая каких-либо сопоставлений VLAN сама по себе), вы можете использовать отображение /перевод VLAN.

В принципе, вы определяете две VLAN, внешние и внутренние. Внешний коммутатор имеет внешнюю VLAN (возможно, порт внешней линии), внутренний коммутатор внутренней VLAN. Во внутреннем коммутаторе вы настраиваете отображение /перевод VLAN. c6500s позаботится о переводе информации BPDU, поэтому вы не получите никаких ошибок несоответствия.

Это даже работает с избыточными коммутаторами /IPSes, вторая установка блокирует свой внутренний блок.

Я сделал это с 6500 Sup720 и 67xx линейными картами (которые имеют ограничение на применение сопоставления VLAN для ASIC порта), не могу сказать, работает ли это с другой передачей.

Другим недостатком является то, что вам приходится иметь дело с различными идентификаторами VLAN для внешних (восходящих) и внутренних (нисходящих) устройств, что может повлиять на планирование и устранение неполадок.

ответил mmi 30 Maypm13 2013, 20:53:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132