VLAN + DHCP + VoIP = Cisco

    В продолжение темы настройки DHCP на оборудовании Cisco с учетом VLAN, предлагаю рассмотреть вопрос вглубь: давайте скрестим описанный функционал с VoIP технологией. Что если мы решили внедрить в нашу сеть VoIP со всеми вытекающими последствиями: отдельным устройством с Communication Manager Express, VoIP телефонами и необходимостью приоретизации трафика?



    Для начала коротко об изображенной здесь архитектуре Cisco VoIP. Начнем с телефонов. В VoIP телефоны Cisco встроен минисвич на два порта, который позволяет подключить телефон к розетке, а компьютер к телефону. Этим мы экономим розетки и порты на свиче, но этим же и создаем себе дополнительную проблему: VoIP трафик должен быть изолирован от трафика, предназначенного компьютеру. Во имя приоретизации, что для VoIP критично, и безопасности.

    Для решения этой проблемы Cisco использует, говоря заумными словами, технологию 802.1q транков, а проще – VLAN. VoIP телефон добавляет в свой трафик тег, по которому свич распознает, что фрейм принадлежит VoIP трафику, и ему надо оказать особое внимание.
    На портах свича предусмотрен отдельная команда, чтобы задать VLAN для телефона, который подключен к нему. Теперь настройка порта будет выглядеть вот так:
    interface FastEthernet0/1
     switchport mode access
     switchport access vlan 50
     switchport voice vlan 10

    После этого свич по CDP передаст телефону номер его VLAN и он сможет помечать фреймы правильным тегом.

    «Ага, — скажет внимательный и хитрый читатель, — но ведь весь VoIP трафик всей сети сконцентрирован в одном VLAN? Значит, наш компьютер может отключить телефон, прикинуться им и слушать все разговоры по сети?»

    «И зачем вообще этот костыль c switchport voice vlan? – спросит внимательный и умный читатель, — ведь можно настроить порт на свиче как trunk, указав ему allowed vlan 10 и native vlan 50?»

    Ответ на оба эти вопроса один: Cisco предусмотрела механизм, который не позволяет чужому устройству прикинуться VoIP телефоном. Именно этот механизм включается командой switchport voice vlan. Второй внимательный читатель прав, его конфигурация верна и будет работать, но она сделает правым и первого внимательного читателя. А этого нам совершенно не нужно.

    Детальный рассказ про механизм Voice VLAN – это тема для отдельного поста. Те, кто заинтересовался и хочет узнать о нем прямо сейчас, могут почитать об этом на сайте Циско и, кто знает, может, в процессе заинтересоваться еще чем-то из цисковского VoIP.

    Но вернемся к нашей задаче. В IP адресе нуждаются не только рабочие станции, но и IP телефоны. Однако доступ к DHCP серверу имеют только устройства из VLAN 50, то есть, компьютеры. Что же делать телефонам?

    А для телефонов мы используем два интересных механизма DHCP: команду helper-address и принцип, по которому DHCP выделяет адреса.

    Настроим сам DHCP сервер на маршрутизаторе с двумя пулами:
    ip dhcp pool VOICE
     network 172.16.1.0 /24
     default-router 172.16.1.1
     dns-server 4.2.2.2

    Команда network в настройке DHCP на Циско – одна из немногих, где мы можем задать маску подсети через слеш. А можем и вовсе не задавать, тогда она будет определена автоматически, в зависимости от класса сети.
    Команда default-router задает шлюз по умолчанию для сети, а dns-server – соответственно, DNS сервер. 4.2.2.2 – это адрес публичного NDS сервера, который поддерживается университетом Беркли, и является надежной альтернативой, если по какой-то причине вы не доверяете DNS вашего провайдера.
    Буквально парой предложений про еще одну особенность DHCP в VoIP: с его помощью телефоны получают адрес TFTP сервера, на котором хранится образ операционной системы для них. Эта функциональность известна как опция 150 и задается командой:
    option 150 ip 'TFTP server IP address'

    Если углубляться в DHCP еще больше, то все функции этого замечательного протокола являют собой опции. Так, шлюз по умолчанию можно задать как default-router, а можно как option 3. Под такими опциями скрыто множество интересной дополнительной функциональности, которая, к сожалению, тоже в один пост не поместится.

    Все-все, уже заканчиваю отвлекаться: таким же образом настроим пул IP адресов для рабочих станций:
    ip dhcp pool DATA
     network 172.16.2.0 /24
     default-router 172.16.2.1
     dns-server 4.2.2.2

    Дальше идем на сабинтерфейсы CME роутера (предполагаю, что вы знакомы с маршрутизацией между VLAN и уже настроили их самостоятельно). Все широковещательные пакеты, при помощи которых наши телефоны будут обращаться к широкой общественности: «эй, кто здесь DHCP сервер, мне нужен IP адрес» придут на сабинтерфейс Fa0/0.10 – потому что телефоны находятся во VLAN 10. Тут бы этим крикам о помощи и погибнуть – в VLAN 10 нет DHCP сервера – но это не выход. Выход – команда ip helper-address:
    interface FastEthernet0/0.10
     ip helper-address 172.16.2.5

    Этой командой мы говорим CME маршрутизатору: когда ты получаешь широковещательный DHCP пакет, отправляй его DHCP серверу по адресу 172.16.2.5. Этот сервер ответит тебе, и тогда ты передашь его тому, кто прислал тебе запрос.

    «Подождите, — скажут наши внимательные читатели, — но ведь телефоны передают широковещательными пакетами «эй, дай нам IP адрес» точно так же, как и компьютеры – все эти устройства не имеют адресов. Как DHCP сервер узнает, что телефонам он доложен выдавать адреса из пула VOICE, а компьютерам – из пула DATA?”

    Тут мы подходим ко второму интересному моменту: на самом деле DHCP сервер не знает. Если бы все телефоны и компьютеры были в одном VLAN, он бы сказал: «Я не знаю, кто вы такие. Все ваши запросы пришли ко мне через интерфейс 172.16.2.5, потому я выдам всем вам адреса из сети, к которой относится этот интерфейс, то есть 172.16.2.0/24».

    Но мы использовали helper-address! Смотрите, как это работает сейчас: компьютеры шлют запрос «эй, дай мне IP адрес». Запрос попадает к DHCP серверу через интерфейс 172.16.2.5 – сервер находится в том же VLAN, что и компьютеры. И он выдает им адреса из сети 172.16.2.0/24 – нашего DATA пула. Но широковещательные пакеты телефонов идут в другом VLAN. Они приходят на сабинтерфейс Fa0/0.10, который для них является шлюзом по умолчанию, и CME шлет их на ip helper-address — 172.16.2.5.

    И когда CME пересылает запросы телефонов, он не посылает их как broadcast. Он шлет их как unicast. А unicast IP пакет имеет адреса источника и получателя. И в нашем случае IP адресом источника DHCP запроса будет адрес сабинтерфейс Fa0/0.10, потому что там эти фреймы впервые вышли на третий уровень, там они впервые вообще узнали, что в мире бывают IP адреса!

    Итак, DHCP сервер получает unicast запрос, source address которого значится 172.16.1.1. «Ага, — говорит сервер, — значит, источник запроса имеет связь с этим адресом. Значит, надо выдавать ему IP адрес из сети, к которой этот адрес относится». И отвечает на запрос выдачей адреса из сети 172.16.1.1/24 – нашого VOICE пула!

    Таким образом, мы получаем как раз то, что хотели: все наши телефоны получили IP адреса из нужной подсети, они изолированы от VLAN с данными и имеют связь только с CME, который может соединять их с другими телефонами через PSTN или VoIP посредством Интернет. Компьютеры же получили адреса из другой сети, они теперь могут обмениваться данными с филиалами компании, server farm или чем угодно еще. Мы получили гибкую в настройке сеть, возможность приоретизации трафика на втором и третьем уровне и экономию пропускной способности и ресурсов за счет использования одного DHCP сервера для нескольких изолированных VLAN.

    P.S. Хочу выразить благодарность за вдохновение на этот пост и значительный пласт моих телеком-знаний несравненному Jeremy Cioara. Надеюсь, вы простите слишком вольный местами тон рассказа.

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 253 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 49

      0
      впринципе все это уже знал кроме некоторых мелочей, но статейка полезная, для начинающих ccna-щиков…
        0
        перечитал статью еще раз, вникнул в комментарии. элегантное решение. возьму на заметку.
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Это если у нас какой-то VPN есть, разве что.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Бывает, что они вынуждены использовать одинаковые маршруты. Но это большая тема. Смотря, какой VoIP (операторский/корпоративный) и какая структура сети.
                0
                защита отсутствием маршрутов — что-то новое :) ACL тут намного логичнее, имхо
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Там где ставится обычно экспресс — это не нужно вообще.
                    А если сеть реально большая, лучше ставить под ссме отдельный раутер и не грузить его вообще обычным сетевым трафиком.
                    Кроме того, с точки зрения циски inter-vlan роутинг вообще было бы правильнее делать на L3 коммутаторах, а запрещающие ACL помещать как можно ближе к источнику трафика (юзерам), т.е. либо на L2 свичах, либо если аксес у нас «тупой» — на L3 свичах.

                    А ССМЕ через VRF для изоляции голосового трафика, это, извините, изврат полный.
                      0
                      Кстати говоря, 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
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          На 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 тоже решает данную задачу и, по моему, является рекомендуемым циской способом фильтрации трафика на данном уровне устройств.
                          По этому поводу, правда, могу гнать, т.к. безопасностью не занимаюсь.
                          • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Блин, новый редактор глючный, сам отправил коммент.

                          В моем примере 192.168.1.0/24 — голосовая сеть, ACL по умолчанию имеет в конце Implicit deny, то есть от пропускается трафик только от самого роутера к телефонам, весь остальной дропается.
                          Profit.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Не факт что это оплошность. Трафик от пользовательских машин до голосового роутера приходится разрешать для:
                              1) работы софтфонов на клиентских компах;
                              2) доступ на веб-рожу CCMЕ для юзеров (можно правда повесить на другой адрес, но это не всегда удобно);
                              3) доступ на веб-рожу голосовой почты Unity Express;

                              • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          бросьте, ACL давно в железе и никого не напрягает. и добавить правила в ACL не сложнее, чем добавить VRFы, особенно если начнется схема с их пересечением
                          • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    поддержу дискуссию и поправлю автора:

                    После этого свич по CDP передаст телефону номер его VLAN и он сможет помечать фреймы правильным тегом.
                    свич не передает по cdp ничего телефону. вообще cdp протокол информативный.

                    на самом деле свич «говорит» телефону весь голосовой трафик засунуть в влан который вы укажете.
                      0
                      Не соглашусь с Вами, как говорит нам тот-таки Джереми Чара и 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.

                        0
                          0
                          да о печатался получается :). в заблуждение ввело что у меня другого вндора телефоны. и они работают. естественно cdp не знают они…
                            0
                            Да, в этом плюс чисто цисковской сети — много всякого проприетарного :-)
                      0
                      А почему на маршрутизаторе с DHCP не сделать subinterface пропустить 10 vlan на него и раздавать адреса без ip helper!?
                        0
                        Не кошерно — транк до DHCP будет забиваться высокоприоритетным VoIP трафиком. По концепту там подключение к branch offices или еще чему-то важному.
                          0
                          а до маршрутизатора, транки не будут забиваться высокоприоритетным VoIP трафиком?
                            0
                            Да какого маршрутизатора?
                              0
                              До любого:)
                                0
                                До CME этот рафик должен попасть, в этом суть Communication Manager Express :) Потому этот транк не забивается, а используется по назначению. Как и все транки между телефонами и CME, всю массу которых здесь символизирует линк SwitchA — SwitchB.
                                  0
                                  Смысл в том, что конечный канал от свитчей к пользовательским компьютерам все равно будет забит.
                                    0
                                    Там линк минимум в 100 Мб/с на одного человека, ему-то как раз бродкасты не страшны, что Вы :-)

                                    Я Вам по секрету скажу: так работают все операторы, с VoIP в едином VLAN для каждой из aggregation-access сети.

                                    Aggregation-access сеть — это обчно два каких-то 6509 каталиста (aggregation), которые подключены к двух PE роутерам (за ними начинается core), и много-много access свичей 2 уровня. Так вот, на всем этом сегменте весь VoIP идет по единому VLAN.
                                      0
                                      Подождите, VoIP трафик не гуляет только по каналу между маршрутизатором и коммутатором ядра, я правильно понимаю?
                                        0
                                        Суть иллюстрации в этом смысле в том, что VoIP трафик гуляет только по пути до CME. А дальше, поскольку нам надо этим телефонам выдать адреса, от CME мы используем helper-address.

                                        Транки между SwitchA и SwitchB символизируют путь VoIP трафика через сеть.

                                        DHCP Server и Branch Offices cloud символизируют ту часть сети, куда VoIP трафик пускать нельзя, но откуда телефончикам может что-то понадобиться.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Нет, не так. По многим причинам:

                              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.
                              Далее:
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Э-э-э… Дело в том, что я тут описывал особенности реализации именно 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 свичи.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      SVI интерфейс тут — это неправтичное решение по следующим соображениям: поднимая SVI мы выигрываем в DHCP запросах, посылаемых один раз в день (неделю-месяц-год).

                                      И мы проигрываем в следующем:

                                      1. Весь RTP трафик теперь обрабатывается на 3 уровне, что выливается в дополнительную задержку + нагрузку на оборудование

                                      2. Мы или отказываемся от мультикастов вообще (пока конференции и moh, привет забитые каналы и транки), или ищем где-то свич 3 уровня с достаточным нам мультикастом т покупаем его за дохренище (в сравнении с L2) денег.

                                      Я там чуть выше писал уже: крупный оператор в одной их жарких стран, топология aggregation-access сети следующая:



                                      Сервисы, предоставляемые через сеть: Triple Play (Internet, Voice, Video).

                                        0
                                        Пардон, не дописал, к топологии:
                                        Access свичей типа C4506 намного больше, они формируют кольца с C4924 (Metro Ethernet).

                                        Весь VoIP трафик на всех кольцах идет по единому VLAN. На C4924 настроены SVI с helper-address.

                                        Поверьте, эти ребята знают, как строить сети :)
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Я чего-то, видимо, не понимаю просто…

                                            С какой целью в приведенной в посте схеме поднимать SVI на SwitchA? Где выигрыш? Ради чего Вы готовы пожертвовать latency, мультикастами и деньгами?
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1
                                                А, кажется, понял Вас, вы предлагаете default gateway для телефонов таки оставить сабинтерфейс CME, верно?

                                                Тогда с третьим пунктом согласен, но

                                                1. dhcp broadcast туда ходит раз в день-неделю-месяц. Выигрыш ничтожен.
                                                2. Data из филиалов и так не ходет через CME, она маршрутизируется DHCP Server.

                                                Фактически, мы меняем L2 коммутатор на L3 только ради бродкастов. Они столько долларов не стоят :-)

                                                Кстати, не совсем уверен, что при включении layer 3 режима трафик, идущий по VLAN с SVI, но не имеющий в destination address значения IP SVI, будет коммутироваться ACIS, а не пойдет через routing plan.

                                                То есть, хопа не будет, но не будет ли задержки во времени — не могу так сразу что-то утверждать.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Не кошерно — транк до DHCP будет забиваться высокоприоритетным VoIP трафиком. По концепту там подключение к branch offices или еще чему-то важному.
                              0
                              При использовании стороннего(на циске) dhcp сервера в сети AD придется на DNS серверах включать небезопасное обновление. Не вариант.

                              Посему лично я использую цисковский dhcp только для железок (телефоны, базы ipdect wifi и т.п.) в бранчах.

                              Да и если уж делать в центре dhcp сервер на циске то не на бордере(обозначен как DHCP сервер ) а в ядре (SwitchA).

                                0
                                Это исключительно модельная топология. Не поймите правильно, это не нечто реально существующее, это придумано, и придумано исключительно с целью акцентировать внимание на технологии.

                                В этой модели мы предполагаем, что обв свича у нас layer 2.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое