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

[ya4ya]

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

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

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

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

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

 

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

 

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

 

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

 

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

[arseniiv]

посмотрите PRTG. вроде им можно

[s.lobanov]

ya4ya

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

[config]

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

 

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

Edited May 29, 2012 by config

[agr]

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

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

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

[ya4ya]

ya4ya

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

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

 

 

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

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

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

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

[s.lobanov]

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

 

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

[agr]

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

[s.lobanov]

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

[agr]

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

 

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

[ya4ya]

s.lobanov

Спасибо.

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

[s.lobanov]

route-map xxx

match community-list yyyy

set traffic-index zzz

 

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

[ya4ya]

да, именно так.

[OKyHb]

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

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

 

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

[shvlad1]

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

[OKyHb]

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