ilili Опубликовано 11 декабря, 2013 (изменено) · Жалоба под NAT лучше взять нормальный сервак + *nix + толковый тюнинг. ISG делайте на ASR1002 + еще SCE8000 = агонь и почёт. Не надо PPPoE, забудьте. Надо делать, чтобы клиент воткнул шнурок в свою любую железку, получил IP адрес (один порт = один адрес, независимо от того, что подключать на стороне клиента) и пошел в Интернет, без всяких головняков с вводами логинов-паролей и прочих "сложных" в настройке вещей ) Про Option82 вам правильно подсказали, передавайте на dhcp сервер хостнейм свитча, порт и мак абонента. DHCP делайте на вендорном CNR или же, если денег не останется - на ISC DHCP. Выдали адрес клиенту, в snooping binding он появился (на час), а в dhcp сервере лизу удаляйте, чтобы клиент смог получить этот же ip адрес на любом другом девайсе у себя дома. Удачи вам в ваших начинаниях, делайте сразу нормально. Изменено 11 декабря, 2013 пользователем ilili Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 11 декабря, 2013 · Жалоба Лучше сделать QinQ и авторизвать/выдавать адрес по vlanid:vlanid. Таким образом будет изумительная изоляция абонентов и централизация доступа. В таком случий все MAC адреса протащим по всей сети до БРАС-а? и пропускная способность БРАС-а должна быть соответствующая, т.е. получается дорого?. У ASR1000 есть печальки относительно "IPoE": http://www.cisco.com...14-628D0C8AC8F8 , IPoE subscribing over Q-in-Q он не умеет У ASR9000 всё куда лучше. По ссылке я так понял что ASR1000 не умеет работать с L3 connected абонентов, а в случае L2 connected не должно быть проблем или я что не так понял? Касательно ASR9000 к сожалению не поддерживает учет трафика. Если будет много оптики, то сводить все в центр с узлов, которые делают заворот в SVLAN. Т.е. в пределах L2-аггрегирующего узла vlan'ы уникальные, а дальше в ябре уже не важно. Для транзита можно отключать mac-learning. Если планируется кольцо по городу с несколькими выходами в ядро, то лучше использовать MPLS. Таблица мак-адресов на современных коммутаторах достаточно большая - даже с запасом на коллизии. Предлагаю сделать звезду: В центре два X670 в стэке, к ним по два волокна с узлов аггрегации десятками SFP+ DGS-3420-28SC - их можно тоже в стэк ставить. А дальше уже кольца на DES-3200. Останется придумать план по распределению vlan в одном сегменте или кольце. У меня был опыт с DGS-3627G/DES-3200-28/SE100 3 года назад рисовал хитрую схему с адресацией вланов, в которой влан на порту формировался так: aabb, где aa - это последний октет ip-адреса, а bb - номер порта на коммутаторе (ограничение: 39 коммутаторов в кольце и до 99 портов на коммутаторе) или наоборот (тогда до 99 коммутаторов и до 38 портов на каждом - мы использовали не более 24-х портов модели). Второй бонус использования mgmt vlan default в том, что на 3627, где делали qinq при помощи double_vlan, мы приземляли управление кольцом и дальше по L3 отдавали в ядро. на кольце использовали функцию vlan_trunk, чтобы руками создавать на 3200 только те вланы, которые на нем присутствуют... [ipoe]core#sh subscribers TYPE CIRCUIT SUBSCRIBER CONTEXT START TIME -------------------------------------------------------------------------------- clips 2/3 vlan-id 37:333 clips 1 f8:1a:67:71:22:2b ipoe Nov 14 10:39:35 clips 2/3 vlan-id 38:311 clips 1 f0:7d:68:82:4a:0f ipoe Nov 14 10:39:35 clips 2/3 vlan-id 37:1633 clips f0:7d:68:82:53:b7 ipoe Nov 14 10:39:35 clips 2/3 vlan-id 40:1514 clips cc:b2:55:92:b1:d9 ipoe Nov 14 10:39:35 clips 2/3 vlan-id 33:619 clips 1 28:10:7b:ee:6d:e5 ipoe Nov 14 10:39:36 clips 2/3 vlan-id 31:1028 clips 64:70:02:62:0c:fb ipoe Nov 14 10:39:36 clips 2/3 vlan-id 36:212 clips 1 cc:b2:55:92:b5:1b ipoe Nov 14 10:39:36 clips 2/3 vlan-id 42:1014 clips 34:08:04:d2:d9:d5 ipoe Nov 14 10:39:36 clips 2/3 vlan-id 30:1033 clips f8:1a:67:49:32:e9 ipoe Nov 14 10:39:37 clips 2/3 vlan-id 33:305 clips 1 f8:1a:67:49:52:f1 ipoe Nov 14 10:39:37 clips 2/3 vlan-id 42:2122 clips 34:08:04:d5:30:81 ipoe Nov 14 10:39:37 clips 2/3 vlan-id 33:1809 clips 34:08:04:d2:d2:09 ipoe Nov 14 10:39:38 clips 2/3 vlan-id 31:1628 clips b8:88:e3:af:34:8c ipoe Nov 14 10:39:38 clips 2/3 vlan-id 40:523 clips 1 2c:41:38:5f:c8:2f ipoe Nov 14 10:39:38 clips 2/3 vlan-id 42:612 clips 1 a0:f3:c1:56:e4:f9 ipoe Nov 14 10:39:38 возьмем последний: vlan-id 42:612 верхний тэг 42: значит подсеть управления коммутаторами 10.4.42.0/24 нижний тэг 612 - это значит последний октет 12 и полный адрес коммутатора 10.4.42.12 а 6 означает номер порта. очень удобно! все конфиги генерируются скриптом только исходя из ip-адреса коммутатора. на брасе также скриптом генерируется портянка: port ethernet 2/3 no shutdown encapsulation dot1q dot1q pvc 30 encapsulation 1qtunnel dot1q pvc on-demand 30:102 service clips dhcp context ipoe dot1q pvc on-demand 30:103 service clips dhcp context ipoe dot1q pvc on-demand 30:104 service clips dhcp context ipoe dot1q pvc on-demand 30:105 service clips dhcp context ipoe dot1q pvc on-demand 30:106 service clips dhcp context ipoe dot1q pvc on-demand 30:107 service clips dhcp context ipoe dot1q pvc on-demand 30:108 service clips dhcp context ipoe dot1q pvc on-demand 30:109 service clips dhcp context ipoe dot1q pvc on-demand 30:110 service clips dhcp context ipoe dot1q pvc on-demand 30:111 service clips dhcp context ipoe ..... service clips dhcp context ipoe dot1q pvc on-demand 31:826 service clips dhcp context ipoe dot1q pvc on-demand 31:827 service clips dhcp context ipoe dot1q pvc on-demand 31:828 service clips dhcp context ipoe dot1q pvc on-demand 31:829 service clips dhcp context ipoe dot1q pvc on-demand 31:830 service clips dhcp context ipoe dot1q pvc on-demand 31:902 service clips dhcp context ipoe dot1q pvc on-demand 31:903 service clips dhcp context ipoe dot1q pvc on-demand 31:904 service clips dhcp context ipoe В приложении к посту альфа-версия такой конфигурации... ipoe.pdf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 12 декабря, 2013 · Жалоба Ну допустим каждому клиенту отдельный VLANX:VLANY На BRAS каждому клиенту по интерфейсу чтоли? Или как? Как давать абоненту реальный IP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 декабря, 2013 · Жалоба PPPOE нафига нужен тут? Время его безвозвратно ушло Да никуда оно не ушло. Если вы сделали IPoE на пару десятков тысяч сабскрайберов, то это вообще ни о чём. В IPoE есть проблемы с резервированием брасов и перетеканием/балансировкой сессий, есть нюансы в dual-stack'е (которых нет в ppp, ибо v4 и v6 согласовывается в рамках одной и той же сессии) И кстати, DSL=PPP(oE) это стереотип. На DSL-е точно также можно делать IPoE (на некоторых дсламах можно сделать vlan-per-user, где-то есть и opt82). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 12 декабря, 2013 · Жалоба Предлагаю сделать звезду: В центре два X670 в стэке, к ним по два волокна с узлов аггрегации десятками SFP+ DGS-3420-28SC - их можно тоже в стэк ставить. А дальше уже кольца на DES-3200. Останется придумать план по распределению vlan в одном сегменте или кольце. т.е. центр занимается только агрегации, а терминацию вы предлагаете делать на BRAS SE100/600?, но у автора только ASR1002X. На BRAS каждому клиенту по интерфейсу чтоли? Или как? в случае QinQ наверно Ambiguous vlan: http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html#wp1068909 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 12 декабря, 2013 · Жалоба На BRAS каждому клиенту по интерфейсу чтоли? Или как? в случае QinQ наверно Ambiguous vlan: http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html#wp1068909 А как же быть с этим - Only PPPoE is supported on ambiguous subinterfaces. Standard IP routing is not supported on ambiguous subinterfaces. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 12 декабря, 2013 · Жалоба На BRAS каждому клиенту по интерфейсу чтоли? Или как? в случае QinQ наверно Ambiguous vlan: http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html#wp1068909 А как же быть с этим - Only PPPoE is supported on ambiguous subinterfaces. Standard IP routing is not supported on ambiguous subinterfaces. Вот-вот, только что проштудировал доку. Как кстати бороться с незаконными подключениями? В случае с PPPoE хоть как-то возлагается на абонента ответственность за хранение пароля доступа, а в случае авторизации по порту - любой пионер воткнул хаб, проснифал мак и вперед? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 декабря, 2013 · Жалоба В случае с PPPoE хоть как-то возлагается на абонента ответственность за хранение пароля доступа, а в случае авторизации по порту - любой пионер воткнул хаб, проснифал мак и вперед? По аналогичной схеме можно и пароль проснифать. Включить соседа в свой pppoe-server и посмотреть его пароль. Безопасность подключений в IPoE может быть реализована так: portal+порт-свитча+мак. Т.е. если абонент меняет mac-адрес, то нужно один раз авторизоваться на портале. Чтобы украсть чужое подключение, придётся занять чужой порт и это быстро обнаружится(т.к. неработающий абонент пожалуется) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 12 декабря, 2013 · Жалоба IP Source Guard либо ACL на порту. Всё, никуда абонент после этого не денется. Можешь хоть обснифаться, толку ноль. Я лично вообще блокирую даже анонсы ARP не своего IP с абонентского порта. Тут схем тоже несколько может быть, как всегда :) А ответсвенность за "монтажники перепутали порты при смене свитча" разумеется лежит на вас. Сейчас люди настолько пошли необразованные в плане "как это работает", что можно не бояться сниферов. Тарифы все примерно одинаковые, скорости огромные - смысла нет заморачиваться даже. Я проводил эксперимент, в сегменте на полтысячи абонентов отключена автоматическая привязка ip, arp к порту, ставь любой - работай. За изменениями адресов на уровне L3 следит отдельная программа. Так вот за год в этом сегменте не было ни одной смены IP. Просто все получают адреса по DHCP и работают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 декабря, 2013 (изменено) · Жалоба И кстати, DSL=PPP(oE) это стереотип. На DSL-е точно также можно делать IPoE (на некоторых дсламах можно сделать vlan-per-user, где-то есть и opt82). Далеко не на всех, это раз. Второе - это не нужно, унификация в данном случае приносит больше профита чем наличие IPoE в DSL. И не забывайте, по большей части проблема резервирования DSL связана с отказом DSLAM а не с BRAS. В IPoE есть проблемы с резервированием брасов и перетеканием/балансировкой сессий, есть нюансы в dual-stack'е (которых нет в ppp, ибо v4 и v6 согласовывается в рамках одной и той же сессии) Если в нагруженной сети откажет 1 BRAS PPPOE из 4-х, то есть вероятность что не вытянут остальные доп. нагрузку. Тут вопрос скорей эмпирический: "Есть ли возможность резервирования". Да она есть, но на том же плохом уровне что и IPOE BRAS + VRRP. Ну и к моменту когда кому-либо реально вот так рабочий дуалстек понадобится - думаю уже оно будет работать. Слышал что у ASR с этим проблемы, а есть ли они у MX? PS. Наличие PPPOE/PPPOA обычно подразумевает наличие CPE у абонента. В случае с xDSL/xPON это суперлогично. А вот с 100Base-T я бы не сказал что у всех есть роутеры/вифи... Изменено 12 декабря, 2013 пользователем DVM-Avgoor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 12 декабря, 2013 · Жалоба Ну допустим каждому клиенту отдельный VLANX:VLANY На BRAS каждому клиенту по интерфейсу чтоли? Или как? Как давать абоненту реальный IP? на BRAS интерфейс поднимется только после прохождения AAA. В зависимости от от ваших предпочтений можете дать белый адрес, можете дать серый и повесить NAT policy, а если на порту не должно быть абонента, то дайте ему серый адрес и перенаправление на заглушку, где предложить связаться с техподдержкой (вдруг монтажник/ремонтник переткнул в другой порт абонента). С DHCP легко наладить автоматическую привязку - достаточно у dhcp-сервера спросить кому сейчас выдан адрес с которого производится активация... PPPOE нафига нужен тут? Время его безвозвратно ушло Да никуда оно не ушло. Если вы сделали IPoE на пару десятков тысяч сабскрайберов, то это вообще ни о чём. В IPoE есть проблемы с резервированием брасов и перетеканием/балансировкой сессий, есть нюансы в dual-stack'е (которых нет в ppp, ибо v4 и v6 согласовывается в рамках одной и той же сессии) И кстати, DSL=PPP(oE) это стереотип. На DSL-е точно также можно делать IPoE (на некоторых дсламах можно сделать vlan-per-user, где-то есть и opt82). В SE можно авторизовать v4 и v6 в рамках одного SVID:CVID или mac-адреса на PVC и абонент по обоим протоколам получит один тариф и одно ограничение скорости. Резервирование можно сделать уменьшением времени лизы (на SE продление DHCP-сессии аппаратно происходит) вплоть до 5 минут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 декабря, 2013 · Жалоба А вот с 100Base-T я бы не сказал что у всех есть роутеры/вифи Сейчас? При поголовном наличии смартфонов/планшетов? Я бы сказал, что они есть почти у всех. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 декабря, 2013 · Жалоба Сейчас? При поголовном наличии смартфонов/планшетов? Это лишь ваше предположение. Дело в том что технология не требует наличия CPE, его отлично заменяет сетевая карта. Провайдеры конечно в случае PPPOE обычно еще и роутер в аренду / в подарок выдают, но зачем? Я понимаю зачем он был раньше, когда вся авторизация была на событиях BRAS PPPOE/PPTP, да радиус-биллинги связки готовые были. Но это все прошло, сейчас тот же Juniper MX в качестве BRAS прозрачно для биллинга и радиуса поднимает IPoE сессии. Зачем городить костыли та? От наличия инкапсуляций да упаковки кадров LAN-протокол WAN-ом не станет, на качественно новый уровень не взлетит. Зачем жопу рвать? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 декабря, 2013 · Жалоба Дело в том что технология не требует наличия CPE, его отлично заменяет сетевая карта. Можно подумать, что для PPPoE иначе. Там также не требуется CPE и его отлично заменяет сетевая карта. Разница только в том, что нужно создать PPPoE-подключение. Что занимает полминуты и доступно любому. Зачем городить костыли та? Ну например мне удобно то, что абонент не привязан к порту коммутатора. Как следствие — все коммутаторы настроены идентично, никаких специальных привязок по MAC не требуется и подключаться абонент может с любого места. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zstas Опубликовано 12 декабря, 2013 · Жалоба а когда дома 2 планшета и 3 смартфона, как без CPE обойтись? :) роутеры есть у большинства клиентов, а им пофик, pppoe у вас или ipoe. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 декабря, 2013 · Жалоба Можно подумать, что для PPPoE иначе. Там также не требуется CPE и его отлично заменяет сетевая карта. Э. Речь шла о xDSL. Там сессионность и p-t-p связаны с архаикой коммутируемых линий. Я не спорю, в эзернете можно многое нагородить, как бы только незачем. Ну например мне удобно то, что абонент не привязан к порту коммутатора. Как следствие — все коммутаторы настроены идентично, никаких специальных привязок по MAC не требуется и подключаться абонент может с любого места. Ну и как следствие отсутствие порядка в линках. Можно и мыльницы вместо коммутаторов использовать. "Мне удобно" посчитать в цифрах сложно. Оператор должен исходить из многих факторов. Применение дополнительной инкапсуляции на готовом ETH+TCP/IP решении ничем не оправдано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 12 декабря, 2013 · Жалоба Ну например мне удобно то, что абонент не привязан к порту коммутатора. Как следствие — все коммутаторы настроены идентично, никаких специальных привязок по MAC не требуется и подключаться абонент может с любого места. Ну и как следствие отсутствие порядка в линках. Можно и мыльницы вместо коммутаторов использовать. "Мне удобно" посчитать в цифрах сложно. Оператор должен исходить из многих факторов. Применение дополнительной инкапсуляции на готовом ETH+TCP/IP решении ничем не оправдано. Тут вопрос "крупности" провайдера. Вон Билайн до сих пор L2TP предоставляет, потому что скупал сети чужих операторов, которые сделаны непонятно на чем. Когда используется PPPoE нет многих проблем. Резервирование - не проблема, ставите сколько угодно и где угодно сервера доступа и готово. Коммутаторы - любые, если сгорел порт, просто перетыкают абонента в другой. Нужно абонентам сменить адреса - делов на пару секунд, пока их роутеры переподключатся. Нужно отключить абонента от сети - так же проблем нет. Нужно найти где абонент? по маку легко определить к какому коммутатору и порту он подключен. Теперь интернет из розетки - абонент привязан к своему порту, в отличие от PPPoE нельзя просто так зафильтровать мусор от абонента на транспортной сети. Так же требуется тянуть все в центр, в отличии от PPPoE нельзя поставить кучу серверов доступа на выносных узлах, т.к. начнутся проблемы с маршрутизацией, которые на микротике решаются легко, а на всяких цисках и ериксонах сложно. Если монтажники постоянно путают порты - будет неразбериха. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 декабря, 2013 · Жалоба IPOE BRAS + VRRP. Вы сами-то это собирали? Откуда второй брас(который vrrp stand-by) узнает о политике, которую нужно применять к абоненту? В случае с xDSL/xPON это суперлогично. А вот с 100Base-T я бы не сказал что у всех есть роутеры/вифи... Да ни аргумент ни разу. Узнайте у ваших подключенцев сколько % сейчас с картами, сколько с роутерами. У меня среди знакомых нет ни одного, у кого нет CPE(за исключением парочки, у которых дома комп-сервер-роутер, но это особые случаи) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
viver Опубликовано 12 декабря, 2013 · Жалоба Ну например мне удобно то, что абонент не привязан к порту коммутатора. А мне это очень не удобно. У нас IPoE, и при звонке абонента очень лего понять в чем дело с одной странички: есть ли линк, изучен ли мак, передаются ли данные вообще, посмотреть график порта за день/неделю/месяц. Все это, и отсутствие логина/пароля помогает анализировать проблемы очень быстро. Что бы я делал без привязки к порту я не знаю... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
viver Опубликовано 12 декабря, 2013 · Жалоба В качестве иллюстрации моих слов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 декабря, 2013 · Жалоба Вы сами-то это собирали? Откуда второй брас(который vrrp stand-by) узнает о политике, которую нужно применять к абоненту? Нет не собирал. А что мешает ему получить ее так же из радиуса? Да ни аргумент ни разу. Узнайте у ваших подключенцев сколько % сейчас с картами, сколько с роутерами. У меня среди знакомых нет ни одного, у кого нет CPE(за исключением парочки, у которых дома комп-сервер-роутер, но это особые случаи) У нас есть социальные учреждения, где вообще роутеров нет и не будет. Но это частный случай. У каждого по-разному, вопрос в том что технология не обязывает. Теперь интернет из розетки - абонент привязан к своему порту, в отличие от PPPoE нельзя просто так зафильтровать мусор от абонента на транспортной сети. Так же требуется тянуть все в центр, в отличии от PPPoE нельзя поставить кучу серверов доступа на выносных узлах, т.к. начнутся проблемы с маршрутизацией, которые на микротике решаются легко, а на всяких цисках и ериксонах сложно. Если монтажники постоянно путают порты - будет неразбериха. Я вас прошу, давайте без этого юношеского колхоза. Ни у кого из серьезных товарищей brasы по чердакам не распиханы. Мы не в Германии, где брас реально возле дома в коробке стоит. У нас централизация больше. Я просто однажды поработал с месяц в кабинете с ТП оператора у которого PPPOE и IPOE в эксплуатации. Это был адский ад, какие-то "ошибка №631" и так далее. А вот звонков с сегмента с IPOE было очень мало, но там и VPU. Оператор медленно но уверенно движется в IPOE, поддержка PPPOE+общий влна жрет его человеко/часы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 декабря, 2013 · Жалоба Что бы я делал без привязки к порту я не знаю... Это и на PPPoE можно проверить на порту. А порт определить либо по PPPoE+, либо по MAC-адресу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 декабря, 2013 · Жалоба Вы сами-то это собирали? Откуда второй брас(который vrrp stand-by) узнает о политике, которую нужно применять к абоненту? Нет не собирал. А что мешает ему получить ее так же из радиуса? В какой момент времени stand-by bras будет её получать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 декабря, 2013 (изменено) · Жалоба В какой момент времени stand-by bras будет её получать? В момент авторизации абонента, не? Я думаю тут основной момент не авторизация как раз. А как так сделать чтобы в нормальном состоянии БРАС не слушал запросы с чужих вланов. Тут надо искать, пытаться, а может и отказаться. Изменено 12 декабря, 2013 пользователем DVM-Avgoor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 декабря, 2013 · Жалоба DVM-Avgoor Ну вы попробуйте собирите, потом расскажите, ну или так догадаетесь, если подумать немного Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
