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

M.Os

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    42

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

  • Посещение

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

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

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

    Добрый день!

     

    Господа поделитесь информацией кто чем считает трафик.

    Вводная:

    Есть Cisco 7600 RSP720-3C-GE

    есть 3 аплинка есть около 1 гбит сумарного трафика.

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

    Оказывается Src-only / Dest-only Microflow policer will not work, when NDE is configured.

    На практике это означает шейпить в 2 стороны вместе с Netflow не получается. Либо только в одну и всё хорошо, либо в обе, но до свидания netflow.

     

    Перечитано много мегабайт google.ru и cisco.com подружить их видимо не возможно. Если от шейпа отказаться не получается может надо чем то другим считать? Да и вопрос этот встал бы по любому в ближайшее время так как таблица netflow катастрофически приближается к отметке 100% utilization. Еще чуть чуть и приплыли. А считать хочется.

     

     

     

     

     

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

    Смотри. а если у меня на PPTP VPN используется отдельный префикс, скажем /22.

     

    И IP-адрес для каждой pptp сессии назначается биллингом, либо динамически (из пула адресов), либо статически (если у пользователя IP-адрес для VPN статически привязан в биллинге). То как мне с вышестоящего бордера маршрутизировать трафик до этих pptp абонентов?

    в случае когда за каждым bras закреплена подсеть - всё достаточно детерминировано, но в случае использования dns для распределения нагрузки, единственное что приходит в голову - это redistribute connected чз ospf/eigrp и т.п. на вышестоящий роутер.

    IGP засылаем коннектед и всё работает прекрасно.

     

  3. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

    Вот и началось

     

    $ host v3.cache.googlevideo.com

    v3.cache.googlevideo.com is an alias for v3.cache.l.google.com.

    v3.cache.l.google.com has address 212.188.7.22

     

    Это локальный ютубовский кеш в МТУ.

    Ну зачем же в МТУ. А как же RS MSK-IX ? Вот надо было им с ОПГ связаться. :(

     

    А у меня почему то никакого МТУ не получается:

     

    host v3.cache.googlevideo.com

    v3.cache.googlevideo.com is an alias for v3.cache.l.google.com.

    v3.cache.l.google.com has address 74.125.13.22

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

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

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

    Не платил? Виноват. В правилах описано. Что бы обратно, сново платим стоимость регистрации, что то там около 2000 евриков. Вот и думай потом кому больше нужно что бы счета доходили им или вам.

  5. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

    На вопрос что кушает CPU есть простой ответ : Interrupts

     

    Это видно из вашего первого поста CPU utilization for five seconds: 82%/72%

     

    Всего 82% из них Interrupts 72%

     

    А если сделать вот так:

     

    conf t

    interface FastEthernet0

    ip route-cache flow

    Это не правильный вывод. Если бы вторая цифра не 72, а, скажем, 20 - тогда бы такая команда имел эффект.

     

    Надо сделать что-то вроде

    sh processes cpu sorted

     

    И посмотреть верхние строки.

    В исходном примере видно, что довольно много потребляет CCH323_CT.

    Но вот почему - не могу помочь. А может еще что-то требует ресурсов...

    sh debug еще можно сделать. Если что-то включено - надо включить, он потребяет много.

    Вот пример моей цизки:

     

    CPU utilization for five seconds: 19%/18%; one minute: 20%; five minutes: 18%

    PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

    122 3603880 14368265 250 0.15% 0.21% 0.19% 0 VOIP_RTCP

    118 6340296 19126533 331 0.15% 0.25% 0.26% 0 VTSP

    47 3296704 9196925 358 0.15% 0.25% 0.34% 0 IP Input

    136 8383092 6279432 1335 0.15% 0.42% 0.41% 0 CCH323_CT

    24 3101688 4399159 705 0.07% 0.04% 0.02% 0 Net Background

    146 573012 5762910 99 0.07% 0.02% 0.01% 0 ISDN L2D SRQ Pro

    111 4088832 1446437 2826 0.07% 0.21% 0.25% 0 ISDN

     

    Ситуация примерно такая же с учетом меньшей нагрузки, дейсвительно если сложить (0.15*4)+(0.07*3)=0.81 Вот что говорит cisco.com по этому поводу :

     

    show processes cpu Command

     

    This is an example of the header of the show processes cpu command:

     

    CPU utilization for five seconds: X%/Y%; one minute: Z%; five minutes: W%

    PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

     

    X Average total utilization during last five seconds (interrupts + processes)

     

    Y Average utilization due to interrupts, during last five seconds1

     

    Всё подтверждается это interrupts !!!

     

    Есть даже ссылка для решения этой проблемы, но пока вопрос остаётся открытым. Действительно нагрузка великовата явно 4 потока не потянет:

     

    http://www.cisco.com/en/US/products/hw/rou...0801c2af0.shtml

     

    понимаю что пример для 7500 для 5300 пока похожий документ не видел.

     

    Должно быть решение факт. И как правило 1 командой. Но какой пока вопрос?

  6. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

    Тогда это похоже на CSCdt09262 .

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

    Не в данном случае.

    На вопрос что кушает CPU есть простой ответ : Interrupts

     

    Это видно из вашего первого поста CPU utilization for five seconds: 82%/72%

     

    Всего 82% из них Interrupts 72%

     

    А если сделать вот так:

     

    conf t

    interface FastEthernet0

    ip route-cache flow

     

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

    А вот что пишет представитель google:

     

    we are not announcing prefixes learned in Moscow to Youtube at this time so you cannot get AS36561 other than transit. However please note that as we complete our rollout of AS15169 we will be adding more traffic to what you currently receive.

     

    И с учетом пробежавшего письма в рассылка MSK-IX данных которыми поделился x567y и выше написанного. Ютюб будет на RS. Другой вопрос когда.

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

    Огромное спасибо! Проблема решена. Во всяком случае сейчас я её не вижу. Сегодня увеличу нагрузочку еще понаблюдаю.

    Для информации, мало ли кому пригодиться, после переезда на sb11 ни в какую не хотели коннектиться пользователи с включенным LCP.

    Было решено заменой в конфигурации:

    ppp callback accept на

    ppp callback request

    Пока полёт нормальный.

  13. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

    Схема примерно такая:

    ppp->cisco4948->cisco7204->Internet

     

    Тоннель поднимается от клиента идёт через 4948 и терминируется на 7204 На интерфейсе Virtual-access поднимаются 2 rate-limit'a вот такого примерна вида:

    Virtual-Access3

    Input

    matches: all traffic

    params: 2248000 bps, 422400 limit, 844800 extended limit

    conformed 24055538 packets, 30860M bytes; action: transmit

    exceeded 549699 packets, 735192515 bytes; action: drop

    last packet: 16ms ago, current burst: 0 bytes

    last cleared 1d16h ago, conformed 1691000 bps, exceeded 40000 bps

    Output

    matches: all traffic

    params: 2240000 bps, 422400 limit, 844800 extended limit

    conformed 16160156 packets, 3630M bytes; action: transmit

    exceeded 15253 packets, 14977749 bytes; action: drop

    last packet: 16ms ago, current burst: 320 bytes

    last cleared 1d16h ago, conformed 198000 bps, exceeded 0 bps

     

    И всё бы хорошо, но когда клиент начинает превышать свою скорость и залезать в burst (на Output это видно) Cisco 7204 начинает генерировать пакеты, от своего имени запакованные в GRE назначая их клиенту выставляет TTL 0 и шлёт в сторону 4948.

    4948 Естественно переживает по этому поводу так как TTL 0 лезет в свой CPU и генерирует ответ Time-to-Live exeeded .

    Образовывается прямая зависимость между количеством пакетов CPU Load и нервным состоянием.

     

    Товарищи помогите! Не знаю где еще и самое обидное какими поисковыми запросами найти решение этой проблемы.

     

    IOS c7200p-advipservicesk9-mz.124-4.XD7.bin проблема обнаружена.

    IOS c7200p-adventerprisek9-mz.124-4.XD10.bin проблема не исчезла.

    Других иосов не пробовал за не имением.

     

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

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

    У бегущей сети проблем нет, гугль зашел на RS. Остальным придется задуматься о ширинговых отношениях.
    Бегущей сети на RS нету, и видит она Гугль через RETN, который в свою очередь видит его через DE.

     

    А у меня в упор во франкфурт идет Оо

     

    Tracing the route to google.ru (66.249.93.104)

     

    1 195.239.8.37 [AS 3216] 4 msec 48 msec 4 msec

    Ну дак, GT на RS тоже нет.

     

    Ну вот и входняк пошел через IX, с чем всех IX-еров и поздравляю. :)

    А у меня входняк продолжает упорно идти через retn. Что бы это могло значить?

    А ты препендишься в RETN ?

    А вот с препендом всё стало гораздо веселее. Спасибо за мысль.

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

    Гугль дал анонсы на RS MSK-IX

     

    Исходняк попер через IX.

     

    Входняк идет через ТТК, пиры Голды и ТТК с гуглем расположены на DE-CIX, на голду у меня препенд, поэтому идет через ТТК.

    Ну вот и входняк пошел через IX, с чем всех IX-еров и поздравляю. :)

     

    Также Google официально появился и в участниках MSK-IX.

     

    http://www.msk-ix.ru

    http://www.msk-ix.ru/members/?org_oid=37530〈=ru

    А у меня входняк продолжает упорно идти через retn. Что бы это могло значить?

  16. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

     

    А вот и google:

     

    Tracing the route to www.l.google.com (209.85.135.99)

     

    1 msk-ix-gw.google.com (193.232.244.232) 0 msec 0 msec 4 msec

    2 209.85.241.40 [AS 15169] 0 msec 4 msec 0 msec

    3 209.85.241.43 [AS 15169] 24 msec 28 msec 24 msec

    4 209.85.252.190 [AS 15169] 48 msec 48 msec 48 msec

    5 72.14.233.106 [AS 15169] 52 msec 52 msec 56 msec

    6 66.249.94.85 [AS 15169] 56 msec

    209.85.130.21 [AS 15169] 56 msec

    66.249.94.85 [AS 15169] 56 msec

    7 72.14.239.58 [AS 15169] 68 msec 64 msec

    209.85.253.26 [AS 15169] 56 msec

    8 www.l.google.com (209.85.135.99) [AS 15169] 56 msec 56 msec 56 msec

     

    Но youtube'а пока нет...

    А может и не будет, может действительно поисковым своим отросткам жизнь упрощают?

    Хотя время покажет.

    Проверьте plz, исход от Гугла уже пошел через IX ?

    Наш вход от него даже не вздрогнул.

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

  17. Опубликовано · Изменено пользователем M.Os · Жалоба на ответ

    А вот и google:

     

    Tracing the route to www.l.google.com (209.85.135.99)

     

    1 msk-ix-gw.google.com (193.232.244.232) 0 msec 0 msec 4 msec

    2 209.85.241.40 [AS 15169] 0 msec 4 msec 0 msec

    3 209.85.241.43 [AS 15169] 24 msec 28 msec 24 msec

    4 209.85.252.190 [AS 15169] 48 msec 48 msec 48 msec

    5 72.14.233.106 [AS 15169] 52 msec 52 msec 56 msec

    6 66.249.94.85 [AS 15169] 56 msec

    209.85.130.21 [AS 15169] 56 msec

    66.249.94.85 [AS 15169] 56 msec

    7 72.14.239.58 [AS 15169] 68 msec 64 msec

    209.85.253.26 [AS 15169] 56 msec

    8 www.l.google.com (209.85.135.99) [AS 15169] 56 msec 56 msec 56 msec

     

    Но youtube'а пока нет...

    А может и не будет, может действительно поисковым своим отросткам жизнь упрощают?

    Хотя время покажет.