Как оператор сотовой связи понимает, что сим-карта выдаёт интернет на смартфон или на роутер/USB-модем?

Ну да нифига себе, три года прошло же )

Sergio, в шифрованной части трафика не видно.
Но вот HTTP, при помощи которого устройства проверяют доступность Интернета и отлавливают Captive Portal авторизации в публичных Wi-Fi-сетях - нешифрованный.

А ещё идентификатор платформы может вылазить в совершенно неожиданных местах - например, если мне не изменяет память, я его видел в передающейся в нешифрованном текстовом виде версии библиотеки протокола ZRTP, использующегося некоторыми мессенджерами для передачи аудио/видеопотока во время звонка.

Как настроить NAT на Juniper SRX650?

telegin:

Удивительно, но у меня в IN приватный адрес, а в OUT - публичный.

Session ID: 432838, Policy name: 135/393, State: Active, Timeout: 2, Valid
In: 172.16.16.2/24 --> 8.8.8.8/1661;icmp, If: reth8.453, Pkts: 1, Bytes: 84
Out: 8.8.8.8/1661 --> 217.148.x.x/52931;icmp, If: reth0.293, Pkts: 1, Bytes: 84

SRX650, Junos 12.1X44-D35.5
Да, немножко постарее )

Как настроить NAT на Juniper SRX650?

И вот в этот момент, когда с клиентской машины делается ping 8.8.8.8, надо посмотреть на show security flow session

NAT, на первый взляд, настроен правильно, и в выводе должно оказаться что-то вроде:

Session ID: 24015, Policy name: имя_политики, State: Active, Timeout: 1778, Valid
In: серый_адрес --> 8.8.8.8;icmp, If: reth8.453, Pkts: 6, Bytes: 969
Out: 8.8.8.8 --> публичный_адрес_после_NAT;icmp, If: reth0.293, Pkts: 4, Bytes: 1008

И, кстати, default gateway на клиентских машинах по DHCP правильно подтянулся?

VoLTE с выключенной передачей данных?

Логинов Станислав, значок VoLTE горит в углу совершенно не зря )

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

Таким образом, если:
- у Вас на телефоне настроен VoLTE
- у Вашего оператора связи все VoLTE-настройки для Вас выполнены
- Вы видите значок VoLTE-регистрации
- в настройках самого телефона то, что называется "Мобильный интернет", отключено

То звонки у Вас всё равно будут проходить не через 2G/3G, а через VoLTE.

С точки зрения логики, это правильно и разумно.
Тарифицировать VoLTE-трафик по правилам интернет-трафика, чего Вы, вероятно, опасаетесь, оператор не должен: VoLTE-трафик в сети оператора специально максимально отделён интернет-трафика.

VoLTE с выключенной передачей данных?

Полагаю, вопрос заключался в том, будет ли работать VoLTE, если со стороны оператора PS Services выключены: либо в принципе абонентского PS профиля нет, либо там навешан Operator Determined Barring.

Хотя забавный момент: если мобильный интернет выключить не со стороны сети, а в настройках телефона, VoLTE вполне себе работает, поскольку телефон понимает, что VoLTE-профиль настроек используется не для интернета.

А отдельные APN - одна для просто IMS, другая для Emergency calls, обе с QCI-номером поменьше, наличие на HSS не только PS profile, но и IMS profile, прописка на PCRF связки между Rx и Gx для создания Network Initiated Dedicated Bearer'ов - это всё детали )

Валентин, и позволю себе напомнить: там не просто отдельный bearer, там прям отдельные PDN Connection'ы )

Как определить позицию, с которой начинается BGP протокол в пакете MPLS?

Соответственно, _точно_ знают, что там и в каком виде летит, только PE-маршрутизаторы )

Как определить позицию, с которой начинается BGP протокол в пакете MPLS?

irdr, дело происходит примерно так.
Я беру самый простой случай, без промежуточных P-маршрутизаторов.
Сразу предупреждаю: будет куча неточностей во имя простоты, но я старался передать общий дух происходящего )

Итак, есть два маршрутизатора:
Маршрутизатор A: IP 10.0.0.1/30, MAC 00:00:00:00:00:01
Маршрутизатор B: IP 10.0.0.2/30, MAC 00:00:00:00:00:02

