Jump to content
Калькуляторы

Ядрышко небольшой районной сети

1) vlan-per-customer, терминирование клиентских вланов и всё, что с этим связано.

 

Терминируете на районных маршрутизаторах.

 

 

2) Сегментирование /16, так чтобы при этом все продолжало работать со старыми настройками, но не сыпался бродкаст со всего /16 домена

 

Не нужно ничего сегментировать, загоняете каждого абонента во влан, на него вешаете старые настройки и все работает. Про броадкасты сразу забываете.

 

 

 

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

Таким образом клиенты друг друга не видят напрямую, только через шлюз. Широковещательные между конкретным клиентом и шлюзом проходят тет-а-тет, и другие клиенты этот мусор не видят, так? Профит!

Share this post


Link to post
Share on other sites
У клиента к примеру такие статик настройки 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 между собой не перекликались, но имели доступ к влану с адресом шлюза.

Таким образом клиенты друг друга не видят напрямую, только через шлюз.

Это не поможет от дублирующихся маков, подмены ипов и т.д.

Share this post


Link to post
Share on other sites

От подмены ипов прекрасно спасает 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 примерно так оно и будет, но не сейчас.

Share this post


Link to post
Share on other sites

Поделюсь своим опытом.

Не исключаю что схема 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. по схеме влан на клиента я не подскажу, не используем, т.к. довольны текущей схемой.

Share this post


Link to post
Share on other sites

Например настройки одного абонента на микротике при схеме влан на клиента:

 

/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 все пойдет в центр, где отшейпится по тарифам и отправится в интернет. Внутрисетевой трафик не ограничивается.

Share this post


Link to post
Share on other sites
От подмены ипов прекрасно спасает arp-inspection, source-guard и dhcp-snooping
Конструкция из палок и верёвок, которая мешает при попытке выдать абоненту несколько ipv4, и которая несовместима со SLAAC.
как поведут себя многие коммутаторы при обнаружении дубля мака, может и крышу снести
Совершенно нормально себя ведут.

При vlan per customer в каждом влане светится мак браса, и это никого никогда не смущает.

Таблица коммутации содержит не просто маки, а пары мак-влан.

Давать или не давать клиенту более /32? мое мнение нефик даже с серыми, да и настройки dhcp порядком усложняются
С серыми - наоборот, кардинально упрощаются. Каждому свою серую подсеть - пул dhcp.

А вообще у меня полно клиентов, которые заказывают несколько штук белых, и щедро платят.

Да и не будем отбирать хлеб у производителей роутеров ;-)
Лично мне наплевать на их хлеб. Типичная настройка вайфая, которую я делаю клиенту - перевожу его в мост и всё.

Share this post


Link to post
Share on other sites

Можно ставить Mikrotik CRS на доступ

Если уж и ставить на L3-доступ Микротики, то явно не такое убожество, как CRS.

Share this post


Link to post
Share on other sites

Если уж и ставить на L3-доступ Микротики, то явно не такое убожество, как CRS.

 

На них только роутинг, они легко пропускают гиг трафика.

Share this post


Link to post
Share on other sites

у нас 76ая пропускает больше 40гбит и ?

 

в эпоху 1/10/40/100GE гигабитом не удивить.

