Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Отличная статья.
Очень интересно.
Здесь речь идет про eBGP next-hop? Т.е. IP роутера в соседней AS? Не очень понимаю тогда, как нарезать туннели по 1-2 Gbps?
Чтобы наши LSP не становились слишком «жирными», мы будем примерно ограничивать LSP в пределах 1-2Gbps, т.е. мапить в этот туннель примерно ~1Gbps трафика. Это занятие мы предоставим нашим BGP RR'ам. Маппинг происходит простым способом: bgp next-hop reachability.
Здесь речь идет про eBGP next-hop? Т.е. IP роутера в соседней AS? Не очень понимаю тогда, как нарезать туннели по 1-2 Gbps?
Нет, здесь речь идет о iBGP, т.к. маппинг происходит на ingress PE. Наш RR отдает некое, как мы его называем, «направление», например, в понятиях Juniper'а — as-path-group. Этому направлению присваиваится уникальный next-hop, известный только ingress и egress PE. Как я уже писал в статье, именно этот NH не ходит в нашем IGP. Количество же трафика, которое маппится в данный конкретный LSP и регулируется набором этих самых AS_PATH.
Например,
PE1-PE2-1 — as-path-group-1 — NH: 192.168.1.1
PE1-PE2-2 — as-path-group-2 — NH: 192.168.1.2
и тд
Идея делать LSP «потоньше» в том, чтобы они могли найти себе пути сами, исходя из текущей загрузки. Если LSP будут довольно «жирными», то они с очень большой вероятностью не найдут себе свободной емкости и будут в down'е до тех пор, пока не починится линк.
Например,
PE1-PE2-1 — as-path-group-1 — NH: 192.168.1.1
PE1-PE2-2 — as-path-group-2 — NH: 192.168.1.2
и тд
Идея делать LSP «потоньше» в том, чтобы они могли найти себе пути сами, исходя из текущей загрузки. Если LSP будут довольно «жирными», то они с очень большой вероятностью не найдут себе свободной емкости и будут в down'е до тех пор, пока не починится линк.
Спасибо, теперь ясно. Интересная схема. Наверное, монструозный конфиг получается на RR с кучей policy-map. Просто интересно, сколько у вас там таких as-path-group прибито руками?
Ну не совсем много. Как я уже писал выше, это всегда challenge между толщиной LSP и динамикой поиска. Мы все понимаем, что каналы не резиновые, поэтому некоторые LSP мы специально оставляем довольно толстыми и прибитыми к одному пути (strict ERO), чтобы в случае аварии _любого_ линка на пути, трафик автоматически маршрутизировался в кариера локально (или в пределах POP).
Ну а если в какую-нибудь AS вдруг начнет литься траффика значительно больше, чем зарезервировано в туннеле? Например, у вас есть гигабитный туннель для десятка AS, вдруг траффик в одну AS значительно возрастает и суммартный траффик туннеля становится больше гига. Это как-то обрабатывается автоматически или требует ручного вмешательства?
Я еще только изучаю rsvp-te и поэтому могу чего-то не понимать и задавать глупые вопросы. Заранее прошу прощения :)
Я еще только изучаю rsvp-te и поэтому могу чего-то не понимать и задавать глупые вопросы. Заранее прошу прощения :)
давно пытаюсь понять суть RSVP-TE и решить нужен ли он… спасибо за понятное разъяснение. Если не трудно, то хотелось бы почитать про реализацю FRR и необходимые для этого протоколы и настройки (path profile и др.)
RSVP-TE необходим именно тогда, когда нам нужно управлять трафиком, не обращая внимание на IGP, опираясь лишь на некоторые направляющие или же просто «прибивать» наши LSP к определенному пути, например, при помощи strict ERO. В этом суть данной статьи. Таким образом, мы можем держать, фактически, все линки, за которые платим деньги, с утилизацией, близкой в 100%, максимально снижая себестоимость этой самой сети.
К сожалению, о FRR и facility backup я могу говорить только теоретически, мы не используем это на данный момент. Пресловутая сходимость в 50ms нам не нужна, у нас нет в сети телефонии. Но и опять же, Link/Node protection нужно только для того, чтобы именно в данный момент завернуть трафик куда-то на PLR, таким образом, не потерять его (трафик). При этом, сигнализировать ingress PE что на пути авария и нужно искать срочно другой путь. Но, исходя из того, что у нас линки утилизируются на 100%, нам заворачивать этот трафик просто нету — нет капасити. Поэтому нам проще подождать максимум подождать сходимости BGP, пока необходимые маршруты не развернуться в кариера, либо минимум, пока наши LSP на найдут себе новых путей.
К сожалению, о FRR и facility backup я могу говорить только теоретически, мы не используем это на данный момент. Пресловутая сходимость в 50ms нам не нужна, у нас нет в сети телефонии. Но и опять же, Link/Node protection нужно только для того, чтобы именно в данный момент завернуть трафик куда-то на PLR, таким образом, не потерять его (трафик). При этом, сигнализировать ingress PE что на пути авария и нужно искать срочно другой путь. Но, исходя из того, что у нас линки утилизируются на 100%, нам заворачивать этот трафик просто нету — нет капасити. Поэтому нам проще подождать максимум подождать сходимости BGP, пока необходимые маршруты не развернуться в кариера, либо минимум, пока наши LSP на найдут себе новых путей.
Мне кажется, Гугл делает все то же самое в своей сети, но не с помощью роутеров и MPLS, а с помощью коммутаторов, управлемых по OpenFlow.
Не совсем так. Вот статейка на этот счет: blog.ioshints.info/2012/05/openflow-google-brilliant-but-not.html Они все так же используют mpls, но управляют LSP другими средствами.
Мне кажется, что будь то MPLS, Carrier Ethernet или plain ip routing — не играет особой роли. Суть SDN в том, что есть некий единый brain, который видит всю сеть, как один большой свитч/роутер. И этот «brain» можно программировать как угодно, опираясь, фактически, на любые данные, совершенно наплевав на тот код и рамки, которые накладывает сейчас тот или иной вендор.
Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences. Brocade, насколько я знаю, уже выпустила SDN-свитч, Juniper вроде начал об этом заикаться (насколько это далеко от реалий, а не обычный маркетинг, я затрудняюсь сказать). От Cisco мало что слышал.
Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences. Brocade, насколько я знаю, уже выпустила SDN-свитч, Juniper вроде начал об этом заикаться (насколько это далеко от реалий, а не обычный маркетинг, я затрудняюсь сказать). От Cisco мало что слышал.
Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences
Кто-то говорит про отсутствие проприетарных расширений?
SDN станет эпическим vendor lock-in. На заявления о полной открытости не обращайте внимание.
Ах да — где-то под SDN еще много десятилетий будут работать традиционные IGP протоколы и TE туннели, чтобы сразу подхватить трафик, как только контроллер потеряется. У Google это именно так.
От Cisco мало что слышал.
У них было нечто похожее на SDN еще до того, как это стало модно: OER/PfR.
А сейчас есть ONE. Работает практически на любом имеющемся оборудовании, включая ISR и многие каталисты.
Да, все верно, со всем согласен. Однако C/J могут и не потерять пирога или по крайней мере принять активное участие в его дележке. Вендоры все равно будут реализовывать свои дополнения к OpenFlow, плюс к этому они будут выпускать свои openflow контроллеры с пропиетарными «мега-фичами» используюя проприетарные расширения к OpenFlow, так что пути для монетизации еще есть, главное не упустить момент.
Да, вы совершенно правы, только SDN предоставляет гораздо большие возможности, учитывая то, что у Гугла еще толпа неплохих программистов, которые воплотят в реальность любые желания сетевиков. Здесь же я просто показал, как с помощью подручных средств, предоставляемых IOS/JunOS добиться более-менее 100% утилизации сети без потери качества.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление трафиком в сети хостинг-провайдера