Ярослав

По SNMP происходит )
У каждой eNodeB есть свой O&M-адрес.

А ломится туда, сводит всё в одну кучу и складывает в базу данных система управления от производителя:
- у Эриксон - OSS
- у Huawei - E2000/N2000

Да.
Логика работы та же, чего-то принципиально нового тут не придумать.
Протоколы те же.
Плюс, внезапно захочется придушить того, кто придумал синтаксис цисковых настроек.

Из технических проблем здесь только "как непойми кому сказать, какой телефонный номер у того, кто зашёл на эту страничку".

Проблема решается просто, тупо и в лоб.
Владелец странички заключает договор с оператором связи, мол, хочу видеть телефонные номера заходящих ко мне людей, законы читал, зуб даю - гадить не буду.

После этого, начинает работать операторский DPI.
Как правило, в DPI реализован набор Application Level Gateway (ALG) для наиболее популярных протоколов: HTTP, FTP, DNS. Если по-русски, то ALG - это прозрачный прокси.
Какой телефонный номер у абонента, DPI знает: если DPI встроен в GGSP/PGW (это типа BRAS, но с мобильной спецификой), то знает изначально, а если это отдельная коробка, то получает связку ip-адрес -> телефонный номер, например, по тому же RADIUS. Или же, если DPI включен в разрыв между SGSN и GGSN/SGW и PGW (бывает и такое), подглядывает абонентский номер из полей GTP-C.

В общем, DPI абонентский телефонный номер каким-то образом узнал.
А дальше он его попросту добавляет в виде отдельного HTTP-заголовка в HTTP-запросы к целевой страничке.
Да, в качестве защиты от Злобного хакера где-то посередине, иногда телефонный номер шифруется, дабы никто, кроме владельца странички, разобрать его не мог.

Закрыть такую возможность можно одним способом: сделать абонентский трафик для оператора связи нечитаемым.
Это:
- отказ от HTTP и переход на HTTPS, либо
- работа исключительно через VPN

Поскольку резолвинг DNS происходит корректно, промышленно готовых вариантов остаётся три:

1. Провайдерский DPI: наверняка он уже есть у всех провайдеров в том или ином виде.
Логически DPI обычно включается в разрыв линка между ядром и NAT.
Физически зачастую тоже.
Кроме обычных шейпинга и подсчёта трафика per-subscriber, там реализован набор ALG (Application Layer Gateway), которые представляют из себя, фактически, прозрачные прокси для типичных протоколов: HTTP, FTP, DNS и т.д.
Как правило, ALG умеют не только реагировать на определённые значения полей, но и вмешиваться в процесс передачи данных.
Количество ALG зависит от навороченности DPI; в Procera даже World of Warcraft есть )
Ну а уж подмена HTTP-страницы - пожалуй, самая используемая функция HTTP ALG.

2. Наколенное решение раз:
Описано у none7
Завести у себя в сети сервер с ip-адресами, совпадающими с Ip-адресами Вконтакта (ну, или NAT'ить все запросы к нему на сервер-заглушку, что примерно то же самое) - вполне себе решение, если надо заблокировать сервис целиком, а не отдельные страницы на нём.
Но если вдруг ваши политики наберутся дурости у наших, и список блокируемых ресурсов начнёт расти, провайдеры взвоют этот вариант поддерживать )

3. Наколенное решение два:
На самом деле, в России есть свой список блокируемых ресурсов (т.н. список Роскомнадзора) с сотнями тысяч URL.

Выяснилось, что таким количеством записей множество провайдерских DPI попросту давится, поэтому эта задача зачастую решается следующим образом: заводятся отдельные серверы, подключаемые непосредственно к провайдерским BR (Border router'ам).

Задачи серверов:
- заглотить список блокируемых ресурсов, выдрать оттуда имена доменов и разрезолвить их в ip-адреса; адресов получается несколько десятков тысяч
- полученные адреса через OSPF или BGP сливаются в BR. BR - он большой, спокойно держит BGP Full View, поэтому 10-20-50k лишних префиксов для него - капля в море

Получается, что весь трафик в сторону ip-адресов, на которых находится хотя бы одна заблокированная страница, теперь льётся на эти серверы.
Казалось бы, фиг какой сервер всё это переварит, но их можно плодить десятками: срабатывает ECMP/Load Balancing на уровне маршрутизации, и трафик размазывается между серверами примерно поровну.

На самих серверах Linux, а в Linux - squid в transparent mode и iptables )
Соответственно:
- tcp port 80 силами iptables отправляется в сквид, где каждый запрошенный абонентом URL ищется в списке блокированных ресурсов
- в tcp port 443 проверяется SNI чтобы понять, пропускать трафик дальше, или резать к такой-то матери
- весь остальной трафик (и пинги, угу) пропускается насквозь без изменения

