KaYot

В споре рождается истина. Я лично для себя из этой никчемной темы узнал много нового, и вижу что пора вводить dual stack у себя и ничего сложного тут нет.

Ролик можно назвать - терпеливый промоутер и тупое стадо. Водиле респект, хотя я бы полицию вызвал сразу "на всякий случай".

Новое поступление, наличие 6шт. Отличное состояние, тихие и экономичные сервера. Dell R210 II CPU: Xeon E3-1240(4 core/8 threads, up to 3.7Ghz, 80w) RAM: 16Gb DDR3-1333 ECC HDD: 500Gb SATA IDrac6 express + IDrac6 Enterprise - полноценное удаленное управление сервером с выделенным портом. PCIe-16x рейзер 290$

Постоянно в наличии, 20$/шт.

Silicom intel 82599, 2 порта SFP+ - 90$ Qlogic QLE8442-CU, 2 порта SFP+ - 90$ Так же в наличии SFP+ short range модуля(5$) и DA-twinax медные кабеля(20$).

Up, 750$

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

Я могу понять смысл использования хуанана в домашней машине, в итоге все тоже, но на 50$ дешевле и это круто. Но вот собирать из стрёмной китайской железки свой же бизнес с экономией все те х же 50$.. Какая-нить неформатная б/у плата dell/hp/fujitsu будет стоить столько же, но прослужит до окончания времен.

Через вторую PPPoE сессию давать это вообще зашквар.

Ну вот, проектировалось "что бы было красиво", а по итогу таблицы маршрутизации содержат ненужные поля МАК, и раздуваются в лишние 2 раза. Да и обработка 128бит на софт-роутерах в разы затратнее чем нативных 64 бит. NAT64? Мы ж от него уходили всеми силами))

Тут как раз проблемы никакой, целый блок /64 выдан клиенту и любой IP входящий в него - проблема клиента. А вот то что сейчас даже списки блокировок ничего не знают про V6 - забавно.

P.S.S вот нахрена заложена концепция выдачи конечному клиенту /64? Зачем ему эти зиллиарды адресов? Если цель уйти от НАТа полностью - 16 бит для этого достаточно с огромным запасом, остальное гигантизм и понты.

А как по мне - ipv6 бесполезная и изначально хреново продуманная концепция, созданная профессорами-теоретиками, а не сетевиками. Можно ж было сделать не "что б круто было", а с сохранением совместимости и практичности, расширить адресное пространство еще на 2 байта ZZ.ZZ.XX.XX.XX.XX с сохранением IPV4 сетей как одного из подмножеств V6. Старое железо работало бы на ура, минимальные изменения в конфигурациях и мозгах. В современной реализации никто не думал как будут выделяться блоки, где хранить эти 128 бит, как их вообще раздавать кастомерам и как обеспечить переход с V4.

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

Все верно написано. Лимит в 65к соединений можно получить только для обращения 1 источника к 1 получателю, и это не открытые порты роутера. Количество вариаций src-port источника . В любых других ситуациях лимита соединений нет.

Самому стало интересно в чем же разница. Гугель говорит - НАТ в BSD отслеживал только адрес назначения, что б вернуть пакет отправителю нужно однозначное соответствие "порт на который пришел трафик - локальный ИП". Итого 65к tcp + 65k udp трансляций на IP. Линукс же изначально отслеживает все 4 параметра SRC, DST, sport, dport - нет нужды подменять порты и нет ограничения числа трансляций на 1 ИП. Думаю этой ереси и в БСД давно нет, да и НАТов там несколько разновидностей.

Да тут криокамера не при чем. Какие порты должен у себя открывать маршрутизатор и зачем? Трафик к нему в input/output вообще не попадает, он транзитный. Дело маршрутизатора переложить пакет из интерфейса в интерфейс, и уменьшить ему TTL на 1. Если используется НАТ - заменить src и dst адрес в пакете согласно записям в таблице трекинга. Если записи нет и есть флаги SYN/NEW - добавить запись. Если записи нет и флагов нет - дропнуть пакет, не наш он.

Не совсем Какая-то из реализаций НАТа(PF?) во фре когда-то требовала выделения порта под каждый коннект и иначе никак. Вероятно вместо таблицы состояний тупо использовались открытые порты. Нынче никакой связи с портами маршрутизатора нет, могут отслеживаться десятки миллионов соединений. В linux и МТ точно так, думаю и во фре давно все изменилось.

Элементарно. Всем клиентам в этом свиче сбрасывается порт, дальше по последним МАКам операторы вручную восстанавливают 90% пользователей все как было. Оставшиеся 2-3 неактивные в данный момент клиента авторизируются или самостоятельно после ввода пароля на парковочной странице, или по звонку. Происходит это достаточно редко что б специально что-то автоматизировать, в неблагонадежных домах где неоднократно вырезали мы к примеру весь кабель идущий по чердаку-техэтажу закрыли в металлорукав и вандализм моментально прекратился. Т.е. это опять же больше административная пробле

Проблема перетыкания сильно преувеличена. Решается она административным запретом на подобные действия, за 5 лет работы не припомню ни одной проблемы перепутанных портов/логинов. При подключении нового клиента ему заранее создается учетка(а как иначе?), и монтажник включает кабель в заранее указанный порт. Изредка оказывается что порт битый/занят чем-то не прописанным в системе контроля - в телефонном режиме за 30с оператор меняет порт в учетке клиента и все счастливы. Не нужны клиенту лишние авторизации, не нужны записи "на пачке сигарет".

Вообще ничего общего с реальностью. Скрипт разбирает опцию 82 и на её основе выдает IP. У нас оно используется сугубо в виде "vlan пользователя", на основе этой информации юзер получает свой ИП. И пох, свич с витухой это в многоэтажке, ethernet на медиках в ЧС или ПОН любой марки.

Perl-dhcp от Ивана с НАГа например. У нас он выдает IP по опт82 полностью игнорируя мак. Решает клиент в воскресенье ночью воткнуть комп напрямую в кабель вместо сгоревшего роутера - мгновенно получает тот же ИП и все работает. Без звонков в ТП и лишних нервов.

Так я вроде и не тебе писал а человеку в криокапсуле.

Это пережитки прошлого в виде freeBsd и необходимости держать открытые порты для NAT. Linux использует другой механизм отслеживания соединений без таких тупых ограничений, 10М+ отслеживаемых одновременно соединений вполне нормально нынче. Вылезайте из криокапсулы. Нет, это сила чтения форумов и личного опыта)

Нет, с какой радости? Еще против каптчей помогает корректное описание блока в reverse-dns, если ваш NAT-IP никак не называется, политики к нему применяются как к флудящему хомячку с вирусом. А если он корректно обозван NAT-POOL1-ISPxxx - тот же гугль сильно смягчает нрав.