ya4ya Опубликовано 29 мая, 2012 · Жалоба Здравствуйте. Подскажите кто нибудь решение следующей проблемы: Имеется некий магистрал. У него берем полосу, со следующего месяца, кроме полосы в этом же канале, берем ещё и пиринг (трафик с его ассета без лимитирования). Пиринговый трафик понятно, много выше интернет трафика, а так как все находится в одной трубе нормальных графиков, отображающих реальную необходимость в расширении полосы (интернет) стандартными методами не построить. Переговоры по выносу пиринга в отдельный влан ни к чему не привели, ровно как и доступ к информации отображающей статистику интернет и пирингово трафика. Не представляю чем у них может отличаться пиринг от интернета, кроме как наверно управления через коммунити, для галочки? ну да ладно... Стоимости, кстати, нет, видимо как-раз из-за "проблем с доступом к информации". По сему вопрос, возможно ли каким либо образом опираясь хотя бы на номера AS или IP адресов выделить трафик для отображения его на графиках. Из железок способных переварить трафик с BGP: в наличии ASR-RP2-ESP20 и Extreme x460. Были мысли на эктриме мирорить трафик по acl в отдельный порт и снимать с него статистику, или на ASR тем же способом мирорить но по ERSPAN (по моему была возможность опираться на ACL), но все как то, если грубо, попахивает. Сейчас трафик приземляется на ASR - варианты с ASR приоритетнее. Адекватных мыслей пока кроме как отказаться от пиринга (если бы он - пиринг был платным) не приходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arseniiv Опубликовано 29 мая, 2012 · Жалоба посмотрите PRTG. вроде им можно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 29 мая, 2012 · Жалоба ya4ya повесьте service-policy, который будет по пиринговым сеткам считать трафик. acl придётся обновлять перидочески(генерить по ripe-у или по bgp) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 29 мая, 2012 (изменено) · Жалоба Не особо понимаю в пиринге, но нельзя ли считать по destination AS , из netflow. Ведь Netflow / sflow содержат информацию о src AS и dst AS. Изменено 29 мая, 2012 пользователем config Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 30 мая, 2012 · Жалоба Т.е. у вас будет 2 BGP сессии? Исходящий трафик можете считать через Netflow по параметру "IP nexthop". Входящий трафик корректно посчитать по разным сессиям вам не удастся, т.к. логику выбора маршрута к вам от вашего пира вы не знаете. Мало того, с вероятностью 99% весь входящий трафик пойдет по одной сессии, причем скорее всего по той в которой транзит, а не в той где пиринг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ya4ya Опубликовано 30 мая, 2012 · Жалоба ya4ya повесьте service-policy, который будет по пиринговым сеткам считать трафик. acl придётся обновлять перидочески(генерить по ripe-у или по bgp) Да, спасибо то что нужно. Как появиться, попробую не просто по IP acl'ить. Т.е. у вас будет 2 BGP сессии? Исходящий трафик можете считать через Netflow по параметру "IP nexthop". Входящий трафик корректно посчитать по разным сессиям вам не удастся, т.к. логику выбора маршрута к вам от вашего пира вы не знаете. Мало того, с вероятностью 99% весь входящий трафик пойдет по одной сессии, причем скорее всего по той в которой транзит, а не в той где пиринг. Да нет, входящий трафик интересует именно приходящий на конкретный интерфейс (его будет много больше, как если бы тот же самый трафик приходил через другой интерфейс - другого аплинка), нужна именно градация трафика пришедшего на конкретный интерфейс, от конкретного аплинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 мая, 2012 · Жалоба Да, спасибо то что нужно. Как появиться, попробую не просто по IP acl'ить. В dataplane-е особо вариантов у вас нет. Матчить по AS_PATH и прочим плюшкам это только в controlplane-е можно. Ну кстати, на современных цисках есть встроенный tcl и cron, наверное можно прямо в cisco сделать скрипт, который будет acl править Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 30 мая, 2012 · Жалоба Не понял, так у вас трафик будет терминироваться на одном интерфейсе или на разных? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 мая, 2012 · Жалоба так если б на разных, то тогда вообще говорить не о чем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 30 мая, 2012 · Жалоба Повторяю: если у вас один интерфейс, на котором настроены 2 BGP сессии, то узнать по какой сессии пришел ВХОДЯЩИЙ трафик не удастся, по крайней мере посредством данных из уровня L3. Поймите, получаемые вами маршруты удаленных сетей со всеми их атрибутами типа AS_path и прочими влияют исключительно на ваш ИСХОДЯЩИЙ трафик. На ваш ВХОДЯЩИЙ трафик будет влиять исключительно то, как ваш пир ВИДИТ У СЕБЯ ваши сети. Более чем в 90% случаев магистрал будет ставить на маршруты даунлинка больший localpref нежели чем на маршруты пира. В этом случае, чтобы вы ни делали(за исключением дробления своей сети на специфики) трафик к вам пойдет по магистральному линку, а не по пиринговому. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ya4ya Опубликовано 20 июня, 2012 · Жалоба s.lobanov Спасибо. Оказалось все просто. Получаем раскрашенные анонсы. Матчинг необходимых приходящих коммунити решает проблему. Графики рисуем по снмп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 20 июня, 2012 · Жалоба route-map xxxmatch community-list yyyy set traffic-index zzz так сделали или как-то по-другому? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ya4ya Опубликовано 21 июня, 2012 · Жалоба да, именно так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 3 ноября, 2012 · Жалоба Возникла похожая задача (посчитать трафик от одной AS). Сделали по цисковскому примеру "BGP Policy Accounting", но счётчики cef interface policy-statistics показывают какие-то смешные числа (~20 пакетов за 5 минут). Делалось на cisco 7600 с WS-X6708-10GE (DFC3CXL) модулями. Может ли проблема с подсчётом быть вызвана из-за DFC модулей? Или всё-таки "bgp-policy accounting input source" должен нормально работать на 76й даже в таких условиях? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shvlad1 Опубликовано 4 ноября, 2012 · Жалоба На 7600 bgp pa криво работает, проверено на нескольких софтах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 5 ноября, 2012 · Жалоба Вопрос к ya4ya - а вы на какой железке сделали policy accounting? Где этот функционал работает без проблем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...