[lm]

Есть два BRAS из ESR10k, на них раскиданы вланы доступа по схеме влан-на-свитч.

ip unnumbered привязано к lo, на котором висит ip с маской /32, для каждого BRAS свой.

Клиентам выдается привязанный к порту по opt82 ip (динамического пула нет) и

широкая маска /16 для "серых" ip или меньшая, но тоже широкая, для "белых".

На arp-запрос отвечает тот BRAS, на который заведен влан (причем не важно, висит ли на этом bras запрошенный ip).

За счет этого ip клиента не зависит от того, к какому bras он подключен.

В ядро брасы отдают по ospf маршрут на каждого клиента.

 

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

 

Существует-ли вариант, чтобы оба браса работали параллельно и самобалансировались, как на PPPoE, когда более нагруженный bras просто подтупливает с выдачей pado и

клиент коннектится к более шустрому?

[catalist]

мне тоже интересно, но думаю что нет решения.

[buckethead]

Существует-ли вариант, чтобы оба браса работали параллельно и самобалансировались, как на PPPoE, когда более нагруженный bras просто подтупливает с выдачей pado и

клиент коннектится к более шустрому?

Можно сделать по принципу -- какой первый BRAS ответит DISCOVER абоненту. Но тут одна тонкость есть: Access-Request будут слать оба BRAS, надо чтобы RADIUS/биллинг умели как-то с этим жить.

[bomberman]

Первое что пришло в голову, раскидать абонентов на уровне логики в биллинге. Т.е. авторизировать абонента на каком то одном БРАС-е, за которым закреплён абонент. При аварии чтоб биллинг отвечал для абонента на работающем БРАС-е.