Валентин

Фича 802.1x, погуглите 802.1x radius VLAN assignment, чаще используется для вай-фая. Зачем это нужно на обычных коммутаторах, не очень понимаю, но оно там есть.

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

Схему рисуют в ms visio от абонентского устройства до шлюза и аплинка-интернета. Мне бы хватило пары часов. Инструменты - логика, ping и traceroute.

Убедись, что в ripe создана записать типа route для твоей сети с правильным origin.
Убедись, что для AS твоего аплинка добавлены правила import/export для твоей asn/as-set.
Проверь себя в radb
Долби своего аплинка по этим вопросам.

Ну так вы нарисуйте, какие между какими узлами ipsecи хотите. А так хоть криптомапы и пишутся одна на интерфейс, но поддерживает синтаксис с несколькими записями, где можно связывать ACL с трансформ-сетами, по аналогии с полиси-мапами или аксес листами, через циферки.

Я видел полно ситуаций, когда ТП отвечала так клиентам (и даже сам говорил им так отвечать). Это может быть срабатывающий loopbackdetect, постоянно флапающий порт (half-full dublex, 10-100М), глючный мак-адрес (операторские свичи обрабатывают не весь мак адрес, а хеш от него и влана, причём только только часть этого хеша), устраивать шторм, в конце концов просто коротить линию и ещё очень много чего. Разбираться с вами отдельно - потратить несколько дней одного (двух) сетевого инженера (скорее всего в пустую, т.к. делать вы ничего не будете полгода - надо будет сначала получить бюджет).

Свич - не тупое устройство, в нем есть микросхема и прошивка. Тупой может быть только хаб или медиаконвертер.

Рекомендую:
1) избавиться от этого коммутатора, поднять линк на 10М и понаблюдать (на нормальной витухе 200 метров не проблема)
2) включить апстрим в другой порт этого коммутатора, а в текущий подключить какой-нибудь компьютер и генерировать в него трафик
3) поставить у себя нормальный коммутатор (а ещё лучше полноценный бордер, хоть тот же дешевый микротик)

Два балансировщика с одинаковыми адресами (по паре в кластере, итого четыре), каждый из которых расположен в разных субъектах страны, каждый балансировщик подключен двумя ногами к разным маршрутизаторам по EBGP. Бэки балансировщиков в постоянной синхронизации (heartbeat). Добавляем резерв по виртуализации (vmotion + fault tolerance), по питанию (два независимых ввода + ИБП + ДГУ). Статистически измеряем недоступность + время восстановление + длительность профилактических работ и масштабируем решение по вышеприведенной схеме, дотягиваем доступность до нужного уровня)

У нас некоторые узлы, где есть риск политических волнений в транзитных странах, ещё по двум спутниковым каналам включены.

Легально - настроить на 1.1.1.10 свою прокси и на клиентских ПК настроить 1.1.1.10 как прокси.
Нелегально - это man-in-the-middle, множество разных вариантов - спуфинги, прозрачная прокси на шлюзе, DNS-фишинги, крюки маршрутизации, подставные скрипты автонастройки браузера и т.д, все зависит от деталей расположения 1.1.1.10 и PC, а также ваших возможностей влияния на инфраструктуру.

Взрослые дяди выносят прогу (сервис) на виртуальную машину, виртуальная машина поднимается на кластере физ серверов с гипервизорами, в случае отказа одного физ сервера виртуалка переезжает через какой-нибудь vmotion на другой, ну и Жесткие диски стоят в вынесенной СХД, подключаемой по fibrechannel. Естественно каждый физ сервер подключен к разным коммутаторам и маршрутизаторам. Так работает в рамках одного помещения (ЦОДа), для территориально разнесенных цодов надо уже думать исходя из инфраструктуры этих цодов. А если этого мало, то считаем, сколько там допустимо время простоя в месяц, каково допустимое время восстановления, и уже исходя из этого выполняем ряд мероприятий.