Для простоты - чтобы не получилась Война и Мир, предлагаю считать, что BGP мы поднимаем не между лупбеками, а непосредственно между сетевыми интерфейсами. Будет у нас что-то типа Inter-AS Option B ;)

Сервер A подключен к маршрутизатору A.
Сервер B подключен к маршрутизатору B.
Необходимо сделать так, чтобы Серверы A и B оказались в одном и том же VPN, для определённости, пусть это будет L3VPN.

Схема будет примерно такой:
[Сервер А] --- [Маршрутизатор A] --- [Маршрутизатор B] --- [Сервер B]

1. Итак, акт первый.
1.1. Маршрутизатор A -> Маршрутизатору B: Привет! Давай дружить по BGP! Я умею MP-BGP!
1.2. Маршрутизатор B -> Маршрутизатору A: Привет! Давай! Я тоже умею MP-BGP!

Маршрутизаторы A и B поднимают BGP-сессию, используя адреса 10.0.0.1 и 10.0.0.2

Параллельно, они договариваются о транспортных метках, например, по протоколу LDP:
1.3. Маршрутизатор A -> Маршрутизатору B: Давай, если полученный MPLS-пакет адресован мне, и пересылать его дальше никому не надо, первой MPLS-меткой будет 0!
1.4. Маршрутизатор B -> Маршрутизатору A: Давай! И если ты шлёшь пакет именно мне, не транзитом, пусть тоже 0 будет!

// На самом деле, 0 - это специальное зарезервированное значение метки под названием Explicit Null, а если по-русски, "Это тебе, лови!", но для определённости будем считать, что маршрутизаторы и об этом значении договорились явно.

2. Акт второй.
2.1. Маршрутизатор A -> Маршрутизатору B по протоколу BGP: Привет! У меня тут L3VPN появился, "Рога и Копыта Телеком", а в нём какой-то "Сервер А". Ты про "РиК Телеком" слышал что-нибудь?
2.2. Маршрутизатор B -> Маршрутизатору A по протоколу BGP: Привет! Да, у меня в "РиК Телеком" есть "Сервер В". Давай договоримся, что в РиК сервисной меткой будет 100!
2.3. Маршрутизатор A -> Маршрутизатору B по протоколу BGP: Договорились!

3. Акт третий.
3.1. Сервер A -> Серверу B: ping!
3.2. Маршрутизатор A получает ping! (Сервер A -> Серверу B). Его размышления:
3.2.1. Сервер А это "Рога и Копыта Телеком", значит, сервисная метка = 100
3.2.2. Сервер В в VPN "РиК Телеком" ко мне напрямую не подключен.
Зато, я знаю, что он подключен к Маршрутизатору В!
IP-адрес Маршрутизатора В - 10.0.0.2. Уж ты! Я с ним в одной подсети 10.0.0.0/30!
Блин, это ж MPLS, там нет транспортных IP-адресов...
Ну и что, что нет, я же с ним в одной Ethernet-подсети!

3.3. Маршрутизатор A посылает ARP-запрос: Эй, там, напомните, у кого IP-адрес 10.0.0.2?
3.4. Маршрутизатор В: Да здесь я, мой MAC 00:00:00:00:00:02!

3.5. Маршрутизатор А собирает MPLS-пакет и отправляет его по Ethernet:
[Source MAC] 00:00:00:00:00:01: "Это от Маршрутизатора А, хотя всем пофиг"
[Destination MAC] 00:00:00:00:00:02: "Ethernet switch, доставь это Маршрутизатору В!"
[Транспортная MPLS-метка] 0: "Маршрутизатор В, как получишь, разбирай пакет сам, никому пересылать его не надо!"
[Сервисная MPLS-метка с установленным флажком "End of stack" ("Больше меток нет")] 100: "VPN Рога и Копыта Телеком"
[ping! (Сервер A -> Серверу B)]

Как определить позицию, с которой начинается BGP протокол в пакете MPLS?

Немного исправлюсь.
BGP со стороны PE надо смотреть, конечно.
P незачем знать, что там внутри )

