Перейти к содержимому
Калькуляторы

seagull

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    178

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем seagull

  1. Опубликовано · Жалоба на ответ

    Но такие вопрос как связан брас и аннамберед - не раскрыт. Это совершенно разные темы. :-)
    Да, в этой теме плаваю, согласен.

    Аннамберед - применяется на агрегации при влан-на-клиента? то есть - сколько клиентов, столько виртуальных интерфейсов? А я где-то видел максимальное количество этих SVI на каталистах, и оно было не такое уж и большое? или SVI тут не причем?

     

    А насчет браса - не понятно, а чем он занят, если у нас IPoE, без всяких pppoe, l2tp и прочее? Именно шейпингом-биллингом? Значит в него нужно все по L2 сливать, а не терминировать вланы на агрегации?

  2. Опубликовано · Жалоба на ответ

    1. Да не обязательно 3526, их сейчас поди хватает, которые IMP binding умеют. По любому мыльницу не поставишь.

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

     

    2. резать полосы - в смысле трафик шейпить? а не надо его резать на 3526, пусть его режет в ядре роутер. Биллить - да, роутер сливает нетфлов на писюк с биллингом. Или это не кошерно?

    Насчет браса от доллара на клиента - это опять же вопрос масштабов сети, что-то я брасов за 2000 баксов не видел. ;)

     

    Инвестиции на 5-7 лет не понять простому оператору из домушников. Они и не планируют так долго жить.
    Да куда уж нам, сиволапым. Вы-то наверное родились в датацентре...

     

    Мое видение проблемы - ставяться на доступ свитчи типа 3526, на которых делается привязка IP-MAC-PORT binding
    А вы пробовали?

    Техподдержка спасибо сказала?

    А абоненты запищали от восторга?

    Честно говоря - пока нет, только планируем. Какие подводные камни? Смена MAC у юзеров - ну это понятно. А что еще?

     

  3. Опубликовано · Жалоба на ответ

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

    Ну это все понятно, но смысл вопроса не в этом. Я не говорю, что все вокруг дураки, а я один умный, наоборот - я хочу понять, в чем я заблуждаюсь?

  4. Опубликовано · Жалоба на ответ

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

    Мое видение проблемы - ставяться на доступ свитчи типа 3526, на которых делается привязка IP-MAC-PORT binding некоей самописной софтиной, выбирающей данные из биллинга, по этим же MAC адресам, забитым в биллинг, DHCP раздает IP адреса. На этом же доступе через ACL режется всякая гадость типа нетбиоса. :) На свитч доступа, или на группу, даем один VLAN. Ну агрегация - понятно как обычно, роутит между VLANами со свитчей доступа. В ядре - у нас уже все чистенько, каждый адрес привязан к пользователю, биллим их через netflow.

     

    Предполагаю, что не все так гладко, и где-то есть подставы. Не понимаю - где? Единственный минус который вижу - что LAN трафик не идет через ядро, и его нельзя четко контролировать, но это, мне кажется, проблема не большая.

    Объясните, чем плоха такая схема?

  5. Опубликовано · Жалоба на ответ

    Написал скрипт для управления Ip/Mac/Port binding, но думаю тут над одним вопросом - когда делать save на свитче? Каждый раз при прописывании правил - нехорошо вроде, потому как сохранение - это секунд 30, и если автоматом на свитч несколько клиентов разом будут прописыватся, то последствия будут непредсказуемые. да и ресурс флеша на запись не вечный вроде. Проходить кроном по свитчам раз в несколько часов, и делать сейв - при неожиданной перезагрузке свитча данные потеряются, глюки ловить умучаешься. Коллеги, как вы решаете такие проблемы?

  6. Опубликовано · Жалоба на ответ

    Вот есть старенькая fujikura 30 - народ постоянно жалуется, что не варит нифига - то зеркало грязное, то еще что. А может - со скалывателем проблема.

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

    Денег к сожалению не много.

    Где могут сделать нормально? Сами в Москве.

  7. Опубликовано · Жалоба на ответ

    опять же оффтоп, но просто интересно: как пользователи подключаются по VDSL, если модемов нет? ;)

     

    По сабжу: у нас портировали ПО на несколько VDSL-бордов от Ikanos и они нам прислали CO, чтобы тестировать железяки. Так там в самом CO можно было посмотреть параметры линии.

    Ну, модемы периодически появляются, нодо только момент ловить :)

     

    А ПО - это не то, не таскать же монтажникам за собой всю эту хрень... Нам бы тестер, причем даже особые навороты не нужны...

  8. Опубликовано · Жалоба на ответ

    Оффтоп конечно, но вы лучше скажите где вы вдсл2 железки покупаете? Я уже пол года четыре модема купить не могу :(

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

  9. Опубликовано · Жалоба на ответ

    Вот столкнулся с такой проблемой - дофига пользователей в частном секторе подключено по vdsl, а тестирование линии - только на тупой обрыв. Хочется прикупить что-нибудь, но не слишком дорого при этом. :)

    Кто чем пользуется?

  11. Опубликовано · Жалоба на ответ

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

    А реально чем пользуетесь? Удалось выбрать что-то удобное?

  12. Опубликовано · Жалоба на ответ

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

    Поделитесь пожалуйста опытом...

  13. Опубликовано · Жалоба на ответ

    Ага, время обновления разное, однозначно, в зебре более старое, чем в bgpd.

    В общем, понятно, где копать - да и зебра странно себя ведет, я в zebra.conf прописал

    log file /etc/quagga/zebra.log

    послал зебре HUP, а она - ноль эмоций, ничего не пишет в лог...

    А killall zebra - это для нее мягко будет? :)

     

  14. Опубликовано · Жалоба на ответ

    Ага, неправильный:

    xxx# show ip route 62.16.32.0
