В продолжение темы настройки DHCP на оборудовании Cisco с учетом VLAN, предлагаю рассмотреть вопрос вглубь: давайте скрестим описанный функционал с VoIP технологией. Что если мы решили внедрить в нашу сеть VoIP со всеми вытекающими последствиями: отдельным устройством с Communication Manager Express, VoIP телефонами и необходимостью приоретизации трафика?
Для начала коротко об изображенной здесь архитектуре Cisco VoIP. Начнем с телефонов. В VoIP телефоны Cisco встроен минисвич на два порта, который позволяет подключить телефон к розетке, а компьютер к телефону. Этим мы экономим розетки и порты на свиче, но этим же и создаем себе дополнительную проблему: VoIP трафик должен быть изолирован от трафика, предназначенного компьютеру. Во имя приоретизации, что для VoIP критично, и безопасности.
Для решения этой проблемы Cisco использует, говоря заумными словами, технологию 802.1q транков, а проще – VLAN. VoIP телефон добавляет в свой трафик тег, по которому свич распознает, что фрейм принадлежит VoIP трафику, и ему надо оказать особое внимание.
На портах свича предусмотрен отдельная команда, чтобы задать VLAN для телефона, который подключен к нему. Теперь настройка порта будет выглядеть вот так:
После этого свич по 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 сервер на маршрутизаторе с двумя пулами:
Команда network в настройке DHCP на Циско – одна из немногих, где мы можем задать маску подсети через слеш. А можем и вовсе не задавать, тогда она будет определена автоматически, в зависимости от класса сети.
Команда default-router задает шлюз по умолчанию для сети, а dns-server – соответственно, DNS сервер. 4.2.2.2 – это адрес публичного NDS сервера, который поддерживается университетом Беркли, и является надежной альтернативой, если по какой-то причине вы не доверяете DNS вашего провайдера.
Буквально парой предложений про еще одну особенность DHCP в VoIP: с его помощью телефоны получают адрес TFTP сервера, на котором хранится образ операционной системы для них. Эта функциональность известна как опция 150 и задается командой:
Если углубляться в DHCP еще больше, то все функции этого замечательного протокола являют собой опции. Так, шлюз по умолчанию можно задать как default-router, а можно как option 3. Под такими опциями скрыто множество интересной дополнительной функциональности, которая, к сожалению, тоже в один пост не поместится.
Все-все, уже заканчиваю отвлекаться: таким же образом настроим пул IP адресов для рабочих станций:
Дальше идем на сабинтерфейсы CME роутера (предполагаю, что вы знакомы с маршрутизацией между VLAN и уже настроили их самостоятельно). Все широковещательные пакеты, при помощи которых наши телефоны будут обращаться к широкой общественности: «эй, кто здесь DHCP сервер, мне нужен IP адрес» придут на сабинтерфейс Fa0/0.10 – потому что телефоны находятся во VLAN 10. Тут бы этим крикам о помощи и погибнуть – в VLAN 10 нет DHCP сервера – но это не выход. Выход – команда ip helper-address:
Этой командой мы говорим 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. Надеюсь, вы простите слишком вольный местами тон рассказа.
Для начала коротко об изображенной здесь архитектуре 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. Надеюсь, вы простите слишком вольный местами тон рассказа.