Как определить позицию, с которой начинается BGP протокол в пакете MPLS?

irdr, для понимания сути задачи уточню: Вы же понимаете, что тот BGP, который Вы, может быть, вдруг найдёте вложенным в MPLS-пакет, к L2VPN/L3VPN/EVPN MP-BGP-сессии, породившей этот пакет, отношения иметь не будет?

Тот BGP, из которого станет ясно, что именно там внутри, будет не "внутри", а "рядом".
Вероятно, проще было бы разобрать тот "рядом" находящийся MP-BGP, в котором P-маршрутизаторы договорились о типе сервиса и номерах меток...

Насколько затратно по деньгам для мобильного оператора внедрение технологии VoLTE?

Валентин: допускаю, что я мог немного отстать от последних тенденций операторского Wi-Fi, но я почему-то уверен, что Guaranteed QoS - это в принципе единственное преимущество VoLTE перед голосовыми вызовами в WhatsApp/Viber/Skype )
В условно незагаженном эфире голосовой вызов в любом мессенджере ничуть не хуже такого же вызова в VoLTE.

Надо бы почитать, вдруг в Wi-Fi 6 появились аналоги Dedicated Bearer'ов? Модуляцию и радиопланировщик они у LTE, помнится, уже стащили...
Но на большинстве виденных мною схем VoWiFi сам Wi-Fi был, как правило, Third Party, читай, "включая TP-Link" )
Да и присвоение медиапотоку своего собственного QoS надо как-то синхронизировать с IMS, а значит, это уже какой-то хитрый Trusted Wi-Fi, который в обслуживании может оказаться сложнее или, по крайней мере, замороченнее обычных LTE или будущего NR.

Также, надо как-то заставить звонилку поднимать VoWiFi только в дружественных SSID, а потом в мыле носиться и расставлять собственные точки... Мне кажется, уж проще тогда фемтосот натыкать.

Хотя - оговорюсь - я от радио далёк и, возможно, каких-то радийных нюансов не знаю, я по ядру больше.

Кстати, есть же ещё Unlicensed LTE access в частотах 2.4/5 GHz!
Его поддержки, вроде бы, пока что почти нет в терминалах, и всякие надзоры от него шарахаются как чёрт от ладана, но, сдаётся мне, это до поры до времени )

Насколько затратно по деньгам для мобильного оператора внедрение технологии VoLTE?

За всех операторов отвечать не могу )

Как в bird настроить фильтр ospf export?

Можно попробовать настроить соседей, чтобы подлежащие фильтрации сети они отдавали как external.
На route type external фильтр может и сработать

Как поймать сигнал с сотового телефона?

Товарищ майор, я его не знаю, я не с ним! ;)

В природе есть:
- статистика, которой оператор связи за некоторую сумму готов поделиться
- вещи на грани легальности
- вещи совсем сомнительные

Настоятельно рекомендовал бы с пунктами 2-3 бы не связываться: это занятие, по мнению многих, профессионала недостойное.

Очень многую же полезную статистическую информацию - если она не включает личных данных - можно получить вполне легально у операторов связи.

Как я вижу из переписки выше, Вас интересует статистика по количеству абонентов в некоторой географической точке.
Технически, такая информация у любого оператора связи есть: любой оператор ежедневно отвечает на множество запросов от полиции о географическом местонахождении некоего номера в определённый момент времени.

Телефонные номера Вам, конечно, не дадут: это требования законодательства о личных данных. А вот посчитать уникальных абонентов, засветившихся в соте, в которую попадает интересующая Вас географическая точка - почему бы и нет? Возможно, даже и в разбивке по IMEI TAC-кодам, идентифицирующим производителя и модель телефонного аппарата.
Тогда Вам дорога в коммерческий отдел любого оператора.

Visitor Location Register: данные LAC и Cell_ID - хранится ли история их изменений и где?

Inter-System Change RAU ( -> GSM/WCDMA) или TAU (-> LTE) это тоже, по сути, Location Update )

Получается, в момент переключения радиотехнологий номер соты тоже известен.
Соответственно, номер соты должен бы попадать в CDR VLR или MME (для сети LTE) и подсасываться биллингом - хотя бы для обеспечения требований СОРМ.

