Pull to refresh
9
0
Vitaliy Karlov @vkarlov

User

Send message
Мне кажется, что будь то MPLS, Carrier Ethernet или plain ip routing — не играет особой роли. Суть SDN в том, что есть некий единый brain, который видит всю сеть, как один большой свитч/роутер. И этот «brain» можно программировать как угодно, опираясь, фактически, на любые данные, совершенно наплевав на тот код и рамки, которые накладывает сейчас тот или иной вендор.

Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences. Brocade, насколько я знаю, уже выпустила SDN-свитч, Juniper вроде начал об этом заикаться (насколько это далеко от реалий, а не обычный маркетинг, я затрудняюсь сказать). От Cisco мало что слышал.
Да, вы совершенно правы, только SDN предоставляет гораздо большие возможности, учитывая то, что у Гугла еще толпа неплохих программистов, которые воплотят в реальность любые желания сетевиков. Здесь же я просто показал, как с помощью подручных средств, предоставляемых IOS/JunOS добиться более-менее 100% утилизации сети без потери качества.
Ну не совсем много. Как я уже писал выше, это всегда challenge между толщиной LSP и динамикой поиска. Мы все понимаем, что каналы не резиновые, поэтому некоторые LSP мы специально оставляем довольно толстыми и прибитыми к одному пути (strict ERO), чтобы в случае аварии _любого_ линка на пути, трафик автоматически маршрутизировался в кариера локально (или в пределах POP).
RSVP-TE необходим именно тогда, когда нам нужно управлять трафиком, не обращая внимание на IGP, опираясь лишь на некоторые направляющие или же просто «прибивать» наши LSP к определенному пути, например, при помощи strict ERO. В этом суть данной статьи. Таким образом, мы можем держать, фактически, все линки, за которые платим деньги, с утилизацией, близкой в 100%, максимально снижая себестоимость этой самой сети.

К сожалению, о FRR и facility backup я могу говорить только теоретически, мы не используем это на данный момент. Пресловутая сходимость в 50ms нам не нужна, у нас нет в сети телефонии. Но и опять же, Link/Node protection нужно только для того, чтобы именно в данный момент завернуть трафик куда-то на PLR, таким образом, не потерять его (трафик). При этом, сигнализировать ingress PE что на пути авария и нужно искать срочно другой путь. Но, исходя из того, что у нас линки утилизируются на 100%, нам заворачивать этот трафик просто нету — нет капасити. Поэтому нам проще подождать максимум подождать сходимости BGP, пока необходимые маршруты не развернуться в кариера, либо минимум, пока наши LSP на найдут себе новых путей.
Нет, здесь речь идет о 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'е до тех пор, пока не починится линк.

Information

Rating
Does not participate
Registered
Activity