• Как оператор сотовой связи понимает, что сим-карта выдаёт интернет на смартфон или на роутер/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!
    Его поддержки, вроде бы, пока что почти нет в терминалах, и всякие надзоры от него шарахаются как чёрт от ладана, но, сдаётся мне, это до поры до времени )
  • Как в 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-сетях называется асимметричным прохождением трафика