Как же оно на самом деле - Vendor Specific, вопрос даже не к операторам, а к производителям оборудования )

В момент Attach (аппарат включили, или же он выпадал из сети, и теперь, увидев сеть, радостно решил к ней прицепиться) номер соты также известен.

Как реализовать HLR запрос?

А что Вы хотите слать или, наоборот, получать?

Что такое "тайм аут соединения" в обычной "звонилке"?

Плохое качество покрытия - может.
Отрицательный баланс в чистом виде - вряд ли.

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

Настройка vlan-ов в juniper?

Немного разжую сообщение от vertex4

В JunOS на платформе SRX Ethernet-интерфейс может работать в двух режимах:
- L3 (когда прописана family inet)
- L2 (когда прописана family ethernet-switching)

А теперь предлагаю посмотреть на VLAN 30, 40, 101, 102, 103.

В конфиге они зачем-то прописаны дважды:
- в сабинтерфейсах интерфейса fe-0/0/6
- в vlans

Если я правильно понимаю задумку, предполагается Ethernet-свитчинг между fe-0/0/6 и fe-0/0/7.

В таком случае, необходимо перепрописать интерфейс fe-0/0/6 аналогично тому, как это сделано в fe-0/0/7:

fe-0/0/6 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ vlan30 vlan40 vlan101 vlan102 vlan103];
                }
            }
        }
    }

И, для красоты, придушить в конфиге все упоминания о fe-0/0/6.30, .40, .102-.103, заменив их соответствующими vlan.30-.103

И ещё один момент.
Есть у меня сомнения в работоспособности вот этой конструкции:
security zones security-zone trust interfaces fe-0/0/5.0 host-inbound-traffic
и вообще security zones security-zone trust interfaces fe-0/0/5.0 как таковом

Поскольку fe-0/0/5.0 работает в режиме свитчинга, все необходимые host-inbound-traffic необходимо поднимать на соответствующем vlan-интерфейсе.

А сам факт добавления switching-интерфейса в security zone...
Полагаю, здесь, всё-таки, подразумевался ip-рутинг.
Нет, какие-то SRX умеют файрволлить в режиме свитча, но я не могу с ходу вспомнить, умеет ли это SRX100. По-моему, это было на старших моделях, и включалось хитрее.

Настройка vlan-ов в juniper?

А с host-inbound-traffic, на будущее, будьте осторожнее-с ;)

Эта ветка отвечает не за транзитный трафик с интерфейса на интерфейс, а за трафик, терминирующийся на Routing Engine. Говоря проще, Вы только что разрешили всем в зоне trust лазить на этот SRX по ssh, telnet, snmp, http, https, ntp.

Настройка vlan-ов в juniper?

Роутинг есть, если глянуть в show route ;)

Надо явно разрешить транзитный трафик из зоны trust в зону trust:

edit security policies from-zone trust to-zone trust policy permit-all
set match source-address any destination-address any application any
set then permit

Какой основной принцип отправки пакетов IP на конкретный узел (хост) сети Интернет?

Станислав Бодро́в: предлагаю вернуться к исходному обсуждению.

Вопрос Даниил, насколько я его понял, заключается в следующем: какие наработки в технологии построения Ip-сетей можно было бы использовать при создании сети системы Distributed Messaging.

Разумеется, все мы здесь эксперты, знаем, как работает Traffic Engeneering, и помним, что в том же BGP, кроме AS Path, есть куча других замечательных полей, таких, как local preference, MED, origin, разных видов communities.

Однако, мне, почему-то, кажется, что при начальном разворачивании Distributed Messaging-сети это всё не пригодится ;)

Хотя да, есть один момент, который мешать не помешает, но с непривычки с толку сбить может, ибо, поскольку при неполной связности узлов могут образоваться равнозначные маршруты, то:
1. Исходящие сообщения могут, в зависимости от выбранного алгоритма выбора пути в таком случае, каждый раз уходить разным путём
2. Если предполагается что-то вроде Remote Procedure Call с явными запросом и ответом, надо быть готовым к тому, что запрос уйдёт одним путём, а ответ придёт совершенно другим, то, что в ip-сетях называется асимметричным прохождением трафика