Enable option125 что это

18.04.202218.04.2022 admin 0 Comments

Настройка модема HUAWEI HG8245A (H)

В одно прекрасное время в линейке модемов появилась недорогая качественная современная модель, благодаря наличию двух антенн обеспечивающая качество сигнала по всему жилищу (и как показывает практика) и за его пределами. Рассмотрим, как настроить модем HUAWEI HG8245A или HG8245H.

Подключение

Прежде всего модем нужно подключить к ПК. Это делается с помощью провода, идущего в комплекте с устройством. Один из концов подключается в порт LAN (это порт, через который идёт соединение с локальной сетью). Вторым подключаемся к компьютеру (ноутбуку).

После подключения в адресной строке запущенного браузера (любого, который есть в наличии) нужно ввести 192.168.100.1 (это IP-адрес данных модемов по умолчанию). Рекомендуются браузеры — Internet Explorer, Yandex, Firefox.

В ответ появится окно с запросом логина и пароля:

Возможные варианты для логина/пароля:

С логином «telecomadmin» возможны значения для пароля:

Или комбинация логин/пароль —root/admin (для изменения настроек только сети Wi-Fi).

Если такое окно не появляется проверяем другие данные в настройках сетевой карты:

После сверки и набора логина с паролем попадаем в меню отладки функций оптического терминала, начинаем настраивать.

Настройка

Включает в себя перемещение и установку данных по нескольким складкам (страничкам):

Вкладка WAN

Настройка модема HUAWEI HG8245A начинается с перемещения на страницу «WAN».

На ней должно быть отмечено:

Страница LAN

Настройка Wi-Fi

Настройка Wi-Fi для нашего Байфлаймодема производится из вкладки WLAN. В ней:

Устанавливаем галочку в верхней части возле «Enable WLAN»;

Дальше правее от неё нажимается «NEW»;

Поле «SSID Name» должно содержать название сети Wi-Fi;

Рядом с «Enable SSID», «Broadcast SSID» и «Enable WMM» ставятся галочки;

Значение «Number of Associated…» говорит околичестве одновременно подключенных девайсов;

Оставшиеся поля должны соответствовать картинке;

Нажатие кнопки «Apply» сохранит введённые настройки:

Ознакомившись с нашей статьёй, вы уже поняли, что настройка модема Byfly Huawei HG8245H не представляет особой сложности.

Настраивайте, оставляйте комментарии о своих успехах, делитесь ими с друзьями.

Источник

DHCP сервер на нескольких VLAN

Под термином “клиент” будем понимать зону ответственности за совокупность сетевых устройств.

Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:

Таким образом, при появлении у клиента нового устройства адрес для него будет выдан автоматически (и у нас не будет проблем из-за того, что один клиент может использовать для своих нужд единицы IP-адресов, а другому потребуются их десятки или сотни), а при добавлении нового клиента мы просто создадим еще один VLAN и добавим его в нашу общую группу. Даже если из-за большого количества клиентских устройств первоначально выделенное нами адресное пространство будет исчерпано, то мы всегда сможем его расширить, изменив настройки всего в двух местах (на DHCP-сервере и на интерфейсе, который объединяет все клиентские VLAN).

Технически описанное выше решение можно реализовать только аппаратными средствами на коммутаторах уровня L3 или программно-аппаратными средствами на коммутаторах уровня L2 (лишь бы они понимали 802.1q) и каком-либо компьютере с linux-подобной операционной системой. Так как у меня уже был сервер (являющийся, к тому же, целевым для клиентов), то логично было бы остановиться на аппаратно-программном варианте.

Итак, программируем коммутатор таким образом, чтобы на каждом клиентском VLAN был один физический порт коммутатора в “access mode”, и один общий порт в режиме 802.1q (к этому порту будет подключаться наш сервер). Подробно технология настройки не расписывается, т.к. она достаточно тривиальна и зависит от конкретной модели используемого коммутатора.

Далее приступаем к созданию конфигурации для сервера. Пусть физический интерфейс, который подключается к порту 802.1q коммутатора, имеет имя eth0. Для моей конкретной задачи понадобилось 200 клиентских VLAN с VLAN ID от 600 до 799 включительно, так что будем их создавать:

Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:

Непосредственно создаем VLAN на базе интерфейса eth0:

Создаем бридж, в который будем объединять созданные vlan:

Объединяем созданные интерфейсы в бридж:

Теперь прописываем на интерфейс br1 адрес, который будет выступать для всех наших клиентов в качестве шлюза по умолчанию:

И запрещаем трафик между клиентскими VLAN средствами ebtables:

(в данном случае используется таблица ebtables ‘filter’, запрещающая передачу трафика между интерфейсами, входящими в бридж в виде логических портов). Если все-таки необходимо разрешить возможность передачи трафика между клиентами под нашим контролем (см. п. 3 техзадания), то вместо вышеприведенного правила устанавливаем следующие:

Здесь мы работаем с таблицей ‘broute’. В ней не стандартные действия для целей ACCEPT и DROP. Цель ACCEPT разрешает форвардинг трафика с заданными условиями (т.е. трафик передается на уровне L2), а цель DROP запрещает форвардинг трафика и обеспечивает его передачу на роутинг (и, соответственно, мы сможем им управлять посредством iptables). Однако т.к. все адреса принадлежат одной IP-подсети но могут находиться в разных клиентских VLAN, на интерфейсе br1 необходимо будет разрешить arp proxy:

Замечу, что у меня не не стояло задачи пропуска трафика между клиентами, поэтому описанное выше расширение чисто умозрительное и на практике не проверялось!

Осталось только настроить сервер DHCP и поселить его на интерфейс br1. Эта операция также тривиальна, поэтому в рамках данной статьи не описывается.

Ну что, все работает? А вот как бы не так:

Здесь все нормально: получили один broadcast запрос DHCPDISCOVER, ответили одним broadcast-ответом DHCPOFFER.

А теперь давайте посмотрим, что происходит на физическом интерфейсе:

Мало того, что мы засветили всем клиентам MAC/IP адреса одного из них, так еще и вдобавок получили не хилый broadcast storm на физический коммутатор. Кстати, от такого шторма у некоторых коммутаторов просто едет крыша: работающий у нас QTECH не только не смог пропустить broadcast на все заявленные 200 клиентских VLAN (т.е. конечный клиент с произвольной вероятностью либо получал свой адрес от DHCP сервера, либо не дожидался от него вообще никакого ответа), но и даже забыл таблицу известных ему MAC-адресов (во всяком случае в консоли он показывал только один MAC-адрес для всех портов). А вот коммутатор ASOTEL справлялся с такой нагрузкой и клиенты могли получить адреса от нашего DHCP-сервера.

Ну ладно, будем исправлять ситуацию. Надо заставить сервер посылать broadcast только в тот VLAN, от которого пришел первоначальный запрос, а не размножать его по всем доступным местам.
Модуля трекинга DHCP broadcast-ов я не нашел. Как выяснилось позднее, он бы в данном случае все равно не помог, т.к. broadcast-ответ DHCP-сервером формируется при помощи системного вызова
socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IP))
который не проходит ни через одну из таблиц ebtables или iptables. Т.е. если входящие broadcast отловить еще можно, то вот ответы передаются драйверу минуя стек протоколов. И это логично: если уж мы сами формируем ethernet-заголовок, то какой смысл дополнительно обрабатывать его средствами ядра?

Для начала вспомним, что в современных linux-ядрах есть такие вкусности, как Virtual Ethernet Device (из них можно делать хорошие pipes для перегонки ethernet-трафика внутри нашего компьютера) и Network Namespace (средство для изоляции сетевого стека. В аппаратных маршрутизаторах это, обычно, называется VRF). В принципе для данной задачи можно обойтись исключительно Virtual Ethernet (veth), но для красоты решения (и упрощения связки DHCP Server — DHCP Relay Agent) будем использовать также и Network Namespace (netns).

После инициализации сети в linux по умолчанию имеется только один root netns, в котором находится единственная копия сетевого стека, таблицы маршрутизации, интерфейсы и т.п. В дальнейшем описании для определенности будем использовать следующую терминологию:
Network Namespace назовем “слоем” (layer);
root netns назовем слоем “backplate” (хотя в реальности этот netns имеет имя в виде пустой строки);

каждый клиентский VLAN добавляем в отдельный bridge, на интерфейс которого будем вешать DHCP Relay Agent. Через этот интерфейс клиенты смогут посылать broadcast-запросы агенту и принимать от него broadcast-ответы.
из каждого клиентского bridge сделаем ethernet pipe до нашего основного br1. Через связку “customer vlan”-”customer vlan bridge”-”virtual ethernet”-”br1” будет проходить полезный трафик между клиентским сервисом и общими внешними ресурсами.

Сам DHCP Relay Agent живет в одном экземпляре (он может слушать несколько клиентских интерфейсов) на специальном ethernet pipe, на другой стороне которого находится наш DHCP Server.
весь прикладной уровень (т.е. все, что не касается DHCP), расположим на уровне backplate;
все, что связано с DHCP Relay Agent, расположим на уровне с именем “relay”;
собственно сервер DHCP должен быть доступен как для DHCP Relay Agent (для обработки сообщений, распространяемых в виде broadcast и преобразуемых агентом в unicast и обратно), а также непосредственно для клиентов DHCP (для обработки специального случая: сообщения DHCPRELEASE, отправляемого unicast клиентом напрямую тому DHCP-серверу, который выдавал этот адрес).

С учетом данных требований сам DHCP-сервер расположим на уровне backplate на интерфейсе br1, но для предотвращения приема им broadcast-запросов от конечных клиентом на интерфейс будут наложены специальные фильтры.

Ну, поехали… Создаем слой “relay”

Создаем на слое backplate виртуальный pipe, предназначенный для общения DHCP Relay Agent и DHCP Server:

Переносим хвост dhcpd (интерфейс, на котором будет работать Relay Agent) в слой relay:

Настраиваем в слое relay интерфейс dhcpd:

Создаем наш основной бридж br1:

Пусть этот бридж работает как умный коммутатор (т.е. хранит у себя таблицу MAC-адресов и выполняет форвардинг на конкретный порт в зависимости от наличия на нем целевого адреса). Для этого устанавливаем время обучения равным 30 секундам:

Ну и клиенты — личности своеобразные, вполне могут и кольца сотворить. Ежели кто этим и займется, то пусть страдает сам, не затрагивая при этом других. Т.е. запустим на нашем виртуальном коммутаторе STP:

Т.к. этот бридж является также шлюзом по умолчанию для клиентов, то повесим на него IP-адрес (вместе с сеткой) и поднимем непосредственно сам интерфейс:

Добавляем в бридж интерфейс, по которому DHCP сервер будет общаться с агентом:

Запрещаем трафик между клиентскими VLAN средствами ebtables:

Запрещаем обработку DHCP-сервером broadcast-запросов (они должны вылавливаться агентом и отсылаться серверу в виде unicast):

Для подстраховки разрешаем использование адреса, выделенного для DHCP Relay Agent только на интерфейсе с именем relay:

Ладно, последний мазок. Так как я категорически не доверяю клиентам, заставим ядро убеждаться в том, что приходящие от них IP-пакеты имеют source address вида 10.12.8.0/23 (а не, к примеру, 192.168.1.1). Для этого включаем на интерфейсе rp filter:

Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:

Непосредственно создаем VLAN на базе интерфейса eth0:

Переносим созданный интерфейс vlan600 из слоя backplate в слой relay:

Поднимаем интерфейс vlan600, но уже в слое relay:

Создаем в слое relay бридж для данного клиентского VLAN (на который будем вешать DHCP Relay Agent).

Мы хотим, чтобы этот бридж работал в качестве хаба (т.е. выполнял бы трансляцию пакета сразу же после его получения, не используя период сбора информации о MAC-адресах). Для этого до момента добавления первого интерфейса в бридж устанавливаем его параметры:

Кроме того, STP на данном бридже нам явно не нужен:

Поднимаем интерфейс бриджа:

И добавляем в него клиентский VLAN:

Создаем на слое backplate (ну все равно он туда придет) ethernet pipe для связки клиентского бриджа br600 и нашего основного бриджа br1:

Переносим второй конец pipe в слой relay:

И добавляем этот конец трубы в бридж:

Ну и добавляем конец pipe, оставшийся в слое backplate, в бридж br1:

Повторяем в цикле операции создания клиентских VLAN в нужном количестве.

Теперь достаточно запустить сам DHCP сервер в слое backplate и DHCP Relay Agent в слое relay. В моем случае используется сборка из BusyBox, что в данном случае не критично. Использование ISC агента и сервера не должно вызвать больших затруднений.

Итак, запускаем агента. В качестве клиентских интерфейсов используются br600-br799, в качестве интерфейса для связи с DHCP-сервером используется интерфейс dhcpd, а сам DHCP сервер имеет адрес 10.12.8.1:

Ну и, наконец, запускаем DHCP сервер:

В файле /etc/udhcpd.conf единственная строчка, которая относится к данной схеме:

Все, теперь broadcast-запросы в пользовательском VLAN отлавливаются DHCP Relay Agent через соответствующий br-интерфейс, после чего запрос unicast-ом передается на серверу через интерфейс dhcpd. Сервер отсылает unicast-ответ через интерфейс relay, который агент получает из интерфейса dhcpd и транслирует broadcast-ом в исходный VLAN.

Клиенты стали получать адреса через DHCP, broadcast-storm исчез. И клиент может послать DHCPRELEASE непосредственно серверу на адрес 10.12.8.1

Что посмотреть к этой статье:

Источник

Enable option125 что это

Вопрос

Maybe some one can help me? i need some information how to set up DHCP option 125 on server 2008 R2 x64. I can`t find any info about it.

Ответы

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

Все ответы

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

Thank you for replay. The device that i`m using supports data and VOIP. So i need to define enterprise number: 25167, the length of the following data: 16, the sub-option code: 1, the length of the suboption content: 14 in option 125.

This is example of linux, but i need to do on server 2008:

Источник

Enable option125 что это

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Maybe some one can help me? i need some information how to set up DHCP option 125 on server 2008 R2 x64. I can`t find any info about it.

Answers

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

All replies

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

This is example of linux, but i need to do on server 2008:

Источник

Enable option125 что это

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Maybe some one can help me? i need some information how to set up DHCP option 125 on server 2008 R2 x64. I can`t find any info about it.

Answers

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

All replies

Thanks for posting here.

Technically we can add Vendor Specific DHCP option by using command ‘netsh dhcp server scope ipaddress set optionvalue 125 ’ to set the value.

TechNet Community Support

This is example of linux, but i need to do on server 2008:

Источник

Для чего мы создаем…

Enable option125 что это

Настройка модема HUAWEI HG8245A (H)

Подключение