Может быть, вывести вот это:

o.datetime_order >= $date_start
AND o.datetime_order <= $date_end

из-под join'а в where?

Например, так:

SELECT w.name_worker,
w.surname_worker,
w.midname_worker,
w.id_worker,
SUM(number) numb
FROM workers w
LEFT JOIN exhours e ON (w.id_worker = e.id_worker)
LEFT JOIN orders o ON (e.id_order = o.id_order)
where
o.datetime_order >= $date_start
AND o.datetime_order <= $date_end
GROUP BY w.id_worker

Потому что сейчас получается так:
1. Будут выведены все записи таблицы Workers
2. К ним будут прицеплены _все_ записи таблицы exhours по полю id_worker
3. Также будут прицеплены записи таблицы orders, _для которых поле datetime_order попадает в указаную вилку_
Однако, поле number-то хранится в таблице exhours!

Как вариант, можно было бы сделать так:

SELECT w.name_worker,
w.surname_worker,
w.midname_worker,
w.id_worker,
SUM(h.number) numb
FROM
workers w
left join
(select e.id_worker, e.number from
exhours e inner join orders o on e.id_order = o.id_order
where o.datetime_order >= $date_start
AND o.datetime_order <= $date_end) h
on w.id_worker = h.id_worker
GROUP BY w.id_worker

Предлагаю посмотреть:
1. Как настроена балансировка?
2. Как замерялась скорость?

Эти вопросы связаны, на самом деле: для того, чтобы понять, в какой порт LAG засунуть Ethernet-кадр, коммутатор вычисляет хэш-функцию от выбранных при настройке полей кадра и берёт остаток от деления хэша на количество линков в LAG.

По умолчанию, как правило, хэш считается от Source MAC + Destination MAC.
Также, обычно можно руками включить использование для вычисления хэша:
- Source ip/Destination ip
- Source port/Destination port

На практике же это означает, что:
1. Чем больше _разных_ MAC/ip-адресов проходит через LAG, там равномернее распределяется трафик
2. А вот установленное TCP-соединение не "размажется" по линкам и при, например, загрузке файла по FTP скорость всё равно упрётся в скорость одного-единственного линка, будь их там хоть все восемь

CIDR - это один из способов записи диапазонов ip-адресов, не более того.
Просто способ написать, что "ip-адреса компьютеров бухгалтерии лежат в диапазоне 172.16.0.0-172.16.255.255": 172.16.0.0/16

Если уж подходить к понятию автономной системы абстрактно, то автономная система - это ip-транспортная инфраструктура некоторого состоящего из множества отделов и, соответственно, ip-подсетей предприятия целиком либо, как минимум, изолированного филиала, поскольку:
- там свой отдельный план выделения ip-адресов
- там свой отдельный администратор сети

Для того, чтобы различать принадлежность ip-адресов на уровне организаций, в некоторых протоколах маршрутизации, например, BGP, принято каждому предприятию выделять свой идентификатор - т.н. ASN, Autonomous System Number.

Надо понимать, что ASN - это чисто BGP-шный термин.
Если организация подключена к Интернет через единственный стык единственного провайдера, то необходимости в BGP у неё нет.
Соответственно, получается, что автономная система формально у неё всё равно есть (как совокупность используемых в организации ip-сетей и механизмов управления ими), просто номер ASN ей не присвоен.

В реальной жизни, как правило, понятие автономной системы фигурирует не в описании сетевой инфраструктуры организации, а в правилах обмена трафиком между двумя различными организациями:
- параметры физического и ip-стыков двух автономных систем
- какие принадлежащие каждой АС ip-подсети должны быть доступны партнёру по стыку