По вариантам крепления на опоры выбирай.
Воздушкой все равно не кинешь дальше 200 метров без активного оборудования (регенерации), а на активном оборудовании и будет заземление.
На счет грозозащиты - да, покупаете отдельно и ставите на порты ethernet. Их полно, на том же наге посмотрите, ну или загуглите что-то типа "грозозащита ethernet". Только проблема грозозащиты в том, что она не мониторится. Молния долбанула, вы не узнаете, сгорела она или нет.

Админство в прежнем виде умирает, маркетинг перспективнее. Но если все же прямо тянет, определитесь с направлением - ну там windows, Linux, network, devops etc. А дальше вперёд на черновую работу за гроши - эникей, дежурная смена, монтаж... Если башка есть, через год подниметесь

Обычно это куча периферии, чаще всего, как уже сказали, касса (куда деньги убирают), сканер штрихкодов, принтер чеков. Это все подключается к компьютеру со специальным софтом типа r-keeper. В общем по всему есть инструкции на русском или платные курсы. Надо уд5лить нед5льку на изучение и использовать их как справочник. Ведь оборудование предназначено, чтоб с ним продавцы работали, а не программисты.

Сеть оператора ШПД в общем случае довольно простая, по крайней мере по сравнению с мобильными, спутниковыми и магистральными сетями, она состоит из множества коммутаторов, одного маршрутизатора и биллинга. Фактически это большая сеть доступа. Маршрутизатор здесь называется BRAS (ну или dslam если мы о adsl). Так вот конкретно для pppoe на клиентской стороне создается так называемый туннельный интерфейс, и на стороне BRAS аналогичный при успешном подключении абонента. На BRAS на этом туннельном интерфейсе и вешается ограничение. Сами данные по ограничению услуги BRAS берет из биллинга при создании подключения (взаимодействует с ним по RADIUS/TACACS или даже DIAMETER).

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

И да, PPPoE уже давно несовременная технология авторизации, сейчас все стараются переходить (и успешно переходят) на IPoE. Но это уже совсем другая история.

В linux я бы настроил несколько views на bind. Но win похоже изкоробки не поддерживает этот функционал. Хотя вот что-то похожеее. Впрочем и на win можно поставить bind

Когда я и коллеги использовали python вместо баш?
Когда потребовалось написать бекапилку конфигов на 8k сетевых устройст по snmp.
Когда надо было набросать простой веб-интерфейс для дежурной смены для примитивного up/down и смену description на этих устройствах.
Когда надо было проинтегрировать nagios-мониторилку с внешей сторонней базой данных.
Когда на 600 виртуалок необходимо было поставить разные софтины, перечень и версии которых хранились во внешнем xml-файле
Когда с увесистой пачки серверов понадобилось провести инвентаризацию типа sfp-модулей

К чему я это? Если вам хватает bash, радуйтесь и используйте его. Когда будет надо, вы сами придете к python.

На чистом баше вы замучаетесь делать веб-интерфейс к чему-либо, организовывать взаимодействие с внешними системами/программами, отличными от чистого linux (web, snmp, sql, email, ftp не разовое обращение), обрабатывать вводные данные к системе в форматах сложнее csv (html, xml, json), обрабатывать файлы в нестандартных кодировках, использовать нетекстовые переменные в скриптах (арифметика, дроби, списки, файлы). Боль начнется даже просто тогда, когда появятся файлы с названиями с нестандартными символами (?$!*\+alt-символы), а еще и в левой кодировке (привет mount ftp/samba/sshfs/ntfs и даже вложения к письмам). А еще больнее станет, когда размер своих скриптов превысит хотя бы 500 строк.

И уже как бонус идет то, что python есть из коробки в deb/rhel дистрибутивах, многие системные утилиты написаны уже на нем. Плагин к apt/yum проще всего сделать на python, даже можно не парясь писать стартап скрипты к сервисам.

Предположу, что косяк скорее всего в mtu (системном и на интерфейсе) и в каких-нибудь опциях фильтрации трафика и обработки фрагментированных пакетов. Ещё можно проверить стандартные политики обработки qos.