Имеется собственная AS с PI-адресами.
Коммутатор DGS-3627G подключен к 4-м BGP соседям, каждый их которых отдает только default (0.0.0.0) маршрут.
Какие есть варианты настроить балансировку входящего и исходящего трафика, если каналы до соседей разной толщины

Если только дефолты, то про про исходящую балансировку можно вообще не упоминать. Всё будет лететь в трубу с большим приоритетом. Входящий траф, в отличие от входящего, не так поддадется управлению, тут разве что препендами и комьюнити (узнавать у соседей их наличие).

Препендами и так уже частично регулирую входящий, а с коммунити сложно - слишком много соседей...
С исходящим что, совсем ничего нельзя поделать? ((
А как же weight, localpref, маршруты с указанным nexthop, частичное анонсирование prefixlist и им подобные штуки..?

Должен же быть какой-то вариант...

Может сотрудник D-link прокоментирует этот вопрос

ну weight, ну localpref... а маршрут то в итоге всего один, и называется он 0.0.0.0. Вернее их 4, каждому ты можешь назначить допустим localpref, а будет лучшим только один маршрут с наибольшим значением, и пойдет через него весь исходящий трафик.
По поводу остальных маршрутов и анонсов - так вроде как изначально озвучено что от пиров приходит только дефолт.

Хотя бы балансировку исходящего с помощью route-map не решить? Я имею ввиду что определенным подсетям указывать на каждого neighbor свой weight, разве так не получится?

Ну или на крайний случай разделить подсети на части и кажду группу PI-номеров посылать на каждого соседа отдельно. От соседей-же трафик будет распределятся сам (только препендами буду рулить). Так получится?

PBR - это пожалуйста, но тогда динамичность теряется.

Мне хоть как бы, вручную делить какие есть варианты?

Так вроде озвучили уже - PBR, т.е. в зависимости от адреса источника назначаем дефолт гейтвей того или иного пира. Только, насколько знаю, в д-линке PBR имеет приоритет по отношению ко всем остальным маршрутам (т.е. нет цыско-аналога set ip default next-hop). Поэтому если есть какие-то локальные роуты на коммутаторе, то они для PBR остаются побоку.

Хорошо, спасибо, буду пробывать.

А манипулируя записями в БД RIPE возможно повлиять на балансировку? Пока у нас на всех соседей прописаны одинаковые параметры.

Сам процесс маршрутизации к RIPE никакого отношения не имеет.

Нафига тогда там указывать, например, в объекте AS import и export записи с указанием pref и accept )

Это так, для информирования участников взаимодействия что у тебя, да как. Еще обычно там прописывают имеющиеся у тебя комьюнити (обычно это крупные операторы имеют). И повторюсь еще раз, к реальной маршрутизации это отношение не имеет, ибо коммутатор/маршрутизатор берет данные из конфига и получает от соседа, а не из БД RIPE.

балансировка "равнозначных" маршрутов в bgp задача очень не тривиальная (в большинстве нормальных случаев она не используется во избежании раздутия баз и возникновения петель)....
в вашем случае для получения условной исходящей балансировки, при условии что некст-хопами являются сами же пиры (а значит динамики не будет...) пропишите просто дефолтовую статику с одинаковыми метриками и разными весами, на толстый канал больше на тонкие поменьше...без всяких bgp...
А для входящей балансировки...bgp использовать вполне реально по договоренности с соседями...
что касается pbr то использовать его можно, но есть опасность, т.к. pbr все равно доступен ли next-hop или нет, он продолжает отрабатывать...

Т.е. Вы предлагаете анонсируемые соседями дефолт маршруты фильтровать, а вместо этого прописать свои ручками с нужной метрикой и весом?
Разве так будет распределятся исходящий? На сколько я понимаю (по опыту работы с CISCO маршрутизаторами), что весь исходящий трафик пойдет по пути с большим весом и никакой балансировкой тут не пахнет. Может я не прав? (вдруг у d-linkов фичи какие есть дополнительные)

Про балансировку входящего трафика Вы имеете ввиду community?

На счет PBR я прекрасно понимаю, что отказоустойчивость никакая, но например на CISCO можно оправшивать наличие next-hop по icmp с помощью sla и отключать нерабочие маршруты с помощью track. На D-Linkе возможно настроит что-нибудь подобное?

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

Давайте по порядку:
1) у вас есть 4 статических дефолта с ОДИНАКОВОЙ метрикой и РАЗНЫМИ весами
метрика - указывает на то, что маршруты равнозначные и можно выбрать любой
вес - указывает на то, как часто выбирать этот маршрут из прочих равных....

2) на первые 3 пира делаем веса X на последний Y т.е. последний пир будет выбираться чаще...чем первые 3

3) балансировка будет условной, т.к. если представить что на узкий канал начинает попадать часто посещаемый ресурс, то это не самая лучшая ситуация
поэтому надо внимательно, думать и пробовать прежде чем, что-то делать.

по поводу тракинга, вам ответят мои коллеги позднее, т.к. это не совсем моя компетенция, но тракинг тоже не самое лучшее решение...вдруг ресурс/служба мониторинга случайно стал недоступной?

мое лично мнение, чем проще, тем надежней...