lm Posted July 31, 2017 Posted July 31, 2017 Есть два BRAS из ESR10k, на них раскиданы вланы доступа по схеме влан-на-свитч. ip unnumbered привязано к lo, на котором висит ip с маской /32, для каждого BRAS свой. Клиентам выдается привязанный к порту по opt82 ip (динамического пула нет) и широкая маска /16 для "серых" ip или меньшая, но тоже широкая, для "белых". На arp-запрос отвечает тот BRAS, на который заведен влан (причем не важно, висит ли на этом bras запрошенный ip). За счет этого ip клиента не зависит от того, к какому bras он подключен. В ядро брасы отдают по ospf маршрут на каждого клиента. В случае проблем с одним из брасов нужно перебросить все его вланы на оставшийся, например, скриптом. Существует-ли вариант, чтобы оба браса работали параллельно и самобалансировались, как на PPPoE, когда более нагруженный bras просто подтупливает с выдачей pado и клиент коннектится к более шустрому? Вставить ник Quote
catalist Posted August 3, 2017 Posted August 3, 2017 мне тоже интересно, но думаю что нет решения. Вставить ник Quote
buckethead Posted August 4, 2017 Posted August 4, 2017 Существует-ли вариант, чтобы оба браса работали параллельно и самобалансировались, как на PPPoE, когда более нагруженный bras просто подтупливает с выдачей pado и клиент коннектится к более шустрому? Можно сделать по принципу -- какой первый BRAS ответит DISCOVER абоненту. Но тут одна тонкость есть: Access-Request будут слать оба BRAS, надо чтобы RADIUS/биллинг умели как-то с этим жить. Вставить ник Quote
bomberman Posted August 4, 2017 Posted August 4, 2017 Первое что пришло в голову, раскидать абонентов на уровне логики в биллинге. Т.е. авторизировать абонента на каком то одном БРАС-е, за которым закреплён абонент. При аварии чтоб биллинг отвечал для абонента на работающем БРАС-е. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.