Насколько я понял из tools.ietf.org/html/draft-davie-stt-01, STT работает поверх IP, а не TCP, и у него свой (отдаленно похожий на TCP) заголовок. Так прохождение через файрволы и тем более NATилки несколько сомнительно :) Ну это я так, придираюсь…
С другой стороны, при использовании подобного туннелирования нет смысла пропускать его трафик через файрволы и тем более NAT.
И все-таки возможность фактически свести к нулю L2 сегменты на физической сети ЦОДа не может не радовать :)
Нет, это — инженеры департамента информационной безопасности, они абсолютно изолированы от сетевиков (иерархии руководства пересекаются где-то на уровне членов правления) :) Ну а физические безопасники (решетки на окнах, СКУДы и так далее) к ним вообще никаким боком.
Скорее — смотря какие безопасники. Даже с сетевыми безопасниками уровня CCIE Sec, сетевики могут считать их некомпетентными болванами, ничего не смыслящими в роутинге.
Вы не участвовали во внедрении того же NAC в нашей конторе для доменных машин. Да, факт перекидывания между VLANами вызывал колоссальные проблемы. И да, эти проблемы по определению исключены в случае ISE.
Хотя в случае изменения VLANа сразу после поднятия физики последствия будут менее неприятными.
И на самом деле L3 в случае L3 коммутатора будет даже малость попроще, чем L2. И хрен с ним, что надо глубже в пакет лазить.
Для связанных с роутингом багов? С какой стати? Вот за багами, представляющие собой вектора целенаправленной атаки на протоколы маршрутизации они действительно должны следить.
А кто-то уже отменил защиту от спуфинга? Ну там uRPF, IP source guard и т.д.? Боюсь, у злоумышленника пупок развяжется спуфить адрес даже при общении в пределах VLANа.
Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.
А к апгрейду стоит подходить с умом. Читать рассылки bug toolkit'а и release notes. Смотреть, какие есть опасные для данной железки с данной конфигурацией баги. Может обнаружиться баг уровня catastrophic, на который железка может напороться в любой момент.
Далеко ходить не надо. У меня пограничные BGP маршрутизаторы имеют (имели до недавнего времени) аптайм года 3. И вдруг при аварии на одном из каналов я заметил, что видимость интернета у нас далеко не полная, часть префиксов, полученных через резервные каналы, не попадала в таблицу BGP и виделась лишь в received-routes из-за soft-reconfiguration (даже при радикально более коротком AS-PATH и прочими равными). Поклирил нейбора — увиделись все, проблема ушла. Я открыл ради интереса список багов и выпал в осадок от того, какие связанные с BGP баги имели место быть в той версии. Там было штуки четыре severity 1, а менее опасных куда больше.
Причем тут мониторинг?
Разумеется, есть целый отдел, занятый исключительно мониторингом и способный осуществлять самую базовую диагностику (потому СМС отсутствует — будет звонок). И естественно, имеется детальная информация о сети по данным с интерфейсов, с netflow, с сенсоров и т.д. Это все само собой разумеется.
С другой стороны, при использовании подобного туннелирования нет смысла пропускать его трафик через файрволы и тем более NAT.
И все-таки возможность фактически свести к нулю L2 сегменты на физической сети ЦОДа не может не радовать :)
А вот это уже реально здорово.
Какую из техник туннелирования задействуете? Насколько я помню, там полно вариантов — от mac-in-mac до GRE или VXLAN.
Хотя в случае изменения VLANа сразу после поднятия физики последствия будут менее неприятными.
И на самом деле L3 в случае L3 коммутатора будет даже малость попроще, чем L2. И хрен с ним, что надо глубже в пакет лазить.
А к апгрейду стоит подходить с умом. Читать рассылки bug toolkit'а и release notes. Смотреть, какие есть опасные для данной железки с данной конфигурацией баги. Может обнаружиться баг уровня catastrophic, на который железка может напороться в любой момент.
Далеко ходить не надо. У меня пограничные BGP маршрутизаторы имеют (имели до недавнего времени) аптайм года 3. И вдруг при аварии на одном из каналов я заметил, что видимость интернета у нас далеко не полная, часть префиксов, полученных через резервные каналы, не попадала в таблицу BGP и виделась лишь в received-routes из-за soft-reconfiguration (даже при радикально более коротком AS-PATH и прочими равными). Поклирил нейбора — увиделись все, проблема ушла. Я открыл ради интереса список багов и выпал в осадок от того, какие связанные с BGP баги имели место быть в той версии. Там было штуки четыре severity 1, а менее опасных куда больше.
Разумеется, есть целый отдел, занятый исключительно мониторингом и способный осуществлять самую базовую диагностику (потому СМС отсутствует — будет звонок). И естественно, имеется детальная информация о сети по данным с интерфейсов, с netflow, с сенсоров и т.д. Это все само собой разумеется.