Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
впринципе все это уже знал кроме некоторых мелочей, но статейка полезная, для начинающих ccna-щиков…
Это если у нас какой-то VPN есть, разве что.
Бывает, что они вынуждены использовать одинаковые маршруты. Но это большая тема. Смотря, какой VoIP (операторский/корпоративный) и какая структура сети.
защита отсутствием маршрутов — что-то новое :) ACL тут намного логичнее, имхо
Там где ставится обычно экспресс — это не нужно вообще.
А если сеть реально большая, лучше ставить под ссме отдельный раутер и не грузить его вообще обычным сетевым трафиком.
Кроме того, с точки зрения циски inter-vlan роутинг вообще было бы правильнее делать на L3 коммутаторах, а запрещающие ACL помещать как можно ближе к источнику трафика (юзерам), т.е. либо на L2 свичах, либо если аксес у нас «тупой» — на L3 свичах.
А ССМЕ через VRF для изоляции голосового трафика, это, извините, изврат полный.
А если сеть реально большая, лучше ставить под ссме отдельный раутер и не грузить его вообще обычным сетевым трафиком.
Кроме того, с точки зрения циски inter-vlan роутинг вообще было бы правильнее делать на L3 коммутаторах, а запрещающие ACL помещать как можно ближе к источнику трафика (юзерам), т.е. либо на L2 свичах, либо если аксес у нас «тупой» — на L3 свичах.
А ССМЕ через VRF для изоляции голосового трафика, это, извините, изврат полный.
Кстати говоря, ACL-а достаточно одного независимо от кол-ва прочих сетей.
на роутере с СМЕ:
interface fa 0/0.10
ip access group voice-out out
ip access-list exteded voice-out
permit ip 192.168.1.1 0.0.0.0 192.168.0.0 0.0.0.255
на роутере с СМЕ:
interface fa 0/0.10
ip access group voice-out out
ip access-list exteded voice-out
permit ip 192.168.1.1 0.0.0.0 192.168.0.0 0.0.0.255
На in его надо вешать у источника трафика. В данном случае, на свичах.
2960 этот функционал есть и вполне работает:
2960-PoE(config)#interface FastEthernet0/1
2960-PoE(config-if)#ip access-group?
IP access list (standard or extended)
IP expanded access list (standard or extended)
WORD Access-list name
На дешевейших аксесных СЕ500 тоже.
Кстати, ZBF тоже решает данную задачу и, по моему, является рекомендуемым циской способом фильтрации трафика на данном уровне устройств.
По этому поводу, правда, могу гнать, т.к. безопасностью не занимаюсь.
2960 этот функционал есть и вполне работает:
2960-PoE(config)#interface FastEthernet0/1
2960-PoE(config-if)#ip access-group?
IP access list (standard or extended)
IP expanded access list (standard or extended)
WORD Access-list name
На дешевейших аксесных СЕ500 тоже.
Кстати, ZBF тоже решает данную задачу и, по моему, является рекомендуемым циской способом фильтрации трафика на данном уровне устройств.
По этому поводу, правда, могу гнать, т.к. безопасностью не занимаюсь.
Блин, новый редактор глючный, сам отправил коммент.
В моем примере 192.168.1.0/24 — голосовая сеть, ACL по умолчанию имеет в конце Implicit deny, то есть от пропускается трафик только от самого роутера к телефонам, весь остальной дропается.
Profit.
В моем примере 192.168.1.0/24 — голосовая сеть, ACL по умолчанию имеет в конце Implicit deny, то есть от пропускается трафик только от самого роутера к телефонам, весь остальной дропается.
Profit.
Не факт что это оплошность. Трафик от пользовательских машин до голосового роутера приходится разрешать для:
1) работы софтфонов на клиентских компах;
2) доступ на веб-рожу CCMЕ для юзеров (можно правда повесить на другой адрес, но это не всегда удобно);
3) доступ на веб-рожу голосовой почты Unity Express;
1) работы софтфонов на клиентских компах;
2) доступ на веб-рожу CCMЕ для юзеров (можно правда повесить на другой адрес, но это не всегда удобно);
3) доступ на веб-рожу голосовой почты Unity Express;
бросьте, ACL давно в железе и никого не напрягает. и добавить правила в ACL не сложнее, чем добавить VRFы, особенно если начнется схема с их пересечением
поддержу дискуссию и поправлю автора:
После этого свич по CDP передаст телефону номер его VLAN и он сможет помечать фреймы правильным тегом.
свич не передает по cdp ничего телефону. вообще cdp протокол информативный.
на самом деле свич «говорит» телефону весь голосовой трафик засунуть в влан который вы укажете.
После этого свич по CDP передаст телефону номер его VLAN и он сможет помечать фреймы правильным тегом.
свич не передает по cdp ничего телефону. вообще cdp протокол информативный.
на самом деле свич «говорит» телефону весь голосовой трафик засунуть в влан который вы укажете.
Не соглашусь с Вами, как говорит нам тот-таки Джереми Чара и Co в CCNA Voice Official Exam Certification Guide:
Keep in mind that Cisco IP phones will be able to receive voice VLAN configuration from the switch via CDP. Once it has received the voice VLAN number, the IP phone will begin tagging its own packets.
Keep in mind that Cisco IP phones will be able to receive voice VLAN configuration from the switch via CDP. Once it has received the voice VLAN number, the IP phone will begin tagging its own packets.
И вот тут еще есть много по теме:
www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.1_19_ea1/configuration/guide/swvoip.html
www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.1_19_ea1/configuration/guide/swvoip.html
А почему на маршрутизаторе с DHCP не сделать subinterface пропустить 10 vlan на него и раздавать адреса без ip helper!?
Не кошерно — транк до DHCP будет забиваться высокоприоритетным VoIP трафиком. По концепту там подключение к branch offices или еще чему-то важному.
а до маршрутизатора, транки не будут забиваться высокоприоритетным VoIP трафиком?
Да какого маршрутизатора?
До любого:)
До CME этот рафик должен попасть, в этом суть Communication Manager Express :) Потому этот транк не забивается, а используется по назначению. Как и все транки между телефонами и CME, всю массу которых здесь символизирует линк SwitchA — SwitchB.
Смысл в том, что конечный канал от свитчей к пользовательским компьютерам все равно будет забит.
Там линк минимум в 100 Мб/с на одного человека, ему-то как раз бродкасты не страшны, что Вы :-)
Я Вам по секрету скажу: так работают все операторы, с VoIP в едином VLAN для каждой из aggregation-access сети.
Aggregation-access сеть — это обчно два каких-то 6509 каталиста (aggregation), которые подключены к двух PE роутерам (за ними начинается core), и много-много access свичей 2 уровня. Так вот, на всем этом сегменте весь VoIP идет по единому VLAN.
Я Вам по секрету скажу: так работают все операторы, с VoIP в едином VLAN для каждой из aggregation-access сети.
Aggregation-access сеть — это обчно два каких-то 6509 каталиста (aggregation), которые подключены к двух PE роутерам (за ними начинается core), и много-много access свичей 2 уровня. Так вот, на всем этом сегменте весь VoIP идет по единому VLAN.
Подождите, VoIP трафик не гуляет только по каналу между маршрутизатором и коммутатором ядра, я правильно понимаю?
Суть иллюстрации в этом смысле в том, что VoIP трафик гуляет только по пути до CME. А дальше, поскольку нам надо этим телефонам выдать адреса, от CME мы используем helper-address.
Транки между SwitchA и SwitchB символизируют путь VoIP трафика через сеть.
DHCP Server и Branch Offices cloud символизируют ту часть сети, куда VoIP трафик пускать нельзя, но откуда телефончикам может что-то понадобиться.
Транки между SwitchA и SwitchB символизируют путь VoIP трафика через сеть.
DHCP Server и Branch Offices cloud символизируют ту часть сети, куда VoIP трафик пускать нельзя, но откуда телефончикам может что-то понадобиться.
Нет, не так. По многим причинам:
1. VoIP трафик должен добираться до CME — это обязательно, в этом суть.
2. CME форвардит до DHCP Server только DHCP запросы — доля трафика ничтожна, пропускная способность линка CME — DHCP Server не забивается совершенно.
3. Если создать на DHCP Server сабинтерфейс для VoIP VLAN, тогда в этот транк полетят все бродкасты из VoIP сети, и полетят с высшим приоритетом. Это есть очень плохо.
4. Здесь предполагается чистый access, все свичи 2 уровня. Кроме того, там, где это только можно, всегда нужно обходиться коммутацией, не используя маршрутизацию. Потому что производительность. Суть двух свичей — изобразить какую-то инфраструктуру 2 уровня (в жизни таких свичей может быть и 2, и 5), связывающую VoIP телефоны с CME.
Далее:
1. VoIP трафик должен добираться до CME — это обязательно, в этом суть.
2. CME форвардит до DHCP Server только DHCP запросы — доля трафика ничтожна, пропускная способность линка CME — DHCP Server не забивается совершенно.
3. Если создать на DHCP Server сабинтерфейс для VoIP VLAN, тогда в этот транк полетят все бродкасты из VoIP сети, и полетят с высшим приоритетом. Это есть очень плохо.
4. Здесь предполагается чистый access, все свичи 2 уровня. Кроме того, там, где это только можно, всегда нужно обходиться коммутацией, не используя маршрутизацию. Потому что производительность. Суть двух свичей — изобразить какую-то инфраструктуру 2 уровня (в жизни таких свичей может быть и 2, и 5), связывающую VoIP телефоны с CME.
Далее:
Э-э-э… Дело в том, что я тут описывал особенности реализации именно VoIP сети на VLAN и DHCP. А Вы, похоже, решили применить к ней общие принципы из курса CCNA. Это не правильно, там своих фич куча целая.
> Про это был не в курсе, но разве на cisco phone нельзя задать куда конектиться? default-gateway то все-таки выдан.
Ему нужно задать IP адрес Communication Manager (Express). Так что главное, чтобы с этим самым CM(E) была связь на уровне IP пакетов. Потому — хоть в другую сеть помещайте, хоть на другой конец планеты, но только учитывайте, что для VoIP пакетов максимально допустимой задержкой является 150 мс.
> Я про subinterface идею и не продвигал. Я говорю о SVI на SwichA c ip helper-address на нем — соответственно в строну DHCP пойдет unicast. Как раз по вашей схеме boradcast с SwitchB и летит на CME с бешеной скоростью.
Я ж о концепции писал, а не о конкретной схеме. А если свичей с телефонами 5? На каждом свой VLAN с SVI поднимать?
Кроме того, SVI — это третий уровень. Не используйте его там, где можете использовать коммутацию :)
> Я так понимаю что access это SwitchB, а SwitchA это distribution, раз с него идет линк на branch. Ведь если появиться SwitchC на который нужно будет выводить сеть и трубки то вы его к SwitchA будете подключать? Значит L3 на SwitchA все-таки нормально. Как раз на SwitchA можно сагрегировать все сетки и отдать их на CME.
:)
Повторяю, это все layer 2 свичи.
> Про это был не в курсе, но разве на cisco phone нельзя задать куда конектиться? default-gateway то все-таки выдан.
Ему нужно задать IP адрес Communication Manager (Express). Так что главное, чтобы с этим самым CM(E) была связь на уровне IP пакетов. Потому — хоть в другую сеть помещайте, хоть на другой конец планеты, но только учитывайте, что для VoIP пакетов максимально допустимой задержкой является 150 мс.
> Я про subinterface идею и не продвигал. Я говорю о SVI на SwichA c ip helper-address на нем — соответственно в строну DHCP пойдет unicast. Как раз по вашей схеме boradcast с SwitchB и летит на CME с бешеной скоростью.
Я ж о концепции писал, а не о конкретной схеме. А если свичей с телефонами 5? На каждом свой VLAN с SVI поднимать?
Кроме того, SVI — это третий уровень. Не используйте его там, где можете использовать коммутацию :)
> Я так понимаю что access это SwitchB, а SwitchA это distribution, раз с него идет линк на branch. Ведь если появиться SwitchC на который нужно будет выводить сеть и трубки то вы его к SwitchA будете подключать? Значит L3 на SwitchA все-таки нормально. Как раз на SwitchA можно сагрегировать все сетки и отдать их на CME.
:)
Повторяю, это все layer 2 свичи.
SVI интерфейс тут — это неправтичное решение по следующим соображениям: поднимая SVI мы выигрываем в DHCP запросах, посылаемых один раз в день (неделю-месяц-год).
И мы проигрываем в следующем:
1. Весь RTP трафик теперь обрабатывается на 3 уровне, что выливается в дополнительную задержку + нагрузку на оборудование
2. Мы или отказываемся от мультикастов вообще (пока конференции и moh, привет забитые каналы и транки), или ищем где-то свич 3 уровня с достаточным нам мультикастом т покупаем его за дохренище (в сравнении с L2) денег.
Я там чуть выше писал уже: крупный оператор в одной их жарких стран, топология aggregation-access сети следующая:
Сервисы, предоставляемые через сеть: Triple Play (Internet, Voice, Video).
И мы проигрываем в следующем:
1. Весь RTP трафик теперь обрабатывается на 3 уровне, что выливается в дополнительную задержку + нагрузку на оборудование
2. Мы или отказываемся от мультикастов вообще (пока конференции и moh, привет забитые каналы и транки), или ищем где-то свич 3 уровня с достаточным нам мультикастом т покупаем его за дохренище (в сравнении с L2) денег.
Я там чуть выше писал уже: крупный оператор в одной их жарких стран, топология aggregation-access сети следующая:
Сервисы, предоставляемые через сеть: Triple Play (Internet, Voice, Video).
Пардон, не дописал, к топологии:
Access свичей типа C4506 намного больше, они формируют кольца с C4924 (Metro Ethernet).
Весь VoIP трафик на всех кольцах идет по единому VLAN. На C4924 настроены SVI с helper-address.
Поверьте, эти ребята знают, как строить сети :)
Access свичей типа C4506 намного больше, они формируют кольца с C4924 (Metro Ethernet).
Весь VoIP трафик на всех кольцах идет по единому VLAN. На C4924 настроены SVI с helper-address.
Поверьте, эти ребята знают, как строить сети :)
Я чего-то, видимо, не понимаю просто…
С какой целью в приведенной в посте схеме поднимать SVI на SwitchA? Где выигрыш? Ради чего Вы готовы пожертвовать latency, мультикастами и деньгами?
С какой целью в приведенной в посте схеме поднимать SVI на SwitchA? Где выигрыш? Ради чего Вы готовы пожертвовать latency, мультикастами и деньгами?
А, кажется, понял Вас, вы предлагаете default gateway для телефонов таки оставить сабинтерфейс CME, верно?
Тогда с третьим пунктом согласен, но
1. dhcp broadcast туда ходит раз в день-неделю-месяц. Выигрыш ничтожен.
2. Data из филиалов и так не ходет через CME, она маршрутизируется DHCP Server.
Фактически, мы меняем L2 коммутатор на L3 только ради бродкастов. Они столько долларов не стоят :-)
Кстати, не совсем уверен, что при включении layer 3 режима трафик, идущий по VLAN с SVI, но не имеющий в destination address значения IP SVI, будет коммутироваться ACIS, а не пойдет через routing plan.
То есть, хопа не будет, но не будет ли задержки во времени — не могу так сразу что-то утверждать.
Тогда с третьим пунктом согласен, но
1. dhcp broadcast туда ходит раз в день-неделю-месяц. Выигрыш ничтожен.
2. Data из филиалов и так не ходет через CME, она маршрутизируется DHCP Server.
Фактически, мы меняем L2 коммутатор на L3 только ради бродкастов. Они столько долларов не стоят :-)
Кстати, не совсем уверен, что при включении layer 3 режима трафик, идущий по VLAN с SVI, но не имеющий в destination address значения IP SVI, будет коммутироваться ACIS, а не пойдет через routing plan.
То есть, хопа не будет, но не будет ли задержки во времени — не могу так сразу что-то утверждать.
Не кошерно — транк до DHCP будет забиваться высокоприоритетным VoIP трафиком. По концепту там подключение к branch offices или еще чему-то важному.
При использовании стороннего(на циске) dhcp сервера в сети AD придется на DNS серверах включать небезопасное обновление. Не вариант.
Посему лично я использую цисковский dhcp только для железок (телефоны, базы ipdect wifi и т.п.) в бранчах.
Да и если уж делать в центре dhcp сервер на циске то не на бордере(обозначен как DHCP сервер ) а в ядре (SwitchA).
Посему лично я использую цисковский dhcp только для железок (телефоны, базы ipdect wifi и т.п.) в бранчах.
Да и если уж делать в центре dhcp сервер на циске то не на бордере(обозначен как DHCP сервер ) а в ядре (SwitchA).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VLAN + DHCP + VoIP = Cisco