окей, я понял что у каждого свой взгляд на то каким должен быть «пиринг». но это не меняет того факта что впн не нужен при наличии управляемого доступа.
однако, даже исходя из вашей логики «пирингов», где «пиринг» это серые адреса, придется каждого пользователя заставлять прописывать все используемые диапазоны таких адресов либо вручную, либо заставлять качать скрипты всякие, либо экспериментировать с дшцп. зачем эти сложности не ясно.
да, впн терминировать это еще та затея. то с горой писюков вола насиловать, анонсирую в бэкбон по /32 от каждого подключившегося ебонента, то большую и дорогую железяку покупай, то еще что. это все хорошо и замечательно, когда нет умного доступа.
почему не защищают? если мак прибит гвоздями к порту, то как врезавшийся в кабель гастролер узнает этот мак чтобы начать работать? позвонит в саппорт и попросить флушнуть мак? а номер договора абонента он назовет или каким способом проавторизуется у саппорта?
1. каким образом с туннелем отделять пиринговый трафик от интернета на порту пользователя? по дшцп костылями ему вдуть тонну маршрутов статики? заставить его регулярно запускать скрипт который качает список сетей с рутсервера провайдера и прописывает его в статику? это все слишком сложно и этого быть не должно. пользователь не должен греться такой х*йней.
2. раз гигобиты пирингового трафика нельзя отделить, то надо их рутить через брас => покупка конячих брасов. при этом без них вообще можно было обойтись если не пользовать туннели.
pptp/l2tp/pppoe и т.п. существуют лишь для того чтобы избавиться от проблемы подмены адресов/маков в случае если доступ на неуправляемых свищах, как это было лет 5 назад на моей деревне. тогда и каналы были поменьше и пиринги не так чтобы уж шибко развиты и управляемые свищи дорогими. :D
никак не борются, потому что аплинк свища жирнее чем порты пользователя, как результат даже нескольким пользователям забить его будет сложно, одному — вообще не возможно.
простой пример: DES3526 — 24 порта 10/100 и 2 шареда на 10/100/1000. тянем до агрегации два провода в lacp, получаем на свищ доступа 2гбе канал. т.о. чтобы его «забить», надо заставить одновременно «качать» сразу 20 пользователей, вероятность чего крайне мала.
особо отчаяным можно конечно нарисовать кос. имхо, оно не надо.
1. я хочу сказать что как магистрала никто не обременяет натами, так и хомяка никто не обременяет мплсом на полмира. ценовой перевес явно не в сторону хомяка. у хомяка задачи гораздо скромнее и соответственно цена на инфраструктуру тоже. «купить кота» для хомяка и тоже самое для магистрала — две большие разницы как по цене, так и по фичам. да и обслуживать спд на полмира явно накладнее чем например горсть раенов в городе.
2. а в чем разница, тем более «БОЛЬШАЯ»? :D
3. да, вижу. зачем q-in-q? зачем тащить трафик в ядро? ну и кто сказал что этого трафика будет много? в звезде у вас и так трафик между свичами ходит как минимум через агрегацию, ну добавится к нему трафик между портами на свичах, чо такого-то. или у вас порта доступа по полосе такие же как «магистральные» линки между свищами? вобщем я не хочу вдаваться в детали и полемику по ним, хотя уже вдался. :D если кратко, то нет, суть не та же.
4. нет, у вас речь о том что вместо асы надо поставить линукс, а у меня речь о том что при желании можно жить на вендорах первого эшелона, тем более уж в таком простом месте как хоменетик :) надо просто адекватно составлять себе список задач для железа.
5. хоменет из нескольких тысяч абонентов, а тем более нескольких десятков тысяч, без особых сложностей может позволить купить себе даже новых котов. ну да ладно, в разных местах наверняка разная планка «самоокупаемости» хоменета и его «прибыльности». не буду спорить о количестве абонентов. переформулирую: техдир игнорирующий возможность преобретать «нормальные» решения от вендоров и «экономящий» линуксом должен быть распят на кресте и выпорот ссаными тряпками. :)
ps: на вопросы из пункта 3 отвечать не надо. а то всё превратится в обмусоливание деталей. :)
> Как раз ошибаются те, кто пытается навязать одни и те же стандарты для совершенно разных сфер телекома.
расскажите это местному на моей деревне хоменету с 20 или сколько там тысячами абонентов, отчаяно пытавшемуся жить на телесинах и линуксах/бсдях, но таке сдавшемуся и купившему гору «котов» за гору денег. представте себе, они довольны.
> Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить?
а что, хомяку надо больше что-то? хомяку как раз таке можно и вообще меньше :) не надо озадачиваться годными свищами на доступ способными нарезать скорость в обоих направлениях. ему как раз можно бриджующий полисер сунуть между ядром и погранцом и быть счастливым. вопрос с nat'ом решается так же. чего здесь сложного и страшного не очень понятно. цена решения от вендора первого эшелона? если уж вдаваться в детали, ну для nat'а у juniper'а есть на 500 мегабит железка где-то за 100 тыщ рублей. пролиант для этих затей не намного дешевле будет, если вообще будет.
> Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс…
нет, не одинакого. у кого-то pppoe, у кого-то pptp, у кого-то «умный доступ» c vlan per user и на котах, у кого-то такой же доступ и на писючках с санным линуксом и лютыми лагами и печалью в фейловере. из «бесплатных» альтернатив меня только фряха с мпд и каром радует как впн-концентратор. всё остальное уныло чуть более чем полностью. ну да, думминетик во фряхе тоже удобен по тейбларгу в таблице гору динамических пайпов рожать. :))
> А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
опять же если вдаваться в детали, то по моему скромному мнению — аса говно. но это уж наверно удел всего совка дрочить, плакать, колоться на циско, но всего равно её жрать. но это их выбор, возможно чем-то обусловлен даже.
> Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов…
ппц, несколько тысяч абонентов и продолжать абать вола на линуксах. простите, конечно, но таких директоров надо гнать ссанными тряпками с такими их политиками.
не надо выдавать желаемое за действительное. дураком я никого не обзывал. я лишь заметил что всё это имеет мало общего с телекомом. я не спорю что домушние сети собранные любителями линукса ради проведения домой себе интернета вряд ли могут позволить купить себе какую вундервафлю (однако есть примеры как такие сети покупали себе б/у фаундри/циско/жунипер и в ус не дули довольные покупкой :)), но и вобщем-то со всеми вытекающими. :)
да, с позицией автора топика и многих в откомментировавших я не согласен. тут считают что «Не Linux в провайдинге используют разве что самые неадекватные». со сторонниками этой идеи я не имею большого желания вести долгую и нудную палемику об очевидных вещах. я хочу лишь чтобы сторонники этой идеи пошли к ростелекому, ретн.нету, транстелекому, телии и многим другим операторам связи и рассказали о том как они ошибаются, ведь можно сэкономить и использовать линукс, мужики-то ведь не знают, ога. кстати, их всех только что назвали неадекватными. мне на такие заявления нечего сказать, я просто не найду подходящих слов чтобы быть понятым сообществом.
кстати, не смотря на все заявления про линукс, автор топика таке купил для ната cisco asa, а для погранца cisco asr. не кажется что одно протеворечит другому? да, не озаботились резервом, но это проблемы кастомера, чо уж. быть годным оператором связи нынче накладно, суетно и вовсе не сулит золотые горы. :)
автор топика, кстати, рассказывает про сооружения аварийных костылей о которых не было подумано вначале и риски не были правильно оценены. это уже тут общество провозгласило культ линукса на не совсем понятной почве.
они же конкуренты, это очевидно что примерно одинаковые цены на одинаковый класс. я и говорю что оно никак не «крайний случай, когда не хватило бабла на циско».
>>Да, а на DMVPN подняли распределенную сеть (в пределах Украины, не России) с видео телефонией. Голос совершенно нормален, видео — в зависимости от канала.
я говорил не про каналы провайдеров для офисов, а про то что «офисный» не дорогой кот восьмисотой серии плохой кандидат для офиса в dmvpn инфраструктуре с каким-то более менее активным обменом данных и тем более телефонией вкупе, в отличии от срх за те же деньги. старшие модели никак не работают спасают положение, с крипто там всё так же уныло, цены всё так же велики, вобщем грусть, да печаль. :) зато можно dmvpn на e-tolken'ах городить и pvdm dsp с e1 портами втыкать и плясать от счастья «сколько всего в одной коробчонке». :)
о! :) полезли в ход тонкости. не надо переживать, все проблемы можно решить. ну и да, я конечно представляю dmvpn на 8ХХ коте с шифрованием, горой «прямых» туннелей по которым ходить voip и квакает в трубке телефонной ^___^
производительность в bps с шифрованием она одна, хоть с одним туннелем, хоть с горой. разница только в том что по этому параметру и 2801 отсасывает вполне себе. толку то от этого dmvpn'а. но не спорю, фича конечно хорошая и вообще. насчет аналога у juniper не озадачивался, надо почитать.
про ip-телефонию в целом тоже весьма громко сказано и слишком широко. что имеет под этим ввиду? sip у cisco прямо скажем не очень. h323 — мертвый протокол. да и стоимость решения ip-телефонии от cisco не просто сказочная, а очень сказочная. что не устраивает в использовании для телефонии железа отдельного вендора? того же аудиокодеса. насколько помню получается ощутимо дешевле циски, а по качеству ни чуть. да и сами циски вроде как пользуют чипы того же аудиокодеса.
вообще я считаю не надо мешать все в кучу, в частности пд и войп. пускай уж каждый занимается своим делом. вся это комплексность котов в итоге вылевается и в жирную стоимость и в то что умеют много, всего и… и посредственно. :\
т.е. всю инфраструктуру сети ПД на рутирах и коммутаторах, скажем, juniper нельзя построить?
а в филиалах вообще младшим srx нет равных за те же деньги шифрованный впн гонять. cisco отсасывает либо по производительности либо по деньгам.
никто не говорил про зоопарк и никто не говорил про меньшие деньги между прочим. равно как никто не предлагал строить сети на делинках. так что вы мимо тазика со своим патриотичным постом про cisco.
если речь за ipv6, то все коты его умеют в той или иной степени, даже те что несколько лет как не только eos, но и eol. :)
в частности в упомянутый вами sup2 легко влезет десятки ipv6 full-view таблиц. :) понятно дело со временем они могут перерасти возможности tcam'а, так же как это сделал ipv4 в свое время, но когда оно из 3.5 тыщ маршрутов превратится в что-то большее чем 250 тыщ :)
Chapter Goals
•Introduce the OSI protocol, used primarily to facilitate multivendor equipment interoperability.
•Discuss the structures and functioning of this protocol, from its introduction in the early 1980s.
мне кажется не двусмысленно нам говорят о представлении протокола OSI.
слева в оглавлении рядом есть ссылка про Internet Protocol и IPv6, рекоммендую так же открыть и прочитать.
выше товарищ eek написал «90% того что сейчас выдается за новинки ipv6 было реализовано в протоколе OSI более 25 лет назад» и весь забр ринулся с пеной у рта доказывать очевидные вещи и спорить о _ДРУГОМ_. мне до фени ваши доказательства и споры, я пытаюсь сказать что судя по приведенной ссылке на документ описан комплекс протоколов альтернативный нынешним с, возможно, и с этими 90% новинками из IPv6.
>>>>а дальше выясняется что ничего вобщем-то общего у эти OSI protocols suite кроме как OSI модели с текущим IPv4 нет ни грамма.
>>Это вообще сравнение автопарка с самокатом. Как можно стек протоколов сравнить с одним из членов стека?
я имел ввиду, конечно, сравнение сетевого уровня между тем что в OSI protocols suite и тем что в Internet Protocol.
а так то да, все они из модели OSI. но так уж у них вышло этот комплекс протоколов назвать провакационной обревиатурой OSI.
уважаемый, вы для начала по ссылкам сходите которые вам дали и прочувствуйте разницу:
en.wikipedia.org/wiki/Iso_osi
The Open Systems Interconnection model (OSI model) is a product of the Open Systems Interconnection effort at the International Organization for Standardization.
вам, как человеку не привыкшему читать дальше одного абзаца, есессно не заметно разницы, хотя она _уже_ есть в абревиатуре :)
читаем дальше линк про cisco и видим блоксхему со знакомыми квадратиками референсной модели OSI и вот, ортодоксальный забраюзер с улюлюканьем бежит разоблачать. :) не нужно игнорировать не понятные буквы в квадратиках, нужно прочитать про них дальше.
а дальше выясняется что ничего вобщем-то общего у эти OSI protocols suite кроме как OSI модели с текущим IPv4 нет ни грамма. ну а про общее в начале ясно написано почему оно общее. :)
OSI protocols suite может использовать в качестве канального уровноя ethernet, да. но всё что выше не очень похоже на то что вы привыкли видеть. в частности взаимодействие между канальным и сетевым уровнем осуществляется через протокол NSAP, который дает на канальном уровне адрес IDP (Initial Domain Part), а на сетевом DSP (Domain Specific Part), каждый из которых подразделяется на две и четыре подзаголовка соответственно, каждый со своей целью. как-то так, о деталях любознательныe могут прочитать сами.
да, очевидно, какие-то блоки из IPv4 были заменены здесь соответственно модели OSI, а какие были добавленны, так же в рамках модели OSI. немножко запутано и сложновато, но это оттого что я впервые читаю про него :) я еще слишком молод чтобы знать такие вещи :D
да, об IS-IS, это протокол внутренней маршрутизации основанный на индикации интерфейсов, он действительно был заимствован от сюда, а его вторая часть IS-ES выброшена на свалку истории. :(
вобщем не надо путать теплое с мягким, товарищи. модель OSI, это модель. по ней может быть создано сколько угодно протоколов, но так уж вышло что массам известен IPv4 и грядущий IPv6 :) ну и да, вы кричите «пруфлинк», дак будьте любезны читать эти самые «пруфлинки».
этих ваших NAT'ов я повидал не только в делинке за $50 для дома и могу смело утверждать что вы _переоцениваете_ преимущества NAT'а. даже не так, вы видите преимущества в том где их нет впринципе. давайте начнем с того что сам по себе NAT — это костыль, выдуманный после того как стало ясно что в IPv4 недостаточно адресов. улавливаете мысль? _задача_ и _цель_ NAT'а продлить жизнь IPv4 и на этом всё, роль пакетного фильтра NAT не выполнял и никогда не будет выполнять. всё остальное что вы считаете «преимуществами» лишь побочный эффект, который не есть сама цель. кстати в этих ваших делинках за $50 таке пакетный фильтр используются и благодаря которому из вне не попасть в вашу внутреннюю сеть, а вовсе не из-за ната.
самый простой сценарий пенетрации NAT'а без пакетного фильтра: на устройстве в пределах direct линка с этим делинком прописать маршрут на вашу домашнюю сеть на внешний ойпи этого делинка. да, для этого надо знать внутренню подсеть, только меняете ли вы её с дефолтной? да, есть проблема с тем что исходящие из этой сети пакеты всё равно будут натиться, но ведь послать мегастрашный пакет с магическим содержимым в ваш компьютер всё равно можно.
кстати, с IPv6 вам дома не нужен роутир. а для безопасности хватит аутпоста на компьютере :) возможно в будущем получат своё развитие «бриджующие» фильтры, которые будут ставиться в разрыв и не влиять на топологию сети на канальном уровне.
вы не правы. нат вам «слегка» поможет только от ботов которые долбятся на внешние адреса. от этого вас легко спасет и обычный пакетный фильтр, который прикроет все порты от входящих соединений без всяких натов. заразу можно подхватить и на исходящих соединениях которые вы в любом случае устанавливаете. сходите на сайт, схватите бяку, бяка запустит коннекшн-бэкдор и никакие наты не спасут :)
все описаные для ната преимущества решаются политиками пакетнами фильтра, как было правильно замечено в статье. а профита от IPv6 в разы больше, например ваш любимые P2P будет работать не обязывая пользователя сношаться с upnp или портмаппингом.
в IPv6 я вижу плюсов гораздо больше чем минусов. а уж для конечных пользователей так вообще сплошные плюсы.
ну для начала необходимо прочитать какие адреса бывают в ip6. приведенный вами адрес является «link-local» и аналогом 169.254.0.0/16 из ip4, который наверняка вам знаком, — в случае если dhcp в сервере не найдет, то windows присваивает адрес интерфейсу ip4 именно из этого диапазона. вобщем не суть, вам нужен global unicast адрес для маршрутизации в мир. его можно получить несколькими путями. самый простой, если ваш провайдер предоставит вам линк на ip6. чуть более сложный способ, использовать туннельного брокера ip6 адресов. как сделать последнее написано в гуглах и википедиях, и несколько раз на забре:
однако, даже исходя из вашей логики «пирингов», где «пиринг» это серые адреса, придется каждого пользователя заставлять прописывать все используемые диапазоны таких адресов либо вручную, либо заставлять качать скрипты всякие, либо экспериментировать с дшцп. зачем эти сложности не ясно.
да, впн терминировать это еще та затея. то с горой писюков вола насиловать, анонсирую в бэкбон по /32 от каждого подключившегося ебонента, то большую и дорогую железяку покупай, то еще что. это все хорошо и замечательно, когда нет умного доступа.
почему не защищают? если мак прибит гвоздями к порту, то как врезавшийся в кабель гастролер узнает этот мак чтобы начать работать? позвонит в саппорт и попросить флушнуть мак? а номер договора абонента он назовет или каким способом проавторизуется у саппорта?
1. каким образом с туннелем отделять пиринговый трафик от интернета на порту пользователя? по дшцп костылями ему вдуть тонну маршрутов статики? заставить его регулярно запускать скрипт который качает список сетей с рутсервера провайдера и прописывает его в статику? это все слишком сложно и этого быть не должно. пользователь не должен греться такой х*йней.
2. раз гигобиты пирингового трафика нельзя отделить, то надо их рутить через брас => покупка конячих брасов. при этом без них вообще можно было обойтись если не пользовать туннели.
pptp/l2tp/pppoe и т.п. существуют лишь для того чтобы избавиться от проблемы подмены адресов/маков в случае если доступ на неуправляемых свищах, как это было лет 5 назад на моей деревне. тогда и каналы были поменьше и пиринги не так чтобы уж шибко развиты и управляемые свищи дорогими. :D
простой пример: DES3526 — 24 порта 10/100 и 2 шареда на 10/100/1000. тянем до агрегации два провода в lacp, получаем на свищ доступа 2гбе канал. т.о. чтобы его «забить», надо заставить одновременно «качать» сразу 20 пользователей, вероятность чего крайне мала.
особо отчаяным можно конечно нарисовать кос. имхо, оно не надо.
2. а в чем разница, тем более «БОЛЬШАЯ»? :D
3. да, вижу. зачем q-in-q? зачем тащить трафик в ядро? ну и кто сказал что этого трафика будет много? в звезде у вас и так трафик между свичами ходит как минимум через агрегацию, ну добавится к нему трафик между портами на свичах, чо такого-то. или у вас порта доступа по полосе такие же как «магистральные» линки между свищами? вобщем я не хочу вдаваться в детали и полемику по ним, хотя уже вдался. :D если кратко, то нет, суть не та же.
4. нет, у вас речь о том что вместо асы надо поставить линукс, а у меня речь о том что при желании можно жить на вендорах первого эшелона, тем более уж в таком простом месте как хоменетик :) надо просто адекватно составлять себе список задач для железа.
5. хоменет из нескольких тысяч абонентов, а тем более нескольких десятков тысяч, без особых сложностей может позволить купить себе даже новых котов. ну да ладно, в разных местах наверняка разная планка «самоокупаемости» хоменета и его «прибыльности». не буду спорить о количестве абонентов. переформулирую: техдир игнорирующий возможность преобретать «нормальные» решения от вендоров и «экономящий» линуксом должен быть распят на кресте и выпорот ссаными тряпками. :)
ps: на вопросы из пункта 3 отвечать не надо. а то всё превратится в обмусоливание деталей. :)
расскажите это местному на моей деревне хоменету с 20 или сколько там тысячами абонентов, отчаяно пытавшемуся жить на телесинах и линуксах/бсдях, но таке сдавшемуся и купившему гору «котов» за гору денег. представте себе, они довольны.
> Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить?
а что, хомяку надо больше что-то? хомяку как раз таке можно и вообще меньше :) не надо озадачиваться годными свищами на доступ способными нарезать скорость в обоих направлениях. ему как раз можно бриджующий полисер сунуть между ядром и погранцом и быть счастливым. вопрос с nat'ом решается так же. чего здесь сложного и страшного не очень понятно. цена решения от вендора первого эшелона? если уж вдаваться в детали, ну для nat'а у juniper'а есть на 500 мегабит железка где-то за 100 тыщ рублей. пролиант для этих затей не намного дешевле будет, если вообще будет.
> Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс…
нет, не одинакого. у кого-то pppoe, у кого-то pptp, у кого-то «умный доступ» c vlan per user и на котах, у кого-то такой же доступ и на писючках с санным линуксом и лютыми лагами и печалью в фейловере. из «бесплатных» альтернатив меня только фряха с мпд и каром радует как впн-концентратор. всё остальное уныло чуть более чем полностью. ну да, думминетик во фряхе тоже удобен по тейбларгу в таблице гору динамических пайпов рожать. :))
> А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
опять же если вдаваться в детали, то по моему скромному мнению — аса говно. но это уж наверно удел всего совка дрочить, плакать, колоться на циско, но всего равно её жрать. но это их выбор, возможно чем-то обусловлен даже.
> Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов…
ппц, несколько тысяч абонентов и продолжать абать вола на линуксах. простите, конечно, но таких директоров надо гнать ссанными тряпками с такими их политиками.
да, с позицией автора топика и многих в откомментировавших я не согласен. тут считают что «Не Linux в провайдинге используют разве что самые неадекватные». со сторонниками этой идеи я не имею большого желания вести долгую и нудную палемику об очевидных вещах. я хочу лишь чтобы сторонники этой идеи пошли к ростелекому, ретн.нету, транстелекому, телии и многим другим операторам связи и рассказали о том как они ошибаются, ведь можно сэкономить и использовать линукс, мужики-то ведь не знают, ога. кстати, их всех только что назвали неадекватными. мне на такие заявления нечего сказать, я просто не найду подходящих слов чтобы быть понятым сообществом.
кстати, не смотря на все заявления про линукс, автор топика таке купил для ната cisco asa, а для погранца cisco asr. не кажется что одно протеворечит другому? да, не озаботились резервом, но это проблемы кастомера, чо уж. быть годным оператором связи нынче накладно, суетно и вовсе не сулит золотые горы. :)
автор топика, кстати, рассказывает про сооружения аварийных костылей о которых не было подумано вначале и риски не были правильно оценены. это уже тут общество провозгласило культ линукса на не совсем понятной почве.
хуясебе крайний случай — juniper. вы ценники на juniper-то хоть видели?
йеп
>>Да, а на DMVPN подняли распределенную сеть (в пределах Украины, не России) с видео телефонией. Голос совершенно нормален, видео — в зависимости от канала.
я говорил не про каналы провайдеров для офисов, а про то что «офисный» не дорогой кот восьмисотой серии плохой кандидат для офиса в dmvpn инфраструктуре с каким-то более менее активным обменом данных и тем более телефонией вкупе, в отличии от срх за те же деньги. старшие модели никак не работают спасают положение, с крипто там всё так же уныло, цены всё так же велики, вобщем грусть, да печаль. :) зато можно dmvpn на e-tolken'ах городить и pvdm dsp с e1 портами втыкать и плясать от счастья «сколько всего в одной коробчонке». :)
производительность в bps с шифрованием она одна, хоть с одним туннелем, хоть с горой. разница только в том что по этому параметру и 2801 отсасывает вполне себе. толку то от этого dmvpn'а. но не спорю, фича конечно хорошая и вообще. насчет аналога у juniper не озадачивался, надо почитать.
про ip-телефонию в целом тоже весьма громко сказано и слишком широко. что имеет под этим ввиду? sip у cisco прямо скажем не очень. h323 — мертвый протокол. да и стоимость решения ip-телефонии от cisco не просто сказочная, а очень сказочная. что не устраивает в использовании для телефонии железа отдельного вендора? того же аудиокодеса. насколько помню получается ощутимо дешевле циски, а по качеству ни чуть. да и сами циски вроде как пользуют чипы того же аудиокодеса.
вообще я считаю не надо мешать все в кучу, в частности пд и войп. пускай уж каждый занимается своим делом. вся это комплексность котов в итоге вылевается и в жирную стоимость и в то что умеют много, всего и… и посредственно. :\
ну а вообще о чем собсенно спор? :)
а в филиалах вообще младшим srx нет равных за те же деньги шифрованный впн гонять. cisco отсасывает либо по производительности либо по деньгам.
никто не говорил про зоопарк и никто не говорил про меньшие деньги между прочим. равно как никто не предлагал строить сети на делинках. так что вы мимо тазика со своим патриотичным постом про cisco.
лолшто? у cisco-то и нет конкурентов? не смешите. вагон и тележка. зачастую гораздо гораздее вашей циски.
в частности в упомянутый вами sup2 легко влезет десятки ipv6 full-view таблиц. :) понятно дело со временем они могут перерасти возможности tcam'а, так же как это сделал ipv4 в свое время, но когда оно из 3.5 тыщ маршрутов превратится в что-то большее чем 250 тыщ :)
•Introduce the OSI protocol, used primarily to facilitate multivendor equipment interoperability.
•Discuss the structures and functioning of this protocol, from its introduction in the early 1980s.
мне кажется не двусмысленно нам говорят о представлении протокола OSI.
слева в оглавлении рядом есть ссылка про Internet Protocol и IPv6, рекоммендую так же открыть и прочитать.
выше товарищ eek написал «90% того что сейчас выдается за новинки ipv6 было реализовано в протоколе OSI более 25 лет назад» и весь забр ринулся с пеной у рта доказывать очевидные вещи и спорить о _ДРУГОМ_. мне до фени ваши доказательства и споры, я пытаюсь сказать что судя по приведенной ссылке на документ описан комплекс протоколов альтернативный нынешним с, возможно, и с этими 90% новинками из IPv6.
>>>>а дальше выясняется что ничего вобщем-то общего у эти OSI protocols suite кроме как OSI модели с текущим IPv4 нет ни грамма.
>>Это вообще сравнение автопарка с самокатом. Как можно стек протоколов сравнить с одним из членов стека?
я имел ввиду, конечно, сравнение сетевого уровня между тем что в OSI protocols suite и тем что в Internet Protocol.
а так то да, все они из модели OSI. но так уж у них вышло этот комплекс протоколов назвать провакационной обревиатурой OSI.
en.wikipedia.org/wiki/Iso_osi
The Open Systems Interconnection model (OSI model) is a product of the Open Systems Interconnection effort at the International Organization for Standardization.
www.cisco.com/en/US/docs/internetworking/technology/handbook/OSI-Protocols.html#wp1022362
The Open System Interconnection (OSI) protocol suite is comprised of numerous standard protocols that are based on the OSI reference model.
вам, как человеку не привыкшему читать дальше одного абзаца, есессно не заметно разницы, хотя она _уже_ есть в абревиатуре :)
читаем дальше линк про cisco и видим блоксхему со знакомыми квадратиками референсной модели OSI и вот, ортодоксальный забраюзер с улюлюканьем бежит разоблачать. :) не нужно игнорировать не понятные буквы в квадратиках, нужно прочитать про них дальше.
а дальше выясняется что ничего вобщем-то общего у эти OSI protocols suite кроме как OSI модели с текущим IPv4 нет ни грамма. ну а про общее в начале ясно написано почему оно общее. :)
OSI protocols suite может использовать в качестве канального уровноя ethernet, да. но всё что выше не очень похоже на то что вы привыкли видеть. в частности взаимодействие между канальным и сетевым уровнем осуществляется через протокол NSAP, который дает на канальном уровне адрес IDP (Initial Domain Part), а на сетевом DSP (Domain Specific Part), каждый из которых подразделяется на две и четыре подзаголовка соответственно, каждый со своей целью. как-то так, о деталях любознательныe могут прочитать сами.
да, очевидно, какие-то блоки из IPv4 были заменены здесь соответственно модели OSI, а какие были добавленны, так же в рамках модели OSI. немножко запутано и сложновато, но это оттого что я впервые читаю про него :) я еще слишком молод чтобы знать такие вещи :D
да, об IS-IS, это протокол внутренней маршрутизации основанный на индикации интерфейсов, он действительно был заимствован от сюда, а его вторая часть IS-ES выброшена на свалку истории. :(
вобщем не надо путать теплое с мягким, товарищи. модель OSI, это модель. по ней может быть создано сколько угодно протоколов, но так уж вышло что массам известен IPv4 и грядущий IPv6 :) ну и да, вы кричите «пруфлинк», дак будьте любезны читать эти самые «пруфлинки».
самый простой сценарий пенетрации NAT'а без пакетного фильтра: на устройстве в пределах direct линка с этим делинком прописать маршрут на вашу домашнюю сеть на внешний ойпи этого делинка. да, для этого надо знать внутренню подсеть, только меняете ли вы её с дефолтной? да, есть проблема с тем что исходящие из этой сети пакеты всё равно будут натиться, но ведь послать мегастрашный пакет с магическим содержимым в ваш компьютер всё равно можно.
кстати, с IPv6 вам дома не нужен роутир. а для безопасности хватит аутпоста на компьютере :) возможно в будущем получат своё развитие «бриджующие» фильтры, которые будут ставиться в разрыв и не влиять на топологию сети на канальном уровне.
все описаные для ната преимущества решаются политиками пакетнами фильтра, как было правильно замечено в статье. а профита от IPv6 в разы больше, например ваш любимые P2P будет работать не обязывая пользователя сношаться с upnp или портмаппингом.
в IPv6 я вижу плюсов гораздо больше чем минусов. а уж для конечных пользователей так вообще сплошные плюсы.
habrahabr.ru/blogs/p2p/53625/
habrahabr.ru/blogs/sysadm/82397/
habrahabr.ru/blogs/sysadm/85777/
по последней ссылке можно даже по туннелю смаршрутизировать по протоколу BGP «свой» PI/PA блок ip6 адресов. :)