в предшедший заметке я рассмотрел использование топологии «кольцо». эта топология эффективна: в предлагаемом решении надёжно изолируются пользовательские широковещательные домены (L2-сегменты) друг от друга, что открывает путь к построению больших сетей. но я бы не рекомендовал делать больше 6 L3-коммутаторов в кольце.
почему? пакет от пользователя будет проходить через большое число коммутаторов. L3-коммутаторы хоть и быстрые, но в цепочке каждый вносит свою задержку. кроме того, длинная цепочка — это больше потенциальных точек отказа.
в случае 6 коммутаторов мы подключаем два диаметрально противоположных коммутатора. еще два находятся по обе стороны от линии которую можно провести через точки подключения. в этом случае для каждого такого коммутатора будет один лишний коммутатор на пути до магистрального маршрутизатора, что вполне приемлемо. если добавить еще один коммутатор, то расстояние для него до магистрального маршрутизатора будет уже два коммутатора.
конечно можно взять ещё один магистральный маршрутизатор и подключить его к двум другим точкам кольца, но это «каша из топора». эффективно получается 6 коммутаторов в кольце, один магистральный маршрутизатор подключённый к двум диаметрально противоположным точкам.
давайте грубо посчитаем сколько абонентов можно подключить используя такую топологию. если величина таблицы MAC в L3-коммутаторе в среднем 16К записей, а для IPv6 каждое устройство абонента представлено своим MAC-адресом (из-за отсутствия NAT в IPv4-смысле), и будем считать, что абонент представлен 3 устройствами, тогда 16 / 3 = 5.3К абонентов в сегменте.
впритык я бы тоже делать не советовал. итого для расчётов можно использовать цифру порядка 5К абонентов на L2-сегмент. это уже много. нужно обязательно ограничить число MAC-адресов на порту пользователя — например не более 5. защитить DHCP и RA от подделок. максимально ограничить широковещательный трафик с абонентских портов. то есть построение IPoE сети подразумевает определённые требования к коммутаторам доступа для обеспечения безопасности. добавьте к этому средства авторизации абонентов.
однако даже с таким подходом получается 5K*6= 30K абонентов — сеть небольшого ISP. а что делать если нужно построить сеть 5К*40=200К абонентов? честно признаюсь я такие сети не строил. опишу общий подход.
такую архитектуру принято называть Spine-Leaf. за страшными словами скрывается простая суть. есть уровень коммутаторов Spine они агрегируют коммутаторы Leaf которые изолируют l2 сегменты с абонентами т.е в них включены коммутаторы доступа.
при таком количестве абонентов ядро сети крайне желательно делать отказоустойчивым. для простоты рассмотрим такую схему: 2 магистральных маршрутизатора, 2 Spine коммутатора и 16 Leaf — 5*16= 80K абонентов — серьёзный ISP.
сама схема довольно простая: каждый Spine коммутатор соединён с каждым Leaf коммутатором. можно сказать иначе у каждого Leaf коммутатора ап-линьком являются два разных Spine коммутатора. поэтому крайне для этих коммутаторов крайне желательна функция Equal-cost multi-path routing (ECMP). суть функции проста. она позволяет существовать двум маршрутам с одинаковой стоимостью. при этом коммутатор будет оправлять пакет то по одному, то по другому маршруту. т.е. естественная балансировка up-link на уровне l3. в результате аплинки находятся не просто в резерве, а работают вместе, объединяя пропускную способность примерно как в LACP. но в отличи от LACP функция работает на сетевом уровне.
далее к каждому Spine коммутатору необходимо подключить магистральный маршрутизатор, который будет анонсировать им маршрут по умолчанию. магистральный маршрутизатор тоже резервируется — в нашей гипотетической схеме их два подключены каждый в свой Spine коммутатор.
таким образом мы получаем отказоустойчивое ядро, функция ECMP позволяет эффективно использовать линьки. схему можно легко масштабировать на больше число Spine коммутаторов и (или) магистральных маршрутизаторов. главное не нарушить симметричность - без неё не будет работать ECMP.
например, можно использовать 4 Spine-коммутатора, объединенных в две пары. магистральный маршрутизатор подключается двумя интерфейсами к двум Spine-коммутаторам из разных пар. таким образом, мы вдвое увеличили количество Spine-портов, сохранив прежнее количество магистральных маршрутизаторов.
сделав две группы Spine легко можно достичь количества 80 пар Spine портов, что в теории дает возможность подключить 400К абонентов. однако здесь следует рассчитывать можно ли прокачать такой трафик через уровень Spine и магистральные маршрутизаторы.
поэтому при выборе L3-коммутаторов для ядра необходимо обращать внимание не только на размер таблицы MAC-адресов (FDB), но и именно на размер L3 Host Table, который определяет, сколько IPv6-устройств коммутатор может маршрутизировать на аппаратной скорости.
для сети на 20 тысяч абонентов, где в среднем на одного приходится 2-3 устройства, потребуется ёмкость около 40-60 тысяч IPv6-записей в масштабах всего ядра. в данном случае с двумя парами Spine-коммутаторов — примерно по 20K IPv6-записей на каждый коммутатор.
впрочем, это не означает, что подключить более 20K устройств невозможно. трафик абонентов имеет периодический, а не непрерывный характер. необходимо убедиться, что время жизни (Timeout) записей в таблице не слишком велико — тогда неактивные записи будут быстрее удаляться, освобождая место для новых. однако важно понимать, что активная манипуляция содержимым таблицы коммутации требует ресурсов CPU.
не обязательно явно объединять коммутаторы в пары — я использовал этот пример в первую очередь для наглядности. представьте, например, 5
Spine-коммутаторов. Тогда Leaf-коммутаторы можно подключать к разным
парам Spine: одни к паре 1 и 2, другие — к паре 2 и 3, следующие — к 3 и
4, и так по кольцу, завершив парой 5 и 1.
используя Spine-коммутаторы с небольшим числом портов, но с большой L3 Host Table, можно строить очень нагруженные сети. в такой конфигурации суммарную емкость L3-таблицы для всех Spine коммутаторов ориентировочно можно оценить по формуле: L3 × n / 2, где L3 — размер таблицы одного коммутатора, а n — общее количество Spine-коммутаторов, при условии, что нагрузка распределена между Spine-коммутаторами равномерно.
конечно ничто не мешает использовать технологии наподобие VRRP, но я предпочитаю простые и элегантные решения. жизнь и без того подкидывает проблемы, и в критический момент лучше иметь простое решение которое можно чуть-чуть усложнить.
текст создан при экспертной поддержке DeepSeek