creed Опубликовано 22 апреля, 2015 · Жалоба 1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано. Терминируете на районных маршрутизаторах. 2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 домена Не нужно ничего сегментировать, загоняете каждого абонента во влан, на него вешаете старые настройки и все работает. Про броадкасты сразу забываете. Вланы с доступа веду на агрегацию, там терминирую. Настраиваю traffic-segmentation таким образом чтобы QinQ между собой не перекликались, но имели доступ к влану с адресом шлюза. Таким образом клиенты друг друга не видят напрямую, только через шлюз. Широковещательные между конкретным клиентом и шлюзом проходят тет-а-тет, и другие клиенты этот мусор не видят, так? Профит! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 22 апреля, 2015 · Жалоба У клиента к примеру такие статик настройки 10.208.3.164/255.255.0.0 gw 10.208.0.1Для этого в ядре заводится статический маршрут 10.208.3.164/32 на этот влан.Если абонент ставит вручную чужой ип - у него просто перестаёт работать сеть, поскольку на него завёрнут только этот ип и всё. Если у абонента несколько ипов - делаются соответствующие статические маршруты. Никакой привязки к маку тут не нужно вовсе. Когда на юзера приходит первый же пакет - в его сторону уйдёт arp-запрос. При отрицательном балансе ипы должника перенаправляем на страницу "вы должник", средств это сделать масса. Если ипы у абонентов сейчас серые - то разумнее на каждый такой влан добавить серую подсеть, для физиков /28 вполне достаточно - и по dhcp выдавать ипы из подсети. Это упрощает подключение нескольких компов - не нужно полоскать мозги абоненту на тему настройки роутера, достаточно отправить его в магазин за говносвичом, с которым он справится сам. Чем конктретно вариант vlan-per-customer предпочтительнее, какие преимущества это принесет?Тем, что абоненты в принципе лишены возможности нагадить друг другу.Например, если кто-то поставит себе мак соседа. Однако эту кучу вланов нужно будет где-то терминировать. На агрегации (в моем случае на DGS-3120-24SC)? Не пускать же напрямую в ядро.Как раз надо пустить напрямую в ядро.DGS-3120-24SC будет сворачивать вланы доступа в двойные вланы QinQ, а эта пачка двойных вланов в ядре войдёт в BRAS. Как быть со сменой мака при смене сетевушки?Забудьте про все эти привязки и подвязки. К влану абонента привязаны только его ипы. Его мак - его личное дело. Открыты вопросы по практической релизации:1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано. Реализуется BRASом в ядре.BRAS может быть как аппаратным, так и программным на базе компа. 2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 доменаВезде, где управляемое железо, у каждого абонента по влану, в который завёрнуты маршруты на его ипы.Везде, где ещё неуправляемое - общие вланы, куда завёрнуты маршруты на все оставшиеся ипы. По мере перехода на управляемое с индивидуальными вланами, маршруты переносятся с неуправляемых колхозных вланов на индивидуальные управляемые. В результате как у непереведённых, так и у переведённых абонентов всё продолжает работать со старыми настройками. 3) Можно ли обойтись без прослушавания тысяч вланов на dhcpd, если не будет использоваться opt.82? Например, используя dhcp relayВстречный вопрос - с чем связан страх прослушивания тысяч вланов? :D 4) Каким образом авторизовывать на порту только разрешенные ip?Пример реализации на софтовом BRAS на базе FreeBSD.Допустим, имеется два "внешних" влана, в каждом из которых по два "внутренних". ifconfig vlan10 create vlan 10 vlandev em0 up ifconfig vlan20 create vlan 20 vlandev em0 up ifconfig vlan1001 create vlan 1001 vlandev vlan10 10.0.0.1/32 ifconfig vlan1002 create vlan 1002 vlandev vlan10 10.0.0.1/32 ifconfig vlan1003 create vlan 1003 vlandev vlan20 10.0.0.1/32 ifconfig vlan1004 create vlan 1004 vlandev vlan20 10.0.0.1/32 route add 10.0.0.31/32 -iface vlan1001 route add 10.0.0.32/32 -iface vlan1002 route add 10.0.0.33/32 -iface vlan1003 route add 10.0.0.34/32 -iface vlan1004 У самих юзеров настройки при этом такие: у юзера 1001 - 10.0.0.31/16 у юзера 1002 - 10.0.0.32/16 у юзера 1003 - 10.0.0.33/16 у юзера 1004 - 10.0.0.34/16 С их точки зрения, они продолжают сидеть в колхозе 10.0.0.0/16. Но если кто-то из них попробует поменять ип - у него перестанет работать сеть, поскольку в его влан идёт маршрут только на заданный /32. На другой ип он даже arp-запроса не получит. Могу показать подобный конфиг для аппаратного решения на Juniper MX. На цисках это называется unnumbered и делается аналогично, насколько я понимаю. Настраиваю traffic-segmentation таким образом чтобы QinQ между собой не перекликались, но имели доступ к влану с адресом шлюза.Таким образом клиенты друг друга не видят напрямую, только через шлюз. Это не поможет от дублирующихся маков, подмены ипов и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
B_Bondarenko Опубликовано 22 апреля, 2015 · Жалоба От подмены ипов прекрасно спасает arp-inspection, source-guard и dhcp-snooping - это все автоматом на основе dhcp, и вот хоть заподменяйся за порт коммутатора доступа ты не уйдешь - дропнет тебя. Физик без dhcp - не порядок, хотя для особо упертых неслабо сделать и статическкие привязки. От дублей маков без vlan per user или диких схем Saaba не спасет ничего, в варианте vlan per user до bras, читай упакованый в qinq останется на совести bras, как тут многие знают на некоторых брасах дубль мака не прокатывает. К слову не совсем уверен как поведут себя многие коммутаторы при обнаружении дубля мака, может и крышу снести. Как говорилось выше привязка абонента исключительно к vlan/port (opt82) или svlan/cvlan(qinq) для маленькой сети и особозвращенцев можно к чистому vlan. Давать или не давать клиенту более /32? мое мнение нефик даже с серыми, да и настройки dhcp порядком усложняются, хотя уже есть железяки с функцией виртуального роутера для клиента, но IMHO пока этот функционал избыточен. Да и не будем отбирать хлеб у производителей роутеров ;-). Тянуть все до BRASa или терминировать на L3 агрегациях вопрос вашей модели, во втором случае выше требования к свитчам доступа, зато нет нагрузки на BRAS локальным трафиком, но нет контроля за локальным трафиком - думайте сами, решайте сами. В том, что скоро коммутаторы отомрут Saab отчасти даже прав, ибо наблюдается тенденция к l3 коммутаторам доступа, т.ч. вполне возможно, что лет через 5-10 примерно так оно и будет, но не сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 22 апреля, 2015 · Жалоба Поделюсь своим опытом. Не исключаю что схема vlan per customer будет лучше. Но у нас исторически сделано так и работает без проблем уже несколько лет. При этом не ограничивать его использованием только одного ip, если у него их несколько.В идеале, уйти от привязки по маку вообще, чтобы при смене устройства всё заработало и при статике и при dhcp. Рисуем ACL на порт юзера. Данным ACL-ом прибивается IP к порту пользователя. Работает железно, хоть статикой, хоть DHCP адрес получай. никаких привязок к мак адресу нет, будет работать любой МАС Напишите в личку почту. Скину подробное описание как это делать на 3526 по SNMP. В биллинге и интерфейсе техподдержки все привязки видны, можно включить/выключить. При любых изменениях IP в биллинге - привязка сносится. (а то мало ли IP поменяли клиенту) Раз в сутки всем она проставляется автоматически по данным из биллинга. Кроме этого на длинках настроен loopdetect, port security, traffic segmentation (все порты смотрят наверх). Ну и немножко ACL Таким образом все клиенты не видят соседей и проблемы исключены. Буду очень признателен за примеры конфигурации. Пишите мыло в личку, вышлю подробный документ. Насколько я понял, vlan-per-customer не применяете. Как сегментируете? Мы нет, не применяем. Используем влан/ подсеть на дом или на несколько домов. Как быть со сменой мака при смене сетевушки? Хранить в БД связку mac-ip-свич-порт, следить за trap'ами от mac-notification и при совпадении порта сбрасывать привязку автоматически? мы никак не завязаны на МАС. ACL по сути делает привяку абонент-PORT. И вот ее в БД хранить надо. По многим причинам. Можно ли обойтись без прослушавания тысяч вланов на dhcpd, если не будет использоваться opt.82? Например, используя dhcp relay Я считаю можно и нужно использовать DHCP Relay. Мы выдаем IP по порту, у нас релеями явяются каждый коммутатор доступа. Но если использовать vlan per customer то лучше релеить например на аггрегации и выдавать ip по номеру влана. P.S. по схеме влан на клиента я не подскажу, не используем, т.к. довольны текущей схемой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 22 апреля, 2015 · Жалоба Например настройки одного абонента на микротике при схеме влан на клиента: /interface vlan add arp=proxy-arp interface=bridge_vlan name=vlan_79 vlan-id=79 /ip address add address=10.10.13.1/32 network=10.10.13.79 interface=vlan_79 /ip pool add name=dhcp_pool_79 ranges=10.10.13.79 /ip dhcp-server add add-arp=yes address-pool=dhcp_pool_79 disabled=no interface=vlan_79 lease-time=5m name=dhcp_79 Никакие маршруты не нужны, они добавляются сами при указании IP адреса. Биллинг, при необходимости смены адреса у абонента, просто физически меняет его адрес в пуле. Если требуется полностью не зависимая авторизация по Radius, то эти команды заносятся в настройку DHCP сервера и выполняются при выдачи адреса клиенту. Поэтому схема работоспособна и при ручном управлении, полуавтоматическом и полностью автоматическом. Можно ставить Mikrotik CRS на доступ и вешать адреса прямо на порты, можно ставить CCR на агрегацию районов или групп домов, дальше уже поверх L3 все пойдет в центр, где отшейпится по тарифам и отправится в интернет. Внутрисетевой трафик не ограничивается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 22 апреля, 2015 · Жалоба От подмены ипов прекрасно спасает arp-inspection, source-guard и dhcp-snoopingКонструкция из палок и верёвок, которая мешает при попытке выдать абоненту несколько ipv4, и которая несовместима со SLAAC.как поведут себя многие коммутаторы при обнаружении дубля мака, может и крышу снестиСовершенно нормально себя ведут.При vlan per customer в каждом влане светится мак браса, и это никого никогда не смущает. Таблица коммутации содержит не просто маки, а пары мак-влан. Давать или не давать клиенту более /32? мое мнение нефик даже с серыми, да и настройки dhcp порядком усложняютсяС серыми - наоборот, кардинально упрощаются. Каждому свою серую подсеть - пул dhcp.А вообще у меня полно клиентов, которые заказывают несколько штук белых, и щедро платят. Да и не будем отбирать хлеб у производителей роутеров ;-)Лично мне наплевать на их хлеб. Типичная настройка вайфая, которую я делаю клиенту - перевожу его в мост и всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 апреля, 2015 · Жалоба Можно ставить Mikrotik CRS на доступ Если уж и ставить на L3-доступ Микротики, то явно не такое убожество, как CRS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 23 апреля, 2015 · Жалоба Если уж и ставить на L3-доступ Микротики, то явно не такое убожество, как CRS. На них только роутинг, они легко пропускают гиг трафика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 23 апреля, 2015 (изменено) · Жалоба у нас 76ая пропускает больше 40гбит и ? в эпоху 1/10/40/100GE гигабитом не удивить. Изменено 23 апреля, 2015 пользователем zhenya` Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dIMbI4 Опубликовано 23 апреля, 2015 · Жалоба Да тут фишка в чем- товарищу надо подогнать брас под л2/л3 коннектед с "аннамбердом" и натом. Будет ему счастье. Бордер есть, с агрегацией разрулит. Главное в голове решить л2 или л3 коннектед? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
B_Bondarenko Опубликовано 23 апреля, 2015 · Жалоба От подмены ипов прекрасно спасает arp-inspection, source-guard и dhcp-snoopingКонструкция из палок и верёвок, которая мешает при попытке выдать абоненту несколько ipv4, и которая несовместима со SLAAC.как поведут себя многие коммутаторы при обнаружении дубля мака, может и крышу снестиСовершенно нормально себя ведут.При vlan per customer в каждом влане светится мак браса, и это никого никогда не смущает. Таблица коммутации содержит не просто маки, а пары мак-влан. Давать или не давать клиенту более /32? мое мнение нефик даже с серыми, да и настройки dhcp порядком усложняютсяС серыми - наоборот, кардинально упрощаются. Каждому свою серую подсеть - пул dhcp.А вообще у меня полно клиентов, которые заказывают несколько штук белых, и щедро платят. Да и не будем отбирать хлеб у производителей роутеров ;-)Лично мне наплевать на их хлеб. Типичная настройка вайфая, которую я делаю клиенту - перевожу его в мост и всё. Ваш выбор, у каждого свой сценарий. Свитчи доступа незазря развивают. У нас пока белых ип хватает, не хватит - пустим CGNAT, кроме всего прочего, что-то мне шепчет, что засормить вашу схему не очень просто. Да и интересно, как в вашей схеме у клиента будет работать порт форвардинг, и прочие плюшки? Вы будете рисовать это за него у себя? Ваша схема вроде бы полноценно реализована на Ericsson SSR, но и то только по презенташкам, но даже после выхода потребностей сети за пару se100 в нынешних реалиях скорее будет se600, чем этот монстрик. у нас 76ая пропускает больше 40гбит и ? в эпоху 1/10/40/100GE гигабитом не удивить. Если не секрет какой у вас RSP, что-то мне подсказывает, что сильно иной нежели у топикстартера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 23 апреля, 2015 · Жалоба что-то мне шепчет, что засормить вашу схему не очень простоСормится "серый" трафик + отдаётся табличка соответствия внешних серым. Никаких вопросов не возникало.Да и интересно, как в вашей схеме у клиента будет работать порт форвардингКому надо - берут себе белые ипы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wz2002 Опубликовано 1 мая, 2015 · Жалоба Зачем ему в ядре вообще что-то из коммутаторов, если есть 76хх? Вот чего я не пойму Кто-нибудь ответит? Почему к нему нельзя добавить x6748-sfp? Зачем там 4948 или стэки из 3750g-12s? Есть сетка подобная описанной ТСом. Может кто-нибудь проконсультировать за денежку в Москве по поводу аналогичного апгрейда? Имею совсем общие представления о телекоме. Интересует не конечная схема, а описание плюсов/минусов различных подходов: vlan-per-customer, dhcp+opt82, как у Negator или как-то еще. При ограниченном кол-ве внешников можно ли использовать NAT или обязательно докупать еще. Почему нельзя сделать ядро и bgp на 7600, нужно ли исользовать fv или можно обойтись default bgp. Какое лучше железо использовать для этих целей или, быть может, нужен Linux, и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KaraVan Опубликовано 4 мая, 2015 · Жалоба Есть подобная история в провинции. 1)все клиенты(~1000)висят на пачке DSLAM 2)у всех уже забиты статикой IP адреса на модемах 3)шейпит и авторизует всё это сервер на Линуксе, фактически это уже IPoE 4)трафик маленький, в районе 300Мбит Замену доступа пока не рассматриваем. Основной вопрос, как на DSLAMах обеспечить безопасность, сравнимую с современными коммутаторами доступа Ethernet. Пока что видится топология vlan-per-user, с оборачиванием в QinQ и затаскиванием этого трафика на BRAS. У кого-нибудь был успешный опыт по встраиванию DSL сегмента в IPoE? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 4 мая, 2015 · Жалоба В DSLAM помоему все намного проще. Если не ошибаюсь, изоляция портов там в дизайне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
creed Опубликовано 1 июня, 2016 (изменено) · Жалоба Спустя год таймаута на раздумия и подготовку. Сеть 500 домов. Теперь уже практически везде хотя бы по одному DES-3526 на дом, агрегация домов на DGS-3120-24SC. Кое-где гирлянды из нескольких домов, иногда с мыльницами - но таких менее 10%. Абонентов - порядка 4000, активного прироста не предвидится. Нужно сделать так, чтобы в идеале работало хорошо и с минимальными вмешательствами со стороны админского состава) В ядре в данный момент, всё тот же роутящий /16 бродкастовые сети, Catalyst WS-C4948-S, паразитного бродкаста очень много. 1. На сколько я понял BRAS терминирует L2 линии напрямую от пользователя (qinq,pppoe, etc..). И всеравно до конца не понимаю как его использовать на практике. Вот ядром сейчас является 4948 - терминирует вланы сегментов (v200 .. v224), является шлюзом (10.200.0.1/16 .. 10.224.0.1/16), гоняет мультикаст, pim-sm, роутит сегменты между собой и выше 0.0.0.0. При этом имеет 48 гигабитных портов, фабрику 96Gbps и может форвардить 72mpps. При использовании vlan-per-customer и BRAS'а - получается L3 от 4948 уже будет не нужен, вланы будут проходить через него транзитом, правильно понимаю? Т.е. весь роутинг переедет на BRAS, он же будет терминировать QinQ, аналогично unnumbered обслуживать единичные роуты, а каталист станет просто агрегирующим коммутатором ядра? В таком случае его можно будет заменить на 4948-10GE с десяточными портами или вообще что-нибудь вроде DGS-3420-28SC, поставить машину на i7 или на паре x5650 и соединить через direct-attach sfp+. Ну или оставить 4948 и через LACP соединить. От прослушки тонны вланов на dhcpd по всей видимости никуда не деться, ну и ладно. Но получается, что весь трафик в том числе и локальный будет переть через BRAS. Справится ли обычный Linux PC-роутер со всем этим роутингом, трафиком под 10гбит и pps наравне с каталистом? 2. Если делать не влан до абонента, а скажем влан до дома. Видится как некий компромиссный вариант. Насколько я понял, в этом случае бродкаста уже будет на порядок меньше, можно обойтись без QinQ - вланов уже не 4000 а всего 500. Коммутаторы доступа останутся с прежними настройками - проще диагностировать неполадки, не нужно шибко автоматизировать автонастройку и переучивать персонал. Вычислить воришек в пределах одного дома с Mac Notification не сложно. Возможно ли в этом случае обойтись без выделенного BRAS с помощью имеющегося каталиста 4948, на 500 статично созданных dot1q вланах и ip unnumbered? Примерно по тому же принципу, на агрегации (3120-24SC) создаем по untagged влану на дом (1порт=1дом), тащим в ядро. Вместо существующих L3 Vlan интерфейсов создаем Loopback интерфейс и переносим на него все ip шлюзов. interface Loopback2 ip address 10.200.0.1 255.255.255.255 .. ip address 10.224.0.1 255.255.255.255 secondary no ip redirects interface Vlan3001 description house1 ip unnumbered Loopback2 .. interface Vlan3501 description house501 ip unnumbered Loopback2 Кстати, возможно ли в этом случае использовать ip dhcp helper прямо на вланах домов? - Догадываюсь что нет, ведь это уже будут L2 интерфейсы, следовательно релеить запросы будет нечему. Верно? Если нет - транком пробрасываем все 500 вланов на линуксовую машину, поднимаем dhcp и слушаем/выдаем известные базе ip или временные ip из пула При включении интернета для пользователя в автоматическом режиме создаем на каталисте ip route 10.200.1.196 255.255.255.255 Vlan3001 При выключении - no ip route 10.224.6.43 255.255.255.255 Vlan3501 (и по rsh создаем алиас eth1.3501:1 10.224.0.1 на влан интерфейсе машины которая слушает все вланы с применением DNAT'а 80,443 портов на страничку со сообщением что интернет выключен или заблокирован) Вопрос - справится ли 4948 как минимум с 4000 статик роутами и терминацией 500 вланов? ● Support for 4096 active VLANs and 4096 VLAN IDs per switch ● SVIs: 2048 По крайней мере по вланам умещаемся. У клиента к примеру такие статик настройки 10.208.3.164/255.255.0.0 gw 10.208.0.1Для этого в ядре заводится статический маршрут 10.208.3.164/32 на этот влан.Если абонент ставит вручную чужой ип - у него просто перестаёт работать сеть, поскольку на него завёрнут только этот ип и всё. Если у абонента несколько ипов - делаются соответствующие статические маршруты. Никакой привязки к маку тут не нужно вовсе. Когда на юзера приходит первый же пакет - в его сторону уйдёт arp-запрос. При отрицательном балансе ипы должника перенаправляем на страницу "вы должник", средств это сделать масса. Однако эту кучу вланов нужно будет где-то терминировать. На агрегации (в моем случае на DGS-3120-24SC)? Не пускать же напрямую в ядро.Как раз надо пустить напрямую в ядро.DGS-3120-24SC будет сворачивать вланы доступа в двойные вланы QinQ, а эта пачка двойных вланов в ядре войдёт в BRAS. Открыты вопросы по практической релизации:1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано. Реализуется BRASом в ядре.BRAS может быть как аппаратным, так и программным на базе компа. 2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 доменаВезде, где управляемое железо, у каждого абонента по влану, в который завёрнуты маршруты на его ипы.Везде, где ещё неуправляемое - общие вланы, куда завёрнуты маршруты на все оставшиеся ипы. По мере перехода на управляемое с индивидуальными вланами, маршруты переносятся с неуправляемых колхозных вланов на индивидуальные управляемые. В результате как у непереведённых, так и у переведённых абонентов всё продолжает работать со старыми настройками. 3) Можно ли обойтись без прослушавания тысяч вланов на dhcpd, если не будет использоваться opt.82? Например, используя dhcp relayВстречный вопрос - с чем связан страх прослушивания тысяч вланов? :D 4) Каким образом авторизовывать на порту только разрешенные ip?Пример реализации на софтовом BRAS на базе FreeBSD.Допустим, имеется два "внешних" влана, в каждом из которых по два "внутренних". ifconfig vlan10 create vlan 10 vlandev em0 up ifconfig vlan20 create vlan 20 vlandev em0 up ifconfig vlan1001 create vlan 1001 vlandev vlan10 10.0.0.1/32 ifconfig vlan1002 create vlan 1002 vlandev vlan10 10.0.0.1/32 ifconfig vlan1003 create vlan 1003 vlandev vlan20 10.0.0.1/32 ifconfig vlan1004 create vlan 1004 vlandev vlan20 10.0.0.1/32 route add 10.0.0.31/32 -iface vlan1001 route add 10.0.0.32/32 -iface vlan1002 route add 10.0.0.33/32 -iface vlan1003 route add 10.0.0.34/32 -iface vlan1004 У самих юзеров настройки при этом такие: у юзера 1001 - 10.0.0.31/16 у юзера 1002 - 10.0.0.32/16 у юзера 1003 - 10.0.0.33/16 у юзера 1004 - 10.0.0.34/16 С их точки зрения, они продолжают сидеть в колхозе 10.0.0.0/16. Но если кто-то из них попробует поменять ип - у него перестанет работать сеть, поскольку в его влан идёт маршрут только на заданный /32. На другой ип он даже arp-запроса не получит. Могу показать подобный конфиг для аппаратного решения на Juniper MX. На цисках это называется unnumbered и делается аналогично, насколько я понимаю. Изменено 1 июня, 2016 пользователем creed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 1 июня, 2016 · Жалоба Справится ли обычный Linux PC-роутер со всем этим роутингом, трафиком под 10гбит и pps наравне с каталистом? Смотря какое железо, какой тип траффика, сколько pps и будет ли на нем NAT. Вообще-то, для ядра обязательное N+1 резервирование и запас по производительности, чтоб выдержало DDoS и штормы внутри сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 июня, 2016 · Жалоба Вообще-то, для ядра обязательное N+1 резервирование и запас по производительности, чтоб выдержало DDoS и штормы внутри сети. ну и бред. как вы запас по производительности под DDOS посчитаете? да и штормы - это для говносетей у которых всё в одном vlan, никаких защит и stp в ядре Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
creed Опубликовано 1 июня, 2016 (изменено) · Жалоба Натинг, шейпинг делается после ядра, непосредственно перед миром. И с этим проблем нет, компы тянут. Да и в текущей реализации единая точка отказа это 4948. Компьютеры-то можно зарезервировать в перспективе. Изменено 1 июня, 2016 пользователем creed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 1 июня, 2016 · Жалоба Натинг, шейпинг делается после ядра, непосредственно перед миром. И с этим проблем нет, компы тянут. Ну, тогда Dell PowerEdge r710 с 2мя квадро Интел картами или с двумя 10Г интерфейсами должно чисто на роутинг хватить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 2 июня, 2016 · Жалоба Правильный вариант это влан на абонента, тогда будет куча вланов, которые можете поделить на 2 и более сервера, которые будут их терминировать. Если один выйдет из строя, можно поднять оставшиеся вланы на втором. Хотя обычно заводят идентичные конфигурации, и отключают половину вланов на одном и симметричную половину на другом, в случае проблем включают отключенные вланы и всю нагрузку принимает один сервер. Так же вланы можно перенаправлять и на коммутаторах перед серверами, способов много. Так же есть и вариант распределения нагрузки, когда IP адреса выдаются автоматически по номеру влана, тогда ставите 2 и более серверов с идентичными настройками, но разными адресами шлюзов, тогда абонент получит адрес автоматически от какого-то одного сервера, а срок аренды 5 минут. Если один сервер сломается, то через 5 минут абонент получит адрес от другого и продолжит работу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 3 июня, 2016 · Жалоба Вы забыли про VRRP и CARP. При правильной настройке, не надо ничего ручками поднимать :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 3 июня, 2016 · Жалоба его устройства так не умеют) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...