Routing entry for 62.16.32.0/19
  Known via "bgp", distance 20, metric 0, best
  Last update 07:33:42 ago
  * 77.94.166.189, via eth1.720

     

    А почему?

    Я понимаю, что нужно вдумчиво курить мануал кваги, просто надо сейчас, а я до этого места не докурил еще... :(

  16. Опубликовано · Жалоба на ответ 

    xxx# sh ip bgp 62.16.32.0
BGP routing table entry for 62.16.32.0/19
Paths: (3 available, best #3, table Default-IP-Routing-Table)
  Not advertised to any peer
  47923 47923 47923 29226 12389 41938 15640
    83.69.196.9 from 83.69.196.9 (217.67.176.58)
      Origin IGP, localpref 100, valid, external
      Community: 0:44237 8342:1001
      Last update: Tue Apr 27 14:21:43 2010

  28809 12389 41938 15640
    77.94.166.189 from 77.94.166.189 (81.26.144.2)
      Origin IGP, localpref 100, valid, external
      Community: 28809:3 28809:8631
      Last update: Tue Apr 27 14:21:19 2010

  28809 12389 41938 15640
    77.94.166.5 from 77.94.166.5 (81.26.144.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 28809:3 28809:8631
      Last update: Tue Apr 27 14:21:16 2010

     

    LocalPref то на них одинаковый, зачем его поднимать?

    И на 77.94.166.5 аттрибут стоит best, а в таблице:

     

    root@xxx:~# ip r |grep '62.16.32.0'
62.16.32.0/19 via 77.94.166.189 dev eth1.720  proto zebra

  17. Опубликовано · Жалоба на ответ

    Прошу сразу не пинать, с квагой и BGP только начал знакомится.

    Вопрос такой - есть у нас 2 апстрима, основной и резервный соответственно, через резервного трафик не пускается препендами.

    Но поскольку через резервного прова все-таки есть более короткие маршруты, есть они и в таблице машрутизации:

    root@xxx:/etc/quagga# ip r |grep 'eth0.719' |wc -l
3712

    А основной траф идет через другого:

    root@xxx:/etc/quagga# ip r |grep 'eth1.720' |wc -l
313879

    Понадобилось через 2 прова подключить канал на MSK-IX. BGP сессию прописали, анонсы с MSK-IX приняли.

    Смотрим роуты:

    xxx# sh ip bgp neighbors 77.94.166.5 routes
BGP table version is 0, local router ID is 10.0.0.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*> 62.16.32.0/19    77.94.166.5                            0 28809 12389 41938 15640 i
*> 62.16.64.0/19    77.94.166.5                            0 28809 25308 2820 i
*> 62.16.72.0/24    77.94.166.5                            0 28809 8744 2820 2820 2820 2820 2820 2820 i
*> 62.21.0.0/17     77.94.166.5                            0 28809 3327 24724 13110 13110 i
*  62.29.128.0/17   77.94.166.5                            0 28809 3327 8938 8938 i
*  62.32.64.0/20    77.94.166.5                            0 28809 44436 i

    Видим best маршруты, помеченые > - я так понимаю, они и должны писатся в таблицу маршрутизации через 77.94.166.5?

    Однако таких маршрутов там нет...

    root@xxx:/etc/quagga# ip r |grep '77.94.166.5' |wc -l
0

     

    Кто виноват, и что делать?

  18. Опубликовано · Жалоба на ответ

    Вот возник такой вопрос - сейчас популярен пиринг локальных сетей на точках типа HOME-IX, и т.д.

    Но каким образом оно делается, если вся адресация в локалках как правило на интранет-адресах, то есть, адресные пространства в разных локалках могут запросто пересекатся? Или использование адресных блоков как-то согласуется, например, на точках обмена?