Cisco ASR1001-X IPoE BRAS

[KaYot 3 708]

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.

[Setevikcomua 5]

У нас работает АСР1006+RP2+esp20

НАТ + ПППОЕ для клиентов

вместо джуна мх80

пропускает он 20 гиг или 10 фул дуплекса всего

но нам хватает

потом можно поставить esp40

Відредаговано 2017-01-17 16:51:34 Setevikcomua

[wad1015 23]

 

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.

 

Может конфиги проще получаются, а не схема? Любая схема, при добавлении в нее элементов, всегда только усложняется.

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

[wad1015 23]

У нас работает АСР1006+RP2+esp20

НАТ + ПППОЕ для клиентов

вместо джуна мх80

пропускает он 20 гиг или 10 фул дуплекса всего

но нам хватает

потом можно поставить esp40

чей-то маловато 10 фул для есп20. у меня проц 20-го есп при 7 гиг фула загружен всего на 22%.

[KaYot 3 708]

 

 

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.

Может конфиги проще получаются, а не схема? Любая схема, при добавлении в нее элементов, всегда только усложняется.

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

В том то и дело. На тазиках при отдельном NAT-сервере BRAS-часть получается проще, меньше заморочек.

Плюс, тазик-терминатор+тазик-NAT пропустят больше трафика, чем 2 универсальных тазика работающих параллельно. Накладных расходов из-за conntrack-table и костылей BRASа меньше.

[Турист 12]

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

[l1ght 377]

 

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

 

вы только что ответили в прошлый год, путешественник во времени детекдет!

[KaYot 3 708]

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы )))

Нормальные IPOE-БРАСы умеют масштабироваться/резервироваться by design. Умер один - в течении минимального времени клиенты перетекли на соседний, никакой разницы с pppoe.

NAT-боксы резервируются стандартными средствами ОС, vrrp или вообще какой-нить ospf поднять между NASами и NATами. Ничего сложного.

[pavlabor 1 939]

CARP всему голова.

[fet4 46]

А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.

 

 

Как по мне это вообще единственный правильный вариант когда с трафиком работаешь в плотную. qos, шейпинг, nat и т.д. не реально сделать на одной тачке адекватными способами, приходится изощряться разными способами imq,ifb, маркировки, патчинги и т.д. а это уже костыли. А когда это разделено как минимум на 2 тачки, архитектура управления трафиком становится прозрачней и понятней в разы.

На железные решения пока смотрю косо т.к. голый Linux удовлетворяет почти полностью и в принципе стабилен, бывают конечно и приколы, например месяц назад NAT на 4.9 начал выпадать в кернел паник проработавши месяц, обновил на 4.14 стабилизировался.

 

Есть так же accel на 4.14 по стабильности пока не скажу только неделю ввел в эксплуатацию, на 3.18 работал хорошо.

[Турист 12]

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы )))

Нормальные IPOE-БРАСы умеют масштабироваться/резервироваться by design. 

 

Можно пример такого IPoE-браса? )) 

 

 

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

 

вы только что ответили в прошлый год, путешественник во времени детекдет!

 

Ну вот прикиньте, вкладка год уже открыта )

[l1ght 377]

 

 

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да? 

[Турист 12]

 

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да? 

 

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

[pavlabor 1 939]

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да?

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

Кто то ждет мессию, а кто то давно закрыл вопрос построив то что ему нужно.

А каждому нужно свое, потому что каждый находится на своей ступеньки эволюции понимания.

 

Биндинг мака на порт, который практикуют некоторый крупные провы это пик маразма.

Влан на пользователя, это с той же песни но там маразм сводится к утяжелению железа и растущей сложности в обслуживании.

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

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

 

Безусловно можно ждать мессию cisco super asr+++, megajuniper++++, но он не придет, от слова никогда.

Потому что сделать такое безусловно можно, купить такое нельзя.

 

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

Поднялся порт, запускается скрипт который причесывает событие.

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

Сложно это сделать?

С какого это перепугу?

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

 

А если на мыльницах, то мивина ваше все.

[Турист 12]

 

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да?

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

Кто то ждет мессию, а кто то давно закрыл вопрос построив то что ему нужно.

А каждому нужно свое, потому что каждый находится на своей ступеньки эволюции понимания.

 

