Jump to content
Калькуляторы

магистрал + пиринг = не айс

Здравствуйте.

Подскажите кто нибудь решение следующей проблемы:

Имеется некий магистрал. У него берем полосу, со следующего месяца, кроме полосы в этом же канале, берем ещё и пиринг (трафик с его ассета без лимитирования). Пиринговый трафик понятно, много выше интернет трафика, а так как все находится в одной трубе нормальных графиков, отображающих реальную необходимость в расширении полосы (интернет) стандартными методами не построить. Переговоры по выносу пиринга в отдельный влан ни к чему не привели, ровно как и доступ к информации отображающей статистику интернет и пирингово трафика.

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

Стоимости, кстати, нет, видимо как-раз из-за "проблем с доступом к информации".

 

По сему вопрос, возможно ли каким либо образом опираясь хотя бы на номера AS или IP адресов выделить трафик для отображения его на графиках.

 

Из железок способных переварить трафик с BGP: в наличии ASR-RP2-ESP20 и Extreme x460.

 

Были мысли на эктриме мирорить трафик по acl в отдельный порт и снимать с него статистику, или на ASR тем же способом мирорить но по ERSPAN (по моему была возможность опираться на ACL), но все как то, если грубо, попахивает. Сейчас трафик приземляется на ASR - варианты с ASR приоритетнее.

 

Адекватных мыслей пока кроме как отказаться от пиринга (если бы он - пиринг был платным) не приходит.

Share this post


Link to post
Share on other sites

ya4ya

повесьте service-policy, который будет по пиринговым сеткам считать трафик. acl придётся обновлять перидочески(генерить по ripe-у или по bgp)

Share this post


Link to post
Share on other sites

Не особо понимаю в пиринге, но нельзя ли считать по destination AS , из netflow.

 

Ведь Netflow / sflow содержат информацию о src AS и dst AS.

Edited by config

Share this post


Link to post
Share on other sites

Т.е. у вас будет 2 BGP сессии?

Исходящий трафик можете считать через Netflow по параметру "IP nexthop".

Входящий трафик корректно посчитать по разным сессиям вам не удастся, т.к. логику выбора маршрута к вам от вашего пира вы не знаете. Мало того, с вероятностью 99% весь входящий трафик пойдет по одной сессии, причем скорее всего по той в которой транзит, а не в той где пиринг.

Share this post


Link to post
Share on other sites

ya4ya

повесьте service-policy, который будет по пиринговым сеткам считать трафик. acl придётся обновлять перидочески(генерить по ripe-у или по bgp)

Да, спасибо то что нужно. Как появиться, попробую не просто по IP acl'ить.

 

 

Т.е. у вас будет 2 BGP сессии?

Исходящий трафик можете считать через Netflow по параметру "IP nexthop".

Входящий трафик корректно посчитать по разным сессиям вам не удастся, т.к. логику выбора маршрута к вам от вашего пира вы не знаете. Мало того, с вероятностью 99% весь входящий трафик пойдет по одной сессии, причем скорее всего по той в которой транзит, а не в той где пиринг.

Да нет, входящий трафик интересует именно приходящий на конкретный интерфейс (его будет много больше, как если бы тот же самый трафик приходил через другой интерфейс - другого аплинка), нужна именно градация трафика пришедшего на конкретный интерфейс, от конкретного аплинка.

Share this post


Link to post
Share on other sites

Да, спасибо то что нужно. Как появиться, попробую не просто по IP acl'ить.

 

В dataplane-е особо вариантов у вас нет. Матчить по AS_PATH и прочим плюшкам это только в controlplane-е можно. Ну кстати, на современных цисках есть встроенный tcl и cron, наверное можно прямо в cisco сделать скрипт, который будет acl править

Share this post


Link to post
Share on other sites

Не понял, так у вас трафик будет терминироваться на одном интерфейсе или на разных?

Share this post


Link to post
Share on other sites

так если б на разных, то тогда вообще говорить не о чем

Share this post


Link to post
Share on other sites

Повторяю: если у вас один интерфейс, на котором настроены 2 BGP сессии, то узнать по какой сессии пришел ВХОДЯЩИЙ трафик не удастся, по крайней мере посредством данных из уровня L3.

 

Поймите, получаемые вами маршруты удаленных сетей со всеми их атрибутами типа AS_path и прочими влияют исключительно на ваш ИСХОДЯЩИЙ трафик. На ваш ВХОДЯЩИЙ трафик будет влиять исключительно то, как ваш пир ВИДИТ У СЕБЯ ваши сети. Более чем в 90% случаев магистрал будет ставить на маршруты даунлинка больший localpref нежели чем на маршруты пира. В этом случае, чтобы вы ни делали(за исключением дробления своей сети на специфики) трафик к вам пойдет по магистральному линку, а не по пиринговому.

Share this post


Link to post
Share on other sites

s.lobanov

Спасибо.

Оказалось все просто. Получаем раскрашенные анонсы. Матчинг необходимых приходящих коммунити решает проблему. Графики рисуем по снмп.

Share this post


Link to post
Share on other sites
route-map xxx

match community-list yyyy

set traffic-index zzz

 

так сделали или как-то по-другому?

Share this post


Link to post
Share on other sites

Возникла похожая задача (посчитать трафик от одной AS). Сделали по цисковскому примеру "BGP Policy Accounting", но счётчики cef interface policy-statistics показывают какие-то смешные числа (~20 пакетов за 5 минут).

Делалось на cisco 7600 с WS-X6708-10GE (DFC3CXL) модулями.

 

Может ли проблема с подсчётом быть вызвана из-за DFC модулей? Или всё-таки "bgp-policy accounting input source" должен нормально работать на 76й даже в таких условиях?

Share this post


Link to post
Share on other sites

На 7600 bgp pa криво работает, проверено на нескольких софтах.

Share this post


Link to post
Share on other sites

Вопрос к ya4ya - а вы на какой железке сделали policy accounting? Где этот функционал работает без проблем?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this