Edited by zhenya`

Share this post


Link to post
Share on other sites

Да тут фишка в чем- товарищу надо подогнать брас под л2/л3 коннектед с "аннамбердом" и натом. Будет ему счастье. Бордер есть, с агрегацией разрулит. Главное в голове решить л2 или л3 коннектед?

Share this post


Link to post
Share on other sites
От подмены ипов прекрасно спасает 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, что-то мне подсказывает, что сильно иной нежели у топикстартера.

Share this post


Link to post
Share on other sites
что-то мне шепчет, что засормить вашу схему не очень просто
Сормится "серый" трафик + отдаётся табличка соответствия внешних серым. Никаких вопросов не возникало.
Да и интересно, как в вашей схеме у клиента будет работать порт форвардинг
Кому надо - берут себе белые ипы.

Share this post


Link to post
Share on other sites

Зачем ему в ядре вообще что-то из коммутаторов, если есть 76хх? Вот чего я не пойму

Кто-нибудь ответит? Почему к нему нельзя добавить x6748-sfp? Зачем там 4948 или стэки из 3750g-12s?

 

Есть сетка подобная описанной ТСом. Может кто-нибудь проконсультировать за денежку в Москве по поводу аналогичного апгрейда? Имею совсем общие представления о телекоме. Интересует не конечная схема, а описание плюсов/минусов различных подходов: vlan-per-customer, dhcp+opt82, как у Negator или как-то еще. При ограниченном кол-ве внешников можно ли использовать NAT или обязательно докупать еще. Почему нельзя сделать ядро и bgp на 7600, нужно ли исользовать fv или можно обойтись default bgp. Какое лучше железо использовать для этих целей или, быть может, нужен Linux, и т.п.

Share this post


Link to post
Share on other sites

Есть подобная история в провинции.

1)все клиенты(~1000)висят на пачке DSLAM

2)у всех уже забиты статикой IP адреса на модемах

3)шейпит и авторизует всё это сервер на Линуксе, фактически это уже IPoE

4)трафик маленький, в районе 300Мбит

 

Замену доступа пока не рассматриваем.

Основной вопрос, как на DSLAMах обеспечить безопасность, сравнимую с современными коммутаторами доступа Ethernet.

Пока что видится топология vlan-per-user, с оборачиванием в QinQ и затаскиванием этого трафика на BRAS.

У кого-нибудь был успешный опыт по встраиванию DSL сегмента в IPoE?

Share this post


Link to post
Share on other sites

В DSLAM помоему все намного проще.

Если не ошибаюсь, изоляция портов там в дизайне.

Share this post


Link to post
Share on other sites

Спустя год таймаута на раздумия и подготовку.

 

Сеть 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 и делается аналогично, насколько я понимаю.

Edited by creed

Share this post


Link to post
Share on other sites

Справится ли обычный Linux PC-роутер со всем этим роутингом, трафиком под 10гбит и pps наравне с каталистом?

 

Смотря какое железо, какой тип траффика, сколько pps и будет ли на нем NAT.

Вообще-то, для ядра обязательное N+1 резервирование и запас по производительности, чтоб выдержало DDoS и штормы внутри сети.

Share this post


Link to post
Share on other sites

Вообще-то, для ядра обязательное N+1 резервирование и запас по производительности, чтоб выдержало DDoS и штормы внутри сети.

 

ну и бред. как вы запас по производительности под DDOS посчитаете? да и штормы - это для говносетей у которых всё в одном vlan, никаких защит и stp в ядре

Share this post


Link to post
Share on other sites

Натинг, шейпинг делается после ядра, непосредственно перед миром. И с этим проблем нет, компы тянут.

Да и в текущей реализации единая точка отказа это 4948. Компьютеры-то можно зарезервировать в перспективе.

Edited by creed

Share this post


Link to post
Share on other sites

Натинг, шейпинг делается после ядра, непосредственно перед миром. И с этим проблем нет, компы тянут.

 

Ну, тогда Dell PowerEdge r710 с 2мя квадро Интел картами или с двумя 10Г интерфейсами должно чисто на роутинг хватить.

Share this post


Link to post
Share on other sites

Правильный вариант это влан на абонента, тогда будет куча вланов, которые можете поделить на 2 и более сервера, которые будут их терминировать. Если один выйдет из строя, можно поднять оставшиеся вланы на втором. Хотя обычно заводят идентичные конфигурации, и отключают половину вланов на одном и симметричную половину на другом, в случае проблем включают отключенные вланы и всю нагрузку принимает один сервер. Так же вланы можно перенаправлять и на коммутаторах перед серверами, способов много.

 

Так же есть и вариант распределения нагрузки, когда IP адреса выдаются автоматически по номеру влана, тогда ставите 2 и более серверов с идентичными настройками, но разными адресами шлюзов, тогда абонент получит адрес автоматически от какого-то одного сервера, а срок аренды 5 минут. Если один сервер сломается, то через 5 минут абонент получит адрес от другого и продолжит работу.

Share this post


Link to post
Share on other sites

Вы забыли про VRRP и CARP. При правильной настройке, не надо ничего ручками поднимать :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this