Биндинг мака на порт, который практикуют некоторый крупные провы это пик маразма.

Влан на пользователя, это с той же песни но там маразм сводится к утяжелению железа и растущей сложности в обслуживании.

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

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

 

Безусловно можно ждать мессию cisco super asr+++, megajuniper++++, но он не придет, от слова никогда.

Потому что сделать такое безусловно можно, купить такое нельзя.

 

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

Поднялся порт, запускается скрипт который причесывает событие.

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

Сложно это сделать?

С какого это перепугу?

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

 

А если на мыльницах, то мивина ваше все.

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр? 

[KaYot 3 708]

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

[pavlabor 1 939]

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

Всем доброго времени.

Кто что может сказать про сей девайс? Насколько он хорош как IPoE BRAS? Есть ли какие-то неприятные моменты? Хотелось бы, чтоб отозвались те, у кого есть опыт эксплуатации, либо те, кто по каким-то тем или иным причинам отказались в пользу другого решения.

[pavlabor 1 939]

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

 

У меня умеют, часть серверов отключается автоматически на ночь, при перегрузках автоматически в водится в работу резервы.

Более того у меня в городе три площадки, на который находится не один джунипер, а несколько софтовых роутеров.

При чем, резервирования питания идет только на коммутацию, при пропадании питания сервера автоматом выключаются, а пользователи переруливаются на обслуживания другими площадками.

В связи с этим там стоит упса с двумя автомобильными акумами по 55ач и работы хватает на пару суток без электропитания.

Теперь расскажи мне сказку про Киевстар, мега сиську, два контейнера с акумами и дизель генератором... патаму что...

 

Идеология резервирования/масштабирования построена на карпе.

Сектор может обслуживается от одного до любого количества роутеров.

 

Поэтому с помощью карпа я решаю не только горячее резервирование/масштабирование IPoE-браса а и вопрос бесперебойного питания.

Відредаговано 2018-01-10 08:59:56 pavlabor

[Турист 12]

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

 

5 минут это уже далеко не горячий резерв. Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы. Кто должен отслеживать работоспособность браса и по каким критериям?

В общем костыли все это.

[pavlabor 1 939]

Переход осуществляется мгновенно.

Вот тебе пример состояние интерфейсов на трех брасах на каждой из площадок

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: Pavlabor
        options=303<RXCSUM,TXCSUM,TSO4,TSO6>
        ether 00:1b:21:b3:2a:94
        inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129
        inet 194.146.181.130 netmask 0xffffffff broadcast 194.146.181.130 vhid 130
        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 132 parent interface: igb0
        carp: MASTER vhid 129 advbase 1 advskew 50
        carp: BACKUP vhid 130 advbase 1 advskew 150
        carp: BACKUP vhid 245 advbase 1 advskew 150

 

 

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: Pavlabor
        options=303<RXCSUM,TXCSUM,TSO4,TSO6>
        ether 00:1b:21:66:92:d4
        inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130
        inet 194.146.181.129 netmask 0xffffffff broadcast 194.146.181.129 vhid 129
        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 132 parent interface: igb0
        carp: MASTER vhid 130 advbase 1 advskew 50
        carp: BACKUP vhid 129 advbase 1 advskew 150
        carp: MASTER vhid 245 advbase 1 advskew 50

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

Висят два ип

  inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

и

  inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

Состяние на активном 194.146.181.129

 carp: MASTER vhid 129 advbase 1 advskew 50

на резерве

carp: BACKUP vhid 129 advbase 1 advskew 150

Балансировка идет путем выдачи в качестве дефаулта соответствующего IP.

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

 

я тупо выключаю первый брас без предупреждения пользователей

и состяние на втором брассе с

carp: BACKUP vhid 129 advbase 1 advskew 150

переходит в состяние

carp: MASTER vhid 129 advbase 1 advskew 150

 

carp генерит собственный мак для связки

поэтому потоки переруливаются практически мгновенно.

Клиенты смены даже не замечают, даже игровые сессии не разваливаются.

 

Время опроса можно выставлять на свое усмотрение, но 5 минут наверно нельзя... а может и можно. Не пробовал.

 

Это горячее резервирование/масштабирование именно IPoE-браса, на остальные печеньки можете не обращать внимания.

Відредаговано 2018-01-10 09:20:38 pavlabor

