По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Раньше, когда хабы еще находили применение в архитектуре сетей, анализировать трафик было очень просто. Достаточно было подключить компьютер со специальным ПО к одному из портов хаба и мы получали каждый пакет, передающийся по сети. Теперь, когда хабы не используются, а коммутаторы отправляют пакеты только на определенный порт, анализ трафика усложнился.
Однако, большинство вендоров уже давно решили эту проблему, разработав механизмы “зеркалирования” трафика. Примерами таких механизмов являются SPAN(Switch Port Analyzer) и RSPAN (Remote Switch Port Analyzer), которые используются в оборудовании Cisco Systems. Не стоит путать SPAN/RSPAN с STP (Spanning Tree Protocol) и RSTP (Rapid Spanning Tree Protocol). Несмотря на то, что оба эти протокола работают на канальном уровне модели TCP/IP, служат они совершенно разным целям.
Технологии “зеркалирования” трафика, к которым относятся SPAN и RSPAN, позволяют настроить коммутатор так, чтобы все пакеты, приходящие на один порт или группу портов коммутатора, дублировались на другом, с целью их дальнейшего анализа и мониторинга.
Нет времени объяснять!
Торопитесь? Нет времени читать матчасть? Прыгайте по ссылке ниже, тут настройка!
Пример настройки
Теория
Как можно догадаться, функциональность SPAN’а ограничена пределами только одного устройства.
Для того, что бы SPAN заработал необходимо настроить следующее:
Источник (Source). То есть откуда брать трафик для анализа.
Здесь можно указать порт коммутатора, работающий в режиме access, trunk и etherchannel, группу портов, т.е VLAN или L3 порт.
Стоит отметить, что при указании в качестве источника определенного VLAN, будет дублироваться трафик со всех портов, которые в него входят. При добавлении или исключении порта из VLAN это сразу повлияет на SPAN.
Получатель (Destination).
Здесь указывается тот порт, куда будет “зеркалироваться” трафик.
Стоит отметить, что по умолчанию будет дублироваться весь трафик, который проходит через источник. Однако, можно сконфигурировать SPAN так, чтобы отслеживались только входящие или исходящие пакеты. Пример коммутатора с настроенным SPAN приведен ниже:
Как видно из рисунка, SPAN может отслеживать только трафик проходящий через коммутатор, на котором он настроен непосредственно.
Remote SPAN (RSPAN) же позволяет производить мониторинг трафика на физически удаленных портах, через сеть коммутаторов.
Источником трафика при настройке RSPAN являются source порты, входящие в специальный RSPAN VLAN, который задается специально для каждой RSPAN – сессии. Фреймы, передающиеся в этой сессии затем, проходят процедуру тегирования по протоколу 802.1q для передачи через другие устройства, находящиеся в сети. Добравшись до коммутатора, содержащего destination порт для данной RSPAN - сессии, трафик просто зеркалируется на указанный destination порт.
Ниже приведен типовой пример сети с настроенным RSPAN:
При настройке SPAN/RSPAN должны соблюдаться следующие условия:
На одном коммутаторе может быть максимально сконфигурировано 64 destination порта
Source порт не может быть destination портом и наоборот
Для каждой SPAN/RSPAN – сессии может быть только один порт destination
При объявлении порта как destination, он может только принимать “зеркалированный” трафик, остальные функции канального уровня становятся для него недоступными
При объявлении порта, работающего в режиме switchport trunk, как source порта, трафик всех VLAN’ов, проходящих через данный порт будет отслеживаться
Если в качестве источника указан VLAN, то трафик из другого VLAN’а, настроенного на коммутаторе не попадет в SPAN
По умолчанию на destination порт не отслеживается и не передается трафик следующих протоколов, работающих на канальном уровне: CDP (Cisco Discovery Protocol), STP (Spanning Tree Protocol), (VTP) VLAN Trunking Protocol, (DTP) Dynamic Trunk Protocol и (PAgP) Port Aggregation Protocol
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях.
Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это.
На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до:
Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу).
В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения.
Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C:
[C, A, B, F], общей стоимостью 5
[C, A, D, E], общей стоимостью 6
[C, F], общей стоимостью 2
Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor:
Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу).
Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда:
Если NC LC, то тогда neighbor is downstream.
Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A?
Имеющиеся у D пути:
[D, A, C, F], общей стоимостью 5
[D, A, B, F], общей стоимостью 4
[D, E, F], общей стоимостью 3
Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA):
Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу).
Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC:
Если NC + BC LC, то сосед - это LFA.
Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее.
Модель водопада (Waterfall (or Continental Divide) Model).
Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5.
На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен.
Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае:
D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D
B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B
Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A.
Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A.
P/Q пространство
Еще одна модель, описывающая, как работают LFA, - это пространство P / Q.
Рисунок 6 иллюстрирует эту модель.
Проще всего начать с определения двух пространств.
Предполагая, что линия связи [E, D] должна быть защищена от сбоя:
Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути).
Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию.
Остальные узлы, которых может достичь E, - это пространство Q.
Рассчитайте Shortest Path Tree из D.
Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии.
Остальные узлы, которых может достичь D, находятся в пространстве P.
Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA.
Удаленные (remote) Loop-Free Alternates
Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика.
Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик.
Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети.
Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее:
Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C.
Сформируйте туннель к этому маршрутизатору.
Инкапсулируйте трафик в заголовок туннеля.
Перенаправьте трафик.
Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется.
D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.
Ваш клиент хочет перестроить свою систему IP-телефона или, возможно, впервые перейти на нее. Вы придете к нему с проприетарной системой, например, CUCM, или открытой стандартной системой, например, Asterisk? Прежде чем сделать выбор, важно не упускать сразу ни один из вариантов. Понимание всех входов и выходов каждого типа системы, а также конкретных требований вашего клиента имеет важное значение.
Давайте рассмотрим некоторые сильные и слабые стороны каждого подхода.
Положительные и отрицательные стороны открытых АТС
АТС с открытым стандартом являются решениями с открытым стеком, использующими стандартный подход - например, SIP - для передачи мультимедийных сообщений. Широко распространенные и признанные благодаря своей универсальности в использовании и гибкости, системы АТС с открытым стандартом не имеют многих недостатков для многих предприятий сегодня. Наряду с необходимыми функциями телефонии, некоторые передовые решения, также предлагают высококачественные унифицированные коммуникации из коробки. В целом системы АТС с открытым стандартом обеспечивают:
Лучшее соотношение цены и качества:
Опенсорс АТС часто ассоциируется с существенной экономией, потому что ею легко управлять, и в большинстве случаев нужно беспокоиться о небольших лицензионных сборах. По сравнению с запатентованными решениями, которые заключают вас в долгосрочные контракты на обслуживание или дорогостоящий ремонт системы, решения с открытыми стандартами могут быть более рентабельными во многих бизнес-сценариях.
Устранить риск блокировки поставщика:
Истинная ценность таких АТС заключается в возможности сочетать набор стандартных компонентов для предоставления инновационных услуг. С системой можно использовать практически любой SIP-телефон, шлюз или периферийные устройства на основе стандарта, что способствует удовлетворенности пользователей и производительности бизнеса.
Проще установить и настроить:
Если вы используете проприетаруню телефонную систему, вы, вероятно, уже знаете о трудностях, возникающих при ее установке, использовании и обслуживании. Вместо этого системы АТС открытого стандарта просты в использовании и управлении. Это может быть особенно актуально для тех, кто использует Asterisk с интуитивно понятным интерфейсом.
Совместимость и настройка:
Кастомизация очень важна для телефонных систем. И на этом этапе выигрывают АТС открытого стандарта. Относительно легко интегрироваться с другими стандартными приложениями, такими как базы данных, CRM, PMS отеля, колл-центр и другие, чтобы удовлетворить специфические потребности клиентов.
Хотя АТС с открытым стандартом, по большому счету, не имеют многих недостатков, качество всей системы сильно зависит от поставщиков и интеграторов. Некоторые, выбравшие бесплатные открытые решения утверждают, что им не хватает нужных функций, профессиональной поддержки и частых обновлений.
Положительные и отрицательные стороны проприетарной АТС
Проприетарной АТС являются «закрытой» системой, разработанной специально производителями, в комплекте с собственным брендом. Большинство проприетарных решений, таких как NEC или Panasonic, считаются относительно надежными, но менее привлекательными с финансовой точки зрения. С проприетарной системой вы получаете практически все ваше оборудование и программное обеспечение от одного поставщика, который будет поддерживать и гарантировать все, от АТС до мобильных телефонов. Таким образом, некоторые из преимуществ включают в себя:
Единый пользовательский опыт:
В большинстве случаев проприетарные системы предлагают единый пользовательский интерфейс. Вся система VoIP остается согласованной для всех совместимых аппаратных и программных приложений. Таким образом, вы можете ожидать аналогичного и знакомого взаимодействия с каждым устройством.
Поддержка производителя:
Благодаря проприетарной системе ваш поставщик имеет единоличный контроль над обновлениями, обновлениями и модификациями. Как следствие, вы, как торговый посредник или дистрибьютор, могли бы иметь больший контроль над клиентами, но вам нужно будет вкладывать больше ресурсов в освоение сложных запатентованных систем и интерфейсов для лучшей поддержки клиентов.
Наряду с преимуществами проприетарного решения, есть некоторые недостатки, которыми нельзя пренебрегать. Самые большие из них могут быть связаны с затратами, риском блокировки поставщиков и ограниченной гибкостью. Многие запатентованные продукты могут функционировать должным образом только при использовании с другими продуктами того же производителя. Другими словами, вы, скорее всего, будете заложниками проприетарных мобильных телефонов и периферийных устройств, которые могут быть переоценены с ограниченной функциональностью, что приведет к негативным последствиям в процессе продаж.
Еще одна важная вещь, которую следует помнить, это то, что с проприетарной системой АТС вы не сможете достичь того же уровня гибкости, что и решения с открытыми стандартами. Поскольку проприетарные решения обычно не допускают обходных путей для разработчиков, специфичных для данной проблемы, скорее всего, вы не сможете реализовать наименьшие изменения, необходимые для лучшей адаптации решения к потребностям вашего бизнеса. И когда возникают сложные проблемы, ваш поставщик является вашей единственной резервной копией.
Предвидение: бизнес-экосистема и возможности
В условиях постоянно расширяющегося горизонта и достижений на рынке VoIP ключом к тому, чтобы телефонная система оставалась впереди, было стремление идти в ногу с рыночными тенденциями и предлагать жизнеспособные решения, чтобы вписаться в более широкий спектр потребностей клиентов. И нельзя отрицать, что решения открытых стандартов имеют конкурентные преимущества.
Роль собственности как первичного новатора на рынке ушла на второй план. Распространенность промышленных открытых стандартов, таких как SIP и телефония с открытым исходным кодом, таких как Asterisk, произвела революцию в экосистеме и принесла больше возможностей для бизнеса.
Используя коллективные усилия огромного мирового сообщества экспертов, новые непатентованные, то есть открытые, системы набирают обороты. Они приносят преимущества, связанные с открытым SIP и открытым исходным кодом: стабильность, быстрое развитие, гибкость и, самое главное, экономия затрат.
Благодаря постоянно развивающимся решениям открытого стандарта пользователям теперь предоставляется больше свободы для взаимодействия нескольких приложений и интеграции систем данных. Интеграторы все чаще хотят их, а конечные пользователи требуют от них более высокого уровня соотношения цена-качество и устранения риска привязки к поставщику.
Итого
И проприетарные, и открытые стандартные системы имеют свои явные преимущества. Важно знать своих клиентов и понимать их потребности. Сколько они могут позволить себе новую телефонную систему? Какой уровень гибкости и настройки они требуют? Есть ли у них собственный опыт по обслуживанию системы? Задавая правильные вопросы, вы сможете сделать выбор, чтобы предложить наилучшее решение.