Comments 116
если у вас гигабитная сеть, нет IP-видеонаблюдения, нет IP-телефонии и все свитчи подключены к одному свитчу-ядру. Могу вам позавидовать
А я бы посочувствовал. Навернулся свитч-ядро, и капут. Надобно сразу два ставить. Даже не в горячий резерв, а на параллельную работу.
выделение «название подразделения» в отдельный vlan.
Зачем?
Чтоб всей бухгалтерии разом перекрыть контактик, например.
Вообще-то фен-шуй велит, чтобы фильтрация запросов в интернет осуществлялась на основе логина, а не IP адреса компьютера или префикса.
Сетевики о логинах ничего не слышали и слышать не желают.
Но вообще доступ в интернет закрывается не адресами, а действительно проксей с AD аутентификацией.
Но вообще доступ в интернет закрывается не адресами, а действительно проксей с AD аутентификацией.
Даже ASA уже позволяют в ACLях указывать логины…
Ошибаетесь — там опять же ip адреса.
Архитектура построена так: на домен контроллер или компьютер в домене ставиться агент, который смотрит логи сервера AD на предмет логина. В логах пишется примерно так «user test1 logged on computer testcomp1» после этого агент по DNS смотрит ip адрес testcomp и скидывает инфу о соответствии логина ip адресу на ASA.
Итого АСА, принимая первый пакет от пользователя, сверяет его с имеющейся в ней базе login-ip и пускает или не пускает.
Архитектура построена так: на домен контроллер или компьютер в домене ставиться агент, который смотрит логи сервера AD на предмет логина. В логах пишется примерно так «user test1 logged on computer testcomp1» после этого агент по DNS смотрит ip адрес testcomp и скидывает инфу о соответствии логина ip адресу на ASA.
Итого АСА, принимая первый пакет от пользователя, сверяет его с имеющейся в ней базе login-ip и пускает или не пускает.
Речь про то, что IP адреса в явном виде не указываются в конфигурации. Будут применяться те политики доступа, что назначены конкретному юзеру.
Неа. ASA оперирует только ip адесами. И если злоумышленник знает адрес пользователя с полными правами ему ничего не стоит установить любую сессию.
Мы сдаём некоторые помещения в аренду дружественной компании. Мне очень не нравится, когда там по ошибке втыкают свой DHCP, да и пользователям сети это тоже не нравится.
Физика устроена таким образом, что мы вынуждены держать сети вместе, чтобы их правильно разнести и нужно управляемое оборудование.
Хотя с подразделением в влан я возможно перегибаю. Но компанию в влан — однозначно.
Физика устроена таким образом, что мы вынуждены держать сети вместе, чтобы их правильно разнести и нужно управляемое оборудование.
Хотя с подразделением в влан я возможно перегибаю. Но компанию в влан — однозначно.
Хотя с подразделением в влан я возможно перегибаю. Но компанию в влан — однозначно.
Тут уж надо бы даже не VLANами, а VRFами разделять, с файрволом посередке… А если вопрос ограничения доступа не стоит, то есть простейшие механизмы, позволяющие исключить такие атаки. DHCP snooping, IP source guard, DAI и так далее. Суммарно: невозможно поднять свой DHCP сервер, невозможно настроить на компьютере адрес статически, невозможно арп спуфингом нарушить работу сети у других и т.д.
Управляемое оборудование же способно справиться с DHCP за портом, за которым его не должно быть
Ну например для того чтобы сократить размер широковещательных доменов, на случай бродкастовых штормов.
Мимо. «Размер широковещательных доменов на случай штормов» сокращают «географически», т.е. ограничить количество устройств, видящих каждый VLAN. В этом плане создавать новые VLANы на тех же устройствах бесполезно. Все равно шторм разойдется на всем сетевом железе, загадит все аплинки и выжрет ресурсы всех свитчей.
Ну а что до уменьшения количества броадкастов — в современных 100мб сетях 500 компьютеров на VLAN не создаст никаких проблем, суммарный широковещательный трафик будет лишь десятки, край — сотни килобит.
Но я главным образом имел в виду «зачем разделять пользователей по VLANам на основе подразделений?». Обычно принято дробить по диапазонам портов. Я вот люблю в модульных коммутаторах делать по VLANу на слот (48 портов обычно).
Ну а что до уменьшения количества броадкастов — в современных 100мб сетях 500 компьютеров на VLAN не создаст никаких проблем, суммарный широковещательный трафик будет лишь десятки, край — сотни килобит.
Но я главным образом имел в виду «зачем разделять пользователей по VLANам на основе подразделений?». Обычно принято дробить по диапазонам портов. Я вот люблю в модульных коммутаторах делать по VLANу на слот (48 портов обычно).
ИМХО раздуваете панику. Во-первых «что может сделать… воткнувшись в порт бухгалтера»… А вы лучше спросите, что он может сделать оказавшись рядом со столом бухгалтера, на котором печать ООО лежит. Во-вторых, гигабитный core при нескольких 100Мбитных access покрывают нужды компании сильно с головой.
Обычно проблемы начинаются, когда активка расползается по конторе в виде «хабика под столом» и т.д.
Обычно проблемы начинаются, когда активка расползается по конторе в виде «хабика под столом» и т.д.
Ну например стандарт PCI DSS (который в последнее время вызывает у меня сильную мигрень) требует, чтобы все неиспользуемые на коммутаторах порты непременно были отключены. И, по-моему, там требуется проверка здоровья подключаемых к сети компьютеров (доменный ли комп, кто залогинился, какая дата у антивирусных баз, применены ли такие-то политики, стоит ли такой-то софт и т.д.), иначе не пущать практически никуда (реализуется либо отдельным VRFом для NAC, либо портовым ACL для ISE). Хотя тут не уверен, нам это в требованиях не писали, но у нас это и так развернуто.
Защита портов коммутатора и L2 — на самом деле весьма здравая идея, о которой действительно мало кто заботится.
Защита портов коммутатора и L2 — на самом деле весьма здравая идея, о которой действительно мало кто заботится.
Что нужно защищать больше — порт на коммутаторе или доступ к столу главбуха?
А что лежит в зоне ответственности сетевого инженера?
Что лучше — апельсин или велосипед?
А по поводу печати: работал я в одном из крупнейших банков. Нужно было впервые поставить печать на материальном пропуске. Мне объяснили, как нужно действовать. Итак: подхожу к указанному столу, бормочу «здрасьте», хватаю со стола печать банка, штампую бумажки, возвращаю печать и ухожу. Владелица печати на меня даже не посмотрела.
А вот человек, совершивший глупость вида «можно мне поставить печать?», потерял минут 5 на объяснениях по поводу «что это за бумаги?».
А по поводу печати: работал я в одном из крупнейших банков. Нужно было впервые поставить печать на материальном пропуске. Мне объяснили, как нужно действовать. Итак: подхожу к указанному столу, бормочу «здрасьте», хватаю со стола печать банка, штампую бумажки, возвращаю печать и ухожу. Владелица печати на меня даже не посмотрела.
А вот человек, совершивший глупость вида «можно мне поставить печать?», потерял минут 5 на объяснениях по поводу «что это за бумаги?».
Я с таким сталкивался в одной крупной фарм компании. Аналогичная история про печать. Однако, считаю это расхлябанностью, которая и ведёт к проблемам большого масштаба. В зоне своей ответственности такого не позволяю, поэтому и бешу многих :)
PCI DCC совсем не страшен — я его проходил несколько раз :)
Есть стандартные гайды по приведению оборудования к стандартам безопасности. Но тут тоже не стоит перегибать. Проже всего настроить авторизацию по 802.1X — тогда vlan будет динамически приезжать на порт пользователя. А ежели комп гостевой, то ему отдельный изолированный vlan вообще.
Очень удобно.
Есть стандартные гайды по приведению оборудования к стандартам безопасности. Но тут тоже не стоит перегибать. Проже всего настроить авторизацию по 802.1X — тогда vlan будет динамически приезжать на порт пользователя. А ежели комп гостевой, то ему отдельный изолированный vlan вообще.
Очень удобно.
У нас есть NAC и скоро будет ISE. Это круче :)
Я бы не сказал что круче… Cisco в промышленных масштабах скупает компании и привлекает на себя все больше технологий, но качество их конечно оставляет желать лучшего :(
BYOD еще не окрепло как понятие, как уже появился Cisco ISE. Чем проще, тем мне кажется надежнее.
BYOD еще не окрепло как понятие, как уже появился Cisco ISE. Чем проще, тем мне кажется надежнее.
ISE вполне прост, он вешает на порт ACL. Это проще, чем менять VLANы на портах.
К вопросу что проще — L2 или L3.
Вы не участвовали во внедрении того же NAC в нашей конторе для доменных машин. Да, факт перекидывания между VLANами вызывал колоссальные проблемы. И да, эти проблемы по определению исключены в случае ISE.
Хотя в случае изменения VLANа сразу после поднятия физики последствия будут менее неприятными.
И на самом деле L3 в случае L3 коммутатора будет даже малость попроще, чем L2. И хрен с ним, что надо глубже в пакет лазить.
Хотя в случае изменения VLANа сразу после поднятия физики последствия будут менее неприятными.
И на самом деле L3 в случае L3 коммутатора будет даже малость попроще, чем L2. И хрен с ним, что надо глубже в пакет лазить.
отключать порты на практике не очень удобно, куда проще перевести все порты в неиспользуемы VLAN и по мере подключения переводить порты в нужный.
На неиспользуемом VLANе неизбежно должен быть VACL вида «deny IP any any» и т.д. Да, я думал об этом — но надо еще уточнить, удовлетворятся ли этим аудиторы…
Просто, на транковых портах не пропускайте этот влан за пределы коммутатора.
Не годится — устройства за этими портами смогут общаться между собой и атаковать control plane свитча. Без VACL обойтись не удастся. Ну или извернуться средствами PVLAN.
Хабик под столом — согласен. Решение, которое потом превращает задачу установки новой розетки в кабинете в эпический квест, хотя в компании работает масса специалистов строительного плана и перестроить пару перегородок на этаже можно по телефонному звонку, аналогично и с электрическими розетками. Но, если придти и сказать, что этот исторический бардак надо убрать — квест. Несмотря на то, что от владельца стола\принтера и т.д. не требуется ровно ничего.
Хабик под столом тоже не проблема — если свичи управляемые, то на порту, с подключенным хабом устанавливается ограничение на кол-во мак адресов на порту и правило, которое первым n мак адресам разрешает работать, а остальных просто откидывает. Естественно правила типа «Каждый компьютер должен быть подключен в свой порт коммутатора, допускается подключение ip телефона и компьютера в один порт» должен быть прописан в политике компании по безопасности. Иначе настучат по голове за самоуправство.
Выбить денег на ровном месте? Сложно, но необходимо!Забавная агитка, а чего не написали про гарантию на железки или с контрактов маржа сликом маленькая?
Если всё работает – пора обновлять оборудование.
Если все работает — не трогай!
Я предпочитаю и пропагандирую метод трогать самому, планово и с головой. Чтобы для пользователя всё всегда работало. Профилактика дешевле лечения.
А я поддерживаю.
Метод «не чини то, что не сломано» всегда ведет к огромной головной боли. Например, руководствуясь этим методом, нельзя ставить патчи, если вроде как ничего не глючит…
Метод «не чини то, что не сломано» всегда ведет к огромной головной боли. Например, руководствуясь этим методом, нельзя ставить патчи, если вроде как ничего не глючит…
А вы не пробовали просто настроить грамотный мониторинг на все случаи жизни — чтобы смс присылало если чего не так.
Повторяю — грамотный, который позволяет не только факапы увидеть, но и общую текущую картину. По такому мониторингу можно посмотреть загрузки аплинков, спрогнозировать когда и где трафик упрется в аплинк и надо расширятся… Так же можно мониторить нестандартные поведения трафика и реагировать на них практически сразу.
Повторяю — грамотный, который позволяет не только факапы увидеть, но и общую текущую картину. По такому мониторингу можно посмотреть загрузки аплинков, спрогнозировать когда и где трафик упрется в аплинк и надо расширятся… Так же можно мониторить нестандартные поведения трафика и реагировать на них практически сразу.
Причем тут мониторинг?
Разумеется, есть целый отдел, занятый исключительно мониторингом и способный осуществлять самую базовую диагностику (потому СМС отсутствует — будет звонок). И естественно, имеется детальная информация о сети по данным с интерфейсов, с netflow, с сенсоров и т.д. Это все само собой разумеется.
Разумеется, есть целый отдел, занятый исключительно мониторингом и способный осуществлять самую базовую диагностику (потому СМС отсутствует — будет звонок). И естественно, имеется детальная информация о сети по данным с интерфейсов, с netflow, с сенсоров и т.д. Это все само собой разумеется.
При том, что «планово и с головой» как раз и предполагает то, что уже есть картина сети и ее можно просмотреть как в реальном времени, так и историю за некоторое время. Исходя из истории поведения на сети можно уже предполагать замены и т.п. В противном случае лучше и вправду ен трогать.
Я вас уверяю, что на точке обмена трафиком MSK IX стоят далеко не самые актуальные прошивки софта. И не потому, что кому-то лень, а потому, что не всегда знаешь — что произойдет в слачае обновления. Насколько может быть факап по времени. Где взять аналогичное оборудование для тестов, если оно все в продакшене?
Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.
Я вас уверяю, что на точке обмена трафиком MSK IX стоят далеко не самые актуальные прошивки софта. И не потому, что кому-то лень, а потому, что не всегда знаешь — что произойдет в слачае обновления. Насколько может быть факап по времени. Где взять аналогичное оборудование для тестов, если оно все в продакшене?
Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.
Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.
А к апгрейду стоит подходить с умом. Читать рассылки bug toolkit'а и release notes. Смотреть, какие есть опасные для данной железки с данной конфигурацией баги. Может обнаружиться баг уровня catastrophic, на который железка может напороться в любой момент.
Далеко ходить не надо. У меня пограничные BGP маршрутизаторы имеют (имели до недавнего времени) аптайм года 3. И вдруг при аварии на одном из каналов я заметил, что видимость интернета у нас далеко не полная, часть префиксов, полученных через резервные каналы, не попадала в таблицу BGP и виделась лишь в received-routes из-за soft-reconfiguration (даже при радикально более коротком AS-PATH и прочими равными). Поклирил нейбора — увиделись все, проблема ушла. Я открыл ради интереса список багов и выпал в осадок от того, какие связанные с BGP баги имели место быть в той версии. Там было штуки четыре severity 1, а менее опасных куда больше.
Для багов влияющих на компанию есть отдел безопасности.
Для связанных с роутингом багов? С какой стати? Вот за багами, представляющие собой вектора целенаправленной атаки на протоколы маршрутизации они действительно должны следить.
То о чем вы говорили так же может влиять на безопасность. Смотря какая политика безопасности у компании в общем.
Скорее — смотря какие безопасники. Даже с сетевыми безопасниками уровня CCIE Sec, сетевики могут считать их некомпетентными болванами, ничего не смыслящими в роутинге.
Вы сейчас безопасников оскорбили статусом CCIE Security. Они вообще знают про безопасность, а не про сети. :)
Хоть это и нелепо звучит, но это именно так.
Хоть это и нелепо звучит, но это именно так.
Безопаснику теоретически положено работать с VPNами, давать рекомендации по защите сети и т.д. CCIE Sec вполне это покрывает.
Направление CCIE по безопасности у циски очень специфическое. Для безопасности нужно не такое сертифицирование а CISSP например
CCIE Sec — сертификация не менеджера, а технаря. Который будет поддерживать системы, отвечающие за секьюрность.
В том-то и дело, что в отделе безопасности сидят менеджеры :)
Видимо, мы с сильно разными безопасниками общаемся. Некоторые непосредственно администрируют файрволы, VPNы, IPSы, сканеры wi-fi и т.д.
Да — это инженеры сетевого отдела (какое-нибудь подразденелие FW и т.п.). Они отвечают за настройку и отладку этих устройств и протоколов. А менеджеры отдела безопасности отвечают за политики безопасности и актуальность всего этим политикам — от софта и багов на нем, до решеток на окнах.
Про резерв запчастей ничего не написано. В целом — хорошо и применимо ко всем инфраструктурным проектам.
Подбираем оборудование с запасом. Здесь требуется подобрать оборудование с запасом по возможностям и портам. Желательно как можно более новое, чтобы его выпуск не прекратился через три месяца после начала проекта.
Зачем подбирать «как можно более новое», если стоит проблема обосновать бюджет руководству?
Сейчас есть большой рынок б/у сетевого оборудования. За стоимость нового dlink'a можно без проблем купить пару cisco, которые уже лет 5 не производятся.
Опасаетесь за качество? Купите на одну больше, протестируйте и положите в шкаф.
А почему не Длинки? L2-коммутаторы у них очень приличные, стоят копейки и идут с «пожизненной» гарантией.
Потому что все dlink'и которые я использовал благополучно сгорали или висли по питанию.
Пиком моего негодования по этому поводу было выгорание схемы питания у dlink'а des-30xx (точно модель не помню), который был подключен к ИБП APC серии rt (это которые с более менее нормальной развязкой питания).
А по поводу копеек, я бы поспорил.
Вот например 48 портовый DES-3052 стоит согласно яндекс маркету от 13 т.р.
Б/у Сisco C2950G-48-EI стоит менее 6т.р.
Мой выбор однозначен.
Пиком моего негодования по этому поводу было выгорание схемы питания у dlink'а des-30xx (точно модель не помню), который был подключен к ИБП APC серии rt (это которые с более менее нормальной развязкой питания).
А по поводу копеек, я бы поспорил.
Вот например 48 портовый DES-3052 стоит согласно яндекс маркету от 13 т.р.
Б/у Сisco C2950G-48-EI стоит менее 6т.р.
Мой выбор однозначен.
Древние каталисты продают на вес, потому что сотки на доступе уже откровенно мало.
Сколько будет стоить [стекируемый] 48-ми портовый гигабитный коммутатор от Циски? DGS-3120-48TC стоит 39 тысяч рублей.
Сколько будет стоить [стекируемый] 48-ми портовый гигабитный коммутатор от Циски? DGS-3120-48TC стоит 39 тысяч рублей.
Гигабит на доступе идет по моему начиная с серии 2960, она пока дорогая. Точно сказать не могу — посмотрите на shop.nag.ru.
И расскажите, мне правда интересно, зачем на доступе больше сотки? У меня даже на горизонте нет таких задач.
И расскажите, мне правда интересно, зачем на доступе больше сотки? У меня даже на горизонте нет таких задач.
Сотка на аксесс для пользователей — выше крыши. На аплинк — несколько агрегированных гигабитов для фиксированных свитчей либо 10G для модульных. Никто не выдает пользователям гигабиты.
У нас на типичном аксессе 4510R, нередко со старенькими supV, 100mb портов в среднем по 300-350 на шасси, аплинки 2 или 4 гигабита. Ни разу нигде не было даже намека на congestion.
Гигабитные порты скорее стоит выдавать не самым требовательным серверам. И вот тут должны быть очень серьезные проблемы с головой, чтобы ставить дэлинки на мало-мальски критических направлениях.
Тем более что у упомянутого DGS-3120-48TC нет ни одного 10G аплинка. Это уже даже не смешно. Oversubscription будет явно выше феншуйного 1/3…
У нас на типичном аксессе 4510R, нередко со старенькими supV, 100mb портов в среднем по 300-350 на шасси, аплинки 2 или 4 гигабита. Ни разу нигде не было даже намека на congestion.
Гигабитные порты скорее стоит выдавать не самым требовательным серверам. И вот тут должны быть очень серьезные проблемы с головой, чтобы ставить дэлинки на мало-мальски критических направлениях.
Тем более что у упомянутого DGS-3120-48TC нет ни одного 10G аплинка. Это уже даже не смешно. Oversubscription будет явно выше феншуйного 1/3…
Поддерживаю всех выше высказавшихся. Просвятите — это где откровенно мало 100 мегабит на access?
В голову приходит только варианты iSCSI загрузки системы у всех пользователей или Vmware thin client — он в первых версиях забивал полосу под 60 mbps хотя сейчас вроде поуменьшили аппетит.
В голову приходит только варианты iSCSI загрузки системы у всех пользователей или Vmware thin client — он в первых версиях забивал полосу под 60 mbps хотя сейчас вроде поуменьшили аппетит.
Есть хорошая алтернатива длинку и циске для гигабитного аксеса, это Allied Telesis AT-8000gs/24 цена 30 тыщ, стекируемый. Cisco like cli.
Зачем подбирать «как можно более новое»
Затем, чтобы при расширении или ошибках проектирования можно было бы докупить абсолютно такое же оборудование, а не бегать сломя голову с мыслями «что теперь делать с двумя длинками, пятью планетами, и восемью цисками». И на кой черт нужны циски без гарантии, что уже пять лет не производятся, эксплуатируются неизвестно кем в хрен знает каких условиях?
И на кой черт нужны циски без гарантии, что уже пять лет не производятся, эксплуатируются неизвестно кем в хрен знает каких условиях?
1. Продавец дает гарантию на б/у циски 3 месяца. За 10% цены — на год. За 30% цены — на три года.
2. То что они не производятся ничего не значит, потому как купить их проблем нет никаких. К примеру сейчас я беру линейку 2950, а через пять лет я буду покупать 2960. Никаких проблем.
3. Предыдущая эксплуатация конечно может быть неблагоприятной, но опять же — купите с запасом, протестируйте под нагрузкой и положите в шкаф. Решите сразу две проблемы — и сеть обновите и резерв создатите.
Бывает так, что сеть до тебя уже выстроена и весьма неплохо, на хорошем оборудовании, ядро дублировано на 3COM гигабитных свичах L2. (2005й год). запас по портам и пропускной способности некоторый есть. А стоимость замены оборудования — 15-20 килобаксов. В таком случае затеивать обновление — не самый лучший совет :)
Так что бывают случаи, когда знать все это полезно, но делать все равно ничего не надо, кроме как иметь план.
Так что бывают случаи, когда знать все это полезно, но делать все равно ничего не надо, кроме как иметь план.
Иметь план при аварии разом выложить все 20 штук баксов, потому что сегодняшнее используемое в продакшен оборудование уже EOS и заменить таким же или починить не представляется реальным?
На тот момент не представлялось. Через 2 года — да, компания подросла и финансово попроще стало, IT директор появился.
На данный момент — не знаю, я в IT уже 4й год не работаю.
На данный момент — не знаю, я в IT уже 4й год не работаю.
А зачем покупать такое-же? За несколько лет свитчи ухудшаются? Покупайте новое, в кол-ве одна штука (а лучше имейте на складе, и докупаейте на склад) и все будет ок.
С аргументами автора в целом согласен, но по поводу финансирования — весьма спорный вопрос. Как мне кажется, есть два основных момента: вы, как администратор, формируете бюджет, который должен быть утвержден, в конечном счете, руководителем компании. Если руководитель — наемный менеджер, которому поставлены конкретные PKI (повышение продаж, доля на рынке и т.д.), то он, с высокой долей вероятности, внемлет вашим аргументам о необходимости закупки нового оборудования, так как у вас есть свой PKI (доступность, мощность, непрерывность), но если руководитель = владелец, то тут отношение совсем другое (IT только деньги тратит, да пользы от них никакой, и так все работает и т.д.). К тому же имеется эффект масштаба — купить один маршрутизатор или 1000, для модернизации большой сети, уже совершенно разный ценник.
UFO just landed and posted this here
Зато сразу есть к чему стремиться :)
UFO just landed and posted this here
по сетям как минимум CCNA сдайте и сразу будет другой взгляд на процесс.
Есть такое явление, которое я называю «синдром CCNA». Симптом: человек, осиливший данную сертификацию, почему-то уверен, что он хоть что-то знает про работу сетей. Я сам им в свое время переболел.
Зато сразу есть к чему стремитьсяНу например из тех контор, где надо с боем выбивать нужное железо на жалкие $20k, я бы убегал быстрее ветра… Топик в основном про них и написан.
CCNA — зло! Это отвратительнейший, на мой скромный взгляд, экзамен, при подготовке к которому человеку заливают в голову совершеннейше вредные вещи, типа router-on-stick! ITIL/ITSM — полезнейшая вещь, но только 2 версии, где процесс-ориентированный подход, так как в 3-й всё черезчур отдалено от наших реалий. Для ITIL рекомендую книгу Потоцкого, после прочтения коей я стал совсем по другому смотреть на свою повседневную деятельность.
UFO just landed and posted this here
Называется «Введение в ITSM», гуляет по интернетам в фомате .doc, есть на рутрекере, по моему. По поводу CCNA: так получилось, что я его сдавал уже после сданных ROUTE и SWITCH и я был неприятно удивлен тем, что курс охватывает только самые вершки и явно давно не пересматривался.
UFO just landed and posted this here
совершеннейше вредные вещи, типа router-on-stick!
Ну как бы создавать на маршрутизируемых интерфейсах роутеров сабинтерфейсы — совершенно нормальная практика для компаний любого масштаба. Я правильно понимаю, что претензии идут к концепции «пользователи на L2 свитче, а default GW у них указывает на подключенный транком роутер»? Дык и это используется очень часто в типовой топологии мини-бранча, где сидят 20 сотрудников с IP телефонами. Топология: пара различных каналов заходит на роутер, он по ним поднимает DMVPN к примеру до разных ЦОДов, а третьим концом смотрит на свитч уровня 2960, на котором висят юзеры и телефоны. Не вижу никаких проблем с такой реализацией (подчеркиваю — только мелкого офиса). Или прикажете ставить 3560-е в каждый миниофис и поднимать пару SVI под голос и данные? Дороговато будет, а смысла — никакого.
Нет, немного не так. Сабинтерфейсы были нормальной практикой до появления модуля WIC-4ESW для 17xx серии.
Для SMB-офисов я сам сторонник установки дешевых L2 коммутаторов, тут я с Вами полностью согласен, но если нужно больше 1-го Vlan, то и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan, что можно сделать чере HWIC-4ESW, NM-16ESW и т.д. Если трафик между этими Vlan будет больше 100 Мб/с, то уже стоит озаботиться L3 коммутатором.
Для SMB-офисов я сам сторонник установки дешевых L2 коммутаторов, тут я с Вами полностью согласен, но если нужно больше 1-го Vlan, то и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan, что можно сделать чере HWIC-4ESW, NM-16ESW и т.д. Если трафик между этими Vlan будет больше 100 Мб/с, то уже стоит озаботиться L3 коммутатором.
Сабинтерфейсы были нормальной практикой до появления модуля WIC-4ESW для 17xx серии.
Нет. Функциональность (особенно QoS) несравнима, etherswith модули в этом смысле крайне убоги.
если нужно больше 1-го Vlan, то и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan
Назовите ровно одну причину для этого. Всей моей фантазии почему-то не хватает. Отродясь не использовал любого рода etherswitch модули кроме как некоторое время назад дома (затем тоже отказался и перешел на чистый транк).
Единственное применение etherswitch — если не хочется ставить отдельную железку-свитч, тогда можно втыкать в него конечных пользователей, сейчас у них даже PoE есть. Если отдельный свитч в любом случае будет, подключать его к hwic-4esw (если хватает маршрутизируемых портов и если к модулю больше ничего не подключено, т.е. исключив архитектуру «роутер — ядро/распределение») будет несусветной глупостью.
Вот одна: сравните информативность sh int:
Vlan225 is up, line protocol is up
Hardware is EtherSVI, address is 0019.e771.1d78 (bia 0019.e771.1d78)
Description: — … — Internet address is .../30
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 4/255
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:20:00, output never, output hang never
Last clearing of «show interface» counters never
Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1588000 bits/sec, 206 packets/sec
5 minute output rate 774000 bits/sec, 198 packets/sec
231685519 packets input, 3500754793 bytes, 0 no buffer
Received 3 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
221143132 packets output, 2834337340 bytes, 0 underruns
0 output errors, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
и
GigabitEthernet0/1.225 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 0019.e869.6ff9 (bia 0019.e869.6ff9)
Description: — … — Internet address is .../30
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 5/255, rxload 4/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 225.
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of «show interface» counters never
Vlan225 is up, line protocol is up
Hardware is EtherSVI, address is 0019.e771.1d78 (bia 0019.e771.1d78)
Description: — … — Internet address is .../30
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 4/255
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:20:00, output never, output hang never
Last clearing of «show interface» counters never
Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1588000 bits/sec, 206 packets/sec
5 minute output rate 774000 bits/sec, 198 packets/sec
231685519 packets input, 3500754793 bytes, 0 no buffer
Received 3 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
221143132 packets output, 2834337340 bytes, 0 underruns
0 output errors, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
и
GigabitEthernet0/1.225 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 0019.e869.6ff9 (bia 0019.e869.6ff9)
Description: — … — Internet address is .../30
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 5/255, rxload 4/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 225.
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of «show interface» counters never
Обычно за статистикой по скорости передачи данных принято обращаться к SNMP-мониторилкам, не? Там всё есть…
Я правильно понимаю, что ни одного иного аргумента в пользу «и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan» нету? И возможность увидеть скорость передачи пакетиков с определенным тегом Вы оцениваете примерно в $400?
Я правильно понимаю, что ни одного иного аргумента в пользу «и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan» нету? И возможность увидеть скорость передачи пакетиков с определенным тегом Вы оцениваете примерно в $400?
Вы просили назвать — я назвал, а в ответ слышу демагогию про SNMP.
Какая же это демагогия?
Счетчики на интерфейсах совершенно неинформативны. Весь мир следит за трафиком с помощью SNMP…
Так все-таки: на каком основании Вы категорично заявили, что «router-on-a-stick» — «совершеннейше вредная вещь»? Только на основании объема вывода «show interface», правильно?
Счетчики на интерфейсах совершенно неинформативны. Весь мир следит за трафиком с помощью SNMP…
Так все-таки: на каком основании Вы категорично заявили, что «router-on-a-stick» — «совершеннейше вредная вещь»? Только на основании объема вывода «show interface», правильно?
Дмитрий, я не собираюсь Вас в чем-либо убеждать, если вы сдавали CCNP, то должны знать, что router-on-a-stick шарит пропускную способность между сабинтерфейсами и является единой точкой отказа для сети (это то, что явно упоминается в CCNP SWITCH 642-813 Quick Reference). Так же, мой опыт позволяет говорить о повышении нагрузки на CPU маршрутизатора при использовании данного решения.
router-on-a-stick шарит пропускную способность между сабинтерфейсами и является единой точкой отказа для сети
А один проводок, заходящий в etherswitch модуль и несущий на себе несколько VLANов, не является в точности такой же единой точкой отказа?
Если Вы используете по одному физическому проводку на каждый VLAN, то это воистину кошмарно. Даже CCNA не станет делать такую глупость.
«Шарит пропускную способность» абсолютно не является проблемой по одной простой причине: ресурсов роутера не хватит для полной загрузки даже одного имеющегося у него физического интерфейса. Так что «пропускная способность» ни разу не является аргументом. Хотя при желании никто не мешает поднять сабы не на физике, а на порт-ченнеле.
это то, что явно упоминается в CCNP SWITCH 642-813 Quick Reference
Я сдавал CCNP еще когда про SWITCH никто не слышал :) С тех пор как-то ориентируюсь не на курсы, а на SRND, config guide'ы и так далее. Там информация малость более подробная и актуальная…
Но новый трек CCNP мне абсолютно не нравится. Ну кто додумался выкинуть из него QoS к примеру? Куда делась безопасность? Раньше «CCNP» значило «универсал с углубленным знанием роутинга-свитчинга», а сейчас это вообще что-то непонятное.
Так же, мой опыт позволяет говорить о повышении нагрузки на CPU маршрутизатора при использовании данного решения.
Откуда же эта нагрузка берется? :) Вы этим вопросом вообще занимались? У меня вот в обоих сценариях нагрузка одинаковая, как оно и должно быть. Рекомендую ознакомиться с www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml к примеру…
Простите, что вмешиваюсь, но отходя от темы, как бы вы сейчас подходили к изучению Cisco оборудования? Мне интересно из практических соображений, хочу углубиться от банальной настройки роутеров 800 серии.
Sign up to leave a comment.
Обновление сетевого оборудования