[Турист 12]

Переход осуществляется мгновенно.

Вот тебе пример состояние интерфейсов на трех брасах на каждой из площадок

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        description: Pavlabor

        options=303<RXCSUM,TXCSUM,TSO4,TSO6>

        ether 00:1b:21:b3:2a:94

        inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

        inet 194.146.181.130 netmask 0xffffffff broadcast 194.146.181.130 vhid 130

        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245

        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

        media: Ethernet autoselect (1000baseT <full-duplex>)

        status: active

        vlan: 132 parent interface: igb0

        carp: MASTER vhid 129 advbase 1 advskew 50

        carp: BACKUP vhid 130 advbase 1 advskew 150

        carp: BACKUP vhid 245 advbase 1 advskew 150

 

 

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        description: Pavlabor

        options=303<RXCSUM,TXCSUM,TSO4,TSO6>

        ether 00:1b:21:66:92:d4

        inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

        inet 194.146.181.129 netmask 0xffffffff broadcast 194.146.181.129 vhid 129

        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245

        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

        media: Ethernet autoselect (1000baseT <full-duplex>)

        status: active

        vlan: 132 parent interface: igb0

        carp: MASTER vhid 130 advbase 1 advskew 50

        carp: BACKUP vhid 129 advbase 1 advskew 150

        carp: MASTER vhid 245 advbase 1 advskew 50

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

Висят два ип

  inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

и

  inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

Состяние на активном 194.146.181.129

 carp: MASTER vhid 129 advbase 1 advskew 50

на резерве

carp: BACKUP vhid 129 advbase 1 advskew 150

Балансировка идет путем выдачи в качестве дефаулта соответствующего IP.

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

 

я тупо выключаю первый брас без предупреждения пользователей

и состяние на втором брассе с

carp: BACKUP vhid 129 advbase 1 advskew 150

переходит в состяние

carp: MASTER vhid 129 advbase 1 advskew 150

 

carp генерит собственный мак для связки

поэтому потоки переруливаются практически мгновенно.

Клиенты смены даже не замечают, даже игровые сессии не разваливаются.

 

Время опроса можно выставлять на свое усмотрение, но 5 минут наверно нельзя... а может и можно. Не пробовал.

 

Это горячее резервирование/масштабирование именно IPoE-браса, на остальные печеньки можете не обращать внимания.

 

Вы не путаете BRASы c обычными роутерами? Для браса должно быть понятие сессии с абонентом, там где хранится сессия - это и есть брас.

Вы каким образом на IPoE поднимаете сессию с абонентом?

Відредаговано 2018-01-10 10:23:21 Турист

[KaYot 3 708]

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

Вы чего-то явно не допонимаете. Вланы BRASами создаются динамически при получении первого пакета и присутствуют на коробках, нет никаких скриптов и костылей.

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

[Турист 12]

 

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

Вы чего-то явно не допонимаете. Вланы BRASами создаются динамически при получении первого пакета и присутствуют на коробках, нет никаких скриптов и костылей.

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

 

горячий резерв - это без разрыва абонентской сессии и потери пакетов.

Динамическое создание виланов это про линукс с аксель ппп? Я имел в виду аппаратные брасы. В asr1k нет никакой балансировки субскрайберов в принципе.

Відредаговано 2018-01-10 11:02:23 Турист

[KaYot 3 708]

 

 

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

Вы чего-то явно не допонимаете. Вланы BRASами создаются динамически при получении первого пакета и присутствуют на коробках, нет никаких скриптов и костылей.

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

горячий резерв - это без разрыва абонентской сессии и потери пакетов.

Динамическое создание виланов это про линукс с аксель ппп? Я имел в виду аппаратные брасы. В asr1k нет никакой балансировки субскрайберов в принципе.

SE и MX создают vlan-интерфейсы динамически, так же как и accel.

Резервирование без обрыва сессии между БРАСами это уже сильно крутая хотелка, зачем оно для ISP?

[pavlabor 1 939]

Вы не путаете BRASы c обычными роутерами? Для браса должно быть понятие сессии с абонентом, там где хранится сессия - это и есть брас.

Вы каким образом на IPoE поднимаете сессию с абонентом?

Возможно я смогу ответить на вопрос если вы уточните что в вашем понимании означает сессия в IPoE.